10/8/2019

Course web site

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

Giorgio Buttazzo
E-mail: [email protected]

Scuola Superiore Sant’Anna

Lectures About programming

Monday Tuesday Wednesday Thursday Friday
“Millions jobs will be lost in the coming decades due
8:30
to AI. Coding skill is one that looks futureproof”
9:30
- The Guardian
10:30
11:30 RTS
12:30 RTS
Nei prossimi decenni, l’Intelligenza Artificiale farà
14:30 RTS RTS
perdere milioni di posti di lavoro, ma l’abilità di
RTS RTS
15:30
programmare è una delle poche attività a prova di
16:30 RTS RTS
futuro.
17:30
18:30

Real-Time Systems Embedded Systems

Real-Time Systems are computing systems Real-time systems are typically embedded in a larger system to
that must perform computations within given  control its functions;
timing constraints.  manage the available resources;
 simplify the interaction with the user.
Hence, they must provide bounded response times to
tasks with bounded execution, in all possible scenarios. Real-Time Embedded Systems
 possible event arrivals Smart Object

They must be able to bound actuators

Ri Computing
inter-task interference System
Environment
sensors
Ri Response Time Bound
communication

Ri
user other units

1
 10/8/2019

Evolution of Embedded Systems Computers everywhere

Embedded computing systems have grown Today, 98% of all processors in the planet are
exponentially in several application domains: embedded in other objects:
Number of
embedded
computers consumer electronics

multimedia

automotive

robotics
avionics
0
1970 1980 1990 2000 2010 year

Typical applications Art & Entertainment

 avionics

 automotive

 robotics

 industrial automation Virtual reality Game simulators

 telecommunications

 multimedia systems

 consumer electronics
Animation Smart toys

Health Care Other applications

 Tele-monitoring intelligent transport systems

 Tele-rehabilitation
 Assisted Living
 Sport agriculture

civil protection
Smart buildings

2
 10/8/2019

Smart objects Smart objects

The number of such objects will increase in the future:

Electronic key GPS Localizer

Step counter Smart Tire Smart Shoe

Smart cork
Recording pen
Cardio pulse meter Watch computer Smart glasses

Inside body From Hardware to Software

We are experiencing a dematerialization process in
Computers will be embedded even in our body:
which many functions are converted into software.

Examples
heart ear eye brain
– Money
– Documents
– Books
– Music
– Pictures
– Movies
– Tickets
– Education

Why? The replication

Industriaprocess
There are many advantages dematerialization materialization
1. Software is more flexible than hardware

2. It can be quickly changed/adapted/updated

If information is preserved
3. It can be upgraded remotely at each step, the final copy
is functionally equivalent to
4. It can evolve into intelligent control algorithms
the original
5. It has no mass, so it can travel at the speed of light

6. It enables an efficient replication process transmission

encoding decoding

3
 10/8/2019

Increasing complexity Increasing complexity

The price to be paid is a higher software complexity. # functions
in a cell phone
Related problems 200
 Difficult design
80
 Less predictability
 Less reliability 60

40
Novel solutions for:
 Component-based software design 20
 Analysis for guaranteeing predictability and safety
0
 Testing 2010 year
1970 1980 1990 2000

ECU growth in a car Software evolution in a car

# Lines of source code
# ECUs in a car
in a car 1010
100 109

80 108
107
60 106
40 105
104
20
103
0 102
2010 year
1970 1980 1990 2000 1980 1990 2000 2010 2020

Steer by Wire Steer by Wire

Advantages

1. Placing the steering wheel in any position

Control
2. Record the driving style of the driver
Unit
Sensor 3. Develop self-parking functions
Motor Motor
Sensor 4. Autonomous driving

4
 10/8/2019

Software in a car Heterogeneous networks

Distributed architecture
Driver Steering
Environment sensors feedback wheel
(e.g. cameras) actuators sensors

ECU Assistance
System

Steering
actuators ECU ECU
Data Bus

Wheel angle
sensors Main Redundant
ECU ECU

Software in a car Comparing Software Complexity

Car software controls almost everything: Lines of code 100 M
100 M
 Engine: ignition, fuel pressure, water temperature, 30 M
valve control, gear control,
10 M
10 M
 Dashboard: engine status, message display, alarms
2M
 Diagnostic: failure signaling and prediction
1M
 Safety: ABS, ESC, EAL, CBC, TCS
 Assistance: power steering, navigation, sleep sensors, 100 K
parking, night vision, collision detection 50 K

 Comfort: fan control, heating, air conditioning, music,

active light control, noise control & cancellation,
regulations: steer/lights/sits/mirrors/glasses…

Complexity and bugs Software reliability

Software bugs increase with complexity: When aircraft control depends on a program
with 100 million instructions, reliability is a
primary objective.
bugs
10.000

1000 108 instructions

100

10
Lines of code
0
1K 10K 100 K 1M 10 M

5
 10/8/2019

Software reliability Real-Time Systems

Reliability does not only depend on the correctness of
single instructions, but also on when they are
Computing systems that must guarantee
executed:
bounded and predictable response times
input
controller are called real-time systems.
t

Predictability of response times must be guaranteed
output
 for each critical activity;
t+
 for all possible combination of events.
A correct action executed too late can be useless or
even dangerous.

Predictability vs. Efficiency What’s special in Embedded Systems?

QoS management High performance Safety critical
FEATURES REQUIREMENTS

efficiency predictability Scarce resources (space, weight, High efficiency in resource

time, memory, energy) management

High concurrency and resource Temporal isolation to limit

sharing (high task interference) the interference

Interaction with the environment High predictability in the

(causing timing constraints) response time
Allocated resources

digital tv High variability on workload and Adaptivity to handle

soft firm hard overload situations
resource demand
Criticality

Aim of the Course Main focus: predictable software

 Studying software methodologies for supporting Sensory

time critical computing systems. processing

Control Design
 We will not consider how to control a system,
Analysis software
but only how to provide a predictable software
support to control applications. Commun. Programming

Graphics
system
dynamics Embedded
Computer

Controlled System

6
 10/8/2019

Control and implementation Control and implementation

Often, control and implementation are done by
In reality, a computer:
different people that do not talk to each other:
 has limited resources;
x  Ax  Bu if (b != 0) y = a/b;
else printf("error\n");
 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
Control guys typically assume that computations take
improvement in performance and reliability.
zero time. This means assuming computers with
infinite resources and computational power.

A control example A control example

A positive angle  requires a positive control action u A negative angle  requires a negative control action u

 >0  <0

u>0 u<0

 >0 u>0  <0 u<0

A control task A control task

task control(float theta0, float k) task control(float theta0, float k)

{ control gain {
float error; float error, u, theta;
float u; reference angle
float theta; while (1) {
theta = read_sensor(); 
while (1) { error = theta – theta0; u
sensing
theta = read_sensor();  u = k * error;
output(u);
error = theta – theta0; computation wait_for_next_period();
u = k * error; }
u } sensing
output(u); actuation
computation actuation
wait_for_next_period(); synchronization task execution
}
} task period time

7
 10/8/2019

Traditional control view Effect of computation times

Negligible delay and jitter: Computation times introduce a non negligible delay:

i i
t t
  
u u>0 u
u>0 wrong!
u>0
t t
correct
u<0 wrong!
u<0 u<0
u<0
 

t t
 >0  >0  >0  >0
 <0  <0
 <0
 <0
 <0  <0

Actual situation Specific course objectives

Actual situation: variable delay and jitter:
 Study software methodologies and algorithms
to increase predictability in computing systems.
i
t
    We consider embeddded computing systems
u
correct consisting of several concurrent activities subject
u>0 to timing constratints.
t
correct
wrong!
u<0  We will see how to model and analyze a real-time
u<0
 application to predict worst-case response times
and verify its feasibility under a set of constraints.
t
 >0  >0

 <0

Specific course objectives Course outline - 1

How to model a real-time system
1. Basic concepts and terminology
How to combine 2. Sample applications
control & programming 3. Problem identification
4. Modeling real-time activities
How to analyze timing properties
5. Deriving timing constraints

How to monitor real-time applications 6. Worst-case reasoning

7. Managing periodic tasks
How to program safety-critical code 8. Scheduling algorithms
9. Schedulability analysis
How to manage load variations

8
 10/8/2019

Course outline - 2 Course outline - 3

10. Problems introduced by resource sharing Programming real-time applications

11. Resource access protocols  Processes and threads in Linux
 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
It consists of two parts:
http://retis.sssup.it/~giorgio/rts-MECS.html
1. Project work
Books:
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
Third Edition Third Edition course program.
Springer, 2011 Pitagora, 2006
51 52

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
micro- Environment
processor sensors

communication

user other units

9
 10/8/2019

Control system components 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 Environ-
Controller System
ment
 the controller
– it sends signals to the system according to a feedback
predetermined control objective

 the environment in which the system operates

Detailed block diagram Software vision

System

Controller actuators
OUTPUT
Environ.
sensor sensor
feedback internal state
INPUT

Sensory pre- external state

processing processing

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

Types of control systems Monitoring Systems

Depending of the system-environment interactions,  Do not have actuators
we can distinguish 3 types of control systems:  Do not modify the environment

 Monitoring Systems Real-time system sensors

– do not modify the environment
Data Environ-
sensors
 Open-loop control systems processing
.. ment
.
– loosely modify the environment
Display
sensors
 Closed-loop control systems
– tight interaction between perception and action
Examples: Environmental monitoring, surveillance systems,
air traffic control

10
 10/8/2019

Loosely-coupled control systems Sorting

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

ROBOT
camera
Controller System actuators
sensing control
Environment

Data
Planning sensors
processing

Examples: painting robots, assembly robots, sorting robots

Tightly-coupled control systems Hierarchical control

Sensing and control are tightly coupled and occur at high-level high-level
recognition command
different hierarchical level:
F3

Controller System actuators S3 A3

F2
Sensing Control
Environment
S2 A2
F1
Data
Planning sensors
processing low-level low-level
S1 A1
acquisition actuation
Examples: flight control systems, military systems, Environment
advanced robots, living beings

Implications A robot control example

 The tight interaction with the environment Consider a mobile robot equipped with:
requires the system to react to events within  two actuated wheels;
precise timing constraints.  two proximity (US) sensors;
 Timing constraints are imposed by the  a mobile (pan/tilt) camera;
performance requirements and the dynamics of  a wireless transceiver.
the system to be controlled.

The operating system must be able to Goal

execute tasks within timing constraints.  Follow a path based on visual feedback;
 Avoid obstacles;
 Send complete robot status every 20 ms.

11
 10/8/2019

Design requirements Modularity

 Modularity: a subsystem must be developed without Modularity can be achieved by:
knowing the details of other subsystems (team work).
 partitioning the system into a set of subsystems, each
 Configurability: software must be adapted to different managed by one or more computational tasks;
situations (through the use of suitable parameters) without
 defining precise interfaces between tasks, each specifying:
changing the source code.
 data exchanged with the other tasks (input and output)
 Portability: minimize code changes when porting the system  functionality of the task (what it has to do)
to different hardware platforms.
 validity assumptions (e.g., admissible ranges)
 Predictability: allow the estimation of maximum delays.  performance requirements (priority, period, deadline, jitter)

 Efficiency: optimize the use of available resources  Asynchronous communication mechanisms.

(computation time, memory, energy).

Control view Software View

periodic task buffer
visual‐based
navigation
visual‐based obstacle
100 ms obstacle navigation avoidance
object object
avoidance recognition
recognition
10 ms vehicle
visual
visual tracking control
vehicle
tracking control
20 ms 5 ms
feature feature
motor motor motor motor extraction
extraction control control control control
1 ms 1 ms motor
control

camera pan tilt US1 US2 mot_dx mot_sx camera pan tilt US1 US2 mot_dx mot_sx

Software structure Real-Time System

It is a system in which the correctness depends
OUTPUT not only on the output values, but also on the time
at which results are produced.

INPUT x (t)
RT System Environment
t t
task resource y (t+)

The operating system is responsible for providing REAL means that system time must be synchronized
the proper mechanisms for a predictable interaction with the time flowing in the environment.
between tasks and resources.

12
 10/8/2019

RTOS responsibilities Typical objection

A real-time operating system is responsible for:
It is not worth to invest in RT theory, because
 Managing concurrency; computer speed is increasing exponentially, and
 Activating periodic tasks at the beginning of each all timing constraints can eventually be handled.
period (time management);
 Deciding the execution order of tasks (scheduling);
Answer
 Solving possible timing conflicts during the access Given an arbitrary computer speed, we must
of shared resources (mutual exclusion);
always guarantee that timing constraints can be
 Manage the timely execution of asynchronous met. Testing is NOT sufficient.
events (interrupt handling).

Real-Time  Fast Cyber-Physical Systems

Most real-time systems are cyber-physical systems
 A real-time system is not a fast system.
Sensory
 Speed is always relative to a specific processing
environment. Control Design
Analysis software
Commun. Programming
 Running faster is good, but does not
guarantee a correct behavior. Graphics
system
dynamics Embedded
Computer

Controlled System

Fast vs. Predictable Sources of non determinism

Fast  Predictable  Architecture
Average  Worst-case  cache, pipelining, interrupts, DMA

 Operating system
minimize the guarantee that the  scheduling, synchronization, communication
average response time worst-case response time
of a task set of each individual task does  Language
not exceed a given bound  lack of explicit support for time

Don’t trust the average  Design methodologies

when you have to guarantee  lack of analysis and verification techniques
individual performance

13
 10/8/2019

Traditional (wrong) approach Disadvantages

In spite of this large application domain, most of 1. Tedious programming which heavily
RT applications are designed using empirical depends on programmer’s ability
techniques:
– assembly programming
2. Difficult code understanding

– timing through dedicated timers

1
– control through driver programming Readability 
efficiency
– priority manipulation

Disadvantages Implications

3. Difficult software maintainability  Such a way of programming RT applications

is very dangerous.
 Complex appl.s consists of millions lines of code
 Code understanding takes more that re-writing  It may work in most situations, but the risk of
 But re-writing is VERY expensive and bug prone a failure is high.

4. Difficult to verify timing constraints without  When the system fails is very difficult to
explicit support from the OS and the language understand why.

low reliability

Lessons learned
 Tests, although necessary, allow only a
partial verification of system’s behavior.
Let’s studying
 Predictability must be improved at the level of
the operating system.
real-time systems
 The system must be designed to be fault-tolerant and fight against Murphy’s Laws
and handle overload conditions.

 Critical systems must be designed under

pessimistic assumptions.

14