SIST-TS CEN/TS 17400:2020
(Main)Intelligent transport systems - Urban ITS - Mixed vendor environments, methodologies & translators
Intelligent transport systems - Urban ITS - Mixed vendor environments, methodologies & translators
This TS will focus on the principal aspects of urban ITS where vendor lock-in is a technical and financial problem: primarily centre-tofield communications and traffic management systems. It will cover the following scope:
- Analysis of vendor lock-in challenges, and mitigation and migration options
- Technical options for interworking multiple vendors' products
- Review of principal approaches taken to date to implement these options in comunity frameworks and specifications
- Translation between frameworks/products
- Technical and management protocols to achieve interworking, using product/interface adaptation, translation products, replacement/reengineering, and other migration strategies
Intelligente Verkehrssysteme - IVS in Städten - Herstellergemischte Systemlandschaften, Methodik und Umsetzung von Schnittstellen
Systèmes de transport intelligents - STI-urbain - Environnements de fournisseurs mixtes méthodologies et traducteurs
Inteligentni transportni sistemi - Mestni ITS - Mešana prodajna okolja, metodologije in prevajalci
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 17400:2020
01-junij-2020
Inteligentni transportni sistemi - Mestni ITS - Mešana prodajna okolja,
metodologije in prevajalci
Intelligent transport systems - Urban ITS - Mixed vendor environments, methodologies &
translators
Intelligente Verkehrssysteme - IVS in Städten - Herstellergemischte Systemlandschaften,
Methodik und Umsetzung von Schnittstellen
Systèmes de transport intelligents - STI-urbain - Environnements de fournisseurs mixtes
méthodologies et traducteurs
Ta slovenski standard je istoveten z: CEN/TS 17400:2020
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
SIST-TS CEN/TS 17400:2020 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 17400:2020
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Intelligent transport systems - Urban ITS - Mixed vendor
environments, methodologies & translators
Systèmes de transport intelligents - ITS urbain - Intelligente Verkehrssysteme - Städtische IVS -
Environnements de fournisseurs mixtes méthodologies Gemischte Anbieterumgebungen Methodologien &
et traduction Übersetzer
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 17400:2020 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviations . 8
5 Mixed vendor environments in urban ITS . 10
5.1 General. 10
5.2 Interfaces between systems . 11
5.3 Legacy and migration issues . 13
6 MVE methodologies . 14
6.1 Design methodologies . 14
6.2 Public procurement constraints. 16
6.3 Communications . 17
7 Translators . 19
7.1 Introduction . 19
7.2 Specifications . 21
7.3 Location of functional processing . 21
7.4 Data storage and caching . 22
7.5 Data models: concepts, definitions and units . 23
7.6 Upper layer protocol adaptors . 24
7.7 Communications network translation . 24
7.8 Information security . 25
Annex A (informative) Approach of DVM Exchange/IVERA to interoperability . 26
A.1 Introduction . 26
A.2 General architectural approach of DVM-Exchange . 26
A.3 General architectural approach of IVERA . 28
A.4 Procurement issues and impact . 29
A.5 Management and governance . 29
A.6 Example DVM Exchange/IVERA implementation: Deventer . 30
Annex B (informative) Approach of OCIT to interoperability . 32
B.1 Introduction . 32
B.2 General architectural approach . 33
B.3 Procurement issues and impact . 33
B.4 Management . 34
B.5 Example OCIT implementation . 34
2
---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
Annex C (informative) Approach of UTMC to interoperability . 37
C.1 Introduction . 37
C.2 General architectural approach . 38
C.3 Procurement issues and impact . 40
C.4 Management . 41
C.5 Example UTMC implementation: Reading . 41
Annex D (informative) Approach of RSMP to interoperability . 43
D.1 Introduction . 43
D.2 General architectural approach of RSMP . 44
D.3 Procurement issues and impact . 46
D.4 Management and governance . 47
Bibliography . 48
3
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
European foreword
This document (CEN/TS 17400: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 Commission Implementing Decision (M/546) given to CEN by
the European Commission and the European Free Trade Association [1], and supports essential
requirements of the EU ITS Directive [2]. It fulfils part of the workplan identified in CEN/TR 17143:2017,
Intelligent transport systems - Standards and actions necessary to enable urban infrastructure
coordination to support urban-ITS [3].
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.
4
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
Introduction
This suite of standards ([4], [5] and the present document) assist stakeholders to implement urban-ITS
systems in a mixed vendor environment.
This suite of standards deliverables will support the family of existent standards, and others under
development, 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 intelligent transport systems (ITS) to deliver their services.
Historically, urban ITS 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 change.
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, 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 Europe, compromising the efficiency of the single market.
This document 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.
This specification is designed to enable ITS architects to develop concrete architectural concepts for
mixed-manufacturer systems in order to achieve the migration of existing monolithic single-
manufacturer systems, by creating and delivering EU-wide MVE communication specifications designed
to actively support the implementation of distributed and open system structures for regionally and
nationally networked systems in the transport sector throughout the EU.
This document should be read together with [4], which provides a ‘Guide’ giving a high level introduction
into the concept of operations (CONOPS) for a mixed vendor environment (MVE); provides a high-level
architectural context explanation of an MVE and its operational requirements, and describes the
problems and effects are associated with vendor lock-in. It also provides a systematic approach for many
aspects of Urban-ITS implementation, and indeed almost all ITS MVE implementation; 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 [5], which 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 (RTS) in such mixed
vendor environments (RTS-MVE), with particular emphasis on the centre/field systems context. The
document also provides information regarding MVE provisions in the public transport domain.
5
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
1 Scope
This document focuses on the principal aspects of urban ITS where vendor lock-in is recognized as a
technical and financial problem: primarily centre-to-field communications and traffic management
systems. It will cover the following scope:
— approaches to the management of MVEs by urban authorities, including mitigation and migration
options;
— procedural and operational protocols to achieve interworking, using product/interface adaptation,
translation products, replacement/reengineering, and other migration strategies;
— technical options for interworking multiple vendors' products;
— mechanisms to enable interoperability through automated translation between specifications,
frameworks and product interfaces;
— review of principal approaches taken to date to implement these options in community frameworks
and specifications.
2 Normative references
There are no normative references in this document.
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 http://www.iso.org/obp
3.1
central system
collection of ITS products and services maintained and managed at one or more control centres, in a
sheltered environment
3.2
field device
ITS device that is intended for location within the public realm, whose primary mode of operation does
not involve control by a human operator
Note 1 to entry: Field devices may operate in a standalone mode; these are not subject to significant MVE issues.
Generally in this document, therefore, the term will refer to field devices which are connected to a central system
by an operational communications link, over which the communication (in real time) is essential to their designed
operation.
6
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
3.3
ITS
system in which information and communication technologies are applied in the field of road transport,
including infrastructure, vehicles and users, and in traffic management and mobility management, as well
as for interfaces with other modes of transport
Note 1 to entry: This definition is taken from EU Directive 2010/40/EU.
3.4
ITS system
ITS with at least two interfaces compliant to different specifications, used to facilitate the effective
interworking of ITS that are unable to interwork through a direct connection
3.5
manufacturer
legal entity that designs and creates ITS, and offers and provides them for public use
Note 1 to entry: A manufacturer may or may not be a vendor.
3.6
methodology
constructive framework of design decisions, operating procedures and development processes intended
to achieve a specific overall set of ITS goals
3.7
mixed vendor environment
ITS system containing products which are supplied and/or maintained by more than one vendor
Note 1 to entry: A single company may have multiple semi-independent operating divisions, or multiple product
suites which are not designed to operate together. Systems using a collection of products from such a company are
likely to share many features of an MVE, and this standard may also be applied.
3.8
operator
legal entity responsible for sustaining the efficient operation of an urban road transport network on a
day-to-day basis, including through the deployment and/or use of suitable ITS
Note 1 to entry: An urban authority may be an operator, or may contract operator services from a third party. In the
latter case, the authority and contracted operator normally share the role of specifying, procuring, and deploying
ITS, although the precise split of roles may vary from case to case.
3.9
product
ITS, or a collection of ITS, provided by a vendor under a commercial contract or similar arrangement
Note 1 to entry: The use of this term implies that contractual law applies. In particular, the vendor is held to warrant
the suitability and effectiveness of the product, and to underwrite the compliance of the product with the customer
specification.
Note 2 to entry: Whether a supply by a vendor is considered to be one product or a collection of connected products
will normally be determined by the structure of the procurement specification and resulting supply contract.
7
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
3.10
translator
ITS with at least two interfaces compliant to different specifications, used to facilitate the effective
interworking of ITS that are unable to interwork through a direct connection
3.11
urban authority
legal entity responsible for the management of a road transport network within an urban area
Note 1 to entry: This definition includes both public bodies that are legally responsible for the network, as well as
public and private bodies which have devolved responsibility under a service contact or similar arrangement.
3.12
vendor
legal entity that offers and provides ITS products to urban authorities, typically under a commercial
contract
3.13
vendor lock-in
situation where a user is dependent on a specific vendor for products and services, and unable to use
another vendor without substantial switching costs (also known as proprietary lock-in or customer lock-
in)
4 Abbreviations
ADSL Asymmetric Digital Subscriber Line
ANPR Automatic Number Plate Recognition
APP Application
ASN.1 Abstract Syntax Notation 1
CCTV Closed circuit television
CEO Chief executive officer
C-ITS Cooperative-Intelligent Transport System(s)
CPU Central processor unit
CROCS Controller to Roadside Open C-ITS Standard (a protocol associated with UTMC,
qv.)
DATEX standardized DATa EXchange
DATEX II standardized DATa EXchange II
DfT (UK) Department for Transport
DSL Digital Subscriber Line
DVM Dynamisch Verkeers Management (Dynamic Traffic Management)
GPRS General Packet Radio Service
GSM General System for Mobile communications
HTTP Hypertext Transfer Protocol (world wide web protocol)
ICT Information and Communication Technologies
IEC International Electrotechnical Commission
8
---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
IP Internet protocol
ISO International Organization for Standardization
iTLC Intelligent Traffic Light Controller
ITS Intelligent Transport System
IVERA Formed on IVER + ASTRIN, the two organisations that developed the
eponymous open specification
IVERA-APP IVERA Application
IVERA-TLC IVERA Traffic Light Control
JPEG Joint Photographic Experts Group (image format)
JSON JavaScript Object Notation
LA Local authority
LTE Long Term Evolution (associated with UMTS)
MVE Mixed vendor environment
NeTEx NEtwork and Timetable EXchange
OCA Open Traffic Systems City Association
OCIT Open Communication Interface for Road Traffic Control Systems
OCIT-C OCIT – Centre protocol
OCIT-O OCIT – Outstation protocol
ODG OCIT Development Group
OSI Open Systems Interconnection
PC-SCOOT Personal Computer – Split Cycle and Offset Optimization Technique?
POSSE P
PPP Point-to-Point Protocol (Internet)
PSTN Public Switched Telephone Network
PW Private Wire
RIS Road ITS System
RSMP RoadSide Management Protocol
SCOOT Split Cycle and Offset Optimization Technique
SIRI Service Interface for Real-time Information relating to public transport
operations
SNMP Simple Network Management Protocol
STA Swedish Transport Administration
SXL Signal eXchange Lists (a protocol of RSMP, qv.)
TCP Transmission Control Protocol
TCS Traffic Control System
TDS Traffic Data System
TERN Trans-European Road Network
9
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
TETRA TErrestrial Trunked RAdio
TLC Traffic Light Controller
TM Traffic light controller Middleware
TMC Traffic Management Centre
TPEG Transport Protocol Experts Group
UDG UTMC Development Group
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications Service
UTC Urban Traffic Control
UTMC Urban Traffic Management and Control
VDV Verband Deutsches Verkehrsunternehmen
VMS Variable Message Sign
VPN Virtual Private Network
XML eXtensible Markup Language
5 Mixed vendor environments in urban ITS
5.1 General
[4] reviews the context and emergence of the requirements for mixed vendor environments in the urban-
ITS paradigm, and provides the context for which the methodologies and translators specified in this
document have been specified. Specifically, the following sections of [4] describe:
— The MVE context and issues to be addressed (Section 5), including:
• factors driving the emergence of MVEs (Sections 5.1/5.2);
• MVE contexts (Section 5.3);
• MVE challenges: vendor lock-in (Section 5.8);
• MVE challenges: integration and interoperability (Section 5.11);
• MVE requirements: functional integration (Section 5.13); and
• MVE requirements: the operator perspective (Section 5.14)
— The nature of MVE architectures (Section 6), providing an overview, and the context of cooperating
traffic management system and the architectures of roadside systems.
The reader is referred to these sections of [4] in order to obtain a better understanding regarding the
paradigm for which the methodologies and translators specified in this document are specified.
10
---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
5.2 Interfaces between systems
5.2.1 Introduction
Section 6 of [4] describes how, in order to achieve an MVE that meets the urban authority's goals of
section 5.1 while minimizing the management challenges, it is crucial to specify the interfaces between
systems in a clear, precise and open way. Moreover, this needs to be common across the sector if it is to
create a genuine competitive environment with proven products and stable suppliers (see Figure 2).
A number of approaches to this are possible, through formal standards, common industry practice, and
(sometimes) specifications produced by an individual authority. The effectiveness of these depends on
the context for the interface.
5.2.2 Interfaces with other system owners
These interfaces are relevant where several traffic management systems and sub systems are
interconnected.
This interface exchanges data and service requests between the both systems enabling one traffic
management system to have access to the measures and instruments of another traffic management
system. For these interfaces there are already important standards, including:
— DATEX II, a European protocol, much of which is now standardized in the EN 16157 series [14].
— Standards for exchanging public transport data based on the Transmodel architecture, including SIRI
(EN 15531, [15]) and NeTEx (EN 16614, [16]).
— TPEG (ISO 21219, [17]), which is designed for data exchange with information service providers.
A
I.T
I.R
T R
Key
A ITS Application
T Smart traffic light controller
R Roadside C-ITS station
I.T Interface from A to T
I.R Interface from A to R
Figure 1 — iTLC: architecture for connected roadside units (example)
11
---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 17400:2020
CEN/TS 17400:2020 (E)
Of these, DATEX II (in Europe, DATEX in USA) is much the most important for traffic management
systems. Transmodel and TPEG standards may also be of use for particular functional requirements,
although unfortunately the three standards are not entirely compatible.
These standards are complemented or profiled in local implementations. Examples include:
— DVM-Exchange, a Dutch protocol for horizontal and vertical connections between traffic
management systems based on exchanging and requesting services.
— UTMC, a UK protocol for interconnecting traffic management ITS, which references DATEX II but
without significant profiling.
— OCIT-C, a German protocol for interconnecting traffic management ITS as part of the OCIT
environment, heavily based on DATEX II.
Using an open protocol such these, vendors are able to work together in a MVE at this level and road
authorities have the opportunity to combine several systems from multiple vendors. Locally, vendors
often favour the more specific and well-publicised protocols available in frameworks such as DVM-
Exchange, UTMC or OCIT-C, although national highways administrations and some large urban
authorities make use of DATEX as well.
5.2.3 Interfaces between procurements by a systems owner
For a system owner, the architecture as shown in Section 6 of [4], cover several nodes. The vendor
providing a node in the owner’s system is likely to be part of a separate procurement (an individual node
B, C or D) or a large procurement covering all or much of the complete system (a complex of nodes B, C
and D).
The availability of existing equipment, like a node D, usually give need to procure the other node B and
or C separately as the existing equipment is usually too expensive to replace. In this case, the interfaces
between existing nodes and newly procured nodes are likely to be open or known, otherwise it becomes
almost impossible for a vendor to fill in the needs.
The vertical connections between a traffic management system and its underlying measures/
instruments (as depicted Section 6 of [4] between nodes B, C and D) are intended to give control over the
actual systems, and need more detailed protocol in order to facilitate this.
At present there are few standards to assist with this integration context. While frameworks such as
DATEX II may be used, they may not be efficient – especially for centre-to-field communications, where
the environment is entirely different from the centre-to-centre context for which DATEX II (or DATEX in
USA) is designed. In particular:
— Communications links may be constrained in terms of bandwidth, reliability etc.
— Security may be a greater challenge for on-street devices.
— There may be less need for compl
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.