An Airbus A340 experimentation with formal verification techniques

1
An Airbus A340 experimentation with formal
verification techniques
Odile Laurent
AIRBUS FRANCE
2
Scope

• 1. Introduction context and aim
• 2. Method and tools
• 3. Brief description of the case study
• 4. Main results
• 5. Conclusion

3
Objectives

• Industrial context
• Growing complexity of aircraft
• Verification and validation very costly
• Formal methods already used at AIRBUS FRANCE for
  the design of embedded systems
• Major aim of the study
• Study if formal verification techniques can be
  used to reduce the verification effort
• Industrial context real case study, operational
  way

4
System development life cycle
5
Desktop simulator overview
6
Impact on the verification activities
SCADE Spécifications
Properties
Verification process (simulation, tests)
formal verification
Elimination of verification activities related
to proven properties
Proven properties
Counter-examples
7
Method

• Identification of properties
• On inputs / outputs of the system (or subsystems)
  
• By means of
• Analysis of specification documents, validation
  plan
• Discussions with designers
• Formal expression of properties
• In Lustre or SCADE
• Verification
• On the SCADE specification
• Using verification tools

8
Tools

• Choice criteria
• Able to handle Lustre
• Easy to use
• Lesar
• Model checker associated to Lustre
• Developed by Verimag
• NP-tools
• Prover for propositional logic developed by
  Prover Technology
• Lucifer translator for Lustre
• SCADE Prover (beta version)
• Commercial proof engine for SCADE environment

9
Case study The A340 500/600 Flight Control
System
10
Case Study

• FCSC Flight Control Secondary Computer
• - part of the flight control system including
  five digital computers 3 primary computers
  (FCPC) and 2 secondary computers (FCSC)
• - functions monitoring, logic, flight laws
  actuators, servo loop
• - two computation units (COM/MON) which are
  physically and electrically distinct
• - ARINC buses between the different flight
  control computers systems and the different units
• Detailed specification main characteristics
• - formal specification in SCADE language
  (graphical representation for LUSTRE)
• - many reused parts defined in a functions
  library
• - about 350 sheets per unit

11
Properties

• Redundancy property (Prop1)
• left Aileron if (P1 and P2 are not active)
  then S1 becomes active
• P1 ? P2
• S1 ? S2
• Safety properties
• (Prop2)
• There is always one side stick that is active
  (detected unfailed by at least one computer)
• Hypothesis the two side sticks cannot fail to
  sensor pilot order at the same time
• (Prop3)
• If any primary flight control computer is active
  then the pilot commands must be effective

12
Main encountered problems

• Identification of properties sometimes difficult
• Requirements not always explicit
• From scenarios to property (define the test
  objective)
• Identification of the sub-system
• Real values
• Not handled by NP-tools
• Ad hoc solutions (translation to integers,
  abstraction)
• Symbols
• Inserted C code
• Translation into Lustre or SCADE
• Abstracted by assertions (different levels of
  complexity)

13
Main results

• Tools results
• lesar
• Prop1 and Prop2 proved
• NP-Tools with Lucifer
• Prop1 and Prop2 proved
• SCADE Prover (beta version)
• Prop3 falsifiable specification error
  found with the counter example ( this
  specification error has already been identified
  by testing activities on the iron bird)
• A first methodological approach has been defined

14
Methodology
15
CONCLUSION

• Formal verification techniques can be used in an
  operational environment but cannot fully replace
  simulation and integration tests activities
• Formal verification tools may be deployed for
  future programmes
• future work about formal proof
• to study the benefit for automatically generating
  test cases from properties
• objective to ease the integration tests
  definition for the iron bird