Configuration of Actions and Events

After the domain model has been loaded, all of its elements can be accessed via the world instance. In particular, it is necessary to configure probability distributions and selection strategies for the actions and events:

For exogenous actions, an occurrence distribution has to be specified whose meaning depends on the declaration of the event. If a schedulable axiom is defined for the exogenous action, the occurrence distribution has to be numeric. When an event instance is detected to be schedulable in a simulation step, then the occurrence distribution is used to sample a delay time after which the occurrence of the event instance will be scheduled. On the other hand, if only a precondition for the event is specified by means of a poss axiom, then the occurrence distribution has to be boolean. If the precondition is satisfied for a specific event instance in the current simulation step, the occurrence distribution is used to decide whether the event instance should occur in the same step. Additionally, as mentioned in Section 3.2.3, an exogenous action can also have probabilistic parameters, for which the modeler has to set up adequate probability distributions, too.

Forstochastic actions, aselection strategyhas to be defined which is used to choose one of the possibleoutcomeswhen the stochastic action is performed by an agent. Often such a distribution simply assigns a fixed probability to each outcome, although any type of categorical distribution with the right value range can be used. Additionally, the modeler has to specify how the parameters of the chosen outcome action are going to be filled. This can either be a direct mapping to a controlled parameter that is set when the agent executes the action, or it could itself be another probability distribution that is able to yield values of the correct type.

Exogenous action choices, i.e. sets of mutually exclusive events, require a selection strategy similar to stochastic actions, with the difference that the choices are exogenous actions. Each of these options have to be configured like any independent event as described above.

As a concrete example for the configuration of probability distributions and selection strategies, Figure 3.15 shows an excerpt of one version of the delivery robots example. First, a categorical selection strategy is chosen for the exogenous action choice step_finished, where the probabilities for the eventsstep_succeeded and step_failedare set to 0.8 and 0.2, respectively.

For both of these step options, a constant occurrence distribution with the parameter 1 is defined, which means that each movement will either succeed or fail after exactly one time step. For the stochastic action pickUp, the probability of a successful grab is set to 70% vs a 30% chance of dropping the item. The parameters r and i of both outcomes, which represent the robot and the item, are mapped to the correspondent parameters of pickUp. Furthermore, the model specifies a uniform distribution for thegripparameter that selects a value between 1 and 10 with the same probability. For both the two following exogenous actions accidental_drop and request, geometric distributions are defined, with a success probability of0.001for the accidental drop and0.01for a request by a workstation. Finally, for the collision event, for which apossbut noschedulable axiom exists in the model (cf. Figure 3.7), the occurrence distribution decides directly about the occurrence within the current simulation step.

All probability distributions used in the current example have in com-mon that they are defined using parameters that are fixed when the distribu-tion object is created during simuladistribu-tion setup. Although this is sufficient in many cases, often a distribution depends on the current situation. Therefore, the SALMA framework makes it easy to define custom probability distribu-tions by inheriting from the class Distribution and overriding the method generateSample or by using a special class CustomDistribution that dele-gates generation of a sample to a Python function. In both cases, the custom method or function receives the arguments that define the action or event in-stance and can access the full world state in order to derive a value. As an example, it could be reasonable to assume that the rate with which a worksta-tion sends out item requests is related to the current number of “open orders”,

defsetup_distributions(self):

step_finished = world.get_exogenous_action_choice("step_finished") step_finished.selection_strategy = Categorical(step_succeeded=0.8,

step_failed=0.2) stepdelay = ConstantDistribution("integer", 1)

world.get_exogenous_action(

"step_succeeded").config.occurrence_distribution = stepdelay world.get_exogenous_action(

"step_failed").config.occurrence_distribution = stepdelay pickup = world.get_stochastic_action("pickUp")

pickup.selection_strategy = Categorical(grab=0.7, drop=0.3) grab = pickup.outcome("grab")

grab.map_param("r", "r"), grab.map_param("i", "i") grab.uniform_param("grip", value_range=(1, 10)) drop = pickup.outcome("drop")

drop.map_param("r", "r"), drop.map_param("i", "i")

accidental_drop = world.get_exogenous_action("accidental_drop") accidental_drop.config.occurrence_distribution =

GeometricDistribution(0.001)

request_event = world.get_exogenous_action("request") request_event.config.occurrence_distribution =

GeometricDistribution(0.01)

collision_event = world.get_exogenous_action("collision")

collision_event.config.occurrence_distribution = BernoulliDistribution(1.0) collision_event.config.uniform_param("severity", value_range=(5, 10))

Figure 3.15: Definition of probability distributions for the delivery robots ex-ample.

i.e. requests for which no item has been delivered yet. If an item is interpreted as a resource that is needed at a workstation to perform some task, then it could be imagined that a workstation has a number N_slots of slots at which tasks can be performed in parallel. When the processes that happen at each slot are not modeled in more detail, it is a common choice to describe the times between requests at each slot by the same geometric distribution. However, if a request has been sent due to a current demand of a slot, this means that the slot will be waiting for the item to arrive and not issue any further requests in the meantime. Therefore, the total inter-arrival times for a workstationws can be modeled by a geometric distribution that depends on the number of free slotsNf ree(ws):

P(T =t)∼Geom(ptot(ws)) (3.1)

where

p_tot(ws) = 1−(1−p_slot)^{Nf ree(ws)}

Here, p_slot is the parameter for each slot and N_{f ree}(ws) is the number of slots ofwsthat are not currently waiting for the delivery of a requested item.

This can be seen whenptot(ws) is understood as the probability that at least one free slot ofwsissues a request at a given step. Since the model guarantees that every request will remain in the coordinator’s queue until it is assigned to a robot, the number of free slots can be derived as follows:

N_{f ree}(ws) =N_slots−card({robots delivering tows}) (3.2)

−card({entries in request queue from ws})

Figure 3.16 shows how this probability distribution is realized by means of a short Python functionrequest_distrib that is installed for the request event via a CustomDistribution object. This function is called each time the simulation algorithm has chosen an instance of the event request for which the corresponding schedulable axiom was true. The workstation, the coordinator, and the world’s rootevaluation context are passed to the function via the parameters ws, c, and ctx, respectively. Using these arguments, the function first uses the method count of Python’slisttype to count the number of times the workstation appears in the request queue of the coordinator.

Then it iterates over all existing robots, i.e. the domain of the sort robot and counts the number of robots that are currently assigned to deliver an item to the workstation. With these numbers and the constantsN_SLOTS and P_SLOT, the parameter p_totis calculated as explained above and a sample from the corresponding geometric distribution is returned, which will be used to schedule the next occurrence for the event instancerequest(ws, c).

defrequest_distrib(ws, c, ctx: EvaluationContext=None, **kwargs):

ws_in_queue = c.request_queue.count(ws) assigned_robots = 0

forrinctx.getDomain("robot"):

ifr.task_workstation == ws:

assigned_robots += 1

n_free = N_SLOTS - assigned_robots - ws_in_queue p_tot = 1 - (1 - P_SLOT)**n_free

returnNoneifp_tot == 0elsenp.random.geometric(p_tot) . . .

request_event.config.occurrence_distribution = CustomDistribution(

"integer", request_distrib)

Figure 3.16: Alternative custom distribution for the occurrence of item re-quests.

Altogether, it is obvious that the choice of probability distributions and outcome selection strategies plays an important role in the model. By the abil-ity to integrate custom Python code, SALMA achieves a high level of flexibilabil-ity that allows tackling even complex scenarios with much detail. Due to the im-portant role of probability distribution definitions within the model, SALMA puts considerable effort into achieving a tight integration of the SALMA do-main and behavior models into the Python environment in order to achieve conciseness and high readability. One of the facilities that serve this purpose is the event and action configuration API used in Figure 3.15. However, the most important facet of language integration is the fact that SALMA makes fluent and constant instances accessible in an object-oriented manner. This could already be seen, e.g., in the function request_distrib in Figure 3.16 and Section 3.4.5 will explore this topic a bit further. Before that, however, the remaining steps in configuring the simulation are taken, namely the pop-ulation of the world’s state at the simpop-ulation start and the definition of the concrete experiment.

3.4.3 Creating Entities, Agents, and the Initial Situation