Embedded Real Time Systems -...

Embedded Real Time Systems

Prof. Davide Brugali

Università degli Studi di Bergamo

Embedded Real Time Systems

Embedded systems

A real-time computer system is a computer system in which the correctness

of the system behavior depends not only on the logical results of the

computations, but also on the physical instant at which these results are

produced.

A real-time computer system is always part of a larger system–this larger

system is called a real-time system.

A real-time system changes its state as a function of physical time, e.g., a

chemical reaction continues to change its state even after its controlling

computer system has stopped.

Embedded systems

They are computing systems hidden in an object (e.g. a car) to control

its functions, enhance its performance, manage the available resources

and simplify the interaction with the user.

They monitor and control their environment through sensors and

actuators: Sensors: Collect data from the system environment

Actuators: Change (in some way) the system's environment 3

Embedded

computer

Actua tor Actua tor Actua tor Actua tor

Sensor Sensor Sensor Sensor Sensor Sensor

Correctness of Embedded Systems

Correctness

Response Time and Deadline

Real Time Systems

Segway

Online Trading

Controller design and implementation

Controller design and implementation

What is special in ERTS

What is the purpose of concurrency?

• To better exploit the processor

10 -7

10 -6

10 -5

10 -4

10 -3

10 -2

10 -1

10 2

10 1

10 -8

10 -9

Res

ponse

tim

e in

sec

onds

10 0 human tape

floppy

CD

memory

processor

UNIBG - Embedded Real Time Systems - Brugali

What is the purpose of concurrency?

CPU I/O Device

Initiate I/O

Operation Process I/O

Request

Signal Completion

Interrupt I/O

Routine

I/O Finished Continue with

Outstanding Requests

UNIBG - Embedded Real Time Systems - Brugali

idle

idle

What is the purpose of concurrency? • To model parallelism in the real world

• The alternative is to use sequential programming techniques

• The programmer must implement the application in such a way that the various activities are carried out in a predefined sequence

UNIBG - Embedded Real Time Systems - Brugali

16

CRUISE CONTROL Regulate the speed of a car by adjusting the throttle:

Input by the driver sets a speed and car maintains it.

Measures the speed through device connected to the motor shaft

Disturbances: road surface and slope, wind

Real-Time Embedded control

Real-Time Embedded control The responsiveness of the system (Car) can be measured by its rise

time R.

R is the time it takes to get close to its final state after the input

changes.

A good rule of thumb is the ratio R/T of rise time to sampling period is

from 10 to 20.

The faster a system respond to changes, the shorter the sampling

period is.

17

Speed

Controller Actuator Car

Sensor

+ + +

-

+

+

PERIODICALLY T

R Road slope, surface

Actual

speed

SPORADICALLY

Desired

speed

Real-Time Embedded control

18

Speed

Controller Actuator Car

Sensor

+ + +

-

+

+

PERIODICALLY

Set timer to interrupt periodically with Period T;

at each interrupt, do;

read data from Sensor;

compute control output u;

write command to Actuator;

end do;

T

Road slope, surface

Actual

speed

SPORADICALLY

Desired

speed

R

Real-Time Embedded control

19

T

read comp write

CPU

Speed

Controller Actuator Car

Sensor

+ + +

-

+

+

PERIODICALLY T

Road slope, surface

Actual

speed

SPORADICALLY

Desired

speed

R

Real-Time Embedded control

Embedded PC

with OS Microcontroller

without OS

Real Time

Software

Speed

Controller Actuator Car

Sensor

+ + +

-

+

+

PERIODICALLY T

Road slope, surface

Actual

speed

SPORADICALLY

Desired

speed

R

Real-Time Embedded control

21

CRUISE CONTROL WITH OBSTACLE DETECTION Regulate the speed of a car by adjusting the throttle:

Input by the driver sets a speed and car maintains it.

Measures the speed through device connected to the motor shaft

Disturbances: road surface and slope, wind

Automatically regulates the speed according to the distance to the preceding car

Min distance

Concurrent Real-Time Embedded control

22

Speed

Controller Actuator Car

Sensor

+ + +

-

+

+ Desired

speed

Actual

speed

Distance

Monitor Environment

Obstacle distance

PERIODICALLY

PERIODICALLY

Sensor

T1

Road slope, surface

T2

T1

T2 CPU {

communication

Distributed Real-Time Embedded control

23

Speed

Controller Actuator Car

Sensor

+ + +

-

+

+ Desired

speed Actual

speed

Distance

Monitor Environment

Obstacle distance

PERIODICALLY

PERIODICALLY

Sensor

T1

T2

T1

Network

T2

CPU 1

CPU 2

Network

Road slope, surface

Concurrent Real-time Applications

Real-time

Operating System

Hardware

Real-time Application

Task

1

Task

2 ...

Hardware

Real-time Application

Interrupt

Handler

1

Interrupt

Handler

2

...

RT-Operating System

Scheduler

NO

RT-Operating System

Cyclic Executive &

Interrupt Handlers

24

Distributed Real-time Applications

Real-time

Operating System

Hardware

Real-time Application

Task

1

Task

2 ...

Hardware

Real-time Application

Interrupt

Handler

1

Interrupt

Handler

2

...

CAN

Transceiver

25

Distributed Real-time Applications

Real-time

Operating System

Hardware

Real-time Application

Task

1

Task

2 ...

Middleware

Real-time

Operating System

Hardware

Real-time Application

Task

1

Task

2 ...

Middleware

Ethernet / Ethercat

Data / Events

26

27

Need for Special Network Technologies

General-purpose networks, such as Ethernet, exhibit random and nondeterministic behaviour due to the conflict arbitration methods used (e.g., CSMA/CD)

Results in nondeterministic delays, including arbitrarily long delays in

the worst-case

Results in packet dropping during periods of heavy network activity

Fieldbus, used in process and factory automation

PROFIBUS, used in factory and process automation

CANBUS, used in automotive

EtherCAT, Ethernet for Control Automation Technology

Classification of RT Systems

Slides based on the book “Real-Time Systems: Design Principles

for Distributed Embedded Applications”, by H. Kopetz

Hard RT System versus Soft RT System

29

The design of a hard real-time system, which must produce the

results at the correct instant, is fundamentally different from the

design of a soft-real time or an on-line system, such as a

transaction processing system.

Hard RT System versus Soft RT System

Hard RT System versus Soft RT System

Hard RT System versus Soft RT System

Fail-safe versus Fail-Operational For some hard real-time systems one or more safe states which can be reached

in case of a system failure, can be identified. Consider the example of a railway

signaling system. In case a failure is detected, it is possible to stop all the trains

and to set all the signals to red to avoid a catastrophe. If such a safe state can

be identified and quickly reached upon the occurrence of a failure, then we call

the system fail-safe.

Fail-safeness is a characteristic of the controlled object, not the computer

system. In fail-safe applications the computer system must have a high error-

detection coverage, i.e., the probability that an error is detected, provided it has

occurred, must be close to one.

There are, however, applications where a safe state cannot be identified, e.g., a

flight control system aboard an airplane. In such an application the computer

system must provide a minimal level of service to avoid a catastrophe even in

the case of a failure.

This is why these applications are called fail-operational.

Guaranteed Response Paradigm Guaranteed response systems are based on the principle of resource adequacy,

i.e., there are enough computing resources available to handle the specified

peak load and the fault scenario.

Many non safety-critical real-time system designs are based on the principle of

resource inadequacy. It is assumed that the provision of sufficient resources to

handle every possible situation is not economically viable, and that a dynamic

resource allocation strategy based on resource sharing and probabilistic

arguments about the expected load and fault scenarios is acceptable.

Hard real-time systems must be designed according to the guaranteed response

paradigm that requires the availability of adequate resources.

Event-Triggered versus Time-Triggered

• In event-triggered systems, all processing activities are driven by some event in the environment

• The computer system receives the event via an I/O interrupt

• In time-triggered systems, all processing activities are initiated at periodic intervals

• There is a single interrupt associated with a clock to pace the system

• The occurrence of events in the environment are detected via periodic polling

Course content and organization

Course syllabus

38

Part one: embedded system programming Arduino (periodic and reactive programming)

Introduction to operating systems and RT OS

Concurrent programming with POSIX

RT Communication : CANBUS, DDS

Part two: Real Time scheduling Priority-driven scheduling

Shared resources

Oveload management

Scheduling Aperiodic tasks

Response Time Analysis

Part three: designing Real Time application Component-based development

UML MARTE

Teaching material

39

Textbook Giorgio C. Buttazzo, «Sistemi in Tempo Reale»,

Pitagora Editrice Bologna, 3° edizione

Giorgio C. Buttazzo, Hard Real-Time Computing

Systems, Springer

Course web site http://robotics.unibg.it/teaching/srt/

Exam

Written exam only • Theoretical questions • Scheduling exercises

Preappello • Monday December 16th 2019

41