Formal Method for Avionics Software Verification

31
Open-DO Conference Combining Formality with Agility for Critical Software D evelopment March 2010 Formal Method for Avionics Software Verification From a real use for Airbus aircrafts to the integration in ED-12C/DO-178C Open-DO Conference Combining Formality with Agility for Critical Software Presented by Hervé Delseny Head of Software Process Definition and Follow-up Expert in Software Aspects of Certification Avionics and Simulation Products Airbus

description

This talk will give examples of Airbus use of Formal Methods to verify avionics software, and summarises the integration of Formal Methods in the upcoming ED-12/DO-178 issue C. Firstly, examples of verification based on theorem proving or abstract interpretation will show how Airbus has already taken advantage of the use of Formal Methods to verify avionics software. Secondly, we will show how Formal Method for verification has been introduced in the upcoming issue C of ED-12/DO-178.

Transcript of Formal Method for Avionics Software Verification

  • 1. Formal Method for Avionics Software Verification From a real use for Airbus aircrafts to the integration in ED-12C/DO-178COpen-DO Conference Combining Formality with Agility for Critical Software Presented by Herv Delseny Head of Software Process Definition and Follow-up Expert in Software Aspects of Certification Avionics and Simulation Products Airbus

2. Formal Method : Advantages

  • Improvedunderstandingof a computer programs specifications
  • More accuracyandless ambiguity
  • Proofverification of a programs conformity with respect to its specification
  • Proof isexhaustive
    • all of the programs behaviours meet the property
    • property is proved for all possible input combinations.

3. Formal Method on A380

  • 1 sttype :Proof of genericproperties
    • WCET computation
    • Stack consumption computation
    • And next to come :
    • Precision of Floating-point calculus
    • Proof of absence of Run Time Errors
  • 2 ndtype :Unit Proof of functional properties
    • Instead of Unit Tests.

4. Formal Method on A380 : 1 stType

  • aiTfor WCET computation
    • Developed by Absint ( www. absint .com )
    • Abstract Interpretation based
    • Analysis of binary code; Model of the CPU & Chipset
    • Worst Case Execution Time computation of programs
    • Used for DO-178B level A software
  • Stackanalyzerfor stack consumption computation
    • Developed by Absint ( www. absint .com )
    • Abstract Interpretation based
    • Analysis of binary code
    • Tighter maximum stack usage computation
    • Used for DO178B level A, B and C software.

5. Formal Method :1 stTypeNext to come

  • Fluctuat: precision of Floating-point calculus
    • Developed by CEA, the French nuclear research center
    • Abstract Interpretation based
    • Analysis of C or assembly code
    • Safe computation of the numerical (rounding) errors introduced by basic operators or input filtering code
  • Astre: proof of absence of Run Time Errors
    • Developed by ENS (Pr.Cousots team at Ecole normale suprieure de Paris)
    • Abstract Interpretation based
    • Analysis of C code
    • Proof of absence of RTE like division by zero, numerical overflow, out of bounds access to an array.

6. Formal Method on A380 :2 ndTypeUnit Proof

  • Caveatfor Unit Proving
    • Developed by CEA, the French nuclear research center
    • Deductive method; Weakest Precondition
    • Analysis of C code
    • DO178B Level A
    • Verification of compliance to Low Level Requirements in replacement of Unit Testing.

7. Formal Method on A380 : Unit Proof

  • A Caveat property is based on first order predicates :
    • Boolean expressions ( , , , , ), Relational operators ( , , , , ),Arithmetic expressions ( +, -, , /, ),Quantifiers ( , )
  • A Caveat property defines a relation between input operand(s) and /or output operand(s) of the service
  • Objectives
    • Reduce costs of software verification without compromising the effectiveness of the verification
  • Solution selected
    • Definition of low-level requirements (LLR) using formal properties (design)
    • Unit proof verification supported by the CAVEAT tool, which replaces the unit test activity.

8. Formal Method on A380 : Unit Proof Design

  • LLR composed by :
    • properties
    • data-control flows
    • mapping constraint
    • timing constraint
  • Pseudo-code

Coding

  • Code production based on LLR
  • verification of mapping constraint (reading of source code)

Unit Proofs

  • Verification of compliance of C-source to properties (LLR)
  • Automatic verification of the data/control flow

Integration

  • Functional verification of HLR
  • Verification of timing constraint (LLR)
  • Verification of mapping constraint (reading of linking file)

Subset Specification

  • HLR

9. Formal Method on A380 : Unit Proof - Definition of proof environment - Flows Generation Verificationof Flows against Design Proof performing Analysis of Proof Results Design Phase Data & control flows Caveat Caveat Flows Code compliantWith Design Coding Phase C Source Functional Properties Caveat Process Management Tool Caveat is integrated into the process management tool to automate the proof process If OK If not OK 10. Formal Method on A380 :Conclusions

  • Static verification and formal method are :
    • Cheaperfor the same or even better level of quality, compared to the traditional testing approach
    • Industrially applicablenow:tools are available
  • Our vision :
    • Extendthe use offormal proofto a wider functional area
    • Extendthe use ofstatic verificationtools for Run Time errors,
    • Apply theFormal Method supplementof DO-178C.

11. DO-178C Formal Method Supplement

  • Enablethe use of Formal Method in place of conventional methods by
    • Providingguidanceon how to use Formal Method
      • Modifying existing objectives
      • Defining new objectives
      • Describing needed activities
      • Describing evidence to meet objectives
    • Givinginformationon the fundamentals of Formal Methods
    • Dealing with Formal Methodspecific characteristics
  • Lets go deeper in this supplement

12. FM supplement

  • Appliesonlywhencredit is soughtfrom formal method to reach verification objectives

Givesguidancefor planning, development and verification processes

  • Motivates to use formal methods:
    • More formalism (syntax and semantics)
    • Implies more completeness, more correctness, more accuracy, more consistency,
    • Improves communication between engineers
    • But still requires verifications.

13. What is a Formal Method ?

  • Descriptivenotationsandanalyticalmethods used to construct, develop and reason about mathematical models of system behavior

Aformal methodis aformal analysiscarried out on aformal model. Formal Method Formal model Formal Analysis 14. What is a Formal Model ?

  • A model isan abstract representation of a given set of aspects of a system that is used for analysis, simulation, code generation, or any combination thereof

Aformal notationis a notation having aprecise ,unambiguous ,mathematicallydefinedsyntaxandsemantics . Aformal modelis a model defined using aformal notation Formal Method Formal model Formal Analysis 15. What is a Formal Analysis ?

  • The use ofmathematicalreasoning to guarantee that properties arealwayssatisfied byaformal model.

Formal Analysis Formal Method Formal model 16. Notion of property

  • Properties are the formalization of requirements:
    • Functional requirements
      • Check of a flash zone:
        • verify that the whole Flash zone is initialized to value0xFF,
        • if a memory location is different from 0xFF, the check has failed
    • Or
    • Non functional requirements
      • No over sizing of stack use during execution
      • No over timing of CPU use during execution
      • No runtime errors like 0 division

17. Being Sound

  • A method isformalif it has asoundmathematical basis, typically realized by a formal notation:

A sound methodnever assertthat aproperty is truewhenit is not. Formal model of the requirements Formal Analysis OK X Not Sound 18. Conservative representation

  • When a formal model is created from an informal item to do a formal analysis

We need to be sure thatwhatever is proved about the formal model also applies to what is modeled . Then review or analysis should be used to demonstrate that the formal statement is aconservative representationof the informal requirement Requirements Formal model of the requirements Formal Analysis Results 19. DO-178/ED-12 Verification Process System Requirements High-Level Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements ComplianceRobustness Compatible With Target ComplianceRobustness Accuracy & ConsistencyHW CompatibilityVerifiability ConformanceAlgorithm Accuracy VerifiabilityConformance Accuracy & Consistency Complete & Correct ComplianceTraceability Architecture Compatibility ComplianceTraceability Compliance ComplianceTraceability Accuracy & Consistency HW CompatibilityVerifiabilityConformanceAlgorithm Accuracy Consistency HW CompatibilityVerifiabilityConformancePartition Integrity 20. FM Supplement : Formal verification

  • Formal Analysis might replace :
    • Review and analysis objectives.

21. FM Supplement :Formal verification instead of reviews HLRFormalHLR Accuracy & ConsistencyHW CompatibilityVerifiability ConformanceAlgorithm Accuracy Accuracy & ConsistencyHW CompatibilityVerifiability ConformanceAlgorithm Accuracy System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements When HLR are formaly expressed Formal analysis can be used VerifiabilityConformance Accuracy & Consistency Complete & Correct ComplianceTraceability Architecture Compatibility ComplianceTraceability Compliance ComplianceTraceability ComplianceRobustness Compatible With Target ComplianceRobustness Accuracy & Consistency HW CompatibilityVerifiabilityConformanceAlgorithm Accuracy Consistency HW CompatibilityVerifiabilityConformancePartition Integrity 22. FM Supplement :Formal verification instead of reviews HLRFormalHLR Accuracy & ConsistencyHW CompatibilityVerifiability ConformanceAlgorithm Accuracy System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements When HLR and LLR are formaly expressed Formal analysis can be used FormalLLR ComplianceTraceability VerifiabilityConformance Accuracy & Consistency Complete & Correct ComplianceTraceability Architecture Compatibility ComplianceTraceability Compliance ComplianceTraceability ComplianceRobustness Compatible With Target ComplianceRobustness Accuracy & Consistency HW CompatibilityVerifiabilityConformanceAlgorithm Accuracy Consistency HW CompatibilityVerifiabilityConformancePartition Integrity 23. FM Supplement : Formal verification

  • Formal Analysis might replace :
    • Review and analysis objectives
    • Conformance tests versus HLR & LLR
    • Robustness tests
  • In that case the structural coverage objectives are achieved if it can be demonstrated that:
    • Each requirements is completely covered
    • The set of requirements is complete in regards of the attended function
    • There is no non expected dependencies between output and input data
    • There is no dead code.

24. FM Supplement :Formal verification for EOC HLRAccuracy & ConsistencyHW CompatibilityVerifiability ConformanceAlgorithm Accuracy System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements When LLR are formaly expressed with a conservative representation between code and EOC, then Formal analysis can be used to replace some tests FormalLLR ComplianceTraceability X VerifiabilityConformance Accuracy & Consistency Complete & Correct ComplianceTraceability Architecture Compatibility ComplianceTraceability Compliance ComplianceTraceability ComplianceRobustness Compatible With Target ComplianceRobustness Accuracy & Consistency HW CompatibilityVerifiabilityConformanceAlgorithm Accuracy Consistency HW CompatibilityVerifiabilityConformancePartition Integrity Conservative representation 25. FM Supplement : Formal verification

  • Formal Analysis might replace :
    • Review and analysis objectives
    • Conformance tests versus HLR & LLR
    • Robustness tests
  • Formal Analysis might help for verification of compatibility with the hardware.

26. FM Supplement :Formal verification for EOC HLRAccuracy & ConsistencyHW CompatibilityVerifiability ConformanceAlgorithm Accuracy System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compatible With Target Properties might be proved directly on EOC : WCET, Stack usage, Compatible With Target VerifiabilityConformance Accuracy & Consistency Complete & Correct ComplianceTraceability Architecture Compatibility ComplianceTraceability Compliance ComplianceTraceability ComplianceRobustness ComplianceRobustness Accuracy & Consistency HW CompatibilityVerifiabilityConformanceAlgorithm Accuracy Consistency HW CompatibilityVerifiabilityConformancePartition Integrity 27. FM Supplement : Formal verification

  • Formal Analysis might replace :
    • Review and analysis objectives
    • Conformance tests versus HLR & LLR
    • Robustness tests
  • Formal Analysis might help for verification of compatibility with the hardware
  • Formal Analysis cannot replace HW/SW integration tests
  • Therefore testing will always be required.

28. To conclude

  • Static verification and formal method are :
    • Cheaperfor the same or even better level of quality, compared to the traditional testing approach
    • Industrially applicablenow:tools are available
    • Guidance will soon exist with the Formal Method supplement of DO-178C
    • Therefore no more breakers for using Formal Method for avionics software.

29. Special thanks to

  • Airbus Formal Method team members:
    • Jean Souyris&David Delmas
  • The Formal Method team of DO-178C committee:
    • All the SubGroup 6 of SC205/WG71 committee, and especially the chairmen
    • Duncan Brown(Aero Engine Control)
    • Kelly Hayhurst(NASA Langley Research Center)
  • Virginie Wiels(ONERA) my coach in Formal Method

30. 31. AIRBUS OPERATIONS S.A.S. All rights reserved. Confidential and proprietary document. This document and all information contained herein is the sole property of AIRBUS OPERATIONS S.A.S. No intellectual property rights are granted by the delivery of this document or the disclosure of its content. This document shall not be reproduced or disclosed to a third party without the express written consent of AIRBUS OPERATIONS S.AS. This document and its content shall not be used for any purpose other than that for which it is supplied. The statements made herein do not constitute an offer. They are based on the mentioned assumptions and are expressed in good faith. Where the supporting grounds for these statements are not shown, AIRBUS OPERATIONS S.A.S will be pleased to explain the basis thereof. AIRBUS, its logo, A300, A310, A318, A319, A320, A321, A330, A340, A350, A380, A400M are registered trademarks.