B. Sharma, S.D. Dhodapkar, S. Ramesh 1 Assertion Checking Environment (ACE) for Formal Verification...

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

[email protected]


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


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


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


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


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


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


Formal Verification Methodology


Program Verification Methodology

• Important Features– Abstract Models– Formal Specification– Verification Engine


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


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


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


ACE


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..


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


Compositional Verification


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


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*/ }


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 ]


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)


Industrial Experience• Verification of many real programs

• Safety-critical Applications– Control– Process Interlock– Data Acquisition and Display


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


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


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 1 Assertion Checking Environment (ACE) for Formal Verification...

Documents

Transcript of B. Sharma, S.D. Dhodapkar, S. Ramesh 1 Assertion Checking Environment (ACE) for Formal Verification...