CEN/TR 17401:2020

SLOVENSKI STANDARD
01-marec-2020
Inteligentni transportni sistemi - Mestni ITS - Vodnik za mešana okolja ponudnikov
Intelligent transport systems - Urban-ITS - Mixed vendor environment guide
Intelligente Transportsysteme - Urbane Verkehrssysteme - Leitfaden für gemischte
Anbieterumgebungen
Systèmes de transport intelligents - ITS urbain - Guide pour un environnement de
fournisseur mixte
Ta slovenski standard je istoveten z: CEN/TR 17401: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/TR 17401
TECHNICAL REPORT
RAPPORT TECHNIQUE
January 2020
TECHNISCHER BERICHT
ICS 35.240.60
English Version
Intelligent transport systems - Urban-ITS - Mixed vendor
environment guide
Systèmes de transport intelligents - ITS urbain - Guide Intelligente Transportsysteme - Urbane
pour un environnement de fournisseur mixte Verkehrssysteme - Leitfaden für gemischte
Anbieterumgebungen
This Technical Report was approved by CEN on 27 October 2019. It has been drawn up by the Technical Committee CEN/TC 278.

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/TR 17401:2020 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviations . 8
5 Part I: Context and issues to be addressed . 9
5.1 Background . 9
5.2 Objective of MVE Guide . 11
5.3 Approach of the MVE Guide . 12
5.4 Target audience of the MVE Guide . 12
5.5 Mixed vendor environments in Urban ITS . 13
5.6 The ‘setting’: MVE challenges and vendor lock-in . 13
5.7 History of MVE frameworks . 14
5.8 Principles of co-existence of regional standard solutions for TMS . 14
5.9 MVE contexts . 16
5.10 MVE challenges: integration and interoperability . 17
5.11 System evolution . 17
5.12 MVE requirements: functional integration . 18
5.13 MVE requirements: the operator perspective . 19
6 MVE architectures . 20
6.1 Architectural overview . 20
6.2 Cooperating traffic management systems . 20
6.3 Architecture of roadside systems . 21
6.4 Interoperability requirements in the ‘Traffic Management’ domain . 22
7 Existing open specifications . 22
7.1 DATEX II . 22
7.2 SNMP . 23
7.3 Distributed C-ITS via a secured ITS domain . 24
8 Part II: Work Concepts . 29
8.1 The application of the MVE Guide . 29
9 Key MVE interfaces for traffic control and management . 30
9.1 Introduction . 30
9.2 Principal subsystems for traffic management and their communications
requirements . 31
10 Key MVE interfaces for public transport . 37
10.1 Introduction . 37
10.2 Existing open specifications . 37
11 Mixed vendor environment scenarios . 40
11.1 Introduction . 40
11.2 Scenario 1: Manufacturer mix at field level . 40
11.3 Scenario 2: Collation of data from multiple authorities/operators. 41
11.4 Scenario 3: Data sharing service . 42
12 Part III: Practice (Course of action) . 43
13 PART IV Outlook: Guidance and requirements for the application of MVE for future
business . 43
13.1 Trends for urban ITS . 43
13.2 Distributed C-ITS via a secured ITS domain. 44
Annex A (informative) General principles of project planning and management . 46
Bibliography . 47
European foreword
This document (CEN/TR 17401:2020) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
Introduction
1 2 3
CEN/TR 17401 CEN/TS 17402 and CEN/TS 17400 are a suite of standards deliverables designed to
achieve successful implementation of urban-ITS systems in a mixed vendor environment. This document
should be considered as the introductory part.
This suite of standards deliverables supports the family of existent standards, and those 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, consequently, 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.
CEN/TR 17401, this document, is a ‘Guide’ providing 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 of ITS MVE implementations; and provides a methodical guideline
with a procedural model, in order to assist implementers and managers involved with the structure of an
MVE and/or with the removal of vendor lock-in.
CEN/TS 17402 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
emphasis on the centre/field systems context.
CEN/TS 17400 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.
Against this background, this document is designed to enable ITS architects to develop architectural
concepts for mixed-manufacturer systems in order to achieve the migration of existing monolithic single-

Under preparation. Stage at the time of publication: FprCEN/TR 17401.
Under preparation. Stage at the time of publication: FprCEN/TS 17402.
Under preparation. Stage at the time of publication: FprCEN/TS 17400.
manufacturer systems, by creating and delivering EU-wide MVE communication specifications. These are
designed to actively support the implementation of distributed and open system structures for regionally
and nationally networked systems in the transport sector throughout the European Union.
1 Scope
This document provides a “Concept of Operations (CONOPS) for the introduction and maintenance of a
“Mixed Vendor Environment” (MVE) in the domain of urban-ITS. Structured as:
— PART I Context and issues to be addressed
— Describes the context, background, objective of the MVE Guide, and describes the architectural
context.
— PART II work concepts
— Aspects of system design and architecture are examined and the basic knowledge required for
the application of Part III are presented.
— PART III Practice
— Provides system design and procurement on three levels against the background of a procedure
model.
— user level;
— conceptual explanation;
— examples.
— PART IV Outlook
— Guidance and requirements for the application of MVE for future business.
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.
CEN/TS 17400:—, Intelligent transport systems – Urban ITS – Mixed vendor environments methodologies
& translators
CEN/TS 17402:—, Intelligent transport systems – Urban ITS – Use of regional traffic standards in a mixed
vendor environment
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:

• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
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.
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
methodology
constructive framework of design decisions, operating procedures and development processes intended
to achieve a specific overall set of ITS goals
3.5
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 document may also be applied.
3.6
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.7
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.
3.8
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.9
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.10
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
Note 1 to entry: Also known as proprietary lock-in or customer lock-in.
4 Symbols and abbreviations
ADSL Asymmetric digital subscriber line
ANPR Automatic number plate recognition
API Application programming interface
ATM Active traffic management
ATMS Advanced traffic management systems
CCTV Closed circuit television
C-ITS Cooperative-intelligent transport system(s)
DATEX II standardized DATa Exchange, version II (CEN 16157 (all parts))
DVM Dynamisch Verkeers Management (Dynamic Traffic Management)
GDPR General Data Protection Regulation
GNSS Global Navigation Satellite System
GPS Global positioning system
GUI Graphical user interface(s)
ICT Information and communication technologies
IP Internet protocol
ISO International Organization for Standardization
iTLC Intelligent traffic light controller
ITS Intelligent transport system(s)
IVERA Formed on IVER + ASTRIN, the two organisations that developed the eponymous
open specification
IVERA-APP IVERA Application
IVERA-TLC IVERA Traffic Light Control
MVE Mixed vendor environment
NeTEx NEtwork and Timetable EXchange
OCIT Open Communication Interface for Road Traffic Control Systems
OCIT-O OCIT – Outstation protocol
OSI Open Systems Interconnection
RSMP RoadSide Management Protocol
RWIS Road weather information system
SCOOT Split Cycle and Offset Optimization Technique
SIRI Service Interface for Real-time Information relating to public transport operations
SNMP Simple Network Management Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TLC Traffic Light Controller
TMC Traffic management centre
TMS Traffic management system
XML eXtensible Markup Language
UDP User Datagram Protocol
UTC Urban Traffic Control
UTMC Urban Traffic Management and Control
UVAR Urban Vehicle Access Restriction
VMS Variable Message Sign
5 Part I: Context and issues to be addressed
5.1 Background
The first traffic signal was probably that installed outside the UK Houses of Parliament in 1868, had
waving semaphore arms and red-green lamps, operated by gas, for night use. Modern traffic signals, red-
green systems were installed in Cleveland, USA, in 1914. Three-colour signals, operated manually from a
tower in the middle of the street, were installed in New York in 1918. In 1920 the first three-coloured
traffic signals with red, yellow and green lights were put to service in New York and Detroit, USA. The
first traffic lights in Europe were installed in Paris and Hamburg in 1922, in London in 1925. Automatic,
electronically interconnected, signals were first introduced by Houston in USA in 1922. They soon spread
to Europe (UK 1926, France 1927). It was the post war evolution of computers in the early 1950s that led
to what came to be called “advanced traffic management systems” (ATMS). But while the basis of
computer logic behind them was common, the solutions were designed to meet local traffic geography
needs (which are often very different in different towns and cities), and so the logic and architecture
evolved into different philosophies and different system architectures.
As these systems have been developed by systems specialists, local authorities have tended to buy-in
solutions from experts, because it is usually not cost effective to obtain and maintain such skills in-house.
The result is that there are now several such system providers who have historically been used to
dominating traffic management and information systems within an administration, region or country,
and who have, accidentally or deliberately, created walls around proprietary systems, which make
interoperability more difficult.
In a coordinated urban paradigm, this impairs interoperability, and the ethos behind this series of MVE
standards deliverables, while recognizing the reality of already implemented systems, is to enable
workable MVE (see CEN/TS 17400, Intelligent transport systems – Urban ITS – Mixed vendor
environments methodologies and translators and CEN/TS 17402, Intelligent transport systems —
Urban-ITS — Use of regional traffic standards in a mixed vendor environment).
The motivation to create MVEs derives directly from the objectives of urban authorities and operators.
In addition to domain specific goals (that is, regarding the operation of the urban transport network),
local authorities also have goals related to procurement, including the following:
— Facilitating and exploiting a competitive supply market;
— Ensuring that requirements statements are practical and implementable, and in line with good
practice by other authorities;
— Ensuring economic efficiency and quality assurance in awarding and operating contracts;
— Simplifying and shortening tendering procedures.
However, the mix of systems is also a result from technological change, the increased capabilities of
networks and need for networking, and financial pressures to benefit from competition between different
manufacturers. See Figure 1.
Figure 1 — Typical demands leading to mixed vendor environments
Furthermore, operators have a legitimate expectation that ITS will adopt good technical practice, and will
typically aim to follow the following principles as far as practical:
— Minimization of the cost to acquire, use and maintain the equipment, both financially and in human
resource;
— Deployment of future-proof systems (as far as practical);
— Achieving greater independence from suppliers so that components can be replaced, or suppliers
changed, at any time;
— Increasing reliability, adaptability and sustainability of systems in use;
— Enabling the ability to introduce new technologies (integrated to current systems wherever
appropriate);
— Reducing complexity of systems in use.
Other goals that are likely to be relevant include the ability to adapt traffic management to new
developments such as:
— New transport demands: new vehicle types, new usage patterns, new land use developments etc.;
— Changing policy environments (for example changes in priority between maximizing flow and
minimizing emissions);
— Road user expectations, for example on live travel information and guidance or direct vehicle
connectivity.
This document focusses on the co-existence and interworking/interoperability of the established
regional standard solutions for TMS to achieve MVE, but recognizes that other aspects of the urban-ITS
paradigm, such as public transport, also have similar issues regarding vendor lock-in, and can benefit
from a similar systematic approach to achieve an MVE.
5.2 Objective of MVE Guide
This clause explains the objective of the MVE guide.
This document is part of a series of CEN documents dealing with the ITS standards required and primarily
useful for traffic management in urban environments particularly where holistic MVE products are
largely not yet available.
This document is intended to support those who are involved in tasks for the specification and
procurement of traffic management systems (or components such as systems for traffic control, traffic
guidance and traffic information), particularly in the context of the required European ‘open’ market, and
provides a systematic approach to achieve their objectives.
Users of this document are faced with the difficult task of justifying their decisions or justifying their
decisions regarding requirements defined by others. This MVE guide provides a systematic approach for
the definition of ‘lots’ in the context of tendering procedures.
The general technical trend is towards increasing networking “MVE”, and this makes solutions far more
complex, providing a difficult analysis task. System parts have different lifetimes which increase the
complexity of determining optimal solutions.
System designers or system architects need to be forward thinking and work to influence the
development towards mixed-manufacturer system landscapes through their procurement measures.
This document provides foresight regarding the strategic decisions for the successful achievement of
mixed-manufacturer environments.
This document provides recommendations for actions aimed to identify and avoid the problems that can
be expected to occur with mixed systems. This is necessary because systems for road traffic generally
have to be procured and operated by the public sector, and thus under the application of public
procurement law, i.e. enabling competition; which will inevitably result in a mixture of manufacturers.
This document is divided into the following parts:
— PART I Context and issues to be addressed (this clause)
— Describes the context and objective of the MVE Guide.
— PART II work concepts
— Aspects of system design and architecture are examined and the basic knowledge required for
the application of Part III is presented.
— PART III Practice
— Provides system design and procurement on three levels against the background of a procedure
model.
— user level;
— conceptual explanation;
— examples.
— PART IV Outlook
— Guidance and requirements for the application of MVE for over the coming years.
5.3 Approach of the MVE Guide
This document provides guidance on suitable procedures that authorities may use to achieve an effective
MVE for their ITS. It focuses on the creation and adoption of a coherent system architecture and relevant
standards, and the management of such a system from design, through procurement and operation, to
maintenance and evolution.
It is recommended that a formal systemised approach to the planning and management of projects is
used to develop, migrate to, and maintain, a mixed vendor environment. Annex A provides some guidance
regarding the use of such approaches and tools for project planning and project management and
provides some examples of project management aspects that are particularly relevant in order to
develop, migrate to, and maintain, a mixed vendor environment.
In each case, a solution concept needs to be developed that encompass “all” of the requirements. A
formalized approach starts with a representation at the conceptual level, and it is necessary to ensure
that any components of solution supplied by different manufacturers not only successfully interact with
the existing system environment, but also with each other, as intended.
The recommended general approach is to create a “distributed system” (regardless of whether it is
actually implemented as a manufacturer-mixed or manufacturer-specific solution). In a distributed
system the definition and specification of messages to be exchanged, and their representation in specified
open format, are an indispensable component of the specifications.
5.4 Target audience of the MVE Guide
While much of the focus of this document is on traffic management systems, the general principles are
applicable across the entire gamut of urban-ITS service provision, including public transport MVE aspects
which are explicitly addressed below.
Within the arena of traffic control and management, the renewal or extension of existing traffic control
systems, or their confederation into regional or supra-regional traffic information and traffic
management systems, involve tasks which can be very different in different cases.
This document is aimed primarily at those who are responsible for the development of integrated urban-
ITS concepts and the associated processes of procurement, operation, and evolution.
Particular attention is paid to the concept development stage, that is to say the capture of system
requirements in a coherent architecture and operations model, since this will define the scope for the
necessary procurements. This stage is fundamentally important: what is misinterpreted or omitted at
this stage is likely to be much harder to correct later.
5.5 Mixed vendor environments in Urban ITS
Historically, urban ITS have tended to be single solutions provided to a clear requirements specification
by a single supplier. Today, urban authorities use an increasing array of ITS to deliver their services.
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 manufactured by different manufacturers to so-called ‘Mixed Vendor
Environments’ (MVEs) is a growing issue, which results primarily from the demand for the introduction
of competition in the context of public tenders (European ‘open’ market), and the increasing networking
of existing stand-alone solutions to achieve complex, connected, 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, consequently, 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.
Against this background, this document is designed to enable ITS architects to develop 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 regional markets.
5.6 The ‘setting’: MVE challenges and vendor lock-in
While the achievement of an effective MVE can broadly be described in the terms of any project to be
managed, there are aspects concerning MVE that are particular to its situation and objectives, and which
provide the ‘setting’ in which the project is to be undertaken.
“Vendor lock-in”, is a 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).
The lock-in effect is both a market strategy and a marketing strategy of manufacturers and suppliers. It
is regarded as technical-functional customer loyalty, because product or service components can only be
obtained from one manufacturer or complementary products only provide joint benefits. Although the
lock-in term implies that customer loyalty activities originate from the manufacturer, it can also be
triggered by the customer itself through preferences for the supplier or its product(s), or simply seeking
the easiest and quickest short-term solution.
Vendor lock-in is widespread in the transport sector, especially in cities. It has largely developed because
of the special system architecture of urban traffic control and traffic management systems, each with a
control centre and many field devices connected to it. These solutions have, in general, developed and
evolved, often in a piecemeal fashion, over time, with the road authority asking its present supplier to
extend its present system to also be able to do task b, or operate c. However due to this architecture, and
with the use of proprietary communication interfaces, the supplier of the control centre can prevent other
“external” manufacturers from connecting their field devices to this control centre. The principle
“whoever delivers the central unit also delivers the field devices” applies. Typical examples of such
vendor-locked systems are traffic signal control systems and parking guidance systems.
The lack of competition not only leads to high investment and maintenance costs, but finally also to a lack
of flexibility/evolvability, and a loss of innovation.
Vendor lock-in does not play a significant role throughout the entire ITS domain, and not all systems are
prone to it. Vendor lock-in is concentrated primarily on systems that consist of many subsystems and are
associated with areas of high investment and maintenance costs for the operator. The most typical
examples are traffic signal control systems, which usually consist of a central unit and many roadside
mounted control units.
5.7 History of MVE frameworks
As early as the 1990s, in some European countries (e.g. Germany, United Kingdom and the Netherlands)
public authorities and operators were increasingly confronted with demands from funding bodies, audit
offices, or other stakeholders, to create competitive conditions for awarding ITS contracts (at that time
mainly traffic signal control and parking systems) with the aim of reducing costs.
The initial reaction was for those responsible for awarding the contracts to define their own city-specific
standards. These interface standards were designed to break down the previously common monolithic
traffic signal control systems in such a way that central control units and control units could be made the
subject of public tenders as independent ‘lots’, under competitive conditions.
For manufacturers, however, city specific standards are associated with unmanageable cost risks. Several
national initiatives were therefore created with the objective of creating an open industry standard that
could command wide support from vendors. Such initiatives include the OCIT® initiative in German-
speaking Europe, UTMC in the UK, DVM/IVERA in the Netherlands, DIASER in France, RSMP in Sweden,
etc.
5.8 Principles of co-existence of regional standard solutions for TMS
The objective of achieving co-existence and interworking/interoperability starts with an open
specification and understanding of the principal systems deployed in Europe. The key objectives and
specifications of principal non-proprietary systems deployed in Europe, especially those that are based
on MVE (such as OCIT, UTMC and DVM/IVERA) can be found in CEN/TS 17400 Intelligent transport
systems – Urban ITS – Mixed vendor environments methodologies and translators.
The mixed vendor environment, with its data interoperability, also makes a significant step creating new
options for the future, both in terms of more capable and extended systems, and in the use of so called
‘big data’. In order to achieve MVE, systems and subsystems have to be designed in a way that the various
sub-systems can be supplied by different manufacturers and can be exchanged without any problems
through sub-systems from other manufacturers later. The mixed vendor environment, and the Standards
that underpin it, therefore always imply options for the future with the goal to have these systems
working efficiently (see CEN/TS 17400 Intelligent Transport Systems – Urban-ITS – Mixed vendor
environments Methodologies and Translators).
On the other hand, it cannot be denied that the extension of an existing system with systems or
components from different vendors usually increases the complexity of the system.
It is also important to recognize that the opportunity for having a mixed vendor environment does not
necessarily lead to mixed implementation, however, the possibility should always be given. (This is
particularly true where there are well established regional standards already widely implemented).
Where systems are designed to allow the different applications used within traffic management systems
to communicate and share information with each other, previously disparate data from multiple sources
such as ‘Automatic Number Plate Recognition’ (ANPR) cameras, ‘Variable Message Signs’ (VMS), car
parks, traffic signals, air quality monitoring stations and meteorological data, can be amalgamated into a
central console or database. This enables more intelligent management; for example, by collating car park
data with traffic flow data, and providing an integrated response through variable message signs and
altered signal timings, cities have found a dramatic reduction in congestion caused by vehicles trying to
find a parking space - with consequential benefit on journey times, emissions and road safety. Similar
operational benefits are being achieved in other areas, and the trend is towards integration of city and
highway systems, tunnels and bridges, and other strategic developments.
Such systems cover both roadside <-> centre communications (e.g. between a roadside VMS and the VMS
management system at the traffic control centre) and centre <-> centre communications (e.g. between
the VMS management system and the traffic signal control system). They also provide format for data
which is exported to other systems (e.g. traveller information systems).
A typical architecture is shown in Figure 2.

Figure 2 — Example architecture for an MVE environment (Courtesy UTMC)
Occasionally a standard is developed for a single purpose, and a single standard is adequate to obtain its
objectives. However, as a general rule in a complex domain like ITS/Urban-ITS, a suite of standards is
required in order to achieve the objectives, particularly at the “application” level. In this setting there are
some fundamental requirements:
a) each data concept is generically specified such that it can be used by other systems (and not just
usable only in the context of the sourcing system);
b) Both data concept specifications and TMS foundation standards need to be ‘abstract’ regarding any
particular application they are envisaged to serve; and
c) it is the application standards that need to specify their application specific issues within the
application standard.
That said, if standardizing an update sequence in an interface standard, the protocols for the sequence of
operations will be included in the interface standard, and this relevant standard will have to specify the
communication standard (or standards) upon which it relies (and may also have to specify options within
that/those standards).
Moving up to the user application level (business processes and strategic levels, such as an ‘app’ to update
a VMS), while the scope and specification of the ‘app’ will be defined, it will in all probability rely on a
combination of interface standards, ‘foundation’ level standards, a metadata standard, and another
interface standard to a database where the data values are stored.
By its determination of its “National Transportation Communications for Intelligent Transportation
System Protocol” (NTCIP), the US Department of Transportation already provides a family of standards
designed to achieve interoperability and interchangeability between computers and electronic traffic
control equipment from different manufacturers. NTCIP has been focussed on centre <-> centre and
centre <-> field communication and command/control of equipment from different manufacturers to be
specified, procured, deployed, and tested. Although not European, it provides another set of regional
standards (that have wide acceptance beyond USA) to create a functioning MVE, and are referenced in
this document. However, it needs to be noted that that NTCIP is in many ways unsuitable for
implementations in Europe, because it is founded on the philosophy of a centralized control (as opposed
to the decentralised Member State subsidiarity applicable in Europe), and is based largely on the use of
ISO DATEX-AP, whereas in Europe, DATEX II is preferred, widely deployed, and referenced in regulations.
5.9 MVE contexts
In an urban environment,
...