7.3 ManeuverGroups, Events and Maneuvers

A maneuver group singles out the instances of Entity that may be actuated, or referenced to, by the maneuvers in that group. These instances of Entity are grouped and referred to as the Actors, because they play a role in the maneuvers to come. The Actors group may be left empty. This is allowed for situations where the maneuvers in a maneuver group lead to actions that are not related to instances of Entity, but instead world or simulation states.

An actor is defined using the EntityRef element. This element is then combined in an unbounded list to specify actors for a given maneuver group. A list of Actor instances may contain several instantiations of the type EntityRef. Additionally, extra instances of Entity may be added to the list, at trigger time, if the selectTriggeringEntities option is active.

The EntityRef element explicitly couples an existing entity to an actor in the maneuver group. This is achieved by specifying the name of the desired entity in the element. EntityRef is used when the entity of interest is known when the scenario is defined.

The selectTriggeringEntities property may be used when the choice of actors depends on runtime information and cannot be made at scenario definition time. When the selectTriggeringEntities property is true, entities become actors if they fulfill the following criteria:

Only condition groups that are relevant for determining which instances of Entity are added to the actors are located in the parent Act of the maneuver groups. The maneuver group inherits the start trigger from its parent act.

EntityRef may be combined with selectTriggeringEntities set to true. In this case, the resulting actors are the union of the two.

Finally, a ManeuverGroup instance is defined with a maximumExecutionCount. This setting specifies how many times the maneuver group runs, and is explained in Section 8.4.4, "Execution of a ManeuverGroup".

Actions are singular elements that may need to be combined to create meaningful behavior in a scenario. This behavior is created by the type Event which serves as a container for actions. Events also incorporate start triggers. The event start trigger determines when the event starts and when the actions contained in the event, start.

Actions shall always be wrapped by events with only one exception: In the InitActions class, where actions are declared individually.

The maximumExecutionCount setting specifies how many times an event is supposed to run. Interpretation of this parameter in runtime is explained in Section 8.4.2, "Execution of an event" .

An event is also parameterized with a definition of priority relatively to events that coexist in the same scope, i.e. maneuver. Whenever an event is started, the Priority parameter is taken into consideration to determine what happens to already ongoing events in the same maneuver. The three choices of the Priority parameter are:

Refer to Section 8.4.2.2, "Event priority" for the runtime interpretation of the Priority parameter.

Each event defined in a scenario corresponds to a single runtime instantiation which implies that there shall not be multiple instantiations of the same event running simultaneously. This also means that start triggers only make sense for events in standbyState, as opposed to each start trigger starting a new instantiation of the event.

A maneuver groups events creating a scope where the events can interact with each other using the event priority rules. The definition of a maneuver may be outsourced to a catalog and parameterized for easy reuse in a variety of scenarios.