Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

1

DynaMap: a Dynamic Map for Road side ITS Stations

Bart Netten, Leon Kester, Harry Wedemeijer, Igor Passchier, Bart Driessen

Senior Researchers, TNO

Oude Waalsdorperweg 63, 2597 AK, The Hague, The Netherlands

+31 888 666 310, bart.netten@tno.nl

ABSTRACT

This paper presents the rationale and design of the DynaMap, a Local Dynamic Map (LDM)

for infrastructure-based cooperative applications on Road side and Central ITS Stations. Most

LDMs are developed primarily for use in cooperative vehicles. The requirements for

infrastructure-based applications are different from vehicle-based applications though. This

paper motivates the requirements for road side applications and presents the architecture of

the DynaMap.

Keywords: Fundamental Technologies, Map database, Local Dynamic Map

1. INTRODUCTION

The DynaMap is an implementation of a Local Dynamic Map (LDM) for infrastructure–based

cooperative systems. A cooperative system is a system in a vehicle, road side station or traffic

control center that cooperates with other cooperative systems to improve traffic safety,

efficiency and the environment. The purpose of cooperative systems is similar to ITS; e.g. to

warn drivers for eminent safety risk such as collisions or traffic jams, and for traffic measures

such as speed limits and speed advices to improve traffic flow and reduce emissions.

Cooperation is achieved by a set of peer applications and communication. The cooperative

applications detect the events, communicate the events to other systems, and inform or warn

drivers for the eminent events.

A Local Dynamic Map is a central facility in a cooperative system. An LDM receives data

from various sources, such as the sensors and systems of a vehicle or road side station, and

from communication with other cooperative systems. The primary purpose of an LDM is to

provide a common and consistent situational and cooperative awareness to all applications

running on the host system. This has two advantages. Consistency in the cooperative behavior

is improved due to the common model of the world shared by all applications on a host

system. Computational performance is improved because the acquisition and fusion of source

data is executed only once.

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

2

The concept of the LDM was developed in the SAFESPOT project [1] and shared and further

developed in projects like CVIS [2], DRIVE-C2X [3] and eCoMove [4]. This concept is being

standardized as a facility in the architecture of ITS-Stations [5]. Although the LDM is applied

in Road side ITS Stations (RIS) or Central ITS Station (CIS) in all these projects, it was

primarily developed for the requirements and applications in Vehicle ITS Stations (VIS). The

RIS and CIS have some different requirements for an LDM than the VIS, for example:

RIS and CIS do not use the LDM for navigation or routing.

RIS and CIS do not need highly detailed information about infrastructure objects (e.g.

road markings, road furniture or buildings) as used to enhance positioning in a VIS.

RIS and CIS use a stationary map of a predefined part of the road network, while the

map in the VIS is moving with the host vehicle. Functionalities like an electronic

horizon or moving, routing and frequent queries for the next road links are not

relevant at the road side. Stationary objects in the LDM remain stationary with respect

to the host RIS or CIS. Continuous rotations of reference systems are not relevant at

the road side.

The RIS will primarily use the topology of reference tracks to map the traces of road

users, detect track conflicts, and monitor traffic flows along these tracks (see e.g. [6]).

The RIS generates one or a few TOPO messages of the intersection or road segments

it covers. A VIS on the other hand should match every new TOPO onto its internal

map.

The geographic scope of a RIS covers an area or road segment in the order of 1 km

with typically 100 moving objects. The scope of a CIS is even larger. The scope of a

VIS is likely to be smaller than that of a RIS.

The next section presents several road side applications to exemplify the above points. The

following sections presents the architecture of the DynaMap and components. The LDM at

the road side is not so local, hence the name Dynamic Map, or DynaMap for short, is used.

2. COOPERATIVE APPLICATIONS ON THE DITCM TEST SITE

The Dutch Integrated Test site for Cooperative Mobility (DITCM) [7] is a collaboration of

over 20 public and private partners, focussing on open innovation and acceleration of the

introduction of cooperative systems. DITCM operates a test site on the A270 and N270 roads

from the cities of Helmond to Eindhoven in the Netherlands. The test site provides a mixed

traffic environment for testing cooperative systems on the public road in normal urban and

motorway traffic situations.

The road side infrastructure of the test site [8] is shown in Figure 1. It contains several Central

and Road side ITS Stations, a Test Management Center (TMC), and road side equipment such

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

3

as video cameras, loop detectors, traffic light controllers, and G5 ITS communication units

(CU). The CIS and RIS are Application Units (AU) with an architecture compliant with the

ITS Communication Architecture [9]. The DynaMap is an LDM facility at the AU of a CIS or

RIS. The CIS in DITCM are used for test management, traffic monitoring and traffic control

over multiple RIS.

Figure 1: DITCM Test Site infrastructure

The DITCM Test Site is used in a variety of projects (e.g. SPITS [10], GCDC[11],

CONTRAST [12], DRIVE-C2X [3], MOBINET[13] and COMPASS4D[14]) for the

development and technical evaluation of cooperative applications. This includes the basic set

of cooperative applications [5] and also more advanced applications such as Cooperative

Adaptive Cruise Control, contextual dynamic speed advice and shockwave damping. The

following subsections demonstrate the requirements on an infrastructure-based LDM from the

Introduction.

2.1 Visualization in the TMC

The Test Management Center has tools for monitoring the test site and controlling the test site

infrastructure. The DynaMaps running on the CISs provide the data for monitoring traffic,

individual vehicles and the status of road side applications. This data is requested from the

DynaMaps for visualization in the TMC (Figure 2 and Figure 3) and provides a good

overview of the DynaMap.

The Google Map gives an overview of the static and dynamic data from the DynaMap. It

shows the location of road side equipment and road users and distinguishes cooperative and

normal vehicles. The bottom part of Figure 2 shows more detailed information from road

16 G5 Communication Units

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

4

users and traffic states. The plot bottom left shows the current location (horizontal axis) and

speed (vertical axis) of all road users along the test track. The plot bottom right shows the

complete trajectories of all vehicles maintained in the history of the vehicles in the DynaMap.

This gives the most detailed level of the traffic state along the route. More information of a

road users can be requested from the context menu (top right), such as a station-id, and a

specific road user can be followed on the map or camera, for example to check a detected

incident like a stationary vehicle. The second plot from the bottom left shows the system time

offset of all VISs on the test site. The time offset is determined from the messages received

from the VIS [15]. Figure 3 shows the status of road side equipment, include inductive loops

(blue lines for occupied loops) and traffic light states (green and red).

Figure 2. Visualization of static and dynamic data from DynaMap on a motorway

Figure 3: Visualization of static and dynamic data from DynaMap at an intersection

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

5

2.2 Incident Detection

Incident detection [16] is primarily based on the detection of anomalies in vehicle trajectories

and lane mapping, such as the use of the hard shoulder, tailgating, speeding, slow and

stationary vehicles (see Figure 2). These applications are closely related to some cooperative

Basic Set of Applications, such as slow-vehicle warning and obstacle warning. The DynaMap

is used to monitor the behavior of individual vehicles. This information is queried by the

applications, which is much more efficient than having all applications track the same

vehicles. Also the events detected by the incident detection applications are fed back into the

DynaMap. The slow vehicle application is simplified to an application that queries the

DynaMap for particular events and send out a warning message to vehicles.

2.3 Dynamic Speed Advice and Shockwave Damping

The shockwave damping application [10], [12] runs on a CIS. The application consists of

several components on the Application Unit that interact with the DynaMap. A traffic monitor

reads vehicle trajectories and generalizes this data into a continuous traffic state along the

road, and writes the traffic state back. A shockwave detector components reads the traffic state

to detect jams and jam fronts, which are written back to the DynaMap.

Other applications also use the jam front information. The traffic jam ahead warning (TJAW)

application will send out this TJAW messages to vehicles. A shockwave monitor monitors the

creation, progress and bifurcation of jam fronts to model moving jams. A shockwave damping

application also reads traffic state and moving jam information to calculate a desired speed

profile to damp the jams, and sent out speed advice messages to vehicles.

3. DYNAMAP ARCHITECTURE

The DynaMap is not implemented as a data base like in [1] where data sources can add data

via transactions and applications retrieve information using SQL-like queries. Instead,

DynaMap is an information system where several types of components actively maintain and

process information in memory. DynaMap has evolved from the World Model in the MARS

simulation environment [17]. The main components of the DynaMap and the components

interfacing to data sources and applications are shown in the architecture in Figure 4 and will

be described in more detail in the following sections. The high level data flow through the

DynaMap is as follows:

DataSources provide their source data asynchronously to the DynaMap. Examples of

data sources are the inductive loops, video cameras, traffic light controllers, and the

messages received from other cooperative systems. The WorldObjectAssociator is a

component that controls the insertion of source data as Observations to the appropriate

object in the World Model. The WorldObjectAssociator can also retract data, for

example when a data fusion component adapts its association of tracks to road users.

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

6

The WorldModel maintains a consistent view of the WorldObjects in the world.

Consistency is maintained in time and space. A history of objects’ observations and

states is maintained. The reference position of observations and objects are matched to

a common topology (map).

WorldObjects have Monitors that maintain a model of the consistency of their state

and behavior. The monitors filter observations and predict the state of the object to

update the world model.

DataSinks, such as Applications, can request state information on WorldObjects. An

Applications can also act as a Data Source to provide derived information that can be

useful to other applications. EventDetectors for example are (parts of) applications

that monitor the DynaMap for specific events of road users or traffic state and add or

update the event detections.

Figure 4: DynaMap reference architecture

3.1 World Model

The WorldModel is a knowledge model that structures the source data as WorldObjects and

maintains object relationships by type, location and time. Objects are hierarchically organized,

for example by spatial granularity. Tracking information of road users from cooperative

messages and from road side video cameras are fused. Traffic states are either aggregated

from vehicle tracks, or received from road side detectors, and fused into a continuous traffic

state model. Events are associated either to individual road users, sets of road users, or to

relevance areas in the traffic state.

class DynaMap

WorldModel «interface»

DataSink

«interface»

DataSource

RoadUser

WorldObject

- state

- timestamp

Traffic Ev ent

TopologyWorldObjectAssociator

Monitor

+ updateState()

Observ ation

- referencePosition

- timestamp

Clock

+ update()

Ev entDetector

+ detectEvent() :Event

Application

1

referencePosition

* 1..*

1

request

newData

newObservation

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

7

The world model handles data requests from data sink also by type, location and time. The

structure allows applications to add data derived from external data sources for other

applications. Typically, the applications are composed of event detectors, application logic,

driver advice generation, and the generation of cooperative messages. Especially the event

detections are of interest to other applications as well, as exemplified in section 2. A detected

incident, like a slow vehicle, provides input for road-side traffic jam front detection, which in

turn provides input for shockwave monitoring and damping, and speed advice applications.

Every world object has a current state, but can also keep a (short) history for some of its

observations and states. These histories are kept by so called monitors. The history of a

parameter can be kept for several reasons:

For smoothing the values, and removing outliers.

For monitoring the changing state of an event (e.g. the length and wave speed of a

traffic jam).

For calculating the derivative (e.g. calculate acceleration from the speed values).

For interpolating the value at a different time.

For extrapolating (predicting) the value to a future time.

For calculating aggregate functions (like average, minimum, maximum and standard

deviation) of the value.

For keeping track of objects (e.g. show a trace on a map).

The structure and consistency of the world model is actively maintained by

WorldObjectAssociators and Monitors. The WorldObjectAssociators add source data

asynchronously to the world objects. The applications, however, need a time synchronized

world model. The clock is time synchronized with the Application Unit and all road side

equipment. The clock controls the Monitors for updating of object states. The frequency for

updating may vary between WorldObjects, as requested by applications.

3.2 Topology

World objects are associated to a location as a reference position or area on a topology of the

roads, lanes and reference tracks. In other words, the topology is a graph model of reference

tracks to map traffic states, measures and road users, e.g. [6]. The structure is equivalent to the

models of reference lanes and tracks in TOPO messages that are used for speed advice

(SLAM) and traffic light state (SPAT) messages as used for example in [3], [4], [10], and [12].

The topology could be created from a static navigation map. However, as the road side is

responsible for unique identification of topology elements in TOPO messages, the identifiers

should be independent of any navigation map. Any definition from a road authority or

operator can be used. The applications on the Road side and Central ITS Stations have no

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

8

need for navigation functionality or a navigation map. For example:

No e-horizon concept as map is stationary and not moving with a vehicle

Map details such as lane markings and physical properties of road furniture, are not

required for positioning

The RIS and CIS map traffic to reference tracks and lanes rather than roads.

3.3 World Object Associator

Data sources, such as tracking and data fusion components, may have different definitions for

identifying objects and tracks. Data sources have no knowledge of the world model data

structure and have no direct access to the WorldObjects. The interface to data sources is

provided by WorldObjectAssociators, or associator for short. The associator is the component

that creates world objects and updates its observations asynchronously. There are associators

specific for the type of source data:

VBM (Video Based Monitoring): detections of vehicles from road side video cameras.

Single detections are connected to each other by a track association algorithm to form

tracks [8], [16]. VBM provides a series of time points per track with a position and

speed.

CAM (Cooperative Awareness Messages): the CAMs from the cooperative vehicles

are received by road side communication units and decoded by message services on

the application units. The CAM messages are not directly provided as source data to

the DynaMap, Instead, the CAM service provides a series of time points per station id

with a position and speed, similar to VBM data. Alternatively, the CAMS and VBM

detections can be fused together to single tracks for cooperative vehicles by the

Monitors.

DENM (Decentralised Environmental Notification Messages): the events from

cooperative vehicles are received by the communication units and decoded by

message services on the application units. The events are either associated to road user

objects or to event objects.

ILD (Inductive Loop Detectors): detection of passing vehicles from inductive loops

near the intersections.

3.4 Monitors

Every World Object has one or more monitors to calculate the current state or the object.

Monitors are triggered by the clock to update the state at a specific timestamp. Monitors

calculate the momentary motion state of moving objects, location and speed of traffic

perturbations and the state of events for example. A monitor uses the history of observations

for smoothing, filtering of outliers, fusion, and extrapolation of the state to the timestamp

from the clock. A monitor can also interpolate a state to a timestamp requested by a data sink.

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

9

3.5 Prioritization by DataSinks

DataSinks, such as applications can be in different states of priority or activity for traffic

efficiency or safety. These are comparable to risk status of vehicle based applications, such as

background, informative, warning, severe warning (e.g. [3]). These levels indicate the priority

the applications should get form the DynaMap for handling their information requests.

Together with this priority the applications can request the quality of the required information,

the region of interest and an update frequency. Based on this information the DynaMap

decides what actions to take to meet the needs of the different applications in the best possible

way. Typical applications for which such an approach is interesting are incident detections.

Usually, the application runs in background to detect an incident at lower frequency. Upon

detection of the incident, the priority level increases with the severity of the incident.

4. RELATED WORK

DynaMap is not implemented as a database as in earlier projects [1],[2],[3],[4]. Instead the

DynaMap has a knowledge model that provides more functionality and better performance for

structuring, searching and maintaining source data. In [18] an alternative concept is presented

for a Stream LDM for application in vehicles. It uses a combination of a data base

management system and a data stream management system to improve the responsiveness of

database access. Input data streams are maintained as time series data in memory (rather than

in a database) that are continuously / asynchronously updated. An application can register to

the data stream with a specific filter for required information. Essentially, this provides

functionality similar to the associators and monitors of the DynaMap.

5. CONCLUSIONS

The DynaMap is a Local Dynamic Map similar to the concept and rationale of [5], but

specifically developed for application at Road side (RIS) or Central ITS Stations (CIS).

Several requirements are identified for a LDM at the infrastructure side that are essentially

different from the requirements for vehicle-based LDMs. These requirements are motivated

by examples from applications, projects and field tests developed at the Dutch Integrated

Test site for Cooperative Mobility (DITCM). These requirements also motivate a different

implementation of a LDM for Road side and Central ITS Stations such as DynaMap. Most

notably, there are no applications for navigation or routing on a RIS or CIS that require a

detailed navigation map that moves with the host vehicle. Also the scope of the LDM is larger

in terms of space, number of objects, and time history. Instead the RIS or CIS structure all

source data to the simplified graph model that is similar to the topology in TOPO messages

that a RIS sends to vehicles. DynaMap is not implemented as a database but as a knowledge

model that provides more functionality and better performance for structuring, searching and

maintaining source data.

Proceedings of the 20th ITS World congress, Tokyo 2013, TS129

10

6. REFERENCES

[1] Christian Zott, Sheung, C. L. Brown, C. Bartels, Z. Papp and B. Netten, "SAFESPOT

Local Dynamic Maps - context-dependent view generation of a platform's state &

environment," in Proceedings of the 15th World Congress on Intelligent Transportation

Systems (New York, 2008).

[2] Thijs de Graaff, et.al., “Cooperation architecture and requirements on content interfaces

for interoperability”, CVIS Deliverable D.DEPN2.1, version 1.5, February 2010.

[3] DRIVE-C2X project site, http://www.drive-c2x.eu/

[4] Ola Martin Lykka, et.al., “eCoMove Communication platform design specification”,

eCoMove Deliverable D2.3, May 2011.

[5] “Intelligent Transportation Systems (ITS); Vehicular Communications; Basic Set of

Applications; Local Dynamic Map (LDM); Rationale for and guidance on standardization”,

ETSI TR 102 863 v1.1.1 (2011-06).

[6] Erik Koenders, Kees Wevers, Jaap Vreeswijk, Stéphane Dreher, “Map based applications:

the reference track approach”, 2009, http://www.peektraffic.nl/download.php?docid=73

[7] DITCM, 2013. Available: http://www.ditcm.eu.

[8] I. Passchier, B. Driessen, B. Heijligers, B. Netten en P. Schackmann, “The Road Side Unit

for the A270 Test Site”, in Proceedings of ITS Europe, Lyon, 2011.

[9] ETSI, “Intelligent Transport Systems (ITS); Communications Architecture”, ETSI EN 302

665 v1.1.1 (2010-09).

[10] B. Netten, T. van den Broek, I. Passchier, P. Lieverse, “Low penetration shockwave

damping with cooperative driving systems”, in ITS Europe, Lyon, 2011.

[11] E. van Nunen, et.al., “Cooperative Competition for Future Mobility”, IEEE Transactions

on ITS, Vol. 13, No. 3, September 2012.

[12] I. Passchier en et al., “Influencing driving behaviour via in-car speed advice,” submitted

to ITS Europe, Dublin, 2013.

[13] P. Kompfner, “Europe-Wide Platform for Connected Mobility Services – MOBINET”,

http://www.ertico.com/europe-wide-platform-for-connected-mobility-services-mobinet.

[14] Compass4D, http://www.compass4d.eu

[15] B. Netten, et.al., “Technical Evaluation of Cooperative Systems – Experience from the

DITCM Test Site”, 9th

ITS European Congress, Dublin, June 2013.

[16] J. van Huis, J. Baan, “Incident Detection using Video Based Monitoring,” in ITS Europe,

Lyon, 2011.

[17] Frank den Ouden, et.al., “Coping with the worrying complexity of cooperative driver

assistance systems”, in Proceedings of the 13th

ITS World Congress (London, 2006).

[18] Kenya Sato, et.al., “Stream LDM: Local Dynamic Map (LDM) with Stream Processing

Technology”, The Science Engineering Review of Doshisha University, Vol 53, No. 3,

October 2012.