Project Number

P2021-03

Domain

Simulation

Relevant Standard

ASAM OpenDRIVE BS 1.6.1

Project Name

P_2021_3_OpenDRIVE_BS_V1-8-0

Project Type

Standard Development Project

Start Date

01.05.2021

End Date

30.10.2022

ASAM Funds

t.b.d

Executive Summary

This project is a standard development project and intended to fix ambiguities and errors in the released version of ASAM OpenDRIVE 1.6.1., which could not be fixed in the prevuois maintenance project. In addition to the issues, the project will also implement concept that where create in the OpenDRIVE Concept Project, the individual concepts will be listed in the chapter "technical content".

Due to the fact that some feature are urgently requested by the community it is proposed to have two standard releases in this project:

  • OpenDRIVE 1.7.0 in July 2021

  • OpenDRIVE 1.8.0 in November 2022

OpenDRIVE comprises the specification, style guide and scheme for the logical description of road networks. It is intended for vehicle dynamics simulation, traffic simulation and sensor simulation. OpenDRIVE is used in virtual development, test and validation of driving assistance functions, automated and autonomous driving. Within these use cases, OpenDRIVE files are describing road networks with respect to all data belonging to the road environment. They do not describe the entities acting on or interacting with the road. The open standards OpenSCENARIO and OpenCRG supplement OpenDRIVEs content concerning scenario description and road surface description. The consolidated content of the three standards provides comprehensive input for the use-cases mentioned above.

1. Overview

1.1. Motivation

As a result of the transfer of OpenDRIVE 1.5 to ASAM, ASAM OpenDRIVE 1.6.0 was released in March 2020. In the Transfer project not all errors and ambiguities could be fixed. After 8 months of being in the field ASAM has received some feedback on ASAM OpenDRIVE 1.6.0. The goal of the project is to clear the ambiguities and fix the found errors in the specification.

1.2. Use Cases

Use cases in the context of ASAM standards describe the external behavior of the standardized system, i.e. the interaction of the system with a user or with another system. The description of use cases is particularly useful for explaining the motivation for new standards, major version development projects or the addition of new features in minor version development projects.

UC 1: Generation of High-Definition Maps for Simulation

Relevant Users

  • Surveying companies

  • Authorities

  • Vehicle manufacturers and their suppliers

  • Simulation tool vendors

  • Urban planners

Description

Traffic simulation, vehicle dynamics simulation, sensor simulation as well as virtual development, test and validation require geo-referenced, high-definition maps of road networks. These maps are ordered from surveying companies by authorities, car manufacturers, simulation tool vendors, urban planners etc. The de-facto standard for maps used in commercial and publicly funded projects is OpenDRIVE.
UC 2: Traffic Simulation

Relevant Users

  • Authorities

  • Vehicle manufacturers and their suppliers

  • Simulation tool vendors

  • Urban planners

Description

Macroscopic simulation of traffic on road networks. Traffic simulation may incorporate large numbers of various traffic participants, e.g. pedestrians, cyclists, cars etc. Traffic simulation is used to simulate surrounding traffic of a vehicle under test, traffic volume in specific areas, accident probabilities etc. Traffic simulation requires a logical description of corresponding road net-works, such as it is provided by OpenDRIVE.
UC 3: Vehicle Dynamic Simulation

Relevant Users

  • Vehicle manufacturers and their suppliers

  • Simulation tool vendors

Description

Virtual development, test and evaluation of the dynamic subsystem of a vehicle using driver inputs and a given road map as input. Vehicle dynamics simulation provides valuable results in early development stages. It further allows parallel execution of time-consuming physical test runs at low costs. Vehicle dynamics simulation enables tests at the limits of dynamic driving performance and within hazardous situations. As mentioned above, vehicle dynamics simulation requires a logical description of correspond-ing road networks as input, such as provided by OpenDRIVE.
UC 4: Sensor Simulation

Relevant Users

  • Vehicle manufacturers and their suppliers

  • Simulation tool vendors

Description

Simulation of sensors as a device, module or subsystem of a vehicle is indispensable for the selection of individual sensors as wells as for the compilation of sensor sets and the development of sensors and sensor-based functionalities in the automotive context.

A sensors ability to detect events or changes in its environment is heavily influenced by vehicle geometry, mounting position and interferences with other sensors. Sensor simulation offers valuable insights on this complex, heavily entangled phenomena. Due to the strong influence of the sensor setup on vehicle bodywork and electrical systems, this knowledge is particularly valuable in early development stages of a vehicle, where physical sensors may not yet be available.

Sensor simulation provides the foundation for development and test of driving assistance functions, as well as for automated and autonomous driving functions. Besides the vehicles geometry and the sensor configuration, road geometry and appearance is strongly influencing sensor behavior. In sensor simulation, all the latter data is provided by OpenDRIVE road maps.
UC 5: Virtual Development, Test and Validation

Relevant Users

  • Vehicle manufacturers and their suppliers

  • Simulation tool vendors

  • Authorities

Description

Development, testing and validation of automated and autonomous driving functions is increasingly carried out virtually. The reproduction of countless, realistic journeys over millions of kilometers requires huge numbers of road maps and scenarios as input files. Major requirements on corresponding file formats is standardization and exchangability. This is why, besides OpenSCENARIO as scenario format, OpenDRIVE is used as input file format for virtual development, test and validation throughout the automotive industry.

1.3. Requirements

The Standard Development Project needs to fix the listed issues and implement the selected concept from the OpenDRIVE Concept Project, all solutions need to ensure that OpenDRIVE 1.7.0 stays backward compatible to ASAM OpenDRIVE 1.6.1 and therefore also to OpenDRIVE 1.4 and 1.5.

1.4. Relations to Other Standards or Organizations

1.4.1. Backward Compatibility to Earlier Releases

This project is going to be a standard development project and will ensure backward compatibility to OpenDRIVE 1.6.1

1.4.2. References to Other Standards

  • ASAM OpenLABEL

  • ASAM OpenXOntology

  • ASAM OpenSimulationInterface

2. Technical Content

2.1. Known Issues for OpenDRIVE 1.6.1

2.1.1. Enable to apply OpenCRG for Objects

Type:

Improvement / Clarification

Issue

#50

Target

ASAM OpenDRIVE 1.7.0

The OpenDRIVE 1.6 standard places no restriction on the placement of OpenCRG files: multiple OpenCRG files can overlap. However, the standard does not say what should happen if multiple CRG files do overlap.

There is an important use-case for this, and there seems only one generally sensible behavior in the face of overlapping CRG files. This document explains the use-case and the desired interpretation:

Use case

Currently objects on the road do not influence the road surface. It would be helpful if CRG files could be attached to road objects, which would then influence the road surface. This would make it possible to have low-frequency road surface information for the whole road, but also high-frequency road surface information for specific spots (e.g. at places where there is road damage).

Currently, supporting high-frequency road surface information requires attaching very large CRG files to the OpenDRIVE file (thus slowing down loading and querying of the data), even if that data is only needed in very small areas of the road. This can be solved by adding CRG files to road objects, and adding their height to the surface of the road.

Type

Improvement

Issue

#42

Target

ASAM OpenDRIVE 1.7.0

create a new example for a U-turn in the upcoming OpenDRIVE development Project

  • only U-Turn

  • U-turn in a junction (more complex example)

Will be part of the Junction Guideline

2.1.2. Link related topics in the documentation

Type

Improvement (Documentation Issue)

Issue

#43

Target

ASAM OpenDRIVE 1.7.0

In the new HMTL Version of the the related topics can be linked, this is a major effort and will be done in this project

2.1.3. Overlapping bike lane with lanes

Type

Improvement

Issue

#18

Target

ASAM OpenDRIVE 1.7.0

it is currently not possible to model overlapping bike lanes in OpenDRIVE this is a new feature for OpenDRIVE 1.7

2.1.4. Some details are difficult to find in the documentation

Type

Improvement (Documentation Issue)

Issue

#22

Target

ASAM OpenDRIVE 1.7.0

The online documentation does not comprise every detail of the OpenDRIVE Standard, as it used to be in the pdf documentation for previous OpenDRIVE versions. Instead one sometimes has to look for details in UML and additional_content files, which makes it much more difficult to find them, in particular if you’re not aware that you have to download additional information. Two examples:

The description of types and subtypes for traffic signals have to be searched in ~\ASAM OpenDRIVE v1.6.0\additional_content\Signal_Base_catalog.pdf of the Standard’s Deliverables The object type "pole" (and all other type enumeration elements) can now only be found in the UML model or in an example xodr file

2.1.5. Handling of short lanesections

Type

Improvement

Issue

#39

Target

ASAM OpenDRIVE 1.7.0

For 1.6.1 it was agreed on that Lane sections should be greater than length zero. However short lane sections can still be a problem and often can’t be avoided. There is a possibility to use one-sided lane sections, but these can come with their own problems. Maybe we can come up with a solution how to handle the occurance of short lane sections for 1.7.

2.1.6. Header: License Tag

Type

Improvement

Issue

#7

Target

ASAM OpenDRIVE 1.8.0

Related to the OpenSCENARIO Issue: openscenario#175 (closed) It is asked if it is possible to introduce a license tag structure. this structure would make it possible to add the following attributes:

spdx-ID
Name
License Text
...

Compare to the OpenSCENARIO implementation Requested by Thomas Nader (BMW, thomas.nader@bmw.de)

2.1.7. Lane height with applied superelevation and elevation

Type

Improvement / Clarification

Issue

#10

Target

ASAM OpenDRIVE 1.8.0

When a lane height is added to a lane and the road has applied super elevation the height is perpendicular to the X/Y plane and not perpendicular to the road surface

Current status:

there is a h-coordinate, which defines the top direction of the reference line (towards the sky). lane height and attached CRGs use the h-coordinate. superelevation tilts the h-coordinate, but everything else leaves it untouched (especially attached CRG, elevation, road shape). objects and signals are not tilted in any direction (they don’t use the h-direction).

→ this means that attached CRG files and sidewalks will not have the expected height relative to the road for strong elevations. Conceptually, it seems clearer to tilt the h-coordinate. However, it will make calculation of Z queries ("give me the Z coordinate at a given XY coordinate") even more complicated than currently (since now one XY coordinate can have two Z coordinates, even on one lane. Suggestion: tilt h-coordinate based on elevation. However, this would be an incompatible change (even if slightly).

TODO:

  1. should road shape tilt the h-coordinate?

  2. should lane height tilt the h-coordinate?

  3. should elevation tilt the h-coordinate? (suggestion above: yes)

Think about what happens when potholes are placed via CRG attached mode onto these roads (e.g. a sidewalk defined via lane height, where inner != outer).

2.1.8. Modelling/Handling of double markings

Type

Clarification

Issue

#16

Target

ASAM OpenDRIVE 1.8.0

Modelling/Handling of double markings (e.g. 'brso', 'sobr')

If a roadmark element has 'double marking' as attribute type there is no clear indication how to model this type of marking. The corresponding border geometry could lie on the left or the right mark or in the offset space in between. Therefore there is no clear way to interpret this for visualization. You could describe these markings with the 'type' and 'line' elements, but this should not be mandatory and in addition could be illustrated with an example for clarification.

2.1.9. Lane Speed: Handling supplementary speed limits

Type

Improvement

Issue

#41

Target

ASAM OpenDRIVE 1.8.0

Currently there is no way of handling lane speeds that are defined by supplementary signs (e.g. time or weather related). If there is a lane speed record wouldn’t it be reasonable to have the possibility to define supplementary speeds?

2.1.10. Clarify relation between orientation and lane validity

Type

Clarification

Issue

#49

Target

ASAM OpenDRIVE 1.7.0

The relation between orientation and lane validity is not clear in OpenDRIVE 1.6.1. There was not enough time in 1.6.1 to properly fix this, so this should be clarified for 1.7.

2.1.11. Allow multiple adjacent junctions

Type

Improvements

Issue

#59

Target

ASAM OpenDRIVE 1.8.0

Currently two junctions may not be directly adjacent. This is needed for some road layouts, and to allow conversion of maps of other formats, which support this feature.

2.2. new features based on concepts from the OpenDRIVE Concept Paper

In November 2020 ASAM released the OpenDRIVE Concept Paper (OpenDRIVE Concept Paper). This concept paper contains concept for the next versions of OpenDRIVE

The following concepts shall be evaluated and implemented in this project

2.2.1. Concepts from Junction Modelling

Improved description of the elevation profile of roads in junctions

Concept in the concept paper

The concept proposes an improved method for describing the elevation (z-value) of roads in junctions. The proposal includes the following subconcepts:

  • Junction borders to define the outline of junctions. The borders specify a clearly defined and closed junction area.

  • A junction road with its own reference line that runs through the junction area. The junction road will be used for placing individual objects independent of the connecting roads.

  • A junction grid, that is similar to the grid of OpenCRG and may be defined left and right of the junction road. The grid defines all elevations points within the junction area.

  • A transition area between the junction grid and each road leading in and out of the junction. The grid shall create a smooth transition for the simulated traffic participants. It is intended that the transition takes place within the junction area. The details of transition areas need to be specified by the standardization project.

There are the following advantages:

  • Modelling of elevation profiles is easier compared to OpenCRG.

  • It is no longer necessary to define the elevation profile of connecting roads inside junctions.

  • Overlaps or gaps between connecting roads in junctions, resulting from diverging height information, vanish.

  • Positioning of objects via junction roads is more flexible.

  • Transition areas provide a smooth transition from the junction elevation profile to the incoming roads.

  • Grid and the lane heights can be used to visualize the junction area.

  • Junctions will contain more information than just the connections between roads.

There are the following disadvantages:

  • The creation of junctions gets more complex because grids need to be defined.

  • The JunctionBorderOutline has to be defined.

  • The JunctionGrid has to be defined.

Direct Links

Concept in the concept paper

This concept proposes adding a new junction type to OpenDRIVE in order to simplify the modeling of motorway exits and entries. Motorway roads shall be linked directly without connecting roads. This will reduce the number of roads required to describe motorway exits and entries by up to 40 to 50 %.

There are the following advantages:

  • Easier modeling of motorway exits by removing the connectingRoad element.

  • Leaner XML code.

  • Improved processing by simulation applications.

There are the following disadvantages:

  • The concept would be limited to a specific junction class. It can only be used for non-overlapping entry or exit lanes.

  • The concept could be used for junctions that are not in scope. To prevent misuse, a clear recommendation for how to model specific junction types is required.

Specify the length of virtual junctions

Concept in the concept paper

Simulated vehicles driving into virtual junctions cannot recognize connecting roads inside the virtual junction. Therefore, incoming traffic on those connecting roads are unexpected for the simulated vehicles. For this reason, the concept proposes adding the length of the area created by the virtual junction to the virtual junction element.

There are the following advantages:

  • It will be easier for simulated vehicles to access virtual junctions.

  • Vehicles in simulation will find it easier to determine the possible interaction with traffic on connecting roads inside a virtual junction.

Junction Guidelines

Concept in the concept paper

The concept proposes standardized modeling guidelines for different junction classifications. Six junction classes shall be used as templates for typical traffic situations. This means, similar junctions can be consistent including the correct usage of the junction type attribute. The introduction of a junction class attribute is not goal of this concept.

The guidelines should be valid for all three junction types: regular, virtual, direct.

There are the following advantages:

  • Better portability between creators and consumers of OpenDRIVE files

  • Clearer usage of junction type attribute

  • Increase usability of OpenDRIVE

There are the following disadvantages:

  • The concept does not propose changes to the standard but only to the documentation. It is only a guideline

2.2.2. Concepts from the Environmental Modelling

Simplifying the data model of OpenDRIVE by implementing modeling paradigms

(partial implementation for 1.8)

Concept in the concept paper

This concept is categorized as 2.0, only parts of this concept will be implemented that will not effect backward compatiblity
Geometry modeling in OpenDRIVE

(partial implementation for 1.8)

Concept in the concept paper

The concept proposes simplifying the modeling of object geometry in OpenDRIVE. In the current version, geometry records are scattered over the entire OpenDRIVE file. The records are not separated from attributes that describe semantic or logical information. The concept suggests to summarizing geometry records in a new geometry class that contains all available geometry types of OpenDRIVE.

This concept is categorized as 2.0, only parts of this concept will be implemented that will not effect backward compatiblity
External object referencing

Concept in the concept paper

OpenDRIVE is a format for the description of roads. It does not and shall not include complex high-resolution geometry of objects. For use cases that require a detailed description of objects, references to external sources shall be used. The current version of OpenDRIVE does not specify how external objects are referenced. Neither does it specify how these objects are transformed from one coordinate system to another, which is a key issue of this concept.

A possible use case for referencing an external object is a multi-storey car park, where the road description is done with OpenDRIVE, while the geometry description of the building is inserted by an external reference.

There are the following advantages:

  • It will be easier to place objects of any shape in OpenDRIVE without making changes to the standard itself.

  • The visual representation of scenarios created by OpenDRIVE is improved.

Interface to other (GIS) standards

Concept in the concept paper

OpenDRIVE does not include a detailed environment model. It focuses on the detailed description of the logical road network, not the road environment.

However, some use cases require a detailed description of both the road and the environment. In order to cover those use cases, the concept proposes to link OpenDRIVE to standards with an environment model like CityGML. The goal is to implement simpler references to spatial reference systems in OpenDRIVE.

There are the following advantages:

  • Improved alignment with other standards, for example, CityGML.

  • Datasets in the same geodetic datum may be linked directly, without transformation.

There are the following disadvantages:

  • The group agrees that there is nothing to note here as the proposed concept is fully optional.

Object list

Concept in the concept paper

The object definition in OpenDRIVE 1.6 is not sufficient, because object types in the current version of the standard are ambiguous. This concept proposes using a standardized object catalog. It also suggests an extension mechanism to define object entries that are compliant with the standard.

There are the following advantages:

  • OpenDRIVE object packages are restructured to achieve a clear and unambiguous object definition.

  • The object list is checkable and extendable.

There are the following disadvantages:

  • The fact that users can define extensions in namespaces of their choice offers maximum flexibility but restricts direct software support. Software support might even be not possible at all.

This will be aligned with the ASAM OpenXOntology, ASAM OpenLABEL, ASAM OSI

2.2.3. Concepts from Road Geometry

Parametric cubic splines

(for revision, could also be solved by better explaning ParamPloy3)

Concept in the concept paper

The concept proposes adding a parametric cubic spline element to OpenDRIVE. The element is designed to simplify the integration of measurement data into OpenDRIVE. It aims to simplify the creation of roads that originate in the real world.

There are the following advantages:

  • Simplifies the editing of coordinates.

  • Eliminate bends or gaps in roads.

  • Prevents the misuse of the line element. This often happens to avoid the calculation of polynomial coefficients.

There are the following disadvantages:

  • OpenDRIVE gets more complex due to the additional geometry option.

Transition area for OpenCRG

(linked to #50)

Concept in the concept paper

In OpenDRIVE 1.6, there is no option to ensure a smooth transition to an OpenCRG patch regardless of the OpenCRG data quality. OpenCRG data is directly added to the local OpenDRIVE elevation data (@mode = attached) or replaces any local elevation values from OpenDRIVE, such as elevation or superelevation (@mode = attached0 or @mode = genuine). To ensure a smooth simulation, OpenCRG data must be consistent with OpenDRIVE data.

This concept proposes the following solution: add optional transition areas for OpenCRG in both longitudinal and lateral direction. This will ensure existing OpenCRG data can be reused more easily in various OpenDRIVE road files while vehicle dynamics models run more robustly.

There are the following advantages:

  • The possibility of a smooth transition on OpenCRG patches in x- and y-direction, regardless of the data.

  • OpenCRG patches can be reused more easily.

Improved shape definition by using two cubic functions

Concept in the concept paper

This proposal aims at simplifying the definition of lateral road profiles. The road profile is applied to the left and right of the reference line, using only one cubic function for each direction. In OpenDRIVE 1.6, a complicated combination of superelevation and lateral shapes, with potentially multiple shapes at a single s-coordinate, is necessary to calculate the lateral profile.

There are the following advantages:

  • Easier and faster calculation of road elevation.

There are the following disadvantages:

  • There is no backward compatibility because this is a new feature of OpenDRIVE.

  • The methods of the concept are not detailed enough for the realistic description of sophisticated roads, for example, complex motorways.

Prohibit combination of shape and superelevation
for discussion in the project

Concept in the concept paper

In OpenDRIVE 1.6 there is the possibility of using shape and superelevation at the same time at the same x-y-/s-t-position. This can lead to multiple z-values when trying to calculate the z-values at a given x and y, because the s-t-coordinate system is rotated when using superelevation, and shape is defined perpendicularly to this axis system. The current OpenDRIVE Manager does not seem to provide reasonable results in these cases (it already provides wrong data when using only superelevation).

Simulations should be able to get an unambiguous z-value for a given x-y-position. Therefore, it needs to be discussed if shape and superelevation may be used at the same time or if this should be forbidden. If it stays allowed, it needs to be clearly defined how applications retrieve the correct z-values.

Because the investigations have only started towards the end of the concept project, this issue is postponed to the Standard Development Project.

2.2.4. Concepts from International Traffic Sign Model

Concept in the concept paper

This concept is categorized as 2.0, only parts of this concept will be implemented that will not effect backward compatiblity

Defining semantic data structures from AD test cases is not realistic, because it includes many different traffic situations and uncertainties. In order to deal with this task, this concept proposes a common semantics structure: a meta-language and a hierarchical data structure. The part of the hierachical data structure that is part of any local rule can be used as an original description part.

This concept does not target the case of defining meaning for multiple signs in OpenDRIVE. In this version, the concept intends that meaning is defined for each sign individually.

The semantics concept is based on the following ideas:

  • An analysis and logical description that is based on common information and knowledge.

  • Common/variable analysis of sign image and semantics.

  • Separation of common semantics from each country/region by the result of common/variable analysis.

The semantics concept extends the verification range of AD simulation.

There are the following advantages:

  • Multiple signs can be interpreted: Software vendors can build the interpretation logic based on each sign’s semantics.

  • It provides labeling information: In the case of machine learning, the semantic information of each traffic sign can be used as metadata for teachers.

  • Multi-agent simulation: It can be used for driving rules when expressing the behavior of other vehicles with a model.

There are the following disadvantages:

  • The semantics concept increases the map size

2.2.5. Concepts from the Area Modell

As the modelling approach that is detailed out in WP5-Area Modell is completely different from the modelling approach in OpenDRIVE, the use cases for OpenDRIVE and the Area Modell are different and only overlap in few cases. Therefore this concept will not be considered in this project.

2.3. UML Model adaption

Adapt the UML Model for OpenDRIVE 1.6.1 where necessary and deploy the Model onto a webserver, which is accessible via the ASAM website.

2.4. Perform a public OpenDRIVE conformity Test

In the project a OpenDRIVE "Cross Test" will be prepared and executed. The cross test than shall take place on the OpenDRIVE Version 1.6.1 and a preliminary version of OpenDRIVE 1.7.0 to provide feedback for this project.

2.4.1. Goal of the OpenDRIVE Conformity Test

The goal of the conformity test is to check the exchangeability of OpenDRIVE files and how this can be improved.

2.4.2. Needed Resoruces for the OpenDRIVE Conformity Test

  • Simple and complex example files in different levels of detail

  • Participants providing Tools and Application to use the example files

  • List of Metrics to determine the success of the Test

  • Feedback process to improve OpenDRIVE

3. Project Resources

3.1. Work Packages

Description

Deliverable

Effort (Man-days)

Standard Documentation

  • OpenDRIVE 1.7.0 (July 2021)

  • OpenDRIVE 1.8.0 (Nov 2022)

240 days

UML Model adaption

  • UML Model 1.7.0 (July 2021)

  • UML Model 1.8.0 (Nov 2022)

50 days

OpenDRIVE Confomitiy Test

  • Test Report 1.7.0

  • Test Report 1.8.0

240 days

Fixing known issues for 1.7.0

n.a.

40 days

Direct Links

n.a.

30 days

Fixing known issues for 1.8.0

n.a.

100 days

Junction Modelling

n.a.

240 days

Environmental Modelling

n.a.

200 days

Road Geometry

n.a.

240 days

Semantic Traffic Signs

n.a.

80 days

3.2. Company Commitments

Member companies contribute resources for the project as per the following table.

Table 1. Commitments
Company Location Commitment Participant(s) Participant Email

Hexagon

Bad Aibling

60days

Esther Hekele

dSpace

Paderborn

60days

Maximilian Jahn

3D Mapping

Holzkirchen

60days

Daniel Becher

Continental

Frankfurt

40days

Annemarie Albrecht

VirtualCitySystems

Grafing

60days

Roland Ruhdorfer

Vector

Stuttgart

50 days

Andre Pinnel

FiveAI

London

40 days

Jared Kahn

BMW AG

Munich

40 days

Detlef Strehmel

ANSYS

France

60days

Nicolas Dalmasso

IPG

3.3. Effort Summary

Table 2. Required Effort (man-days)
WP Category Project Members Service Provider Total

Standard Documentation

  • OpenDRIVE 1.7.0

  • OpenDRIVE 1.8.0

t.b.d

t.b.d

240 days

UML Model adaption

  • OpenDRIVE 1.7.0

  • OpenDRIVE 1.8.0

t.b.d

50 days

50 days

OpenDRIVE Confomitiy Test

  • OpenDRIVE 1.7.0

  • OpenDRIVE 1.8.0

t.b.d

t.b.d

240 days

Fixing known issues

  • OpenDRIVE 1.7.0

  • OpenDRIVE 1.8.0

t.b.d

t.b.d

140 days

Direct Links

t.b.d

t.b.d

30 days

Junction Modelling

t.b.d

t.b.d

240 days

Environmental Modelling

t.b.d

t.b.d

200 days

Road Geometry

t.b.d

t.b.d

240 days

Semantic Traffic Signs

t.b.d

t.b.d

80 days

Total

t.b.d

t.b.d

1460 days
Table 3. Resource Check
Project Members Service Provider Total

Required

Committed

t.b.d

3.3.1. Budget

This section details the budget required by the project to e.g. pay service providers and the funds to be provided by ASAM. The limits are determined as a factor of the total required work effort. The corresponding effort is allocated a fixed price of 700 EURO per man-day.

Table 4. Funding limits

Project Type

Factor

New, major, minor or revision standard development project

0.25

Study project

0.25

Concept project

0.75
Table 5. Funds required for Service Providers
Task Description Effort
[man-days]		 Cost
[€700 / day]

Model adaption

t.b.d

Total

t.b.d

t.b.d

4. Project Plan

4.1. Timeline

timeline ODR

4.2. Deliverables

At the end of the project, the project group will hand over the following deliverables to ASAM:

  1. OpenDRIVE 1.7.0 Specification

  2. OpenDRIVE 1.8.0 Specification

  3. UML Model for 1.7.0

  4. UML Model for 1.8.0

  5. xsd schema files for 1.7.0

  6. xsd schema files for 1.8.0

4.3. Review Process

The following quality assurance measures shall be carried out by the project:

  • Project member review

  • Public review

  • Reference implementation