Presented by Maya Arbel , May 2012 - PowerPoint PPT Presentation

symbolic model checking with rich assertional languages y kesten o maler m marcus a pnueli e shahar n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Presented by Maya Arbel , May 2012 PowerPoint Presentation
Download Presentation
Presented by Maya Arbel , May 2012

play fullscreen
1 / 70
Presented by Maya Arbel , May 2012
97 Views
Download Presentation
kaori
Download Presentation

Presented by Maya Arbel , May 2012

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Symbolic model checking with rich assertional languagesY. Kesten, O. Maler, M. Marcus, A. Pnueli, E. Shahar Presented by Maya Arbel, May 2012

  2. Parameterized Systems • In the previous lecture we saw the problem of verification of parameterized systems. • Given a network of processes, such that each process is a finite state machine, verify some property for the entire network. • This is the uniform verification problem: can we model check that the network is correct for all possible configuration?

  3. Parameterized Systems (Cont.) • In general the problem of uniform verification is undecidable. • In the previous lecture we saw: • The use of network grammars as a representation of the topology. • The use of regular language for representing the behavior of a single process. • In this lecture we will see a simplified solution using a single regular language to describe both the topology and the local state of each process.

  4. The Solution Idea • With an appropriate choice of an assertional language, the paradigm of symbolic model checking is adequate for uniform verificationof parameterized systems. • The resulting process: • Process Network • Dist. Algorithm • Translation to • Assertional Language • Symbolic Model Checking

  5. The Solution Idea (Cont.) • Advantage: • Simple approach. • Disadvantage: • Each topology require the development of a different assertional language.

  6. Symbolic Model Checking • Procedure SYMB-MC is a symbolic model checking procedure for showing that the invariance property is satisfied by system . g- State formula -All states that have a stae as a successor - All initial states in P

  7. Symbolic Model Checking (Cont.) • Procedure SYMB-MC attempts to compute an assertion characterizing all the states from which a -state can be reached by a finite number of steps. • If the search loop terminates at iteration , then provides such an assertion. • Since the problem is undecidable, the procedure may fail to terminate.

  8. Symbolic Model Checking (Cont.) • In order to apply the SYMB-MC procedure one chooses an assertional language . • The language should satisfy the following requirements: • The property and the assertion should be expressible in . • The language should be effectively closed under negation and disjunction, and possess an algorithm for deciding equivalence of two assertions. • There should exist an algorithm for constructing . • We refer to a language satisfying these three requirements as a language adequate for symbolic model checking.

  9. Process Array MUX Example • Goal: Verify that at most one process is in the critical section. When If then Await N T C

  10. Process Array MUX Example (Cont.) • Each process has two local state variables: • a local boolean variable . • a control variable ranging over the set of locations . • Process sends the boolean value T on channel to its right neighbor (if ) • Process reads into variable has a boolean value from its left neighbor on channel (if ). Await T N C

  11. Process Array MUX Example (Cont.) • We have our Distributed Algorithm. • Next step: Define an adequate assertional language.

  12. Logic • We will use the logic FS1S as a specification language for the sets of global states of parameterized systems. • FS1S has the expressive power of regular expressions, as well as finite automata, which are the representation underlying our implementation.

  13. The Logic FS1S • Syntax: We assume a signature consisting of a finite set of finite alphabets. • The vocabulary consists of : • Position variables … • Array variables

  14. The Logic FS1S(Cont.) • Positions (first order) terms: • The constant 0 • Any position variable . • , where is a position term. • Letter terms • Every is a -term • If is a -array variable and is a position term, then is a -term.

  15. Process Array MUX and FS1S • Our signature contains two alphabets: • Each alphabet has an array variable: • - array • - array • Each array variable is of size , the number of processes

  16. The Logic FS1S- Formulas • Atomic formulas: • , where and are position terms and . • , where and are -term for some • Formulas: • An atomic formula is a formula. • Let and be formulas. Then , ,, are formulas, where is a position variable and is an array variable.

  17. The Logic FS1S(Cont.) • Semantics: Let be an FS1S formula. • A model for is given by , • where is a positive integer. • assigns to each position variable a natural number • assigns to each -array variable a -word of size .

  18. The Logic FS1S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • interprets every Position term into a natural number , as follows: • The constant symbol 0 is interpreted as the natural number 0. • For position variable , . • modulo .

  19. The Logic FS1S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • A -term is interpreted into a -letter, as follows: • The constant symbol is interpreted ad the -letter . • If and , then

  20. The Logic FS1S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • Formulas are interpreted into values as follows: • For propostion terms and , evaluates to 1 if the relation holds between and • For -term and , evaluates to 1 if equals • , ,,,where and are formulas, are interpreted in the standard way, after the formulas and are interpreted.

  21. The Logic FS1S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • Formulas are interpreted into values as follows: • is true if there exists a model , such that and ’ differ at most in the interpretation of the position variable , and such that . • is true if there exists a model , such that and ’ differ at most in the interpretation of the array variable , and such that .

  22. FS1S is Adequate • Remainder: a language is adequate if it satisfy the three requirements • The property and the assertion should be expressible in . • The language should be effectively closed under negation and disjunction, and possess an algorithm for deciding equivalence of two assertions. • There should exist an algorithm for constructing .

  23. FS1S is Adequate (Cont.) • Expressing and the invariant

  24. FS1S is Adequate (Cont.) • Expressing the transformer. • We define some helper formulas:

  25. FS1S is Adequate (Cont.) • Expressing the transformer. • There are transitions that affect only a single process: • express internal movements and variable changes within the process

  26. FS1S is Adequate (Cont.) • Expressing the transformer. • The other kind of transition involves two contiguous processes, i.e., and for some . • This corresponds to communication in which process sends the boolean value which process stores into .

  27. FS1S is Adequate (Cont.) • Expressing the transformer. • The formula represents a transition of a single process • The formula represent a joint communication transition. • The FS1S formula representing all transitions is: • Finally we get:

  28. Process Array MUX Example (Cont.) • We showed that FS1S is adequate. • Now we can use SYMB-MC to prove for MUX.

  29. Applying SYMB-MC to MUX • We start the iteration with the negation of the property we want to verify: • Next we apply to , as follows:

  30. Applying SYMB-MC to MUX (Cont.) • We continue iterating until the result converges:

  31. Applying SYMB-MC to MUX (Cont.) • The iteration converges at with the final value: • Finally, we check the intersection with the initial condition: • Since the intersection is false a configuration satisfying cannot be reached from an initial configuration. We can conclude that MUX satisfy .

  32. Additional Examples – Processor Ring • Example MUX considered processes arranged in an array. Once the rightmost process obtains the token, it cannot deliver it to any other process. • This is a degenerate version of the real protocol, in which the processes are arranged in a ring. • The transition relation for the ring configuration is:

  33. Additional Examples – Processor Ring (Cont.) • The transition relation for the ring configuration is: • The execution of procedure SYMB-MC converges, and is found to be an invariant of program PROC-RING.

  34. Additional Examples – Request Messages • The MUX satisfies the safety property of mutual exclusion, but does not satisfy the liveness property. • It does not guarantee that any process wishing to enter its critical section will eventually do so. • Example: consider the following 3-process configuration: • P[0] has the token. • P[2] is interested in entering its critical section. • P[2] will not be able to obtain the token until P[1] moves to state

  35. Additional Examples – Request Messages(Cont.) • An efficient solution which ensures accessibility, uses an additional local boolean variable . • Variable is true for all processes having some right neighbor who is interested in entering its critical section. • The improved protocol introduces an token which moves from right to left.

  36. Additional Examples – Request Messages(Cont.) When Await N T C e

  37. Additional Examples – Request Messages(Cont.) • The initial condition for program MUX-REQ is given by the FS1S formula:

  38. Additional Examples – Request Messages(Cont.) • The transition relation for program MUX-REQ is given by the disjunction: • is the idling transition. • describes changes in the control location of sub-process. • describes transitions related to communications on channel t. • describes transitions related to communications on channel r.

  39. Additional Examples – Request Messages(Cont.) • Transition relation is given by: • Transition relation is given by:

  40. Additional Examples – Request Messages(Cont.) • Transition relation is given by: • Applying procedure SYMB-MC to program MUX-REQ and the mutual-exclusion specification the procedure converges.

  41. Tree Languages • We extend the method of regular expressions over strings to deal with regular tree languages. • Process trees may have different out-degrees for different nodes. • We use the logic FS∗S as a specification language for regular sets of trees.

  42. Tree Languages (Cont.) • We define a tree structure to be a finite subset of . • contains the empty sequence . • If contains then it also contains: • for every

  43. Tree Languages (Cont.) • Let be an arbitrary alphabet. • A -tree consistsof: • Atree structure S. • A labeling function , mapping each node of the tree to a symbol.

  44. The Logic FS*S • Syntax: We assume a signature consisting of a finite set of finite alphabets. • The vocabulary consists of : • Position variables … • Tree variables

  45. The Logic FS*S(Cont.) • Positions (first order) terms: • The constant • Any position variable . • Letter terms • Every is a -term • If is a -tree variable and is a position term, then is a -term.

  46. The Logic FS*S- Formulas • Atomic formulas: • , where and are position terms and . • , where and are -term for some • Formulas: • An atomic formula is a formula. • Let and be formulas. Then , ,, are formulas, where is a position variable and is an tree variable.

  47. The Logic FS*S(Cont.) • Semantics: Let be an FS*S formula. • A model for is given by , • where is a tree structure. • assigns to each position variable a sequence of natural number • assigns to each -tree variable a -tree with tree structure .

  48. The Logic FS*S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • interprets every Position term into a sequence of natural numbers , as follows: • The constant symbol is interpreted as the empty sequence. • For position variable , . • A -term is interpreted into a -letter, as follows: • The constant symbol is interpreted ad the -letter . • If , and then

  49. The Logic FS*S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • Formulas are interpreted into values as follows: • For propostion terms and , • evaluates to 1 if • evaluates to 1 if is prefix of • evaluates to 1 if is smaller then in lexicographic order. • For -term and , evaluates to 1 if equals • , ,,,where and are formulas, are interpreted in the standard way, after the formulas and are interpreted.

  50. The Logic FS*S(Cont.) • Given a model , we inductively define the interpretation induced by as follows: • Formulas are interpreted into values as follows: • is true if there exists a model , such that and ’ differ at most in the interpretation of the position variable , and such that . • is true if there exists a model , such that and ’ differ at most in the interpretation of the array variable , and such that .