Course web site Course homepage - - PDF document

9/29/2020 1

Giorgio Buttazzo

E-mail: buttazzo@sssup.it

Scuola Superiore Sant’Anna

2

Course web site

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

Lectures

Monday Tuesday Wednesday Thursday Friday RTS RTS RTS RTS RTS

8:30 9:30 10:30 11:30 12:30 14:00 15:00 16:00 17:00 18:00

3

RTS RTS RTS

• ptional

REGULAR

14:30 15:30 16:30 17:30

About programming

“Millions jobs will be lost in the coming decades due to AI. Coding skill is one that looks futureproof”

• The Guardian

Nei prossimi decenni, l’Intelligenza Artificiale farà perdere milioni di posti di lavoro, ma l’abilità di programmare è una delle poche attività a prova di futuro.

Real-Time Systems

Real-Time Systems are computing systems that must perform computations within given timing constraints. Hence, they must provide bounded response times to tasks with bounded execution, in all possible scenarios. Hence, they must provide bounded response times to tasks with bounded execution, in all possible scenarios.

 possible event arrivals

Ri Ri Ri

Response Time Bound

They must be able to bound inter-task interference They must be able to bound inter-task interference

Real-time systems are typically embedded in a larger system to

• control its functions;
• manage the available resources;
• simplify the interaction with the user.

Real-Time Embedded Systems

Environment

actuators sensors

Computing System

communication

user

• ther units

Smart Object

Embedded Systems

9/29/2020 2 Evolution of Embedded Systems

Embedded computing systems have grown exponentially in several application domains:

1970 1990 2000 2010

Number of embedded computers

1980 year

avionics robotics automotive consumer electronics multimedia

Computers everywhere

Today, 98% of all processors in the planet are embedded in other objects:

Typical applications

• avionics
• automotive
• robotics
• industrial automation
• telecommunications
• multimedia systems
• consumer electronics

Art & Entertainment

Game simulators Virtual reality Animation Smart toys

Health Care

• Tele-monitoring
• Tele-rehabilitation
• Assisted Living
• Sport

Smart buildings

intelligent transport systems agriculture

civil protection

Other applications

9/29/2020 3 Smart objects

Electronic key Recording pen GPS Localizer Cardio pulse meter Step counter Watch computer

The number of such objects will increase in the future:

Smart objects

Smart Tire Smart Shoe Smart glasses Smart cork

Computers will be embedded even in our body:

Inside body

heart ear eye brain

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

Why?

• 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
• 6. It enables an efficient replication process

There are many advantages

I ndustria

The replication process

dematerialization encoding decoding transmission materialization If information is preserved at each step, the final copy is functionally equivalent to the original

9/29/2020 4 Increasing complexity

Related problems

• Difficult design
• Less predictability
• Less reliability

The price to be paid is a higher software complexity.

Novel solutions for:

• Component-based software design
• Analysis for guaranteeing predictability and safety
• Testing

Increasing complexity

1970 1990 2000 2010

20 40 60 80 200

# functions in a cell phone 1980 year

ECU growth in a car

1970 1990 2000 2010

20 40 60 80 100

# ECUs in a car 1980 year 1980 1990 2000 2010 2020

102 103 104 105 106 107 108 109 1010

Software evolution in a car

# Lines of source code in a car Sensor Motor Sensor Motor Control Unit

Steer by Wire

• 1. Placing the steering wheel in any position
• 2. Record the driving style of the driver
• 3. Develop self-parking functions
• 4. Autonomous driving

Advantages

Steer by Wire

9/29/2020 5 Software in a car

Steering actuators Wheel angle sensors

ECU ECU

Environment sensors (e.g. cameras)

ECU

Assistance System Data Bus Driver feedback actuators Steering wheel sensors Main ECU Redundant ECU

Distributed architecture

Heterogeneous networks 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, heating, air conditioning, music, active light control, noise control & cancellation, regulations: steer/lights/sits/mirrors/glasses…

Comparing Software Complexity

100 K 1 M 10 M

Lines of code

100 M 50 K 2 M 10 M 30 M 100 M

Complexity and bugs

Software bugs increase with complexity:

1 K 100 K 1 M 10 M

10 100 1000 10.000

10K Lines of code

bugs

When aircraft control depends on a program with 100 million instructions, reliability is a primary objective. 108 instructions

Software reliability

9/29/2020 6

Reliability does not only depend on the correctness of single instructions, but also

• n

when they are executed: controller

• utput

input t t +  

A correct action executed too late can be useless or even dangerous.

Software reliability 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.

efficiency predictability

Predictability vs. Efficiency

Allocated resources QoS management High performance Safety critical digital tv

soft firm hard Criticality

What’s special in Embedded Systems?

FEATURES Scarce resources (space, weight, time, memory, energy) High concurrency and resource sharing (high task interference) Interaction with the environment (causing timing constraints) High variability on workload and resource demand REQUIREMENTS High efficiency in resource management Temporal isolation to limit the interference High predictability in the response time Adaptivity to handle

• verload situations

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

Design Analysis Programming Design Analysis Programming

Sensory processing Control Commun. software Graphics

Embedded Computer Controlled System

system dynamics

9/29/2020 7

Often, control and implementation are done by different people that do not talk to each other: Control guys typically assume that computations take zero time. This means assuming computers with infinite resources and computational power.

Bu Ax x   

if (b != 0) y = a/b; else printf("error\n");

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. Modeling such factors and taking them into account in the design phase allows a significant improvement in performance and reliability.

Control and implementation

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

A control example

A positive angle  requires a positive control action u

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

A control example

A negative angle  requires a negative control action u



task control(float theta0, float k) { float error; float u; float theta; while (1) { theta = read_sensor(); error = theta – theta0; u = k * error;

• utput(u);

wait_for_next_period(); } }

sensing

u

actuation computation synchronization reference angle control gain

A control task



task control(float theta0, float k) { float error, u, theta; while (1) { theta = read_sensor(); error = theta – theta0; u = k * error;

• utput(u);

wait_for_next_period(); } }

u

task execution sensing computation actuation time

A control task

task period

9/29/2020 8

 u t t t

i

Negligible delay and jitter:

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

Traditional control view

43

 u t t t

i

Computation times introduce a non negligible delay:

 wrong! wrong!  < 0  > 0  < 0    > 0 correct  < 0  < 0 u > 0 u < 0 u < 0

Effect of computation times

44

 u t t t

i

Actual situation: variable delay and jitter:

   wrong!  > 0 u < 0  < 0 u < 0 u > 0  > 0 correct correct

Actual situation

45

• 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.

Specific course objectives Specific course objectives

How to model a real-time system How to program safety-critical code How to monitor real-time applications How to analyze timing properties How to manage load variations How to combine control & programming

Course outline - 1

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

9/29/2020 9

• 10. Problems introduced by resource sharing
• 11. Resource access protocols
• 12. Estimating worst-case blocking times
• 13. Handling asynchronous (aperiodic) tasks
• 14. Handling execution overruns
• 15. Managing overload conditions
• 16. Real-time communication mechanisms

Course outline - 2

Programming real-time applications

• Processes and threads in Linux
• Thread creation and activation
• Linux schedulers
• Time management
• How implement periodic threads
• How to structure RT applications
• How to use a graphics library
• How to simulate RT control systems

Course outline - 3

51

Teaching material

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

Third Edition Pitagora, 2006 Third Edition Pitagora, 2006 Third Edition Springer, 2011 Third Edition Springer, 2011

52

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.

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.

Environment actuators sensors

micro- processor

communication

user

• ther units

Object

9/29/2020 10 Control system 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 In every control application, we can distinguish 3 basic components:

A typical control system

Environ- ment System Controller

feedback

Detailed block diagram

Other activities filtering, classification, data fusion, recognition, planning Environ. System Controller

Sensory processing

internal state external state

pre- processing

feedback

actuators sensor sensor

Software vision

INPUT OUTPUT task buffer

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

Depending of the system-environment interactions, we can distinguish 3 types of control systems:

• Do not have actuators
• Do not modify the environment

Monitoring Systems

Examples: Environmental monitoring, surveillance systems, air traffic control Environ- ment

Data processing

sensors sensors sensors

. . .

Real-time system

Display

9/29/2020 11

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

Loosely-coupled control systems

System Controller

actuators

sensors

Data processing Planning

Environment Examples: painting robots, assembly robots, sorting robots sensing control

camera ROBOT

Sorting

Environment System Controller

actuators

sensors

Data processing Planning

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

Tightly-coupled control systems

Examples: flight control systems, military systems, advanced robots, living beings

Hierarchical control

Environment

S1 S2 S3 A1 A2 A3 F1 F2 F3

Sensing Control

high-level command high-level recognition low-level actuation low-level acquisition

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.

Goal

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

9/29/2020 12 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:
• ptimize

the use

• f

available resources (computation time, memory, energy).

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.

Control view

mot_dx mot_sx pan tilt camera US2 US1 visual tracking

• bstacle

avoidance vehicle control visual‐based navigation

1 ms 1 ms 5 ms 10 ms 20 ms 100 ms

feature extraction

• bject

recognition

motor control motor control motor control motor control

Software View

mot_dx mot_sx pan tilt camera US2 US1

visual tracking

• bstacle

avoidance vehicle control visual‐based navigation feature extraction

• bject

recognition motor control

periodic task buffer

Software structure

INPUT OUTPUT task resource

The operating system is responsible for providing the proper mechanisms for a predictable interaction between tasks and resources. The operating system is responsible for providing the proper mechanisms for a predictable interaction between tasks and resources. Environment RT System y x(t) (t+)

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. t t

REAL means that system time must be synchronized with the time flowing in the environment.

9/29/2020 13 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
• f shared resources (mutual exclusion);
• Manage the timely execution of asynchronous

events (interrupt handling).

Typical objection

Answer

Given an arbitrary computer speed, we must always guarantee that timing constraints can be

• met. Testing is NOT sufficient.

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

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.

Cyber-Physical Systems

Design Analysis Programming Design Analysis Programming

Sensory processing Control Commun.

software

Graphics

Embedded Computer Controlled System

system dynamics

Most real-time systems are cyber-physical systems Most real-time systems are cyber-physical systems

Fast vs. Predictable

Don’t trust the average when you have to guarantee individual performance Don’t trust the average when you have to guarantee individual performance Fast  Predictable Average  Worst-case minimize the average response time

• f a task set

guarantee that the worst-case response time

• f each individual task does

not exceed a given bound

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

9/29/2020 14 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

Disadvantages

1. Tedious programming which heavily depends on programmer’s ability 2. Difficult code understanding

Readability  1 efficiency

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

Lessons learned

• Tests,

although necessary, allow

• nly

a partial verification of system’s 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 designed under pessimistic assumptions.

Let’s studying real-time systems

and fight against Murphy’s Laws