6.2 Key terminology

This section provides a summary of key terminology used throughout this standard.

6.2.1 Operational design domain (ODD)

The complete range of space where the system under test is expected to operate.

6.2.2 Action

A fundamental, non-decomposable behavior of an actor. An action is a piece of behavior that can be executed or observed. Actions are abstract and their actual implementation is platform-specific and outside of the scope of this standard.

6.2.2.1 Action details

Actions are used whenever the state of an actor is expected to change. Typical examples include:

  • A vehicle changing speed, changing lanes, or activating a turn signal.

  • Pedestrians walking on the sidewalk or crossing the street.

  • A traffic light changing color.

Actors may perform multiple actions simultaneously.

6.2.2.2 More information about actions

  • Actions constitute the fundamental building block for scenarios and a typical scenario is a composite of multiple actions (and, potentially, other scenarios).

  • The temporal or logical organization of actions within the scenario is achieved through temporal operators (for example, serial, parallel, or one_of) using events to trigger the start or end of an action, or both.

  • Unlike scenarios, actions are not intended to be decomposed into smaller parts.

  • Actions can consume zero or non-zero (simulation- or clock-) time to be executed.

  • Actions can be interrupted by instantiation of another action or invocation of another scenario.

6.2.3 Scenario

A description of the behavior or temporal evolution of physical objects and environmental conditions on the driving infrastructure over an interval of time, including the movement of traffic participants or the change of environmental conditions.

  • It is a base building block of the storyboard hierarchy.

  • It can represent a definition of a single action.

  • It can use composition operators to define equivalents to Event, Maneuver, Act, Story, and all the levels up to a description of a complete scenario of ASAM OpenSCENARIO 1.2.0.

Scenarios can be expressed in multiple levels of abstraction.

An ASAM OpenSCENARIO scenario can be used to define scenarios in the following contexts:

  • SOTIF (ISO 21448 – Safety of the intended functionality)

  • UNECE/WP.29 Regulations – World Forum For harmonization of vehicle regulations

  • [Euro] NCAP – New Car Assessment Program

  • Other safety or regulation frameworks

6.2.3.1 Scenario details

A full scenario description should answer the following questions:

  • Where does the scenario take place?

    • Answer: On the driving infrastructure of the driving domain (N1). The driving infrastructure includes the road layout, road furniture, and other static objects (like buildings and vegetation).

  • Who participates in the scenario?

    • Answer: Actors (like vehicles, objects, people, and traffic lights) participate in the scenario; environmental conditions (N2) (like weather and lighting) can be set or changed in the scenario, or both.

  • What do the participants do?

    • Answer: Actions describe the behavior of the actors; environmental actions (N2) describe changing environmental conditions during the scenario.

  • When do the actions take place?

    • Answer: This is achieved through the following language elements:

      1. Compositional operators

      2. Temporal directives

      3. Events

    • OpenSCENARIO compositional operators - such as serial, parallel, one_of, and so on - allow users to construct phases or temporal labels for when a scenario invocation or action instantiation occurs.

    • Temporal directives - such as wait, on, or until - reference events.

    • ASAM OpenSCENARIO events resolve to a specific point in time within the scenario.
      This allows users to:

      1. Resolve the start and/or end of a phase.

      2. Resolve a moment to take a measurement in the scenario.

6.2.3.2 More information about scenarios

  • A scenario may include a specification of validity criteria.

  • OpenSCENARIO language enables a scenario to include commands to control the test execution platform.

  • A scenario may refer to simulations, physical tests, driving data, or any combination thereof.

  • There is not necessarily a one-to-one relation between one scenario and one ASAM OpenSCENARIO file.

  • A single ASAM OpenSCENARIO file can contain several scenarios, or the definition of a single scenario can be distributed across different ASAM OpenSCENARIO files, or both.

6.2.4 Scenario instance

The scenario that is executed, whether it is passively observed or actively controlled.

By definition, the scenario instance is concrete. For example, a user may ask for a cut-in scenario (scenario request), execute it and observe the scenario instance that might be different from the scenario request.

6.2.5 Abstraction

Generalization of one or more related specific implementations or situations. In this standard, abstraction refers to the generalization of scenarios. Abstraction is the opposite of concretization.

The degree of abstraction is defined as abstraction levels.

6.2.6 Abstraction levels

Gradation spectrum of generalization (abstraction) of a scenario.

The following definitions list the different levels of abstractions in which a scenario can be specified:

This picture from [24] shows the different levels of abstraction in which a scenario can be specified.

Levels of scenario abstraction
Figure 1. Levels of scenario abstraction (Source: [24])
Abstraction levels are a spectrum and not limited to the four layers.

The levels of abstraction and other of their key aspects are discussed in more detail in Section 6.3, "Scenario abstraction". Guidelines on how to move a scenario more towards either end of this spectrum are described in Concretization and abstraction guidelines.