Actions and Events

Like Reiter [Rei01], SALMA distinguishes three basic types of actions, namely 1) deterministic, so calledprimitive actions ; 2) stochastic actions, i.e. actions with a random outcome ; and 3) exogenous actions aka events. As with fluents, SALMA requires actions and events to be declared explicitly.

Definition 3.6(Action and Event Declarations). The following grammar rules describe the syntax of action declarations in the SALMA-DDL:

ActionDecl = "primitive_action" "("ActionName","ParamList")" "." |

"stochastic_action" "("ActionName","ParamList","OutcomeList")" "." ; EventDecl=ExogenousAtionDecl|ExogenousActionChoiceDecl;

ExogenousAtionDecl= "exogenous_action" "("ActionName","

ParamList","ParamList")" "." ;

ExogenousActionChoiceDecl= "exogenous_action_choice" "("ActionName","

ParamList","OutcomeList")" "." ; ActionName=Identifier ;

OutcomeList= "["ActionName","ActionName"]" ;

Here, primitive action(A,[x₁ : t₁, . . . , x_n : t_n], t_A) declares a determin-istic action that can be performed intentionally by an agent. All parameters x1, . . . , xn are set by the acting agent to concretize the intended effect. The parameter types are not restricted in any way. i.e. both entity sorts and any primitive type can be used. The second action declaration statement, stochastic actiondeclares an action together with a list of possibleoutcomes, i.e. a list of action names that have to refer to primitive actions declared in the same model. The choice between these outcomes is made by the simulation according to some probability distribution that is defined by the modeler (see below).

In contrast to primitive and stochastic actions, the statement

exogenous action(E,[x1 : t1, . . . , xm : tm],[xm+1 : tm+1, . . . , xn : tn]) de-clares E as a type of exogenous action, i.e. an event that originates from the environment instead of an agent. Concrete event instances are formed by combinations of values for the parameters that are declared inside the first parameter list (x₁, . . . , x_m). Just like in the case of fluent instances, the types of these ‘identifying’ parameters have to be finite entity sorts. The parameters declared in the second list, xm+1, . . . , xn, convey information that augment the event instance and are not subject to any type restrictions. In some cases, several events are actuallymutually exclusive, i.e. only one of them can hap-pen in a given situation. To model this fact, an exogenous action choice declaration can be used that groups a list of exogenous actions with the same identifying parameter. The simulation will later pick only one of the speci-fied events when the common precondition of theexogenous action choice is fulfilled (see Section 3.2.5).

Although the use of actions in agent processes and domain axioms is dis-cussed in detail within later sections, it is useful right away to clarify how the

concreteaction terms are formed that determine the state changes within the system. For primitive actions, the answer is simple: the action term is exactly what is issued by the agent in the Act statement within the agent procedure (see Section 3.3.2).

For stochastic actions, the situation is different. Although the agent per-forms the action that is declared in the stochastic action statement, the resulting action term depends on the outcome that is chosen probabilistically by the simulation engine. Each of the possible outcomes that are mentioned in the declaration of the stochastic action has to be declared as a primitive ac-tion itself. Since both the stochastic acac-tion and the primitive acac-tion outcomes could be declared with parameters, the modeler has to specify amapping from the parameters of the stochastic action, which the agent actually sets when it performs the action, to parameters of the outcome action. This is done with the SALMA experiment configuration API, which is described in Section 3.4.2.

Another use of the same API is the configuration of probability distributions for exogenous actions (events). Without going into details now, the simulation selects theevent instances that should occur at a specific point in time accord-ing to a set of axioms and probability distributions. To make this possible, each event instance has to be identified by the values for the parameters of the first parameter list in the declaration. Once an event instance has been chosen to occur, the engine chooses values for the parameters of the second list according to additional distributions that are allowed to produce values of any type. For example, this mechanism is used for information transfer processes in SALMA to introduce random errors (see Chapter 6). It is impor-tant to note, however, that in the final action term that represents the event within the situation calculus, the parameters from both lists appear in one flat sequence just like for regular actions.

For the robotics example, the model is extended with the actions shown in Figure 3.4. The four move actions will be used within a robot control process to initiate a movement to the adjacent grid cell in one of the four main directions.

A movement step does not happen instantaneously but is instead an activity that is started by a move action and ended by either a step_succeeded or a step_failedevent. Both of these concrete outcomes are declared as exogenous actions with a single parameter that identifies the robot. However, since the movement step can either fail or succeed but not both, they are declared as mutually exclusive by means of an exogenous_action_choice.

Another related exogenous action iscollision, which can happen between two robots. The integer parameter severity, which is declared in the second parameter list, will convey a random value for each event instance that will later be used to decide whether the robots are damaged during the collision.

The stochastic action pickUprepresents the attempt of a robot to pick up an item. The model acknowledges that this might fail and therefore specifies both a positive outcome, graband a negative one,drop, which means that the item slips and the robot cannot get a grip on it. In fact, the graboutcome also has

primitive_action(move_right,[r:robot]).

primitive_action(move_left, [r:robot]).

primitive_action(move_down, [r:robot]).

primitive_action(move_up, [r:robot]).

exogenous_action(step_succeeded, [r:robot], []).

exogenous_action(step_failed, [r:robot], []).

exogenous_action_choice(step_finished, [r:robot],

[step_succeeded, step_failed]).

exogenous_action(collision, [r1:robot, r2:robot], [severity:integer]).

stochastic_action(pickUp, [r:robot, i:item], [grab, drop]).

primitive_action(grab, [r:robot, i:item, grip:integer]).

primitive_action(drop, [r:robot, i:item]).

exogenous_action(accidental_drop, [r:robot, i:item], []).

exogenous_action(request, [ws:workstation, c:coordinator], []).

primitive_action(assign_task, [c:coordinator, r:robot, i:item, ws:workstation]).

Figure 3.4: Action and event declarations for the multi-robot example.

a parametergripthat could reflect the grip quality. For parameters like that, which are not directly mappable to arguments of the action execution like r andi, the modeler has to specify a probability distribution from which a value is chosen when the action is performed (see Section 3.4.2). Besides the item being dropped during a pick-up attempt, it could also happen that the robot drops an item during its journey to the workstation, which is modeled by the exogenous actionaccidental_drop. It is clear that the selection of the proba-bility distributions that determine the grip quality and whether an accidental drop occurs obviously affects the outcome of the simulation significantly. In fact, Section 4.3 will come back to this topic and demonstrate how a physical aspect like grip quality can be reflected by a distribution foraccidental_drop that is conditioned on the grip quality. The last two actions in Figure 3.4 are used to handle the coordination of tasks. Here, the request of a workstation is modeled as an exogenous action rather than a primitive, aka intentional, action. This implies what could also be seen in the sort declaration, namely that workstations are not modeled as active agents in the example, but as passive entities without own behavior. On the other hand, the assignment of a task is clearly intentional and therefore added as a primitive action that is performed by the coordination agent.

At this point, all assets of the system, i.e. sorts, fluents, actions, and events, have been declared. The next step towards a full domain specification

is to add axioms that describe how the values of fluents come about.