ISO 21219-3:2019

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 3: UML to binary conversion rules (TPEG2-UBCR)

TPEG applications are modelled in UML to provide an application description that is independent of a physical format representation. By separating semantics from application description, applications can easily be developed at a functional level. Different physical format representations can be generated following a well defined set of rules on how to convert UML classes to different physical formats. This document specifies the rules for converting UML models of TPEG application to the TPEG binary format. It contains the binary format definition of the abstract data types defined in ISO 21219-2. Rules for converting compound data types are also defined.

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 3: Règles de conversion d'UML à système binaire

General Information

• Status: Published
• Publication Date: 23-Jul-2019
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 06-Jun-2025
• Completion Date: 13-Dec-2025

Relations

• Revises: ISO/TS 21219-3:2015 - Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 3: UML to binary conversion rules
• Effective Date: 23-Apr-2020

Overview - ISO 21219-3:2019 (TPEG2-UBCR)

ISO 21219-3:2019, titled Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 3: UML to binary conversion rules (TPEG2‑UBCR), defines how TPEG2 applications modelled in UML are converted into the TPEG binary format. The standard separates semantics (UML application models) from physical format representations, providing a repeatable, tool-friendly rule set to produce a binary representation for Traffic and Travel Information (TTI) applications.

Key topics and technical requirements

• UML to binary conversion rules: Normative rules for converting UML classes, attributes and relationships into the binary encoding required by TPEG2.
• Binary format description: Required structure for the binary-format annex in application specifications, including Introduction, Application framing and signalling, Application components, and Application datastructures.
• Abstract data types: Binary definitions for the abstract data types specified in ISO 21219‑2 are provided and must be followed when encoding.
• Compound data types: Specific rules for converting classes, data structures, selectors and attribute multiplicities (single, optional, repeating) into binary.
• Application framing & signalling: Rules for Application Identifier (AID), version number signalling (major/minor), and selection of the appropriate Service Component Frame type for transmission.
• Component IDs and TPEG tables: Guidance for assigning unique component IDs for UML classes (excluding those stereotyped as <>) and representing TPEG tables in binary.
• Robustness features: Use of a binary component structure to detect and skip unknown content (see Annex A), aiding forward/backward compatibility.
• Normative references: Works in conjunction with ISO 21219‑2 (UML modelling rules), ISO 21219‑5 (service framework) and IEEE/ISO floating-point rules where applicable.

Practical applications and target users

ISO 21219-3 is intended for:

• ITS architects and system designers creating TPEG2 traffic and travel information services.
• Application developers and tool vendors implementing automated conversion tools (UML XMI → TPEG binary).
• Broadcasters, telematics and navigation vendors, automotive OEMs and mobile content providers who encode, transmit or decode TTI messages.
• Standards and compliance teams preparing application specification annexes for TPEG binary deployment.

Practical benefits include consistent binary encoding, multi-format interoperability (binary + XML), easier maintenance of application semantics, and improved compatibility across service versions and decoders.

Related standards

• ISO 21219‑2 - TPEG2 UML modelling rules (normative companion)
• ISO 21219‑5 - TPEG2 Service framework (framing and SC types)
• ISO/IEC/IEEE 60559 - Floating‑point arithmetic (used where numeric types apply)

Keywords: ISO 21219-3:2019, TPEG2, UML to binary conversion, TPEG binary format, traffic and travel information, ITS, UML modelling, application framing.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-3
First edition
2019-07
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 3:
UML to binary conversion rules
(TPEG2-UBCR)
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 3: Règles de conversion d'UML à système binaire
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Rules for UML to binary format description conversion . 2
5.1 Definition of binary format description . 2
5.2 Abstract data types . 3
5.3 Binary format specific data types . 9
5.4 TPEG tables . 9
5.5 Compound data types .10
5.5.1 Rule 1: Classes .10
5.5.2 Rule 2: Datastructures .11
5.5.3 Rule 3: Selector .11
5.5.4 Rule 4: Attributes.12
5.5.5 Rule 4a: Datatypes .12
5.5.6 Rule 4b: Ordering .12
5.5.7 Rule 4c: Single multiplicity . .12
5.5.8 Rule 4d: Multiplicity [0.maxOccurs>1], Multiplicity [1.maxOccurs>1] and
Multiplicity [minOccurs>1.maxOccurs>1] .12
5.5.9 Rule 4e: Multiplicity [0.1].14
5.5.10 Rule 6 — Specialisations/Abstract classes .15
Annex A (normative) Usage of the binary component structure to detect and skip unknown
content .17
Bibliography .19
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces ISO/TS 21219-3:2015 which has been technically revised. The
main changes compared to the previous edition are as follows:
A list of all parts in the ISO 21219 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2019 – All rights reserved

Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax,
semantics and framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
Further parts were developed to make the initial set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the service and network information
application used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
public transport information application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications of parts of the
ISO/TS 18234 series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of
rules that contain the modelling strategy covered in ISO 21219-2, ISO 21219-3 and ISO 21219-4 and
the conversion to two current physical formats: binary and XML; others could be added in the future.
TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word
document file, to minimize drafting errors, that forms the annex for each physical format.
TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application
(several parts) and location referencing (ISO/TS 21219-7). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose. Note that the list below may be incomplete, e.g. new TPEG2 parts may be introduced
after publication of this document.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3),
TPEG2-UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC
(ISO/TS 21219-7).
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10), TPEG2-LTE
(ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO17572-2), TPEG2-DLR (ISO17572-3).
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25), TPEG2-VLI (ISO/TS 21219-26).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as parking information.
This document is based on the TISA specification technical/editorial version reference: SP10032.
vi © ISO 2019 – All rights reserved

INTERNATIONAL STANDARD ISO 21219-3:2019(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 3:
UML to binary conversion rules (TPEG2-UBCR)
1 Scope
TPEG applications are modelled in UML to provide an application description that is independent of a
physical format representation. By separating semantics from application description, applications can
easily be developed at a functional level. Different physical format representations can be generated
following a well defined set of rules on how to convert UML classes to different physical formats.
This document specifies the rules for converting UML models of TPEG application to the TPEG binary
format. It contains the binary format definition of the abstract data types defined in ISO 21219-2. Rules
for converting compound data types are also defined.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 21219-2, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 2: UML modelling rules
ISO 21219-5, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 5: Service framework
ISO/IEC/IEEE 60559, Information technology — Microprocessor Systems — Floating-Point arithmetic
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
4 Abbreviated terms
The abbreviated terms defined in ISO 21219-2 and the following apply.
LSB Least Significant Bit
LSByte Least Significant Byte
MSB Most Significant Bit
MSByte Most Significant Byte
5 Rules for UML to binary format description conversion
5.1 Definition of binary format description
The binary format description of TPEG applications is included in application specifications as a
normative annex. This annex shall be named according to the following scheme:
[Full application name], TPEG-binary representation
The annex shall have four subclauses: Introduction, Application framing and signalling, Application
components and Application datastructures. The content of these subclauses is subject to the
specifications in this clause.
The introduction shall use a similar formulation as in the following:
This chapter defines the application framing and the format of the [Full application name] message
components, datastructures and its attributes for the TPEG binary representation of [application
abbreviation] as described in [reference to TPEG framework]. For further descriptions of these
objects see the related clauses [reference to clauses] in this specification.
The Application framing and signalling subclause shall have three parts: Application identification,
Version number signalling, and Application framing. The Application identification part shall define the
Application Identifier (AID) that is used for the application. The Version number signalling shall define
the major and minor version number of the application that are signalled within the SNI application.
The Application framing part shall state in what kind of service component the application shall be
transmitted. TPEG Service Component (SC) types are defined in ISO 21219-5. Currently, the following
Service Component types are defined:
— ServCompFrame — Standard SC
— ServCompFrameProtected — SC with data CRC
— ServCompFrameCountedProtected — SC with message count and data CRC
— ServCompFramePrioritisedProtected — SC with group priority and data CRC
— ServCompFramePrioritisedCountedProtected — SC with group priority, message count and data CRC
The wording shall be similar to the following:
TPEG binary format messages of the [Full application name] type are transmitted in Service
Component Frames of the [Service Component Frame type] type. Service Component Frames are
described in [reference to TPEG framework].
The Application components description shall have a first subclause with title List of generic component
IDs. This clause contains unique component IDs for each application UML class that is not stereotyped
as <>. The component IDs should be ordered in the order of appearance in the model.
The list of generic component IDs subclause is followed by subclauses providing the binary format
description of each application UML class that is not stereotyped as <>. This binary
format description shall follow the rules as specified in 5.5. The generic component ID of each component
defined in the list of generic component IDs shall be inserted in the binary format description where the
rules of 5.5 read ‘gcid’.
2 © ISO 2019 – All rights reserved

The Application datastructures description shall provide the binary format description of each
application UML class that is stereotyped as <>. This binary format description shall
follow the rules as specified in 5.5.
5.2 Abstract data types
This clause presents the binary format definition of the abstract data types that are defined in the TPEG
UML modelling rules document ISO 21219-5.
The following general rules were used for defining data types in the column "binary format definition":
A data type is written in upper camel case letters in one single expression. The data type may contain
letters (a-z), number (0-9), underscore "_", round brackets "()" and colon ":"; the first must be a letter.
EXAMPLE IntUnLo stands for Integer Unsigned Long
A data type is framed by angle brackets “ < > ” .
The content of a data type is defined by a colon followed by an equal sign “ := ”.
The end of a data type is indicated by a semicolon “ ; ”.
A descriptor written in lower camel case may be added to a data type as one single expression without spaces.
A descriptor is framed by round brackets “ ( ) ”.
The descriptor contains either a value or a name of the associated type.
Data types in a definition list of another one are separated by commas “ , ”. The order of definition is defined as
the order of occurrence in a data stream.
Curly brackets (braces) “ { } ” group together a block of data types.
Control statements ( “if”, “infinite”, “unordered” or “external”) are noted in lower case letters. A control statement
is followed by a block statement or only one data type:
1) if defines a condition statement. The block’s (or data type’s) occurrence is conditional to the condition
statement being valid. The condition statement is framed with round brackets. This statement applies to any
data type.
2) infinite defines endless repetition of the block (or data type). This is only used to mark the main TPEG
stream as not ending stream of data.
3) unordered defines that the following block contains data types which may occur in any order, not only the
one used to specify subsequent data types. This statement applies to components only.
4) ordered defines that the following block contains data types of which the order of definition is defined as
the order of occurrence in a data stream. This statement applies to components only.
5) external defines that the content of the data type is being defined external to the scope of given specification.
The control statement “external” must be followed by only one data. A reference to the corresponding
specification should follow in the comment. All types specified in TYP specification are treated as being in
scope of any application.
The expression “ n * ” indicates multiplicity of occurrence of a data type. The lower and upper bound
are implicitly from 0 to infinite; other bounds are described in square brackets between two points " . "
and behind the data type descriptor. The " * " stands for no limitation at upper bound.
Any text after a colon “ : ” is regarded as a comment.
For clear graphical presentation, lines in a coding box if they are too long to fit, are broken with a
backslash “\” followed by a carriage return. The broken line restarts with an additional backslash.
Data type Binary format definition
BitArray :=
m * [1.*]; : Byte containing bits. MSB signals following bytes
Bit set ( = 1) signals logical true
Bit not set ( = 0) or not present signals logical false
The bits in a BitArray are encoded in a sequence of bytes, where the first bit of each byte
(MSB) is a continuation flag (marked as CF in the table below). If this bit is set (=1) there
follows at least one more byte in this BitArray. The last byte always has the continuation
flag not set (=0). A BitArray represents a list of Boolean values which is implemented in
the same way as for all lists. The first byte holds bits numbered from zero to six in that
order. The second byte holds bits numbered seven to 13, again in that order, and so on.
The ordering is sequential from first bit (MSB) to last bit (LSB).
Table 1 — Binary format coding of BitArray
Byte 0 Byte 1 .
Bit number Bit number
CF 0 1 2 3 4 5 6 CF 7 8 9 10 11 12 13 .

If all bits after a certain bit in a BitArray are not set, the remaining bytes containing only
unset bits may be removed. The continuation flag of the new last byte is set to false. De-
coders shall interpret undefined bits as logical value false.
EXAMPLE  BitArray =05 hex: Bit 4 and bit 6 are set, the BitArray consists of only one byte
(continuation flag not set).
Boolean The TPEG binary format knows three representations for Booleans.
— Mandatory Booleans are stored in the selector of a class
— Multiple mandatory Booleans are stored in
— Single, optional Booleans are stored in a table of type typ008: OptionalBoolean as
defined in ISO 21219-2
The default value of a Boolean is false.
DataStructure := : Name of data structure
<…>, : Content of data structure
...;
DateTime := : Date and time
; : Number of seconds since
1970-01-01T00:00:00
Universal Coordinated Time (UTC)
NOTE  The formula for date and time calculation is given in ISO/TS 18234-2:2013, Annex D.
4 © ISO 2019 – All rights reserved

Data type Binary format definition
DaySelector :=
(selector), : DaySelector
if (bit 0 of selector is set)
(Saturday), : every Saturday
if (bit 1 of selector is set)
(Friday), : every Friday
if (bit 2 of selector is set)
(Thursday), : every Thursday
if (bit 3 of selector is set)
(Wednesday), : every Wednesday
if (bit 4 of selector is set)
(Tuesday), : every Tuesday
if (bit 5 of selector is set)
(Monday), : every Monday
if (bit 6 of selector is set)
(Sunday); : every Sunday
DistanceMetres :=
; : Distance in integer units of metres
DistanceCentiMetres :=
; : Distance in integer units of centimetres
Duration :=
; : Time duration in number of seconds
FixedPercentage :=
; : integer value of percentage
Deprecated: :=
FixedPointNumber    (integerPart), : integer part of the number
(decimalPart); : fraction of 2 decimal digits [0…99]
The datatype is deprecated and may be removed in one of the future versions of this document.
Please do not make use of this datatype anymore.
Float :=
4 * ; : ISO/IEC/IEEE 60559 single precision
floating point number
N−1 e
NOTE  Floating-point numbers are in the form of s (m / 2 ) 2 , with s the sign, m the mantissa,
e the exponent and N the number of bits in the mantissa. For single precision floating point
numbers, N = 24 the first bit in the mantissa is always one and can therefore be omitted.
Sign:      bit# 31 (bit #)
Exponent: bit# 23-30
Mantissa:  bit# 0-22
IntSiTi :=
; : Two’s complement
IntSiLi :=
, : MSByte, two’s complement
; : LSByte, two’s complement
IntSi24 :=
, : MSByte, two’s complement
,
; : LSByte, two’s complement
IntSiLo :=
, : MSByte, two’s complement
,
,
; : LSByte, two’s complement
Data type Binary format definition
IntSiLoMB :=
m * [1.5]; : MSB of each byte is continuation flag.
Two’s complement after elimination of continuation flags
The signed multi-byte is defined in the same way as IntUnLoMB except in case of signed value
interpretation; the complement on two is used on the 7-bit wide byte series. The count of bytes
is then defined by the magnitude of the positive value to be stored in multi-byte. The three re-
served bits in most significant byte #5 shall be set to 111 in
...