Software Model Checking for Embedded Systems PIs: Matthew Dwyer 1, John Hatcliff 1, and George Avrunin 2 Post-docs: Steven Seigel 2, Radu Iosif 1 Students: Robby 1, Roby Joehanes 1, Yu Chen 1 Kansas State University 1 University of Massachusetts 2

The Dream Program Requirement Checker void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Property 1: … Property 2: … … OK Error trace or

Model Checking Finite-state model Temporal logic formula Model Checker  OK Error trace or Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:…

Why use Model Checking? In contrast to testing, gives complete coverage by exhaustively exploring all paths in system, It’s been used for years with good success in hardware and protocol design Automatically check, e.g., –invariants, safety & liveness properties –absence of dead-lock and live-lock, –complex event sequencing properties, “Between the key being inserted and the key being removed, the ignition can be activated at most twice.” This suggests that model-checking can complement existing software quality assurance techniques.

What makes model-checking software difficult? Model construction OK Error trace or Finite-state model Temporal logic formula Model Checker  State explosion Problems using existing checkers: Property specification Output interpretation Line 5: … Line 12: … Line 15:… Line 21:…

Model Construction Problem Semantic gap: Model Description Model Checker Program void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Gap Programming Languages Model Description Languages methods, inheritance, dynamic creation, exceptions, etc. automata

What makes model-checking software difficult? Model construction OK Error trace or Finite-state model Temporal logic formula Model Checker  State explosion Problems using existing checkers: Property specification Output interpretation Line 5: … Line 12: … Line 15:… Line 21:…

Property Specification Problem Difficult to formalize a requirement in temporal logic “Between the key being inserted and the key being removed, the ignition can be activated at most twice.” []((keyIn /\ <>keyRem) -> ((!activate /\ !keyRem) U (keyRem \/ ((activate /\ !keyRem) U (keyRem \/ ((!activate /\ !keyRem) U (keyRem \/ ((activate /\ !keyRem) U (keyRem \/ (!activate U keyRem)))))))))) …is rendered in LTL as...

What makes model-checking software difficult? Model construction OK Error trace or Finite-state model Temporal logic formula Model Checker  State explosion Problems using existing checkers: Property specification Output interpretation Line 5: … Line 12: … Line 15:… Line 21:…

State Explosion Problem Moore’s law and algorithm advances can help –Holzmann: 7 days (1980) ==> 7 seconds (2000) Explosive growth of software limits scalability Bit x1,…,xN2^N states Cost is exponential in the number of components

What makes model-checking software difficult? Model construction OK Error trace or Finite-state model Temporal logic formula Model Checker  State explosion Problems using existing checkers: Property specification Output interpretation Line 5: … Line 12: … Line 15:… Line 21:…

Output Interpretation Problem Raw error trace may be 1000’s of steps long Model Description Program void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Gap Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… Must map line listing onto model description Mapping to source is made difficult by –Semantic gap & clever encodings of complex features –multiple optimizations and transformations

Bandera: An open tool set for model-checking Java source code Checker Inputs Checker Outputs Transformation & Abstraction Tools Model Checkers Java Source void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Bandera Specification Language Graphical User Interface Error Trace Mapping Bandera

Addressing the Model Construction Problem Numerous analyses, optimizations, two intermediate languages, multiple back-ends Slicing, abstract interpretation Model extraction: compiling to model checker inputs: Java Source void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Model DescriptionModel Compiler Static Analyses Abstract Interpretation Slicing Optimizations

Addressing the Property Specification Problem A Java-based language for defining sequences of program observations as instances of field-tested specification patterns Using the pattern system: 2-bounded existence forall[v: Vehicle]. between {keyIn(v)} and {keyRem(v)} {activate(v)} exists at most {2} times; []((keyIn /\ <>keyRem) -> ((!activate /\ !keyRem) U (keyRem \/ ((activate /\ !keyRem) U (keyRem \/ ((!activate /\ !keyRem) U (keyRem \/ ((activate /\ !keyRem) U (keyRem \/ (!activate U keyRem))))))))))

Addressing the State Explosion Problem Aggressive customization via slicing, abstract interpretation, static analysis Java Source void add(Object o) { buffer[head] = o; head = (head+1)%size; } … Model DescriptionsModel Compiler Property Generate models customized for property! Result: multiple models --- even as many as one per property

Addressing the Output Interpretation Problem Run error traces forwards and backwards Program state queried Locks, wait sets, blocked sets displayed Like a debugger: error traces mapped back to source Java Source void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Model Compiler Model Checker Intermediate Representations Error trace Line 5: … Line 12: … Line 15:… Line 21:… Model Description + simulator

Goals for HCES project … Extend model extraction technologies, e.g., –Exploit both code and design artifacts –Automate generation of environments –Automate program abstraction Extend property-specification formalisms, e.g., –Code and design-based formalisms –Mixed state and event-based formalisms –Multiple inter-operating formalisms Add time to models, environments, specifications, and abstractions

Goals for HCES project … Integrate software model checking tools, e.g., –Develop methodological support for applying tools Conduct systematic evaluation of tools –Apply tools to embedded systems code contributed by industrial/government partners –Develop suites of realistic multi-threaded Java programs for tool evaluation that might serve as community-wide challenge/demonstration problems