27/09/2016
Course web site
Course homepage
http://retis.sssup.it/~giorgio/rts-MECS.html
Giorgio Buttazzo
To receive announcements
E-mail: [email protected]
https://didactive.sssup.it/didactive/
Scuola Superiore Sant’Anna
2
Lectures
Monday
Tuesday
Definition
Wednesday
Thursday
Friday
9:00
RTS
10:00
RTS
11:00
RTS
Real-Time Systems are
computing systems that must
perform computation within given
timing constraints.
12:00
13:00
14:00
RTS
15:00
RTS
They are typically embedded
in a larger system to control
its functions:
RTS
16:00
RTS
17:00
RTS
Controlled System
Sensors
Motors
18:00
Embedded
Computer
Real-Time Embedded Systems
Evolution of Embedded Systems
Computers everywhere
Embedded computing systems have grown
exponentially in several application domains:
Today, 98% of all processors in the planet are
embedded in other objects:
Number of
embedded
computers
consumer electronics
multimedia
automotive
robotics
avionics
0
1970
1980
1990
2000
2010
year
1
27/09/2016
Typical applications
Health Care
 avionics
 Tele-monitoring
 automotive
 Tele-rehabilitation
 robotics
 Assisted Living
 industrial automation
 Sport
 telecommunications
 multimedia systems
 consumer electronics
Increasing complexity
Steer by Wire
The price to be paid is a higher software complexity.
Related problems
Control
Unit
Sensor
Motor
Sensor

Difficult design

Less predictability

Less reliability
Motor
Novel solutions for:

Component-based software design

Analysis for guaranteeing predictability and safety

Testing
Software evolution in a car
ECU growth in a car
# ECUs
in a car
1010
100
109
80
108
# Lines of source code
in a car
107
60
106
40
105
104
20
103
102
0
1970
1980
1990
2000
2010
year
1980
1990
2000
2010
2020
2
27/09/2016
Software in a car
Comparing Software Complexity
Car software controls almost everything:
 Engine:
Lines of code
ignition, fuel pressure, water temperature,
valve control, gear control,
 Dashboard: engine status, message display, alarms
30 M
10 M
10 M
2M
 Diagnostic: failure signaling and prediction
 Safety:
100 M
100 M
1M
ABS, ESC, EAL, CBC, TCS
 Assistance: power steering, navigation, sleep sensors,
parking, night vision, collision detection
 Comfort:
100 K
50 K
fan control, heating, air conditioning, music,
active light control, noise control & cancellation,
regulations: steer/lights/sits/mirrors/glasses…
Complexity and bugs
Software reliability
When aircraft control depends on a program
with 100 million instructions, reliability is a
primary objective.
Software bugs increase with complexity:
bugs
10.000
108 instructions
1000
100
10
Lines of code
0
1K
10K
100 K
1M
10 M
Software reliability
Reliability does not only depend on the correctness of
single instructions, but also on when they are
executed:
controller
input
t
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
output
t+
 for each critical activity;
 for all possible combination of events.
A correct action executed too late can be useless or
even dangerous.
3
27/09/2016
Predictability vs. Efficiency
QoS management
High performance
Safety critical
predictability
efficiency
Allocated resources
digital tv
soft
What’s special in Embedded Systems?
firm
hard
FEATURES
REQUIREMENTS
Scarce resources (space, weight, time, memory, energy)
High efficiency in resource management
High concurrency and resource sharing (high task interference)
Temporal isolation to limit the interference
Interaction with the environment
(causing timing constraints)
High predictability in the response time
High variability on workload and resource demand
Adaptivity to handle overload situations
Criticality
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.
Control and implementation
Often, control and implementation are done by
different people that do not talk to each other:
x  Ax  Bu
if (b != 0) y = a/b;
else printf("error\n");
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:
A control example
A positive angle  requires a positive control action u
 has limited resources;
 >0
 <0
 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.
u>0
u<0
 >0
u>0
 <0
u<0
4
27/09/2016
A control task
task
{
float
float
float
A control task
control(float theta0, float k)
task
{
float
control gain
reference angle
error;
u;
theta;
control(float theta0, float k)
error, u, theta;
while (1) {
sensing
theta = read_sensor();

error = theta – theta0;
u = k * error;
computation
output(u);
actuation

theta = read_sensor();
error = theta – theta0;
u = k * error;
output(u);
wait_for_next_period();
while (1) {
u
}
}
u
sensing
actuation
computation
wait_for_next_period(); synchronization
task execution
}
task period
}
Traditional control view
Effect of computation times
Computation times introduce a non negligible delay:
Negligible delay and jitter:
i
t
u
i


wrong!
u>0
u>0
t
t
correct
u<0
wrong!
u<0
u<0

u<0

 >0
 <0
 <0
t
Actual situation
 <0
 >0
 <0
 <0
t
 <0
 Study software methodologies and algorithms
to increase predictability in computing systems.
i

 >0
Specific course objectives
Actual situation: variable delay and jitter:

t

u
u>0
 >0
time
t

u
correct
u>0
t
 We consider embeddded computing systems
consisting of several concurrent activities subject
to timing constratints.
correct
u<0
wrong!
 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.
u<0

 >0
 >0
t
 <0
5
27/09/2016
Course outline - 1
Specific course objectives
How to model a real-time system
1. Basic concepts and terminology
2. Sample applications
How to combine
control & programming
3. Problem identification
4. Modeling real-time activities
How to analyze timing properties
5. Deriving timing constraints
6. Worst-case reasoning
How to monitor real-time applications
7. Managing periodic tasks
8. Scheduling algorithms
How to program safety-critical code
9. Schedulability analysis
How to manage load variations
Course outline - 2
Course outline - 3
Programming real-time applications
10. Problems introduced by resource sharing
 Processes and threads in Linux
11. Resource access protocols
 Thread creation and activation
12. Estimating worst-case blocking times
 Linux schedulers
13. Handling asynchronous (aperiodic) tasks
 Time management
14. Handling execution overruns
 How implement periodic threads
15. Managing overload conditions
 How to structure RT applications
16. Real-time communication mechanisms
 How to use a graphics library
 How to simulate RT control systems
Teaching material
Final Exam
Course homepage
http://retis.sssup.it/~giorgio/rts-MECS.html
It consists of two parts:
1. Project work
Books:
2. Written test
Project: Developing a RT application under Linux, using
the Pthread library and the Allegro graphics library.
Test:
Third Edition
Springer, 2011
Third Edition
Pitagora, 2006
35
A number of questions and exercises on the
course program.
36
6
27/09/2016
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
actuators
microprocessor
Environment
sensors
communication
user
Control system components
other units
A typical control system
In every control application, we can distinguish 3
basic components:
 the system to be controlled
– it may include sensors and actuators
Controller
System
Environment
 the controller
– it sends signals to the system according to a
predetermined control objective
feedback
 the environment in which the system operates
Detailed block diagram
Software vision
System
Controller
actuators
OUTPUT
Environ.
feedback
internal state
sensor
sensor
INPUT
Sensory
processing
preprocessing
external state
Other activities
task
buffer
filtering, classification, data fusion, recognition, planning
7
27/09/2016
Types of control systems
Depending of the system-environment interactions,
we can distinguish 3 types of control systems:
 Monitoring Systems
Monitoring Systems
 Do not have actuators
 Do not modify the environment
Real-time system
sensors
– do not modify the environment
Data
processing
 Open-loop control systems
– loosely modify the environment
Display
..
.
Environment
sensors
 Closed-loop control systems
– tight interaction between perception and action
sensors
Examples: Environmental monitoring, surveillance systems,
air traffic control
Loosely-coupled control systems
Tightly-coupled control systems
Modify the environment, actions are mostly pre-programmed,
so loosely coupled with the current state of the environment:
Sensing and control are tightly coupled and occur at
different hierarchical level:
System
Controller
Controller
actuators
System
actuators
Environment
Data
processing
Planning
Planning
sensors
Examples: painting robots, assembly robots, sorting robots
high-level
command
Sensing
S2
low-level
acquisition
F2
F1
S1
A3
Control
A2
A1
sensors
flight control systems, military systems,
advanced robots, living beings
 The tight interaction with the environment
requires the system to react to events within
precise timing constraints.
F3
S3
Examples:
Data
processing
Implications
Hierarchical control
high-level
recognition
Environment
low-level
actuation
 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.
Environment
8
27/09/2016
A robot control example
Design requirements
Consider a mobile robot equipped with:
 Modularity: a subsystem must be developed without
knowing the details of other subsystems (team work).
 two actuated wheels;
 two proximity (US) sensors;
 Configurability: software must be adapted to different
situations (through the use of suitable parameters) without
changing the source code.
 a mobile (pan/tilt) camera;
 a wireless transceiver.
 Portability: minimize code changes when porting the system
to different hardware platforms.
Goal
 Follow a path based on visual feedback;
 Avoid obstacles;
 Send complete robot status every 20 ms.
 Predictability: allow the estimation of maximum delays.
 Efficiency: optimize the use of
(computation time, memory, energy).
Modularity
available
resources
Control view
Modularity can be achieved by:
visual‐based
navigation
 partitioning the system into a set of subsystems, each
managed by one or more computational tasks;
 defining precise interfaces between tasks, each specifying:
100 ms
object
recognition
obstacle
avoidance
10 ms
 data exchanged with the other tasks (input and output)
visual
tracking
 functionality of the task (what it has to do)
 validity assumptions (e.g., admissible ranges)
feature
extraction
 performance requirements (priority, period, deadline, jitter)
vehicle
control
5 ms
20 ms
motor
control
motor
control
motor
control
1 ms
 Asynchronous communication mechanisms.
camera
Software View
pan
motor
control
1 ms
tilt
US1
US2
mot_dx
mot_sx
Software structure
periodic task
buffer
OUTPUT
visual‐based
navigation
object
recognition
obstacle
avoidance
INPUT
vehicle
control
visual
tracking
task
feature
extraction
motor
control
camera
pan
tilt
US1
US2
mot_dx
mot_sx
resource
The operating system is responsible for providing
the proper mechanisms for a predictable interaction
between tasks and resources.
9
27/09/2016
RTOS responsibilities
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
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);
t
y (t+)
 Solving possible timing conflicts during the access
of shared resources (mutual exclusion);
REAL means that system time must be synchronized
with the time flowing in the environment.
 Manage the timely execution of asynchronous
events (interrupt handling).
Real-Time  Fast
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.
 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.
Answer
Given an arbitrary computer speed, we must
always guarantee that timing constraints can be
met. Testing is NOT sufficient.
Importance of system dynamics
Sensory
processing
Control
Commun.
Design
Analysis
Programming
Speed vs. Predictability
 The objective of a real-time system is to guarantee
the timing behavior of each individual task.
software
 The objective of a fast system is to minimize the
average response time of a task set. But …
Graphics
system
dynamics
Embedded
Computer
Don’t trust the average when you have to
guarantee individual performance
Controlled System
10
27/09/2016
Sources of non determinism
 Architecture
Traditional (wrong) approach
In spite of this large application domain, most of
RT applications are designed using empirical
techniques:
 cache, pipelining, interrupts, DMA
 Operating system
 scheduling, synchronization, communication
– assembly programming
– timing through dedicated timers
 Language
 lack of explicit support for time
– control through driver programming
– priority manipulation
 Design methodologies
 lack of analysis and verification techniques
Disadvantages
1. Tedious
programming
which
depends on programmer’s ability
Disadvantages
heavily

 Complex appl.s consists of millions lines of code
 Code understanding takes more that re-writing
2. Difficult code understanding
Readability
3. Difficult software maintainability
 But re-writing is VERY expensive and bug prone
1
efficiency
Implications
4. Difficult to verify timing constraints without
explicit support from the OS and the language
Lessons learned
 Such a way of programming RT applications
is very dangerous.
 Tests, although necessary, allow only
partial verification of system’s behavior.
 It may work in most situations, but the risk of
a failure is high.
 Predictability must be improved at the level of
the operating system.
 When the system fails is very difficult to
understand why.
 The system must be designed to be fault-tolerant
and handle overload conditions.
low reliability
 Critical systems must be
pessimistic assumptions.
designed
a
under
11