CEN ISO/TS 18234-9:2013

SLOVENSKI STANDARD
01-marec-2014
,QWHOLJHQWQLWUDQVSRUWQLVLVWHPL3URPHWQHLQSRWRYDOQHLQIRUPDFLMHSUHN
L]YHGHQVNHVNXSLQH]DWUDQVSRUWQHSURWRNROHELQDUQLSRGDWNRYQLIRUPDW
JHQHUDFLMH73(*GHO=JRãþHQLSRGDWNLRSURPHWQLKGRJRGNLK73(*7(&
,6276
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) (ISO/TS 18234-9:2013)
Intelligente Transportsysteme - Reise- und Verkehrsinformation über Datenströme der
Transportprotokoll Expertengruppe (TPEG) - Teil 9: Kompakte Verkehrsereignisse
(TPEG-TEC) (ISO/TS 18234-9:2013)
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) (ISO/TS 18234-9:2013)
Ta slovenski standard je istoveten z: CEN ISO/TS 18234-9:2013
ICS:
03.220.01 Transport na splošno Transport in general
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN ISO/TS 18234-9
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
October 2013
ICS 35.240.60
English Version
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)
(ISO/TS 18234-9:2013)
Systèmes intelligents de transport - Informations sur le trafic Intelligente Transportsysteme - Reise- und
et le tourisme via les données de format binaire du groupe Verkehrsinformation über Datenströme der
d'experts du protocole de transport, génération 1 (TPEG1) - Transportprotokoll Expertengruppe (TPEG) - Teil 9:
Partie 9: Événement trafic compact (TPEG1-TEC) (ISO/TS Kompakte Verkehrsereignisse (TPEG-TEC) (ISO/TS
18234-9:2013) 18234-9:2013)
This Technical Specification (CEN/TS) was approved by CEN on 15 July 2013 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

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

Contents Page
Foreword .3
Foreword
This document (CEN ISO/TS 18234-9:2013) has been prepared by Technical Committee ISO/TC 204
"Intelligent transport systems" in collaboration with Technical Committee CEN/TC 278 “Intelligent transport
systems” the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
Endorsement notice
The text of ISO/TS 18234-9:2013 has been approved by CEN as CEN ISO/TS 18234-9:2013 without any
modification.
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/TS 18234-9:2013(E)
©
ISO 2013
ISO/TS 18234-9:2013(E)
©  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

ISO/TS 18234-9:2013(E)
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
ISO/TS 18234-9:2013(E)
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

ISO/TS 18234-9:2013(E)
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
ISO/TS 18234-9:2013(E)
 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

ISO/TS 18234-9:2013(E)
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;
ISO/TS 18234-9:2013(E)
 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.
ISO/TS 18234-9:2013(E)
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

ISO/TS 18234-9:2013(E)
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.
ISO/TS 18234-9:2013(E)
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

ISO/TS 18234-9:2013(E)
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.
ISO/TS 18234-9:2013(E)
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

ISO/TS 18234-9:2013(E)
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.
ISO/TS 18234-9:2013(E)
:= : 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

ISO/TS 18234-9:2013(E)
 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.
ISO/TS 18234-9:2013(E)
Rounding of speed information
Speed informatio
...