summary(
res
R) =
> if ∀I ∈ IT(T).R(I) =>
⊥ if ∀I ∈ IT(T).R(I) =⊥ ambiguous if (∀I ∈ IT(T).R(I)6=?)
∧(∃I0 ∈ IT(T).R(I0) =>)
∧(∃I00 ∈ IT(T).R(I00) =⊥)
? if ∃I ∈ IT(T).R(I) =?
In the definition above,?has precedence overambiguous in the sense that even if the result mapping contains both positive and negative definite inter-vals, it is still seen as undetermined if at least one of its intervals is. This is important for the evaluation algorithm since it indicates that at least for some of the intervals, entries for the evaluation goal schedule have to be created.
Other mechanisms to manipulate result mappings are actually not neces-sary, since result mappings are only used as means for data collection through-out recursive function calls during property evaluation. The actual evaluation state information in the evaluation goal schedule is stored differently. This will be discussed in Section 5.5. However, before the data structures involved in the evaluation goal schedule can be examined properly, it is necessary to look at the way in which formulas are translated into the internal representation that is actually used by the Prolog-based property interpreter. This is the topic of the next section.
Due to its rather technical nature, it is not practicable to describe the whole compilation process in detail. However, this section will describe the most important transformation rules since they offer valuable insight in the expected structure of the internal representation. This in turn will later in Section 5.6 be very helpful for understanding some of the most essential design aspects of the evaluation algorithm.
First, however, it is necessary to introduce some essential concepts, namely variable substitution, term unification, and subterm substitution. First, vari-able substitution and unification are defined in the usual way in which it can be found throughout the literature, for instance in [BA12, CHAP. 10].
Definition 5.18 (Variable substitution). A variable substitutionθ ={x1 7→
t1, . . . , xn7→tn}is a set of mappings from variables to terms. The application of a substitution θto a termφ, is written asθφ. The result ofθφis defined as the term that results from replacing any occurrence of a variable x1 to xn in φ with the corresponding replacement term from the substitutionθ.
Using variable substitutionunification of two terms can be defined.
Definition 5.19 (Unification). A substitution θ is a unifier for two terms φ and ψ if θφ = θψ. Furthermore, Two terms φ and ψ are unifiable, written φ'θ if there exists a unifier for them.
Besides being one of the most basic mechanism in logic programming and therefore in the evaluation of SALMA-PSL formulas, the unification concept is used here to define thesubterm substitution operation, which is used in various places both in the property compiler and the formula evaluation algorithms.
Definition 5.20 (Subterm substitution). LetΘbe a term and letΨ ={θ17→
θ10, . . . , θm 7→ θm0 } be a set of mappings that relate arbitrary ground or non-ground termsθito ground replacement termsθ0i. Thensubstterm(Ψ,Θ)denotes the subterm substitution that results from rewritingΘ by replacing each sub-term of Θ that unifies with one ofθ1, . . . , θm with the respective substitution term. Formally, let cbe a symbol with arity0,φa symbol with arityn. Then substterm(Ψ,Θ)is recursively defined as follows:
1. substterm(Ψ, c) =
(θ0 if ∃θ.θ'c∧θ7→θ0∈Ψ c otherwise
2. substterm(Ψ, φ(t1, . . . , tn)) =
θ0 if ∃θ.θ'φ(t1, . . . , tn)∧θ7→θ0∈Ψ φ(substterm(Ψ, t1), . . . ,
substterm(Ψ, tn)) otherwise
3. substterm({θ7→θ0} ∪Ψ,Φ) =substterm({θ7→θ0}, substterm(Ψ,Φ))
The ability to replace arbitrary subterms allows in particular to substitute variables that are bound by quantifiers. In fact, since all sort domains within a SALMA model are constrained to be finite sets, the property compiler can eliminate any quantifier in the following way:
1. Iterate over the entities in the sort domain of the variable that is bound by the quantifier.
2. For each of these entities, create an instance of the original subformula inside the quantifier where this entity is substituted for the bound vari-able.
3. In case of universal quantification (forall), replace the quantifier block with a conjunction over the generated subformula instances. For exis-tential quantification (exists), use a disjunction instead.
Formally, when JΦKcomp denotes the result of the compilation procedure for the SALMA-PSL formula Φ, then the quantifier elimination step can be expressed as follows:
Definition 5.21(Quantifier elimination in the property compiler). LetΦbe a SALMA-PSL formula andT be a finite sort withdomain(T) ={e1, . . . , en}. Then the elimination of quantifiers inΦ, written aselimQ(Φ)can be defined recursively as follows:
elimQ(f orall(x:T,Φ)) =and(elimQ(substterm({x7→e1},Φ)), . . . , elimQ(substterm({x7→en},Φ))) elimQ(exists(x:T,Φ)) =or(elimQ(substterm({x7→e1},Φ)), . . . ,
elimQ(substterm({x7→en},Φ)))
One direct result of this way of representing quantification is that formulas have to be re-compiled when the domain of a sort changes during simulation, i.e. when entities are created or destroyed during simulation. Although the use of dynamic sorts complicates reasoning about the system model and is therefore not generally recommended, it is used within SALMA’s extension for modeling information transfer that is described in Chapter 6 (see Sec-tion 6.2.5). Having to re-compile formulas during simulaSec-tions might seem like an unnecessary overhead compared to possible alternative solutions in which
sort domains are cleanly separated from the formulas and accessed dynamically during evaluation. However, since formulas in the evaluation goal schedule are not re-compiled, the domain at the time a formula is added to the schedule is effectively fixated at that moment. A look back to Definition 4.10 reveals that this is exactly what is required by the intended semantics.
After all quantifiers have been eliminated, the property compiler has to translate SALMA-PSL formulas to a representation that can be evaluated by the Prolog interpreter. The main problem is that the evaluation scheme of Prolog does not really support the functional style used in SALMA-PSL formulas. Instead, each immediate result within an evaluation has to be bound to a Prolog variable2 and propagated to the next steps. For instance, consider a formula that tests whether the combined weight of two items is less than100. When it is assumed that weight is a constant defined to take one argument of type item, then this could be expressed with the following SALMA-PSL expression:
weight(item1) + weight(item2) < 100
However, the Prolog representation of the constantweight and the built-in function + are actually defined as predicates that bind their result to a variable that is passed as the last position. This means that the results of all steps of the calculation have to be collected in fresh Prolog variables and then combined in the comparison. In this case, the expression from above will be translated to
all([weight(item1, _530), weight(item2, _567), +(_530, _567, _515), _515 < 100]) Here, _530, _567, and _515 are unnamed (anonymous) Prolog variables that are created programmatically during the compilation process. It can be seen that the first two of them, which store the results retrieved from theweightpredicate, are actually substituted for the correspondingweight() subterms within the sum. The same happens again with_515which eventually passes the sum to the comparison with 100. All rewritten parts are finally combined in a conjunction, which is represented by all in the compilation result. The compiler assures that the binding of each variable appears before its use in the conjunction. Knowing that the evaluation algorithm processes the elements of the conjunction in order, this realizes the intended semantics.
The treatment of functional fluents is very similar to that of regular func-tions, except that the initial situation term (s0) has to be added as a last argument. With this general pattern in mind, the semantics of the translation procedure can be summarized.
2The name Prolog variable is used here and in the following to distinguish them from variables that appear in untranslated SALMA-PSL expressions.
Definition 5.22 (Compilation of SALMA-PSL formulas). Let R(θ1, . . . , θn) denote any relation, including relational fluents, situation-independent predi-cates, and comparisons like<,≤,=,≥,>, or6=. On the other hand, letf rep-resent a situation-independent function, a functional fluent, or an arithmetic operation. For brevity’s sake, the operators for comparisons and arithmetics are thought to appear in prefix form (e.g. +(weight(rob1), weight(rob2)) in-stead of weight(rob1) +weight(rob2)) and thus can be treated exactly like situation-independent predicates or functions. For the subtermsθ1, . . . , θnand Θ1, . . . ,Θn, it is assumed that they do not contain any quantifiers, i.e. there either were none in the original SALMA-PSL formula or they were eliminated by the procedure described above. Furthermore, let[Θ1, . . . ,Θn] represent a list of terms, and A◦B the concatenation of list A and listB. Additionally, hX1, . . . , Xni is used as a notation to describe either a tuple of values that are returned by a function, or a list of variables to which the elements of a tuple are assigned. Besides these variables that are used in the rules below, it is necessary to distinguish between symbolic variables that appear in the SALMA-PSL expressions as regular subterms, and logical variables that are instantiated directly by the Prolog interpreter. Therefore, logical variables are marked with a hat, e.g. xˆ, while unmarked names are used for symbolic variables.
With these notational conventions, the compilation procedure can be de-scribed as follows:
1. processEvalT erms(Bindings,[Θ1, . . . ,Θn]) =hBindings0,[Θ01]◦P arams0i where
hBindings0, P arams0i=processEvalT erms(Bindings00,[Θ2, . . . ,Θn]) where hBindings00,Θ0i=processEvalT erm(Bindings,Θ1) 2. processEvalT erms(Bindings,[Θ]) =processEvalT erm(Bindings,Θ) 3. processEvalT erm(Bindings, v) =hBindings, vi
wherev is a number or an entity literal
4. processEvalT erm(Bindings, f(θ1, . . . , θn)) =hBindings0◦[Θ0],xiˆ where
hBindings0,[θ10, . . . , θn0]i=processEvalT erms(Bindings,[θ1, . . . , θn]) and
Θ0 =
(f(θ01, . . . , θn0,x, Sˆ 0) if f is a fluent f(θ01, . . . , θn0,x)ˆ otherwise
5. compile(R(θ1, . . . , θn)) =c ([β1, . . . , βm,Θ0]) where
Θ0=
(R(θ01, . . . , θ0n, S0) if R is a relational fluent R(θ01, . . . , θ0n) otherwise
with
h[β1, . . . , βm],[θ01, . . . , θn0]i=processEvalT erms([ ],[θ1, . . . , θn]) 6. compile(and(Θ1, . . . ,Θn)) =all([compile(Θ1), . . . , compile(Θn)]) 7. compile(or(Θ1, . . . ,Θn)) =one([compile(Θ1), . . . , compile(Θn)]) 8. compile(not(Θ)) =not(compile(Θ))
9. compile(implies(Φ,Ψ)) =one([not(compile(Φ)), compile(Ψ)]) 10. compile(eventually(T,Φ)) =eventually(T, compile(Φ)) 11. compile(always(T,Φ)) =always(T, compile(Φ))
12. compile(until(T,Φ,Ψ)) =until(T, compile(Φ), compile(Ψ)) 13. compile(occur(Θ)) =occur(compile(Θ))
14. compile(let(x: Θ,Φ)) =let(x: ˆx,Θ0,Φ0)
whereΘ0 =compile(= (ˆx,Θ)) and Φ0 =compile(Φ)
Most of the rules in the definition above are straightforward. The most interesting part is certainly the compilation of predicates and relational fluents in rule 5, which also includes comparisons. In this rule, the compiler uses the recursive functions processEvalT erm and processEvalT erms to gather terms that instantiate freshly created variables, which in turn are substituted for the parameters of compiled relationR. The recursion works on a tuple that consists of two lists that are labeled BindingsandP arams, respectively. The second list contains the parameters that are eventually used in the compilation result, i.e. either constants like numbers or entity symbols, or freshly created logical variables (see above). To this end, the first list,Bindings, contains the terms that, when evaluated, bind these variables to the values of the original subterms they represent. For this to work, the compiler has to assure that, for each variable, its binding term precedes all usages. Indeed, this can be verified by inspection of rule 4: since the binding terms gathered in the recursion step (Bindings0) are used as the left side of the concatenation with the new binding termΘ0, the binding terms are effectively ordered from inside to outside. With the generated order, all terms are combined with the special c (. . .) operator,
comp(p(f(g(h(t))))) =c ([β1, . . . , βm,Θ]) (1)
Θ =p(θ) (2)
h[β1, . . . , βm],[θ]i=pets([f(g(h(t)))]) (3)
=pet(f(g(h(t)))) =hB0◦[Θ0],xiˆ
Θ0=f(θ0,x)ˆ (4)
hB0,[θ0]i=pet(g(h(t))) =hB00◦[Θ00],yiˆ (5)
Θ00=g(θ00,y)ˆ (6)
hB00,[θ00]i=pet(h(t)) =hB000◦[Θ000],ziˆ (7) Θ000=h(θ000,z)ˆ (8) hB000,[θ000]i=pet(t) =h[],[t]i (9)
9in8 : Θ000=h(t,z)ˆ (10)
9,10 in7 : hB00,[θ00]i=h[]◦[h(t,z)],ˆ ziˆ (11) 11 in6 : Θ00=g(ˆz,y)ˆ (12) 11,12 in5 :hB0,[θ0]i=h[]◦[h(t,z)]ˆ ◦[g(ˆz,y)],ˆ yiˆ (13) 13 in4 : Θ0=f(ˆy,x)ˆ (14) 14,13 in3 :h[β1, . . . , βm],[θ]i=h[h(t,z), g(ˆˆ z,y), fˆ (ˆy,x)],ˆ [ˆx]i (15)
15in2 : Θ =p(ˆx) (16)
15,16 in1 :comp(p(f(g(h(t))))) =c ([h(t,z), g(ˆˆ z,y),ˆ (17) f(ˆy,x), p(ˆˆ x)])
Figure 5.10: Transformation of a predicate in the SALMA-PSL compiler.
which is a synonym for all(. . .) but marks the contained term sequence as a coherent evaluation unit that may not be separated by term transformations.
The example in Figure 5.10 illustrates the ideas sketched above. To make it more readable, pet and pets were used as abbreviations for the functions processEvalT ermandprocessEvalT ermsfrom above. Otherwise, the exam-ple adheres strictly to the rules from Definition 5.22. In this case, p is sup-posed to be a situation-independent predicate,f,g, andhare unary situation-independent functions, andtis a literal, e.g. an entity name.