3.6 SALMA Simulation Semantics
3.6.2 Core Simulation Semantics
In the following, the simulation semantics of SALMA will be described by means of transition rules that define how the system state can evolve during simulation. These rules are written in a style that is inspired by structural operational semantics (see [Plo04]). However, the premises for the applicability of each rule are mostly not stated as explicit preconditions but implicitly by
patterns in the respective data structures that have to be matched when the rule “fires”.
At first, there is theActstatement with which an agent can executeactions. In fact, this is the only option for an agent to influence its environment – namely through the effect of the executed actions in the sense of the situation calculus. However, the progression is not performed directly for each Actcall.
Instead, the current interpretation of the action term is added to the set of pending actions. At the same time, the process is suspended temporarily until the action has been handled.
Definition 3.23 (Action execution). Let α be an action term that possibly contains variables. Then, an action execution is interpreted as follows:
h{(pid, as,Act(α)◦σ, η)} ∪Prun, Pact, Pwait, Pidle, Act, Evt,F i −→
hPrun, Pact∪ {(pid, as, σ, η)}, Pwait, Pidle, Act∪ {JαKF,η}, Evt,F i (3.9)
Concordant with the postponed execution mentioned in the last definition, the system performs progression steps for the executed actions only when all active processes are currently blocked, i.e. they are either waiting or perform-ing actions. In this case, both pendperform-ing actions and events that are due for the current time step are performed in random order.
Definition 3.24 (Action progression). Let α and be ground terms that denote a valid concrete action or event, respectively. Furthermore, let t = time(S)be the current time andprogress(F, α)the fluent database that results from performing a progression step for action α to the fluent database in the current simulation step, F (see [Rei01, Chap. 9]). Then, the following rule describes the premise and effect of a progression step:
a) Actions:
h∅, Pact, Pwait, Pidle,{α} ∪Act, Evt,F i −→
h∅, Pact, Pwait, Pidle, Act, Evt,F0i (3.10)
whereF0=
(progress(F, α) if Jposs(α)KF
F otherwise
b) Events:
h∅, Pact, Pwait, Pidle, Act,{(, t)} ∪Evt,F i −→
h∅, Pact, Pwait, Pidle, Act, Evt,F0i (3.11)
whereF0 =
(progress(F, ) if Jposs()KF
F otherwise
After all currently scheduled agent actions have been performed, idle due processes are activated and blocked processes are reactivated. This first in-cludes all processes that are currently executing actions. Additionally, waiting and idle processes can be scheduled in this phase when the corresponding conditions are satisfied.
Definition 3.25 (Process activation). Let cond(p) denote a condition on which the process p is waiting after executing a Wait statement, and let trigger(p) be a condition that, if true, causes an idle triggered process to be executed in the current step. Similarly, letnextScheduleT ime(p) be a func-tion that yields the next time point when an idle periodic process is scheduled to be launched. Then, the following rule describes the activation of processes:
h∅, Pact, Pwait, Pidle,∅, Evt,F i −→ hPrun,∅, Pwait0 , Pidle0 ,∅, Evt,F i (3.12)
where Pw+ ={pw |pw ∈Pwait∧Jcond(pw)KF =>}
Pi+ ={pi |pi ∈Pidle∧(Jtrigger(pi)KF => ∨ JtimeKF =nextScheduleT ime(pi))}
Prun =Pact∪Pw+∪Pi+ Pwait0 =Pwait\Pw+
Pidle0 =Pidle\Pi+
In the definition above it can be seen that both processes that are idle and those that arewaiting can be reactivated. The waiting state is reached as an explicit consequence of aWait statement, which will be explained later in Definition 3.33. In contrast, a process becomesidlesimply when all statements of the process body have completed. This is expressed by the following rule.
Definition 3.26 (Process completion). Letpidbe the id of a running process that has completed its statement sequence in the current simulation step and let PBodypid be the body that is defined for the process in the agent behavior model. A process becomes idle when all statements of its body have completed, i.e.
h{(pid, as,∅, η)} ∪Prun, Pact, Pwait, Pidle, Act, Evt,F i −→
hPrun, Pact, Pwait,{(pid, as,PBodypid,∅)} ∪Pidle, Act, Evt,F i (3.13)
It was already mentioned before, e.g. in Section 3.4.2, that an event can be added to the event schedule either a) instantaneously, i.e. within the cur-rent simulation step, or b) anticipatory, i.e. at a time point in the future that is chosen according to a specific probability distribution. Instantaneous scheduling is used when a poss axiom but no schedulable axiom exists for the event type. Then, that poss axiom is tested for every time step and if it is found to be true, the occurrence distribution assigned to the event is used to decide whether or not the event should occur. For anticipatory scheduling, a schedulable axiom has to exist, which is also evaluated at each time step.
When this yields a positive result, it means that at this point it is possible to determine a point in the future at which the event should occur. This is done by sampling the delay until the occurrence of the event instance from the assigned occurrence distribution.
In general, scheduling is performed iteratively until no further events can be scheduled, although every concrete event instance can only be scheduled once. Additionally, there may be cases where there can be only one of a set of several events - i.e. they form an exogenous action choice (see Section 3.2.3).
Definition 3.27 (Event scheduling). Let be an event term, ∆T a random variable that models a delay for the event , and Occur a random variable that models whether should occur (Occur = 1) or not (Occur = 0) in the current simulation step. Furthermore, let the predicates schedulable() and poss() represent the tests of the schedulability and possibility axioms with the concrete event instancein the current simulation step. Whether an event is scheduled instantaneously or anticipatory in the sense explained above is de-termined by the functiontype(). Furthermore, the predicateexclusive(1, 2) indicates that two events are mutually exclusive as part of an exogenous ac-tion choice. Finally, the notation −→p is used to express that the given state transition occurs with probability p. Finally, as above,F is used to represent the fluent database in the current simulation step.
Given the definitions above, assume thatΦ0 and one of the two conditions Φ1 or Φ2 are satisfied:
Φ0 ≡(@t0.(, t0)∈Evt)∧(@t00@0. exclusive(, 0)∧(0, t00)∈Evt) Φ1 ≡type() =immediate∧Jposs()KF
Φ2 ≡type() =scheduled∧Jsched()KF
(3.14)
Then,
h∅, Pact, Pwait, Pidle, Act, Evt,F i−→p
h∅, Pact, Pwait, Pidle, Act,{(, t)} ∪Evt,F i (3.15) and
h∅, Pact, Pwait, Pidle, Act, Evt,F i−→1−p
h∅, Pact, Pwait, Pidle, Act, Evt,F i (3.16) where
p=
P r(Occur= 1) ift=JtimeKF ∧Φ1 P r(∆T=δt) ift=JtimeKF +δt∧Φ2
0 otherwise
(3.17)
When no agent processes can proceed any further and no more actions or events can be executed in the current simulation step, the system progresses to the next time point that is relevant either a) because an event is scheduled for this time, b) because a periodic process is scheduled to be executed, or c) because an event will become possible or schedulable at this time.
Definition 3.28(Time advance). LetF be the fluent database in the current simulation step and Scur the associated current situation. As usual in the situation calculus literature, S1 ⊂ S2 is used to express that situation S2 results from performing a sequence of actions in S1. Also, letEligibleEvent be aderived fluent that is defined as below:
EligibleEvent(, S)≡(type() =immediate∧poss(, S))
∨ (type() =scheduled∧sched(, S)) (3.18)
EligibleEventdetermines whether an event instance can happen in a given situation or be scheduled for later occurrence. Based on that,StepEndis true if no further processing is possible in the current simulation step.
StepEnd≡(@pw ∈Pwait.Jcond(pw)KS =>)
∧ (@pi∈Pidle.Jtrigger(pi)KS =>)
∧ @. EligibleEvent()
(3.19)
Furthermore, let tcur=JtimeKF be the time at the current time step and nextScheduleT ime(p)the next time at which a periodic processpis scheduled to be launched.
IfStepEndholds in the current system state, the following rule is applica-ble:
h∅,∅, Pwait, Pidle,∅, Evt,F i −→ if StepEnd=>
h∅,∅, Pwait, Pidle,∅, Evt,F0i (3.20) where F0 =progress(F, tick(tnext−tcur)) (3.21) tnext=min{tev, twait, tperiod, tscan} (3.22)
tev =min{t|(, t)∈Evt} (3.23)
twait=
(∞ if Pwait=∅
tcur+ 1 if Pwait6=∅ (3.24)
tperiod =min{t| ∃p∈Pidle. t=nextScheduleT ime(p)} (3.25) tscan=min{t| ∃S, . EligibleEvent(, S)∧ (3.26)
t=time(S)∧Scur ⊂S}
In the definition above, a situation calculus perspective was chosen to de-scribe the interpretation of fluents, preconditions, and schedulability predi-cates. In particular, this allows evaluating EligibleEvent for future steps that follow the current situation. In the calculation for tscan this is used to search for future situations in which any event becomes possible or schedula-ble. In fact, as mentioned earlier in Section 3.2, the use of effect axioms in the domain model allows the simulation algorithm to detect if a fluent instance is affected by the tick event. This can also be used to determine whether the formula in a poss or schedulable axiom is time-dependent. By excluding time-independent event instances from consideration in the scanning process, the algorithm can avoid unnecessary computation.
The definition oftwait in (3.24) effectively says that as soon as at least one process is in the waiting state, the next time step has to be visited, i.e. the
time cannot be advanced further thattcur+ 1. This is due to the fact that in general, the conditions of waiting processes could depend on events other than tick, whose occurrences cannot be predicted. However, as a future extension, it would be worthwhile to integrate a mechanism that recognizes conditions which only depend on time – similar to the mechanism that already exists for exogenous actions (events).
The most obvious effect of the progression step progress(F, tick(tnext − tcur)) is that the world time is advanced to the next “interesting” point for which an event or a process is scheduled. In fact, the time steps in between the current simulation step and this next one are not simulated explicitly.
Depending on the model, this can be much more efficient than approaches that are fixed to equidistant time steps. However, it is possible that the model contains effect axioms that make the eventtick(∆T) affect not onlytimebut also other fluents. In this case, it has to be guaranteed that progressing the model in one step totnext actually has the same effect as advancing every time step separately or as any other time partitioning scheme. This is expressed as a property that will be calledtime-advance stability in this thesis.
Definition 3.29 (Time-Advance-Stability). Let F(x1, . . . , xn, S) be a func-tional fluent and G(x1, . . . , xn, S) a relational fluent defined in the system domain model. Additionally, letS denote a situation term andAˆS = (ai,S)li=1 the action sequence that leads from the initial situationS0 toS. Furthermore, let Sta be defined as the set of possible situation terms that consist only of tick actions, i.e.
Sta={S| ∀i∈[1, l].∃t. ai,S=tick(t)} (3.27) Then F is calledtime-advance-stable if the following property holds:
∀S ∈ Sta.∀∆t∈N0.∀x1, . . . ,∀xn. time(S) =time(S0) + ∆t =⇒
F(x1, . . . , xn, S) =F(x1, . . . , xn, do(tick(∆t), S0)) Similarly,G istime-advance-stable iff
∀S ∈ Sta.∀∆t∈N0.∀x1, . . . ,∀xn. time(S) =time(S0) + ∆t =⇒
G(x1, . . . , xn, S)≡G(x1, . . . , xn, do(tick(∆t), S0))
Finally, a system model Sys is called time-advance-stable iff all fluents defined inSysare time-advance-stable.
Time-advance-stability requires that all fluents are defined in a way so that it does not matter whether the time is advanced by multiple tick-steps that add up to the intended delay, or whether this happens with a singletick-action.
This directly leads to the following theorem:
Theorem 3.1. Let Sys be simulation model and let F be the state of the fluent instance database in a simulation step of Sys. Let furthermore tnext and tcur be the times of the current and the next scheduled simulation step, respectively. Furthermore, let (δti)ni=1 denote a sequence of time differences and let F1 = F2 be an abbreviation for the fact that the value of each fluent instance in F1 is equal to the value of the corresponding fluent instance in F2. Finally, the progression operator is recursively lifted to the application of a sequence of time steps:
progress(F,(δti)1i=1) =progress(F, tick(δti))
progress(F,(δti)ni=1) =progress(progress(F,(δti)n−1i=1), tick(δtn))
Given the definitions above, it holds that ifSysis time-advance stable, then all possible sequences oftick actions that in sum lead to the same time advance have the same effect on the model, i.e.
∀∆T∀(δti)ni=1.
n
X
1
δti = ∆T =⇒
progress(F,(δti)ni=1) =progress(F, tick(∆T))
Proof. It is shown in [Rei01, Chap. 9.2.1] that for SALMA’s fluent database, which islogically complete in the sense that it stores concrete values for all flu-ent instances, a progression step can be realized by substitution with the right sides of the successor state axioms, i.e. by a one-step regression. In fact, this is exactly how progression is realized in the SALMA simulation engine. This implies that if S0 denotes the current situation, then the sequence (Si)1≤i≤n
can be defined recursively as follows:
Si =do(tick(δti), Si−1) (3.28) This means that the situationSn, which corresponds to the situation that results from performingprogress(F,(δti)ni=1), will have the following structure:
Sn=do(tick(δtn), do(tick(δtn−1), . . . do(tick(δt1), S0). . .) (3.29) Since Sn contains only tick actions, it belongs to the set Sta that was defined in Definition 3.28. Therefore, since the system model is time-advance stable, it holds for any functional fluent F and any relational fluentGthat
F(x1, . . . , xn, Sn) =F(x1, . . . , xn, do(tick(∆T), S0)) (3.30) G(x1, . . . , xn, Sn)≡G(x1, . . . , xn, do(tick(∆T), S0)) (3.31) By the definition of the progression operator from above, this implies
progress(F,(δti)ni=1) =progress(F, tick(∆T)) (3.32) Therefore, the theorem holds.