Action Precondition and Schedulability Axioms

As mentioned before, the SALMA runtime automatically translates effect axioms into successor state axioms in the form that was introduced in Sec-tion 2.2. In fact, during the model initializaSec-tion phase, a new dynamicfluent clause is added to the Prolog clause database which combines all effect ax-ioms for the fluent and adds a default case that returns the original value for any action term that is not covered by the effect axioms. The clause for a fluentf with parametersx₁, . . . , x_nwill have the form f(x₁, . . . , x_n, S):-Γ. for a boolean (i.e. relational) fluent and f(x1, . . . , xn, V, S):-Γ. for a functional fluent, where S is the situation variable and V will be bound to the value of the fluent instance.

Besides regular fluents, whose contents are updated in each step according to the effect axioms, a model can also containderived fluents whose values are calculated based on the values of others. Hence, derived fluents are just situa-tion dependent funcsitua-tions and predicates that are specified like normal Prolog predicates. In fact, for each derived fluent declarationderived fluent(f,[x1 : t₁, . . . , x_n:t_n], t_f)., the modeler has to add a Prolog clause with a signature of the formf(X₁, . . . , X_n, V, S) or f(X₁, . . . , X_n, S) whereX₁, . . . X_n are Prolog variables that represent the derived fluents parameters,V a variable that will be bound to the return value, and S a variable that will contain the current situation when the derived fluent is evaluated. For a boolean (i.e. relational) derived fluent, the return value is not needed, so the second form is used. Both forms can be seen in Figure 3.6 that shows the derived fluents for the running example. Most of these definitions are quite self-explanatory. The clause for dist_from_stationcalculates the Manhattan distance (see [Bla06]) between a robot and a workstation, which is used because robots can only move in strictly horizontal or vertical steps. The predicate unassigned is simply a check that next_task contains none for a given robot, and moving checks whether the absolute value of a robot’s velocity is higher than0. Additionally, the predicate ready is used as a shortcut to check whether the robot is ready for the next step, which requires it to be functional and not moving. Another shortcut isundelivered, which will be used by the coordinator’s control proce-dure to select items that neither have already been delivered nor are currently scheduled to be delivered to a workstation. Finally, the two derived fluents task_itemandtask_workstationextract the item and the workstation from an assignment term. As will be shown in Section 3.3, this is helpful for the definition of control procedures because it avoids having to deal with Prolog terms within Python.

dist_from_station(Rob, Station, Dist, S) :-xpos(Rob, X, S),

ypos(Rob, Y, S),

stationX(Station, Sx), stationY(Station, Sy), Dist is abs(X - Sx) + abs(Y - Sy).

unassigned(Rob, S)

:-next_task(Rob, none, S).

moving(Rob, S)

:-vx(Rob, Vx, S), abs(Vx) > 0, !

;

vy(Rob, Vy, S), abs(Vy) > 0.

ready(Rob, S)

:-not moving(Rob, S), :-not broken(Rob, S).

undelivered(Item, S)

:-delivered_to(Item, none, S), domain(robot, Robots, S),

not (member(R, Robots), next_task(R, d(Item, _), S)).

task_item(Rob, Item, S) :-next_task(Rob, Task, S), Task = d(Item, _), !

;

Item = none.

task_workstation(Rob, Ws, S) :-next_task(Rob, Task, S), Task = d(_, Ws), !

;

Ws = none.

Figure 3.6: Derived fluents in the multi-robot example.

clauses.

Definition 3.8 (Action Precondition Axioms). The syntax of an action pre-condition axiom is given by the following EBNF-rule:

PossAxiom = "poss" "(" ActionTerm "," Variable ")" [ PossAxiomBody ] "." ; ActionTerm = Variable | ActionName ["(" Term {"," Term } ")"] ;

PossAxiomBody = ":" "-"? ARBITRARY VALID PROLOG SOURCE CODE ?; Here, the action term before the comma will be unified with the action term that is about to be applied in progression. In fact, SALMA’s progression algorithm will only perform the progression of an action term if apossaxiom clause exists where the action term is unifiable and the axiom clause evaluates to true. The second parameter of thepossaxiom contains a variable that will be bound to the current situation when the axiom is evaluated.

One subtle question about action precondition axioms is what should actu-ally happen when an agent attempts to perform an action that is not possible in this situation. For the original use of the situation calculus, the fact whether an action is executable plays an important role in proofs or in planning. In sim-ulation, however, the systemcommits itself to performing an action, i.e. there is no possibility of backtracking as in planning. One possible rather intuitive reaction to the attempt of performing an impossible action would be toblock the execution of the performing agent process until the action becomes possible again. However, this would actually establish a kind of implicit synchroniza-tion mechanism that might not be adequate for every model. Therefore, the SALMA simulation engine by default treats the attempt of performing an im-possible action as an error and cancels the simulation run. This forces the modeler to include explicit tests into the agent control procedures that make sure an action is only performed when its precondition is satisfied. Although this makes the behavioral model more verbose than in other approaches like GoLog, it actually fits well to SALMA’s understanding that aspects like the possibility of a violated precondition are exactly what should be represented within the simulated model.

Yet another perspective on preconditions exists in the context of exogenous action (events). There, theposs-axioms are used by the simulation engine to select event instances that may occur in the current simulation step. As indi-cated in Section 2.3, this corresponds to what is usually calledactivity scan-ning, which is one possible strategy for discrete event simulations. However, in many cases, this mechanism is inefficient because aspects of the world state that are relevant for the precondition can only change at certain distinct times.

For these cases, it is better to use an event scheduling mechanism where the time when an event instance should occur is determined in advance. For this purpose, SALMA introducesschedulability axioms that determine whether it

is possible in the current simulation step to decideat which point in the future an event instance should occur. The syntax of such a statement is similar to the classical action precondition.

Definition 3.9(Schedulability Axioms). The syntax of a schedulability axiom is given by the following EBNF-rule:

SchedAxiom = "schedulable" "(" ActionTerm "," Variable ")"

[ PossAxiomBody ] "." ; ActionTerm = Variable | ActionName ["(" Term {"," Term } ")"] ;

PossAxiomBody = ":" "-"? ARBITRARY VALID PROLOG SOURCE CODE ?; Like before, the action term in the axiom will be unified with an action term, in this case that of an exogenous action instance or with an instance of an exogenous action choice. Only if there is a schedulability axiom clause that evaluates to true, an event instance may be scheduled at a time that is determined by the occurrence probability distribution of the event (see Sec-tion 3.4.2). For exogenous acSec-tion choices, a schedulable axiom may only be specified for the choice group itself but not for the events declared as mutually exclusive outcomes.

The action precondition and schedulability axioms for the robotics example are shown in Figure 3.7. At first, the movement actions are set to be only possible if the robot is not broken. A slightly more complex condition is needed forpickUp: first of all, the robot has to be at the same grid position as the item.

Besides that, it can only grab an item that is not currently being carried by any other robot. The outcomes forpickUpadd no further requirement, so they are declared to be possible anytime by setting the body of the correspondingposs -axioms to true. The same is done for the actionsrequest andassign_task, which effectively implies the tolerable simplifications that the coordinator’s request message queue is unbounded and assignments could be changed at any time. On the other hand, in order to deliver an item, a robot must not be broken, must be carrying the item, and has to be at the same grid cell as the target workstation.

The preconditions for these actions that are actively performed by robots are followed by two furtherposs-axioms for the eventscollision and accidental_drop. While for accidental_drop, the condition is again simply that the item is actually carried by the robot, formulating the precondition for the collision event requires more thought. One obvious condition is that two robots are close enough to each other, which comes down to being at the same grid location in the model of the ongoing example. This constraint is added as a simple coordinate comparison. However, this constraint would always be satisfied when both variablesR1andR2point to the same robot, and therefore this case is excluded explicitly by the constraintR1 \= R2(where\=is Prolog’s

poss(move_right(R), S) :- not broken(R,S).

. . . same for other move-actions poss(pickUp(R, I), S)

:-not broken(R, S),

xpos(R, Xr, S), xpos(I, Xi, S), Xr =:= Xi, ypos(R, Yr, S), ypos(I, Yi, S), Yr =:= Yi, domain(robot, Robots),

not (member(R2, Robots), carrying(R2, I, S)).

poss(grab(_, _, _), _) :- true.

poss(drop(_, _), _) :- true.

poss(request(_, _), _) :- true.

poss(assign_task(_, _, _, _), _) :- true.

poss(deliver(R, I, Station), S)

:-not broken(R, S), carrying(R, I, S),

xpos(R, Xr, S), stationX(Station, Xs), Xr =:= Xs, ypos(R, Yr, S), stationY(Station, Ys), Yr =:= Ys.

poss(accidental_drop(R,I), S) :- carrying(R,I,S).

poss(collision(R1, R2, _), S) :-R1 \= R2,

xpos(R1, X1, S), xpos(R2, X2, S), X1 =:= X2, ypos(R1, Y1, S), ypos(R2, Y2, S), Y1 =:= Y2, (moving(R2, S), ! ; moving(R2, S)).

schedulable(step_finished(Rob), S) :-moving(Rob, S).

schedulable(accidental_drop(R,I), S) :-action_occurred(grab(R,I), S).

schedulable(request(_, _), _) :- true.

Figure 3.7: Action precondition and schedulability axioms in the multi-robot example.

syntax for6=). As a last condition, the axiom also states that a collision occurs only if at least one of the robots is moving.

On closer inspection, there is an important difference between the event collision and the other events in the model with respect to the way the simulation determines their occurrence times. Actually, in order to decide if a collision between two robots can occur within a certain time interval, the

simulation system has to evaluate the poss-axiom for each step because the coordinates of the robots may be different each time. In contrast to that, the occurrence time for an accidental drop event can be chosen in advance as soon as the item is grabbed. In other words, the event can be scheduled for a future point in time that is, for instance, determined by sampling from a geometric probability distribution. For cases like that, a schedulability ax-iom is required that specifies under which conditions it is possible to decide whether an event should occur and, if necessary, calculate the occurrence time.

Therefore, the schedulability axiom for accidental_drop uses the predefined predicate action_occurred to assert that a grab action has occurred in the current step. Similarly, the axiom for the event choice group step_finished states that the end of a movement, i.e. one of the eventsstep_succeeded and step_failed, can be scheduled right from its start, which is detected by the derived fluent moving. This makes it possible to model various forms of un-certainty with respect to the robots’ motion by choosing adequate probability distributions for the delay of the step_succeeded and step_failed events.

Finally, the last axiom in Figure 3.7 makes the request event schedulable at any time, which means that the arrival times of new requests will be deter-mined solely by the probability distribution that is assigned for the event.