Introduction

Overview

To verify the safety and the correct functionality of an Autonomous Vehicle (AV) or an Advanced Driver Assistance System (ADAS), it is necessary to observe its behavior in various evolving situations. These evolving situations are called scenarios.

Using ASAM OpenSCENARIO, scenarios can be created that describe the behavior of the autonomous vehicle as well as other actors or entities in the environment.

ASAM OpenSCENARIO covers the following key concepts:

ASAM OpenSCENARIO is a domain-specific language.
The language is tailored for describing complex traffic system scenarios at various abstraction levels. ASAM OpenSCENARIO also provides a domain model that captures the central concepts of dynamic traffic systems in the form of types and actions that can be used as the basic building blocks when modeling scenarios.
ASAM OpenSCENARIO scenarios can be high-level abstract descriptions.
Many specific variants of a scenario can be created by varying the scenario parameters, for example, speed, vehicle type, weather conditions, and so on. Tools that support ASAM OpenSCENARIO can generate these variants automatically, within the constraints that can be specified. These tools then collect and aggregate parameter data from successful tests. This data enables to measure the safety of autonomous vehicles.
ASAM OpenSCENARIO is a programming language.
When designing and specifying scenarios, it is essential to think of them as software programs. To define complex behaviors, scenarios can be composed in different ways. For example, scenarios can invoke other scenarios in sequence or in parallel. One scenario can be chosen as the entry point for execution; executing this scenario leads to the execution of the behaviors that it is composed of.
ASAM OpenSCENARIO is a declarative language.
The language describes what should happen, rather than instructing how it should happen. The language uses constraints to specify these expectations.
ASAM OpenSCENARIO is a constraint-based language.
Concrete values can be specified for parameters, for example, vehicle speeds, scenario durations, execution orders, and so on. Also, constraints can be specified over these parameters. This allows to define scenarios in a more abstract way: A scenario model can be created that encompasses a whole family of many concrete scenarios.
ASAM OpenSCENARIO is an aspect-oriented programming language.
Given a base scenario model, its behavior can be modified to suit particular purposes:
- The whole behavior or aspects of the behavior can be modified.
- The behavior of some or of all instances of an object can be modified.
- The behavior can be modified to suit a particular test or simulation.
  
  All this can be done without disturbing the original description of the scenario.

Chapter overview

ASAM OpenSCENARIO consists of the following parts:

Section 6, "Conceptual overview"
The conceptual overview describes central concepts of ASAM OpenSCENARIO, particularly scenarios and key terminology.
Section 7, "Language reference manual"
The language reference manual contains a complete definition of the domain-specific language that is used to describe scenarios.
Section 8, "Domain model reference"
The domain model defines the entities needed to build scenarios. It defines different actions and properties of these entities.
Section 9, "User guide"
The user guide contains extension guidelines that explain how additional entities can be created and added to the domain model. It also provides guidelines on writing reusable scenarios and styling of ASAM OpenSCENARIO syntax.
Section 10, "Migrating from ASAM OpenSCENARIO 1.2.0"
The migration guide is a useful source of information for an audience that is already familiar with ASAM OpenSCENARIO 1.2.0 and would like to migrate scenarios to this version of ASAM OpenSCENARIO.

Target group

The following users were explicitly considered during the creation of ASAM OpenSCENARIO:

Auditors/regulators
AV/ADAS developer companies
Content or model developers
Development project leaders
Researchers
Safety engineers
Service providers
Software developers
Stakeholders
System engineers
Test engineers
Tool developers
Tool providers or consumers

Conventions and notation

Units

See Section 7.3.4, "Physical types and units".

Modal verbs

To ensure compliance with the ASAM OpenSCENARIO standard, users need to be able to distinguish between mandatory requirements, recommendations, permissions, as well as possibilities and capabilities.

The following rules for using modal verbs apply:

Table 1. Rules for using modal verbs
Provision	Verbal form
Requirements Requirements shall be followed strictly in order to conform to the standard. Deviations are not allowed.	shall shall not
Recommendations Recommendations indicate that one possibility out of the several available is particularly suitable, without mentioning or excluding the other possibilities.	should should not
Permissions Permissions indicate a course of action permissible within the limits of ASAM OpenSCENARIO deliverables.	may need not
Possibilities and capabilities Verbal forms used to state possibilities or capabilities, whether technical, material, physical, etc.	can cannot
Obligations and necessities Verbal forms used to describe legal, organizational, or technical obligations and necessities that are not regulated or enforced by the ASAM OpenSCENARIO standard.	must must not

Normative and informative content

Content in this standard can be normative or informative. The sections listed in Table 2 are normative or informative per definition.

Table 2. Normative and informative sections
Section	Indication
Foreword	Informative
Introduction	Informative
Scope	Normative
Normative references	Informative
Terms and definitions	Normative
Abbreviations	Normative
Annexes	Annexes can be normative or informative. The annex heading contains the indication "(normative)" or "(informative)".
Bibliography	Informative

All other sections in this standard are normative as long as not explicitly stated otherwise. Informative sections are highlighted using the non-normative tag:

Please note that the following section and its sub-sections are non-normative.

The non-normative tag is valid for the section and all of its sub-sections.

Typographic conventions

Table 3. Typographic 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.
Terms	This format is used to introduce glossary terms and new terms and to emphasize terms.

Notes for this version of ASAM OpenSCENARIO

This is the first release of the language. Scenario developers can find themselves in need of functionality that either does not exist yet or may have been left to be implementation-specific. The language offers self-extension capabilities as well as the ability to bind to external software (methods that are implemented in a different language or mechanism).

Consult the instructions on extending the domain model to use entities, actors, or actions that are not currently defined in the domain model (see Section 9.3, "Extending the domain model").

Scenario developers can use calls to external functions if they have to implement missing functionality. For example, this version of ASAM OpenSCENARIO does not define a built-in distribution function for parameter values. Such distribution functions can be implemented by an external method (see Section 7.3.7, "Methods" for the definition of external methods). Parameters can be constrained by such an external method (see Section 10.2, "Parameters" for an example).