INTRODUCTION
INTRODUCTION | |
The principal responsibility of a real-time (RT) operating system (RTOS) can be summarized as that of producing correct results while meeting predefined deadlines in doing so. Therefore, the computational correctness of the system depends on both the logical correctness of the results it produces, and then timing correctness, i.e. the ability to meet deadlines, of its computation.
Hard real-time (HRT) operating systems can be thought as a particular subclass of RT systems, in which the lack of adherence to the above mentioned deadlines may result in a catastrophic system failure.
An RT application can be modeled as a set of cooperating tasks. These tasks can be classified according to their timing requirements, as hard real-time (HRT), and not real-time (NRT). A HRT task is a task whose timely (and logically correct) execution is labeled as critical for the operation of the whole system. The deadline associated to a HRT task is pronounced hard deadline. Consequently, it is assumed that the missing of a hard deadline can result in a tragic system failure. NRT tasks are those tasks which exhibits no real-time requirements (e.g. system maintenance tasks that can run occasionally in the background). The taxonomy of application tasks can de further expanded with the terms periodic, aperiodic and sporadic. Periodic tasks are tasks which enter the execution state at regular intervals of time, i.e. every T time units. These tasks are usually associated with hard deadlines. Aperiodic tasks are tasks whose execution time cannot be anticipated, as their execution is determined by the occurrence of some internal or external events. These tasks are usually NRT tasks. Finally, aperiodic tasks bound to hard deadlines are termed sporadic tasks, e.g. tasks dealing with the occurrence of system failures (exceptions), or prioritized responses to some event.
With the above classifications in mind, one can observe that the principal responsibility of a RT operating system is to guarantee that each individual execution of each application task can meet the timing requirements of that task. However, it is worth noting that, in order to fulfill that responsibility, the objective of a RT operating system cannot be stated just as that of minimizing the average response time of each application task; rather the fundamental concern of a RT operating system is that of being predictable.
Two general paradigms for the design of predictable RTOSes can be found: Event-Triggered (ET) and Time-Triggered (TT). In ET RTOSes any system activity is initiated in response of the occurrence of a particular event, caused by the system environment (mainly software or hardware interrupt vectors). In TT RTOSes system activities are initiated as predefined instants of the globally synchronized clock recur (scheduling, dispatching of events).
The XOberon operating system is a rapid application development (RAD) tool for high-end mechatronic products, developed at the Institute of Robotics (IfR), Swiss Federal Institute of Technology, Zürich (ETHZ). XOberon is loosely based on the Oberon Operating System, and it is written in the Oberon-2, Object Oriented programming language. Both the Oberon System and the programming language Oberon-2 were developed at the Institute for Computer Systems of ETHZ. The XOberon RTOS runs natively on Motorola VME boards based on Motorola MC68040 and PowerPC architectures.
XOberon is divided in components, like the Memory Manager, the Scheduler, the Linker, the Communication Support, and the Drivers Interface. Hereafter, some highlights of each component will be presented.
The real-time kernel is the most important part of the system, since it incarnates the hard real-time nature of the system, along as acting as an interface-published, real-time framework for the application programmer. The real-time kernel features a deadline driven, admission testing scheduler, which presents to the application programmer an object oriented abstraction layer for modeling user tasks. Each task fed to the scheduler has the following characteristics: an entry-point (i.e. a procedure), a duration and a deadline. Furthermore, repetitive tasks are characterized by a period. Each task is admission-tested by the scheduler, after being fed. A positive response by the scheduler, states that the operating system will be able to guarantee that the task will be started, executed and retired before the expiration of the deadline (i.e. the timing correctness is guaranteed), given that the hinted duration is correct. If the duration information does not hold, the operating system will stop the execution of the task and remove it from the scheduling pools.
The Memory Manager takes care of the memory architecture of the underlying hardware. The XOberon operating system will manage the 32-bit virtual address space in Stack, Heap, Module, DMA, and I/O spaces. This allows, for example, to check for NIL-references without compiler intervention, to precisely discover stack overflows, to allow dynamic stack growth, and to quick remedy to dangling pointers to unloaded modules.
The Linker features dynamic linking and loading and resides on the target. This allows better memory use and very short edit-compiler-run cycles, since an application module can be quickly unloaded, modified and reloaded onto the target.
The Communication Package takes care of managing the host-to-target link. It bases on the TCP/IP protocol over an ethernet medium. Some private protocols are implemented for the cross-development, but standard protocols are widely deployed on the target for standalone applications. As an example, telnet, tftp, and ftp servers can be installed as NRT processes on the target, along with an http server, publishing web-pages, which could be used for target-controlling through a refined, Oberon savvy, CGI architecture.
The Drivers Interface allows the on-the-fly configuration of peripheral components, like serial links, digital input and outputs, analog outputs, counters and so on. The user application will only need to reference driver objects by name, this permitting the application to be fully decoupled from the used drivers. Therefore a change in the hardware will only need a reconfiguration of the drivers? object-oriented database, without needing the application to be neither modified nor recompiled.
The whole idea of XOberon is about providing a reliable, real-time capable run-time environment, with safety aspects guaranteed by the operating system. The main goal is providing non-computer-scientists a valuable RAD tool for implementing embedded applications. Nonetheless the kernel schedules tasks with 10KHz rate, with an overhead of less than 1 percent on a PowerPC 604 hardware. This allows response times which are a factor 4 faster than any other industry operating system running on the same hardware. Moreover, the size of the complete XOberon operating system (core and network servers and clients), is less than 512 KB ROM and needs 1.5 MB RAM on the target.
Further development will guarantee best-of-breed real-time capabilities, like a real-time compatible incremental garbage collector, off-line execution time profiling, Java support, ActiveX visualization tools, etc.
A lot of aplications are driven by XOberon, in either the older (MC680x0 based) or newer (PowerPC) implementation.
The Hexaglide is a a 6 DOF parallel mechanism similar to the Stewart Platform or Hexapod.
The Robojet (Meyco) is a hydraulically actuated manipulator used in the tunneling construction work. Its task consists of spraying liquid concrete on the walls of new tunnels using a jet as its tool.
The Mobile Post System (MOPS) is mobile robot suited for autonomous mail distribution.
The "Biegemaschine" is a modular, sensor-controlled Sheet-bending robot.
Other examples include a balancing pendulum robot, a ping-pong playing robot and many others.
Panzieri, Davoli, "Real Time Systems: A Tutorial", Lab. for Computer Science, University of Bologna, October 1993.
Reiser M., "The Oberon System", Addison Wesley, 1991.
Mössenböck H., "Object-Oriented Programming in Oberon-2", Springer Verlag, 1993.
Hennessy J., Patterson D., "Computer Architecture: a Quantitative Approach", Morgan Kaufmann Publishers, 1996.
Honegger M., Schweitzer G., "Vision Supported Operation of a Concrete Spraying Robot for Tunneling Work", M2VIP'97, Toowoomba, Australia, September 1997.
Honegger M., Codourey A., E. Burdet, "Adaptive Control of the Hexaglide, a 6 dof Parallel Manipulator", ICRA'97, Albuquerque NM, USA, April 1997.
Vestli S. J., Tschichold-Gürman N., "MOPS, a system for mail distribution in office type buildings", Service Robots Journal, 1996.
Contact: Roberto Brega, Sjur VestliInstitute of Robotics Homepage
Jun 1998, R. Brega & M. Honegger