b. sharma, s.d. dhodapkar, s. ramesh 1 assertion checking environment (ace) for formal verification...
TRANSCRIPT
B. Sharma, S.D. Dhodapkar, S. Ramesh 1
Assertion Checking Environment (ACE) for Formal Verification of
C Programs
Babita Sharma, S.D.DhodapkarRCnD, BARC, Mumbai, India
[email protected], [email protected]
S.RameshCFDVS, IIT Bombay, Mumbai, India
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 STeP format
c2splPre-conditions
Assertions/
Post-conditions
SPL Model
axioms
Properties
MISRA C
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 and postfunc 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
Examplestruct 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 Programget_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