Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.

Similar presentations


Presentation on theme: "1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for."— Presentation transcript:

1 1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for proctype, with one exception. Every statement in a temporal (never) claim must model a proposition and must be side-effect free. A never claim expresses behaviour that is claimed to be impossible. There can be only one never claim per model. E.g. #define p = (x>=4) never { T0: if :: (true) -> goto T0 :: (p) -> goto T1 T1: skip }

2 2 Matching Claims The temporal claim and the model (under examination) are executed in lock-step. The temporal claim cannot alter the model behaviour. The first statement (ie proposition) of the temporal claim labels the first reachable state of the combined model (after the init process has been executed). Thereafter, for every reachable system state, the executability of the corresponding proposition of the temporal claim must be evaluated. Each such proposition (statement) can be executable or not- executable. if it is executable then the proposition is true and the temporal claim is moved on to its next statement, if it is not executable then the proposition is false. This means that the behaviour described by the current execution path cannot be matched by the claim. The search will continue along other paths.

3 3 Matching Claims A temporal claim is matched when: it reaches its normal end-state, i.e. }. This is the case for finite executions. In this case all the propositions held in each step of a computation path. A correctness violation has occurred. (A so-called never behaviour actually occurred.) an acceptance cycle is detected. This is the case for infinite executions. If a cycle is found, then a correctness violation has occurred. never { T0: if :: (true) -> goto T0 :: (q) -> goto accept fi; accept: if :: (true) -> goto T0 fi }

4 4 Translation of LTL formulae LTL formula Buchi automata Promela []<>p : always guaranteed that eventually p will become true at least once more. Written in Promela as: never { T0: if :: (true) -> goto T0 :: (p) -> goto accept fi; accept: if :: (true) -> goto T0 fi } 1 accepting state, 1 non-accepting state. The conditions are on the transitions of the automata, not on the states. true p

5 5 Translation of LTL formulae [](p U q) : always guaranteed that p remains true at least until q becomes true. Written in Promela as: never { T0: if :: (p) -> goto T0 :: (q) -> goto accept fi; accept: if :: (p || q) -> goto T0 fi } 1 accepting state, 1 non-accepting state. The conditions are on the transitions of the automata, not on the states. q p V q p

6 6 Translation of LTL formulae There is a translation algorithm (ltl manager). The translation first converts the formula to normal form, the translation recursively compiles the set of subformulae that must hold for each (reachable) state, and of its successor states. SPIN will convert LTL formulae into never claims automatically.

7 7 Satisfaction of LTL formulae LTL formula Buchi automata E.g. []<>p [](p U q) A B.a. accepts a word iff it forces execution through one or more accepting states infinitely often (acceptance cycle). LTL formula Buchi automata x global system f automata Sxf B. automata If language accepted by Sxf is empty, L(Sxf) = {}, then f is not satisfied. If there are no acceptance cycles in Sxf, then f is not satisfied. true p q p V q p

8 8 Satisfaction of LTL formulae Reasoning about product automata Formula []<>p system I product lang. includes system lang. f is true. an abstraction system II product lang. is empty. f is false. an abstraction ~p p true p

9 9 Satisfaction of LTL formulae Reasoning about product automata It is much easier to prove that the product language is empty, than it includes the system language. i.e. it is easier to prove that a formula does not hold. Therefore, we try to prove the negation of the formula of interest. This is the never claim. So: no execution sequence matches the never claim no acceptance cycles in product of system and never claim the formula holds If there is an acceptance cycle (the negated formula holds, the formula does not) there is a counter-example. Best-case: compute empty product, 0 states. If there is no acceptance cycle (the negated formula does not hold, the formula does hold) there is no counter-example. Worst-case: compute entire product, all states.

10 10 Satisfaction of LTL formulae Additional meta level operation In the LTL property manager, you can select all executions quantify over all paths. no executions quantify over no paths. Default is all executions.

11 11 Satisfaction of LTL formulae never claim a process expressing undesirable behaviour “matched” if it has an acceptance cycle, or negate LTL formula f never claim Buchi automata So we prove f with a never claim: formula []p []p <>p <>p quantifier all exec no exec all exec no exec matched <>~p []p []~p <>p some some some some branch branch branch branch not []p <>~p <>p []~p matched all all all all branches branches branches branches Summary

12 12 Behind the scenes checking is carried out on the fly - generate the graph as it is being searched must store states on a stack as they are visited how to cope with enormous state spaces? (e.g. >>10 8 ) memory M reachable states N state size S S <= M/N exhaustive search possible S > M/N ?? In general, we can remove states (safe) compress states (safe and unsafe)

13 13 Behind the scenes Partial Order Reduction Remove spurious interleavings of process behaviour static reduction method remove “extra” acceptance cycles exploit asynchronous communication overhead of time

14 14 Behind the scenes Storing visited states collision hash stack of hash table indices hash table of states “ordinary” hashing hash compact always hash to k bits (64) collapse reduce spurious “process” states every state: hash global variables processes channels

15 15 Behind the scenes Bistate Hashing (Supertrace) S is state size. M is memory size. N is no. of reachable states. What do you do when S> M/N and we don’t know N! There will be collisions, so let’s minimise them. The key is to choose m, the number of bits to represent a state. So we have: state hash value bitstate vector S bits m bits 2 m bits P = probability of collision N<M P <= 2 N-m-1 (n-m-1 should be small) N>=M P>= 1-2 m-n (so try to make n>>m) H f = M/N’ where N’= (1-P) * N H f >100 ==> 2 m is a good approximation of N

16 16 Behind the scenes S is state size. M=2 m is memory size (bits). N= 2 n is no. of reachable states. m is no. of hash bits. What is the probability of a collision? P = probability of collision N<M P <= 2 n-m-1 no states < memory N-M-1 is negative. P is small. N>=M P>= 1-2 m-n want |m-m| to be large. so make n >> m. Can we define a reliable indication of the coverage that has been achieved. (A true measure would involve exhaustive search!) Define: H f = M/N’ where N’= (1-P) * N Then, when H f >100 ==> 2 m is a good approximation of N.


Download ppt "1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for."

Similar presentations


Ads by Google