FprCEN/TS 16157-8

SLOVENSKI STANDARD
01-november-2024
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: Publikationen von
Verkehrsmanagementmaßnahmen und kommunale Ergänzungen
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: FprCEN/TS 16157-8
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.

FINAL DRAFT
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
September 2024
ICS Will supersede CEN/TS 16157-8:2020
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: Publikationen von
dédiées à l'environnement urbain Verkehrsmanagementmaßnahmen und kommunale
Ergänzungen
This draft Technical Specification is submitted to CEN members for Vote. 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, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.

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
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 16157-8:2024 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 . 7
5 UML notation . 8
6 «D2Namespace» UrbanExtensions . 8
6.1 Overview . 8
6.2 ClassifiedDelay Class. 9
6.3 EquipmentOrSystemType Class . 11
6.4 GeneralInstructionsToRoadUsers Class . 11
6.5 GeneralNetworkManagementType Class . 12
6.6 InfrastructureDamageType Class . 13
6.7 InfrastructureDescriptor Class . 13
6.8 LaneEnum Class . 14
6.9 NonVehicularRoadUsers Classes . 15
6.10 ObstructionType Class . 16
6.11 RoadOrCarriagewayOrLaneManagement Class . 17
6.12 StreetWorks Class . 18
6.13 VehicleType Class . 18
7 «D2Namespace» ReroutingManagementEnhanced . 19
7.1 Overview . 19
7.2 Semantics – Rerouting management and route description . 22
7.3 Semantics - RouteAllocation . 23
7.4 Semantics – Capacity Management . 24
8 «D2Namespace» TrafficManagementPlan . 25
8.1 Scope and Purpose of TrafficManagementPlan . 25
8.2 Key Concepts . 26
8.3 TmplanTablePublication . 27
8.4 TmplanTable . 27
8.4.1 Overview . 27
8.4.2 Scenario . 28
8.4.3 Strategy . 29
8.4.4 Measure . 29
8.4.5 Action . 30
8.4.6 OperatorActionDefinition . 31
8.4.7 TmplanOperationPublication . 33
8.5 TmplanImplementingAction . 34
Annex A (normative) Data Dictionary . 36
A.4.2 The <> "EquipmentOrSystemTypeEnumExtendedUrban" . 38
A.4.3 The <>
"GeneralInstructionToRoadUsersTypeEnumExtendedUrban" . 39
A.4.4 The <> "GeneralNetworkManagementTypeEnumExtendedUrban" . 39
A.4.5 The <> "InfrastructureDamageTypeEnumExtendedUrban" . 39
A.4.6 The <> "InfrastructureDescriptorEnumExtendedUrban" . 40
A.4.7 The <> "LaneEnumExtendedUrban" . 41
A.4.8 The <> "NonVehicularRoadUserTypeEnum" . 41
A.4.9 The <> "ObstructionTypeEnumExtendedUrban" . 41
A.4.10 The <>
"RoadOrCarriageWayOrLaneManagementTypeEnumExtendedUrban" . 42
A.4.11 The <> "StreetWorksTypeEnum" . 43
A.4.12 The <> "VehicleTypeExtendedUrban" . 43
A.5 Data Dictionary for "ReroutingManagementEnhanced" . 44
A.5.1 "Allocation" package . 44
A.5.2 "Classes" package . 47
A.6 Data Dictionary of <> for "ReroutingManagementEnhanced" . 55
A.6.1 The <> "PriorityIndex" . 55
A.7 Data Dictionary of <> for "ReroutingManagementEnhanced" . 55
A.7.2 The <> "CommentTypeEnumExtended". 55
A.7.3 The <> "CapacityManagementActionEnum" . 56
A.7.4 The <> "CapacityManagementMeasureEnum" . 56
A.7.5 on>> "ComplianceOptionEnumExtended" . 57
A.7.6 The <> "ConditionOperator" . 57
A.7.7 The <> "FacilityTypeEnum" . 58
A.7.8 The <> "PublicTransportTypeEnum" . 59
A.7.9 The <> "PublicTransportVehicleType" . 59
A.7.10 The <> "ReroutingAdviceTypeEnum" . 60
A.7.11 The <> "ReroutingTypeEnum". 60
A.7.12 The <> "TrafficTypeEnumExtended" . 61
A.8 Data Dictionary for "TrafficManagementPlan" . 61
A.8.1 "Action" package . 61
A.8.2 "Measure" package . 63
A.8.3 "OperatorActionDefinition" package . 65
A.8.4 "Scenario" package. 68
A.8.5 "TmplanOperation" package . 73
A.8.6 "TmplanOperationPublication" package . 80
A.8.7 "TmplanTable" package . 81
A.8.8 "TmplanTablePublication" package . 84
A.9 Data Dictionary of <> for "TrafficManagementPlan" . 85
A.10 Data Dictionary of <> for "TrafficManagementPlan" . 85
A.10.2 The <> "CauseTypeExtended" . 85
A.10.3 The <> "ResponseEffectTypeEnum" . 85
A.10.4 The <> "ResponseStageEnum" . 85
A.10.5 The <> "TmplanOperationStatusEnum" . 86
Annex B (normative) XML Schemas . 87
Bibliography . 114

European foreword
This document (FprCEN/TS 16157-8:2024) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the Vote on TS.
The CEN 16157 series consists of several parts under the general title “Intelligent transport systems —
DATEX II data exchange specifications for traffic management and information”.
This document will supersede CEN/TS 16157-8:2020.
CEN/TS 16157-8:2020:
• The ReroutingManagementEnhanced publication has been upgraded to improve fit with other parts
in the CEN 16157 series
• The TrafficManagementPlan publication has been revised and enhanced to make use of predefined
plans.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
Introduction
This document defines a common set of data exchange specifications to support the vision of a seamless
interoperable exchange of road traffic and travel information across boundaries, including national,
urban, interurban, road administrations, infrastructure providers and service providers.
Standardisation in this context is a vital constituent to ensure interoperability, reduction of risk,
reduction of the cost base, promotion of open marketplaces and many social, economic and community
benefits to be gained from more informed travellers, network managers and transport operators.
Deploying intelligent transport systems in line with European Sustainable and Smart Mobility Strategy
as issued by the European Commission requires co-ordination of traffic management operation and
development of seamless pan-European information services. These jointly aim at contributing to the
transformation of the European transport system for the objectives of efficient, safe, sustainable, smart
and resilient mobility.
In this context the European Commission has been supporting the development of information
exchange between the actors of road traffic management and related services for several 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 co-funding of the further evolution of the
standard and user support ecosystem. With this standardisation of DATEX II, there is a real basis for
common exchange between the actors of the traffic and travel information sector both in the
collaboration between traffic management organisations and their systems, as well as in coherent
information provision to service providers. DATEX II supports the requirements of the stakeholder
organisations involved in the road traffic and travel domain in compliance with the EU policy and legal
frameworks aimed at the sector.
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.
1 Scope
The CEN 16157 multipart standard specifies and defines component facets supporting the shared use of
data and information in the field of traffic and travel. The component facets include the modelling
approach, the data content, the data structure and relationships and the communications specification.
This document, specifies additional data model structures that are applicable for traffic management
applications in the urban environment. This document addresses data concepts to support the exchange
of traffic management plans, rerouting and extensions of the existing DATEX II core model to better
support application to the urban environment.
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:2019, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 2: Location referencing
EN 16157-3:2019, 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
3 Terms and definitions
For the purposes of this document, the terms and definitions given in the normative references and the
following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://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
predefined kind of road network situation with potential impact that would lead road operators to
initiate traffic management
Note 1 to entry: It identifies a subset of possible traffic situations. It may be arbitrarily specific yet not fixed to a
specific instance in time
3.3
strategy
coherent set of one or more traffic management measures that aims to achieve some overall effect in
response to a traffic management scenario
EXAMPLE limit through traffic in an area; to favour a transport mode or a preferred route.
3.4
measure
compound ITS service or set of one or more actions that can be performed by a road operator or other
ITS service provider, and which work together to achieve an overall effect on traffic
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 atomic traffic management action or ITS service that can be performed by a road operator or
other ITS service provider
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
UUID Universally Unique Identifier
IT Information technology
ITS Intelligent Transport Systems
PT Public transport
TMP Traffic Management Plan
TRO Traffic Regulation Order
UML Unified Modelling Language
VMS Variable Message Sign
5 UML notation
This document includes diagrams using the UML notation as defined in ISO / IEC 19505-1 [1].
NOTE Some introductory guides to UML 2 are provided in the Bibliography of EN 16157-1:2018
6 «D2Namespace» UrbanExtensions
6.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-2, EN 16157-3, and EN 16157-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.
The «D2Namespace» UrbanExtensions shall have the namespace-prefix “ubx”.
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

6.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 1 — Extension to Delay
6.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 2 — Extension to equipment or system type
6.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 3 — Extension to General instructions to road users
6.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 4 — Extension to general network management
6.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 5 — Extension to infrastructure damage
6.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 6 — Extension to infrastructure descriptor
6.8 LaneEnum Class
The “LaneEnum” enumeration defined in EN 16157-2 shall be extended by several literals, which are
generally used in the urban environment (see Figure 8).

Figure 7 — Extension to lanes
6.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 8 — 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 9 — Extension to network management for non-vehicular road users
6.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 10 — Extension to obstruction type
6.11 RoadOrCarriagewayOrLaneManagement Class
The “RoadOrCarriagewayOrLaneManagementTypeEnum” enumeration defined in EN 16157-3:2018
shall be extended by several urban-related literals (see Figure 12).

Figure 11 — Extension to road or carriageway or lane management
6.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 13).
Figure 12 — Extension to 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).
6.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 13 — Extension to vehicle types
7 «D2Namespace» ReroutingManagementEnhanced
7.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 e xisting 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 14 — 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 ReroutingManagementEnhancedStructure is shown in Figure 16.
Both “ReroutingManagementEnhanced” class and the “CapacityManagement” clas 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).
“CapacityManagement” is a new class that is added in this version of the standard. Several other classes
already defined in EN 16157-2, EN 16157-3 or EN 16157-7 are used. The
“CapacityManagementMeasure” is new and added to the “CapacityManagement” class as well.
Figure 16 — The “ReroutingManagementEnhanced” structure
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).
7.2 Semantics – Rerouting management and route description

Figure 15 — “ReroutingManagementEnhanced” and “RouteDescription” Class models
Figure 17 shows the “ReroutingManagementEnhanced” and “RouteDescription” class models.
For the ReroutingManagementEnhanced, a name (nameOfReroutingManagement) may be specified, as
well as if it concerns an advice or not (it is a recommendation and is not a requirement to be followed or
mandatory), if the measure is preventive or reactive and the type of rerouting may be described. 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).
The “Location” class (see EN 16157-2:2018) is used as an aggregation to define 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 may 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 may 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. Attributes are “capacityAvailable”, “entry, “exit”,
“isPublicTransportRoute”, “nameofRoute”, “routeClosed”, “routeLength, “signedRerouting”,
“priorityIndex” to indicate which route has a higher priority, “trafficConstriction” and “troReference” to
give a reference to a traffic regulation order.
A specific kind of destination facility for a route may be defined, as well as public transport schedule(s)
and information for service providers so that if agreements have been made between the road operator
and service provider, they know how to handle the rerouting.
The georeferenced location of each route may be specified by using the “Itinerary” class specified in
EN 16157-2:2019 . Supplementary positional description may be specified.
7.3 Semantics - RouteAllocation
Figure 18 shows the RouteAllocation class model.

Figure 16 — Route Allocation
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 %).
The “RouteAllocation” shall be either a DetailedAllocation which can contain different condition sets as
described in TrafficRegulations (see CEN/TS 16157-11:2021), or a BasicAllocation which uses the
Conditions as seen in the figure.
7.4 Semantics – Capacity Management
Figure 19 shows the “CapacityManagement” class model.

Figure 17 — Capacity Management Class
Capacity measures on a location may be specified by using the “CapacityManagement” class. This class
shall exist of one or more “CapacityManagementMeasures”.
Examples of “CapacityManagementMeasures” 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 CEN/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.
8 «D2Namespace» TrafficManagementPlan
8.1 Scope and Purpose of TrafficManagementPlan
The «D2Namespace» TrafficManagementPlan shall have the namespace-prefix “tmp”.
The “TrafficManagementPlan” namespace shall contain the 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 predefined 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 predefined 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 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.
Another purpose of the namespace is to provide elements that extend 16157-3 to allow the expression
of traffic management plans in a situation publication. (SignSetting and TmplanImplementingAction).
Figure 20 illustrates the “TrafficManagementPlan” namespace and its constituent packages and classes.

Figure 18 — «D2Namespace» TrafficManagementPlan
8.2 Key Concepts
The key concepts of traffic management plans are illustrated in Figure 21.

Figure 19 — Key concepts within traffic management plans
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 coherent set of one or more traffic management measures that aims to achieve some
overall effect in response to a traffic management scenario;
— A measure is a compound ITS service or set of one or more actions that can be performed by a road
operator or other ITS service provider, and which work together to achieve an overall effect on
traffic;
— An action is a single atomic traffic management action or ITS service that can be performed by a
road operator or other ITS service provider, 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.

8.3 TmplanTablePublication
The TmplanTablePublication package contains classes defined in this sub-clause 8.3, as illustrated in
Figure 22. The TmplanTablePublication is designed for holding all the predefined TrafficManagement
plans.
Figure 20 — TmplanTablePublication
8.4 TmplanTable
8.4.1 Overview
Figure 22 illustrates the sub-packages, the data types and the enumerations within the TmplanTable
package.
Figure 21 — TmplanTable
A single TmplanTable publication consist of any number of predefined scenarios, predefined measures,
and predefined actions. It may also contain a description and identification that points to an external
data source. It shall contain a versionTime.
The class TmplanTable is <> as defined in EN 16157-1:2018.
8.4.2 Scenario
Figure 24 illustrates the “Scenario” class model. The class Scenario is <> as
defined in EN 16157-1:2018, which allows Scenarios to be referenced in Tmplan publications.

Figure 22 — Scenario class
A Scenario is a predefined kind of road network situation with potential impact that would lead road
operators to initiate traffic management. It identifies a subset of possible traffic situations. It may be
arbitrarily specific yet not fixed to a specific instance in time.
A Scenario shall provide a versionTime and may contain a description of the scenario, a textual
description if emergency services can access the roads in the scenario, an external identification if
needed and a name.
A Scenario may reference to an organisation (as defined in TS 16157-12:2021) responsible for directing
the scenario. A Scenario may contain one or more textual description of triggers for the scenario. A
Scenario may provide one or more types that describe the cause situation by using the causeTypeEnum
enumeration defined in EN 16157-3:2018. For more detail the detailedCauseTypeEnum may be used in
addition.
The Scenario can also describe the impact on the road network it wants to achieve, when it comes to
reducing capacity.
The location of a Scenario may be specified by using the “LocationReference” class specified in
EN 16157-2:2019 . If a Scenario is valid only in certain time period this may be described using the
Validity class specified in EN 16157-7:2018.
8.4.3 Strategy
Figure 25 illustrates the “Strategy” class model.

Figure 23 — Strategy class
A Strategy is a coherent set of measures within a Traffic Management scenario.
A Strategy shall be either a predefined Strategy or a StrategyDefinition, which is a specialisation of
Strategy. A StrategyDefinition shall have a description and may contain an external identifier, an integer
that indicates a priority and a short name. A strategyDefinition may have a maximum of one overall
activation condition.
A strategyDefinition shall have one or more StrategyMeasure that can have an indication it is essential
for the Strategy and an optional index that describes the order of the StrategyMeasures. Each
StrategyMeasure shall aggregat
...