CEN/TS 16157-9:2020

SLOVENSKI STANDARD
01-julij-2020
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 9. del: Publikacije za upravljanje prometnih
signalov, namenjene mestnemu okolju
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 9: Traffic signal management publications dedicated
to the urban environment
Intelligente Verkehrssysteme - Intelligente Verkehrssysteme - DATEX II
Datenaustauschspezifikationen für Verkehrsmanagement und Verkehrsinformationen -
Teil 9: Lichtsignalanlagen-Management-Publikationen für das städtische Umfeld
Systèmes de transport intelligents - Spécification DATEX II d’échange de données pour
la gestion du trafic et l’information routière - Partie 9 : Publications pour la gestion des
feux de circulation dédiées à l'environnement urbain
Ta slovenski standard je istoveten z: CEN/TS 16157-9: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-9
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 9: Traffic signal management publications dedicated
to the urban environment
Systèmes de transport intelligents - Spécification Intelligente Verkehrssysteme - Intelligente
DATEX II d'échange de données pour la gestion du Verkehrssysteme - DATEX II
trafic et l'information routière - Partie 9 : Publications Datenaustauschspezifikationen für
pour la gestion des feux de circulation dédiées à Verkehrsmanagement und Verkehrsinformationen -
l'environnement urbain Teil 9: Lichtsignalanlagen-Management-Publikationen
für das städtische Umfeld
This Technical Specification (CEN/TS) was approved by CEN on 13 January 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-9:2020 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Conformance . 8
5 Symbols and abbreviations . 8
6 UML notation . 8
7 TheTrafficSignals model . 8
7.1 Overview . 8
7.2 <> MapDataPublication . 10
7.3 <> Geometry . 12
7.4 <> GenericLane . 14
7.5 <> NodeSetXY . 18
7.6 SignalPhaseAndTiming Publication . 20
Annex A (normative) Data Dictionary . 23
A.1 Overview . 23
A.2 Data Dictionary for “TrafficSignals” . 24
A.3 Data Dictionary of <> for “TrafficSignals” . 44
A.4 Data Dictionary of <> bits strings for “TrafficSignals” . 45
A.5 Data Dictionary of <> for “TrafficSignals” . 54
Annex B (normative) Referenced XML Schema for “TrafficSignals” . 69
B.1 Overview . 69
B.2 Schema . 69
Annex C (informative) Example publication messages . 95
C.1 MapDataPublication Example . 95
C.2 SignalPhaseAndTimingPublication Example . 97
Annex D (normative) Mapping of data concepts between CEN ISO/TS 19091 and this
document . 101
D.1 Overview . 101
D.2 Mapping of data concepts . 101
Bibliography . 114

European foreword
This document (CEN/TS 16157-9:2020) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request given to CEN by the European
Commission and the European Free Trade Association.
As a user of this document, attention is drawn to the resources of
www.datex2.eu < http://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) 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) 2015/962 of 18 December 2014 regarding the provision
of EU-wide real-time traffic information services,
— 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 9 of the CEN 16157 series, deals with the publication of traffic signal related
information that is most relevant in the urban environment. It specifies the structures and definitions of
information that may be exchanged within two publications:
— The Map Data publication conveys static information related to the intersections and road segments
belonging to a road network, related to traffic signal-controlled intersections. The Map Data
Publication is the translation in UML of the MapData message (MAP) as it is defined in
CEN ISO/TS 19091 and its European profile.
— The Traffic Signal Phase and Timing Publication conveys the dynamic information related to traffic
signal-controlled intersections belonging to a road network. Traffic Signal Phase and Timing
Publication is the translation in UML of the SignalPhaseAndTiming message (SPAT) as it is defined in
CEN ISO/TS 19091 and its European profile.
Both publications are specified as Level B Extensions to the DATEX II model.
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 [1]). The focus of M/546 is Intelligent Transport Systems in the urban
environment – but this does not preclude this document being used in the non-urban environment.
It is noted that the terms and concepts utilized in this document draw heavily on those defined in
CEN ISO/TS 19091 and SAE J2735.
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 9, this document, specifies additional data model structures that are applicable for traffic signal
management applications in the urban environment. This part specifies data concepts to support the
exchange of traffic signal status messaging, intersection geometry definition and attribution in a
consistent way with existing C-ITS standards and technical specifications.
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, Intelligent transport systems - DATEX II data exchange specifications for traffic management
and information - Part 2: Location referencing
EN 16157-7:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 7: Common data elements
CEN ISO/TS 19091:2017, Intelligent transport systems – Cooperative ITS – Using V2I and I2V
communications for applications related to signalized intersections
SAE J2735:2016, Dedicated Short Range Communications (DSRC) Message Set Dictionary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 16157-1, EN 16157-2 and
EN 16157-7 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
bit string
simple type whose distinguished values are an ordered sequence of zero, one or more bits
[SOURCE: ISO/IEC 8824-1:2015]
3.2
egress path
egress
flow of vehicular or other types of traffic leaving an intersection on one or more of the defined lanes of
travel
[SOURCE: SAE J2735:2016]
3.3
ingress path
ingress
flow of vehicular or other types of traffic approaching an intersection on one or more of the defined lanes
of travel
[SOURCE: SAE J2735:2016]
3.4
lane
strip of carriageway intended to accommodate a single line of moving vehicles, frequently defined by road
markings
[SOURCE: ISO 6707-1:2017]
3.5
link
directed topological connection between two nodes, composed of an ordered sequence of one or more
segments and represented by an ordered sequence of zero or more shape points
[SOURCE: ISO/TS 20452:2007]
3.6
manoeuvre
collection of related links and turns used in a route in combination
Note 1 to entry: Manoeuvres are used to cluster turns into convenient and legal combinations. They could be as
simple as a single turn, a combination of quick turns or very complex combinations consisting of entry, exit, and
connecting roadways.
[SOURCE: EN ISO 19133:2007]
3.7
node
0-dimensional topological primitive
[SOURCE: EN ISO 19107:2005]
3.8
vehicle trajectory
trajectory
path of a selected point on the vehicle in the earth-fixed coordinate system
|SOURCE: ISO 8855:2011]
4 Conformance
The Traffic Signals Namespace sub-model is a part of the DATEX II platform independent data model. The
Traffic Signals Namespace sub-model corresponds to a Level B extension as defined in EN 16157-1.
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 and with the
following requirements of this sub-model, which are expressed in this document:
— 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.
5 Symbols and abbreviations
DE Data Element
DF  Data Frame
GUID  Globally Unique identifier
ITS  Intelligent Transport Systems
PIM  Platform Independent Model
SPaT  Signal Phase and Timing
UML  Unified Modelling Language
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-1.
7 TheTrafficSignals model
7.1 Overview
The TrafficSignals model shall comprise the packages used in the SignalPhaseAndTiming Publication and
the MapData Publication and the Classes and Enumerations specific for these publications. Figure 1
illustrates the sub-packages contained within the Traffic Signals package, which shall include the
SignalPhaseAndTimingPublication package, the MapDataPublication package, the data types and the
enumerations within the <> TrafficSignals.

Figure 1 — The “TrafficSignals” package class model
As illustrated in Figure 2, the “SignalPhaseAndTimingPublication” class and the “MapDataPublication”
class shall be specializations of the GenericPublication class, as specified in CEN / EN16157-7, with the
relationships defined as D2LevelBExtension. A dedicated namespace “TrafficSignals” has been created to
host them, which uses the namespace prefix “tsi”.
NOTE For most applications using the TrafficSignals, model use of both the SignalPhaseAndTiming and
MapData Publications can be expected due to the cross-referencing between the two Publications.
Figure 2 — The “TrafficSignals” publications
7.2 <> MapDataPublication
7.2.1 Overview
The package “MapDataPublication” supplies classes and attributes for the static information related to
the intersections and road segments belonging to a road network. The “MapDataPublication” class shall
be defined as a Level B Extension to the “GenericPublication” class. The package “MapDataPublication” is
the translation in UML of the MapData message (MAP) as specified in CEN ISO/TS 19091 and specifically
its European profile (Annex G), which heavily relies upon terms, definitions and concepts from the
standard SAE J2735. It is pictured including the relationships between the classes in Figure 3.
The MapDataPublication is used in combination with the second publication defined in this document,
i.e. “SignalPhaseAndTimingPublication” which represents the dynamic content of the stages and phase of
traffic signals. As both publications are DATEX II extensions they are located in the “Extension”
namespace of the DATEX II tree structure, under the parent package “TrafficSignals”.
Figure 3 — The MapPublication class model
7.2.2 Semantics
The entry point of this package is the class “MapDataPublication”. Being an extension, it is derived from
the “GenericPublication” class defined in EN 16157-7. It shall contain at least a set of data defining
different road geographic features (class “MapData”). As every publication in DATEX II it is associated
with general information (class “HeaderInformation”) representing among others its status (e.g. if it is
“real” or for “test”). This latter class in defined in EN 16157-7.
This set of road geographic features may include data related to:
— Complex intersections description (class “IntersectionGeometry”) (up to 32 different instances);
— Road segments description (class “RoadSegment”) (up to 32 instances);
— Restrictions applicable to a road user category (class “RestrictionClassAssignment”) (up to 254
instances);
— The position of traffic signal heads (class “SignalHeadLocation”) (up to 64 instances).
Each occurrence of map data may be timestamped.
Every intersection description and every road segment description are based on a common geometrical
description realized by the “Geometry” class. Each occurrence of the class is identified through the
identification mechanism of DATEX II as specified in EN 16157-7 (stereotype “D2VersionedIdentifiable”).
It shall own a revision number (between 0 and 127) incremented at each revision to communicate the
valid release of the geometry description for the same publisher. If there is no change in the deployed
geometry description, the same revision counter is transmitted. If a revised deployment of the geometry
description (e.g. new lane added, identifiers changed, etc.), the revision number is increased by one. This
number shall be reinitialised, when the publisher changes, or when the value 127 is reached.
Every occurrence of geometry may be given a name and/or a lane width, which is used as a default value
for all the described lanes unless a new lane width is provided. It shall be given a unique external
reference identification (class “GeometryReferenceId”) which shall be composed of an identifier (integer
number between 256 and 65535). In case of testing usage, the corresponding flag (“testing”) shall be set
to “true”. The “region” attribute may be used to identify a local road authority assigning generic reference
identification for intersection geometries or road segments.
NOTE The usage of such an external reference identification is only of interest for creating MAP and SPAT
messages. It is not used internally.
Every position of traffic signal head is defined by a geographic point defined by coordinates (according
to CEN ISO/TS 19091:2017,G.5.2.7, this definition shall be tridimensional).
7.3 <> Geometry
7.3.1 Overview
The package “Geometry” supplies classes and attributes for the definition of a geometry usable when
defining geometric features of an intersection or a road segment including the relevant attributive items
of these features. It is pictured including the relationships between the classes in Figure 4.
Figure 4 — “Geometry” package class model
7.3.2 Semantics
The common geometry description is defined by the class “Geometry” which is already defined in 7.2.2.
To this geometry are associated:
— One point location (class “PointByCoordinates” associated through “refPoint”) which represents a
reference of this intersection of this road segment (e.g. for representational purpose). According to
CEN ISO/TS 19091 this point shall be defined in three dimensions. This point is defined as required
in EN 16157-2. This point may be used for calculating the offsets of the other points belonging to the
same geometry during the MAP message generation;
— A set of up to 9 speed limit values (class “RegulatorySpeedLimit”) applicable to the whole geometric
element and corresponding to certain types and to the vehicle type (class “VehicleCharacteristics”).
This latter class is defined in EN 16157-7;
— A set of up to 255 generic lane definition (class “GenericLane) which allow describing every lane
belonging to the Geometry feature in terms of geometry, topology and attributes.
The “<>Geometry” class shall be the only entry point of the “Geometry” package and is a
specific VersionIdentifiable instance.
7.4 <> GenericLane
7.4.1 Overview
The package “GenericLane” supplies classes and attributes for the definition of a generic lane part of an
intersection or a road segment including the relevant attributive items of these features. It is pictured
including the relationships between the classes in Figure 5.
The notion of generic lane is taken in a very wide meaning. Items, such as “pedestrian crossing”,
“pavement” or “parking lanes”, are also considered as “generic lanes”.
Figure 5 — “GenericLane” package class model
7.4.2 Semantics
A generic lane is defined as an elementary element of a road. Its description includes a geometric
description of its centreline (class “NodeListXY”), information about attributes (class “LaneAttributes”)
and about connectivity to other lanes (classes “Connection” and “ConnectionTrajectory”). Each
occurrence of generic lane shall have an external lane identifier, which is used when building MAP
messages. If the identity of LaneId is unknown the LaneId attribute shall not be supplied. Information on
the allowed manoeuvres may be added using the attribute “manoeuvres”. When another lane shares a
part of its reference centreline with the considered generic lane, the references of these lanes are added
through the class “OverlayLane”.
The geometric definition of this lane can be achieved using two methods:
— Using a sequence of nodes (class “NodeSetXY”). This method is specified in 7.5;
— By computing it from another lane geometry by using mathematical transformation as translations,
rotation and/or homothecy (class “ComputedLane”).
The connectivity with other lanes is defined in two ways:
— The first way is based on the class “ConnectionTrajectory” that links it with a sequence of nodes (class
“NodeSetXY”) with a given traffic signals stage (class “LaneConnection”). Only up to 4 trajectories are
allowed being defined following this way and according to CEN ISO/TS 19091:2017, G.5.1.2. In case
a lane has more than 4 connecting trajectories, priority should be given to connecting trajectories of
motorised traffic and complex manoeuvres. Figure 6 (source: CEN ISO/TS 19091:2017, Figure G.3)
illustrates how such a connection trajectory is defined.
Key
L6-01 first node of L6 (egress lane)
L2-01 first node of L2 (ingress lane)
T2-01 first node of Trajectory
T2-07 last node of Trajectory
Trajectory connecting lane 2 with lane 6
Figure 6 — ConnectionTrajectory (Source: CEN ISO/TS 19091:2017)
EXAMPLE The connecting trajectory on this figure is defined between the ingress lane 2 and the egress lane 6.
The two nodes T2–07 and L6–01 share the same point location.
— The second way is based on the class “Connection” that links it with another lane (class
“ConnectingLane”) and optionally with a traffic signals group (attribute “signalGroup” which refers
to the class “SignalHeadLocation” see 7.2.1) and/or a user restriction class assignment (attribute
“userClass” which refers to the class “RestrictionClassAssignment”). According to SAE J2735:2016,
6.14, the attribute “signalGroup” shall be provided except in case the intersection is not signal
controlled. Up to 16 connections are allowed being defined following this way. Figure 7 (source:
CEN ISO/TS 19091:2017, Figure G.5) illustrates how such a connection is defined.
Key
L6-01 first node - egress lane
L6-02 last node - egress lane
L2-01 first node - stop bar - ingress lane
L2-02 last node - ingress lane
L09-01 first node - egress lane
L09-02 last node - egress lane
EXAMPLE The lane 2 of the Figure 7 is connected through the class “Connection” (association end
“connectsTo”) to the other lanes 6 and 9.
Figure 7 — Vehicle Lane (source: CEN ISO/TS 19091:2017)
The attributes of a generic lane are assigned using the class “LaneAttributes”. There is information about
the direction of use of the lane (in terms of ingress or egress movement), if the lane is shared by different
users (e.g. by pedestrians and cyclists) or if there are vehicle restrictions (height or weight). In addition,
a set of indicators are added with the class “LaneTypeAttributes”. These indicators are specific to the type
of lane, i.e. if it is a lane assigned to vehicles (class “VehicleLane”), or to bicycles (class “BicycleLane”) or
to rail vehicles (class “RailVehicleLane”) or if is a pedestrian crossing (class “PedestrianCrossing”) or a
pavement (class “Pavement”) or a central reservation (class “CentralReservation”) or for striping (class
“Striping”).
7.5 <> NodeSetXY
7.5.1 Overview
The package “NodeSetXY” supplies classes and attributes for the definition of a geometric path of a lane
including attributive items of these features. It is pictured including the relationships between the classes
in Figure 8.
Figure 8 — “NodeSetXY” package class model
7.5.2 Semantics
A geometric path of a lane is defined by a set of up to 63 nodes (class “NodeXY”) (with at least 2 instances
as a minimum).
A node is a 0-dimensional topological primitive (as defined by EN ISO 19107:2005) that is defined by:
— A three-dimensional point by coordinates delineating this node geometrically (class
“PointByCoordinates”). This definition complies with EN 16157-2;
— Optionally an attribute set (class “NodeAttributeSetXY”) which includes the corresponding node
identifier (class “NodeId” with the association end “nodeId”) and the identifiers of up to 5 identifiers
of nodes linked to the considered node (through the association end “nodeIdLink”). It helps to
precisely describe a link from a lane node to one or more nodes of another lane (see
CEN ISO/TS 19091:2017, G.8.2.9). It may also include the local lane width at this location and
different additional attributes.
These additional attributes are:
— A set of up to 8 attributes characterizing the node itself (seen as a point) (attribute “localNode”).
EXAMPLE: if the attribute “localNode” contains the value “stopLine” (enumeration item from the enumeration
“NodeAttributeXYEnum” – see A.4.5) it means that a stop line exists across the considered lane.
— Two sets of up to 8 attributes characterizing the segment defined by the node and the subsequent
one (seen as a straight line). Each list is associated with the status attributes (“enable” and “disable”),
which reflects whether it is enabled or disabled.
EXAMPLE: if the attribute “enable” contains the value “mergingLaneLeft” (enumeration item from the
enumeration “SegmentAttributeXYEnum” – see A.4.9) it means that the left side lane is merging with the considered
lane).
— The “ptvRequest” attribute is used to qualify an activation request (used for C-ITS migration of legacy
public transport prioritization systems – see CEN ISO/TS 19091:2017, G.5.3.2).
7.6 SignalPhaseAndTiming Publication
7.6.1 Overview
The package “SignalPhaseAndTimingPublication” supplies classes and attributes for the dynamic
information related to the intersections belonging to a road network. It is the translation in UML of the
SignalPhaseAndTiming message (SPAT), as it is defined in the standard SAE J2735. It is pictured including
the relationships between the classes in Figure 9.
It is used in relation with the first publication defined in this document, i.e. “MapDataPublication”, which
represents the static content of the traffic signals. It shares the same namespace TrafficSignals with the
namespace prefix “tsi”.
Figure 9 — SignalPhaseAndTimingPublication” package class model
7.6.2 Semantics
The entry point of this package is the class “SignalPhaseAndTimingPublication”. Being an extension, it is
derived from the “GenericPublication” class defined in EN 16157-7. It shall contain at least a set of data
defining the status (class “SignalPhaseAndTiming”) of a set of 1 to 32 intersections (class
“IntersectionState”). The class “SignalPhaseAndTiming” may carry a descriptive name of the set, the
creation timestamp and the binary version (using UPER encoding as specified in ISO/IEC 8825-2) of the
corresponding SPAT message. As every publication in DATEX II it is associated with general information
(class “HeaderInformation”) representing among others its status (e.g. if it is “real” or for “test”). This
latter class is defined in EN 16157-7.
Each occurrence of the class “SignalPhaseAndTiming” shall be related to an occurrence of the class
“IntersectionGeometry”, which contains the descriptive data of the considered intersection for which
signal phase and timing information is provided. It shall also contain status information about the
corresponding signal controller. It may have a descriptive name for the intersection and a creation time
stamp. When revocable lanes are present in the corresponding map data definition (e.g. a tidal lane or a
hard shoulder is opened to traffic) and marked as it, it is possible to identify their status change through
the class “EnabledLane”.
To each occurrence of “IntersectionState” correspond a number of stage descriptions each corresponding
to a movement (class “MovementState”) is related to a group of traffic signal heads defined through the
MAP data publication. Additional Boolean attributes shall be used for indicating if this group identifier is
unavailable (attribute “signalGroupUnknownOrUnavailable”), or if the movement corresponds to a
permanent green movement (attribute “permanentGreenMovementStatus”). In turn, an occurrence of
“MovementState” is composed of one or several signal stages associated to the movement. Optional
information on advisory speeds (e.g. associated to a green wave) or details about the corresponding stage
time (start or end) may be added.
In case prioritization procedure (like for public transport) is active additional information about the
corresponding ITS station identifier (ITS-S-ID), the corresponding traffic signal group and the response
status is provided through the class “PrioritisationResponse”.
Additional information on lane and manoeuvre (class “ConnectionManoeuvreAssist”) may be brought
either globally to the intersection (associated to the class “IntersectionState”) or to a specific movement
(when associated with the class “MovementState”). This additional information can relate to queue
length, available storage length or if a pedestrian or a cyclist is detected. The attribute “connectionId” is
used to associate a given movement stage to an already defined group of lanes through the class
“LaneConnection” (see 7.4).
Annex A
(normative)
Data Dictionary
A.1 Overview
This data dictionary includes 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 <> and one
for <> , each ordered alphabetically.
The generic data types that are used throughout all publications are defined in EN 16157-7:2018, 6.3.
The first part of the data dictionary is partitioned into subclauses that 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 corresponding
class, attribute, association end or enumeration value,
6) Column Definition: it provides a comprehensive definition detailing the class, attribute or association
end,
7) Column Stereotype: it provides a statement of the stereotype that is assigned to the class, if any - see
EN 16157-1:2018, 6.2 for further details,
8) Column Abstract: it provides a statement as to whether the class is abstract (non-realizable) or
concrete (realizable),
9) Column Multiplicity: it provides a statement of the allowed multiplicity for the attribute or
association end,
10) Column Target: It provides the name of the class which is at the end of the association to which the
role applies,
11) Column Type: it provides the name of the class used to define the data type relating to the attribute
of the class.
A.2 Data Dictionary for “TrafficSignals”
A.2.1 “GenericLane” package
A.2.1.1 Location of “GenericLane” package
The location of “GenericLane” package is:
— D2Payload/Extension/TrafficSignals/MapDataPublication/GenericLane
A.2.1.2 Classes of the “GenericLane” package
Table A.1 — Classes of the “GenericLane” package
Class name Designation Definition Stereotype Abstract
BicycleLane Bicycle lane Lane dedicated to bicycle traffic. D2Class no
CentralReservation Central reservation Area separating the carriageways of a dual carriageway road. D2Class no
ComputedLane Computed lane Computational parameters of one lane from another lane. D2Class no
ConnectingLane Connecting lane Lane connected to the given lane through specific manoeuvres. D2Class no
Connection Connection Set of data detailing how the stop line at the end of a single lane D2Class no
connects to another lane beyond its stop point. [Adapted from
SAE J2735:2016]
ConnectionTrajectory Connection trajectory Trajectory for travelling through the conflict area of an D2Class no
intersection. The trajectory is defined by two or more nodes.
[Source: CEN ISO/TS 19091:2017]
GenericLane Generic lane Lane of any type described by a set of basic attributes. D2Class no
LaneAttributes Lane attributes Set of constant parameters used for the lane description of any D2Class no
type (constant means valid along the path of the lane). [Adapted
from SAE J2735:2016]
LaneConnection Lane connection Lane connected to the given lane. D2Class no
Class name Designation Definition Stereotype Abstract
LaneTypeAttributes Lane type attributes Overall characteristics of a lane of any type. [Adapted from D2Class yes
SAE J2735:2016]
NodeListXY Node list X Y Sequence of points describing the geometric path of the reference D2Class yes
centreline of the lane.
OverlayLane Overlay lane Other lane sharing the same layout as the considered lane. D2Class no
ParkingLane Parking lane Part of a street dedicated for vehicle parking. D2Class no
Pavement Pavement Pavement or pedestrian footway. D2Class no
PedestrianCrossing Pedestrian crossing Part of a street used by pedestrians to cross it. D2Class no
RailVehicleLane Rail vehicle lane Part of a street dedicated to railed vehicles. D2Class no
Striping Striping Horizontal road markings, often painted, denoted sections of the D2Class no
carriageway not intended for vehicular use, or designated for a
specific use.
VehicleLane Vehicle lane Part of a street usable by general traffic. D2Class no
A.2.1.3 Associations of the “GenericLane” package
Table A.2 — Associations of the “GenericLane” package
Class name Association end Designation Definition Multiplicity Target
Connection connectingLane Connecting lane  1.1 ConnectingLane
connectionId Connection ID  0.1 LaneConnection
ConnectionTrajectory nodes Nodes  1.1 NodeSetXY
connectionId Connection ID  1.1 LaneConnection
GenericLane laneAttributes Lane attributes  1.1 LaneAttributes
nodeList Node list  1.1 NodeListXY
connectsTo Connects to  0.16 Connection
Class name Association end Designation Definition Multiplicity Target
overlays Overlays  0.5 OverlayLane
connectionTrajectory Connection trajectory  0.4 ConnectionTraje
ctory
LaneAttributes laneType Lane type  1.1 LaneTypeAttrib
utes
A.2.1.4 Attributes of the “GenericLane” package
Table A.3 — Attributes of the “GenericLane” package
Class name Attribute name Designation Definition Multiplicity Type
BicycleLane bicycleLane Bicycle lane Characteristics of a bicycle lane. 1.1 LaneAttributesB
icycle
CentralReservation centralReservation Central reservation Characteristics of a central reservation. 1.1 LaneAttributesB
arrier
ComputedLane offsetXAxis Offset x-axis Offset value along the x-axis in case of 1.1 MetresAsFloat
translation (longitude) (between
−32,767 m and +32,767 m).
offsetYAxis Offset y-axis Offset value along the y-axis in case of 1.1
...