The Advanced Manipulators Laboratory, at Carnegie Mellon University, has developed the Chimera Real-Time Operating System, a next generation multiprocessor real-time operating system (RTOS) designed especially to support the development of dynamically reconfigurable software for robotic and automation systems. Version 3.0 and later of the software is already being used by several institutions outside of Carnegie Mellon, including university, government, and industrial research labs.
Chimera provides most of the features available in commercial real-time operating systems, and performs as well as VxWorks, OS-9, VRTX, and LynxOS. In some cases, such as interprocessor communication, Chimera performance is an order of magnitude faster. The main strength of Chimera, however, lies in the multitude of features offered which are necessary for quickly developing reconfigurable and reusable code, but are not available in other real-time operating systems.
Chimera is a VMEbus-based operating system which supports multiple general and special purpose processors. General purpose processors come in the form of single-board-computers (currently MC680x0 family of processors supported) which we call Real-Time Processing Units (RTPUs). Chimera has a full-featured real-time kernel which supports both static and dynamic scheduling, extensive error detection and handling, a full set of library utilities, several different multiprocessor communication and synchronization primitives, and a fully integrated host workstation environment. More detail into each of these is given below. Both C and C++ programming languages are supported, with the GNU CC compiler being used for cross-compilation for the target hardware.
The Chimera real-time kernel is multitasking, allowing multiple tasks to run concurrently. By default, the kernel supports both fixed (e.g. rate monotonic algorithm) and dynamic priority scheduling (including earliest-deadline-first and the maximum-urgency-first scheduling algorithms). It uses a policy/mechanism separation which allows the user to easily customize any part of the kernel or to add a new scheduler. The context switch time is 66 usec, which includes the complete save and restore operation of both the main CPU and MC68882 co-processor registers. The dynamic scheduler takes 26 usec per reschedule operation.
Hardware timers are controlled by the operating system, thus allowing software developers to write programs with timing constraints for any number of tasks. This method allows any number of tasks to pause on a time signal, regardless of the number of timers available in hardware, and takes away the need for the user to program any timers. Periodic and Aperiodic tasks are all programmed in the same way, and deadline and execution times may optionally be specified for use with both static and dynamic scheduling algorithms. For small delays, a "delay" utility automatically times the speed of the processor, and performs an empty loop for the duration of the delay, which is specified in seconds.
The kernel also supports high-performance local semaphores (7 usec for non-blocking call on a 20MHz MC68020). UNIX-compatible system calls are usually implemented in user space in order to minimize kernel overhead and improve response time of applications. C-language interfaces to local, VMEbus, and mailbox interrupts are provided, which allow quick development of interrupt-driven applications. The kernel automatically configures itself to use the built-in devices of the RTPU for providing these services, allowing the same binary executable to run on several different models of RTPU, as long as they use the same processor family.
An extensive set of utility libraries are provided, including typical UNIX libraries (e.g. strings, math, random, time, etc.), a concurrent standard I/O (e.g. printf, fgets, etc. with multitasking synchronization), a matrix math package (e.g. addition, inverse, gaussian elimination, determinant, etc.), a command interpreter library for quickly developing custom command-line interfaces, a configuration file reading utility, and a variety of other useful utilities.
Chimera has elaborate error detection and error handling capabilities. Its most prominent features are the global error handling and deadline failure handling mechanisms. With the global error handling, errors within the system or user modules generate an error signal, which in turn invokes a previously defined error handler. It completely removes the need to have to check error return values, such as if (read(...) == -1) then perror(...). A default error handler is provided to print out an error message and abort the task. The default handler can be overriden by any number of user-defined handlers. The handlers can be assigned to specific errors, or any set of errors based on the module or scope where the error occured. Processor exceptions also generate error signals, allowing both processor exceptions and software errors to be handled with a single mechanism. The mechanism is also able to detect various memory corruption problems, thus aiding in tracking down bugs in the system at an early stage. A debug mode causes the exact file, module, and source code line number of where the error handling was invoked, as well as a trace of any user-defined error handlers called, to aid in debugging. This form of error handling allows the separation of program code and error handling code, thus making the code much easier to develop and maintain.
The deadline failure handling operates in a similar manner to the global error handling, except that it detects timing errors, such as missed deadlines, insufficient CPU time avaiable, and maximum estimated CPU time for a task surpassed. User error handlers can be installed to alter the default action of the system.
If the global error handling is not enabled, then standard system calls (such as open(), read(), etc.) have the functionality of their UNIX counterparts; for example, they will return -1 on error, and set errno.
Chimera is a true multiprocessor real-time operating system, unlike most commercial RTOS, which are single processor operating systems that are replicated on multiple CPUs and communicate with each other using some form of network protocol. The real-time kernels communicate with each other with a low-overhead, non-blocking message passing mechanism which we call express mail. This underlying system communication provides the basis for many different user-level real-time multiprocessor communication and synchronization mechanisms, including dynamically allocatable global shared memory, remote semaphores, prioritized message passing, global state variable tables, multiprocessor subsystem task control, remote procedure calls, host workstation integration, remote symbolic debugging, triple-buffer external subsystem communication, and the extended file system.
Chimera provides many tools for quickly developing dynamically reconfigurable sensor-based control systems, such as the multiprocessor subsystem task control mechanism, the global state variable table, reconfigurable device drivers, generic sensor/actuator and special purpose processor interfaces, and a configuration file reading mechanism. The operating system automatically integrates the reconfigurable modules by creating and initializing tasks on the appropriate RTPUs, setting up inter-module communication paths, handling their timing and synchronization, catching and directing signals which control flow of an application, and providing on-line information of a subsystem such as state of each task, measured versus desired frequency, missed deadlines, and execution and CPU utilization of each task, through the use of a novel tool built-into the kernel which we call automatic task profiling.
Chimera provides a network interface to Onika, so that programmers can work with real-time code graphically by combining icons representing real-time modules into reusable software. Both high-level event-driven applications and low-level feedback software can be generated, modified, debugged, and executed in this fashion.
Chimera is already being used by many systems in university, industry, and government labs. These include Carnegie Mellon University, The Jet Propulsion Laboratory, California Institute of Technology, Concordia University, Air Force Institute of Technology, and University of Alberta. Chimera has allowed all of these systems to share both software and hardware, thus reducing the development costs and improving the flexibility of applications. Chimera has also proven itself to be an excellent testbed for real-time systems groups, because every part of the kernel can easily be overriden by user's code.
Click here for an annotated presentation of Chimera 3.0, The Real-Time Operating System for Reconfigurable Sensor-Based Control Systems.
Click here for the Chimera v3.2 manual.
October 1, 1993.
RTPU drivers (General Purpose Processor Boards, on which Chimera kernel is
executed)
model processor Description
--------------- --------------- --------------------------------------------
IV3201A MC68020 Ironics IV3201A
IV3204A MC68020 Ironics IV3204A
IV3220 MC68020 Ironics IV3220
IV3230 MC68030 Ironics IV3230
PME6833 MC68030 Radstone PME 68-33
IV3207 MC68040 Ironics IV3207 (expected Jan. 1994)
ADT drivers (Bus adaptors for hooking up a Sun host workstation to
a VMEbus.)
model host slave driver Description
--------- ------ ------ ------ -------------------------------------------
BIT3_412 VMEbus VMEbus hxm BIT3 Corp. Model 412
BIT3_413 VMEbus VMEbus hxm BIT3 Corp. Model 413
BIT3_466 Sbus VMEbus sxm BIT3 Corp. Model 416
PTSBS915 Sbus VMEbus pxm Performance Technologies, Model PT-SBS915
(expected Jan 1994)
SPP drivers (Special Purpose Processors, which execute Chimera executive, and
operator as slave processors in the system)
model driver nproc size(hex) Description
--------------- ------ ----- --------- ------------------------------------
MC3200 mcfpa 1 200000 Mercury 3200 FPU
SKYI860 bolt 1 400000 Skybolt i860 FPU
IOD drivers (I/O devices)
model type driver nports size(hex) Description
---------- ---- ------ ------ -------- ------------------------------------
BIT3_412 MEM bit var var BIT3 Model 412
BIT3_413 MEM bit var var BIT3 Model 413
DT1401 ADC dtadc 32 10 Data Translation ADC/DAC
DT1401 DAC dtdac 2 8 Data Translation ADC/DAC *1
DVME601B ADC diadc 16 10000 Datel Intelligent ADC
IV1623 PIO ipio 6 20 Ironics PIO
IV1640 DAC idac 8 10000 Ironics DAC
IV1642 ADC iadc 16 80 Ironics ADC
IV1643 DAC mdac 16 20 Ironics ADC (same as MPV904)
IV1645S ADC iadc 16 80 Ironics ADC
IV3220 SIO isio 2 20 Ironics SIO, local to IV3220 RTPU
IV3230 SIO isio 2 20 Ironics SIO, local to IV3230 RTPU
MPV901 ADC iadc 16 80 Burr Brown/Pentland ADC (same as IV1642)
MPV904 DAC mdac 8 20 Burr Brown/Pentland ADC
MPV950S ADC iadc 16 80 Burr Brown/Pentland ADC(same as IV1645S)
MPV954 DAC idac 8 10000 Burr Brown/Pentland ADC (same as IV1640)
TRC005 RCB trpi 3 40 Trident Robotics Puma RCB
VMIC4100 DAC vdac 16 20 VMIC DAC
VMIC2510B PIO vpio 2,4,8s 10 VMIC PIO
XVME500/* ADC xadc 16,32h 400 XYCOM ADC
XVME590/* ADC xadc 16,32h 400 XYCOM ADC (same as XVME500/[123])
XVME505/* DAC xdac 4 100 XYCOM DAC
XVME595/* DAC xdac 4 100 XYCOM DAC (same as XVME505/[12])
XVME240 PIO xpiofts 4 400 XYCOM PIO for LORD FTS
[SIO=Serial I/O, ADC=Analog-to-Digital Converter, DAC=Digital-to-Analog
Converter, PIO=Parallel I/O, RCB=Robot Control Board, MEM=Shared Memory
Interface]
SAI drivers (drivers for sensors and actuators)
model Description
----- ------------------------------------------------------------
dim6 'Dimension 6' six-dof trackball; uses an SIO-type IOD driver
pumad Puma Driver, uses RCB-type IOD driver
lfts Lord Force Sensor, uses PIO-type IOD driver
pgrip Puma pneumatic gripper, uses RCB-type IOD driver
vis External Vision Subsystem, uses MEM-type IOD driver