Model Checking Large-Scale Software

1
Model Checking Large-Scale Software

• Natasha Sharygina
• Carnegie Mellon University
• Software Engineering Institute

2
Outline

• Model Checking Software
• Integrated Design and Verification Approach
• Integrated State Space Reduction Approach
• Conclusions
• Directions for Future Work

3
Formal Verification by Model Checking

• Continuously operating concurrent systems (e.g.
  operating systems, hardware
• controllers and network protocols)
• Ongoing, reactive semantics
• Non-terminating, infinite computations
• Manifest non-determinism
• Temporal Logic Model checking Clarke,Emerson
  81Queille,Sifakis 82
• Formal model, M
• (state transition system - finite state machines)
• Specification, P
• (temporal logic)
• Algorithm to check if M satisfies P, M P
• exhaustive enumeration of all states reachable by
  the system
• when the design fails to satisfy a desired
  property, a counterexample is generated

4
State Space Explosion

• Problem Size of the state graph can be
  exponential in size of the program
• text (both in the number of the program variables
  and the number of
• program components)
• M M1 Mn
• If each Mi has just 2 local states, potentially
  2n global states
• Research Directions State space reduction
• Principal Approaches
• Abstraction (elimination of details irrelevant to
  verification)
• Compositional reasoning (reasoning about parts of
  the system)

5
Application of Model Checking to Hardware
Verification

• Simple data structures are used
• Systems are modular
• Mostly finite-state systems
• System components have well defined interfaces
• Mostly synchronous execution

6
Application of Model Checking to Software
Verification

• Complex data structures are used
• Procedural or OO design
• Non-finite state systems
• System components do not have well defined
  interfaces
• Complex coordination between SW components
• Synchronous or asynchronous execution

7
Model Checking Software (current practice)

• ? 1. Design/Implementation/Testing
• ? 2. Modeling/Property Specification
• Finite-state model extraction
• Simplifications
• Restrictions
• ? 3. Verification
• Abstractions
• Divide-and-conquer
• techniques (when applicable)

• Limitations
• Final (expensive) stage in the program
  development
• Consistency between code and model
• Limited to simplified systems

8
Outline

• Model Checking Software
• Integrated Design and Verification Approach
• Integrated State Space Reduction Approach
• Conclusions
• Directions for Future Work

9
Model Checking Software (UT Austin Bell Labs
Project)
? 4. Code Generation (last stage)

• ? 1. Executable Design Specifications
• Abstraction from low-level to
• high-level operations

• ? 2. Modeling/Property Specification
• Finite-state model extraction

• 3. Verification
• State space reduction techniques

• Advantages
• Earlier bug detection
• Direct translation of informal program into
  formal syntax (no simplifications)
• Separation of concerns abstraction of
  control from data
• Domain-specific property specification

10
xUML An Executable OO Modeling Language

• Executable dialect of UML
• A system consists of interacting sequential
  programs (class instances)
• System and class hierarchies
• Class instances communicate mainly through
  asynchronous event passing with buffering
• Behavior of class instances is defined as State
  Models
• State Models are extended with state actions
• Each action is run-to-completion
• State transitions are enabled by events

11
Executable OO Modeling Language (textual xUML)

• An xUML system is a parallel composition of
  individual sequential program,
• P p1 pn,

Sample commands of xUML programs Assignments
x exp x anyexp1 , ,
expn Communication Generate ei(ID,exp) -
Event generation Receive ei(ID,x)
- Event consumption Compounds if
then else, while do od, switch
12
A Sample xUML State Model
State Transition
State Action
Message Type
State
13
Model Checking xUML Programs(UT-Bell Labs
Project)
xUML Model
xUML Query
xUML Level Error Report
xUML-to-S/R Translation
Error Report Generation
S/R Model
S/R Query
S/R Query
COSPAN Error Track
Model Checking with COSPAN Model Checker
Legend
Input
Output
Data
Process
14
COSPAN Model Checker and S/R Automaton Language

• COSPAN is an ? - automata-based model checker and
  input models and queries are formulated in S/R
• In S/R, a system is a synchronous parallel
  composition of processes

15
xUML-to-S/R Model Translation

• Maps xUML class instances to S/R processes
• Models asynchrony with synchrony
• An S/R process as global execution scheduler
• Message buffers by separate S/R processes
• Simulates dynamic creation of class instances
• Bounds infinite state spaces of xUML models
• Reuses modules from SDLCheck Kurshan, Levin01,
  such as optimization modules that conduct Static
  Partial Order Reduction

16
xUML Level Query Formulation
Proposition
Semantic Constructs of xUML Model

• DECLARE Joint_2_in_Move_EE ltltJoint 2gtgt Move_EE
• DECLARE Recovery_Called ltltRecovery 1gtgt
  recovery_status 1
• NEVER (Joint_2_in_Move_EE AND Recovery_Called)

Instantiation of Temporal Template
17
Demonstration
Property Specification Interface
xUML IDE
Error Visualizer
xUML-to-S/R Translator
Error Report Generator
COSPAN Model Checker
18
Step-by-Step Demonstration
Designer
Property Specification Interface
xUML IDE
Error Visualizer
Error Report
xUML Model
Property
xUML-to-S/R Translator
Error Report Generator
Error Track
S/R Model
S/R Query
COSPAN Model Checker
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
Step-by-Step Demonstration
Designer
Property Specification Interface
xUML IDE
Error Visualizer
Error Report
xUML Model
Property
xUML-to-S/R Translator
Error Report Generator
Error Track
S/R Model
S/R Query
COSPAN Model Checker
26
(No Transcript)
27
Step-by-Step Demonstration
Designer
Property Specification Interface
xUML IDE
Error Visualizer
Error Report
xUML Model
Property
xUML-to-S/R Translator
Error Report Generator
Error Track
S/R Model
S/R Query
COSPAN Model Checker
28
(No Transcript)
29
(No Transcript)
30
Step-by-Step Demonstration
Designer
Property Specification Interface
xUML IDE
Error Visualizer
Error Report
xUML Model
Property
xUML-to-S/R Translator
Error Report Generator
Error Track
S/R Model
S/R Query
COSPAN Model Checker
31
(No Transcript)
32
Step-by-Step Demonstration
Designer
Property Specification Interface
xUML IDE
Error Visualizer
Error Report
xUML Model
Property
xUML-to-S/R Translator
Error Report Generator
Error Track
S/R Model
S/R Query
COSPAN Model Checker
33
(No Transcript)
34
Step-by-Step Demonstration
Designer
Property Specification Interface
xUML IDE
Error Visualizer
Error Report
xUML Model
Property
xUML-to-S/R Translator
Error Report Generator
Error Track
S/R Model
S/R Query
COSPAN Model Checker
35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
NASA Robot Controller System
39
NASA Robot Controller System

• Actual robot control system deployed in space
  (Canadian arm)
• Complex functionality (kinematics control,
  obstacle avoidance, fault tolerance, performance
  evaluation, etc.)
• Complex coordination (hand shaking) between
  functional units
• Stringent reliability requirements
• Distributed control
• xUML framework for design and validation of robot
  control algorithms
• Discrete real-time modeling
• 800K LOC of textual xUML
• Abstract interfaces to the computational
  libraries
• Computational libraries (C)
• 300K LOC, 150 classes, 500 methods of C
• 34 functional properties, 20 implementation
  properties
• 6 logical errors were found and reported to NASA

40
Class Information Model of the Robot Controller
Systems
41
xUML Modeling of the NASA Robot Controller System
Arm xUML program

EndEffector xUML program
42
Examples of the Robot Control Properties

• Control Termination Eventually the robot control
  terminates
• EventuallyAlways(abort_var1)
• Safety Operation If the EndEffector reaches an
  undesired position than the program terminates
  prior to a new move of the EndEffector
• AfterAlwaysUntil(undesired_position
  1,ee_reference1,abort_var1)
• Configuration Validity Check If an instance of
  the EndEffector class is in the
  FollowingDesiredTrajectory state than the
  instance of the corresponding Arm class is in the
  Valid state
• Always((ee_reference1) -gt(arm_status1))
• Proper Program Termination The program
  terminates when it either completes the task or
  reaches the state where there is no solution for
  the fault recovery
• AlwaysUntil(abort_var0,end_position1 OR
  (recovery_status1 AND number_joints1))

43
Outline

• Model Checking Software
• Integrated Design and Verification Approach
• Integrated State Space Reduction Approach
• Conclusions
• Directions for Future Work

44
Efficient Model Checking of xUML Programs

• State Space Reduction Approach
• Exploit design modularity for modular
  verification
• Reduce complexity of the program prior to
  generation of state graph (by syntactic analysis
  and program transformation)
• Use domain specific knowledge to derive
  abstractions and other reduction techniques
• Use existing state space reduction techniques

45
Integrated State Space Reduction Approach
 
Methodological Approaches
Algorithmic Approaches
46
Assume-Guarantee Compositional Reasoning

• In the assume-guarantee paradigm each component
  guarantees properties based on
• assumptions about other components via proof
  rules
• M1 T2 T1
• M2 T1 T2
• Circularity during verification of different
  blocks is broken by induction over time
• AbadiLamport95AlurHenzinger96HenzingerQadeerR
  ajamani99Kurshan94McMillan98Stark85
• A trace is a sequence of states
• Composition of FSM () is the intersection of
  traces
• Consistency check () is the trace containment
  check

Constraining environment
M1 M2 T1 T2
47
Scalability of Multi-Process Model Checking
Limitation Properties when used as constraints
commonly do not give sufficient details about the
verifiable processes Approach Add abstraction
constraints Abstraction constraints (cf.
Kurshan 94, Henzinger 98) are added to the
property specifications M1 T2 T1
T1abs Tnabs T1abs , , Tkabs
abstraction constraints Abstraction
constraints specification - temporal logic
formulae constraining the external variables of
the verifiable processes - translation of the
formulae to processes
48
Limitations

• Observation
• Conventional software structure and behaviors
  preclude system decomposition and
• applicability of assume/guarantee reasoning
• Hardware (Spatial Modularity)
• Natural division into components
• System components have well defined interfaces
• Precisely defined communication protocols
• Software (Not Spatially Modular)
• Monolithic designs (even for OO programs)
• Difficulties in property decomposition
• No clean interfaces
• Complex interaction between SW elements
• Difficulties in identifying environment
  assumptions
• Inability to specify meaningful abstraction
  constraints

49
Design for Verification

• Approach Enforce software design discipline
• apply design constraints
  analogous to the physical
  constraints of hardware designs
• Principle 1 Perform encapsulation at
  the component level (not an object)
• Principle 2 Design software components to
  spatial modularity
• What to do?
• Make state spaces of components rigorously
  disjoint
• Channel communication through precisely defined
  interfaces
• Specify precise communication protocols

50
Assume/Guarantee Reasoning of Software Spatial
Designs
51
Assume/Guarantee Reasoning of Software Spatial
Designs


T2abs T1abs
M1 T2 T1 M2 T1 T2
T2abs T1abs
52
Verification Statistics Robot Controller System
Memory, B
Models
Memory/Time exhaustion
i(M) Monolithic verification, i number of
joints i(C) Compositional verification of
Kinematics component Platform HP9000 (440MHz)
with 6144 MB RAM
53
Abstractions in Model Checking

• Data Abstraction (abstraction of details
  irrelevant to verification of a property)
• Approach Mabs ?? T ? Mconc ?? T
• To Prove soundness and completeness
• Systematic Construction of Abstractions
  (Predicate Abstraction) Saidi,Graf 97
• Define an abstraction function as a predicate
  over concrete data
• Specify decision procedures to compute a set of
  abstraction predicates
• Demonstrate the soundness and completeness of the
  abstraction
• Refinementbased abstraction MSR SLAM
  Project,Clarke et. al. 00, Saidi 00,
• Visser et. al 00

54
Abstractions in Model Checking Limitations

• Abstraction might be expensive!
• Complex computation procedures to define a set of
  the abstraction predicates
• Memory exhaustion during computation of
  predicates for large systems and complex
  properties
• Behavioral over-approximations caused by the
  abstraction might lead to the state space
  explosion
• Can we do better?
• Abstract and verify selectively
• Example Abstract with respect to a subset of
  properties (not a single property)
• Simplify decision procedures
• Example Eliminate some predicates from
  consideration

55
Model Checking Programs with Loops
Control intensive systems typically execute loops
of control functions. Each decision point in the
loop typically depends on a small number of
variables and each possible branch is commonly
taken for a wide range of data values of these
variables. Let Xcontrol ? X be the
control effect variables (variables that
determine the control flow). The global state
transition graph incorporates all of the loops
for all values of the control effect variables.
56
Example of a Program with Loops
EndEffector xUML program
Arm xUML program

57
Control Abstraction
Goal Verify Control Properties (properties
defined over states that input events) of
programs with loops Approach Abstract
execution of loops from valuation of data -
Construct an abstract program which contains all
of the control flow paths in the concrete
program Atomicity of Program Structure
Basic Block is a sequence of statements which
can be entered by an event only at the head
statement and which always run to completion.
58
Key Ideas

• Exploit atomicity of the program structure (not
  predicates) to identify control flow sequences
• 2. Compute output ranges of each basic block
  that has loop predicates
• 3. Transform control flow predicates of each
  basic block into a multi-way selector
• expression (non-deterministic choice) that
  controls all possible sequences of events.
• Each output of an abstract basic block is
  controlled by a single value
• 4. Perform dependency analysis and
  source-to-source transformation

59
Loop Abstraction for Model Checking of Control
Properties
 

60
Verification Statistics Robot Controller
Memory
Models
5(C)
6(C)
Memory/Time exhaustion
i(C) Concrete program, i number of joints i(A)
Abstract program Platform HP9000 (440MHz) with
6144 MB RAM
61
Lessons Learned

• Integration design and verification environment
  enables verification of non-trivial software
  systems
• Translation of software into a formal language of
  model checkers is simplified
• Model checker is used as a debugging tool during
  software design
• Software design management enhances the
  applicability of the existing state space
  reduction techniques
• Testing of design-level specifications is helpful
  for specification of useful abstractions
• Integrated state space reduction supports
  verifying larger systems
• State space reduction techniques conducted by the
  syntactic program transformation are applicable
  without a change to the model checking tools and
  can be combined with the existing reduction
  techniques
• Effectiveness of reduction algorithms depends on
  interaction (combination, order of application,
  etc.) among reduction algorithms

62
Some Ideas for Future Work

• Integration of abstraction techniques
• Combined abstraction approach syntactic program
  transformation and reductions of the state
  transition graphs
• Systematic design and analysis of refinement
  procedures for design-level specifications
• Predictable component assembly
• Abstraction techniques to check consistency of
  the component interfaces
• Integration of model checking and testing
  techniques
• Model checking to support interactive simulation
  during analysis of errors
• To track multiple processes
• To allow analysis backwards and forward during
  the execution
• Testing of data dependent parts of the code which
  can not be handled by finite-state model checking
  techniques
• Engineering of software systems to enable
  symbolic verification to be efficient