20140121 cisec-safety criticalsoftwaredevelopment

  • 767 views
Uploaded on

Software occupy an increasingly prominent place in the critical embedded systems : their size and complexity is increasing , while their criticality also continues to rise. In this context, how the …

Software occupy an increasingly prominent place in the critical embedded systems : their size and complexity is increasing , while their criticality also continues to rise. In this context, how the aeronautical, space , automotive, industrial domains are facing these challenges ? Application of international standards is essential to define the scope of practices recognized by the community as " state of the art " in terms of producing safety critical software . What are these practices, the principles on which they are built ? Starting with (re)defining the concept of software criticality and placing this concept in the whole system, then we will try to answer all these questions. During this presentation , we will illustrate the point with examples from aeronautics, air traffic control , space , automotive or railway . Finally, we will take a look at some trends , particularly through standards recently released.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
767
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Seminar CISEC 2013/2014 Software for embedded safety critical systems Toulouse, january 2014 Hugues Bonnin
  • 2. cisec Plus d’information à http://asso-cisec.org 2013-2014 Le lundi mardi, de 17h à 19h Série de Conférences Ingénierie des systèmes embarqués critiques 1- Introduction, systèmes critiques Aéronautique (P. Traverse, Airbus, 18/11/2013) Espace (JP. Blanquart, Astrium, 25/11/2013) Automobile (H. Foligné, Continental Automotive, 2/12/2013 Reportée, date à fixer) 2- Sûreté, historique Histoire de la sécurité du Concorde à l’A380 (JP. Heckmann, Apsys, 9/12/2013) Comparaison de normes de sûreté (JP. Blanquart, Astrium, JM. Astruc, Continental, 16/12/2013) 3- Développement logiciel, assurance (H. Bonnin, Capgemini, 21/1/2014) 4- Développement matériel, assurance Automobile (JP. Loncle, Continental, 28/1/2014) Aéronautique (P. Pons, Airbus, 11/2/2014) 5- Intégration système et compatibilité électromagnétique (JC. Gautherot, DGA) Partie 1, 18/2/2014 Partie 2, 25/2/2014 6- Interactions homme-système (F, Reuzeau, Airbus, P. Palanque, IRIT, 18/3/2014) 7- Chaîne de production d’électronique pour l’automobile (Continental, 25/3/2014) 8- Diagnostic et maintenance de systèmes (Actia, 1/4/2014) 9- Systèmes autonomes dans les transports (drones, aide à la conduite automobile) (ONERA, Continental, 8/4/2014) 10- Les systèmes domotiques (R. Alami, LAAS, 15/4/2014)
  • 3. Abstract Software occupy an increasingly prominent place in the critical embedded systems : their size and complexity is increasing , while their criticality also continues to rise. In this context, how the aeronautical, space , automotive, industrial domains are facing these challenges ? Application of international standards is essential to define the scope of practices recognized by the community as " state of the art " in terms of producing safety critical software . What are these practices, the principles on which they are built ? Starting with (re)defining the concept of software criticality and placing this concept in the whole system, then we will try to answer all these questions. During this presentation , we will illustrate the point with examples from aeronautics, air traffic control , space , automotive or railway . Finally, we will take a look at some trends , particularly through standards recently released . Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 3
  • 4. Contents 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 4
  • 5. 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 5
  • 6. Principles : software is everywhere Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 6
  • 7. Principles : software complexity increases Software Size 1000000 1 GLOC - A380 100000 12MB A330/A340 5MB - A320 2MB - A310 10000 1000 200KB - A300FF 100 23KB - A300B 10 4KB - Concorde 1 1960 1970 1980 1990 2000 2010 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 7
  • 8. Principles : “brain juice”  Software is not material, it’s only « brain juice »…  It is a result of engineering, but without any physical manufacturing  At most it is a formalization understandable by machines.  As software is not physical, there is no real failure, but only errors. So, how to deal with that sort of problem ? How to kill bugs ? Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 8
  • 9. Principles : the bibles DO178(B,C) /ED12(B,C) ISO 26262-chap6 … ECSS-Q-ST-80-C EN50128 ED153 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 9
  • 10. 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 10
  • 11. Regulation & Standards short story ICAO Navigabilité CS25 SES Circulation Aérienne EC 482/2008 CS25-1309 ARP-4754 DO178(B,C) DO-278(-,A) (See course chapter 2 « standards ») Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 11
  • 12. 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 12
  • 13. Level and system : assurance level definition  Embedded software is part of a system, which is submitted to safety analysis, and for which is assigned a safety objective (i.e. a maximum frequence of failure) linked to the criticality. (See course chapter 1 « avionic systems »)  Standards establishes a relationship between this criticality and the level of « severity » to which the software has to be developped  This relationship is more or less direct (depending on domain/standard) : Effect severity class Hazardous A Serious incident Major incident Significant incident 1 2 3 4 SWAL1 SWAL2 SWAL3 SWAL4 Possible Catastrophic Software level Accident Very Possible Criticallity SWAL2 SWAL3 SWAL3 SWAL4 Unlikely SWAL3 SWAL3 SWAL4 SWAL4 Very Unlikely SWAL4 SWAL4 SWAL4 SWAL4 likelyhood of generating such an effect B Major C Minor D DO178(B,C) approach ED153 approach Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 13
  • 14. Level and System : different scales of level CNS/ATM ESARR, SAM, ECxx SWAL 1 SWAL 2 SWAL 3 SWAL 4 CNS/ATM ED109/ DO278 AL 1 AL 2 AL 3 AL 4 AL 5 AL 6 Aeronautical embedded software ED12B/ DO178B A B C other domains (nuclear, railway...) IEC 61508, EN 50128... SIL 4 SIL 3 SIL 2 D E SIL 1 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 14
  • 15. Level and System : « feedback » to system level EAR/JAR/FAR Airworthiness requirements System Operational requirements SYSTEM LIFE CYCLE PROCESSES System Safety Assessment Process System Requirements Allocated to S/W S/W levels Design Constraints Derived Requirements Error Sources Identified/Eliminated Partitioning, ROM, RAM size, CPU, redundancy SOFTWARE LIFE CYCLE PROCESSES DO178(B,C) approach Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 15
  • 16. Level and system : examples of software level  EN50128/SIL4 : Railway odometer of ERTMS  DO178B/Level B : BSCU  DO178B/Level C : FMS  ED109*/AL 4 : Display in ATM Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 16
  • 17. 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 17
  • 18. Standards : ground principles  Air Traffic Management regulation (ESARR6, and EC 482/2008), defines 4 General Safety Requirements :     Software requirements management Software implementation satisfy its requirements Software requirements traceability Software configuration management • NB : a 5th is added : no function which adversely affect safety  All these requirements are inherent in each standards of software development in aeronautics, the principle is « to be sure that the software is really what you want, and only what you want, at any time of its lifecycle » Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 18
  • 19. Standards : ground principles Requirements Verification Verification measure Implementation  Requirements, Verification, Traceability Development Activity Verification Activity Verification of Verification Traceability Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 19
  • 20. Standards : ground principles spec. test spec. test spec. test spec. test cov. cov. cov. implem. cov. implem. implem. space implem. space  Requirements, Verification, Traceability, Configuration management Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 20
  • 21. Standards : ground principles Reason theory, the « swiss cheese » Rules, Controls Initial event Errors -Design -Operations -Maintenance incident accident Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 21
  • 22. Standards : processes  « Cheese Slices Principle » in standards like DO178B Development Verification Verification of Verification Configuration Management Quality Certification Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 22
  • 23. Standards : processes Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 23
  • 24. Standards : processes System Requirements A3-2 Accuracy&Consistency A3-3 HW Compatiblity A3-4 Verifiability A3-1 Compliance A2-1,2 A3-6 Traceability A3-5 Conformance A3-7 Algorithm Accuracy High Level Requirements A4-8 Compatibility A4-9 Consitency A4-10 HW Compatiblity A4-11 Verifiability A4-12 Conformance A4-13 Partition Integrity A4-1 Compliance A4-6 Traceability A2-3,4,5 Software Architecture A5-2 Compliance A5-3 Verifiability A5-4 Conformance A5-6 Accuracy&Consitency Low Level Requirements A2-6 Source Code A5-7 Complete & Correct A2-7 A6-5 HW Compatiblity DO178B « christmas tree » Executable Object Code A4-2 A4-3 A4-4 A4-5 A4-7 Accuracy&Consistency HW Compatiblity Verifiability Conformance Algorithm Accuracy A5-1 Compliance A5-5 Traceability A6-1 Compliance A6-2 Robustness A6-3 Compliance A6-4 Robustness A7-1 Tests Correct A7-2 Results Correct A7-3,4 Reqs Coverage A7-5..8 Struct. Coverage Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 24
  • 25. Standards : requirement processes  Requirements ellicitation, definition, refinement, is key in all standards  Granularity is hard to define, but fundamental for the total effort needed for the product  Example of ATM, where this point is not clearly defined Visibility depth Traceability links SWAL4 specifications SWAL3 architecture design SWAL2 code SWAL1 executable Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 25
  • 26. Standards : design processes  Architecture has to be as simple as possible, to be demonstrable  For example, determinism allows to show, easily, that resources are sufficient It allows to prove, to show (even not formaly) It gives confidence Basics of « certification »  General principles are written, but no recommanded practices or solution are given  In DO178B/C activities (design, coding), to show that resources are sufficient (CPU, space) Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 26
  • 27. Standards : coding processes  Programming languages can be used (using their compiler) ; constraints on them are more or less strong :  EN50128 imposes languages characteristics depending on level : ex. « strong typing language » for SIL 4  DO178B gives no recommandation : there is no difference between Ada usage, and assembly usage. • Theoritically, quite all languages can be used, given some « extra demonstration » is done • for level A, demonstration of « direct traceability » bw exec. code and source code (tricky) • NB : formal languages (like SCADE) not considered as programming languages, but specification languages  Coding rules are imposed : to « filter » the « bad practices » (i.e. risky ones) Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 27
  • 28. Standards : verification processes (1/2)  Verification is fundamental  Several forms of verifications are accepted  Tests are the most accepted  But analysis and reviews are sometimes mandatory too (see « Christmas tree » of DO178B) • Peer reviews • Formal reviews • Demonstrations by analysis : – example : response times, WCET Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 28
  • 29. Standards : verification processes (2/2)  Standards defines « high level tests », « low level tests »…  => in fact, it depends of the requirement level the test is aimed to cover  DO178 imposes that only requirement based tests are recognized (no structural testing)  Note that it inderectly answers to the problem of requirements granularity Direct link requirement/ structure Requirement Req. test Struct. Coverage test mesurement Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 29
  • 30. Standards : composition (=> reuse)  Aeronautic : IMA (Integrated Modular Approach) (=> DO 297)  Principles are to make independant tests at each level + integration tests with the whole system Applicative Module Applicative Module  Problem of « Java Virtual Machine » : sort of composition ; it is helped by DO-332 (one of the DO178-C supplement) with Java (an extra-code) Applicative Module  To mix different assurance level  Platform has to be developped at highest Applicative Module  To communalise hardware and HW dependant software Executive (RTOS, BSP) Hardware Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 30
  • 31. Standards : COTS (=> reuse)  COTS (Commercial On The Shelf) problem  By definition, not very compatible with the « show me how you work and I will be confident » principle : the processes are often « black boxes »  Two solutions :  Either the vendor is interested by direct application of standards to its processes • Its COTS become a « normal certifiable software »  Either the COTS is really not compliant to the processes transparency principle • Alternative means should be found : Very difficult to be standardised (see DO278A working group history…). Alternative methods DO278A Example Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 31
  • 32. 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 32
  • 33. Industrialization  All the processes imposed by standards demands efforts  Reproductibility of processes are demanded  Certification principles ask for proofs  => solution to productivity, reproductibility and provability is to have as more as possible tooled and automated processes. Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 33
  • 34. Industrialization : Capgemini example Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 34
  • 35. Qualification des outils (1/2) Specification Design Code Specification Executable Design Tool Qualified Tool Certification Efforts Transfert Code Certification Credit Development Activity Verification Activity Verification of Verification Executable Development Tool Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 35
  • 36. Qualification des outils (2/2) Specification Certification Efforts Transfert Design Code Specification Executable Design Tool Qualified Tool Certification Credit Development Activity Verification Activity Verification of Verification Code Executable Qualified Verification Tool for embedded safety critical systems | january 2014 Software Copyright © Capgemini 2014. All Rights Reserved 36
  • 37. 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 37
  • 38. Contents 1- Software confidence principles : a brain and cheese story Page 5 2 - Regulation, Standards Page 10 3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12 4 - Common rules Page 17 5 - Industrial and tooled processes Page 33 6 - Conclusion Page 39 Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 38
  • 39. Conclusion  Formal methods will (or not) enter into processes ?  EN50128 make them mandatory for a long time  DO178-C formal Method Supplement (DO333) introduce them precisely in aeronautic  What about COTS, intensive reuse, etc. vs safety constraints ?  Cf Hardware COTS problems (example of batteries….)  Is there a schism between software approaches for safety critical software and « normal? » software ? Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 39
  • 40. The end Thank you. Any question ? Hugues Bonnin Critical Software Consultant hugues.bonnin@capgemini.com Software for embedded safety critical systems | january 2014 Copyright © Capgemini 2014. All Rights Reserved 40
  • 41. About Capgemini With more than 120,000 people in 40 countries, Capgemini is one of the world's foremost providers of consulting, technology and outsourcing services. The Group reported 2011 global revenues of EUR 9.7 billion. Together with its clients, Capgemini creates and delivers business and technology solutions that fit their needs and drive the results they want. A deeply multicultural organization, Capgemini has developed its own way of working, the Collaborative Business ExperienceTM, and draws on Rightshore ®, its worldwide delivery model. Rightshore® is a trademark belonging to Capgemini www.capgemini.com The information contained in this presentation is proprietary. © 2012 Capgemini. All rights reserved.