ASAM OpenSCENARIO: User Guide

A scenario is a description of how the view of the world changes with time, usually from a specific perspective. In the context of vehicles and driving, this encompasses the developing view of both world-fixed (static) elements, such as road layout and road furniture, and world-changing (dynamic) elements, such as weather and lighting, vehicles, objects, people, and traffic light states. This description is independent of whether the environment is simulated, real, or any combination thereof.

In a simulation context, a complete scenario is comprised of the following parts:

ASAM OpenSCENARIO defines a data model and a derived file format for the description of scenarios used in driving and traffic simulators, as well as in automotive virtual development, testing, and validation. The primary use case of ASAM OpenSCENARIO is to describe complex, synchronized maneuvers that involve multiple entities, like vehicles, pedestrians, and other traffic participants. The description of a scenario may be based on driver actions, for example, performing a lane change, or on trajectories, for example, derived from a recorded driving maneuver. The standard provides the description methodology for scenarios by defining hierarchical elements, from which scenarios, their attributes, and relations are constructed. This methodology comprises:

Other content, such as the description of the ego vehicle, entity appearance, pedestrians, traffic and environment conditions, is included in the standard as well.

Scenario descriptions in ASAM OpenSCENARIO are organized in a hierarchical structure and serialized in an XML file format with the file extension .xosc.

ASAM OpenSCENARIO defines the dynamic content of the (simulated) world, for example, the behavior of traffic participants. Static components, such as the road network, are not part of ASAM OpenSCENARIO but can be referenced by the format.

ASAM OpenSCENARIO does not specify the behavior models themselves or their handling by a simulation engine.

Furthermore, beyond the scenario itself, other pieces of information are needed to describe a full simulation setup and test case. ASAM OpenSCENARIO cannot be regarded as a complete specification of a simulator, its system under test or, its test case. The following features specifically are not considered in scope for ASAM OpenSCENARIO:

This User Guide uses a standard information structure. The following rules apply regarding normativity of sections:

Elements in scenario descriptions may be referenced from other parts of the description through their names. To ensure that all references can be unambiguously resolved, the following set of rules apply for references to scenario elements:

All numeric values within this standard are using SI units, unless explicitly stated otherwise. Table 2 presents details of the used units.

ASAM OpenSCENARIO uses the XSD 1.0 data types [3] string, Boolean, dateTime, double, int, unsignedInt and unsignedShort.

In ASAM OpenSCENARIO, the usage of date and time is restricted to the ISO 8601 [4] Basic Notation. The following format pattern is used: "yyyy-MM-dd 'T' HH:mm:ss '.' FFFZ". Here 'T' is again used as time designator and '.' is used as separator for the following millisecond portion. An explanation is given in Table 3.

At a given date and time of 2011-03-10 11:23:56 in the Central European Time zone (CET), the following standard-format output is produced:

2011-03-10T11:23:56.000+0100

To ensure compliance with the other OpenX standards, users must be able to distinguish between mandatory requirements, recommendations, permissions, as well as possibilities, capabilities, obligations, and necessities.

The following rules for using modal verbs apply:

This documentation uses the following typographical conventions:

The ASAM OpenSCENARIO architecture contains the following basic components:

Figure 2 illustrates how the components interact:

OSC Director and Simulator Core both manage the lifecycle of elements within their respective scope. An element is an object instance that exists either in the OSC Director or in the Simulator Core and may change its state during the execution of a scenario. ASAM OpenSCENARIO clearly states which elements shall be encapsulated in an OSC Director and which elements are managed by a Simulator Core.

Executing a scenario synchronizes the state of the elements in the OSC Director with the state of the elements in the Simulator Core.

The OSC Director interprets the OSC Model Instance at runtime, which translates in commands to the Simulator Core. The Simulator Core handles its elements, whose states are used by the OSC Director, to guide the developing scenario in the directions prescribed by the OSC Model Instance.

As an example, the SpeedCondition can be used via its application in a startTrigger to couple the speed of an entity managed by the Simulator Core to the start of an event that is managed by the OSC Director.

Actions and Conditions are abstract concepts that enable an OSC Director to interact with the Simulator Core and thus manage the ongoing simulation in accordance with the OSC Model Instance. Actions are used to manage the simulation by targeting the behavior of traffic simulation elements in Simulator Core. Conditions evaluate the state of traffic simulation elements in Simulator Core.

In ASAM OpenSCENARIO, actions are the exclusive mechanisms for controlling and modifying the content of a simulation. Conditions are the exclusive mechanisms for evaluating the status information of a simulation.

Actions are not the only factor influencing simulations. Other influencing factors are driver models, drivers-in-the-loop, and environmental conditions. These concepts are not defined in ASAM OpenSCENARIO.

In the same way, conditions cannot describe all quantified property values that exist in a simulation. Simulations can vary in scope and details of their simulated components. In order to be compatible with other simulation standards, ASAM OpenSCENARIO builds on high-level, abstract information that represents a common denominator for a majority of simulations. For example, a condition can be used to specify the speed of a vehicle, but not the speed of the vehicle’s left front wheel.

The ASAM OpenSCENARIO format is organic, meaning it may grow dependent on the used application. It can be expected that the scope of what is possible to use in conditions expands as the format grows. The same applies for actions. Actions and conditions are described in detail in Section 7.

With the definition of actions and conditions, the logical interface between OSC Director and Simulator Core can be refined into an Apply Action Interface and an Evaluate Condition Interface. More generic interfaces are also required for general commands like initialize, starting, and stopping a simulation. Figure 4 illustrates the architecture of ASAM OpenSCENARIO.

Coordinate system of type (X, Y, Z) fixed in the inertial reference frame of the simulation environment, with X_w and Y_w axes parallel to the ground plane and Z_w axis pointing upward.

Neither origin nor orientation of the world coordinate system are defined by the ASAM OpenSCENARIO standard. If a road network is referenced from a scenario, the world coordinate system is aligned with the inertial coordinate system present in this description (in particular, the Z_w-coordinate is assumed to consider a road elevation, an entire road super-elevation, or a lateral road shape profile).

To every road specified in the road network definition document (external to ASAM OpenSCENARIO), there is a s/t-type coordinate system assigned. The road reference line defines the s-axis belonging to the (X,Y)-plane of the world coordinate system. The shape of the s-axis line is flat and determined by the geometry of the road projected on the (X,Y)-plane (Z-coordinates equal to 0). The origin of s-coordinates are fixed at the beginning of the road reference line and not affected by an elevation of the road (its inclination in the s-direction).

In contrast, multiple t-axes can be defined along the s-axis. Each t-axis points orthogonally leftwards to the s-axis direction and originates on the s-axis at the point with the concerned s-coordinate. All t-axes lie on the surface which is derived from the road surface as if its elevation were not considered. Therefore, t-axes adopt a lateral slope of the road as they are oriented coplanar to the road surface. As the consequence, t-coordinates are not affected by a superelevation of the road.

The following constraints are defined:

To every lane specified in a lane section of a road (the road network definition document is external to ASAM OpenSCENARIO), there is a s/t-type coordinate system assigned. The lane’s center line defines the s-axis going in the middle between lane’s side boundaries throughout the whole lane section in the direction of the road’s s-axis. The shape of the s-axis line is determined by the geometry of the respective lane. The s-axis lies on the road surface and therefore takes into account an elevation of the road (its inclination in the s-direction). The origin of s-coordinates is fixed to the beginning of the lane section.

In contrast, multiple t-axes can be defined along the s-axis. Each t-axis points orthogonally leftwards to the s-axis direction and originates on the s-axis at the point with the concerned s-coordinate. All t-axes lie on the surface of the road and therefore adopt a lateral slope profile and an elevation of the road.

The following constraints are defined:

The vehicle axis system of type (X, Y, Z), as defined in ISO 8855:2011 [11], is fixed in the reference frame of the vehicle sprung mass. The X_v axis is horizontal and forwards with the vehicle at rest. The X_v axis is parallel to the vehicle’s longitudinal plane of symmetry. The Y_v axis is perpendicular to the vehicle’s longitudinal plane of symmetry and points left. The Z_v axis points upward.

In ASAM OpenSCENARIO, the origin of this coordinate system is derived by projecting the center of the vehicle’s rear axis to the ground plane at neutral load conditions. The origin remains fixed to the vehicle sprung mass, as illustrated in Figure 7.

The axis system for a pedestrian (subscript p) or a miscellaneous object (subscript m) is fixed in the reference frame of the object’s bounding box. The X axis is horizontal and normal to the object’s front plane. The Y axis is horizontal, perpendicular to X, and points to the left. The Z-axis points upward.

The origin of this coordinate system is derived from the geometrical center of the object’s bounding box under neutral load conditions (if applicable) projected onto the ground plane.

To every trajectory specified within the scenario, there is a s/t-type coordinate system assigned. The trajectory is deemed as an imaginary spatial directed line ("trajectory line") on the road surface indicating a movement path. The geometry of the trajectory line defines the s-axis course and shape. The origin of s-coordinates is fixed to the beginning of the trajectory line which can go through multiple chained roads.

In contrast, multiple t-axes can be defined along the s-axis. Each t-axis points orthogonally leftwards to the s-axis direction and originates on the s-axis at the point with the concerned s-coordinate. All t-axes lie on the surface of the road and therefore adopt a lateral slope profile and an elevation of the road.

The following constraints are defined:

ASAM OpenSCENARIO accepts position coordinates expressed in spherical geographic coordinate systems as longitude, latitude, and altitude. Interpretation of geographic coordinates might depend on the reference geoid model (datum) used in the geographic coordinate system and is therefore external to ASAM OpenSCENARIO.

The world coordinate system is considered the projected coordinate system compatible with the ENU (East, North, Up) convention of the X/Y/Z-axis directions and is derived from the used geographic coordinate system that is based on the applied geoid model. The (X,Y)-plane of the world coordinate system is assumed to be a local tangent plane in relation to the surface of the reference geoid model.

If coordinates of positions are derived from the geographic coordinate system, the road network definition shall specify the map projection system type involved and provide its mandatory parameters.

ASAM OpenSCENARIO provides various ways to position or localize instances of Entity acting in the scenario:

If not otherwise stated, the three-dimensional Euclidean space (ℝ³) is used for distance measurement. In some cases and for better visualization, a two-dimensional space is used (ℝ²). In these cases, generalization for ℝ³ is provided.

For convenience, only one direction of travel is shown when visualizing a road, as shown in Figure 8.

In ASAM OpenSCENARIO, lateral and longitudinal distance depends on the type of referential, for example Entity, road, lane, or trajectory. Euclidean distance is measured in a global context.

Euclidean distance between two points in Euclidean space is the length of a line segment between those two points, as shown in Figure 9. It is unambiguously defined in ℝ³, independently from the coordinate system that describes the coordinates.

Given two points A = (X_A , Y_A , Z_A) and B = (X_B , Y_B , Z_B) in the coordinates of a specific Entity, the definition in ASAM OpenSCENARIO is:

Given two points in road coordinates A = (s_A , t_A , h_A) and B = (s_B , t_B , h_B), the definition in ASAM OpenSCENARIO is:

Distances based on the lane or trajectory referentials are measured using the same methods as distances measured in the road referential.

In addition to distances between two points, ASAM OpenSCENARIO also support distance measurement between two entities or between an entity and a point. In both cases, it is important to identify the two points of interest and apply the distance concepts introduced in this chapter.

Identifying the point of interest for an Entity depends on the value of the Boolean attribute freeSpace. It determines whether the entities bounding box shall be taken into consideration (freeSpace = true), or shall not be taken into consideration (freeSpace = false).

ASAM OpenSCENARIO defines four different domains of a Controller:

Where the longitudinal and lateral domains are controlling the movement of the ScenarioObject, whereas the lighting and animation domains are controlling the appearance of the ScenarioObject (see Section 6.7).

ASAM OpenSCENARIO defines two types of controllers:

ASAM OpenSCENARIO cannot prescribe the behavior of an user-defined controller. This means that simulations with user-defined controllers can differ from simulations generated using only default controllers, even though they use the same OSC Model Instance. This allows the scenario designer to use ASAM OpenSCENARIO in a broader scope, interpreting Action as suggestions rather than commands. Repeatable simulation results are only expected when using default controllers.

Any number of controllers can be assigned for the same ScenarioObject domain. However, only one controller can be activated for a domain at the time. If a controller is activated for a domain, it deactivates the currently active controller on that domain.

Activating a new controller does not interfere with the existing control strategy and the Action associated with that control strategy. Control strategies belong to the entity they are assigned to. Having a new controller does not change this. The new controller continues to enforce the existing control strategy just like the previous controller did. Figure 25 illustrates the coupling between controllers, entities, and control strategies.

A user-defined controller is assigned with the AssignControllerAction:

A user-defined controller may also be implicitly assigned by including it in the definition of a ScenarioObject, for example:

By default, controllers are assigned to entities in deactivated state.

User-defined controllers are activated for a given domain, for example, longitudinal, or lateral. The following actions are used to activate controllers:

At runtime, all ScenarioObjects of type Pedestrian or Vehicle are assigned a default controller capable of enforcing control strategies. This controller shall not be assigned or unassigned by the OSC Model Instance.

The default controller cannot be activated or deactivated explicitly in the OSC Model Instance.

At runtime, the default controller is activated for a given domain if no user-defined controller is active for that domain. If a user-defined controller is activated for a domain, it automatically deactivates the default controller for that domain.

Starting conditions:

Expected behavior:

Starting conditions:

Expected behavior:

Starting conditions:

Expected behavior:

Starting conditions:

Expected behavior:

Trajectory-relative positions may be defined using TrajectoryPosition, which define a position relative (and potentially offset) to the path of the trajectory. See Figure 21 for an example position along a linestring-defined trajectory.

Traffic signal controllers provide identical states for one or more dynamic traffic signals. Controllers serve as wrappers for the behavior of a group of signals. TrafficSignalController instances are used for dynamic speed control on motorways and to control traffic light switching phases. ASAM OpenSCENARIO adds dynamic aspects, such as phases and durations, to the traffic controllers that are defined in the road network.

Traffic signals are declared in the RoadNetwork section of a scenario file. TrafficSignalController instances are wrapped around their phases (go, attention, stop, etc.) and their traffic signal states (on, off, etc.). A TrafficSignalController references the ID of a signal controller instance in the road network, e.g., an ASAM OpenDRIVE controller, with the name attribute. If the road network format does not define signal controllers, then the name attribute of the TrafficSignalController is only its identifier for reference within the scenario.

ASAM OpenSCENARIO provides an optional mechanism to connect the dynamic behavior of multiple TrafficSignalController instances. The TrafficSignalController defines a delay to a referenced signal controller. The referenced signal controller shall be defined in ASAM OpenSCENARIO with its dynamic behavior.

TrafficSignalController provides an ordered list of Phase instances. A Phase represents a dynamic element of a TrafficSignalController and defines a duration and a name, which represents the semantic information of a Phase, e.g., go, attention, stop, etc. The simulation sequentially runs through the Phase instances of the declared TrafficSignalController while executing the scenario with respect to each duration. The list of Phase instances represents a cycle. That means, the first Phase repeats after the last Phase has ended. The duration of a cycle is the sum of the duration of the Phase instances. The first Phase starts with the execution of the storyboard.

Phase instances are connected to multiple instances of TrafficSignalState or one TrafficSignalGroupState. Because a TrafficSignalController can control multiple traffic signals, each traffic signal is represented by a state during a specific Phase.

In the following example, the pedestrian traffic signals are encoded with Boolean values (on/off) and as a group because all traffic signals share the same state for every Phase:

In ASAM OpenSCENARIO, the storyboard covers the complete scenario description. The storyboard provides the answers to the questions "who" is doing "what" and "when" in a scenario. An ASAM OpenSCENARIO Storyboard element consists of the following elements:

Instances of Story in ASAM OpenSCENARIO contain Act instances, which in turn define conditional groups of Action instances. Each act focuses on answering the question "when" something happens in the timeline of its corresponding story. The act regulates the story via its startTrigger instance and its stopTrigger instance. If a startTrigger evaluates to true, the act’s ManeuverGroup instances are executed.

A ManeuverGroup element is part of the Act element and addresses the question of "who" is doing something, by assigning entities as Actors (see Section 7.3.1) in the included Maneuver instances. Maneuver groups may also include catalog references with predefined maneuvers. This concept is described in Section 9.4.

The Maneuver element defines "what" is happening in a scenario. A Maneuver is a container for Event instances that need to share a common scope. Events control the simulated world or the actors defined in their parent maneuver group. This is achieved through triggering Action instances, via user-defined Condition instances.

Figure 22 illustrates the components of a storyboard.

In a scenario, instances of Entity are the participants that make up the developing traffic situation. Vehicle, Pedestrian, and MiscObjects instances may change their location dynamically. A MiscObject instance represents an object, such as tree or pole. The possible categories are identical to the ones that are defined in ASAM OpenDRIVE. If an object is already defined in the road network file, it can be instantiated in the scenario as Entity as ExternalObjectReference.

Instances of Entity may be specified in the scenario format but the properties are specific to their type. For example, a Vehicle is an instance of Entity that has properties like vehicleCategory and performance. In contrast, a Pedestrian is specified by a property pedestrianCategory.

Where applicable, actions may change the state of an entity, for example, its position, speed or its associated Controller instances. The state of an entity may be queried to trigger an action, via a condition.

ASAM OpenSCENARIO and entity can be represented by any of these two model elements:

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 actors’s 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:

Condition groups relevant for determining which instances of Entity are added to the actors, are located in the maneuver groups parent Act. The maneuver group inherits its parent act’s start trigger.

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.

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 .

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 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.

Private actions shall be assigned to instances of Entity. These actions may affect motion control for their designated entity:

Dynamic behavior implied by a private action is called a control strategy and is assigned to the entity when the private action is instantiated.

The GlobalAction type is used to set or modify non-entity-related quantities.

The UserDefinedActions type enables user customized actions. When user-defined actions are used, the executability of the scenario dependents on the ability of the specific simulation environment recognizing these 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.

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.

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 are applicable to never-ending actions, with the exception of the regular end.

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.

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, and instance of a SpeedAction, A, controls five entities when an instance of a SpeedAction, B, starts, aiming to control one entity in action A. Because the actions are of the same nature, a conflict occurs and action A is overridden. Action B resumes control of the conflicting entity while the remaining entities from the late action A, engage in default behavior.

The Trigger class is an association of ConditionGroup instances, which are an association of Condition instances. At runtime, a condition group evaluates to either true or false and its outcome is calculated as the AND operation between all its conditions:

The outcome of a trigger is calculated as the OR operation between all its condition groups.

Formally, a trigger containing N instances of ConditionGroup at time t_d is defined as:

Let M_n be the number of conditions in a condition group m, and Condition_nm be condition n of condition group m. Replacing the condition group formulation in the expression above gives the trigger as:

Example

A trigger is formed by three condition groups. Let M_n be the number of conditions in condition Group n. The first condition group has two associated conditions (M₁ = 2), the second condition group has three associated conditions (M₂ = 3) and the third condition group has one associated condition (M₃ = 1).

The trigger value is T(t_d) and is calculated as a function of its conditions' evaluations. Let CE_mn be the evaluation of condition n of condition group m:

When edges are defined, with rising, falling, and risingOrFalling, the condition evaluation is also dependent on past values of its logical expression at the discrete time t_d-1. See Figure 30 for the possible evaluations of a condition, given the available edges.

A delay is a modification of a condition that allows past values of the condition evaluation to be used in the present t_d. When a delay Δt is defined, a condition at time t_d is represented by the evaluation of the logical expressions associated to that condition, at t_d-Δt, rather than the evaluation of its logical expressions at time t_d. In other words, evaluation of a delayed condition at time t_d it is equivalent to the evaluation of a similar condition, but without delay, at time t_d-Δt:

Both edge and delay concepts rely on previous evaluations of the logical expression of a condition. Depending on when the condition is evaluated, these previous evaluations of the logical expression may not be available.

The first time a condition defined with edge is checked, there is no information about previous evaluations of its logical expression. At runtime, a condition defined with edge shall always evaluate to false, the first time it is checked. ASAM OpenSCENARIO expects a condition to be checked for the first time once its enclosing storyboard element enters the standbyState. If standbyState is not defined, runningState shall be used.

In case of conditions defined with delay, if t_d < Δt, the concerned condition evaluates to false.

The base condition type contains three basic elements: name, delay, and conditionEdge. Whereas the first element is self-explanatory, clarification on the other terms is given in the preceding sections. Other elements of a condition depend on its subtype, of which there are two: ByEntityCondition and ByValueCondition.

The duration of an execution is determined by three factors:

There is no other runtime aspect that consumes simulation time.

The execution of a scenario follows a general nested pattern:

ASAM OpenSCENARIO applies several execution patterns while running the Storyboard:

An Action instance enters runningState when the parent Event enters runningState. An Action transfers into completeState either when its execution is stopped or when it ends regularly, as shown in Figure 35. stopTransition may be used for different reasons.

An Event enters standbyState when its enclosing Maneuver is started and enters runningState, as shown in Figure 36. When the start trigger of the Event is executed and the priority allows execution, the Event enters runningState. An Event lacking an own start trigger inherits its start trigger from its parent Act.

While in runningState, the Event ends regularly when every nested Action is completed. The Event transfers to completeState with stopTransition under two conditions:

A Maneuver enters runningState as soon as its enclosing ManeuverGroup is started. In this state, all nested Event instances are set to standbyState and wait for their start trigger, as shown in Figure 37.

The Maneuver completes when all nested Event instances have entered the completeState or when the Maneuver is stopped by an issued stop trigger from the enclosing Act or Storyboard.

ManeuverGroup instances are set to runningState when the start trigger of their enclosing Act is executed and the Act enters runningState. At this point, the nested Maneuver instances are set to runningState.

A ManeuverGroup ends regularly when all its Maneuvers are completed.

The number of executions of a ManeuverGroup corresponds to the number of startTransitions performed from the standbyState to the runningState. The ManeuverGroup transfers out of the runningState depending on the number of executions:

When the ManeuverGroup resides either in runningState or in standbyState, it may be stopped by a stop trigger that is issued by its enclosing Act or its Storyboard. When stopped, the ManeuverGroup transfers to completeState regardless of the number of execution counts left.

An Act is set into standbyState as soon as its enclosing Story is started. When the start trigger of the Act is executed, the Act enters runningState, as shown in Figure 39. The nested ManeuverGroup instances transfer to runningState.

The Act may be stopped by its stop trigger or by the stop trigger in the enclosing Storyboard and let the Act transfer to completeState.

The Act ends regularly and enters completeState when all nested ManeuverGroup instances are completed.

A Story is started and set into runningState when its enclosing Storyboard starts and enters runningState. Its nested Act instances are set to standbyState and wait for their start triggers to execute, as shown in Figure 40.

The execution of a Story is stopped when the enclosing Storyboard issues a stop trigger. The execution transfers from runningState into completeState when all nested Acts are completed.

The Storyboard enters runningState when the simulation starts, as shown in Figure 41. This marks the start of the simulation time. Nested Story instances are started and set into runningState. A Storyboard does not transfer to completeState when all its nested stories are complete. A Storyboard only transfers to completeState with a stopTransition when its stop trigger is executed.

A Storyboard instance is able to run without defined stories, for example, when it is empty.

The actions defined in init are handled prior to the execution of the Storyboard. Because the simulation time starts with the execution of the Storyboard (see Section 8.4.7), the init phase does not consume simulation time. All types of Action may be used in init, even those that require elapsed simulation time to fulfill their designated goal, meaning that they cannot be executed instantaneously.