IV Distributed Embedded Systems and Real Time Networks

Cours Mastere SE / Stream01-EPU-SI 3
STREAM01 Course / Mastère SE
Distributed embedded Systems

and Real-time networks
Marie-Agnès Peraldi-Frati
AOSTE Project
UNSA- CNRS-INRIA
December 2007
1
Course Schedule
Evolutions in real-time architecture (C)

Real-time Communications (C )
Standards AUTOSAR and OSEK/VDX : A Real-time
Middleware (C)
Example of RealTime embedded protocols
Time triggered Protocol : TTP (C, TD)
An asynchronous network : CAN/VAN protocol (C-TD-
TP)
Marie-agnès Peraldi-Frati- UNSA 1

Plan
Evolutions in real-time architecture
Real-time control system design example
Real-time control systems characteristics
Centralized vs distributed architecture
«Event triggered » vs. «Time triggered» system
Technical context
Examples : Automotive, mobile robots, avionic
Design methodology in automotive
Control system block diagram
Controller+ controlled system

Event triggered, Continuous time, Hierarchy
Feedforward and Feedback control loops
Well established mathematical theory
4

Control system Implementation

ABS/ESP Brake by wire Steer by wire
Engine Control System
Mapping of function
to hardware and
software components
controler
controler
controler
Control system mapping
Engine Control System
Engine Control system Brake Control system

Gasoline engine hardware architecture
Real-time system characteristics ?

Events are emitted by the process and their occurrences are
imposed to the controller.
Interaction with the environment
Reactivity
Measures are permanently emitted by the controlled system.
Measures are received by the controller at a rate determined by
itself
Commands are permanently received by the process
Commands are emitted by the controller at a rate determined by
itself.
8

Hard RTS
Timing problems
Response time, Execution time, Blocking ,Scheduling,
Arbitration, Transmission time, Jitters, Transient error,
Etc …
Safety : absence of catastrophic consequences on
the user and the environment
Reliability : continuity of correct service
Complexity
Centralized – « Dispersed » - Distributed

Determined by the granularity and the physical
distribution of components and computers.
Centralized
• One computer connected to a set of Input/Output
channels
• “Old-style” for embedded systems before the low-cost
microcontrollers. Capteurs
Contrôleur Actionneurs
Processus
10

Advantages of a centralized system

Simple programming model
CPU is a central element
Variation of the power depends of the needs.
Computers are maintain in a safe and secure space
Protection to external elements : fire, temperature
Central management : modifications must be done only
on a single machine
The evolution depends only on the number of available racks.
Any of these reasons might be sufficient to justify a
centralized system
11
Centralized - Dispersed - Distributed
Multiple CPU and Input/output devices on a single

computer
A single common memory space
Communication between modules using a shared memory
(Blackboard)
12

Centralized or Dispersed or Distributed

Dispersed
“Multiple” computers ( 2- 10) architecture
Each one with input/output capabilities
Limited communications between computers
Contrôleur 1
Processus
Contrôleur 2
13
Centralized vs. Dispersed vs. Distributed
Distributed
Processus
Controller 1 Controller 2 Controller 3
Communication link
14

An example of distributed embedded

system
• Multiple controllers connected to their multiple I/O
• Communication between modules by message passing

15
Centralized, Dispersed or Distributed

Distributed
Computer with input/output modules
Multiple computers (until hundred computers)
Few input/output channels by computer
A controller by equipment
Intelligent sensors/actuators
Central components of the system :
Input/Output
16

Benefit of distributed systems

Modularity in the design phase
Multiple teams conceive each node of the system (Car
part manufacturer, IP integration in electronics)
Well-defined, tightly enforced interface (system message
formats)
Independent « Upgrade » of modules that limit effect of
changes on rest of system
Modularity at the resource level
Reduction of the competition for the use of resources.
Incremental addition of I/O and microcontrollers in the

architecture.
17

Modularity for the validation/test
Worst case evaluation time is more easy one
module by one.
Modularity in the certification ( Avionic DO-
178B Level A, IEC 61508 SIL3/SIL4)

Limitation of the certification to critical modules
(X-By-Wire in automotive New IEC certification :

AUTOSAR)
18


Diagnosis is more simpler to establish
Containment of faults on nodes
Useful for systems with frequent errors on
cabling. Sensors and Sensors and
Sensors and
Actuators OK Actuators OK
Actuators OK
I hear neither I hear C2 but
I hear C3 but
C2 nor C3 not C1
not C1
Error ?
Error ? Error ?
Controller Actuators Process C 1 C. 2 C3
Network cutted
Where is the problem ? 19
Benefits of distributed system
Simplicity in the cabling and the hardware

maintenance
One-wire cabling instead of numerous wire lines.
Simplified connectivity
Substitution of nodes with failures “online”
The system can continue in a degraded operational
mode with a failure node
In case of failure possibility of error confinement
20

Benefits of a distributed system
Fault tolerance
One single point of failure in a centralized system
In a distributed potential fault recovery
mechanisms
A defection of one node may not imply the
defection of all the system.
21
Input/output management
Event Triggered
• system must reacts to significant external events directly and
immediately.
• external Events arrive in a sporadic way
• Closed to “interrupt- driven I/O”
• Efficient – treatments are only executed if necessary
• Concurrency problem – What’s happen if all potential events
arrive concurrently ?
22

Inputs/Outputs management
Time-triggered
• system must reacts to significant external events at pre-
specified instants.
• Events arrive according to a scheduling (fixed or variable
scheduling)
• Closed to the “I/O polling”
• Sometimes inefficient – Treatments are executed in a
periodic way even if it is not necessary.
• Calculable load – for the full system
23
Communications in distributed
systems
Event-Triggered protocols
Communications are initiated when a “send” message is received.
Problem of multiple access ,
Events arrive in a sporadic manner
Time-triggered protocols
Communication are triggered at pre-specified periodic instants.
Message sending is periodic
Message carry the newest information
Message lost is not a big problem
Message update is detected thanks to a modification of its value.
24

Applications domains of distributed

RTS
Automotive systems
Engine/steering/brake functions :
Comfort functions, body electronic functions
Maintenance
Control system, Embedded control/command
Automated production system
Robotics
Avionic
Avionic architecture
Specific communication buses
System on Chip …
25
Example : Evolutions of electronics in

automotive systems
Old style : A centralized power control command
Actuators are triggered using electro mechanical relays
Point to point wire connections
New architecture : distributed numerical controllers with
command of multiple sensors/actuators
Local cabling between ECU (Electronic Control Unit) and its
sensors/actuators.
Global cabling between ECUs
Low power energy is managed by ECU, relays are in charge of
distributing high level power.
26

Evolution in automotive
Past
[Kassadian96]
27
Recent past [Kassadian96]
28

ECU ECU ECU
ECU ECU
ECU ECU
ECU ECU ECU
Present
[Kassadian96]
29
Embedded system in automotive

Electronics represent 20% of a vehicle price
80% of innovations are due to electronics
Control and command laws are more complexes
ESP : Electronic Stability Program
CGC : Chassis control
ACC : Automatic cruise control
Coupling between the different control elements
Brakes, suspensions, engine …
Mechanical command are replaced by electronics commands
X by Wire
30

The Peugeot 607 PSA electronic

architecture
Up to 24 electronic equipment’s are connected through
5 electronic busses
CAN intersystem network
VAN Comfort network
VAN body network 1 dedicated to highly safety critical
functions ( airbags, headlights switching , … )
VAN body network 2 for the other functions (door control,
seat control, fuel additivation requested by particle filter for
multi valve diesel engine …)
An optical data link for large data transfer between navigation
system and the multifunction display
Copyright PSA Peugeot Citroen
31
PSA electrical electronic architecture
Based Bi-VAN – CAN – optical fibre networks

Immediate consequence on wiring
Citroën Xantia number of wires :
670 in previous version
429 in actual version -39%
Peugeot 306 number of wires
635 in previous version
373 in actual version -41%

32

Technological context in automotive
Complexity !
Functional :
Architectural
Interaction between systems
Flexibility
33
Functional complexity
Systems size
Number of automatic control laws
Coupling between controllers
34
CourtoisieJ.P.Elloy - Irccyn

Example of Knock: The Physical

phenomenon
Spark ignition engine phases: Intake, Compression,
Explosion, Exhaust
At end of compression, a spark is generated to ignite
air/fuel mixture.
Under particular conditions, a second ignition point is
auto-generated. This causes a 2nd combustion.
When the 2 flame fronts are crossing each-other,
pressure is increasing quickly.
=> KNOCK 35
Illustrating Engine Knock

Desired Combustion Knocking
Spark Plug
Cylinder Head
Flame Front
Fresh
Compressed
Auto Ignition
Mixture
Knocking
Courtesy A. Albinet SiemensVDO 36

Functional complexity
Multiple sampling asynchronous periods
Régulation AirFuel : Lambda sensor,
Gas : vanne EGAS
Sampling periods with variation
Knock sensor acquisition : Hertz
Engine Rotation Speed : CAMShaft rotation
Event-triggered sampling
Epuration du catalyseur à accumulateur : richesse
Knock control : Knock detection; Ignition angle correction.
37
Architectural complexity
Number and heterogeneity of
numerical controllers
Multiplicity of networks
Gear Box
controller
Engine controller
Comfort network
Powertrain
network
38

Architectural complexity
Synchronization by data handling

Vehicle speed : tachymeter,
Engine torque : induction sensor
Connection between networks (bridge) :
Vehicle speed : engine and brake network, comfort network
Airbag sub-network
Fault tolerance and recovery from errors
Fault recovery :
lost of tachymeter measures => re-emission
Engine torque information + Gear Box => Robotized Gear Box
39
Complexity of interactions between

systems
Co-operation of functionalities : new
functionalities
Light controlled by the windscreen wiper speed and the
ignition key Steering-wheel sensor
Functionalities Inclusion :
ABS => ESP
Anti-lock Braking System
Electronic Stability Program
Yaw-rate sensor
40

Complexity of interactions between systems

Power train functions
Engine - Brake
Steering - Gear box
Suspension - Clutch
Comfort functions
Continuous wiper speed depending on the weather and the vehicle speed
Volume detection in the cockpit for airbag
Intelligent lighting system
power-assisted steering
Security functions
Detection of hypo vigilance of the driver
Obstacle detection and assistance to braking
41
Complexity of interactions between

systems
Common synchronization mechanisms
Events, commands,
Rendez-vous ….
Standardized access to vehicle data.
Time Stamped data
Blackboard, Mailbox, ports, multi-cast
Freshness of data , temporal consistency
Templates for cooperation
Client-server architecture
42

Complexity of interactions between systems

ECU Computer
C: sensor
A : actuator
Flexibility in the projection
Vehicle
Gamme G,
VersionV,
Year A1
Vehicle
Gamme G,
VersionV,
Year A2
43
Complexity linked to flexibility

Integration of new services
Evolution of components Flexibility
Hardware optimization
44

Complexity linked to flexibility

Ad’hoc vehicles Flexibility due to
Variability in the commercial proposal variability
45
Courtoisie J.P.Elloy - Irccyn
Complexity linked to flexibility – diversity

Flexibility in the projection of functions onto hardware .
Diversification of configurations
Access to data independent from the projection

Middleware => data locations are transparent for the
designer.
Causal relations must be ensured : independent
from the projection
Event-driven, data-driven, time-triggered protocols
Management of functions : absence/ presence
Supervision, degraded modes
46

Example of robotique application : Cycab

Electrical Vehicle
Designed for circulation in restricted area
Urban zone
Railway station / airport
University
Touristic zone
Vehicles designed to be used in a safe and simple
mode :
Access with magnetic card
Driving assistance using a joystick
Automatic park and battery energy reload
Availability from one point to another
Multimedia information terminal
47
Cycab equipements
Caméra CCD pour la téléopération
Balises infra rouges

pour la conduite en train
Terminal multimédia
Borne de recharge par Caméra linéaire

induction fixée sur la pour la conduite en train
voirie
batteries + gestionnaire Capteurs ultrasons pour

automatique de charge la détection d’obstacles
Joystick central de commande

Vérin de direction électrique
pour la conduite sécurisée
frein électrique par roue 48
moteur électrique par roue

Cycab architecture
Control and command of 9 motors
An distributed hardware architecture : 3 intelligent nodes
One Steering node that control the joystick and the steering
actuator
twowheel drive nodes that control the wheel drive motors
and brakes
An industrial PC manage the finger touch screen
A MVME162 microcontroller with VxWorks operating
system for implementing control motor laws
Communication between nodes with a fielbusController
Area Network (CAN).
Ultasonics sensors and the CCD camera are connected on
the CAN bus.
49
Cycab architecture
50

Avionic first class concepts
SIL 4
Safety
Dependability
Certification
Redundancy
51
Classical Avionic architecture

A340 Conventional
Avionics
Black boxed functionalities (several LRU Suppliers)
Single emission bus

Isolated functionalities
Multi suppliers for functionalities
52

Classical avionic architecture
53
IMA Avionic architecture
A380
IMA (Integrated Modular Avionic)
Complexity increase
Number of Functionalities
Communication increase
Buses arinc, ethernet commuté full duplex
54

IMA A380 architrecture
55
Design methodology for DRTS

System requirement process
What the system will do : Functional/Non functional
What is the environment
Hierarchical description
Refinement of requirements
Traceability links
Software architecture process
Elicitation of functionalities
Control flow and data flow between functions
Temporal constraints on functions
Control view / software view / implementation view
Reaction in case of errors (Degraded mode of computation, Critical situations :
Fault tolerance : To preserve the operational capacity of the system, Redundancy of
hardware components.
56

Design methodology
Hardware architecture process
Computation resources (CPU, memory, ASIC…)
Communication resources (protocols, interfaces … )
OS and middleware
Implementation process
Allocation
Automatic code generation
Preserve properties
Take into account physical architecture parameters
OS compatible with specifications ?
57
Methodology in automotive control design

Decomposition into different layers
58

Functional layer
Functions and sub-fonctions : what the system do ?
Sensor #1
Actuator #3
F1.1
F2
F1.2
Sensor #2 F1
F1.3
Non-defined
F3 Actuator
Sub-functions :
Can be shared by different functions
59
Software layer : specific components

Projection of functions on
specific software
components
Notion of services
Services are provided by multiple
components
LDM : local drivers for
sensors and actuators
ASC : application software
components
60

Hardware/Software layers : dedicated

components
Hardware components :
Sensors-Actuators
ECU: Electronical Control

ECU Network
Unit
Network
Software components :
Driver Com-SC ICEM OS-SC
Drivers
Protocols , Exchange system
OS
61
Operational layer
Projection of functional components onto hardware and
software
62

Operational layer
Control and data flow connections
#1 #3
#6
#2 #4
#5
63
Deployment phase
Deployment of components into logical tasks
Transformation of logical tasks into
executable tasks
Projection of
synchronizations and
communication onto OS
and network primitives
64

Operational view of an ECU
#2 #4 #3 #6
#5
#2
#1
a b
A #4
#5
B
b a
#6
65
Conclusion
Pros and cons of distributed real-time systems

Definitely distributed !
Modular, fault tolerant, reduction of cabling cost, reconfiguration…
Necessity of “ad’hoc” methodology and tools for taking into account,
Physical characteristics, Determinism, Fault tolerance at the system level
We will focus on communications protocols and middleware in
automotive
Realtime networks
What is the level of service of these networks ?
What are the response of these networks to determinism, fault tolerance,
temporal validation…?
66

Plan of course 2
Realtime Communications
STANDARD
OSEK/VDX standard
AUTOSAR
ISO and realtime
Medium Access Protocols
67
Thanks
Jean pierre Elloy –Professor Irccyn Nantes for its

documentation about automotive design informations
Yvon Trinquet – Professor Irccyn Nantes for
documentation about OSEK/VDX
68

Réferences
• H. Kopetz, Real-Time Systems : Design Principles for Distributed Embedded

Applications, Kluwer, 1997.
• Autosar Automotive Open System Architecture, www.autosar.org
• EAST ADL EAST-EEA Architecture Description Language www.east-
eea.net
69
Trends for the future
Electrical Electronic architecture deployment
1999 2000 2001 2002 2003 2004 2005

70

Caractérisation des communications

temps réel
Latence du protocole : c’est l’intervalle de temps entre le
début d’une transmission d’un message au niveau du CNI
(Network Communication Interface)du nœud émetteur et la
réception par le CNI du nœud récepteur.
Jitter :
71
Embedded distributed system

Heat-energy Electrical
Vehicle control energy
control
Supervision
Contrôle de Steering
Execution
Controller châssis control
Brakes Steering Transmission

Suspension Engine Gear box
72

IV Distributed Embedded Systems and Real Time Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IV Distributed Embedded Systems and Real Time Networks

Uploaded by

Copyright:

Available Formats

Cours Mastere SE / Stream01-EPU-SI 3

STREAM01 Course / Mastère SE

Distributed embedded Systems

 Evolutions in real-time architecture (C)

Marie-agnès Peraldi-Frati- UNSA 1

 Real-time control systems characteristics

 Centralized vs distributed architecture

 «Event triggered » vs. «Time triggered» system

 Examples : Automotive, mobile robots, avionic

 Design methodology in automotive

Control system block diagram

 Controller+ controlled system

Marie-agnès Peraldi-Frati- UNSA 2

Control system Implementation

Control system mapping

Engine Control System

Engine Control system Brake Control system

Marie-agnès Peraldi-Frati- UNSA 3

Gasoline engine hardware architecture

Real-time system characteristics ?

Marie-agnès Peraldi-Frati- UNSA 4

Centralized – « Dispersed » - Distributed

Marie-agnès Peraldi-Frati- UNSA 5

Advantages of a centralized system

Centralized - Dispersed - Distributed

 Multiple CPU and Input/output devices on a single

Marie-agnès Peraldi-Frati- UNSA 6

Centralized or Dispersed or Distributed

Centralized vs. Dispersed vs. Distributed

Controller 1 Controller 2 Controller 3

Marie-agnès Peraldi-Frati- UNSA 7

An example of distributed embedded

• Multiple controllers connected to their multiple I/O

• Communication between modules by message passing

Centralized, Dispersed or Distributed

 Central components of the system :

Marie-agnès Peraldi-Frati- UNSA 8

Benefit of distributed systems

 Incremental addition of I/O and microcontrollers in the

Benefit of distributed systems

178B Level A, IEC 61508 SIL3/SIL4)

(X-By-Wire in automotive New IEC certification :

Marie-agnès Peraldi-Frati- UNSA 9

Benefit of distributed systems

Controller Actuators Process C 1 C. 2 C3

Benefits of distributed system

 Simplicity in the cabling and the hardware

Marie-agnès Peraldi-Frati- UNSA 10

Benefits of a distributed system

Marie-agnès Peraldi-Frati- UNSA 11

Marie-agnès Peraldi-Frati- UNSA 12

Applications domains of distributed

Example : Evolutions of electronics in

Marie-agnès Peraldi-Frati- UNSA 13

Recent past [Kassadian96]

Marie-agnès Peraldi-Frati- UNSA 14

ECU ECU ECU

ECU ECU ECU

Embedded system in automotive

Marie-agnès Peraldi-Frati- UNSA 15

The Peugeot 607 PSA electronic

PSA electrical electronic architecture

 Based Bi-VAN – CAN – optical fibre networks

Evolutions in real-time architecture (C)

Real-time control systems characteristics

Centralized vs distributed architecture

«Event triggered » vs. «Time triggered» system

Examples : Automotive, mobile robots, avionic

Design methodology in automotive

Controller+ controlled system

Multiple CPU and Input/output devices on a single

Central components of the system :

Incremental addition of I/O and microcontrollers in the

Simplicity in the cabling and the hardware

Based Bi-VAN – CAN – optical fibre networks

Interaction between systems

Synchronization by data handling

Volume detection in the cockpit for airbag

Intelligent lighting system

Access to data independent from the projection

Single emission bus

ECU: Electronical Control

Protocols , Exchange system

Pros and cons of distributed real-time systems

What are the response of these networks to determinism, fault tolerance,

Jean pierre Elloy –Professor Irccyn Nantes for its

Electrical Electronic architecture deployment