ISO/TS 17575-3:2011

Electronic fee collection - Application interface definition for autonomous systems - Part 3: Context data

ISO/TS 17575 defines the information exchange between the Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board equipment (OBE). ISO/TS 17575-3:2011 defines the data to be used for a description of individual charging systems in terms of charged geographical objects and charging and reporting rules. For every Toll Charger's system, attributes defined in ISO/TS 17575-3:2011 are used to transfer data to the Front End in order to instruct it which data to collect and report.

Perception du télépéage — Définition de l'interface d'application pour les systèmes autonomes — Partie 3: Données du contexte

General Information

• Status: Withdrawn
• Publication Date: 10-Apr-2011
• Withdrawal Date: 10-Apr-2011
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 5 - Fee and toll collection
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 18-Jan-2016
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 17575-3:2016 - Electronic fee collection - Application interface definition for autonomous systems - Part 3: Context data
• Effective Date: 29-Jun-2013

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 17575-3
First edition
2011-04-15
Electronic fee collection — Application
interface definition for autonomous
systems —
Part 3:
Context data
Perception du télépéage — Définition de l'interface d'application pour
les systèmes autonomes —
Partie 3: Données du contexte
Reference number
©
ISO 2011
©  ISO 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing 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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
4 Abbreviated terms.5
5 General concept and overview .5
6 Procedural requirements and encoding rules.7
6.1 Communication services.7
6.2 Version and validity handling .7
6.3 Encoding rules.7
7 Application data units.8
7.1 Application data unit structure .8
7.2 Application data unit header .8
7.3 Application data unit body .9
8 EFC Attributes .9
8.1 Rules with respect to support of context data .9
8.2 Attributes and data sets.10
8.3 EFC attributes data catalogue.10
8.3.1 General .10
8.3.2 Data set “Context Overview” .11
8.3.3 Data group “Tariff Information” .12
8.3.4 Data set “Context Layout”.28
8.3.5 Data set “Reporting rules” .38
Annex A (normative) EFC data type specifications .48
Annex B (normative) PICS proforma for the attributes.63
Annex C (informative) How to use context data defining the properties of an EFC regime .82
Annex D (informative) Examples using EFC context data for scheme definitions .87
Bibliography.91

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
ISO/TS 17575-3 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with Technical Committee ISO/TC 204,
Intelligent transport systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
ISO/TS 17575 consists of the following parts, under the general title Electronic fee collection — Application
interface definition for autonomous systems:
⎯ Part 1: Charging
⎯ Part 2: Communication and connection to the lower layers
⎯ Part 3: Context data
⎯ Part 4: Roaming
iv © ISO 2011 – All rights reserved

Introduction
Autonomous systems
This part of ISO/TS 17575 is part of a series of specifications defining the information exchange between the
Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board equipment
(OBE). EFC systems automatically collect charging data for the use of road infrastructure including motorway
tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels, distance-based
charging, and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-area
technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Communications Networks
(CN). These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, also the terms GPS/GSM systems and wide-area charging systems are in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such as
gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map containing
the charged geographic objects, such as charged roads or charged areas. From the charged objects, the
vehicle characteristics, the time of day and other data that are relevant for describing road use, the tariff and
ultimately the road usage fee are determined.
Some of the strengths of the autonomous approach to electronic fee collection are its flexibility, allowing the
implementation of almost all conceivable charging principles, and its independence from local infrastructure,
thereby predisposing this technology towards interoperability across charging systems and countries.
Interoperability can only be achieved with clearly defined interfaces, which is the aim and justification of
ISO/TS 17575.
Business architecture
This part of ISO/TS 17575 complies with the business architecture defined in ISO 17573. According to this
architecture, the Toll Charger is the provider of the road infrastructure and, hence, the recipient of the road
usage charges. The Toll Charger is the actor associated with the Toll Charging role. See Figure 1.
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
he rolebased model underlying this Technical Specification
Figure 1 — T
Service Providers issue OBE to the users of the road infrastructure. Service Providers are responsible for
operating the OBE that will record the amount of road usage in all toll charging systems the vehicle passes
through and for delivering the charging data to the individual Toll Chargers. In general, each Service Provider
delivers charging data to several Toll Chargers, as well as each Toll Charger in general receives charging
data from more than one Service Provider. Interoperability Management in Figure 1 comprises all
specifications and activities that in common define and maintain a set of rules that govern the overall toll
charging environment.
Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects the fact
that some processing functionalities can either be allocated to the OBE or to an associated off-board
component (Proxy). An example of processing functionality that can be realized either on- or off-board is
map-matching, where the vehicle locations in terms of measured coordinates from GNSS are associated to
geographic objects on a map that either resides on- or off-board. Also tariffication can be done with OBE tariff
tables and processing, or with an off-board component.
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Front End Back End
Road Usage Data
Context Data
Figure 2 — Assumed technical architecture and interfaces
The combined functionality of OBE and Proxy is denoted as Front End. A Front End implementation where
processing is predominately on OBE-side is known as a smart client (or intelligent client, fat client) or
edge-heavy. A Front End where processing is mostly done off-board is denoted as thin-client or edge-light
architecture. Many implementations between the “thin” and “thick” extremes are possible, as depicted by the
gradual transition in the wedges in Figure 2. Both extremes of architectural choices have their merits and are
one means where manufacturers compete with individual allocations of functionality between on-board and
central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the transfer of
localization data between OBE and off-board components, where proprietary algorithms are used for data
reduction and data compression. Standardization of this transfer is neither fully possible nor beneficial.
Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices, the primary
scope of ISO/TS 17575 is the data exchange between Front End and Back End (see the corresponding dotted
line in Figure 2). For every toll regime, the Back End will send context data, i.e. a description of the toll regime
in terms of charged objects, charging rules and, if required, the tariff scheme to the Front End, and will receive
usage data from the Front End.
vi © ISO 2011 – All rights reserved

It has to be noted also that the distribution of tasks and responsibilities between Service Provider and Toll
Charger will vary individually. Depending on local legal situation, Toll Chargers will require “thinner” or
“thicker” data, and might or might not leave certain data processing tasks to Service Providers. Hence, the
data definitions in ISO/TS 17575 may be useful on several interfaces.
ISO/TS 17575 also provides for basic media-independent communication services that may be used for
communication between Front End and Back End, which might be line-based or an air-link, and can also be
used for the air-link between OBE and central communication server.
The parts of ISO/TS 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End. The
required attributes will differ from one Toll Charger to another, hence, attributes for all requirements are
offered, ranging from attributes for raw localization data, for map-matched geographic objects and for
completely priced toll transactions.
Part 2: Communication and connection to lower layers, defines basic communication services for data transfer
over the OBE air-link or between Front End and Back End.
Part 3: Context Data, defines the data to be used for a description of individual charging systems in terms of
charged geographical objects and charging and reporting rules. For every Toll Charger's system, attributes as
defined in Part 3 are used to transfer data to the Front End in order to instruct it which data to collect and
report.
Part 4: Roaming, defines the functional details and data elements required to operate more than one EFC
regime in parallel. The domains of these EFC regimes may or may not overlap. The charge rules of different
overlapping EFC regimes can be linked, i.e. they may include rules that an area pricing scheme will not be
charged if an overlapping toll road is used and already paid for.

Figure 3 — Scope of ISO/TS 17575
In ISO/TS 17575, context data is the description of the properties of a single instance of an EFC context. This
single instance of an EFC context operates according to one of the basic tolling principles such as
⎯ road sectioned tolling,
⎯ area pricing according to travelled distance,
⎯ area pricing according to the time,
⎯ cordon pricing.
EFC context data comprise a set of rules for charging, including the description of the charged network, the
charging principles, the liable vehicles and a definition of the required contents of the charge report. This set
of rules is defined individually for each EFC context according to local needs.
This part of ISO/TS 17575 contains the definitions of the above listed type of data.
Only a Front End configured with the context data necessary for the respective EFC context is able to be used
for charging processes.
The following data definitions are in this part of ISO/TS 17575:
⎯ data providing toll context overview information;
⎯ data providing tariff information (this includes definitions of required tariff determinants like vehicle
parameters, time classes and others);
⎯ data providing context layout information;
⎯ data providing reporting rules information.
In case one EFC domain cannot be described with a single set of context data, several of these context data
are used. ISO/TS 17575-4 defines the parallel operation of more than one EFC context and how to handle
interdependencies.
Applicatory needs covered by ISO/TS 17575
⎯ The parts of ISO/TS 17575 are compliant with the architecture defined in ISO 17573.
⎯ The parts of ISO/TS 17575 support charges for use of road sections (including bridges, tunnels, passes,
etc.), passage of cordons (entry/exit), and use of infrastructure within an area (distance, time).
⎯ The parts of ISO/TS 17575 support fee collection based on units of distance or duration, and based on
occurrence of events.
⎯ The parts of ISO/TS 17575 support modulation of fees by vehicle category, road category, time of usage,
and contract type (e.g. exempt vehicles, special tariff vehicles, etc.)
⎯ The parts of ISO/TS 17575 support limiting of fees by a defined maximum per period of usage.
⎯ The parts of ISO/TS 17575 support fees with different legal status (e.g. public tax, private toll).
⎯ The parts of ISO/TS 17575 support differing requirements of different Toll Chargers, especially in terms of
⎯ geographic domain and context descriptions,
⎯ contents and frequency of charge reports,
viii © ISO 2011 – All rights reserved

⎯ feedback to the driver (e.g. green or red light), and
⎯ provision of additional detailed data on request, e.g. for settling of disputes.
⎯ The parts of ISO/TS 17575 support overlapping geographic toll domains.
⎯ The parts of ISO/TS 17575 support adaptations to changes in
⎯ tolled infrastructure,
⎯ tariffs, and
⎯ participating regimes.
⎯ The parts of ISO/TS 17575 support the provision of trust guarantees by the Service Provider to the Toll
Charger for the data originated from the Front End.

TECHNICAL SPECIFICATION ISO/TS 17575-3:2011(E)

Electronic fee collection — Application interface definition for
autonomous systems —
Part 3:
Context data
1 Scope
This part of ISO/TS 17575 defines the content, semantic and format of the data exchange between a Front
End (OBE plus optional proxy) and the corresponding Back End in autonomous toll systems. This part of
ISO/TS 17575 comprises the definition of the data elements used to specify and describe the toll context
details. Context data are transmitted from the Back End to the Front End.
2 Normative references
The following referenced documents are indispensable for the application 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 612, Road vehicles — Dimensions of motor vehicles and towed vehicles — Terms and definitions
ISO 1176, Road vehicles — Masses — Vocabulary and codes
ISO 4217, Codes for the representation of currencies and funds
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rule
(PER)
ISO/TS 12813:2009, Electronic fee collection — Compliance check communication for autonomous systems
ISO 14906:2011, Road transport and traffic telematics — Electronic fee collection — Application interface
definition for dedicated short-range communication
ISO 17573, Electronic Fee Collection — Systems architecture for vehicle related transport services
ISO/TS 17575-1:2010, Electronic fee collection — Application interface definition for autonomous systems —
Part 1: Charging
ISO/TS 17575-2:2010, Electronic fee collection — Application interface definition for autonomous systems —
Part 2: Communication and connections to the lower layers
EN 15509, Road transport and traffic telematics — Electronic fee collection — Interoperability application
profile for DSRC
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17573 and the following apply.
3.1
area pricing
charging process based on road usage occurring within a given area
3.2
attribute
application information formed by one or by a sequence of data elements, used for implementation of a
transaction
NOTE Adapted from ISO 14906:2011.
3.3
authenticator
data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to
prove the source and/or the integrity of the data unit and protect against forgery
[ISO 14906:2011, definition 3.4]
3.4
Back End
generic name for the computing and communication facilities of the Service Provider and/or the Toll Charger
3.5
charge report
data structure transmitted from the Front End to the Back End to report road usage data and supplementary
related information
3.6
charge object
any object that is part of the toll context description that may be charged for its use under certain conditions
3.7
contract
expression of an agreement between two or more parties concerning the use of the road infrastructure
[ISO 14906:2011, definition 3.7]
3.8
cordon
border line of an area
3.9
cordon pricing
charging process based on registering passages of a cordon
3.10
currencies minor unit
the minor unit of a currency (e.g. cent, pence or öre)
3.11
data element
datum, which might itself consist of lower level data elements
3.12
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[ISO 7498-2:1989, definition 3.3.21]
2 © ISO 2011 – All rights reserved

3.13
data set
logical set of data elements selected by semantic relation
NOTE Data set is used only for better understanding and is fully independent from implementation solutions.
3.14
Front End
part(s) of the toll system where road usage data for an individual road user are collected, processed and
delivered to the Back End
NOTE The Front End comprises the on-board equipment and an optional proxy.
3.15
interval scale parameters
scale of measurement of data, according to which the differences between values can be quantified in
absolute but not relative terms and for which any zero is merely arbitrary
NOTE Interval scaled parameters are applicable in mathematical equations using the operators plus or minus.
Interval scales having a zero offset are equal to ratio scales.
EXAMPLE The temperature scale in Celsius is an interval scale, in Kelvin it's a ratio scale.
3.16
layout
technical description of the location of a tolled object including, if applicable, auxiliary data for determining the
vehicle's position relative to the tolled object
3.17
nominal scale parameters
discrete classification of data, in which data are neither measured nor ordered but subjects are merely
allocated to distinct categories
NOTE Nominal scaled parameters are applicable in Boolean equations using the operators equal or not equal.
EXAMPLE A nominal scale parameter for vehicles could consist of cars, trucks, vans and motorcycles.
3.18
on-board equipment
OBE
equipment fitted within or on the outside of a vehicle and used for toll purposes
NOTE The OBE does not need to include payment means.
[ISO 14906:2011, definition 3.13]
3.19
ordinal scale parameters
scale on which data is shown simply in order of magnitude since there is no standard of measurement of
differences
NOTE Ordinal scaled parameters are applicable in Boolean equations using the operators greater, greater or equal,
less or less or equal.
3.20
proxy
optional component of the Front End that communicates with on-board equipment and processes road usage
data into a format compliant with this part of ISO/TS 17575 and delivers the data to the Back End
3.21
ratio scale
scale of measurement of data, having a fixed zero value, which permits the comparison of differences of
values
NOTE Ratio scaled parameters are applicable in mathematical equations using the operators multiplication and
division.
3.22
road
any stretch of land which can be navigated by a vehicle
3.23
road usage
travelling on a road with a vehicle
3.24
road section tolling
processes for EFC based on charges for individual road sections
3.25
toll
charge, tax, fee or duty in connection with using a vehicle within a toll domain
NOTE The definition is the generalization of the classic definition of a toll as a charge, a tax, or a duty for permission
to pass a barrier or to proceed along a road, over a bridge, etc. The definition above also includes fees regarded as an
(administrative) obligation, e.g. a tax or a duty.
3.26
tolled area
geographic area where a toll is applied for use of vehicles
3.27
tolled passage
location where a toll is applied for passing vehicles
3.28
tolled road
road where a toll is applied for vehicles
3.29
tolled road network
road network where a toll is applied for vehicles
3.30
tolled road section
road section where a toll is applied for vehicles
3.31
toll context
logical view of a toll scheme as defined by attributes and functions
NOTE Adapted from ISO/TS 12813:2009.
3.32
toll context data
set of data necessary to define a toll context
4 © ISO 2011 – All rights reserved

3.33
toll domain
area or part of a road network where a toll regime is applied
[ISO 14906:2011, definition 3.21]
3.34
toll regime
set of rules, including enforcement rules, governing the collection of toll in a toll domain
3.35
toll scheme
organizational view of a toll regime, including the group of actors of one toll domain and their relationships
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
ADU Application data unit
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
CCC Compliance Check Communication, as defined by ISO/TS 12813:2009
CN Cellular network
EFC Electronic Fee Collection (ISO 14906:2011); here used equivalently to the term toll in ISO 17573
GNSS Global Navigation Satellite Systems
HOT High Occupancy Tolling
ID Identifier
OBE On Board Equipment
PICS Protocol Implementation Conformance Statements
UTC Coordinated Universal Time
VAT Value added tax
5 General concept and overview
To enable a Front End to operate autonomously in a toll domain in the expected manner, a particular set of
data elements containing application data has to be available to the Front End. These data elements shall
contain a description of the rules which apply in a toll domain. This includes information regarding tariffs,
vehicle classes, description of the charge objects and others.
The data elements shall be made available to the Front End using the communication services described in
ISO/TS 17575-2.
For the purpose of data transfer an application data unit (ADU) is defined which comprises a header (mainly
containing identification and data management information) and a data body (containing the application data
elements itself).
The ADU header allows for identification of the data originator and the data sender. Furthermore it contains
information about the EFC context to which the application data belong. Finally the ADU header carries a
sequence number and an optional authenticator.
The data elements containing the EFC context description shall be dedicated to one single EFC context. To
support the use of the Front End in multiple EFC contexts, the Front End may have the capability to manage
multiple sets of data elements (one per EFC context) (see also Figure 4). Details regarding these “roaming”
procedures and the normative requirements are defined in ISO/TS 17575-4.

Figure 4 — Logical structure of toll context descriptions in a Front End
NOTE There may be a maximum number of toll regimes a Front End can manage. This number may depend on the
memory size, the complexity of the toll regime and the envisaged use of the Front End. Front Ends may also be designed
in a way to support the context description for one particular toll regime only. Other Front End designs may support
context descriptions for more than one toll regime.
Context data are structured into logical data sets (refer to clause 8.2). Figure 5 gives an overview of these
data sets and the type of information belonging to each data set.
Each data set comprises one or more EFC attributes. EFC attributes contain the application data. They are
defined in clause 8.
Figure 5 — Context data overview
6 © ISO 2011 – All rights reserved

The organization of the memory and the physical structure of the data within a Front End are outside the
scope of this part of ISO/TS 17575.
6 Procedural requirements and encoding rules
6.1 Communication services
For the purpose of transmitting ADUs from the Back End to the Front End, the communication services
defined in ISO/TS 17575-2 shall be used.
6.2 Version and validity handling
Each EFC attribute carries an optional data element containing version and validity information. The data type
of this data element shall always be VersionAndValidity. This data type shall comprise two data elements:
− version and
− validFrom.
The data element version shall give the version number of the respective EFC attribute. The data type shall
VersionId defined in ISO/TS 17575-1. The version number shall always be used in an increasing order.
be
NOTE 1 This concept enables the Front End to autonomously detect missing versions of context data. This may be
used to initiate an action to update the respective information.
The data element validFrom shall give the start date and time of the validity of the respective EFC attribute.
The data type shall be DateAndTime as defined in ISO 14906.
The information regarding version and validity of EFC attributes enables the Front End to autonomously notice
the existence of new updated context data in the Back End.
NOTE 2 Once the start date and time of a context data is reached, previous versions (having a version number lower
than the current one) become obsolete. The Front End may decide - depending on local settings - to initiate an action to
activate the valid context data and deactivate (and delete) the previous used version(s).
The given version and validity information are exclusively valid for the EFC attribute it belongs to.
NOTE 3 This concept allows the efficient use of different versions for different types of context data. E.g. the tariff table
version may be managed independently from the one valid for context layout and reporting rules. This approach reduces
the amount of data to be updated.
NOTE 4 The update process itself is outside the scope of this part of ISO/TS 17575.
6.3 Encoding rules
The data types and associated coding related to the data elements described in Clauses 7 and 8 are defined
using the Abstract Syntax Notation One (ASN.1) technique according to ISO/IEC 8824-1 (Annex A).
The packed encoding rules according to ISO/IEC 8825-2 shall be applied.
Octet alignment shall be used.
The distinguished encoding rules shall not apply.
7 Application data units
7.1 Application data unit structure
For the purpose of data transfer and identification the information content shall be structured into application
data units (ADU).
Each ADU shall consist of
− an ADU header and
− an ADU body.
Figure 6 — Structure of an ISO 17575-3 ADU
7.2 Application data unit header
The ADU header shall consist of the data fields (Figure 7)
− information sender identifier field,
− information originator identifier field,
− toll charger identifier field
− context identifier field
− ADU sequence number field
− ADU authenticator field (optional).

Figure 7 — Structure of the ADU header
The semantics for the data elements of the ADU header shall be according to Table 1. The data types are
defined in Annex A.
8 © ISO 2011 – All rights reserved

Table 1 — Data elements of the ADU Header
Data type
Data element Definition of semantic Remarks
(informative)
informationSender Provider Unique identifier of the entity which has sent the e.g. Transport Service
data provided in the ADU body Provider, Toll Charger or
Service Provider
informationOriginator Provider Unique identifier of the entity which has created e.g. Transport Service
the data provided in the ADU body Provider, Toll Charger or
Service Provider
tollCharger Provider Unique identifier of the entity which acts as toll Consist of country code
charger of the toll regime and unique number within
country
contextId ContextId Unique identifier for the toll context the data in Consist of country code
the ADU body are applicable to and unique number within
country
aduSequenceNumber Int4 Sequence number of the respective ADU Shall be used in increasing
order. In case of overflow,
the sequence number
shall restart at 0.
aduAuthenticator Bit String Message Authenticator Optional

7.3 Application data unit body
The ADU body shall contain one or more EFC attributes describing the EFC context. One ADU body shall
contain EFC attributes belonging to one single EFC context only.
NOTE Very complex EFC contexts (e.g. containing different types of toll schemes like a cordon pricing and a section
pricing) may be split into two EFC context descriptions. Interdependencies between these multiple layout descriptions are
specified in ISO/TS 17575-4.
The EFC context is identified by information given in data element contextId in the ADU header.
EXAMPLE 1 The ADU body contains the tariff table for the Barcelona congestion charging scheme.
EXAMPLE 2 The ADU body contains the geographic description of the road network of the truck tolling schemes
applicable on highways in Hungary.
EXAMPLE 3 The ADU body contains the reporting rules applicable in the nationwide all-road charging scheme in
Denmark.
EFC attributes and sections descriptions are defined in chapter 8.
8 EFC Attributes
8.1 Rules with respect to support of context data
Context data available in the Front End shall contain all information required to ensure a minimum level of
functionality to either participate in the services of this toll regime or to unambiguously identify the toll regime
as not valid (for the specific user, vehicle, moment in time.).
Each attribute being part of the context data shall be allocated to one single EFC context.
8.2 Attributes and data sets
Each EFC context shall be described using one or more EFC attributes. EFC attributes shall contain all
necessary information to enable proper functioning of the Front End in the respective EFC context.
To improve readability of this part of ISO/TS 17575 toll context description respectively attributes have been
logically structured into data sets.
The following data sets are used:
− Regime Overview,
− Tariff Information,
− Context Layout,
− Reporting Rules.
NOTE Logical data sets are fully independent from the physical data structure in a Front End. The physical structure
is implementation dependent and outside the scope of this part of ISO/TS 17575.
8.3 EFC attributes data catalogue
8.3.1 General
The following EFC attributes or a subset here of shall be available to the Front End (Table 2).
Table 2 — List of EFC attributes
EFC Attribute Data set Refer to
TollContextOverview Context Overview chapter 8.3.2
TariffTable Tariff Information chapter 8.3.3.2
TariffClassDefinition chapter 8.3.3.3
LocalVehicleClassDefinition chapter 8.3.3.4
TimeClassDefinition chapter 8.3.3.5
UserClassDefinition chapter 8.3.3.6
TollContextLayout Context Layout chapter 8.3.4
ChargeReportingEvents Reporting Rules chapter 8.3.5.1
ChargeReportConfiguration chapter 8.3.5.2

In the following clauses, EFC attributes and data elements are specified in terms of:
− the names of the data elements forming the EFC attributes,
− the content and semantic definition of the EFC attributes and data elements,
− informative remarks, including references to other standards.
The specification of the corresponding data types in ASN.1 is provided in the normative Annex A.
10 © ISO 2011 – All rights reserved

8.3.2 Data set “Context Overview”
Toll context overview information shall be represented by one single EFC attribute TollContextOverview.
The attribute TollContextOverview shall contain information about toll context identification, type of the toll
scheme (e.g. section based tolling, area pricing, cordon pricing), time zone information and information
regarding the operational status of the toll context.
The main purpose of the EFC attribute TollContextOverview is to give the Front End a minimum amount of
basic information regarding a toll scheme. Based on these overview data the Front End may or may not
require more information.
EXAMPLE Based on the information in data element tollContextBoundingBoxes a Front End dedicated to a
passenger car may notice that it is cruising in a toll domain. But due to the information in the data element
operationalStatus it may realize that this toll regime is currently inactive. In this case the Front End may not require
additional data (like context layout or tariff table) of this respective toll scheme.
Structure and data elements of the EFC attribute TollContextOverview are given in table below and defined
in Annex A.
Table 3 — EFC attribute TollContextOverview (informative)
EFC Attribute Data element Data Type Remark
TollContextOverview tollCharger TollCharger
tollContext ContextId
tollSchemeName UTF8String optional
tollSchemeType TollSchemeType
operationalStatus OperationalStatus
timeZone INTEGER (-720.720)
tollContextBoundingBoxes SEQUENCE OF SphericalBox optional
TollContextOverviewVersion VersionAndValidity
TollContextOverviewAuthenticator MessageAuthenticator optional

The data element tollCharger shall identify the toll charger which operates the toll scheme for which the
context description is valid. The data type shall be TollCharger defined in ISO/TS 17575-1:2010.
The data element tollContext shall identify the toll context for which the context description is valid. The
data type shall be ContextId, defined in ISO/TS 17575-1:2010.
The data element tollSchemeName shall contain a designation for the toll scheme. The data element shall be
optional. The data type shall be UTF8String.
NOTE This data element may be used to display a well known “brand name” of the toll scheme in the OBE (e.g.
“LKW Maut”, “Go Maut” or “TIS-PL”).
The data element tollSchemeType shall contain information regarding the type of the toll scheme (road
section pricing, distance based area pricing, time based area pricing, cordon pricing).
The data element operationalStatus shall contain information regarding the period of operation of the toll
scheme. This information shall be given by defining date and time when the toll regime starts or has started
operation (in data element startsOperationAt) and optionally by defining date and time when the toll regime
will stop operation (in date element stopsOperationAt). Both data elements startsOperationAt and
stopsOperationAt shall by of data type DateAndTime defined in ISO 14906:2011.
The data element timeZone shall give the time zone applicable for the toll scheme in relation to UTC. The
data type is INTEGER(-720.720). The value shall be given in minutes in relation to UTC (-720 … +720
minutes). In case one single toll domain is located on more than one time zone, this toll domain shall be split
into two separate toll contexts and have two context descriptions.
All absolute time information used in EFC attributes and data elements defined in this part of ISO/TS 17575
(especially in the time class definitions) shall be given in local real time. In case daylight-saving time applies
the Front End shall be capable of re-calculating time information according to the applicable legal rules.
The data element tollContextBoundingBoxes shall contain a list of spherical rectangles which enclose the
geographic area of the toll context. Each list entry shall be of data type SphericalBox. The data type
SphericalBox shall contain the description of a spherical rectangle by defining the edges of the rectangle in
latitude and longitude. The date element SphericalBox shall contain the data elements southernLatitude,
northernLatitude, westernLongitude and easternLongitude. The data elements in the data type
SphericalBox shall be used as follows:
− data element southernLatitude shall contain the lower (southernmost) latitude value (data type
Latitude),
− data element northernLatitude shall contain the larger (northernmost) longitude value (data type
Latitude),
− data element westernLongitude shall contain the lower (westernmost) latitude value (data type
Longitude) and
− data element easternLongitude shall contain the larger (easternmost) latitude value (data type
Longitude).
The data element TollContextOverviewVersion shall contain version and validity information for the EFC
attribute TollContextOverview. The data type shall be VersionAndValidity. For details refer to clause 6.2.
The data element TollContextOverviewAuthenticator shall contain a message authenticator valid for the
EFC attribute TollContextOverview. The data type shall be MessageAuthenticator defined in
ISO/TS 17575-1:2010. The data element TollContextOverviewAuthenticator shall be optional.
8.3.3 Data group “Tariff Information”
8.3.3.1 Concept and overview
The EFC attributes in the data set Tariff Information shall contain all necessary information regarding
− tariff table
− tariff classes and
− locally applicable definitions for vehicle classes, time classes and user classes.
All these information is toll regime specific.
12 © ISO 2011 – All rights reserved

The data set shall comprise the EFC attributes
− TariffTable
− TariffClassDefinition
− LocalVehicleClassDefinition
− TimeClassDefinition
− UserClassDefinition
The following clauses give the descriptions and definitions for these EFC attributes.
The fee calculation algorithm is specified in clause 8.3.3.7.
8.3.3.2 Tariff table
Each EFC context description contains exactly one tariff table. The tariff table comprises the following
information:
− For each tariff class:
o a unique tariff class identifier,
o a basic fee per charge unit,
o the VAT amount per charge unit,
o an interval scale parameter (optional),
o an offset fee (optional)
o a minimum fee (optional),
o
...