5.1 Modular Verification of Synchronous Programs
5.1.1 Partially Determined Outputs
In the following section we introduce the notion of closed and open systems including their differences, and a running example for the whole chapter.
Closed System
As explained, synchronous programs lend themselves well for formal verification, since one can easily translate synchronous programs to state transition systems so that all formal methods for transition systems can be applied. Section 2.3.6 shows how symbolic representations of the transition systems can be directly obtained via a compilation to synchronous guarded actions, so that formal verification methods can be directly applied. Following these steps the complete environment is fixed for these programs to get a specific behavior. In the following those systems are called closed systems, meaning that the context/environment is completely known. However, due to the state explosion problem, we have to deal with the enormous complexity of the obtained verification problems, and therefore we are interested in a modular verification. Modules obtained by modular compilation are called open systems. The environment of these systems is not known (completely) and one has to assume the most general behavior for them.
The difference of these systems is represented in a different handling of the default reaction. Since output variables of a called module are replaced in the module call by local or output variables of the called module, it is possible that the calling module may also write to the output variables of the called module. Therefore, if the called module (the regarded open system) does not assign a value to one of its output variables at a certain point of time, we cannot apply the default action as it is done in a closed system. Instead, we have to omit the default action for outputs in open systems that have to be considered for modular verification. Note, however, that the default actions have to be added for local variables of the called modules since these are not visible in the calling module.
Example
For example, consider the following Quartz program that we will use as a running example throughout the chapter:
module rfEdgeDet (event bool ?i ,!u){
event bool p; loop { next(p) = i; if(i∧¬p) u=true; if(¬i∧p) u=false; w: pause; } }
The guarded actions that are obtained for this program are the following ones: • true ⇒ next(init) = false
94 5 Modular Verification by Decomposition of Synchronous Programs
• (init ∨ w) ⇒ next(w) = true • (init ∨ w) ⇒ next(p) = i • (init ∨ w) ∧ i ∧ ¬p ⇒ u = true • (init ∨ w) ∧ p ∧ ¬i ⇒ u = false
In addition to these explicit actions, there are also default actions that determine the values when no guard action for a variable determines its value. Note that(init ∨ w) is invariantly true, since init is true at the initial point of time, andw holds always after the initial point of time. Hence, after the initial point of time,p always holds the previous value of i, and thereforeu is made true if there is a rising edge on i, and it is made false if there is a falling edge on i. If neither is the case, the default action takes place which resets u to falsesinceu is an event variable.
Reconsidering the generation of a transition system introduced in Section 2.3.6 for the example modulerfEdgeDet to generate the closed system, the following formulas are obtained where the formulas are split into the computed guarded actions and the default actions.
Icl:=
((init ∨w) ∧ i ∧ ¬p → u)∧ ((init ∨w) ∧ p ∧ ¬i → ¬u)
∧ (true → ¬p)∧ (true → ¬w)∧ (true → init) ∧ ((¬init ∧ ¬w) ∨ (i ↔ p) → ¬u) Rcl:= ((init ∨w) ∧ i ∧ ¬p → u)∧ ((init ∨w) ∧ p ∧ ¬i → ¬u)∧ (init ∨w → next(p) = i)∧ (init ∨w → next(w))∧ (true → next(init) = false)
∧ (¬(init ∨w) → ¬next(p))∧ (¬(init ∨w) → ¬next(w))∧ (next((¬init ∧ ¬w) ∨ (i ↔ p)) → ¬next(u))
Figure 5.1 shows the state transition diagram of the encoded transition system for the closed system, where the reader may ignore the dashed transitions and states (they are added for the open system later). States drawn with double lines are initial states (where init holds), and the label of the state denotes its variable assignment. Reachable states without outgoing transitions are omitted for reasons of clarity and comprehensibility. Hence, there are two initial states and six reachable states.
Open System
Having explained the construction of symbolic transition relations for closed systems, it is almost obvious how to obtain a symbolic transition relations for open systems: All to do is to leave out the parts that model the default action for the output variables. However, the default action for local variables must be retained (likep and w in our running example). Definition 31 (Symbolic Representation of Open Systems). For a synchronous pro- gram with input variables Vi, label and local variables Vl and output variables Vo, we define
5.1 Modular Verification of Synchronous Programs 95
w wiu
iu wp wip
wu u
wipu
Fig. 5.1: Explicit State Transition Diagram of SystemrfEdgeDet
the initial state condition Iop and the state transition relation Rop of the corresponding open
system as follows: Iop:≡ V x∈Vl∪Vo ImmActs(x) ∧ V x∈Vl InitDefActs(x) Rop:≡ V x∈Vl∪Vo ImmActs(x) ∧ V x∈Vl∪Vo DelActs(x) ∧ V x∈Vl NextDefActs(x)
Note that the only change is that the default actions are restricted to the local variables Vl,
while in a closed system, these actions are also performed on the output variables. This is necessary, since the calling module may add further assignments to output variables which would then contradict to the default actions1. Therefore, output variables are not completely determined in the open system in these cases.
Hence, the open system’s transition system for therfEdgeDet example is given by the formulas in Figure 5.2.
The resulting transition system is shown in Figure 5.1 where this time the dashed states and transitions are added due to the deletion of the default actions.
It is clear that in general the removal of the default actions yields a transition system with more states and more transitions. Hence, we consider the following first result: Lemma 6. Let the two transition systems T1= (S1, I1, R1, L1) and T2= (S2, I2, R2, L2) be
given where S1⊆ S2, I1⊆ I2, R1⊆ R2, and L1(ϑ) = L2(ϑ) holds for any state ϑ ∈ S1. Then,
there exists a simulation relation between T1 and T2.
Proof. Simply define the simulation relation as follows: ϑ1 ϑ2:⇔ ϑ1= ϑ2, i.e. is the
identity relation. It is then clear that the properties of a simulation relation are fulfilled, i.e., we have
96 5 Modular Verification by Decomposition of Synchronous Programs
Iop:=
((init ∨w) ∧ i ∧ ¬p → u)∧ ((init ∨w) ∧ p ∧ ¬i → ¬u)
∧ (true → ¬p)∧ (true → ¬w)∧ (true → init) Rop:= ((init ∨w) ∧ i ∧ ¬p → u)∧ ((init ∨w) ∧ p ∧ ¬i → ¬u)∧ (init ∨w → next(p) = i)∧ (init ∨w → next(w))∧ (true → ¬next(init)) ∧ (¬(init ∨w) → ¬next(p))∧ (¬(init ∨w) → ¬next(w))
Fig. 5.2: Transition SystemrfEdgeDet for the open system
• ϑ1 ϑ2 implies that for every variable x ∈ V, we have x ∈ ϑ1 iff x ∈ ϑ2
• for all ϑ1, ϑ01∈ S1 and every ϑ2∈ S2 with ϑ1 ϑ2 and (ϑ1, ϑ01) ∈ R1, there is a state
ϑ02∈ S2 with ϑ01 ϑ02 and (ϑ2, ϑ02) ∈ R2. By definition of , it is clear that we choose
ϑ02:= ϑ01 to see this.
• for every initial state ϑ1∈ I1, there is an initial state ϑ2∈ I2 with ϑ1 ϑ2: clearly, we
choose ϑ2:= ϑ1 to prove this.
By construction of Icl, Rcl, Iop and Rop, it is clear that we have Icl⊆ Iop and Rcl⊆ Rop, so
that we can apply the above lemma. Hence, the open system simulates the closed system, and therefore, we have the following theorem (see [GrLo91] for a definition of ACTL∗): Theorem 2. Let Top and Tcl be the open and the closed transition system obtained for a
synchronous program P. For every universal temporal logic formula ϕ ∈ ACTL∗ with Top|= ϕ,
we then also have Tcl|= ϕ, i.e., we have the following proof rules (where ϑ is any state in Scl): Top|= ϕ Tcl|= ϕ Top, ϑ |= ϕ Tcl, ϑ |= ϕ Illustrating Example
Considering the running examplerfEdgeDet and its corresponding closed system Tcl and
open system Topto illustrate the use of the above proof rules. It is not difficult to verify that
the open system Top satisfies the following specifications:
• Φ0 := A G (¬i ∧ X (i → u))
• Φ1 := A G (i ∧ X (¬i → ¬u))
Φ0 states that u must be true whenever there is a rising edge on i, and Φ1 states thatu
must be false whenever there is a falling edge oni. In this case, the specifications are very close to the implementation, which is in general, of course, not necessary. By Theorem 2, we know that these specifications are also valid for each system obtained from Top by adding
5.1 Modular Verification of Synchronous Programs 97
The reverse implication is in general not true: There are temporal logic formulas that hold in Tcl, but not in Top. Since the closed system sets u whenever a rising edge on i is
detected, and to false either by the default action or by the assignment triggered when a falling edge oni is detected, and the fact that in between two rising edges, a falling edge must occur, it is possible to verify that the following specifications hold for Tcl:
• Φ2 := A G [¬u U ( ¬i ∧ X i)]
• Φ3 := A G (u → X [¬u U (i ∧ X¬i)])
Φ2 states thatu is false until there is a rising edge on i, and Φ3 states that wheneveru
holds, it will remain false until there is a falling edge oni. Note that this holds in the closed system due to the default action onu that takes place whenever there is neither a rising nor a falling edge oni. The default action is however not present in the open system Top, and
therefore arbitrary values are allowed there foru in these cases. Hence, neither Φ2 nor Φ3
holds for the open system Top.
This can be seen in the transition system given in Figure 5.1: a counterexample for Φ2 is
the path π := {init,u},{w,u}ω, where sω expresses the infinite repetition of s to obtain an infinite path. Using {init}, {w,u}ω, we are also able to find a counterexample starting in an initial state of the closed system (but we need to use at least one transition of Top, since Φ2
does hold in Tcl). The path π is also a counterexample for the specification Φ3.