ISO/TS 21219-26:2018

TECHNICAL ISO/TS
SPECIFICATION 21219-26
First edition
2018-11
Intelligent transport systems — Traffic
and travel information via transport
protocol experts group, generation 2
(TPEG2) —
Part 26:
Vigilance location information
(TPEG2-VLI)
Reference number
©
ISO 2018
© ISO 2018
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: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 3
5 Application specific constraints . 3
5.1 Application identification . 3
5.2 Version number signaling . 3
5.3 Ordered components . 4
5.4 Extendibility . 4
5.5 TPEG Service Component Frame. 4
6 VLI Structure . 4
7 VLI Message components. 5
7.1 LocationReferenceLink . 5
7.2 MessageManagementContainerLink. 5
7.3 VigilanceMessage . 6
7.4 MMCSwitch . 6
7.5 VigilanceInformation . 6
7.6 SpeedLimit . 6
8 VLI Datatypes . 7
8.1 LaneNumber . 7
8.2 SubdivisionCountryCode . 8
9 VLI Tables . 8
9.1 vli001:VigilanceT ype . 8
9.2 vli002:ConfidenceLe vel .10
9.3 vli003:V ehicleType .11
9.4 vli004:W eatherCondition .11
Annex A (normative) TPEG application, TPEG-Binary Representation .12
Annex B (normative) TPEG application, TPEG-ML Representation .16
Bibliography .22
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.
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 2018 – All rights reserved

Introduction
0.1 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 parts of the ISO/
TS 18234 series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
0.2 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/TS 21219-2, ISO/TS 21219-3 and ISO/TS 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/TS 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.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR (ISO/
TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC (ISO/
TS 21219-6), TPEG2-LRC (ISO/TS 21219-7), TPEG2-LTE (ISO/TS 21219-24).
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10).
— Location referencing: TPEG2-GLR (ISO/TS 21219-21), TPEG2-OLR (ISO/TS 21219-22).
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI (ISO/
TS 21219-16), TPEG2-TFP (ISO/TS 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 this document).
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:
SP17003/1.0/002.
vi © ISO 2018 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 21219-26:2018(E)
Intelligent transport systems — Traffic and travel
information via transport protocol experts group,
generation 2 (TPEG2) —
Part 26:
Vigilance location information (TPEG2-VLI)
1 Scope
This document defines the application for Vigilance Location Information (VLI).
Vigilance messages are intended for in-car applications to inform drivers when they should pay extra
attention to their driving behaviour because of dangerous road stretches, traffic enforcement cameras
or other hazardous locations, requiring increased driver vigilance. The warnings can be presented
visually, audibly, or with the spoken voice, or as a combination of all three.
The presentation of such messages to the drivers allows them to drive relaxed, in the knowledge that
they will be warned when necessary. The situation where a vigilance message makes sense can be
very different. For example speed cameras are usually placed in areas where vigilance is required; the
information about those locations promote safe driving and also more safety for other road users and
outside traffic participants. Another example for areas requiring high driver attention are roads close-
by a school.
The information can be categorized in two ways:
Fixed or mobile locations:
— Fixed locations refer to locations which are fixed of nature, such as the presence of known accident
black-spots.
— Mobile locations refer to locations which are transient in nature, such as the presence of a mobile
speed camera.
Spot locations or zones:
— Spot locations refer to single points on a road network where the warning is located, with an
indication of which direction of traffic is affected by the vigilance information.
— Zones refer to stretches of road network which represent a continuous area of warning affecting
only one traffic direction.
The local regulations regarding the signalling of speed measurement systems, e.g. fixed speed cameras,
or mobile speed radar locations can vary depending on the country or region. The signalling of
speed measurement systems is encouraged by local authorities in certain markets whereas it can be
punishable by law in other markets.
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/TS 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO/TS 21219-3, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules
ISO/TS 21219-4, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 4: UML to XML conversion rules
ISO/TS 21219-5, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 5: Service framework (TPEG2-SFW)
ISO/TS 21219-9, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at http: //www .iso .org/obp
— IEC Electropedia: available at https: //www .electropedia .org/
3.1
vigilance information
information for a driver to pay additional attention to
3.2
location
logical position where special attention is needed
EXAMPLE The position on the road where a speed check is placed which is not necessarily the physical
location of the camera.
3.3
spot location
exact points on a road network where the attention is needed, with an indication of which direction of
traffic is affected by the alert
3.4
zone
stretches of road network which represent a continuous area of warning affecting only one traffic
direction
3.5
stop time
date and time when the vigilance information expires and is no longer valid
3.6
confidence level
optional indication of the correctness and accuracy of the attributes of the vigilance information
Note 1 to entry: The exact definition of the levels strongly depends on the offer of the vendor as well as the needs
of the customer and hence is a matter of negotiation.
3.7
speed limit
regulation defining maximum (which may be variable) speeds allowed
Note 1 to entry: Speed limits are commonly set by the legislative bodies of nations or provincial governments.
2 © ISO 2018 – All rights reserved

3.8
hard shoulder
hardened strip alongside a motorway for stopping on in an emergency
4 Abbreviated terms
ACID application and content identifier
ADC application data container
CEN Comité Européen de Normalisation
EBU European Broadcasting Union
LRC location reference container
MMC message management container
n.a. not available
OSI Open Systems Interconnection
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI traffic and travel information
UML Unified Modelling Language
5 Application specific constraints
5.1 Application identification
The word 'application' is used in the TPEG specifications to describe specific subsets of the TPEG
structure. An application defines a limited vocabulary for a certain type of messages, e.g. parking
information or road traffic information. Each TPEG application is assigned a unique number, called the
Application IDentification (AID). An AID is defined whenever a new application is developed and these
are all listed in ISO/TS 21219-1.
The application identification number is used within the TPEG-SNI application ISO/TS 21219-9 to
indicate how to process TPEG content and facilitates the routing of information to the appropriate
application decoder.
5.2 Version number signaling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions may have an impact on client devices.
The version numbering principle is defined in ISO/TS 21219-1.
Table 1 shows the current version numbers for signaling VLI within the SNI application:
Table 1 — Current version numbers for signalling of VLI
major version number 1
minor version number 0
5.3 Ordered components
TPEG2-VLI requires a fixed order of TPEG components. The order for the VLI message component is
shown in Figure 1; the first component shall be the Message Management Container. This shall be the
only component if the message is a cancellation message. Otherwise, the MMC component shall be
followed by the one or more Application Data Container component(s) which includes the application-
specific information.
Figure 1 — Composition of TPEG messages
5.4 Extendibility
The requirement of a fixed component order does not affect the extension of TPEG2-VLI. Future
application extensions may insert new components or may replace existing components by new
ones without losing backward compatibility, i.e. a TPEG2-VLI decoder shall be able to detect and skip
unknown components.
5.5 TPEG Service Component Frame
TPEG2-VLI makes use of the "Service Component Frame with dataCRC and messageCount" according to
ISO/TS 21219-5.
6 VLI Structure
The structure of VLI messages is shown in Figure 2.
4 © ISO 2018 – All rights reserved

Figure 2 — VLI message structure
7 VLI Message components
7.1 LocationReferenceLink
The LocationReferenceLink component is a placeholder for the LocationReferencingContainer (LRC). It
assigns the VLI application specific local component ID for the LRC container. All component IDs within
the LRC container are local to the LRC toolkit.
7.2 MessageManagementContainerLink
The MessageManagementContainerLink component is a placeholder for the
MessageManagementContainer.
7.3 VigilanceMessage
The VigilianceMessage is the data component of TPEG2-VLI.
Table 2 defines the VigilanceMessage component.
Table 2 — VigilanceMessage
Name Type Multiplicity Description
Ordered Components
mmt MMCSwitch 1 The message management information.
vigilanceInformation VigilanceInformation 0.1 The vigilance information.
loc LocationReferenceLink 0.1 The location reference.
7.4 MMCSwitch
The MMCSwitch is an abstract container included for formal reasons, to allow future extension of
the MMC.
7.5 VigilanceInformation
The VigilanceInformation component describes a vigilance information.
Table 3 defines the VigilanceInformation component.
Table 3 — VigilanceInformation
Name Type Multiplicity Description
stopTime DateTime 1 The date and time when the vigilance information
expires and is no longer valid.
type vli001:VigilanceType 1 The type of the vigilance information.
confidence vli002:ConfidenceLevel 0.1 A confidence value for this message.
countryCode SubdivisionCountryCode 0.1 The subdivision country code to further specify
the region for which this method is valid for.
source LocalisedShortString 0.* The source of the information.
freeText LocalisedShortString 0.* This field may be used to provide additional infor-
mation (e.g. human readable position description)
Ordered Components
speedLimit SpeedLimit 0.* If the vigilance information contains speed limit
information this is provided in the SpeedLimit
component.
7.6 SpeedLimit
The component SpeedLimit contains fields to describe a speed limit and add restrictions to it. The
timeInterval, laneNumber, vehicleType and weatherCondition, if set, restrict the validity of the speed limit.
Table 4 defines the SpeedLimit component.
6 © ISO 2018 – All rights reserved

Table 4 — SpeedLimit
Name Type Multiplicity Description
variableSpeedLimit Boolean 1 The speed limit changes within
short time periods (e.g. man-
aged via a traffic control centre).
The provided speed limit might
not match with the current real
speed limit.
speedLimitInMilesPerHours Boolean 1 Needs to be set to true in case the
speed limit unit is miles per hour
(mph). The default (false) is kilo-
metre per hour (kph).
speedLimit IntUnTi 0.1 A speed limit applicable for the
vigilance type.
timeInterval TimeToolkit 0.1 The time interval may be used to
restrict the period the speed limit
is active.
laneNumber LaneNumber 0.1 The lane number for which this
speed limit is valid.
vehicleType vli003:VehicleType 0.1 The vehicle type for which this
speed limit is valid.
weatherCondition vli004:WeatherCondition 0.1 The weather conditions for which
this speed limit is valid.
8 VLI Datatypes
8.1 LaneNumber
Lanes are numbered from the curb to the middle of the road. Right hand traffic lanes are therefore
numbered from the right to the left relating to the driving direction. Left hand traffic lanes are
numbered from left to right relating to the driving direction. The first lane has the number 0.
The lane numbering should follow these rules:
— hard shoulder is always number 0:
— leftmost lane in case of left hand driving (if exists);
— rightmost lane in case of right hand driving (if exists);
— additional hard shoulders are numbered consecutively (also applicable for hard shoulders next
to the divider);
— first drivable lane for vehicles is number 1;
— all lanes which are physically available count;
— lanes which are temporarily closed also count;
— numbering is consecutive.
If physical layout changes then a split of the location is recommended.
Table 5 defines the LaneNumber datatype.
Table 5 — LaneNumber
Name Type Multiplicity Description
hardShoulder Boolean 1 true, if the hard shoulder exists and is selected
lane1 Boolean 1 true, if the lane is selected
lane2 Boolean 1 true, if the lane is selected
lane3 Boolean 1 true, if the lane is selected
lane4 Boolean 1 true, if the lane is selected
lane5 Boolean 1 true, if the lane is selected
lane6 Boolean 1 true, if the lane is selected
lane7 Boolean 1 true, if the lane is selected
lane8 Boolean 1 true, if the lane is selected
lane9 Boolean 1 true, if the lane is selected
lane10 Boolean 1 true, if t
...