Springer - Concurrency Theory Episode 10 pdf

350 12 Timelocks in Timed Automata ∀ d ∈ R +0 ,s+ d ∈ S ∧  a ∈ Act .s+ d a −→→ Time-actionlock. Time-actionlocks are states where neither action nor time transitions can be performed. For example, Figure 12.2(ii) shows a time- actionlock produced by a mismatched synchronisation between two automata. Transition a! in the upper automaton is urgent when v(x)=5,butitcannot synchronise with a? in the lower automaton, because this transition is not enabled at that time. Consequently, the system enters a time-actionlock state at v(x) = 5. Formally, s ∈ S is a time-actionlock if,  a ∈ Act ,d∈ R + .s a −→→∨s d −→→ Zeno-timelock. In such a state, systems can still perform transitions (which can be either action or time transitions), but time cannot pass beyond a certain point. This represents a situation where the system performs an infinite number of actions in a finite period of time. For example, any reachable state in the automaton shown in Figure 12.2(iii) is a zeno-timelock, because time can only pass up to 5 time units and transition a is always enabled. Hence, a becomes urgent at v(x) = 5 and will be performed infinitely often, without time-passing at all. Formally, s ∈ S is a zeno-timelock if there exists at least one infinite run starting from s, and all such runs are zeno; i.e. ∃ ρ(s) ∈ ZRuns(A) ∧∀ρ(s) ∈ Runs (A),ρ(s) ∈ ZRuns(A) a! x>5 a? x<=5 a a b c 1 2 1 2 3 4 1 x<=10 x<=5 (i) (ii) (iii) Fig. 12.2. (i) Pure-actionlock (ii) Time-actionlock (iii) Zeno-timelock 12.2.1 Discussion: Justifying the Classification of Deadlocks One reason for presenting this classification is that we believe that differ- ent types of deadlocks bring different types of problems and, hence, should be treated differently. Firstly, although pure actionlocks may be undesirable within the context of a particular specification, they are not of themselves 12.2 A Classification of Deadlocks in Timed Automata 351 counterintuitive situations. It is wholely reasonable that a component or a system might reach a state from which it cannot perform any actions, as long as such an actionlock does not stop time. Thus, although analytical tools that detect pure-actionlocks certainly have value, we do not believe there is any fundamental reason why actionlocks should be prevented (by construction) at the level of the specification notation. In contrast, we are strongly of the opinion that time-actionlocks are coun- terintuitive. In particular, and as previously discussed, a local “error” in one component has a global effect on the entire system, even if other components have no actions in common with the timelocked component. Because of these particularly counterintuitive aspects, we believe that time-actionlocks should be prevented by construction; i.e. the timed automata model should be rein- terpreted in such a way that time-actionlocks just cannot arise. Finally, to come to zeno-timelocks: our position here is that analytical methods should be provided to check on a specification-by-specification basis whether zeno-timelocks occur. Our reasons for advocating this approach are largely pragmatic, because it is not clear how the timed automata model could be changed in order to constructively prevent such situations. In particular, any mechanism that ensured at the level of the semantics that a minimum time (say ) was passed on every cycle, would impose rigid constraints on the specifier’s ability to describe systems abstractly. Sections 12.4.2 and 12.4.3 consider just such an analytical method for detecting zeno-timelocks. 12.2.2 Discussion: Timelocks in Process Calculi It is interesting to mention that in the early work on timed concurrency theory, which largely focused on timed process calculi (see Chapter 9), the problem of timelocks was noted and partially resolved. As a result most timed process calculi only allow urgency to be applied to internal actions, and so timelocks due to synchronisation mismatches cannot happen. Indeed, they often enforce the so-called as soon as possible (asap) principle [168] that we have mentioned in Section 9.2.2; in such an interpretation, internal actions are considered implicitly urgent and will be performed as soon as they are enabled. In timed process calculi with asap, a hiding operator can be used to make synchronisation urgent without causing a time-actionlock (see Sections 9.2.10 and 9.4). The hiding operator turns observable into internal actions, which are, as we just mentioned, urgent as soon as they are enabled. Because ob- servable actions correspond to successful synchronisation between half actions, synchronisation is only made urgent if it is possible. This rules out most time-actionlocks in timed process calculi with asap (as we have discussed in Section 9.4, unguarded recursion can though also generate time-actionlocks). Unlike timed process calculi, timed automata do not incorporate a hiding operator, and so it is not possible to selectively take an observable action that results from synchronising half actions and turn it into an (urgent) completed action. Instead, urgency can only be specified individually for half actions, 352 12 Timelocks in Timed Automata regardless of whether synchronisation is possible. 12.3 Time-actionlocks As previously discussed, perhaps the most counterintuitive aspect of the time- lock story is the manner in which timelocks can arise from mismatched syn- chronisations (e.g. Figure 12.2(ii)). If we consider how this problem arises, we can see that it is caused by the particular interpretation of urgent interaction employed in timed automata. It is undoubtedly true that facilities to express urgency are required; oth- erwise certain important forms of timing behaviour could not be expressed (e.g. timeouts; see Section 9.2.2). However, it is our perspective that although urgency is needed, currently it is given an excessively strong formulation. We illustrate this issue with a modified specification for the multimedia stream example. Consider the model shown in Figure 12.3, where now packets can be sent to the Sink by two different sources, Source1 and Source2. The behaviour of the new added Source2 is similar to that of Source1, although (a) it can send the first packet at any time (notice that there is no invariant attached to Source2.State0) and (b) following packets are sent faster than in Source1 (1 packet every 25 ms). This, however, will produce a time-actionlock in the network. Consider the following scenario. Source1 sends its first packet to Place1, at time t =0.Later,sayatt =10,Source2 sends its first packet to Place2.By the time that Source2 attempts to send the second packet (t = 35), neither Place1 nor Place2 can offer a matching sourceOut?, as the transmission of the previous packets is not yet finished (the transmission delay is at least 80 ms). At this point, a time-actionlock occurs: because sourceOut! in Source2 is urgent at t = 35, time is prevented from passing and no action is enabled. The time-actionlock occurs because Source2 makes the sourceOut! action urgent even when it is not enabled, as both Place1 and Place2 are currently transmitting packets and synchronisation cannot be achieved. Moreover, the time-actionlock propagates to all other components because time is prevented from passing. We would argue, then, that it should only be possible to make an action urgent if it is enabled, i.e. must requires may or, in other terms, you can only force what is pos- sible. Such an interpretation of urgency arises in TimedAutomatawithDeadlines (TADs) [29,30], which are discussed in the next section. In particular, certain time constraints (so-called deadlines) are attached to actions denoting those time intervals where the action is considered urgent. Because every deadline implies the act ion’s guard, only enabled actions can be urgently performed, 12.3 Time-actionlocks 353 State1 State2 t4<=90 State1 t1<=50 t1=50 sourceout ! t1:=0 State1 State2 t3<=90 State1 State2 t2<=5 play t2=5 Place1 Place2 Sink State0 State1 t5<=25 Source1 Source2 State0 t1=0 sourceOut ! sourceOut ! t5:=0 t5=25 sourceOut ! t5:=0 sourceOut ? t3:=0 sourceOut ? t4:=0 sinkIn ? t2:=0 sinkIn ! t4>=80 sinkIn ! t3>=80 Fig. 12.3. A Multimedia Stream with Two Sources and a Time-actionlock and therefore time-actionlocks are ruled out by construction (although zeno- timelocks, on the other hand, can still occur). Timed automata with deadlines, then, guarantee time reactiveness (i.e. the absence of time-actionlocks) by construction. 12.3.1 Timed Automata with Deadlines Informally speaking, timed automata with deadlines [29, 30, 34, 35] can be described as timed automata where the time progress condition is expressed by deadlines, instead of invariants. Importantly, TADs are time reactive; i.e. time-actionlocks cannot occur. Different variants of TADs have been proposed, which differ in the treatment of parallel composition (although all of them preserve time reactiveness), e.g. standard TADs, sparse TADs and TADs with minimal priority escape transitions [34]. Our presentation of TADs in this section follows the model of Sparse-TADs, developed by Bowman in [34,35]. Deadlines are clock constraints attached to transitions (in contrast with invariants, which are attached to locations), which determine when the transi- tion is considered urgent. However, in TADs, time cannot be prevented from passing by an “urgent” transition not being enabled. This is an important difference between invariants and deadlines: unlike in TAs, urgency in TADs does not cause time-actionlocks. Let us illustrate this issue with the following example. 354 12 Timelocks in Timed Automata Figure 12.4(i) shows a network of two TADs 4 , and the corresponding prod- uct automaton to the right. Assuming all clocks are initially set to zero, tran- sition b! is enabled in the time interval [1, ∞), and is urgent in [2, ∞): the deadline (x ≥ 2) expresses that, during [2, ∞), synchronisation must happen as soon as possible. In the second automaton, b? is enabled during [3, ∞), and is urgent in [4, ∞). But then, what happens when v(x)=v(y) = 2? Clearly, at this point in execution, transition b! is enabled and enters its urgency period, but b? is not yet enabled, and so synchronisation cannot occur! Deadlines on half actions enforce urgency only if synchronisation can be achieved. Equiva- lently, synchronisation is urgent as soon as: (a) one of the parties is urgent, and (b) both parties can synchronise (i.e. when both half actions are enabled). 5 As a result, b! “waits” for b? to become enabled, and so synchronisation is im- mediately performed when v(x)=v(y) = 3. It is important to note that time passes until synchronisation is possible, and so synchronisation mismatches cannot cause time-actionlocks. This behaviour is evident from the structure of the product automaton: the guard on b results from conjoining the compo- nent guards, and the deadline assigned to b is defined as the disjunction of the component deadlines, conjoined with the component guards. In this way, the deadline on b implies its guard. Furthermore, by construction, every deadline in a TAD specification implies the corresponding guard: this is true for half actions, completed actions in components and completed actions which re- sult from synchronisation. It is not difficult to see, then, that time-actionlocks cannot occur in TAD specifications. The TA specification in (ii), on the other hand, shows that invariants en- force a stronger form of urgency than deadlines. Notice that the network of TAs shown in (ii) “intends” to mimic the network of TADs in (i); for example, the invariant x ≤ 2 (in location 1), makes b! urgent at v(x)=v(y) = 2. How- ever, unlike the network of TADs, the network of TAs enters a time-actionlock at v(x)=v(y) = 2: synchronisation cannot yet occur, but the invariant in location 1, x ≤ 2, prevents time from passing any further. Even though, in this example, half actions are not urgent until they are enabled (e.g. b! becomes enabled at v(x) = 1, and is not urgent until v(x) = 2), invariants will enforce this “local” urgency regardless of whether synchronisation is possible. This can be seen in the product automaton: the invariant in 1, 3 prevents time from passing beyond v(x)=v(y) = 2, even though b is not yet enabled. 12.3.1.1 Formal Definitions: Timed Automata with Deadlines Here we just highlight the basic elements of the theory, and refer the reader to [29, 30, 34, 35] for a more comprehensive presentation. Unless stated oth- 4 In our TAD figures, deadlines are shown in brackets; “,” denotes conjunction; and “|” denotes disjunction. 5 Notice that tLOTOS adopts a similar approach: internal actions (in particular, those which result from synchronisation) are urgent on their upper bounds (Sec- tion 9.2.10). 12.3 Time-actionlocks 355 1 2 3 4 (TAD) || => <1,3> <2,4> 1 2 3 4 || => <1,3> <2,4> (i) (ii) (TA) x>=1 b! y<=4 x>=1 b! (x>=2) y>=3 b? (y>=4) x>=1, y>=3 b ((x>=2 | y>=4), x>=1,y>=3) x<=2 y>=3 b? x>=1, y>=3 b x<=2, y<=4 Fig. 12.4. Parallel Composition in TADs and TAs erwise, the notation used here respects the sets and conventions defined for timed automata in Section 11.2. Syntax. A timed automaton with deadlines (or simply, TAD) is a tuple of the form A =(L, TL,T,l 0 ,C), where L isafinitesetoflocations(l 0 ∈ L is the initial location); TL ∈ Act is a set of labels; T is a transition relation and C is a set of clocks. Transitions in T are denoted l a,g,d,r −−−−−→ l  ,wherel, l  ∈ L are automata locations; a ∈ TL is the action labelling the transition; g ∈ CC C is a guard; d ∈ CC C is a deadline; and r ∈P(C) is a reset set. In addition, deadlines and guards satisfy the following conditions. 1. Deadlines imply guards, (C1) l a,g,d,r −−−−−→ l  =⇒ (d ⇒ g) 2. If both a deadline and its corresponding guard denote the same solution set, then this set must denote a left-closed time interval, (C2) l a,g,d,r −−−−−→ l  =⇒ ((d = g) ⇒∃v.(v |= g) ∧∀v  , (v  |= g) ⇒ v  ≥ v) Let us illustrate the necessity for condition (C2) with the following example. Assume a transition with guard g = x>1 and deadline d = x>1, where x ∈ C. Notice that both g and d denote the same solution set, which corre- sponds to the left-open interval v(x) ∈ (1, ∞). This transition will be urgent as soon as it is enabled, but the constraint imposed by the d does not allow 356 12 Timelocks in Timed Automata time to progress beyond v(x) = 1 (to see why, check the semantic rule S2 below). It should not be difficult to see, then, that TADs that do not fulfill (C2) are not guaranteed to be time reactive, even if deadlines imply guards (C1). Semantics. Let A =(L,TL,T,l 0 ,C,I) be a TAD where all actions are completed (i.e. TL ⊆ CAct). The semantics of A aregivenbytheTTS (S, Lab ,T S ,s 0 ), where • S ⊆ L × V C is the set of reachable states; i.e. S = { s 0 }∪{s  |∃s ∈ S, γ ∈ Lab .s γ −→→ s  } • s 0 =[l 0 ,v 0 ] is the starting state; • Lab = TL ∪ R + is the set of transition labels; • T S ⊆ S × Lab × S is the transition relation, defined by the following inference rules, (S1) l a,g,d,r −−−−−→ l  v |= g [l, v] a −→→ [l  ,r(v)] (S2) ∀ l  ,l a,g,d,r −−−−−→ l  ⇒∀t  <t∈ R + ,v+ t  |= d [l, v] t −→→ [l, v + t] At the beginning of this section, we elaborated on the relation between dead- lines and invariants; let us carry on with this comparison a bit further. Ur- gency, as expressed by deadlines in TADs, has more in common with a weak interpretation of invariants in TAs (Section 11.2.2), than it does with the strong interpretation. For example, the TAD shown in Figure 12.5(i) can per- form transition a at any time (false-deadlines model non urgent actions), but it will take b immediately after that. This behaviour corresponds to the timed automaton with weak invariants in (ii). Notice that, if the same automaton would be given a strong invariant interpretation, no transition (not even a) can ever be performed, as locations with false-invariants cannot be entered. On the other hand, the timed automaton with strong invariants shown in (iii) achieves the same behaviour as the TAD in (i), at the expense of adding a clock x, which is reset in a, and attaching the invariant x = 0 to location 2. In any case, as we have discussed before (and illustrated by Figure 12.4), the semantics of networks of TADs cannot always be expressed by networks of TAs. Parallel Composition (Sparse TADs). Let |A = A 1 , ,A n  be a net- work of TADs, where 12.3 Time-actionlocks 357 1 2 3 ab (false) 1 2 3 ab false (true) true true 12 3 a b true true x:=0 x=0 (i) TAD (ii) TA−weak invariants (iii) TA−strong invariants Fig. 12.5. Deadlines, Weak Invariants and Strong Invariants A i =(L i , TL i ,T i ,l i,0 ,C i ) for 1 ≤ i ≤ n.Letu, u  , etc. denote location vectors. Once again, here we follow the substitution notation introduced in Section 8.2.2.2. The product automaton is defined as Π =(L, TL,T,l 0 ,C) where • L = { l 0 }∪{u  |∃u ∈ L, a, g, d, r . u a,g,d,r −−−−−→ u  }; • TL = n  i=1 TL i ; • T is as defined by the following rules (1 ≤ i = j ≤ n), (TAD1) u i a?,g i ,d i ,r i −−−−−−−→ i lu j a!,g j ,d j ,r j −−−−−−−→ j l  u a,g  ,d  ,r i ∪r j −−−−−−−−−→ u[l → i, l  → j] (TAD2) u i a,g,d,r −−−−−→ i la∈ CAct u a,g,d,r −−−−−→ u[l → i] where g   g i ∧ g j and d   g i ∧ g j ∧ (d i ∨ d j ); • l 0 = l 1,0 , ,l n,0 ;and • C = n  i=1 C i Rule (TAD1) defines synchronisation in TADs. As in TAs, guards and reset sets of component transitions (matching half actions) are combined in the re- sulting transition in the product automaton (completed action). Two things must be noticed in the definition of the resulting deadline. First, the disjunc- tion of component deadlines ensures that synchronisation is made urgent if at least one of the involved half actions is urgent. Second, and as it is nec- essary to ensure time-reactiveness, conjoining the component guards ensures that deadlines in the product automaton’s transitions imply their guards. In other words, synchronisation is urgent only if it can be performed. Finally, rule (TAD2) gives the standard interpretation for completed actions in component TADs. 358 12 Timelocks in Timed Automata 12.3.2 Example: A TAD Specification for the Multimedia Stream Figure 12.6 shows a TAD specification for the multimedia stream, correspond- ing to the example discussed in Section 12.3. Transitions have been annotated with the necessary deadlines (shown in brackets): for example, sourceOut? in Source1.State1 is made urgent as soon as it is enabled (with a deadline t1 = 50). Let us revisit the scenario which caused a time-actionlock in the TA specification (see again Figure 12.3). Source1 sends at t =0;Source2 sends at t = 10 and attempts to send the second packet at t = 35. At this point, Source2 blocks because synchronisation with sourceOut? in either Place1 or Place2 is not possible. However, unlike in the TA specification, time is not prevented from passing and all the other components can evolve normally. This is so because deadlines attached to half actions are only enforced if syn- chronisation can be achieved (rule TAD1). State1 State1 State1 Place1 Place2 Sink State0 State0 State1 State2 State2 State2 State1 Source1 Source2 sourceOut ! (t1=0) sourceOut ? t4:=0 sourceOut ? t3:=0 sinkIn ? t2:=0 sourceOut ! t5:=0 t1=50 sourceout ! (t1=50) t1:=0 play t2=5 (t2=5) t5=25 sourceOut ! (t5=25) t5:=0 sinkIn ! t3>=80 (t3=90) sinkIn ! t4>=80 (t4=90) Fig. 12.6. A TAD Specification for the Multimedia Stream (with Two Sources) 12.4 Zeno-timelocks 359 12.4 Zeno-timelocks This section elaborates on a number of methods to detect nonzenoness [44, 190]. Before discussing these approaches in detail, let us introduce some basic concepts and notation which appear throughout the section. Preliminaries. Let A ∈ TA. A simple loop is a cycle in the timed automaton graph; i.e. a sequence of locations and transitions of the form, l 0 a 1 ,g 1 ,r 1 −−−−−→ l 1 a 2 ,g 2 ,r 2 −−−−−→ a n ,g n ,r n −−−−−−→ l n where l 0 = l n such that l i = l j for all 0 ≤ i = j<n. A nonsimple loop is, correspondingly, a sequence of locations and transitions that starts and ends in the same location, and also contains other repeating locations. Unless otherwise stated, when we talk about loops we are referring to simple loops. Usually, we refer to loops (both simple and nonsimple) through their component transitions. For example, Figure 12.7 shows two simple loops, ab 6 and cd , and one nonsimple loop, acdb. The entry point (a location throughwhichtheloopisreachable)intheseloopsislocation1,wherex is previously set to 0. x:=0 1 x<=1x<=1x<=1 3 2 a b c d Fig. 12.7. Simple and Non Simple Loops Let Loops(A) be the set of all loops in A,andlp a given loop in A. Loc(lp) is the set of all locations of lp; Clocks(lp) is the set of all clocks occurring in any invariant of lp; Trans (lp), Guards(lp)andResets (lp)are,respectively,thesets of all transitions of lp, all guards of lp, and all clocks that are reset in lp;and Act (lp) is the set of all actions labelling transitions in lp.Ahalf loop is a loop that contains at least one transition labelled with a half action. A completed loop is a loop which is not a half loop, i.e. a loop where all transitions are labelled with completed actions. 12.4.1 Example: Zeno-timelocks in the Multimedia Stream Figure 12.8 shows a multimedia stream similar to the one described in Sec- tion 12.3 (Figure 12.3), but where a new component Source3 has been added. 6 The notation for loops must not be confused with that we have used for location vectors, e.g. 1, 3. [...]... a (t = 0)-state in which no (t = 1)-state is reachable It turns out that, considering again a network augmented with a test automaton such as the one shown in Figure 12.16, a sufficient-and-necessary condition for nonzenoness is given by the TCTL formula AG((t = 0) ⇒ EF(t = 1)) Indeed, a system is timelock-free if there exists at least one run starting at every (t = 0)-state, where a (t = 1)-state is... that the loop cd contains a local zeno-timelock The following theorem (proved in [44]) formalises a sufficient-and-necessary condition for nonzenoness in a timed automaton Theorem 12.5 Let A ∈ TA A contains a zeno-timelock if and only if there exists a loop in A, lp, such that reachable(A, φ) holds, where φ is defined as follows, φ A.l ∧ α(lp) ∧ β(lp), l ∈ Loc(lp) Zeno-timelocks and Nonsimple Loops Clearly,... that a sufficient-and-necessary condition for the occurrence of zeno-timelocks in a given loop can be expressed as a reachability problem A loop lp contains a zeno-timelock if and only if a state in lp can be reached where the valuation is maximal, and it does not enable any transition leading to a location outside lp Moreover, we show that such a state can be characterised by a formula con- 9 Moreover,... State2 t4=80 sourceOut ? t3:=0 State2 t3 . on syntactic infor- mation obtained from a timed automaton’s structure, can be used to provide a sufficient-and-necessary condition to guarantee nonzenoness. This sufficient-and-necessary condition,. time-actionlocks should be prevented by construction; i.e. the timed automata model should be rein- terpreted in such a way that time-actionlocks just cannot arise. Finally, to come to zeno-timelocks:. Sufficient-and-Necessary Condition The syntactic conditions presented in the previous section provide sufficient- only conditions for nonzenoness. One may argue that in most systems the presence of zeno-timelocks