Introduction

Overview

ASAM OpenDRIVE was developed in response to demand for the specification of an exchange format to define static road networks that can be used in driving simulation applications.

The ASAM OpenDRIVE Specification specifies the file format for static road network descriptions. The Extensible Markup Language (XML) is used to represent these descriptions. The ASAM OpenDRIVE Specification specifies how to model static road networks. In more detail, it specifies the structure, the sequence, the elements, and values to represent static road networks.

Static road networks consist of, for example, roads, lanes, signals, junctions, and objects along the road, for example, traffic islands. The static road networks described in an ASAM OpenDRIVE file can be either artificial or derived from real world data. ASAM OpenDRIVE does not define dynamic content, for example, traffic participants and moving objects.

ASAM OpenDRIVE descriptions may contain:

  • Road definitions

    • Road geometry in plan view

    • Lateral and elevation profiles of roads

    • Lanes

    • Road marks

    • Signals and their validity for specific roads and lanes

    • Objects along roads

  • Junctions

    • Junction types

    • Connections

    • Junction areas

  • Junction groups

  • References to controllers for traffic lights

  • Tram and railway tracks

Every ASAM OpenDRIVE element can be extended by user-defined data. For example, when defining a speed limit sign, the only way to reference an external 3D object of that speed limit sign is to use the `<userData>' element. The extensibility facilitates a high degree of specialization for individual applications, while supporting exchangeability of ASAM OpenDRIVE data between different applications.

ASAM OpenDRIVE is part of the ASAM domain of simulation standards that focus on simulation data for the automotive environment. Next to ASAM OpenDRIVE, ASAM provides other standards in the simulation domain, such as ASAM OpenCRG and ASAM OpenSCENARIO.

img
Figure 1. Relationship between ASAM OpenDRIVE, ASAM OpenCRG, and ASAM OpenSCENARIO

Figure 1 shows how to combine ASAM OpenDRIVE, ASAM OpenCRG, and ASAM OpenSCENARIO to define a scenario-driven description for traffic simulation that contains static and dynamic content.

ASAM OpenCRG enables to add detailed road surface descriptions to road networks defined in ASAM OpenDRIVE. Like ASAM OpenDRIVE, ASAM OpenCRG does not define dynamic content. ASAM OpenSCENARIO enables to add dynamic content to road networks defined in ASAM OpenDRIVE.

Conventions and notations

Normative and informative content

Content in this specification can be normative or informative. The sections listed in Table 1 are normative or informative per definition. Further informative content is shown in table Table 2.

Table 1. Normative and informative sections
Section Indication

Foreword

Informative

Introduction

Informative

Scope

Normative

Normative references

Informative

Terms and definitions

Normative

Abbreviations

Normative

Backward compatibility

Normative

First to last specification-specific section

Normative

Annexes

Annexes can be normative or informative. The annex heading contains the indication "(normative)" or "(informative)".

Bibliography

Informative

All other sections in this specification are normative.

Table 2. Informative text components
Text components Indication Hints

Notes

Informative

The document shall be usable without notes.

Footnotes

Informative

The document shall be usable without footnotes.

Examples

Informative

The document shall be usable without examples.

Sequence diagrams

Informative

The document shall be usable without sequence diagrams.

Notes, footnotes, and examples shall not contain requirements or any information considered indispensable for the use of the document, for example, instructions or permission.

Left- and right-hand traffic

Unless stated otherwise, all examples, figures, and descriptions in this specification assume there is right-hand traffic.

Naming conventions

In this document, the following conventions apply:

data types are given according to the IEEE standard

Units

Unless stated otherwise, all numeric values within this specification are in SI units, for example:

  • Angles in [rad]

  • Position/distance in [m]

  • Speed in [m/s]

  • Time in [s]

Geographic positions are stated in the unit defined by the spatial coordinate system, for example, in accordance with EPSG:4326 WGS 84 [1].

With some data elements, it is possible to explicitly state the unit of a given value. If the unit is not shown or if there is no means of stating the unit, SI units apply. The following units may be used in explicit assignments:

Table 3. Units
Category Description Symbol

distance

meter

m

kilometer

km

feet

ft

land mile

mile

speed

meters per second

m/s

miles per hour

mph

kilometers per hour

km/h

mass

kilogram

kg

metric tons

t

slope

percent

%

These optional units shall be used only for the purposes of signage and speed indication. They shall not be used as general units, for example, to define road geometry, etc.

Modal verbs

To ensure compliance with the ASAM OpenDRIVE specification, users need to be able to distinguish between requirements, recommendations, permissions, possibilities and capabilities, and external constraints.

Table 4. Verbal forms for expressions of provisions
Provision Verbal form Definition

Requirement

shall, shall not

A requirement conveys objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed.

Recommendation

should, should not

A recommendation conveys a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others.

Permission

may

A permission conveys consent or liberty (or opportunity) to do something.

Possibility and capability

can, cannot

A possibility conveys expected or conceivable material, physical or causal outcome.
A capability conveys the ability, fitness, or quality necessary to do or achieve a specified thing.

External constraint

must

An external constraint or obligation on the user of the document, for example laws of nature or particular conditions existing in some countries or regions, that is not stated as a provision of the document. External constraints are not requirements of the document. They are given for the information of the user.

Typographic conventions

This documentation uses the following typographical conventions:

Table 5. Typographical conventions
Mark-up Definition

Code elements

This format is used for code elements, such as technical names of classes and attributes, as well as attribute values.

Terms

This format is used to introduce glossary terms, new terms and to emphasize terms.

Mathematical elements

This format is used for calculations and mathematical elements.

<element>

This describes a tag for an element within the XML specification.

@attribute

The "@" identifies an attribute of any ASAM OpenDRIVE element.

The ASAM OpenDRIVE structure diagrams are modeled according to Unified Modeling Language (UML). For detailed information on UML, see Booch et al. (1997).

img
Figure 2. UML notation (see ISO TS 19103, Geographic information - Conceptual schema language)

Figure 2 shows the basic principles of UML modeling and its notation.

The context that an element takes within an association is indicated by its role. The role is given near the target of the association. For better readability, the ASAM OpenDRIVE class diagrams use a color scheme:

  • The top-level element of a diagram is marked orange. This helps finding the entry point when reading a diagram top-down.

  • Classes that are marked yellow belong to the UML package that is discussed in the specification chapter, where the UML diagram is given.

  • Classes that are marked blue belong to an ASAM OpenDRIVE package that is different from the package that is associated with the yellow color.

  • Classes that are marked green are classes that contain geometry information.

Mandatory and optional attributes

img
Figure 3. UML attribute notation

In the UML model, attributes are marked as mandatory or optional. Figure 3 shows the marking of the attributes. Optional attributes have the UML specific notation [0..1], mandatory attributes do not have any notation.

Color conventions for lane types in images

Table 6. Color conventions for lane types in images
Name RGB color code HEX color code HEX color representation

biking

207, 016, 045

#cf102d

border

165, 094, 055

#a55e37

connectingRamp

168, 211, 000

#a8d300

curb

151, 120, 211

#9778d3

driving +

239, 215, 171

#efd7ab

driving -

205, 216, 232

#cdd8e8

entry

234, 217, 096

#ead960

exit

103, 153, 204

#6799cc

median

124, 084, 071

#7c5447

none

147, 149, 152

#939598

offRamp

035, 121, 185

#2379b9

onRamp

255, 212, 002

#ffd402

parking

098, 038, 158

#62269e

rail

056, 043, 178

#382bb2

restricted

255, 103, 027

#ff671b

shoulder

000, 098, 065

#006241

walking

121, 036, 047

#79242f

slipLane

000, 148, 094

#00945e

stop

146, 213, 172

#92d5ac

tram

109, 109, 226

#6d6de2

Use of IDs

The following rules apply to the use of IDs in ASAM OpenDRIVE:

  • IDs shall be unique within a class.

  • Lane IDs shall be unique within a lane section.

  • Only defined IDs may be referenced.

Curvature

For curvature indications, the following convention applies:

  • Positive curvature: left curve (counter-clockwise motion)

  • Negative curvature: right curve (clockwise motion)

Curvature == 1/radius

Deliverables

The following deliverables are provided for ASAM OpenDRIVE: