Assertion Checking Environment (ACE) for Formal Verification of C Programs

1. Assertion Checking Environment (ACE) for Formal Verification of C Programs Babita Sharma, S.D.DhodapkarRCnD, BARC, Mumbai, Indiababita@apsara.barc.ernet.in, sdd@magnum.barc.ernet.in S.RameshCFDVS, IIT Bombay, Mumbai, Indiaramesh@cfdvs.iitb.ac.in B. Sharma, S.D. Dhodapkar, S. Ramesh

2. Introduction • Safety Critical Systems • Process, Automobile and Aircraft Control • Mission critical avionics applications • Bugs are Costly • Pentium bug, Ariane 5 failure • Stringent Reliability Requirements • High level of Software Integrity Requirements B. Sharma, S.D. Dhodapkar, S. Ramesh

3. Rigorous Development • Verification • Freedom from defects • Rigorous Verification practices essential • Safety Integrity Levels • Various guidelines and standards • MISRA guidelines, IEC 1508 • 1 to 4 (low to high integrity) • Formal Specification and Verification B. Sharma, S.D. Dhodapkar, S. Ramesh

4. Traditional Approaches • Peer Review, formal Inspection and Dynamic Testing • Effective in detecting presence of bugs never their absence • Late detection of bugs • When to stop testing? • Coverage criteria • 60% of time spent on V&V • Rigorous methods that establish absence of defects required • Formal Verification B. Sharma, S.D. Dhodapkar, S. Ramesh

5. Formal Methods • More rigorous approach • Founded on Mathematical methods • Proves correctness of Systems • Increased confidence • Early Detection of bugs • Design Verification • Complementary to traditional techniques B. Sharma, S.D. Dhodapkar, S. Ramesh

6. Verification Environment • For industrial software • Assertion Checking Environment (ACE) • Static Checking of assertions about program units • safety properties of program units • Safety Subsets of Programming languages • MISRA C • Checking Procedure • Static • Theorem Proving Techniques B. Sharma, S.D. Dhodapkar, S. Ramesh

7. Static vs Dynamic checking • Classical Code Verification methods based on Dynamic Testing & Assertion Checking • Effectiveness determined by test cases • more testing, more confidence in Verification • Static Assertion Checking equivalent to exhaustive testing • leads to higher level of assurance of code correctness • Static Assertion Checking not new! • Classical Hoare Logic, Manna’s inductive assertion method • The Central issue • Applying to industrial systems B. Sharma, S.D. Dhodapkar, S. Ramesh

8. Formal Verification Methodology B. Sharma, S.D. Dhodapkar, S. Ramesh

9. Program Verification Methodology • Important Features • Abstract Models • Formal Specification • Verification Engine B. Sharma, S.D. Dhodapkar, S. Ramesh

10. Models • Abstract, High Level descriptions • Modeling an error-prone activity • Major bottleneck in using formal methods • Real Languages pose several problems • Our proposal • Language Subsets • Consistent with Safety considerations • Safe subset of C • MISRA C • Motor Industry Standard • Safe features of C B. Sharma, S.D. Dhodapkar, S. Ramesh

11. Specification • Formal Specification using mathematical Logic • Assertions at specific program control points • Conditions satisfied by program variables • Input Constraints or Pre-Conditions • Output Properties or Post-Conditions • Loop Invariants • Compositional Specifications • Individual and independent specification of program units B. Sharma, S.D. Dhodapkar, S. Ramesh

12. Verification • Formal Procedures to check correctness of assertions • Theorem Proving Capabilities • STeP • Powerful Theorem Prover from Stanford U. • Strategies for Verification • Programmable using tactics and tacticals • Translation tools • STeP uses SPL models • MISRA C need to be translated B. Sharma, S.D. Dhodapkar, S. Ramesh

13. ACE B. Sharma, S.D. Dhodapkar, S. Ramesh

14. MISRA C • Safe subset of C for embedded automotive systems • General C has a lot of problems • complex operator prec. rules, side effecting expressions, run-time checks, pointer arithmetics • MISRA recommends a set of rules • No dependence on operator precedence rules • goto statement shall not be used. • Every case clause terminated with a break statement. • A function should have a single point of exit. • Pointer arithmetic not to be used. • Unions shall not be used to access the sub-parts of larger data types.. B. Sharma, S.D. Dhodapkar, S. Ramesh

15. C2SPL • Important Component of ACE • converts MISRA C program to SPL programs • converts pre, post conditions and assertions into SPEC file in STePformat MISRA C SPL Model axioms Pre-conditions c2spl Properties Assertions/ Post-conditions B. Sharma, S.D. Dhodapkar, S. Ramesh

16. Compositional Verification B. Sharma, S.D. Dhodapkar, S. Ramesh

17. Compositional Verification • prefunc and postfunc type of annotations • prefunc captures the pre-condition of the called function • postfunc captures post-condition of the called function • both prefunc andpostfunc annotations are automatically inserted by ACE • Discharging the proofs for a function containing prefunc and postfunc annotations • prefunc type annotations become additional proof obligations, • postfunc type annotations become axioms B. Sharma, S.D. Dhodapkar, S. Ramesh

18. Example struct RCD3_data { double X, Y; }; void get_inputsXY(struct RCD3_data *final_data) { ret1 = read_from_reg( 1, &InputX ); /*postfunc ( InputX >= 0 /\ InputX <= 4095 ) end*/ change_to_v(InputX, input_src, &tempX ); /*assert !(tempX < 0 \/ tempX > 5) end*/ final_data->X= tempX; convert_to_d(1, tempX, final_data); /*post (#X final_data >= -180) /\ (#X final_data <= 180) end*/ } B. Sharma, S.D. Dhodapkar, S. Ramesh

19. SPL Program get_inputsXY :: [ local final_data : RCD3_data local InputX, InputY : WORD … ret1 := read_from_reg(1,InputX); postf1 : skip; prefunc2 : skip; void_var := change_to_v(InputX,input_src,tempX); postf3 : skip; assert4 : skip; #X final_data := tempX; prefunc5 : skip; void_var := convert_to_d(1,tempX,final_data); postf6 : skip; assert7 : skip ] B. Sharma, S.D. Dhodapkar, S. Ramesh

20. Specification SPEC AXIOM postf1 : postf1 ==> ( InputX >= 0 /\ InputX <= 4095 ) AXIOM prefunc2 : prefunc2 ==> (input_src = 2) \/ (input_src = 3) PROPERTY postf3 : postf3 ==> ((input_src = 3) /\ (tempX = ((5/4096) * InputX))) \/ ((input_src=2) /\ (tempX = ((5/2048) * InputX - 5.0))) PROPERTY assert4 : assert4 ==> !(tempX < 0 \/ tempX > 5) PROPERTY prefunc5 : prefunc5 ==> (1 = 1) \/ (1 = 2) B. Sharma, S.D. Dhodapkar, S. Ramesh

21. Industrial Experience • Verification of many real programs • Safety-critical Applications • Control • Process Interlock • Data Acquisition and Display B. Sharma, S.D. Dhodapkar, S. Ramesh

22. Process Interlock Software • tool-generated C code (translation validation) • Logic diagrams to code • Annotations derived from input logic diagrams • 6000 lines of code, 54 functions, • roughly 500 assertions proved B. Sharma, S.D. Dhodapkar, S. Ramesh

23. Data acquisition system • Manual development of programs and specifications • 4000 lines of code, 40 functions, • 110 assertions proved • Properties Verified • Range Checks • arithmetic computations, • performance of software controlled actions, • intermediate values of variables etc. • one program required slicing to reduce model size B. Sharma, S.D. Dhodapkar, S. Ramesh

24. Conclusions • Initial Experience with the tool encouraging • Future Enhancements • Use of slicing techniques • Finite State machine abstractions • Concurrency aspects B. Sharma, S.D. Dhodapkar, S. Ramesh