10.8 Elements from 1.2.0 not yet covered

Usage of these two actions outside of the <Init> section is incompatible with the semantics of this version of ASAM OpenSCENARIO, 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.

Constraints in this version of ASAM OpenSCENARIO 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.

Such examples are represented in:

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 this version of ASAM OpenSCENARIO 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.

In this version of ASAM OpenSCENARIO 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.

In this version of ASAM OpenSCENARIO 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.

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

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).

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

This condition should be avoided in this version of ASAM OpenSCENARIO. 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.