1 / 20

Basic concepts of Model Checking

Basic concepts of Model Checking. Model-Based Programming and Verification. Introduction. Dependence on the correct functioning of computing systems more and more evident. e.g. automatic control of heating systems, safety systems of cars. Not even the smallest faults can be tolerated.

tarika
Download Presentation

Basic concepts of Model Checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Basic concepts ofModel Checking Model-Based Programming and Verification

  2. Introduction • Dependence on the correct functioning of computing systems more and more evident. • e.g. automatic control of heating systems, safety systems of cars. • Not even the smallest faults can be tolerated. • Only formal verification methods are able to guarantee that a software system is free of errors from the design to the deployment of actual code.

  3. Model checking… • One of the most widespread formal methods • Already proved its effectiveness in real world situations. • Unfortunately the separately developed software components make it difficult to use as the environment of deployment and the original development are rarely the same. • Building the information of correctness into the design and the code might sound reasonable (Design-By-Contract).

  4. Model checking… • Is an algorithmic way of verifying whether a desired property holds for a model of a system • A (software or hardware) system can usually be modeled in a special-purpose language • The requirements are usually specified in some temporal logic (LTL, CTL, CTL*, etc.) • As an intermediate step, a state space is generated from the specification, in the form of a graph covering all possible behavior • A model checking algorithm decides whether a given property holds for a model (verified) or not (refuted). In the latter case a counterexample (or witness) is provided • In practice, model checking can significantly contribute to the early detection of faults and errors in the early design phases.

  5. Problems of model checking • State space explosion: arises from many transitions parallel. • Expressive logics: have complex model checking algorithms • How to solve? • On-the-fly: integrate the generation and verification phases, to prune the state space • Symbolic model checking: represent sets of states by clever data structures (BDD) • Partial-order reduction: ignore certain execution orders, covered by others • Abstraction: ignore and remove details from the model

  6. State space • The behavior of a system is modeled by a graph, consisting of: • Nodes, representing states of the system (variables, etc.) • Edges, representing state transitions (events, etc.) • Information can be associated with either states or transitions: • Kripke structures: information on states, called atomic propositions (AP) • Labeled Transition Systems: information on transitions, called action labels

  7. Kripke structures • Let AP be a set of atomic propositions • A Kripke structure over AP is a tuple M=(S,S0,R,L), where • S is a finite set of states • S0S is the set of initial states • RSxS is a total binary relation (representing the set of transitions) on S, meaning for all sS, there exists tS such that sRt. • L: S2AP, assigns the set of atomic propositions holding in a state • A path  in M is an infinite sequence s0,s1,s2,… such that for all i, siS and SiRsi+1

  8. CTL* • CTL* means (Full) Computation Tree Logic • CTL* formulas hold for states and/or infinite paths • CTL* has the following temporal operators, which are used to express properties of infinite paths: • neXt, Future, Globally, Until, Releases • Intuitive meanings: • Xf: f holds in the next state in this path • Ff: f holds somewhere on this path • Gf: f holds everywhere on this path • fUg: g holds somewhere on this path, and f holds in all preceding states • fRg: g holds as long as f has not held before • Difference between: FGf (almost always) and GFf (infinitely often)

  9. CTL* operators (cont.) • CTL* consists of: • Atomic propositions (AP) • Boolean connectives:  (not),  (or),  (and) • Temporal operators (on paths, previous slide) • Path quantifiers (on states) • The path quantifiers of CTL* are needed to express properties on the branching structure of a system: • For All paths, there Exists a path • Intuitive meanings: • Af: f holds for all paths from this state • Ef: f holds for some path from this state

  10. Properties described • mutual exclusion: always ( cs1  cs2) • non starvation: always (request eventuallygrant) • communication protocols: ( get-message) until send-message

  11. Property types

  12. Model Checking M |= f* • The Model Checking algorithm works iterativelyon subformulas of f , from simpler subformulas to more complex ones • When checking subformula g of f we assume that all subformulas of g have already been checked • For subformula g, the algorithm returns the set of states that satisfy g ( Sg ) • The algorithm has time complexity: O( |M|  |f| ) Clarke, E., Grumberg, O., Peled, D. (2000) Model Checking, MIT Press, Cambridge, MA.

  13. Model checking f =EF g Given a model M= < S, S0, R, L > and Sg the sets of states satisfying g in M procedureCheckEF (Sg ) Q := emptyset; Q’ := Sg ; while Q  Q’ do Q := Q’; Q’ := Q  { s | s' [ R(s,s’)  Q(s’) ] } end while Sf := Q ; return(Sf )

  14. Model checking f =EG g CheckEG gets M= < S, S0, R, L > and Sg and returns Sf procedureCheckEG (Sg) Q := S ; Q’ := Sg ; while Q  Q’ do Q := Q’; Q’ := Q { s | s' [ R(s,s’)  Q(s’) ] } end while Sf := Q ; return(Sf )

  15. Symbolic model checking* If the model is given explicitly (e.g. by adjacent matrix) then only systems with about ten Boolean variables (~1000 states) can be handled Symbolic model checking uses Binary Decision Diagrams ( BDDs ) to represent the model and sets of states. It can handle systems with hundreds of Boolean variables. Burch 1990

  16. Binary decision diagrams (BDDs) • Data structure for representing Boolean functions • Often concise in memory • Canonical representation • Boolean operations on BDDs can be done in polynomial time in the BDD size

  17. BDDs in model checking • Every set A can be represented by its characteristic function1 if uAfA(u) = 0 if u  A • If the elements of A are encoded by sequences over {0,1}n then fA is a Booleanfunction and can be represented by a BDD

  18. Assume that states in model M are encoded by {0,1}n and described by Boolean variables v1...vn • Sf can be represented by a BDD over v1...vn • R (a set of pairs of states (s,s’) ) can be represented by a BDD over v1...vn v1’...vn’

  19. State explosion problem • Hardware designs are extremely large: > 106 registers • state of the art symbolic model checking can handle medium size designs effectively:a few hundreds of Boolean variables Other solutions for the state explosion problem are needed!

  20. Possible solution Replacing the system model by a smaller one (less states and transitions) that still preserves properties of interest • Modular verification • Symmetry • Abstraction

More Related