7.5 Actions at runtime

7.5.1 Conflicting actions

At runtime, it may occur that coexisting actions end up competing for the same resource thus creating a conflict. A typical example: An action that controls an entity’s speed clashes with a newly triggered action that tries to control the speed of the same entity.

When an action acts on an entity selection and there is a conflict for one entity, all other instances of Entity within the selection are also treated as being in conflict. Actions are treated as conflicting if they are competing for control of the same domain in the same resource. For example, a SpeedAction always conflicts with any other SpeedAction if both target the same entity. Conflicts of actions of different types depend on how the actions relate to each other and need to be identified in a case-by-case basis. Table 7 and Table 8 depict the possible runtime conflicts between actions of different types.

If it is determined that a newly triggered action conflicts with a currently ongoing action, the latter is overridden. Overriding a running action is equivalent to issuing a stop trigger to that action, see Section 7.6, "Conditions and triggers".

7.5.2 Completing an action

For synchronizing the forked and nested execution paths of instances of storyboard elements, such as Story, Act, ManeuverGroup, Maneuver, Event, it is necessary to determine how an action is completed.

Private actions that assign control strategies are complete when the goal prescribed by the control strategy is reached. Enforcing a control strategy is done over time and, actions that assign control strategies take simulation time to complete.

All actions that do not assign control strategies are completed immediately. These actions transition from runningState to completeState, when instantiated, because the tasks associated to such actions are performed instantaneously.

The end criteria for actions are depicted in Table 7, Table 8, and Table 9.

7.5.2.1 Completing a private action

A private actions may be completed as follows:

Regular ending: A regular ending implies endTransition from the runningState to the completeState. An action ends regularly when its goal is accomplished, for example, an instance of a SpeedAction ends when the speed is reached. An action ends regularly if its goal is accomplished upon the start of the action, for example, the entity is traveling at the desired speed when an instance of a SpeedAction starts. The end criteria are depicted in Table 7.
Override by another Action: A private action that defines a control strategy on a specific domain of an entity is overridden by another action that defines a control strategy on the same domain of the same entity. The overridden action moves to the completeState with a stopTransition. For example, an instance of FollowTrajectoryAction overrides an instance of LaneChangeAction on an entity. The LaneChangeAction instance is stopped.
Override by Event: An event which is stopped is forced to stop all actions in its scope. The concerned actions move to the completeState with a stopTransition. To understand how an event can be stopped, see Section 7.3.2, "Events".
StopTrigger: A StopTrigger instance originating from the a storyboard or the action’s parent act. The action moves to the completeState with a stopTransition.
Missing prerequisites: The prerequisites for running an action are not fulfilled either during execution of the action or when the action starts. The action moves to the completeState with a stopTransition. For example, if the referenced entity of an instance of a LongitudinalDistanceAction disappears, or a private action is instantiated with no actors, the action is considered to be missing prerequisites.

7.5.2.2 Action prerequisites

Missing prerequisites are one reason why actions may be stopped. Prerequisites are specific to the action type and are the components or information required for the action to run. An action that is missing prerequisites, at start or during execution, is supposed to move to the completeState with a stopTransition. For example, an instance of a LaneChangeAction has these prerequisites: an existing lane and an entity to change lane with.

Executing actions depends on the robustness of the simulation engine and on the legitimacy of the OSC Model Instance. The ASAM OpenSCENARIO format specifies how actions work and how they interact with each other - it cannot and does not classify a OSC Model Instance as wrong or right, appropriate or not appropriate. In ASAM OpenSCENARIO, the only indicator that an action could not be completed regularly, is the 'stop' transition that is taken while entering the completeState. It is up to the implementation of the simulator to warn the users about potential unintended behavior, for example, teleporting a non-existing entity, assigning conflicting control strategies simultaneously, or referencing unintended entities.

PrivateAction
A general prerequisite for private actions is that the actor is a valid entity.
- LongitudinalAction
  - SpeedAction
    If followingMode is follow, then the target speed must be equal or less than the maxSpeed defined in the Performance of the actor.
  - LongitudinalDistanceAction
    Referenced entity exists. Referenced entity is on the route of the actor.
- LateralAction
  - LaneChangeAction
    Target lane exists.
  - LaneOffsetAction
    Target lane exists.
  - LateralDistanceAction
    Referenced entity exists.
- SynchronizeAction
  Referenced master entity exists.
  finalSpeed is equal or less than the maxSpeed defined in the Performance of the actor.
  The referred positions are valid reachable positions on a road.
- ControllerAction
  - OverrideControllerValueAction
    At least one movement Controller exists for this actor.
  - ActivateControllerAction
    Referenced Controller exists.
    Referenced Controller is defined for the domains which shall be activated.
  - AssignControllerAction
    Referenced Controller exists.
- RoutingAction
  - AssignRouteAction
    CatalogReference exists.
    Waypoint instances are valid positions on roads.
  - FollowTrajectoryAction
    CatalogReference exists and is on roads.
  - AcquirePositionAction
    Position is on a road.
- AppearanceAction
  - AnimationAction
    AnimationType exists.
  - LightStateAction
    VehicleLightType exists.
- TrailerAction
  - ConnectTrailerAction
    Referenced entity exists, is a vehicle and has a TrailerCoupler.
  - DisconnectTrailerAction
    Actor is a vehicle with a TrailerHitch.
GlobalAction
- EntityAction
  - AddEntityAction
    Entity with this name reference has not been added yet.
  - DeleteEntityAction
    Entity with this name reference has not been deleted yet.
- VariableAction
  - VariableSetAction
    Referenced variable exists.
  - VariableModifyAction
    Referenced variable exists.
- InfrastructureAction
  - TrafficSignalControllerAction
    Referenced controller is defined in scenario.
  - TrafficSignalStateAction
    Referenced traffic signal is defined in road network file.
- SetMonitorAction
  Referenced monitor exists.
- TrafficAction
  - TrafficSourceAction
    Position is valid.
  - TrafficSinkAction
    Position is valid.
  - TrafficSwarmAction
    Semi-major and semi-minor axis are greater or equal to inner radius. CentralSwarmObject is an existing entity.
  - TrafficAreaAction
    Position in Polygon is valid.
    RoadCursor is defined with existing road, lane and s-coordinate. ScenarioObjectTemplate references existing CatalogReference.
  - TrafficStopAction
    Referenced TrafficAction exists.

7.5.3 Continuous actions

Some private actions lack a regular ending by design. Their underlying control strategy pursues a permanent goal that is supposed to be continuously tracked over time. These private actions are often referred to as never-ending actions or continuous actions.

Private action types like LongitudinalDistanceAction, LateralDistanceAction, LaneOffsetAction, and SpeedAction forfeit a regular ending when a scenario designer sets the continuous flag to true. This also applies to AnimationStateAction with flag loop set to true and LightStateAction with LightMode set to flashing. These are the only cases of never-ending actions.

All action ends described in Section 7.5.2.1, “Completing a private action” are applicable to never-ending actions, with the exception of the regular end.

7.5.4 Acting on multiple entities - bulk action

Private actions may have to control more than one entity at a time. This occurs when the actors resolve to multiple instances of an entity or an entity selection, in a maneuver group. In this case, all concerned instances of an Entity shall be actuated simultaneously when the action starts. An action that acts on multiple entities is called a Bulk Action. For more details on the behavior of Bulk Actions in runtime, see Section 8.3.3.3, "Bulk action execution".

Actions acting on entity selections shall only be considered complete if all instances of entity in the selection have completed the tasks specified in the action. For example, an instance of a SpeedAction acting on five instances of Entity is only complete when all five instances of Entity have reached the desired speed, regardless of the fact that some of them may reach that speed earlier than others.

If any of the corresponding instances of Entity sparks a conflict with a newly started action, then the running action is overridden. All its instances of Entity are supposed to fall back to default behavior simultaneously. For example, consider two instances of type SpeedAction, named A and B. Action A is active and controls five entities. Then action B starts, aiming to control one entity of action A. Because the actions are of the same nature, a conflict occurs and action A is overridden. As a result, action B resumes control of the conflicting entity, while the remaining entities from the late action A engage in default behavior.