Testing Or Formal Verification

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

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 between 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 example 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 evidence exists for all of the software’s ing the hardware/software integration analyses to check that the code imple- requirements—that is, that all the re- testing and the verification of untrace- ments these formal contracts, although quirements have been met. This also able object code. deductive methods typically perform applies to formal verification. Struc- The form of verification required better here, as demonstrated by the op- tural coverage analysis during testing by DO-178 is mostly based on require- erational deployment of tools such as (for example, statement coverage) aims ments, both for verifying high-level re- Caveat/Frama-C5,8 and SPARK.9 to detect shortcomings in test cases, in- quirements, such as “HLR1: the pro- Robustness requirements focus on a adequacies in requirements, or extrane- gram is never in error state E1,” and for program’s behaviors outside its nomi- ous code. verifying low-level requirements, such nal use cases. A particularly important Structural coverage analysis doesn’t as “LLR1: function F computes out- robustness requirement is that pro- apply to formal verification. Instead, puts O1, …, On from inputs I1, … Im.” grams are free from runtime errors, DO-178C’s supplement on formal For both HLRs and LLRs, the DO- such as reading uninitialized data, ac- methods, DO-333, defines four al- 178 guidance requires in-range (com- cessing out-of-bounds array elements, ternative activities to reach the struc- pliance) and out-of-range (robustness) dereferencing null pointers, generating tural coverage goals when using formal

52 IEEE Software | www.computer.org/software

s3moy.indd 52 4/2/13 11:33 AM verification:6,7 cover, complete, data- Dataflow: Detect Unintended Dataflow be executed and unintended function- flow, and extraneous. The four alterna- To show that the coding phase didn’t alities—those that could be executed tive activities aim to achieve the same introduce undesired functionality, the but aren’t triggered by the tests derived three goals, substituting verification absence of unintended dependencies from requirements. When you use for- cases for test cases in the first one. between the source code’s inputs and mal analysis, the previous activities give outputs must be demonstrated. You some degree of confidence that unin- Cover: Detect Missing can use formal analysis to achieve this tended functionalities can be detected. Verification Evidence Unlike testing, formal verification can provide complete coverage with re- Unit proof has replaced some spect to a given requirement: it en- of the testing activities at Airbus on sures that each requirement has been sufficiently—in other words, mathe- the A400M military aircraft and the matically—verified. But unlike testing, A380 and A350 commercial aircraft. formal verification results depend on assumptions, typically constraints on the running environment, such as the objective. Formal notations exist to It only remains to detect by review or range of values from a sensor. Thus, all specify dataflows, such as the SPARK analysis the unreachable code. Because assumptions should be known, under- dataflow contracts9 or the Fan-C nota- this is a manual activity, its details vary stood, and justified. tion in Frama-C,8 and associated tools from project to project. automate the analysis. Complete: Detect Missing Formal Verification or Incomplete Requirements Extraneous: Detect Code That Doesn’t of Functional Formal verification is complete with re- Correspond to a Requirement Properties: Airbus spect to any given requirement. How- DO-178C requires demonstrating the Since 2001, a group at Airbus has trans- ever, additional activities are necessary absence of “extraneous code”: any code ferred formal verification technology— to ensure that all requirements have that can’t be traced to a requirement. tools and associated methods—from been expressed—that is, all admissible This includes “dead code” as defined research projects to operational teams behaviors of the software have been in DO-178C: code that’s present by er- who develop avionics software.5 The specified. This activity states that the ror and unreachable. The relevant sec- technology for verifying nonfunctional completeness of the set of requirements tion of DO-333 explicitly states that properties such as stack consumption should be demonstrated with respect to detection of extraneous code should be analysis, WCET assessment, absence the intended function: achieved by “review or analysis (other of runtime errors, and floating-point than formal).” Although formal analy- accuracy isn’t seen as an alternative to • “For all input conditions, the re- sis might detect some such code, com- testing and won’t be discussed here. In- quired output has been specified.” putability theory tells us that any prac- stead, we focus on unit proof,4,10 which • “For all outputs, the required input tical formal analysis tool (which doesn’t we developed for verifying functional conditions have been specified.” generate so many false alarms that it’s properties. It has replaced some of the useless in practice) will be unsound, testing activities at Airbus for parts Checking that the cases don’t over- meaning it will fail to detect some in- of critical embedded software on the lap and that they cover all input con- stances of extraneous code. DO-178C A400M military aircraft and the A380 ditions is sufficient for demonstrating doesn’t allow unsound tools. and A350 commercial aircraft. the first bullet point. Furthermore, it’s The effort required by this review or Within the classical V-cycle devel- easy to detect obvious violations of the analysis depends chiefly on the degree opment process of most safety-critical second point by checking syntactically of confidence obtained after complet- avionics programs, we use unit proof that each case explicitly mentions each ing the previous activities (cover, com- for achieving DO-178 objectives re- output. A manual review completes this plete, and dataflow). Testing detects lated to verifying that the executable verification. Note that formal methods extraneous code as code that isn’t ex- code meets the functional LLRs. The can’t handle the more general problem ecuted at runtime. This step detects term “unit proof” echoes the name of of detecting all missing requirements. both unreachable code that can never the classical technique it replaces: unit

May/June 2013 | IEEE Software 53

s3moy.indd 53 4/2/13 11:33 AM FOCUS: Safety-Critical Software

testing. The use of unity proof diverged the functional properties defined dur- guarantee, the theorem-proving from the DO-178B standard (more ac- ing the design phase. Finally, the en- tool verifies that the formal con- curately, it was treated as an alternative gineer analyzes the proof results. The tract defined in the design phase method of compliance), so we worked theorem-proving tool is integrated specifies a behavior for all possible with the certification authorities to ad- into the standard process management inputs. Then, we manually verify dress and authorize this alternative. tool, so that this proof process is en- the formal contracts, to determine The new DO-178C standard—together tirely automated and supported during that an accurate property exists and with the formal methods supplement maintenance. specifies the value of each output for each execution condition. • Dataflow. The dataflow verification The technique of unit proof reduces the gives evidence that the operands overall effort compared to unit testing, used by the source code are those defined at the design level. in particular because it facilitates • Extraneous. Except for unreach- maintenance. able code (which can’t be executed), all the executable code is formally verified against LLRs. Thus, the DO-333—fully supports the use of unit As discussed earlier, because we completeness of the properties and proof. perform a verification activity at the the exhaustiveness of formal proof Unit proof is a process comprising source level instead of the binary level, guarantee that any code section three steps: we also analyze the compiler-generated that can be executed will have no object code, including the effects of the other impact on function results • An engineer expresses LLRs for- compiler options on the object code, than what’s specified in the LLRs. mally as dataflow constraints be- to ensure that the compiler preserves Identification of unreachable code, tween a computation’s inputs and in the object code the property proved including dead code, is achieved outputs, and as preconditions and on the source code. Within this devel- through an independent, focused postconditions in first-order logic, opment cycle, HLRs are expressed in- manual review of the source code. during the development process’s formally, so integration verification is detailed design activity. done via testing, which includes verifi- There are two manually intensive, • An engineer writes a module to im- cation of timing aspects and hardware- low-level testing activities in DO-178: plement the desired functionality related properties. Even when taking normal range testing and robustness (this is the classical coding activ- into account these additional activities, testing. While Airbus has been us- ity). The C language is used for this the technique of unit proof reduces the ing formal verification to replace both purpose. overall effort compared to unit test- types of testing (excluding runtime er- • An engineer gives the C module’s ing, in particular because it facilitates rors), Dassault-Aviation has experi- formal requirements and the mod- maintenance. mented with formal verification to re- ule itself to a proof tool. This activ- This approach satisfies the four place the robustness testing (including ity is performed for each C function alternative objectives to coverage: runtime errors). of each C module. • Cover. Each requirement is ex- Formal Verification Different steps are needed when us- pressed as a property, each property of Robustness: ing the theorem-proving tool. An en- is formally proved exhaustively, and Dassault-Aviation gineer first defines the proof environ- every assumption made for formal Since 2004, a group at Dassault- ment, and then the tool automatically verification is verified. Aviation has used formal verification generates the data and control flows • Complete. Completeness of the set techniques experimentally to replace from the C code. The engineer then of requirements is verified by verify- integration robustness testing,6 where verifies these flows against the data and ing that the dataflow gives evidence robustness is defined as “the extent to control flows defined during the design that the data used by the source which software can continue to oper- phase. Next, the tool attempts to prove code is conformant with decisions ate correctly despite abnormal inputs that the C code correctly implements made during design. Based on this and conditions.”1 We’ve applied these

54 IEEE Software | www.computer.org/software

s3moy.indd 54 4/2/13 11:33 AM techniques to flight control software present formal verification cost: for- the model requires revisiting the extra developed following a model-based mal verification supplements an activity assertions, possibly with some support approach, specifically on the Falcon that was never performed through test- from the formal verification expert. family of business jets equipped with ing, just through human analysis. Design-rule verification and manual digital flight control systems. C source To mechanize the analysis through assertion analysis is estimated to take a code is automatically generated from a formal proof of the assertions, we use person-month of effort by the indepen- graphical model that includes a mix of two static analyzers that collaborate dent control engineers (not software en- dataflow and statechart diagrams. The and share results on the Frama-C plat- gineers) in charge of model verification. average size of the software units veri- form. Approximately 85 percent of This effort must be repeated for every fied by static analyzers is roughly 50 these assertions are proved by abstract software model release, so there’s no KLOC. interpretation using Frama-C’s value- economic gain for a single release. How- Normal conditions for this software analysis plug-in, and the remaining as- ever, because robustness verification is are defined as intervals bounding the sertions are proved by deductive verifi- a recurrent task that’s automated once model’s input variables and the per- cation using Frama-C’s WP plug-in and the setup phase is complete, this rather manent validity of a set of assertions a set of automated theorem provers. long preparation provides a significant stated at the model level. These asser- The value-analysis plug-in takes into competitive advantage for repetitive tions are assumptions expected to be account IEEE 754-compliant numerical analyses. The gain is roughly a person- met in both normal and abnormal in- precision; while propagating intervals, month per flight software release. put conditions for the model to operate it also verifies the absence of runtime This approach satisfies the following properly—typically, they’re range con- errors, in particular, the absence of alternative objectives to coverage: straints on arguments to library func- overflows and underflows. tions at the model’s leaf nodes. Apart As far as the verification process is • Cover. An engineer handles abnor- from runtime errors, the robustness as- concerned, once the integrated flight mal input conditions through larger sertions amount to a few hundred prop- control software is sufficiently stable, intervals and no other assump- erties stated at the model level and then a static analysis expert, in cooperation tions. The tool performs abstract propagated to the generated C code. with a model expert, initially performs interpretation with no assumptions On such software, integration testing the formal robustness verification. The other than those required to en- is functional, based on pilot-in-the-loop critical issue is to add a few extra asser- sure hardware-dependent numerical and hardware-in-the-loop activation of tions to be conclusive about the return consistency. the flight control laws. Designing test values for the numerically intensive li- • Complete. A manual peer review of cases to observe what might happen if brary functions. Finding them requires the set of assertions in the libraries some internal assertions break was de- termined to be costly and inconclusive, so we handle robustness by manually Because robustness verification justifying that normal and abnormal external inputs can’t lead to assertion is a recurrent task, the gain is roughly failures. A set of design rules facilitate a person-month per flight software release. the checking of range properties; we apply them at the software-modeling level and use a custom checker to verify them. These rules made a manual justi- both deep knowledge of the model and and in the model ensures that ro- fication possible. abstract interpretation expertise. It bustness requirements are complete. We anticipated that strengthen- takes roughly a person-month effort This is facilitated by the simplicity ing the manual analysis of range con- to set up the Frama-C analysis script of typical assertions, 90 percent of straints through mechanized interval and to tune any manually added as- which are interval constraints. propagation and abstract interpretation sertions. Then the model verifiers—an • Dataflow. An engineer formally would be beneficial. But we couldn’t independent group from the model de- specifies dataflows at the model compare the benefits of this process velopment team—can autonomously level, using a dataflow formalism. evolution on the baseline process by replay and update the analysis until Qualification of the code genera- simply comparing past testing cost and some substantial algorithmic change in tor ensures no unintended dataflow

May/June 2013 | IEEE Software 55

s3moy.indd 55 4/2/13 11:33 AM FOCUS: Safety-CritiCal Software

ormal methods technology has matured considerably in recent YAnnicK MoY is a senior engineer at AdaCore, working on static years, and it’s attracting in- analysis and formal verifi cation tools for Ada and SPARK programs. He F creasing interest in the domain of high- previously worked on similar tools for C/C++ programs at PolySpace, integrity systems. Airborne software INRIA research labs, and Microsoft Research. Moy received a PhD in formal program verifi cation from Université Paris-Sud. Contact him at is an obvious candidate, but DO-178B [email protected]. treated the use of formal methods for verifi cation as an activity that could supplement but not necessarily replace the prescribed testing-based approach. eMMAnueL LeDinot is a senior expert in formal methods applied The revision of DO-178B has changed to software and system engineering at Dassault-Aviation and was this, and the new DO-178C standard Dassault’s representative in the ED-12/DO-178 formal methods group. together with its DO-333 supplement Ledinot graduated as an engineer from Centrale Paris and has an MS in theoretical computer science from the University of Paris VII. Contact offer specifi c guidance on how formal him at [email protected]. techniques can replace, and not simply aBoUt tHe aUtHorS tHe aBoUt augment, testing. Experience at Airbus and Dassault- Aviation shows that the use of formal heRvÉ DeLsenY is an expert in avionic software aspects of certi- methods in a DO-178 context isn’t fi cation at Airbus and was a member of the working group in charge simply possible but also practical and of writing issue C of ED-12/DO-178. His professional interests include cost-effective, especially when backed formal methods and promoting their use in avionics software verifi cation. Delseny has an MS in industrial software from Tours University, by automated tools. During the require- France. Contact him at [email protected]. ments formulation process, engineers can use formal notation to express requirements, thus avoiding the ambi- guities of natural language, and formal viRGinie WieLs is a research scientist at Onera. She previously analysis techniques can then be used to worked for NASA on formal verifi cation of the Space Shuttle’s embed- check for consistency. This is especially ded software. Wiels received a PhD in formal system development useful because, in practice, the errors and verifi cation from Ecole Nationale Supérieure d’Aéronautique et d’Espace. Contact her at [email protected]. that show up in fi elded systems tend to be with requirements rather than with code. However, the correct capture of system-functional safety at the software level can’t be addressed by for- BenJAMin MonAte is a founder and director at TrustMySoft. He’s mal methods. During the coding phase, the former leader of the Software Reliability Laboratory at CEA LIST formal verifi cation techniques can de- and a senior expert in formal verifi cation and validation. His research termine that the source code complies interests include application of formal methods to static and dynamic analysis of programs as well as their certifi cation and methodologies with its requirements. of deployment. Monate has a PhD from Université Paris-Sud Orsay. An interesting possibility that we Contact him at [email protected]. didn’t discuss here is to combine testing with formal verifi cation. This has seen some promising research in recent years,11 and further industrial experience in this area will no doubt prove useful. relationship at the source-code level testing, at a time where the applicable compared to the design model. standard DO-178B didn’t fully recognize it. New projects can expect to get Acknowledgments Airbus and Dassault-Aviation were the same benefi ts in contexts where the We thank the anonymous reviewers and Ben- jamin Brosgol for their helpful comments on early adopters of formal verifi cation as new standard DO-178C explicitly sup- this article, as well as Cyrille Comar for in- a means to replace manually-intensive ports it. spiring us to write it.

56 IEEE SoftwarE | www.computEr.org/SoftwarE

s3moy.indd 56 4/2/13 11:33 AM References Avionics Software Products,” Proc. Formal tion Processing, René Jacquart, ed., vol. 156, 1. RTCA DO-178, “Software Considerations in Methods, Springer, 2009; http://link.springer. 2004, pp. 527–535. Airborne Systems and Equipment Certifi ca- com/chapter/10.1007%2F978-3-642 11. C. Comar, J. Kanig, and Y. Moy, “In- tion,” RTCA and EUROCAE, 2011. -05089-3_34?LI=true. tegrating Formal Program Verifi cation with 2. NASA ARMD Research Opportunities 6. E. Ledinot and D. Pariente, “Formal Methods Testing,” Proc. Embedded Real-Time Systems in Aeronautics 2011 (ROA-2011), research and Compliance to the DO-178C/ED-12C and Software, 2012; www.adacore.com/ program System-Wide Safety and Assurance Standard in Aeronautics,” Static Analysis of uploads_gems/Hi-Lite_ERTS-2012.pdf. Technologies Project (SSAT2), subtopic Software, J.-L. Boulanger, ed., John Wiley & AFCS-1.3 Software Intensive Systems, p. 77; Sons, 2012, pp. 207–272. http://nspires.nasaprs.com/external/ 7. D. Brown et al., “Guidance for Using Formal viewrepositorydocument/cmdocumentid= Methods in a Certifi cation Context,” Proc. 320108/solicitationId=%7B2344F7C4 Embedded Real-Time Systems and Software, -8CF5-D17B-DB86-018B0B184C63%7D/ 2010; www.open-do.org/wp-content/ viewSolicitationDocument=1/ROA-2011%20 uploads/2013/03/ERTS2010_0038_fi nal.pdf. Amendment%208%2002May12.pdf. 8. P. Cuoq et al., “Frama-C, A Software Analysis 3. J. Rushby, “New Challenges in Certifi cation Perspective,” Proc. Int’l Conf. Software Eng. for Aircraft Software,” Proc. 9th ACM Int’l and Formal Methods, Springer, 2012; www. Conf. Embedded Software, ACM, 2011; springer.com/computer/swe/book/978-3-642 www.csl.sri.com/users/rushby/papers/ -33825-0. emsoft11.pdf. 9. J. Barnes, SPARK, the Proven Approach to See www.computer.org/software 4. RTCA DO-333, Formal Methods Supplement High Integrity Software, Altran Praxis, 2012. -multimedia for multimedia to DO-178C and DO-278A, RTCA 10. J. Souyris and D. Favre-Félix, “Proof of content related to this article. and EUROCAE, 2011. Properties in Avionics,” Building the Informa- 5. J. Souyris et al., “Formal Verifi cation of tion Society, IFIP Int’l Federation for Informa-

IEEE Computer Society is offering $40,000 in student scholarships, from $1,000 and up, to recognize and reward active student volunteer leaders who show promise in their academic and professional efforts.

Graduate students and undergraduate students in their final two years, enrolled in a program in Richard E. Merwin electrical or computer engineering, computer Student Leadership science, information technology, or a well-defined computer-related field, are eligible. IEEE Computer Scholarship Society student membership is required.

Apply now! Application deadline is 30 April 2013. For more information, go to www.computer.org/ scholarships, or email [email protected].

To join IEEE Computer Society, visit www.computer.org/membership.

may/JunE 2013 | IEEE SoftwarE 57

s3moy.indd 57 4/2/13 11:33 AM