You are on page 1of 4

Course Outline Overall Structure of RT Systems

Introduction
Characteristics of RTS Hardware (CPU, I/O device etc)
Real Time Operating Systems (RTOS)

a clock!
OS support: scheduling, resource handling
Real Time Programming Languages
Language support, e.g. Ada tasking

Scheduling and Timing Analysis of RT Software


A real time OS (function as standard OS, with predictable
Worst-case execution and response time analysis behavior and well-defined functionality)
Design and Validation
Modeling, Verification and Testing
Reliability and Fault-Tolerance A collection of RT tasks/processes (share resourses,
Fault tolerant, failure recovery, exception handling communicate/synchronize with each other and the
Distributed real time systems environment)
Real Time Communication: CAN Bus

1 2

General-Purpose vs. Embedded RT Computer Systems


Components of RT Systems

Comm. Network
Other Computers
User Programs/application Control Tasks and
Actuators Real Time Software Operating
Operating System

RTOS Hardware Hardware


e.g.
Cars,
trains Task Task System
Sensors Task

Physical World General-purpose computer systems Typical Embedded Configuration

3 4

Characteristics of a RTS Characteristics of a RTS (ctn.)


Large and complex vary from a few hundred lines Extreme reliability and safety embedded
of assembler or C to 20 million lines of Ada estimated
for the Space Station Freedom systems typically control the environment in
Concurrent control of separate system components which they operate; failure to control can
devices operate in parallel in the real-world; better
to model this parallelism by concurrent entities in the result in loss of life, damage to environment
program or economic loss
Facilities to interact with special purpose hardware Guaranteed response times we need to be
need to be able to program devices in a reliable and
abstract way able to predict with confidence the worst case
Mixture of Hardware/Software: some modules response times for systems; efficiency is
implemented in hardware, even whole systems, SoC
important but predictability is essential

5 6

1
Classification of RTSs Classification of RTSs

Hard real-time systems where it is absolutely imperative that value value


responses occur within the required deadline. E.g. Flight control
systems, automotive systems, robotics etc. Hard deadline soft deadline

Soft real-time systems where deadlines are important but which


will still function correctly if deadlines are occasionally missed. E.g.
Banking system, multimedia etc.
value value
A single system may have both hard and soft real-time

Subsystems. In reality many systems will have a cost On-time deadline no deadline

function associated with missing each deadline.

7 8

Example: a Car Controller Programming the car controller (1)

Activities of a car control system. Let


Process Speed: Process ABS
1. C= worst case execution time
Loop Loop
2. T= (sampling) period
3. D= deadline
read sensor,compute,display... Read sensor, compute, react
Speed measurment: C=4ms, T=20ms, D=5ms sleep (0.02) /*period*/ sleep(0.04)
ABS control: C=10ms,T=40ms, D=40ms End loop End loop
Fuel injection: C=40ms, T=80ms,D=80ms
Other software with soft deadlines e.g audio, air condition etc Process Fuel Soft RT Processes
Loop Loop
read data, compute, inject ... read temperature
Construct a controller meeting all the deadlines! sleep(0.08) el hiss, stereo
End loop ....
End loop
9 10

Any problem? Programming the car controller (2)

We forgot the execution times Process Speed: Process ABS


Loop Loop
next := get-time + 0.02 next:=get-time + 0.04
read sensor,compute,display... Read sensor, compute, react
sleep until next sleep until next
e.g. Process speed: End loop End loop

20ms = execution time + sleep(X) 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
11 12

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

We dont know if the deadlines are met! 80 0


4
76 Soft RT tasks speed 14
We need to know the execution times ABS
We need to do schedulability analysis
We need to construct a schedule FUEL-4
FUEL-1 20
We need to implement/buy an RT OS kernel 64
speed
speed A feasible Schedule!
24

FUEL-3
60 Fuel-2
ABS
speed
54 40
13 44 14

Design and Implementation of RT Systems Real-time Programming Languages

Specification and Analysis Assembly languages


Requirement Specs Sequential programming languages e.g. Pascal, C.
Design Specs
Both normally require operating system support.
Implementation
Hardware platform
High-level concurrent languages e.g. Concurrent
OS kernel
Pascal, Ada, Modula-2, RT Java.
Design/Programming Languages No/less operating system support!
Code generation vs. coding
Other (design/prog) languages: Esterel, Lustre,
Validation

SystemC, UML (modeling and Code generation)
Verification

Testing
We will consider:
Ada 95 and C

15 16

Challenges in RT Systems Design Main desirable properties of RT Systems (2)

Predictability: able to predict the future Maintainability: modular structure to ease system
consequences of current actions modification
Testability: easy to test if the system can meet all the Robustness: must not collapse when subject to peak
deadlines load, exception, manage all possible scenarios
Cost optimality: e.g. Energy consumption, memory Fault tolerance: hardware and software failures
blocks etc should not cause the system to crash - function
down-grading

17 18

3
Predictability: the most important one Difficult to achieve predictability: Hardware & RTOS

The system behaviour is known before it is Cache sharing, processor pipelines, DMA ...
Interrupt handling may introduce unbounded delays
put into operation!

Priority inversion (low-prority tasks blocking high-prior taskts)


e.g. Response times, deadlock freedom etc Memory management (static allocation may not be enough,
dynamic data structures e.g. Queue), no virtual memory
Communication delays in a distributed environment
Difficult (impossible?) to achieve!

19 20

Difficult to achieve predictability: RT Tasks: Problems to solve ...


Difficult to calculate the worst case execution time for Missing deadlines (!)
tasks (theoretically impossible, halting problem) Deadlocks/livelocks
Avoid dynamic data structures
Uncontrolled exception (ARIAN 5)
Avoid recursion
Bounded loops e.g. For-loops only
Priority inversion (the Mars project)
Uncontrolled code size, cost, ...
Complex synchronization patterns between tasks:
Non-determinism and/or Race condition
potential deadlocks (formal verification)
Overloaded
Multi-tasking, tasks that share resources

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, ...
Non-determinism and/or Race condition
Overloaded

23

You might also like