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 2015
© 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
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
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
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.
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
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
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
— 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
— 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
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
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
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 generic function calls. Although this Technical
Report provides a description of the API, precise definition of the API was still underway at the time of
publication. In addition to queries on demand, a subscription mechanism will be defined for automatic
notification, which will push information concerning objects to applications when certain predefined
conditions are met. Although this mechanism is sometimes referred to as continuous querying, it will
actually reduce the number of regular active queries that applications need to make to avoid the risk of
using dated information, and thereby reduce computational load on the system.
Figure 2 — Driver warning of dangerous situations via Car2X-communication and local
dynamic maps
8 © ISO 2015 – All rights reserved
Figure 3 — Vehicles as sensors for cooperative systems
See Specification[12]
.
Local Dynamic Maps: Focuses on extending digital maps to incorporate real-time environmental
conditions. Static and dynamic data handling and access functions and location referencing for data
exchange are considered the most relevant technologies.
Example of an application using LDM given in[21]
.
[Intelligent Cooperative Intersection Safety System (IRIS): A SAFESPOT Application
Local Dynamic Map features
The LDM is the link between the data fusion process and the applications. Therefore, any information
(static and dynamic) required by the applications has to be stored in the LDM. The LDM is a real-time
geometric representation of relevant infrastructure and non-infrastructure features and objects
near the RSU[3] It consists of four layers. The first layer contains the standard static map of the map
.
providers. The second layer includes additional static information of the surrounding environment
of the RSU; in case of IRIS a detailed description of the intersection. As Figure 4 shows, the database
contains the location of traffic signs (purple dots) and traffic lights (blue dots). Furthermore, the layer
stores information on the operational status such as operating, manual operation (police officer) or out
of operation/technical failure of the controller and for each signal group of the traffic light control the
current traffic light status, the residual time of the current traffic light status and the next traffic lights
status. These data are important for IRIS in order to compute the interactions of the vehicles with the
status of the traffic lights at the controlled intersection. In addition, the road marking, lane dividers,
pedestrian crossings and the reference tracks (green lines) are an important component of this layer.
IRIS accesses the static content of the second layer by the means of special pre-stored queries that are realized
through database views. The advantage of these views is the independency of different physical storage
formats and database structures maintained by the different map providers for the static map content.
Figure 4 — Visualization of the static map content of the LDM at an urban intersection
Beside the static content layers, layers 3 and 4 contain the dynamic data elements of the LDM. Dynamic
information such as for rain or congested road element is stored in the third layer. The fourth layer
contains the most dynamic data elements of the moving objects. It provides the possibility to store for
each moving objects the absolute and map matched position. Furthermore all additional attributes on
the objects gathered by the data sources and refined by the data fusion, such as vehicle type, speed,
acceleration and the vehicle trajectories, can be written in that layer.
The SAFESPOT applications need to access the dynamic content of the fourth layer in a fast and reliable
way. For this purpose, the LDM provides a data access library containing the API. The basic API provides
very generic queries which are SQL like. The object oriented API focuses on functions, which are more
complex, or need further LDM support, also due to performance reasons. Based on the available data in
the LDM, the applications fulfil the assessment of the situation near the RSU.
10 © ISO 2015 – All rights reserved
Concept description
The IRIS surveys signalized urban intersections by tracking all individual movements of road users
(drivers, pedestrian and cyclists), which can be regarded as a microscopic procedure [19] By analysing
.
the individual vehicle movements, IRIS tries to identify dangerous situations as early as possible in order
to warn or intervene as effectively as possible. The whole IRIS procedure is performed periodically in a
loop and consists of five subsequent main parts (see Figure 5 below):
Figure 5 — Functional description of IRIS
1) Receive LDM data: this component reads the static data describing the intersection geometry from
the LDM database. This is done once at the initialization phase of the application. The dynamic data
are constantly queried from the LDM.
2) Vehicle trajectory prediction: the prediction is based on the known position of the vehicles, and
the vehicle dynamics such as speed and acceleration. By the use of additional information, such
as the indicator usage or the lane the vehicles are driving on, the future route of the vehicle can
be estimated. Furthermore, the prediction of the trajectories is based on the reference tracks.
These tracks can be regarded as static representations of the typical driving lines of vehicles at
intersections. The predicted trajectory will comprise 10 additional future positions of the vehicle
and an assigned likelihood with a time resolution of one second.
3) Situation analysis: all potential conflicts of vehicle movements are determined together with
probabilities by examining all combinations of the predicted trajectories of the vehicles and cyclists.
The indicator of a potential conflict is not only the spatial intersection of two trajectories. This
intersection has to occur also in approximately the same point of time. This part of the analysis
module supports the safe right and left turning at the intersection. Combining the traffic lights
status and the predicted trajectories red light violation by passenger cars or emergency vehicles
can be detected. The result is a list of critical/dangerous situations specifying their expected point
in time and their likelihood to happen. The prediction will not consider the cross-correlations
of vehicles driving on different reference tracks, i.e. the movements of two vehicles of different
reference tracks are independent from each other. The reason for this restriction is to reduce
algorithmic complexity. However, cross-correlations of predicted vehicle trajectories on the same
reference tracks are considered in order to take into account the vehicles that are on the same track
downstream. If no conflicting trajectories are identified the process terminates.
4) Threat assessment: the task of the threat assessment is the identification of the level of risk of
a potential accident. This is achieved by considering the likelihood of a potential accident, which
mainly depends on the accuracy of the predicted trajectories. Furthermore, the time-to-collision is
computed. The time-to-collision can be defined as the remaining time for two road users to collide if
they continue their speed and stay on the same path[10]. Based on this, the situation can be assigned
to the safety margin concept of SAFESPOT[11]. The concept classifies three stages of warning and
actions to take:
i) Comfort Area: the situation should be communicated to the driver, but the driver has to react in
a very comfortable way to avoid the accident;
ii) Safety Area: the situation is relevant for safety and the driver has to react timely to avoid
the accident;
iii) Critical Area: the situation is critical for safety and the driver has to react in a very fast way and
with the correct manoeuvre to avoid the accident.
5) Measure generation: based on the assessed threat, the appropriate messages need to be created.
Thus, each scenario requires a different decision from IRIS, which may result in different sets of
messages in order to prevent collisions.
6) Alert device control: the last action in the course of events is the control of the corresponding alert
subsystems or devices, respectively. In principle, three different types of measures are carried out:
i) warning messages that will be sent to the drivers using wireless communication,
ii) local traffic light control changes in order to lengthen red light times of certain signal groups and
iii) warning message to vulnerable road users via icons and acoustics through roadside alert systems.
5.2.1.2 CVIS
5.2.1.2.1 Positioning, Maps and Local Referencing (POMA)
See Reference [8].
5.2.1.2.1.1 Context Diagram
The Context Diagram is the base for the detailed design of the external interfaces reported in this
Technical Report. The following definitions are used.
Core POMA entities:
— Vehicle Positioning Box: a POMA module installed in the vehicle and delivering X, Y coordinates with
quality attributes (e.g. integrity, accuracy level…) based on sensor data fusion.
— Infrastructure Positioning Box: a POMA module installed in the infrastructure (e.g. road side
cabinet) and delivering X, Y coordinates with quality attributes (e.g. integrity, accuracy level…)
based on sensor data fusion.
— Map-matching: a POMA module translating the output of the POMA positioning box (X,Y with
quality attributes) to the road network representation (map) and delivering addresses or link IDs
with quality attributes (e.g. integrity of the output).
— Map update server: a POMA module delivering map update files in given data formats (e.g. XML).
Map updates can be pushed to or pulled from applications.
— Geospatial platform: A POMA module offering access to georeferenced content (e.g. map, traffic
related to infrastructure elements) via basic navigation modules such as geocoder (e.g. from GPS
location to infrastructure elements), reverse-geocoder, map display, and route calculation.
— Georeferenced language: A XML language used to exchange georeferenced content. This language
includes specific tags to code location data (e.g. AGORA-C, X-Y …) at different abstraction level (point,
area …) and to codes events and status data.
12 © ISO 2015 – All rights reserved
— API: a set of request/response protocols (typically XML format).
5.2.1.2.1.2 Other entities of relevance to POMA
— Map update module: a module that takes map updates, compiles them and stores them in the local
map database.
— Map DB: a local map database compiled into a vendor specific format.
— External content: any set of static or dynamic geo-referenced data which can be layered on top of a map.
— The environmental conditions (e.g. urban canyons) are not under influence by CVIS, but place
requirements on the positioning capabilities, such as accuracy and integrity, especially for GNSS systems.
5.2.1.2.2 Design of POMA
Upon the context specification given in the previous paragraph, the architectural design of POMA led to
three separate parts of the POMA system:
a) the POMA in-vehicle positioning box;
b) the POMA infrastructure positioning box;
c) the POMA server components.
The collection of these three parts complies with all requirements on POMA and implements the external
interfaces as given in the next paragraphs.
Key
Processed Data Sensors
Sensor Data POMAModule
Physical Interface PVT Position, Velocity, Time
Logical Interface
Figure 6 — Functional architecture of the on-board positioning part
Figure 6 above presents the internal functional design of the in-vehicle positioning box of POMA with
external interfaces. Positioning data are delivered via two Positioning Interfaces:
— the raw position calculated by the Hybrid Fusion module using Sensor Data;
— the map-matched position using the
— standard map from the Map Module,
— enhanced map from the EMAP Module, and
14 © ISO 2015 – All rights reserved
— Road Side Positioning Module.
The raw data interface (1, L1) serves as time server for all local devices within CVIS. This timing
interface provides a UTC time (by GPS) as soon as the GPS receiver has reached operational conditions
and receives enough satellite signals. This time will be used by COMM to time stamp data communicated
over the CALM interface. Several issues with time stamping have been agreed in WP3 harmonization
meetings and corresponding email discussions according the following agreements:
— Before operational conditions (ample satellite signal received, and proper initialization of the GPS
receiver to operational) are fully met, timing given at this POMA interface cannot be relied on. During
these phases, COMM will provide an ntp service over the communications device to synchronize
time with the central CVIS time.
— The signal at the raw data interface is optimized for speed. Hence, no correction factors will be
applied. Hence, the data by applications and other CVIS components that use correction factors
will deviate in position vectors as well as that time corrections might be applicable. COMM agreed
that this dispersion in data and time stamping does not hamper the COMM intended use (e.g.
prioritization of messages).
Figure 7 below presents the internal functional design of the infrastructure positioning box (wireless
sensor network positioning and WLAN positioning) of POMA with external interfaces.
Figure 7 — Functional architecture of the positioning module (Infrastructure)
Figure 8 below presents the internal functional design of the server components and in-vehicle map
components of POMA with external interfaces and the connection to the other in-vehicle positioning
components.
Figure 8 — Functional architecture of the map module
See Reference [20].
5.2.1.3 Cooperative Awareness
If all vehicles are equipped with communication devices and regularly broadcast their positions, speed
and directions, a so called Local Dynamic Map (LDM) can be constructed. A LDM would also contain static
map information and temporary information about e.g. road conditions communicated from selected
road-side units. The co
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...