ISO/TS 21219-2:2014
(Main)Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 2: UML modelling rules
Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 2: UML modelling rules
ISO/TS 21219-2:2014 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. ISO/TS 21219-2:2014 also specifies the preferred structure of TPEG application specifications.
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
General Information
Relations
Standards Content (Sample)
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/TS 21219-2:2014(E)
©
ISO 2014
---------------------- Page: 1 ----------------------
ISO/TS 21219-2:2014(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
ISO/TS 21219-2:2014(E)
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
© ISO 2014 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 21219-2:2014(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.
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
---------------------- Page: 4 ----------------------
ISO/TS 21219-2:2014(E)
— 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]
© ISO 2014 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/TS 21219-2:2014(E)
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
---------------------- Page: 6 ----------------------
ISO/TS 21219-2:2014(E)
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.
© ISO 2014 – All rights reserved vii
---------------------- Page: 7 ----------------------
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
© ISO 2014 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO/TS 21219-2:2014(E)
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
---------------------- Page: 9 ----------------------
ISO/TS 21219-2:2014(E)
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).
© ISO 2014 – All rights reserved 3
---------------------- Page: 10 ----------------------
ISO/TS 21219-2:2014(E)
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
---------------------- Page: 11 ----------------------
ISO/TS 21219-2:2014(E)
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.
© ISO 2014 – All rights reserved 5
---------------------- Page: 12 ----------------------
ISO/TS 21219-2:2014(E)
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
---------------------- Page: 13 ----------------------
ISO/TS 21219-2:2014(E)
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.
© ISO 2014 – All rights reserved 7
---------------------- Page: 14 ----------------------
ISO/TS 21219-2:2014(E)
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
---------------------- Page: 15 ----------------------
ISO/TS 21219-2:2014(E)
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.
© ISO 2014 – All rights reserved 9
---------------------- Page: 16 ----------------------
ISO/TS 21219-2:2014(E)
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 mode
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.