8 Elements from ASAM OpenSCENARIO 1.2.0 not yet covered

Not all elements from ASAM OpenSCENARIO 1.2.0 were covered in ASAM OpenSCENARIO 2.0.0 . These are described in this section.

8.1 AddEntity/RemoveEntity actions

Usage of these two actions outside of the <Init> section is incompatible with the semantics of ASAM OpenSCENARIO 2.0.0, so the actions cannot be converted. Usage of the actions within the <Init> section is equivalent to setting the initial positions with TeleportAction and can be converted in the same way.

8.1.1 VisibilityAction

This action does not have a direct equivalent in ASAM OpenSCENARIO 2.0.0.

8.2 Constraint limitations in ASAM OpenSCENARIO 2.0.0

Constraints in ASAM OpenSCENARIO 2.0.0 are symmetric constructs. When constraints involve multiple actors they set up limits on the behavior of all of the actors involved in a non-discriminating way. This is usually the desired behavior. However, in some cases, it makes the conversion of ASAM OpenSCENARIO 1.2.0 actions difficult.

These use cases represent a minority and usually can be formulated differently.

Such examples are represented in:

  • SynchronizeAction

  • LongitudinalDistanceAction

  • LateralDistanceAction

If these actions are used in the scenario, the referent actor is executing another action that affects its driving.

Constraints on the position of actors at the end of phases (see Example SpeedAction) also attempt to affect the behavior of a referent actor and not only controlled actor. In most cases, the referent actor is Ego/DUT.

In this case, this does not pose a problem during simulation, because the actor’s actions are not fully controlled by the scenario and the constraint acts on the controlled actor only.

If none of the involved actors is Ego/DUT and the referenced actor does not need to execute another action during this phase, the following workaround can be used: Place an additional constraint on the actor (in the case of the SynchronizeAction the acceleration can be set to 0).

The specialized action keep_space_gap from ASAM OpenSCENARIO 2.0.0 can be used to avoid problems with setting up constraints in the case of LongitudinalDistanceAction and LateralDistanceAction. It can be used in cases where freespace parameter is false, while for cases where freespace is true there is no direct conversion.

8.3 SelectTriggeringEntities

In ASAM OpenSCENARIO 2.0.0 the representation of condition groups from triggers is different. Condition groups from triggers are represented by logical expressions, with no object representing a condition group.

Translating a ManeuverGroup using selectTriggeringEntities flag is difficult and in some cases can be resolved by duplicating a conditional expression of the parent Act startTrigger.

Break the expression into individual condition groups and assign actors to the scenario, based on which one of the expressions evaluates as true.

8.4 RoutePosition and TrajectoryPosition

In ASAM OpenSCENARIO 2.0.0 these two types of positions from ASAM OpenSCENARIO 1.2.0 cannot be accurately represented. This is likely to be resolved in the next revision of the standard.

8.5 TrafficSignalCondition and TrafficSignalControllerCondition

  1. Checks the current state on the specified traffic signal controller.

  2. Checks the traffic signal for the specified state.

8.5.1 TrafficSignalControllerAction and TrafficSignalStateAction

  1. Sets the current state on the specified traffic signal controller.

  2. Sets the specified traffic signal to the given state.

These two related pairs of conditions and states are not supported in ASAM OpenSCENARIO 2.0.0. This is likely to be resolved in the next revision of the standard.

8.6 EndOfRoadCondition, OffroadCondition

ASAM OpenSCENARIO 2.0.0 does not provide this condition as such. Similar constructs can be made instead.

8.7 StandStillCondition

There is no concise way to write the condition where the entity has zero speed continuously for some time. Checking if the vehicle has just stopped is easy (see Example SpeedCondition).

8.8 TravelledDistanceCondition

This condition cannot be expressed in general, although some special cases can be covered.

8.9 SimulationTimeCondition

This condition should be avoided in ASAM OpenSCENARIO 2.0.0. It leads to a lot of problems when composing scenarios. A secondary reason is that simulation environments often have a certain warm-up period, before the actual start of the scenario, and simulation time measurement could already start in this period, which would lead to portability problems. The SimulationTimeCondition can be converted by using the duration parameter in actions and temporal operators, or by using the elapsed() predicate in events, which gives reliable relative time measures since the start of a (main) scenario invocation. Attempt to define this time relative to the scenario you are writing, as it might be invoked from other scenarios.