Time Driven Operating Systems ? A Case Study on the MARS Kernel

(Position Paper)

Johannes Reisinger

Institut f?r Technische Informatik, Technische Universit?t Wien

Treitlstra?e 3/182/1, A?1040 Wien, Austria/Europe

Tel.: +43/222/58801?8173, Fax: +43/222/569149, E?mail: [email protected]

Date: 06/23/1992

1 Introduction

Time driven real?time systems are of increasing importance in the field of critical computer control applications [Sta90]. Because of their predictable behavior they are well suited for systems whose correct operation in the time domain must be guaranteed already in the design phase of an application. Time driven systems allow the proof of the correct timing behavior of an application by construction of a feasible schedule.

In the MARS system [Kop89] the time driven approach is realized. The structure of the MARS operating system kernel differs significantly from that of others because of the specific demands which a distributed time driven system imposes on its underlying operating system. Based on the experiences with the first prototype of the MARS operating system [Dam89] (MARS?1), a new operating system kernel, MARS?2, has been developed from scratch. There have been some motivations for the development of MARS?2:

w New processor boards (`MARS components') have been developed to fully support the MARS concepts [Ste91]. These boards provide mechanisms to achieve a high self?checking coverage and a highly predictable timing behavior.

w The introduction of new concepts and mechanisms into the MARS system (e.g. membership protocol, time redundant process execution, shadow component [Kop90], [Kop91]) requires support by the run? time system.

w A predictable timing behavior should be achieved by the new kernel. Although the system overhead caused by the old implementation was boundable in principle, the calculated bounds were too high to guarantee the correct timing behavior of an application already at design time [Vrc91].

w The self?checking coverage of the MARS components has to be high because the fault tolerance mechanisms of MARS are based on it. Whereas the old kernel was not specifically designed in order to meet this requirement, MARS?2 uses both hardware and software mechanisms to increase the self? checking coverage to a sufficiently high degree.

MARS?2 is based on a microkernel operating system architecture in contrast to the monolithic kernel of MARS?1.

2 Key Design Issues

The most distinguishing feature of a time driven operating system is the way how activities within the system are synchronized. There is no explicit synchronization among processes. Instead, synchronization is done implicitly by the passage of time. A basic requirement for using this type of synchronization in a distributed system is the availability of a globally synchronized time base which is used to trigger each activity within the system.

The scheduling of a time driven system is done before run?time of an application. This static, pre?run?time schedule determines the invocation times of all processes at all components of the distributed system and the exact points in time when communication is done. To guarantee that scheduling can be done as desired, upper bounds for communication and process execution times are calculated and constitute part of the input data to the pre?run? time scheduler. Moreover, it is not sufficient to calculate any upper bounds for the process execution and communication times: the calculated times should be as tight as possible to the actually needed execution times.

Communication times can be bounded by using a communication protocol whose execution time may be bounded even in the presence of faults which are covered by the appropriate fault hypothesis. A protocol which not only bounds communication times but moreover has a