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

▶
real time operating systems
SMART_READER_LITE
LIVE PREVIEW

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

Nov 08, 2023 478 likes •1.02k views

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

slide-1
SLIDE 1

Real-time Operating Systems

VO Embedded Systems Engineering Armin Wasicek 11.12.2012

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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
slide-4
SLIDE 4

Real-Time Systems

  • Hard Real-Time

deadline miss can have catastrophic results

  • Soft Real-Time

result has utility after the deadline

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 the physical instant at which these results are produced. 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 the physical instant at which these results are produced.

Utility reaction time reaction time

deadline

Utility

slide-5
SLIDE 5

Determinism

  • 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

A system behaves deterministically if – given a set of initial conditions at time t0 – a sequence of inputs always produces the same sequence of outputs at any future instant t.

slide-6
SLIDE 6

OS and RTOS

11.12.2012 Real-time Operating Systems 6

slide-7
SLIDE 7

Operating Systems

Operating System (OS):

  • abstracts from hardware
  • provides access to I/O,
  • memory management,
  • sharing of the resources
  • f the computer
  • provides system calls to

access low level functions

User Hardware

Input devices

Application

Output devices System calls Signals Registers Interrupts

Operating system

Embedded system is a hardware/software artifact.

slide-8
SLIDE 8

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
slide-9
SLIDE 9

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
slide-10
SLIDE 10

Scheduling

  • 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

created dead ready running blocked

11.12.2012 Real-time Operating Systems 10

slide-11
SLIDE 11

Schedulability Analysis

  • 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 In a hard real-time system, we need to a high confidence that no deadline will be missed during operation.

11.12.2012 Real-time Operating Systems 11

slide-12
SLIDE 12

Mutual Exclusion – Priority Inversion

  • Realized using e.g. semaphores
  • Increases response times
  • Priority inversion due to locking must be avoided in real-time

systems!

  • 2. T1 attempts to lock R
  • 3. T3 preempted by T2
  • 6. T1 preempts T3

T1 T2 T3

  • 4. T2 runs before T3

11.12.2012 Real-time Operating Systems 12

priority

  • 1. T3 starts with resource R
  • 5. T3 unlocks R
slide-13
SLIDE 13

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

slide-14
SLIDE 14

RTOS Taxonomy and Architecture

11.12.2012 Real-time Operating Systems 14

slide-15
SLIDE 15

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

slide-16
SLIDE 16

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

slide-17
SLIDE 17

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

slide-18
SLIDE 18

Monolithic Kernels

  • All basic system services run in

kernel space

  • Provide rich and powerful

abstractions of the hardware

  • Amount of context switches and

messaging involved are low

  • Runs faster than microkernel
  • Examples: Linux, Windows

Hardware Kernel space User space

Applications Libraries File systems IO/Device management Process management Interprocess comm. Memory management

11.12.2012 Real-time Operating Systems 18

slide-19
SLIDE 19

Microkernels

  • Kernel restricted to

a minimum

IPC, Resource Allocation (not scheduling), I/O …

Improves maintainability, predictability, security

  • 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

User space

Server Software

Hardware Kernel space

Process server Drivers Microkernel Applications Libraries File systems

IPC

11.12.2012 Real-time Operating Systems 19

slide-20
SLIDE 20

Exokernels

Two basic principles:

  • Exokernel safely exports resources
  • Anyone can manage resources

Low-level interface to hardware provided by libOSes

  • (e.g., for networking, disk access,

memory management)

Hardware Kernel space User space

Applications Libraries Exokernel libOSes

http://pdos.csail.mit.edu/exo/

11.12.2012 Real-time Operating Systems 20

slide-21
SLIDE 21

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

slide-22
SLIDE 22

Mixed Criticality Systems

slide-23
SLIDE 23

Definition: Mixed criticality

  • 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

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.

11.12.2012 Real-time Operating Systems 23

slide-24
SLIDE 24

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) 4 10-5 to 10-4 105 to 104 3 10-4 to 10-3 104 to 103 2 10-3 to 10-2 103 to 102 1 10-2 to 10-1 102 to 10 Verification Technique SIL1 SIL2 SIL3 SIL4 Formal Proof R R HR Probabilistic testing R R HR Static analysis R HR HR HR Dynamic analysis and testing R HR HR HR Software complexity metrics R R R R 24 11.12.2012 Armin Wasicek

slide-25
SLIDE 25

Benefits of Mixed-criticality systems

  • Integrated platforms use

less physical components

  • Reduction in
  • Cost
  • Weight
  • Power
  • Wiring
  • Common interface for

multiple software providers "For size, weight, and power (SWaP) reasons, avionics manufacturers were including more and increasingly complex functions; instead of having a new box on the aircraft every time they added something like that, they wanted to integrate different types of applications

  • nto

the same central processing unit (CPU).

11.12.2012 Real-time Operating Systems 25

slide-26
SLIDE 26

Possible system architecture

  • Mix applications with different

levels of criticality on the same computing platform

  • Segregate subsystems in

execution compartments

  • Use e.g. a partitioned OS to

shield compartments in time and space 11.12.2012

Real-time Operating Systems 26

COMPUTING PLATFORM (PARTITIONED) RTOS

APPLICATION B APPLICATION A APPLICATION B APPLICATION B APPLICATION C

slide-27
SLIDE 27

Mixed Criticality Challenges

  • Certification of reusable components:
  • Construct a system from components with known levels of certifiability.
  • Develop a certification process and composition framework
  • Certification by Design:
  • Identify and assess the “certifiability” of a component, even before it is

implemented,

  • Formal and analytical methods to define a design process for certifiability
  • Reconfigurable Systems:
  • It is inherently difficult to bind the decision space of a reconfigurable

system under a certain fault model

  • Fault Tolerant Systems:
  • Generic approaches to implement fault tolerance are extremely hard
  • It is even harder to define an approach to certify such systems.
slide-28
SLIDE 28

Example 1: UAV

  • UAVs are software-centric:
  • Flight control system
  • Ground control system
  • Multiple Criticality levels in flight

software:

  • Common CPU(s) due to size, weight, and

power (SWAP) constraints

  • Increasing certification requirements

would drive separating criticalities

  • Demand for demonstration of higher

assurance for more critical functions

11.12.2012 Real-time Operating Systems 28

slide-29
SLIDE 29

UAV criticality levels (examples)

Level Required to prevent Flight Critical

  • Unintended loss of life.
  • Unintended reduction of public safety.
  • Substantial damage to the vehicle or its support structure.
  • Loss of vehicle
  • Unintended event (e.g., crash) into politically sensitive area

Mission Critical

  • Unintended loss of the vehicle’s function (mission sensors or
  • ther effectors).
  • Unintended loss of support structure function (e.g., ability of
  • perator to use on-board UAV sensors).

Maintenance Critical • Inefficient use of the vehicle’s resources.

  • Inefficient use of ground support structure.

11.12.2012 Real-time Operating Systems 29

slide-30
SLIDE 30

Example 2 ARINC 653

An Avionics Standard for Safe, Partitioned Systems

  • ARINC 653 defines a standardized Real-Time Operating

System (RTOS) interface for avionics equipment

  • Called: APplication EXecutive (APEX) for space and time

partitioning ARINC 653 approach allocates a predefined faction of CPU time and memory of the whole system to each partition

  • Key enabler in the development of Integrated Modular

Avionics (IMA).

  • It recognizes the RTOS as key component of an IMA system.
  • Products: PikeOS, INTEGRITY, VxWorks, LynxOS, etc-
slide-31
SLIDE 31

http://www.computersociety.it/wp- content/uploads/2008/08/ieee-cc- arinc653_final.pdf

11.12.2012 Real-time Operating Systems 31

slide-32
SLIDE 32

http://www.computersociety.it/wp- content/uploads/2008/08/ieee-cc- arinc653_final.pdf

11.12.2012 Real-time Operating Systems 32

slide-33
SLIDE 33

http://www.computersociety.it/wp- content/uploads/2008/08/ieee-cc- arinc653_final.pdf

11.12.2012 Real-time Operating Systems 33

slide-34
SLIDE 34

Example 3: Synthetic Vision

11.12.2012 Real-time Operating Systems 34

slide-35
SLIDE 35

The RTOS Market

slide-36
SLIDE 36

Cost-Benefit ratio of an RTOS

  • Average number of software developers per project is 25.7
  • Average cost per engineer is about $150,000 per year
  • Average cost for each month of delay is $321,250
  • In average 42% of embedded designs are behind schedule

by an average of 4.1 months

  • Average expected loss due to design delays per project:

($321,250) * 0.42 * 4.1 = $553,200

  • Cost of a commercial RTOS ~$1k-20k
slide-37
SLIDE 37

Comparison RTOS – No OS

http://www.rtos.com/PDFs/EMFWhitePaper-RTOSSelection.pdf

slide-38
SLIDE 38

RTOS market shares

  • Trend towards commercial RTOS
  • “Roll their own" has steadily declined
  • In-house OS projects decline
  • Increase of commercial RTOS is

fueled by the rise of 32-bit microprocessors

  • Ratio drops from 55% for 32-bit

users to 19% for 8-bit controllers

http://www.eetimes.com/discussion/other/4025539/Embedded-systems-survey-Operating-systems-up-for-grabs 11.12.2012 Real-time Operating Systems 38

slide-39
SLIDE 39

Market data for 2004 on tools and services

Characteristics Market (2004) Market volume in million € Market growth Largest consuming region and its share Largest consuming sector and its share Embedded OSs, bundled tools, related services 712.6 20.9% Americas 52.7% Consumer Electronics 41.7% SW development tools, related services 195.1 1.8% Americas 48.2% n.a. Design automation tools, related services 275.6 n.a. Americas n.a. Military / Aerospace, n.a. Test automation tools, related services 65.7 19.8% Americas 50.8% Military / Aerospace, 27.6% 1,249.0 17.0% (weighted average)

slide-40
SLIDE 40

Linux as RTOS

11.12.2012 Real-time Operating Systems 40

slide-41
SLIDE 41

Linux as real-time operating system (1)

  • Predictability of real-time task execution
  • Pre-2.6 scheduling algorithm was O(n), so it could

delay a even a high priority task‘s start time.

(Since 2.6 O(1) scheduler introduced: time to schedule is both fixed and deterministic regardless of the number of active tasks)

  • Kernel cannot always be preempted. Sometimes it

requires exclusive access to resources and internal data structures in order to maintain their consistency

  • Interrupts from hardware may delay a task
slide-42
SLIDE 42

Linux as real-time operating system (2)

  • Virtual memory management introduces

indeterministic delays (jitter). Real-Time applications may not use the virtual memory

  • Clock granularity of 1ms insufficient for most

real-time apps (e.g., a typical control loop task executes with 100 Hz = every 10ms)

slide-43
SLIDE 43

The Real-Time Preemption Patch

  • Makes Linux better suited to real-time systems
  • Real-Time Scheduling In the RTPreempt, RT-Posix fixed

priority scheduling. There is also an EDF patch for Linux.

  • Critical sections in kernel are preemptable They now

use real-time mutexes, including a priority inheritance protocol

  • Interrupt handlers are interruptable kernel threads
  • High-precision timer support
  • Not suitable for safety-critical hard real-time

[SCHED_DEADLINE, http://www.evidence.eu.com/content/view/313/390/]

slide-44
SLIDE 44

The Dual-kernel Approach

Solutions to run hard-real time tasks and Linux:

  • Real Time Linux

(RTLinux)

  • Real-Time

Application Interface (RTAI)

  • Xenomai

11.12.2012 Real-time Operating Systems 44

slide-45
SLIDE 45

RTLinux & RTAI

  • Dual-kernel approach, two schedulers are in operation
  • Supports hard real-time (deterministic) operation through

interrupt control between the hardware and the operating

  • system. (Adeos Event Pipeline)
  • Linux runs as its lowest-priority process
  • Real-time applications specifically written for the non-

Linux kernel using an associated real-time API

  • Can exchange data with Linux applications (LXRT)
slide-46
SLIDE 46

RTLinux & RTAI

  • Tasks are executed inside kernel memory space, which

prevents threads to be swapped-out and also the number of TLB misses is reduced.

  • Threads are executed in processor supervisor mode

(i.e. ring level 0 in i386 arch), have full access to the underlying hardware.

  • Since the RTOS and the application are linked together in a

"single" execution space, system call mechanism is implemented by means of a simple function call (default is software interrupt which produces higher overhead).

slide-47
SLIDE 47

Xenomai

RTAI spin-off, designed for

  • extensibility
  • portability
  • maintainability

Task can switch transparently

  • Primary mode (hard RT)
  • Secondary mode (soft RT)

Skins can emulate RTOS APIs

11.12.2012 Real-time Operating Systems 47

slide-48
SLIDE 48

Conclusion

11.12.2012 Real-time Operating Systems 48

slide-49
SLIDE 49

RTOS Trends

“Mil-aero systems require more and more functionality often found in traditional desktop operating systems rather than traditional real-time

  • perating systems, including graphical user interfaces (GUIs) and graphics,

advanced networking, and disk and SSD storage” Robert Day, vice president of marketing at LynuxWorks Inc. “Mil-aero systems require more and more functionality often found in traditional desktop operating systems rather than traditional real-time

  • perating systems, including graphical user interfaces (GUIs) and graphics,

advanced networking, and disk and SSD storage” Robert Day, vice president of marketing at LynuxWorks Inc. Security of network, security of information and data, and access controls and secure logins are now often specified as part of the functionality of the RTOS and its associated stacks. Separation kernels, partitioned operating systems, and secure operating systems are now being mandated for programs.“ Robert Day, vice president of marketing at LynuxWorks Inc. Security of network, security of information and data, and access controls and secure logins are now often specified as part of the functionality of the RTOS and its associated stacks. Separation kernels, partitioned operating systems, and secure operating systems are now being mandated for programs.“ Robert Day, vice president of marketing at LynuxWorks Inc.

11.12.2012 Real-time Operating Systems 49

slide-50
SLIDE 50

Conclusion

  • RTOS provide guarentees for embedded

application developers

  • RTOS can significantly reduce effort for embedded

software development

  • RTOS act as means to implement mixed-criticality

systems

  • Are readily available as open source, research or

commercial products

11.12.2012 Real-time Operating Systems 50

slide-51
SLIDE 51

ENDE

Danke für die Aufmerksamkeit!

11.12.2012 Real-time Operating Systems 51

slide-52
SLIDE 52

Demonstration: PWM signal generation

See http://veter-project.blogspot.co.at/2011/09/real-time- enough-about-pwms-and-shaky.html

11.12.2012 Real-time Operating Systems 52