30/09/2014

Giorgio Buttazzo
E-mail: buttazzo@sssup.it

Scuola Superiore SantAnna

Definition
Real-Time Systems are
computing systems that must
perform computation within given
timing constraints.
They are typically embedded
in a larger system to control
its functions:

Controlled System
Sensors
Motors

Embedded
Computer

Real-Time Embedded Systems

30/09/2014

Evolution of Embedded Systems

Embedded computing systems have grown
exponentially in several application domains:
Number of
embedded
computers

consumer electronics
multimedia
automotive
robotics
avionics

0
1970

1980

1990

2000

2010

year

Typical applications
avionics
automotive
robotics
industrial automation
telecommunications
multimedia systems
consumer electronics

30/09/2014

Health Care
Tele-monitoring
Tele-rehabilitation
Assisted Living
Sport

From Hardware to Software

We are experiencing a dematerialization process in
which many functions are converted into software.
Examples

Money
Documents
Books
Music
Pictures
Movies
Tickets
Education

30/09/2014

Steer by Wire

Control
Unit
Sensor
Motor
Sensor

Motor

Why?
There are many advantages
1. Software is more flexible than hardware
2. It can be quickly changed/adapted/updated
3. It can be upgraded remotely
4. It can evolve into intelligent control algorithms
5. It has no mass, so it can travel at the speed of light

30/09/2014

Increasing complexity
The price to be paid is a higher software complexity.
Related problems

Difficult design

Less predictability

Less reliability

Novel solutions for:

Component-based software design

Analysis for guaranteeing predictability and safety

Testing

Increasing complexity
# functions
in a cell phone

200
80
60
40
20
0
1970

1980

1990

2000

2010

year

30/09/2014

ECU growth in a car

# ECUs
in a car

100
80
60
40
20
0
1970

1980

1990

2000

2010

year

Software in a car
Car software controls almost everything:
Engine:

ignition, fuel pressure, water temperature,

valve control, gear control,

Dashboard: engine status, message display, alarms

Diagnostic: failure signaling and prediction
Safety:

ABS, ESC, EAL, CBC, TCS

Assistance: power steering, navigation, sleep sensors,

parking, night vision, collision detection
Comfort:

fan
control,
air
conditioning,
music,
regulations: steer/lights/sits/mirrors/glasses

30/09/2014

Comparing Software Complexity

Lines of code

100 M

100 M
30 M
10 M

10 M
2M
1M
100 K

50 K

Complexity and bugs

Software bugs increase with complexity:
bugs
10.000
1000
100
10
Lines of code

0
1K

10K

100 K

1M

10 M

30/09/2014

Software reliability
Reliability does not only depend on the correctness of
single instructions, but also on when they are
executed:
controller

input
t

output
t+

A correct action executed too late can be useless or

even dangerous.

Real-Time Systems
Computing systems that must guarantee
bounded and predictable response times
are called real-time systems.
Predictability of response times must be guaranteed
for each critical activity;
for all possible combination of events.

30/09/2014

Predictability vs. Efficiency

QoS management

High performance

Safety critical

predictability

efficiency

Allocated resources
digital tv
soft

firm

hard

Criticality

Whats special in Embedded Systems?

FEATURES

REQUIREMENTS

Scarceresources (space,weight,
time, memory,energy)

Highefficiency inresource
management

Highconcurrency andresource
sharing(hightaskinterference)

Temporalisolation tolimit
theinterference

Interactionwiththeenvironment
(causingtiming constraints)

Highpredictability inthe
responsetime

Highvariability onworkloadand
resourcedemand

Adaptivity tohandle
overloadsituations

30/09/2014

Aim of the Course

Studying software methodologies for supporting
time critical computing systems.
We will not consider how to control a system,
but only how to provide a predictable software
support to control applications.

Main focus: predictable software

Sensory
processing
Control
Commun.

Cyber-Physical Systems

Design
Analysis
Programming

software

Graphics
system
dynamics

Embedded
Computer
Controlled System

10

30/09/2014

Control and implementation

Often, control and implementation are done by
different people that do not talk to each other:

Control guys typically assume a computer with infinite

resources and computational power. In some case,
computation is modeled by a fixed delay .

Control and implementation

In reality, a computer:
has limited resources;
finite computational power (non null execution times);
executes several concurrent activities;
introduces variabile delays (often unpredictable).

Modeling such factors and taking them into account

in the design phase allows a significant
improvement in performance and reliability.

11

30/09/2014

Specific objectives
Study software methodologies and algorithms
to increase predictability in computing systems.
We consider embeddded computing systems
consisting of several concurrent activities subject
to timing constratints.
We will see how to model and analyze a real-time
application to predict worst-case response times
and verify its feasibility under a set of constraints.

Course outline - 1
1. Basic concepts and terminology
2. Problem identification
3. Modeling real-time activities
4. Deriving timing constraints from the application
5. Worst-case reasoning
6. Managing periodic tasks
7. Scheduling algorithms
8. Schedulability analysis
9. Response time analysis

12

30/09/2014

Course outline - 2
10. Problems introduced by resource sharing
11. Resource access protocols
12. Handling asynchronous (aperiodic) tasks
13. Handling overload situations
14. Real-time communication mechanisms
15. Programming examples under Linux

Course outline - 3
Programming real-time tasks
Task structure
Processes and threads
Thread creation and activation
Linux schedulers
Time management
Periodic threads
Accessing shared resources
Examples using a graphics library

13

30/09/2014

Teaching material
Course homepage
http://retis.sssup.it/~giorgio/rts-MECS.html
Books:

ThirdEdition
Springer,2011

ThirdEdition
Pitagora,2006
27

Final Exam
It consists of two parts:
1. Project work
2. Written test

Project: Developing a RT application under Linux, using

the Pthread library and the Allegro graphics library.
Test:

A number of questions and exercises on the

course program.
28

14

30/09/2014

Embedded systems
They are computing systems hidden in an object to control
its functions, enhance its performance, manage the available
resources and simplify the interaction with the user.

Object
microprocessor

actuators
Environment
sensors

communication

user

other units

Control system components

In every control application, we can distinguish 3
basic components:
the system to be controlled
it may include sensors and actuators

the controller
it sends signals to the system according to a
predetermined control objective

the environment in which the system operates

15

30/09/2014

A typical control system

Controller

Environment

System

feedback

Detailed block diagram

System
Controller

actuators

Environ.
sensor
feedback

sensor

internal state

Sensory
processing

preprocessing

external state

Other activities
filtering, classification, data fusion, recognition, planning

16

30/09/2014

Software vision

OUTPUT

INPUT

task

buffer

Types of control systems

Depending of the system-environment interactions,
we can distinguish 3 types of control systems:
Monitoring Systems
do not modify the environment

Open-loop control systems

loosely modify the environment

Closed-loop control systems

tight interaction between perception and action

17

30/09/2014

Monitoring Systems
Do not have actuators
Do not modify the environment
Real-time system
Data
processing
Display

sensors
sensors

..
.

Environment

sensors

Examples: Environmental monitoring, surveillance systems,

air traffic control

Loosely-coupled control systems

Modify the environment, actions are mostly pre-programmed,
so loosely coupled with the current state of the environment:

Controller

System

actuators

Environment

Planning

Data
processing

sensors

Examples: painting robots, assembly robots, sorting robots

18

30/09/2014

Tightly-coupled control systems

Sensing and control are tightly coupled and occur at
different hierarchical level:

System

Controller

actuators

Environment
Data
processing

Planning

Examples:

sensors

flight control systems, military systems,

advanced robots, living beings

Hierarchical control
high-level
recognition

high-level
command

F3
S3

Sensing
S2
low-level
acquisition

F2

F1

S1

A3

Control
A2

A1

low-level
actuation

Environment

19

30/09/2014

Implications
The tight interaction with the environment
requires the system to react to events within
precise timing constraints.
Timing constraints are imposed by the
performance requirements and the dynamics of
the system to be controlled.
The operating system must be able to
execute tasks within timing constraints.

A robot control example

Consider a mobile robot equipped with:
two actuated wheels;
two proximity (US) sensors;
a mobile (pan/tilt) camera;
a wireless transceiver.

Goal
Follow a path based on visual feedback;
Avoid obstacles;
Send complete robot status every 20 ms.

20

30/09/2014

Design requirements
Modularity: a subsystem must be developed without
knowing the details of other subsystems (team work).
Configurability: software must be adapted to different
situations (through the use of suitable parameters) without
changing the source code.
Portability: minimize code changes when porting the system
to different hardware platforms.
Predictability: allow the estimation of maximum delays.
Efficiency: optimize the use of
(computation time, memory, energy).

available

resources

Modularity
Modularity can be achieved by:
partitioning the system into a set of subsystems, each
managed by one or more computational tasks;
defining precise interfaces between tasks, each specifying:
data exchanged with the other tasks (input and output)
functionality of the task (what it has to do)
validity assumptions (e.g., admissible ranges)
performance requirements (priority, period, deadline, jitter)

Asynchronous communication mechanisms.

21

30/09/2014

Control view
visualbased
navigation
100ms

object
recognition

obstacle
avoidance
10ms

visual
tracking
feature
extraction

vehicle
control
5ms

20ms
motor
control

motor
control

motor
control

1ms

camera

pan

motor
control

1ms

tilt

US1

US2

mot_dx

mot_sx

Software View
periodic task

visualbased
navigation
object
recognition

buffer

obstacle
avoidance

vehicle
control

visual
tracking

feature
extraction
motor
control

camera

pan

tilt

US1

US2

mot_dx

mot_sx

22

30/09/2014

Software structure
OUTPUT

INPUT

task

resource

The operating system is responsible for providing

the proper mechanisms for a predictable interaction
between tasks and resources.

Real-Time System
It is a system in which the correctness depends
not only on the output values, but also on the time
at which results are produced.
RT System

x (t)

Environment
t

y (t+)
REAL means that system time must be synchronized
with the time flowing in the environment.

23

30/09/2014

RTOS responsibilities
A real-time operating system is responsible for:
Managing concurrency;
Activating periodic tasks at the beginning of each
period (time management);
Deciding the execution order of tasks (scheduling);
Solving possible timing conflicts during the access
of shared resources (mutual exclusion);
Manage the timely execution of asynchronous
events (interrupt handling).

Typical objection
It is not worth to invest in RT theory, because
computer speed is increasing exponentially, and
all timing constraints can eventually be handled.

Answer
Given an arbitrary computer speed, we must
always guarantee that timing constraints can be
met. Testing is NOT sufficient.

24

30/09/2014

Real-Time Fast
A real-time system is not a fast system.
Speed is always relative to a specific
environment.
Running faster is good, but does not
guarantee a correct behavior.

Speed vs. Predictability

The objective of a real-time system is to guarantee
the timing behavior of each individual task.
The objective of a fast system is to minimize the
average response time of a task set. But

Dont trust the average when you have to

guarantee individual performance

25

30/09/2014

Sources of non determinism

Architecture
cache, pipelining, interrupts, DMA

Operating system
scheduling, synchronization, communication

Language
lack of explicit support for time

Design methodologies
lack of analysis and verification techniques

Traditional (wrong) approach

In spite of this large application domain, most of
RT applications are designed using empirical
techniques:
assembly programming
timing through dedicated timers
control through driver programming
priority manipulation

26

30/09/2014

Disadvantages
1. Tedious
programming
which
depends on programmers ability

heavily

2. Difficult code understanding

Readability

1
efficiency

An efficient C program
int a[1817];
main(z,p,q,r)
{
for(p=80;q+p-80;p-=2*a[p])
for(z=9;z--;)
q=3&(r=time(0)+r*57)/7,q=q?q-1?
q-2?1-p%79?-1:0:p%79-77?
1:0:p<1659?79:0:p>158?-79:0,
q?!a[p+q*2]?a[p+=a[p+=q]=q]=q :0:0;
for(;q++-1817;)
printf(q%79?"%c":"%c\n"," "[!a[q-1]]);
}

27

30/09/2014

Disadvantages
3. Difficult software maintainability
Complex appl.s consists of millions lines of code
Code understanding takes more that re-writing
But re-writing is VERY expensive and bug prone

4. Difficult to verify timing constraints without

explicit support from the OS and the language

Implications
Such a way of programming RT applications
is very dangerous.
It may work in most situations, but the risk of
a failure is high.
When the system fails is very difficult to
understand why.

low reliability

28

30/09/2014

Other accidents due to SW

Task overrun during LEM lunar landing
First flight of the Space Shuttle (synch)
Ariane 5 (overflow)
Airbus 320 (cart task)
Airbus 320 (holding task)
Pathfinder (reset for timeout)

Lessons learned
Tests, although necessary, allow only
partial verification of systems behavior.

Predictability must be improved at the level of

the operating system.
The system must be designed to be fault-tolerant
and handle overload conditions.
Critical systems must be
pessimistic assumptions.

designed

under

29