Lecture 19, part 1: Embedded & Real-time Operating Systems
NOTE: Not relevant for the exam.
Embedded operating systems - Characteristics: Configurability -
Configurability No overhead for unused functions tolerated, no single OS fits all needs, -> configurability needed.
- Object-orientation could lead to a of derivation subclasses.
- Aspect-oriented programming
- Conditional compilation (using # if and # ifdef commands).
- Advanced compile-time evaluation useful.
- Linker-time optimization (removal of unused functions)
Dynamic data might be replaced by static data.
Verification of derived OS?
Verification a potential problem of systems with a large number of derived OSs:
- Each derived OS must be tested thoroughly;
- Potential problem for eCos (open source RTOS from Red Hat), including 100 to 200 configuration points [Takada, 2001].
Embedded operating systems - Characteristics: Disk and network handled by tasks -
- Effectively no device needs to be supported by all
variants of the OS, except maybe the system timer.
- Many ES without disk, a keyboard, a screen or a mouse.
- Disk & network handled by tasks instead of integrated
drivers.
Embedded operating systems - Characteristics: Protection is optional
Protection mechanisms not always necessary: ES typically designed for a single purpose, untested programs rarely loaded, SW considered reliable. Privileged I/O instructions not necessary and tasks can do their own I/O. Example: Let switch be the address of some switch Simply use
load register,switch
instead of OS call. However, protection mechanisms may be needed for safety and security reasons.
Embedded operating systems - Characteristics: 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 always necessary and
- since efficient control over a variety of devices is required,
- it is possible to let interrupts directly start or stop SW (by storing the start address in the interrupt table).
- More efficient than going through OS services.
- Reduced composability: if SW is connected to an interrupt, it may be difficult to add more SW which also needs to be started by an event.
Embedded operating systems - Characteristics: Real-time capability
Many embedded systems are real-time (RT) systems and, hence, the OSs used in these systems must be real-time operating systems (RTOSs).
RT 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
- 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]
- OS should manage the timing and scheduling
- OS possibly has to be aware of task deadlines; (unless scheduling is done off-line).
- Frequently, the OS should provide precise time services with high resolution.
- The OS must be fast
- Practically important.
Time
Time plays a central role in βreal-timeβ systems Physical time: real numbers Computers: mostly discrete time
- Relative time: clock ticks in some resolution
- Absolute time: wall clock time
β’ International atomic time TAI (french: temps atomic internationale) Free of any artifacts. β’ Universal Time Coordinated (UTC) UTC is defined by astronomical standards TAI and UTC identical on Jan. 1st, 1958. 30 seconds had to be added since then. Not without problems: New Year may start twice per night.
Internal synchronization
- Synchronization with one master clock
β’ Typically used in startup-phases
- Distributed synchronization:
- Collect information from neighbors
- Compute correction value
- Set correction value.
Precision of step 1 depends on how information is collected: β’ Application level: ~500 Β΅s to 5 ms β’ Operation system kernel: 10 Β΅s to 100 Β΅s β’ Communication hardware: < 10 Β΅s
External synchronization
External synchronization guarantees consistency with actual physical time. Trend is to use GPS for ext. synchronization GPS offers TAI and UTC time information. Resolution is about 100 ns.
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 see Kopetz, 1997.
RTOS-Kernels
Distinction between
- real-time kernels and modified kernels of standard OSes.
Distinction between
- general RTOSs and RTOSs for specific domains,
- standard APIs (e.g. POSIX RT-Extension of Unix,
ITRON, OSEK) or proprietary APIs.
Functionality of RTOS-Kernels
Includes
- processor management,
- memory management,
- and timer management;
- task management (resume, wait etc),
- inter-task communication and synchronization.
Classes of RTOSes: 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.
Classes of RTOSs: 2. RT extensions to standard OSs
Attempt to exploit comfortable main stream OS. RT-kernel running all RT-tasks. Standard-OS executed as one task.
-
Crash of standard-OS does not affect RT-tasks;
-
RT-tasks cannot use Standard-OS services;
less comfortable than expected
Example: RT-Linux
Example (2):
RTAI β Real Time Application Interface https://www.rtai.org/ Fixes to many of the sources for unpredictability in Linux Hardware abstraction layer in between hardware and Linux
Evaluation
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.
Classes of RTOSs: 3. Research trying to avoid limitations
Research systems trying to avoid limitations. Include MARS, Spring, MARUTI, Arts, Hartos, DARK, and Melody Research issues [Takada, 2001]:
- low overhead memory protection,
- temporal protection of computing resources
- RTOSes for on-chip multiprocessors
- support for continuous media
- quality of service (QoS) control.
Lecture 19, part 2: Resource Access Protocols
Resource access protocols
Critical sections: sections of code at which exclusive access to some resource must be guaranteed. Can be guaranteed with semaphores S or βmutexesβ*.
Blocking due to mutual exclusion
Blocking with >2 tasks can exceed the length of any critical section
The MARS Pathfinder problem
Solutions
Disallow preemption during the execution of all critical sections. Simple, but creates unnecessary blocking as unrelated tasks may be blocked.
Remarks on priority inheritance protocol
Possibly large number of tasks with high priority. Possible deadlocks. Ongoing debate about problems with the protocol: Victor Yodaiken: Against Priority Inheritance, Sept. 2004, http://www.fsmlabs.com/resources/white_papers/priority-inheritance/ Finds application in ADA: During rendez-vous, task priority is set to the maximum. Protocol for fixed set of tasks: priority ceiling protocol.
Summary
- General requirements for embedded
operating systems β’ Configurability β’ I/O β’ Interrupts
- General properties of real-time operating systems β’ Predictability β’ Time services β’ Synchronization β’ Classes of RTOSs, β’ Device driver embedding
- Priority inversion β’ The problem β’ Priority inheritance