Chimera Real-Time Operating System

David B. Stewart and Pradeep K. Khosla

Advanced Manipulators Laboratory, The Robotics Institute, Carnegie Mellon University, Pittsburgh, PA 15213

Questions regarding Chimera should be directed to Dr. David B. Stewart.

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.


Chimera Hardware Support List

October 1, 1993.

RTPU drivers (General Purpose Processor Boards, on which Chimera kernel is

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

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