ISO 21219-16:2023

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 16: Fuel price information and availability (TPEG2-FPI)

This document specifies the TPEG fuel price information and availability (FPI) application. The FPI application has been specifically designed to support information from fuel stations, such as their location, fuel types offered and fuel pricing and availability information. The standardized delivery, via TPEG technology, of fuel price information has the following benefits for end users of a TPEG service: a) cost savings to the driver through improved ease of access to price information; b) potentially significant cost savings for fleet operators through improved ease of access to price information; c) environmental benefits from drivers not having to drive around to find the cheapest fuel prices; d) safety improvements for highways authorities, as drivers are less likely to run out of fuel if they are well-informed of local availability and prices; e) as availability of new fuels becomes more common, and more vehicles begin to use them (e.g. biofuels, hydrogen, etc.), drivers will be better informed about availability of fuelling stations. The TPEG FPI application (as an add-on service component next to traffic information, for example) is laid out to support large numbers of fuel stations and fuel prices with only modest bandwidth requirements The application described in this document (TPEG2-FPI) is not appropriate for cases where the objective is to inform electric vehicles of the location of charging stations and the availability of charging points. In such cases, the TPEG application TPEG2-EMI (electro mobility information) is chosen. This is because while TPEG2-FPI (the application described in this document) contains rudimentary support for electric charging stations, a TISA investigation revealed that a simple extension/differentiation of TPEG2-FPI is insufficient for addressing the evolving market needs of the electric vehicle market. Hence, a separate TPEG application has been created to serve the information needs of electric vehicles and their operators: TPEG2-EMI, specified in ISO/TS 21219-25.

Systèmes intelligents de transport — Informations sur le trafic et le tourisme (TTI) via le groupe expert du protocole de transport, génération 2 (TPEG2) — Partie 16: Informations sur le prix des carburants et leur disponibilité (TPEG2-FPI)

General Information

• Status: Published
• Publication Date: 23-May-2023
• 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: 6060 - International Standard published
• Start Date: 24-May-2023
• Due Date: 12-Dec-2022
• Completion Date: 24-May-2023

Relations

• Revises: ISO/TS 21219-16:2016 - Intelligent transport systems - Traffic and travel information via transport protocol exports group, generation 2 (TPEG2) - Part 16: Fuel price information and availability (TPEG2-FPI)
• Effective Date: 23-Apr-2020

Overview

ISO 21219-16:2023 specifies the TPEG2 Fuel Price Information and Availability application (TPEG2‑FPI), part of the ISO 21219 series for Intelligent Transport Systems (ITS). TPEG2‑FPI standardizes delivery of fuel station data - location, fuel types, pricing and availability - using TPEG (Transport Protocol Experts Group) generation 2 messaging. Published as an International Standard in 2023 (first edition), it replaces the earlier Technical Specification and expands fuel-kind support for evolving markets.

Key SEO phrases: ISO 21219-16, TPEG2, fuel price information, fuel availability, intelligent transport systems, TPEG FPI.

Key technical topics and requirements

• FPI structure and message design: Defines the overall FPI message architecture, including factoring out reusable definitions and support for large numbers of stations with modest bandwidth.
• Message components and datatypes: Specifies components such as FuelingDefinitions, StationFuelingInformation, StationExtraInformation, StationSiteInfo and location clusters (map, POI, navigation-along-road) plus associated datatypes (fuel types, prices, contact info, coordinate formats).
• Application lifecycle controls: Application identification, version number signalling, ordered components, and extension mechanisms to ensure interoperability and graceful evolution.
• Transmission models: Guidance for transmission of tables and use of MMC (Message Management Container) for message combinations and large datasets.
• Normative encodings: Includes normative representations for TPEG binary and TPEG‑ML (see Annex A and B) to ensure consistent encoding/decoding across systems.
• Reference tables: Predefined FPI tables (e.g., FuelKindType, PaymentMethodType, FuelBrand) standardize values and semantics across implementations.

Practical applications

• Navigation and in‑vehicle systems: Integrate live fuel prices and availability into route planning and POI displays, enabling drivers to find cost‑effective refuelling stops.
• Fleet management and telematics: Optimize refuelling strategies and reduce operational costs by incorporating standardized fuel price feeds into fleet planning tools.
• Traffic and travel service providers: Add FPI as an add‑on service alongside traffic information to enrich travel information services.
• Fuel retailers and aggregators: Distribute standardized price and availability data to third‑party services and navigation apps.
• Road authorities and safety services: Improve safety and reduce instances of vehicles running out of fuel by conveying availability information.

Who should use this standard

• ITS developers, navigation system OEMs, telematics vendors and app developers
• Traffic and travel information providers and broadcasters
• Fleet operators, fuel price aggregators and fuel station operators
• Standards implementers and national ITS authorities

Related standards

• ISO 21219 series (TPEG2 applications)
• For electric vehicle charging information, use TPEG2‑EMI (ISO/TS 21219‑25) - TPEG2‑FPI is not intended as the primary solution for EV charging infrastructure data.

This standard supports interoperable, bandwidth‑efficient distribution of fuel pricing and availability across the ITS ecosystem, helping reduce costs, emissions and refuelling uncertainty for drivers and fleets.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-16
First edition
2023-05
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 16:
Fuel price information and availability
(TPEG2-FPI)
Systèmes intelligents de transport — Informations sur le trafic et
le tourisme (TTI) via le groupe expert du protocole de transport,
génération 2 (TPEG2) —
Partie 16: Informations sur le prix des carburants et leur disponibilité
(TPEG2-FPI)
Reference number
© ISO 2023
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]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 2
5 Application specific constraints . .2
5.1 Application identification . 2
5.2 Version number signalling . 2
5.3 Ordered components . . 3
5.4 Extension . 3
5.5 TPEG service component frame . 3
6 FPI structure . 4
6.1 General . 4
6.2 FPI structuring concepts . 4
6.2.1 Design . . 4
6.2.2 Factoring out definitions . 4
6.2.3 Transmission of tables of information . 6
6.2.4 MMC usage and FPI message combinations . 7
6.3 FPI Message structure . 8
6.3.1 General . 8
6.3.2 FuelingDefinitions. 10
6.3.3 StationFuelingInformation . 11
6.3.4 Station extra information .12
6.3.5 Station site information . 13
6.3.6 Station location information . 14
7 FPI Message components .16
7.1 FPIMessage . 16
7.2 FPIapplicationContainerTemplate . 17
7.3 FuelingDefinitions . 17
7.4 MessageManagement . 18
7.5 StationExtraInfoCluster . 18
7.6 StationExtraInformation . 19
7.7 StationFuelingInfoCluster . 19
7.8 StationMapLocationCluster . 20
7.9 StationNavLocationAlongRoadCluster . 20
7.10 StationPOILocationCluster . 21
7.11 StationSiteInfo . 21
7.12 StationSiteInfoCluster . 22
7.13 GeographicCoverageLocation .23
7.14 MessageManagementContainerLink . 23
7.15 MMCMasterMessageLink .23
7.16 MMCMessagePartLink .23
7.17 StationEntryLocation . 23
7.18 StationMapLocation . 23
7.19 RoadLocation .23
7.20 StationExitLocation . 23
8 FPI Datatypes.24
8.1 FuelDeliveryRestrictionType . 24
8.2 FuelTypeInformation . 24
8.3 FuelTypePrice . 24
iii
8.4 StationContactInformation . 25
8.5 POILinkType . 25
8.6 SizeRestrictions . 25
8.7 StationBrandAndRating . 26
8.8 StationFuelingInformation .26
8.9 StationMapLocationInfo . 27
8.10 StationLocationVectorInfo . 27
8.11 StationPOILocationInfo .28
8.12 WGS84coordinate .28
9 FPI tables .29
9.1 Introduction of FPI tables . 29
9.2 fpi001:DeliveryUnitType .29
9.3 fpi003:FuelKindType . .29
9.4 fpi004:PaymentMethodType .30
9.5 fpi005:FuelServicePolicyType . 31
9.6 fpi006:AssociatedServiceType . 31
9.7 fpi007:SpatialResolution . 32
9.8 fpi008:FuelBrand . 32
9.9 fpi009:AltFuelBrand . . 37
Annex A (normative) TPEG application, TPEG-binary representation .38
Annex B (normative) TPEG application, TPEG-ML representation .54
Bibliography .64
iv
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 the first edition (ISO/TS 21219-16:2016), which has been
technically revised.
The main changes are as follows:
— the document has been changed from a Technical Specification to an International Standard;
— three new FuelKindType values have been added in Table 28.
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.
v
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 can 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, later 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, later 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, later 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 18234 series to provide location referencing.
The ISO 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 the 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 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).
TPEG2 is embodied in the ISO 21219 series and it comprises many parts that cover an 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 (see Annex A) and XML (see Annex B); others can
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; this file forms the annex for each
physical format.
vi
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 is potentially incomplete, as there is the possibility that new
TPEG2 parts will be introduced after the publication of this document.
— Toolkit parts: TPEG2-INV (ISO 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 21219-9), TPEG2-CAI (ISO 21219-10), TPEG2-LTE
(ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PKI (ISO 21219-14), TPEG2-TEC (ISO 21219-15), TPEG2-FPI (ISO 21219-16 -
this document), TPEG2-SPI (ISO 21219-17), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO 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 with 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:
SP20013/2.1/001.
vii
INTERNATIONAL STANDARD ISO 21219-16:2023(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 16:
Fuel price information and availability (TPEG2-FPI)
1 Scope
This document specifies the TPEG fuel price information and availability (FPI) application. The FPI
application has been specifically designed to support information from fuel stations, such as their
location, fuel types offered and fuel pricing and availability information.
The standardized delivery, via TPEG technology, of fuel price information has the following benefits for
end users of a TPEG service:
a) cost savings to the driver through improved ease of access to price information;
b) potentially significant cost savings for fleet operators through improved ease of access to price
information;
c) environmental benefits from drivers not having to drive around to find the cheapest fuel prices;
d) safety improvements for highways authorities, as drivers are less likely to run out of fuel if they are
well-informed of local availability and prices;
e) as availability of new fuels becomes more common, and more vehicles begin to use them (e.g.
biofuels, hydrogen, etc.), drivers will be better informed about availability of fuelling stations.
The TPEG FPI application (as an add-on service component next to traffic information, for example)
is laid out to support large numbers of fuel stations and fuel prices with only modest bandwidth
requirements
The application described in this document (TPEG2-FPI) is not appropriate for cases where the objective
is to inform electric vehicles of the location of charging stations and the availability of charging points.
In such cases, the TPEG application TPEG2-EMI (electro mobility information) is chosen. This is
because while TPEG2-FPI (the application described in this document) contains rudimentary support
for electric charging stations, a TISA investigation revealed that a simple extension/differentiation
of TPEG2-FPI is insufficient for addressing the evolving market needs of the electric vehicle market.
Hence, a separate TPEG application has been created to serve the information needs of electric vehicles
and their operators: TPEG2-EMI, specified in ISO/TS 21219-25.
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-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 21219-6, Intelligent transport systems — Traffic and travel information(TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 6: Message management container (TPEG2-MMC)
ISO 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 terms and definitions given in ISO 21219-9 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
fuel station
facility which sells fuel and lubricants for motor vehicles
Note 1 to entry: The most common fuels sold are petrol (gasoline in U.S. and Canada) or diesel fuel. Alternative
names in use for such a facility are gas station, fuelling station, filling station, service station, petrol station,
garage, gas bar, petrol pump or petrol bunk.
4 Abbreviated terms
For the purposes of this document, the abbreviated terms in ISO 21219-1, ISO 21219-9 and the following
apply.
ADC application data container
CNG compressed natural gas
MSL mean sea level
POI point of interest
TFP traffic flow and prediction
TMC traffic message channel
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, for example,
parking information or road traffic information. Each TPEG application is assigned a unique number,
called the application identity (AID). An AID number is defined in ISO 21219-1 whenever a new
application is developed.
The AID number is used within the TPEG2-SNI application (ISO 21219-9) to indicate how to process
TPEG content. It facilitates the routing of information to the appropriate application decoder.
5.2 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions can have an impact on client devices.
The version numbering principle is defined in ISO 21219-1.
Table 1 shows the current version numbers for signalling FPI within the SNI application.
Table 1 — Current version numbers for signalling of FPI
Major version number 2
Minor version number 1
5.3 Ordered components
TPEG2-FPI requires a fixed order of TPEG components. The order for the FPI message component
is shown in Figure 1. The first component shall be the MMC. This shall be the only component if the
message is a cancellation message. Otherwise, the MMC component shall be followed by one or more
application data container (ADC) component(s) which includes the application-specific information.
Figure 1 — Composition of TPEG messages
NOTE The FPI design is centred around the large commonality of information elements, notably for fuel
types, (pricing structure: currency, resolution of price information; delivery units) and the relatively slow refresh
rate of this information, and the expected large volume of FPI information. To give an example of the expected
volume, in the USA, approximately 200 000 fuel stations are in operation and, for example, in a radius of 50 km
around New York City, there are approximately 5 000 fuel stations. Consideration of these aspects has guided the
design of FPI.
Consequently, the design of the ADC is such that it can contain information for multiple fuel stations
at once. The top-level LRC of an FPI message shall contain a "geographic coverage area” to indicate the
geographic region of interest of the message’s content, for receiver geographic filtering purposes. The
individual locations of fuel stations are contained in specialized versions of the ADC, as geographic
“markers” within this geographic coverage location (see Clause 7 for details). This concept is similar as
in TFP, where congested sections of a road are indicated with linear markers with respect to a top-level
linear location.
5.4 Extension
The requirement of a fixed component order does not affect the extension of FPI. Future application
extensions may insert new components or may replace existing components by new ones without losing
backward compatibility. This means that an FPI decoder shall be able to detect and skip unknown
components.
5.5 TPEG service component frame
FPI makes use of the "service component frame with dataCRC and messageCount" according to
ISO 21219-5.
6 FPI structure
6.1 General
In this clause, the main structure of FPI and capabilities are defined.
The FPI design centres around the large commonality of information elements, notably for fuel types,
pricing structure (currency, resolution of price information; delivery units), the relatively slow refresh
rate of this information and the expected large volume of FPI information.
6.2 FPI structuring concepts
6.2.1 Design
In FPI, for purposes of transmission efficiency, common elements of fuel information are factored
out using standard relational database theory concepts (the so-called normal forms). This is applied
in particular for fuel type and pricing structure information (“fuelingDefinitions" in this document).
Furthermore, all information is transmitted as tables of information, each under the control of an MMC
component for validity and update management.
These concepts are described in the following subclauses.
6.2.2 Factoring out definitions
In general, an approach for factoring out definitions is more efficient under the following conditions:
a) information is of a composite nature;
b) parts of the information are not the same worldwide (otherwise, a TPEG table would suffice) or
more than 255 options exist or are likely to exist (the cardinality of a TPEG table is limited to 255
entries);
c) the amount of duplication in the transmission otherwise needed would significantly affect
transmission efficiency.
For FPI, this applies to the fuel names, type and pricing, and to fuel brands. Typically, for these data
elements, a large number of combinations exist worldwide. Moreover, over time, new types or names
can come into existence. Nonetheless, for an individual service provider, only a few combinations are of
interest.
Under these conditions, it is advantageous to transmit a separate table with fuel type and pricing
structure definitions. Information for a particular fuel station can then refer to this item with a
reference (the Table Key and Fuel Type Key) rather than duplicating the complete definition every time
a fuel station needs to list a price for a particular fuel type with a specific pricing structure.
Table 2 shows a sample from a table for a US-based service provider (e.g. for California). Here, the local
fuel names such as “Unleaded”, “Premium” or even “H ” are used. Delivery units are (US) Gallons for
liquid fuels or kg for Hydrogen, and prices are given in US Dollars with a two decimal digit accuracy [e.g.
USD 1,34 per (US) Gallon].
Table 2 — Sample table with fuelling definitions for the USA
Table key (AreaID_Key=01, fuelingDefinitionsID_Key=01)
Currency unit US Dollar
Fuel type key Fuel name Fuel type Delivery unit Price resolution
0 “Unleaded” Unleaded petrol Gallon 2 digits
1 “Premium” High octane unleaded petrol Gallon 2 digits
TTaabblle 2 e 2 ((ccoonnttiinnueuedd))
2 “Diesel” Diesel Gallon 2 digits
3 “H “ Hydrogen kg 2 digits
4 "CNG" CNG gge 2 digits
In Table 2, a line item represents one fuelingDefinition. The fields "Fuel type" and "Delivery unit" can
each be represented through a standard TPEG table construct, as less than 254 variations are expected.
The fuel name is represented with a short string and the price resolution with a tiny unsigned integer.
Table 3 shows a sample from a table for a Dutch-based service provider. Here, local names such as “euro-
95” and “super-98” are used. Delivery units are now in litres and prices are in Euro, with a price display
resolution of 3 digits (e.g. EUR 1,349 per litre).
Table 3 — Table with fuelling definitions for the Netherlands
Table key (AreaID_Key=31, fuelingDefinitionsID_Key=1)
Currency unit Euro
Fuel type key Fuel name Fuel type Delivery unit Price resolution
0 “Euro-95” Unleaded petrol Litre 3 digits
1 “Super-98” High octane unleaded petrol Litre 3 digits
2 “Diesel” Diesel Litre 3 digits
Thus, for every fuel station carrying unleaded petrol, only the item key of the line item is required
to be transmitted to indicate the fuel type meant, rather than the complete definition with the four
fields (fuel name, fuel type, delivery unit, pricing resolution). With several thousand fuel prices to be
transmitted in dense urban regions, such a mechanism leads to a significant reduction in bandwidth
need for a specific repetition rate. This mechanism is used both for fuel type and pricing structure, as
for (local) fuel brands. Many fuel stations may have these information items in common.
6.2.3 Transmission of tables of information
A service provider, transmitting fuel price information and availability, needs to be able to provide
a TPEG client with a large volume of data at a relatively low transmission bandwidth. This makes it
challenging to apply the typical TPEG concept that a single TPEG message equates with a single content
item, in this case, a fuel station. The total volume of data per fuel station can easily exceed a hundred
bytes. However, clients without any pre-existing information (e.g. transit users) shall still be able to
have useable data in a short amount of time (~10 min to ~20 min). Some form of transmission at high
repetition rates for minimum content, augmented with low repetition rate for additional detailed
content is required.
Clustering of (partial) content: The design direction taken for FPI is to allow service providers to
arrange their transmissions flexibly, depending on the volume of data to be transmitted and the
available bandwidth. That is, the unit of control (a TPEG message) is separated from the unit of content
(fuel station). Instead, a TPEG message can contain partial content for a cluster of stations (e.g. station
locations or fuelling information) or complete content for a single fuel station.
A large bandwidth service provider with fewer fuel stations for which it transmits information can
provide the following lay-out of TPEG FPI messages (all messages include the standard MMC component
and, for receiver geographic filtering, an LRC indicating the geographic coverage area).
— TPEG FPI message, variant A: Fuel definitions (FPI Component: fuelingDefinitions)
— TPEG FPI message, variant B: Station information for a cluster of 1 station
(FPI components: StationFuelingInfoCluster,
StationExtraInfoCluster, StationSiteInfoCluster and
StationMapLocationCluster).
Both message variants are transmitted at a high repetition rate.
Conversely, a small bandwidth service provider (with more fuel stations for which it transmits
information) can capitalize on the fact that most of the fuel station information is rather static (location,
site information, etc.).
Thus, a small bandwidth service provider can utilize the following lay-out of TPEG FPI messages.
High repetition rate messages (with standard inclusion of the MMC component and, for receiver
geographic filtering, a LocationReferencingContainer indicating the geographic coverage area):
— TPEG FPI message, variant 1: Fuel definitions (FPI Component: fuelingDefinitions)
— TPEG FPI message, variant 2: Station information for a cluster of e.g. 25 stations
(FPI components: StationFuelingInfoCluster)
— TPEG FPI message, variant 3: Station information for a cluster of e.g. 16 stations
(FPI components: StationPOILocationCluster)
Low repetition rate messages (with standard inclusion of the MMC component and, for receiver
geographic filtering, a LocationReferencingContainer indicating the geographic coverage area):
— TPEG FPI message, variant 4: Station information for a cluster of e.g. 10 stations
(FPI components: StationSiteInfoCluster)
— TPEG FPI message, variant 5: Station information for a cluster of e.g. 6 stations
(FPI components: StationNavLocationCluster)
— TPEG FPI message, variant 6: Station information for a cluster of e.g. 4 stations
(FPI components: StationExtraInfoCluster)
In this case, a low bandwidth service provider can tailor the repetition rate and content of message
variants to its local situation and demands. Transit users, without any pre-existing information,
are quickly served with the high repetition messages containing the basic location and fuel price
information. Over time, commuter users can build up the complete fuel station database, including
detailed site and location information.
Receivers link the content tables together based on the unique identification of a fuel station, i.e. the
triplet (areaID_Key, stationID_Key) and the fuel definition table (areaID_Key, fuelingDefinitionsID_Key).
NOTE This relational database technology is well known. For utmost clarity, in this document, the identifiers
used as table keys have been given the suffix “_Key”.
6.2.4 MMC usage and FPI message combinations
FPI can make use of both monolithic and multi-part message management for transmission of the fuel
station and fuelling definition tables (see ISO 21219-6). The unit of content update shall always be an
individual message in case of monolithic message management, or a message part in case of a multi-
part message.
In case of a choice (for example, in a TPEG profile) for monolithic message management, then each
FPI table (represented by the top-level applicationInformation components) can be transmitted in a
separate message or, alternatively, several applicationInformation components can be transmitted
together in a single message. The choice largely depends on the desirable repetition rates for these
components. Components with an equal repetition rate can advantageously be combined in a single
message.
With monolithic message management, each message shall have a unique message ID to distinguish it
from other messages. If at least one information element changes for any of the contained fuel stations,
then the versionID of the message shall be increased.
In case of a choice for multi-part message management, then the respective information parts for a
cluster of Fuel Stations can be transmitted as partial messages. A single ”MMCMasterMessage” in
this case can indicate the respective partial messages together comprising of the total information.
The minimal information, i.e. StationFuelingInfoCluster and one of the LocationInfoClusters shall
be signalled as mandatory, since together they comprise the minimal information which can be
presented to the user. The other applicationInformation components (e.g. StationExtraInfoCluster,
StationSiteInfoCluster) may be signalled as optional to indicate that the overall message contents may
be presented to the user, even if this partial message has not yet been received.
With multi-part message management, providers are recommended to have the various message parts
contain information for the same cluster of stations (i.e. the same set of stationID_Key’s). If at least one
information element changes for any of the contained fuel stations, then the versionID of the affected
partial message shall increase.
For both forms of message management, it is recommended to send the FuelingDefinitions in a separate,
long lasting, FPI message. Its content is independent of any fuel station in particular and rather encodes
the regional or national fuel and fuel pricing conventions.
In summary, the minimal applicationInformation components needed to provide a basic FPI service are
the following:
a) FuelingDefinitions;
b) StationFuelingInfoCluster;
c) one of the Station(…)Location(…)Cluster options.
The additional applicationInformation components providing more detailed and/or special information
for selected fuel stations are the following:
a) StationExtraInfoCluster;
b) StationSiteInfoCluster.
The FPI service provider can utilize both monolithic and multi-part message management. With
multi-part messagemanagement, the provider should ensure that the repetition rate of the
”MMCMasterMessage” is at least as frequent as the mandatory message parts to provide for the fastest
display of FPI information in a TPEG client after start-up.
6.3 FPI Message structure
6.3.1 General
The structur
...