School of Electrical and Computer Engineering N.T.U.A.

Real Time Operating Systems

Embedded System DesignAlex BartzasMicrolab/NTUA

Άδεια Χρήσης

Το παρόν εκπαιδευτικό υλικό υπόκειται σε άδειες χρήσης Creative Commons.

Για εκπαιδευτικό υλικό, όπως εικόνες, που υπόκειται σε άδεια χρήσης άλλου τύπου, αυτή πρέπει να αναφέρεται ρητώς.

What is an Embedded OS?

An "embedded system" is any computer system or computing device that performs a dedicated function or is designed for use with a specific embedded software

li tiapplication.

Embedded systems may use a ROM-based operating system or they may use a disk-based system, like a PC. But

b dd d t i t bl i ll i blan embedded system is not usable as a commercially viable substitute for general purpose computers or devices.

3

Aspects of embedded system design

4

Metrics

•Performance can be measured in multiple ways–Latency vs. throughput–Average vs. worst-case vs. best-case–Peak vs. sustained

•Power/energy–Power consumption is important for heat generation–Energy consumption is important for battery lifeI t t d t i h E D l P d t (EDP)–Integrated metrics such as Energy-Delay Product (EDP)

•CostD i ti lif ti–Design time vs. lifetime

•ReliabilityA il bilit d d bilit f bilit–Availability, dependability, performability

5

Hardware/software codesign

•Goals–Optimizing design process–Optimizing designp g g

•Tasks–Cospecificationand comodeling–Codesigng–Cosynthesis, optimization, interfacing–VerificationVerification

6

Codesign flow

7

What makes a good Embedded OS?

ModularScalableConfigurablegSmall footprintCPU supportppDevice driversetc, etc, etc..., ,

8

What is Real Time?

“A real time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result i d d If th ti i t i t f th t tis produced. If the timing constraints of the system are not

met, system failure is said to have occurred.”

9

What is Real Time?

“Real time in operating systems:

The ability of the operating system to provide a required l l f i i b d d ti ”level of service in a bounded response time.”

10

Hard vs. Soft Real Time

Hardguaranteed worst-case response timesabsolutely, positively, first time every timeabso u e y, pos e y, s e e e y e

SoftKinda, sorta, usuallyKinda, sorta, usually

11

What makes a good RTOS?

Multi-threaded

Thread priority has to exist because no deadline driven OS p yexists

Must support predictable thread synchronization mechanisms

A system of priority inheritance must exist

12

Embedded operating systems- Requirement: Configurability -- Requirement: Configurability -

ConfigurabilityNo single RTOS will fit all needs, no overhead forunused functions tolerated configurability needed.

simplest form: remove unused functions (by linker ?)simplest form: remove unused functions (by linker ?).Conditional compilation (using #if and #ifdef commands).Dynamic data might be replaced by static dataDynamic data might be replaced by static data.Advanced compile-time evaluation useful.Object-orientation could lead to a derivation subclasses.j

Verification a potential problem of systemswith a large number of derived OSs:

Each derived OS must be tested thoroughly;potential problem for eCos (open source RTOS from Red Hat) incl ding 100 to 200 config ration points [Takada 01]Hat), including 100 to 200 configuration points [Takada, 01].

13

Example: Configuration of VxWorks

pdf

/torn

ado_

2_ds

.pol

s/id

e/to

rnad

o2/

evel

opm

ent_

too

com

/pro

duct

s/de

ww

w.w

indr

iver

.c

© Windriver

http

://w

14

Embedded operating systems -Requirement: Disc and network handled by tasks--Requirement: Disc and network handled by tasks-

Disc & network handled by tasks instead of integrated drivers Many ES without disc, a keyboard, a screen or a mouse.Effectively no device that needs to be supported by all versions of the OS, except maybe the system timer.Relatively slow discs & networks can be handled by tasksRelatively slow discs & networks can be handled by tasks.

RTOS Standard OS

15

Example: WindRiver Platform Industrial Automation

© Windriver16

Embedded operating systems - Requirement: Protection is optional-- Requirement: Protection is optional-

Protection mechanisms not always necessary:y yES typically designed for a single purpose,untested programs rarely loaded, SW considered reliable.(However, protection mechanisms may be needed for safety and security reasons).

17

Embedded operating systems - Requirement: Interrupts not restricted to OS -- Requirement: Interrupts not restricted to OS -

Interrupts can be employed by any processFor standard OS: serious source of unreliability.Since

b dd d b id d b dembedded programs can be considered to be tested, since protection is not necessary andi ffi i t t l i t f d i i i dsince 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)storing the tasks start address in the interrupt table).More efficient than going through OS services.However composability suffers: if a specific task isHowever, composability suffers: if a specific task is connected to some interrupt, it may be difficult to add another task which also needs to be started by an event.y

18

Embedded operating systems- Requirement: Real-time capability-- Requirement: Real-time capability-

Many embedded systems are real-time (RT) systems and, hence, the OS used in these systems must be real-time operating systems (RTOSes).

19

Real-time operating systems- Real-time OS (1) -- Real-time OS (1) -

Def.: (A) real-time operating system is an operating system that supports the construction of real-time systems

The following are the three key requirementsg y q1. The timing behavior of the OS must be predictable.

∀ services of the OS: Upper bound on the execution time!ppRTOSs must be deterministic:

unlike standard Java,,short times during which interrupts are disabled,contiguous files to avoid unpredictable headcontiguous files to avoid unpredictable head movements.

[Takada 2001][Takada, 2001]

20

Real-time operating systems- Real-time OS (2) -- Real-time OS (2) -

2. OS must manage the timing and schedulingg g g

OS possibly has to be aware of task deadlines;(unless scheduling is done off line)(unless scheduling is done off-line).

OS must provide precise time services with high resolution.

[Takada, 2001][Takada, 2001]

21

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:q p• International atomic time TAI

(french: temps atomic internationale)Free of any artificial artifacts.

• Universal Time Coordinated (UTC)UTC i d fi d b t i l t d dUTC is defined by astronomical standards

UTC and TAI were identical on Jan. 1st, 1958.In the meantime, 30 seconds had to be added.Not without problems: New Year may start twice per night.

22

Internal synchronization

Synchronization with one master clockTypically used in startup-phases

Distributed synchronization:y1. Collect information from neighbors2. Compute correction valuep3. Set correction value.Precision of step 1 depends on how information is collected:p pApplication level: ~500 µs to 5 msOperation system kernel: 10 µs to 100 µsOperation system kernel: 10 µs to 100 µsCommunication hardware: < 10 µs

23

Byzantine Error

Erroneous local clocks can have an impact on the computed local time.Advanced algorithms are fault-tolerant with respect to Byzantine errors. Excluding k erroneous clocks is possible with 3k+1 clocks (largest and smallest values will be excludedexcluded.Many publications in this area.

k=1

t

24

External synchronization

External synchronization guarantees consistency with actual physical time.Recent trend is to use GPS for ext. synchronizationGPS offers TAI and UTC time information.Resolution is about 100 ns.

25

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.

26

Real-time operating systems- Real-time OS (3) -- Real-time OS (3) -

3. The OS must be fastPractically important.

[Takada 2001][Takada, 2001]

27

RTOS-Kernels

Distinction between• real-time kernels and modified kernels of standard OSes.

Distinction betweengeneral RTOSes and RTOSes for specific domains• general RTOSes and RTOSes for specific domains,

• standard APIs (e.g. POSIX RT-Extension of Unix, ITRON, OSEK) or proprietary APIsOSEK) or proprietary APIs.

28

Functionality of RTOS-Kernels

Includesc udes• processor management, • memory management, resource managementmemory management,• and timer management;• task management (resume wait etc)

resource management

task management (resume, wait etc),• inter-task communication and synchronization.

29

Classes of RTOSes according to R. Gupta1 Fast proprietary kernels1. Fast proprietary kernels

Fast proprietary kernelsFast proprietary kernelsFor complex systems, these kernels are inadequate, because they are designed to be fast, rather than to bebecause they are designed to be fast, rather than to be predictable in every respect

[R Gupta UCI/UCSD][R. Gupta, UCI/UCSD]Examples includeQNX PDOS VCOS VTRX32 VxWORKSQNX, PDOS, VCOS, VTRX32, VxWORKS.

30

Classes of RTOSes according to R. Gupta2 Real-time extensions to standard OSs2. Real-time extensions to standard OSs

Real-time extensions to standard OSes:Attempt to exploit comfortable main stream OSes. RT-kernel running all RT-tasks.St d d OS t d t kStandard-OS executed as one task.

+ Crash of standard-OS does not affect RT-tasks;- RT-tasks cannot use Standard-OS services;

less comfortable than expectedless comfortable than expected

31

Example: RT-Linux

RT-tasks cannot use Init B h M ill standard OS calls.Commercially available from f l b ( f l b )

Init Bash Mozilla

fsmlabs (www.fsmlabs.com)

RT T k RT T kLinux-Kernel

scheduler

RT-Task RT-TaskLinux Kernel

driver

interrupts

RT-Linux RT-Schedulerinterrupts

interrupts

I/O

Hardware

interruptsI/O

Hardware

32

Example: Posix 1.b RT-extensions to Linux

Standard scheduler can be replaced by POSIX scheduler implementing priorities for RT tasks

Init Bash MozillaRT-Task RT-Task

Special RT-calls and

Linux-KernelPOSIX 1.b scheduler

pstandard OS calls available.Linux Kernel

driver

I/O i t t

Easy programming, no guarantee for

ti d dli

Hardware

I/O, interrupts meeting deadline

Hardware

33

Evaluation (Gupta)

According to Gupta, trying to use a version of a standard OS:

t th t h b t b i dnot 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)optimizing for the average case (rather than the worst case), ... ignoring most if not all semantic information, and independent CPU scheduling and resource allocation.p gDependences 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

Classes of RTOSes according to R. Gupta3 Research systems trying to avoid limitations3. Research systems trying to avoid limitations

Research systems trying to avoid limitations.Include MARS, Spring, MARUTI, Arts, Hartos, DARK, and MelodyR h i [T k d 2001]Research issues [Takada, 2001]:

low overhead memory protection,t l t ti f titemporal protection of computing resources RTOSes for on-chip multiprocessors

t f ti disupport for continuous mediaquality of service (QoS) control.

C titi b tCompetition betweentraditional vendors (e.g. Wind River Systems) and Embedded Windows XP and Windows CEM

arke

t

Embedded Windows XP and Windows CEM

35

Middleware

1. Real-time data bases2. Access to remote objects

36

Real-time data bases (1)

Goal: store and retrieve persistent informationTransaction= sequence of read and write operationsChanges not final until they are committed g yRequested (“ACID”) properties of transactions1. Atomic: state information as if transaction is either

completed or had no effect at all.2. Consistent: Set of values retrieved from several

accesses to the data base must be possible in the world modeled.

3. Isolation: No user should see intermediate states of transactions

4 D bilit lt f t ti h ld b i t t4. Durability: results of transactions should be persistent.

37

Real-time data bases (2)

Problems with implementing real-time data bases:1. transactions may be aborted various times before they

are finally committed.2. For hard discs, the access times to discs are hardly

predictable.

Possible solutions:1. Main memory data bases2. Relax ACID requirements2. Relax ACID requirements

38

Access to remote objects

Software packages for access to remote objects;p g j ;Example: CORBA (Common Object Request Broker Architecture).I f ti t t Obj t R t B k (ORB) i l l t bInformation sent to Object Request Broker (ORB) via local stub. ORB determines location to be accessed and sends information via the IIOP I/O protocolvia the IIOP I/O protocol.

Access times not predictable.

39

Real-time (RT-) CORBA

A very essential feature of RT-CORBA is to provideA very essential feature of RT CORBA is to provideend-to-end predictability of timeliness in a fixed priority system.yThis involves respecting thread priorities between client and server for resolving resource contention,and bounding the latencies of operation invocations.Thread priorities might not be respected when threads p g pobtain mutually exclusive access to resources (priority inversion).RT-CORBA includes provisions for bounding the time during which such priority inversion can happen.

40

Real-time COBRA- Thread priority management -Thread priority management

RT-CORBA includes facilities for thread priorityRT CORBA includes facilities for thread priority management.Priority independent of the priorities of the underlying y p p y gOS, even though it is compatible with the RT-extensions of the POSIX standard for OSs [Harbour, 1993].The thread priority of clients can be propagated to the server side.Priority management for primitives for mutually exclusive access to resources. Priority inheritance protocol must be available in implementations of RT CORBAbe available in implementations of RT-CORBA.Pools of preexisting threads avoid the overhead of thread creation and thread-constructioncreation and thread-construction.

41

Message passing interface (MPI)

Message passing interface (MPI): alternative to CORBAMessage passing interface (MPI): alternative to CORBAMPI/RT: a real-time version of MPI [MPI/RT forum, 2001].]MPI-RT does not cover issues such as thread creation and termination.MPI/RT is conceived as a potential layer between the operating system and standard (non real-time) MPI.

42

Resiliency/reliability issues in multicores

43

Reliability, power, performance

44

Best EDP Choices for FFT

45

Automatic code replication for reliability

46

Summary

G l i t f b dd d ti tGeneral requirements for embedded operating systems• Configurability, I/O, interrupts

G l ti f l ti ti tGeneral properties of real-time operating systems• Predictability• Time services, synchronization• Classes of RTOSs, device driver embedding

Middleware (briefly)• RT-data bases• Access to remote objects (RT-CORBA, RT-MPI)

47

Χρηματοδότηση

Το παρόν εκπαιδευτικό υλικό έχει αναπτυχθεί στα πλαίσια του εκπαιδευτικού έργου του διδάσκοντα.

Το έργο «Ανοικτά Ακαδημαϊκά Μαθήματα» του ΕΜΠ έχει χρηματοδοτήσει μόνο την αναδιαμόρφωση του υλικού.

Το έργο υλοποιείται στο πλαίσιο του Επιχειρησιακού Προγράμματος «Εκπαίδευση και Δια Βίου Μάθηση» και συγχρηματοδοτείται από την Ευρωπαϊκή Ένωση (Ευρωπαϊκό Κοινωνικό Ταμείο) και από εθνικούς πόρους.