FOCUS: SAFETY-CRITICAL SOFTWARE The current version, called DO- Testing or Formal 178B,1 has been quite successful, with no fatalities attributed to faulty imple- mentation of software requirements since the standard’s introduction in Verification: 1992. However, the cost of complying with it is significant: projects can spend DO-178C Alternatives up to seven times more on verification than on other development activities.2 The complexity of avionics software and Industrial Experience has also increased to the point where many doubt that current verification techniques based on testing will be suf- Yannick Moy, AdaCore ficient in the future.3 This led the avi- onics industry to consider alternative Emmanuel Ledinot, Dassault-Aviation means of verification during the DO- 178B revision process. The new stan- Hervé Delseny, Airbus dard, DO-178C,1 includes a supplement on formal methods (see the “What Are Virginie Wiels, ONERA Formal Methods?” sidebar), known as DO-3334, which states the following: Benjamin Monate, TrustMySoft Formal methods might be used in a very selective manner to partially ad- // Software for commercial aircraft is subject to stringent dress a small set of objectives, or might certification processes described in the DO-178B standard, be the primary source of evidence for the satisfaction of many of the objec- Software Considerations in Airborne Systems and Equipment tives concerned with development and Certification. Issued in late 2011, DO-178C allows formal verification. verification to replace certain forms of testing. Dassault-Aviation Although this permission to replace and Airbus have successfully applied formal verification part of testing with formal verification early on as a cost-effective alternative to testing. // is quite new, we’ve successfully applied this new guidance into a production- like environment at Dassault-Aviation and Airbus. The use of formal verifi- cation for activities previously done by testing has been cost-effective for both companies, by facilitating maintenance leading to gains in time on repeated activities. Formal Verification AVIONICS IS THE canonical example software, DO-178 and its equivalent in at the Source-Code Level of safety-critical embedded software, Europe, ED-12, which are known ge- DO-178 requires verification activities where an error could kill hundreds of nerically as DO-178. The standard pro- to show that a program in executable people. To prevent such catastrophic vides guidance—objectives as well as form satisfies its requirements (see Fig- events, the avionics industry and regu- associated activities and data—concern- ure 1). For some requirements, verifica- latory authorities have defined a strin- ing various software life-cycle processes, tion, which can include formal analysis, gent certification standard for avionics with a strong emphasis on verification. can be conducted directly on the binary 50 IEEE SOFTWARE | PUBLisHED BY THE IEEE COMPUTER SOCieTY 0740-7459/13/$31.00 © 2013 IEEE s3moy.indd 50 4/2/13 11:33 AM representation. For example, Airbus uses formal analysis tools to compute WHAT ARE FORMAL the worst case execution time (WCET) and maximum stack usage of execut- METHODS? ables.5 For many other requirements, According to RTCA DO-333, formal methods are mathematically based techniques for such as datafl ow and functional prop- the specifi cation, development, and verifi cation of software aspects of digital systems. erties, formal verifi cation is only feasi- The fi rst work on formal methods dates back to the 1960s, when engineers needed to ble via the source-code representation. prove the correctness of programs. The technology has evolved steadily since then, ex- DO-178 allows this approach, provided ploiting computing power that has increased exponentially. In DO-333, a formal meth- the user can demonstrate that proper- od is defi ned as “a formal model combined with a formal analysis.” A model is formal ties established at the source level still if it has unambiguous, mathematically defi ned syntax and semantics. This allows auto- hold at the binary level. The natural mated and exhaustive verifi cation of properties using formal analysis techniques, which way to fulfi ll this objective is to show DO-333 separates into three categories: deductive methods such as theorem proving, that requirements at source-code level model checking, and abstract interpretation. Today, formal methods are used in a wide are traceable down to the object-code range of application domains including hardware, railway, and aeronautics. level.6,7 Demonstrating traceability be- tween source and object code is greatly System requirements • Accuracy and consistency • Compatibility with the target computer • Compliance • Veriability • Traceability • Conformance to standards • Algorithm accuracy High-level requirements • Consistency • Accuracy and consistency • Compatibility with the target computer • Compatibility with the target computer • Veriability • Compliance • Veriability • Conformance to standards • Compliance • Traceability • Conformance to standards • Partitioning integrity • Algorithm accuracy Design Software Low-level architecture requirements • Compliance • Robustness • Compliance • Compliance • Traceability Source code • Compliance • Veriability • Robustness • Conformance to standards • Accuracy and consistency • Traceability • Completeness and correctness Development activity Executable Review activity object code Test activity • Compatibility with the target computer Note: Requirements include derived requirements FIGURE 1. Activities mandated by DO-178C to ful ll objectives (the labels on the arcs). Veri cation against requirements is shown in two white boxes with blue borders. (Note that the legend says “Test activity,” but DO-333 allows formal veri cation to replace these testing activities; artwork reproduced with permission of RTCA/EUROCAE.) MAY/JUNE 2013 | IEEE SOFTWARE 51 s3moy.indd 51 4/2/13 11:33 AM FOCUS: SAFETY-CRITICAL SOFTWARE numeric overflows, and so on, which WHAT ARE FUNCTION might be manifest at runtime by an ex- ception or by the program silently go- CONTraCTS? ing wrong. Formal analyses can help The concept of program contracts was invented by the researcher C.A.R. Hoare in 1969 check for the absence of runtime errors. in the context of reasoning about programs. In the mid-1980s, another researcher, Model checking and abstract interpre- Bertrand Meyer, introduced the modern function contract in the Eiffel programming tation are attractive options because language. In its simplest formulation, a function contract consists of two Boolean ex- they don’t require the user to write pressions: a precondition to specify input constraints and a postcondition to specify contracts, but they usually suffer from output constraints. Function contracts have subsequently been included in many other state explosion problems (meaning the languages, either as part of the language (such as CodeContracts for .NET or contracts tool doesn’t terminate) or they gener- for Ada 2012) or as an annotation language (such as JML for Java or ACSL for C). Con- ate too many false alarms (meaning tracts can be executed as runtime assertions, interpreted as logic formulas by analysis the tool warns about possible problems tools, or both. that aren’t genuine). A successful ex- ample of such a tool is Astrée,5 which was specifically crafted to address this facilitated by using qualified tools for verification, either by testing or by for- requirement on a restricted domain- purposes such as enforcing coding re- mal verification. specific software. Deductive verifica- strictions against features that would Compliance requirements focus on tion techniques require user-written complicate traceability, by applying ap- a program’s intended nominal behav- function contracts instead of domain- propriate compiler options to preserve iors. To use formal verification for these specific tools and don’t suffer from ter- control flow, and by using code trace- requirements, you first express the re- mination problems or too many false ability analyses prepared by compiler quirement in a formal language—for alarms. These techniques are available vendors. example, HLR1 can be expressed as a in Caveat,5 Frama-C,8 and SPARK.9 Assuring the correctness of the com- temporal logic formula on traces of ex- piler’s translation of source code into ecution or as an observer program that Replacing Coverage with object code is, of course, important. checks the error state is never reached. Alternative Objectives Trust can be based on examination Then, you can use symbolic execution To increase confidence in the compre- of the compiler itself (the tool qualifi- techniques to check that the require- hensiveness of testing-based verifica- cation process) or the compiler’s out- ment is respected. The Java PathFinder tion activities, DO-178 requires cov- put. The former approach (qualifying tool used at NASA and the Aoraï plug-in erage analysis. Test coverage analysis the compiler) is rare because of the ef- of Frama-C implement this technique.8 is a two-step process that involves fort involved. The latter approach pro- As another example, you can express requirements-based and structural cov- vides the relevant degree of assurance LLR1 as a logic function contract (see erage analyses. Requirements-based through the multiple and overlapping the “What Are Function Contracts?” coverage establishes that verification activities required by DO-178, includ- sidebar). Then, you use various formal