5.6 The Formula Evaluation Algorithm
5.6.10 Evaluation of Temporal Operators
As one would expect, the major part of the evaluation algorithm’s complexity is found within the cases for temporal operators. In fact, it is the ability to use interval operations for realizing the semantics of the temporal operators that makes SALMA’s evaluation algorithm efficient. Therefore, this subsection discusses the involved strategies and design decisions in detail. Algorithm 5.11 gives an overview of the three cases for temporal operators, namelyeventually, always, and until. It can be seen that eventually and always are handled by the same function that distinguishes the cases via its first parameter. This implies that the evaluation of both operators is similar to some extent, which is indeed confirmed below. On the other hand, there are several special difficulties for the evaluation of the until operator, so this case is handled separately in order to achieve a comprehensible presentation.
Algorithm 5.11: Evaluation of temporal operators.
. . .
case Φ =always(Tmax, P) h
res
R , Rov,Ψ,linkParamsi ← evaluateAlwaysOrEventually(,P, ˆ
pΦ,level,scur, Ts,Tend, Tmax) end
case Φ =eventually(Tmax, P) h
res
R , Rov,Ψ,linkParamsi ← evaluateAlwaysOrEventually(♦,P, ˆ
pΦ,level,scur, Ts,Tend, Tmax) end
case Φ =until(Tmax, P, Q) h
res
R , Rov,Ψ,linkParamsi ← evaluateUntil(P, Q,
level,pˆΦ,scur, Ts,Tend, Tmax) end
A Common procedure for always(Tmax, P) and eventually(Tmax, P) The common scaffolding for the evaluation of always and eventually is the function shown in Algorithm 5.12. First, the upper time bound for the evalu-ation intervalT>is calculated as the minimum of the end of the time advance Tend and theevaluation limit Tlim. The latter is given by the latest point that is reachable from any point in the start time interval sequence Ts within the time bound of the operatorTmax. To calculate this, the operatormaxt from Definition 5.11 is used, which yields the latest time point in the given interval sequence. The other relevant time point,Tcur, is determined as before by eval-uating the fluenttime for the situation given by the current stepscur. After these initializations have been made, the algorithm has to distinguish between two cases. First, the subformula P of the temporal operator could be of the formsched(Idsched, Idcache), which implies that in fact the original subformula at this position has been scheduled as a subgoal because at least for one time instance the result of the evaluation was not definite. In this case, the formula is loaded from the cache using the id that was conveyed in the sched-term.
Otherwise, ifP is nosched-term, it is used directly for the further evaluation and the ids for the formula cache and the schedule are set to−1, which act as commands that will cause the creation of new entries as required.
The next step is to evaluate the subformula for all distinct time steps from the current time Tcur to the interval end T>. As expected, this is per-formed by the function evaluateForAllTImesteps from Algorithm 5.2 that was already presented as part of the top-level property evaluation procedure (Algorithm 5.1). It was shown before that during this iteration, schedule
en-tries are created for each time point for which the evaluation did not pro-duce a definite result (?). Therefore, it can be assumed after the call to evaluateForAllTImesteps that the evaluation goal schedule is set up with all entries that are necessary for further calculations. The variables Id0sched andId0cachecontain either−1or the ids that refer to the relevant entries in the schedule and the cache forP after the lookahead evaluation, which could have been created in this process. Besides the updated ids, the call to evaluateFor-AllTImestepsreturns three other values, namely the result summaryRov1, the time of the earliest positive definite outcome, Tdef< , and the time of the latest possibility for a positive outcome, Tposs> . While these time markers were ig-nored in the top-level evaluation procedure (Algorithm 5.1), they are crucial for the evaluation of temporal expressions.
At this point, the treatment of always and eventually diverges into the functionshandleAlwaysandhandleEventuallythat are shown in Algorithms 5.13 and 5.15 and are discussed below. Both functions return a result mapping
res
R1 and an interval sequenceTs0 that contains the start times fromTs for which no definite result could be determined. Consequently, the intervals in Ts0 are labeled with ?and combined with the results from before into the final result mapping
res
R. In the rest of Algorithm 5.12, a result summary is determined and, if the result is not entirely definite, asched-term is established as replace-ment for P that, together with the link parameters that are created along the way, reference the goal that represents P in the evaluation goal schedule.
In the following, the individual algorithms for the evaluation ofalwaysand eventually are described. Although they are structured very similarly, the full functions are shown to make them easier to understand.
The Evaluation of always(Tmax, P)
Algorithm 5.13 shows the functionhandleAlways, which expects as arguments the previously calculated result summary of the lookahead evaluation Rov1, the time of the latest possible positive result Tposs> , the time bound of the always-expressionTmax, the evaluation interval endT>, the start time interval sequenceTs, and the schedule id of the goal that represents the subformula P, which could also be −1as described above.
The interval-based calculations described above are visualized in Figure 5.15.
In the top row (Figure 5.15a), the first part ofhandleAlwayscan be seen, where the algorithm tries to leverage results from the lookahead evaluation that was done beforehand. This is possible when a negative result was found at some point in evaluateForAllTimesteps. Then,Tposs> will point to the last time at which a positive result is still possible, which has to be the step just before the one in which the negative result was found. This implies that all scheduled in-stances ofP that start not longer thanTmaxbeforeTposs> will be terminated by the negative result. Therefore, these time points can be marked as negative,
Algorithm 5.12: Evaluation ofalwaysor eventually.
functionevaluateAlwaysOrEventually(mode, P, pˆΦ, level,scur, Ts, Tend,Tmax) Tstart> ←maxt(Ts)
Tlim←Tstart> +Tmax T>←min(Tlim, Tend)
Tcur ←time(do(tick(scur), S0)) if P =sched(Idsched, Idcache) then
P0 ←loadFromCache(Idcache) else
P0 ←P, Idsched← −1, Idcache← −1 end
hRov1, Tdef< , Tposs> , Id0sched, Id0cachei ←
evaluateForAllTimesteps(mode, P0,pˆΦ◦2, level+ 1, scur,Tcur,T>, Idsched,Idcache) assume A schedule entry has been added for every time point
where the evaluation of P yielded ?. if mode= then
h
res
R1, Ts0i ← handleAlways(Rov1, Tposs> ,
Tmax, T>, Ts, Id0sched) else
h
res
R1, Ts0i ← handleEventually(Rov1, Tdef< ,
Tmax, T>, Ts, Id0sched) end
res
R2 ←Ts0|?
res
R ←
res
R1∪
res
R2 Rov ←summary(
res
R) if Rov =?then
Ψ← {27→sched(∗, Id0cache)} /* ∗ represents
a placeholder for the concrete schedule id */
linkParams ← {ˆpΦ◦27→Id0sched} else
Ψ← ∅,linkParams ← ∅ end
returnh
res
R , Rov,Ψ,linkParamsi end
which is done by building the intersection of Ts with the described interval and labeling it with the unique assignment operator |, which creates a result mapping that is stored in the variable
res
R1. The relative complement of the original start times Ts and the said interval yields an interval sequence that contains the time start time instances for which the result is still open. How-ever, it is still possible that more definite results can be found. First, if there is an entry forP in the evaluation goal schedule, the evaluation history could convey enough information to determine additional results. This is pursued in the function checkScheduleAlwaysin Algorithm 5.14.
In Algorithm 5.14, the goal evaluation history is loaded from the schedule using the given id. By matching all intervals within the negative historyG. T⊥
against the start timesTs, it is possible to mark all those instances as failed that are at mostTmax time units before a time point with negative result. Similar to the first step in handleAlways, this labeling of multiple time instances is reduced to a single intersection between an interval sequence and an interval.
The result mapping that is created in this way is appended to a collective result mapping
res
Rtot that is returned later, and as before, the sequence of undetermined start time intervals is updated using the relative complement.
Figure 5.15c shows an example for the negative labeling of several interval segments based on one interval from G. T⊥.
The other source for determining definite results is the positive history G. T>. Indeed, this sequence might contain positive intervals that are at least as long as Tmax. Then, any goal instance that starts within that interval and at least Tmax time units before its end, can be labeled as positive because the invariant is guaranteed to have been fulfilled within the given time bound.
This can be seen in Figure 5.15d. All results that are calculated based on the evaluation history are returned back tohandleAlways, together with the start time intervals for no results have been found, yet, which will later be marked with?, as shown in Algorithm 5.12.
Back in handleAlways, it is also possible that no schedule entry exists.
However, some definite results can still be found if the overall result of the lookahead evaluation was positive. This means that there must have been positive results for all time points up to T>. Hence, all instances in Ts that begin at least Tmax time units before T> must be satisfied and can be la-beled with >. Figure 5.15b shows the involved interval operations. It can be seen that the algorithm effectively assumes that the evaluation results for the subformula P have also been positive for all relevant time points that are overlapped by intervals in Ts. Indeed, this assumption is justified because if any of these time points had yielded a negative result, then the intervals in Ts that are within a distance of Tmax would have been negated already in a previous evaluation step.
Algorithm 5.13: Handling of temporal operatoralways. functionhandleAlways(Rov1, Tposs> ,Tmax, T>, Ts, Idsched)
if Rov1 =⊥then
// See Figure 5.15a Tl←Tposs> −Tmax
res
R1 ←(Ts∩[Tl, T>])|⊥ Ts0 ←Ts\[Tl, T>] else
res
R1 ← ∅, Ts0 ←Ts
end
if Ts0 6=∅ then
if Idsched >−1then h
res
R2, Ts00i ←checkScheduleAlways(Idsched, Ts0, Tmax) else
// There is no schedule entry for the subformula P. if Rov1 =>then
// See Figure 5.15b Tr←T>−Tmax
res
R2 ←(Ts0∩[0, Tr])|>
Ts00←Ts0\[0, Tr] else
res
R2 ← ∅, Ts00 ←Ts0 end
end else
res
R2 ← ∅, Ts00 ← ∅ end
returnh
res
R1∪
res
R2, Ts00i end
Algorithm 5.14:Calculating schedule decisions for always. functioncheckScheduleAlways(Idsched, Ts, Tmax)
G←loadFromSchedule(Idsched) Ts0 ←Ts
res
Rtot ← ∅
/* Negate all starting points within range of ⊥
instances. */
foreach[T1, T2]∈G. T⊥ do
// See Figure 5.15c Tl ←max(0, T1−Tmax)
res
R ←(Ts0∩[Tl, T2])|⊥
res
Rtot ←
res
Rtot∪
res
R Ts0 ←Ts0\[Tl, T2] end
/* Confirm goals that are entirely covered in >
intervals. */
foreach[T1, T2]∈G. T> do
// See Figure 5.15d if T2−T1 ≥Tmax then
Tr ←T2−Tmax res
R ←(Ts0∩[T1, Tr])|>
res
Rtot ←
res
Rtot∪
res
R Ts0 ←Ts0\[T1, Tr] end
end returnh
res
Rtot, Ts0i end
(a) Determining⊥instances through lookahead evaluation results.
(b) Determining>instances through lookahead evaluation results.
(c) Determining ⊥instances through schedule history.
(d) Determining>instances through schedule history.
Figure 5.15: Calculation of results for always.
The Evaluation of eventually(Tmax, P)
As expected, the operator eventually is treated very similarly to its always counterpart. In fact, the only difference is that the roles of positive results are reversed. This means that exactly the same structure that is used to “reject”
goal instances based on negative lookahead results in the case ofalwaysis used to confirm goal instances with positive results. The same congruence obviously holds also for the other cases. Therefore, it is not very instructional to discuss the algorithms for eventually in detail. Nonetheless, both the algorithms (Algorithm 5.15, 5.16) and the interval diagrams (Figure 5.16) are included here for the sake of completeness.
Algorithm 5.15: Handling of temporal operatoreventually. functionhandleEventually(Rov1, Tdef< , Tmax,T>, Ts, Idsched)
if Rov1 =>then Tl←Tdef< −Tmax
res
R1 ←(Ts∩[Tl, T>])|>
Ts0 ←Ts\[Tl, T>] else
res
R1 ← ∅,Ts0 ←Ts end
if Ts0 6=∅ then
if Idsched >−1then h
res
R2, Ts00i ←checkScheduleEventually(Idsched, Ts0, Tmax) else
// There is no schedule entry for P.
if Rov1 =⊥then Tr←T>−Tmax
res
R2 ←(Ts0∩[0, Tr])|⊥ Ts00←Ts0\[0, Tr] else
res
R2 ← ∅,Ts00←Ts0 end
end else
res
R2 ← ∅,Ts00← ∅ end
returnh
res
R1∪
res
R2, Ts00i end
(a) Determining >instances through lookahead evaluation results.
(b) Determining⊥instances through lookahead evaluation results.
(c) Determining>instances through schedule history.
(d) Determining⊥instances through schedule history.
Figure 5.16: Calculation of results for eventually.
Algorithm 5.16: Calculating schedule decisions foreventually. functioncheckScheduleEventually(Idsched, Ts, Tmax)
G←loadFromSchedule(Idsched) Ts0 ←Ts
res
Rtot ← ∅
/* Acknowledge all starting points within range of >
instances. */
foreach[T1, T2]∈G. T> do Tl←max(0, T1−Tmax)
res
R ←(Ts0∩[Tl, T2])|>
res
Rtot ←
res
Rtot∪
res
R Ts0 ←Ts0\[Tl, T2] end
/* Handle time-outs. */
foreach[T1, T2]∈G. T⊥ do if T2−T1 ≥Tmax then
Tr←T2−Tmax
res
R ←(Ts0∩[T1, Tr])|⊥
res
Rtot ←
res
Rtot∪
res
R Ts0 ←Ts0\[T1, Tr] end
end returnh
res
Rtot, Ts0i end
Evaluation of until(Tmax, P, Q)
For the efficient evaluation of until-expressions, the algorithm has to extend and combine the ideas from the handlers for eventually / always so that definite results can be found as early as possible. The main procedure foruntil is shown in Algorithm 5.17. The first part performs an initialization that is very similar to that of the Algorithms 5.13 and 5.15. Of course, two subformulas have to be set up, namely P for the invariant part and Q for the goal part.
After the initialization, lookahead evaluation is performed for bothP and Q, withQ treated like aneventually formula (♦) and P as in always(). It is worth noticing that forQ, the iteration is not necessarily performed up to the general end of the evaluation period (T>), but only to the earliest point where
Algorithm 5.17:Evaluation of until.
functionevaluateUntil(P, Q, pˆΦ, level, scur, Ts, Tend, Tmax) Tstart> ←maxt(Ts)
Tlim ←Tstart> +Tmax T>←min(Tlim, Tend)
Tcur ←time(do(tick(scur), S0))
if P =sched(Idsched,P, Idcache,P)then P0← loadFromCache(Idcache,P) else
P0←P
Idsched,P ←new, Idcache,P ←new // force scheduling end
if Q=sched(Idsched,Q, Idcache,Q) then Q0← loadFromCache(Idcache,Q) else
Q0←Q, Idsched,Q←new, Idcache,Q←new end
hTdef< ,Q, Id0sched,Q, Id0cache,Qi ← evaluateForAllTimesteps(♦, Q0, pˆΦ◦3,level+ 1, scur, Tcur, T>, Idsched,Q, Idcache,Q) if Tdef< ,Q6=? thenTP>←Tdef< ,QelseTP>←?
hId0sched,P, Id0cache,Pi ←evaluateForAllTimesteps(, P0, pˆΦ◦2, level+ 1, scur, Tcur,TP>, Idsched,P, Idcache,P)
assume all relevant results betweenTcur and T>
have been added to the goal schedule.
h
res
R , T0i ← checkScheduleUntil(Id0sched,P, Id0sched,Q, Ts, Tmax)
res
R ←
res
R ∪T0|? Rov ←summary(
res
R) if Rov =? then
Ψ← {27→sched(∗, Id0cache,P),37→sched(∗, Id0cache,Q)}
linkParams ← {ˆpΦ◦27→Id0sched,P,pˆΦ◦37→Id0sched,Q} else
Ψ← ∅,linkParams ← ∅ end
returnh
res
R , Rov,Ψ,linkParamsi end
a positive definite result forQis found – if that is the case. Another specialty of theuntil-case is that the creation of evaluation goal schedule entries is forces by the new flag, even in cases where the lookahead evaluation produced only definite results. This guarantees that a history for bothP and Q exists that contains all results up to T>. The evaluation algorithm can therefore use the same decision mechanisms over the whole relevant time span, which allows for a much clearer design. In that sense, the function checkScheduleUntil in Algorithm 5.18 arranges all schedule-based calculations into four phases that are by themselves sourced out to four separate functions.
In the first phase, the functionconfirmScheduledUntilGoals(Algorithm 5.19) uses the evaluation goal history of bothP and Qto determine instances that can be confirmed definitively. First, this is possible when the goal Q is true directly at the start time of a goal instance, i.e. when the intersection between an interval inGQ. T> andTs is not empty. Figure 5.17a demonstrates this situation. Therefore, the function in Algorithm 5.19 iterates through all intervals in the positive history of Q and successively fills a result mapping with >-entries that are retrieved by means of the intersection operator from Definition 5.8. Besides that, the start time points that are confirmed in this way are “cut out” ofTsby the relative complement and the iteration is canceled at the end of the loop body ifTs is empty.
As shown at in the right part of Figure 5.17a, even if Q is not true at an instance’s start, a positive outcome can still be confirmed when a true result for Q is found within Tmax time units and P is true up to that point. The second part of this condition is equivalent to the existence of an interval in GP. T> that is left adjacent to a positiveQinterval. If such an interval exists, then all time points can be confirmed that are both within that interval and
Algorithm 5.18: Calculating schedule decisions foruntil. functioncheckScheduleUntil(Idsched,P, Idsched,Q,Ts, Tmax)
GP ←loadFromSchedule(Idsched,P) GQ←loadFromSchedule(Idsched,Q)
T0 ←Ts /* unhandled start times */
h
res
R1, T0i ← confirmScheduledUntilGoals(T0, GP, GQ, Tmax) h
res
R2, T0i ← rejectUntilGoalsP(T0, GP) h
res
R3, T0i ← rejectUntilGoalsPQ(T0,GP, GQ) h
res
R4, T0i ← detectTimedOutUntilGoals(T0, GQ, Tmax) returnh
res
R1∪
res
R2∪
res
R3∪
res
R4, T0i end
not farther thanTmax from the positiveQinterval. This is done in the middle block of Algorithm 5.19, again using the intersection operator and the relative complement to compile results and to remove handled start times from Ts.
After all positive results have been gathered, the produced result mapping is returned tocheckScheduleUntiltogether with a temporal interval sequence T0 that contains the “unhandled” start times, i.e. the goal instances that have not been confirmed yet. In the next step, this remaining start time interval sequence is passed to the function rejectUntilGoalsP(Algorithm 5.20) that processes cases in which goal instances can be rejected because P is known to be violated at their start point (see right part of Figure 5.17b). On the other hand, goal instances can also be identified as failed when the period between their start and the earliest time point where Q is true is interrupted by a negative outcome for P. Transferred to the interval-based viewpoint, this situation can be identified when an interval ofGQ. T⊥overlaps intervals of GP. T⊥. Then, all goal instances that start within the interval with negativeQ and before the last time point in the overlapped region ofGP. T⊥are inevitably interrupted and can thus be marked as failed (see Algorithm 5.21 and left part of Figure 5.17b). Finally, in the last step of checkScheduleUntil, the algorithm searches for goal instances that have expired their time bounds (see Algorithm 5.22 and Figure 5.17c). After all these possible definite cases have been handled, the result for evaluateUntilis combined very similarly to the cases for eventually and always.
Algorithm 5.19: Confirmation ofuntil goals.
functionconfirmScheduledUntilGoals(Ts, GP, GQ,Tmax) T0 ←Ts,
res
R ← ∅
foreach[Ts,Q, Te,Q]∈GQ. T> do
/* Confirm instances where Q holds directly at the
start point. */
res
R1 ←(T0∩[Ts,Q, Te,Q])|>
T0 ←T0\[Ts,Q, Te,Q]
/* If P has been true continuously for an interval before Ts,Q, we can confirm additional goals. */
if ∃[ts, te]∈GP. T>. Ts,Q ∈[ts, te]then Tl←max(ts, Ts,Q−Tmax)
res
R2 ←(T0∩[Tl, Ts,Q])|>
T0 ←T0\[Tl, Ts,Q] else
res
R2 ← ∅ end
res
R ←
res
R ∪
res
R1∪
res
R2 if T0 =∅ then break end
returnh
res
R , T0i end
Algorithm 5.20:Rejection ofuntilgoals that lie within a¬P-interval.
functionrejectUntilGoalsP(Ts,GP)
T0←Ts /* unhandled start times */
res
R ← ∅
foreach[Ts, Te]∈GP. T⊥ do
res
R0 ←(T0∩[Ts, Te])|⊥
res
R ←
res
R ∪
res
R0 T0←T0\[Ts, Te] if T0=∅then break end
returnh
res
R , T0i end
Algorithm 5.21:Rejection of inevitably interrupteduntil goals.
functionrejectUntilGoalsPQ(Ts, GP, GQ)
T0←Ts /* unhandled start times */
res
R ← ∅
foreach[Ts,Q, Te,Q]∈GQ. T⊥ do Tintr ←GP. T⊥∩[Ts,Q, Te,Q] if Tintr 6=∅then
Tr ←maxt(Tintr)
res
R0 ←(T0 ∩[Ts,Q, Tr])|⊥
res
R ←
res
R ∪
res
R0 T0←T0\[Ts,Q, Tr] end
if T0=∅then break end
returnh
res
R , T0i end