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. -
ASAM OpenSCENARIO Migration
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
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:
Provision | Verbal form |
---|---|
Requirements |
shall |
Recommendations |
should |
Permissions |
may |
Possibilities and capabilities |
can |
Obligations and necessities |
must |
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.
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
Mark-up | Definition |
---|---|
|
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 Migration: Parameters for an example).