OpenX Compatibility

Notes on Auto-Translations from WMG’s SDL Level-2 to ASAM OpenX scenario formats

To make scenarios on SafetyPool^TM accessible and usable with off-the-shelf simulation platforms, scenarios in our Level-2 Scenario Description Language (SDL) are translated into the well-defined and widely implemented ASAM OpenSCENARIO v1.1 and ASAM OpenDRIVE v1.6 standards. This ensures that our scenarios are useful to a wide variety of stakeholders, as dictated by our values. 

Translation between Level-2 SDL and these standards is non-trivial. Since the languages do not share the same syntactic structures, the translation process is a semantic one. Our translation is designed to ensure that the meaning of the scenarios in Safety Pool is well represented. Our translation algorithm keeps improving with the help of feedback from our users.

The translated scenario specifications comply with their respective schemas for ASAM OpenSCENARIO v1.1 and OpenDRIVE v1.6. However, given the multitude of available off-the-shelf simulators, we understand that additional tooling may be necessary to make our scenarios compatible. This is because different simulators can have differing requirements, in addition to those in the defined schema. Hence, minor modifications might be necessary to meet the requirements of your choice of tool. Further, translation choices (how to represent our SDL elements in OpenX) have been made to ensure that the semantic meaning of the scenarios are, as far as possible, retained. 

To help users of SafetyPool^TM understand our translations better, below we describe a few elements of our translation and the motivation behind the translation choices made. Additionally, we also provide a list (likely incomplete) of common tools and respective steps required for successful scenario import.

Key translation choices:

• Road Representation: Specific transformations for roads are needed during the transition from SDL to ASAM OpenSCENARIO v1.1 and OpenDRIVE v1.6 to treat lane manoeuvres uniformly regardless of the lane/road position of the car, or direction of traffic. Hence, a bidirectional road, which is typically represented as a single road with lanes on either side, is transformed into two distinct roads with opposing driving directions and road start and end points. For left-handed traffic, all lanes are positively numbered, while for right-handed traffic they are negatively numbered. These changes allow us to define lane change manoeuvres in a consistent, position independent manner, as a relative lane change action.

• Intersection Representation: The definition of junctions in Level-2 SDL takes a declarative form and must be translated into a set of concrete geometries for ASAM OpenDRIVE v1.6. Junctions are easier to represent once the roads have been translated into a suitable OpenDRIVE v1.6 format. At present, intersections (T-junctions, cross-junctions, Y-junctions) are geometrically treated as a single point where all connecting roads meet. To improve the visual appearance of these junctions, we are in the process of adding more intricate geometric details. Future iterations of the conversion toolchain will replace the present single point intersection implementation with a smooth and seamless transition between the roads at the intersection.

Using translated files with third-party tools:

Depending on how your chosen simulator/application interprets ASAM OpenSCENARIO v1.1 and OpenDRIVE v1.6 files, you may be required to make minor modifications to view the scenario as intended. Those known to us are listed below. 

• Esmini (version 2.27.2): OK
• Odrviewer.io: OK
• RoadRunner (version R2022b 1.5.0.fcdcb76871): 
  1. OpenDrive 1.6: Requires header to include a “geoReference”. GeoReference data must either be inserted into the header before opening the file in RoadRunner or predetermined elsewhere within RoadRunner.

Excerpt of an OpenDRIVE (xodr) file showing GeoReference data