CEN/TS 17402:2020

SLOVENSKI STANDARD
01-junij-2020
Inteligentni transportni sistemi - Mestni ITS - Uporaba regionalnih prometnih
standardov v mešanem prodajnem okolju
Intelligent transport systems - Urban ITS - Use of regional traffic standards in a mixed
vendor environment
Intelligente Transportsysteme - Urbane Verkehrssysteme - Verwendung regionaler
herstellerspezifischer Normen und Spezifikationen
Systèmes de transport intelligents - STI urbain - Utilisation des normes de trafic
régionales dans un environnement mixte
Ta slovenski standard je istoveten z: CEN/TS 17402:2020
ICS:
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 17402
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Intelligent transport systems - Urban ITS - Use of regional
traffic standards in a mixed vendor environment
Systèmes de transport intelligents - ITS urbain - Intelligente Transportsysteme - Urbane
Utilisation des normes de trafic régionales dans un Verkehrssysteme - Verwendung regionaler
environnement mixte herstellerspezifischer Normen und Spezifikationen
This Technical Specification (CEN/TS) was approved by CEN on 29 December 2019 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 17402: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 . 10
4 Symbols and abbreviations . 12
5 Requirements . 14
6 Context . 14
6.1 Background . 14
6.2 Interoperability requirements in the traffic management domain. 14
6.3 Communication standards for traffic management . 15
7 Data model requirements . 22
7.1 General . 22
7.2 DATEX II . 22
7.3 Use-case specific data model requirements . 25
7.4 NTCIP . 28
8 Open specifications for sensor systems . 29
8.1 Introduction . 29
8.2 Existing open specifications . 29
9 Open specifications for traffic control . 30
9.1 Introduction . 30
9.2 Existing open specifications . 31
10 Open specifications for traffic information . 37
10.1 Introduction . 37
10.2 Existing open specifications . 37
11 Open specifications for public transport information systems. 38
11.1 Introduction . 38
11.2 Existing open specifications . 38
12 Open specifications for distributed C-ITS . 42
12.1 Distributed C-ITS via a secured ITS domain . 42
12.2 Existing open specifications . 43
13 Open specifications for central systems . 46
13.1 Transmodel and related standards for public transport . 46
13.2 TPEG . 46
13.3 OCIT-C . 47
13.4 UTMC . 48
13.5 NTCIP . 49
14 Openly plied proprietary standards . 49
14.1 Introduction . 49
14.2 General transit feed specification (GTFS) . 49
14.3 JAVA . 50
14.4 Bluetooth . 51
14.5 Common specification . 52
Annex A (informative) NTCIP . 53
A.1 Background . 53
A.2 NTCIP Standards Framework . 53
A.3 NTCIP Communications Standards. 55
Annex B (informative) Traffic signal controller interface . 60
B.1 Background . 60
B.2 Implementation and usage . 61
B.3 Data model . 63
B.4 Data Dictionary for TrafficSignalStatusPublication . 65
B.5 Data Dictionary of < > for TrafficSignalStatusPublication . 70
B.6 XSD . 74
Bibliography . 100

European foreword
This document (CEN/TS 17402: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.
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
The standard deliverables “Mixed Vendor Environment Guide” CEN/TR 17401, “Mixed vendor
environments methodologies & translators” CEN/TS 17400, and this document provide a suite of
standards designed to achieve successful implementation of “Urban-Intelligent Transport Systems” (U-
ITS) in a mixed vendor environment.
This suite of standards supports the family of existent standards, referencing both common
communications protocols and data definitions, that, in combinations, enable Urban-ITS (and ITS in
general) to function and be managed, and will reference application standards, and their
interdependencies and relationships.
Urban authorities use an increasing array of ITS implementations to deliver their services. Historically,
urban ITS implementations have tended to be single solutions provided to a clear requirements
specification by a single supplier. Increasingly, as ITS opportunities become more complex and varied,
they involve the integration of multiple products from different vendors, procured at different times and
integrated by the urban authority.
The need for a mixture of systems provided by different manufacturers to so-called “Mixed Vendor
Environments” (MVEs) is a growing paradigm, which results primarily from the demand for the
introduction of competition in the context of public tenders, and the increasing networking of existing
stand-alone solutions to address complex traffic management systems.
The mix of systems of different manufacturers is also, in part, a result from technological changes.
Established companies are suddenly in competition with new companies that exploit technological
changes and offer exclusively, or at a reasonable price, new or improved functionality for sub-systems.
However, ITS design is often proprietary and, as a consequence, integration and interoperability can be
difficult, time-consuming, and expensive, limiting the ability of urban authorities to deploy innovative
solutions to transport problems. In some member states of the European Union, national/regional
solutions to this problem have been created, and there are also some solutions in specific domains, which
have been very beneficial. However, these are not uniform across the EU, compromising the efficiency of
the single market.
This document focuses specifically on the area of traffic management systems in an MVE, identifies
appropriate standards to use to enable an MVE, and addresses aspects associated with the
accommodation of regional traffic standards in such mixed vendor environments, with particular
emphasis on the centre/field systems context. This document also provides information regarding MVE
provisions in the public transport domain.
This document should be read together with CEN/TR 17401, which provides a ‘Guide’ giving a high level
introduction into the “Concept of Operations” (CONOPS) for MVEs; provides a high-level architectural
context explanation of an MVE and its operational requirements, and describes the problems and effects
that are associated with vendor lock-in. It also provides a systematic approach for many aspects of U-ITS
implementations, and indeed almost all ITS MVE implementations; and provides a methodical guideline
with a procedural model, in order to provide assistance to implementers and managers involved with the
structure of an MVE and/or with the removal of vendor lock-in.
This document should also be considered together with CEN/TS 17400, which provides the
methodologies and translators to avoid vendor lock-in, introducing suitable methodologies for system
architecture design, making appropriate use of standards, and specifications to be used when translator
systems are adopted.
Over many decades, regional traffic interface standards have evolved and been implemented around
Europe. Implemented, they cannot be replaced in the near term. This document is designed to show how
they can operate, co-exist and evolve in an MVE over time.
This document also describes the major existing regional traffic standards established in Europe, such as
OCIT, UTMC, DVM/IVERA, and the data exchange provisions provided in the DATEX II series of standards,
and how these regional traffic standards and DATEX II are used in MVE or to avoid vendor lock-in. This
document recognizes that there are other implemented local traffic management standards and is
designed to enable them to also seek to achieve an MVE accommodation path.
The organization of the deliverable is based on functionality, and will provide framework overviews, and
minimum system requirements for ITS service provision in the context of regional traffic standards MVEs.
1 Scope
This document provides a background to the relevance of standards concerning mixed vendor
environments in the context of urban-ITS. It describes key mixed vendor environments interfaces.
It identifies existing open specifications for
— sensor systems;
— traffic control;
— traffic information;
— public transport information;
— distributed C-ITS;
— central systems.
It provides common specifications of
— sensor systems;
— traffic control;
— traffic information;
— public transport information;
— distributed C-ITS;
— central systems.
It describes openly plied proprietary standards and extant communications protocols that can be used in
mixed vendor environments in the context of U-ITS.
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.
EN 12896 (all parts), Public transport - Reference data model
EN 12966, Road vertical signs - Variable message traffic signs
EN 13149 (all parts), Public transport - Road vehicle scheduling and control systems
EN 15509, Electronic fee collection - Interoperability application profile for DSRC
CEN/TS 15531 (all parts), Public transport - Service interface for real-time information relating to public
transport operations
CEN/TS 16157 (all parts), Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information
CEN/TS 16614 (all parts), Public transport - Network and Timetable Exchange (NeTEx)
EN ISO 17419, Intelligent transport systems - Cooperative systems - Globally unique identification (ISO
17419:2018)
EN ISO 18750:2018, Intelligent transport systems - Co-operative ITS - Local dynamic map (ISO 18750:2018)
CEN ISO/TS 19321:2015, Intelligent transport systems — Cooperative ITS — Dictionary of in-vehicle
information (IVI) data structures
CEN/TS 17380, Intelligent transport systems - Urban-ITS - 'Controlled Zone' management for UVARs using
C-ITS
CEN/TS 17400:2020, Intelligent Transport Systems – Urban-ITS – Mixed vendor environments
methodologies & translators
CEN/TR 17401:2020, Intelligent Transport Systems – Urban-ITS – Mixed Vendor Environment Guide
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO/TS 16460:2018, Intelligent transport systems — Communications access for land mobiles (CALM) —
Communication protocol messages for global usage
ISO 17572-2, Intelligent transport systems (ITS) — Location referencing for geographic databases — Part
2: Pre-coded location references (pre-coded profile)
ISO 17572-3, Intelligent transport systems (ITS) — Location referencing for geographic databases — Part
3: Dynamic location references (dynamic profile)
ISO/TS 19091, Intelligent transport systems — Cooperative ITS — Using V2I and I2V communications for
applications related to signalized intersections
ISO 20684 (all parts), Intelligent transport systems — Roadside modules SNMP data interface
ISO/TS 21177, Intelligent transport systems – ITS-station security services for secure session establishment
and authentication between trusted devices
ISO/TS 21184, Intelligent transport systems – Management of messages containing information of sensor
and control networks specified in data dictionaries
ISO 21210, Intelligent transport systems — Communications access for land mobiles (CALM) — IPv6
Networking
ISO 21215:2018, Intelligent transport systems — Localized communications — ITS-M5
ISO 21217:2014, Intelligent transport systems — Communications access for land mobiles (CALM) —
Architecture
ISO/TS 21219 (all parts), Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2)
ISO 22418:2018, Intelligent transport systems — Fast service announcement protocol (FSAP)
ISO 24532, Intelligent transport systems — Systems architecture, taxonomy and terminology — Using
CORBA (Common Object Request Broker Architecture) in ITS Standards, data registries and data
dictionaries
ISO 29281-1:2018, Intelligent transport systems — Localized communications — Part 1: Fast networking
& transport layer protocol (FNTP)
ETSI TS 102 687 (2011-07), Intelligent Transport Systems (ITS); Decentralized Congestion Control
Mechanisms for Intelligent Transport Systems operating in the 5 GHz range; Access layer part
ETSI TS 102 724 (2011-07), Intelligent Transport Systems (ITS); Harmonized Channel Specifications for
Intelligent Transport Systems operating in the 5 GHz frequency band
ETSI TS 102 792 (2015-06), Intelligent Transport Systems (ITS); Mitigation techniques to avoid
interference between European CEN Dedicated Short Range Communication (CEN DSRC) equipment and
Intelligent Transport Systems (ITS) operating in the 5 GHz frequency range
ETSI TS 103 097 (2017-10), Intelligent Transport Systems (ITS); Security; Security header and certificate
formats
ETSI EN 302-637-2:2014-09, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Part 2: Specification of Cooperative Awareness Basic Service
ETSI EN 302-637-3:2014-09, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service
IEEE Std 802.11™, IEEE Standard for Information technology–Telecommunications and information
exchange between systems Local and metropolitan area networks–Specific requirements - Part 11: Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications
SAE J2735, Dedicated Short Range Communications (DSRC) Message Set Dictionary
SAE J2945/1, On-Board System Requirements for V2V Safety Communications
ITU-T E.163, Numbering plan for the international telephone service
ITU-T E.164 (all parts), The international public telecommunication numbering plan
IEC 60870-5-101, Transmission Protocols - companion standards especially for basic telecontrol tasks
ISO/IEC 18000, Information technology — Radio frequency identification for item management
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modeling
Language (UML) Version 1.4.2
IETF RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP)
Management Frameworks
IETF RFC 3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
IETF RFC 3413, Simple Network Management Protocol (SNMP) Applications
IETF RFC 3414, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol
(SNMPv3)
IETF RFC 3415, View-based Access Control Model (VACM) for the Simple Network Management Protocol
(SNMP)
IETF RFC 3416, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
IETF RFC 3417, Transport Mappings for the Simple Network Management Protocol (SNMP)
IETF RFC 3418, Management Information Base (MIB) for the Simple Network Management Protocol
(SNMP)
NF P 99071-1 (septembre 2002): Régulation du trafic routier par feux de circulation - Spécification du
dialogue standard des équipements de régulation de trafic - Diaser
RTIGT008, Radio Link Specification for RTI-driven Traffic Light Priority and Display Clear down
RTIGT030, Digital Air Interface Protocol
RTIGT031, Centre-to-centre traffic signal priority request protocol
RTIGT035, Language and terminology in Real Time Information systems
RTIGT036, Additional information on RTI signs
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21217:2014 and the following
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 http://www.iso.org/obp
3.1
Demand Responsive Transit
form of transport where vehicles alter their routes based on particular transport demand rather than
using a fixed route or timetable; vehicles typically pick-up and drop-off passengers in locations according
to passengers needs
3.2
hybrid communications
simultaneous operation of various communication technologies or operation via a choice from more than
one available communication medium dependent on application requirements and applicable regional
regulations and specifications
3.3
inter-green interlock
functionality within a signal controller that prevents traffic on conflicting paths through a junction from
being assigned a green phase simultaneously
3.4
ITS-S access layer
protocol layer in the ITS-S reference architecture containing the OSI physical and data link layer protocols
for ITS communications
[SOURCE: ISO 21217]
3.5
ITS-S facilities layer
layer in the ITS-S reference architecture containing OSI layers 5, 6, and 7 that connects applications to
the ITS-S networking and transport layer
[SOURCE: ISO 21217]
3.6
ITS-S networking and transport layer
layer in the ITS-S reference architecture containing OSI layers 3 and 4 that connects the ITS-S facilities
layer to the ITS-S access layer
[SOURCE: ISO 21217]
3.7
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]
3.8
ITS station unit
implementation of an ITS-S
[SOURCE: ISO 21217]
3.9
local dynamic map
data storage for location- and time-referenced data providing query mechanisms
3.10
outstation
roadside equipment for traffic management which communicates with a traffic management centre; also
referred to as field-device
3.11
secured ITS domain
network of communication nodes applying the ITS station architecture specified in ISO 21217
[SOURCE: ISO 21217]
3.12
transmodel
abstract model of common public transport concepts and data structures that can be used to build many
different kinds of public transport information system, including timetabling, fares, operational
management, real time data, journey planning etc
3.13
transponder
device which responds to the receipt of a specified signal by responding with its identity and sometimes
additional information
Note 1 to entry: Passive transponders achieve this by backscatter techniques using the transmitted energy to
power their circuits and return the signal, sometimes using batteries to assist this process.
Note 2 to entry: Active transponders act as full transceivers.
4 Symbols and abbreviations
2G Second generation of cellular networks
3G Third generation of cellular networks
4G Fourth generation of cellular networks
AES Advanced Encryption Standard
ANPR Automatic Number Plate Recognition
API Application Programming Interface
ASN.1 Abstract Syntax Notation 1
BLE Bluetooth Low Energy
BTPPL Basic Transport Protocol Layer
CAM Cooperative Awareness Message
CCAM Cooperative, Connected and Automated Mobility
CCTV Closed Circuit Television
CORBA Common Object Request Broker Architecture
CZ Controlled Zone
DENM Decentralized Environmental Notification Message
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GTFS General Transit Feed Specification
HARTS Harmonized Architecture Reference for Technical Standards
HTML Hyper Text Markup Language
IFOPT Identification of Fixed objects for Public Transport
IP Internet Protocol
ISM Industrial, Scientific, Medical
ISO International Standards Organization
ITS Intelligent Transport Systems
ITU International Telecommunication Union
JDK JAVA Development Kit
JVM JAVA Virtual Machine
LTE Long Term Evolution
MIB Management Information Base
MOVA Microprocessor Optimized Vehicle Actuation
MVE Mixed Vendor Environment
NEMA National Electrical Manufacturers Association
NTCIP National Transportation Communications for Intelligent Transportation System
Protocol
OCIT Open Communication Interface for Road Traffic Control Systems
ONVIF Open Network Video Interface Forum
OSI Open Systems Interconnection
PSTN Public Switched Telephone Network
PTZ Pan, Tilt and Zoom
RDS-TMC Radio Data System - Traffic Management Channel
RTI Real Time Information
RTIG Real Time Information Group
RTP Real-time Transport Protocol
SCATS Sydney Coordinated Adaptive Traffic System
SCOOT Split Cycle and Offset Optimization Technique
SIG Specialist Interest Group
SIRI Standard Interface for Real-time Information
SNMP Simple Network Management Protocol
SOAP Simple Object Access Protocol
SPaT Signal Phase and Timing
TCP Transmission Control Protocol
TISA Traveller Information Services Association
TMC Traffic Management Centre
TPEG Transport Protocol Experts Group
TPEG Transport Protocol Experts Group
TSS Traffic Signal System
UDP User Datagram Protocol
U-ITS Urban ITS
UML Unified Modelling Lanugage
USDOT United States Department of Transportation
UTMC Urban Traffic Management and Control
VMS Variable Message Sign
WAVE Wireless Access in Vehicular Environments
WSA WAVE Service Advertisement
WSMP WAVE Short Message Protocol
XML Extensible Markup Language
3GPPP Third Generation Partnership Project
5 Requirements
This document pairs communication requirements and data requirements for traffic management
systems with appropriate standards and methodologies.
In order to claim compliance with this specification U-ITS implementations shall use the standards listed
in Clause 2, which are referenced and explained in Clauses 6, 7, 11, 12, 13, in preference to other
specifications covering the same service.
Clauses 8, 9, 10, and 14, and Annex A and Annex B provide informative descriptions.
6 Context
6.1 Background
The context of the provision of MVEs in U-ITS paradigms is described in some detail in CEN/TR 17401,
and the reader of this document is referred to that document for such detail.
6.2 Interoperability requirements in the traffic management domain
Interface requirements for MVEs in ITS are described in CEN/TR 17401 to which the reader is referred
for detail.
In summary, interface requirements for all systems exist at two levels:
a) Communications
b) Data
CEN/TR 17401 identifies typical systems that deliver traffic management as:
— real-time traffic monitoring;
— dynamic message sign monitoring and control;
— incident monitoring;
— traffic camera monitoring and control;
— active traffic management;
— ramp meter monitoring and control;
— arterial management;
— traffic signal monitoring and control;
— road weather information system monitoring;
— highway advisory radio;
— urban traffic management and control;
— traffic optimization;
— speed limit: variable speed limits;
— variable-message signs:
This document pairs communication requirements and data requirements for such systems with
appropriate (regional) standards and methodologies.
— UTMC is a framework of national specifications for traffic management systems, originating in the
UK. The imitative was founded by the UK Government in the early 1990s, but is now managed by an
independent body whose members are urban authorities and system suppliers: the “UTMC
Development Group”. The approach of UTMC is more fully described in CEN/TS 17400; the website
is http://www.utmc.eu.
— The “OCIT Developer Group” is a consortium of signal construction companies, largely focussed in
the German speaking countries of Europe. Their goal is to standardize the most important interfaces
of traffic control. They focus on standardized connections between distributed central and
distributed components, such as sub-systems, tools and field devices. With the use of Internet
technology, they enable the construction of traffic management systems and system-wide networks,
which include field devices and control panels. The OCIT definitions specify system architecture,
rules, OCIT protocols, functions, and transfer protocols. See the OCIT web at [42].
6.3 Communication standards for traffic management
6.3.1 General overview on communication standards
The wide range of technologies and techniques for Traffic management ITS described in this document
make use of a variety of general communications protocols, depending on their need for bandwidth,
latency, security etc. Traditionally, this includes but is not limited to the following wired and wireless
technologies:
— “Public Switched Telephone Network” (PSTN): The technical operation of PSTNs adheres to the
standards created by the ITU-T. These standards allow different networks in different countries to
interconnect seamlessly. The principal standards are ITU-T E.163 and ITU-T E.164.
— Private Wire Circuit: Being a private circuit the protocols can be proprietary, but IEC 60870-5-101 is
very widely used. It provides a 3-layer communications protocol designed primarily to meet the
needs of real-time exchange of data between compute-constrained devices over media-constrained
communication channels (typically less than 1200 bps).
— “Global System for Mobile Communications” (GSM) – widely known as 2G/3G standards, “General
Packet Radio Service” (GPRS) – Mobile communication data service provided by 2G/3G mobile
network operators, and LTE/4G – Packet switched (IP) mobile communication data service provided
by mobile network operators, are based on various releases of 3GPP communication standards: 3GPP
ETSI TS 122 101 [56], 3GPP ETSI TS 124 008 [57], 3GPP ETSI TS 122 003 [58], 3GPP ETSI TS 122
011 [59], 3GPP ETSI TS 127 007 [60], 3GPP ETSI TS 102 164 [61], 3GPP ETSI TS 151 010-1 [62],
3GPP ETSI TS 121 133 [63], 3GPP ETSI TS 122 071 [64].
— Broadband IP addressed circuits.
— Data are packet switched using standard Internet protocols.
— Other wireless radio communications: In the past these systems have largely been proprietary, or
have used standards specific to the radio frequencies used. The most widely used standards are IEEE
Std 802.11™.
The EC's mandate M/453 on Cooperative ITS (C-ITS) [3] and recently technically detailed in the draft C-
ITS Delegated Act [4], C-ITS communication technologies are being utilized and also applicable for U-ITS.
Development of standards for C-ITS started originally in ISO TC204, and was later specialized at ETSI TC
ITS for the service domain of road safety.
As part of the “EU/US Joint Approach towards C-ITS” [2], considerable effort has been made to align the
work of ISO/CEN with the work of IEEE in the USA so that C-ITS systems and WAVE systems can co-exist
and support interoperability modes. They are based on a combination of ISO 21217:2014 and
ISO 21215:2018 (referred to as ‘ITS-M5’), and on the IEEE 1609 series (primarily 1609.2 [39] and 1609.3
[38])/IEEE Std 802.11™ OCB.
Considerable effort has also been made to align the ISO/CEN work on messaging protocols FNTP:
(ISO 29281-1:2018) and service advertisement protocols FSAP: ISO 22418:2018 /ISO/TS 16460:2018)
with WSMP and WSA: (IEEE 1609.3 [38]).
The ETSI work on C-ITS as common roots to the ISO/CEN work, being based on the twin standards
ISO 21217:2014/ ETSI EN 302 665 [23]. The current ETSI profile ETSI EN 302 663 [22] on 5,9 GHz
communications does not specify directly how to use cellular technology, as in hybrid communication
(see below). However, considerable effort has been spent on making messages and protocol functions
bearer independent, so that the hybrid standards from CEN/ISO are directly applicable to most ETSI TC
ITS standards.
Considerable effort has been made recently to align the ETSI work with the security work in IEEE 1609.2
[39], which is now finalised and approved, and the CEN/ISO work with the security work in IEEE 1609.2
[39], which is TS 21177now approved as ISO TS 21177.
There is now one reference communication standard suite for interoperable communications (IEEE Std
802.11™ OCB and its profile standards from ETSI, IEEE and ISO) that ITS-M5/FNTP/FSAP and US
DSRC/WSMP/WSA are based on, even if there are differences remaining at the implementation levels. In
addition, the European and US security provisions (two stage Public Key Infrastructure (PKI) and
conformance assessment) are, although two different standards, implementing the same paradigm.
A basic principle in CEN/ISO C-ITS is “Hybrid Communications”, which enables simultaneous operation
of various communication technologies in a station, e.g. dedicated to the ITS service domain. Recently, in
addition to the above mentioned reference communication standard suite for localized communications
(vehicle-to-vehicle, and vehicle-to-roadside), C-ITS deployment projects now also require Internet
technologies for localized communications.
Details on C-ITS technologies are presented in Clause 12.
Where possible, direct reference to the appropriate protocols has been referenced in the various sections
of this document.
6.3.2 Use-case-specific communication standards
6.3.2.1 Active traffic management
Active traffic management systems are described in CEN/TR 17401, and use a mix of detectors, signals
and VMS with their associated communications standards (see below).
6.3.2.2 Arterial road management
Arterial road management systems are described in CEN/TR 17401.
For appropriate standards, see control zone management below.
6.3.2.3 Control zone management
Management of traffic in a “Controlled Zone” (CZ) are described in CEN/TR 17401.
The principal standard for CZ management is CEN/TS 17380.
6.3.2.4 Dynamic message sign monitoring and control
Variable message sign (VMS) systems are described in CEN/TR 17401.
Technology standards used include TCP / IP, RS485, RS232, GPRS, NTCIP [40], Paknet, NMCS2 and
unspecified licence-free radio.
UTMC includes a specification for a “VMS” object (UC/023) in UML format, and an associated ” Extensible
Markup Language ” (XML) implementation, as well as specific support objects. More recently this has
been adapted towards alignment with DATEX II; a specification document is posted on the UTMC website
as a “proposed addition”. UML is standardized in ISO/IEC 19501:2005.
For basic VMS, UTMC also provides an SNMP-based protocol, the VMS MIB; see 7.3.1.
6.3.2.5 Incident monitoring
Incident monitoring systems are described in CEN/TR 17401.
This service is largely undertaken using “Closed Circuit Television” (CCTV), see 6.3.2.9, or the presence
of a policeman or traffic management officer.
Communication medium standards:
Technology standards used are those for CCTV, see 6.3.2.9.
UTMC includes specifications for both an “accident” object (UC/002) and an “incident” object (UC014) in
UML format, and an associated XML implementation for each.
DATEX has part 3 of CEN/TS 16157 dedicated on Situation Publication regarding incidents; see 7.2.2.3.
SIRI also has a profile in part 5 of CEN/TS 15531 on incidents from a public transport perspective; see
7.3.11.
Both DATEX II and SIRI use XML so assume an internet connection.
The set of standards ISO/TS 21219 from the “Transport Protocol Experts Group” (TPEG) (see 13.2) has a
number of parts (applications) concerned with incidents:
— Part 14: TPEG2-PKI - Parking
— Part 15: TPEG2-TEC - The main incident application
— Part 16: TPEG2-FPI - Fuel Price Information
— Part 18: TPEG2-TFP - Travel time and prediction
— Part 19: TPEG2-WEA – Weather
6.3.2.6 Parking management
Parking management systems are described in CEN/TR 17401.
Communication medium standards:
UTMC includes a specification for a “car park data” object (UC/004) in UML format, and an associated
XML implementation, which contains elements related to the total capacity and current utilization of the
parking facility. It is not designed for on-street parking.
Car park management usually includes other ITS, including traffic counters (see 6.3.2.9), entry/exit
barriers (see 6.3.2.10), CCTV (6.3.2.9), etc.
6.3.2.7 Ramp meter monitoring and control
Ramp metering systems are described in CEN/TR 17401.
Ramp meter monitoring and control require vehicle detectors on the on-ramp and main carriageway to
measures traffic conditions:
⎯ Main carriageway detectors;
⎯ On-ramp detectors.
The EC Project “Easyway” recommends the use of DATEX II for communications between a “Traffic
Management Centre” (TMC) and its ramp monitoring and management systems. Communications
protocols: DATEX II. CEN/TS 16157. See 7.2.2.
Normally, communications of this nature are locally wired. If ramp detector data are sent remotely, it
should use standard IP following the mainstream signals industry protocols.
If the detectors-centre-signal is made indirectly, it will normally use traffic signal protocols as referred to
elsewhere - just the decision application will be written differently.
A DATEX II link could be used where the highways authority needs to communicate its ramp meter status,
after capture, across its system.
6.3.2.8 Real-time passenger information
Real time passenger information systems are described in CEN/TR 17401.
Standards for vehicle to control centre communications: 2G/3G/4G; see the set of GSM standards
referenced in 6.3.1, and communications specified in ISO 21217:2014 and in related standards for ITS.
Reference data model (Transmodel): EN 12896; capture
...