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


ASAM e. V. (Association for Standardization of Automation and Measuring Systems) is a non-profit organization that promotes standardization of tool chains in automotive development and testing. Our members are international car manufacturers, suppliers, tool vendors, engineering service providers and research institutes. ASAM standards are developed by experts from our member companies and are thus based on real use cases. They enable the easy exchange of data or tools within a tool chain. ASAM is the legal owner of these standards and responsible for their distribution and marketing.

ASAM standards define file formats, data models, protocols and interfaces for tools that are used for the development, test and validation of electronic control units (ECUs) and of the entire vehicle. The standards enable easy exchange of data and tools within a tool chain. They are applied worldwide.



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.

overview open x
Figure 1. Relationship between ASAM OpenSCENARIO, ASAM OpenDRIVE, and ASAM OpenCRG

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


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

  • 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, entity appearance, pedestrians, traffic and environment conditions, is included in the standard as well.

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

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

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

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

Table 1. What is not part of ASAM OpenSCENARIO
Feature Description

Test configuration description

ASAM OpenSCENARIO does not describe a test instance or its structure.

Test case language

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

Test evaluation

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

Driver model

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

Vehicle dynamics

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

Environmental models

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

Conventions and notations

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 Modal verbs, are normative.

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

Naming conventions

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


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 Name Symbol




Duration, (relative) time




Meters per second



Meters per second squared



Meters per second cubed






Newton meter








Angle (geo referencing)






Luminous intensity









Data types

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

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

Table 3. Date and time format specifiers
Specifiers Meaning Example


Year (four digits)



Month in year (without / with leading zero)

9, 09

d, dd

Day in month (without / with leading zero)

3, 09


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


Milliseconds (without / with leading zeros)

357, 04, 002


RFC 822 time zone (time shift to GMT)


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:


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

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

shall not

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

should not

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

need not

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


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 not

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, and language elements.


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


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:

  • User Guide, this document

  • XML schema file

  • UML model

  • UML Model reference documentation (HTML)

  • Examples

  • Migration scripts and schemas

  • Modeling guidelines

Revision history

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



Bugfix Release





Transfer to ASAM




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

  • Support for virtual sensor recognition testing​

    • Reference to sky & illumination image​

    • More options for custom properties​

  • Support for sensor error injection​

    • False positive / false negative for entities​

  • Introduction of variables​

    • Separated concept from parameters​

    • Can change during runtime

    • External access​

  • Support for multiple controllers​

    • Lateral and/or longitudinal​

    • Two new controller types (animation / light)​

  • Improvement in controller overrides​

    • Physical values​

    • Dynamic limitations (max rate, max torque)​

  • New entity role​ attribute

    • Police, ambulance…​​

  • New Light action​

    • Vehicle lights​

  • New Animation action​

    • Vehicle components (doors, windows, mirrors)

    • Pedestrian motions​ & gestures

    • Reference to 3d animation files​

  • New Speed profile action​

    • For modelling of realistic speed profiles​

  • Extended Traffic Swarm action​

    • Velocity range​

    • Direction of travel​

  • Extended Speed & acceleration condition​

    • Check per dimension (lateral, longitudinal, both)​

  • New Clearance condition​

  • Clarifications​

    • Coordinate systems & rotations​

    • Position types (esp. Road/Lane)​

    • Relative and absolute orientation in positions + defaults​

    • Speed (longitudinal/lateral domain)​

    • Distance calculations across several roads​

    • Route calculation​

    • Route assignment​

    • Closed trajectory​

    • Interfacing between scenario and test case / runtime environment​

    • Dynamic constraints of entities in actions​

    • Action prerequisites​

    • Add / remove entity actions​

  • Fixes​

    • Datatype integer → int​

    • Gear number: double → int for manual and enum for automatic gear

    • Overwrite → override​

    • State machine states (standby vs. complete)​

    • GeoPosition in degree​

  • Harmonization​

    • Cloud state (ASAM OSI)​

    • Traffic signal controller (ASAM OpenDRIVE)​

Complementary standards and formats

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

  • Logical road network

    • Navigation Data Standard (NDS) [5]

  • 3D models of road, scenery and objects

    • CityGML [6]

    • OpenSceneGraph [7]

    • glTF (Khronos Group) [8]

    • FBX (Autodesk) [9]

    • 3ds (Autodesk) [10]

1. Scope

ASAM OpenSCENARIO specifies the modeling approach how to describe dynamic content in driving application simulations using the Extensible Markup Language (XML).

The ASAM OpenSCENARIO standard

  • specifies the schema for ASAM OpenSCENARIO in an UML model and an XSD schema. The UML model and the XSD schema defines the structure, sequence, elements, and values of ASAM OpenSCENARIO. The XSD schema is derived from the UML model.

  • provides the XSD schema to which valid ASAM OpenSCENARIO files shall conform.

  • explains how the ASAM OpenSCENARIO elements are used and relationships between elements in the ASAM OpenSCENARIO UML model and XSD schemas, for example, actions, entities, a road network, and triggers.

2. Normative References

The following documents are referred to in the text in such a way that some or all of their content constitutes some of the requirements set out in this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

  • ASAM OpenDRIVE [1]

  • ASAM OpenCRG [2]

  • ISO 8855 [11]

  • ISO 8601 [4]

  • W3C XML Schema Definition Language [3]

3. Terms and definitions

Ego vehicle

Source: DIN SAE SPEC 91381 [12]

The vehicle(s) that is (are) the focus of a scenario, meaning the vehicle(s) under test. For evaluation of automated driving systems, the Ego vehicle is the vehicle controlled by the system-under-test. For human driver experiments, the Ego vehicle is the vehicle driven by the human driver. There may be zero, one, or multiple Ego vehicles within a scenario.


Source: DIN SAE SPEC 91381 [12]

The use of parameters, which are symbols that may be replaced by concrete values at a later stage according to either user needs or stochastic selection.


Source: DIN SAE SPEC 91381 [12]

Everything that falls within the spatial extent of a scenario and therefore may form a part of the scenario description.

4. Abbreviations




Association for Standardization of Automation and Measuring systems


Central European Time


Curved Regular Grid


Electronic Control Unit


World reference frame "East, North, Up"


Hypertext Markup Language




Open Simulation Interface


Systéme international (d' unités)


Unified Modeling Language


Extensible Markup Language


XML Schema Definition


Extensible Stylesheet Language Transformation

5. Backward compatibility

ASAM OpenSCENARIO version v1.2 is fully backward compatible to v1.1 as well as v1.0. That means, there is no need for migration. A strict XML schema file without the deprecated elements is provided, so that deprecated elements can be removed manually.

6. General concepts

6.1. Architecture

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:

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

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.

6.1.1. Basic architecture components

The ASAM 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 ASAM OpenSCENARIO and provides an not standardized interface to the OSC Director for orchestrating the traffic situations defined in the scenario.

Figure 2 illustrates how the components interact:

Figure 2. ASAM 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 ASAM 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.

6.1.2. ASAM 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. ASAM OpenSCENARIO clearly states which elements shall be encapsulated in an 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 7.2 describes the runtime behavior of storyboard elements in detail.

Elements in the Simulator Core

ASAM 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, drivers in the loop, or for the appearance of the ScenarioObject

  • Control strategies: Entity control instructions that originate from actions

  • Variables and user defined values

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.

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

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

Figure 3. Actions and conditions
Figure 3 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 ASAM OpenSCENARIO, actions are the exclusive mechanisms for controlling and modifying the content of a simulation. Conditions are the exclusive mechanisms for evaluating the status information of a simulation.

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

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

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

6.1.5. Abstract ASAM 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 4 illustrates the architecture of ASAM OpenSCENARIO.

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

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

  • Individual road

  • Lane within a road

  • Traffic signal

  • Traffic signal controller

  • Road object

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.

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 9.4

6.3. Coordinate systems

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

  • A coordinate system that consists of three orthogonal directions associated with X, Y, and Z axes and a coordinate origin where axes meet, defines the right-handed Cartesian coordinate system. It is compliant with the ISO 8855:2011 [11] definition. Orientation of road objects is expressed extrinsically by the heading (yaw), pitch, and roll angles derived from the sequence of rotations in the order: Z-axis, then Y-axis, then X-axis. The positive rotation is assumed to be counter-clockwise ("right-hand rule", see Figure 5):

    Figure 5. Heading, pitch, and roll angle in an ISO 8855:2011 compliant coordinate system
  • A road-based coordinate system that consists of 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. The definition of the s- and t-axes depends on the reference part of the road in use (see Figure 6):

    Figure 6. Road-based s/t-coordinate system with origin at the beginning of the road
  • A coordinate system associated with positions on the earth and defined by the corresponding terrestrial reference system (geodetic datum) in use.

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

6.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 ASAM OpenSCENARIO standard. If a road network is referenced from a scenario, the world coordinate system is aligned with the inertial coordinate system present in this description (in particular, the Zw-coordinate is assumed to consider a road elevation, an entire road super-elevation, or a lateral road shape profile).

6.3.2. Road coordinate system (s/t)

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

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

The following constraints are defined:

  • It is assumed the s-axis line has a smooth shape (no leaps nor kinks).

  • Being two-dimensional by its nature, the Road coordinate system does not define any vertical positioning. This means positions, specified with (s/t)-coordinates, are on the road surface.

  • Both s- and t-coordinates are applicable within boundaries of the respective road only.

  • In the case of multiple chained roads, each road defines its own s-axis.

  • In the case of roads with a complex lateral profile (for example, uneven surface), applicability and conversion of s/t-coordinates into other coordinate systems might appear problematic or even impossible.

6.3.3. Lane coordinate System (s/t)

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

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

The following constraints are defined:

  • It is assumed the s-axis line has a smooth shape (no leaps nor kinks).

  • Being two-dimensional by its nature, the Lane coordinate system does not define any vertical positioning. This means positions, specified with (s/t)-coordinates, are on the road surface.

  • S-coordinates are applicable within the length of the respective lane section only.

  • T-coordinates are applicable within the width of the respective road only.

  • In the case, a road contains multiple lane sections, each lane section defines its own set of lanes with their own s-axes.

  • In the case of roads with a complex lateral profile (for example, uneven surface), applicability and conversion of s/t-coordinates into other coordinate systems might appear problematic or even impossible.

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

The vehicle axis system of type (X, Y, Z), as defined in ISO 8855:2011 [11], is fixed in the reference frame of the vehicle sprung mass. The 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 ASAM OpenSCENARIO, the origin of this coordinate system is derived by projecting the center of the vehicle’s rear axis to the ground plane at neutral load conditions. The origin remains fixed to the vehicle sprung mass, as illustrated in Figure 7.

Figure 7. Vehicle coordinate system

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

6.3.6. Trajectory coordinate system (s/t)

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

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

The following constraints are defined:

  • Being two-dimensional by its nature, the Trajectory coordinate system does not define any vertical positioning. This means positions, specified with (s/t)-coordinates, are on the road surface.

  • S-coordinates are applicable within the length of the respective trajectory line only.

  • T-coordinates are applicable within boundaries of the respective road only.

  • If a trajectory line has a polyline shape, t-axes are undefined at points where the line has sharp kinks.

  • In the case of roads with a complex lateral profile (for example, uneven surface), applicability and conversion of s/t-coordinates into other coordinate systems might appear problematic or even impossible.

6.3.7. Geographic coordinate system (latitude, longitude, altitude)

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

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

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

6.3.8. Positioning

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

  • Absolute in the world coordinate system

  • Absolute/relative 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

6.4. Distances

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:

  • 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 ASAM OpenSCENARIO specific term position. Within the scope of this chapter, both terms can be used interchangeably.

Distances in ASAM 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

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

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

Figure 8. Parts are not shown in road visualizations.

6.4.2. Referring to distances in ASAM OpenSCENARIO

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

6.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 9. It is unambiguously defined in ℝ3, independently from the coordinate system that describes the coordinates.