20140121 cisec-safety criticalsoftwaredevelopment

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

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 .



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



1- Software confidence principles : a brain and cheese story








Principles : software is everywhere



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



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 ?



Principles : the bibles

DO178(B,C)

/ED12(B,C)

EN50128

ED153 ECSS-Q-ST-80-C

ISO 26262-chap6 …




2 - Regulation, Standards







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






3 - Assurance level (SWAL, AL, SIL…) and System relationship






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




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



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



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






4 - Common rules





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 »




Requirements, Verification, Traceability

Requirements

Implementation

Verification

Verification measure

Development Activity

Verification Activity

Verification of Verification

Traceability



space

space

spec.

implem.

test

cov.

spec.

implem.

test

cov.

spec.

implem.

test

cov.


spec.

implem.

test

cov.

Requirements, Verification, Traceability, Configuration management




Errors -Design

-Operations

-Maintenance

Rules, Controls

accident

Initial event

incident

Reason theory, the « swiss cheese »



Standards : processes

« Cheese Slices Principle » in standards like DO178B

Development Verification Verification

of Verification

Configuration Management

Quality Certification




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


A3-2 Accuracy&Consistency


A3-4 Verifiability

A3-5 Conformance

A3-7 Algorithm Accuracy

System Requirements



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



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)



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)



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



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



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



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



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.



Industrialization : Capgemini example



Certification Credit

Tool

Qualification des outils (1/2)

Executable

Code

Design

Specification

Qualified Tool

Executable

Code

Design

Specification

Certification Efforts Transfert



Verification of Verification

Development Tool



Tool

Qualification des outils (2/2)

Qualified Tool

Executable

Code

Design

Specification

Certification Efforts Transfert



Verification of Verification Qualified Verification Tool

Executable

Code

Design

Specification

Certification Credit



Contents









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 ?



The end

Thank you. Any question ?

Hugues

Bonnin Critical Software Consultant

[email protected]

mailto:[email protected]

mailto:[email protected]

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

http://www.facebook.com/Capgemini

http://www.linkedin.com/company/capgemini

http://www.twitter.com/capgemini

http://www.youtube.com/capgemini

http://www.slideshare.net/capgemini

20140121 cisec-safety criticalsoftwaredevelopment

Technology

Transcript of 20140121 cisec-safety criticalsoftwaredevelopment