operating systems real-time...

Hermann Härtig, TU-DresdenReal-Time Systems, WS 2006 Real-Time Operating Systems, 1

Real-Time Operating Systems


Attention

Thomas Gleixneron the real-time preemption patch for Linux(exact title to be announced later)

EZAG: FR 26.1.2007 1300h

Location: to be announced !


Paper Reading

• J. Loeser, H. Härtig: Low-latency Hard Real-Time Communication over Switched Ethernet (ECRTS 2004)

• L. Reuther, M. Pohlack: Rotational-Position-Aware Real-Time Disk Scheduling Using a Dynamic Active Subset (IEEE RTSS 2003)

• N. Feske, H. Härtig: Demonstration of DOpE — a Window Server for Real-time and Embedded Systems (IEEE RTSS 2003)

• S. Schönberg: Impact of PCI-Bus Load on Applications in a PC Architecture (IEEE RTSS 2003)

• U. Dannowski, H. Härtig: Policing Offloaded (RTAS 2000)


Overview

VariantsRequirementsCase-Studies:• RT-Posix Interface• ARINC Partition Operating Systems• See Our Web Pages: DROPS (Paper Reading)• See Our Web Pages: OSEK (Folien: Dr. Jochen Schof)


Variants of RTOSes

• cyclic executives• no preemption• time driven, polling for events

• collection of interrupt handlers• handlers have priorities


More Variants

• thread packages (thousands)• fixed priorities• preemption• some: have priority ceiling/inheritance•most: proprietary (e.g. iRMX)no address spaces

• Micro Kernels• address spaces• some have virtual memory / some have not • extensive functionality as servers on top

(e.g. QNX, VxWorks)


Event-Driven v Time-Driven

• event driven•messages, signals, interrupts ... as events• priorities

• time driven: for example “Partitioned Systems”• statically create partitions and allocate resources to them• divide memory and CPU time between partitions• ensure space and time isolation between partitions• each partition may contain multiple threads, processes• time isolation

– global time-driven scheduler allocates time to partition(fixed cyclic scheduler)

– local scheduler schedules time among processes within partition

Arinc 653-1 standard for avionics


More Variants

• Modified non RT-Systems• identify areas of problems and add/change•many UNIX-variants (SORIX, LynxOS, ...)•Linux preemption patches


More Variants

• Provide some commonly used interface on top of RTOS• QNX with Unix emulator

• Run existing Non RT-Systems on top of RTOSRT-Linux, Radisys Windows-NT, RT-MACHDROPS, Green Hills


More Variants

• Resource Managers•manage more resources than just CPU• rk-linux, resource kernel, DROPS


Requirements: Time as „First Class Citizen“

• Periodic Processes orabsolute timeouts

• syscalls: • clock_gettime()• clock_setresolution

• Higher resolution Clocks than commercial OSes:10 ms is too coarse•Use CPU‘s event counters•Use timers in „one shot mode“

• Time synchronisation


Scheduler Policies

Fixed PrioritySufficient priority levels ( e.g. 256 for RMS)Priority Ceiling or Priority inheritence is supported

(e.g. VxWorks had it swiched off on Mars Pathfinder)

Events / messages with priorities:higher priority messages/events arrive firstsome systems: donate their priority to receiver

Signals are queued (predictability)


Dynamic Priorities

set_priority (), get_priority• not usable for EDF • usable for mode changes

EDF scheduling• research systems (RT-MACH)• RT-Oberon • ALPHA

What if processes abuse priorities ? Overload ?


Periodic Threads and Quanta

Admission/Scheduler.Reserve(thread, period, priority, budget)

how to control overuse of budgets?• periodic threads as first class objects:

while (){ if beginperiod /* notify if not completed during

/* reserved period{ do execute }else

}• watchdog timers


Priority Ceiling / Inheritance

Ceiling:• lock.setprio() after init• add used critical sections as parameter to process_creationInheritance:• borrowing cpu timeoften much simpler:• no preemption in critical sections


Sources of Impredictability in Modern Hardware

TLBsCachesPipelining (write buffers)Busses“Intelligent” Devicesnetworks


Reduce or bound interrupt latency

Techniques:• Do not use interrupt interrupt blocking for synchronisation• Very short interrupt service routines („top halves“)• Schedule bottom halves (and top halves) independently

use software interrupts priority levels• Use partitioned cache• ...


Memory Management

Avoid paging

But:• separate address spaces very useful for debugging•Paging must sometimes be included in RT-Applications

mlock(address, length)mlockall


Asynchronous I/O

E.g. RT-Posix:

aio_read(struct aiocb *raccb) aio_write(struct aiocb *waccb)

notification via signals ...

aio_suspend to wait for asynchronous IO


Tools

Separation of development and target platform (VxWorks)

Tools • Extensive: for debugging in development platforms

RMS tools• E.g. Logging to identify problems in deployed systems


IEEE Posix(Portable OS Interface) Real-Time Extensions

Posix 1003.1: Core ServicesPosix 1003.1b: Real-Time Extensions (alias Posix 4)Posix 1003.1c: ThreadsPosix 1003.1d: Additional Real-Time extensionsPosix 1003.1j: Advanced Real-Time extensionsPosix 1b:• Priority Scheduling• Real-Time Signals• Clocks• Semaphores, Message Passing, Shared Memory• Asynchronous IO• Memory Locking


RT Posix Signals

Key Differences• Queued• Carry Data• Ordered Delivery

Additional new class of RT-Signals: SIGRTMIN ... SIGRTMAX

With Parameter: pointer to siginfo_t structureAre queued and are delivered in order:

lower number first

Posix RT messages: priority ordered.


RT-Posix Clocks and Timers

Key differences• Higher resolution (min 20ms)• At least one required, more allowed

struct timespec {time_t tv-Sec; /* number of seconds since 1970 */long tv_nsec }

clock_gettime(clockid_t clockid, struct timespec *t );clock_settime, clock_getres

nanosleeptimeout for semaphores


RT-Posix Clocks and Timers

Timers: • are associated to a clock• Up to 32 per process• RT Signals can be associated

timer_create (clockid, signal, timer_id)timer_delete (timerid)timer_settime (timerid, time)


RT-Posix Execution-Time Clocks and Timers

Clock_Process_CPUtime_IdClock_Thread_CPUtime_Id

timer_create (Clock_Thread_CPUtime_Id, signal, timer_id) timer_settime (timerid, time)

“fires” if thread overuses its WCET


RT Posix Scheduling

Key difference:• Select one of two (three) standard schedulers

•Sched_FIFO: preemptive, priority-based scheduler•Sched_PR: preempt., prio.-based sched. with quanta•Sched_OTHER: vendor specific

Sched_setscheduler (per process !)At least 32 priorities required Int sched_setparam(pid, ... )


Asnychronous IO (AIO)

Key difference:• Explicitely overlap IO and processing


Memory Locking

Key differences:• Pages can be locked


DROPS: Dresden Real – Time OS

L4 / Fiasco Microkernel

Resource ManagementL4Env & Basic Resource Manager

Legacy ApplicationsEditor, Compiler, …

Mixed ApplicationsMultimedia, …

Real-Time ApplicationsController, …

Real TimeNon Real Time

Disk Driver

Real-TimeFile System

NetworkDriver

WindowSystem

NetworkProtocol

L4Linux

Stu

bs


DROPS – Real-Time Application Model

• Applications are constructed from several real-time components• Application sets up and controls chain of components

• Components process data streams

• Data transfer between components e.g. using DSI

Video Player

CPUScheduler

MemoryManager

VideoDecoder

FileSystem

AudioDecoder

WindowSystem

SoundDriver

DiskDriver


DROPS – Real-Time Application Model

• Real-time components require system resources to work properly• Resources must be available when they are needed to achieve guarantees

(response time, bandwidth, …) No “out of memory” etc.

Components use Resource Mamanger to reserve the required amount of resources

VideoDecoder

Input Data Stream

OutputData Stream

Resource Reservations

ApplicationInterface

CPUScheduler

MemoryManager

Hermann Härtig, TU-DresdenReal-Time Systems, WS 2006 Real-Time Operating Systems, 32KernelFiasco Microkernel

L4/Fiasco Scheduling – Programming Interface

Example: application with a mandatorypart (M) and two optional parts (O1, O2)

Admission server calculates priorities and reservation times

Sets scheduling contexts and period for thread which executes application

– rt_add(), rt_remove(), rt_period()

Admission Server

rt_period(…)rt_add(…)…

M

O1O2

time

priority

Thread



Example: application with a mandatorypart (M) and two optional parts (O1, O2)

Admission starts periodic execution of application thread

– rt_begin_periodic(),

rt_end_periodic() Admission Server

rt_begin_periodic(…)

M

O1O2

time

priority

Thread



Application

while(periodic) {

rt_next_period();

/* do mandatory M */

}

M

O1O2

time

priority

Application waits for begin of next period

– rt_next_period()

Thread



Application

while(periodic) {

rt_next_period();


rt_next_reservation();

/* do optional O1 */



}

M

O1O2

time

priority

If finished with M, the application calls rt_next_reservation()

to switch to the reservation for O1

Thread



Thread

Application

while(periodic) {

rt_next_period();






}

M

O1O2

time

priority

Kernel monitors execution of threads

Time slice overrun

– Thread exceeded time quantum

( reservation time)

Deadline miss– Thread missed its periodic deadline

In both cases aPreemption IPC is sent to the preempter assigned to the thread

Preempter can handle fault, e.g. set thread to an error handler

period


L4/Fiasco Scheduling

• Execution models•Strict periodic - constant interrelease times

•Periodic - minimal interrelease times

•Aperidoc - unknown interrelease times• (Sporadic - aperiodic with hard deadline)

M

time

M M

t n+1tnt n+2

M

time

M M

t n+1tn t n+2



Example: Application with minimal interrelease times

two release conditions• Minimal interrelease time over

• Required event came inApplication

while(periodic) {

rt_next_period(ipc_params);

/* do something like

- handle an interrupt

- handle some optional

parts

*/

}

M

time

priority

M

KernelFiasco Microkernel

l4_ipc(…)

msg

Thread


Arinc 653-1 standard for avionics

aus: http://www.lynuxworks.com/rtos/image/time-partition.gif


ARINC Partitions

aus: Green Hills Webseiten


ARINC Health Monitoring and Time Managment

ARINC 653 Health Monitoring: The Health Monitor (HM) is invoked by an application calling the RAISE_APPLICATION_ERROR service or by the OS or hardware detecting a fault.

Time Management: services related to time management. TIMED_WAIT and PERIODIC_WAIT are Time Management service requests.

aus:http://www.lynuxworks.com/solutions/milaero/arinc-653.php


ARINC Interpartition Communication

for communication between processes residing in different partitions• Sampling Port Services: A sampling port is a communication object

allowing a partition to access a channel of communication configured to operate in sampling mode.

• Queuing Port Services: A queuing port is a communication object allowing a partition to access a channel of communication configured to operate in queuing mode.



ARINC Intrapartition Communication:

between processes residing in the same partition. • Buffer Servicesand Blackboard Services: communication objects

used by processes of the same partition to send or receive messages.• Semaphore Services: a synchronization object commonly used to

provide access to partition resources.• Event Services: a synchronization object used to notify the

occurrence of a condition to processes that may wait for it.



ARINC RTOS

Lynx OSVxWorksRT-Linux (FSM Labs)Green Hills

(-> A380, B1B, Eurofighter, F35 Joint Strike Fighter, Boeing X45 Unmanned Air Vehicle, Allied Telesyn Gigabit Ethernet Switch, ...)


Do 178B Standard(taken from esterel.com)

defines the guidelines for development of aviation softwaredefines * Objectives for software life-cycle processes. * Description of activities and design considerations for achieving

those objectives. * Description of the evidence indicating that the objectives have

been satisfied.


Do 178B Standard(taken from esterel.com)

DO-178B defines five Development Assurance Levels: * Level A: Catastrophic failure condition for the aircraft (e.g.,

aircraft crash). * Level B: Hazardous/severe failure condition for the aircraft

(e.g., several persons could be injured). * Level C: Major failure condition for the aircraft (e.g., flight

management system could be down, the pilot would have to do it manually).

* Level D: Minor failure condition for the aircraft (e.g., some pilot-ground communications could have to be done manually).

* Level E: No effect on aircraft operation or pilot workload (e.g., entertainment features may be down).


References

Liu,.. Kopetz

More on DROPS• Paper Reading• TUD OS group web-sites• Lecture:

Konstruktion microkernbasierter Betriebssysteme

Real-Time Magazin• What makes a good RTOS ?• Evaluation Reports on various RTOS (e.g., Windows NT)

operating systems real-time...

Documents