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


  • 419 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

PowerPoint Slideshow about 'Assertion Checking Environment (ACE) for Formal Verification of C Programs' - paul2


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