Co-funded by the European Commission
TRAIN-ALL
Integrated System for driver Training and Assessment using Interactive
education tools and New training curricula for ALL modes of road
transport
Contract no. 031517
Towards an open format for Road Network
and 3D Landscape for driving simulators’
Deliverable No.:
D2.4
Dissemination Level
Public
Workpackage No.
WP2
Activity No.
A2.1
Workpackage Leader
Workpackage Title
Towards a Single Training and
Assessment Platform
Activity Title:
Common System Architecture
for Driving Simulators
Activity Leader:
Henk Janssen/ Philippe
Vanhulle
Henk Janssen
Authors (per company, if more than Henk Janssen (TNO) Philippe Vanhulle (Thales)
Ruben Smelik (TNO) Joris van de Vrande (Green
one company provide it together)
Ingmar Stel
(TNO) Dino)
Stéphane Espié (INRETS)
Status (Final; Draft; Revised Draft):
Final
File Name:
TRAIN-ALL Deliverable 2.4_final.doc
Project start date and duration:
01 November 2006, 38 Months
Submission date:
November 2009
Version Number:
V1.0
Pages Number:
46
Distribution
All partners, Restricted
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.4
contract no 031517
Version history
Version
V-
Date
Modifications
0.01
14 October 2008
First draft based on Open Scenario Format Specification
(meeting in The Hague in November 2008)
0.02
12 January 2009
Work in progress (meeting in Paris in January 2009)
0.03
12 March 2009
Work in progress (meeting in Wageningen)
0.04
19 March 2009
Editing on structure of report
0.05
22 April 2009
Editing on structure of report
0.06
01 August 2009
Editing on content of report
0.07
29 September 2009
Editing on content of report
0.08
15 October 2009
Editing on content of report
0.09
16 October 2009
Editing on content of report
0.10
28 October 2009
Draft version for review
1.0
01 December 2009
Final version
V1.0 Final Version November 2009
Page 2 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.1
contract no 031517
Executive Summary
TRAIN-ALL (see also www.train-all.eu.org) aims at defining and prototyping a Simulator Based
Training System Architecture for different land-based driver cohorts that integrates multimedia
software, driving simulators and on-board vehicle sensors, into a single modular system. New
systems based on the architecture will be cost-effective and adequate for training and assessment.
Within the Simulator Based Training System Architecture, three domains can be distinguished,
being.
Training System Architecture and interfaces:
This domain deals with the hardware and software system, its decomposition into system
components and the interfaces between components. Within WP2 a common architecture has been
described and proposed for TRAIN-ALL prototype development.
Environmental databases:
The environmental databases or landscape database consist of:
a 3D representation of the road and its surroundings for visualization purposes
the Road Network Database as the logical description of the road for generating realistic
behaviour of computer generated traffic.
Scenario database:
The scenario database contains the actors and the behavior of the actors in the environment.
Scenarios are designed for providing the trainee the right cues during his training lessons.Although
technologies have made tremendous strides in the past 10 years, it has been recognized that
current Road Network, 3D Landscape- and Scenario databases are lacking standardization for costeffective and easy exchange of databases between driver training systems of different
manufacturers.
To achieve cost-effective and time-saving use of Road Network-, Landscape- and Scenario
Databases various participants of the TRAIN-ALL project decided to define and develop an OPEN
STANDARD on the road network-, landscape and scenario formats that allows interoperability
(exchange) of databases between driving simulators and simulation tools of different manufacturers.
Research into the rationale and need for Scenario and Landscape formats resulted in the following
conclusions:
As the scenario format is dependent on the road network format, a prerequisite for exchanging
scenarios between simulators is an agreement on the definition of the road network. This has the
implication that first a common road network has to be defined before a common scenario
description can be made.
Given the fact that there are available landscape formats which could fulfil TRAIN-ALL requirements,
it was decided not to start development of a landscape standard, but to adhere to the standards or
initiatives of SEDRIS and CDB for achieving interoperability between 3D landscapes of different
driving simulators
Taking these conclusions into account and provided time available before end of project, it was
decided by the participants of TRAIN-ALL to focus first on a common Road Network Format.
To explore existing solutions on Road Network Formats, a survey was prepared. From the survey on
Road Network format standards send out worldwide 10 replies were received. These replies
resulted into the conclusion that there were only two existing de-facto standards available, which
could be assumed as being serious solutions for TRAIN-ALL. The two de-facto standards were:
V1.0 Final Version November 2009
Page 3 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.1
contract no 031517
OpenDRIVE, an open road network format description available since 2006 and managed by the
VIRES company,
ROADXML, not open yet when the survey was distributed, is an initiative of Oktal company and
was released in October 2009.
Next to these de-facto standards another applicable Road Network Format description was
discovered at TNO Science and Industry, department of Automotive. This Road Network format, is
incorporated in the PreScan tool for supporting development of Advanced Driver Assistive Systems
(ADAS) and In-Vehicle Information Systems (IVIS).
To determine a preferred solution, it was decided to perform a multi-criteria analysis. The following
graph shows the results of the multi-criteria analysis for each participant and each road network
solution. Also a mean value for every solution is calculated. The mean value of the road network
solution in PreScan has a much lower score than both OpenDRIVE and ROADXML.
Based on the results of the analysis as shown above and discussions afterwards, it turns out that a
unanimous decision of the road network format solution to pursue cannot be achieved. In our view,
both solutions OpenDRIVE and RoadXML, have their advantages and disadvantages. Taken into
account the these results, only OpenDRIVE and ROADXML are selected for further evaluation and
discussions on how unification or merging of above initiatives towards one road network format
standard is going to be achieved in the near future.
The TRAIN-ALL objective is still to have one standard for the future. How to achieve this is still not
clearly understood, but would it be possible to merge current initiatives OpenDRIVE and RoadXML
in the future towards one certified standard?
TRAIN-ALL participants believe that merging both OpenDRIVE and RoadXML (where also
commercial aspects are dealing), will be eased from a technical point of view if both road network
V1.0 Final Version November 2009
Page 4 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.1
contract no 031517
formats share the same functionality. In order to achieve this, for the near future a decision was
made by a number of TRAIN-ALL participants, to start collaboration with both Oktal and Vires
company. Also, to explore the feasibility of having one certified standard, a meeting was organised
with representatives of both OpenDRIVE and ROADXMLS during the last progress meeting of
TRAIN-ALL.
From this meeting the following was concluded:
The standardization process should be carried out by a community with representatives of
TRAIN-ALL participants, representatives currently in the Management boards of OpenDRIVE
and ROADXML, representatives of current communities using OpenDRIVE or ROADXML and
representatives of future users.
What shall be standardized is the description of the format of the Road Network with preferably a
specification of an XML scheme for file exchange purposes.
To provide users with services for evaluating the standard format exchange file, a file
assessment tool as service managed by the standard management authority shall be delivered
with the standard.
User acceptance is created by backward compatibility with the current (de-facto) standards
OpenDRIVE and ROADXML in use, meaning that users should be able to use the new standard
without large modification.
The process of merging the current de-facto standards into one common standard is not fully
understood at this moment. For defining and implementing this process, a CEN workshop was
proposed as the first initiative towards a common certified standard.
The standard should be developed in a short timeframe, estimated 3-5 years from now. This
would allow present and near-future replacement of old commercial software to adapt to an open
road format.
Conclusions
Standardization of Road Network Format, Landscape and Scenarios for driving simulators are
beneficial for users and manufacturers.
A Road Network Format standard is a prerequisite for standardization or exchange of scenarios
for driving simulators.
Current Open Road Network formats OpenDRIVE and ROADXML are not fulfilling TRAIN-ALL
requirements.
Achievements
The achievements within the TRAIN-ALL project on standardization of road network, landscape and
scenarios are:
TRAIN-ALL requirements for a common road network format have been established.
TRAIN-ALL Open Road Network requirements are proposed for implementation into
OpenDRIVE and RoadXML.
TRAIN-ALL participants are members of management boards of OpenDRIVE and RoadXML.
TRAIN-ALL participants have adopted current Open Road Network format initiatives
OpenDRIVE and RoadXML.
Open Source Projects within OpenDrive and RoadXML are initiated by TRAIN-ALL participants.
V1.0 Final Version November 2009
Page 5 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.1
contract no 031517
A discussion with current owners of de-facto road network standards was initiated towards
creation of a single certified road network standard format.
Recommendations
To setup a standardization community and continue the Open Road Network Standardization
process, with support of an official standardization body (i.e. CEN).
V1.0 Final Version November 2009
Page 6 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.1
contract no 031517
Table of Contents
Version history
2
Executive Summary
3
Table of Contents
7
List of Figures
8
List of Tables
8
Definitions, Glossary and Terminology
1
Abbreviations
6
1
Introduction
7
2
Referenced Documents
9
3
Standard Databases for Driving Simulators
10
3.1
3.2
3.3
3.4
Standardization initiatives for driving simulators
Standardization on Open Scenario Format
Standardization on Landscape format
Standardization on Road Network Format
10
11
12
15
3.4.1
3.4.2
16
16
3.5
4
5
Standardization Process
18
Road Network Format Requirements
19
4.1
4.2
4.3
4.4
4.5
19
19
20
20
23
Introduction
Structure of the lateral profile
Structure of the longitudinal profile
General Road Network Format Requirements
Design considerations
Survey on (open) Road Network Formats
24
5.1
5.2
Survey
Results of the Survey
24
24
5.2.1
5.2.2
5.2.3
24
26
26
5.3
5.4
6
Objectives on Road Network format standardization
Towards Road Network standardization
OpenDRIVE
ROADXML - Oktal
PreScan – TNO
Analysis of results
Way ahead
Conclusions, Achievements and Recommendations
Appendix A: Survey
V1.0 Final Version November 2009
27
29
31
32
Page 7 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.1
contract no 031517
List of Figures
Figure 3-1: History and trend of standardization initiatives ........................................................11
Figure 3-2: System architecture for road network presentation .................................................17
Figure 3-3: Approach for TRAIN-ALL standardization process ..................................................18
Figure 4-1: Road lateral profile .................................................................................................19
Figure 4-2: Road longitudinal profile ........................................................................................20
Figure 5-1; Data format structure of OpenDRIVE ......................................................................25
Figure 5-2: Data structure of ROADXML format ........................................................................26
Figure 5-3: Data Structure of PreScan format ...........................................................................27
Figure 5-4: Graph presentation of the results of the Multi-Criteria Analysis ...............................29
List of Tables
Table 2-1: Referenced Documents .............................................................................................9
Table 5-1: Results for OpenDRIVE of the Multi-Criteria Analysis ..............................................28
V1.0 Final Version November 2009
Page 8 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Definitions, Glossary and Terminology
General Terms
Term
Explanation
Functional requirements
Functional requirements capture the intended behaviour of the
system. This behaviour may be expressed as services, tasks, or
functions the system is required to perform.
Landscape
3D Representation of the natural environment and its objects (used
for visual purposes)
Requirement
A requirement is a condition needed by a user to solve a problem or
achieve an objective. Requirements describe the functions the
systems must provide, the constraints under which it must operate,
and the rationale.
Road network
Logical road network and geometry of roads and vicinity and its
horizontal and vertical road signs (lanes, traffic lights, material
identification, material characteristics).
Scenario
Description of the environment (terrain with the road network, its
actors in the environment and the behaviour of the actors in the
environment)
Specification
Specifications provide a precise description of the system that is to
be built. They serve as the basis of a contract between Purchasing
and Manufacturing. Specifications are often called technical
requirements.
Standard
A standard is a technical specification or report that is developed
with consensus across industry and is then approved by a body
recognised at the national or international level. Standards specify
how systems, products and services should operate, and they
should facilitate inter-operability without impeding innovation as new
technologies and approaches develop.
Technical Requirement
Characteristics, attributes, or distinguishing features, stated in terms
of quantified performance requirements and design constraints that
a system element must have to meet the functional requirements.
User requirements
User requirements are statements, in a natural language plus
diagrams, of what services the system is expected to provide and
the constraints under which it must operate. They should only
specify the external behaviour of the system, and should avoid
system design characteristics. They should be written using natural
or operational language and simple intuitive diagrams, because they
are meant for people who do not have a detailed technical
knowledge of the system.
V1.0 Final Version November 2009
Page 1 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Road construction terms
Term
Explanation
Alignment (road)
Cross slope/Banking / Super elevation, horizontal and vertical curvature
of a road
Bollard
Rigid posts that can be arranged in a line to close a road or path to
vehicles above a certain width
Bottleneck
Section of a road with a carrying capacity substantially below that of other
sections of the same road
Botts' dots
Non reflective raised pavement marker used on roads
Cat's eye
Reflective raised pavement marker used on roads
Chicane
Sequence of tight serpentine curves (usually an S-shape curve or a bus
stop) in a roadway
Corniche
Road on the side of a cliff or mountain, with the ground rising on one side
and falling away on the other
Curb
Edge where a raised pavement/sidewalk/footpath, road median, or road
shoulder meets an unraised street or other roadway
Curb extension
(or also kerb extension, bulb-out, nib, elephant ear, curb bulge and
blister) Traffic calming measure, intended to slow the speed of traffic and
increase driver awareness, particularly in built-up and residential
neighborhoods
Fork
(literally "fork in the road") Type of intersection where a road splits
Guard rail
Prevents vehicles from veering off the road into oncoming traffic, crashing
against solid objects or falling from a road
Infrastructure
An infrastructure is a road network combined with the road markings and
road equipment connected to this road network
Lane
A lane is assigned for a specific use and / or for a specific actor (e.g.
direction, traffic lane, bike lane, sidewalk / pavement, bus lane, tram, etc.)
It should be possible that lanes overlap, e.g. one can drive with a car on a
tram-lane. Horizontal and vertical markings can be linked to a specific
lane (e.g. different speed limits per lane). Space that is not assigned to
lanes can be assigned to specific actors.
Median
On divided roads, including expressways, motorways, or autobahns, the
central reservation (British English), median (North American English),
median strip (North American English and Australian English), neutral
ground [Louisiana English] or central nature strip (Australian English) is
the area which separates opposing lanes of traffic
Milestone
One of a series of numbered markers placed along a road at regular
intervals, showing the distance to destinations
Navigation/
finding
Path An algorithm that computes a desired path according to constraints
Path
A succession of road sections to go from point A to point B using the road
network
Pavement
The road regarded as a geo-construction
V1.0 Final Version November 2009
Page 2 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Term
Explanation
Pedestrian
crossing
Designated point on a road at which some means are employed to assist
pedestrians wishing to cross safely
Pullout
(or also lay-by, pull-off). A paved area beside a main road where cars can
stop temporarily to let another car pass
road network
A road network consists of one or more roads which sometimes
intersect.
road
A road is a path between two points, which can be the same (in case of
cycle). It starts at one point and finishes at the second point.
Roads can intersect other roads. A road can consist of many road
sections.
A road is defined by its longitudinal profile and lateral profiles (that
includes the road verge).
A road can consist out of one or more roadways.
road network
A road network consists of one or more roads which sometimes
intersect.
roadway
A roadway is a description of the area on which a road user can act
(tarmac, pavement, bikeway).
A roadway is structured using some specific road information (normally
by horizontal road marking) elements to inform the actor about the
layout of the space which are commonly named lanes.
Under normal circumstances it is not possible to go change between roadways
without an intersection. For instance, a bike lane next to road with grass in
between is considered as two roadways; however a bike lane on a road is one
roadway.
road lateral profile
A lateral profile is a cross-section definition (2D cross-section curve X,
Z). The origin of the coordinate system is the point along the longitudinal
profile where the cross-section is defined. The origin of the lateral profile
can be the road axis or the roadway axis.
road longitudinal A longitudinal profile is a 3D-curve described by X, Y, Z (Z=elevation)
profile
series of points (straight, curve, clothoïd can be common superdescriptions).
road information A road information element describes objects or particular features
elements
attached to the road environment. This includes at least:

horizontal markings like lines, zebra, stop lines, dedicated stop lines,

vertical markings like arrows above road,

but also road pavement description like speed bumps, potholes,

and road equipment as public lighting, barriers, trees, speed bumps,
rumble strips, etc., which are all on the road (and maintained as well by
the road operator).
Road information elements are located and are preferentially referenced
in the road network in the longitudinal profile.
The attached information can change the state of the environment; it
V1.0 Final Version November 2009
Page 3 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Term
Co-funded by the European Commission
Explanation
can be static or dynamic (i.e. information can change); it can be assigned
to a specific lane in the roadway.
road network
graph
A topological representation of the road network
road section
A section is the stretch of road between two intersections. Bridges and
crossing levels could be special sections of a road. The beginning and
ending of a road are defined by (sometimes dummy) intersections.
road intersection
A road intersection is a virtual point to which a section can connect.
Several sections of different roads can connect to the same intersection.
roadway
A roadway is a description of the area on which a road user can act
(tarmac, pavement, bikeway).
A roadway is structured using some specific road information (normally
by horizontal road marking) elements to inform the actor about the
layout of the space which are commonly named lanes.
Under normal circumstances it is not possible to go change between roadways
without an intersection. For instance, a bikelane next to road with grass in
between is considered as two roadways; however a bikelane on a road is one
roadway.
Road-traffic safety
Process to reduce the harm (deaths, injuries, and property damage)
resulting from crashes of road vehicles travelling on public roads
Roadwork
Part or all of the road has to be occupied for work or maintenance relating
to the road
Roughness
Deviations from a true planar pavement surface, which affects vehicle
suspension deflection, dynamic loading, ride quality, surface drainage and
winter operations. Roughness has wavelengths ranging from 500 mm up
to some 40 m. The upper limit may be as high as 350 m when considering
motion sickness aspects; motion sickness is generated by motion with
down to 0.1 Hz frequency; in an ambulance car driving 35 m/s (126 km/h),
waves with up to 350 m will excite motion sickness.
Rumble strip
One of a set of raised strips on a road that makes a low sound when
vehicles drive over it to warn drivers to slow down or change direction
because they are approaching something
Shoulder
Reserved area by the verge of a road, generally it is kept clear of all traffic
Speed bump
(speed hump or sleeping policeman) a small raised area built across a
road to force people to driver slowly
Texture (roads)
Deviations from a true planar pavement surface, which affects the
interaction between road and tire. Microtexture have wavelengths below
0.5 mm, Macrotexture below 50 mm and Megatexture below 500 mm
Traffic calming
Set of strategies used by urban planners and traffic engineers which aim
to slow down or reduce traffic, thereby improving safety for pedestrians
and bicyclists as well as improving the environment for residents
V1.0 Final Version November 2009
Page 4 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Term
Explanation
Traffic light
Also known as a traffic signal, stop light, stop-and-go lights, robot or
semaphore, is a signaling device positioned at a road intersection,
pedestrian crossing, or other location in order to assign right of way to
different approaches to an intersection
Trajectory
Successive positions of an actor over time
This terminology is inspired or copied from Wikipedia source.
oad construction requires the creation of a continuous right-of-way, overcoming
geographic obstacles and having grades low enough to permit vehicle or foot travel and
may be required to meet standards set by law or official guidelines. The process is often
begun with the removal of earth and rock by digging or blasting, construction of embankments,
bridges and tunnels, and removal of vegetation (this may involve deforestation) and followed by
the laying of pavement material. A variety of road building equipment is employed in road
building.
After design, approval, planning, legal and environmental considerations have been addressed
alignment of the road is set out by a surveyor. The radii and gradient are designed and staked
out to best suit the natural ground levels and minimize the amount of cut and fill. Great care is
taken to preserve reference Benchmarks.
Roadways are designed and built for primary use by vehicular and pedestrian traffic. Storm
drainage and environmental considerations are a major concern. Erosion and sediment controls
are constructed to prevent detrimental effects. Drainage lines are laid with sealed joints in the
road easement with runoff coefficients and characteristics adequate for the land zoning and
storm water system. Drainage systems must be capable of carrying the ultimate design flow
from the upstream catchment with approval for the outfall from the appropriate authority to a
watercourse, creek, river or the sea for drainage discharge.” (Wikipedia source)
R
V1.0 Final Version November 2009
Page 5 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Abbreviations
Abbreviation
Explanation
2D
2-dimensional
3D
3-dimensional
ADAS
Advanced Driver Assistive Systems
API
Application Programming Interface
CAD
Computer-Assisted Design
CDB
Common Database
CEN
European Committee for Standardization
CGE
Computer Generated Entities
DBGS
Database Generation System
DEM
Digital Elevation Model
DIS
Distributed Interactive Simulation
DS
Driving Simulator
GIS
Geographical Information System
HWIL
Hardware-In-the-Loop
HLA
High Level Architecture
IEEE
Institute of Electrical and Electronic Engineers
IG
Image Generator
IVIS
In-vehicle Information System
MSDL
Military Scenario Definition Language
RFI
Request For Information
RND
Road Network Description
SEDRIS
Synthetic Environment Data Representation and Interchange Specification
SISO
Simulation Interoperability Standards Organisation
TH
Time Headway
TLC
Time to Line Crossing
TTC
Time To Collision
WP
Work Package
XML
Extensible Markup Language
V1.0 Final Version November 2009
Page 6 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
1 Introduction
The rapid development of information and other technologies have produced a large variety of
training tools available for practically all driver groups, from basic training of novice drivers to inservice training of experienced drivers. The technological development hence offers a large
array of training tools, from simple video sequences to high fidelity driving simulators, offering
both realistic movements and visual displays.
And yet, for all driver types, there still exists no large and European Simulator Based Training
tools market, despite the maturity of the relevant technology. One of the major obstacles is the
high fractionalisation of the market, with most Simulator Based Training manufacturers
operating in few countries and a total lack of standardisation and modularity, that would allow
users to expand their systems gradually to different scenarios/user groups or to interconnect
different Simulator Based Training tools. Currently, users are totally dependent upon the viability
and market plans of the vendor they choose to purchase from and thus are reluctant to invest
more.
TRAIN-ALL (see
Training System
software, driving
systems based
assessment.
also www.train-all.eu.org) aims at defining and prototyping a Simulator Based
Architecture for different land-based driver cohorts that integrates multimedia
simulators and on-board vehicle sensors, into a single modular system. New
on the architecture will be cost-effective and adequate for training and
Within the Simulator Based Training System Architecture, three domains can be distinguished,
being:
Training System Architecture and interfaces:
This domain deals with the hardware and software system, its decomposition into system
components and the interfaces between components. Within WP2 a common architecture has
been described and proposed for TRAIN-ALL prototype development.
Environmental databases:
The environmental databases or landscape database consist of:
A 3D representation of the road and its surroundings for visualization purposes
The Road Network Database as the logical description of the road for generating
realistic behaviour of computer generated traffic. Also the Road Network database is
input for the car simulator for instance for generation of sounds dependent on the type of
road surface.
Scenario database:
The scenario database contains the actors and the behavior of the actors in the environment.
Scenarios are designed for providing the trainee the right cues during his training lessons.
Although technologies have made tremendous strides in the past 10 years, it has been
recognized that current Road Network, 3D Landscape- and Scenario databases are lacking
standardization for cost-effective and easy exchange of databases between driver training
systems of different manufacturers.
For exchanging 3D landscape databases between different Driver Training Systems, most of
the time separate, non-harmonized, Image Generator (IG) manufacturer proprietary tools and
processes are required to generate and modify the databases, resulting in sometimes
V1.0 Final Version November 2009
Page 7 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
incongruous, incomplete, and closed database formats. As a result, the creation and update of
such databases is still a costly and recurring labour-intensive exercise.
Furthermore, various simulator components (e.g. traffic generator) require different content and
the level of detail, depending on the scope of the simulation. For instance, a traffic flow
simulation requires the possibilities to simulate a road network with relatively little emphasis on
visualisation. A driving simulator run on the other hand can often be based on a relatively simple
road network, but puts large requirements on the visualisation, including a level of detail (road
furniture, trees, etc.) that is irrelevant for a traffic flow model.
To achieve cost-effective and time-saving use of Road Network-, Landscape- and Scenario
Databases which are interoperable between different simulators and simulation tools, various
participants in the TRAIN-ALL project decided to develop recommendations for general
agreements that apply to interoperable driving simulation systems. The objective of this activity
is to define and develop an OPEN STANDARD on the road network format, landscape and
scenario formats that allows interoperability (exchange) of databases between driving
simulators and simulation tools of different manufacturers.
This definition of the OPEN STANDARD should not be restricted for use in the Civil or Military
Application domain, or to specific use for training or research. The intention is to have a
standard which is flexible and extendable for purposes other than training as is currently
pursued by TRAIN-ALL.
The structure of the document is according to a logical flow of activities to establish the
objective of the research.
Chapter 2 of this document provides a list of referenced documents.
Chapter 3 deals with the identification of lacking standards on the landscape, Road Network
and Scenario Format, and provides the rationale on the selected research on developing the
Road Network Format standard. An approach on the standardization process is proposed.
Chapter 4 presents the Road Network Format Requirements as a result of several workshops
with TRAIN-ALL participants.
Chapter 5 presents the survey and provides the results of the survey and analysis on Open
Road Network Format standards.
Chapter 6 finally presents the conclusions, achievements and recommendations
This document is a deliverable of the activity A2.1 (Common System Architecture for Driving
Simulators based on Interoperable Federates of TRAIN-ALL, named Deliverable D2.4. The
activity is part of the overall WP2 (Towards a Single Training and Assessment Platform).
V1.0 Final Version November 2009
Page 8 of 46
Co-funded by the European Commission
TRAIN-ALL Deliverable 2.4
Contract no. 031517
2 Referenced Documents
These documents constitute the reference for the management of the project. There are the
applicable documents issued before the launch of the project, the different plans produced by
the TRAIN-ALL project and the applicable technical documents references used in the activities
as described in this document. The Quality manager ensures that the quality plan is available to
all concerned regarding this baseline and that its requirements are met.
Table 2-1: Referenced Documents
Reference
[1]
Title
Date
Comment
Public on
OPENDRIVE , Format Specification, Rev. 1.2, VIRES
2 January 2008 www.opendrive.
Simulationstechnologie GmBH,
org
[2]
OKTAL-RND, Road Network Description, Dossier de
specifications du format RND V1.2
[3]
Open Scenario Format, Green Dino, Version 1.5
[4]
Scenario Scripting Language , Programming Tool
Version
2.25, 9 January 2007
Dr.-Ing. Reiner Foerst GMBH
[5]
TRAIN-ALL Del. 8.1, “Project Management and Quality
Manual“ Ph.Vanhulle
2007
[6]
TRAIN-ALL Consortium Agreement
2007
[7]
TRAIN-ALL Del. 2.1 “Common System Architecture for
driving simulators based on interoperable federates”
W.Huiskamp R.Jansen (TNO), R.Holzer (UP),
I.Mandsouris (ICCS), Ph.Vanhulle (Thales), 2008
2008
[8]
TRAIN-ALL Del. 3.6 “Dynamic Scenario Management
module”, Christian Mark (WIVW), Jorrit Kuipers (Green
Dino), Ingo Wassink (Green Dino)
2008
[9]
TRAIN-ALL Del. 3.6 “Dynamic Scenario Management
module”, Christian Mark (WIVW), Jorrit Kuipers (Green
Dino), Ingo Wassink (Green Dino)
2008
[10]
TRAIN-ALL Del. 3.10 “Enhanced Reality module”, Heidi
Grattenthaler & Alexandra Neukum (IZVW), Christian
Mark (WIVW), Kai Foerst (FOERST), Jorrit Kuipers
(Green Dino)
2008
V1.0 Final Version November 2009
27 April 2006
www.oktal.fr
Train-All Draft
from FOERST
Page 9 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
3 Standard Databases for Driving Simulators
3.1 Standardization initiatives for driving simulators
Before introducing current standard developments related to the driving simulation domain, the
definition of what a standard is exactly has to be provided
A “Standard” is “a definition or format that has been approved by a recognized standards
organization (e.g. IEEE, ISO, CEN, W3C,…) or is accepted as a de-facto standard by the
industry”.
A de-facto standard refers to a standard “in practice” and often applies to commonly used
technologies, protocols, information file formats etc.(example Microsoft PowerPoint)
If a standard is publicly available and has various rights to use associated with it often this
standard is indicated as an “open” standard”. The term "Open standard" is sometimes coupled
with "open source" with the idea that a standard is not truly open if it does not have a complete
free/open source reference implementation available
The use of standards has become very common in our daily life and is often taken for granted
(for instance wall socket connectors for our home electrical appliances). The need and objective
for standardization within TRAIN-ALL was driven by the many advantages standards provide,
being:
Standards and methodologies provide the building blocks for interoperability, reusability and
increased capability in a cost effective manner.
Standards level the playing field between large and small solution providers, creating a
larger, more diverse marketplace.
Standards compliance is an objective measure of compatibility against which to evaluate
deliverables.
Standards reduce / avoid duplication of efforts / costs.
Standards improve vendor independence
Standards increase the choice of vendors
Open standards reduce the cost of switching vendors leading to increased vendorindependence and lower barriers to enter market
Open standards drive the quantity and diversity of vendors and their ability to address user
requirements
Standards increase the choice of solutions by a greater accessibility to alternate vendors
and increased ability for vendors to provide open solutions
As is described in the introduction of this document, the remaining domains for standardization
consist of the landscape, road network and scenario format. First a definition of these terms is
given for proper understanding of the described standardization activities in this document.
Landscape (for visual purposes) is a description of the 3D natural environment and its objects.
Road Network is the description of the logical road network and the geometry of roads and
vicinity together with its horizontal and vertical road signs (lanes, traffic lights, material
identification, material characteristics).
V1.0 Final Version November 2009
Page 10 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
A Scenario is the description of the actors and the behavior of the actors in the environment.
The following figure shows standardization initiatives of the mentioned architectural domains. As
can be concluded from this figure, the number of standardization initiatives in the domain has
increased enormously during the last decade. The importance of having standards is already
well understood by various standards development boards.
Figure 3-1: History and trend of standardization initiatives
So for TRAIN-ALL it was decided end 2008 to research into standardization of Landscape,
Scenario and Road Network formats.
3.2 Standardization on Open Scenario Format
Driving simulators require deterministic scenarios for training and especially for testing. The
scenario should present a blue vehicle from the right at collision course if the scenario so
requires. It can be really convenient though to have pseudo-randomized traffic in the scenario
too. Thus, other ‘less relevant’ traffic participants can be present in the scenario without the
need to script their behaviour in detail. Simulator manufacturers not only use different traffic
models, but also use different ways to specify the scenario for the computer generated traffic. At
the moment there is no common description for driving simulator scenarios. Initiatives like the
Military Scenario Definition Language1 (MSDL) are aimed at standardization of scenario
definitions, but these standards lack specific driving simulator functionality, like dealing with a
logical road network description. Where most manufacturers use their own specific scripting
language, others use open source languages, such as Lua®2. Some provide hard coded
1
2
MSDL is an XML data interchange format used to interchange military scenario across systems and
applications
Lua® is an interpreted oriented object language of script for user’s software programming extension
heavily used in videogames
V1.0 Final Version November 2009
Page 11 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
scenarios, which do not allow scenario modifications without changing the core simulator
software.
Designing, testing and optimizing traffic scenarios is very time consuming work. Given the lack
of standardization, the chances of reuse of scenario code is very small.
Given these disparate scenario languages, standardization of scenarios can only be realized on
a meta-level. That is: each manufacturer implements a generic description of a traffic situation
in their own scenario language, so that different systems will show similar scenarios.
Similar problems exist if a connection between a driving simulator to other simulators or
simulations is required. The definition of ‘other simulators’ is quite broad, this could mean that
you connect two driving simulators, but it could also mean that you connect an intelligent model
predicting driver behaviour. The solution there is on one hand quite simple, but on the other
hand very complex. If only the position3 is transmitted to the other simulators (or intelligent
devices), the receiver has to remap this position on the road network. This remapping leads to
errors, for instance with overlapping routes on crossings where the same position can remap to
different routes. To overcome this remapping, the simulators could exchange higher level data,
like the route they are driving on, but this requires that the road network definition files are
interpreted in the same way.
Concluding, a prerequisite for making an exchange of scenarios between simulators is an
agreement on the definition of the road network. So first a common road network has to be
defined before a common scenario description can be made. Furthermore, exchange of
scenarios normally does not guarantee the same result in different simulators, due to:
Differences in simulator fidelity or realism
Differences in simulator implementation (Image Generator, Projection System) and
capabilities and implementation of the traffic generator module.
Taking these conclusions into account and provided time left before end of project, it was
decided by the participants of TRAIN-ALL to focus first on a common Road Network Format.
3.3 Standardization on Landscape format
The landscape or 3D terrain database represents the virtual environment visually presented to
the trainee. Besides visual information, it contains some logical information as well. An
important part of this logical information is the road network or infrastructure geometry, which
represents the logical connection between roads, the number of lanes on a road, the curvature
of a curve in mathematical numbers and many other functions (road signs, road markings).
Typically, the logical and visual representation of the road network can be automatically created
on the basis of the road network description file.
The level of detail and resolution of the terrain database is application dependant. In the typical
driving simulator database there is no detailed representation of the surroundings of the roads.
For instance, a house 3 km from a road is usually not represented at all, and a house on the
corner of a junction is often represented using only a box describing the occlusion caused by
the house.
The above is of course only true if we make the assumption that trainees stay on the roads; in
cross-country / all-terrain driving simulators (e.g. for military training purposes) where off the
road driving is allowed, we need a much more detailed landscape. For tactical training
purposes, the required resolution is even higher.
3
x, y, z, Pitching , Rolling , Yawning 
V1.0 Final Version November 2009
Page 12 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
For the development process of and type of 3D terrain databases, the following distinctions
have to be made
A landscape which does not represent a part of the real world and most of the time is
optimized for training or research. This database does not have to represent the real world;
this landscape type is called ‘geo-typical’ in the sense that it represents a typical
environment that could exist in the real world. For example an urban environment in
Western European style. Developing this kind of geo-typical database involves most of the
time manual work. Due to this manual work, exchange of landscapes between different
simulators is harder to achieve than in case of:,
A landscape which is a model of a part of the real world. This database type is called ‘geospecific’ in the sense that it represents a specific environment that exists in the real world
and is geographically correct. For example, a model of Paris. Typically, these models are
generated based on geographical source data, including digital maps, elevation
measurements, satellite imagery and photographs or radar data. Having the same source
data with an agreed development process for generating the landscape provide a larger
guarantee that landscapes can easily be exchanged between different simulators.
Integration of Landscape and Road Network
The road network information required for visual representation is composed essentially of
geometrical information of the road network with the vertical and horizontal road markings and
road equipment. Inserting a 3D representation of a road network into an existing 3D
representation of a landscape requires changing and seaming the landscape to the 3D
representation. The 3D road profile cannot be changed during merging with the landscape,
because other systems (e.g. autonomous agents) are depending on the profile to stay intact.
For two simulators using the same road network information, the landscape might differ
substantially. Examples of this include:
Visual differences due to colours, texturing, external 3D models, rendering quality, display
brightness and contrast etc. This issue is often hard to avoid or solve completely.
Terrain profile differences due to:
Different implementations of road merging and stitching algorithms, these differences
are localised to the vicinity of the roads;
For geo-referenced terrain, different resolutions of Digital Elevation Models (DEM) may
be used, or elevation may have been obtained differently. This will result in large
differences in elevation all over the landscape. For instance, a small river (with a bridge
in the road network) in a 1-meter resolution DEM might not show up at all in a 30-meter
DEM.
Terrain features differences; one landscape model may be less complete than the other. For
instance, one terrain model only has elevation and vegetation data, while the other includes
urban environments.
It will depend on the type of application to which extent this is problematic. For a car driving
trainer, difference in profile and terrain features might influence visibility (around the corner in a
mountain pass, buildings obscuring sight in urban environments). For some military simulations,
off-road driving will be allowed and used; the entire landscape model is drivable. In this case,
differences in the landscape will have a much larger influence.
In order to exchange road network and landscapes effectively, it is recommended agreeing on a
common practice and workflow in creating 3D terrain databases, and, at least, starting from the
same source data.
This problem is not unique to driving simulations; within the military modelling and simulation
community, a lot of research and developments is put in creating exchangeable databases and
V1.0 Final Version November 2009
Page 13 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
numerous standardisation efforts have been initiated in the past. Two dominant proposals are
the SEDRIS and CDB initiatives, which are introduced below.
Synthetic Environment Data Representation and Interchange Specification (SEDRIS) (ref.
SEDRIS website)
SEDRIS is managed by the SEDRIS organisation (www.sedris.org) and is fundamentally about:
the representation of environmental data, and
the interchange of environmental data sets.
To achieve the first, SEDRIS offers a data representation model, augmented with its
environmental data coding specification and spatial reference model, so that one can articulate
one's environmental data clearly, while also using the same representation model to understand
others' data unambiguously. Therefore, the data representation aspect of SEDRIS is about
capturing and communicating meaning and semantics.
For the second part, practice indicates that it is not enough to be able to clearly represent or
describe the data; we must also be able to share such data with others in an efficient manner.
So the second aspect of SEDRIS is about interchange of data that can be described using the
data representation model. For the interchange part, the SEDRIS API, its format and all the
associated tools and utilities play the primary role, while being semantically coupled to the data
representation model.
In this regard, SEDRIS does not try to judge, side with, separate, or distinguish how various
domains use environmental data. Instead, SEDRIS provides a unifying mechanism for all of
them to describe (and subsequently share) such data without detracting from one or the other.
Because of these characteristics, the representational aspect of SEDRIS is much like a
language or a method for unambiguously describing the environment, independent of whether
the environment is geo-specific, geo-typical or completely fictitious. And the interchange aspect
is a mechanism for sharing the described environmental data.
In October 1999, SEDRIS began the process of establishing international standards through the
combined International Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC). SEDRIS technologies have been assembled into the
following specification and language binding standards through the ISO/IEC
Establishing formal standards was a key part of the SEDRIS development plan. Pursuing
international standardization helped ensure a broad base for applying SEDRIS technologies,
and opened interoperability opportunities in multiple national and international markets.
However, developing formal specification standards was insufficient to realize all the
interoperability potential that SEDRIS could provide. Establishing tested implementations,
guidance and education documents, and data coding mapping documents was also required.
Toward this end, in the spring of 2000 the Simulation Interoperability Standards Organization
(SISO) established two Product Development Groups (PDGs) to address technical
implementation of the SRM and EDCS ISO/IEC standards.
Common Data Base (CDB) (ref. Presagis website)
The Common Database (CDB) specification is an open synthetic environment database
specification managed by the company Presagis. Because it is a common database
specification, any database built to the CDB specification is referred to as a Common Database
(CDB). The CDB is a single-copy data repository from which various simulator client-devices
are able to simultaneously retrieve, in real-time, relevant information for performing their
respective runtime simulation tasks. A CDB that conforms to the CDB specification contains
datasets organized in layers and tiles that represent the features of a synthetic environment for
V1.0 Final Version November 2009
Page 14 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
distributed simulation applications. Also, a CDB can be readily used by existing simulation
client-devices, such as legacy IGs, radars, and CGF, through a publishing process performed in
real-time.
While improving database maintainability, the CDB specification also enhances unity and
correlation between various simulator level client-devices, such as visual and radar. As a result,
one of the main benefits of the CDB specification is the elimination of correlation errors arising
from alternating and sometimes conflicting data representations required by each of the
simulator client-devices. The specification achieves this by allowing all simulator client-devices
to share, in runtime, a single repository for the synthetic environment information. In addition, a
CDB can also be used as a master repository for the authoring tools, thereby enabling the
interchange of CDB content between DB workstations. And, because the CDB specification
internal data representation model is based on the native formats used by industry-standard
toolsets, it eliminates the time consuming off-line database compilation process for each client.
The CDB specification has been standardized on formats adopted by the industry, meaning that
the data structures used in CDB specification synthetic environment databases are different
than those used in relational databases. These data structures facilitate the adaptation of
existing authoring tools to read/write/modify the CDB as well as the development of runtime
publishers designed to operate on these data structures. CDB internal data representation is
based on three commercial data formats endorsed by leaders of the simulation database tools
industry:
Tiff/GeoTiff -for the representation of terrain altimetry, terrain raster imagery, terrain surface
characteristics relevant to simulation, as well as texture for 3D culture.
OpenFlight-for the representation of 3D culture and moving models.
Shapefile-for the instancing and attribution of statically positioned point, lineal, and areal
2D/3D culture features.
Within TRAIN-ALL is was decided not to start development of an landscape standard, but to
adhere to the standards or initiatives of SEDRIS and CDB for achieving interoperability between
landscapes of different driving simulators.
3.4 Standardization on Road Network Format
In driving simulators people are driving on roads and interacting with other participants in the
simulation. The other participants in the simulation or Computer Generated Entity (CGE)
behave according to certain predefined rules. To apply these, the traffic model must have
knowledge of the road, the road surroundings and the other traffic participants. It must know
how fast vehicles are allowed to drive, if overtaking is allowed, if the car from the right has
priority, if the view to right is obstructed by a house etc. Most of these things are obvious for a
normal driver; it is something he deducts from the scene in front of him, recognizing the signs,
the type of road he rides on etc., and makes decisions based on all this information. The
problem for the computer generated traffic is that computers cannot ‘see’ and interpret the world
like a human. Thus, all the relevant elements need to be described in such a way that the
computer generated traffic driver can ‘read’ them and generate the appropriate traffic behaviour.
Missing information or small flaws in definitions can lead to undesired and/ or unnatural
behaviour of the computer generated traffic.
V1.0 Final Version November 2009
Page 15 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
3.4.1
Co-funded by the European Commission
Objectives on Road Network format standardization
Within TRAIN-ALL, having a common agreed standard road network became one of the most
important aspects of the common architecture to pursue. The objectives of the standardization
activities related to the common road network format standard were agreed at the end of 2008,
being:
To define and standardize an interoperable road network format for representation in all
kinds of applications related to road transportation, such as
Driver Training Systems including
Visual/sound systems of driving simulators
Intelligent Traffic Generators for driving simulators
Motion and road vibration generation for driving simulators
Driver behaviour research in driving simulators.
Road design research and verification of new designs
Car Behavior research (dynamics)
Car Components Test Environments
Test Environments for Driver Assistance Systems
Traffic Flow Analysis Tools
An approach and plan how to pursue standardization was defined (par 3.5) and initial thoughts
on what to standardize were discussed.
3.4.2
Towards Road Network standardization
For determination to what standardization should apply, the following architecture of the road
network database system and support tools was defined.
V1.0 Final Version November 2009
Page 16 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Figure 3-2: System architecture for road network presentation
The Exchange File is described as part of the Open Standard. An XML format is selected
because this is an easy and readable format for exchanging files between applications.
The Parser is implemented as software capable of reading/writing the exchange file.
A common software library is identified, containing mathematical functions/primitives. As an
example a standard function which would transfer the curvilinear description of the road into a
set of points in the geodetic coordinate system could be part of this library, thus ensuring that
the representation of the road is the same in every simulator.
The memory structure is seen as the database that resides into the simulator. The structure of
this database has to be designed in such a way o that each application can easily access the
database for its own purpose via the API.
A number of simulator applications are identified in the figure in green color, such as the visual,
dynamics, sound of the car simulator and applications such as a Traffic Simulator for generation
of intelligent computer generated traffic into the environment. These applications interact with
the runtime memory structure for the road network database.
To have a quick start and minimize investment for new users on the road network standard,
TRAIN-ALL participants agreed on the objective that next to a description of the Road Network
format also provision of the Parser and Common Mathematical Library components would be
required by means of an Open Source Project.
Having an open source Road Network Generator would be preferable, but initially no high
priority was set on pursuing this objective.
V1.0 Final Version November 2009
Page 17 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
3.5 Standardization Process
In order to develop a standard, the following approach was adopted between consortium
partners for developing an open Road Network format standard.
Figure 3-3: Approach for TRAIN-ALL standardization process
The process starts with identifying requirements on the future road network standard. Together
with a survey on existing solutions next a specification of the road network can be established.
Having a specification (format) described, the official standardization process with a
standardization authority can start, in parallel with development or adaptation of support tools
for the draft road network format standard (of instance parsers / mathematical libraries).
Implementation of the solutions will lead to tools for supporting the application of the Road
Network Format standard. Such tools will also lower investments and ease the adoption of the
new standard.
To support the survey a Request For Information (RFI) is distributed to about 60 driving
simulator manufacturers and research institutes on driving simulation. The content of the RFI as
well as the results are provided in appendix A.
V1.0 Final Version November 2009
Page 18 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
4 Road Network Format Requirements
4.1 Introduction
Before requirements can be defined, agreement has to exist between participants on definitions
of the road network, its structure and the context of the road network. To structure the road
network, several levels can be distinguished.
structure of the pavements/ shoulders / embankment-soft shoulder (lateral profile);
geometric laying out (longitudinal profile: curve, clothoid), country network (intersection,
level crossing, roadmap);
road signs (horizontal, vertical – road equipment): two symbolic layers description;
pathfinding information (vehicle users).
Next a clear understanding of the different terms on roads and road networks has to be
established between participants. For a description and explanation of the different terms see
chapter Definitions, Glossary and Terminology. A more detailed explanation of the lateral and
longitudinal profile is provided in the next paragraphs.
4.2 Structure of the lateral profile
The lateral profile of the road is structured in parts that are described as e.g. hard shoulder,
roadway and grass (see Figure 4-1).
Figure 4-1: Road lateral profile
V1.0 Final Version November 2009
Page 19 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
The embankment is a part of the terrain on which the road is built (including soft shoulder (if
existing) and transition area (if existing) to the terrain. Soft shoulder is considered part of the
lateral profile (can be populated with trees).
4.3 Structure of the longitudinal profile
A longitudinal profile is a 3D-curve described by X, Y, Z series of points. (straight, curve,
clothoïd can be common super-descriptions).
Figure 4-2: Road longitudinal profile
4.4 General Road Network Format Requirements
The road network format requirements come from the TRAIN-ALL partners’ usage of the road
network: for training, technical simulation and studies (traffic simulation development).
No
1
Requirement description
Comment
A synthetic actor (pedestrian, driver, etc.) shall be Hardware in the loop, for instance a
able to use the synthetic infrastructure according to real traffic light controller integrated
the context of the synthetic road network
in the simulation, is considered as a
synthetic actor
V1.0 Final Version November 2009
Page 20 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Requirement description
No
2
A real actor shall be able to move on the road
according to the context of the synthetic road
network
3
An actor shall be provided with all required
information to facilitate autonomous behaviour, i.e:
- Actors shall be able to compute their own
trajectory in real-time depending on the context.
4




roadway description (width, surface type…),
horizontal road marking:

number of lanes,

lines type,

lanes width,

assignement of lanes,

arrows, stopline, zebra…
vertical road marking:

traffic light, physical barriers, Variable
Message Signs (VMS),

forbidding, warning, advice,

information,
obstacles (potholes, speed bumps…);
environmental conditions (visibility…)
A single actor shall be able to move on the road- In a city, road-sections could be
network according to:
very short



6
e.g. using free space on junctions.
A single actor shall be able to move on a roadsection according to:

5
Comment
the network structured in roads,
current and next road-sections,
geometry of the space defined by the
connection of roadways at the road intersection
(e.g., smoothing of the corners)
The network allows navigation
The geometry of the junction should
be described to allow trajectory
calculation
A actor shall be able to move on the road-section
and road-network according to:


single actors requirements 26 & 27,
other actors behaviours, position and visible Passing,
overtaking,
following,
state (current and expected behaviour)
stopping… are behaviours
7
It shall be possible to describe an existing, past,
future or fictional (i.e. for learning & training
purpose) road network
8
The road network description shall support georeferencing for both flat and curved geo-models.
9
The road network description shall be able to
represent country specific elements
10
It shall be possible to build a road network from
other representations and sources (e.g. CAD-data,
V1.0 Final Version November 2009
Page 21 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
No
Co-funded by the European Commission
Requirement description
Comment
GPS-data, GIS vector data, aerial photographs)
11
It shall be possible to automatically generate a 3Drepresentation (road and verge) from the road
network description
12
The database of the road network shall be of such
structure that required data for certain applications
(dynamic model, sound model, autonomous
agents, weather, etc…) can easily be extracted
(see req. 21)
13
The road network format shall be an open standard
14
It shall be possible to add new elements to the
structure of the road network format
15
It shall be possible to add properties/attributes to
elements of the road network specification format
(e.g. proprietary information, additional information
for autonomous agents)
16
It shall be possible to insert a sub-network (e.g.
complex intersection) to the structure of the road
network
17
It shall be possible to structure intersections and
“unstructured” areas using (virtual) lanes. Remark:
Those lanes can be with or without horizontal road
marking and they can have there own axis.
18
For local variation in the geometry it is possible to For roadways this will define a new
override the specified road axis that applies to longitudinal profile
roadway, lanes, lines and elements along the road
by an override axis
19
Elements are defined relative to road, roadway,
lane or line axis or other elements. To be precise,
they are positioned by the curvilinear distance from
the start of this axis, the perpendicular distance to
the axis and relative heading of the element
20
It shall be specified whether the road network Explain what has to be done to
description is designed for right-hand and/or left- change from one to the other.
hand traffic. The format shall allow to adjust to
multiple countries/traffic rules
V1.0 Final Version November 2009
Unstructured area for instance a
Toll-gate
This
ensures
backwards
compatibility
with
network
description that explicitly describe
all the possible trajectories, e.g.
OpenDRIVE for intersections.
Page 22 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
4.5 Design considerations
Design requirements description
21
Comment
Road information elements shall be in separate As for instance in Geographical
layers of the road network description
Information System (GIS)
In particular, vertical and horizontal road
markings (signs) shall be in separate layers of
the road network description
22
The longitudinal profile of a road is described:

either using a list of 3D points

or with 2D (X, Y) geometric primitives

List of 3D points is a particular case
of n-polynomial
The distance has to be computed in
3D
that are line, spiral (clothoïd), arc, npolynomial or a list of 2D points,

which have to be elevated by a 2D (S,Z)
geometric primitive as line, arc, n-polynomial
or a list of 2D points
23
API shall be language independent, meaning that Added after discussion on design of
an application in any language can link with the open standard for road network
API library
support tools.
There can be numerous, more practical design considerations. For these kinds of
considerations, the developer of the specification is free to choose as he sees fit. We do have
some preferences, though:

Tool support should at least be evaluating that a given file is both syntactically and
semantically in accordance with the road network specification;

We would prefer a human (e.g. XML) readable file format;

Coordinate systems used should follow some existing standard e.g. ISO 8855. For georeferenced data, we prefer the WSG-84 system.
V1.0 Final Version November 2009
Page 23 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
5 Survey on (open) Road Network Formats
5.1 Survey
To explore existing solutions on Road Network Formats, a survey was prepared. The survey
format is presented in appendix A.
The survey to discover existing solutions on the Road Network format applicable to the TRAINALL requirements was send out worldwide to about 60 points of contact in the driving simulator
industry, driving simulator research institutes and universities. The survey contained questions,
which were based on the TRAIN-ALL requirements on the road network format.
5.2 Results of the Survey
From the survey send out worldwide 10 replies were received. These replies resulted into the
conclusion that there were only two existing de-facto standards available, which could be
assumed as being serious solutions for TRAIN-ALL. Most of the repliers had selected one of
these available standards for representing the logical road network in their simulation
environment. The two de-facto standards were:
OpenDRIVE, an open road network format description available since 2006 and managed
by the VIRES company.
ROADXML, not open yet when the survey was distributed, is an initiative of Oktal company
and was released in October 2009
Next to these de-facto standards another applicable Road Network Format description was
discovered at TNO Science and Industry, department of Automotive. This Road Network format,
is incorporated in the PreScan tool for supporting development of Advanced Driver Assistance
Systems (ADAS) and In-Vehicle Information Systmes (IVIS).
All of these identified solutions are described shortly in the next paragraphs.
5.2.1
OpenDRIVE
The basis of the OpenDrive
specification is a road. This
road consists of a longitudinal
profile (track), the lateral profile
and property objects.
The longitudinal profile is
described by the Road Plan
View in terms of Straight lines,
Spirals, Arcs and Cubic
Polynomials.
The properties for elevation, lanes and signs and the lateral profile(s) are defined along and
relative to the track. The properties must be defined in accessing order.
V1.0 Final Version November 2009
Page 24 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
The lanes are defined relative of the track center line and divided in a left, center and right
section for easier navigation. All parameters to specify the lanes are defined in this section like
width, markings, material, speed, accessibility and height. Also the predecessor and successor
are specified. In version 1.2 of the OpenDRIVE specification, the Surface record is introduced
which can point to a CRG (Curved Regular Grid) file.
A set of roads makes the road network. Two roads (tracks) are connected directly to each other.
Tracks with more than one connection are connected via a junction. In this junction all the
connections between lanes are predefined.
Other objects like signs and trees are defined in an object container. These objects are
specified relative to and along the track
Although the OpenDRIVE specification does not match the Train-All definitions, it is almost
possible to get the data into the records. The Information Elements are difficult. Horizontal and
vertical road markings can fit into the appropriate record. It’s even possible to get dynamic
objects in to OpenDRIVE by using Set records. But in the Train-All definition these elements
can interact with the actor and are not limited to a set of objects. To specify those objects it is
recommended to use User Defined data blocks instead. There is no common interface for these
kinds of data.
The data format of OpenDRIVE has the following characteristics and is organised as shown in
the figure below.
XML Format
Hierarchical structure
Extensible with user-defined beads
All values in SI units
Figure 5-1; Data format structure of OpenDRIVE
Based on discussions with VIRES, the current OpenDRIVE can be adapted to fullfill most of
TRAINALL requirements on the road network format. It therefore is a candidate to investigate
for further development of the envisaged Road Network Format Standard. For more information
on OpenDRIVE see www.opendrive.org.
V1.0 Final Version November 2009
Page 25 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
5.2.2
Co-funded by the European Commission
ROADXML - Oktal
A road network in the RoadXML file format is
made of a patchwork of Sub-Networks. Each
Sub-Network is a collection of Tracks linked by
Intersections. Each of these Intersections and
Tracks are then enhanced with different layers of
data :
The road profile is added on the track to
define the pavement surface.
Road Signs and other local cognitive
elements are attached to the track.
Traffic and 3D description is carried by the
road profiles.
RoadXML file format also provide user data mechanism to allow application to add extra
information into the format. The data structure is organized as shown in the figure below.
Figure 5-2: Data structure of ROADXML format
Based on discussions with the Oktal company, the RoadXML format has been selected for our
requirements analysis. For more information on RoadXML see www.road-xml.org.
5.2.3
PreScan – TNO
PreScan was created by TNO Science and Industry as a development environment for
intelligent vehicle (IV) systems that monitor the vehicle’s surroundings and respond to them.
Such responses may range from ‘simple’ warnings issued to the driver to ‘complex’ fully
autonomous control interventions. PreScan can be used for designing and evaluating current
and future IV systems that are based on sensor technologies such as radar, laser, camera,
V1.0 Final Version November 2009
Page 26 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
GPS and car-to-car communication.
PreScan is the perfect tool to
benchmark various system concepts
and, once a system qualifies, to check
how robust it is under less than ideal
circumstances. In PreScan, models of
sensors, vehicles and obstacles contain
real physical relationships. Also,
weather and light are modelled in a
physically correct way. The fact that
PreScan is based on real physics
guarantees high fidelity results.
Figure 5-3: Data Structure of PreScan format
PreScan contains a road network format that fulfils the TRAIN-All requirements to a certain
extent. This makes the road network format as used in PreScan a candidate for considering this
format to be developed towards a certified standard. For more information on PreScan, see
www.tno.nl/prescan
5.3 Analysis of results
To determine a preferred solution, it was decided to perform a multi-criteria analysis.
First, criteria had to be established as the basis for the analysis. The criteria selected were
based on the requirements and additional criteria on openness, active community and “living”
standard.The following criteria were selected for the multi-criteria analysis:
V1.0 Final Version November 2009
Page 27 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
An intelligent actor shall be provided with all required information to compute their own
trajectory in real-time depending on the context
The longitudinal profile of a road is described either using a list of 3D points or with 2D (X,
Y) geometric primitives
It shall be possible in the road network format to insert a sub-network (e.g. complex
intersection) to the structure of the road network
Available Open Road Network Format Description
Exchange format in human-readable format, e.g. XML
Willing to provide basic open source Road Network Generation Tool
Number of Proposals and new developments on and related to the Road Network format per
year - living standard and active community indication
Large existing Community of Users
Range of (commercial) support tools up to 3D Landscape generation/visualization that use
common standards (e.g. OpenFlight)
For each criterion and each solution, a score in the range of 1-5 was determined in a plenary
session with Train-All participants. Next, each participant was requested to give a weighting
factor for each criterion, i.e. to rate the relative importance of the criteria in a range of 1-5.
The outcome of the analysis was retrieved by normalizing the weight factors of each partner
and multiplying this with the score for each criterion. The following tables provide the results of
the analysis for each solution provided
Table 5-1: Results for OpenDRIVE of the Multi-Criteria Analysis
V1.0 Final Version November 2009
Page 28 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
The following graph shows the results of the Multi Criteria Analysis for each participant and
each road network solution. Also a mean value for every solution is calculated. The mean value
of the road network solution in PreScan has a much lower score than both OpenDRIVE and
ROADXML.
Figure 5-4: Graph presentation of the results of the Multi-Criteria Analysis
Based on the results of the analysis as shown above and discussions afterwards, it turns out
that a unanimous decision of the road network format solution to pursue cannot be achieved. In
our view, both solutions OpenDRIVE and RoadXML, have their advantages and disadvantages.
Put in simple terms, RoadXML adheres more to our technical requirements, and OpenDRIVE
scores better on our additional criteria on openness and community support.
Taken into account these results, only OpenDRIVE and ROADXML are selected for further
evaluation and discussions on how unification or merging of above initiatives towards one road
network format standard is going to be achieved in the near future.
5.4 Way ahead
The TRAIN-ALL objective is still to have one standard for the future. How to achieve this is still
not clearly understood, but would it be possible to merge current initiatives OpenDRIVE and
RoadXML in the future towards one certified standard?
When merging the two into a common standard, it is important to consider special features in
other European countries to obtain a true “European” standard, flexible enough to allow for
V1.0 Final Version November 2009
Page 29 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
special conditions in different countries. TRAIN-ALL participants believe that merging both
OpenDRIVE and RoadXML (where also commercial aspects are dealing), will be eased from a
technical point of view if both road network formats share the same functionality. In order to
achieve this, for the near future a decision was made by a number of TRAIN-ALL participants,
to start collaboration with both Oktal and Vires company by:
Adopting both road network format solutions within driving simulator applications of TRAINALL participants,
Participation in OpenDRIVE and ROADXML boards by TRAIN-ALL participants
Recommend changes to road network “standards” OpenDRIVE and ROADXML in order to
achieve a common functionality.
Start open source projects to provide community with parsers for both formats
To explore the feasibility of one certified standard in the near future, a meeting was organised
with representatives of both OpenDRIVE and ROADXML. From this meeting the following was
concluded:
The standardization process should be carried out by a community with representatives of
TRAIN-ALL participants, representatives currently in the Management boards of
OpenDRIVE and ROADXML, representatives of current communities using OpenDRIVE or
ROADXML and representatives of future users.
What shall be standardized is the description of the format of the Road Network with
preferably a specification of an XML scheme for file exchange purposes.
To provide users with services for evaluating the standard format exchange file, an
assessment tool as service managed by the standard management authority shall be
delivered with the standard.
User acceptance is created by backward compatibility with the current (de-facto) standards
OpenDRIVE and ROADXML in use, meaning that users should be able to use the new
standard without large modification.
The process of merging the current de-facto standards into one common standard is not
fully understood at this moment. For defining and implementing this process, a CEN
workshop was proposed as the first initiative towards a common certified standard.
The standard should be developed in a short timeframe, estimated 3-5 years from now. This
would allow present and near-future replacement of old commercial software to adapt to an
open road format.
V1.0 Final Version November 2009
Page 30 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
6 Conclusions, Achievements and Recommendations
Conclusions
Standardization of Road Network Format, Landscape and Scenarios for driving simulators
are beneficial for users and manufacturers.
A Road Network Format standard is a prerequisite for standardization or exchange of
scenarios for driving simulators.
Current Open Road Network formats OpenDRIVE and ROADXML are not fulfilling TRAINALL requirements
Achievements
The achievements within the TRAIN-ALL project on standardization of road network, landscape
and scenarios are:
TRAIN-ALL requirements for a common road network format have been established,
TRAIN-ALL Open Road Network requirements are proposed for implementation into
OpenDRIVE and RoadXML,
TRAIN-ALL participants are members of management boards of OpenDRIVE and
RoadXML,
TRAIN-ALL participants have adopted current Open Road Network format initiatives
OpenDRIVE and RoadXML,
Open Source Projects within OpenDrive and RoadXML are initiated by TRAIN-ALL
participants.
A discussion with current owners of de-facto road network standards was initiated towards
creation of a single certified road network standard format
Recommendations
To setup a standardization community and continue the Open Road Network
Standardization process, with support of an official standardization body (CEN)
V1.0 Final Version November 2009
Page 31 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Appendix A: Survey template
General Information
Please provide the following information:
Company/Research Institute
Address
Point of contact
Phone:
Fax:
E-mail:
General road network format requirements
Several workshops within TRAIN-ALL with participation from several companies/research
laboratories have resulted in a list of high-level requirements for an open road network format.
In the next section a number of requirements are listed for the specification and
design/implementation of the road network format. Please indicate how your
specification/solution of the road network format fits the listed requirement.
Requirement description
No
23
Comment
A synthetic actor (pedestrian, driver, etc.) shall be able Hardware in the loop, for
to use the synthetic infrastructure according to the instance a real traffic light
context of the synthetic road network
controller integrated in the
simulation, is considered as a
synthetic actor
Your solution/remarks:
24
A real actor shall be able to move on the road according
to the context of the synthetic road network
Your solution/remarks:
V1.0 Final Version November 2009
Page 32 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Requirement description
No
25
Co-funded by the European Commission
Comment
An actor shall be provided with all required information e.g. using free space on
to facilitate autonomous behaviour, i.e:
junctions.
- Actors shall be able to compute their own trajectory in
real-time depending on the context.
Your solution/remarks:
26
A single actor shall be able to move on a road-section
according to:





roadway description (width, surface type,…),
horizontal road marking:

number of lanes,

lines type,

lanes width,

assignement of lanes,

arrows, stopline, zebra…
vertical road marking:

traffic light, physical barriers, Variable Message
Signs (VMS),

forbidding, warning, advice,

information,
obstacles (potholes, speed bumps…);
environmental conditions (visibility…)
Your solution/remarks:
27
A single actor shall be able to move on the road- In a city, road-sections could
network according to:
be very short



the network structured in roads,
current and next road-sections,
geometry of the space defined by the connection of
roadways at the road intersection (e.g., smoothing
of the corners)
The
network
navigation
allows
The geometry of the junction
should be described to allow
trajectory calculation
Your solution/remarks:
28
A actor shall be able to move on the road-section and
road-network according to:


single actors requirements 26 & 27,
Passing,
overtaking,
other actors behaviours, position and visible state following, stopping… are
(current and expected behaviour)
behaviours
V1.0 Final Version November 2009
Page 33 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Requirement description
No
Comment
Your solution/remarks:
29
It shall be possible to describe an existing, past, future
or fictional (e.g. for learning & training purpose) road
network
Your solution/remarks:
30
The road network description shall support georeferencing for both flat and curved geo-models
Your solution/remarks:
31
The road network description shall be able to represent
country specific elements
Your solution/remarks:
32
It shall be possible to build a road network from other
representations and sources (e.g. CAD-data, GPS-data,
GIS vector data, aerial photographs)
Your solution/remarks:
33
It shall be possible to automatically generate a 3Drepresentation (road and verge) from the road network
description
Your solution/remarks:
34
The road network format shall be of such structure that
required data for certain applications (dynamic model,
sound model, autonomous agents, weather, etc…) can
easily be extracted (see req. 21)
Your solution/remarks:
V1.0 Final Version November 2009
Page 34 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Requirement description
No
35
Co-funded by the European Commission
Comment
The road network format shall be an open standard
Your solution/remarks:
36
It shall be possible to add new elements to the structure
of the road network format
Your solution/remarks:
37
It shall be possible to add properties/attributes to
elements of the road network specification format (e.g.
proprietary information, additional information for
autonomous agents)
Your solution/remarks:
38
It shall be possible to insert a sub-network (e.g.
complex intersection) to the structure of the road
network
Your solution/remarks:
39
It shall be possible to structure intersections and
“unstructured” areas using lanes. Remark: Those lanes
can be with or without horizontal road marking and they
can have there own axis.
Unstructured
area
for
instance
a
Toll-gate
This ensures backwards
compatibility networks that
have the notion of paths.
Your solution/remarks:
40
For local variation in the geometry it is possible to For roadways this will define
override the specified road axis that applies to roadway, a new longitudinal profile
lanes, lines and elements along the road by an override
axis
Your solution/remarks:
V1.0 Final Version November 2009
Page 35 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
No
Requirement description
41
Elements are defined relative to road, roadway, lane or
line axis or other elements. To be precise, they are
positioned by the curvilinear distance from the start of
this axis, the perpendicular distance to the axis and
relative heading of the element
Comment
Your solution/remarks:
42
It shall be specified whether the road network (Explain what has to be done
description is designed for right-hand and/or left-hand to change from one to the
traffic.
other)
Your solution/remarks:
Design considerations
No
43
Design requirements description
Comment
Road information elements shall be in separate layers of As
for
instance
in
the road network description
Geographical
Information
System (GIS)
In particular, vertical and horizontal road markings
(signs) shall be in separate layers of the road network
description
Your solution/remarks:
44
The longitudinal profile of a road is described:

either using a list of 3D points

or with 2D (X, Y) geometric primitives
List of 3D points is a
particular
case
of
npolynomial
The distance has to be
that are line, spiral (clothoid), arc, n-polynomial or computed in 3D
a list of 2D points,
Cubic-polynomial
seems

which have to be elevated by a 2D (S,Z) accurate for most case
geometric primitive as line, arc, n-polynomial or a list
of 2D points

Your solution/remarks:
V1.0 Final Version November 2009
Page 36 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
There can be numerous, more practical design considerations. For these kinds of
considerations, the developer of the specification is free to choose as he sees fit. We do have
some preferences, though:
No
Design requirements description
23
Tool support should, at least, be a validator that confirms
that a given file is both syntactically and semantically in
accordance with the road network specification
Comment
Your solution/remarks:
24
We would prefer a human (e.g. XML) readable file format
Your solution/remarks:
25
For geo-referenced data, we prefer the WSG-84 system.
Your solution/remarks:
Additional requirements.
The following sketches are complex road network intersections which are reqjuired to be
supported in our driving simulators.
For each situation, please explain how your Road Network Specification would handle this
situation.
V1.0 Final Version November 2009
Page 37 of 46
TRAIN-ALL Deliverable 2.4
Contract no. 031517
Co-funded by the European Commission
Crossing 1:
Describe your specification / solution to
accommodate this crossing and how this is to be
used by autonomous actors for navigation
purposes.
Crossing 2:
Describe your specification /
solution to accommodate this
crossing and how this is to be
used by autonomous actors
for navigation purposes.
Roundabout 1:
Describe your specification / solution to
accommodate this crossing and how this is to
be used by autonomous actors for navigation
purposes.
We thank you for your input provided and we will keep you up to date with our progress.
V1.0 Final Version November 2009
Page 38 of 46