Assertion Checking Environment (ACE) for Formal Verification of

1

• Assertion Checking Environment (ACE) for Formal
  Verification of
• C Programs
• Babita Sharma, S.D.DhodapkarRCnD, BARC, Mumbai,
  Indiababita_at_apsara.barc.ernet.in,
  sdd_at_magnum.barc.ernet.in
• S.RameshCFDVS, IIT Bombay, Mumbai,
  Indiaramesh_at_cfdvs.iitb.ac.in

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

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

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 VV
• Rigorous methods that establish absence of
  defects required
• Formal Verification

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

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

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, Mannas inductive
  assertion method
• The Central issue
• Applying to industrial systems

8
Formal Verification Methodology
9
Program Verification Methodology

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

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

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

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

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

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

SPL Model

• MISRA C

axioms
Pre-conditions
c2spl
Properties
Assertions/
Post-conditions
16
Compositional Verification

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

18
Example

• struct RCD3_data double X, Y
• void get_inputsXY(struct RCD3_data final_data)
• ret1 read_from_reg(
  1, InputX )
• /postfunc ( InputX gt 0 /\ InputX lt
  4095 ) end/
• change_to_v(InputX, input_src, tempX )
• /assert !(tempX lt 0 \/ tempX gt 5) end/
• final_data-gtX tempX
  convert_to_d(1, tempX, final_data)
• /post (X final_data gt -180) /\ (X
  final_data lt 180) end/

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,temp
  X)
• postf3 skip
• assert4 skip
• X final_data tempX
• prefunc5 skip
• void_var convert_to_d(1,tempX,final_data)
  
• postf6 skip
• assert7 skip

20
Specification

• SPEC
• AXIOM postf1
• postf1 gt ( InputX gt 0 /\ InputX lt 4095 )
• AXIOM prefunc2
• prefunc2 gt (input_src 2) \/ (input_src
  3)
• PROPERTY postf3
• postf3 gt ((input_src 3) /\ (tempX
  ((5/4096) InputX)))
• \/ ((input_src2) /\ (tempX
  ((5/2048) InputX - 5.0)))
• PROPERTY assert4
• assert4 gt !(tempX lt 0 \/ tempX gt 5)
• PROPERTY prefunc5
• prefunc5 gt (1 1) \/ (1 2)

21
Industrial Experience

• Verification of many real programs
• Safety-critical Applications
• Control
• Process Interlock
• Data Acquisition and Display

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

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

24
Conclusions

• Initial Experience with the tool encouraging
• Future Enhancements
• Use of slicing techniques
• Finite State machine abstractions
• Concurrency aspects