Disclaimer

This document is the copyrighted property of ASAM e.V.

Any use is limited to the scope described in the license terms (https://www.asam.net/license). In alteration to the regular license terms, ASAM allows unrestricted distribution of this standard. §2 (1) of ASAM’s regular license terms is therefore substituted by the following clause: "The licensor grants everyone a basic, non-exclusive and unlimited license to use the standard ASAM OpenSCENARIO".

Foreword

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

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.

After the standard had been developed over several years in an industry consortium, it was transferred to ASAM e.V. in March 2020.

1. Introduction

1.1. What has changed

The following main changes were made in OpenSCENARIO 1.1 compared to OpenSCENARIO 1.0:

  • Support for logical scenarios

    • Parameter value distributions for scenario variation / automated generation of concrete scenarios

    • Stochastic and deterministic distributions

    • Single- and multi-parameter distributions

  • More flexible maneuver modeling

    • Arithmetic calculations and logical expressions

    • External object referencing in road network

    • Trajectory coordinate system and positions

  • Compatibility with more road network formats

    • Geographic coordinate system and positions

  • Improved test support

    • Parameter-value constraints (ranges) prevent misuse and misunderstanding of scenarios in test design

    • Consistency with ASAM OSI (weather conditions)

  • Improved sensor test support

    • 3D model referencing

    • Precipitation

  • Improved controller test support

    • Wind, atmospheric pressure, outside temperature (for external force on vehicle calculation)

  • Improved exchangeability of scenarios

    • Licensing information can be included

  • Clarifications

    • Actions (traffic, lane change, lane offset, longitudinal/lateral distance, synchronize, controller assignment/activation, etc.)

    • Conditions ( (relative) distance, time headway, time to collision)

    • Distance calculation

    • Controller concept (control strategy)

    • Init actions and end of simulation/scenario

    • Default values

    • Restrictions on entity selection references for actions and conditions

    • Parameter usage

    • Runtime behavior of scenarios in an environment simulator

    • System boundaries of OpenSCENARIO

  • Corrected examples

    • Consistency of scenario files for User Guide

    • Validation of scenarios and road networks against schema

    • Executability in environment simulators

  • Enhanced User Guide

    • Applied consistent structure throughout ASAM OpenX standards

  • Ensured backward compatibility

    • Introduced deprecation mechanism

1.2. Overview

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 OpenSCENARIO, supports this endeavor by enabling the exchange and usability of scenarios in various simulation applications.

As an example, with the help of 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.

1.2.1. What is a scenario?

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:

  • Static environment description, including:

    • Logical road network

    • Optionally physical and geometric road and environment descriptions

  • Dynamic content description, including:

    • Overall description and coordination of behavior of dynamic entities

    • Optional behavior models of dynamic entities

1.2.2. What is OpenSCENARIO?

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

  • Storyboarding, that is usage of a storyboard and stories. Each story consists of one or more acts and maneuvers.

  • An event is triggered by a trigger, when a condition is evaluated to true. Events cause the execution of actions.

  • References to logical road network descriptions.

  • Instantiation of entities, such as vehicles, or pedestrians, acting on and off the road.

  • Catalogs and parameter declarations provide mechanisms to re-use several aspects of a scenario.

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

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

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 OpenSCENARIO but can be referenced by the format.

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. OpenSCENARIO cannot not 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 OpenSCENARIO:

Table 1. What is not part of OpenSCENARIO
Feature Description

Test configuration description

OpenSCENARIO does not describe a test instance or its structure.

Test case language

OpenSCENARIO does not specify all possible user or system interactions with a vehicle.

Test evaluation

OpenSCENARIO does not include concepts for creating test verdicts, although it contains methods for the evaluation conditions for triggering actions.

Driver model

OpenSCENARIO does not include behavioral driver models, except for basic concepts, such as the physiological description of a driver.

Vehicle dynamics

OpenSCENARIO does not include elements to describe advanced motion dynamics for vehicles.

Environmental models

OpenSCENARIO includes elements to define environmental properties, such as the current time or the weather, but does not specify how this is to be interpreted by a simulator.

1.2.3. Deliverables of OpenSCENARIO

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 modelling guidelines for further extensions are provided as well. Thus, the standard comprises the following content:

  • XML schema file

  • Model documentation (html)

  • User Guide

  • Examples

  • Migration scripts and schemas

  • UML model

  • Modelling guidelines

1.3. Normative and non-normative statements

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

  • Statements expressed as requirements, permissions, or prohibitions according to the use of modal verbs, as defined in Section 1.4.3, are normative.

  • Code samples and use case descriptions are non-normative.

1.4. Conventions

1.4.1. Units

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

Table 2. Units
Unit of Unit Symbol

Length

Meter

m

Duration, (relative) time

Second

s

Speed

Meters per second

m/s

Acceleration

Meters per second squared

m/s²

Mass

Kilogram

kg

Angle

Radians

rad

Light intensity

Lux

lx

1.4.2. Data types

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

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

Table 3. Date and time format specifiers
Specifiers Meaning Example

yyyy

Year (four digits)

2011

M, MM

Month in year (without / with leading zero)

9, 09

d, dd

Day in month (without / with leading zero)

3, 09

H, HH

Hours, 0-23 count (without / with leading zero)

7, 07

m, mm

Minutes (without / with leading zero)

2, 02

s, ss

Seconds (without / with leading zero)

4, 04

F, FF, FFF

Milliseconds (without / with leading zeros)

357, 04, 002

Z

RFC 822 time zone (time shift to GMT)

+100

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

1.4.3. Modal verbs

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:

Table 4. Rules for using modal verbs
Provision Verbal form

Requirement
Requirements shall be followed strictly in order to be conform to the standard. Deviations are not allowed.

shall
shall not

Recommendation
Recommendations indicate that among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others.

should
should not

Permission
Permissions indicate a course of action permissible within the limits of the ASAM standard’s deliverables.

may
need not

Possibility and capability
These verbal forms are used for stating possibilities or capabilities, being technical, material, physical, or others.

can
cannot

Obligation and necessity
These verbal forms are used to describe legal, organizational, or technical obligations and necessities that are not regulated or enforced by the ASAM standard’s.

must
must not

1.4.4. Typographic conventions

This documentation uses the following typographical conventions:

Table 5. Typographical conventions
Mark-up Definition

Code elements

This format is used for code elements, such as technical names of classes and attributes, as well as attribute values.

Code snippets

This format is used for excerpts of code that serve as an example for implementation.

Terms

This format is used to introduce glossary terms, new terms and to emphasize terms.

1.4.5. Naming conventions for OpenSCENARIO references

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:

  • Name lookup shall start at the referencing element, but shall comprise all elements at all hierarchy levels of the scenario hierarchy.

  • Element names at each level shall be unique at that level. There shall not be more than one element with the same name at the same level (within the same directly enclosing element). For example, within one Story, every Act shall use a unique name ("MyStory1": "MyAct1", "MyAct2"…​), but the names of the acts may be reused in another story ("MyStory2": "MyAct1", "MyAct2"…​).

  • If the referenced name is globally unique, then it may be used directly as the only part of the reference. If the referenced name is not globally unique, name prefixes shall be be used to make the name unique.

  • A name prefix consists of the name of a directly enclosing element, which is prefixed to the name using the separator '::', thus forming a new name reference. This implies that the '::' must not be used in names itself. The name is disambiguated by the "::" specifying a directly enclosing element name.

  • Multiple prefixes of subordinate enclosing elements may be specified, up to the root element name, until a globally unique reference name is established.

  • If a reference cannot be resolved uniquely, for example, if too few name prefixes have been specified the result of the lookup is undefined.

1.5. Contributing to OpenSCENARIO

OpenSCENARIO is maintained by ASAM. Like all ASAM standards, it grows and changes over time. To reflect these changes, ASAM regularly launches projects to enhance OpenSCENARIO, keep it up to date, and adapt it to the latest industry requirements. All ASAM members, regardless of the background of their company, are welcome to contribute to these projects by bringing in their broad range of knowledge. Only by combining the expertise of various experts, OpenSCENARIO reaches the widest possible audience.

All new projects regarding OpenSCENARIO and other ASAM standards can be found on the ASAM website.

2. Releases and relations to other standards

2.1. Earlier releases of OpenSCENARIO

Table 6. Revision history of OpenSCENARIO
Version number Release date Comments

v1.1.0

2021-03-18

v1.0.0

2020-03-13

Transfer to ASAM

v0.9.1

2018-09-01

2.2. Relations to other ASAM standards

OpenSCENARIO is part of the ASAM simulation standards that focus on simulation data for the automotive environment. The standard can be used together with road network descriptions defined according to the standard ASAM OpenDRIVE and the description of the road surface described by ASAM OpenCRG. The three standards complement each other, together defining the content required to describe the simulated world. When combined, all three standards provide a scenario-driven description of traffic simulation that contains both static and dynamic content.

2.3. Relations to other non-ASAM standards

The terminology of OpenSCENARIO is based on the ISO standard 8855:2011 [5]. OpenSCENARIO can be complemented by other logical road network as well as 3D model standards. The following list gives some examples:

  • Logical road network

    • Navigation Data Standard (NDS) [6]

  • 3D models of road, scenery and objects

    • CityGML [7]

    • OpenSceneGraph [8]

    • glTF (Khronos Group) [9]

    • FBX (Autodesk) [10]

    • 3ds (Autodesk) [11]

3. General concepts of OpenSCENARIO

3.1. Architecture

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, OpenSCENARIO covers two main aspects:

  • Designing a scenario (design time)

  • Executing a scenario (runtime)

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.

OpenSCENARIO does not describe all these aspects in detail. 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.

3.1.1. Basic architecture components

The OpenSCENARIO architecture contains the following basic components:

  • An OpenSCENARIO Model Instance (OSC Model Instance) represents a scenario description in the solution space defined by the data model.

  • An OpenSCENARIO Director (OSC Director) is a component that interprets the OSC Model Instance and governs the progress of a scenario in a simulation. The OSC Director is the component responsible for running the scenario.

  • A Simulator Core. The Simulator Core is defined as all components other than OSC Director or OSC Model Instance that are needed to run a simulation. The Simulator Core is an external concept to OpenSCENARIO and provides an interface to the OSC Director for orchestrating the traffic situations defined in the scenario.

Figure 1 illustrates how the components interact:

image
Figure 1. OpenSCENARIO base architecture
This architecture is a simple abstraction to help understand how a scenario is coupled to a running simulation. It is not the intent of the OpenSCENARIO standard to prescribe a formal software architecture for simulator implementation. The provided architecture informally illustrates how components are separated and how interaction can be achieved. Implementation-specific details are not part of this architecture, even though the ideas and concepts might be useful when designing a simulation or designing a scenario.

3.1.2. OpenSCENARIO elements

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. OpenSCENARIO clearly states which elements shall be encapsulated in a OSC Director and which elements are managed by a Simulator Core.

Elements of the OSC Director

The OSC Director manages the lifecycle of the following elements:

  • Storyboard (1 per scenario)

  • Story instances (0..* per Storyboard)

  • Act instances (1..* per Story)

  • ManeuverGroup instances (1..* per Act)

  • Maneuver instances (0..* per ManeuverGroup)

  • Event instances (1..* per Maneuver)

  • Action instances (1..* per Event)

The OSC Director performs the nested and concurrent execution of the elements above. This includes:

  • Forking into different execution paths.

  • Joining from different execution paths.

  • Loop execution (ManeuverGroup , Event) for maximumExecutionCount > 1.

Section 4.2 describes the runtime behaviour of storyboard elements in detail.

Elements in the Simulator Core

OpenSCENARIO also requires an abstract understanding of elements that are not under the responsibility of the OSC Director at runtime. These are:

  • Entities representing traffic participants, such as vehicles and pedestrians.

  • Environmental parameters, such as time of day, weather, and road conditions.

  • Traffic signal controllers and traffic signals.

  • Traffic objects, such as swarms of vehicles, sources for vehicles, and sinks of vehicles.

  • Controllers: Default controllers, user-defined controllers like simulated drivers, or drivers in the loop.

  • Control strategies: Entity control instructions that originate from actions.

  • User parameters.

Element states

Elements generally have a set of property values at runtime. Because properties and relations, for example speed and position, may change during the simulation the complete set of property values and relations at a specific time represents the state of an element.

Static elements

A static element is a stateless component that does not change during runtime. Examples of static elements are the road network and road surface descriptions. These resources may be shared between OSC Director and Simulator Core.

3.1.3. Executing a scenario

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.

3.1.4. Actions and conditions

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.

image
Figure 2. Actions and conditions
Figure 2 illustrates the idea behind the logical concepts. It is not an implementation recommendation or guideline and does not intended to represent interactions between programs or define software protocols. Condition evaluation, for example, could also be implemented with a publish-subscribe mechanism on the trigger level.

In OpenSCENARIO, actions are the exclusive mechanisms for controling 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 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, 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 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 4.

3.1.5. Abstract OpenSCENARIO architecture

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 3 illustrates the architecture of OpenSCENARIO.

image
Figure 3. Abstract OpenSCENARIO architecture
The architecture depicted in Figure 3 illustrates the logical relations between the identified components and interfaces. It is not meant to prescribe a formal software API.

3.2. Road networks and environment models

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 OpenSCENARIO. Those references are established within the RoadNetwork language element. As an example, the 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. 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 OpenSCENARIO:

  • Individual road

  • Lane within a road

  • Traffic signal

  • Traffic signal controller

  • Road object

As mentioned before, a road network description supported by OpenSCENARIO is the 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 OpenDRIVE is used to represent the road network, the OpenSCENARIO file should follow the 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 OpenSCENARIO format.

It is also possible to outsource some parts of the scenario description to an external Catalog file. The process for referencing external scenario parts is described in Section 6.4

3.3. Coordinate systems

Following the ISO 8855:2011 [5] convention, a coordinate system consists of a set of three orthogonal directions associated with X, Y, Z axes (an axis system) and a coordinate origin. In OpenSCENARIO, there are two main types of coordinate systems:

  • A right-handed coordinate system, compliant with the ISO 8855:2011 [5] definition. Orientation is expressed by a heading(yaw)-pitch-roll sequence of rotations (see Figure 4)

    image
    Figure 4. Heading, pitch, and roll angle in an ISO 8855:2011 compliant coordinate system

  • A right-handed, road-based coordinate system defined by two coordinate axes associated with the reference line of the corresponding road (s-axis) and the direction orthogonal to it (t-axis) and pointing leftwards (see Figure 5)

    image
    Figure 5. Road-based s/t-coordinate system with origin at the beginning of the road

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

3.3.1. World coordinate system (Xw, Yw, Zw)

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

Neither origin nor orientation of the world coordinate system are defined by the 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.

3.3.2. Road coordinate system (s/t)

To every road specified in the world coordinate system there is an s/t-type coordinate system assigned. The s-axis follows road reference line while the t-axis, orthogonal to the s-axis, points left. The origin of the s-coordinate resides at the start point of the road. The origin of the t-coordinate is fixed to the road center line at the current s-position.

3.3.3. Lane Coordinate System (s/t)

To every lane specified in a lane section of a road there is an s/t-type coordinate system assigned. The s-axis follows the lane center line while the t-axis, orthogonal to the s-axis, points left. The origin of the s-coordinate resides at the mid point between the lane’s left and right boundaries at the very start of its lane section. The origin of the t-coordinate is fixed to the lane center line at the current s-position.

3.3.4. Vehicle coordinate system (Xv, Yv, Zv)

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

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

image
Figure 6. Vehicle coordinate system

3.3.5. Pedestrian / MiscObject coordinate system (Xp/m , Yp/m , Zp/m)

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.

3.3.6. Geographic coordinate system (latitude, longitude, height)

The geographic coordinate system is a spherical coordinate system of type (latitude, longitude, height). Latitude and longitude axes are parallel to the ground plane. The height axis points upward.

Neither origin nor orientation of the geographic coordinate system are defined by OpenSCENARIO. If a road network is referenced from a scenario, the geographic coordinate system is aligned with the geographic coordinate system present in the road network. The offset in coordinates and in orientation between world coordinate system and geographic coordinate system shall be defined in the road network.

3.3.7. Positioning

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

  • Absolute/relative in the world coordinate system

  • Absolute in the geographic coordinate system

  • Relative to another Entity

  • Absolute/relative in the road coordinate system

  • Absolute/relative in the lane coordinate system

  • Relative to a Route

  • Relative to a Trajectory

3.4. Distances

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:

  • Two points.

  • A point and an Entity (with or without bounding box considerations).

  • Two entities (with or without bounding box considerations).

The general term point used in this chapter may be replaced with the OpenSCENARIO specific term position. Within the scope of this chapter, both terms can be used interchangeably.

Distances in OpenSCENARIO may be measured in two ways:

  • From a local coordinate system, with lateral and longitudinal distance in an Entity, road, lane, or trajectory coordinate system.

  • In absolute context, that is Euclidean distance.

OpenSCENARIO assumes distances to be greater than equal to zero, (ℝ+0).

3.4.1. Visualization

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

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

image
Figure 7. Parts are not shown in road visualizations.

3.4.2. Referring to distances in OpenSCENARIO

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

3.4.3. Euclidean distance

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

image
Figure 8. Euclidean distance dAB between two points A/B

3.4.4. Distances in an entity coordinate system

Given two points A = (XA , YA , ZA) and B = (XB , YB , ZB) in the coordinates of a specific Entity, the definition in OpenSCENARIO is:

  • Longitudinal Entity distance - (dXAB): |XB - XA |

  • Lateral Entity distance - (dYAB): |YB - YA |

image
Figure 9. Longitudinal entity distance dXAB and lateral entity distance dYAB between point A and point B in entity referentials

3.4.5. Distances in road coordinates

Given two points in road coordinates A = (sA , tA , hA) and B = (sB , tB , hB), the definition in OpenSCENARIO is:

  • Longitudinal road distance: dsAB: |sB - sA|

  • Lateral road distance: dtAB: |tB - tA|

image
Figure 10. Longitudinal road distance dsAB and lateral road distance dtAB between point A and point B in road referentials

3.4.6. Lane distance and trajectory distance

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

  • Distances measured in the lane referential use the lane center as a reference line, rather than the road reference line.

  • Distances measured in the trajectory referential use the trajectory as a reference line, rather than the road reference line.

Trajectories do not define a road plane and thus no lateral direction. Trajectories shall be projected onto a road or plane, depending on the definition for measuring unambiguous lateral trajectory distances.

3.4.7. Involving an entity in a distance calculation

In addition to distances between two points, 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).

freeSpace = false

In this case, the bounding boxes of the entity shall not be considered. The point of the entity used to calculate the distance is the entity’s origin. That means:

  • The distance between point P and Entity E is the distance between point P and Entity E’s origin (E0), as shown in Figure 11.

image
Figure 11. Distances between a point P and an entity E, with freespace = false

In this case, the bounding boxes of the Entity shall be considered. Which point is chosen depends on the desired distance type.

  • The distance between Entity E and Entity F is the distance between their origins (E0, F0), as shown in Figure 12.

image
Figure 12. Distances between an entity E and an entity F, with freespace = false.
freeSpace = true

For distances between entities and reference points:

  • In the Entity referential, if the desired distance is the Euclidean distance, then the point of interest is the point on the bounding box of the Entity which yields the lowest distance value to the reference point.

  • If the desired distance is longitudinal, then the point of interest is the point on the bounding box of the Entity that yields the lowest longitudinal distance to the reference point.

  • If the desired distance is lateral, then the point of interest is the point on the bounding box of the Entity that yields the lowest lateral distance to the reference point.

image
Figure 13. Distances between a point P and an entity E, with freespace = true.
If freeSpace = true, the distance between an Entity and a point on or in its bounding box is zero.

For distances between entities:

  • In the Entity referential, if the desired distance is the Euclidean distance, then the points of interest are the two points on the entities' bounding boxes that yield the lowest distance.

  • If the desired distance is longitudinal, then the points of interest are the two points on the entities' bounding boxes that yield the lowest longitudinal distance.

  • If the desired distance is lateral, then the points of interest are the the two points on the entities' bounding boxes that yield the lowest lateral distance.

image
Figure 14. Distances between an entity E and an entity F, with freespace = true.
If freeSpace = true, the distance between two entities whose bounding boxes intersect is zero.

3.5. Controllers

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

A Controller 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:

  • Specifying that a vehicle is controlled by the system under test.

  • Defining smart actor behavior, where a controller takes intelligent decisions in response to the road network or other actors. Hence, controllers can be used, for example, to make agents in a scenario behave in a human-like way.

  • Assigning a vehicle to direct human control.

By default, controllers are assigned in a deactivated state.

3.5.1. Controller types

OpenSCENARIO defines two types of controllers:

  • The default controller that enforces control strategies exactly as they are described by the actions.

  • An user-defined controller that may have custom interpretations of control strategies.

The default controller is expected to enforce control strategies along the entity dimensions that do not have a user defined controller.

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 OpenSCENARIO in a broader scope, interpreting Action as suggestions rather than commands. Repeatable simulation results are only expected when using default controllers.

3.5.2. Controlling a scenario object

A maximum of two controllers shall be defined for the same ScenarioObject dimension. If a second controller is activated for a dimension, it deactivates the currently active controller on that dimension.

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 23 illustrates the coupling between controllers, entities, and control strategies.

3.5.3. Assigning a user-defined controller

A user-defined controller is assigned with the AssignControllerAction:

<AssignControllerAction>
    <Controller name="HAF_Driver"/>
</AssignControllerAction>

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

<ScenarioObject name="Ego">
    <CatalogReference catalogName="VehicleCatalog" entryName="car_white"/>
    <ObjectController>
        <Controller name="HAF_Driver"/>
    </ObjectController>
</ScenarioObject>

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

3.5.4. Activating a user-defined controller

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

3.5.5. Assigning the default controller

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 OpenSCENARIO Model Instance.

3.5.6. Activating the default controller

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

At runtime, the default controller is activated for a given motion 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.

3.6. Routes

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 last Waypoint shall be used.

The implementation of this strategy may vary between simulators. In order to create unambiguous routes, the user must specify a sufficient number of waypoints. As long as the waypoints describe an unambiguous path, the corresponding route specifies a one-dimensional s-coordinate system that enables unambiguous localization and positioning.

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

If an Entity is on a route, it normally continues along the same route when it reaches a junction. However, actions involving routes are not lateral actions and do not override or create lateral actions. This means that a route is not followed along if the corresponding entity is in the wrong lane or conflicting lateral behavior is defined, for example, an Action involving a Trajectory. In these cases, the route is ignored.

An Actor is still considered "on the route" if it is on a road section that does not have a waypoint on it but is part of the route between waypoints as calculated at execution time.

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.

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 it passes the same road section several times, as shown in Figure 15.

  • If the route does not contains loops, the actor ignores the part of the route ranging from the first waypoint of the route to the position where the actor enters the route. The actor follows the remaining part of the route starting at the actors current position.

If the route does contain loops, see Figure 15 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:

  • Where an entity is on a road that belongs to more than one link between waypoints, the entity shall be treated as being on the earliest link which has not been followed yet.

    • If an entity joins the route just before Waypoint 2, it is treated as being on the link between Waypoint 1 and Waypoint 2 (and not between 3 and 4).

  • Instances of Entity only follows later links than the one they are currently on.

    • If an entity joins the route just after Waypoint 3, it goes towards Waypoint 4, then 5.

  • When an entity leaves then rejoins a route or reaches the final waypoint, any previously visited waypoints shall be ignored.

    • If an entity is teleported to waypoint 1 after reaching waypoint 4, it follows the route as if for the first time.

    image
    Figure 15. Route passing the same road section twice

When a route consists of a consecutive, unambiguous series of roads from its start to finish, InRoutePosition. PositionInRoadCoordinates and InRoutePosition.PositionInLaneCoordinates may be used to define points relative to the continuous reference line of the road or lanes. An example of this is shown in Figure 16.

image
Figure 16. A route consisting of roads with a continuous reference line and PositionInRoardCoordinates

3.7. Trajectories

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:

  • Polyline: A concatenation of simple line segments across a set of vertices.

  • Clothoid: Euler spiral, meaning a curve with linearly increasing curvature.

  • Non-Uniform Rational B-Splines (Nurbs) of arbitrary order.

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

3.7.1. Entity is not at the start of trajectory, timeReference is not set

Starting conditions:

  • When the FollowTrajectoryAction starts, the entity is not at the beginning of the trajectory.

  • Time references are not set.

Expected behavior:

  • If the followingMode is position, the entity teleports to the beginning of the trajectory.

  • If the followingMode is follow, the controller attempts to steer as close to the trajectory as possible. Because the timeReference is not defined, the controller steers towards the point that bring the entity in line with the trajectory as soon as feasible. Considering the current position, orientation, and performance limitations of the entity, this is possibly not the start point of the trajectory, and maybe not even the geometrically closest point, as shown in Figure 17.

image
Figure 17. Entity is not at the start of the trajectory

3.7.2. Entity is not at the start of trajectory, timeReference is set (in the future)

Starting conditions:

  • When the FollowTrajectoryAction starts, the entity is not at the beginning of the trajectory.

  • The time reference is set at beginning of the trajectory (t1), the time reference is later than the current time (t < t1).

Expected behavior:

  • If the followingMode is position, the action starts, but the entity keeps moving as before until t1 is reached. At t = t1, the entity teleports to the start of the trajectory, and continues along the trajectory.

  • If the followingMode is follow, the entity immediately starts steering towards the trajectory, with the aim to be at the trajectory start at t = t1.

3.7.3. Entity is not at the start of trajectory, timeReference is set (in the past)

Starting conditions:

  • When the FollowTrajectoryAction starts, the entity is not at the beginning of the trajectory.

  • The time reference is set at beginning of the trajectory (t1), the time reference is earlier than the current time (t > t1).

Expected behaviour:

  • If the followingMode is position, the entity behaves as if the trajectory starts at the position interpolated between the most recent time reference and the earliest future time reference. The entity teleports to that position and continues along the trajectory.

  • If the followingMode is follow, the entity starts steering towards the trajectory, aiming to hit the first referenced point in the future and taking into consideration the performance limitations.

3.7.4. Entity is at an ambiguous point near the trajectory

Starting conditions:

  • The entity is located in vicinity to more than one waypoint or segment connecting the waypoints.

Expected behavoiur:

  • The entity joins at the first possible segment, according to the user-defined orientation of the trajectory and respecting time references, if given. See section on Section 3.6 and previous points in this section.

image
Figure 18. Entity is at an ambiguous point near the trajectory

3.7.5. Trajectory-relative positions

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

image
Figure 19. Trajectory position example

3.8. Traffic simulation

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

  • Make the scenario more realistic.

  • Induce variances into the scenario sequence.

  • Define traffic parameters, such as traffic density.

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

3.9. Properties

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

  • Vehicle

  • Pedestrian

  • MiscObject

  • Controller

  • RoadCondition

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.

3.10. Traffic signals

Traffic signals introduce two main aspects into simulation:

  1. Position and rendering of traffic signals and their possible state in a simulation. Locations are defined in the road network. Rendering is specific to the simulator.

  2. The dynamic behavior that describes how and when the traffic signals change during a simulation. This is defined in OpenSCENARIO with referencing the objects in the road network.

3.10.1. Traffic signal controllers

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

3.10.2. Traffic signal definition

Traffic signals are declared in the RoadNetwork section of a scenario file. TrafficSignalController instances are wrapped around their phases and their traffic signal states. A TrafficSignalController references a traffic controller instance in the road network with the name attribute.

<RoadNetwork>
  <LogicFile/>
  <SceneGraphFile/>
  <TrafficSignalController name="RoadNetwork_ID1">
    ...
  </TrafficSignalController>
  <TrafficSignalController name="RoadNetwork_ID2">
    ...
  </TrafficSignalController>
  ...
</RoadNetwork>

3.10.3. Connecting traffic signal controllers

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

<RoadNetwork>
  <LogicFile/>
  <SceneGraphFile/>
  <TrafficSignalController name="RoadNetwork_ID1">
    ...
  </TrafficSignalController>
  <TrafficSignalController name="RoadNetwork_ID2"
                           delay="10"
                           reference="RoadNetwork_ID1">
    ...
  </TrafficSignalController>
  ...
</RoadNetwork>

3.10.4. Phases

TrafficSignalController provides an ordered list of phases. A phase represents a dynamic element of a traffic signal controller and defines a duration and a name. The simulation sequentially runs through the phases of the declared traffic signal controller while executing the scenario with respect to each duration. The list of phases 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 phases' durations. The first phase starts with the execution of the storyboard.

Phases are connected to TrafficSignalStates. Because a traffic signal controller controls multiple traffic signals, each traffic signal is represented by a state during a specific phase.

In the current version, interpretation and notation of state are specific to the simulation engine used.

In the following example, traffic signals are encoded with boolean values:

<TrafficSignalController name="6">
  <Phase name="stop" duration="25">
    <TrafficSignalState trafficSignalId="8594" state="true;false;false"/>
    <TrafficSignalState trafficSignalId="8595" state="true;false;false"/>
  </Phase>
  ...
</TrafficSignalController>

4. Components of a scenario

4.1. Overview of a scenario

To represent a traffic situation, an OpenSCENARIO model instance is built up of four main components:

  • Road network: mapping of the different driving surfaces and all relevant elements of the road infrastructure, like traffic signals.

  • Entities: road users, including vehicles, pedestrians, and other miscellaneous objects that interact during a scenario.

  • Actions: basic building blocks to define dynamic behavior of the entities. It may also be used to modify simulation states or components of the simulated world.

  • Triggers: mechanism that determines when an action starts or stops. It is built on logical expressions revolving around the states of entities or the simulation.

It is possible to design a scenario without a road network but it restricts the application of certain OpenSCENARIO actions.

The structure of the OpenSCENARIO 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 OpenSCENARIO structure, how the different components fit in the structure, and how these components relate to one another.

4.2. Storyboard and entities

4.2.1. Storyboard

In 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 OpenSCENARIO Storyboard element consists of the following elements:

  • Init: Initialization element that sets the intial states of the scenario elements, such as the position and speed of instances of Entity. It is not possible to specify conditional behavior in this section.

  • One or more Story elements (optional): Story elements enable scenario authors to group different scenario aspects into a higher-level hierarchy and thus create a structure for large scenarios.

  • stopTrigger: determines the end of the scenario.

Instances of Story in 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 4.3.1) in the included Maneuver instances. Maneuver groups may also include catalog references with predefined maneuvers. This concept is described in Section 6.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 20 illustrates the components of a storyboard.