10
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Embedded operating systems - Interrupts not restricted to OS - Interrupts can be employed by any process For standard OS: serious source of unreliability. Since embedded programs can be considered to be tested, since protection is not necessary and since efficient control over a variety of devices is required, it is possible to let interrupts directly start or stop tasks (by storing the tasks start address in the interrupt table). More efficient than going through OS services. Reduced composability: if a task is connected to an interrupt, it may be difficult to add another task which also needs to be started by an event.

12
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Real-time operating systems - Definition and requirement 1: predictability - Def.: (A) real-time operating system is an operating system that supports the construction of real-time systems. The following are the three key requirements 1.The timing behavior of the OS must be predictable. services of the OS: Upper bound on the execution time! RTOSs must be timing-predictable: short times during which interrupts are disabled, (for hard disks:) contiguous files to avoid unpredictable head movements. [Takada, 2001]

14
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Time services Time plays a central role in real-time systems. Actual time is described by real numbers. Two discrete standards are used in real-time equipment: International atomic time TAI (french: temps atomic internationale) Free of any artificial artifacts. Universal Time Coordinated (UTC) UTC is defined by astronomical standards UTC and TAI identical on Jan. 1st, seconds had to be added since then. Not without problems: New Year may start twice per night.

18
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Problems with external synchronization Problematic from the perspective of fault tolerance: Erroneous values are copied to all stations. Consequence: Accepting only small changes to local time. Many time formats too restricted; e.g.: NTP protocol includes only years up to 2036 For time services and global synchronization of clocks synchronization see Kopetz, 1997.

22
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Classes of RTOSes according to R. Gupta: 1. Fast proprietary kernels For complex systems, these kernels are inadequate, because they are designed to be fast, rather than to be predictable in every respect [R. Gupta, UCI/UCSD] Examples include QNX, PDOS, VCOS, VTRX32, VxWORKS.

26
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Evaluation (Gupta) According to Gupta, trying to use a version of a standard OS: not the correct approach because too many basic and inappropriate underlying assumptions still exist such as optimizing for the average case (rather than the worst case),... ignoring most if not all semantic information, and independent CPU scheduling and resource allocation. Dependences between tasks not frequent for most applications of std. OSs & therefore frequently ignored. Situation different for ES since dependences between tasks are quite common.

34
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund The MARS Pathfinder problem (1) But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data. The press reported these failures in terms such as "software glitches" and "the computer was trying to do too many things at once". …

35
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund The MARS Pathfinder problem (2) VxWorks provides preemptive priority scheduling of threads. Tasks on the Pathfinder spacecraft were executed as threads with priorities that were assigned in the usual manner reflecting the relative urgency of these tasks. Pathfinder contained an "information bus", which you can think of as a shared memory area used for passing information between different components of the spacecraft. A bus management task ran frequently with high priority to move certain kinds of data in and out of the information bus. Access to the bus was synchronized with mutual exclusion locks (mutexes).

37
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund The MARS Pathfinder problem (4) Most of the time this combination worked fine. However, very infrequently it was possible for an interrupt to occur that caused the (medium priority) communications task to be scheduled during the short interval while the (high priority) information bus thread was blocked waiting for the (low priority) meteorological data thread. In this case, the long-running communications task, having higher priority than the meteorological task, would prevent it from running, consequently preventing the blocked information bus task from running. After some time had passed, a watchdog timer would go off, notice that the data bus task had not been executed for some time, conclude that something had gone drastically wrong, and initiate a total system reset. This scenario is a classic case of priority inversion.

43
technische universität dortmund fakultät für informatik p. marwedel, informatik 12, 2010 TU Dortmund Priority inversion on Mars Priority inheritance also solved the Mars Pathfinder problem: the VxWorks operating system used in the pathfinder implements a flag for the calls to mutex primitives. This flag allows priority inheritance to be set to on. When the software was shipped, it was set to off. The problem on Mars was corrected by using the debugging facilities of VxWorks to change the flag to on, while the Pathfinder was already on the Mars [Jones, 1997].