Aspects logiciels de la certification avionique et vérification statique : une nouvelle ère?

Transcription

1 Mai 2003 Presenté par Gérard LADIER Head of Software Methods/Quality Group Avionics & Simulation Products Airbus France Aspects logiciels de la certification avionique et vérification statique : une nouvelle ère? Jean Souyris ; Famantanantsoa Randimbivololona ; Gérard Ladier gerard.ladier@airbus.com

2 Who are we? EMPLOYEES Center of Competences for : Electronics and on board Software in real time applications Avionics and Simulation Business Center Developing and selling products Electronics : 140 Software : 200 Manufacturing : 115 Other : 220 gerard.ladier@airbus.com Mai 2003 Page 2

3 Who are we? AVIONICS Products Products / Equipment's sets A300/310 A319/20/21 DOMAINS Flight control Warnings A380 A330/340 Maintenance Communication gerard.ladier@airbus.com Mai 2003 Page 3

4 Summary Regulation Logic Equipment related regulation Means of compliance From a product to a process assessment Development Assurance Levels DO-178B/ED-12B : outlines Conclusion ; motivation for static analysis State of our practice What next? gerard.ladier@airbus.com Mai 2003 Page 4

5 Regulation Logic Aeronautics and space regulation Other aeroplanes Territories flown over Aircraft Federal Aviation Regulations Maintenance Noise Standard... Airworthiness FAR 25 - JAR 25 Joint Aviation Requirements Powerplant Structure... Equipment Powerplant instruments.... Equipment and system gerard.ladier@airbus.com Mai 2003 Page 5 FAR/JAR

6 Equipment related regulation (JAR/FAR ) The equipment, systems, and installations whose functioning is required by the JAR/FAR and national operating regulations must be designed to ensure that they perform their intended functions under any foreseeable operating conditions ( ). The aeroplane systems and associated components, considered separately and in relation to other systems, must be designed so that... "(1) The occurrence of any failure condition which would prevent the continued safe flight and landing of the aeroplane is extremely improbable "(2) The occurrence of any other failure condition which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating conditions is improbable gerard.ladier@airbus.com Mai 2003 Page 6

7 Means of compliance AMJ / AC A > acceptable means for showing compliance with the JAR : " These means are intended to provide guidance for the experienced engineering and operational judgement that must form the basis for compliance findings " An inverse relationship should exist between the probability of loss of function(s) or malfunction(s) (leading to a serious Failure Condition) and the degree of hazard to the aeroplane and its occupants arising therefrom. " It is in general not feasible to assess the number or kinds of software errors, if any, that may remain after the completion of system design, development, and test. DO-178B/ED-12B, provide acceptable means for assessing and controlling the software used to program digital-computer-based systems gerard.ladier@airbus.com Mai 2003 Page 7

8 From a product to a process assessment It is in general not feasible to assess the number or kinds of software errors, if any, that may remain after the completion of system design, development, and test. The planned & systematic actions necessary to provide adequate confidence that a product or a process satisfies given requirements So «other qualitative means should be used to establish that the system can satisfy safety objectives. Development assurance establishes confidence that the system development has been accomplished in a sufficiently disciplined manner to limit the likelihood of development errors that could impact aircraft safety» (ARP ) gerard.ladier@airbus.com Mai 2003 Page 8

9 Development Assurance Levels STEP1 Determination of Failure Condition and Associated Safety Classification Failure Condition Catastrophic Hazardous Safety objectives < 10-9 < 10-7 System DAL (Development Assurance Level) A B Major < 10-5 C STEP2 Assignment of Sub-System DAL Minor No safety effect none none D E STEP3 Determination of software item DAL for each software Software DAL and system DAL are the same (except if architectural means allow reduction) gerard.ladier@airbus.com Mai 2003 Page 9

10 DO-178B/ED-12B : outlines DO-178B/ED-12B is primarily a process-oriented document Requirements on processes : "details objectives, input, activities, outputs "no specific means or life cycle required 3 classes of processes : "Planning process (organisation/plans) "Development processes : requirement, design, coding integration "Integral processes : verification, configuration management, quality assurance, certification liaison gerard.ladier@airbus.com Mai 2003 Page 10

11 DO-178B/ED-12B : outlines Guidelines for process objectives and outputs Remember the rule : " An inverse relationship should exist between the probability of loss of function(s) or malfunction(s) (leading to a serious Failure Condition) and the degree of hazard to the aeroplane and its occupants arising therefrom. "So assurance requirements vary by software level Requirements for definition of rules and plans : " SACP, " SDP, " SVP, " CMP, " SQAP Emphasis on functional verification and assessment of coverage obtained by functional tests Requirements on tools used for the SW development (qualification). gerard.ladier@airbus.com Mai 2003 Page 11

12 Conclusion Not formally proven, but it works! Why? "A pragmatic approach (remember : "experienced engineering and operational judgement must form the basis for compliance findings ) "DO-178B/ED-12B focuses on objectives rather than on means, obsolete as soon as they are prescribed "DO-178B/ED-12B and its application take into account needs and constraints from all the people implied : Independent Certification Authority, Equipment Suppliers, Aircraft Manufacturers on a consensus basis "There must be some truth in the famous clean pipe paradigm : a clean pipe does give clean water gerard.ladier@airbus.com Mai 2003 Page 12

13 But DO 178B was released in 1992 : "In 1992, SW Engineering was 24 years old... "In 2004, SW Engineering is 50% older, as compared to 1992 Recurrent problems with test-based verification "Costs: test means and tools, test software, coverage completion "Intrinsic issues on robustness checks, determination of computerresources upper-bounds, computation safety => suboptimal architecture, resources-consuming fault-tolerance mechanisms The problems are increasing "More functions implemented in software, more sophisticated functions, new functions "Evolution of underlying hardware technology: integration level, modern processor architecture, floating-point operators gerard.ladier@airbus.com Mai 2003 Page 13

14 But DO-178B is primarily a process-oriented document ( 3.0) : The assurance on the product is gained through assurance on its processes. Not so a problem when avionics software was developed from scratch Big problem for Off The Shelf In 20xx, do not use OTS is counter-productive : "Cost No comment "Safety : what is best for safety : an OS developed by an OS specialist and used by thousands of users, or an OS developed by a Flight Warning specialist, used by 26 developers? gerard.ladier@airbus.com Mai 2003 Page 14

15 First motivation for static analysis As a consequence "Test alone will not cover all future needs in software verification "Process Based Assurance is restricted to home made software Introduction of static analysis "Main idea: all dynamic properties are «present» in the code of the program "Analyse the source code - at compilation-time - to check executiontime properties "Grounded on so-called «formal methods» An initial target "Smooth and incremental changes in operational engineering (deliberately limited impact on upstream tasks) "The A380 program opportunity gerard.ladier@airbus.com Mai 2003 Page 15

16 Properties of interest A set of independent static analysers Resources properties Real-time analyser Numerical analyser Program under analysis Functional analyser Floating-point precision properties Safety analyser Runtime error properties Data properties End-user verification methodology based on formal static analysis gerard.ladier@airbus.com Mai 2003 Page 16

17 A new generation of static analysers Well-founded on scientific theory "Abstract interpretation "Hoare logic Proof-oriented "Exhaustive and precise check "Sound (no error miss) Priorities "Safety-critical software "Hard realtime constraints guarantee A pragmatic orientation "Early payback "Support partial implementation gerard.ladier@airbus.com Mai 2003 Page 17

18 Functional properties CAVEAT tool based on Hoare logic "Low level requirements checks "Automatic theorem proving + interactive proof-assistant Specification Validation testing Design architecture Integration testing Precond: true int find(int tab, int size, int elt) Static design LL requirements Coding Unit proof gerard.ladier@airbus.com Mai 2003 Page 18 { }.. Postcond: (find = 1) ( i: i 0 i<size:tab[i]=elt) (find = 0) ( i: i 0 i<size:tab[i]=elt)

19 Computation safety properties ASTREE tool based on abstract interpretation "Prove the absence of runtime errors on synchronous program "Fully automatic, zero false alarm Specification Design architecture Validation level checks Integration testing Whole program > 120,000 loc: Numeric overflow, Array bound check,. Static design LL requirements Unit proof Coding Mai 2003 Page 19

20 Resources properties AiT and Stack tools based on abstract interpretation "Stack for execution stacks upperbounds "AiT for Worst-case Execution Time "Both analyse the binary executable code Specification Design architecture Validation level checks Integration testing Whole binary code of a > loc program Stack usage Stack upperbound WCET value WCET upperbound Static design LL requirements Coding Unit proof gerard.ladier@airbus.com Mai 2003 Page 20

21 Floating-point precision properties FLUCTUAT based on abstract interpretation "Quality of Floating point calculus "At source (with some care) and assembly code level "First targets: basic SCADE operators and data acquisition and filtering functions Specification Validation level checks Data acquisition and filtering functions: about 1000 loc each Design architecture Integration testing Static design LL requirements Coding Unit proof SCADE operators: 10 to 100 loc each Mai 2003 Page 21

22 More details on static analysers CAVEAT and FLUCTUAT [CEA Laboratory: www-drt.cea.fr] ASTREE [ENS Laboratory: AiT, Stack [Absint Company: Mai 2003 Page 22

23 So Current status "Introduction of static analysis well accepted If clear and concrete benefits If local impacts on activities and processes "Positive first feedbacks from partial implementation on A380 "And our American colleagues are also becoming fans : «Extended static analysis» such as abstract interpretation, model checking, and theorem proving are now used on an industrial scale. There are strong signs of a «new golden age» for SV See gerard.ladier@airbus.com Mai 2003 Page 23

24 what next? Extension of tools (classes of properties, classes of software) And then, THE question arises : will we be able to get sufficient confidence on the product itself to get rid of Process Based Assurance for software aspects of certification? The ASBAPROD (ASsurance BAsée PRODuit) project is aimed to answer to this simple question, split in several ones : "Are we able to define all the properties of a software relevant to safety and function (>completeness)? "Without any execution of the software (>exhaustiveness)? "Automatically? "Can we separate the characterization cycle (certification) and the development cycle? gerard.ladier@airbus.com Mai 2003 Page 24

25 The ASBAPROD main tasks (1/2) Extension of tools set : "Run-Time errors detection analyser : extension to asynchronous multitasks software "Proof of functional properties tool : Extended to address more complex algorithms Extended to enable integration proof thanks to composition of unit proofs "Floating Point Calculus precision analyser development "Development of a Memory Violation analyser of multitasks programs "Task scheduling analyser "Proof of translation/compilation between a C code and its generated code. gerard.ladier@airbus.com Mai 2003 Page 25

26 The ASBAPROD main tasks (2/2) Evolution of verification methods : "Classification/formalisation of relevant properties in order to select adequate tools "Study of links between analysis of structural code coverage and proof of properties "Approach for proof by combination of unit proofs Propositions for a software aspects of certification process focusing on the product, hopefully taken into account by the future DO-178C See you in AFADL 2008 for the results! gerard.ladier@airbus.com Mai 2003 Page 26

27 Mai 2003 Page 27

28 Example of a DO-178B requirement Applicability Control Objective Output category by SW by SW level level description Ref A B C D Description Ref. A B C D 3 Test coverage of high level requirement is achieved Software verification results Requirements-Based Test Coverage Analysis ➋ ➋ ➋ ➋ The objective of this analysis is to determine how well the requirements-based testing verified the implementation of the software requirements. This analysis may reveal the need for additional requirements-based test cases. The requirements-based test coverage analysis should show that: a. Test cases exist for each software requirement. b. Test cases satisfy the criteria of normal and robustness testing as defined in paragraph gerard.ladier@airbus.com Mai 2003 Page 28

29 DO178B - Variations according to levels Levels A and B very close "same number of objectives (except one dealing with structural coverage) "differentiation is mainly based on degree of independence required to satisfy the process's objectives (40 % with independence for level A, 20% for level B) Level C ~ 85 % of A/B levels (number of objectives) "Variation is mainly on the design process and on structural coverage Level D ~ 50 % of level C (number of objectives) "Nearly no requirement left on design, coding, and verification Level E : No requirement " "one software has been confirmed as level E by the certification authority" gerard.ladier@airbus.com Mai 2003 Page 29

30 Ce document et son contenu sont la propriété d AIRBUS FRANCE S.A.S. Aucun droit de propriété intellectuelle n est accordé par la communication du présent document ou son contenu. Ce document ne doit pas être reproduit ou communiqué à un tiers sans l autorisation expresse et écrite d AIRBUS FRANCE S.A.S. Ce document et son contenu ne doivent pas être utilisés à d autres fins que celles qui sont autorisées. Les déclarations faites dans ce document ne constituent pas une offre commerciale. Elles sont basées sur les postulats indiqués et sont exprimées de bonne foi. Si les motifs de ces déclarations n étaient pas démontrés, AIRBUS FRANCE S.A.S serait prêt à en expliquer les fondements. gerard.ladier@airbus.com Mai 2003 Page 30