ISO/TS 21219-2:2014

TECHNICAL ISO/TS
SPECIFICATION 21219-2
First edition
2014-09-15
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 2:
UML modelling rules
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 2: Règles de modelage UML
Reference number
©
ISO 2014
© ISO 2014
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 2014 – All rights reserved

Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Terms, definitions and abbreviated terms . 1
2.1 Terms and definitions . 1
2.2 Abbreviated terms . 2
3 TPEG UML model definition . 2
3.1 Allowed UML elements . 2
3.2 Modelling rules and recommendations . 7
3.3 Extending TPEG UML models .12
3.4 Adding documentation to TPEG UML models .12
4 Drafting specifications using UML models .13
4.1 Specification of contents .13
4.2 Normative clauses .15
4.3 Specification of normative annexes .16
Annex A (normative) TPEG abstract data types .17
Annex B (normative) TPEG tables .20
Bibliography .44
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, in cooperation
with the Traveller Information Services Association (TISA), TPEG Applications Working Group through
Category A Liasion status.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol expert group, generation 2 (TPEG2):
— 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 [Technical Specification]
— Part 6: Message management container [Technical Specification]
— Part 7: Location referencing container [Technical Specification]
— Part 18: Traffic flow and prediction application [Technical Specification]
The following parts are planned:
— Part 1: Introduction, numbering and version [Technical Specification]
— Part 9: Service and network information [Technical Specification]
— Part 10: Conditional access information [Technical Specification]
— Part 14: Parking information application [Technical Specification]
— Part 15: Traffic event compact application [Technical Specification]
— Part 16: Fuel price information application [Technical Specification]
iv © ISO 2014 – All rights reserved

— Part 19: Weather information for travellers application [Technical Specification]
— Part 20: Extended TMC locations for applications [Technical Specification]
— Part 21: Geographic location referencing [Technical Specification]
— Part 22: OpenLR·location·reference [Technical Specification]
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/WG 4, in conjunction with ISO/TC 204/WG 10, established a
project group comprising members of the former EBU B/TPEG and they continued the work concurrently.
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
With the inauguration of the Traveller Information Services Association (TISA) in December 2007
derived from former Forums and the CEN/ISO development project group, the TPEG Applications
Working Group took over development work for TPEG technology.
It was about this time that the (then) new Unified Modeling 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 realised
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 Parts 2, 3, 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 minimise drafting
errors, that forms the Annex for each physical format.
vi © ISO 2014 – All rights reserved

TPEG2 has a three container conceptual structure: Message Management (Part 6), Application (many
Parts) and Location Referencing (Part 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.
Toolkit parts: TPEG2-INV (Part 1), TPEG2-UML (Part 2), TPEG2-UBCR (Part 3), TPEG2-UXCR (Part 4),
TPEG2-SFW (Part 5), TPEG2-MMC (Part 6), TPEG2-LRC (Part 7)
Special applications: TPEG2-SNI (Part 9), TPEG2-CAI (Part 10)
Location referencing: TPEG2-ULR (Part 11), TPEG2-ETL (Part 20), TPEG2-GLR (Part 21), TPEG2-OLR
(Part 22)
Applications: TPEG2-PKI (Part 14), TPEG2-TEC (Part 15), TPEG2-FPI (Part 16), TPEG2-TFP (Part 18),
TPEG2-WEA (Part 19), TPEG2-RMR (Part 23)
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.
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, whilst 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.
TECHNICAL SPECIFICATION ISO/TS 21219-2:2014(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 2:
UML modelling rules
1 Scope
This Technical Specification specifies rules for the creation and extending of TPEG application UML
models. The rules are intended to ensure that TPEG application UML models can be interpreted
unambiguously for conversion to physical format representations. TPEG application UML models that
are defined according to these rules may be used for automatic generation of TPEG standards and for
automatic generation of TPEG application physical format descriptions.
This Technical Specification also specifies the preferred structure of TPEG application specifications.
The TPEG abstract data types and the set of TPEG tables of common use are specified in the annexes.
2 Terms, definitions and abbreviated terms
2.1 Terms and definitions
2.1.1
abstract data type
data type of atomic nature
2.1.2
attribute compartment
graphical section of a UML class box positioned directly under the class name compartment
2.1.3
class name compartment
top most graphical section of a class box defining the name of the class and optionally a stereotype,
inherited class and package scope
2.1.4
data structure
data type being composed of other data types being either of abstract or complex data type, not having
a component header, stereotyped as <>
2.1.5
component
revisable, named, complex data type, not stereotyped as <>
2.1.6
component header
data structure consisting of a component identifier, component length indicator and attribute length
indicator
2.1.7
element
component or data structure
2.1.8
link
relation between two or more elements
2.1.9
TPEG Application
set of classes and rules defining TPEG information services at the highest layer of the ISO OSI model
2.2 Abbreviated terms
IPR Intellectual Property Right(s)
ISO International Organization for Standardization
LRC Location Referencing Container
MMC Message Management Container
OSI Open Systems Interconnection
PTI PTI Public Transport Information
TISA Traveller Information Services Association
TPEG Transport Protocol Experts Group
UML Unified Modelling Language
3 TPEG UML model definition
3.1 Allowed UML elements
[1]
TPEG UML models are based on the UML standard , but only use a subset of the elements defined in
the standard. This clause provides a description of the elements of UML that are used for modelling
TPEG. This clause also defines restrictions on these elements. TPEG UML models shall only use the UML
elements described in this clause. The defined restrictions shall be obeyed.
3.1.1 Class
A class provides a description of the structure of the data stored in an instance of a class. The data are
stored in the class attributes.
3.1.2 Abstract class
Abstract classes may be used to define shared properties of specialized child classes.
3.1.3 Attribute
An attribute provides a data type description of data that is stored in a class. Attributes can be either
of primitive data type or compound data type. Within a class, an attribute has a multiplicity. If not
explicitly indicated, the multiplicity is one. Other multiplicities may be indicated between square
brackets: [minOccurs . maxOccurs].
2 © ISO 2014 – All rights reserved

Attribute multiplicity shall be interpreted as listed in Table 1. If no multiplicity is indicated, a multiplicity
of one (mandatory attribute) is implied.
Table 1 — TPEG multiplicity
Multiplicity TPEG meaning
1 mandatory attribute
1.n mandatory list of attributes
0.1 optional attribute
0.n optional list of attributes
Attributes in classes are always modelled as public. Each attribute must have a data type. Attributes
occur in the order as listed in the class definition in TPEG physical formats, unless this is overruled by
the stereotype <> .
3.1.4 Dependency
Graphical representation used for ordered components (attributes stereotyped
as <> ) and DataStructures to show the hierarchical structure of the UML
model.
Figure 1 — UML dependency relation
3.1.5 Aggregation
An aggregation is an association representing a part-whole relationship. The containing object may have
objects of the contained class, but the contained class is not life cycle dependent of the containing class.
Classes included by aggregation may occur in random order in TPEG physical formats.
NOTE Using aggregations in TPEG UML Models is deprecated. Instead of using aggregations,
the aggregated class should be included as attribute. The attribute can then either be stereotyped
as <> or <> (see 3.1.8 for details).
Figure 2 — UML aggregation relation
3.1.6 Composition
A composition is a stronger variant of the aggregation association. The contained object can only exist
within the container class. Classes included by composition may occur in random order in TPEG physical
formats.
NOTE Using compositions in TPEG UML Models is deprecated. Instead of using compositions,
the composed class should be included as attribute. The attribute can then either be stereotyped
as <> or <> (see 3.1.8 for details).
4 © ISO 2014 – All rights reserved

Figure 3 — UML composition relation
3.1.7 Specialization
A specialization relates a parent class to a child class. The child class inherits properties from the parent
class. Classes shall not inherit from multiple parent classes. Classes shall only inherit from classes with
the same stereotype.
Derived classes copy all attributes from the parent class. Parent classes shall contain no aggregations
or classes not stereotyped as <> . Parent classes shall be modelled as abstract class. In
future versions of a standard, parent classes shall not be extended. Classes shall not be both parent and
child class.
NOTE Extending parent classes in future versions of a standard breaks backwards compatibility.
Figure 4 — UML specialization relation
3.1.8 Stereotype
A stereotype is used to provide an additional classification of UML properties. A physical format
specification may use stereotype information to select a rule set for converting UML to the physical
format.
The stereotypes as listed in Table 2 may be used for UML modelling of TPEG applications. Other
stereotypes shall not be used.
Table 2 — TPEG stereotypes
UML element Stereotype TPEG meaning
Package TPEG Application self standing protocol specification for a given applica-
tion
Package TPEG Toolkit specification of general interest being referenced by dif-
ferent other specifications
Package TPEG DataTypes specification defining data structures and tables belong-
ing to one single package
Class DataStructure TPEG data structure
Class Enumeration list of defined, constant expressions not containing
attributes or sub data elements
Class External TPEG Component defined in an external document
Attribute OrderedComponentGroup Attribute is of component type, and belongs to the group
of components occurring in the order as defined by the
attribute order
Attribute UnorderedComponentGroup Attribute is of component type, and belongs to the group
of components that may occur in random order, after all
other attributes.
6 © ISO 2014 – All rights reserved

3.1.9 Tagged values
Tagged values may be used to provide additional information on a UML element, used for the creation of
the specification document.
Only the tagged values listed in Table 3 shall be used.
Table 3 — Allowed tagged values
Tag TPEG meaning Example
ApplicationAbbreviation Abbreviation of the application name TEC
ApplicationName Name of the application Traffic Event Compact
ApplicationRoot Root class of an application TECMessage
TableEntryExample Comment for a table entry
Documentation Description of generic properties of a
class
Description Description of single attributes within a
class
In UML packages that are stereotyped as <> , the ApplicationAbbreviation,
ApplicationName and ApplicationRoot tagged values are mandatory.
3.1.10 Notes
Notes may be used to provide additional information that is used for generating the specification
document.
3.2 Modelling rules and recommendations
TPEG UML models are used to generate TPEG specifications. A fundamental assumption is that
applications will develop and new features will be added. Correct designs permit applications to be
upgraded and extended over time, providing new features to new decoders, and yet permit existing
decoders to continue to operate. This clause describes design principles that shall be obeyed when
building and upgrading TPEG applications.
3.2.1 Order of elements
In a physical format, attributes shall occur in the same order as listed in the UML class definition.
When components may occur in any order (independent of the order in which they
are listed in the UML class definition), they should be modelled as attributes with the
stereotype <> and of the type of the corresponding class. The unordered
components shall be linked by the embedding class using a dependency relation.
When components shall occur in a specific order, they shall be modelled as attributes with the
stereotype <> and of the type of the corresponding class. The ordered
components shall be linked by the embedding class using a dependency relation.
Mandatory attributes should occur before optional attributes. Mandatory Booleans should occur after the
other mandatory attributes. Optional attributes should occur after mandatory attributes. Components
shall occur after all other attributes. Ordered components shall occur before unordered components.
Figure 5 — Ordering of class elements
NOTE Special rules for extending TPEG UML models for newer revisions of a standard are provided in 3.3.
Extending TPEG UML models in a backwards compatible way may break the recommendations for ordering
mandatory and optional elements described in 3.2.1.
3.2.2 Stereotypes
3.2.2.1 TPEG Application
The <> stereotype is used to identify a UML package as TPEG Application.
3.2.2.2 TPEG Toolkit
TPEG Toolkits are used to share common functionality between different TPEG Applications. For example
the Location Referencing Container and Message Management Container are toolkits that are used by
all TPEG applications. A TPEG Application therefore can refer to a data type definition not specified in
the same model.
TPEG Toolkits are designed such that its root components are defined as templates which can be used as
external reference within other packages. A TPEG Application using a toolkit template therefore needs
to specify a unique interface class for this instantiation of the imported toolkit interface’s component.
All subsequent components in a toolkit are defined as out of the scope of the TPEG application, i.e. the
toolkit on its own defines subcomponents beginning with local identifiers.
The <> stereotype is applied at UML package level.
3.2.2.3 TPEG DataTypes
General TPEG datatypes and TPEG Application specific datatypes are defined in separate UML packages.
This only applies for elementary data types and classes that are stereotyped as <> .
The <> stereotype is applied at UML package level.
3.2.2.4 DataStructure
The TPEG binary format distinguishes between components and datastructures. In this physical
representation, a componenent is a compound data type, containing a header, providing type and length
information. The type information of a component shall be unique within an application. A datastructure
is a compound datatype not containing this type and length information.
8 © ISO 2014 – All rights reserved

Datastructures shall explicitly be stereotyped as <> . Classes that are not explicitly
stereotyped as <> shall be interpreted as component. The differentiation between
components and datastructures is not relevant for tpegML as both variants are represented as xs:element.
Components can be included in classes both by using an aggregation or composition or by attributes
typed as this component. Datastructures shall not be included using an aggregation or composition, but
shall be included as regular attribute only.
The <> stereotype is applied at UML class level.
NOTE The specific usage of datastructures or components depends on the requirements of the particular
application. Components should be used wherever future extensions are envisioned, and where ‘future proofing’
is a strong requirement. Datastructures are more bandwidth efficient as they contain no header information but
are not extendible in a backwards-compatible manner.
3.2.2.5 Enumeration
TPEG Tables are modelled as enumerations and shall have no more than 256 entries. Each enumeration
shall have a nunique name which consists of two parts. The first part is the abbreviation of the application
where the enumeration is specified in, appended with a three-digit number, starting at value 001. The
second part is a description of the content of the table in camel-case. The two parts are separated by a
semicolon.
EXAMPLE typ001:LanguageCode
When applicable, the enumeration entry with index zero should have the value “unknown”. If tables are
likely to be extended in future versions of a standard, a default value shall be defined. This default value
shall have index 255.
EXAMPLE See Figure 6.
Figure 6 — Enumeration stereotype
The < < Enumeration > > stereotype is applied at UML class level.
3.2.2.6 External
TPEG applications can use classes that are not defined in the same package, but are defined in other
TPEG applications or TPEG toolkits. These classes shall be stereotyped as <> .
The <> stereotype is applied at UML class level.
3.2.2.7 UnorderedComponentGroup
By default, components that are included in classes are unordered: The order in which the components
appear in a model has no influence on the order in a physical format representation. These components
should be modelled as attributes with the stereotype <> .
The <> stereotype is applied at UML attribute level.
NOTE Unordered components could also be included by aggregation or composition. Due to practical and
model layout reasons, this method is deprecated. Use of the method described above is encouraged.
3.2.2.8 OrderedComponentGroup
By default, components that are included in classes are unordered (see 3.2.2.7). When
components should appear in a fixed order, they shall be modelled as attributes with the
stereotype <> and of the type of the corresponding class. See 3.2.1 for
details on ordering of attributes.
The <> stereotype is applied at UML attribute level.
3.2.3 Data types
An overview of TPEG abstract data types is given in Annex A.
3.2.4 Optional Booleans
Due to encoding in the binary physical format, usage of optional Booleans is deprecated. The preferred
solution is to use two mandatory Booleans, with the first one indicating the validity of the second
Boolean. Alternatively, the enumeration as defined in typ008:OptionalBoolean (see Annex B) may be
used as attribute.
3.2.5 Tables and Switching Tables
TPEG Tables represent defined groupings of pre-defined concepts (see 3.2.2.5 for details on the modelling
of tables and Annex B for an overview of the general TPEG tables). TPEG enables hierarchical tables
(see example below) by using ‘Switching Tables’. Switching Tables are modelled in UML using abstract
classes. The switched table is referenced by including an attribute of the abstract table class type (see
Figure 7).
Figure 7 — TPEG Switching Table concept
10 © ISO 2014 – All rights reserved

The Application Specification shall define an unambiguous relation between the mainTable entry and
the switchedTable type. It is recommended that the name of the switchedTable matches the entry in the
mainTable and that the switchedTable number has a direct relation with the mainTable number.
EXAMPLE ‘One table called ‘xyz001:furniture’ has one entry ‘1:chair’. One hierarchical level below the
‘xyz001:furniture’ table might be a table called ‘xyz101:chair’, having entries ‘1:computer chair’, ‘2:rocking chair’,
etcetera. If an attribute of type xyz001:furniture has value 1, the referenced table is of type xyz101:chair.
3.2.6 Aggregations and compositions of DataStructures
Classes that are stereotyped as <> shall not be included in a class using aggregation or
composition but by an attribute of type of this DataStructure.
3.2.7 Aggregations and compositions in DataStructures
Classes that are stereotyped as <> shall not include classes using aggregation or
composition. When a class stereotyped as <> shall include a class, this class shall be
modelled as an attribute stereotyped as <> .
3.2.8 Linking abstract classes
Classes can link to abstract classes. In this case, an instance of exactly one of the child classes is
instantiated.
EXAMPLE The LinkingClass has one attribute of abstract type, which can be instantiated with ChildClass1
and ChildClass2 (see Figure 8). The class only links to the abstract class. Each linked instance is of one of the two
child class types.
Figure 8 — Linking of abstract class
3.2.9 Graphical representation
Linked classes should be represented below the linking class. This provides a graphical hierarchical
representation, improving readability.
3.2.10 Documentation
Each class should contain a functional description of the class and its attributes.
NOTE More information on documenting TPEG UML models is given in 3.4.
3.3 Extending TPEG UML models
TPEG provides means for extending applications without breaking backward compatibility. Classes can
be extended by appending components, mandatory and optional attributes.
For each revision of a standard, the following rules shall be obeyed:
Classes that are stereotyped as <> shall not be extended.
Mandatory attributes shall be appended after all previously defined attributes and before all components
that are modelled as attributes with the stereotype <> . Optional attributes
shall be appended after all previously defined attributes and newly added mandatory attributes and before
all components that are modelled as attributes with the stereotype <> .
The order and the multiplicity of the attributes shall not be changed.
Newly added ordered components shall occur only after the last ordered component of the extended class.
No additional rules for adding components not stereotyped as <> apply.
Newly added unordered components shall only occur after the last unordered component
of the extended class. No additional rules for adding components not stereotyped
as <> apply.
Attributes and aggregations shall not be added to parent classes (classes that other classes inherit from),
this would cause breaking backward compatibility.
Other application extensions break backward compatibility and are therefore strongly depreciated.
EXAMPLE Figure 9 shows a complex component in a first and second revision of a standard. The second
revision contains a newly added mandatory attribute, optional attribute and ordered component.
Figure 9 — Extending a TPEG component in a backwards compatible way
3.4 Adding documentation to TPEG UML models
Several parts from TPEG specifications are automatically generated from TPEG UML models. This
particularly concerns class and attribute descriptions. All information required for generating these
TPEG specification sections is contained in the UML models.
12 © ISO 2014 – All rights reserved

3.4.1 Class documentation
Each class
3.4.2 Attribute description
4 Drafting specifications using UML models
This clause specifies rules for creating TPEG specification documents using TPEG compliant UML models.
4.1 Specification of contents
4.1.1 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, in cooperation
with the Traveller Information Services Association (TISA), TPEG Applications Working Group through
Category A Liasion status.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol expert group, generation 2 (TPEG2):
— 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 [Technical Specification]
— Part 6: Message management container [Technical Specification]
— Part 7: Location referencing container [Technical Specification]
— Part 18: Traffic flow and prediction application [Technical Specification]
The following parts are planned:
— Part 1: Introduction, numbering and version [Technical Specification]
— Part 9: Service and network information [Technical Specification]
— Part 10: Conditional access information [Technical Specification]
— Part 14: Parking information application [Technical Specification]
— Part 15: Traffic event compact application [Technical Specification]
— Part 16: Fuel price information application [Technical Specification]
— Part 19: Weather information for travellers application [Technical Specification]
— Part 20: Extended TMC locations for applications [Technical Specification]
— Part 21: Geographic location referencing [Technical Specification]
— Part 22: OpenLR·location·reference [Technical Specification]
4.1.2 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/WG 4, in conjunction with ISO/TC 204/WG 10, established a
project group comprising members of the former EBU B/TPEG and they continued the work concurrently.
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
14 © ISO 2014 – All rights reserved

With the inauguration of the Traveller Information Services Association (TISA) in December 2007
derived from former Forums and the CEN/ISO development project group, the TPEG Applications
Working Group took over development work for TPEG technology.
It was about this time that the (then) new Unified Modeling 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 realised
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 Parts 2, 3, 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 minimise drafting
errors, that forms the Annex for each physical format.
TPEG2 has a three container conceptual structure: Message Management (Part 6), Application (many
Parts) and Location Referencing (Part 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.
Toolkit parts: TPEG2-INV (Part 1), TPEG2-UML (Part 2), TPEG2-UBCR (Part 3), TPEG2-UXCR (Part 4),
TPEG2-SFW (Part 5), TPEG2-MMC (Part 6), TPEG2-LRC (Part 7)
Special applications: TPEG2-SNI (Part 9), TPEG2-CAI (Part 10)
Location referencing: TPEG2-ULR (Part 11), TPEG2-ETL (Part 20), TPEG2-GLR (Part 21), TPEG2-OLR
(Part 22)
Applications: TPEG2-PKI (Part 14), TPEG2-TEC (Part 15), TPEG2-FPI (Part 16), TPEG2-TFP (Part 18),
TPEG2-WEA (Part 19), TPEG2-RMR (Part 23)
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.
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, whilst 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.
4.1.3 Scope
[2]
Rules for the drafting of the scope of TP
...