ASAM OpenSCENARIO: User Guide

ASAM OpenSCENARIO comprises the specification and file schema for the description of dynamic content in driving simulation applications. The primary use of ASAM OpenSCENARIO is the description of complex maneuvers that involve multiple vehicles.

ASAM OpenSCENARIO is used in virtual development, test, and validation of functions for driver assistance, automated driving and autonomous driving. The standard may be used in conjunction with ASAM OpenDRIVE [1] and ASAM OpenCRG [2], which describe static content in driving simulation.

Scenario descriptions are essential for testing, validating, and certifying the safety of driver assistance systems and autonomous cars. The industry, certification bodies, and government authorities jointly define scenario libraries that can be used to test and validate the safe operation of such systems. A publicly developed and vendor-independent standard, such as ASAM OpenSCENARIO, supports this endeavor by enabling the exchange and usability of scenarios in various simulation applications.

As an example, with the help of ASAM OpenSCENARIO large numbers of critical situations can be run across various simulators. Thus, compared to road testing in real traffic, the number of test kilometers driven in field tests can be significantly reduced.

The core of the specification is an XML schema file. It is accompanied by an HTML documentation of its underlying UML model and by this User Guide. Several example files show, how the XML schema has to be applied to model scenarios. To migrate existing scenario files to newer versions, scripts and schemas are provided. The UML model and modeling guidelines for further extensions are provided as well.

Thus, the standard comprises the following content:

The following main changes were made in ASAM OpenSCENARIO v1.2 compared to ASAM OpenSCENARIO v1.1:

ASAM OpenSCENARIO can be complemented by other logical road network and 3D model formats. The following list gives some examples:

ASAM OpenSCENARIO provides standardized descriptions of traffic situations for the purpose of simulation. Such descriptions represent executable scenarios that enforce a specific behavior during simulation runtime. For this reason, ASAM OpenSCENARIO covers two main aspects:

The definition of system boundaries and the existence of an abstract runtime model are fundamental for the design of a meaningful scenario because they help bridge the gap between scenario designer and tool implementer. System boundaries delimit the standard’s scope by separating concepts covered by the standard from those concepts that are covered by external systems or definitions.

An abstract runtime model represents a basic contract between the author of a scenario and the provider of a simulation environment, together with a common idea about what should happen when a specific scenario is executed.

ASAM OpenSCENARIO does not describe all these aspects in detail. ASAM OpenSCENARIO provides a solution space and data model for defining traffic situations. The data model is supplemented with an abstract runtime model necessary to interpret interactions between the components at runtime.

A scenario description may require references to a specific road network as well as inclusion of specific 3D models that represent the simulated environment visually. The definition of road network logic and/or environment 3D models is optional of ASAM OpenSCENARIO. Those references are established within the RoadNetwork language element. As an example, the ASAM OpenDRIVE file format is common when it comes to describing road network logic.

Scenario authors often need to refer to items defined in the road network, for example, to instruct a vehicle to drive in a specific lane. ASAM OpenSCENARIO does not impose its own naming system for these items; they should be referred with the names allocated by their own file format.

The following features of the road network may be addressed using ASAM OpenSCENARIO:

As mentioned before, a road network description supported by ASAM OpenSCENARIO is the ASAM OpenDRIVE format. This format describes the logical information related to road structure, such as road id, lane id, and road geometry. This information may be used to locate and position instances of Entity acting on the road and to position traffic participants. If ASAM OpenDRIVE is used to represent the road network, the ASAM OpenSCENARIO file should follow the ASAM OpenDRIVE conventions for numbering lanes.

In addition to the road network description, 3D models representing the environment may be referenced in a scenario description. Files containing 3D models provide the geometric and visual representation, like mesh and textures for elements of the virtual environment including the road surface. Use cases for 3D models referenced from scenarios are rendering, physical modeling, and sensor simulation. Files containing 3D models are considered to be external elements to the ASAM OpenSCENARIO format.

In ASAM OpenSCENARIO, the following coordinate system types are defined:

These coordinate system types are referenced to create the following coordinate systems:

ASAM OpenSCENARIO interprets distances in special ways. To properly use instances of Action and Condition, it is important to understand distance interpretation.

Depending on the use case, a distance may be specified between:

Distances in ASAM OpenSCENARIO may be measured in two ways:

ASAM OpenSCENARIO assumes distances to be greater than equal to zero, (ℝ⁺₀).

Speed is measured as the magnitude of the speed vector in the vehicle coordinate system, consisting of longitudinal and lateral speed components.

Controller are elements of the simulation core that control the motion or appearance of a ScenarioObject. ASAM OpenSCENARIO does not specify how controllers work and how they are implemented. ASAM OpenSCENARIO considers a controller as a runtime element that is used to enforce the control strategies (see Section 7.4.1.1) assigned to instances of ScenarioObject.

Any number of Controller elements can be assigned to objects of type Vehicle or Pedestrian.

A Controller may be internal, as a part of the simulator, or external, defined in a file. The intended use cases for controllers are:

By default, controllers are assigned in a deactivated state.

ASAM OpenSCENARIO allows changing and controlling the Appearance of a ScenarioObject. The Appearance handles dynamic changes a ScenarioObject can undergo during a scenario. Hence, the color of a Vehicle is not controlled by the Appearance. The Appearance does not affect the position or change the effective BoundingBox of an ScenarioObject, only how it is perceived.

The Appearance is divided into two separate categories:

ASAM OpenSCENARIO supports simple use cases, for example:

To handle more complex modeling of either Light or Animation, a Controller of type lighting or animation can be used.

A Route is used to navigate instances of Entity through the road network based on a list of waypoints on the road that are linked in a specific order, resulting in directional route. A Waypoint consists of a position and a RouteStrategy. The RouteStrategy indicates how to reach the position. An Entity’s movement between the waypoints is created by the simulator which uses the RouteStrategy as constraint. There may be more than one way to travel between a pair of waypoints. If this is the case, the RouteStrategy specified in the target Waypoint shall be used.

The different available and simulator-specific options for RouteStrategy are:

If, for example, the RouteStrategy "shortest" results in multiple possible routes of equal lengths, it is up to the simulator which route to choose.

The following figure exemplifies the resulting routes dependent on the chosen RouteStrategy (e.g., either shortest or fastest) of the target waypoint. Moreover, the waypoint of a route does not affect the lateral position of an entity within a road when following the route.

The reference line of a route consists of the road reference lines along the calculated path.

Instances of Route may be assigned to an Actor using AcquirePositionAction or AssignRouteAction. Once assigned, they remain in place until another action overwrites them. For more details, refer to Section 7.5.1.

If an entity approaches a junction and is not on a route, or is on a route that cannot be followed, the road to follow is selected randomly from the available options.

If an actors starts somewhere before the first waypoint on a route, two different outcomes are possible, depending on where the first waypoint is located:

It is possible that an actor starts somewhere along a route and not at its first waypoint. There are two ways to proceed for the actor, depending on whether the route contains loops:

If the route contains loops, see Figure 17 for an example, some additional rules apply. The route in the example consists of four waypoints (shown in boxes) that are linked in a specific order. The part of the route highlighted in red is driven twice: once on the links between waypoints 1 and 3, and once on the links between Waypoints 3 and 5. To avoid the entity becoming stuck in a loop, the following rules apply:

When waypoints and the resulting ordered sequence of roads uniquely define the path from the start to target location, a position along the route can be defined in road or lane coordinates relative to the reference line of the road or lane. For this purpose, PositionInRoadCoordinates or PositionInLaneCoordinates can be used. An example of this is shown in Figure 18. Furthermore, it is assumed that a simulator makes a calculation so that the composite reference line of a route consists of the road reference lines along the calculated path.

Instances of Trajectory are used to define an intended path for Entity motion in precise mathematical terms. The motion path may be specified using different mathematical shapes:

By using nurbs, most relevant paths may be expressed either directly or with arbitrary approximation: Nurbs curves form a strict superset of the curves expressible as Bézier curves, piecewise Bézier curves, or non-rational B-Splines, which can be mapped to corresponding nurbs curves. Because nurbs curves directly support the expression of conic sections, such as circles and ellipses) approximation of, for example clothoids using arc spline approaches, is feasible.

Also, nurbs make it relatively easy to ensure continuity up to a given derivative: A nurbs curve of degree k, meaning order k+1, is infinitely continuously differentiable in the interior of each knot span and k-M-1 times continuously differentiable at a knot. M is the multiplicity of the knot, meaning the number of consecutive knot vector elements with the same value.

Commonly used nurbs curves are curves of quadratic (order = 3) and cubic (order = 4) degree. Higher-order curves are usually only required if continuity in higher derivatives needs to be ensured. Because the effort for evaluating curves increases with rising orders, it is recommended to restrict instances of Trajectory to lower orders.

Instances of Trajectory may be specified using just the three-positional dimensions along the X, Y, and Z axes (see Section 6.3 for coordinate system definitions). Alternatively, instances of Trajectory may also be specified using the three-positional dimensions and the three-rotational dimensions (heading, pitch and roll) for six total dimensions. In the second case, the path not only specifies the movement of the entity along the path, but also the orientation of the corresponding entity during that movement.

When a Trajectory is specified relative to the position of a moving entity, its absolute position cannot be calculated before the scenario starts. In this case, the trajectory must be calculated at runtime when the corresponding FollowTrajectoryAction is triggered.

Additionally, an instance of Trajectory may be specified with or without a time dimension, allowing for the combined or separate specification of the entities longitudinal domain: A trajectory incorporating the time dimension completely specifies the motion of the entity, including its speed. A trajectory without the time dimension does not specify the speed along the path. This approach allows for the separate control of speed.

A Trajectory provides a mathematically precise definition of a motion path. The corresponding entities behavior, however, depends on the actions employing it: Either an Entity follows this path exactly or it uses the path as a guidance for the controller to follow as best as the entities rules of motion allow.

The following sections describe edge cases in the definition of trajectories.

In addition to deterministic behavior of instances of Entity, ASAM OpenSCENARIO also provides ways to define stochastic or not precisely defined behavior. This can be useful for the following purposes:

To define stochastic behavior, surrounding intelligent traffic agents may be defined using instances of TrafficAction. With the help of this action, the parameterization of traffic sources, traffic sinks, and traffic swarms may be specified.

The definition of a TrafficAction in ASAM OpenSCENARIO does not specify which maneuvers the intelligent traffic agents execute. Instead, those actions specify the initialization or termination of vehicles whose behavior is controlled by external traffic simulation models. Spawned traffic participants makes routing decisions based on their corresponding driver model, just as with the ActivateControllerAction.

Traffic signals introduce two main aspects into simulation:

Variables in ASAM OpenSCENARIO are similar to variables in programming languages. They have the following characteristics:

Unlike parameter values (see Section 9.1), variable values can also change during runtime. This can be achieved in two ways:

Variables are used in a scenario to trigger actions with a VariableCondition. A VariableCondition can also be used where the existing conditions cannot describe the value of the variable or the value needs to be injected from external side because it is not part of the scenario.

An example of a scenario action which is triggered by a VariableCondition could look like this:

Variables can also be read from external side during the scenario. For this, the Simulator Core needs to provide an interface to read variable values. An example of a VariableAction which triggers something on external side could look like this:

The standard defines a type inference check, which ensures that the variable value matches its type. The check is not ensured by the XML validator and therefore must be implemented by the simulator.

Variables can only be used in a VariableCondition to trigger actions during runtime of the scenario. They cannot replace any attribute value in the scenario or be used in expressions like parameters. This avoids unspecified behavior, e.g., changing the AbsoluteTargetSpeed of a SpeedAction during execution or changing the model3d of a Vehicle during runtime.

Instances of Property may be used to define test-instance specific or use-case specific properties of ASAM OpenSCENARIO sub-elements. Properties are available for the following types:

Instances of Property are collected in the Properties container. Every Properties definition may contain one or more name-value pairs (meaning instances of Property) and/or references to external files using the File mechanism. Thus, properties are a powerful instrument for customizing scenarios, without the need of standardizing purpose-built features related to specific simulator, hardware, and software setups.

Typical applications of properties are extensions of vehicle dynamics specifications, additional driver behavior settings, color information of objects, etc.

Properties can influence scenario execution, for example the driver behavior, but scenarios shall be executable without knowledge of the properties meaning.

To represent a traffic situation, an OSC Model Instance is built up of four main components:

The structure of the OSC Model Instance was created with the purpose to host and combine the main components listed above in such a way that rich driving scenarios can be defined. This chapter introduces the ASAM OpenSCENARIO structure, how the different components fit in the structure, and how these components relate to one another.

Actions enable ASAM OpenSCENARIO to prescribe element behavior in traffic simulations or to directly affect element states, which in turn determine how a simulation evolves. An Action instance is defined in a OSC Model Instance.

There are three categories of Action:

In the initialization phase of a scenario, actions are responsible for setting up initial states of dynamic objects, environment, or infrastructure. In any later phase of the scenario, actions are executed when events are triggered.

A scenario can be regarded as a collection of meaningful actions whose activation is regulated by triggers. These triggers play an important role on how a scenario evolves because the same set of actions may lead to a multitude of different outcomes. The outcome strongly depends on how actions are triggered in relation to one other. In ASAM OpenSCENARIO, a trigger is the outcome arising from a combination of conditions and always evaluates to either true or false.

In ASAM OpenSCENARIO, a condition is a container for logical expressions and is assessed at runtime. The condition operates on the current and previous evaluations of its logical expressions to produce a Boolean output that is used by triggers.

The lifecycle of a StoryboardElement instance includes five states.

initState and endState are implementation-specific and represent the creation (initState) and the cleanup (endState) of a StoryboardElement. All other states may be monitored with a StoryboardElementStateCondition.

The change from one state to another is called transition. There are six transitions for the StoryboardElement lifecycle.

startElementLifecycle and stopElementLifecycle are implementation-specific and represent the creation (startElementLifecycle) and the cleanup (stopElementLifecycle) of a StoryboardElement. All other states may be monitored with StoryboardElementStateCondition.

A storyboard element is defined as executing when the element either resides in standbyState or in runningState.

When a storyboard element enters runningState, its direct child elements are set into:

The init section of a scenario defines actions to set entity states or global states providing initialization to a simulation. These actions are handled in the init phase prior to the execution of the StoryboardElement instances.

The order of the actions in the InitActions section is not translated into an execution order at runtime. All actions in init shall run concurrently and conflicts shall be handled according to the conflict solving guidelines provided in Section 7.5.1.

In ASAM OpenSCENARIO, parameters provide a central extension mechanism for scenarios.

External applications can read the provided parameters and thus implement sophisticated methods to assign concrete values to the parameters. This extension method allows scenarios to be reused for a large space of concrete values, for example, the re-simulation of one scenario with different speeds.

Every attribute of an ASAM OpenSCENARIO language element may contain either the actual attribute or a reference to a parameter. Each parameter is defined in the ParameterDeclaration by its name, the parameterType, a default, type-specific initialization value and optional constraintGroups. When using a parameter, more precisely the parameter value, anywhere in the scenario, then the parameter is referenced by its name with a "$" prefix.

All parameters that are used in a scenario shall be defined in ParameterDeclaration where they are declared by their individual names. Because they are declared and not used as a reference, the name has no "$" prefix.

Naming of parameters works different than naming of scenario elements (see Naming conventions). While scenario elements may be made unique by providing prefixes, this does not apply to parameter names. The reason for this is that scenario elements are globally referenceable, whereas parameters have a scope.

The scope of a parameter is the subtree rooted in the element where the ParameterDeclarations is located. That means, if a parameter "ego_speed" is defined at the root of a Maneuver, "ego_speed" may be referenced in every Event, Action and Trigger located in that Maneuver. The parameter shall not be used in other Maneuver instances.

If there are multiple parameters with the same name and overlapping scopes in the scenario, only the parameter with the smallest scope that subsumes the location is accessible. As an example, if the Maneuver "Overtake" declares a parameter "ego_speed" and "Overtake" contains a FollowTrajectoryAction that also declares a parameter "ego_speed", then only the second declaration of "ego_speed" is visible in the FollowTrajectoryAction.

A parameter is considered global if it is a child of the OpenSCENARIO element that is the root of any ASAM OpenSCENARIO file. Global parameters may be overwritten by external tools (see, for example, Section 9.3).

Since every language element may either be the actual type or a referenced parameter, it is also generally allowed to use a reference as, for example, parameterType on another ParameterDeclaration. Using a parameter reference in another parameter declarations name field is allowed, but it is strongly advised not to do such chaining of parameters or mutual referencing as this can easily lead to deadlocks.

The assignment of values to parameters declared in a Catalog is allowed in a CatalogReference.

There is a type inference check defined by the standard, which ensures that the parameterType matches. The check is not ensured by the XML validator and therefore must be implemented by the simulator.

Parameter values are evaluated and set at load time of the simulation. They cannot be changed during runtime. Therefore, the evaluation result of a ParameterCondition is determined in the first step cycle of a simulation and does not change during runtime. Parameters can be used to configure if an action shall be executed or not for different concrete scenarios.

Parameter names starting with OSC are reserved for special use in future versions of ASAM OpenSCENARIO. Generally, the OSC prefix shall not be used.

These naming rules apply to parameters:

The parameter name must match the regular expression [A-Za-z_][A-Za-z0-9_]*.

Special rules apply to referencing parameters within a Catalog (see section Section 9.5).

ASAM OpenSCENARIO supports mathematical operations for evaluating expressions. Every attribute of a language element may contain either the actual attribute as a literal (constant value), a reference to a parameter, or an expression.

Expressions are notated with the following syntax:

ASAM OpenSCENARIO expressions are build on literals and parameters. Because of that circumstance, the expressions are typed as well.

Expressions are designed to define relatively simple operations in scenario files. Checks and more sophisticated, complex calculations should not be expressed in a scenario file.

To use parameters in a convenient way to parametrize scenarios, a parameter value distribution file may be used to describe in which way those parameters vary.

Parameters in ASAM OpenSCENARIO are evaluated at the load time of the scenario. At this point, all parameters are replaced with the current value of the parameter wherever the parameter is referenced. The actual value is given in the ParameterDeclaration part.

With a parameter distribution file, the actual value is not taken out of the ParameterDeclaration but is computed at load times regarding the information in the distribution file.

The file should be separated from the ASAM OpenSCENARIO file and is handled like catalogs. The file format is included into the OpenSCENARIO element and contains the same FileHeader. An ASAM OpenSCENARIO file shall be referenced from the parameter distribution file.

An example without the definition part is shown below:

A distribution file may contain two different types of distributions. There are either Stochastic or Deterministic distributions, containing single-parameter distributions and multi-parameter distributions. For single-parameter distributions, every parameter value distribution is independent of other parameters. Therefore, every distribution definition is bound to a single parameterName. For multi-parameter distributions the values of the parameters are changed dependent on each other. Single-parameter and multi-parameter distributions may be used at the same time, but they shall not contain the same value for parameterName.

Many elements of a scenario require a detailed description, which may not only be rather lengthy but can also be tedious to repeatedly write if the element is used in several different scenarios. The Catalog element offers the possibility to outsource the description of certain elements from the scenario to a separate file, which may then be referenced from a scenario.

Using a Catalog enhances the reusability of elements and the readability of the scenario at the cost of technical detail in the scenario file. In order to refer to an element detailed within a Catalog, a reference to the Catalog shall be specified in the scenario. At the location where the element is being used, the reference to both the Catalog and the specific element shall be given.

There are eight different kinds of elements that may be outsourced to a Catalog. All kinds of objects may be defined within a Catalog, for example, Vehicle, Pedestrian, and MiscObject, as well as their respective Controller. Navigational instructions in the form of Trajectory and Route may also be stored. Additionally, descriptions of the Environment and instances of Maneuver may be outsourced this way.

Catalog files are designed for reuse. For this reason, they can store their own set of parameters. All parameters used within a catalog shall be declared within their ParameterDeclaration, which sets a default value for each parameter. When a catalog is referenced, the ParameterAssignment element within CatalogReference may be used to override these defaults.

For example, a catalog definition may contain the following ParameterDeclaration:

When referenced in the main scenario, the value of x is overridden by using a ParameterAssignment within the CatalogReference:

This means that, for this use of the catalog, any reference to "$x" should be replaced with "0", and any reference to "$y" should be replaced with the default value of "7". No other parameters may be referenced from within the catalog.

Catalog references are resolved by locating the catalog by name and the entry within this catalog by its entry name (catalogName and entryName of the CatalogReference). A CatalogReference may hand over a ParameterAssignment to resolve parameters for this specific reference.

A Catalog shall be defined in a catalog file (for example, "VehicleCatalog.xosc"). An instance of a Catalog is identified by its name property.

Any valid catalog file of the correct catalog type and catalog name shall be processed that resides in the defined directory. A directory for every catalog type may be defined in a scenario:

The file for the sample scenario used in this tutorial is named SimpleOvertake.xosc. The file is located in the examples directory.

Vehicle 2 and Vehicle 1 are located on the same lane on SampleDatabase.xodr 58 meters apart, with Vehicle 2 being in front of Vehicle 1. Vehicle 1, having the larger speed, catches up with Vehicle 2 , and needs to change to the left lane. After some time, when it has overtaken Vehicle 2, it moves back to its previous lane, ending in front of Vehicle 2.

In the Entities section, we define the traffic participants used in the scenario: one or more instances of Vehicle, Pedestrian, MiscObject, or ExternalObjectReference.

To state you want to use an entity from the catalog, use the following syntax:

In this scenario, we are not using catalogs. Instead, both entities are defined directly. It should be noticed that the entities do not have an initial position and initial speed yet. These are added in the following sections.

The following XML example shows multiple instances of Action that position the entities Vehicle 1 and Vehicle 2 using road coordinates and define initial velocities. Vehicle 1 has speed 150 km/h and is located 58 m behind Vehicle 2, which has speed 130 km/h.

Instances of Story may be used to group independent parts of the scenario, to make it easier to follow. In this example, we need only one Story. If an Act is moved from one Story to another, the scenario works in the same way, as long as there are no naming conflicts.

In this scenario, one Story defines just one Act.

An Act allows a set of multiple instances of Trigger to determine when the specific Act starts.

The example below shows the structure of an Act. This Act starts when the scenario starts because it has one SimulationTimeCondition condition checking when time becomes larger than zero. Movements of vehicles in Act are defined in the ManeuverGroups section, which is omitted here but described later in this chapter.

An Act may be terminated by a stopTrigger (see Section 7.6.1.2).

Using ManeuverGroup we specify the Actors that are executing the actions. Because we want Vehicle 1 to change lanes, we specify its name under Actors. This means that all the actions under this ManeuverGroup are executed by Vehicle 1.

ManeuverGroups receives its name from grouping one or multiple instances of Maneuver which is used in the next section.

In this example, one Maneuver is used to group two instances of Event. Two instances of Maneuver may also be used, each hosting one Event. Both alternatives yield the same simulation outcome, as long as each Event retain its startTrigger.

Under Maneuver_1 we define two instances of Event, one for left lane change called Turn left and the other one with right lane change named Turn right. Left and right means relative to the current lane.

In the first Event that we want to execute, which is Turn left, we use one ConditionGroup and inside it one RelativeDistanceCondition. This condition checks if the current longitudinal distance between Vehicle 1 and Vehicle 2 is shorter than 20 m. Because Vehicle 1 has a higher speed than Vehicle 2 their relative distance falls below 20 m at some point and StartTrigger gets triggered on Turn left event, and Vehicle 1 starts its LaneChange action to the left.

The second Event named Turn right contains also one LaneChangeAction, but this one targets the same lane where Vehicle 2 is currently located. That means, the target is to get back to the same lane where Vehicle 1 was, but this time in front of Vehicle 2.

For triggering the event Turn right we use two conditions in one condition group, which means they both have to be true at the exact same time. We use RelativeDistanceCondition that checks whether the relative longitudinal distance between Vehicle 2 and Vehicle 1 is no longer greater than 10 m. However, we have to combine this condition with SimulationTimeCondition to disallow triggering RelativeDistanceCondition anytime before 5 seconds.

The basic execution pattern for StoryboardElement instances is parallel execution of nested elements, for example, a Storyboard executes a Story concurrently, while a Story executes one or multiple instances of Act in parallel.

In many use cases, however, an Action is applied only when others have finished. That means sequentialization of multiple occurrences of Action is a major concept when writing and executing scenarios.

Two major concepts are provided:

The following examples are using the ASAM OpenDRIVE controller definition for grouping signals that have identical Phase instances, which is in alignment with civil engineering specifications like [14].

This example, which is shown in Figure 47, describes a traffic situation where the Ego vehicle drives behind a vehicle on the rightmost lane of a two-lane straight highway. At the same time, the Ego vehicle is overtaken by a faster vehicle on the left lane. After overtaking, the faster vehicle cuts in to the Ego vehicle’s lane.

At the initialization phase, the environment conditions are set. The Ego vehicle is instantiated in the rightmost lane, driving at 100 km/h. A vehicle, driving at the same speed and in the same lane, is instantiated 84 m ahead of the Ego vehicle. A second car, driving at 110 km/h, is instantiated 100 m behind the Ego vehicle in the lane left of it.

At simulation runtime, after the second car has passed the Ego vehicle by 20 m, it cuts in to the Ego vehicle’s lane, using a prescribed trajectory.

This scenario teaches the use of the EnvironmentAction, instantiation of instances of Entity, Event, Condition and Trajectory.

This example, which is shown in Figure 48, describes a traffic situation where the Ego vehicle approaches a slower vehicle in the same lane of a two-lane curved highway.

At the initialization phase, the environment conditions are set. The preceding vehicle is instantiated at the rightmost lane. It is driving at a constant speed of 80 km/h. The Ego vehicle is instantiated relative to this vehicle in the same lane, but 200 m behind, driving at 100 km/h.

Each ParameterDeclaration assign a default value to each parameter in the scenario. Default parameter assignments can be overwritten by external applications or parameter distribution files.

For this scenario, a deterministic and stochastic distribution are defined:

This scenario teaches the instantiation of instances of Entity, the use of ParameterDeclaration, and the definition of deterministic and stochastic parameter sets.

This example, which is shown in Figure 49, describes a traffic situation where the Ego vehicle approaches two slower vehicles driving side-by-side on a straight two-lane highway running over a crest.

The environment conditions are set in the initialization phase. The Ego vehicle is instantiated at a constant speed of 100 km/h on the rightmost lane of the road. 200 m ahead of Ego vehicle, two vehicles are instantiated at a speed of 80 km/h in the rightmost lane and the neighboring lane to the left.

At simulation runtime, after vehicle A1 has travelled a distance of 100 m and vehicle A2 has travelled a distance of 200 m, they linearly decelerate by 5 m/s² until they reach a target speed of 70 km/h.

The EndOfTrafficJamParameterSet.xosc defines two possibilities for the scene graph and the road network for this example. Both can be applied without changing the scenario itself.

This scenario extends the scenario in Section 11.2 by parallel execution of instances of Act and Condition. Moreover, it shows the possibility to change the road network and the scene graph with a deterministic multi parameter set.

This example, which is shown in Figure 50, extends the scenario described in Section 11.3 by a fourth vehicle on a three-lane highway with limited friction. The rightmost and the leftmost lanes of this highway are blocked by stationary vehicles. A third vehicle performs a lane change to the centermost lane in order to prevent a collision with the stationary vehicle on the rightmost lane. At the same time, it decelerates until it arrives at a full stop.

At the initialization phase, the environment conditions are set. The Ego vehicle is instantiated at a constant speed of 80 km/h on the rightmost lane of the road. 300 m ahead of the Ego vehicle, a vehicle is instantiated in the same lane at a speed of 70 km/h. 1000 m ahead of the Ego vehicle, a third vehicle is instantiated in the same lane as the other two vehicles. This vehicle is stationary (speed 0 km/h). It is accompanied by a fourth vehicle, which is situated two lanes left and 1000 m ahead of the Ego vehicle.

At simulation runtime, the vehicle driving in front of the Ego vehicle at a speed of 70 km/h performs a lane change to the left as soon as it approaches the stationary vehicle in the same lane by 55 m. In parallel to the lane change, it decreases its speed linearly by 10 m/s2 until it arrives at a full stop.

This scenario teaches the instantiation of instances of Entity. Moreover parameters are introduced by a ParameterDeclaration and parallel actions are used.

This example, which is shown in Figure 51, describes a traffic situation where the Ego vehicle is driving at the rightmost lane of a three-lane motorway behind another vehicle at the same speed, leaving a gap. A faster vehicle approaches the Ego vehicle from behind on the centermost lane. This vehicle changes lanes into the gap on the rightmost lane after it has passed the Ego vehicle. In order to avoid collision with the vehicle driving ahead of the Ego vehicle, it immediately changes back to the center lane.

At the initialization phase, the Ego vehicle is initialized at the rightmost lane at a speed of 130 km/h. A second vehicle is initialized 13 m behind the Ego vehicle at the centermost lane driving at a speed of 170 km/h. A third vehicle is initialized 70 m ahead of the Ego vehicle on the rightmost lane driving at 130 km/h.

At simulation runtime, when the fast vehicle on the centermost lane has passed the Ego vehicle by 5 m, it performs a sinusoidal lane change to the rightmost lane. When this action is completed, the vehicle immediately changes back to the centermost lane, using another sinusoidal lane change.

This scenario teaches the instantiation of instances of Entity using Cartesian coordinates, use of conditions and consecutive execution of LaneChangeAction.

This example, which is shown in Figure 52, describes a traffic situation where the Ego vehicle approaches a truck that slows down on the right lane of a three-lane highway. An overtaking vehicle is initialized in the centermost lane when the truck performs this action.

At the initialization phase, the Ego vehicle is initialized at a speed of 130 km/h on the rightmost lane. A truck driving at a speed of 90 km/h is initialized 120 m ahead of it in the same lane. The overtaking vehicle is initialized at an arbitrary position and orientation.

At simulation runtime, when the Ego vehicle approaches the truck by 60 m, the latter linearly reduces its speed to 60 km/h. This action triggers the relocation of the overtaking vehicle to the centermost lane at a speed of 200km/h at 200m behind of the truck. This action is delayed by 2 s.

This scenario teaches the consecutive execution of instances of Act and Action.

This example, which is shown in Figure 53, describes a traffic situation where the Ego vehicle is approached by a faster vehicle driving on the rightmost lane of a three-lane motorway.

At the initialization phase, the Ego vehicle is initialized at the rightmost lane driving at a speed of 130 km/h. The other vehicle is initialized 79 m behind of the Ego vehicle driving in the same lane at a speed of 150 km/h.

At simulation runtime, when the faster vehicle approaches the Ego vehicle by 30 m, it performs a sinusoidal lane change to the left. As soon as the vehicle is 5 m ahead of the Ego vehicle, it changes its lane back to the rightmost lane.

This scenario teaches the use of conditions and the consecutive execution of instances of LaneChangeAction.

This example, which is shown in Figure 54, describes a traffic situation where the Ego vehicle approaches a traffic jam of six other vehicles on a three-lane motorway.

At the initialization phase, the Ego vehicle is initialized at a speed of 130 km/h at the leftmost lane. The vehicles forming the traffic jam are initialized 145 m ahead of the Ego vehicle at a speed of 0 km/h. Pairs of vehicles block all three lanes of the motorway. Each of the pairs features a longitudinal gap of 8 m between its two corresponding vehicles.

This scenario teaches the instantiation of instances of Entity using Cartesian coordinates.

This example, which is shown in Figure 55 recreates a critical situation at an intersection where the Ego vehicle and another vehicle are in a collision course. The Ego vehicle is instantiated with an initial speed of 10m/s and is assigned a route guiding it straight through an intersection (south to north). A second vehicle is instantiated with no speed and a route that guides it straight through the same intersection (west to east).

The moment at which the distance between the vehicles becomes smaller than 70m, a SynchronizeAction is triggered. At this stage, the crossing vehicle is regulating its speed in order to reach its synchronization position, at the same time as the Ego vehicle reaches its synchronization position. Additionally, the crossing vehicle is constrained to reach its synchronization position with a final speed of 7m/s.

When the vehicles reach their synchronization positions, the action is complete and vehicle A1 resumes default behavior driving through the intersection at 7m/s.

This scenario teaches the use of SynchronizeAction.

This scenario describes a critical traffic situation where the Ego vehicle approaches an intersection coinciding with two other vehicles crossing perpendicularly.

At the initialization phase, the Ego vehicle is spawned 110m west of the intersection with a speed of 23 km/h. The other vehicles are spawned 255m north of the intersection on a trajectory crossing the intersection at about 18 seconds.

At simulation runtime, the non ego vehicles follow the same trajectory crossing the intersection, coinciding with the Ego vehicle.

This scenario teaches the use of TrajectoryCatalog, TrajectoryPositions and FollowTrajectoryActions with initialDistanceOffset.