20140121 cisec-safety criticalsoftwaredevelopment

Seminar CISEC
2013/2014

Software for
embedded safety
critical systems
Toulouse, january 2014
Hugues Bonnin

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)

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

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


4


Page 5


Page 10

3 - Assurance level (SWAL, AL, SIL…) and System relationship Page 12
4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


5

Principles : software is everywhere


6

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


7

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 ?

8

Principles : the bibles
DO178(B,C)
/ED12(B,C)
ISO 26262-chap6

…

ECSS-Q-ST-80-C

EN50128

ED153


9


Page 5


Page 10

4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


10

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 »)


11


Page 5


Page 10

4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


12

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

13

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


14

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

15

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

16


Page 5


Page 10

4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


17

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 »


18


Requirements

Verification

Verification
measure

Implementation

 Requirements, Verification, Traceability

Development Activity
Verification Activity
Verification of Verification
Traceability


19


spec.

test

spec.

test

spec.

test

spec.

test

cov.
cov.

cov.
implem.

cov.

implem.
implem.

space

implem.

space

 Requirements, Verification, Traceability, Configuration management

20

Reason theory, the « swiss cheese »
Rules, Controls

Initial event
Errors
-Design
-Operations
-Maintenance

incident
accident

21

Standards : processes
 « Cheese Slices Principle » in standards like DO178B

Development

Verification

Verification
of
Verification

Configuration
Management

Quality

Certification


22



23

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-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

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

24

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


25

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)

26

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)

27

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


28

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

29

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


30

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

31


Page 5


Page 10

4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


32

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.


33

Industrialization : Capgemini example


34

Qualification des outils (1/2)
Specification

Design

Code

Specification

Executable

Design

Tool
Qualified Tool

Certification
Efforts
Transfert

Code

Certification
Credit

Executable
Development Tool

35

Qualification des outils (2/2)
Specification

Certification
Efforts
Transfert

Design

Code
Specification

Executable
Design

Tool
Qualified Tool

Certification
Credit


Code

Executable

Qualified
Verification Tool for embedded safety critical systems | january 2014
Software

36


Page 5


Page 10

4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


37

Contents


Page 5


Page 10

4 - Common rules

Page 17


Page 33

6 - Conclusion

Page 39


38

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 ?


39

The end

Thank you.
Any question ?
Hugues
Bonnin
Critical Software Consultant
hugues.bonnin@capgemini.com


40

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.

20140121 cisec-safety criticalsoftwaredevelopment

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (15)

Similaire à 20140121 cisec-safety criticalsoftwaredevelopment

Similaire à 20140121 cisec-safety criticalsoftwaredevelopment (20)

Plus de CISEC

Plus de CISEC (9)

Dernier

Dernier (20)

20140121 cisec-safety criticalsoftwaredevelopment