1) The document discusses critical embedded systems and emerging issues in their design. It uses automotive systems as an example to illustrate complexity challenges for dependability. 2) Automotive systems now rely heavily on software and electronics, introducing new safety risks due to issues like complexity, external development processes, and tight cost/time constraints. Verification is made difficult by incomplete system knowledge and environmental factors. 3) Evolving technologies, standards, and design practices aim to enhance dependability, but open challenges remain regarding issues like semantic interoperability between domain-specific models and tools.

1. 1
Les systèmes embarqués critiques : évolution des
pratiques de conception et problèmes émergents
Nicolas NAVET
INRIA / RealTime-at-Work
Equipe Temps Réel et Interopérabilité (TRIO)
http://www.loria.fr/~nnavet
Journée Prospective du GDR ASR, Paris le 03/11/2011
N. NAVET

2. 2
Plan
1. Illustration : systèmes embarqués dans l’automobile
o Quelles menaces sur leur Sûreté de fonctionnement?
o Zoom sur les contraintes de temps
2. Evolutions des technologies et pratiques dans la
conception des systèmes critiques
3. Problèmes ouverts et émergents
4. Actions en lien dans le pôle « Systèmes Embarqués
hautes performances » du GDR ASR
N. NAVET

3. 3
Les systèmes embarqués : une utilisation au quotidien
N. NAVET
3

4. 4
Dependability vs Security [from Laprie et al, 3]
“absence of unauthorized access to, or
handling of, system state”
“ability to deliver
a service that
can justifiably be Dependability Security
trusted ”
Availability Reliability Safety Confidentiality Integrity Maintenability
Readiness for Continuity of Absence of Absence of Absence of Ability to
usage service catastrophic unauthorized improper undergo repairs
consequences disclosure of system and evolutions
for authorized information alterations
users only
“unauthorized”
system alteration
N. NAVET

5. 5
Systèmes embarqués dans
l’automobile : quelles menaces sur
leur sûreté de fonctionnement ?
N. NAVET

6. 6
Electronics is the driving force of innovation in automotive
Many new functions are safety critical:
brake assist, cruise control, lane keeping,
dynamic lights, etc
Picture from [10]
– 90% of new functions use software
– Electronics: 40% of total costs
– Huge complexity: 70 ECUs, 2500 signals,
>6 comm. protocols, multi-layered run-time
environment (AUTOSAR), multi-source
software, multi-core CPUs, number of
variants, etc
Strong costs and time-to-market constraints !
N. NAVET

7. 7
BMW 7 Series networking architecture [11]
ZGW = central
gateway
4 CAN buses
1 FlexRay Bus
1 MOST bus
Several LIN Buses
(not shown here)
1 Ethernet bus
Wireless
Picture from [11]
N. NAVET

8. 8
Main impediments to safety imho: complexity!
Technologies: numerous, complex and not
explicit. conceived for critical systems
– e.g.: more than 150 specification documents
(textual) for Autosar, no two implementations
can behave identically!
Size of the system!
– Number of functional domains, buses, gateways, Autosar Basic Software
ECUs, size of code, tasks, wiring, number of
variants, etc
Design process
– Most developments are not done in-house :
less control on externalized developments
– Carry-over / Vehicle Family Management : need to
share/re-use architecture and sub-systems between
several brands/models with different requirements [2]
– Optimized solutions for each component / function
does not lead to a global optimal [2] Wiring harness
Picture from [11]
N. NAVET

9. 9
Threats to dependability : the big picture
When faults are introduced in the development phase ?
– Requirements capture (20%) + Specification (50%) + SW development: (30%) (infineon [10])
– HW development : ε
Risk factors beside complexity:
– Technologies: not all conceived with dependability as a priority
– Little hardware redundancy
– Developments are mainly externalized: incomplete knowledge for the OEM
technical parameters are regarded as less important than cost for
supplier / components selection [2]
– Strong cost / time-to-market pressure
– Limited regulatory constraints even with upcoming ISO26262
– Verification / validation does not ensure 100% coverage, limited used
of formal methods
– Human factors
– etc
N. NAVET

10. 10
Zoom sur
les contraintes temporelles
N. NAVET

11. 11
Several hundreds of timing constraints – example of an
end-
end-to –end constraints
Constraint :
brake light on < 50ms
Stimulus Response
Figure from [12]
N. NAVET

12. 12
Verification of the timing constraints
Personal view / experiences
« correctness by construct » and
Mostly optimal synthesis
ahead
bursts of errors
of us! Probabilistic performance & safety
assessment - system level
Interarrival times
Single transmission errors
« Worst-case » deterministic analysis
system level
Probabilistic analysis (sub-system)
« Worst-case » deterministic analysis (sub-system)
COTS tools « Smart » monitoring tools
Simulation tools (SBFI)
1995 1997 2009
N. NAVET

13. 13
Why timing constraints may not be
respected occasionally? Middleware
Lack of precise specification : hard to identify 5ms Comm.
the right timing requirements for each function task
Lack of traceability : from the architects to the suppliers
Flaws in the verification:
– Knowledge of the system and its environment is incomplete: Waiting queue:
• What is done by the suppliers?
- FIFO
• Implementation choices really matter and standards do
not say everything 2 - Highest Priority
• Environmental issues: EMI, α-particles, heat, etc First
• Traffic is not always well characterized and/or well modeled 1 - OEM specific
e.g. aperiodic traffic ?! see [5]
– Testing /simulation alone is not enough CAN Controller
– Analysis is not enough too:
• Analytic models, especially complex ones, can be wrong 9 6 8
(remember “ CAN analysis refuted, revisited, etc” [6] ?!)
• They are often much simplified abstraction of reality buffer Tx
and might become optimistic: neglect FIFOs, hardware limitations
CAN Bus
N. NAVET

14. 14
Illustration: Worst-Case Response Times on a CAN bus
Frame waiting queues are HPF, except ECU1 where queue is FIFO
the OEM does not know or verification software cannot handle it …
Analysis Setup:
- Typical body network with 15 ECUs
generated by NETCARbench (freely available)
- WCRT computed with NETCAR-Analyzer
(freely available)
Many high-priority frames are delayed here because
a single ECU (out of 15) has a FIFO queue …
N. NAVET

15. 15
Quelles évolutions dans la conception
des systèmes critiques ?
- Safety standards
- Design process
-Technologies, computing platforms
N. NAVET

16. 16
Safety standards and certification processes
cannot be ignored
IEC61226
IEC60880
…
EN 50126/28/29
DO 178 / DO 254 ISO 26262
IEC 61508
ECSS / CNES
Airbus: 1/3 of the design costs of an airplane due to certification !
N. NAVET
[Multi-domain comparison of safety standards, ERTSS-2010]

17. 17
Model Based Design for dependable system development
Requirements
Design Verification
code
generation
Scade
C to binary
Compiler
Simulation Certification
Verification Kit
DesignVerifyer State machine to C
certified transformation tool
End-to-end design flows with proven outcomes at eachNAVET
N.
step

18. 18
Stakeholder requirements Ex: Objectiver, Reqtify, Doors
Verification & Validation
is needed at each step Req. Analysis Verification criteria
System specification Fonct. specification Ex: SysML
Architecture design Model./Program. Ex: Scade, frama-C
Validation /
Validation / Verification
Physical Architecture Model/Source
Ex: Gnat, TOM,
Allocation Compile CompCert, Scade
Simplified INCOSE
approach
System Architecture Binary
Implement Link
HW + base SW Exe
Integrate
System
N. NAVET

19. 19
domain-
MBD: domain-specific models and tools
must be dealt with
requirements
sysML?
Some open issues: semantic interoperability,
pivotal language? local versus global verification
N. NAVET

20. 20
cross-
Technology : from domain specific to cross-industry solutions
Today :
- Avionics: IEEE1553, AFDX, TTP, ARINC 653, ..
- Automotive: CAN, FlexRay, Autosar, Lin, ..
- Power plants: Alstom Alspa, Siemens Teleperm, ..
[Thomesse05]
Tomorrow : Objective of the DDASCA consortium
- Convergence of safety standards
- Computing platforms: cross-industry solutionS with profile per
application domain and scalable dependability : e.g., switched
Ethernet, virtualization, etc
- Architecture patterns with specific dependability capabilities
S w itc h S w itch
S w itc h S w itc h
S w itch S w itch
S w itc h S w itc h
C alcu la te ur
N °1
C alcu la te ur
N °i
N. NAVET

21. 21
What is needed now: achieving affordable
dependability
1. A large body of techniques, development processes,
tools, know-how is increasingly available – they have to
become more accessible
2. Simpler systems are more amenable to verification!
3. Formal methods are now sufficiently mature to handle
real-world industrial problems.
Public research : provide support to both companies
and public authorities so that there is no compromise in safety
N. NAVET

22. 22
Intérêt pour les systèmes embarqués critiques ?
Participez aux activités du pôle « Systèmes
Embarqués hautes performances » du GDR ASR
- Action AFFSEC « Approches Formelles des Systèmes
Embarquées Communicants » (inter-GDR MACS et GPL)
http://afsec.asr.cnrs.fr/
- Groupe WEED « Worst End-to-End Delay » - prochaine
journée le 23/11/2011
- Action ACTRISS « ACtion Temps Réel : Infrastructure et
Services Systèmes » - journée « low-power » le
17/02/2012, puis journée « outils » en Mars / Avril 2012.
N. NAVET

23. 23
Merci pour votre attention!
questions / réponses
contact: nicolas.navet@inria.fr
N. NAVET

24. 24
[1] N. Navet, F. Simonot-Lion, editors, The Automotive Embedded Systems
References Handbook, Industrial Information Technology series, CRC Press / Taylor and
Francis, ISBN 978-0849380266, December 2008.
[2] P. Wallin, Axelsson, A Case Study of Issues Related to Automotive E/E
System Architecture Development, IEEE International Conference and
Workshop on the Engineering of Computer Based Systems, 2008.
[3] A. Avizienis, J.C. Laprie, B. Randell, “Dependability and its threat: a
taxonomy", IFIP Congress Topical Sessions 2004.
[4] D. Khan, R. Bril, N. Navet, “Integrating Hardware Limitations in CAN
Schedulability Analysis“, WiP at the 8th IEEE International Workshop on
Factory Communication Systems (WFCS 2010), Nancy, France, May 2010.
[5] D. Khan, N. Navet, B. Bavoux, J. Migge, “Aperiodic Traffic in Response Time
Analyses with Adjustable Safety Level“, IEEE ETFA2009, Mallorca, Spain,
September 22-26, 2009.
[6] R. Davis, A. Burn, R. Bril, and J. Lukkien, “Controller Area Network (CAN)
schedulability analysis: Refuted, revisited and revised”, Real-Time Systems,
vol. 35, pp. 239–272, 2007.
[7] M. D. Natale, “Evaluating message transmission times in Controller Area
Networks without buffer preemption”, in 8th Brazilian Workshop on Real-Time
Systems, 2006.
[8] C. Braun, L. Havet, N. Navet, "NETCARBENCH: a benchmark for techniques
and tools used in the design of automotive communication systems", Proc
IFAC FeT 2007, Toulouse, France, November 7-9, 2007.
[10] P. Leteinturier, “Next Generation Powertrain Microcontrollers”, International
Automotive Electronics Congress, November 2007.
[11] H. Kellerman, G. Nemeth, J. Kostelezky, K. Barbehön, F. El-Dwaik, L.
Hochmuth, “BMW 7 Series architecture”, ATZextra, November 2008.
[12] AUTOSAR, “Specification of Timing Extensions”, Release 4.0 Rev 2, 2010.
N. NAVET