Software Model Checking for Embedded Systems

1
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

2
The Dream
void add(Object o) bufferhead o head
(head1)size Object take()
tail(tail1)size return buffertail
Program
Checker
Property 1 Property 2
Requirement
3
Model Checking
Finite-state model
Model Checker
(F W)
Temporal logic formula
4
Why use Model Checking?

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

• In contrast to testing, gives complete coverage
  by exhaustively exploring all paths in system,
• Its been used for years with good success in
  hardware and protocol design

This suggests that model-checking can complement
existing software quality assurance techniques.
5
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

6
Model Construction Problem
void add(Object o) bufferhead o head
(head1)size Object take()
tail(tail1)size return buffertail
Model Checker
Program
Model Description

• Semantic gap

Programming Languages
methods, inheritance, dynamic creation,
exceptions, etc.
Model Description Languages
automata
7
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

8
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 /\ ltgtkeyRem) -gt ((!activate /\
!keyRem) U (keyRem \/ ((activate /\ !keyRem)
U (keyRem \/ ((!activate /\ !keyRem) U
(keyRem \/ ((activate /\ !keyRem) U
(keyRem \/ (!activate U keyRem))))))))))
9
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

10
State Explosion Problem

• Cost is exponential in the number of components

• Moores law and algorithm advances can help
• Holzmann 7 days (1980) gt 7 seconds (2000)
• Explosive growth of software limits scalability

11
What makes model-checking software difficult?
Problems using existing checkers

• Model construction

• State explosion

• Property specification

• Output interpretation

12
Output Interpretation Problem
void add(Object o) bufferhead o head
(head1)size Object take()
tail(tail1)size return buffertail
Model Description
Program

• Raw error trace may be 1000s of steps long

• 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

13
BanderaAn open tool set for model-checking Java
source code
14
Addressing the Model Construction Problem

• Numerous analyses, optimizations,two
  intermediate languages, multiple back-ends
• Slicing, abstract interpretation

15
Addressing the Property Specification Problem
A Java-based language for defining sequences of
program observations as instances of field-tested
specification patterns
((keyIn /\ ltgtkeyRem) -gt ((!activate /\
!keyRem) U (keyRem \/ ((activate /\ !keyRem)
U (keyRem \/ ((!activate /\ !keyRem) U
(keyRem \/ ((activate /\ !keyRem) U
(keyRem \/ (!activate U keyRem))))))))))
16
Addressing the State Explosion Problem
void add(Object o) bufferhead o head
(head1)size
Java Source
Model Descriptions
Model Compiler

• Aggressive customization via slicing, abstract
  interpretation, static analysis

17
Addressing the Output 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

18
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

19
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