Real-time Operating Systems VO Embedded Systems Engineering Armin - PowerPoint PPT Presentation

Real-time Operating Systems VO Embedded Systems Engineering Armin Wasicek 11.12.2012

Overview  Introduction • OS and RTOS • RTOS taxonomy and architecture  Application areas • Mixed-criticality systems • Examples: UAV, Synthetic vision  The RTOS Market  Implementation • Linux as RTOS  Conclusion 11.12.2012 Real-time Operating Systems 2

Computer system classification Transformational systems compute output values from input values, then stop. • numerical computations, compiler Interactive systems constantly interact with their environment. The system delivers a service to the user. • operating systems, databases Reactive systems continuously react to stimuli from the environment. Reaction time is dictated by the environment. • signal processors, process controllers

Real-Time Systems In a real-time computer system the correctness of the system behavior In a real-time computer system the correctness of the system behavior depends not only on the logical results of the computations, but also on depends not only on the logical results of the computations, but also on the physical instant at which these results are produced. the physical instant at which these results are produced. Utility  Hard Real-Time deadline miss can have catastrophic results reaction time deadline Utility  Soft Real-Time result has utility after the deadline reaction time

Determinism A system behaves deterministically if – given a set of initial conditions at time t 0 – a sequence of inputs always produces the same sequence of outputs at any future instant t .  Key difference between reactive and interactive systems  Compare e.g. a process controller and a compiler Excurs: Predictability  „A deterministic system is not necessarily predictable “  Is our (timing) model a precise characterisation of the system?  Can we predict e.g. context switch delay, execution times?  Temporal behavior of many non-RT systems in unpredictable

OS and RTOS 11.12.2012 Real-time Operating Systems 6

Operating Systems User Input Output devices devices Operating System (OS): Application • abstracts from hardware • provides access to I/O, System Signals calls • memory management, • sharing of the resources Operating system of the computer Registers Interrupts • provides system calls to access low level functions Hardware Embedded system is a hardware/software artifact.

Common OS Services  Task management  Scheduling and Timers  Memory Management  Memory Protection and Error Handling  Hardware Abstraction and I/O interface  Inter Process Communication  Synchronization (mutual exclusion)  Message passing  Shared Memory

Real-Time Operating Systems (RTOS)  Real-Time (RT) requirements for OS + features for timing constraints • guaranteed max. execution time of system calls • guaranteed OS response time to external events • guaranteed max. execution time of OS functions (ISRs, drivers, context switches, ...) • Determinism and Predictability  Efficiency • Fast context switch • Minimize intervals during which the interrupts are disabled

Scheduling created dead ready running blocked  Scheduling Decision: Which task in ready state can execute?  Scheduler uses a scheduling strategy • e.g., fixed priorities, dynamic priorities, round-robin (time-slicing), rate monotonic, cooperative  How does scheduler get CPU? • called by application • system timer interrupt 11.12.2012 Real-time Operating Systems 10

Schedulability Analysis In a hard real-time system, we need to a high confidence that no deadline will be missed during operation.  Offline Scheduling  Timing analysis is much easier without preemption  Online Scheduling  Static Priority Scheduling (e.g., RMS)  Dynamic Priority Scheduling (e.g., EDF) Need to know timing characteristics of runtime system (e.g., OS , uC ) and of all tasks ( WCET ) for real-time scheduling 11.12.2012 Real-time Operating Systems 11

Mutual Exclusion – Priority Inversion  Realized using e.g. semaphores • Increases response times  Priority inversion due to locking must be avoided in real-time systems! 4. T 2 runs before T 3 1. T 3 starts with resource R priority 6. T 1 preempts T 3 2. T 1 attempts to lock R T 1 T 2 T 3 3. T 3 preempted by T 2 5. T 3 unlocks R 11.12.2012 Real-time Operating Systems 12

Is a scheduler absolutely necessary? No, you can meet deadlines without any RTOS (generate offline schedule, implement it): • inefficient (regularly poll infrequent events, reserve max. time for interrupts) • long schedule cycle time (least common multiple of all task periods) or unnecessary overhead (shorten task periods) • hard to change and maintain (use tools!) 11.12.2012 Real-time Operating Systems 13

RTOS Taxonomy and Architecture 11.12.2012 Real-time Operating Systems 14

RTOS taxonomy (1) Small, fast, proprietary kernels ( μ C-OS II, QNX, WinCE) • Highly specialized to specific applications Real-Time extensions (RT-Linux, Xenomai, RT-Posix, RT-MACH, RT-WinNT) • Compliant kernels Existing OS is modified such that non-rtos binaries run without modification • Dual kernels Thin RT-kernel stay below the native OS • Core kernel modification Changes are made in the core of OS • The resource kernel approach Kernel is extended to provide support for resource reservation 11.12.2012 Real-time Operating Systems 15

RTOS taxonomy (2) Component based kernels • OS components can be selectively included to compose an RTOS • Selection depends on the target and application • Construction of OS through composition  eCos  PURE - embedded applications  MMLite - dynamic reconfiguration of components 11.12.2012 Real-time Operating Systems 16

RTOS taxonomy (3) Quality-of-Service (QoS) based kernels • Used for soft real-time systems Research kernels • Developed at university research projects to study research aspects of RTOS • MARS time-triggered, distributed SPRING admission control, reservation HARTOS distributed communication 11.12.2012 Real-time Operating Systems 17

Monolithic Kernels User space Applications  All basic system services run in Libraries kernel space Kernel space  Provide rich and powerful File systems abstractions of the hardware IO/Device management  Amount of context switches and Process management Interprocess comm. messaging involved are low Memory management  Runs faster than microkernel Hardware  Examples: Linux, Windows 11.12.2012 Real-time Operating Systems 18

User space Microkernels Software Server Applications File systems Libraries Process server  Kernel restricted to Drivers IPC a minimum Kernel space  IPC, Resource Allocation (not scheduling), I/O …  Microkernel Improves maintainability, predictability, security Hardware  Hypervisor vs. Microkernel  Isolates hard real-time tasks  Virtual Environment for other paravirtualized RTOSs  Example: OKL4  Used in e.g. Mobile Phones for the Android Platform 11.12.2012 Real-time Operating Systems 19

Exokernels User space Applications Libraries Two basic principles: libOSes  Exokernel safely exports resources Kernel space  Anyone can manage resources Exokernel Hardware Low-level interface to hardware provided by libOSes • (e.g., for networking, disk access, memory management) http://pdos.csail.mit.edu/exo/ 11.12.2012 Real-time Operating Systems 20

Partioning RTOS RTOS can partition resources in time and space  Spatial Partitioning:  Memory protection : one partition cannot corrupt the memory of the software in another partition  Temporal Partitioning:  Shared resources : each partition enjoys a certain amount of time on the resource, regardless of what other software is doing. → Enables the ability to run mixed-criticality applications

Mixed Criticality Systems

Definition: Mixed criticality A mixed-critical system is an integrated suite of hardware, operating system and middleware services and application software that supports the execution of safety-critical, mission-critical, and non- critical software within a single, secure compute platform. Applications at different levels of criticality can interact and co-  exist on the same computational platform .  Mixed criticality systems realize the principle of non-interference 11.12.2012 Real-time Operating Systems 23

Safety Integrity Levels (SIL)  SIL provide rigorous requirements concerning  Design, Verfication, Certification, Dependability, Security  SIL are a qualitative measure of the required protection against software or system failure  SILs provide guidance in selecting appropriate techniques and measures for safety related software development.  Standards: e.g., IEC 61508 Safety Integrity Levels (SIL) SIL Failures per hour MTTF (years) Verification Technique SIL1 SIL2 SIL3 SIL4 10 -5 to 10 -4 10 5 to 10 4 4 Formal Proof R R HR 3 10 -4 to 10 -3 10 4 to 10 3 Probabilistic testing R R HR 10 -3 to 10 -2 10 3 to 10 2 2 Static analysis R HR HR HR 1 10 -2 to 10 -1 10 2 to 10 Dynamic analysis and testing R HR HR HR Software complexity metrics R R R R 11.12.2012 Armin Wasicek 24