Model Checking

1
Model Checking

• By Eddie Nevoani

2
Introduction

• What is Model Checking?
• The Need for Formal Methods
• Hardware and Software Verification
• The Process of Model Checking
• Symbolic Algorithms
• Partial Order Reduction
• Kripke structures
• The Model Checking Problem
• CTL Language
• CTL Model Checking
• A CTL Example - Microwave

3
What is Model Checking?

• Model Checking is an automatic technique for
  verifying finite state concurrent systems. It has
  a number of advantages over traditional
  approaches to this problem that are based on
  simulation, testing, and deductive reasoning.

4
The Need for Formal Methods

• The need for reliable hardware and software
  systems is critical. As the involvement of such
  systems in our lives increases, so too does the
  burden for ensuring their correctness.
  Unfortunately, it is no longer feasible to shut
  down a malfunctioning system in order to restore
  safety. We are very much dependent on such
  systems for continuous operation.

5
Hardware and Software Verification

• The principal validation methods for complex
  systems are simulation, testing, deductive
  verification, and model checking. Simulation and
  testing both involve making experiments before
  deploying the system in the field. While
  simulation is performed on an abstraction or a
  model of the system, testing is performed on the
  actual product.

6
Hardware and Software Verification Cont

• In the case of circuits, simulation is performed
  on the design of the circuit, whereas testing is
  performed on the circuit itself. In both cases,
  these methods typically inject signals at certain
  points in the system and observe the resulting
  signals at other points. For software, simulation
  and testing usually involve providing certain
  inputs and observing the corresponding outputs.

7
Hardware and Software Verification Cont

• These methods can be a cost-efficient way to find
  many errors. However, checking all of the
  possible interactions and potential pitfalls
  using simulation and testing techniques is rarely
  possible.

8
Hardware and Software Verification Cont

• The term deductive verification normally refers
  to the use of axioms and proof rules to prove the
  correctness of systems. However, deductive
  verification is a time-consuming process that can
  be performed only by experts who are educated in
  logical reasoning and have considerable
  experience.

9
Hardware and Software Verification Cont

• The proof of a single protocol or circuit can
  last days or months. Consequently, use of
  deductive verification is rare. It is applied
  primarily to highly sensitive systems such as
  security protocols, where enough resources need
  to be invested to guarantee their safe usage.

10
Hardware and Software Verification Cont

• It is important to realize that some mathematical
  tasks cannot be performed by an algorithm. The
  theory of computability provides limitation on
  what can be decided by an algorithm. In
  particular, it shows that there cannot be an
  algorithm that decides whether an arbitrary
  computer program (written in some programming
  language like C or Pascal) terminates.

11
Hardware and Software Verification Cont

• This immediately limits what can be verified
  automatically. In particular, correct termination
  of programs cannot be verified automatically in
  general. Thus, most proof systems cannot be
  completely automated.

12
Hardware and Software Verification Cont

• An advantage of deductive verification is that it
  can be used for reasoning about infinite state
  systems. This task can be automated to a limited
  extent. However, even if the property to be
  verified is true, no limit can be placed on the
  amount of time or memory that may be needed in
  order to find a proof.

13
Hardware and Software Verification Cont

• Model checking is a technique for verifying
  finite state concurrent systems. One benefit of
  this restriction is that verification can be
  performed automatically. The procedure normally
  uses an exhaustive search of the state space of
  the system to determine if some specification is
  true or not.

14
Hardware and Software Verification Cont

• Given sufficient resources, the procedure will
  always terminate with a yes/no answer. Moreover,
  it can be run on moderate-sized machines (but
  usually not on an average desktop computer).

15
Hardware and Software Verification Cont

• Although the restriction to finite state may seem
  to be a major disadvantage, model checking is
  applicable to several very important classes of
  systems. Hardware controllers are finite state
  systems, and so are many communication protocols.
  In some cases, systems that are not finite state
  may be verified using model checking in
  combination with various abstraction and
  induction principles.

16
Hardware and Software Verification Cont

• Finally, in many cases errors can be found by
  restricting unbounded data structures to specific
  instances that are finite state. For example,
  programs with unbounded message queues can be
  debugged by restricting the size of the queue to
  a small number like two or three.

17
Hardware and Software Verification Cont

• Because model-checking can be done automatically,
  it is preferable to deductive verification,
  whenever it can be applied. However, there will
  be always some critical applications in which
  theorem proving is necessary for complete
  verification.

18
The Process of Model Checking

• Applying model checking to a design consists of
  several tasks
• Modeling The first task is to convert a design
  into a formalism accepted by a model checking
  tool. In many cases, this is simply a compilation
  task. In other cases, owing to limitations on
  time and memory, the modeling of a design may
  require the use of abstraction to eliminate
  irrelevant or unimportant details.

19
The Process of Model Checking Cont

• Specifications Before verification , it is
  necessary to state the properties that the design
  must satisfy. The specification is usually given
  in some logical formalism. For hardware and
  software systems, it is common to use temporal
  logic, which can assert how the behavior of the
  system evolves over time.

20
The Process of Model Checking Cont

• Verification Ideally the verification is
  completely automatic. However, in practice it
  often involves human assistance. One such manual
  activity is the analysis of the verification
  results. In case of a negative result, the user
  is often provided with an error trace. In this
  case, analyzing the error trace may require a
  modification to the system and reapplication of
  the model checking algorithm.

21
The Process of Model Checking Cont

• Verification Cont An error trace can also result
  from incorrect modeling of the system or from an
  incorrect specification. The error trace can also
  be useful in identifying and fixing these two
  problems. A final possibility is that the
  verification task will fail to terminate
  normally, due to the size of the model, which is
  too large to fit in the computer memory. In this
  case, it may be necessary to redo the
  verification after changing some of the
  parameters of the model checker or by adjusting
  the model (e.g., by using additional
  abstractions).

22
Symbolic Algorithms

• In the original implementation of the model
  checking algorithm, transition relations were
  represented explicitly by adjacency lists. For
  concurrent systems with small numbers of
  processes, the number of states was usually
  fairly small, and the approach was often quite
  practical.

23
Symbolic Algorithms Cont

• In systems with many concurrent parts however,
  the number of states in the global state
  transition graph was too large to handle.in 1987
  McMillan realized that by using a symbolic
  representation for the transition graphs, much
  larger systems could be verified. The new
  symbolic representation was based on Bryants
  ordered binary decision diagrams(OBDD).

24
Symbolic Algorithms Cont

• OBDDs provide a canonical form for Boolean
  formulas that is often substantially more compact
  than conjunctive or disjunctive normal form.
  Because the symbolic representation captures some
  of the regularity in the state space determined
  by circuits and protocols, it is possible to
  verify systems with extremely large numbers of
  states (more than )

25
Partial Order Reduction

• Verifying software causes some problems for model
  checking. Software tends to be less structured
  than hardware. In addition, concurrent software
  is usually asynchronous, that is, most of the
  activities taken by different processes are
  performed independently, without a global
  synchronizing clock.

26
Partial Order Reduction Cont

• For these reasons, the state explosion phenomenon
  is a particularly serious problem for software.
  Consequently, model checking has been used less
  frequently for software verification than for
  hardware verification. The most successful
  techniques for dealing with this problem are
  based on the partial order reduction

27
Partial Order Reduction Cont

• These techniques exploit the independence of
  concurrently executed events. Two events are
  independent of each other when executing them in
  either order results in the same global state.
  The partial order reduction techniques make it
  possible to decrease the number of interleaving
  sequences that must be considered.

28
Partial Order Reduction Cont

• When a specification cannot distinguish between
  two interleaving sequences that differ only by
  the order in which concurrently executed events
  are taken, it is sufficient to analyze only one
  of them. These methods are related to the partial
  order model of program execution.

29
Kripke Structures

• Let AP be a set of atomic propositions. A Kripke
  structure M over AP is a four tuple M ( ,
  , R, L ) where
• S is a finite set of states
• S is the set of initial states
• R S x S is a transition relation that must be
  total, that is, for every state s S there is
  a state S such that R(s, ).
• LS is a function that labels each
  state with the set of atomic proposition true in
  that state.

30
The Model Checking Problem

• The model checking problem is easy to describe.
  Given a Kripke structure M (S, R, L) that
  represents a finite state concurrent system and a
  temporal logic formula f expressing some desired
  specifications. Find the set of all sets in S
  that satisfy f
• s S M, s f .

31
The Model Checking Problem Cont

• Normally, some states of the concurrent system
  are designed as initial states. The system
  satisfies the specification provided that all of
  the initial states are in the set.

32
The Model Checking Problem Cont

• The first algorithms for solving the model
  checking problem used an explicit representation
  of the Kripke structure as a labeled, directed
  graph with arcs given by pointers, nodes
  represented the state in S. The arcs in the graph
  give the transition relation R, and the labels
  associated with the nodes described the function
  
• LS .

33
CTL Language (Computation Tree Logic)

• CTL formulas describe properties of computation
  trees. It has five basic temporal operators which
  describe properties of a path through the tree
• X (next time) requires that a a property holds
  in the second state of the path.
• F (in the future) operator is used to assert
  that a property will hold at some state on the
  path.

34
CTL Language (Computation Tree Logic) Cont

• G (Globally) specifies that a property holds at
  every state on the path.
• U (Until) operator is used to combine two
  properties. It holds if there a state on the path
  where the second property holds, and at every
  preceding state on the path, the first property
  holds.
• R (Release) is the logical dual of U operator.
  It requires that the second property holds along
  the path up to and including the first state
  where the first property holds. However, the
  first property is not required to hold
  eventually.

35
CTL Language (Computation Tree Logic) Cont

• g
• g
  g g
• . . . . .
  . . .
• . . . . .
  . . .
• . . . . .
  . . .
• M, EF g M, AF g

36
CTL Language (Computation Tree Logic) Cont
g
g g
g g
g g g g g
. . . . .
. . . . . .
. . . . . .
. . . . . .
. M, EG g M,
AG g
37
CTL Model Checking

• Let M (S, R, L) be a Kripke structure. Assume
  that we want to determine which states in S
  satisfy the CTL formula f. The algorithm will
  operate by labeling each state s with the set
  label(s) of sub formula f which are true in s.
  Initially label(s) is just L(s). The algorithm
  then goes through a series of stages.

38
CTL Model Checking Cont

• During the ith stage, sub formulas with i-1
  nested CTL operators are processed. When a sub
  formula is processed, it is added to the labeling
  of each state in which it is true. Once the
  algorithm terminates, we will have that M, s f
  iff f label(s).

39
CTL Model Checking Cont

• Any CTL formula can be expressed in terms of
  , , EX, EU and EG. Thus, for the intermediate
  stages of the algorithm it is sufficient to be
  able to handle six cases, depending on whether g
  is atomic or has one of the following forms f
  , f1 f2 , EX f1, Ef1 U f2, or EG f1.

40
CTL Model Checking Cont

• For formulas of the form , we label those
  states that are not labeled by f1.
• For f1 f2, we label any state that is labeled
  either by f1 or by f2.
• For EX f1, we label every state that has some
  successor labeled by f1.
• For gf1 U f2 we first find all states that are
  labeled by f2. We then work back words using the
  converse of the transition relation R and find
  all states that can be reached by a path in which
  each state is labeled with f1. All such states
  should be labeled with g.

41
CTL Model Checking Cont

• For gEG f1 it is slightly more complicated. It
  is based on the decomposition of the graph into
  nontrivial strongly connected components (SCC).
  Let M be obtained from M by deleting from S all
  of those states which f1 does not hold and
  restricting R and L accordingly. Thus, M(S,
  R, L) where Ss SM, s f1, R
  and L .

42
A CTL Example - Microwave

• This example describes the behavior of a
  microwave oven. In the next figure we see the
  Kripke structure for the oven. For clarity, each
  state is labeled with both the atomic
  propositions that are true in the state and the
  negations of the propositions that are false in
  the state. The labels on the arcs indicate the
  actions that cause transitions and are not part
  of the Kripke structure.

43
Figure 1

• 1
• start oven
  open oven cook
• open door close door
• 2 3 done
  4
• Open close reset
• Door door
  start oven
  start cooking
• 5 6
  7
• warm up

Start Close Heat Error
Start Close Heat Error
Start Close Heat Error
Start Close Heat Error
Start Close Heat Error
Start Close Heat Error
Start Close Heat Error
44
A CTL Example Microwave Cont

• We check the CTL formula AG(Start AF Heat)
  which is equivalent to the formula EF(Start
  Heat).
• We start by computing the set of states that
  satisfy the atomic formulas and proceed to more
  complicated sub formulas. Let S(g) denote the set
  of all states labeled by the sub formula g.

45
A CTL Example Microwave Cont

• S(Start) 2, 5, 6, 7.
• S( Heat) 1, 2, 3, 5, 6.
• In order to compute S(EG Heat) we first find
  the set of nontrivial strongly connected
  components in S S( Heat).
• SCC 1, 2, 3 ,5. We proceed by setting T.
  the set of all states that should be EG Heat
  to be the union over the elements of SCC, that
  is, initially T1, 2, 3, 5. No other state in
  S can reach a state in T along a path in S.

46
A CTL Example Microwave Cont

• Thus, the computation terminates with
• S(EG Heat) (1, 2, 3, 5.
• Next we compute
• S(Start EG Heat) 2, 5.
• When computing S(EF(Start EG Heat)), we
  start by setting T S(Start EG Heat), Next
  we use the converse of the transition relation to
  label all states in which the formula holds. We
  get

47
A CTL Example Microwave Cont

• S(EF(Start EG Heat)) 1, 2, 3, 4, 5, 6,
  7.
• Finally, we compute that
• S( EF(Start EG Heat)) .
• Since the initial state 1 is not contained in
  this set, we conclude that the system described
  by the Kripke structure does not satisfy the
  given specification.