ISO/TS 21219-15:2016

TECHNICAL ISO/TS
SPECIFICATION 21219-15
First edition
2016-06-01
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 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
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 . 5
7.1 TECMessage . 5
7.2 MMCSwitch . 5
7.3 MessageManagement . 5
7.4 Event . 5
7.5 Cause . 8
7.6 DirectCause . 9
7.7 Causes and sub-causes .10
7.8 LinkedCause .10
7.8.1 Rules .11
7.8.2 Further constraints .11
7.8.3 Coding Examples .11
7.9 Advice .14
7.10 VehicleRestriction.14
7.11 DiversionRoute .15
7.11.1 Description for Creating and Applying Diversions .15
7.11.2 Strategy for Coding a Diversion .15
7.12 TemporarySpeedLimit .17
7.13 ProblemLocation .21
7.14 RestrictionLocation .21
7.15 SegmentLocation .21
8 TEC Datatypes .21
8.1 RestrictionType .21
8.2 SegmentModifier .21
8.3 TemporarySpeedLimitSection .21
9 TEC Tables .22
9.1 tec001:EffectCode .22
9.2 tec002:CauseCode .22
9.3 tec003:WarningLevel .24
9.4 tec004:LaneRestriction .25
9.5 tec005:AdviceCode .25
9.6 tec006:Tendency .26
9.7 tec007:RestrictionType .27
9.8 tec008:DiversionRoadType .28
9.9 tec009:VehicleType .28
9.10 tec100:SubCauseType .29
9.11 tec101:TrafficCongestion .30
9.12 tec102:Accident .30
9.13 tec103:Roadworks .30
9.14 tec104:NarrowLanes .30
9.15 tec105:Impassability .31
9.16 tec106:SlipperyRoad.31
9.17 tec108:Fire .32
9.18 tec109:HazardousDrivingConditions .32
9.19 tec110:ObjectsOnTheRoad .32
9.20 tec111:AnimalsOnRoadway .33
9.21 tec112:PeopleOnRoadway .33
9.22 tec113:BrokenDownVehicles.34
9.23 tec115:RescueAndRecoveryWorkInProgress .34
9.24 tec116:RegulatoryMeasure .34
9.25 tec117:ExtremeWeatherConditions .35
9.26 tec118:VisibilityReduced .35
9.27 tec119:Precipitation .36
9.28 tec120:RecklessPersons .36
9.29 tec123:MajorEvent .36
9.30 tec124:ServiceNotOperating .37
9.31 tec125:ServiceNotUseable .37
9.32 tec126:SlowMovingVehicles .37
9.33 tec127:DangerousEndOfQueue .38
9.34 tec128:RiskOfFire .38
9.35 tec129:TimeDelay .38
9.36 tec130:PoliceCheckpoint .39
9.37 tec131:MalfunctioningRoadsideEquipment .39
9.38 tec200:SubAdviceType . .39
9.39 tec202:OvertakingNotAllowed.40
9.40 tec203:DrivingNotAllowed .40
9.41 tec207:GiveWayToVehiclesFromBehind .40
9.42 tec208:FollowDiversion .41
9.43 tec213:DriveCarefully .41
9.44 tec214:DoNotLeaveYourVehicle .41
9.45 tec216:UseTollLanes .41
Annex A (normative) TPEG TEC, TPEG-Binary Representation .42
Annex B (normative) TPEG application, TPEG-ML Representation .50
Bibliography .63
iv © ISO 2016 – All rights reserved

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 on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2):
— Part 1: Introduction, numbering and versions (TPEG2-INV) [Technical Specification]
— Part 2: UML modelling rules [Technical Specification]
— Part 3: UML to binary conversion rules [Technical Specification]
— Part 4: UML to XML conversion rules [Technical Specification]
— Part 5: Service framework (TPEG2-SFW) [Technical Specification]
— Part 6: Message management container (TPEG2-MMC) [Technical Specification]
— Part 9: Service and network information (TPEG2-SNI) [Technical Specification]
— Part 10: Conditional access information (TPEG2-CAI) [Technical Specification]
— Part 14: Parking information application (TPEG2-PKI) [Technical Specification]
— Part 15: Traffic event compact [Technical Specification]
— Part 18: Traffic flow and prediction application (TPEG2-TFP) [Technical Specification]
— Part 19: Weather information (TPEG2-WEA) [Technical Specification]
The following parts are under preparation:
— Part 16: Fuel price information and availability application (TPEG2-FPI) [Technical Specification]
— Part 23: Road and multi-modal routes application (TPEG2-RMR) [Technical Specification]
— Part 24: Light encryption (TPEG2-LTE) [Technical Specification]
— Part 25: Electromobility charging infrastructure (TPEG2-EMI) [Technical Specification]
The following parts are planned:
— Part 7: Location referencing container [Technical Specification]
— Part 11: Universal location reference [Technical Specification]
— Part 21: Geographic location referencing [Technical Specification]
— Part 22: OpenLR location referencing [Technical Specification]
vi © ISO 2016 – All rights reserved

Introduction
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 may 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, 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, 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, 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 parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
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/TS 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/TS 21219-2, ISO/TS 21219-3, ISO/TS 21219-4 and
the conversion to two current physical formats: binary and XML; others could 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, that forms the Annex for each physical format.
TPEG2 has a three container conceptual structure: Message Management (ISO/TS 21219-6), Application
(many 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.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR
(ISO/TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC
(ISO/TS 21219-6), TPEG2-LRC (ISO/TS 21219-7), TPEG2-LTE (ISO/TS 21219-24);
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10);
— Location referencing: TPEG2-ULR (ISO/TS 21219-11), TPEG2-GLR (ISO/TS 21219-21), TPEG2-OLR
(ISO/TS 21219-22);
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO/TS 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25).
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 having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This part of ISO/TS 21219 is based on the TISA specification technical/editorial version reference:
SP13001/3.2/002
viii © ISO 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 21219-15:2016(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 part of ISO/TS 21219 specifies the TPEG application: Traffic Event Compact (TEC). The TEC
application has been specifically designed to support information about traffic events (e.g. road works,
traffic jams). A specific form of traffic events are local hazard warnings which, being safety-related
messages, are sent with high priority to warn a driver that may encounter dangerous situations (e.g.
black-ice, accident beyond curves, obstacles on road, etc.) unexpectedly.
Generally, the Traffic Event Compact 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, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 21219-4, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 4: UML to XML conversion rules
ISO/TS 21219-6, Intelligent transport systems — Traffic and travel information via transport protocol
experts group, generation 2(TPEG2) — Part 6: Message management container (TPEG2-MMC)
1)
ISO/TS 21219-7 , Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 7: Location referencing container (TPEG2-LOC)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
local hazard warning
specific form of traffic events which, being safety-related messages, are sent with high priority to assist
a driver from encountering dangerous situations
1) Planned.
3.2
location referencing container
concept applied to the grouping of all of the location referencing elements of a TPEG-Message
3.3
location referencing
method to provide information which allows a system to accurately identify a location
Note 1 to entry: The content of a location reference allows the location to be presented in a plain-language
manner to the end-user (i.e. text, speech or icons) and also to be used for navigational purposes, for example, for
map-based systems.
4 Abbreviated terms
ACID Application and Content Identifier
ADC Application Data Container
LRC Location Reference Container
MMC Message Management Container
RF Radio Frequency
SFW TPEG Service Framework: Modelling and Conversion Rules
TEC Traffic Event Compact
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modelling Language
5 Application specific constraints
5.1 Application identification
The word “application” is used in this part of ISO/TS 21219 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 IDentification (AID). An AID is defined whenever a new application is developed
and these are all listed in the TPEG2-INV specification.
The application identification number is used in the TPEG2-SNI application to indicate how to process
TPEG content and 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 may have an impact on client devices.
The version numbering principle is defined in the TPEG2-INV specification.
Table 1 shows the current version numbers for signalling TEC within the SNI application.
2 © ISO 2016 – All rights reserved

Table 1 — Current version numbers for signalling of TEC
Major version number 3
Minor version number 2
5.3 Ordered components
TPEG-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. This shall be the
only component if the message is a cancellation message. Otherwise, the MMC component shall be
followed by the one or more Application Data Container component(s) which includes the application-
specific information and this, in turn, is followed by the Location Referencing Container.
TPEG-Message
Figure 1 — Composition of TPEG messages
Within the Event component, one or more Cause components shall come first followed by one or more
Advice components and so on. Components of the same type shall immediately follow each other.
5.4 Extension
Although there is a requirement 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 the interleaving of other forms of
component.
Example (allowed)
The Advice component is replaced by BetterAdvice having its own component id. A WeatherSituation
component is inserted after Advice component as shown in Figures 2 and 3.
Event
Cause irst component
Advice second component
Vehicle
Restriction
Figure 2 — Example for extension; original component model (before addition of additional
components)
Event
Cause
irst component
Better
second component
Advice
Weather
Situation
Vehicle
Restriction
Figure 3 — Example for extension; Advice replaced by BetterAdvice and WeatherSituation added
5.5 TPEG Service Component Frame
TEC makes use of the “Service component frame with dataCRC, groupPriority and messageCount”.
6 TEC Structure
The TEC structure is presented in Figure 4.
Figure 4 — TEC message structure
4 © ISO 2016 – All rights reserved

7 TEC Message components
7.1 TECMessage
A TECMessage (see Table 2) is either a normal message or a cancellation message. A normal message
(i.e. other than cancellation messages) shall include the following:
— one message management container with management information related to the overall message
(ID and version, expiry time);
— one event container with one traffic flow effect and, optionally, one or more causes with additional
information;
— one location referencing container with the location reference for the overall traffic message.
Cancellation messages (cancelFlag = true) shall not include an event nor a location referencing container,
only the message management container.
Table 2 — TECMessage
Name Type Multiplicity Description
Ordered Components
Mmt MMCSwitch 1 Message Management Container
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 Location Referencing Container (always included
except for cancellation of a message)
7.2 MMCSwitch
The MMCSwitch is an abstract container included for formal reasons, to allow future extension of
the MMC.
7.3 MessageManagement
The MessageManagement component is a placeholder for the MessageManagementContainer as
specified in ISO/TS 21219-6. It assigns the traffic event compact (TEC) application specific local
component ID for the MMC container. All component IDs within the MMC container are local to the MMC
toolkit. The MMC contains all and only information related to message management.
Message generation systems shall ensure that the information given in the MMC 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 reception as typically encountered in broadcast
systems suffering intermittent Radio Frequency (RF) performance.
TEC shall only use the monolithic message management as specified in ISO/TS 21219-6. Multipart
messages management shall not be used.
7.4 Event
The Event component (see Table 3) supports definition, in general, of the impact on the traffic flow and
the related cause.
NOTE For example, Stationary Traffic (due to) Narrow Lanes.
Table 3 — Event component
Name Type Multiplicity Description
effectCode tec001:EffectCode 1 Describes the impairment of the trafficflow.
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 may exist
(e.g. multiple reducing speed limits on
entering a roadworks zone). 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
(seconds) when travelling at the defined
speed limit.
Shall be used as speed limit for re-routing,
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 may vary as function of the time
of day and can be markedly different from
the free-flow speed (especially in rush hour
conditions).
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.* This is the temporary speed limit displayed
on road signs associated with the Event.
This data is intended for display to drivers.
6 © ISO 2016 – All rights reserved

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).
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 Reference Container.
LengthAffected shall not be greater than the length defined by the Location Reference Container.
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.
Speed Attributes
Speed related attributes are all defined in metres per second (m/s). Client devices may need to convert
to other units.
Average Speed Absolute
The averageSpeedAbsolute is used to signal the real speed of traffic through the problem location.
Delay
Delay associated with a specific location like a border crossing.
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.
Expected Speed Absolute
The expectedSpeedAbsolute is used to signal the expected (normal) speed of traffic through the
problem location.
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 mph mph
(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
Table 4 (continued)
m/s km/h km/h mph mph
(exact) (rounded, steps of 5) (exact to 2 decimal places) (rounded, steps of 5)
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 formulae are used to calculate the values listed in Table 4. Additional higher values than
those listed may be used.
For steps of 5 km/h (0, 5, 10, 15, 20, …)
Rounded Speed (km/h) = 5 × [(36 × v + 25)/50]

For steps of 5 mph (0, 5, 10, 15, 20, …)
Rounded Speed (km/h) = 5 × [(360 × v + 401)/802]
Where v is the velocity signalled (in m/s)
In these formulae, the division is an integer division which means that the fractional part (remainder)
is discarded.
7.5 Cause
The cause component (see Table 5) specifies the additional interface including a mandatory CauseCode
for all instances.
Table 5 — Cause
Name Type Multiplicity Description
mainCause tec002:CauseCode 1 Main categorization of the cause according to table
tec002
There are two ways to encode “events” where an effect and one or more causes belong together.
Direct Cause
Direct Cause is where both the effect and the cause are defined together in the same mes-
sage In this case, both the cause and effect are deemed to occur within the same location as
defined by the LRC.
8 © ISO 2016 – All rights reserved

Linked Cause
The other method is called a “LinkedCause” where the effect is defined in one message, but
the detailed cause is defined in a separate message.
In this case, the complete description of the traffic situation will be spread over two or more
separate messages.
7.6 DirectCause
The DirectCause (see Table 6) is used to describe the reason for traffic problem in general.
The main reason for the separation of causes and the effect is so that the traffic situation
...