Course Outline Overall Structure of RT Systems

„ Introduction
„ Characteristics of RTS „ Hardware (CPU, I/O device etc)
Real Time Programming Language
„
„ a clock!
„ Language support, e.g. Ada tasking
„ Real Time Operating Systems (RTOS)
System support: scheduling, resource handling
„
„ A real time OS (function as standard OS, with predictable
„ Design and Analysis of RT Application Software
„ Modeling and analysis behavior and well-defined functionality)
„ Reliability and Fault-Tolerance
„ Fault tolerant, failure recovery, exception handling
„ Distributed real time systems „ A collection of RT tasks/processes (share resourses,
„ Real Time Communication: TTCAN communicate/synchronize with each other and the
environment)

1 2

Components of RT Systems
Characteristics of a RTS
„ Large and complex — vary from a few hundred lines
Other Computers
Comm. Network of assembler or C to 20 million lines of Ada estimated
for the Space Station Freedom
Actuators Real Time Software „ Concurrent control of separate system components
— devices operate in parallel in the real-world; better
to model this parallelism by concurrent entities in the
Real Time OS program
e.g. „ Facilities to interact with special purpose hardware —
Cars, need to be able to program devices in a reliable and
trains Task Task abstract way
Sensors Task
„ Mixture of Hardware/Software: some modules
implemented in hardware, even whole systems, SoC

Physical World
3 4

Characteristics of a RTS (ctn.) Terminology

„ Extreme reliability and safety — embedded

Continuous interaction with the environment:
systems typically control the environment in „

„ Reactive Systems
which they operate; failure to control can „ Must react to the environment in time:
result in loss of life, damage to environment „ Time-sensitive systems

or economic loss „ Embedded in electronic and/or mechanical devices, complex

systems:
„ Guaranteed response times — we need to be „ Embedded systems
able to predict with confidence the worst case „ A failaure may cause the loss of lifes ...:
response times for systems; efficiency is „ Safety-critical systems/fault-tolerant systems

important but predictability is essential

5 6

1
 Terminology (ctn.) Real-time Programming Languages
„ It often deals with continuous variables e.g. „ Assembly languages
temperature, speed, etc (hybrid systems, dynamics „ Sequential programming languages — e.g. Pascal, C.
systems) „ Both normally require operating system support.
„ RT system may consist of many processes running on „ High-level concurrent languages e.g. Concurrent
„ single processor (concurrent/multi-task systems) Pascal, Ada, Modula-2, Java.
„ tightly-coupled processors (parallel systems), „ No/less operating system support!
multicores, MPSoC „ We will consider:
„ loosely-coupled processors connected by a
„ Ada 95 and C
network (distributed systems)

7 8

Real-Time Languages and OS’s Classification of RTS’s

„ Hard real-time — systems where it is absolutely imperative that

responses occur within the required deadline. E.g. Flight control
User Programs/application
Control programs/application
systems.
Operating Including Operating
„ Soft real-time — systems where deadlines are important but which
will still function correctly if deadlines are occasionally missed. E.g.
Hardware Hardware Data acquisition system.

„ Firm real-time — systems which are soft real-time but in which

System System Components there is no benefit from late delivery of service.

„ Real real-time — systems which are hard real-time and in which the
response times are very short. E.g. Missile guidance system.

General-purpose computer systems Typical Embedded Configuration

9 10

Example: a Car Controller

Activities of a car control system. Let
1. C= worst case execution time
2. T= (sampling) period
3. D= deadline
A single system may have all hard, soft and real real-time subsystems „ Speed measurment: C=4ms, T=20ms, D=5ms
In reality many systems will have a cost function associated with „ ABS control: C=10ms,T=40ms, D=40ms
missing each deadline. „ Fuel injection: C=40ms, T=80ms,D=80ms
„ Other software with soft deadlines e.g audio, air condition etc

Construct a controller meeting all the deadlines!

11 12

2
Programming the car controller (1) Any problem?

Process Speed: Process ABS „ We forgot the execution times !

Loop Loop
read sensor,compute,display... Read sensor, compute, react
sleep (0.02) /*period*/ sleep(0.04)
End loop End loop e.g. Process speed:

Process Fuel Soft RT Processes 20ms = execution time + sleep(X)

Loop Loop
read data, compute, inject ... read temperature
sleep(0.08) el hiss, stereo
End loop ....
End loop
13 14

Programming the car controller (2) What is the problem now?

Process Speed: Process ABS We don’t know if the deadlines are met!
Loop Loop
next := get-time + 0.02 next:=get-time + 0.04 „ We need to know the execution times
read sensor,compute,display... Read sensor, compute, react „ We need to do schedulability analysis
sleep until next sleep until next „ We need to construct a schedule
End loop End loop „ We need to implement/buy an RT operating system
„ Run-time system (in programming language design)
Process Fuel Soft RT Processes
Loop Loop
next:=get-time + 0.08 read temperature
read data, compute, inject ... elevator, stereo
sleep until next ....
End loop End loop
15 16

Programming the car controller (3) Main desirable properties of RT Systems(1)

80 0 „ Timeliness: not only outputs but also times they are
4
76 Soft RT tasks produced
speed 14
ABS „ Predictability: able to predict the future
FUEL-4
consequences of current actions
FUEL-1 20 „ Testability: easy to test if the system can meet all the
64
deadlines
speed
speed A feasible Schedule! „ Cost optimality: e.g. Energy consumption, memory
24 blocks etc
FUEL-3
60 Fuel-2
ABS
speed
54 40
44 17 18

3
Main desirable properties of RT Systems (2) Predictability: the most important one
„ Maintainability: modular structure to ease system „ The system behaviour is known before it is
modification put into operation!
Robustness: must not collapse when subject to peak
e.g. Response times, deadlock freedom etc
„

load, exception, manage all possible scenarios

„ Fault tolerance: hardware and software failures
should not cause the system to crash - function Difficult (impossible?) to achieve!
down-grading

19 20

This is not so easy, why? This is not so easy, why?

RT OS: RT Tasks:

„ System calls: difficult to know the worst execution times „ Difficult to calculate the worst case execution time for
(theoretically impossible, halting problem) tasks (theoretically impossible, halting problem)
„ Cache (hit ratio, never exact), pipelines ... „ Avoid dynamic data structures
„ DMA stealing CPU memory cycle (when CPU running a hard „ Avoid recursion
task) „ Bounded loops e.g. For-loops only
„ Interrupt handling may introduce unbounded delays „ Complex synchronization patterns between tasks:
„ Priority inversion (low-prority tasks blocking high-prior taskts) potential deadlocks (formal verification)
„ Memory management (static allocation may not be enough,
dynamic data structures e.g. Queue), no virtual memory
„ Communication delays in a distributed environment

21 22

Problems to solve ...

„ Missing deadlines (!)

„ Deadlocks/livelocks
„ Uncontrolled exception (ARIAN 5)
„ Clock jitter (the golf war, Scud missile)
„ 57micro sec/min, 343ms/100 hours

„ 687 meters

„ Priority inversion (the Mars project)

„ Uncontrolled code size, cost, ...
„ Wrong timeout periods
„ Non-determinism and/or Race condition
„ Overloaded

23