1
STREAM01 Course / Mastère SE
Distributed embedded Systems and Real-time networks
Marie-Agnès Peraldi-Frati AOSTE Project UNSA- CNRS-INRIA
December 2007
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)
3
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
5
Control system Implementation
Engine Control System ABS/ESP Brake by wire Steer by wire
Mapping of function to hardware and software components
controler
controler
controler
Control system mapping
Engine Control System
Engine Control system Brake Control system
7
Gasoline engine hardware architecture
Real-time system characteristics ?
Events are emitted by the process and their occurrences are imposedto the controller.
Interactionwith the environment
Reactivity
Measuresare permanently emittedby the controlled system.
Measuresare receivedby the controller at a rate determined by itself
Commandsare permanently receivedby the process
Commandsare emittedby the controller at a rate determined by itself.
9
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
11
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
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)
13
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
Centralized vs. Dispersed vs. Distributed
Distributed
Processus
Controller 1 Controller 2 Controller 3
15
An example of distributed embedded system
• Multiple controllers connected to their multiple I/O
• Communication between modules by message passing
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
17
Benefit of distributed systems
Modularityin 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.
Benefit of distributed systems
Modularity for the validation/test
Worst case evaluation time is more easy one module by one.
Modularity in the certification
( AvionicDO- 178B Level A, IEC 61508 SIL3/SIL4)
Limitation of the certification to critical modules
(X-By-Wire in automotive New IEC certification :
AUTOSAR)
19
Benefit of distributed systems
Diagnosis is more simpler to establish
Containment of faults on nodes
Useful for systems with frequent errors on cabling.
Controller Actuators Process
Error ? Error ? Error ?
Where is the problem ?
C 1 C. 2 C3
Network cutted
Sensors and Actuators OK I hear C2 but
not C1 Sensors and
Actuators OK I hear C3 but
not C1 Sensors and
Actuators OK I hear neither
C2 nor C3
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
21
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.
Input/output management
Event Triggered
• system must reacts to significant external eventsdirectly and immediately.
• external Eventsarrive 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 ?
23
Inputs/Outputs management
Time-triggered
• system must reactsto significant external eventsat 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
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.
25
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 …
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
27
Evolution in automotive
Past
[Kassadian96]
Evolution in automotive
Recent past
29
Evolution in automotive
Present
ECU ECU
ECU ECU ECU
ECU ECU ECU
ECU ECU
[Kassadian96]
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
31
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
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%
33
Technological context in automotive
Functional :
Architectural
Interaction between systems
Flexibility
Complexity !
Functional complexity
Systems size
Number of automatic control laws
Coupling between controllers
35
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
Illustrating Engine Knock
Fresh Compressed Mixture Cylinder Head
Spark Plug
Flame Front
Desired Combustion Knocking
Auto Ignition
Knocking
37
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.
Architectural complexity
Number and heterogeneity of numerical controllers
Multiplicity of networks
Engine controller
Gear Box controller
Powertrain
Comfort network
39
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
Complexity of interactions between systems
Co-operation of functionalities : new functionalities
Light controlled by the windscreen wiper speed and the ignition key
Functionalities Inclusion : ABS => ESP
Anti-lock Braking System Electronic Stability Program
Steering-wheel sensor
41
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
Complexity of interactions between systems
Common synchronization mechanisms
Events, commands,
Rendez-vous ….
Standardized access to vehicle data.
Time Stampeddata
Blackboard, Mailbox, ports, multi-cast
Freshness of data , temporal consistency
Templates for cooperation
43
Complexity of interactions between systems
Vehicle
Gamme G,
VersionV,
YearA2
Flexibility in the projection
ECU Computer C: sensor A : actuator
Vehicle
Gamme G,
VersionV,
YearA1
CourtoisieJ.P.Elloy - Irccyn
Complexity linked to flexibility
Flexibility
Integration of newservices Evolution ofcomponents Hardware optimization
45
Complexity linked to flexibility
Flexibility due to variability
Ad’hocvehicles
Variabilityin the commercial proposal
Courtoisie J.P.Elloy - Irccyn
Complexity linked to flexibility – diversity
Flexibility in the projection of functions onto hardware . Diversificationof 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
47
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
Cycab equipements
Borne de recharge par induction fixée sur la voirie
Caméra CCD pour la téléopération
Joystick central de commande
Terminal multimédia Caméra linéaire pour la conduite en train Balises infra rouges
pour la conduite en train
Capteurs ultrasons pour la détection d’obstacles Vérin de direction électrique batteries + gestionnaire
automatique de charge
49
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.
Cycab architecture
51
Avionic first class concepts
SIL 4
Safety
Dependability
Certification
Redundancy
Classical Avionic architecture
A340
Black boxed functionalities
Single emission bus
Isolated functionalities
Multi suppliers for functionalities
Conventional Avionics (several LRU Suppliers)
53
Classical avionic architecture
IMA Avionic architecture
A380
IMA (Integrated Modular Avionic)
Complexity increase
Number of Functionalities
Communication increase
Buses arinc, ethernet commuté full duplex
55
IMA A380 architrecture
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.
57
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 ?
Methodology in automotive control design
Decomposition into different layers
59
Functional layer
Functions and sub-fonctions : what the system do ?
F1
F2
F3
F1.1 F1.2
F1.3 Sensor #2
Sensor #1
Actuator #3
Sub-functions :
Can be shared by different functions
Non-defined Actuator
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
61
Hardware/Software layers : dedicated components
Hardware components :
Sensors-Actuators
ECU: Electronical Control Unit
Network
Software components :
Drivers
Protocols , Exchange system
OS
ECU Network
Driver Com-SC ICEM OS-SC
Operational layer
Projection of functional components onto hardware and software
63
Operational layer
Control and data flow connections
CourtoisieJ.P.Elloy - Irccyn
#1
#2
#3
#4
#5
#6
Deployment phase
Projection of
synchronizations and communication onto OS and network primitives
Deployment of components into logical tasks
Transformation of logical tasks into executable tasks
65
Operational view of an ECU
Courtoisie J.P.Elloy - Irccyn
#1
#4
#2
#5
#6
#2 #4
#5
#3 #6
A
B b a
b a
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,
67
Plan of course 2
Realtime Communications
STANDARD
OSEK/VDX standard
AUTOSAR
ISO and realtime
Medium Access Protocols
Thanks
Jean pierre Elloy–Professor Irccyn Nantes for its documentation about automotive design informations
Yvon Trinquet – Professor Irccyn Nantes for documentation about OSEK/VDX
69
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
Trends for the future
Electrical Electronic architecture deployment
1999 2000 2001 2002 2003 2004 2005
71
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 :
Embedded distributed system
Brakes Steering Suspension Engine Gear box Transmission
Supervision
Vehicle Electrical
energy control
Contrôle de châssis
Steering control
Execution Controller
Heat-energy control
