ISO 21219-15:2023

Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 15: Traffic event compact (TPEG2-TEC)

This document specifies the "traffic event compact" (TEC) TPEG application. The TEC application has been specifically designed to support information about traffic events (e.g. road works, traffic jams). A specific form of traffic event is local hazard warnings which, being safety-related messages, are sent with high priority to warn a driver of unexpected dangerous situations (e.g. black-ice, accident beyond curves, obstacles on road, etc.). Generally, the TEC application is designed to allow receivers to: — ensure travel safety for the driver; — enable the calculation of alternative routes; — avoid delays (e.g. traffic jams); — warn the driver of obstructions on route; and — provide the driver with information on infrastructural problems (e.g. closed petrol stations, non-functioning emergency telephones).

Systèmes intelligents de transport — Informations sur le trafic et le tourisme via le groupe expert du protocole de transport, génération 2 (TPEG2) — Partie 15: Événement trafic compact (TPEG2-TEC)

General Information

• Status: Published
• Publication Date: 24-May-2023
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 6060 - International Standard published
• Start Date: 25-May-2023
• Due Date: 31-Oct-2022
• Completion Date: 25-May-2023

Relations

• Revises: ISO/TS 21219-15:2016 - Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 15: Traffic event compact (TPEG2-TEC)
• Effective Date: 23-Apr-2020

Overview

ISO 21219-15:2023 - Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 15: Traffic event compact (TPEG2-TEC) specifies the TPEG2 Traffic Event Compact (TEC) application for exchanging concise, prioritized traffic-event messages. TEC is designed to convey events such as roadworks, traffic jams and local hazard warnings (e.g., black ice, obstacles, accidents) to support safety-critical and real-time traffic and travel information services.

Key topics and technical requirements

The standard defines the structure, semantics and encoding needed for interoperable TPEG2 TEC messages. Major technical topics include:

• Application constraints and signalling: rules for application identification, version signalling, ordered components and extensions to ensure consistent interpretation.
• TEC message structure: definitions of top-level components (e.g., TECMessage, MMCSwitch, MessageManagement) and event models.
• Event modelling: attributes for Event (effect, cause, start/stop time, length affected, speed attributes, rounding rules, at-grade junction closures).
• Location models: ProblemLocation, RestrictionLocation, SegmentLocation to precisely locate incidents and restrictions.
• Cause and advice coding: Cause, DirectCause, LinkedCause, Advice elements with rules and constraints.
• Traffic measures: VehicleRestriction, DiversionRoute, TemporarySpeedLimit and detailed handling for diversions and temporary limits.
• Datatypes and tables: standard datatypes (LaneNumber, RestrictionType, SegmentModifier, etc.) and code tables (effect codes, cause codes, warning levels, vehicle types, diversion types).
• Encodings and examples: normative annexes for TPEG-Binary and TPEG-ML representations and informative coding examples for implementers.

Practical applications and users

ISO 21219-15:2023 enables consistent delivery of compact traffic-event messages for a variety of ITS applications:

• Navigation & route-planning systems - automatically calculate alternative routes and avoid delays.
• In-vehicle infotainment and driver-assistance - present high-priority hazard warnings to enhance travel safety.
• Traffic data providers and broadcasters - encode and distribute standard TPEG2-TEC messages across networks.
• Traffic management centres and road operators - share event information (closures, roadworks, infrastructure failures) across systems.
• Mobile apps and fleet management - integrate concise, interoperable traffic event feeds for real-time operational decisions.

Related standards

• Part of the TPEG2 family and the ISO 21219 series (TPEG TTI standards). Implementers should align with other TPEG2 parts and national/regional ITS regulations when integrating TEC messages.

Keywords: ISO 21219-15:2023, TPEG2-TEC, traffic event compact, intelligent transport systems, TTI, traffic and travel information, hazard warnings, route planning, navigation systems, traffic data providers.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-15
First edition
2023-05
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 15:
Traffic event compact (TPEG2-TEC)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 15: Événement trafic compact (TPEG2-TEC)
Reference number
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Application specific constraints . .2
5.1 Application identification . 2
5.2 Version number signalling . 2
5.3 Ordered components . . 3
5.4 Extension . 3
5.5 TPEG service component frame . 4
6 TEC structure . 4
7 TEC message components . 6
7.1 TECMessage . 6
7.2 MMCSwitch . 6
7.3 MessageManagement . 6
7.4 Event . 7
7.4.1 Effect and Cause . 8
7.4.2 LengthAffected . 8
7.4.3 startTime and stopTime . 8
7.4.4 Speed Attributes . 8
7.4.5 At Grade Junction Closure . 9
7.4.6 Rounding of speed information . 9
7.5 ProblemLocation . 10
7.6 RestrictionLocation . 10
7.7 SegmentLocation . 10
7.8 Cause . . . 10
7.9 DirectCause . 10
7.10 Causes and subCauses .12
7.11 LinkedCause . 12
7.11.1 General .12
7.11.2 Rules .12
7.11.3 Further constraints . 13
7.11.4 Coding examples . 13
7.12 Advice . 13
7.13 VehicleRestriction . .13
7.14 DiversionRoute . 14
7.14.1 Description for creating and applying diversions . 14
7.14.2 Strategy for coding a diversion . 14
7.15 TemporarySpeedLimit . 15
8 TEC Datatypes .16
8.1 LaneNumber . 16
8.2 RestrictionType. 17
8.3 SegmentModifier . 17
8.4 TemporarySpeedLimitSection . 17
9 TEC Tables .18
9.1 tec001:EffectCode . 18
9.2 tec002:CauseCode . 18
9.3 tec003:WarningLevel . .20
9.4 tec004:LaneRestriction . 21
iii
9.5 tec005:AdviceCode . 21
9.6 tec006:Tendency .22
9.7 tec007:RestrictionType .23
9.8 tec008:DiversionRoadType . 24
9.9 tec009:VehicleType . 24
9.10 tec010:AtGradeJunctionClosure . 25
9.11 tec100:SubCauseType . 26
9.12 tec101:TrafficCongestion . 27
9.13 tec102:Accident . 27
9.14 tec103:Roadworks . 27
9.15 tec104:NarrowLanes .28
9.16 tec105:Impassability .28
9.17 tec106:SlipperyRoad .29
9.18 tec108:Fire. 29
9.19 tec109:HazardousDrivingConditions .30
9.20 tec110:ObjectsOnTheRoad . 30
9.21 tec111:AnimalsOnRoadway . 31
9.22 tec112:PeopleOnRoadway . 31
9.23 tec113:BrokenDownVehicles . . 31
9.24 tec115:RescueAndRecoveryWorkInProgress . 32
9.25 tec116:RegulatoryMeasure . 32
9.26 tec117:ExtremeWeatherConditions . 33
9.27 tec118:VisibilityReduced . 33
9.28 tec119:Precipitation .34
9.29 tec120:RecklessPersons .34
9.30 tec123:MajorEvent. 35
9.31 tec124:ServiceNotOperating . 35
9.32 tec125:ServiceNotUseable .36
9.33 tec126:SlowMovingVehicles .36
9.34 tec127:DangerousEndOfQueue . 36
9.35 tec128:RiskOfFire . 37
9.36 tec129:TimeDelay . 37
9.37 tec130:PoliceCheckpoint .38
9.38 tec131:MalfunctioningRoadsideEquipment .38
9.39 tec200:SubAdviceType .38
9.40 tec202:OvertakingNotAllowed .39
9.41 tec203:DrivingNotAllowed . .39
9.42 tec207:GiveWayToVehiclesFromBehind . 39
9.43 tec208:FollowDiversion .40
9.44 tec213:DriveCarefully .40
9.45 tec214:DoNotLeaveYourVehicle .40
9.46 tec216:UseTollLanes . 41
Annex A (normative) TPEG TEC, TPEG-Binary Representation .42
Annex B (normative) TPEG application, TPEG-ML Representation .51
Annex C (informative) TPEG application,TEC message coding examples .65
Bibliography .80
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces the first edition (ISO/TS 21219-15:2016), which has been
technically revised.
The main changes are as follows:
— Lane Level feature has been added for all TEC events;
— Road Closure feature has been added for roads with At-Grade Junctions;
— the document has been changed from a Technical Specification to an International Standard.
A list of all parts in the ISO 21219 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
0.1  History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information in
the multimedia environment. TPEG technology, its applications and service features were designed to
enable travel-related messages to be coded, decoded, filtered and understood by humans (visually and/
or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream format,
which can be carried on almost any digital bearer with an appropriate adaptation layer, was developed.
Hierarchically structured TPEG messages from service providers to end-users were designed to
transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax,
semantics and framing structure which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development
work. Further parts were developed to make the initial set of four parts, enabling the implementation
of a consistent service. Part 3 (TPEG-SNI, later ISO/TS 18234-3) described the service and network
information application used by all service implementations to ensure appropriate referencing from
one service source to another.
Part 1 (TPEG-INV, later ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
public transport information application (TPEG-PTI, later ISO/TS 18234-5), was developed. The so-
called TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-
map-based ones to deliver either map-based location referencing or human-readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications of parts of the
ISO 18234 series to provide location referencing.
The ISO 18234 series has become known as TPEG Generation 1.
0.2  TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO 21219 series and it comprises many parts that cover introduction, rules,
toolkit and application components. TPEG2 is built around UML modelling and has a core of rules that
contain the modelling strategy covered in ISO 21219-2, ISO 21219-3 and ISO 21219-4 and the conversion
to two current physical formats: binary and XML; others can be added in the future. TISA uses an
automated tool to convert from the agreed UML model XMI file directly into an MS Word document file,
to minimize drafting errors; this file forms the annex for each physical format.
vi
TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application
(several parts) and location referencing (ISO/TS 21219-7). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose. Note that the list below is potentially incomplete, as there is the possibility that new
TPEG2 parts will be introduced after the publication of this document.
— Toolkit parts: TPEG2-INV (ISO 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3),
TPEG2-UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC
(ISO/TS 21219-7).
— Special applications: TPEG2-SNI (ISO 21219-9), TPEG2-CAI (ISO 21219-10), TPEG2-LTE
(ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PKI (ISO 21219-14), TPEG2-TEC (ISO 21219-15 - this document), TPEG2-FPI
(ISO 21219-16), TPEG2-SPI (ISO 21219-17), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO 21219-19),
TPEG2-RMR (ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25), TPEG2-VLI (ISO/TS 21219-26).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist in
transitions from earlier implementations, while not hindering the TPEG2 innovative approach and being
able to support many new features, such as dealing with applications with both long-term, unchanging
content and highly dynamic content, such as parking information.
This document is based on the TISA specification technical/editorial version reference:
SP20012/3.4/001
vii
INTERNATIONAL STANDARD ISO 21219-15:2023(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 15:
Traffic event compact (TPEG2-TEC)
1 Scope
This document specifies the "traffic event compact" (TEC) TPEG application. The TEC application has
been specifically designed to support information about traffic events (e.g. road works, traffic jams). A
specific form of traffic event is local hazard warnings which, being safety-related messages, are sent
with high priority to warn a driver of unexpected dangerous situations (e.g. black-ice, accident beyond
curves, obstacles on road, etc.).
Generally, the TEC application is designed to allow receivers to:
— ensure travel safety for the driver;
— enable the calculation of alternative routes;
— avoid delays (e.g. traffic jams);
— warn the driver of obstructions on route; and
— provide the driver with information on infrastructural problems (e.g. closed petrol stations, non-
functioning emergency telephones).
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.
ISO 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO 21219-6, Intelligent transport systems — Traffic and travel information(TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 6: Message management container (TPEG2-MMC)
ISO 21219-9, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
ISO 21219-10, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 10: Conditional access information (TPEG2-CAI)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21219-1, ISO 21219-9,
ISO 21219-10 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
local hazard warning
specific form of traffic event (a safety-related message) which is sent with high priority to assist a driver
in avoiding encountering dangerous situations
4 Abbreviated terms
For the purposes of this document, the abbreviated terms in ISO 21219-1, ISO 21219-9, ISO 21219-19
and the following apply.
AR access road
BP bypass
CR closed road
ITS intelligent transport systems
LA limited access
LRC location referencing container
mi miles
MMC message management container
NR not recommended
XML eXtensible Markup Language
5 Application specific constraints
5.1 Application identification
The word “application” is used in the TPEG specifications to describe specific subsets of the TPEG
structure. An application defines a limited vocabulary for a certain type of messages, for example,
parking information or road traffic information. Each TPEG application is assigned a unique number,
called the application identity (AID). An AID number is defined in ISO 21219-1 whenever a new
application is developed.
The AID number is used within the TPEG2-SNI application (ISO 21219-9) to indicate how to process
TPEG content. It facilitates the routing of information to the appropriate application decoder.
5.2 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions could have an impact on client devices.
The version numbering principle is defined in ISO 21219-9.
Table 1 shows the current version numbers for signalling TEC within the SNI application.
Table 1 — Current version numbers for signalling of TEC
Major version number 3
Minor version number 4
5.3 Ordered components
TPEG2-TEC requires a fixed order of TPEG components. The order for the TEC message component is
shown in Figure 1. The first component shall be the message management container (MMC). This shall
be the only component if the message is a cancellation message. Otherwise, the MMC component shall
be followed by one or more ADC component(s) which includes the application-specific information.
Figure 1 — Composition of TPEG messages
5.4 Extension
Although it is necessary to maintain a fixed component order, this does not prevent the extension of
a TEC message generally. In case of future extensions, new components may be inserted, or existing
components may be replaced by new ones without losing backward compatibility. This requires that a
TEC decoder shall be able to detect and skip unknown components.
Components of the same type shall be included sequentially without interleaving other component
types.
EXAMPLE (allowed)
Figure 2 shows the original component model being extended to the new component model in Figure 3.
The Advice component shown in Figure 2 is replaced by BetterAdvice with its own component ID. A
WeatherSituation component is inserted after BetterAdvice component.
Figure 2 — Example for extension (original component model, before addition of additional
components)
Figure 3 — Example for extension (Advice replaced by BetterAdvice and WeatherSituation
added)
5.5 TPEG service component frame
TPEG2-TEC (this document) makes use of the “service component frame with dataCRC, groupPriority
and messageCount” according to ISO 21219-5.
6 TEC structure
The structure of TEC messages is presented in Figure 4. This structure conforms to the UML modelling
rules defined in ISO 21219-2. The binary format and XML format of the TPEG2-TEC application for use
in transmission shall be in accordance with Annexes A and B, respectively.
Figure 4 — TEC message structure
7 TEC message components
7.1 TECMessage
A TECMessage is either a normal message or a cancellation message. A normal message (i.e. other than
cancellation messages) shall include the following:
— one management container with management information related to the overall message (ID and
version, expiry time);
— one event container with one traffic flow effect and optional one or more causes with additional
information;
— one location container with the location reference for the overall traffic message.
The message management container is mandatory, the event- and location reference container are
optional.
Event and ProblemLocation are modelled optionally because cancel messages do not contain these
elements: cancellation messages shall not include an event and location reference container whereas
normal messages (cancelFlag = false) shall include exactly one event and one location reference
container.
Table 2 defines the TECMessage component.
Table 2 — TECMessage
Name Type Multiplicity Description
Ordered Components
mmt MMCSwitch 1 MMC
event Event 0.1 Describes the impact on the traffic flow and the related
cause (always included except for cancellation of a
message).
loc ProblemLocation 0.1 LRC (always included except for cancellation of a mes-
sage).
7.2 MMCSwitch
The MMCSwitch is an abstract container included for formal reasons, to allow future extension of the
MessageManagementContainer.
7.3 MessageManagement
The MessageManagement component is a placeholder for the MessageManagementContainer
as specified in ISO 21219-6. It assigns the TEC application specific local component ID for the
MessageManagementContainer. All component IDs within this container are local to the MMC toolkit.
The MessageManagementContainer contains all and only information related to message management.
Message generation systems shall ensure that the information given in the MessageManagementContainer
promotes unambiguous interpretation over the whole time a message is valid. It is particularly
important to recognize that client devices are likely to suffer from non-continuous transmission
channels as typically encountered in broadcast systems suffering intermittent RF performance.
TEC shall only use the monolithic message management as specified in ISO 21219-6. Multi-part
messages management shall not be used.
7.4 Event
The Event component with its subordinated component Cause supports the definition, in general, of the
impact on the traffic flow and the related cause.
EXAMPLE Stationary Traffic (due to) Narrow Lanes.
Table 3 defines the Event component.
Table 3 — Event component
Name Type Multiplicity Description
effectCode t e c 0 01: E f f e c t C o de 1 Describes the impairment of the traffic flow.
startTime DateTime 0.1 Date and time at which an event began or is
scheduled to begin (intended to be used for
presentation to the end-user).
stopTime DateTime 0.1 Date and time at which an event, or status
information, ended or is scheduled to end
(intended to be used for presentation to the
end-user).
tendency tec006: Tendency 0.1 Tendency is related to the
averageSpeedAbsolute indicating if this has
been increasing, decreasing or has
remained constant. Timescale of this trend
should be typically in the range of 30 min
or less, but is defined by the service
provider. It is not a forecast of a future
trend, nor does it relate to the length of the
traffic queue.
lengthAffected DistanceMetres 0.1 Length of the event in metres.
averageSpeedAbsolute Velocity 0.1 The actual average speed in m/s at the
given location. It is recommended to use
this value for calculation of the route and
estimated arrival time.
delay IntUnLoMB 0.1 Delay in minutes added to journey due to
event at the location. Only applicable to
point locations, i.e. at border crossings.
segmentSpeedLimit Velocity 0.1 Averaged speed limit (in m/s) within the
problem location. Within the problem
location, multiple speed limits can exist
(e.g. multiple reducing speed limits on
entering a roadworks zone). The average
speed limit is calculated as: the total length
(in m) of the problem location divided by
the sum of the individual travel times travel
times (s) when travelling at the defined
speed limit.
Shall be used as the speed limit for re-rout-
ing,
but not to display or warn the driver.
expectedSpeedAbsolute Velocity 0.1 The expected (normal) speed in m/s for this
time of the day based on, e.g. historical data.
This speed can potentially vary as function
of the time of day and can be markedly dif-
ferent from the free-flow speed (especially
in rush hour conditions).
TTaabblle 3 e 3 ((ccoonnttiinnueuedd))
Name Type Multiplicity Description
atGradeJunctionClosure tec010: At GradeJunct 0.1 Defines the potential types of cases for
ionClosure dealing with cross traffic for at-grade junc-
tions when there is a road closure, which is
indicated by EffectCode=7.
Ordered components
cause Cause 0.* Defines the reason for the traffic problem
(direct or linked cause).
advice Advice 0.* Recommendations or prohibitions for the
driver.
vehicleRestriction VehicleRestriction 0.* Vehicle types (restrictions) that are relevant
for the message.
diversionRoute DiversionRoute 0.* Diversion information relating to the event.
temporarySpeedLimit TemporarySpeedLimit 0.* Temporary speed limit displayed
on road signs associated with the Event.
This data is intended for display to drivers.
7.4.1 Effect and Cause
For a single event, it should be possible to distinguish between the effect that describes an impairment
of the traffic flow (e.g. stationary traffic) and the cause (e.g. roadworks). The latter can be seen as the
reason for the traffic flow effect described by the attribute effectCode. A “Cause” can be used to provide
further information to inform or warn the driver of a special situation (e.g. oil on the road).
7.4.2 LengthAffected
If LengthAffected is included within the Event component, it describes the length of the overall problem;
otherwise, the length is defined by the location given in the location referencing container (LRC).
LengthAffected shall not be greater than the length defined by the LRC.
7.4.3 startTime and stopTime
These describe the beginning and end time of a traffic event. The startTime is the time at which an
event started or is scheduled to start. The stopTime is the time at which the event is scheduled to end.
These times may be presented directly to the user by the receiver for information.
7.4.4 Speed Attributes
Speed-related attributes are all defined in metres per second (m/s). Client devices can need to convert
to other units.
7.4.4.1 Average Speed Absolute
The averageSpeedAbsolute is used to signal the real speed of traffic through the problem location.
7.4.4.2 Delay
Delay associated with a specific location like a border crossing.
7.4.4.3 Segment Speed limit
The segmentSpeedLimit is used to signal the averaged potential speed (due to applied legal limits along
the Problem Location) for re-routing and ETA calculations, but not to display or warn the driver. This
attribute is not guaranteed to match signed speed limits on a road.
7.4.4.4 Expected Speed Absolute
The expectedSpeedAbsolute is used to signal the expected (normal) speed of traffic through the
problem location.
7.4.5 At Grade Junction Closure
For TEC coding examples for road closures with at grade junctions (see Clause C.6).
7.4.6 Rounding of speed information
Speed information is always given in metres per seconds (m/s) as the TPEG data type “Velocity” is used.
For calculations of journey and arrival times, receivers should use this information directly. However,
for presentation to the driver, the receiver should convert and round these values as suggested in
Table 4.
Table 4 — Rounding of speed information
m/s km/h km/h mi/h mi/h
(exact) (rounded, steps of 5) (exact to 2 decimal places) (rounded, steps of 5)
0 0,0 0 0,0 0
1 3,6 5 2,24 0
2 7,2 5 4,49 5
3 10,8 10 6,73 5
4 14,4 15 8,98 10
5 18,0 20 11,22 10
6 21,6 20 13,47 15
7 25,2 25 15,71 15
8 28,8 30 17,96 20
9 32,4 30 20,20 20
10 36,0 35 22,44 20
11 39,6 40 24,69 25
12 43,2 45 26,93 25
13 46,8 45 29,18 30
14 50,4 50 31,42 30
The following Formula (1) and Formula (2) are used to calculate the values listed in Table 4. Additional
higher values than those listed may be used.
1) For steps of 5 km/h (0, 5, 10, 15, 20, etc.):
V = 5 × [(36 × v + 25)/50] (1)
2) For steps of 5 mi/h (0, 5, 10, 15, 20, etc.):
V = 5 × [(360 × v + 401)/802] (2)
where
v is the vel
...