ASAM OpenSCENARIO: Version 2.0.0 Concepts

OpenSCENARIO 2.0 is intended to be a full superset of the features of OpenSCENARIO 1.0. This means that a migration path for OpenSCENARIO 1.x scenarios to OpenSCENARIO 2.0 will be included in the release version of OpenSCENARIO 2.0.

Migration of scenarios might require conversion to 2.0 syntax and semantics. The run time behavior of any scenario converted from the latest OpenSCENARIO 1.x to OpenSCENARIO 2.0 shall be the same.

A conversion of OpenSCENARIO 2.0 scenarios to OpenSCENARIO 1.x will in general not be possible, since OpenSCENARIO 2.0 is intended to be a true superset of OpenSCENARIO 1.x. However conversion of a subset of OpenSCENARIO 2.0 that maps to the feature set of OpenSCENARIO 1.x will be possible.

The standard development projects for the 1.x and the 2.0 tracks shall ensure an up-to-date ruleset for a migration path from 1.x to 2.0.

At the time of writing OpenSCENARIO is the only proposed standard to describe maneuvers and testing scenarios. The standard is designed to integrate with the requirements of other safety standards being developed in parallel. These include:

The foundational concept of OpenSCENARIO 2.0 is to establish a domain specific language of a declarative nature. A declarative language describes what should happen on scenario execution (including the required parameterization/variation), rather than how to do it. A declarative language can also have a dual interpretation, i.e. provide a single scenario description which can be used to describe both how to make it and how to monitor that it indeed happened. This is important if we want to condition some operation on the fact that some other scenario has happened before, without having to describe in detail how to cause that scenario.

Basic methodology concepts developed by the concept project are stated in this section. These should be used to guide the development of the standard. Chapters 4, 7 and 8 will expand and supply more details on these concepts, as well as examples. In cases where examples are supplied, they are supplied using the foundation of the M-SDL language (reference manual).

The Domain Specific Language is based on some foundational concepts introduced here. Detailed terminology and definitions can be found in chapter 3:

OpenSCENARIO has a top level file; additional files can be imported into it, and additional type definitions and type extension may exist there:

Scenarios contain:

All of these (excluding behavior definitions ) can also appear as fields in actors and structs.

Composition is a key concept of the DSL: it enables to build, instantiate, call and re-use scenarios from existing scenarios or building blocks. Composition exists at all levels and on all building blocks; the DSL supplies the following abilities:

Example how to compose a new scenario by calling existing scenarios:

The DSL introduced two additional concepts that are included in the format and are intended to ease the writing of testing and simulating scenarios. The first is usage of constraints and modifiers and their semantic, the second to specify coverage ranges.

Constraints are used to:

Randomization semantics: generating a test (a concrete scenario) for any parameter not assigned a value. An OpenSCENARIO 2.0 scenario description allows for specification of parameters and probability distributions. The details on how to specify these will be developed in the standard development project.

Some examples:

Modifiers can be used to influence the scenario dynamics. For instance, the modifiers below describe v3 relative to the other vehicles:

Coverage:

Examples:

A key concept of the DSL is the ability to extend entities and the testing platform independence/portability between platform and simulators. It implies that the language allows to:

Example:

Suppose a specific simulator X supports a new weight attribute for cars, the file below will add it to every car (and every scenario using cars):

The following two examples of the same overtake scenario show how the concepts of composition, abstraction, modifiers and constraints can all be used in either a concrete or abstract manner.

Example for demonstrating autonomous vehicle functionality. A simple example for a generic use case in Level 2 driving domain comprised of a scenario and an evaluator.

Additional Information

Data from following measurements channels is available:

A compiler transforms the measured data into a scenario file. This example comes from the highD Dataset. Other data sources might have slightly different measurement procedures. This is just one example for the use case and should be representative for all measured data that needs to be transformed into OpenSCENARIO2.0.

Textual scenario description:

The following UML diagram has been created with PlantUML [7]. For reasons of readability, only a compacted version of the UML model is presented here. The entire model including the source code for the UML model can be found in Appendix A.

The following class description provides explanations to the above UML diagram. A full description with actions and attributes for each entity can be found in the Appendix A.

The scenario definition language shall have a modular structure in order to support reuse and concurrent engineering. Each module will be associated with a single file. Accessing entities defined in an external module is enabled by importing the associated file into the accessing module. This is achieved by the import statement.

A collection of modules can be imported into a top file, constituting a library. Library entities are made accessible by importing the library top-level file. Entities defined in a library share the namespace of the importing module, therefore it is important to maintain a strict naming convention in order to avoid naming conflicts. Specifics of namespacing and scoping rules will have to be defined in a way that reduces conflict potential.

A single module shall have the following syntactic structure:

The general syntactic style of scenario definitions will be similar to Python, using indentation to identify code nesting and avoiding syntactic markers as construct terminators. This is motivated by the popularity of this style, its familiarity within the community, and enhanced readability of core content through reduction of syntactic noise.

Accordingly, line comments in scenario definitions start with a hash (number) sign # and end at the end-of-line. Additionally, multi-line comments in the C style are allowed, for example:

Comment nesting is allowed. The indentation of comments is ignored.

Processing a scenario for execution requires identifying one or more top-level files to be processed. These files and any files imported by them, recursively, are considered the scenario program. Each scenario program shall be free of naming conflicts and transitively closed over types (so that every type being used has been defined).

Scenario definitions shall be done in an object-oriented style. In addition, types that are already defined shall be extensible, to facilitate reuse in face of new aspects and concerns.

Accordingly, each module will consist of a list of type declarations and type extensions. The various kinds of types as well as their inheritance and extension mechanisms are discussed in Section 5.3.

Syntactically, each type declaration will have a header statement identifying its kind, name and inheritance relation, if applicable. The declaration body will comprise a list of type members as described below.

Compound types are versatile language constructs used for various programming tasks. In the context of AV verification, such types are used to model the environment, the map of roads, any actors present in the scene and so on. For specific actors, their behavior and repertoire of actions is captured using compound types as well. To facilitate that, the scenario language defines special kinds of compound types: structs, actors and scenarios. Structs are used to model data elements such as road segments, as well as parameter aggregates like the information collected when some special event occurs. Actors are used to represent any entities (concrete or abstract) that have associated behavior. Behavior, such as actions available for actors, is captured by scenario types.

Additionally, types may function as interfaces to external models, for example behavioral models representing a driver or a traffic pattern. The implementation of such models can be provided as a dynamically loaded object or an independent program. The interface type interacts with the external model using foreign function calls, while implementing an API used by the scenario program. While OpenSCENARIO will define a way to interact with such external or implementation-defined models at the scenario language level, standardization of the technical interface that is used to integrate such models is outside of the scope of OpenSCENARIO 2.0. It is assumed that where standardization of these mechanisms is found useful, additional standards will arise.

Type members define the features of the type and their inter-relationships. Type members share a namespace which includes all the inherited features and those added by extension. The type namespace must be free of naming conflicts.

While every kind of type allows different members, some common features are shared by most types. Common features include:

Expressions are nested within type members, for example within the body of constraints. Since the language is strongly typed, each expression has a type that is known statically (at compile time).

Expressions are composed of atoms, which are either identifiers or constant literals, combined by operators. Identifiers are alphanumeric, must lead with a letter and may include underscores. Supported literals are discussed in Section 5.3. The set of operators, their precedence and composition rules will comprise the usual set of arithmetic and relational operators, as well as domain-specific operators to aid in the formulation of relevant scenarios (e.g. to express the distance after passing another vehicle). The details will be defined during standardization.

Expressions may also contain calls to external methods. External methods are declared as type members, with a binding that maps each method to (one or more) implementation functions in some external language such as Python or C++. Functions implemented in external languages have access to the scenario program data and can raise scenario program events. By calling external methods, expressions can cause side effects, communicate with external models and integrate into simulators, HIL rigs and so on.

The following data types are supported:

Numeric integer types can be declared int (signed) or uint (unsigned), and can have 32 or 64 bit representation. Real types are represented as IEEE754 double-precision (64 bit) floating point numbers.

Numeric constants can be expressed as decimal as well as hexadecimal (prefixed by 0x) numbers. Real constants can include a decimal point, and can use exponent notation. Numeric constants may include underscores (similarly to Ada) to improve readability, these are ignored.

The scenario definition language will also support the usual Boolean and enumerated types.

Physical types are used to characterize physical quantities, such as speed, distance, angle and so on. Physical types accept constant literals of a matching kind.

Physical constant implied-type is expressed by associating a physical qunatity to its numeric value. This is done by attaching a physical unit to the number expressing the magnitude of the quantiy. For example, 12.5km has an implied type of distance.

The scenario definition language will support a built-in ordered collection type (list), that holds multiple values of one base type.

It will also support a built-in string type, holding a sequence of characters, which will support the full ISO 10646/Unicode character complement.

The following compound type kinds are built into the language:

All compound types define their own namespace. Identifiers are looked up in that namespace, and if not found they are looked up in the global namespace. The type namespace is accessible explicitly using the pseudo-variable me.

Compound types are composed using inheritance and extension. An overview of these mechanisms follows.

Inheritance is a mechanism for defining types hierarchically, where more complex and specific types inherit from simpler and more general ones. The features of the inherited type become members of the inheriting one. Some features, like external method and event declarations can be overridden in the inheriting type.

Inheritance is expressed by the following syntax:

Example:

The above defines a new type junction, which is a subtype of road_element – junction will inherit all the attributes of road_element.

When declaring a generatable instance of a type defined using simple inheritance, the instance is guaranteed to be of that type, and not any of its subtypes.

Types available in a standard library or a related project may be reused, saving time and effort. Often, however, these types are missing some features that are unique to the task at hand. Extension is a mechanism for specializing types that are already in use (instances of that type are already declared in some other types). All instances of the extended types will be endowed with the new features added in the extension. in other words, extension modifies the type being extended. Inheritance, in contrast, defines a new type and will require revisiting all instances and changing their types, which is intractable.

Extending is particularly helpful when a library of inter-related actors and scenarios is already available, and it needs to be adapted. Common cases include:

Extension is expressed by the following syntax:

Example:

Extensions enables aspect-oriented programming, where each aspect of the model is captured in a particular source file.

Conditional inheritance is addressing the need to classify objects according to different criteria. Considering a vehicle, for example:

Conditional inheritance provides the ability to decide the type of an object conditioned on some of its field values. Assuming the base type has some enumerated or Boolean fields, the values of these can be used to declare a conditional subtype.

Conditional inheritance is expressed using the following syntax:

Declaring a conditional subtype, the condition always sets a single field to a specific value.

Only Boolean and enumerated field values can be used in conditions.

Example:

This defines a new actor type called truck, which is defined to be "a vehicle where the category attribute has the value truck. Any vehicle which has category == truck automatically becomes of type truck. Thus, truck is a conditional subtype of vehicle. The expression category == truck is the condition determining if a vehicle is of type truck.

When defining a generatable instance of a type with conditional subtypes, the resulting object may be one of the subtypes. For example, when generating an instance of vehicle, it may be of type truck. Members of a conditional subtype may be accessed if the object is known to be of the specific subtype (by either testing the type or casting).

Scenarios are declared in the context of an actor. While they define a namespace for their features, the parent actor namespace is accessible too. Members not found in the scenario scope are looked up in the actor scope. The actor scope can be accessed directly by using the actor pseudo-variable.

Scenarios are defined using the following syntax:

Scenarios have all the features of structs and actors, and in addition they can invoke scenarios and modifiers. Invoked scenarios can be built-in or external, user-defined ones. A special kind of built-in scenarios are operators, that create temporal relationship between the scenarios nested within. The following are some of the operator scenario kinds:

The following example shows a scenario type declaration, which is invoking other scenarios with the use of the parallel operator:

The resulting behavior is having the two cars drive along the path at the same time.

Modifiers are similar to scenarios, but they are restricted to invoking other modifiers only. Modifiers influence the behavior of scenarios by modulating or restricting certain aspects. Using modifiers, a single scenario can be used to create many behavioral variations in a controlled manner. The following are some examples of modifiers included in the basic library:

The above modifiers are associated with a scenario invocation in one of two ways: either they are invoked as members of the scenario invocation, or they are associated with it from the outside.

Associating a block of modifiers with a scenario invocation is possible using the in modifier. The in modifier has an argument that identifies the target scenario invocation. The body of the in modifier lists members that will be applied to the scenario invocation targeted.

An example of a scenario with nested modifiers follows:

Further information on modifiers and their role is contained in Section 5.4.2.3.

The rationale for parameters is to enable the definition and use of abstract OpenSCENARIO entities (such as scenarios, actors, models).

An abstract entity, in the context of parameterization, is an entity with at least one piece of information that is necessary to invoke or instantiate the entity is not yet fixed to one concrete value. Any such piece of information which is left open in the definition of the entity is called a parameter of the entity.

In contrast to an abstract entity, a concrete entity is an entity with all information, that is necessary to invoke or instantiate it, unambiguously defined.

Given a scenario with n parameters, the n-dimensional space of all possible/useful/legal n-tuples of concrete parameter values is the parameter space of the scenario. Such parameter spaces are expressed by parameter type definitions and constraints. Special cases of constraints are parameter ranges.

Besides the parameter space definition through parameter types and constraints, the choice of concrete values of parameters may also be influenced by parameter probability distributions.

Depending on the constraints (see Section 5.4.2.2) it may or may not be possible to choose concrete values for all parameters before the start of the top-level scenario execution. In any case, all parameters of an entity must be chosen at the latest when the respective entity gets instantiated/invoked.

Together these concepts, i.e. parameters, constraints, and parameter probability distributions support the following use cases:

Actions define the basic capabilities of actors types. They constitute the fundamental building block to describe the dynamic behavior of actors in a scenario.

An Action is essential to define what actually should happen. This is much like a verb in a sentence, where actions are the most common verbs. Without a verb you cannot describe the action / what happens in a sentence. Without actions you cannot define what happens within a phase.

In Section 4.2 a class hierarchy of actor types is defined including an intentionally incomplete list of actions the respective actor types are able to perform.

It is essential that not only do the actor types form an inheritance hierarchy using the mechanisms described in Section 4.2, but more concrete actions themselves are also derived from more abstract or basic actions: Given basic actions like Move, Communicate, and Change, an example of a concrete action provided by a Vehicle actor type might be the action Drive, derived from the Move action.

It is expected that a robust set of frequently needed actions will be provided as part of the standard library that standardized as part of OpenSCENARIO 2.0, based in part on the identified actions of OpenSCENARIO 1.0. This will not only enable easy construction of new scenarios, but also provide for enough commonality across scenario users to increase readability and reuse through a common core vocabulary for scenario expression.

Modifiers are used to influence (i.e. modify) the behavior of particular scenario invocations, including actions as well as composite scenarios. They can be seen as structured specifications for intended behavior, which are interpreted by the scenario; they do not consume simulated time by themselves. More precisely, they are stateless; there are no state variables associated with modifier instances.

Modifiers influence the behavior of actors indirectly, by constraining the actions that control the actor. While the specifications provided through modifiers can be seen as constraints, they are not constraints in the sense of Section 5.4, in that they are interpreted at runtime by the scenarios, whereas constraints are evaluated prior to the invocation of a scenario. Furthermore constraints only influence parameters, and only through the use of these parameters in modifiers and scenarios do they influence the actual scenario behavior.

For instance the modifier speed([1..5]kph, faster_than: car1) constrains the speed of the receiver to be relative to another car. The constrained property does not change the actor’s speed state variable directly. Rather it is passed on to the simulated actor affecting its behavior, and thus eventually influences the actual speed captured in the actor’s state variable.

Like scenarios, modifiers live within the namespace of the actor in which they are defined. While the interpretation of a modifier thus rests with the scenario and actor being addressed, a set of modifiers common across scenarios will be provided as part of the standard library.

The currently envisaged set will comprise the following basic kinds of modifiers among others:

Some modifiers can only be embedded in specific scenarios. In the following example, a user-defined modifier can be applied to drive() only, as indicated by the of keyword in the header:

Once defined, the modifier can be used with various values, for example:

As seen in this example, a modifier can itself use constraints to constrain its parameters, it is however distinct from the way it and its parameters influence the behavior of the scenario it is applied to.

The overall role that modifiers play in the language is to provide controlled specificity to the behavior of actors, as directed by scenarios and actions: A generic action, like e.g. drive, does not prescribe in any detail the actual behavior of the actor over time. In connection with modifiers, though, the specifics of e.g. where, how, and when can be given to any level of detail, thus concretizing the actual behavior.

In combination with parameters and constraints, modifiers provide the mechanisms to move between very abstract scenarios, which leave many specifics intentionally undefined, to concrete scenarios, which provide concretizations for all unspecified parts of an abstract scenario (see Concretization and Creation of Scenarios for details of the pragmatics of this process).

A Phase, is a form scenario invocation with the possible addition of modifiers. Each phase has an (explicit or implicit) start and end point as well as a duration interval specifying the allowed time that may pass between start and end of that phase.

A phase can also be used to describe a block of time as part of a serial operation or as a part of a parallel operation. Please find more details about this topic in the section Temporal Composition Operators.

An Atomic Phase is the smallest temporal building block and is defined by who (the actor) is performing what (the action) and the details that direct how (the modifiers) the action is performed. This may be further substantiated by referring to events specifying when the action should start or end (explicit start/end point). If not specified explicitly the allowed start and end points are determined by the context the phase is embedded in (e.g. a composition with other phases) and whether all modifiers are satisfied. One may consider an atomic phase as a kind of minimal scenario.

A scenario can be composed of a hierarchical composition of phases (or scenarios) by using temporal composition operators like serial or parallel in an arbitrary order. This is illustrated by a generic example in the following figure. Here, a scenario is composed by a hierarchical combination of sequential and parallel composition of phases.

Apart from temporal composition operators there are further mechanisms available to specify (temporal) dependencies between phases and scenarios, respectively:

There is also the possibility to specify that an action (and hence also the atomic phase the action belongs to) should first start when a certain event has occurred (which may be emitted by another phase). In the following figure an event event is specified which causes the phase to start using the keyword on.

Accordingly, also the end of a phase can be coupled to the occurrence of a certain event, which is illustrated in the figure below by using the keyword until and the reference to an event $event.

The difference between using events vs. using final intervals is the following:

English specification:

Pseudo-code specification:

M-SDL specification:

English specification

Pseudo-code specification

M-SDL specification:

English specification

Pseudo-code specification

M-SDL specification: 

English specification

Pseudo-code specification

M-SDL specification: 

English specification

Pseudo-code specification

M-SDL specification: 

English specification

Pseudo-code specification

M-SDL specification: 

English specification

Pseudo-code specification

M-SDL specification: 

The following UML diagram provides a more detailed view of the UML diagram from Section 4.1.

As mentioned in Section 4.1, the consideration of and harmonization with other standards is of high importance when creating a domain model. Therefore, a UML diagram visualizing actions defined in OpenSCENARIO 1.0 is presented here.

Actions are atomic operations on entities of the domain model. They cannot be subdivided into smaller parts which separates them from phases and scenarios. The following example illustrates an overtake scenario which is the composition of three atomic drive actions.

The drive action can be parameterized in many ways using the M-DSL modifier concept which is explained in Section 5.4.2.3 in more detail.

Object is the base class, of which all other entities will inherit attributes and actions.

LocatableObject is an upper level class that aggregates physical objects, which have a defined position and spatial extent in the world and are, therefore, locatable in an unambiguous way.

TrafficParticipant is a LocatableObject that moves by its own intention, or by the intention of its operator if applicable.

TrafficParticipant can be used to form complex objects that are made up of other Traffic Participant objects, by having a part that is an object of the same class. For example, a "Trailer Truck" is a complex object of type TrafficParticipant that is comprised of the parts "Tractor Unit" and one or more "Trailer Unit(s)", each of which are also objects of type TrafficParticipant . The complex object "Pedestrian pushing a Bicycle" can be defined as the composition of a Bicycle and a Pedestrian pushing it. Note: To express the situation where one or more persons are in or on vehicles, the NumberOfPassengers should be set to a value greater than 0.

Vehicle is a TrafficParticipant with some form of self-propulsion (e.g. an engine or a pulling animal) that is moved by the intention of its operator. The movement of the Vehicle can be controlled directly by setting its position, through human-machine interfaces, e.g. to set a steering wheel angle, or through a model, the Vehicle Controller. Therefore, a vehicle can a) be operated by a action-based description, where a Vehicle Controller defines the actions and their attributes with regard to the physical limitations or b) be moved on a predefined trajectory ignoring the physical limitations (“Hand-of-God” mode), e.g. Vehicle X that is at Point A at time t should be at point B at time t+dt, no matter how it got from A to B in the time interval dt.

The vehicle can be operated by a action-based description, where a vehicle controller defines the actions and their attributes with regard to the physical limitations. Besides that there can be a use case to move a vehicle on a predefined trajectory ignoring the physical limitations, like in a “Hand-of-God”-mode (e.g. Vehicle X should be at time t at Point A and at time t+1 at point B, no matter how it got from A to B in that time). These basic concepts are shown in the block diagram:

VehicleController refers either to a driver model that controls the vehicle or an automated driving function. In case of a driver model, this includes its behavior properties for information acquisition, the mental model itself as well as the situation assessment and action deduction/execution. In case of of an automated driving function, most of these attributes are the same, because the driving function as the vehicle controller is to some extent an imitation of the driver model behavior. To distinguish between these two cases, the “IsDriverAutomated” attribute is used.

A proposal for a basic set of vehicle controller attributes and methods is listed in the UML Model. This proposal is based on a common understanding of a driver behavior model like this:

With the basic set of vehicle controller behavior attributes possible discontinuities when switching between a ’real’ driver and the automated driving functions or between action-based operation and the “Hand-of-God”-mode should be excluded. To ensure a fluent transition, e.g. switching from the “Hand-of-God”-mode to action-based operation, the vehicle controller has to deliver all necessary driving inputs at every time step, even though they will be overwritten by a predefined trajectory until switching.

In Addition to this, behavior influencing attributes ("modifiers") affect the interaction between the vehicle controller and its environment including the vehicle itself, e.g. sporty driver has a higher free desired velocity.

The list of basic attributes can be extended to a certain example of a more detailed driver behavior model (e.g. Driver Model for specific overtaking situations), like shown as follows.

NonVehicle is a TrafficParticipant that is moving with intention on its own, that is without the use of a Vehicle. The most obvious representative of this class is a pedestrian, but also animals would be categorized here.

NonTrafficParticipant is an object that, in contrast to a Traffic Participant, does not move by its own intention or an operator. It may be anchored at a defined position, making it stationary, or it may have an imposed movement.

Scenery contains elements in the vicinity of the road that are not part of the referenced map but are relevant for the scenario definition. In contrast to an Obstacle, which directly affects the possible trajectories that TrafficParticipant_s may take, the _Scenery affects the scenario mostly due to obstructing the view.

May contain a reference to an external building definition source like CityGML.

Maybe defined only for visual quality of the scenario, but might also have an impact on sensors.

Obstacle is an inanimate object that does not move with own intention and that does not directly participate in traffic. An Obstacle is a physical object that causes some traffic participant to restrict the trajectories it is allowed to choose from. Obstacles may be anchored and, thus stationary or a movement can be imposed on those objects, e.g. to define the behavior of a ball kicked onto the road or a log falling off a truck.

AmbientObject is a super-ordinate class that aggregates physical objects that are not locatable in an unambiguous way, in other words any physical object that is not LocatableObject. Instead, an AmbientObject is defined as a physical entity that is located over an area at a certain point in time. There have been several discussions regarding this disctinction, which need to be continued in the following project. The following examples help to understand the reasoning behind it:

The scenario language is not supposed to define the complete topology of a complex road network, it only has to provide an intuitive way of addressing elements in the network. This for example will be used to define conditions in the behavior definition, e.g. "turn right at the second 4-way junction". An ID based access with detailed knowledge of the road network content must also be possible. The detailed definition of the road network will still be done by formats like OpenDRIVE, which for example is used for OpenSCENARIO 1.0. For OpenSCENARIO 2.0 an abstraction level for the road network should be considered, which allows the usage of other map sources. The road topology model for now only contains essential attributes for addressing the correct elements for the scenario in mind. More advanced features (e.g. angle between connected roads of a junction) can be supported in derived models. It should, however, be noted that the usage of advanced road network features automatically decrease the number of usable map sources. Furthermore, the exchangability of the scenario itself will be affected by the complexity of road features.

The Road model has to contain necessary attributes for scenario definition and addressing specific roads in the network. For example a cut-in scenario might require a Road with at least two lanes in the same driving direction. More vehicle dynamics focussed tests could depend on a the curvature value. An ID based access like in OpenSCENARIO 1.0 will also still be necessary as an unique referencing option. _Road_s itself should contain a number of lanes with additional attributes like seen in many existing map formats. It should be considered to omit the intermediate 'Lane Section' level like in OpenDRIVE in order to achieve the aspired map source independency.