Systèmes embarqués critiques


Published on

Support de la présentation de Nicolas Navet

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Systèmes embarqués critiques

  1. 1. 1Les systèmes embarqués critiques : évolution despratiques de conception et problèmes émergentsNicolas NAVETINRIA / RealTime-at-WorkEquipe Temps Réel et Interopérabilité (TRIO)ée Prospective du GDR ASR, Paris le 03/11/2011 N. NAVET
  2. 2. 2Plan1. Illustration : systèmes embarqués dans l’automobile o Quelles menaces sur leur Sûreté de fonctionnement? o Zoom sur les contraintes de temps2. Evolutions des technologies et pratiques dans la conception des systèmes critiques3. Problèmes ouverts et émergents4. Actions en lien dans le pôle « Systèmes Embarqués hautes performances » du GDR ASR N. NAVET
  3. 3. 3Les systèmes embarqués : une utilisation au quotidien N. NAVET 3
  4. 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 evolutionsfor authorized information alterationsusers only “unauthorized” system alteration N. NAVET
  5. 5. 5 Systèmes embarqués dansl’automobile : quelles menaces sur leur sûreté de fonctionnement ? N. NAVET
  6. 6. 6 Electronics is the driving force of innovation in automotiveMany 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. 7BMW 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. 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, etcDesign 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. 9 Threats to dependability : the big pictureWhen 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. 10 Zoom surles contraintes temporelles N. NAVET
  11. 11. 11 Several hundreds of timing constraints – example of an end- end-to –end constraints Constraint : brake light on < 50msStimulus Response Figure from [12] N. NAVET
  12. 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 levelInterarrival 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. 13 Why timing constraints may not be respected occasionally? MiddlewareLack of precise specification : hard to identify 5ms Comm. the right timing requirements for each function taskLack of traceability : from the architects to the suppliersFlaws 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. 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. 15 Quelles évolutions dans la conception des systèmes critiques ?- Safety standards- Design process-Technologies, computing platforms N. NAVET
  16. 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. 17Model Based Design for dependable system development Requirements Design Verification code generation Scade C to binary Compiler Simulation Certification Verification KitDesignVerifyer State machine to C certified transformation tool End-to-end design flows with proven outcomes at eachNAVET N. step
  18. 18. 18 Stakeholder requirements Ex: Objectiver, Reqtify, DoorsVerification & Validationis 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. 19 domain-MBD: domain-specific models and toolsmust be dealt with requirements sysML? Some open issues: semantic interoperability, pivotal language? local versus global verification N. NAVET
  20. 20. 20 cross- Technology : from domain specific to cross-industry solutionsToday :- 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. 21What is needed now: achieving affordabledependability1. A large body of techniques, development processes, tools, know-how is increasingly available – they have to become more accessible2. 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. 22Intérêt pour les systèmes embarqués critiques ?Participez aux activités du pôle « SystèmesEmbarqués hautes performances » du GDR ASR- Action AFFSEC « Approches Formelles des Systèmes Embarquées Communicants » (inter-GDR MACS et GPL) - 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. 23Merci pour votre attention! questions / réponsescontact: N. NAVET
  24. 24. 24 [1] N. Navet, F. Simonot-Lion, editors, The Automotive Embedded SystemsReferences 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