20140121 cisec-safety criticalsoftwaredevelopment
DESCRIPTION
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.TRANSCRIPT
Software for embedded safety critical systems
Toulouse, january 2014
Hugues Bonnin
Seminar CISEC
2013/2014
cesic cesic 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)
Plus d’information à http://asso-cisec.org
3 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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 .
4 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
5 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
6 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Principles : software is everywhere
7 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Principles : software complexity increases
4KB - Concorde
23KB - A300B
200KB - A300FF
2MB - A310 5MB - A320
12MB - A330/A340
1 GLOC - A380
1
10
100
1000
10000
100000
1000000
1960 1970 1980 1990 2000 2010
Software Size
8 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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 ?
9 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Principles : the bibles
DO178(B,C)
/ED12(B,C)
EN50128
ED153 ECSS-Q-ST-80-C
ISO 26262-chap6 …
10 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
11 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Regulation & Standards short story
ICAO
Navigabilité
CS25
Circulation
Aérienne
CS25-1309
EC
482/2008
ARP-4754 DO-
178(B,C)
SES
DO-278(-,A)
(See course chapter 2
« standards »)
12 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
13 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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.
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) :
(See course chapter 1
« avionic systems »)
Criticallity Software
level
Catastrophic A
Hazardous B
Major C
Minor D
DO178(B,C) approach ED153 approach
Accident
Serious
incident
Major
incident
Significant
incident
1 2 3 4
Very Possible SWAL1 SWAL2 SWAL3 SWAL4
Possible SWAL2 SWAL3 SWAL3 SWAL4
Unlikely SWAL3 SWAL3 SWAL4 SWAL4
Very Unlikely SWAL4 SWAL4 SWAL4 SWAL4
Effect severity class
likelyhood of
generating
such an effect
14 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Level and System : different scales of level
CNS/ATM CNS/ATM
Aeronautical
embedded
software
other domains
(nuclear,
railway...)
ESARR, SAM,
ECxxED109/ DO278
ED12B/
DO178B
IEC 61508,
EN 50128...
SWAL 1 AL 1 A SIL 4
AL 2 B SIL 3
SWAL 2 AL 3 C SIL 2
SWAL 3 AL 4
SWAL 4 AL 5 D SIL 1
AL 6 E
15 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Level and System : « feedback » to system level
SYSTEM LIFE CYCLE PROCESSES
System Requirements
Allocated to S/W
S/W levels
Design Constraints
SOFTWARE LIFE CYCLE PROCESSES
Derived Requirements
Error Sources
Identified/Eliminated
Partitioning, ROM,
RAM size, CPU, redundancy
System Safety Assessment Process
EAR/JAR/FAR
Airworthiness
requirements
System Operational
requirements
DO178(B,C) approach
16 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Level and system : examples of software level
ED109*/AL 4 : Display in ATM
EN50128/SIL4 : Railway odometer of ERTMS
DO178B/Level C : FMS
DO178B/Level B : BSCU
17 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
18 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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 »
19 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Standards : ground principles
Requirements, Verification, Traceability
Requirements
Implementation
Verification
Verification measure
Development Activity
Verification Activity
Verification of Verification
Traceability
20 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
space
space
spec.
implem.
test
cov.
spec.
implem.
test
cov.
spec.
implem.
test
cov.
Standards : ground principles
spec.
implem.
test
cov.
Requirements, Verification, Traceability, Configuration management
21 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Standards : ground principles
Errors -Design
-Operations
-Maintenance
Rules, Controls
accident
Initial event
incident
Reason theory, the « swiss cheese »
22 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Standards : processes
« Cheese Slices Principle » in standards like DO178B
Development Verification Verification
of Verification
Configuration Management
Quality Certification
23 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Standards : processes
24 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Standards : processes
DO178B « christmas tree » Executable Object Code
A2-7
Source Code
A2-6
Low Level Requirements
Software Architecture
A2-3,4,5
High Level Requirements
A2-1,2 A3-1 Compliance
A3-6 Traceability
A4-1 Compliance
A4-6 Traceability
A4-3 HW Compatiblity
A4-2 Accuracy&Consistency
A4-4 Verifiability
A4-5 Conformance
A4-7 Algorithm Accuracy
A5-1 Compliance
A5-5 Traceability
A6-1 Compliance
A6-2 Robustness
A6-3 Compliance
A6-4 Robustness
A7-2 Results Correct
A7-1 Tests Correct
A7-3,4 Reqs Coverage
A7-5..8 Struct. Coverage
A4-8 Compatibility
A4-10 HW Compatiblity
A4-11 Verifiability
A4-12 Conformance
A4-9 Consitency
A4-13 Partition Integrity
A5-2 Compliance
A5-3 Verifiability
A5-4 Conformance
A5-6 Accuracy&Consitency
A5-7 Complete & Correct
A6-5 HW Compatiblity
A3-2 Accuracy&Consistency
A3-3 HW Compatiblity
A3-4 Verifiability
A3-5 Conformance
A3-7 Algorithm Accuracy
System Requirements
25 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
SWAL4
SWAL3
specifications
architecture design
Traceability links
SWAL2
SWAL1
code
executable
Visibility
depth
26 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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)
27 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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)
28 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
29 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
Requirement
Req. test
Struct. Coverage test mesurement
Direct link requirement/ structure
30 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Standards : composition (=> reuse)
Aeronautic : IMA (Integrated Modular Approach) (=> DO 297)
To communalise hardware and HW dependant software
App
licative
Module
Executive (RTOS, BSP)
Applic
ative
Module
Applic
ative
Module
Applic
ative
Mo
dule
Hardware
To mix different assurance level
Platform has to be developped at highest
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)
Principles are to make independant tests at each level + integration tests with the whole system
31 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
32 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
33 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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.
34 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Industrialization : Capgemini example
35 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Certification Credit
Tool
Qualification des outils (1/2)
Executable
Code
Design
Specification
Qualified Tool
Executable
Code
Design
Specification
Certification Efforts Transfert
Development Activity
Verification Activity
Verification of Verification
Development Tool
36 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
Tool
Qualification des outils (2/2)
Qualified Tool
Executable
Code
Design
Specification
Certification Efforts Transfert
Development Activity
Verification Activity
Verification of Verification Qualified Verification Tool
Executable
Code
Design
Specification
Certification Credit
37 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
38 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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
39 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
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 ?
40 Copyright © Capgemini 2014. All Rights Reserved
Software for embedded safety critical systems | january 2014
The end
Thank you. Any question ?
Hugues
Bonnin Critical Software Consultant
The information contained in this presentation is proprietary.
© 2012 Capgemini. All rights reserved.
www.capgemini.com
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