1. Is Proof More Cost-Effective Than Testing? Presented by Yin Shi

2. Overview Introduction Introduction The Application: SHOLIS The Application: SHOLIS The Programming Language: SPARK The Programming Language: SPARK Proof in the SHOLIS Development Process Proof in the SHOLIS Development Process Results, Experiences, and Lessons Learned Results, Experiences, and Lessons Learned Analysis of the Results Analysis of the Results Summary and Conclusions Summary and Conclusions

3. Introduction The use of formal development methods on an industrial safety-critical application The use of formal development methods on an industrial safety-critical application Controversy among software suppliers on using formal methods Controversy among software suppliers on using formal methods Developing software using formal techniques is indeed possible Developing software using formal techniques is indeed possible Now becoming Common for project to use formal notations to document specifications and designs Now becoming Common for project to use formal notations to document specifications and designs Used Z for specification and design, the SPARK for code Used Z for specification and design, the SPARK for code

4. The Application: SHOLIS SHOLIS SHOLIS –The Ship Helicopter Operating Limits Information System –It is intended to be used on UK Royal Navy and Royal Fleet Auxiliary vessels Brief System Description Brief System Description –SHOLIS contains a database of Ship Helicopter Operating Limits (SHOLs) –One of the main safety-critical functions of SHOLIS is to make continual comparisons of sensor information against a selected SHOL –The SHOLIS functions are grouped on a number of pages.

5. The Application: SHOLIS Safety Requirements Safety Requirements –Catastrophic hazards –Safety-critical and developed to SIL4 –Non-safety critical

6. The Programming Language: SPARK The executable part of the language is a subset of Ada The executable part of the language is a subset of Ada Design Design –Logical soundness –Simplicity of formal description –Expressive power –Security –Verifiability –Bounded time and space requirements Several features of Ada have been removed Several features of Ada have been removed –Gotos, aliasing, default parameters for subprograms –Side-effects in functions, recursion, tasks, user-defined exceptions, exception handlers, and generics. –Other features

7. The Programming Language: SPARK Annotations are processed by the SPARK tools Annotations are processed by the SPARK tools –The first group of annotations is concerned with data and information flow analysis -- # global -- # global -- # derives -- # derives -- # own -- # own -- # inherit -- # inherit –The second group of annotations is used for code verification -- # pre -- # pre -- # post -- # post -- # assert -- # assert -- # return -- # return

8. The Programming Language: SPARK The design of the SPARK ensures that the Ada exceptions can not be raised The design of the SPARK ensures that the Ada exceptions can not be raised –Tasking_Error –Program_Error –Storage_Error Constraint_Error can only be caused by a division check, an index check, a range check, or an overflow check Constraint_Error can only be caused by a division check, an index check, a range check, or an overflow check Two possible routes for discharging the VCs Two possible routes for discharging the VCs –The Simplifier –The Proof Checker

9. Z notation The formal specification notation The formal specification notation Useful for describing computer-based systems Useful for describing computer-based systems Based on set theory and first order predicate logic Based on set theory and first order predicate logic It has been developed by the Programming Research Group at the Oxford University Computer Laboratory since the late 1970s It has been developed by the Programming Research Group at the Oxford University Computer Laboratory since the late 1970s Z is now defined by an ISO standard and is public domain Z is now defined by an ISO standard and is public domain http://vl.fmnet.info/z/ http://vl.fmnet.info/z/

10. Proof in the SHOLIS Development Process The Development Process The Development Process –Requirements, written in English –Software Requirement Specification (SRS), written in Z and English –Software Design Specification (SDS), written in SPARK, Z, and English –Code, written in SPARK –Testing Proof Activities Proof Activities –Z proof –SPARK proof

11. Z Proof At SRS level proof At SRS level proof –Consistency of global variables and constants –Existence of initial states and checking of preconditions –The key safety properties of SHOLIS were also formalized in Z, and proved. In;Calc;Outgives the correct warning In;Calc;Outgives the correct warning At DSD level proof At DSD level proof –Further Z proofs were done to demonstrate the consistency and correctness of the part of the design written in Z Assistance tools CADiZ tool for schema expansion Assistance tools CADiZ tool for schema expansion

12. SPARK proof All of the work was carried out with machine assistance All of the work was carried out with machine assistance –The Examiner –Simplifier –Proof Checker Data and information flow analysis was carried out for all of the code in SHOLIS Data and information flow analysis was carried out for all of the code in SHOLIS SIL4 subprogram, SPARK pre and post annotations were produced from the Z descriptions SIL4 subprogram, SPARK pre and post annotations were produced from the Z descriptions The final group of SPARK proof activities concerned the run-time checks. The final group of SPARK proof activities concerned the run-time checks.

13. Proof in the SHOLIS Development Process Proof personnel Proof personnel –Engineers Two were for Z proofs Two were for Z proofs One also worked for other two engineers on generating SPARK proof annotations, and SPARK proof activities One also worked for other two engineers on generating SPARK proof annotations, and SPARK proof activities Two coders for Data and information flow analysis Two coders for Data and information flow analysis –Skills are necessary for such a project Proof Validation Proof Validation –Z proofs were subject to a formal peer-review process –SPARK code proof also reviewed by IV&V team –None of the proofs was inspected or reviewed by customer Timing and Resource Usage Timing and Resource Usage –Timings – static timing analysis tool was used –Memory – simple static analysis of object code is sufficient –I/O bandwidth – the available bandwidth to the displays was a limiting factor.

14. Results, Experiences, and Lessons Learned Quantitative Results Quantitative Results –Z proof work 150 proofs were carried out 150 proofs were carried out –130 were at SRS level –The remainder at the SDS level 500 pages 500 pages –SPARK proof work 9000 verification conditions were generated 9000 verification conditions were generated –3100 were proofs of functional and safety properties –Remaining 5900 came from the RTC generator 6800 were discharged automatically by the simplifier 6800 were discharged automatically by the simplifier The remainder were discharged by the Proof checker or by informal justification The remainder were discharged by the Proof checker or by informal justification Faults found at different stages Faults found at different stages

15. Results, Experiences, and Lessons Learned Definition of a fault for these purposes is an error in the system development Definition of a fault for these purposes is an error in the system development

16. Results, Experiences, and Lessons Learned The Z proof phase is effective at finding faults, with relatively little effort, early in the development process. The Z proof phase is effective at finding faults, with relatively little effort, early in the development process.

17. Results, Experiences, and Lessons Learned Types of Errors found by Z Precondition Proofs Types of Errors found by Z Precondition Proofs –Approximately 70 percent of the Z proofs involved calculating preconditions, and they found about 75 percent of the total faults found by Z proof. –Major types of faults Incorrect functionality specified (6) Incorrect functionality specified (6) Contradictory operations (11) Contradictory operations (11) Lack of mode/history information modeled (4) Lack of mode/history information modeled (4) Missing cases (7) Missing cases (7) Incorrectly loose specifications (4) Incorrectly loose specifications (4)

18. Results, Experiences, and Lessons Learned

19. Subjective Feedback on the Use of Proof Subjective Feedback on the Use of Proof –The “middle” part of the system could be neatly described by Z and SPARK –At the very top level, experience showed that the proof annotations were often simply too large to be manageable. –At the “bottom” of the architecture Need to interface with other software, such as device drivers, for which there was no formal specification at all Need to interface with other software, such as device drivers, for which there was no formal specification at all o! = f(x) o! = f(x) –Problems in ensuring that the SPARK code was both provable and obeyed the timing requirements –In Z proofs, it was found that the choice of state invariants was particularly important for finding errors

20. Results, Experiences, and Lessons Learned –Lessons learned about coding styles that made the proof task easier “Coding Style Guide” “Coding Style Guide” –It should be noted that the proportion of effort spent producing the proofs was fairly low –The use of a formal specification leads to simpler code that is easier to understand, and therefore to maintain SPARK 83 versus SPARK 95 SPARK 83 versus SPARK 95 –SHOLIS used SPARK 83 –New features of SPARK 95 would have made life easier on the SHOLIS Use type clauses Use type clauses The ability to read out parameters The ability to read out parameters Moded globals and the changes to static expressions Moded globals and the changes to static expressions

21. Analysis of the Results Our analysis is based on engineering judgment drawn from the experience Our analysis is based on engineering judgment drawn from the experience The Z Proof was the most efficient phase in finding faults, followed by the System Validation Test phase. The Z Proof was the most efficient phase in finding faults, followed by the System Validation Test phase. Code Proof appears more efficient than Unit Testing Code Proof appears more efficient than Unit Testing Three questions: Three questions: –Are any additional cost incurred to make it possible to do proof or testing? –What are the severities of the faults found by proof or testing? –Is the sample size large enough to be statistically significant?

22. Analysis of the Results Additional Costs Additional Costs –Z proof, needed is the Z itself and statements of all the properties to prove. –The time taken to formulate the properties –SPARK code proof, data flow analysis must be performed on the code and appropriate proof annotations –Testing activities include all the time taken to write test specifications, test scripts, run tests, etc. Fault Severities Fault Severities –Not obvious how to compare the severity of faults found by different phases –A possible measure of severity might be the effort taken to fix a fault Effort taken to fix fault found by Z proof was quit low Effort taken to fix fault found by Z proof was quit low The cost of correction rapidly increases the later the faults are found The cost of correction rapidly increases the later the faults are found

23. Analysis of the Results Statistical Significance Statistical Significance –The total number of faults is certainly not large enough to be conclusive –We believe SHOLIS is a large enough example for proof to be given serious consideration on other project Analysis Conclusions Analysis Conclusions –The efficiency numbers in Fig.1 are a reasonable statement of the effectiveness of Z proof on SHOLIS –Proving the code was free of run-time exceptions was practical and important for a safety-critical application –Only the systematic nature of proof could establish the absence of exceptions

24. Summary and Conclusions/Questions The SHOLIS project made extensive use of formal methods The SHOLIS project made extensive use of formal methods Z proof phase was the most efficient phase of the project Z proof phase was the most efficient phase of the project Proofs at the SPARK code level were not as efficient at finding faults Proofs at the SPARK code level were not as efficient at finding faults The code proofs were still more efficient at error detection than unit testing The code proofs were still more efficient at error detection than unit testing System validation testing was more efficient at finding faults than unit testing System validation testing was more efficient at finding faults than unit testing Constraints to remember when attempting proof on a large- scale Constraints to remember when attempting proof on a large- scale –SHOLIS’s simple system architecture –Limits of formality must be considered Proof was an important part of the SHOLIS development process Proof was an important part of the SHOLIS development process Our success shows both the significant benefit and practically of large-scale proof on projects of this kind. Our success shows both the significant benefit and practically of large-scale proof on projects of this kind.