CEN/TS 16157-8:2026

SLOVENSKI STANDARD
01-oktober-2026
Nadomešča:
SIST-TS CEN/TS 16157-8:2020
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
vodenju 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: CEN/TS 16157-8:2026
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
July 2026
TECHNISCHE SPEZIFIKATION
ICS 35.240.60 Supersedes 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 Technical Specification (CEN/TS) was approved by CEN on 8 June 2026 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, Türkiye 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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16157-8:2026 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 . 10
6.4 GeneralInstructionsToRoadUsers Class . 11
6.5 GeneralNetworkManagementType Class . 12
6.6 InfrastructureDamageType Class . 12
6.7 InfrastructureDescriptor Class . 13
6.8 LaneEnum Class . 13
6.9 NonVehicularRoadUsers Classes . 14
6.10 ObstructionType Class . 15
6.11 RoadOrCarriagewayOrLaneManagement Class . 16
6.12 StreetWorks Class . 17
6.13 VehicleType Class . 18
7 «D2Namespace» ReroutingManagementEnhanced . 19
7.1 Overview . 19
7.2 Semantics – Rerouting management and route description . 21
7.3 Semantics - RouteAllocation . 22
7.4 Semantics – Capacity Management . 23
8 «D2Namespace» TrafficManagementPlan . 24
8.1 Scope and purpose of TrafficManagementPlan . 24
8.2 Key concepts . 25
8.3 TmplanTablePublication . 25
8.4 TmplanTable . 26
8.4.1 Overview . 26
8.4.2 Scenario . 27
8.4.3 Strategy . 28
8.4.4 ActivationConditions . 28
8.4.5 Measure . 29
8.4.6 Action . 30
8.4.7 OperatorActionDefinition . 30
8.4.8 TmplanOperationPublication . 33
8.5 TmplanImplementingAction . 34
Annex A (normative)  Data Dictionary . 35
A.1 Overview . 35
A.2 Data Dictionary for "UrbanExtensions" . 35
A.3 Data Dictionary of <> for "UrbanExtensions" . 37
A.4 Data Dictionary of <> for "UrbanExtensions" . 38
A.5 Data Dictionary for "ReroutingManagementEnhanced" . 45
A.6 Data Dictionary of <> for "ReroutingManagementEnhanced" . 55
A.7 Data Dictionary of <> for "ReroutingManagementEnhanced" . 55
A.8 Data Dictionary for "TrafficManagementPlan" . 63
A.9 Data Dictionary of <> for "TrafficManagementPlan" . 86
A.10 Data Dictionary of <> for "TrafficManagementPlan" . 86
Annex B (normative) XML Schemas . 89
B.1 Overview . 89
B.2 Schema UrbanExtensions . 89
B.3 Schema ReroutingManagementEnhanced . 90
B.4 Schema TrafficManagementPlan . 96
Bibliography . 104

European foreword
This document (CEN/TS 16157-8:2026) 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 supersedes CEN/TS 16157-8:2020.
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”.
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.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organizations 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, Türkiye 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 road 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 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 the 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 the making, 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 standardization 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 organizations and their systems, as well as in coherent
information provision to service providers. DATEX II supports the requirements of the stakeholder
organizations involved in the road traffic and travel domain in compliance with the EU policy and legal
frameworks aimed at the sector.
1 Scope
This document specifies 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: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
CEN/TS 16157-11:2025, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 11: Publication of machine interpretable traffic regulations
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 16157-1:2018 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 minimize 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.
Note 2 to entry: 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 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.
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
The details of model elements in this namespace are further defined in normative Annex A, and
corresponding XML Schemas are defined in normative Annex B.

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 2 — 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 3 — 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 4 — 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 enumeration literals for general management concerning restricted areas
and tolling (see Figure 5).
Figure 5 — 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 6 — Extension to infrastructure damage

6.7 InfrastructureDescriptor Class
The “InfrastructureDescriptorEnum” enumeration defined in EN 16157-2:2019 shall be extended by
several literals specifying certain urban types of underpasses, bridges and crossings (see Figure 7).

Figure 7 — 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 8 — Extension to lanes
6.9 NonVehicularRoadUsers Classes
The “NonVehicularRoadUsersTypeEnum” enumeration shall specify road users that do not use a
motorized 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 motorized 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 motorized 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
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 11 — 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 12 — 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 13 — 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 14 — 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 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 its 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 ReroutingManagementEnhancedStructure is shown in Figure 16.
Both “ReroutingManagementEnhanced” class and the “CapacityManagement” 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).
“CapacityManagement” is a new class that is added in this version of the standard. Several other classes
already defined in 16157-2:2019, 16157-3:2018 or 16157-7:2018 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).
The details of model elements in this namespace are further defined in normative Annex A, and
corresponding XML Schemas are defined in normative Annex B.

7.2 Semantics – Rerouting management and route description

Figure 17 “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, 7.3.2.4).
The “Location” class (see EN 16157-2:2019) is used as an aggregation to define geographic areas or
points that may be defined and 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 (TRO).
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 18 — 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:2025), 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 19 — Capacity Management Class
Capacity measures on a location may be specified by using the “CapacityManagement” class. This class
shall consist 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 [3]. 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-signalized
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 20 — «D2Namespace» TrafficManagementPlan
The details of model elements in this namespace are further defined in normative Annex A, and
corresponding XML Schemas are defined in normative Annex B.
8.2 Key concepts
The key concepts of traffic management plans are illustrated in Figure 21.

Figure 21 — 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 subclause 8.3, as illustrated in
Figure 22. The TmplanTablePublication is designed for holding all the predefined traffic management
plans.
Figure 22 — TmplanTablePublication
8.4 TmplanTable
8.4.1 Overview
Figure 23 illustrates the sub-packages, the data types and the enumerations within the TmplanTable
package.
Figure 23 — TmplanTable
A single TmplanTable publication consists 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 24 — 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 an organization (as defined in CEN/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 a 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 25 — 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 specialization 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 aggregate to one Measure. A StrategyMeasure may also have a maximum of one
activation condition.
8.4.4 ActivationConditions
Figure 26 describes the “ActivationConditions” class model. ActivationConditions describe the kind of
activation of a StrategyDefinition or a StrategyMeasure. The attributes of the ActivationConditions are
automaticallyApproved, automaticallyDeactivated and AutomaticallyImplemented. All three are
Booleans.
An ActivationDelay may be added to ActivationConditions to describe the ActivationDelay or
deactivationDelay in seconds.
ActivationConditions may also contain two Conditions namely one activationTrigger and/or one
deactivationTrigger. These may be a TriggerCondition. The TriggerCondition is a specialization of
Condition and shall contain a triggerDefinition and may contain a description.

Figure 26 — ActivationConditions class

8.4.5 Measure
Figure 27 illustrates the “Measure” class model. 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.

Figure 27 — Measure class
A Measure shall contain a versionTime. A CompositeMeasure is a specialization of a Measure that will
contain 2 or more Measures.
A Measure shall be either a predefined Measure or a MeasureDefinition, which is a specialization of
Measure. A MeasureDefinition shall have a description and a reference to a responsible road operator
and may contain an external identifier and a short name. A MeasureDefinition may have a maximum of
one activation condition (see subclause 8.4.3). Each MeasureDefinition shall have one or more Actions.
8.4.6 Action
Figure 28 illustrates the “Action” class model. 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.

Figure 28 — Action class
An Action shall contain a versionTime.
An Action shall be either a predefined Action or an ActionDefinition, which is a specialization of Action.
An ActionDefinition shall have a description and may contain an external identifier. An ActionDefinition
may have a maximum of one (de)activation delay in seconds. The party implementing the action can be
added as well. The Action may also aggregate to one OperatorActionDefinition.
8.4.7 OperatorActionDefinition
Figure 29 illustrates the “OperatorActionDefinition” class model.
This package co
...