ASAM TrafficParticipants Specification

ASAM OpenSCENARIO is a vendor-independent standard that defines a data model and an XML file schema (with the .xosc extension) for describing dynamic content in driving simulation applications. It is primarily used to describe predictable, highly precise scenarios involving complex maneuvers of multiple entities (vehicles, pedestrians, etc.) for the virtual development, testing, and validation of driver assistance and autonomous driving systems.

It focuses exclusively on dynamic content and does not define static environment components (like road networks), though it can reference them. It is typically used in conjunction with ASAM OpenDRIVE and ASAM OpenCRG, which handle static content.

ASAM OpenSCENARIO uses a strong, statically typed system where all expressions have a defined type checked before runtime. Types are categorized as follows:

• Primitive Types: Built-in basic types including Boolean, Integer, Floating-point, and String.
• Enumeration Types: User-defined basic types for finite sets of values.
• Physical Types: User-defined basic types for physical quantities that include unit information.
• List Types: Built-in aggregate containers for elements of a single type (cannot contain other lists).
• Range Types: Built-in aggregate types representing closed intervals over a numeric base type (int, uint, float, or physical types), written as range of <T>.
• Compound Types: User-defined types that compose other types, methods, and components (e.g., structs, scenarios, actions, and actors).

ASAM OpenDRIVE is a standard used to describe static road networks for driving simulation applications using XML. The standard is composed of the following components:

• Specification: The primary document describing the modeling approach for static road networks.
• Enterprise Architect UML model reference: The formal documentation of the ASAM OpenDRIVE data model.
• Junction Guideline 1.0.0: A non-normative supplementary document providing guidance on modeling junctions and selecting junction types.
• Signal reference 1.0.0: A normative supplementary document specifying elements considered signals (e.g., traffic lights) that lack official @type and @subtype representations.

The ASAM OpenSCENARIO domain model core layout defines the primary entities used to describe scenarios. These entities, along with their sub-classes, include definitions, states, properties, and relations to other classes. The core entities available in the domain model are:

• Physical object
• Environment
• Action
• Physical type
• Road abstraction
• Behavioral model

Controllers are runtime elements of the simulation core that enforce control strategies assigned to ScenarioObject instances (specifically Vehicle or Pedestrian). They can be internal to the simulator or external (defined in a file). Controllers are used for:

• Specifying that a vehicle is controlled by the system under test (SUT).
• Defining 'smart actor' behavior (e.g., human-like reactions to road networks).
• Assigning a vehicle to direct human control.

By default, controllers are assigned in a deactivated state.

ASAM OpenSCENARIO 2.0.0 is a programming language-based standard for describing scenarios. In addition to the primary documentation, the following normative and non-normative resources are available for download:

• A consolidated extended Backus–Naur form (EBNF) for the language syntax.
• The full domain model provided as a library file named standard.osc (non-normative).
• An introductory document covering version differences and the ASAM roadmap (non-normative).

Behavioral models connect a scenario description with external, implementation-specific assets that influence how an actor behaves during execution. They are used to select dynamic models, adjust simulation parameters, assign motion control modules, or expose internal actor signals.

Key characteristics include:

• Every physical actor has a behavioral model.
• Behavioral models are implementation-specific and can refer to a dynamic model, a controller, or both.
• They do NOT contain motion states (position, speed, acceleration), as those are part of the standard domain model.
• Actors are initialized with a behavioral model via the initial_bm parameter.