Software Model Checking for Embedded Systems

Software Model Checking for Embedded Systems PIs: Matthew Dwyer1, John Hatcliff1, and George Avrunin2 Post-docs: Steven Seigel2, Radu Iosif1 Students: Robby1, Roby Joehanes1, Yu Chen1 Kansas State University1 University of Massachusetts2

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

OK or Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… Model Checking Finite-state model Model Checker (F W) Temporal logic formula

Why use Model Checking? • Automatically check, e.g., • invariants, safety & liveness properties • absence of dead-lock and live-lock, • complex event sequencing properties, • 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 “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.

OK Finite-state model or Line 5: … Line 12: … Line 15:… Line 21:… Error trace Model Checker (F W) Temporal logic formula What makes model-checking software difficult? • Model construction Problems using existing checkers: • State explosion • Property specification • Output interpretation

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

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.” …is rendered in LTL as... []((keyIn /\ <>keyRem) -> ((!activate /\ !keyRem) U (keyRem \/ ((activate /\ !keyRem) U (keyRem \/ ((!activate /\ !keyRem) U (keyRem \/ ((activate /\ !keyRem) U (keyRem \/ (!activate U keyRem))))))))))

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

Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… Gap Error trace Output Interpretation Problem void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } • Raw error trace may be 1000’s of steps long Model Description Program • 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

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

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

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

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

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

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

Software Model Checking for Embedded Systems

Télécharger la présentation

Plus de contenu associé