ASAM OpenSCENARIO comprises the specification and file schema for the description of dynamic content in driving simulation applications. The primary use case of ASAM OpenSCENARIO is the description of predictable, highly precise scenarios that include complex maneuvers of multiple vehicles.

ASAM OpenSCENARIO may be used with external test specifications 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.

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 conditions, 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 predictable and highly precise 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. A primary use case describes the main use case for which the standard is intended and a key consideration behind many design decisions. The primary use case is not exclusive. The standard may be (and is) used for a wide variety of additional use cases. The description of a scenario may also be based on driver actions (performing a lane change) or on trajectories (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 and create scenario variations.

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. The use of the XML standard allows for simple machine parsing and processing. Simulation tools and content editors can validate, edit, import and export this structured format.

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 and deliverables

This Specification 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, meaning 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)

7, 07, 007


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 ASAM OpenSCENARIO specification, users need to be able to distinguish between requirements, recommendations, permissions, possibilities and capabilities, and external constraints.

The following rules for using modal verbs apply:

Table 4. Verbal forms for expressions of provisions
Provision Verbal form Definition


shall, shall not

A requirement conveys objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed.


should, should not

A recommendation conveys a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others.



A permission conveys consent or liberty (or opportunity) to do something.

Possibility and capability

can, cannot

A possibility conveys expected or conceivable material, physical or causal outcome.
A capability conveys the ability, fitness, or quality necessary to do or achieve a specified thing.

External constraint


An external constraint or obligation on the user of the document, for example laws of nature or particular conditions existing in some countries or regions, that is not stated as a provision of the document. External constraints are not requirements of the document. They are given for the information of the user.

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.


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

Mathematical elements

This format is used for calculations and mathematical elements.


This describes a tag for an element within the XML specification.


The "@" identifies an attribute of any ASAM OpenSCENARIO element.


The following deliverables are provided for ASAM OpenSCENARIO:

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.3.0 compared to ASAM OpenSCENARIO v1.2.0:

  • New / improved features:

    • Trailer support

    • More functions in expressions

    • TrafficAreaAction

    • TrafficDistribution

    • Monitors (evaluation of scenario execution)

    • AngleCondition and RelativeAngleCondition

    • ClothoidSpline for trajectories

    • LogNormalDistribution for parameter values

    • RandomRouteAction

    • Storyboard / scenario stop trigger made optional

    • Act start trigger made optional

  • Clarifications:

    • Use-cases of ASAM OpenSCENARIO

    • End condition of LaneChangeAction

    • RelativeTargetLane in LaneChangeAction

    • Default route

    • Condition behavior (rising edge)

    • Vertical road selection for GeoPosition

    • Speed calculation in RelativeSpeedCondition

    • Number of executions of storyboard elements (Act, ManeuverGroup)

    • Calculation of s-coordinate for PositionInLaneCoordinates

    • Relative lane range in RelativeClearanceCondition

    • End of road in EndOfRoadCondition

  • Fixes:

    • XML schema:

      • XOR implementations corrected

      • Catalog name identifier made mandatory

      • Custom Properties made optional

      • Name identifier added to ObjectController for referencing

    • Trigger without ConditionGroup deprecated

    • Relative orientation definition in RoadPosition & LanePosition corrected

    • Lateral offset in LanePosition and RelativeLanePosition corrected

    • Default Orientation changed to relative

    • Example scenarios:

      • Documentation

      • Start / stop triggers

      • Controller handling

      • Negative rates

      • Global vs. local parameters

      • Parameter referencing

      • Realistic maneuvers

    • Example roads (connections corrected)

  • Harmonization

    • Traffic signals (ASAM OpenDRIVE, ASAM OpenSCENARIO DSL)​

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]