1 / 70

Presented by Maya Arbel , May 2012

Symbolic model checking with rich assertional languages Y. Kesten , O. Maler , M. Marcus, A. Pnueli , E. Shahar. Presented by Maya Arbel , May 2012. Parameterized Systems. In the previous lecture we saw the problem of verification of parameterized systems.

kaori
Télécharger la présentation

Presented by Maya Arbel , May 2012

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. 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 .

More Related