6.1 Architecture

ASAM OpenSCENARIO provides standardized descriptions of traffic situations for the purpose of simulation. Such descriptions represent executable scenarios that enforce a specific behavior during simulation runtime. For this reason, ASAM OpenSCENARIO covers two main aspects:

Designing a scenario (design time)
Executing a scenario (runtime)

The definition of system boundaries and the existence of an abstract runtime model are fundamental for the design of a meaningful scenario because they help bridge the gap between scenario designer and tool implementer. System boundaries delimit the standard’s scope by separating concepts covered by the standard from those concepts that are covered by external systems or definitions.

An abstract runtime model represents a basic contract between the author of a scenario and the provider of a simulation environment, together with a common idea about what should happen when a specific scenario is executed.

ASAM OpenSCENARIO does not describe all these aspects in detail. ASAM OpenSCENARIO provides a solution space and data model for defining traffic situations. The data model is supplemented with an abstract runtime model necessary to interpret interactions between the components at runtime.

6.1.1 Basic architecture components

The ASAM OpenSCENARIO architecture contains the following basic components:

An OpenSCENARIO Model Instance (OSC Model Instance) represents a scenario description in the solution space defined by the data model.
An OpenSCENARIO Director (OSC Director) is a component that interprets the OSC Model Instance and governs the progress of a scenario in a simulation. The OSC Director is the component responsible for running the scenario.
A Simulator Core. The Simulator Core is defined as all components other than OSC Director or OSC Model Instance that are needed to run a simulation. The Simulator Core is an external concept to ASAM OpenSCENARIO and provides a not standardized interface to the OSC Director for orchestrating the traffic situations defined in the scenario.

Figure 2 illustrates how the components interact:

Figure 2. ASAM OpenSCENARIO base architecture

This architecture is a simple abstraction to help understand how a scenario is coupled to a running simulation. It is not the intent of the ASAM OpenSCENARIO standard to prescribe a formal software architecture for simulator implementation. The provided architecture informally illustrates how components are separated and how interaction can be achieved. Implementation-specific details are not part of this architecture, even though the ideas and concepts might be useful when designing a simulation or designing a scenario.

6.1.2 ASAM OpenSCENARIO elements

OSC Director and Simulator Core both manage the lifecycle of elements within their respective scope. An element is an object instance that exists either in the OSC Director or in the Simulator Core and may change its state during the execution of a scenario. ASAM OpenSCENARIO clearly states which elements shall be encapsulated in an OSC Director and which elements are managed by a Simulator Core.

6.1.2.1 Elements of the OSC Director

The OSC Director manages the lifecycle of the following elements:

Storyboard (1 per scenario)
Story instances (0..* per Storyboard)
Act instances (1..* per Story)
ManeuverGroup instances (1..* per Act)
Maneuver instances (0..* per ManeuverGroup)
Event instances (1..* per Maneuver)
Action instances (1..* per Event)

The OSC Director performs the nested and concurrent execution of the elements above. This includes:

Forking into different execution paths.
Joining from different execution paths.
Loop execution (ManeuverGroup , Event) for maximumExecutionCount > 1.

Section 7.2, "Storyboard and entities" describes the runtime behavior of storyboard elements in detail.

6.1.2.2 Elements in the Simulator Core

ASAM OpenSCENARIO also requires an abstract understanding of elements that are not under the responsibility of the OSC Director at runtime. These are:

Entities representing traffic participants, such as vehicles and pedestrians
Environmental parameters, such as time of day, weather, and road conditions
Traffic signal controllers and traffic signals
Traffic objects, such as swarms of vehicles, sources for vehicles, and sinks of vehicles
Controllers: Default controllers, user-defined controllers like simulated drivers, drivers in the loop, or for the appearance of the ScenarioObject
Control strategies: Entity control instructions that originate from actions
Variables and user defined values

6.1.2.3 Element states

Elements generally have a set of property values at runtime. Because properties and relations, for example speed and position, may change during the simulation the complete set of property values and relations at a specific time represents the state of an element.

6.1.2.4 Static elements

A static element is a stateless component that does not change during runtime. Examples of static elements are the road network and road surface descriptions. These resources may be shared between OSC Director and Simulator Core.

6.1.3 Executing a scenario

Executing a scenario synchronizes the state of the elements in the OSC Director with the state of the elements in the Simulator Core.

The OSC Director interprets the OSC Model Instance at runtime, which translates in commands to the Simulator Core. The Simulator Core handles its elements, whose states are used by the OSC Director, to guide the developing scenario in the directions prescribed by the OSC Model Instance.

As an example, the SpeedCondition can be used via its application in a startTrigger to couple the speed of an entity managed by the Simulator Core to the start of an event that is managed by the OSC Director.

6.1.4 Actions and conditions

Actions and Conditions are abstract concepts that enable an OSC Director to interact with the Simulator Core and thus manage the ongoing simulation in accordance with the OSC Model Instance. Actions are used to manage the simulation by targeting the behavior of traffic simulation elements in Simulator Core. Conditions evaluate the state of traffic simulation elements in Simulator Core.

Figure 3. Actions and conditions

Figure 3 illustrates the idea behind the logical concepts. It is not an implementation recommendation or guideline and does not intended to represent interactions between programs or define software protocols. Condition evaluation, for example, could also be implemented with a publish-subscribe mechanism on the trigger level.

In ASAM OpenSCENARIO, actions are the exclusive mechanisms for controlling and modifying the content of a simulation. Conditions are the exclusive mechanisms for evaluating the status information of a simulation.

Actions are not the only factor influencing simulations. Other influencing factors are driver models, drivers-in-the-loop, and environmental conditions. These concepts are not defined in ASAM OpenSCENARIO.

In the same way, conditions cannot describe all quantified property values that exist in a simulation. Simulations can vary in scope and details of their simulated components. In order to be compatible with other simulation standards, ASAM OpenSCENARIO builds on high-level, abstract information that represents a common denominator for a majority of simulations. For example, a condition can be used to specify the speed of a vehicle, but not the speed of the vehicle’s left front wheel.

The ASAM OpenSCENARIO format is organic, meaning it may grow dependent on the used application. It can be expected that the scope of what is possible to use in conditions expands as the format grows. The same applies for actions. Actions and conditions are described in detail in Components of a scenario.

6.1.5 Abstract ASAM OpenSCENARIO architecture

With the definition of actions and conditions, the logical interface between OSC Director and Simulator Core can be refined into an Apply Action Interface and an Evaluate Condition Interface. More generic interfaces are also required for general commands like initialize, starting, and stopping a simulation. Figure 4 illustrates the architecture of ASAM OpenSCENARIO.

Figure 4. Abstract ASAM OpenSCENARIO architecture

The architecture depicted in Figure 4 illustrates the logical relations between the identified components and interfaces. It is not meant to prescribe a formal software API.