Model Checking Large Software Specifications

1. Model Checking Large Software Specifications William Chan, Richard J. Anderson, Paul Beame, Steve Burns, Francesmary Modugno, David Notkin Jon D.Reese Manuscript received 14 Aug. 1997; revised 20 Feb. 1998

2. Major work • In order to investigate model checking can be applied in large software specifications, authors translated a portion of the state-based system requirements specification of Traffic Alert and Collision Avoidance System II (TCAS II) into input to a symbolic model checker (SMV). • A number of properties of the system are successfully analyzed by symbolic model checkers. • They report their experiences, describing their approach to translating the specification to the SMV language. • Based on their experience, they discuss the possibility of using model checking to aid specification development by iteratively applying the technique early in the development cycle.

3. Model Check Problem Definition • Model checking is a formal verification technique based on state exploration. Given a state transition system and a property, model checking algorithms exhaustively explore the state space to determine whether the system satisfies the property.

4. Model of Computation

5. Computation Tree Logic • Temporal logics may differ according to how they handle branching in the underlying computation tree. • In a linear temporal logic, operators are provided for describing events along a single computation path. • In a branching-time logic the temporal operators quantify over the paths that are possible from a given state. • The computation tree logic CTL* combines both branching-time • and linear-time operators. • In this logic a path quantifier can prefix an assertion composed of • arbitrary combinations of the usual linear-time operators. • Path quantifier • A—“for every path” • E—“there exists a path” • Linear-time operators • Xp—p holds next time. • Fp—p holds sometime in the future • Gp—p holds globally in the future • pUq—p holds until q holds

6. Computation Tree Logic (cont) • CTL is a restricted subset of CTL* that permits only branching-time operators—each of the linear-time operators G,F, X, and U must be immediately preceded by a path quantifier. • For example, AG(EF p) • LTL consists of formulas that have the form Af where f is a path formula in which the only state subformulas permitted are atomic propositions. • For example, A(FG p) • Eight basic CTL operators: • AX and EX, • AG and EG, • AF and EF, • AU and EU

7. Computation Tree Logic (cont) • Typical CTL Formulas • AG safe: All reachable states are safe. • AG AF stable: The system is stable infinitely often. • AG (request -> AF response): A request is always followed by a response sometime in the future. • AG EF restart: It is possible to restart the system in any reachable state.

8. Symbolic Model Checking • Ordered Binary Decision Tree for the two-bit comparator, given by the formula

9. Symbolic Model Checking (cont) • Variable Ordering Really can Affect BDD Size • a1 <b1 < a2 < b2 and a1 < a2 < b1 < b2

10. Symbolic Model Checking (cont) • Symbolic Model Checking Algorithm • How to represent state-transition graphs with Ordered Binary Decision Diagrams: • Assume that system behavior is determined by n boolean state variables v1, v2, …. vn. • The Transition relation T will be given as a boolean formula in terms of the state variables: • where v1, v2, …. vn represents the current state and others represents the next state.

11. SMV • The full name of SMV is symbolic model verifier. • SMV is a CTL symbolic model checker using BDDs to represent state sets and transition relations. • SMV Example • a simple pumping control system that transfers water from a source tank A into another sink tank B using a pump P. • Initially, both tanks are empty. • The pump is to be switched on as soon as the water level in tank A reaches ok (from empty), provided that tank B is not full. • The pump remains on as long as tank A is not empty and as long as tank B is not full. • The pump is to be switched off as soon as either tank A becomes empty or tank B becomes full.

12. SMV (cont) • MODULE main • VAR • level_a : {empty, ok, full}; -- lower tank • level_b : {empty, ok, full}; -- upper tank • pump : {on, off}; • ASSIGN • next(level_a) := case • level_a = empty : {empty, ok}; • level_a = ok & pump = off : {ok, full}; • level_a = ok & pump = on : {ok, empty, full}; • level_a = full & pump = off : full; • level_a = full & pump = on : {ok, full}; • 1 : {ok, empty, full}; • esac; • next(level_b) := case • level_b = empty & pump = off : empty; • level_b = empty & pump = on : {empty, ok}; • level_b = ok & pump = off : {ok, empty}; • level_b = ok & pump = on : {ok, empty, full}; • level_b = full & pump = off : {ok, full}; • level_b = full & pump = on : {ok, full}; • 1 : {ok, empty, full}; • esac; • next(pump) := case • pump = off & (level_a = ok | level_a = full) & • (level_b = empty | level_b = ok) : on; • pump = on & (level_a = empty | level_b = full) : off; • 1 : pump; -- keep pump status as it is • esac; • INIT • (pump = off) • SPEC • -- pump if always off if ground tank is empty or up tank is full • AG AF (pump = off -> (level_a = empty | level_b = full)) • -- it is always possible to reach a state when the up tank is ok or full • AG (EF (level_b = ok | level_b = full))

13. RSML • RSML stands for: Requirements State Machine Language • RSML is a state-machine language based on statecharts, extending conventional state diagrams with state hierarchies and broadcast communications. • RSML Semantics • State Hierarchy • And/Or state : Each state S may contain substates, whose superstate is S. The state S is either an and-state or an or-state. Intuitively, the machine is in S if and only if: 1) it is an and-state and the machine is in all of its substates or 2) it is an or-state and the machine is in exactly one of its substates. • Inputs and Events • Transitions

14. RSML (cont)

15. RSML Encoding • To explain the translation from RSML to SMV program generally and precisely, a RSML machine should be encoded into a state transition system. • We define an RSML machine as a state transition system <Q, R, I>. To distinguish between an RSML state and an element in Q, we call the latter a global state and call R the global transition relation. • RSML states • JUST intuitive RSML states, reference RSML sample • A configuration is a maximal set of states that the machine can be in simultaneously (formal definition is in comment) • Global states • Let Config included in (States) be the set of all configurations, Events be the finite set of events, and Inputs be the set of all possible assignments to the input variables. The set Q of global states is defined to be Config * (Events) * Inputs. • RSML transitions • Intuitive, five attribute : src(tr), dest(tr), trig(tr), cond(tr), action event atcs • Global states transitions (Macrostep)

16. RSML Encoding (cont)

17. RSML Translation • Translate Global States • Note that this leader-followers relationship is identical to the parent-child relationship, when there are no nested or-states and nested and-states, and every atomic state has an or-state as parent. • the followers of Composite-RA are No-RA, Climb, Descend, and Negative, while those of Climb-VSL are its children.

18. RSML Translation (cont) • Global States Translation Rule

19. RSML Translation (cont) • Translate Deterministic Transitions

20. RSML Translation (cont) • Translate Non-deterministic Transitions

21. RSML Translation (cont) • Translate Timing Constraints • Translate Prev (y) for Some Input y (will not change during transition – synchrony hypothesis )

22. Optimizing Symbolic Model Checking for State charts William Chan, Richard J. Anderson, Paul Beame, David H. Jones, David Notkin, Jon D.Reese, William E. Warner Manuscript received 15 Nov. 1999; revised 8 Apr. 2000; accepted 1 May 2000

23. Major Work • Present various optimizations for improving the time and space efficiency of symbolic model checking for systems specified by statecharts, inclduing: • Managing forward and backward traversals to reduce the size of the BDD generated at each search iteration. • Semantics-preserving tranformation of the model to again reduce the size of BDDs generated. • More sophisticated conjunctive partitioning of the transition relation and applying disjunctive partitioning in an unusual way to reduce the size of the intermediate BDDs at each iteration. • These techniques are applied in TCAS (Traffic Collision Avoidance System ) an EPD (Electrical Power Distribution), a few flaws not found by simulation are closed.

24. Transition System Encoding • To analyze statecharts using state-exploration techniques, we view the statecharts as a transition system <Q; R; I.> where Q is a finite set of (global) states, R included by Q * Q, a total transition relation, and I Q a set of initial (global) states. A state in Q is a tuple of the current local state of each state machine, the set of events occurring, and the values of the environmental inputs. If .q; q0. is in R, then q is a predecessor of q0, and q0 is a successor of q. A path is an infinite sequence of states in which each consecutive pair of states belongs in R and a trace is a path that starts with some initial state in I. A state is reachable if it appears on some trace.

25. Transition System Encoding

26. Symbolic Model Checking • Fix-point Algorithm • The truth value a CTL formula can be found by searching the state space. We define Pre: 2^Q -> 2^Q to be the set of predecessors of any set S of states under the transition relation R: • Consider the CTL formula AG !error, backward search algorithm is like : • Iteratively calculate Yi+1 = Pre (Yi) Union Yi, if Fix-point and Init state intersection is not null, then formula is true

27. Pruning Backward Traversals • A disadvantage of backward traversals is that they are likely to visit many unreachable and, thus, irrelevant, states. • Notice that any invariant over the state variables describes a condition satisfied by every reachable state and, thus, corresponds to such a bound. • Sometimes we can greatly simplify the search by observing that the events (x0, x1, and x2 in our example) are mutually exclusive. This invariant can be incorporated into the traversals by simply conjoining it with the transition relation R. That is, if sigma is the set of mutually exclusive events, we can compute the conjunction of R and use the result as the transition relation in the traversals.

28. Pruning Backward Traversals (con) • Hot to find mutually exclusive events? • Intuitively, i is in … σ(e) if e can occur just before the ith microstep of some macrostep. • Experimental Result

29. Oblivious vs. Nonoblivious Synchronization

30. Oblivious vs. Nonoblivious Synchronization (cont) • The main difference between the two systems is that, in left figure, event x1 always occurs after x0, while, in right figure, event x1 is not generated if there is no state change in machine A1. In other words, in right figure, an event signals the completion of a state machine's execution and the sequence of events generated is independent of what happens locally in the state machines; we say that such systems have oblivious synchronization. In left figure, an event signals a state change and the sequence of events generated depends on which local transition is taken; we call such systems nonoblivious.

31. Oblivious vs. Nonoblivious Synchronization (cont) • We define a partial order on events: • We have e1 < e2, or e1 precedes e2, if there exists a transition labeled with e1[c]/e2 • ⊥ stands for stable state. We have e < ⊥if there exists a global state q in which e occurs and q has a stable successor state. • Using this partial order we get this event sequence diagram.

32. Oblivious vs. Nonoblivious Synchronization (cont) • Difference in Backward Analysis

33. Mircrostep Counter • Motivation • Decouple the synchronization from the local control while preserving the semantics of the model. • Construction of the Microstep Counter

34. Mircrostep Counter (cont)

35. Mircrostep Counter (cont) • To see that the modifications help prune unreachable simultaneous transitions in backward searches, observe that the microstep counter in Fig. 12 makes it explicit that the transitions in machines A1 and A2 are mutually exclusive. • For example, if in some system we have σ (e1)={1 ,2} and σ(e2) = {2}, then the microstep counter makes it clear that transitions triggered by e1 and e2 cannot be enabled simultaneously when mc = 1, even though e1 and e2 may not always be mutually exclusive (i.e., when mc . 2).

36. Partitioning Transition Relations • A common bottleneck of model checking is the BDD size for the transition relation, which can be reduced by conjunctive or disjunctive partitioning. • The transition relation R is sometimes given as a disjunction D1 V D2 V D3 … V Dj and the BDD for R can be huge even though each disjunct has a small BDD. • We can partition R as: • So, we can compute the predecessors without ever building the BDD for R. Successor computation is symmetric.

37. Partition Transition Relations (cont) • If R is given as a conjunction C1 ^ C2 ^ … Ck, we can still keep the conjuncts separate as above, but predecessor computations become more complicated. • The problem is that existential quantification does not distribute over conjunctions, so it appears that we have to compute the BDD for R any way before we can quantify out the variables. • A trick called “early quantification” is like this: • Define X1’, X2’,… Xk’ to be disjoint subsets of X’, such that their union is X’ • The intuition is to quantify out variables as early as possible and hope that each intermediate ci for 1 < i < k remains small. The effectiveness of the procedure depends critically on the choice and ordering of the conjuncts C1, C2,... Ck.

38. A Framework for Model-Based Design of Agent-Oriented Software Haiping Xu, Sol M. Shatz Manuscript received 4 June 2001; accepted 9 Sept. 2002

39. Major Work • Introduced a agent-oriented model (agent-oriented G-Net) rooted in the Petri net formalism, which provides a foundation that is mature in terms of both theory and tool support. • An example of an agent family in electronic commerce is provided to illustrate the formal model techniques for multiagent systems. • Using INA (Integrated Net Analyzer) to analyze and verify agent-oriented G-Net (Dead lock detection and reachablity detection ) • Using INA model checking tool to verify concurrentcy, mutual exclusion, inheritance mechanism properties.

40. Tool Support for Verifying UML Activity Diagrams Rik Eshuis, Roel Wieringa Manuscript received 19 Mar. 2003; revised 20 Jan. 2004; accepted 8 Apr.2004

41. Major Work • Describe a tool that supports verification of workflow models specified in UML activity diagrams, support strong fairness constrains. • The tool translates an activity diagram into an input format for a model checker according to formal semantics.