29
30/09/2014 1 Giorgio Buttazzo E-mail: [email protected] Scuola Superiore Sant’Anna 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: Real-Time Embedded Systems Embedded Computer Controlled System Sensors Motors

w1-intro-2p

Embed Size (px)

DESCRIPTION

tiempo real

Citation preview

Page 1: w1-intro-2p

30/09/2014

1

Giorgio ButtazzoE-mail: [email protected]

Scuola Superiore Sant’Anna

Definition

Real-Time Systems are computing systems that must perform computation within given timing constraints.

They are typically embeddedin a larger system to control its functions:

Real-Time Embedded Systems

EmbeddedComputer

Controlled System

Sensors

Motors

Page 2: w1-intro-2p

30/09/2014

2

Evolution of Embedded Systems

Embedded computing systems have grownexponentially in several application domains:

1970 1990 2000 20100

Number ofembeddedcomputers

1980 year

avionics

robotics

automotive

consumer electronics

multimedia

Typical applications

avionics

automotive

robotics

industrial automation

telecommunications

multimedia systems

consumer electronics

Page 3: w1-intro-2p

30/09/2014

3

Health Care

Tele-monitoring

Tele-rehabilitation

Assisted Living

Sport

From Hardware to Software

We are experiencing a dematerialization process inwhich many functions are converted into software.

Examples– Money

– Documents

– Books

– Music

– Pictures

– Movies

– Tickets

– Education

Page 4: w1-intro-2p

30/09/2014

4

Sensor

MotorSensorMotor

ControlUnit

Steer by Wire

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

There are many advantages

Page 5: w1-intro-2p

30/09/2014

5

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 20100

20

40

60

80

200

# functionsin a cell phone

1980year

Page 6: w1-intro-2p

30/09/2014

6

ECU growth in a car

1970 1990 2000 20100

20

40

60

80

100

# ECUsin a car

1980year

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…

Page 7: w1-intro-2p

30/09/2014

7

Comparing Software Complexity

100 K

1 M

10 M

Lines of code100 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 M0

10

100

1000

10.000

10K

Lines of code

bugs

Page 8: w1-intro-2p

30/09/2014

8

Reliability does not only depend on the correctness ofsingle instructions, but also on when they areexecuted:

controller

output

input

t

t +

A correct action executed too late can be useless oreven dangerous.

Software reliability

Real-Time Systems

Computing systems that must guaranteebounded and predictable response timesare called real-time systems.

Predictability of response times must be guaranteed

for each critical activity;

for all possible combination of events.

Page 9: w1-intro-2p

30/09/2014

9

efficiency predictability

Predictability vs. Efficiency

Allocated resources

QoS management High performance Safety critical

digital tvsoft 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 overload situations

Page 10: w1-intro-2p

30/09/2014

10

Aim of the Course

Studying software methodologies for supportingtime critical computing systems.

We will not consider how to control a system,but only how to provide a predictable softwaresupport to control applications.

Main focus: predictable software

DesignAnalysis

Programming

Sensoryprocessing

Control

Commun.

software

Graphics

EmbeddedComputer

Controlled System

systemdynamics

Cyber-Physical Systems

Page 11: w1-intro-2p

30/09/2014

11

Control and implementation

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

Control guys typically assume a computer with infiniteresources and computational power. In some case,computation is modeled by a fixed delay .

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 accountin the design phase allows a significantimprovement in performance and reliability.

Control and implementation

Page 12: w1-intro-2p

30/09/2014

12

Specific objectives

Study software methodologies and algorithmsto increase predictability in computing systems.

We consider embeddded computing systemsconsisting of several concurrent activities subjectto timing constratints.

We will see how to model and analyze a real-timeapplication to predict worst-case response timesand 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

Page 13: w1-intro-2p

30/09/2014

13

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 - 2

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

Course outline - 3

Page 14: w1-intro-2p

30/09/2014

14

27

Teaching material

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

Books:

Third EditionPitagora, 2006Third EditionPitagora, 2006

Third EditionSpringer, 2011Third EditionSpringer, 2011

28

Final Exam

It consists of two parts:

1. Project work

2. Written test

Project: Developing a RT application under Linux, usingthe Pthread library and the Allegro graphics library.

Test: A number of questions and exercises on thecourse program.

Page 15: w1-intro-2p

30/09/2014

15

Embedded systems

They are computing systems hidden in an object to controlits functions, enhance its performance, manage the availableresources and simplify the interaction with the user.

Environmentactuators

sensors

micro-processor

communication

user other units

Object

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 3basic components:

Page 16: w1-intro-2p

30/09/2014

16

A typical control system

Environ-ment

SystemController

feedback

Detailed block diagram

Other activities

filtering, classification, data fusion, recognition, planning

Environ.

System

Controller

Sensoryprocessing

internal state

external statepre-processing

feedback

actuators

sensor sensor

Page 17: w1-intro-2p

30/09/2014

17

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:

Page 18: w1-intro-2p

30/09/2014

18

Do not have actuators Do not modify the environment

Monitoring Systems

Examples: Environmental monitoring, surveillance systems,air traffic control

Environ-ment

Dataprocessing

sensors

sensors

sensors

...

Real-time system

Display

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

Loosely-coupled control systems

SystemController actuators

sensorsData

processingPlanning

Environment

Examples: painting robots, assembly robots, sorting robots

Page 19: w1-intro-2p

30/09/2014

19

Environment

SystemController actuators

sensorsData

processingPlanning

Sensing and control are tightly coupled and occur atdifferent 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-levelcommand

high-levelrecognition

low-levelactuation

low-levelacquisition

Page 20: w1-intro-2p

30/09/2014

20

Implications

The tight interaction with the environmentrequires the system to react to events withinprecise timing constraints.

Timing constraints are imposed by theperformance requirements and the dynamics ofthe system to be controlled.

The operating system must be able toexecute 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.

Page 21: w1-intro-2p

30/09/2014

21

Design requirements

Modularity: a subsystem must be developed withoutknowing the details of other subsystems (team work).

Configurability: software must be adapted to differentsituations (through the use of suitable parameters) withoutchanging the source code.

Portability: minimize code changes when porting the systemto different hardware platforms.

Predictability: allow the estimation of maximum delays.

Efficiency: optimize the use of available resources(computation time, memory, energy).

Modularity

Modularity can be achieved by:

partitioning the system into a set of subsystems, eachmanaged 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.

Page 22: w1-intro-2p

30/09/2014

22

Control view

mot_dx mot_sxpan tiltcamera US2US1

visualtracking

obstacleavoidance

vehiclecontrol

visual‐basednavigation

1 ms1 ms

5 ms

10 ms

20 ms

100 ms

featureextraction

objectrecognition

motorcontrol

motorcontrol

motorcontrol

motorcontrol

Software View

mot_dx mot_sxpan tiltcamera US2US1

visualtracking

obstacleavoidance

vehiclecontrol

visual‐basednavigation

featureextraction

objectrecognition

motorcontrol

periodic task buffer

Page 23: w1-intro-2p

30/09/2014

23

Software structure

INPUT

OUTPUT

task resource

The operating system is responsible for providingthe proper mechanisms for a predictable interactionbetween tasks and resources.

EnvironmentRT System

y

x (t)

(t+)

Real-Time System

It is a system in which the correctness dependsnot only on the output values, but also on the timeat which results are produced.

tt

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

Page 24: w1-intro-2p

30/09/2014

24

RTOS responsibilities

A real-time operating system is responsible for:

Managing concurrency;

Activating periodic tasks at the beginning of eachperiod (time management);

Deciding the execution order of tasks (scheduling);

Solving possible timing conflicts during the accessof shared resources (mutual exclusion);

Manage the timely execution of asynchronousevents (interrupt handling).

Typical objection

AnswerGiven an arbitrary computer speed, we mustalways guarantee that timing constraints can bemet. Testing is NOT sufficient.

It is not worth to invest in RT theory, becausecomputer speed is increasing exponentially, andall timing constraints can eventually be handled.

Page 25: w1-intro-2p

30/09/2014

25

Real-Time Fast

A real-time system is not a fast system.

Speed is always relative to a specificenvironment.

Running faster is good, but does notguarantee a correct behavior.

Speed vs. Predictability

The objective of a real-time system is to guaranteethe timing behavior of each individual task.

The objective of a fast system is to minimize theaverage response time of a task set. But …

Don’t trust the average when you have toguarantee individual performance

Page 26: w1-intro-2p

30/09/2014

26

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 ofRT applications are designed using empiricaltechniques:

– assembly programming

– timing through dedicated timers

– control through driver programming

– priority manipulation

Page 27: w1-intro-2p

30/09/2014

27

Disadvantages

1. Tedious programming which heavilydepends on programmer’s ability

2. Difficult code understanding

Readability 1

efficiency

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]]);

}

An efficient C program

Page 28: w1-intro-2p

30/09/2014

28

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 withoutexplicit support from the OS and the language

Implications

Such a way of programming RT applicationsis very dangerous.

It may work in most situations, but the risk ofa failure is high.

When the system fails is very difficult tounderstand why.

low reliability

Page 29: w1-intro-2p

30/09/2014

29

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 apartial verification of system’s behavior.

Predictability must be improved at the level ofthe operating system.

The system must be designed to be fault-tolerantand handle overload conditions.

Critical systems must be designed underpessimistic assumptions.