slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Assertion Checking Environment (ACE) for Formal Verification of C Programs PowerPoint Presentation
Download Presentation
Assertion Checking Environment (ACE) for Formal Verification of C Programs

Loading in 2 Seconds...

play fullscreen
1 / 24

Assertion Checking Environment (ACE) for Formal Verification of C Programs - PowerPoint PPT Presentation


  • 420 Views
  • Uploaded on

Assertion Checking Environment (ACE) for Formal Verification of C Programs Babita Sharma, S.D.Dhodapkar RCnD, BARC, Mumbai, India babita@apsara.barc.ernet.in, sdd@magnum.barc.ernet.in S.Ramesh CFDVS, IIT Bombay, Mumbai, India ramesh@cfdvs.iitb.ac.in Introduction Safety Critical Systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

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


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
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

introduction
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

rigorous development
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

traditional approaches
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

formal methods
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

verification environment
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

static vs dynamic checking
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

formal verification methodology
Formal Verification Methodology

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

program verification methodology
Program Verification Methodology
  • Important Features
    • Abstract Models
    • Formal Specification
    • Verification Engine

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

models
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

specification
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

verification
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

slide13
ACE

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

misra c
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

c2spl
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

compositional verification
Compositional Verification

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

compositional verification17
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

example
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

spl program
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

specification20
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

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

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

process interlock software
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

data acquisition system
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

conclusions
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