3.8 Related Work
4.1.3 Semantics of SALMA-PSL Properties
In order to properly describe the semantics of the language, it is first necessary to introduce the concept of asimulation trace.
Definition 4.8(Simulation trace). A simulation trace of a modelM, denoted by σM is a finite sequence of situations S0, . . . , Sn, where S0 is the initial situation at the simulation start, Si is the situation after iactions have been performed, andSnis the situation that is present in the latest simulation step.
Furthermore, σknis thesegment of the simulation trace that starts at situation Sk and ends in situationSn.
This notion of atrace segment is important because in general, the interpre-tation of a SALMA-PSL formula depends on both a reference (or start) point and the time span from that point up to the end of the observed simulation trace.
Definition 4.9 (Interpretation with respect to a simulation trace segment). Given a term Θ and a simulation trace segment σkn, the interpretation of Θ with respect to σnk is denoted as JΘK
n
k. This can be understood as the value that is assigned to Θ for the situation Sk when the future of Sk is known up to Sn.
Another concept that is necessary to express the semantics of formulas in terms of the situation calculus is regression, which was introduced in Sec-tion 2.2. The applicaSec-tion of the regression operator to the term Θ, written as R(Θ), transforms Θ to a term that still expresses the same value but refers only to the initial situation S0. This allows using the abbreviated statement M, S0 |=R(Φ)to expresses thatΦis entailed by the basic action theory that is formed by the currently simulated model with the initial situationS0. Simi-larly, when a formula is entailed for all possible initial situations, this is written asM |= Φ.
In the chosen semantics, the interpretation of a formula at a given situation Skis understood in the context of a simulation trace with a fixed last situation Sn. However, for formulas that contain temporal operators, it is not always possible to decide whether they are true or false based only on the available simulation trace segment σkn. Therefore, it is necessary to use a three-valued logic that allows expressing that in a given situation, the result of a formula cannot be decided yet. Throughout the remainder of this thesis, the three possible options will be represented by the symbols>,⊥, and ?.
With the concepts and definitions from above, the semantics of SALMA-PSL formulas can be defined in the context of the situation calculus.
Definition 4.10 (Semantics of a SALMA-PSL expression). Let v be a nu-meric or boolean literal or a constant of an entity sort,θR,1, . . . , θR,n numeric terms, an arithmetic operator, ∼ a comparison operator (i.e. one of <,
≤, =, ≥, >, or 6=), θ, θ1, . . . , θn arbitrary terms, andΦ,Φ1, . . . ,Φn formulas.
Furthermore, leti, j, k, n∈N0 be situation indexes, and letT ∈N0 represent a time limit. Finally, letαandγ be an action and a fluent instance as defined in Definition 4.5 and Definition 4.6, respectively. Then the semantics of a SALMA-PSL expressionΘwith respect to the trace segmentσnk is recursively defined as follows:
1. constants:
JvK
nk =
v if v∈Ror v∈T whereT is an entity sort
> if v=true
⊥ if v=f alse 2. arithmetic expressions: JθR,1θR,2K
n
k =JθR,1K
n
kJθR,2K
n k. 3. functional expressions: Jg(θ1, . . . , θn)K
n k =v
if (a) g is a situation-independent function with arity n and the evalu-ation of g(Jθ1K
n
k, . . . ,JθnK
n
k) yields the result v, or (b) g is a functional fluent andM, S0|=R(g(Jθ1K
n
k, . . . ,JtnK
n
k, Sk)) =v. 4. relational expressions:
a) Jf(θ1, . . . , θn)K
n
k = > if (a) f is a situation-independent predicate and M |= f(Jθ1K
n
k, . . . ,JθnK
n
k), or (b) f is a relational fluent and M, S0|=R(f(θ1, . . . , θn, Sk)).
b) Jθ1∼θ2K
n k =
(> ifJθ1K
n
k ∼Jθ2K
n k
⊥ otherwise 5. temporal expressions:
a) Jeventually(T,Φ)K
n k =
> if ∃j∈[k,min(k+bTc, n)].JΦK
n j =>
⊥ if n≥k+dTe ∧
∀j∈[k, k+dTe].JΦK
n j =⊥
? otherwise
b) Jalways(T,Φ)K
n k =
> if n≥k+dTe ∧
∀j∈[k, k+dTe].JΦK
n j =>
⊥ if ∃j ∈[k,min(k+bTc, n)].JΦK
n j =⊥
? otherwise
c) Juntil(T,Φ1,Φ2)K
n k =
> if ∃j∈[k,min(k+bTc, n)].JΦ2K
nj => ∧
∀i∈[k, j[.JΦ1K
n i =>
⊥ if
∃i∈[k, n].JΦ1K
n i =⊥ ∧
∀j∈[k, i].JΦ2K
nj =⊥
∨
n≥k+dTe ∧
∀j∈[k, k+dTe].JΦ2K
nj =⊥
? otherwise 6. logical connectives:
a) Jnot(Φ)K
n k =
> if JΦK
n k =⊥
⊥ if JΦK
n k =>
? otherwise b) Jand(Φ1, . . . ,Φn)K
n k =
> if ∀1≤i≤n.JΦiK
n k =>
⊥ if ∃1≤i≤n.JΦiK
n k =⊥
? otherwise c) Jor(Φ1, . . . ,Φn)K
n k =
> if ∃1≤i≤n.JΦiK
n k =>
⊥ if ∀1≤i≤n.JΦiK
n k =⊥
? otherwise d) Jimplies(Φ1,Φ2)K
n
k =Jor(not(Φ1),Φ2)K
n k
7. quantifiers:
a) Jforall(x:T,Φ)K
nk =
> if ∀e∈Jdomain(T)K
n k. JΦ[e/x]K
n k =>
⊥ if ∃e∈Jdomain(T)K
n k. JΦ[e/x]K
n k =⊥
? otherwise
b) Jexists(x:T,Φ)K
nk =
> if ∃e∈Jdomain(T)K
n k. JΦ[e/x]K
n k =>
⊥ if ∀e∈Jdomain(T)K
n k. JΦ[e/x]K
n k =⊥
? otherwise 8. Joccur(α)K
n k =
(> if Sk=do(α, Sk−1)
⊥ otherwise
9. JlastTime(α)K
n k =
t if ∃k. Sk=do(α, Sk−1) ∧ time(Sk) =t∧
@k0.k0 > k ∧ Sk0 =do(α, Sk0−1)
−1 if @k. Sk=do(α, Sk−1)
10. Jlet(x:θ,Φ)K
n k =
> if JΦ[JθK
n k/x]K
n k =>
⊥ if JΦ[JθK
n k/x]K
n k =⊥
? otherwise
The first interesting point in the definition above is how fluents are in-terpreted in the rules 3 and 4a. Here, the connection is made between the SALMA-PSL semantics and the situation calculus by reducing the interpre-tation with respect to a simulation trace segment (see Definition 4.9) to the application of theregression operator of the situation calculus that was shortly introduced in Section 2.2. There it was already explained that in SALMA, re-gression is actually never used in the traditional sense, in which the initial situation would refer to the start of the simulation. Instead, progression is used, which effectively means that the database is updated in each step so that the initial situation S0 always directly represents the current simulation state. Thus, the regression-based viewpoint above should be understood as an abstraction that allows a more concise description.
The semantics of the temporal operators clarifies that the current valua-tion of a SALMA-PSL formula always has to be understood with respect to
the current trace segment. A definite value (> or ⊥) is assigned only if the requirements for the temporal operator are either clearly fulfilled or violated within the currently accessible time horizon. Otherwise, the marker?is used to declare that no conclusive decision has been found yet. Naturally, this marker for indefiniteness dominates over other values in the logical operatorsand,or, and not, i.e. one indefinite part of such an expression is enough to prevent a definite decision for the whole expression. As mentioned in Section 4.1.1, the time bound for a temporal operator is not guaranteed to be a natural number.
Since SALMA uses a discrete time base, definite decisions are only possible at time points that are whole numbers. This is reflected by the floor and ceiling functions in the definitions above.
Another crucial aspect of the interpretation of formulas is the way in which the range of quantifiers is determined in rule 7. In fact, the entities that are substituted for the quantifier’s variable are taken from Jdomain(T)K
n
k, which is the current content of the domain of sort T in situation Sk. This actually leads to an evaluation semantics that conforms to a natural understanding of the temporal operators. For instance, a model describing a task scheduling system could contain a sort that represents the set of all tasks that currently exist in the system. If the model is intended for long-running simulations, then it makes sense to integrate the possibility of new tasks being scheduled or finished tasks being deleted. This means that the domain of the sort task could be changing throughout a simulation run. In such a model, one could imagine a simple requirement like the following:
implies(occur(snapshot),eventually(10, forall(t : task,occur(writeStackTrace(t))))
This formula says that as soon as asnapshotevent occurs, all active tasks in the system have to write out their stack traces within 10 time units. In this case it is clear that a task entity that is added to the domain after the snapshot event occurred should not be included in the quantifier inside the until block because the task did not receive the signal in the first place. Here, the static unfolding of domains actually achieves this since the formula that is registered in the evaluation goal schedule when the trigger event occurs automatically refers only to the entities that exist at that time.
The rules for the quantifiers are followed by the definition of predicates occur and the function lastTime that provide access to the last occurrence of a specific action instance. It can be seen that both constructs are inter-preted based on thesimulation history. However, like the use of the regression operator above, this is an abstraction that is meant to achieve a more con-cise presentation. In fact, the SALMA evaluation mechanism does not store a longer part of the history but uses a clock-mechanism that records time-stamps for actions and events (see Section 5.6.8).
In each step of the simulation, when the evaluation mechanism has calcu-lated interpretations for the formulas of all properties that are registered to
be checked during the experiment, the SALMA runtime combine these results and tries to find a verdict for the current simulation trace. At this point, the distinction between goals and invariants matters. Basically, a simulation will be canceled and declared as a failure if at least one invariant from the active property collection is violated. On the other hand, it will be declared as success as soon as all goals are fulfilled. However, sometimes it is not easy to formulate proper goals in order to define the end condition of simulation.
Besides that, it could be possible that the formulated goals are not reached at all or only after an unbearable long simulation runtime. Therefore, it is also possible to specify a time limit at which the simulation is ended at the latest if no conclusive result has been found yet. In this case, the simulation run is found to be a success if no goals were specified and is left as inconclusive (?) if at least one goal is still unsatisfied when the time limit is reached. This behavior is summarized in the following definition.
Definition 4.11 (Interpretation of a property collection). LetPC be a prop-erty collection, i.e. a set of invariants or goals that are specified as in Defini-tion 4.7, and letσ0nbe the simulation trace segment observed up to the current step (n). Furthermore, let Tlim be a time limit specified for the experiment.
Then, the current interpretation of the property collectionPC with respect to σ0nis defined as follows:
JPCK
n0 =
> if (∀Inv∈ PC. Inv=invariant(Φinv) =⇒
∀i∈[0, n].JΦinvK
n i =>)
∧
(∀G∈ PC. G=goal(ΦG) =⇒ ∃j∈[0, n]JΦGK
nj =>)
∧time(Sn)< Tlim
∨ (@G∈ PC.G=goal(ΦG))
⊥ if ∃Inv ∈ PC∃i∈[0, n]. Inv=invariant(Φinv)
∧JΦinvK
n i =⊥
∨ time(Sn)≥Tlim∧
∃G∈ PC.G=goal(ΦG) ∧ ∀j∈[0, n].JΦGK
n j =⊥
? otherwise
The definitions in this section define the semantics of SALMA-PSL prop-erties in a concise but relatively abstract manner. How these rules are imple-mented by SALMA’s property evaluation mechanism is the topic of Chapter 5.
First, however, it is time to return to more practical issues, namely how sta-tistical model checking experiments are actually performed with SALMA.