Model Checking Large-Scale Software - PowerPoint PPT Presentation

Loading...

PPT – Model Checking Large-Scale Software PowerPoint presentation | free to download - id: 16619a-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Model Checking Large-Scale Software

Description:

Model Checking Large-Scale Software. Natasha Sharygina. Carnegie Mellon University ... Continuously operating concurrent systems (e.g. operating systems, hardware ... – PowerPoint PPT presentation

Number of Views:38
Avg rating:3.0/5.0
Slides: 63
Provided by: Nat9150
Learn more at: http://www.cs.cmu.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com