CEN/TS 16157-3:2011

SLOVENSKI STANDARD
01-november-2011
1DGRPHãþD
SIST ENV 13106:2003
SIST ENV 13777:2003
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 3. del: Objava situacije
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 3: Situation Publication
Intelligente Verkehrssysteme - DATEX II Datenaustauschspezifikation für
Verkehrsmanagement und Verkehrsinformation - Teil 3: Publikation von
Verkehrssituationen
Systèmes de transport intelligents - Spécifications DATEX II d'échange de données pour
la gestion du trafic et l'information routière - Partie 3: Publication de situations
Ta slovenski standard je istoveten z: CEN/TS 16157-3:2011
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16157-3
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
October 2011
ICS 35.240.60 Supersedes ENV 13106:2000, ENV 13777:2000
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information - Part 3:
Situation Publication
Systèmes de transport intelligents - Spécifications DATEX Intelligente Transportsysteme - DATEX II Datenaustausch
II d'échange de données pour la gestion du trafic et Spezifikationen für Verkehrsmanagement und
l'information routière - Partie 3: Publication de situations Informationen - Teil 3: Situationsveröffentlichungen
This Technical Specification (CEN/TS) was approved by CEN on 10 April 2011 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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16157-3:2011: E
worldwide for CEN national Members.

Contents Page
Introduction .7
1 Scope .8
2 Conformance .8
3 Normative references .9
4 Terms and definitions .9
5 Symbols and abbreviations . 10
6 UML notation . 11
7 The Situation Publication model . 11
7.1 Overview of the Situation Publication model . 11
7.2 The “SituationPublication” package. 11
7.2.1 Overview of the “SituationPublication” package . 11
7.2.2 Semantics of the “SituationPublication” package . 12
7.3 The “SituationRecord” package . 13
7.3.1 Overview of the “SituationRecord” package . 13
7.3.2 Semantics of the “SituationRecord” package . 14
7.4 The “Impact” package . 16
7.4.1 Overview of the “Impact” package . 16
7.4.2 Semantics of the “Impact” package . 17
7.5 The “Validity” package . 18
7.5.1 Overview of “Validity” package . 18
7.5.2 Semantics of the “Validity” package . 20
7.6 The “TimePeriodOfDay” package . 21
7.6.1 Overview of the “TimePeriodOfDay” package . 21
7.6.2 Semantics of the “TimePeriodOfDay” package . 21
7.7 The “NonRoadEventInformation” package . 22
7.7.1 Overview of the “NonRoadEventInformation” package . 22
7.7.2 Semantics of the “NonRoadEventInformation” package . 22
7.8 The “TrafficElement” package . 23
7.8.1 Overview of the “TrafficElement” package . 23
7.8.2 Semantics of the “TrafficElement” package . 24
7.9 The “Conditions” package . 25
7.9.1 Overview of the “Conditions” package . 25
7.9.2 Semantics of the “Conditions” package . 25
7.10 The “WeatherRelated” package . 26
7.10.1 Overview of the “WeatherRelated” package . 26
7.10.2 Semantics of the “WeatherRelated” package . 27
7.11 The “Humidity” package . 27
7.11.1 Overview of the “Humidity” package . 27
7.11.2 Semantics of the “Humidity” package. 27
7.12 The “Temperature” package . 28
7.12.1 Overview of the “Temperature” package . 28
7.12.2 Semantics of the “Temperature” package . 28
7.13 The “Visibility” package . 29
7.13.1 Overview of the “Visibility” package . 29
7.13.2 Semantics of the “Visibility” package . 29
7.14 The “Wind” package . 30
7.14.1 Overview of the “Wind” package . 30
7.14.2 Semantics of the “Wind” package . 30
7.15 The “Pollution” package . 31
7.15.1 Overview of the “Pollution” package . 31
7.15.2 Semantics of the “Pollution” package . 31
7.16 The “PrecipitationDetail” package . 32
7.16.1 Overview of the “PrecipitationDetail” package . 32
7.16.2 Semantics of the “PrecipitationDetail” package . 32
7.17 The “RoadSurfaceConditionMeasurements” package . 33
7.17.1 Overview of the “RoadSurfaceConditionMeasurements” package . 33
7.17.2 Semantics of the “RoadSurfaceConditionMeasurements” package . 33
7.18 The “Accident” package . 34
7.18.1 Overview of the “Accident” package . 34
7.18.2 Semantics of the “Accident” package . 35
7.19 The “Obstruction” package . 36
7.19.1 Overview of the “Obstruction” package . 36
7.19.2 Semantics of the “Obstruction” package . 37
7.20 The “Activity” package . 38
7.20.1 Overview of the “Activity” package . 38
7.20.2 Semantics of the “Activity” package . 39
7.21 The “Vehicle” package . 40
7.21.1 Overview of the “Vehicle” package . 40
7.21.2 Semantics of the “Vehicle” package . 41
7.22 The “VehicleCharacteristics” package . 42
7.22.1 Overview of the “VehicleCharacteristics” package . 42
7.22.2 Semantics of the “VehicleCharacteristics” package . 43
7.23 The “OperatorAction” package . 43
7.23.1 Overview of the “OperatorAction” package . 43
7.23.2 Semantics of the “OperatorAction” package . 44
7.24 The “Roadworks” package . 45
7.24.1 Overview of the “Roadworks” package . 45
7.24.2 Semantics of the “Roadworks” package . 46
7.25 The “NetworkManagement” package . 47
7.25.1 Overview of the “NetworkManagement” package . 47
7.25.2 Semantics of the “NetworkManagement” package . 48
Annex A (normative) Data Dictionary . 51
A.1 Overview . 51
A.2 Data Dictionary for "SituationPublication" . 52
A.2.1 "Accident" package . 52
A.2.2 "Activity" package . 53
A.2.3 "Conditions" package . 54
A.2.4 "DataValue" package . 55
A.2.5 "Humidity" package . 60
A.2.6 "Impact" package . 61
A.2.7 "NetworkManagement" package . 63
A.2.8 "NonRoadEventInformation" package . 67
A.2.9 "Obstruction" package . 70
A.2.10 "OperatorAction" package . 72
A.2.11 "Pollution" package . 73
A.2.12 "PrecipitationDetail" package . 73
A.2.13 "ReusableClasses" package . 75
A.2.14 "RoadSurfaceConditionMeasurements" package . 79
A.2.15 "Roadworks" package . 80
A.2.16 "SituationPublication" package . 82
A.2.17 "SituationRecord" package . 83
A.2.18 "Temperature" package . 86
A.2.19 "TimePeriodOfDay" package . 87
A.2.20 "TrafficElement" package . 88
A.2.21 "Validity" package . 90
A.2.22 "Vehicle" package . 93
A.2.23 "VehicleCharacteristics" package . 96
A.2.24 "Visibility" package . 98
A.2.25 "WeatherRelated" package . 99
A.2.26 "Wind" package . 99
A.3 Data Dictionary of <> for "SituationPublication" . 101
A.3.1 The <> "AngleInDegrees" . 101
A.3.2 The <> "AxlesPerHour" . 101
A.3.3 The <> "ConcentrationKilogramsPerCubicMetre" . 101
A.3.4 The <> "ConcentrationMicrogramsPerCubicMetre" . 101
A.3.5 The <> "ConcentrationVehiclesPerKilometre" . 101
A.3.6 The <> "CubicMetres" . 101
A.3.7 The <> "IntensityKilogramsPerSquareMetre" . 101
A.3.8 The <> "IntensityMillimetresPerHour" . 102
A.3.9 The <> "KilometresPerHour" . 102
A.3.10 The <> "MetresAsFloat" . 102
A.3.11 The <> "MetresAsNonNegativeInteger" . 102
A.3.12 The <> "PassengerCarUnitsPerHour" . 102
A.3.13 The <> "Percentage" . 102
A.3.14 The <> "Seconds" . 102
A.3.15 The <> "TemperatureCelsius" . 102
A.3.16 The <> "Tonnes" . 102
A.3.17 The <> "VehiclesPerHour" . 103
A.4 Data Dictionary of <> for "SituationPublication" . 103
A.4.1 The <> "AbnormalTrafficTypeEnum". 103
A.4.2 The <> "AccidentCauseEnum" . 104
A.4.3 The <> "AccidentTypeEnum" . 105
A.4.4 The <> "AnimalPresenceTypeEnum" . 108
A.4.5 The <> "AreaOfInterestEnum" . 109
A.4.6 The <> "AuthorityOperationTypeEnum" . 110
A.4.7 The <> "CarParkConfigurationEnum" . 112
A.4.8 The <> "CarParkStatusEnum" . 113
A.4.9 The <> "CauseTypeEnum" . 114
A.4.10 The <> "CommentTypeEnum" . 116
A.4.11 The <> "ComparisonOperatorEnum". 117
A.4.12 The <> "ComplianceOptionEnum" . 117
A.4.13 The <> "ComputationMethodEnum" . 118
A.4.14 The <> "ConfidentialityValueEnum" . 118
A.4.15 The <> "ConstructionWorkTypeEnum" . 119
A.4.16 The <> "CountryEnum" . 120
A.4.17 The <> "DangerousGoodsRegulationsEnum" . 122
A.4.18 The <> "DayEnum" . 123
A.4.19 The <> "DelayBandEnum" . 123
A.4.20 The <> "DelaysTypeEnum" . 124
A.4.21 The <> "DirectionCompassEnum" . 125
A.4.22 The <> "DirectionEnum" . 126
A.4.23 The <> "DisturbanceActivityTypeEnum" . 127
A.4.24 The <> "DrivingConditionTypeEnum" . 129
A.4.25 The <> "EnvironmentalObstructionTypeEnum" . 130
A.4.26 The <> "EquipmentOrSystemFaultTypeEnum" . 131
A.4.27 The <> "EquipmentOrSystemTypeEnum" . 132
A.4.28 The <> "FuelTypeEnum" . 133
A.4.29 The <> "GeneralInstructionToRoadUsersTypeEnum" . 134
A.4.30 The <> "GeneralNetworkManagementTypeEnum" . 136
A.4.31 The <> "InformationStatusEnum" . 137
A.4.32 The <> "InfrastructureDamageTypeEnum" . 138
A.4.33 The <> "InjuryStatusTypeEnum" . 139
A.4.34 The <> "InvolvementRolesEnum" . 140
A.4.35 The <> "LoadTypeEnum" . 141
A.4.36 The <> "MaintenanceVehicleActionsEnum" . 143
A.4.37 The <> "MobilityEnum" . 143
A.4.38 The <> "MonthOfYearEnum" . 144
A.4.39 The <> "NonWeatherRelatedRoadConditionTypeEnum" . 145
A.4.40 The <> "ObstructionTypeEnum" . 146
A.4.41 The <> "OperatorActionOriginEnum" . 148
A.4.42 The <> "OperatorActionStatusEnum" . 149
A.4.43 The <> "PersonCategoryEnum" . 150
A.4.44 The <> "PlacesEnum" . 151
A.4.45 The <> "PollutantTypeEnum" . 153
A.4.46 The <> "PoorEnvironmentTypeEnum" . 154
A.4.47 The <> "PrecipitationTypeEnum" . 157
A.4.48 The <> "ProbabilityOfOccurrenceEnum" . 157
A.4.49 The <> "PublicEventTypeEnum" . 158
A.4.50 The <> "RelativeTrafficFlowEnum" . 161
A.4.51 The <> "ReroutingManagementTypeEnum" . 162
A.4.52 The <> "RoadMaintenanceTypeEnum" . 163
A.4.53 The <> "RoadOperatorServiceDisruptionTypeEnum" . 164
A.4.54 The <> "RoadOrCarriagewayOrLaneManagementTypeEnum" . 165
A.4.55 The <> "RoadsideAssistanceTypeEnum" . 167
A.4.56 The <> "RoadsideServiceDisruptionTypeEnum" . 168
A.4.57 The <> "RoadworksDurationEnum" . 170
A.4.58 The <> "RoadworksScaleEnum" . 170
A.4.59 The <> "SeverityEnum" . 171
A.4.60 The <> "SourceTypeEnum" . 172
A.4.61 The <> "SpeedManagementTypeEnum" . 174
A.4.62 The <> "SubjectTypeOfWorksEnum" . 175
A.4.63 The <> "TrafficConstrictionTypeEnum" . 176
A.4.64 The <> "TrafficFlowCharacteristicsEnum" . 177
A.4.65 The <> "TrafficStatusEnum". 177
A.4.66 The <> "TrafficTrendTypeEnum" . 178
A.4.67 The <> "TrafficTypeEnum" . 179
A.4.68 The <> "TransitServiceInformationEnum" . 180
A.4.69 The <> "TransitServiceTypeEnum" . 182
A.4.70 The <> "UrgencyEnum" . 182
A.4.71 The <> "UrlLinkTypeEnum" . 183
A.4.72 The <> "ValidityStatusEnum" . 183
A.4.73 The <> "VehicleEquipmentEnum" . 184
A.4.74 The <> "VehicleObstructionTypeEnum" . 185
A.4.75 The <> "VehicleStatusEnum" . 187
A.4.76 The <> "VehicleTypeEnum". 188
A.4.77 The <> "VehicleUsageEnum" . 190
A.4.78 The <> "WeatherRelatedRoadConditionTypeEnum" . 191
A.4.79 The <> "WeekOfMonthEnum" . 193
A.4.80 The <> "WinterEquipmentManagementTypeEnum" . 193
Annex B (normative) Referenced XML Schema for “SituationPublication” . 194
B.1 Overview . 194
B.2 Schema . 194
Annex C (informative) Examples of Situation Publications In XML . 258
C.1 Example Traffic Element . 258
C.2 Example Operator Action . 261
C.3 Example NonRoadEventInformation . 267
Bibliography . 270

Foreword
This document (CEN/TS 16157-3:2011) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, 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 [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes ENV 13106:2000, ENV 13777:2000.
As a user of the standard, attention is drawn to the resources of www.datex2.eu. This web site contains
related software tools and software resources that aid the implementation of CEN/TS 16157 DATEX II.
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, Romania, Slovakia, Slovenia,
Spain, Sweden, Switzerland and the United Kingdom.
Introduction
This Technical Specification 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. Standardisation 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.
Delivering European Transport Policy in line with the White Paper issued by the European Commission
requires co-ordination of traffic management and the development of seamless pan European services. 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 co-funding through the Euro-
Regional projects. With this standardisation of DATEX II there is a real basis for common exchange between
the actors of the traffic and travel information sector.
This Technical Specification includes the framework and context for exchanges, the modelling approach, data
content, data structure and relationships and communications specification.
This Technical Specification supports a methodology that is extensible.
The third part of this Technical Specification deals with the publication of situation information. It specifies the
structures and definitions of information that may be exchanged to convey situation information relating to a
road network, both from a road network manager and road user point of view.
The European Committee for Standardisation (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning procedures, methods and/or
formats given in this document.
CEN takes no position concerning the evidence, validity and scope of patent rights.

1 Scope
This Technical Specification (CEN/TS 16157-3) 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.
This Technical Specification is applicable to:
 traffic and travel information which is of relevance to road networks (non urban and urban);
 public transport information that is of direct relevance to the use of a road network (e.g. road link via train
or ferry service).
This Technical Specification 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 Technical Specification may be applicable for use by other actors.
This Technical Specification includes the following types of information content:
 road traffic event information – planned and unplanned occurrences both on the road network and in the
surrounding environment;
 operator initiated actions;
 road traffic measurement data, status data and travel time data;
 travel information relevant to road users, including weather and environmental information;
 road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 specifies the informational structures, relationships, roles, attributes and
associated data types required for publishing situation traffic and travel information within the DATEX II
framework. This is specified as a DATEX II Situation Publication sub-model which is part of the DATEX II
platform independent model, but this Part excludes those elements that relate to location information which
are specified in CEN/TS 16157-2 and those elements that relate to VMS settings which are specified in Part 4
of CEN/TS 16157 [4].
2 Conformance
The DATEX II platform independent data model of which the Situation Publication sub-model is a part,
corresponds to the Level A model as defined in CEN/TS 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 CEN/TS 16157-1 and with the following
requirements of this sub-model which are expressed in this part:
 comply with all stipulated minimum and maximum multiplicity requirements for UML elements and
relationships;
 comply with all definitions, types and ordering;
 employ optional elements as specified;
 comply with all expressed constraints.
It should be noted that conformance of a publication service with all the structural requirements stated above
does not necessarily ensure that the informational content of that service will be semantically comprehensible.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
CEN/TS 16157-1:2011, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 1: Context and framework
CEN/TS 16157-2, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 2: Location referencing
ISO 639-2: 1998, Codes for the representation of names of languages — Part 2: Alpha-3 code
4 Terms and definitions
For the purposes of this document, the terms and definitions given in CEN/TS 16157-1:2011 and the following
apply.
4.1
destination
specification of the end point of a defined route or itinerary
NOTE This may be either a location on a road network or an area location.
4.2
location
identifiable geographic place
NOTE It is either on a road network (as a point or a linear location) or as an area. This may be provided in one or
more referencing systems.
[EN ISO 19112:2005]
4.3
Itinerary
route
navigable ordered sequence of locations with a start point and an end point
4.4
RSS
really simple syndication
Really Simple Syndication comprises a Web feed format used to publish frequently updated sources of
information
4.5
situation
identifiable occurrence in the real world comprising one or more traffic/travel circumstances which are linked
by one or more causal relationships. Each Situation has its own life-cycle which encompasses the life-cylcles
of its component circumstances
4.6
situation element
identifiable occurrence in the real world comprising one traffic/travel circumstance which has its own life-cycle
NOTE Details of each situation element are mapped into a single data record.
5 Symbols and abbreviations
For the purposes of this document, the abbreviation of terms given in CEN/TS 16157-1 and the following
apply.
ADR  European Agreement concerning the International Carriage of Dangerous Goods by Road
ETRS89 European Terrestrial Reference System 1989
GUID  Globally Unique IDentifier
HTML  Hyper Text Mark-up Language
IATA  International Air Transport Association
ICAO  International Civil Aviation Organization
IMO  International Maritime Organization
IMDG  International Maritime Dangerous Goods (code)
IP  Internet Protocol
LPG  Liquid Petroleum Gas
PDF  Portable Document Format
TREM  Transport Emergency Card
UML  Unified Modeling Language
UNDG  United Nations Dangerous Goods (number)
URL  Uniform Resource Locator
VIP  Very Important Person
VMS  Variable Message Sign
6 UML notation
The UML notation used in these Technical Specifications shall be as described in ISO/IEC 19501. A short
summary explaining the notation used in this Technical Specification is provided in Annex A of the Part 1 of
CEN/TS 16157.
7 The Situation Publication model
7.1 Overview of the Situation Publication model
The Situation Publication model shall comprise a number of packages, with the “SituationPublication” package
providing the entry to the model and the subordinate “SituationRecord” package modelling the individual
elements of situations. The “SituationPublication” package shall be one of several packages which are
immediately subordinate to the “PayloadPublication” package and hence forms the top of the hierarchy in the
Situation Publication model. The “SituationRecord” package shall make use of a number of packages from
within the “ReusableClasses” package thus invoking a hierarchy of packages.
Each “SituationPublication” instance shall specify any number of individual situations in the real world, each of
which shall comprise separate, but related, elements which are modelled in DATEX II as “SituationRecords”.
A “SituationRecord” shall be further specialised as being either of type “NonRoadEventInformation”,
“TrafficElement”, “OperatorAction” or “GenericSituationRecord”. The “GenericSituationRecor
...