I'm trying to identify the operating system on a Thermo-CRS C500 robot arm controller. From the specifications I know it runs on a 100 MHz 486 processor, and has 4 MB RAM and 2MB of flash/NVRAM combination for filesystem.

All the identifying strings in the system only refer CROS -- CRS Robot Operating System -- v 3.1.1249. It may be that this is a completely custom kernel, but it might also be based on some kind of BSD or other UNIX-like system.

The system shell has a quite unix-like environment. Most of the system binaries, such as /bin/cp and others are implemented in some kind of bytecode. The bytecode interpreter resides in /sbin/r3interp, which file indentifies as FreeBSD/i386 compact demand paged executable.

The kernel binary contains some strings that could help identification:

  • Caught wild IRQ 0
  • double fault exception (very bad) [e=%08x]
  • invalid TSS exception [e=%08x]
  • Cur_Proc->pr_vfsd.vf_vp == 0
  • sp->owner == Cur_Proc->proc_id

In particular the x86 exception names exist in most kernels, but not in that form. I have already checked late 1990s versions of FreeBSD, 386BSD, Linux 1.x, Minix 1 and 2, Xenix 386 and NetBSD, but haven't found a match. For more detailed analysis, binaries are here and boot messages here.

Can someone figure out some obscure Unix version that might be the base of this customized system?

  • What about an in house product? – UncleBod Jun 14 '20 at 11:26
  • 2
    Even an in house system is going to start from something with this file system. – Mark Williams Jun 14 '20 at 11:44
  • Have you tried to identify the manufacturer? They might be willing to tell you. – UncleBod Jun 14 '20 at 12:22
  • 1
    @UncleBod I haven't tried contacting them for this, but some other people did about other information about the system - it seems they don't have anyone who could answer, as the system hasn't been manufactured since ~2003. – jpa Jun 14 '20 at 13:43
  • What happens if you use readelf on r3interp? – John Dallman Jun 14 '20 at 14:51

Here's a manual for CROS and one for the C500C robot controller. It seems clear that the bytecode files are compiled from the RAPL-3 programming language (no filename extension for binaries, .r3 for source files, .v3 for "variables files". There's a manual for the language here and for the development tools, which run on Windows, here. The manual for updating CROS on the controller is here which makes it clear that CROS is updated by re-writing the OS image on the controller, then rebuilding the filesystem on the controller.

I can't find anything in any of these manuals that indicates that CROS is based on any other OS. Given the scale of the software provided for it, it seems plausible that it was purpose-written for the job. Re-using a BSD file format would save some wheel-reinvention, but it could also be a coincidence of magic numbers. The boot-up messages don't say anything about the Regents of the University of California, which is a requirement with BSD-licensed code.

  • 2
    Yeah, I guess you are right. Nowadays it would be weird for any company to spend so much time reinventing the basic operating system, but things were different back in 1990s. And after all they did make up a custom programming language. – jpa Jun 14 '20 at 15:20
  • 6
    I think we often overestimate the effort it takes to design a programming language, or implement a compiler or operating system. Yes, implementing an operating system that can reliably run on millions of possible combinations of CPUs, busses, graphics cards, storage controllers, network cards, can scale from watches to 10000 CPU supercomputers, can support batch, interactive, transactional, and realtime workloads, support I/O-bound and CPU-bound workloads, steady and highly volatile workloads, and be easy to use for novices while being powerful for experts is hard. But this is not such an OS. – Jörg W Mittag Jun 14 '20 at 19:59
  • 3
    … this OS has 1 well-defined hardware platform, 1 well-defined workload, and 0 users. – Jörg W Mittag Jun 14 '20 at 20:00
  • 2
    @jpa Not at all. For robotics and industrial equipment it is in fact very common to write the entire operating system from scratch. The only reason you'd use an existing operating system is if you need TCP/IP networking and can't find a good library or save files on standard filesystems like NTFS or EXT3 and can't find a good libraryor need a GUI and can't find a good library because they require writing complicated drivers . If you're doing none of the above it's easier to manage your processes directly by using timer interrupts in your own code – slebetman Jun 15 '20 at 6:30
  • 2
    Way back when, working on an embedded system, I wrote an OS in 8086 assembly. It handled radio communications using a homegrown protocol, dynamic memory management, digital and analog I/O, and it had a bytecode interpter. I also wrote the compiler, in C, that turned a DSL into bytecodes to run on the embedded system. It wasn't as big a task as a modern OS because the requirements were very specific. I only had to support just what the system needed, no more, no less. – Wayne Conrad Jun 15 '20 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.