ISO/TS 18234-9:2013

TECHNICAL ISO/TS
SPECIFICATION 18234-9
First edition
2013-10-15
Intelligent transport systems — Traffic
and travel information via transport
protocol experts group, generation 1
(TPEG1) binary data format —
Part 9:
Traffic event compact (TPEG1-TEC)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via les données de format binaire du groupe d'experts du
protocole de transport, génération 1 (TPEG1)
Partie 9: Événement trafic compact (TPEG1-TEC)

Reference number
©
ISO 2013
©  ISO 2013
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
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – 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 framing and signalling . 2
5.1 Application identification. 2
5.2 Version number signalling . 3
5.3 Application framing . 3
5.4 Application specific constraints . 3
6 Message components . 6
6.1 List of Generic Component Ids . 7
6.2 TECMessage . 7
6.2.1 MessageManagement . 7
6.2.2 Instances of Location Containers . 8
6.2.3 Event . 8
7 Datatypes . 20
7.1 RestrictionType . 20
7.2 SegmentModifier . 21
7.3 TEC Tables . 21
7.3.1 tec001:EffectCode . 21
7.3.2 tec002:CauseCode . 21
7.3.3 tec003:WarningLevel . 23
7.3.4 tec004:LaneRestriction . 24
7.3.5 tec005:AdviceCode . 24
7.3.6 tec006:Tendency . 25
7.3.7 tec007:RestrictionType . 25
7.3.8 tec008:DiversionRoadType . 27
7.3.9 tec009:VehicleType . 27
7.3.10 SubCauseType . 28
7.3.11 SubAdviceType . 39
Annex A (normative) Binary SSF and Data Types . 42
A.1 Conventions and symbols . 42
A.1.1 Conventions . 42
A.1.2 Symbols . 42
A.2 Representation of syntax. 43
A.2.1 General . 43
A.2.2 Data type notation . 43
A.2.3 Application dependent data types . 46
A.2.4 Toolkits and external definition . 50
A.2.5 Application design principles . 51
A.3 TPEG data stream description . 51
A.3.1 Diagrammatic hierarchy representation of frame structure . 51
A.3.2 Syntactical Representation of the TPEG Stream . 52
A.3.3 Description of data on Transport level . 56
A.3.4 Description of data on Service level . 57
A.3.5 Description of data on Service component level . 58
A.4 General binary data types .59
A.4.1 Primitive data types .59
A.4.2 Compound data types .64
A.4.3 Table definitions .67
A.4.4 Tables .69
Annex B (normative) TPEG Message Management Container, MMC (Binary) .85
B.1 Terms and Definitions .85
B.1.1 Message .85
B.1.2 Monolithic Message Management .85
B.1.3 Multi-Part Message Management .85
B.1.4 Top Level Container .85
B.2 Symbols (and abbreviated terms) .85
B.2.1 MMC .85
B.2.2 PKI .85
B.3 Introduction .85
B.4 Message Components .86
B.4.1 MMCTemplate .86
B.4.2 MessageManagementContainer .88
B.4.3 MMCMasterMessage .89
B.4.4 MMCMessagePart .91
B.5 Datatypes .92
B.5.1 MultiPartMessageDirectory .92
B.6 Tables .93
B.6.1 Structure and semantics .93
B.6.2 Indexing .93
B.6.3 Codes, Names and Comments .93
Bibliography .95
iv © ISO 2013 – 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
 an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
 an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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.
ISO/TS 18234-9 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with ISO Technical Committee
ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement).
ISO/TS 18234 consists of the following parts, under the general title Intelligent transport systems — Traffic
and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format:
 Part 1: Introduction, numbering and versions (TPEG1-INV)
 Part 2: Syntax, semantics and framing structure (TPEG1-SSF)
 Part 3: Service and network information(TPEG1-SNI)
 Part 4: Road Traffic Message application (TPEG1-RTM)
 Part 5: Public Transport Information (PTI) application
 Part 6: Location referencing applications
 Part 7: Parking information (TPEG1-PK1)
 Part 8: Congestion and travel-time application (TPEG1-CTT)
 Part 9: Traffic event compact (TPEG1-TEC)
 Part 10: Conditional access information (TPEG1-CAI)
 Part 11: Location Referencing Container (TPEG1-LRC)
vi © ISO 2013 – All rights reserved

Introduction
TPEG technology
TPEG technology uses a byte-oriented data stream format, which may be carried on almost any digital bearer
with an appropriate adaptation layer. TPEG-messages are delivered from service providers to end-users and
used to transfer information from the database of a service provider to an end-user’s equipment.
The brief history of TPEG technology development dates back to the European Broadcasting Union (EBU)
Broadcast Management Committee establishing the B/TPEG project group in autumn 1997 with the mandate
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 are 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.
One year later in December 1998, the B/TPEG group produced its first EBU specifications. Two Technical
Specifications were released. ISO/TS 18234-2, described the Syntax, Semantics and Framing Structure,
which is used for all TPEG applications. ISO/TS 18234-4 (TPEG-RTM) described the first application, for
Road Traffic Messages.
Subsequently, CEN/TC 278/WG 4, in conjunction with ISO/TC 204, established a project group comprising the
members of B/TPEG and they have continued the work concurrently since March 1999. Since then two further
parts were developed to make the initial complete set of four parts, enabling the implementation of a
consistent service. ISO/TS 18234-3 (TPEG-SNI) describes the Service and Network Information Application,
which should be used by all service implementations to ensure appropriate referencing from one service
source to another. ISO/TS 18234-1 (TPEG-INV), completes the series, by describing the other parts and their
relationship; it also contains the application IDs used within the other parts. Additionally ISO/TS 18234-5 the
Public Transport Information Application (TPEG-PTI) and ISO/TS 18234-6 (TPEG-LRC), were developed.
This Technical Specification adds another powerful application for the ISO 18234 series allowing detailed road
event information to be encoded and transmitted to the user. It was developed specifically to satisfy
messaging for Navigation System clients and designed to provide cause and effect in the Road Traffic events
information domain. This Technical Specification includes new advanced message management and new
datatypes as specified in the annexes.
TPEG applications are developed using UML modelling and a software tool is used to automatically select
content which then populates this Technical Specification. Diagrammatic extracts from the model are used to
show the capability of the binary coding in place of lengthy text descriptions; the diagrams do not necessarily
include all relevant content possible.
This Technical Specification describes the binary data format of the on-air interface of the Traffic Event
Compact application, (TPEG-TEC) with the technical version number TPEG-TEC_3.0/001.
TEC Model
The basic concept behind the TEC model is that a traffic situation is described by a primary information
structure describing the most important information to present to a driver and secondary descriptions of the
causes and/or more details. This model enables a traffic editor to describe complex events in a modular way
allowing TEC-based system and mobile terminals to present the message as it was intended by the editor.
This can be either graphical, textual, voice or a combination of those.
Next to the above mentioned requirement, it is very important to design an efficient coding scheme:
 there will be terminal devices with limited resources;
 to be able to extract those elements early that are relevant to the driver's route, it is key to use the
available bandwidth efficiently.
viii © ISO 2013 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 18234-9:2013(E)

Intelligent transport systems — Traffic and travel information
via transport protocol experts group, generation 1 (TPEG1)
binary data format —
Part 9:
Traffic event compact (TPEG1-TEC)
1 Scope
This Technical Specification defines the TPEG application Traffic Event Compact (TEC). It has been
specifically designed to support information about traffic events, e.g. road works, traffic jams. A specific form
of traffic event are local hazard warnings, which as safety-related messages, are sent with high priority to
assist a driver in encountering dangerous situations (e.g. black-ice, accident behind curves, obstacles on
road) unexpectedly.
Generally, TEC focuses on the following requirements:
 ensuring travel safety for the driver;
 enabling the calculation of alternative routes;
 avoiding delays (e.g. traffic jams);
 warning the driver of obstructions on route;
 informing the driver of infrastructural problems (e.g. closed petrol stations, non-functioning emergency
phones).
2 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.
ISO/TS 18234-2, Intelligent transport systems — Traffic and travel information via transport protocol experts
group, generation 1 (TPEG1) binary data format — Part 2: Syntax, semantics and framing structure (SSF)
ISO/TS 18234-11, Intelligent transport systems — Traffic and travel information via transport protocol experts
group, generation 1 (TPEG1) binary data format — Part 11: Location Referencing Container (TPEG1-LRC)
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
3.2
location referencing container
concept applied to the grouping of all 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 The content of a location reference allows the location to be presented in a plain-language manner to the end-
user (e.g. text, speech or icons), and also to be used for navigational purposes, for example, for map-based systems.
3.4
startTime
beginning time of a traffic event
3.5
stopTime
end time of a traffic event
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
CEN Comité Européen de Normalisation
EBU European Broadcasting Union
LRC Location Referencing Container
OSI  Open Systems Interconnection
RTM Road Traffic Message (see ISO/TS 18234-4)
TLV  Tag length value; a coding method
TPEG Transport Protocol Expert Group
WGS 84 World Geodetic System 1984
5 Application framing and signalling
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
IDentification (AID). An AID is defined whenever a new application is developed and these are all listed in
CEN ISO/TS 18234-1.
2 © ISO 2013 – All rights reserved

The application identification number is used within the TPEG-SNI application (ISO/TS 18234-3:2006) to
indicate how to process TPEG content and facilitates the routing of information to the appropriate application
decoder.
For TPEG TEC, AID has the value five (5).
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 CEN ISO/TS 18234-1.
Figure 1 shows the current version numbers for signalling TEC within the SNI application.
major version number 3
minor version number 0
Figure 1 — Current version numbers for signalling of TEC
5.3 Application framing
TEC makes use of the "Service component frame with severity and message count" according to Annex A,
section A.3.2.6.2.4. For explanatory purpose this is repeated here.
< ServCompFramePrioritisedCountedProtected>:= : CRC protected service component frame with group
priority and message count
(header), : Component frame header as defined in A.3.2.6.
(groupPriority), : group priority applicable to all messages in the
ApplicationContent
(messageCount),
: count of messages in this ApplicationContent
external (content), : actual payload of the application
(dataCRC); : CRC starting with first byte after the header

Within the service component frame, the ApplicationContent is defined as follows:
:=
: application content
messageCount * (msg); : Any number of any TEC message components

5.4 Application specific constraints
TPEG-TEC requires the use of a fixed order of components, unlike other TPEG applications. The order is
shown in Figure 2; the first component is MessageManagement. If the message is not a cancel message then
the MessageManagement component shall be followed by the Event component and this is followed by the
LocationReferencing component.
Figure 2 — Every TPEG message is constructed of three containers
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, i.e. they shall not
be spread over a TECMessage.
Extendibility
The requirement of a fixed component order does not forbid the extension of TEC generally. In case of future
extensions, new components may be inserted or existing components may be replaced by new ones without
loosing backward compatibility. That means, a TEC decoder must be able to detect and skip unknown
components. But, it is not allowed that multiple components of the same type which belong to same upper
component are spread over the message.
Example
The Advice component is replaced by BetterAdvice having an own component id. A WeatherSituation
component is inserted after Advice component.

Figure 3 — Example for extension; original component model
4 © ISO 2013 – All rights reserved

Figure 4 — Example for extension; Advice replaced by BetterAdvice and WeatherSituation added
In any case multiple components of the same type which belong to same upper component shall not be
spread over the message.
Example (not allowed)
An Event component has two Cause components. The first one is followed by an Advice component and the
last one related to the same Event component is a Cause component again. This is forbidden.

Figure 5 — Forbidden ordering of same components
Note: If general TPEG Toolkit definitions (e.g. ISO 18234 Part 2) deviate from the definition in this Part, the
definition given herein takes precedence.
6 Message components
class TrafficEventCompact
TECMessage
«OrderedComponentGroup»
+ mmt: MessageManagement
+ event: Event [0.1]
+ loc: ProblemLocation [0.1]
MMCTemplate LocationReferencingContainer
Event
«External» «External»
+ effectCode: tec001:EffectCode
MessageManagement ProblemLocation
+ startTime: DateTime [0.1]
+ stopTime: DateTime [0.1]
+ tendency: tec006:Tendency [0.1]
+ lengthAffected: DistanceMetres [0.1]
+ averageSpeedAbsolute: Velocity [0.1]
+ delay: Duration [0.1]
+ segmentSpeedLimit: Velocity [0.1]
«OrderedComponentGroup»
+ cause: Cause [0.*]
+ advice: Advice [0.*]
+ vehicleRestriction: VehicleRestriction [0.*]
+ diversionRoute: DiversionRoute [0.*]
Cause Adv ice Div ersionRoute
+ mainCause: tec002:CauseCode + adviceCode: tec005:AdviceCode [0.1] + segmentModifier: SegmentModifier [1.*]
+ subAdviceCode: SubAdviceType [0.1]
«OrderedComponentGroup»
+ freeText: LocalisedShortString [0.*]
+ vehicleRestriction: VehicleRestriction [0.*]
«OrderedComponentGroup»
+ vehicleRestriction: VehicleRestriction [0.*]
«DataStructure»
LinkedCause VehicleRestriction
TECDataTypes::SegmentModifier
+ linkedMessage: IntUnLoMB + vehicleType: tec009:VehicleType [0.1]
+ diversionRoadType: tec008:DiversionRoadType
+ COID: IntUnTi [0.1] + restriction: RestrictionType [0.*]
+ SID: ServiceIdentifier [0.1]
«OrderedComponentGroup»
+ segmentLocation: SegmentLocation
«DataStructure»
DirectCause
TECDataTypes::RestrictionType LocationReferencingContainer
+ warningLevel: tec003:WarningLevel
«External»
+ restrictionType: tec007:RestrictionType
+ unverifiedInformation: Boolean
SegmentLocation
+ restrictionValue: IntUnLoMB [0.1]
+ subCause: SubCauseType [0.1]
+ lengthAffected: DistanceMetres [0.1] «OrderedComponentGroup»
+ laneRestrictionType: tec004:LaneRestriction [0.1]
+ restrictionLocation: RestrictionLocation [0.1]
+ numberOfLanes: IntUnTi [0.1]
+ freeText: LocalisedShortString [0.*]
LocationReferencingContainer
«External»
RestrictionLocation
Figure 6 — UML Model of TPEG-TEC
6 © ISO 2013 – All rights reserved

6.1 List of Generic Component Ids
Name Id
TECMessage 0
MessageManagement 1
ProblemLocation 2
Event 3
DirectCause 4
LinkedCause 5
Advice 6
VehicleRestriction 7
DiversionRoute 8
RestrictionLocation 9
SegmentLocation 10
6.2 TECMessage
A TPEG-TEC Message may include:
 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 container are optional.
Event and location container are modelled optionally because cancel messages do not contain these
elements: Cancellation messages shall not include an event and location container whereas normal
messages (cancelFlag = false) shall include exactly one event and one location container.
>:= :Traffic Event Compact Message Component
(0), : id is unique within the scope of the application.
(compLengthInByte), : length of the component counted in bytes.
(attributeBlockLengthInByte); : length of the attribute block in bytes.
(mmt), : {mandatory} Message management container
m * (event)[0.1], : {optional} Event data
m * (loc)[0.1]; : {optional} Location data

6.2.1 MessageManagement
The MessageManagement component is a placeholder for the MessageManagementContainer (MMC) as
specified in Annex B. 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 management data
external ; : see MMC specification

Message Generation Systems shall ensure that the information given in the MMC allows unambiguous
interpretation over the whole time a message is valid. It is particularly important to recognise 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. Multipart message management must not be used.
6.2.2 Instances of Location Containers
The ProblemLocation, RestrictionLocation and SegmentLocation component are instances of the Location
Referencing Container (LRC) as specified in ISO/TS 18234-11. It assigns the traffic event compact (TEC)
application specific local component ID for the LRC. The different places of the LRC components define
different ids to enable separated evolvement over time of these components in the specification. All
component IDs within the LRC are local to the LRC toolkit.
>:
: the information given by the TEC elements (e.g. effect,
= cause , advice) are related to this ProblemLocation;
LRC container
External ;
: see LRC specification
\ >:= DiversionRoute component;
LRC container
external ;
: see LRC specification
\ >:=
LRC container
external ;
: see LRC specification
6.2.3 Event
The Event component with its subordinated component Cause describes in general the impact on the traffic
flow and the related cause.
For example: 'Stationary Traffic, (due to) Narrow Lanes
Rules
 For a single event it should be possible to distinguish between the effect that describes an acute
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 determined by the attribute effectCode. Furthermore the sub-
component Cause can be used to inform or warn the driver for a special situation (e.g. oil on the road).
The following combinations are possible:
1) a message contains only the Event component with its attribute effectCode that describes the
impairment of the traffic flow directly;
2) the previous described element Event is expanded by one or more sub-components Cause. If a
specific traffic flow is not available or shall not be given, the effectCode must set to ‘unknown’.
8 © ISO 2013 – All rights reserved

 A (real) cause can be represented in the message by either a 'DirectCause' or a 'LinkedCause', but not
both.
 Causes and subCauses- CauseCodes can be further specified by subCauseCodes. Each cause having
more than one assigned subCause has an own subCause list numbered tec1xx where ‘xx’ is the code
from tec002. Simple terminals must support at least all causes, terminals with more memory might
support subCauses. In the latter case sub-causes should replace the (Main)cause completely. With other
words: it is not necessary to combine causes and subCause to a meaningful grammar.
 Advices and subAdvices - The principle for Causes and subCauses are also usedfor Advice, with the
exception that the subAdvice tables are numbered tec2xx.
 The component VehicleRestriction can be used to set a filter for different vehicles.
 Table tec001 and tec002 including all subCauseTables (tec1xx) are mainly taken from TMC-Event list
(refer to ISO/TS 14819-2:2003).
startTime and stopTime
Describe the beginning and the end of a traffic event. The terminal should use these values to calculate the
validity of the event. This validity can be guaranteed by the provider only if the transmission channel is
reliable, i.e. the messages expiry time does not elapse. If the message expiry time elapses, the validity can
not be guaranteed and it is recommended to ignore the message. Finally, the use of the message is up to the
device.
LengthAffected and Length in ProblemLocation (LocationReferencingContainer)
The Length in the location referencing container ProblemLocation, called ProblemLength, describes the
overall length of the event.
If LengthAffected is not defined within the Event component or any Cause of the Event Container, the Length
of ProblemLocation has to be taken.
If the LengthAffected is given by an Event or Cause component it has to be taken only for the specific
component.
In any case, the LengthAffected must not be greater than the ProblemLength.
If, in case of TMC location coding, neither LengthAffected nor ProblemLength is given, the total length
between Primary and Secondary Location has to be taken.
The reference point for the EffectCode and all Causes is defined by the ProblemLocation. If
DLR1LocationReference or TMCLocationReference method is used, the reference point is defined as follows:
 the Start Location, in case of TMCLocationReference precise location referencing (refer to ISO/TS 14819-
3:2004),
 the Secondary Location, in case of TMCLocationReference without precise location referencing (refer
to ISO/TS 14819-3:2004), or
 the first location point, in case of DLR1LocationReference (refer to ISO 17572-3).
Some examples are shown in section “LinkedCause”.Other location referencing methods may also be used
even if they are not described here.
Rounding of speed information
Speed information is always given in metres per seconds (m/s) since the general TPEG data type ‘Velocity’ is
used. Depending on customer requirements the terminal has to convert and round these values.
EXAMPLE
m/s km/h km/h mph mph
(exact) (rounded, steps (exact) (rounded, steps
of 5) 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 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 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 above in the table:
For steps of 5 km/h (0, 5, 10, 15, 20, …)
 ROUND((v*3,6)/5)*5
For steps of 5 mph (0, 5, 10, 15, 20, …)
 ROUND((v*3,6)/1,604)/5)*5
‘ROUND’ in this case is a typical mathematical function to round values without fractional digits.
The Event component is coded as follows:
>:=
(3), : Identifier = 3
(lengthComp), : Length of component in bytes, excluding the id and
length indicator
(lengthAttr), : Length of attributes of this component in bytes
(effectCode),
: Describes the impairment of the traffic flow
(selector), : 1 byte containing 7 switches.
If (bit 0 of selector is set)
(startTime), : Date and time at which an event began or is
scheduled to begin (used for presentation to the end-
user). If startTime is missing first time of reception is
used instead.
10 © ISO 2013 – All rights reserved

If (bit 1 of selector is set)
(stopTime), : Date and time at which an event, or status
information, ended or is scheduled to end (used for
presentation to the end-user). If stopTime is missing
stopTime is set to startTime plus default duration,
which is defined per main cause. In case of multilple
causes the highest default duration shall be taken.
If (bit 2 of selector is set)
(tendency), : Tendency is related to traffic flow. It is not a forecast.
compared with TMC it is not related to the jam length.
If (bit 3 of selector is set)
(lengthAffected), : Length of the event in metres.
If (bit 4 of selector is set)
(averageSpeedAbsolute), : Average speed in m/s at the given location. It is
recommended to use this value for calculation of the
route and the referring arrival time.
If (bit 5 of selector is set)
(delay), : Delay in minutes. Only applicable to point locations,
i.e. at border.
If (bit 6 of selector is set):

(segmentSpeedLimit), : Maximum speed in m/s. Shall be used as
adminstrativ speed limit for re-routing, but not to
display or warn the driver because qualitiy cannot be
guaranteed.
m * [0.*], : A Cause might be only represented by instances of
Cause, either as LinkedCause or as DirectCause.
Within a single message, the same cause code shall
not be used for linked and direct causes.
Multiplicity of Cause is then 0…infinity
m * [0.*], : m represents the number of occurrences, between 0
and infinity.
m * [0.*], : m represents the number of occurrences, between 0
and infinity.
m * [0.*]; : m represents the number of occurrences, between 0
and infinity.
6.2.3.1 Cause
The cause template specifies the additional interface including a mandatory CauseCode for all instances.
>:= : Template for causes
(id),
(lengthComp), : Length of component in bytes, excluding the id and
length indicator
(lengthAttr), : Length of attributes of this component in bytes
(mainCause); : Main categorization of the cause according to table
tec002
6.2.3.2 DirectCause
The component DirectCause can be used to describe the reason for traffic congestion in general. The main
reason for the separation of causes and the effect is that the real traffic situation can be described in
meaningful way to the driver.
EXAMPLE Road closed (effectCode=7), (due to) objects on the road (causeCode 10).
>:=
(4), : Identifier
(lengthComp), : Length of component in bytes, excluding the id and
length indicator
(lengthAttr), : Length of attributes of this component in bytes
(mainCause), : Main categorization of the cause according to table
tec002
(warningLevel), : The level informative should be used for all traffic
events, which may influence the drivers' route in any
way and might require normal attention from the driver.
The danger levels 1 to 3 should only be used for really
dangerous situations, e.g. ghost-driver. The danger
levels 1 to 3 in combination with unverifiedInformation
= True should be used in case of an unverified danger.
For example, a traffic management centre receives a
call from a private "jam buster" that there is a "ghost-
driver", but the event is still not confirmed by the
police.
(selector), : 1 byte containing 6 switches.
If (bit 0 of selector is set)
(unverifiedInformation), : If element is set to 1 the given information has not
been verified.
If (bit 1 of selector is set)
(subCause), : Carries the value in the sub cause table defined by
the mainCauseCode.
If (bit 2 of selector is set)
(lengthAffected), : Length of the event in metres.
If (bit 3 of selector is set)
12 © ISO 2013 – All rights reserved

(laneRestrictionType), : Specifies whether lanes are closed or opened.
If (bit 4 of selector is set)
(numberOfLanes), : Specifies how many lanes are closed or opened. If
this element is not given, the plural form shall always
be used.
If (bit 5
...