ISO/TR 17424:2015
(Main)Intelligent transport systems — Cooperative systems — State of the art of Local Dynamic Maps concepts
Intelligent transport systems — Cooperative systems — State of the art of Local Dynamic Maps concepts
ISO/TR 17424:2015 surveys the status of Local Dynamic Map (LDM) regarding architecture, implementation, and standardization efforts. It summarizes the high level architectures of the most important implementations and compares it with the CEN/ETSI/ISO ITS-Station architecture. ISO/TR 17424:2015 derives out of the application needs the requirements for a global LDM concept in terms of functionality, technical and legal aspects. A gap analysis with existing specification and standards will be performed and recommendations towards SDOs and decision bodies will be made. ISO/TR 17424:2015 does not give any decision on how or whether one of the solutions described is commercially feasible to be considered as an implementable offer to the user. ISO/TR 17424:2015 considers the most important documents and research projects to the knowledge of the authors, but does not claim to be complete or free of any mistakes.
Systèmes intelligents de transport — Systèmes coopératifs — État des connaissances des cartes dynamiques locales
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TR
REPORT 17424
First edition
2015-05-01
Intelligent transport systems —
Cooperative systems — State of the art
of Local Dynamic Maps concepts
Systèmes intelligents de transport — Systèmes coopératifs — État des
connaissances des cartes dynamiques locales
Reference number
ISO/TR 17424:2015(E)
©
ISO 2015
---------------------- Page: 1 ----------------------
ISO/TR 17424:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TR 17424:2015(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Content and structure . 2
5.1 Required LDM Elements (subsystems or functions) . 3
5.1.1 Data elements and protocols . 4
5.2 LDM: state of the art . 6
5.2.1 Proposed LDM Architectures . 6
5.3 Parts and functions not fully specified or not yet available .25
5.3.1 Considerations on Geo-location referencing .25
5.3.2 Considerations on Data Privacy .25
5.3.3 Considerations on Data Security .26
5.3.4 Considerations on data Integrity .26
5.3.5 Considerations on decision rules for conflicting data content .27
5.3.6 Considerations on LDM Synchronization .27
5.4 Recommendations .27
Bibliography .29
© ISO 2015 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TR 17424:2015(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
iv © ISO 2015 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TR 17424:2015(E)
Introduction
Intelligent transport systems (ITS) means to apply information and communication technologies (ICT)
to the transport sector. ITS can create clear benefits in terms of transport efficiency, sustainability,
safety and security.
To take full advantage of the benefits that ICT-based systems and applications can bring to the transport
sector, it is necessary to ensure interoperability among the different systems.
Cooperative systems are ITS (Cooperative ITS) systems based on vehicle-to-vehicle (V2V), vehicle-to-
infrastructure (V2I, I2V) and infrastructure-to-infrastructure (I2I) communications for the exchange
of information. Cooperative systems have the potential to further increase the benefits of ITS services
and applications.
Cooperative ITS is a subset of the overall ITS that communicates and shares information between
ITS stations to give advice or facilitate actions with the objective of improving safety, sustainability,
efficiency and comfort beyond the scope of stand-alone systems.
The European Commission issued Mandate M/453 [6] [7] to invite the European Standardization
Organizations (ESOs) (CEN, CENELEC and ETSI) to prepare a coherent set of standards, specifications and
guidelines to support the European Community’s wide implementation and deployment of Cooperative
intelligent transport systems (Cooperative ITS).
CEN and ETSI have formally accepted the Mandate and will develop standards (EN) and technical
specifications and guidelines requested as far as possible within the timescale required in the Mandate.
(see Reference [7])
Annex C of Reference [7] proposes a “List of minimum set of standards and allocation of responsibility
between CEN and ETSI – Mandate M/453”.
ISO/TC 204 decided in 2009 to join CEN’s efforts and to create a new working group (WG 18) under the
Vienna agreement. This Technical Report is considered by non-European NSOs as important enough to
justify having it under ISO lead.
Different ITS stations (vehicle, nomadic, roadside and central) exchange geographically located
information, which is of importance for the different cooperative applications (standards to be developed
under the responsibility of CEN and ISO).
This Technical Report delivers information about the status at the time of publication of the Local
Dynamic Map (LDM) concepts as they have been developed in the different R&D projects in Europe,
Japan and the USA.
It presents different architectures, implementations, LDM functional blocks and the related
standardization activities. It can identify gaps, lacks and inconsistencies between Cooperative
ITS Reference Station Architecture and existing implementations. It proposes actions for future
standardization activities and harmonization needs. Activities within ISO/TC 204 WG 3 and ETSI TC ITS
at the time of publication are considered.
This Technical Report falls within the agreed scope of work of ISO/TC 204 WG18 and CEN TC 278 WG16.
© ISO 2015 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/TR 17424:2015(E)
Intelligent transport systems — Cooperative systems —
State of the art of Local Dynamic Maps concepts
1 Scope
This Technical Report surveys the status of Local Dynamic Map (LDM) regarding architecture,
implementation, and standardization efforts. It summarizes the high level architectures of the most
important implementations and compares it with the CEN/ETSI/ISO ITS-Station architecture.
This Technical Report derives out of the application needs the requirements for a global LDM concept in
terms of functionality, technical and legal aspects.
A gap analysis with existing specification and standards will be performed and recommendations
towards SDOs and decision bodies will be made.
This Technical Report does not give any decision on how or whether one of the solutions described is
commercially feasible to be considered as an implementable offer to the user.
This Technical Report considers the most important documents and research projects to the knowledge
of the authors, but does not claim to be complete or free of any mistakes.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable to its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TR 24532, Intelligent transport systems — Systems architecture, taxonomy and terminology — Using
CORBA (Common Object Request Broker Architecture) in ITS standards, data registries and data dictionaries
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TR 24532 and the following apply.
3.1
Local Dynamic Map
LDM
conceptual data store which is embedded in an ITS station containing topographical, positional and
status information within a dedicated geographic area of interest, relevant to ITS stations
Note 1 to entry: The LDM is supported by service functions, which ensure the accessibility, integrity, and security.
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
API Application Program Interface
BSA Basic Set of Applications
CA Cooperative Awareness
CAM Cooperative Awareness Message
© ISO 2015 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/TR 17424:2015(E)
CN Cooperative Navigation
COOPERS COOPERative systems for intelligent road Safety
CS Communities Service
CSM Cooperative Speed Management
CVIS Cooperative Vehicle-Infrastructure Systems
DENM Decentralized Environmental Notification Message
FA Facilities/Applications
ICT Information and Communication Technology
ITS Intelligent Transport System
IRIS Intelligent Cooperative Intersection Safety system
LBS Location-Based Service
LCM Life Cycle Management
LDM Local Dynamic Map
MF Management/Facilities
NF Networking and Transport/Facilities
POI Point of Interest
RHW Road Hazard Warning
RSU Road Side Unit
SAP Service Access Point
SF Security/Facilities
TPEG Transport Protocol Experts Group
V2I Vehicle to Infrastructure
V2V Vehicle to Vehicle
WLAN Wireless Local Area Network
5 Content and structure
How a LDM is built, which elements are needed and how they are implemented, strongly depends on the
role of an ITS station.
2 © ISO 2015 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TR 17424:2015(E)
Figure 1 — Viewpoints in respect of the LDM
5.1 Required LDM Elements (subsystems or functions)
A typical LDM consists of following subsystems:
— LDM management, including
— means for synchronizing content in-between LDMs,
— means for updating content, and
— means for removing outdated data elements;
— LDM Data Storage
— data storage, which covers small to huge implementations supporting personnel devices,
infrastructure systems, in-vehicle platforms, service providers and management centres;
— LDM Security
— means for data security;
— LDM Content Integrity
— means for maintaining data integrity and quality, and
© ISO 2015 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/TR 17424:2015(E)
— decision rules on conflicting data;
— LDM Privacy Policy Advisor
— rules on how to deal with privacy-affected static, quasi-static and dynamic content;
— LDM Arbiter/Screening, prioritizing
— means for putting multiple queries according their priority to the data storage and retrieving
the response;
— LDM SAPs/Data access
— interface for writing elements into and retrieving elements from the data storage;
— LDM Broker
— shared data management for multiple application access.
All the data elements and their attributes put in and out the LDM have to comply with the definition
given in the LDM Data dictionary.
5.1.1 Data elements and protocols
The input to the LDM may come from many sources likely using different protocols. Messages originating
from vehicles, for instance CAM and DENM, use a highly condensed protocol format to keep channel
blocking at a minimum. There is only a minimum of additional information contained in the message
itself to decide on reliability and confidence. Other input sources are radio broadcasts (RDS, DAB, DVB,
DMB) using, e.g. TMC or TPEG protocol, traffic centre using DATEX/DATEX2 or HTML-based application
data exchange format and so on. If data from different sources addressing the same event have a
contradicting meaning, the following additional decision-relevant information has to be considered to
get the most accurate information:
— Who is the issuer of the information?
— How and when was the information generated?
— What is the accuracy of the information?
— How was the information transmitted?
— Where and under which condition is the information valid?
5.1.1.1 TPEG in detail
Detailed information on TPEG is provided in [21].
TPEG (Transport Protocol Experts Group) specifications[9] offer a method for transmitting multimodal
traffic and travel information, regardless of client type, location or required delivery channel (e.g. DAB,
HD radio, Internet, DVB-x, DMB, GPRS, Wi-Fi …). Language independence has also been a prime principle
in the design.
5.1.1.1.1 How does TPEG work?
In contrast to TMC (event-based road traffic information), TPEG refers to a whole set or toolkit of
specifications, for offering a wider range of services to a wider range of users and devices.
TPEG services are defined in a modular way and can therefore vary in a number of “directions”:
— application, e.g. Road Traffic Messages, Public Transport Information or Parking Information.
Each Application is uniquely identified by an Application ID (AID) that are allocated by the TPEG
Application Working Group (TAWG) of TISA;
4 © ISO 2015 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TR 17424:2015(E)
— transmission method, e.g. DAB digital radio, DMB, Internet;
— location referencing method, e.g. table-based (using for example TMC location tables) or on-the-
fly (using a method that gives a location reference that works with or without maps and does not
require a look-up table to decode in the receiver);
— device, e.g. intended for vehicle navigation systems, Internet browsers or mobile devices;
— conditional access: whether data are sent for free or only to users/devices who have somehow
established the right to receive it, e.g. by paying a subscription. Encryption of TPEG data are possible
by means of Standardised Encryption Indicators, which are allocated by the TPEG Application
Working Group (TAWG) of TISA.
The term “profile” is used to define a combination of the above which, together, make up what one might
think of as a single TPEG service. For example:
— displaying traffic incidents on a map graphic and supporting re-routing or route optimization;
— displaying public transport status information on a cell phone screen.
5.1.1.1.2 TPEG Service IDs
Any TPEG-service is uniquely identified worldwide by a TPEG Service ID (SID) consisting of three
elements called SID-A, SID-B, SID-C, as described in ISO/TS 18234-2. TISA, as worldwide registrar for
TPEG SID, is responsible for allocating and maintaining TPEG Service IDs in a Registry to ensure a
worldwide unique identification of a TPEG service.
Each TPEG Application is assigned a unique number called the Application Identifier (AID) which is
standardized in ISO/TS 18234-1. An AID is defined whenever a new application is developed. The AIDs
allocated at the time of publication of this Technical Report are the following (see Table 1):
Table 1 — TPEG AID table
AID Number (Hex) Application Abbreviated term
0 Service and Network Information application SNI
1 Road Traffic Message application RTM
2 Public Transport Information application PTI
3 Parking Information application PKI
4 Congestion and Travel Time application CTT
5 Traffic Event Compacy application TEC
6 Conditional Access Information application CAI
7 Traffic Flow and Prediction TFP
8 Fuel Price Information FPI
5.1.1.2 DATEX/DATEX2
Detailed Information on DATEX/DATEX2 are provided in[22]
.
5.1.1.2.1 Background
Delivering European Transport Policy in line with the ITS Action Plan of the European Commission
requires coordination of traffic management and development of seamless pan-European services. With
the aim to support sustainable mobility in Europe, the European Commission has been supporting the
development of information exchange mainly between the actors of the road traffic management domain
for a number of years. In the road sector, the DATEX standard was developed for information exchange
between traffic management centres, traffic information centres and service providers and constitutes
© ISO 2015 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/TR 17424:2015(E)
the reference for applications that have been developed in the past 10 years. At the time of publication of
this Technical Report, the second generation DATEX II specification also pushes the door wide open for
all actors in the traffic and travel information sector.
Much investment has been made in Europe, both in traffic control and information centres over the
last decade and also in a quantum shift in the monitoring of the trans-European transport network
(TEN-T). This is in line with delivering the objectives of the EasyWay programme [17] for safer roads,
reduced congestion and a better environment. Collecting information is only part of the story; to make
the most of the investment data needs to be exchanged both with other centres and, in a more recent
development, with those developing pan-European services provided directly to road users. DATEX was
originally designed and developed as a traffic and travel data exchange mechanism by a European task
force set up to standardize the interface between traffic control and information centres. With the new
generation DATEX II, it has become the reference for all applications requiring access to dynamic traffic
and travel-related information in Europe.
5.1.1.2.2 Organization: SG - TG - User Forum
The DATEX II specifications are maintained at the time of publication by a stakeholder organization that
has been created under the EasyWay programme. In EasyWay, DATEX II is included in a set of European
Studies (ES) that deal with pan-European consensus forming and harmonization. DATEX II is covered by
European Study 5, chaired by Germany at the time of publication.
ES5 has been structured into two working groups:
— The Strategic Group (SG) steers the work programme of ES5 and reports to the EasyWay Steering
Committee and the European Commission. SG itself takes care of liaison with other relevant
stakeholder groups and outreach activities, for instance the organization of a DATEX II User Forum.
Technical day-to-day work is assigned by the SG to a dedicated technical working group.
— The Technical Group (TG) receives its terms of reference from the SG, and also reports back on its
progress. The TG consists of technical experts that deal with the day-to-day management of the
DATEX II specifications, which includes user support and user feedback via this website, but also all
technical work required in preparation of the DATEX II standardization. TG therefore works in close
cooperation with CEN/TC 278/WG 8.
The organizational structure presented is seen as a temporary solution during the life of the EasyWay
programme. In parallel to the work programme described above, the SG and the TG work together on
defining a long term, self-sustained organizational structure for the time after EasyWay.
5.1.1.2.3 Standardization
DATEX II is intended to become a multi-part standard, maintained by CEN/TC 278 (see www.
itsstandards.eu). The first three parts of the CEN DATEX II series [i.e. CEN/TS 16157 (all parts)] deal
with the most mature and widely used parts of DATEX II: the modelling methodology (called Context
and framework) as CEN/TS 16157-1, Location referencing as CEN/TS 16157-2 and the most widely used
DATEX publication for traffic information messages (called Situation publication) as CEN/TS 16157-3.
A fourth part of the CEN DATEX II series, VMS publications, is being proposed for standardization to
CEN/TC 278. More parts are to follow, including other data publications for example measured data and
elaborated data.
5.2 LDM: state of the art
5.2.1 Proposed LDM Architectures
5.2.1.1 SAFESPOT
See also Specification[12]
.
6 © ISO 2015 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TR 17424:2015(E)
Enabled by advances in communication technology, cooperative systems are seen as the next logical
step beyond autonomous driving assistance systems, for safety and comfort applications for road
traffic. In cooperative systems, autonomous information from stored digital maps and from vehicle
sensors is supplemented with cooperative information received via radio links from other vehicles and
the infrastructure.
A new spatial database concept, named local dynamic map, reflecting all relevant static, temporary
and dynamic information in the perception vicinity of a stationary object (road side unit) or moving
object (vehicles and other road users), is considered as a core element of cooperative systems. The local
dynamic map is a highly dynamic data store with a relation to the road network, which enables storage
and updating of objects including type, position and other characteristics, and retrieval of selected
information for further processing and situation analysis, such as calculation of trajectories, and detection
of hazardous obstacles and potential conflicts with other road users. If the object that maintains the
local dynamic map is moving, the map window is moving as well, with the object as its centre point. The
local dynamic map is constructed on top of a digital map database for ITS applications, and conceived
as a four layer structure with increasing dynamics, and specified as a logical object model, which may
serve as the basis for specifying the API, and for its actual implementation. The four layers represent,
respectively: a) the static (semi-permanent) digital map database; b) similar static information that is
not (yet) incorporated in the digital map database; c) temporary and dynamic information (such as
weather and traffic conditions); and d) dynamic and highly dynamic information concerning moving
objects (vehicles, vulnerable road users and animals). This Technical Report provides the specification
of the local dynamic map.
The local dynamic map has a central position in the architecture of the SAFESPOT system. Only the
sensor data processing and fusion module of the system will have write access to the local dynamic
map for transactions. All modules and applications of the system, including the data processing and
fusion module, will have access to the local dynamic map for queries. This implies that all temporary and
dynamic information that is stored in the local dynamic map passes through data processing and fusion.
For instance, sensor information that is used by an application is not directly retrieved from the sensor,
but as processed information from the local dynamic map.
The local dynamic map may be implemented as a relational or an object-oriented database. The static
map data of layer 1 may be used by directly accessing the physical storage format of the digital map
database or by transferring the static map data for the perception horizon also to the relational or an
object-relational database. Positions of dynamic objects will be maintained both as absolute position
and as map matched position to the map database road centre, possibly with lateral offset.
The local dynamic map is described as a logical object-oriented model in a UML (Unified Modelling
Language) static structure diagram. On top of the main class hierarchy is the WorldObject, with main
subclasses Feature and DynamicObject. Feature and its subclasses cover all map-related static objects
(layers 1 and 2). The class DynamicObject has two main subclasses, ConceptualObject and MovingObject.
ConceptualObject and its subclasses cover the temporary weather and traffic related in Deliverable
D3.3.3 - Dissemination Level: RE (restricted) SAFESPOT - Contract IST-4-026963-IP SF-D333-local-
dynamic-map-spec-v07.doc 12 / 86 SINTECH formation of layer 3. The class MovingObject covers the
dynamic and highly dynamic information of layer 4. It has subclasses LivingObject (with subclasses
Pedestrian, Bicyclist and Animal), Trailer and MotorVehicle (with subclasses TwoTrackVehicle and
PoweredTwoWheeler). In addition to the main hierarchy, various classes are defined that are associated
with classes in the main hierarchy. Examples are the GeometryObject (associated with WorldObject)
to express the geometry of an object, MotionState and Trajectory (associated with MovingObject) and
Driver (associated with MotorVehicle). Another class associated with MotorVehicle is EgoMotorVehicle,
covering information that is only present in the own (ego) local dynamic map. This Technical Report
provides class diagrams of various parts of the complete class diagram. In addition the whole structure
of the model is described in a text diagram, and the details of each of the classes (positing in the hierarchy,
attributes and operations) in a set of tables.
The API will consist of two parts, a transaction part and a query part. The transaction part needs to be
able to create (including attribute initialization) and remove instances of all defined DynamicObject
types (layers 3 and 4), and to set and change object attributes values (including uncertainty values) of
dynamic objects that are stored in the local dynamic map, as well as of static objects for which dynamic
© ISO 2015 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/TR 17424:2015(E)
attributes are defined. The query part of the API needs to be able to extract information from the local
dynamic map concerning all object types (i.e. including the static map and map-related information of
layers 1 and 2). It needs to be able to query the database using filters for geographic location (geometry
objects of various kinds as well as map database links), object types and object attributes. Database
queries for moving objects in relation to map database links need to be able to include, in addition to the
link to which the ego object is associated, relevant links ahead of the moving object (much like an ADAS
Horizon). This enables the system to be aware of moving objects on those links that may be encountered
by the ego object in view of their driving directions. The API may be described in terms of SQL
statements, object-oriented query statements, or more
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.