SIST-TS CEN/TS 16157-8:2020

Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 8: Traffic management publications and extensions dedicated to the urban environment

This document constitutes a Part of the CEN 16157 DATEX II series of standards and technical specifications. This series specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel. The component facets include the framework and context for exchanges, the modelling approach, the data content, the data structure and relationships and the communications specification.
Part 8, this document, specifies additional data model structures that are applicable for traffic management applications in the urban environment. This Part addresses data concepts to support the exchange of Traffic Management Plans, rerouting, extensions of the existing DATEX II core model to better support application to the urban environment.
It establishes specifications for data exchange between any two instances of the following actors:
- Traffic Information Centres (TICs),
- Traffic Control Centres (TCCs),
- Service Providers (SPs).
Use of this document may be applicable for use by other actors.

Intelligente Verkehrssysteme - DATEX II Datenaustauschspezifikationen für Verkehrsmanagement und Verkehrsinformationen - Teil 8: Verkehrsmanagement-Publikationen und Erweiterungen für das städtische Umfeld

Systèmes de transport intelligents - DATEX II Spécification des échanges de données pour la gestion du trafic et l'information routières - Partie 8: Publications et extensions pour la gestion du trafic dédiées à l'environnement urbain

Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri upravljanju prometa in informiranju - 8. del: Publikacije in razširitve za upravljanje prometa, namenjene mestnemu okolju

General Information

• Status: Published
• Publication Date: 10-Jun-2020
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 14-May-2020
• Due Date: 19-Jul-2020
• Completion Date: 11-Jun-2020
• Directive: 2010/40/EU - Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport Text with EEA relevance
• Mandate: M/546 - [C(2016)808 Urban ITS (Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport)
• Ref Project: CEN/TS 16157-8:2020 - Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 8: Traffic management publications and extensions dedicated to the urban environment

Relations

• Revised: kSIST-TS FprCEN/TS 16157-8:2024 - Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 8: Traffic management publications and extensions dedicated to the urban environment
• Effective Date: 15-Mar-2023

Overview

CEN/TS 16157-8:2020 is Part 8 of the DATEX II family for intelligent transport systems (ITS). It defines data model extensions and publication structures dedicated to the urban environment, enabling interoperable data exchange for urban traffic management. The technical specification adds Level B extensions to the DATEX II core model to support traffic management plans, rerouting, and urban-specific concepts (e.g., lane, street works, infrastructure descriptors). It targets data exchange between Traffic Information Centres (TICs), Traffic Control Centres (TCCs) and Service Providers (SPs), and can be used by other actors.

Key topics and technical requirements

• UrbanExtensions: model elements that extend the DATEX II core to represent urban-specific traffic objects and events.
• ReroutingManagementEnhanced: enhanced schema for publishing rerouting information and route capacity/allocation semantics.
• TrafficManagementPlan: data structures for publishing coordinated plans (strategies, measures, actions) and sign-setting / implementation details.
• Conformance & modelling: uses UML notation and follows DATEX II modelling principles; normative XML Schema and a data dictionary are provided.
• Interoperability focus: formal data dictionaries, enumerations, and referenced XML schemas to ensure consistent implementations.
• Actors & exchanges: specifies exchange scenarios between TICs, TCCs and SPs and supports extensible publication mechanisms.
• Supporting documents: normative cross-references to EN 16157 Parts 1–3 and 7; includes annexes with XML schema and data dictionaries.

Applications - who uses it and why

• Traffic Control Centres (TCCs): publish and exchange urban traffic management plans, coordinate implementation and sign settings.
• Traffic Information Centres (TICs) and Service Providers (SPs): consume structured rerouting and plan data to deliver timely traveler information, route guidance and dynamic signage.
• City transport authorities & road operators: coordinate multi-actor responses to incidents, events, infrastructure works and demand management in urban areas.
• ITS vendors & software integrators: implement DATEX II-compliant APIs, XML feeds and backend services to ensure interoperability across systems.
  Practical benefits include improved interoperability, reduced integration cost, consistent rerouting publication, and better support for EU-wide traffic information services.

Related standards and references

• EN 16157-1:2018 (Context & framework)
• EN 16157-2:2018 (Location referencing)
• EN 16157-3:2018 (Situation publication)
• EN 16157-7:2018 (Common data elements)
  DATEX II is referenced by EU regulations (e.g., (EU) 2015/962, (EU) 2013/885, (EU) 2013/886, (EU) 1926/2017). For implementation resources and tools see www.datex2.eu.

Keywords: CEN/TS 16157-8:2020, DATEX II, intelligent transport systems, urban traffic management, rerouting, traffic management plans, data exchange, Traffic Control Centre, Traffic Information Centre.

Standards Content (Sample)

SLOVENSKI STANDARD
01-julij-2020
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 8. del: Publikacije in razširitve za upravljanje
prometa, namenjene mestnemu okolju
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 8: Traffic management publications and extensions
dedicated to the urban environment
Intelligente Verkehrssysteme - DATEX II Datenaustauschspezifikationen für
Verkehrsmanagement und Verkehrsinformationen - Teil 8: Verkehrsmanagement-
Publikationen und Erweiterungen für das städtische Umfeld
Systèmes de transport intelligents - DATEX II Spécification des échanges de données
pour la gestion du trafic et l'information routières - Partie 8: Publications et extensions
pour la gestion du trafic dédiées à l'environnement urbain
Ta slovenski standard je istoveten z: CEN/TS 16157-8:2020
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 16157-8
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 8: Traffic management publications and extensions
dedicated to the urban environment
Systèmes de transport intelligents - DATEX II Intelligente Verkehrssysteme - DATEX II
Spécification des échanges de données pour la gestion Datenaustauschspezifikationen für
du trafic et l'information routières - Partie 8: Verkehrsmanagement und Verkehrsinformationen -
Publications et extensions pour la gestion du trafic Teil 8: Verkehrsmanagement-Publikationen und
dédiées à l'environnement urbain Erweiterungen für das städtische Umfeld
This Technical Specification (CEN/TS) was approved by CEN on 10 February 2020 for provisional application.

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

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

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

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16157-8: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 . 7
4 Symbols and abbreviations . 8
5 Conformance . 8
6 UML notation . 8
7 «D2Namespace» UrbanExtensions . 9
7.1 Overview . 9
7.2 ClassifiedDelay Class . 9
7.3 EquipmentOrSystemType Class . 11
7.4 GeneralInstructionsToRoadUsers Class . 12
7.5 GeneralNetworkManagementType Class . 12
7.6 InfrastructureDamageType Class . 13
7.7 InfrastructureDescriptor Class . 13
7.8 LaneEnum Class . 14
7.9 NonVehicularRoadUsers Classes . 15
7.10 ObstructionType Class . 16
7.11 RoadOrCarriagewayOrLaneManagement Class . 17
7.12 StreetWorks Class . 18
7.13 VehicleType Class . 19
8 «D2Namespace» ReroutingManagementEnhanced . 19
8.1 Overview . 19
8.2 Semantics – Rerouting management and route description . 21
8.3 Semantics – Route allocation . 22
8.4 Semantics – Route capacity management . 23
9 «D2Namespace» TrafficManagementPlan . 24
9.1 Overview . 24
9.2 «D2Package» TmplanTablePublication . 25
9.3 «D2Package» TmplanOperationPublication . 27
9.4 Traffic management extension for implementing action . 30
9.5 Sign setting extension . 31
Annex A (normative) Data Dictionary . 33
A.1 Overview . 33
A.2 Data Dictionary for “UrbanExtensions” . 34
A.3 Data Dictionary of «D2Datatype» for “UrbanExtensions” . 37
A.4 Data Dictionary of «D2Enumeration» for “UrbanExtensions” . 37
A.5 Data Dictionary for “ReroutingManagementEnhanced” . 44
A.6 Data Dictionary of «D2Datatype» for “ReroutingManagementEnhanced” . 51
A.7 Data Dictionary of «D2Enumeration» for “ReroutingManagementEnhanced” . 51
A.8 Data Dictionary for “Traffic Management Plan” . 52
A.9 Data Dictionary of «D2Datatype» for “TrafficManagementPlan” . 68
A.10 Data Dictionary of «D2Enumeration» for “TrafficManagementPlan” . 68
Annex B (normative) Referenced XML Schema for “Traffic management publications
dedicated to the urban environment” . 71
B.1 Overview . 71
B.2 Urban Extensions . 71
B.3 ReroutingManagementEnhanced . 75
B.4 Traffic Management Plan . 81
Bibliography . 96

European foreword
This document (CEN/TS 16157-8: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.
As a user of this document, attention is drawn to the resources of www.datex2.eu. This website contains
related software tools and software resources that aid the implementation of EN 16157 DATEX II.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
This document defines a common set of data exchange specifications to support the vision of a seamless
interoperable exchange of traffic and travel information across boundaries, including national, urban,
interurban, road administrations, infrastructure providers and service providers.
Standardization in this context is a vital constituent to ensure that interoperability, reduction of risk,
reduction of the cost base and promotion of open marketplace objectives are achieved that will lead to
many social, economic and community benefits as a result of more informed travellers, network
managers and transport operators.
With the aim to support sustainable mobility in Europe, the European Commission has been supporting
the development of information exchange mainly between the actors of the road traffic management
domain for a number of years. In the road sector, DATEX II has been long in fruition, with the European
Commission being fundamental to its development through an initial contract and subsequent
cofounding through the Euro-Regional projects, and well as support for Programme Support Action
activities.
DATEX II is referenced within European regulations:
— EU Commission Delegated Regulation, (EU) 2015/962 of 18 December 2014 regarding the provision
of EU-wide real-time traffic information services,
— EU Commission Delegated Regulation, (EU) 2013/885 of 15 May 2013 regarding the provision of
information services for safe and secure parking places for trucks and commercial vehicles,
— EU Commission Delegated Regulation, (EU) 2013/886 of 15 May 2013 regarding data and
procedures for the provision, where possible, of road safety-related minimum universal traffic
information free of charge to users,
— EU Commission Delegated Regulation, (EU) 1926/2017 of 31 May 2017 regarding the provision of
EU-wide multimodal travel information services.
This document includes the framework, context and specification for exchanges, the modelling approach,
data content, data structure and relationships.
This document supports a methodology that is extensible.
This document, which is Part 8 for the CEN 16157 series, provides:
— extensions to existing DATEX II publications, to better support use within an urban context. The
extensions are specified as Level B Extensions to the DATEX II model.
— a specification for the publication of rerouting information to enhance the corresponding existing
DATEX II structure
— a specification for the publication of traffic management plans extending the existing DATEX II core
model to better support application to the urban environment.
The specification for the publication of traffic management plans draws on work undertaken within the
DATEX II Programme Support Action tasks, supported by the European Commission, and other related
project work undertaken on these topics.
The present document was developed by project team PT1709 funded by the European Commission
under grant agreement SA/CEN/GROW/EFTA/546/2016-10 'Urban ITS - Traffic Management Data
Models and interfaces' (M/546 [2]).
1 Scope
This document constitutes a Part of the CEN 16157 DATEX II series of standards and technical
specifications. This series specifies and defines component facets supporting the exchange and shared
use of data and information in the field of traffic and travel. The component facets include the framework
and context for exchanges, the modelling approach, the data content, the data structure and relationships
and the communications specification.
Part 8, this document, specifies additional data model structures that are applicable for traffic
management applications in the urban environment. This Part addresses data concepts to support the
exchange of traffic management plans, rerouting, extensions of the existing DATEX II core model to better
support application to the urban environment.
It establishes specifications for data exchange between any two instances of the following actors:
— Traffic Information Centres (TICs),
— Traffic Control Centres (TCCs),
— Service Providers (SPs).
Use of this document may be applicable for use by other actors.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 16157-1:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 1: Context and framework
EN 16157-2:2018, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 2: Location Referencing
EN 16157-3:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 3: Situation Publication
EN 16157-7:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 7: Common data elements
ISO/IEC 19505-1:2012, Information technology — Object Management Group Unified Modeling Language
(OMG UML) — Part 1: Infrastructure
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 16157-1:2018,
EN 16157-2:2018, EN 16157-3:2018 and EN 16157-7:2018 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at http://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/
3.1
traffic management plan
coordinated set of actions implemented by a number of actors such as traffic control centres, service
providers, police, authorities, or road managers aiming to minimise or prevent traffic disruption and
ensure efficient operation of the road network
3.2
scenario
an overall situation on the road network that leads road operators to initiate and run a traffic
management plan
3.3
strategy
principles that underpin a set of traffic measures or actions in order to obtain the general objectives of
the traffic management policy
EXAMPLE limit through traffic in an area; to favour a transport mode or a preferred route.
3.4
measure
specific set of actions to fulfil a specific goal, in a given scenario, which leads to a specific network
operational configuration
EXAMPLE closures with alternative itinerary, restriction for HGV, access control etc.
Note 1 to entry: It can be an isolated action, a set of actions on the same site (road section) or a set of spatially
spread actions that are executed jointly. This also includes general IT actions such as information delivery on
specific delivery channels. When the solution (= measure) is not predefined one can define a procedure to elaborate
this solution.
3.5
action
single operator action which is part of a traffic management plan measure, which is normally an
“OperatorAction”-implementation of specific messages on variable message signs, by information
delivery via other dissemination channels, etc
Note 1 to entry: It may be preventive, curative or planned, e.g.: to deliver information to road users; to spread
salt on a road in case of danger of black ice; to clear a road section of obstacles.
3.6
service request
information which is exchanged among actors for workflow coordination in activating and implementing
traffic management plans, such as an agreement on proposed strategies or measures, agreed measures /
strategies implementation, termination and cancellation request of agreed measures and strategies
4 Symbols and abbreviations
GUID Globally Unique identifier
IT Information technology
ITS Intelligent Transport Systems
PIM Platform Independent Model
TMP Traffic Management Plan
UML Unified Modelling Language
VMS Variable Message Sign
5 Conformance
This document specifies the following namespace sub-models:
— “UrbanExtensions” within Clause 7
— “ReroutingManagementEnhanced” within Clause 8
— “TrafficManagementPlan” within Clause 9
All the sub-models take use of the “Level B” extension mechanism as defined in EN 16157-1:2018.
Specification elements that relate to location information are specified in EN 16157-2:2018; common
specification elements are specified in 16157-7:2018.
Conformance with this Part shall require platform independent models from which platform specific
models are generated to comply with the UML modelling rules defined in EN 16157-1:2018 and with the
following requirements of this sub-model which are expressed in this part:
— comply with all stipulated minimum and maximum multiplicity requirements for UML elements and
relationships,
— comply with all definitions, types and ordering,
— employ optional elements as specified,
— comply with all expressed constraints.
It should be noted that conformance of a publication service with all the structural requirements stated
above does not necessarily ensure that the informational content of that service will be semantically
comprehensible.
6 UML notation
The UML notation used in this document is as described in ISO/IEC 19505. An explanation of the UML
notation used in this document is provided in EN 16157 Part 1:2018.
7 «D2Namespace» UrbanExtensions
7.1 Overview
This clause specifies an additional namespace “UrbanExtensions” which provides several extensions to
different elements of the DATEX II data model defined in EN 16157 parts 2, 3 and 7 focussed on the urban
aspects of the data model. These extensions shall follow the Level-B modelling rules defined in
EN 16157-1:2018.
Figure 1 illustrates the “UrbanExtensions” namespace and its classes. This namespace shall be located
inside the “Extension” namespace defined in EN 16157-7:2018.

Figure 1 — The “UrbanExtensions” namespace
The «D2Namespace» UrbanExtensions shall have the namespace-prefix “ubx”.
7.2 ClassifiedDelay Class
The “ClassifiedDelay” class (see Figure 2) may provide an alternative to the “Delay” class specified in
EN 16157-3:2018. In contrast to this class, the “ClassifiedDelay” class shall have unbounded multiplicity
and an aggregation to the “VehicleCharacteristics” class to specify delays classified for specific types of
vehicles.
Figure 2 — Extension to Delay
7.3 EquipmentOrSystemType Class
The “EquipmentOrSystemTypeEnum” enumeration defined in EN 16157-3:2018 shall be extended by the
enumeration on access control systems, parking sensors and traffic sensors (see Figure 3).

Figure 3 — Extension to equipment or system type
7.4 GeneralInstructionsToRoadUsers Class
The “GeneralInstructionsToRoadUsersTypeEnum” enumeration defined in EN 16157-3:2018 shall be
extended by two further enumerations with instructions for cyclists and pedestrians (see Figure 4).

Figure 4 — Extension to General instructions to road users
7.5 GeneralNetworkManagementType Class
The “GeneralNetworkManagementTypeEnum” enumeration defined in EN 16157-3:2018 shall be
extended by three further enumerations literals for general management concerning restricted areas and
tolling (see Figure 5).
Figure 5 — Extension to general network management
7.6 InfrastructureDamageType Class
The “InfrastructureDamageTypeEnum” enumeration defined in EN 16157-3:2018 shall be extended by a
literal specifying a collapsed road surface (see Figure 6).

Figure 6 — Extension to infrastructure damage
7.7 InfrastructureDescriptor Class
The “InfrastructureDescriptorEnum” enumeration defined in EN 16157-2:2018 shall be extended by
several literals specifying certain urban types of underpasses, bridges and crossings (see Figure 7).

Figure 7 — Extension to infrastructure descriptor
7.8 LaneEnum Class
The “LaneEnum” enumeration defined in EN 16157-2:2018 shall be extended by several literals, which
are generally used in the urban environment (see Figure 8).

Figure 8 — Extension to lanes
7.9 NonVehicularRoadUsers Classes
The “NonVehicularRoadUsersTypeEnum” enumeration shall specify road users that do not use a
motorised vehicle. The “GroupOfNonVehicularRoadUsersInvolved” class shall extend the “Accident” class
defined in EN 16157-3:2018. Together with the “NonVehicularRoadUser” class they build a class
structure to identify information on the number and type of persons (or animals) involved in accidents
that did not use a motorised vehicle (see Figure 9).

Figure 9 — Extension to accident for non-vehicular road users
The “NonVehicularRoadUser” class shall also be aggregated to the “NetworkManagement” class defined
in EN 16157-3:2018 to allow specifying network management measures for road users that do not use a
motorised vehicle. This shall technically be done by the Level B extension mechanism (see Figure 10).

Figure 10 — Extension to network management for non-vehicular road users
7.10 ObstructionType Class
The “ObstructionTypeEnum” enumeration defined in EN 16157-3:2018 shall be extended by three
literals concerning building work, police and firefighter operations (see Figure 11).

Figure 11 — Extension to obstruction type
7.11 RoadOrCarriagewayOrLaneManagement Class
The “RoadOrCarriagewayOrLaneManagementTypeEnum” enumeration defined in EN 16157-3:2018
shall be extended by several urban-related literals (see Figure 12).

Figure 12 — Extension to road or carriageway or lane management
7.12 StreetWorks Class
The “StreetWorks” class shall be an extension of the “Roadworks” class defined in EN 16157-3:2018 and
form a third alternative in contrast to roadworks of type maintenance or construction. Its corresponding
types for urban street works shall be defined in the “StreetWorksTypeEnum” enumeration (see
Figure 14).
Figure 13 — Extension for street works
An instance of the abstract “Roadworks” class needs a specialization, which – for technical reasons –
cannot be fulfilled by a Level B extended class such as the “StreetWorks” class. For this reason, when using
this Level B extension, the “MaintenanceWorks” of type “other” should be used (for the future, it is
intended to transform the Level B extension into inheritance).
7.13 VehicleType Class
The “VehicleTypeEnum” enumeration defined in EN 16157-7:2018 shall be extended by literals for e-
bikes, e-motorscooters and personal light electric vehicles (see Figure 14).

Figure 14 — Extension to vehicle types
8 «D2Namespace» ReroutingManagementEnhanced
8.1 Overview
This clause specifies an extension to the DATEX II data model that shall follow the modelling rules defined
in EN 16157-1:2018 and specifies an additional namespace “ReroutingManagementEnhanced” which
provides an improved alternative to the existing class model “ReroutingManagement”, defined in
EN 16157-3:2018.
The «D2Namespace» ReroutingManagementEnhanced shall have the namespace-prefix “rer”.
Figure 15 illustrates the ReroutingManagementEnhanced namespace and their classes. This namespace
shall be located inside the “Extension” namespace defined in EN 16157-7:2018.
Figure 15 — The ” ReroutingManagementEnhanced” namespace
It contains classes and attributes for information related to rerouting, alternative routes and route
capacity measures. Routing origins and destinations may be defined to specify the geographic area, for
which the rerouting management should apply. Routes may be allocated by proportions, also in
combination with certain types of vehicles for which they are valid or not valid.
The “ReroutingManagementEnhanced” class shall extend the “NetworkManagement” class (defined in
EN 16157-3:2018) by using the Level B extension rules defined in Clause 8 of EN 16157-1:2018. Due to
this construction, this class model shall be part of a Level B Extension within the SituationPublication
model (as defined in EN 16157-3:2018). Further new classes defined in this document are “Origin”,
“PointOrigin”, “AreaOrigin”, “RouteDescription”, “RouteAllocation”,
“RouteCapacityManagementMeasure” and “TrafficSignal” (see Figure 16, Figure 17 and Figure 18).
Several other classes already defined in EN 16157:2018 parts 2, 3 or 7 are used.
Figure 16 — The “ReroutingManagementEnhanced” class model
An instance of the abstract “NetworkManagement” class needs a specialization, which – for technical
reasons – cannot be fulfilled by a Level B extended class such as the
“NetworkManagementExtendedRerouting” class. For this reason, when using this Level B extension, the
“GeneralNetworkManagement” of type “other” should be used (for the future, it is intended to transform
the Level B extension into inheritance).
8.2 Semantics – Rerouting management and route description
For the rerouting management enhanced, a name (nameOfReroutingManagement) may be specified. It
shall be specified, whether the measure is advisory (it is a recommendation, and is not a requirement to
be followed) or mandatory (following a binding regulation or decision). A Situation or a SituationRecord,
related to the specific rerouting measure (for example information on roadworks) may be referenced
(see EN 16157-3:2018 clause 7.3.2.4).
With the “Origin” and “Destination” classes aggregated to the “ReroutingManagementEnhanced” class,
geographic areas or points may be defined that may serve as an indication for the geographical relevance
of the rerouting management. For example, navigation systems may use this information as triggers, if
the route management is relevant on the specific vehicle route.
One or more “RouteDescription” classes shall be aggregated to the “ReroutingManagementEnhanced”
class. One of them may use the aggregation end “originalRoute”, i.e. being the route that is obstructed or
closed or in a critical state in terms of traffic conditions. The others shall use the aggregation end
“alternativeRoute” each specifying an alternative possibility for the trip from origin to destination.
For each route, a name and a description may be specified, as well as information about entries, exits and
the road or junction number. The traffic status may be specified as well as the current travel time on the
route, by using the class “TravelTimeData” specified in EN 16157-5:2018.
The georeferenced location of each route shall be specified by using the “Itinerary” class specified in
EN 16157-2:2018. Supplementary positional description may be specified.
8.3 Semantics – Route allocation
Figure 17 shows the “RouteAllocation” class model.

Figure 17 — The “RouteAllocation” class model
The “RouteAllocation” class may be used to define proportions of traffic for routes meeting the same
overall functional routing requirement. This may include the original route. The corresponding attribute
“routeProportion” specifies the weight of this specific route against other alternative routes that perform
the same functional purpose. The sum of all possible route weights for a specified set of vehicle
characteristics shall be equal to one (100 %).
8.4 Semantics – Route capacity management
Figure 18 shows the “RouteCapacityManagementMeasure” class model.

Figure 18 — The “RouteCapacityManagementMeasure” class model
Additional capacity measures on a route may be specified by using the
“RouteCapacityManagementMeasure” class. Examples are extra lanes, modified traffic signal green stages
or altered signal phasing. For measures referring to traffic signals, a series of “TrafficSignal” classes may
be specified. With the attribute “signalGroup”, each traffic signal may refer to its “SignalHeadLocation”
specified in the “MapDataPublication” in FprCEN/TS 16157-9. Another possibility is to specify the
notional reference point of the traffic signal. The notional reference point for the traffic signal represents
the position of the midpoint of the related stop line. In the case of a non-signalised intersection the
notional reference point represents the midpoint of the related stop line.
9 «D2Namespace» TrafficManagementPlan
9.1 Overview
The «D2Namespace» TrafficManagementPlan shall have the namespace-prefix “tmp”.
The “TrafficManagementPlan” namespace contains classes and attributes for information related to two
publications that support the definition and activation of traffic management plans in the urban
environment. The two publications are:
— TmplanTablePublication which provides the details of proposed traffic management plans, including
the scenario for which they are applicable, and the definition of measures and actions that shall be
taken as part of the traffic management plan;
— TmplanOperationPublication which provides status information and status change information
relating to elements of a traffic management plan. The TmplanOperationPublication may relate to a
previously defined traffic management plan with reference to a traffic management plan within the
TmplanTablePublication, or a traffic management plan that has not previously been defined.
The two publications in the “TrafficManagementPlan” namespace shall extend the DATEX II data model
as Level B extensions of the GenericPublication class (defined in EN 16157-7:2018) by using the Level B
extension rules defined in Clause 8 of EN 16157-1:2018. Several new classes are defined in this
document. Where classes which have been previously defined are used, they are indicated in the class
diagrams contained in Figures 19, 20, 21 and 22. These reused classes are already defined in EN 16157
parts 2, 3 or 7.
The publications of the “TrafficManagementPlan” namespace seek to facilitate the exchange of
information between traffic control centres supporting workflow management to establish pre-defined
traffic management plans including measures and actions to address foreseen scenarios, and then in real-
time manage the activation, termination and other lifecycle processes related to traffic management
plans. Typically, traffic management plans may encompass agreed actions such as an Operator Action
(see EN 16157-3:2018), traffic information distribution, or road device management, such as variable
message sign settings, with the objective of managing traffic patterns, optimizing network traffic flow,
alleviation of congestion, etc. During the real-time management of traffic management plans the plans in
use can be pre-defined (with necessary collaborative agreement if needed) or by means of ad hoc plans.
Figure 19 illustrates the “TrafficManagementPlan” namespace and its constituent packages and classes.
This namespace shall be located inside the “Extension” namespace defined in EN 16157-7:2018.
Figure 19 — «D2Namespace» TrafficManagementPlan
9.2 «D2Package» TmplanTablePublication
9.2.1 Overview
The TmplanTablePublication comprises classes and relationships required to model the static data
needed to pre-define the scenario, measures and actions needed for agreement, if required, and potential
future implementation of a set of traffic management plans.
Figure 20 illustrates the “TmplanTablePublication” package and its classes.
Figure 20 — The “TmplanTablePublication” class model
9.2.2 Semantics
The “TmplanTablePublication” class shall be a Level-B extension of a “GeneralPublication” class. Each
“TmplanTablePublication” shall contain at least one “TmplanTable”. Each “TmplanTable” class instance
(forming a traffic management plan) shall contain at least one “TmplanScenarioRecord” class instance.
A traffic management plan can relate to a set of scenarios which describe the overall situation on the road
network that leads road operators to initiate and run a traffic management plan. Responses and collected
actions defined within a traffic management plan may be defined as any combination of strategies,
measures and actions, where:
— A strategy is a set of principles that underpin a set of traffic of measures or actions in order to obtain
the general objectives of the traffic management policy;
— A measure is a specific set of actions to fulfil a specific goal, in a given scenario, which leads to a
specific network operational configuration;
— An action is a single operator action which is part of a traffic management plan measure, which is
normally implemented as an Operator Action Situation Record, implementation of specific messages
on variable message signs, by information delivery via other dissemination channels, etc.
Each response shall contain one strategy or measure. Each strategy shall be associated with two or more
measures. Each measure shall be associated to one or more actions. In each case of strategy, measure
or action they may be defined by reference to an existing strategy, measure or action respectively or
new definition may be provided.
9.3 «D2Package» TmplanOperationPublication
9.3.1 Overview
The “TmplanOperationPublication” class comprises classes and relationships required to model the
information for exchange of implementation actions relating to the activation, termination, timeout of a
traffic management plan, or subservient measure(s) or action(s). Additionally, this publication supports
planning processes relating to traffic management plans enabling transmission of requests for
agreement, agreement acceptance, agreement rejection, etc.
Figure 21 illustrates the “TmplanOperationPublication” package and its classes, and the classes of the
“TmplanOperation” package that supports it.
Figure 21 — The “OperatorActionTemplate” class model
Figure 21 shows the operator action template model. Each “OperatorActionTemplate” class may be
associated with one or more target locations; also, it may be associated with one or several vehicle
characteristic profiles. Additionally, one recurring period may be specified.
Figure 22 shows the recurring period model.
Figure 22 — The “RecurringPeriod” class model
Figure 23 shows the “TmplanOperationPublication” model.

Figure 23 — The “TmplanOperationPublication” class model
9.3.2 Semantics
The “TmplanOperationPublication” class shall be a specific realizable case of a “GeneralPublication”. Each
“TmplanOperationPublication” may contain any number of TmplanOperation. Each TmplanOperation
shall references one PredefinedTmplanOperation as predefined in a traffic management plan (as
communicated by a TmplanTablePublication) or a NonPredefinedTmplanOperation that has not been
predefined. Each predefined PredefinedTmplanOperation may relate to one identified measure.
9.4 Traffic management extension for implementing action
The “TmplanImplementingAction” class is defined as a specialization of the “OperatorAction” class, using
a Level B extension, to create a linkage of an implemented traffic management plan action and an operator
action.
Figure 24 illustrates the “TmplanImplementingAction” class model.
Figure 24 — The “TmplanImplementingAction” class model
9.5 Sign setting extension
The “SignSetting” class is defined as a specialization of the “OperatorAction” class, using a Level B
extension, to create a linkage of a VMS unit status and an operator action.
Figure 25 illustrates the “SignSetting” class model.

Figure 25 — The “SignSetting” class model
An instance of the abstract “OperatorAction” class needs a specialization, which – for technical reasons –
cannot be fulfilled by a Level B extended class such as the “SignSetting” class. For this reason, when using
this Level B extension, the “GeneralNetworkManagement” of type “other” should be used (for the future,
it is intended to transform the Level B extension into inheritance).
Annex A
(normative)
Data Dictionary
A.1 Overview
This data dictionary identifies the definitions and characteristics of the different classes, attributes,
association ends, data types and enumerations appearing in the data model defined in Clause 7. The data
dictionary is specified in three parts, one for packages, one for «D2Datatypes» and one for
«D2Enumerations», each ordered alphabetically.
The generic data types which are used throughout all publications are defined in are defined in
EN 16157-7:2018, 6.3.
The first part of the data dictionary is partitioned into subclauses which relate to each of the UML model
packages and each subclause defines the contained classes, their attributes and any association ends
defined for associations between the classes within that package.
The Data Dictionary tables use the following columns:
1) Column Class name: it provides the symbolic name (Upper Camel Case) given to the corresponding
class,
2) Column Association End: it provides the symbolic name (Lower Camel Case) given to the
corresponding association end,
3) Column Attribute name: it provides the symbolic name (Lower Camel Case) given to the
corresponding attribute of a class,
4) Column Enumerated value name: It provides the symbolic name (Lower Camel Case) given to the
corresponding enumerated value,
5) Column Designation: it provides the corresponding name in natural language of the co
...