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 - Städtische IVS - Umgebungen, Methodiken und Übersetzer für gemischte Anbieter

Systèmes de transport intelligents - ITS urbain - Environnements de fournisseurs mixtes méthodologies et traduction

Inteligentni transportni sistemi - Mestni ITS - Mešana prodajna okolja, metodologije in prevajalci

General Information

Status
Published
Publication Date
14-Apr-2020
Current Stage
6060 - Definitive text made available (DAV) - Publishing
Due Date
15-Apr-2020
Completion Date
15-Apr-2020

Buy Standard

Technical specification
-TS CEN/TS 17400:2020 - BARVE na PDF-str 21,35,41,42,45,46
English language
49 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

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

---------------------- 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

---------------------- 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.
---------------------- 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.

---------------------- 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.
---------------------- 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.

---------------------- 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
---------------------- 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
---------------------- 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.

---------------------- 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.

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)
---------------------- 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.