CEN/TS 17466:2020

Intelligent transport systems - Urban ITS - Communication interfaces and profiles for traffic management

This document identifies traffic management interfaces between central stations and specifies related ITS communication profiles enabling standardized data exchange over these communication interfaces, applicable for a variety of platforms including ITS station units (ITS-SUs) compliant with ISO 21217:2014. This document further specifies requirements on encoding of data.
These traffic management interfaces enable
-   the provision of appropriate and relevant traffic information, e.g. congestion and travel times, to users across a variety of platforms;
-   exchange of data such as:
-   network performance data, e.g. traffic conditions, travel times, and
-   planned and unplanned events and incidents, e.g.
-   roadworks,
-   closures of roads, bridges, and tunnels,
-   bad weather,
-   road surface conditions.
This document recognizes specifications from DATEX II in order to avoid duplicate specifications. In doing so, this document aligns with existing products of CEN/TC 278/WG 8 and the additional work being undertaken within the DATEX community.

Intelligente Verkehrssysteme - Verkehrsmanagement-Systeme - TM-Schnittstellen und Informationen

Systèmes de transport intelligents - Systèmes de gestion du trafic - Interfaces et informations sur la MT

Inteligentni transportni sistemi - Mestni ITS - Komunikacijski vmesniki in profili za upravljanje prometa

General Information

• Status: Published
• Publication Date: 05-May-2020
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: CEN/TC 278 - Road transport and traffic telematics
• Drafting Committee: CEN/TC 278/WG 8 - Road traffic data (RTD)
• Current Stage: 9060 - Closure of 2 Year Review Enquiry - Review Enquiry
• Start Date: 02-Dec-2023
• Completion Date: 02-Dec-2023
• Directive: 2010/40/EU - Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport Text with EEA relevance
• Mandate: M/546 - [C(2016)808 Urban ITS (Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport)
• Ref Project: SIST-TS CEN/TS 17466:2020 - Intelligent transport systems - Urban ITS - Communication interfaces and profiles for traffic management

Overview

CEN/TS 17466:2020 - Intelligent transport systems (ITS) - Urban ITS - Communication interfaces and profiles for traffic management - defines traffic management communication interfaces and ITS communication profiles to enable standardized data exchange between central stations and a variety of platforms (including ITS station units compliant with ISO 21217:2014). The Technical Specification covers data encodings and protocol stacks needed to deliver consistent, interoperable urban traffic information such as congestion, travel times, roadworks, closures, weather impacts and other planned or unplanned events.

Key topics and requirements

• Traffic management interfaces: Identification of interfaces between central traffic management stations and external systems or ITS-SUs.
• Data models and encodings: Support and alignment with established models (notably DATEX II) and guidance on XML and JSON encodings, including mapping considerations to avoid duplicate specifications.
• Communication protocols and profiles: Specification of communication protocol stacks and communication profiles (including HTTP, MQTT, AMQP, SOAP, RESTful where applicable) and the concept of hybrid or multi-stack (triple) solutions for robust urban ITS communications.
• API features and operational requirements: Guidance on application programming interfaces for data exchange, filtering, version management and security mechanisms.
• Use cases and operational activities: Defined domains and activities such as status gathering, data retrieval and control relevant to urban traffic management.
• Interoperability emphasis: Alignment with DATEX community outputs and CEN/TC 278/WG 8 to promote reuse and compatibility across vendors and platforms.

Applications and who uses it

CEN/TS 17466:2020 is practical for organizations implementing or integrating urban traffic management and ITS services:

• City transport authorities and traffic control centres - to standardize data sharing with service providers and municipal systems.
• System integrators and ITS solution vendors - to implement compatible communication stacks, encodings and APIs.
• Service providers and data platforms - for publishing travel times, incidents, network performance and event notifications.
• Roadside equipment and vehicle ITS-SU suppliers - to ensure interoperability with urban traffic management systems.
• Software developers and API designers - for building secure, version-managed interfaces and filters for traffic data consumers.

Related standards

• DATEX II (data exchange model) - explicitly referenced and aligned to avoid duplication.
• ISO 21217:2014 (ITS station architecture) - ITS-SU applicability.
• CEN/TC 278 outputs and other ITS protocol and hybrid communication standards referenced for stack and handover considerations.

CEN/TS 17466:2020 is a practical reference for deploying interoperable urban ITS communications, enabling consistent traffic management, standardized data exchange, and improved multi-platform dissemination of traffic information.

Standards Content (Sample)

SLOVENSKI STANDARD
01-julij-2020
Inteligentni transportni sistemi - Mestni ITS - Komunikacijski vmesniki in profili za
upravljanje prometa
Intelligent transport systems - Urban ITS - Communication interfaces and profiles for
traffic management
Intelligente Verkehrssysteme - Verkehrsmanagement-Systeme - TM-Schnittstellen und
Informationen
Systèmes de transport intelligents - Systèmes de gestion du trafic - Interfaces et
informations sur la MT
Ta slovenski standard je istoveten z: CEN/TS 17466:2020
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 17466
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
May 2020
TECHNISCHE SPEZIFIKATION
ICS 03.220.20; 35.240.60
English Version
Intelligent transport systems - Urban ITS - Communication
interfaces and profiles for traffic management
Systèmes de transport intelligents - Systèmes de Intelligente Verkehrssysteme - Verkehrsmanagement-
gestion du trafic - Interfaces et informations sur la MT Systeme - TM-Schnittstellen und Informationen
This Technical Specification (CEN/TS) was approved by CEN on 28 March 2020 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17466:2020 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 8
4 Symbols and abbreviations . 9
5 Traffic management interfaces . 11
5.1 Basics on traffic management . 11
5.2 Basics on interfaces . 11
5.3 Interactions between TM actors . 12
5.4 ITS-S Communication Profiles . 12
6 Use cases . 12
6.1 Domains within traffic management . 12
6.2 Operational activities . 13
6.2.1 Overview . 13
6.2.2 Status gathering . 14
6.2.3 Data retrieval . 14
6.2.4 Control . 14
7 Data and communication protocols . 15
7.1 Data models . 15
7.1.1 DATEX II . 15
7.1.2 OCIT-C . 15
7.1.3 UTMC . 17
7.1.4 DIASER. 18
7.1.5 Other data models . 18
7.2 Mapping data models to communications protocols . 18
8 Application programming interfaces . 19
8.1 Introduction . 19
8.2 Data exchange . 19
8.3 Filtering . 19
8.4 Version management . 20
8.5 Security mechanisms . 20
8.6 ITS-S facilities . 20
8.6.1 HTTP . 20
8.6.2 MQTT . 20
8.6.3 AMQP . 20
8.6.4 SOAP . 20
8.6.5 RESTful . 20
8.7 Communications features . 21
9 Encodings . 22
9.1 Interfaces using XML encoding . 22
9.1.1 Role . 22
9.1.2 XML specification . 22
9.2 Interfaces using JSON encoding . 22
9.2.1 Role . 22
9.2.2 Relation to DATEX II implementations . 23
9.2.3 JSON encoding for xsd data definitions . 23
10 Communication interfaces, triple solutions and communication profiles . 23
10.1 Concept of triple solutions . 23
10.2 Triple solutions for traffic management . 25
10.3 Communication protocol stacks . 25
10.4 Communication profile specifications . 27
Annex A (informative) DATEX - JSON mapping . 28
A.1 Initial developments in the DATEX group . 28
A.2 JSON Schema definition mapping . 28
A.2.1 Introduction. 28
A.2.2 Mapping of “D2Datatype” . 28
A.2.2.1 General . 28
A.2.2.2 Mapping of datatypes table . 29
A.2.2.3 Mapping of datatypes, schemaTypeInclude table . 30
A.2.3 Mapping of “D2Enumeration” and “D2Literal” . 31
A.2.4 Mapping of “D2Enumeration” and “D2Literal” . 32
A.2.5 Mapping of “D2Class” . 33
A.2.5.1 General . 33
A.2.5.2 “D2Class” classes without superclass . 33
A.2.5.3 “D2Class” classes with superclass. 35
A.2.5.4 “D2Class” classes which are superclasses. 36
A.2.6 Mapping of “D2Identifiable” and “D2VersionedIdentifiable” classes . 36
A.2.7 Root instances . 38

A.2.8 Extension mapping . 38
A.2.8.1 General . 38
A.2.8.2 Extension mapping for Classes . 38
A.2.8.3 Extension mapping for Enumerations . 39
A.2.9 Overall document structure and namespaces . 39
Bibliography . 41

European foreword
This document (CEN/TS 17466:2020) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
General deployment of Intelligent Transport Systems (ITS) in the field of road transport and for interfaces
with other modes of transport is demanded by the Directive 2010/40/EU [3] of the European Parliament.
ITS means “applying information technology and communications technology (ICT) for improving traffic,
especially road traffic”.
Urban Intelligent Transport Systems (U-ITS) is a term indicating the provisioning of ITS services applying
ITS technologies in an urban context. Development of standards dedicated to U-ITS is supported by the
European Commission's mandate M/546 [2] with technical details identified in the final report [1] of
project team PT1701. U-ITS standards will complement those for cooperative ITS (C-ITS) developed
under the European Commission's mandate M/453, see [4].
NOTE Basic ITS technologies applied for U-ITS can be the same as those applied for C-ITS.
Provisioning of ITS services typically may require communications between ITS station units (ITS-SU)
specified in ISO 21217:2014. Diverging requirements for communications and limitations of capabilities
of available communication channels led to the concept of Hybrid Communications providing multiple
communication protocol stacks with different access technologies and communications protocols for
localized communications and networked communications together with the capability of handover,
specified in a series of standards, e.g. ISO 21217:2014, ISO 21218 [30], EN ISO 17423 [20], ISO 24102-6
[31], ISO 21215 [29], ISO 17515-3 [22], ISO 21210 [28], ISO 29281-1 [32], and others.
A major characteristic of C-ITS is the sharing of data between ITS applications in the same ITS-SU and in
different ITS-SUs. A major service domain of C-ITS is the domain of road safety and traffic efficiency, with
a certain focus on wireless communications between ITS-SUs installed in vehicles, also referred to as
Vehicle ITS-SU (V-ITS-SU), and wireless communications between V-ITS-SUs and ITS-SUs installed at the
roadside, also referred to as Roadside ITS-SU (R-ITS-SU).
Although there are differences between U-ITS and C-ITS with respect of target service domains (data and
procedures necessary for the provisioning of dedicated urban ITS services), data and procedures
developed for C-ITS might also be beneficially applied in U-ITS.
Whilst C-ITS currently largely focuses on the road safety domain, U-ITS deals with the ITS service
domains
— Multimodal Information Systems;
— Traffic Management;
— Urban Logistics;
see [1].
A major goal to be achieved with U-ITS standards is to assist urban administration to implement U-ITS,
and removing barriers for implementing U-ITS, see CEN/TR 17143 [1].
A precise definition of the borderline between U-ITS and ITS for other target domains, e.g. ITS on
highways, is impossible. However, this document aims on identifying and specifying ITS issues that are
relevant for urban administrations. It is important to understand that ITS issues developed for urban
areas also may be applicable outside of urban areas.
Development of standards for U-ITS has to consider automated and autonomous vehicles [1], and the
work on data and message specifications performed under the name of DATEX for data exchange between
central stations and between a central station and a service provider.
The present document was developed by project team PT1710 funded by the European Commission
under grant agreement SA/CEN/GROW/EFTA/546/2016-10 'Urban ITS Traffic Management data
models' (M/546 [2]). The scope of the present document results from the High Level Recommendation
“1701-HLRd Traffic Management Data Models and interfaces” identified in CEN/TR 17143 [1].
The present document is about communications interfaces and profiles applicable for U-ITS with a focus
on communications between central stations, i.e. Central ITS-SUs (C-ITS-SUs). Such C-ITS-SUs can be part
of e.g. central traffic management centres, centres from authorities, centres from service providers. The
communication profile definitions presented in this document are based on the methodology being
specified in ISO/TS 21185.
Data definitions are outside the scope of this document and are developed within other PTs funded under
M/546 [2].
1 Scope
This document identifies traffic management interfaces between central stations and specifies related
ITS communication profiles enabling standardized data exchange over these communication interfaces,
applicable for a variety of platforms including ITS station units (ITS-SUs) compliant with ISO 21217:2014.
This document further specifies requirements on encoding of data.
These traffic management interfaces enable
— the provision of appropriate and relevant traffic information, e.g. congestion and travel times, to
users across a variety of platforms;
— exchange of data such as:
— network performance data, e.g. traffic conditions, travel times, and
— planned and unplanned events and incidents, e.g.
— roadworks,
— closures of roads, bridges, and tunnels,
— bad weather,
— road surface conditions.
This document recognizes specifications from DATEX II in order to avoid duplicate specifications. In
doing so, this document aligns with existing products of CEN/TC 278/WG 8 and the additional work being
undertaken within the DATEX community.
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/TS 21177, Intelligent transport systems — ITS station security services for secure session establishment
and authentication between trusted devices
ISO/TS 21185, Intelligent transport systems — Communication profiles for secure connections between
trusted devices
ISO 21217:2014, Intelligent transport systems — Communications access for land mobiles (CALM) —
Architecture
EN 16157-1:2018, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 1: Context and framework
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:
— ISO Online browsing platform: available at https://www.iso.org/obp/ui
— IEC Electropedia: available at http://www.electropedia.org/
3.1
interface
point of demarcation between two entities through which information flows from one entity to the other
entity based on a given specification of technical details
3.2
logical interface
interface where the semantic, syntactic, and symbolic attributes of information flows is defined
3.3
physical interface
interface where the physical characteristics of signals used to represent information and the physical
characteristics of channels used to carry the signals are defined
3.4
service interface
interface where the set of interactions provided by an entity for participation with another entity for
some purpose along with constraints on how they can occur are defined
3.5
management service interface
service interface that exposes management functions of a service function contained in a component for
use by service consumers
[SOURCE: ISO 18202:2015, 1.4.7 - modified]
3.6
user interface
interface between a user and an interactive system that provides information and controls for the user
to accomplish specific tasks with the interactive system
[SOURCE: ISO/IEC 25063:2014, 3.18 - modified]
3.7
ITS service
functionality provided to users of intelligent transport systems designed e.g. to increase safety,
sustainability, efficiency, or comfort
[SOURCE: ISO 21217:2014, definition 3.11]
3.8
ITS application
instantiation of an ITS service that involves an association of two or more complementary ITS-S
application processes
[SOURCE: ISO 21217:2014, definition 3.9]
3.9
ITS-S application process
element in an ITS station that performs information processing for a particular application and uses ITS-
S services to transmit and receive information
[SOURCE: ISO 21217:2014, definition 3.19]
3.10
ITS-S service
communication functionality of an ITS-S that provides the capability to connect to other nodes
[SOURCE: ISO 21217:2014, definition 3.37]
3.11
ITS station
functional entity comprised of an ITS-S facilities layer, ITS-S networking and transport layer, ITS-S access
layer, ITS-S management entity, ITS-S security entity, and ITS-S applications entity providing ITS services
Note 1 to entry: From an abstract point of view, the term “ITS station” refers to a set of functionalities. The term
is often used to refer to an instantiation of these functionalities in a physical unit. Often, the appropriate
interpretation is obvious from the context. The proper name of the physical instantiation of an ITS-S is ITS station
unit (ITS-SU).
[SOURCE: ISO 21217:2014, definition 3.12]
3.12
ITS-S-secured
secured in compliance with ISO 21217:2014
4 Symbols and abbreviations
AMQP advanced message queuing protocol
ANPR automatic number plate recognition
API application programming interface
ASN abstract syntax notation
CAM cooperative awareness message
CCTV closed circuit television
C-ITS cooperative ITS
C-ITS-SU central ITS-SU
DATEX data exchange
DENM decentralized environmental notification message
DIASER dialogue standard pour les équipements de régulation
DSRC dedicated short range communications
NOTE 1 DSRC as specified in EN 12253 (5,8 GHz backscatter technology)
NOTE 2 In the United States of America, the term DSRC is used for IEEE 802.11 OCB
communications at 5,9 GHz. In order to distinguish both technologies, the US
understanding is referred to as US-DSRC.
DTS draft TS
EN European norm
EU European Union
HARTS harmonized architecture reference for technical standards
HTTP hypertext transfer protocol
ICT information and communication technology
IP Internet protocol
IPv6 IP version 6
IR infrared
ITS intelligent transport systems
ITS-S ITS station
ITS-SCP ITS-S communication profile
ITS-SCPS ITS-S communication protocol stack
ITS-SU ITS station unit
JSON Java script object notation
LAN local area network
LoS Level of Service
MQTT message queuing telemetry transport
NTCIP national transportation communications for ITS protocol
OCIT open communication interface for road traffic control systems
OCIT-C OCIT centre to centre
OCIT-O OCIT outstations
OID object identifier
PER packed encoding rules
PT project team
REST representational state transfer
RESTful REST implemented by using HTTP
RFC request for comments
SIRI service interface for real-time information
SNMP simple network management protocol
SOAP simple object access protocol
SPaT signal phase and timing
TCP transmission control protocol
TM traffic management
TMC TM centre
TMDD TM data dictionary
TC technical committee
TLS transport layer security
TR technical report
TS technical specification
UML unified modelling language
UPER unaligned PER
URL uniform resource locator
UTC urban traffic control
UTMC urban traffic management and control
U-ITS urban ITS
VMS variable message sign
WG working group
WWW world wide web
XSD XML schema definition
XDR external data representation
XML extensible markup language
5 Traffic management interfaces
5.1 Basics on traffic management
“Traffic management” (TM), in the context of this document, is a term pointing to a class of ITS services
that aim on managing road traffic, including urban areas, including not just vehicles, motor-cycles, and
bicycles but also e.g. pedestrians and rail vehicles such as trams. TM interfaces exist between these actors
in TM. TM interfaces are needed for the purpose to manage the operation of TM services.
5.2 Basics on interfaces
The term “interface” has the generic meaning of a “point of demarcation between two entities”, although
originally it comes from natural science with a different meaning.
In the context of information and communications technologies (ICT), many complementary definitions
exist, distinguished by a qualifier added to the term, e.g. “physical interface”, “communications protocol
interface”, “application interface”. The communications protocol interface and the application interface
are examples of logical interfaces. The physical interface together with the communications protocol
interface define an ITS-S Communication Protocol Stack (ITS-SCPS).
NOTE 1 Typically, an ITS-SCPS includes, as a minimum, protocols from the ISO/OSI layers one through four (ITS-
S access layer and ITS-S networking and transport layer specified in ISO 21217:2014), optionally also the layers five
through seven (ITS-S facilities layer specified in ISO 21217:2014); see also the definition of ITS-SCPS in ISO 17423
[20].
Adding the application interface, typically an Application Programming Interface (API) provided by the
ISO/OSI application layer which is part of the ITS-S facilities layer, for TM results in a complete TM
communication interface.
NOTE 2 The term “Intelligent Transport Systems” (ITS) means applying ICT in the transport domain.
Thus, for the purpose in ITS, a more precise general definition applies, i.e.:
— “point of demarcation between two entities through which information flows from one entity to the
other entity based on a given specification of technical details”.
5.3 Interactions between TM actors
These entities on the two sides of the point of demarcation, see 5.2, can be referred to as TM actors.
NOTE A TM actor can be e.g. a field device, a functionality in a central station, a functionality in a service
provider's station, an application in a mobile station of a road user, a road user, an operator of a TM system.
From the point of view of TM applications and services, different types of TM actors and TM interfaces
can be distinguished, e.g. for exchange of information:
a) between TM centres;
b) between a TM centre and TM service providers;
c) between a TM centre and its operator;
d) between a TM centre and its field devices (beyond scope of this document);
e) between a TM centre and road users (beyond scope of this document);
f) between a TM service provider and road users (beyond scope of this document).
Exchange of information between TM actors basically can be with any technology, e.g. speaking, writing,
optical signs, including ICT. However, applying ICT leads to TM communication interfaces in the strict
sense used in this document.
5.4 ITS-S Communication Profiles
This document is restricted to interfaces between application functionalities in central stations, and
between a central station and a service provider's station. Other interfaces are out of scope of this
document. More precisely, this document is restricted to communication interfaces and respective ITS-S
Communication Profiles (ITS-SCPs) using wired or wireless communications between central stations.
Specification of ITS-SCPs uses the methodology specified in ISO/TS 21185, and by this complements the
definitions of ITS-SCPs provided there.
More details on ITS-SCPs are presented in Clause 10.
6 Use cases
6.1 Domains within traffic management
This specification considers use cases from different domains within traffic management:
— Intersection control data includes operational information such as equipment faults and status
history as well as information related directly to traffic control such as measurement values and
signalling status data.
— Network traffic control focuses on network wide information. Additional measurements include
strategic information such as speed and saturation on important links as well as area control
information often in the form of signal plan selection or appropriate parametrization of the traffic
control algorithms.
— Situations and strategies allow operators to transmit descriptions and attributes of specific traffic
situations. This could include sporting events or concerts but also recurring traffic invents i.e. the
blockage of important arteries. Appropriate traffic control strategies are then communicated and
deployed to handle these events.
— Traffic messages aim at road users to transport information related to the traffic network such as
construction sites, accidents or other incidents.
— Traffic data include both measurement values as well as derived data from various sensing a
detection equipment.
— Parking data includes information relating to parking facilities. Typical data includes name,
position, occupancy, free space, trends and status.
— Weather and environmental information can use data relating to an “Air Quality Measurement
System”, see CEN/TS 17378:2019 [17]) covering not only the measured data but also static
information like sensor type and position. It also includes data linked to the traffic infrastructure like
properties of the road surface (wet, frozen). In addition, weather information from instances such as
meteorological services can be taken into TM systems.
— Video systems require not only the control of video cameras, but also the transmission of media
streams. This puts a quite different set of requirements on systems being able to cope with this.
— Operational messages include messages relating to failures, recovery or status change of
infrastructure equipment. Various types of equipment can still share a common subset of messages.
— Variable message sign control requires data to transmit commands to control signs. These can
include segment- as well as full matrix displays.
— Public transport information covers different types of data relating to passengers, vehicles,
schedules and various other elements of public transport. Different types of information have
different requirements concerning latency and freshness.
6.2 Operational activities
6.2.1 Overview
The use cases cover the following operational activities:
— Status gathering: This includes all cases, when one authority needs to access the status of the traffic
equipment in another city. Examples include information about the failure state of equipment or the
current performance level.
— Data retrieval: In addition to the status gathering, the data retrieval use cases include historical data
such as traffic flows or occupancy of parking facilities.
— Control actions: In contrast to the more informational character of reading status or historical data,
control actions have additional requirements relating to authorization of actions and
recording/auditing of events.
NOTE For the purpose of this document, it is assumed that all information is retrieved from central stations
rather than directly from field devices.
6.2.2 Status gathering
The following use cases highlight different aspects, each of which requires a solution in the context of this
technical specification.
City to city – allow the authority of the one city to retrieve a status information from another city. An
example would be two neighbouring cities wanting to establish a cooperative traffic management
solution. This could include situations, where one authority has to agree to route some traffic across its
infrastructure. Some kind of regulation and agreement is required to organize this procedure.
Basic procedure includes: if two cities or a city and an agglomerate organization want to cooperate, they
need to agree on access rights for information.
— Timeliness of information – how old is the data. This could be either restricting the age of data being
provided and stored or limiting the access to current information. Technical constraints could limit
the storage capacity for historic data, or the ability to give immediate access to the latest information.
— Quality of service – how often is the user allowed to exchange the information, and/or how much
information can be exchanged at once. This is to keep the system load under control.
6.2.3 Data retrieval
Similar considerations as the status gathering activities apply for the data retrieval. This covers dynamic
data, such as detector measurement values. Different aspects relating to retrieving the data have to be
considered
— The authority to access the individual data points has to be given as the example in 0 illustrates.
— Maximum/minimum age of data affects the freshness of data or the maximum storage capacity of the
system.
— Resolution (time interval for detector series, accuracy for measurements) is relevant for bandwidth
and storage capacities.
— The maximum bandwidth granted affects the dimensioning of the system and the underlying
network infrastructure. Such consideration also have a major impact on economic factors during
system operations.
Concerning the data itself, some restrictions also apply. The data can be bound to a specific licensing
agreement limiting the usage possibility to aggregate or resell data.
If the data provided touches on privacy issues (which could be the case for certain types of travel data
such as data based on automatic number plate recognition or video data), current regulations such as
GDPR (EU) 2016/679 [5] may have to be considered.
6.2.4 Control
A regional traffic management system might cover several cities’ traffic management systems. An
authority might then grant the right to exercise control over traffic within certain limits such as switching
to a traffic signal plan being more appropriate for the traffic volume. Another example would be the
blocking of certain routes based on environmental data.
Authority and authentication is required as in the cases mentioned in 6.2.3. Certain types of control
actions must be granted/restricted for certain actors.
In the case of different actors with potentially having an influence on the state of one single controlled
object, it might be required, to assign different priorities to different actors such as the police, a
neighbouring city, the operators on site or an automatic system (adaptive network control system), giving
precedence to the request of the actor with highest priority
For traffic control, it is also required, that a certified documentation of control actions exists in the form
of reliable logs.
Apart from technical considerations, organizational measures are in place to handle organizational
issues. Such processes cover reporting, escalation procedures, handling of emergencies and the
moderation / settlement of disputes. Such processes though exceed the scope of this document, since
their focus is on organization more than technical issues.
7 Data and communication protocols
7.1 Data models
7.1.1 DATEX II
DATEX II defines a standardized formal structure for data exchange between road operators, and
between road operators and service providers.
Mainly it is a set of data definitions specified with the “Unified Modeling Language” (UML) and typically
encoded in the “extensible markup language” (XML). Six Technical Specifications CEN/TS 16157 from
CEN provide DATEX II specifications for Version 2.3;
1)   Context and framework; see CEN/TS 16157-1 [8];
2)   Location referencing; see CEN/TS 16157-2 [9];
3)   Situation publication; see CEN/TS 16157-3 [10];
4)   Variable message sign (VMS) publications; see CEN/TS 16157-4 [11];
5)   Measured and elaborated data publications; see CEN/TS 16157-5 [12];
6)   Parking publications; see CEN/TS 16157-6.
Currently DATEX II Version 3.0 is under development to be standardized in a series of CEN European
Norms constituting upgrades of CEN/TS 16157 to EN 16157, and aiming on further standards, e.g.
7)   Common data elements;
see EN 16157-1:2018, CEN/TS 16157-2 [9], CEN/TS 16157-3 [10], EN 16157-7 [13].
DATEX II, as the name says, also deals with data exchange. To enable a flexible use of the data part of
DATEX II, independent from the technology used to exchange this information, a definite split between
the data laid down in Version 3 and DATEX II exchange is made. DATEX II exchange is going to be
standardized jointly by CEN TC278 and ISO TC204, because of similar activities in Japan and the USA.
7.1.2 OCIT-C
OCIT-C is an application layer protocol to implement centre-to-centre communication integrating
different domains of traffic management such as traffic planning and control, parking, environmental data
and others. It is based on SOAP and available as DIN VDE-V 0832-601 [49] and DIN VDE-V-0832-602 [50].
OCIT-C data models consist of generic information each element potentially contains. This includes an
identification information (id, name and description), related objects, type information, location data and
specific additional information.
All data elements are modelled using XSDs.
Data elements cover the following areas:
— Traffic messages to transport messages related to construction sites, events and incidents.
— Traffic data related to detectors. This information can be either raw data or calculated data
originating from a group of detectors. Aggregation can be temporal or spatial for road sections, areas
and routes.
— Parking data includes a static description of the parking installation (facility, district or area) as well
as dynamic information such as occupancy and trend data.
— Weather and environmental information.
— CCTV control information includes static descriptive data, image information as well as the
possibility to issue pan-tilt-zoom commands.
— Strategy and situation includes a module to issue strategical control commands on detection of traffic
situations.
— Operating messages allow the transmission of operational information. These messages are
structured according to the category of the affected subsystem, the severity of the incident or
message identifies and supplemental information.
— Variable message signs include the nominal state, the actual state and control commands.
— Traffic light controller related information relating to the state of the TLC. Included is also the
possibility to issue commands and to read signal phase and timing information.
— Car2X related information includes possibilities to transmit measurement information obtained
from C-ITS enabled vehicles covering the areas Priorization, DENM, CAM, SPAT and MAP.
OCIT-C’s transport protocol is SOAP based. Data are transmitted using XML. An authentication based
security mechanism is implemented. The protocol offers an API to read and configure data as well as
sending commands. Methods are implemented by a request/response pattern.
Protocol methods are:
— put to configure objects,
— get to read changes of data,
— inquireAll to read all data,
— delete to delete dynamic data,
— getContentInfo to read object content,
— wait4Get for an asynchronous communication channel to offer notifications.
7.1.3 UTMC
UTMC was created in the early 1990s by the UK Department for Transport to create a framework for the
use of “modern” ICT in urban traffic management. Determining that an open technical standard was
required, the initiative published the first draft UTMC Technical Specification in 1997
...