OPEN SYSTEM SPECIFICATIONS
SM 1 SM 2 prove
9.4 Forming open from closed systems
9.4.1 Trapped between over and under specification .1 Overspecification
Consider the specification
variables a, b the component controlsb
A =∆ ∧a = 1
∧2(a ∈1. .2)
∧23(a = 2) B =∆ ∧2(b ∈ 1. .2)
∧2[b′ =a]⟨a,b⟩
13 The module TemporalLogic contains a proof of this tautology, and of the theorem WhilePlusSafetyLivenessDecomp.
14 As proved in the moduleWhilePlusHalfTheorems).
∧23(b = 2)
A first inspection suggests that the assumption A should suffice to ensure realizability of the guarantee B.15 To put it differently, we want an operator that forms a realizable open-system from the pair A,B. The resulting open- system should mean what we expect. What do we expect?
Conjoining the open-system with the intended environment should imply the guarantee.16
(OpenSystem∧Env)⇒B
LetEnv ≜A. The above implication is valid with the definitionOpenSystem ≜ A−+▷B because17(A∧(A−+▷B))⇒B so the implication (OpenSystem∧A)⇒ B is valid.
Is the propertyOpenSystem realizable?18 No, due to a counter-example where an arbitrary value of a′ blocks the component from satisfying Cl(B) in the safety partCl(A)−+▷Cl(B) ofOpenSystem [66, Prop. 7].
Briefly, A−+▷B is unrealizable because the finite behavior
⟨
a 7→1 b 7→2
...
| {z }
s1
a 7→20 b 7→ ∗
...
| {z }
s2
⟩
satisfies A up to s1, so in any implementation the variable b should take a values2.b such that⟨s1,s2⟩be extendable to a behavior that satisfiesB. This extension is impossible.19
theorem NotExtensible =∆ assume
∃tau : ∧IsABehavior(tau)
∧tau |=B
∧tau[0].a = 1
∧tau[1].a = 20
∧tau[0].b = 2
15 With realizability defined so that the component pick the initial value of variableb.
16 This is a reasonable sanity check for any operator for defining open-systems.
17 By the propositionStepwiseAntecedent in the moduleTemporalLogic.
18 In the context of a reasonable definition of realizability.
19 A proof of the theoremNotExtensible is in the moduleUnzipTheorems.
prove false
Unrealizability above arises due to a′ taking an arbitrary value that blocks the component, despite A prohibiting that value.20 Unless the value a′ is constrained withinRealization, unrealizability is remains for the propertyA−+▷ B. Incorporating such an assumption withinRealization splits the assumption into two parts (the operator A and a subformula within Realization). Using the operator WhilePlusHalf instead of−+▷can avoid this situation.
What we observed above is an instance of overspecification. We overspecified the component by constraining inB the next environment state (a′), which is unconstrained by A−+▷B, regardless of what the assumption A is. Removing the constraint on a′ from B avoids this situation, but raises another issue as discussed below.
9.4.1.2 Underspecification
Suppose that we modify the guarantee to Bnew =∆ ∧b = 1
∧2(b ∈ 1. .2)
∧2[(a ∈ 1. .2)⇒(b′ =a)]⟨a,b⟩
∧23(b = 2)
That a part of the assumption now occurs within the guarantee indicates that separation into an assumption and guarantee passes through reasoning about the assembled system. In Section 9.4.2 we show how to specify the assembled system (closed) and transform that into an open-system specification.
Reconsidering the behavior that we discussed above, which starts with (was b = 2 at the initial state, but that difference is irrelevant)
[ a 7→1 b 7→1
] [
a 7→20 b 7→ ∗
]
we can now extend it to satisfy Bnew, as follows τ =∆
[a 7→1 b 7→1
] [a 7→20 b 7→1
] [a 7→1 b 7→2 ]
· · ·stuttering tail
20The same problem with −+▷ is present in typed formalisms too; our observation is not an artifact of untypeness.
So the propertyA−+▷Bnew is realizable, in constrast toA−+▷B. The modified propertyBnew has some unexpected properties. For instance, another witness behavior is
tau =∆ [
a 7→1 b 7→1
] [
a 7→20 b 7→1
] [
a 7→ {1,3} b 7→2
] [
a 7→Nat b 7→2
] [
a 7→√ 2 b 7→2
]
· · ·
| {z }
arbitrary values ofa
The suffix ofτ can assign arbitrary values to variablea, even ifa satisfiesAup to the second state, i.e.,PrefixSat(sigma,2,A). A behavior that demonstrates this is the following
tau =∆
[a 7→1 b 7→1
] [a 7→1 b 7→1
] [a 7→ {1,3} b 7→1
] [a 7→Nat b 7→2
] [
a 7→√ 2Nat b 7→2
]
· · · (Variable b cannot take arbitrary values, because the definition of Bnew in- cludes the conjunct 2(b ∈ 1..2)).
This behavior is a witness even for B, given this particular (2-state) prefix that satisfies the assumption. The arbitrariness of values assigned to variable a would better be avoided, as discussed below.
9.4.1.3 Practical considerations
One can argue that, in general, we can formulate a specification so as to allow arbitrariness of values within the suffix of the witness behavior, without compromises to what we can specify.
However, there are other factors to consider too. In order to mechanize the computation of a closure, we have to eliminate a temporal existential quantifier (∃∃∃∃∃∃). This elimination typically involves some reachability analysis (unless we are given a safety property, or a property as the conjunction of a machine- closed pair of a safety and a liveness property). Computing the closure is necessary for mechanized reasoning about the operator −+▷, whenever any of its first two arguments is given as a conjunction of two properties that do not form a machine-closed pair (Section 9.1).
Semantic methods (BDDs, enumeration, etc.) are more automated than syn- tactic methods (theorem proving) so we assume that a semantic method is used to compute the closure of G when given as a machine-unclosed pair of formulas. In order to compute the closure Cl(G), a semantic method needs
∧EnvNext
behavior x′ ̸=x
∃∃∃∃∃∃u,v
∧¬EnvNext
∧SysNext ∧SysNext
∧EnvNext
∧SysNext y′ =y
enabled SysNext enabled SysNext
¬enabled SysNext
Figure 9.5: How 2[SysNext]y within −+▷ allows the component to restore enabledness within the tail of the behavior that witnesses temporal quantifi- cation∃∃∃∃∃∃, even after environment glitches, but at the cost of underspecification.
(For example, by allowing arbitrary environment glitches to occur in the tail of the witness behavior. The component can exploit this to exhibit undesired behavior in the unhidden part of the witness behavior.)
to interpret all the variables that occur in G (with the exception of G written in suitable syntactic form [7], and using a syntactic method). So G should be a bounded formula (∆0 [100]), i.e., a closed-system (with respect to rele- vant variables). Thus, a property G that leaves the environment variable a unconstrained is inconvenient for computing the closure mechanically.
One way to relax a property of the formA−+▷G in order to make it realizable is to by allowing the component to stuttery
G =∆ Init ∧2[N]y ∧L
This stuttering subscript allows A-steps, with A = (x∆ ′ ̸=x)∧(y′ =y),
from states where¬enabled N back to states whereenabled N. This speci- fication style alows the component to restore the environment to a helpful state after glitches, as shown in Fig. 9.5. However, it also allows “wild” behavior of x within ∃∃∃∃∃∃. The possibility of wild behavior is relevant because the sys- tem could exploit it to prevent the environment from satisfying its liveness specification, or its safety specification.