ISO 18750:2018
(Main)Intelligent transport systems — Co-operative ITS — Local dynamic map
Intelligent transport systems — Co-operative ITS — Local dynamic map
This document: — describes the functionality of a "Local Dynamic Map" (LDM) in the context of the "Bounded Secured Managed Domain" (BSMD); — specifies: — general characteristics of LDM Data Objects (LDM-DOs) that may be stored in an LDM, i.e. information on real objects such as vehicles, road works sections, slow traffic sections, special weather condition sections, etc. which are as a minimum requirement location-referenced and time-referenced; — service access point functions providing interfaces in an ITS station (ITS-S) to access an LDM for: — secure add, update and delete access for ITS-S application processes; — secure read access (query) for ITS-S application processes; — secure notifications (upon subscription) to ITS-S application processes; — management access: — secure registration, de-registration and revocation of ITS-S application processes at LDM; — secure subscription and cancellation of subscriptions of ITS-S application processes; — procedures in an LDM considering: — means to maintain the content and integrity of the data store; — mechanisms supporting several LDMs in a single ITS station unit.
Système de transports intelligents — Systèmes coopératifs — Carte locale dynamique
Ce document — décrit la fonctionnalité d’une «Carte dynamique locale» (LDM) dans le contexte du «Domaine délimité géré de manière sécurisée» (BSMD). — spécifie — les caractéristiques générales des objets de données de la LDM (LDM-DO) pouvant être stockés dans une LDM, notamment les informations sur les objets réels tels que les véhicules, les zones de travaux, les zones de ralentissement du trafic, les zones caractérisées par des conditions météorologiques particulières, etc. qui doivent, au minimum, posséder une référence spatiale (localisation) et une référence temporelle. — les fonctions des points d’accès au service fournissant des interfaces d’accès à une LDM dans une station ITS (ITS-S) pour, — les accès sécurisés d’ajout, de mise à jour et de suppression, pour les processus d’application ITS-S, — les accès sécurisés en lecture (requête), pour les processus d’application ITS-S, — les notifications sécurisées (lors de l’abonnement) aux processus d’application ITS-S. — la gestion des accès, — enregistrement, désenregistrement et révocation de manière sécurisée des processus d’application ITS-S au niveau de la LDM — abonnement et annulation des abonnements des processus d’application ITS-S de manière sécurisée, — les procédures d’une LDM tenant compte — des modalités de maintien du contenu et de l’intégrité du magasin de données, — les mécanismes soutenant plusieurs LDM dans une unité de station ITS unique.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 18750
First edition
2018-05
Intelligent transport systems —
Co-operative ITS — Local dynamic
map
Systèmes de transport intelligents — Systèmes intelligents de
transport coopératifs — État des connaissances des cartes
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms . 3
5 Architectural environment . 4
5.1 Local Dynamic Map . 4
5.2 LDM in an ITS-S . 4
5.3 LDM in an ITS-SU . 5
5.4 LDM related processes . 7
5.4.1 Synchronization of LDMs . 7
5.4.2 Archiving of LDM Data Objects . 7
5.5 LDM for road safety and vehicle-to-vehicle applications . 7
5.6 Security perspective . 8
5.6.1 Authorised access to LDM . 8
5.6.2 Initialisation and installation of applications to the BSMD . 8
5.6.3 Privacy . 9
5.7 An LDM versus other similar functionalities in an ITS-SU . 9
6 Functionality . 9
6.1 Terms and conventions . 9
6.2 Structure of an LDM .11
6.3 LDM Data Storage .12
6.4 LDM services .14
6.4.1 Registration, deregistration, and revocation of ITS-S application processes .14
6.4.2 Security checking in access requests .14
6.4.3 Access request management .15
6.5 LDM maintenance . .17
6.5.1 LDM Area of Maintenance .17
6.5.2 Outdated data management .17
6.6 LDM knowledge base .17
6.6.1 Metadata .17
6.6.2 Utility functions .18
6.7 Interfaces .18
6.7.1 Types of interfaces .18
6.7.2 Parameters of interface functions .19
6.7.3 LDM application management interface .20
6.7.4 LDM data interface .22
6.7.5 Security interface .25
6.7.6 LDM management interface .26
6.7.7 Service access points .27
7 Procedures .30
7.1 LDM services .30
7.1.1 Registration, deregistration, and revocation of ITS-S application processes .30
7.1.2 Security checking in access requests .30
7.1.3 Access request management .30
7.1.4 Second level filtering .32
7.2 LDM maintenance . .33
7.2.1 Area management .33
7.2.2 Outdated data removal .33
7.3 LDM knowledge data base .33
7.4 Interfaces .33
7.5 LDM management .33
7.5.1 Registration of LDM at ITS-S management entity .33
7.5.2 Multiple ITS-SCUs .33
Annex A (normative) ASN.1 modules .35
Annex B (normative) LDM Data Dictionary .48
Annex C (informative) Examples of LDM-DOs .50
Annex D (informative) Location-Referencing .57
Annex E (informative) Time-Referencing .61
Annex F (normative) Implementation Conformance Statement proforma .62
Bibliography .68
iv © ISO 2018 – All rights reserved
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 voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces the first edition (ISO/TS 18750:2015), which has been technically
revised.
Introduction
[17]
An essential property of cooperative intelligent transport systems (C-ITS), see ISO TR 17465-1 , is
the sharing of data between different ITS applications providing different ITS services to the users.
This approach replaces the traditional approach where each application is operated in an isolated
environment, i.e. referred to as "silo - approach". The C-ITS approach enables synergies in components
of an ITS station unit, e.g. sharing of communication tools, improves overall performance and reliability,
and reduces overall cost. In order to protect the interests of the various ITS applications, C-ITS
implements the concept of an ITS station operated as a bounded secured managed domain.
The sharing of data between applications is achieved by subscribe/publish mechanisms, where at
least two mechanisms are distinguished, i.e. one allowing ITS-S application processes to subscribe to
standardized messages from ITS message sets (direct forwarding upon reception of such messages
in an ITS station unit), and one using a local dynamic map (LDM) as repository of standardized data
objects. Such data objects stored in an LDM are named LDM Data Objects (LDM-DOs). LDM-DOs provide
self-consistent information on real objects existing at a given geo-location during a given lifetime-
interval. Authorized ITS-S application processes may add LDM-DOs to an LDM, and may retrieve LDM-
DOs from an LDM. Retrieval of LDM-DOs may be performed in queries and by means of subscription. A
subscription will result in automatic notifications of selected LDM Data Objects either in defined time
intervals, or event driven.
This document introduces the usage of LDMs, and specifies the LDM for global usage in C-ITS.
[40] [42]
Initial implementations of LDMs were in the EU research projects CVIS and Safespot .
vi © ISO 2018 – All rights reserved
INTERNATIONAL STANDARD ISO 18750:2018(E)
Intelligent transport systems — Co-operative ITS — Local
dynamic map
1 Scope
This document:
— describes the functionality of a "Local Dynamic Map" (LDM) in the context of the "Bounded Secured
Managed Domain" (BSMD);
— specifies:
— general characteristics of LDM Data Objects (LDM-DOs) that may be stored in an LDM, i.e.
information on real objects such as vehicles, road works sections, slow traffic sections, special
weather condition sections, etc. which are as a minimum requirement location-referenced and
time-referenced;
— service access point functions providing interfaces in an ITS station (ITS-S) to access an LDM for:
— secure add, update and delete access for ITS-S application processes;
— secure read access (query) for ITS-S application processes;
— secure notifications (upon subscription) to ITS-S application processes;
— management access:
— secure registration, de-registration and revocation of ITS-S application processes at
LDM;
— secure subscription and cancellation of subscriptions of ITS-S application processes;
— procedures in an LDM considering:
— means to maintain the content and integrity of the data store;
— mechanisms supporting several LDMs in a single ITS station unit.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2
ISO/IEC 9646-7, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 7: Implementation Conformance Statements
ISO 21217, Intelligent transport systems — Communications access for land mobiles (CALM) — Architecture
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at https: //www .iso .org/obp
3.1
data integrity
property that data has not altered or destroyed in an unauthorized manner
[SOURCE: ISO 24534-5]
3.2
International Atomic Time
time since 00:00:00 UTC, 1 January, 2004, identical with UTC except that no leap seconds need to be added
3.3
LDM Area of Interest
location requirement used in the filter process of queries and automatic notifications
3.4
LDM Area of Maintenance
information on the operational location area of an LDM used by LDM maintenance
[30]
Note 1 to entry: ETSI EN 302 895 restricts the LDM Area of Maintenance to "geographical area specified by
the LDM for LDM maintenance".
3.5
LDM Permissions
information on how a specific ITS-S application process may use an LDM
3.6
LDM Data Object
location-referenced and time-referenced representation of a real object that is self-explanatory without
any further context information
3.7
LDM Data Object ID
identifier of an LDM Data Object which is unique in an LDM
3.8
LDM Data Dictionary
dictionary of LDM Data Object Types
3.9
LDM Data Object Type
identifier of the type of information contained in an LDM Data Record
3.10
Location Validity
information indicating a location at which an LDM Data Object is valid
3.11
Time Validity
information indicating a time interval during which an LDM Data Object is valid
2 © ISO 2018 – All rights reserved
3.12
LDM Time of Interest
time requirement used in the filter process of queries and automatic notifications
3.13
Local Dynamic Map
entity consisting of LDM Data Objects, services and interfaces for manipulating these LDM Data Objects
3.14
location reference
uniquely identifiable description of position or area in the real world
3.15
metadata
data about data
Note 1 to entry: The term "metadata" is ambiguous as it is used for fundamentally different concepts. Structural
metadata is information related to the design and specification of data structures; it is also referred to as "data
about the containers of data". Descriptive metadata is information on instances of data, i.e. the data content; it is
also referred to as "data about data content".
3.16
Time of Creation
time when an LDM Data Record was created and updated
3.17
Time of Deletion
time when an LDM Data Record may be deleted and will no longer be considered by the LDM search
functionality
3.18
Time of Generation
time when the content of the LDM Data Object information field was created
Note 1 to entry: This is different to the time, when the LDM Data Object was written into an LDM.
4 Symbols and abbreviated terms
BSMD Bounded Secured Managed Domain
BSME Bounded Secured Managed Entity
IAT International Atomic Time
ICS Implementation Conformance Statement
ITS Intelligent Transport Systems
ITS-SCU ITS Station Communication Unit
ITS-SU ITS Station Unit
IUT Implementation Under Test
LDM Local Dynamic Map
LDM-DD LDM Data Dictionary
LDM-DT LDM Data Type
LDM-DAT LDM Data Attribute Type
LDM-DATID LDM-DAT Identifier
LDM-DTID LDM-DT Identifier
NoO Notification of Obligations
OoT Obligation of Trust
PMI Privilege Management Infrastructure
SAO Signed Acceptance of Obligations
SUT System Under Test
TPEG Transport Protocol Experts Group
UTC Universal Time Coordinated
5 Architectural environment
This clause contains informative descriptions of the architectural environment of an LDM.
5.1 Local Dynamic Map
A Local Dynamic Map (LDM) is an entity consisting of LDM Data Objects, services and interfaces for
manipulating these LDM Data Objects (LDM-DO). LDM-DOs are distinguished by means of their LDM
Data object Type (LDM-DT). LDM-DTs are specified by registration in an LDM Data Dictionary (LDM-
DD). The concept of the LDM-DD is specified in Annex B.
[18]
NOTE In ISO TR 17424 , LDM-DOs are classified into Type 1 (static permanent data objects, e.g.
[2]
cartographic data), Type 2 (static transitory data objects, e.g. temporary parking lot on the road), Type 3
(dynamic transitory data objects, e.g. works location), and Type 4 (highly dynamic data objects, e.g. location,
orientation and speed of surrounding vehicles). This classification is not used in this document.
An LDM-DO provides information on real objects (cars, road events, .) that exist at a defined location,
e.g. in a defined geo-area, and within a defined time interval. In the uppermost simple case the
information provided by an LDM-DO is just its type, its geo-location, and its time interval of validity.
Such information may be received in an ITS station unit via different channels such as:
[34] [38]
— DATEX II , TPEG , RDS-TMC (legacy systems);
[19] [20] [28]
— CEN / ETSI / ISO / SAE ITS Message sets EN/ISO 19091 , ISO/TS 19321 , ETSI EN 302 637-2 ,
[29] [39]
ETSI EN 302 637-3 , SAE J2735 ;
composed of different sets of attributes, and presented in different formats (encodings). ITS-S
application processes capable to receive this information perform a mapping on LDM-DOs and a
translation of attribute formats into the common format given by the LDM-DTs.
5.2 LDM in an ITS-S
The local dynamic map (LDM) specification provided in this document is designed for the architectural
environment of an ITS station operated as a Bounded Secured Managed Domain (BSMD) specified in
ISO 21217 and illustrated in Figure 1.
4 © ISO 2018 – All rights reserved
Figure 1 — LDM in an ITS-S operated as a Bounded Secured Managed Domain (BSMD)
The LDM functionality specified in Clause 6 is located in the ITS-S facilities layer. An LDM interfaces
with ITS-S application processes specified in ISO 21217. The interface functionality is specified in 6.6.2
by means of functions of services of the FA-SAP and the MF-SAP; both Service Access Points (SAPs)
offer identical functions for this purpose. The generic services of FA-SAP and MF-SAP are specified in
[11]
ISO 24102-3 .
5.3 LDM in an ITS-SU
Various examples of supported implementation configurations are illustrated in Figure 2, Figure 3,
Figure 4, and Figure 5.
Figure 2 illustrates a "single-box" configuration of an ITS station unit (ITS-SU) with a single LDM.
Figure 2 — Implementation configuration example a)
Figure 3 illustrates a "single-box" configuration of an ITS-SU with two LDMs.
Figure 3 — Implementation configuration example b)
Figure 4 illustrates a configuration of an ITS-SU with two ITS station communication units (ITS-SCU).
One of these ITS-SCUs has a host-only role specified in ISO 21217 and contains a single LDM. The other
ITS-SCU has a router-only role specified in ISO 21217 and does not contain an LDM.
Figure 4 — Implementation configuration example c)
Figure 5 illustrates a configuration of an ITS-SU with two ITS station communication units (ITS-SCU).
One of these ITS-SCUs has a host-only role specified in ISO 21217 and contains a single LDM. The other
ITS-SCU has a host-and-router role specified in ISO 21217 and contains also an LDM.
6 © ISO 2018 – All rights reserved
Figure 5 — Implementation configuration example d)
Many other implementation configurations are feasible.
NOTE In ITS-SUs composed of several ITS-SCUs the ITS station management can use the "ITS station-
[12]
internal management communications protocol" (IICP) specified in ISO 24102-4 to support overall station
management.
5.4 LDM related processes
5.4.1 Synchronization of LDMs
[18]
The concept of synchronization of LDMs is introduced in ISO TR 17424 , distinguishing:
— synchronization of LDMs operated in ITS station units of different vehicles;
— synchronization of LDMs operated in ITS station units at the roadside, in central offices and in
vehicles.
Reference is made to means which are already in use for TPEG and DATEX.
Such synchronization means updating of an LDM by an authorized "master" LDM. As only ITS-S
application processes can access LDM-DOs, any synchronization is to be realized by ITS applications.
Details are outside the scope of this document.
NOTE Updates of information in an ITS-SU can be performed using remote management standardized in
[10]
ISO 24102-2 .
5.4.2 Archiving of LDM Data Objects
Archiving of LDM Data Objects is a feature that produces a kind of log-file of an LDM. Such log-
file information might be of interest for different purposes, but might also be subject to privacy
considerations.
This document specifies neither an archiving functionality nor related interfaces. Archiving can be
implemented in a non-standardized way.
5.5 LDM for road safety and vehicle-to-vehicle applications
An LDM dedicated to usage for road safety and vehicle-to-vehicle applications (electronic horizon) is
[30]
specified by ETSI in EN 302 895 . This ETSI LDM specification constitutes a functional sub-set of the
specification provided in this document.
5.6 Security perspective
5.6.1 Authorised access to LDM
The architecture of an LDM in the context of BSMD from a security perspective is to ensure that access is
restricted to identified and authorised ITS-S application processes. Application processes not certified
for operation in a BSMD may access an LDM via a secure gateway described in ISO 21217, where the
firewall ITS-S application process of this gateway is authorised for read-access to the LDM.
All the core assets are to be considered as vulnerable and therefore subject to protection, where
protection takes the form of specific guards. The guard mechanism used in protecting the LDM is a
policy based access control scheme where ITS-S application processes will pre-register their policy
with the ITS-S and if that policy is agreed all future access by the ITS-S application process will be
verified as being consistent with the policy.
5.6.2 Initialisation and installation of applications to the BSMD
The kernel of an ITS-SCU forms a trust centre of the BSME and is identifiable to third party ITS-S
application processes as such. Any ITS-S application process to be added to an ITS-SCU within the
BSME verifies the identity and capability of the ITS-SCU prior to installation. If installation is allowed
an ITS-SCU verifies the credentials offered by the ITS-S application process. Prior to distribution each
ITS-S application process is functionally verified and tested and assertions of required functionality, of
[21]
developer identity, and of the tester, are validated prior to installation ISO 17419 .
[41]
The core model follows that developed in the i-Tour project as an extension of an "Obligation of
Trust" (OoT) protocol, extending the models used for Java midlet distribution used in many common
[21]
application stores, see ISO 17419 . The protection framework is a form of a Privilege Management
Infrastructure (PMI) based on common cryptographic modules and processing where authorisation
is viewed as a set of mutually agreed actions through the assignment of permissions to the parties,
i.e. the LDM and the LDM user. In the OoT protocol the participating parties exchange difficult-to-
repudiate digitally signed obligating constraints, also referred to as "Notification of Obligations" (NoO),
which detail their requirements for sending their sensitive information to the other party, and proof
of acceptances, also referred to as "Signed Acceptance of Obligations" (SAO), which acknowledge the
conditions they have accepted for receiving the other party’s sensitive information. The required
capabilities of the LDM user, i.e. an ITS-S application process, to be installed will be declared and the
application restricted to use only those capabilities by means of a policy enforcement engine acting in
the role of a Policy Enforcement Point in the LDM itself.
For protection of data the data objects identified below capture the primary policy elements
PrivacyPolicyDirective, SecurityPolicyDirective, SignedPrivacyPolicy, SignedSecurityPolicy,
CounterSignedPrivacyPolicy, and CounterSignedSecurityPolicy.
The privacy policy directive is a set of policy statements that identify the identity of the data controller.
The privacy enforcement point agrees to implement the policy and to indicate that in the Signed Privacy
Policy where the signature is of the data processor (acting as policy enforcement point).
Acceptance of the privacy policy is notified by the client in the Countersigned Privacy Policy where
the signature is given by the client using the pseudonymous identity agreed during registration. The
retention of the countersigned policy agreement provides the basis of non-repudiation of consent.
NOTE The data privacy legislation in Europe assumes the presence of a number of entities in a system dealing
with private data. These are the data controller, data processor and data subject, and a contract of consent. In an
all informed C-ITS there is no a priori consent establishment between the transmitting ITS-SU and any of the
receiving ITS-SUs, thus the security model attempts to minimize the possibility of any personal data being made
known to a receiving ITS-SU. The model therefore virtualizes the functionality of data controller, data processor
and consent by use of verifiable proofs of authority to act on data.
Permissions resulting from policy are of type "Permit" and "Deny" based on authorization, i.e. after
application of the policy the request is either permitted or denied. Requests themselves may contain
specific access requests, e.g. read data from the LDM, write data to the LDM.
8 © ISO 2018 – All rights reserved
Every incoming command to the LDM is associated with a set of claims that are checked against the local
policy at the PEP in the LDM. If any data access attempt from an application is made post-registration
and post-acceptance of the policy that does not comply with the policy it is denied.
5.6.3 Privacy
The C-ITS enforces pseudonymity capabilities through the security functions described, e.g. in
[32] [33]
ETSI TS 102 940 and ETSI TS 102 941 which maintains privacy control of data entered into
the LDM.
5.7 An LDM versus other similar functionalities in an ITS-SU
The sharing of data between ITS-S application processes in an ITS-SU can be achieved by subscribe/
publish mechanisms, where at least two mechanisms are distinguished, i.e.
a) one allowing ITS-S application processes to subscribe at the ITS-S facilities layer to standardized
[22]
messages from ITS message sets as specified in ISO/TS 17429 without using an LDM, and
b) one using a local dynamic map (LDM) as repository of standardized data objects.
[22]
The approach a) specified in ISO/TS 17429 standardizes an ITS-S facility layer message handler
which can
— directly forward complete received messages to subscribed ITS-S application processes without
storing these messages, and
— present LDM Data Objects to an LDM in case these LDM Data Objects are contained in messages that
follow the message format convention of this message handler.
There may be also other data storages, which are basically different to an LDM, i.e. which may store
data objects that are not following the definition of an LDM-DO.
6 Functionality
This clause contains informative descriptions of the functionality of an LDM.
6.1 Terms and conventions
As explained in 5.1, an LDM deals with information on real objects that are existent at a defined location
(geo-area) and within a defined time interval. Such information on a real object is identified in an LDM
Data Record, see Figure 7. Every LDM Data Record is identified with a unique LDM Data Record ID; the
value zero indicates an "unknown record".
Different location and time definitions are used to define the functionality of an LDM.
— Definitions related to the information on the real object
— Location Validity
Information at which geo-location or in which geo-area the LDM-DO applies.
— Time Validity
Information in which time interval(s) the LDM-DO applies.
— Time of Generation
Information on the time when the LDM-DO information was generated, e.g. time when a
perception system (e.g. a sensor) detected the event "slippery road".
— Time of Mandatory Deletion
Information on time after which the LDM record will no longer be returned in a query.
— Definitions used in queries
— LDM Area of Interest
Geo-location(s) or geo-area(s) that are of interest for the querying ITS-S application process.
— LDM Time of Interest
Time instant or time interval(s) that are of interest for the querying ITS-S application process.
— Age of Interest
Age of LDM record as required by the querying ITS-S application process. The age is
calculated with a numerical operator presented by the ITS-S application process against the
time of generation of an LDM-DO, if available, or alternatively against the time of last update
of an LDM-DO.
— Definitions used for maintenance purposes
— LDM Area of Maintenance
Geo-area(s) considered by the LDM search functionality and defined by the LDM in an
implementation-specific way. Without overlap of the LDM Area of Interest with the LDM Area
of Maintenance a query will not result in a hit. Note that the area of maintenance can be defined
relative to the momentary location of the host ITS-S.
— LDM Inactive Area
Geo-area(s) considered by the LDM to store LDM records with are not considered by the search
functionality; there is no overlap between the LDM Area of Maintenance and the LDM Inactive
Area. Details on the usage of the LDM Inactive Area are not specified in this document.
— Time of Creation
Time at which the LDM record was created in the LDM Data Storage.
— Time of Deletion
Time after which an LDM record may be deleted, and will no more be considered by the LDM
search functionality.
Several location reference systems and time reference systems are known; examples are presented in
Annex D and Annex E. This document supports any kind of reference system by defining time reference
and location reference with the ASN.1 type CLASS which allows defining specific instantiations at a
later time according to the needs of C-ITS services. The generic approach for location is given in the
ASN.1 type LDMarea. The generic approach for time is given in the ASN.1 type TimeInformation.
In order to manage time an LDM needs to maintain or access a time reference system (clock). This
document assumes that there is a trusted time service available in an ITS-SU which can be used in
an implementation specific way. Time synchronization with an external clock to ensure unique time
information in all ITS-SUs will be a task of the ITS-S management of an ITS-S facility, e.g. as specified in
[23]
ISO 21176 .
Similarly it is assumed that an LDM has access to a service providing continuously the kinematic state of
the ITS-SU in which it resides; thus no explicit interface to such a service is specified in this document.
10 © ISO 2018 – All rights reserved
As this document supports various implementation architectures illustrated in 5.3, ITS-S application
processes need to be enabled to select appropriate LDMs. For this purpose,
a) LDMs are identified by an LDM ID that is unique in an ITS-SU,
b) LDMs register at the ITS-S management entity reporting about their capabilities in terms of
supported LDM-DOs, and
c) ITS-S application processes register at the ITS-S management entity reporting their LDM
requirements in terms of required LDM-DOs, which is acknowledged by providing the address
information of the best suited LDMs.
The LDM performs the following procedures to maintain integrity of the LDM Data Storage:
— Removal of LDM Data Records that are out of date;
— Removal of LDM Data Records which are out of the LDM Area of Maintenance.
Further integrity checking is supposed to be performed by ITS-S application processes.
6.2 Structure of an LDM
An LDM is composed of functional blocks presented in Figure 6:
Figure 6 — Structure of an LDM
— LDM Data Storage: This is the entity in an LDM that stores LDM-DOs as described in 6.3.
— LDM Service: This functional block provides means for:
— managing registration, deregistration requests and revocation of ITS-S application processes;
— security checking in access requests;
— managing access requests (add, update, delete, subscribe, query, notify) from ITS-S application
processes;
as described in 6.4.
— LDM Maintenance: This functional block provides means for:
— updating the LDM Area of Maintenance;
— removing LDM-Data Records;
as described in 6.5.
— LDM Knowledge Base: This provides the knowledge that is required in the LDM for internal
processing as described in 6.6. This functional block includes:
— Metadata;
— the LDM Data Dictionary;
— information on ITS-S application processes' registrations and subscriptions to the LDM;
— LDM utility functions.
— Interfaces: The interfaces used and offered by an LDM are:
— Data interface towards ITS-S application processes for:
— add, update and delete access;
— query access;
— subscription access;
— notifications upon subscription.
— Management and security interfaces for:
— registration, deregistration and revocation of ITS-S applications;
— validation of access rights claimed by ITS-S applications at time of registration;
— LDM management (e.g. registration of LDM at the ITS-S management);
as described in 6.6.2.
— LDM Management: This functional block provides means for:
— registration of an LDM at the ITS-S management.
6.3 LDM Data Storage
An LDM Data Storage logically contains LDM data records presented in Figure 7.
Figure 7 — Elements of LDM Data Record
12 © ISO 2018 – All rights reserved
An LDM data record is uniquely identified by its LDM record ID. An LDM data record consists of:
— LDM-DO Parameters:
— the LDM-DO Type (LDM-DT);
— the Location Validity of the real object;
— the Time Validity of the real object;
— Time of Generation of information contained in the LDM-DO (set to the value zero in case the
time is unknown);
— Time of Mandatory Deletion of an LDM Data Record;
NOTE 1 Updates of an LDM Data Record can only be provided by the same ITS-S application process
that originally generated the LDM Data Record.
NOTE 2 The Location Validity and Time Validity fields basically consist each of two parts, one
containing the values of the original reference system, and the other one containing the values of the
reference system used in the LDM.
— the LDM-DO Attributes as specified in the LDM Data Dictionary (LDM-DD);
— LDM Maintenance Parameters which cannot be set explicitly by an ITS-S application process, and
which cannot be retrieved by an ITS-S application process:
— identifier of the ITS-S application process that presented this instantiation of an LDM-DO for
storing in the LDM;
— Time of Creation of the LDM Data Record which is different to the time of generation of the
information contained in the attributes of the LDM-DO;
— Time of Deletion of the LDM Data Record from the LDM;
— Privacy flag.
Table 1 explains and specifies the elements of an LDM Data Record in Figure 7; it refers to ASN.1 type
definition specified in Annex A.
Table 1 — LDM Data Record elements
Element Specification and explanation
LDM record ID This element uniquely identifies a specific record in the LDM. The format of this element
is given by the ASN.1 element LDMrecordID specified in Annex A. The value zero points
to the "non-existent" LDM Data Record.
LDM-DO type This element uniquely identifies the type of the LDM-DO. The format of this element is
given by the ASN.1 element LDMdataObjectTypeID specified in Annex A.
Location Validity This element uniquely identifies the position or area at which the information given by
the LDM-DO applies. Several location reference systems are allowed in the interface
functions. This field basically consist of two parts, one containing the values of the orig-
inal reference system, and the other one containing the values of the reference system
used in the LDM. The format of location reference systems is given by the ASN.1 element
LDMarea specified in Annex A.
Time Validity This element uniquely identifies the time period when the information given by the LDM-
DO applies. Several time formats to present a time period are allowed in the interface
functions. Thus this field basically consist of two parts, one containing the values of the
original reference system, and the other one containing the values of the reference sys-
tem used in the LDM. The format of time reference systems is given by the ASN.1 element
TimeInformation specified in Annex A.
Table 1 (continued)
Element Specification and explanation
Time of Generation This element uniquely identifies the time when the
...
NORME ISO
INTERNATIONALE 18750
Première édition
2018-05
Système de transports intelligents —
Systèmes coopératifs — Carte locale
dynamique
Intelligent transport systems — Co-operative ITS — Local dynamic
map
Numéro de référence
©
ISO 2018
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2018
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2018 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Symboles et abréviations . 3
5 Environnement architectural . 4
5.1 Carte dynamique locale . 4
5.2 LDM dans une ITS-S . 5
5.3 LDM dans une ITS-SU . 5
5.4 Processus liés à la LDM . 7
5.4.1 Synchronisation des LDM. 7
5.4.2 Archivage des objets de données de la LDM . 8
5.5 LDM pour la sécurité routière et les applications de véhicule à véhicule . 8
5.6 Perspective de sécurité . 8
5.6.1 Accès autorisé à la LDM . 8
5.6.2 Initialisation et installation d’applications dans le BSMD . 8
5.6.3 Confidentialité . 9
5.7 La LDM face à d’autres fonctionnalités similaires dans une ITS-SU. 9
6 Fonctionnalités .10
6.1 Termes et conventions .10
6.2 Structure d’une LDM .12
6.3 Espace de stockage des données de la LDM .13
6.4 Services de la LDM .16
6.4.1 Enregistrement, désenregistrement et révocation des processus
d’application ITS-S . . .16
6.4.2 Vérifications de sécurité dans les demandes d’accès .16
6.4.3 Gestion des demandes d’accès .16
6.5 Maintenance de la LDM .19
6.5.1 Zone de maintenance de la LDM .19
6.5.2 Gestion des données ayant expiré.19
6.6 Base de connaissances de la LDM .19
6.6.1 Métadonnées .19
6.6.2 Fonctions utilitaires .19
6.7 Interfaces .20
6.7.1 Types d’interfaces .20
6.7.2 Paramètres des fonctions d’interface .20
6.7.3 Interface de gestion de l’application de la LDM .23
6.7.4 Interface de données de la LDM .24
6.7.5 Interface de sécurité .28
6.7.6 Interface de gestion de la LDM .29
6.7.7 Points d’accès au service .29
7 Procédures .33
7.1 Services de la LDM .33
7.1.1 Enregistrement, désenregistrement et révocation des processus
d’application ITS-S . . .33
7.1.2 Vérifications de sécurité dans les demandes d’accès .33
7.1.3 Gestion des demandes d’accès .33
7.1.4 Filtrage de deuxième niveau .35
7.2 Maintenance de la LDM .36
7.2.1 Gestion de zone .36
7.2.2 Retrait des données ayant expiré .36
7.3 Base de connaissances de la LDM .36
7.4 Interfaces .36
7.5 Gestion de la LDM .37
7.5.1 Enregistrement de la LDM auprès de l’entité de gestion ITS-S .37
7.5.2 ITS-SCU multiples.37
Annexe A (normative) Modules ASN.1 .38
Annexe B (normative) Dictionnaire de données de la LDM .50
Annexe C (informative) Exemples de LDM-DO .52
Annexe D (informative) Référencement spatial (localisation) .59
Annexe E (informative) Référencement temporel .64
Annexe F (normative) Formulaire de déclaration de conformité des mises en œuvre .65
Bibliographie .72
iv © ISO 2018 – Tous droits réservés
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO, participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction définies dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/directives).
L’attention est attirée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www .iso .org/patents).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes de l’organisation
mondiale du commerce (OMC) concernant les obstacles techniques au commerce (OTC), voir le lien
suivant: www .iso .org/iso/foreword .html.
Le comité chargé de l’élaboration du présent document est l’ISO/TC 204, Système de transports
intelligent.
Cette première édition annule et remplace la première édition (ISO/TS 18750:2015), qui a été
techniquement révisée.
Introduction
[15]
Les systèmes de transport intelligents coopératifs (C-ITS), voir l’ISO TR 17465-1, possèdent une
propriété essentielle: le partage des données entre différentes applications ITS fournissant divers
services ITS aux utilisateurs. Cette démarche remplace l’approche traditionnelle selon laquelle chaque
application est exploitée dans un environnement isolé, également nommée «approche cloisonnée». La
démarche C-ITS permet de créer des synergies dans les composants d’une unité de station ITS, par ex. le
partage des outils de communication, d’améliorer les performances et la fiabilité générales et de réduire
les coûts globaux. Pour protéger les intérêts des différentes applications ITS, les C-ITS mettent en œuvre
le concept d’une station ITS exploitée en tant que domaine délimité géré de manière sécurisée.
Les données sont partagées entre les applications via des dispositifs d’abonnement/de publication,
dans lesquels on distingue au moins deux mécanismes: l’un permettant aux processus d’application
ITS-S de s’abonner à des messages normalisés à partir d’ensembles de messages ITS (transfert direct à
la réception de ces messages dans une unité de station ITS), l’autre utilisant une carte dynamique locale
(LDM) en tant que référentiel d’objets de données normalisés. Ces objets de données stockés dans une
LDM sont nommés Objets de données de la LDM (LDM-DO). Les LDM-DO fournissent des informations
cohérentes sur les objets réels présents à une géolocalisation donnée durant un intervalle de temps
déterminé. Les processus d’application ITS-S autorisés peuvent ajouter des LDM-DO à une LDM et
récupérer des LDM-DO dans une LDM. Les LDM-DO peuvent être récupérés par le biais de requêtes et au
moyen d’un abonnement. Un abonnement générera des notifications automatiques pour une sélection
d’objets de données de la LDM, soit à intervalles de temps définis, soit dès l’occurrence d’un événement.
Ce document présente l’utilisation des LDM et spécifie la LDM pour une exploitation globale dans le
cadre des C-ITS.
Les mises en œuvre initiales des LDM ont été réalisées dans le cadre des projets de recherche de l’UE
[40] [42]
CVIS et Safespot .
vi © ISO 2018 – Tous droits réservés
NORME INTERNATIONALE ISO 18750:2018(F)
Système de transports intelligents — Systèmes coopératifs
— Carte locale dynamique
1 Domaine d’application
Ce document
— décrit la fonctionnalité d’une «Carte dynamique locale» (LDM) dans le contexte du «Domaine
délimité géré de manière sécurisée» (BSMD).
— spécifie
— les caractéristiques générales des objets de données de la LDM (LDM-DO) pouvant être stockés
dans une LDM, notamment les informations sur les objets réels tels que les véhicules, les zones
de travaux, les zones de ralentissement du trafic, les zones caractérisées par des conditions
météorologiques particulières, etc. qui doivent, au minimum, posséder une référence spatiale
(localisation) et une référence temporelle.
— les fonctions des points d’accès au service fournissant des interfaces d’accès à une LDM dans
une station ITS (ITS-S) pour,
— les accès sécurisés d’ajout, de mise à jour et de suppression, pour les processus
d’application ITS-S,
— les accès sécurisés en lecture (requête), pour les processus d’application ITS-S,
— les notifications sécurisées (lors de l’abonnement) aux processus d’application ITS-S.
— la gestion des accès,
— enregistrement, désenregistrement et révocation de manière sécurisée des processus
d’application ITS-S au niveau de la LDM
— abonnement et annulation des abonnements des processus d’application ITS-S de
manière sécurisée,
— les procédures d’une LDM tenant compte
— des modalités de maintien du contenu et de l’intégrité du magasin de données,
— les mécanismes soutenant plusieurs LDM dans une unité de station ITS unique.
2 Références normatives
Les documents de référence suivants, dans leur version intégrale ou partielle, ont un caractère normatif
et sont indispensables pour l’application du présent document. Pour les références datées, seule l’édition
citée s’applique. Pour les références non datées, la dernière édition du document de référence s’applique
(y compris les éventuels amendements).
ISO 21217, Systèmes intelligents de transport — Accès aux communications des services mobiles terrestres
(CALM) — Architecture
ISO/IEC 8824-1, Technologies de l'information -- Notation de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base — Partie 1
ISO/IEC 8825-2, Technologies de l'information -- Règles de codage ASN.1: Spécification des règles de codage
compact (PER) — Partie 2
ISO/IEC 9646-7, Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Essais de
conformité — Méthodologie générale et procédures — Partie 7: Déclarations de conformité des mises
en oeuvre
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https: //www .iso .org/obp
— IEC Electropedia: disponible à l’adresse http: //www .electropedia .org/
3.1
Intégrité des données
propriété assurant que des données n’ont pas été modifiées ou détruites de façon non autorisée
[SOURCE: ISO 24534-5]
3.2
Temps atomique international
er
temps s’écoulant depuis le 1 janvier 2004, 00:00:00 UTC, identique au temps UTC hormis le fait qu’il
n’est nécessaire d’ajouter aucune seconde intercalaire.
3.3
Zone d’intérêt de la LDM
exigence d’emplacement exploitée dans le processus de filtrage des requêtes et des notifications
automatiques
3.4
Zone de maintenance de la LDM
Information sur la zone d’emplacement opérationnel d’une LDM utilisée par la maintenance de la LDM
[28]
Note 1 à l'article: L’ETSI EN 302 895 limite la Zone de maintenance de la LDM à la «zone géographique spécifiée
par la LDM pour sa propre maintenance».
3.5
Permissions de la LDM
information précisant dans quelle mesure un processus d’application ITS-S spécifique est autorisé à
utiliser une LDM
3.6
Objet de données de la LDM
représentation d’un objet réel, basée sur une référence spatiale (localisation) et une référence
temporelle, explicite sans autre information de contexte
3.7
ID d’objet de données de la LDM
identificateur d’un objet de données unique dans une LDM
3.8
Dictionnaire de données de la LDM
dictionnaire de types d’objets de données de la LDM
3.9
Type d’objet de données de la LDM
identificateur du type d’information contenue dans un bloc de données de la LDM
2 © ISO 2018 – Tous droits réservés
3.10
Validité spatiale
information indiquant un emplacement auquel un objet de données de la LDM est valide
3.11
Validité temporelle
information indiquant un intervalle de temps durant lequel un objet de données de la LDM est valide
3.12
Temps d’intérêt de la LDM
exigence de temps employée dans le processus de filtrage des requêtes et des notifications automatiques
3.13
Carte dynamique locale
entité comprenant des objets de données de la LDM, avec les services et interfaces nécessaires à leur
manipulation
3.14
Référence spatiale (localisation)
description d’emplacement ou de zone identifiable de manière unique dans le monde réel
3.15
Métadonnées
données concernant d’autres données
Note 1 à l'article: Le terme «métadonnées» est ambigu, car il est employé dans le cadre de concepts
fondamentalement différents. Les métadonnées structurelles sont des informations liées à la conception et
à la spécification de structures de données; elles sont également définies comme des «données concernant les
conteneurs de données». Les métadonnées descriptives sont des informations sur les instances de données, c’est-
à-dire le contenu des données; elles sont également définies comme des «données concernant le contenu des
données».
3.16
Horaire de création
horaire auquel un bloc de données de la LDM a été créé et mis à jour
3.17
Horaire de suppression
horaire auquel un bloc de données de la LDM peut être supprimé et ne sera plus pris en considération
par la fonctionnalité de recherche de la LDM
3.18
Horaire de génération
horaire auquel le contenu du champ d’information de l’objet de données de la LDM a été créé
Note 1 à l'article: Cet horaire diffère de l’horaire auquel l’objet de données de la LDM a été écrit dans une LDM.
4 Symboles et abréviations
BSMD Bounded Secured Managed Domain (Domaine délimité géré de manière sécurisée)
BSME Bounded Secured Managed Entity (Entité délimitée gérée de manière sécurisée)
IAT International Atomic Time (Temps atomique international)
ICS Implementation Conformance Statement (Déclaration de conformité des mises en œuvre)
ITS Intelligent Transport Systems (Systèmes de transport intelligents)
ITS-SCU ITS Station Communication Unit (Unité de communication de station ITS)
ITS-SU ITS Station Unit (Unité de station ITS)
IUT Implementation Under Test (Mise en œuvre en cours d’essai)
LDM Local Dynamic Map (Carte dynamique locale)
LDM-DD LDM Data Dictionary (Dictionnaire de données de la LDM)
LDM-DT LDM Data Type (Type de données de la LDM)
LDM-DAT LDM Data Attribute Type (Type d’attribut de données de la LDM)
LDM-DATID LDM-DAT Identifier (Identificateur du type d’attribut de données de la LDM)
LDM-DTID LDM-DT Identifier (Identificateur du type de données de la LDM)
NdO Notification of Obligations (Notification d’obligations)
OdC Obligation of Trust (Obligation de confiance)
PMI Privilege Management Infrastructure (Infrastructure de gestion des privilèges)
SAO Signed Acceptance of Obligations (Acceptation signée des obligations)
SUT System Under Test (Système en cours d’essai)
TPEG Transport Protocol Experts Group (Groupe d’experts du protocole de transport)
UTC Universal Time Coordinated (Temps universel coordonné)
5 Environnement architectural
Cette section contient des descriptions à caractère informatif de l’environnement architectural
d’une LDM.
5.1 Carte dynamique locale
Une carte dynamique locale (LDM) est une entité comprenant des objets de données de la LDM (LDM-
DO), avec les services et interfaces nécessaires à leur manipulation. Les LDM-DO se distinguent par
leur type (LDM-DT). Les LDM-DT sont spécifiés par le biais d’un enregistrement dans le dictionnaire de
données de la LDM (LDM-DD). Le concept du LDM-DD est présenté à l’Annex B.
[16]
NOTE Dans l’ISO TR 17424, les LDM-DO sont classés selon 4 types: Type 1 (objets de données permanents
et statiques, par ex. les données de cartographie), Type 2 (objets de données temporaires et statiques, par ex. une
aire de stationnement temporaire sur la route), Type 3 (objets de données temporaires et dynamiques, par ex.
l’emplacement des travaux), et Type 4 (objets de données hautement dynamiques, par ex. localisation, orientation
et vitesse des véhicules alentours). Le présent document n’utilise pas cette classification.
Un LDM-DO fournit des informations sur les objets réels (véhicules, événements routiers, etc.) localisés
à un endroit défini, dans une zone géographique définie, dans un intervalle de temps défini. Dans le cas
le plus simple, les informations fournies par un LDM-DO sont uniquement son type, sa géolocalisation et
sa durée de validité. Ces informations peuvent être reçues dans une unité de station ITS via différents
canaux, tels que
[32] [36]
— DATEX II, TPEG, RDS-TMC (systèmes hérités);
[17] [18]
— Ensembles de messages ITS CEN / ETSI / ISO / SAE selon CEN/ISO, CEN/ISO TS 19321, ETSI
[26] [27] [37]
EN 302 637-2, ETSI EN 302 637-3, SAE J2735 ;
4 © ISO 2018 – Tous droits réservés
composés de différents jeux d’attributs, et présentés selon différents formats (encodages). Les processus
d’application ITS-S capables de recevoir ces informations réalisent une cartographie à partir des LDM-
DO et une conversion des formats d’attributs dans le format commun donné par les LDM-DT.
5.2 LDM dans une ITS-S
La spécification de carte dynamique locale (LDM) présentée dans ce document est conçue pour
l’environnement architectural d’une station ITS exploitée en tant que domaine délimité géré de manière
sécurisée (BSMD) spécifié dans l’ISO 21217:2014 et représenté dans la Figure 1.
Figure 1 — LDM dans une ITS-S exploitée en tant que domaine délimité géré de manière
sécurisée (BSMD)
La fonctionnalité LDM spécifiée dans la section 6 est située dans la couche de dispositifs de l’ITS-S.
Une LDM établit une interface avec les processus d’application ITS-S spécifiés dans l’ISO 21217:2014. La
fonctionnalité d’interface est spécifiée au paragraphe 6.6.2 par le biais de fonctions de services du FA-
SAP et du MF-SAP; ces deux points d’accès au service (SAP) proposent des fonctions identiques à cette
[9]
fin. Les services génériques des FA-SAP et MF-SAP sont spécifiés dans l’ISO 24102-3 .
5.3 LDM dans une ITS-SU
La Figure 2, la Figure 3, la Figure 4, et la Figure 5 présentent divers exemples de configurations de mise
en œuvre supportées.
Figure 2 présente une configuration «monobloc» d’une unité de station ITS (ITS-SU) avec une seule LDM.
Figure 2 — Exemple de configuration de mise en œuvre a)
Figure 3 présente une configuration «monobloc» d’une ITS-SU avec deux LDM.
Figure 3 — Exemple de configuration de mise en œuvre b)
Figure 4 présente une configuration d’une ITS-SU avec deux unités de communication de station ITS
(ITS-SCU). L’une de ces ITS-SCU a un rôle d’hôte uniquement, spécifié dans l’ISO 21217:2014, et contient
une seule LDM. L’autre ITS-SCU a un rôle de routeur uniquement, spécifié dans l’ISO 21217:2014, et ne
contient pas de LDM.
6 © ISO 2018 – Tous droits réservés
Figure 4 — Exemple de configuration de mise en œuvre c)
Figure 5 présente une configuration d’une ITS-SU avec deux unités de communication de station ITS
(ITS-SCU). L’une de ces ITS-SCU a un rôle d’hôte uniquement, spécifié dans l’ISO 21217:2014, et contient
une seule LDM. L’autre ITS-SCU a un rôle d’hôte et de routeur, spécifié dans l’ISO 21217:2014, et contient
également une LDM.
Figure 5 — Exemple de configuration de mise en œuvre d)
De nombreuses autres configurations de mise en œuvre sont réalisables.
NOTE Dans les ITS-SU composées de plusieurs ITS-SCU, la gestion de la station ITS peut exploiter le
[10]
«protocole de communications de gestion interne à la station ITS» (IICP) spécifié dans l’ISO 24102-4 pour
soutenir la gestion globale de la station.
5.4 Processus liés à la LDM
5.4.1 Synchronisation des LDM
[16]
Le concept de synchronisation des LDM est présenté par l’ISO TR 17424, distinguant
— la synchronisation des LDM exploitées dans les unités de station ITS de différents véhicules;
— la synchronisation des LDM exploitées dans les unités de station ITS situées en bord de route, dans
les bureaux centraux et dans les véhicules.
Il est fait référence aux moyens déjà exploités pour TPEG et DATEX.
Cette synchronisation implique la mise à jour d’une LDM par une LDM «maîtresse» autorisée. Étant
donné que seuls les processus d’application ITS-S sont en mesure d’accéder aux LDM-DO, toute
synchronisation doit être réalisée par les applications ITS. Les modalités détaillées sortent du domaine
d’application du présent document.
NOTE La mise à jour des informations d’une ITS-SU peut être réalisée par le biais de la gestion à distance
[8]
normalisée par l’ISO 24102-2 .
5.4.2 Archivage des objets de données de la LDM
L’archivage des objets de données de la LDM est une fonctionnalité permettant de créer une sorte
de fichier journal d’une LDM. Les informations de ce fichier journal peuvent être pertinentes pour
différents usages, mais peuvent également faire l’objet de considérations ayant trait à la confidentialité.
Ce document ne spécifie ni fonctionnalité d’archivage, ni interface connexe. L’archivage peut être mis en
œuvre de manière non normalisée.
5.5 LDM pour la sécurité routière et les applications de véhicule à véhicule
Une LDM dédiée au contexte de la sécurité routière et aux applications de véhicule à véhicule (horizon
[28]
électronique) est spécifiée par l’ETSI dans l’EN 302 895. Cette spécification de l’ETSI concernant la
LDM constitue un sous-ensemble fonctionnel de la spécification du présent document.
5.6 Perspective de sécurité
5.6.1 Accès autorisé à la LDM
L’architecture d’une LDM dans le contexte du BSMD du point de vue de la sécurité permet de s’assurer
que l’accès est réservé aux processus d’application ITS-S identifiés et autorisés. Les processus
d’application non certifiés pour une exploitation dans un BSMD peuvent accéder à une LDM via une
passerelle sécurisée décrite par l’ISO 21217:2014, dans laquelle le processus d’application ITS-S pare-
feu de cette passerelle peut accéder uniquement en lecture à la LDM.
Tous les actifs fondamentaux doivent être considérés comme vulnérables et donc sous protection
prenant la forme de mécanismes spécifiques. Le mécanisme de protection de la LDM est un système de
contrôle d’accès basé sur une politique, dans lequel les processus d’application ITS-S doivent enregistrer
au préalable leur politique auprès de l’ITS-S et, si cette politique est acceptée, tous les accès ultérieurs
par le processus d’application ITS-S seront vérifiés et déclarés conformes à la politique.
5.6.2 Initialisation et installation d’applications dans le BSMD
Le noyau d’une ITS-SCU constitue le centre de confiance de la BSME et est identifiable en tant que tel
vis-à-vis des processus d’application ITS-S tiers. Tout processus d’application ITS-S à ajouter à une ITS-
SCU dans la BSME vérifie l’identité et les capacités de l’ITS-SCU avant l’installation. Si l’installation est
autorisée, une ITS-SCU vérifie les justificatifs proposés par le processus d’application ITS-S. Avant la
distribution, les fonctionnalités de chaque processus d’application ITS-S sont vérifiées et soumises à
essai, et les affirmations de fonctionnalité requise, d’identité du développeur et d’identité du testeur,
[19]
sont validées avant installation selon l’EN/ISO 17419 .
[39]
Le modèle fondamental suit celui qui a été développé dans le cadre du projet i-Tour en tant
qu’extension d’un protocole d’ «obligation de confiance» (OoT), dans le prolongement des modèles
utilisés pour la distribution des midlets Java employés dans de nombreux référentiels d’applications,
[19]
voir EN/ISO 17419. Le cadre de protection est une forme d’Infrastructure de gestion des privilèges
(PMI) basée sur un traitement et des modules cryptographiques communs selon lesquels l’autorisation
est considérée comme un ensemble d’actions mutuellement convenues par l’attribution de permissions
aux parties, c’est-à-dire la LDM et l’utilisateur de la LDM. Dans le protocole OoT, les parties prenantes
échangent des engagements signés numériquement difficilement répudiables, également nommés
«Notifications d’obligations» (NoO), qui énoncent de manière détaillée leurs exigences concernant l’envoi
8 © ISO 2018 – Tous droits réservés
de leurs informations sensibles à l’autre partie, ainsi que des preuves d’acceptation, également nommées
«Acceptations signées d’obligations» (SAO), qui confirment les conditions qu’elles ont acceptées pour la
réception des informations sensibles de l’autre partie. Les capacités requises de l’utilisateur de la LDM,
c’est-à-dire un processus d’application ITS-S, à installer seront déclarées et l’application exploitera
uniquement ces capacités par le biais d’un moteur de mise en œuvre des politiques agissant comme
Point de mise en œuvre des politiques dans la LDM elle-même.
Pour protéger les données, les objets de données identifiés ci-dessous enregistrent les éléments de
politique primaires:
PrivacyPolicyDirective, SecurityPolicyDirective, SignedPrivacyPolicy, SignedSecurityPolicy,
CounterSignedPrivacyPolicy, et CounterSignedSecurityPolicy.
La directive de politique de confidentialité est un ensemble d’énoncés de politique identifiant le
contrôleur des données. Le point de mise en œuvre de la confidentialité accepte de mettre en œuvre
la politique et de l’indiquer dans la Politique de confidentialité signée, lorsque la signature émane de
l’organe de traitement des données (agissant en tant que point de mise en œuvre de la politique, PEP).
L’acceptation de la politique de confidentialité est notifiée par le client dans la Politique de
confidentialité contresignée, la signature étant fournie par le client utilisant le pseudonyme convenu
lors de l’enregistrement. La conservation de l’accord de politique contresigné fournit la base de la non-
répudiation du consentement.
NOTE La législation régissant la confidentialité des données en Europe suppose la présence d’un certain
nombre d’entités dans un système gérant les données privées. Il s’agit du contrôleur des données, de l’organe de
traitement des données et du sujet des données, ainsi que d’un contrat de consentement. Dans un C-ITS s’appuyant
sur une information complète, il n’y a pas d’établissement à priori du consentement entre l’ITS-SU émettrice
et l’une des ITS-SU réceptrices. Ainsi, le modèle de sécurité tente de minimiser le risque de divulgation d’une
donnée personnelle auprès d’une ITS-SU réceptrice. Le modèle virtualise donc les fonctionnalités du contrôleur
de données, de l’organe de traitement des données et du consentement en s’appuyant sur des preuves d’autorité
vérifiables pour se conformer aux données.
Les permissions issues de la politique sont de type «Acceptation» et «Refus» sur la base de l’autorisation,
c’est-à-dire qu’après application de la politique, la demande est soit acceptée, soit refusée. Les demandes
elles-mêmes peuvent contenir des demandes d’accès spécifiques, par ex. lecture de données dans la
LDM, écriture de données dans la LDM.
Toute commande entrante au niveau de la LDM est associée à un ensemble de revendications comparées
à la politique locale au PEP dans la LDM. Si une tentative d’accès aux données à partir d’une application
réalisée après l’enregistrement et après l’acceptation de la politique n’est pas conforme à la politique,
cette tentative sera refusée.
5.6.3 Confidentialité
Le C-ITS met en œuvre les capacités de pseudonymat par le biais des fonctions de sécurité décrites
[30] [31]
notamment par l’ETSI TS 102 940 et l’ETSI TS 102 941 maintenant le contrôle de confidentialité
des données entrant dans la LDM.
5.7 La LDM face à d’autres fonctionnalités similaires dans une ITS-SU
Le partage des données entre les processus d’application ITS-S dans une ITS-SU peut être réalisé par
des mécanismes d’abonnement/de publication, parmi lesquels on distingue au moins deux mécanismes:
a) un mécanisme permettant aux processus d’application ITS-S de s’abonner au niveau de la couche
de dispositifs ITS-S à des messages normalisés provenant des ensembles de messages ITS
[20]
conformément à la norme CEN/ISO 17429 sans utiliser de LDM, et
b) un mécanisme utilisant une carte dynamique locale (LDM) en tant que référentiel d’objets de
données normalisés.
[20]
La démarche a) spécifiée dans la norme CEN/ISO 17429 normalise un module de gestion des
messages au niveau de la couche de dispositifs ITS-S pouvant
— transférer directement les messages complets reçus aux processus d’application ITS-S sans stocker
ces messages, et
— présenter des objets de données LDM à une LDM si ces objets de données sont contenus dans
des messages conformes à la convention de formatage des messages de ce module de gestion des
messages.
Il peut également y avoir d’autres espaces de stockage de données, fondamentalement différents
d’une LDM dans la mesure où ils peuvent stocker des objets de données non conformes à la définition
d’un LDM-DO.
6 Fonctionnalités
Cette section contient des descriptions à titre informatif des fonctionnalités d’une LDM.
6.1 Termes et conventions
Comme l’indique la section 5.1, une LDM traite des informations sur les objets réels, qui existent à un
endroit défini (zone géographique) et dans un intervalle de temps défini. Ces informations relatives
à un objet réel sont identifiées dans un bloc de données de la LDM, voir la Figure 7. Chaque bloc de
données de la LDM est identifié par un ID de bloc de données LDM unique; la valeur zéro indique un
«bloc inconnu».
Différentes définitions spatiales et temporelles sont utilisées pour caractériser les fonctionnalités
d’une LDM:
— Définitions liées à l’information sur l’objet réel
— Validité spatiale
Information à la géolocalisation de laquelle où dans la zone géographique de laquelle le LDM-DO
s’applique.
— Validité temporelle
Information dans le ou les intervalles de temps de laquelle le LDM-DO s’applique.
— Horaire de génération
Horaire auquel l’information relative au LDM-DO a été générée, par ex. horaire auquel un système
de détection (par ex. un capteur) a détecté l’événement «route glissante».
— Horaire de suppression obligatoire
Horaire après lequel le bloc de la LDM ne sera plus renvoyé dans une requête.
— Définitions utilisées dans les requêtes
— Zone d’intérêt de la LDM
Géolocalisation(s) ou zone(s) géographique(s) d’intérêt pour le processus d’application ITS-S
émetteur de la requête.
— Temps d’intérêt de la LDM
Temps précis ou intervalle(s) de temps d’intérêt pour le processus d’application ITS-S émetteur de
la requête.
— Âge d’intérêt
10 © ISO 2018 – Tous droits réservés
Âge du bloc de la LDM demandé par le processus d’application ITS-S émetteur de la requête. L’âge
est calculé au moyen d’un opérateur numérique présenté par le processus d’application ITS-S
par rapport à l’horaire de génération d’un LDM-DO, s’il est disponible, ou à défaut, par rapport à
l’horaire de dernière mise à jour d’un LDM-DO.
— Définitions utilisées à des fins de maintenance
— Zone de maintenance de la LDM
Zone(s) géographique(s) prise(s) en considération par la fonctionnalité de recherche de la LDM et
définie(s) par la LDM de manière spécifique à la mise en œuvre. Sans chevauchement entre la zone
d’intérêt de la LDM et la zone de maintenance de la LDM, une requête ne renverra aucun résultat.
Il convient de noter que la zone de maintenance peut être définie en fonction de l’emplacement
temporaire de l’ITS-S hôte.
— Zone inactive de la LDM
Zone(s) géographique(s) prise(s) en considération par la LDM pour stocker les blocs de la LDM non
pris en considération par la fonctionnalité de recherche; il n’y a pas de chevauchement entre la zone
de maintenance de la LDM et la zone inactive de la LDM. La description détaillée de l’utilisation de
la zone inactive de la LDM n’entre pas dans le cadre du présent document.
— Horaire de création
Horaire auquel le bloc de la LDM a été créé dans l’espace de stockage de données de la LDM.
— Horaire de suppression
Horaire après lequel un bloc de la LDM peut être supprimé et ne sera plus pris en considération par
la fonctionnalité de recherche de la LDM.
Plusieurs systèmes de référence spatiale (localisation) et de référence temporelle sont connus. L’Annex D
et l’Annex E en présentent des exemples. Ce document supporte tout type de système de référence en
définissant la référence temporelle et la référence spatiale avec le type ASN.1 CLASS permettant de
définir ultérieurement des instanciations spécifiques en fonction des besoins des services C-ITS. La
démarche générique applicable à l’emplacement est fournie par le type ASN.1 LDMarea. La démarche
générique applicable au temps est fournie par le type ASN.1 TimeInformation.
Pour gérer le temps, une LDM doit maintenir ou accéder à un système de référence temporelle (horloge).
Ce document suppose qu’un service de référence temporelle de confiance est disponible dans une ITS-
SU, pouvant être utilisé de manière spécifique à la mise en œuvre. La synchronisation temporelle avec
une horloge externe permettant de s’assurer de l’unicité des informations temporelles dans toutes les
[21]
ITS-SU sera à la charge de la gestion ITS-S d’un dispositif ITS-S, conformément à l’ISO 21176 .
De manière similaire, on suppose qu’une LDM a accès à un service fournissant en permanence l’état
cinématique de l’ITS-SU dans laquelle elle réside; ainsi, aucune interface explicite avec ce service n’est
spécifiée dans le présent document.
Vu que ce document supporte différentes architectures de mise en œuvre présentées à la section 5.3, les
processus d’application ITS-S doivent être en mesure de sélectionner les LDM appropriées. À cette fin,
a) Les LDM sont identifiées par un ID de LDM unique dans une ITS-SU
b) Les LDM s’inscrivent auprès de l’entité de gestion ITS-S, signalant leurs capacités en ce qui concerne
les LDM-DO supportés.
c) Les processus d’application ITS-S s’inscrivent auprès de l’entité de gestion ITS-S, signalant leurs
exigences au regard des LDM en ce qui concerne les LDM-DO requis, ce qui est confirmé par la
fou
...
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...