RTOS-UH
Real-Time Operating System for Process Automation

Introduction

In many control applications the synthesis of the hardware and software concept is of substantial importance to ensure performance and reliability. Required software properties are the priority oriented allocation of the processor capacity to the various tasks, real-time capability, proper interrupt handling and comfortable programming. Required hardware features are fast and manageable interfaces between the sensors and actuators on the one hand and the micro controller or process computer on the other. From that reason a demand on a system and programming environment arise which supports multi-tasking and which possesses real-time capability.

Some approaches try to emulate the necessary system functions within the user programs using polling loops or round robin mechanisms. With these solutions performance losses are to be expected. Often a synchronous system concept is proposed. But then a considerable amount of the processor capacity is lost in support of the system functions.

Particularly for the requirements of process automation and automatic control the real-time multi-tasking operating system RTOS-UH (Real-Time Operating System - Universität Hannover) was developed (initial version 1980 and since then continuously improved) by the Institute of Automatic Control. Almost all processors of the 68k- and PowerPC-family are supported.

Mutlitasking

RTOS-UH is completely interrupt triggered and free of polling loops. Since one of the main goals is to achieve a good real-time response, all I/O operations with slow devices, like for instance harddisks, networks, serial and parallel interfaces are controlled by so called I/O-daemons. Daemons themselves are tasks which belong to one device and accomplish the I/O for that device. Thus, the complete I/O can be handled at the user level, and I/O operations initiated by low priority tasks barely affect the real-time performance. The variable priority of the I/O daemons prevents the problem of priority inversion.

Within RTOS-UH two kinds of processes are distinguished. Processes of the first kind are traps, interrupt service routines (IRSR), the dispatcher and the scheduler. They run in supervisor mode.

Processes of the second kind are user processes and I/O-daemons. They run in user mode. In Fig. 1 and Fig. 2 the possible states for the two types of processes are illustrated. In addition, possible events causing a transition from one state to another are given. As can be seen, supervisor processes do not permit a state executable in order to guarantee a high real-time performance.

In fact, RTOS-UH offers a real preemption by priority oriented truncation, also within system functions (traps). The main task of the supervisor processes is the control of processes of the second kind and the change of their state. If necessary, a dispatcher run is initiated. The dispatcher is invoked asynchronously whenever the state of a task is changed.

This process is responsible for the priority oriented allocation of the CPU. Furthermore, the dispatcher takes care for the correct context switching (CSW). That means, the current state of the suspended task is saved, and, if required, the state of the next running task is restored.

The real-time high-level language PEARL 90 (PEARL90 standard, DIN 66253-2), which is used for programming under RTOS-UH, considers the scheduling of tasks, such as event activations, cyclical, relative and absolute time scheduling. To match these features the system has two schedulers. The clock for time scheduling of tasks can be adjusted to a resolution of 50 µs and multiples. Changing a task state by the schedulers causes a dispatcher run.

Processes of the second kind are tasks. Three relationships between processes of the second kind are distinguished.

• coexistence: The tasks exist uncoupled side by side and compete for the processor. The dispatcher takes care for the priority oriented allocation of the CPU.
• competition: A critical path does not permit access from several tasks at the same time. To solve the problem binary semaphores and bolt variables are made available. Bolt variables are an extension of semaphores for the multi reading problem.
• cooperation: Counting semaphores can be used to realize producer/consumer schemes.

Furthermore, the system supports named pipes and inter task communication.

Dispatcher

The dispatcher itself is a process of the first kind and runs in supervisor mode. This process is always called whenever the state of a task is changed. It is responsible for the priority oriented allocation of the CPU for the various tasks of the system. For that reason first of all the dispatcher investigate if a run of one of the two schedulers is required (see the section about the scheduler). Then the dispatcher ring is examined in which all tasks which not prossess the state dormant are queued priority oriented. The dispatcher in its run allocate the processor to the executable task with the highest priority. In worst case within the system there exists an idle task (lowest priority) which always possess the state executable. This task consists merely of an endless loop. In regular cases one of the following actions take place:

• A dormant task becomes executable (and possess the highest priority): The dispatcher reserves a task work space for the task variables and additional memory space for the context. Afterwards the task receives the CPU.
• The actually running task is no longer executable or a task with higher priority changed its state to executable: The context of the the actually running task is saved.
• The executable task (with the highest priority) has run already earlier: The old context of this task is restored.

Scheduler

The real-time high-level language PEARL 90 (PEARL90 standard, DIN 66253-2) which is used for programming under RTOS-UH considers the comfortable cyclical, relative and absolute time scheduling of tasks. To match these features the system dispose of two schedulers. They are able of changing the task state from suspended to executable and from scheduled to executable. When a task is activated while it is already running, RTOS-UH buffers the activation. This fault tolerant behavior guarantees even in case of a high system load a correct even though delayed handling. Furthermore, the schedulers calculate the time for cyclic activations and continuations of suspended tasks. The internal clock for time scheduling of tasks has a resolution of 50 µs. For slower processors which would be overburdened with 50 µs timer interrupts, a resolution is possible in multiples of 50 µs.