EN ISO 17575-3:2016

SLOVENSKI STANDARD
01-julij-2016
1DGRPHãþD
SIST-TS CEN ISO/TS 17575-3:2011
SIST-TS CEN ISO/TS 17575-3:2011/AC:2014
Elektronsko pobiranje pristojbin - Definicija aplikacijskega vmesnika za
avtonomne sisteme - 3. del: Podatki iz sobesedila (ISO 17575-3:2016)
Electronic fee collection - Application interface definition for autonomous systems - Part
3: Context data (ISO 17575-3:2016)
Elektronische Gebührenerhebung - Definition der Anwendungsschnittstelle für autonome
Systeme - Teil 3: Kontextdaten (ISO 17575-3:2016)
Perception du télépéage - Définition de l'interface d'application pour les systèmes
autonomes - Partie 3: Données du contexte (ISO 17575-3:2016)
Ta slovenski standard je istoveten z: EN ISO 17575-3:2016
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 17575-3
EUROPEAN STANDARD
NORME EUROPÉENNE
February 2016
EUROPÄISCHE NORM
ICS 35.240.60; 03.220.20 Supersedes CEN ISO/TS 17575-3:2011
English Version
Electronic fee collection - Application interface definition
for autonomous systems - Part 3: Context data (ISO 17575-
3:2016)
Perception du télépéage - Définition de l'interface Elektronische Gebührenerhebung - Definition der
d'application pour les systèmes autonomes - Partie 3: Anwendungsschnittstelle für autonome Systeme - Teil
Données du contexte (ISO 17575-3:2016) 3: Kontextdaten (ISO 17575-3:2016)
This European Standard was approved by CEN on 11 December 2015.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 17575-3:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
European foreword
This document (EN ISO 17575-3:2016) has been prepared by Technical Committee ISO/TC 204
“Intelligent transport systems” in collaboration with Technical Committee CEN/TC 278 “Intelligent
transport systems” the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by August 2016, and conflicting national standards shall
be withdrawn at the latest by August 2016.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
This document supersedes CEN ISO/TS 17575-3:2011.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Endorsement notice
The text of ISO 17575-3:2016 has been approved by CEN as EN ISO 17575-3:2016 without any
modification.
INTERNATIONAL ISO
STANDARD 17575-3
First edition
2016-01-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 17575-3:2016(E)
©
ISO 2016
ISO 17575-3:2016(E)
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Abbreviated terms . 4
5 General concept and overview . 5
6 Procedural requirements and encoding rules . 7
6.1 General . 7
6.2 Communication services . 7
6.3 Version and validity handling. 7
6.3.1 Protocol versioning. 7
6.3.2 Context data versioning . 7
6.4 Encoding rules . 8
6.5 Acknowledgement and behaviour on errors . 8
7 Application data units . 8
7.1 General . 8
7.2 Message authentication (data type Iso17575-3-InformationContent) . 9
7.3 Application data unit structure (data type Iso17575-3Adu) . 9
7.4 Application data unit header (data type ISO 17575-3AduHeader) .10
7.5 Application data unit body (data type ISO 17575-3AduBody) .11
8 EFC Attributes .11
8.1 General .11
8.2 Rules with respect to support of context data .12
8.3 Attributes and data sets .12
8.4 EFC attributes authentication .12
8.5 EFC attributes data catalogue .13
8.5.1 General.13
8.5.2 Requirements with regards to context overview .14
8.5.3 Requirements with regards to tariff information .17
8.5.4 Requirements with regards to context layout .35
8.5.5 Requirements with regards to reporting rules .45
Annex A (normative) Data type specifications .59
Annex B (normative) Protocol implementation conformance statement (PICS) proforma .60
Annex C (informative) Hierarchical data structure illustration .98
Annex D (informative) How to use context data to define the properties of an EFC regime .103
Annex E (informative) Guidelines on the use of standardised digital maps in GDF format in
the description of section based toll context layouts .108
Annex F (informative) Examples using EFC context data for scheme definitions .111
Annex G (informative) Use of this part of ISO 17575 for the EETS .116
Bibliography .118
ISO 17575-3:2016(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
This edition of ISO 17575-3 cancels and replaces ISO/TS 17575-3:2011, which has been technically
revised. The following changes have been made:
— conversion from a Technical Specification to an International Standard;
— amendments to reflect changes to the underlying base standards, especially ISO 14906;
— major changes regarding
— integration of functionalities for the support of complex toll domains that consist of more than
one partition from ISO/TS 17575-2:2010,
— changes in the security scheme details,
— introduction of protocol version identification,
— harmonization of the identification of toll contexts amongst the parts of ISO 17575,
— improvement of the possibility to use rounding rules,
— enabling the use of a second alternative currency in tariffs,
— adaptation of the charge reporting configuration to changes in ISO 17575-1:2016,
— enabling the use of toll context partitions which may be present in one single toll context,
— support of optional geographic data files (GDF) based description of toll liable networks
(embracing such data definitions from ISO 12855:2012,
— revised terms and definitions (Clause 3), and
— editorial and formal corrections as well as changes to improve readability.
iv © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
ISO 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
In this edition of the ISO 17575-series the contents of ISO/TS 17575-4:2011 were incorporated into
ISO 17575-3:2016. ISO/TS 17575-4:2011 will be withdrawn once ISO 17575-3 has been published.
ISO 17575-3:2016(E)
Introduction
0.1 Autonomous systems
ISO 17575 is a series of standards 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 such as bridges and tunnels, distance-
based charging, and parking fees.
Further introductory explanations of autonomous systems in EFC and, in particular, the considerations
with respect to business and technical architecture that form the base for interfaces within such system
and their interoperable specification are provided in ISO 17575-1:2016.
0.2 Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices,
the primary scope of ISO 17575 is the data exchange between Front End and Back End (see the
corresponding vertical line in Figure 1). For every toll scheme, the Back End will send context data, i.e.
a description of the toll scheme 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.
It has to be noted also that the distribution of tasks and responsibilities between service provider and
toll charger will vary individually. Depending on the 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 17575 may be useful on several interfaces.
ISO 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.
Figure 1 — Scope of ISO 17575
vi © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
0.3 The parts of ISO 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End.
The contents of charge reports might vary between toll regimes, 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. A toll regime comprises a set of rules for charging, including the
charged network, the charging principles, the liable vehicles and a definition of the required contents of
the charge report.
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. The data defined in ISO 17575-1 and
ISO 17575-3 can, but need not be, exchanged using the communication stack as defined in ISO 17575-2.
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 ISO 17575-3 are used to transfer data to the Front End in order to instruct it on
which data to collect and report.
0.4 Application needs covered by ISO 17575
The ISO 17575-series of standards
— is compliant with the architecture defined in ISO 17573:2010,
— supports 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),
— supports fee collection based on units of distance or duration, and based on occurrence of events,
— supports modulation of fees by vehicle category, road category, time of usage and contract type (e.g.
exempt vehicles, special tariff vehicles, etc.),
— supports limiting of fees by a defined maximum per period of usage,
— supports fees with different legal status (e.g. public tax, private toll),
— supports differing requirements of different toll chargers, especially in terms of
— geographic domain and context descriptions,
— contents and frequency of charge reports,
— feedback to the driver (e.g. green or red light), and
— provision of additional detailed data on request, e.g. for settling of disputes,
— supports overlapping geographic toll domains,
— supports adaptations to changes in
— tolled infrastructure,
— tariffs, and
— participating toll schemes, and
— supports the provision of trust guarantees by the service provider to the toll charger for the data
originated from the Front End.
INTERNATIONAL STANDARD ISO 17575-3:2016(E)
Electronic fee collection — Application interface definition
for autonomous systems —
Part 3:
Context data
1 Scope
This part of ISO 17575 defines the content, semantics and format of the data exchange between a Front
End (OBE plus optional proxy) and the corresponding Back End in autonomous toll systems. It defines the
data elements used to specify and describe the toll context details. Context data are transmitted from
the Back End to the Front End to configure it for the charging processes of the associated toll context.
In ISO 17575, context data is the description of the properties of a single instance of an electronic fee
collection (EFC) context. This single instance of an EFC context operates according to one of the basic
tolling principles such as
— road section charging,
— area charging (according to travelled distance or duration of time), and
— cordon charging.
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.
The following data and associated procedures are defined in this part of ISO 17575:
— data providing toll context overview information;
— data providing tariff information (including definitions of required tariff determinants such as
vehicle parameters, time classe, etc.);
— data providing context layout information;
— data providing reporting rules information.
This part of ISO 17575 also provides the required definitions and data specifications to be applied when
one single toll context is spilt inot more than one toll context partitions. This is applicable to cases
where one EFC scheme and the rules applied cannot be described with a single set of context data.
Annex A provides the data type specification using ASN.1 notation.
The protocol implementation conformity statements (PICS) proforma are provided in Annex B.
Annex C provides a graphical presentation of the structure of the toll context data.
Annexes D, E and F contain further information and descriptions, which may support the understanding
and the implementation of the rules specified in this part of ISO 17575.
Annex G provides information how this part of ISO 17575 can be used in a European Electronic Toll
Service (EETS) environment, with reference to EU Decision 2009/750.
ISO 17575-3:2016(E)
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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:2008, Information technology — Abstract Syntax Notation One (ASN.1): Specification of
basic notation — Part 1
ISO/IEC 8825-2:2008, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER) — Part 2
ISO 12813:2015, Electronic fee collection — Compliance check communication for autonomous systems
ISO 14906:2011/Amd1:2015, Electronic fee collection — Application interface definition for dedicated
short-range communication
ISO 17575-1:2016, Electronic fee collection — Application interface definition for autonomous systems —
Part 1: Charging
EN 15509:2014, Electronic fee collection — Interoperability application profile for DSRC
NIMA TR8350.2, Third Edition — Amendment 1, January 2000, Department of Defense — World
Geodetic System 1984, Its Definition and Relationships With Local Geodetic Systems, issued by National
Imagery and Mapping Agency (NIMA), US Department of Defense
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
area charging
charging based on road usage within a given area
[SOURCE: ISO 17575-1:2016, 3.1]
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data elements
[SOURCE: ISO 17575-1:2016, 3.2]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
3.4
Back End
part of a back office system interfacing to one or more Front Ends (3.11)
[SOURCE: ISO 17575-1:2016, 3.4]
2 © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
3.5
charge object
geographic or road related object for the use of which a charge is applied
[SOURCE: ISO 17575-1:2016, 3.5]
3.6
charge report
information containing road usage and related information originated at the Front End (3.11)
[SOURCE: ISO 17575-1:2016, 3.6]
3.7
cordon
border line of an area
[SOURCE: ISO 17575-1:2016, 3.7]
3.8
cordon charging
charging for the crossing of a cordon (3.7)
[SOURCE: ISO 17575-1:2016, 3.8]
3.9
data element
coded information, which might itself consist of lower level information structures
[SOURCE: ISO 17575-1:2016, 3.9]
3.10
data set
logical set of data elements (3.9) with a semantic relation
Note 1 to entry: Data set is used only for better understanding and is fully independent from implementation
solutions.
3.11
Front End
part of a tolling system consisting of an OBE (3.13) and possibly a proxy (3.14) where road tolling
information and usage data are collected and processed for delivery to the Back End (3.4)
[SOURCE: ISO/TS 19299:2015, 3.17]
Note 1 to entry: The Front End comprises the on-board equipment (3.13) and an optional proxy (3.14).
3.12
layout
technical description of the location of tolled objects including their borders
3.13
on-board equipment
OBE
all required equipment on-board a vehicle for performing required EFC functions and
communication services
3.14
proxy
optional part of a Front End (3.11) that communicates with external equipment and processes the data
received into an agreed format to be delivered to the Back End (3.4)
[SOURCE: ISO 17575-1:2016, 3.13]
ISO 17575-3:2016(E)
3.15
road section charging
tolling principle where the fee is due if predefined sections of roads are used
[SOURCE: ISO 17575-1:2016, 3.14]
3.16
toll
charge, tax or duty levied in connection with using a vehicle in a toll domain (3.20)
[SOURCE: ISO/TS 19299:2015, 3.42, modified — “any” has been deleted from before “charge”.]
Note 1 to entry: 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 also includes fees
regarded as an (administrative) obligation, e.g. a tax or a duty.
3.17
tolled area
geographic area where a toll (3.16) is charged for road usage
3.18
toll context
logical view as defined by attributes (3.2) and functions of the basic elements of a toll scheme consisting
of a single basic tolling principle, a spatial distribution of the charge objects (3.5) and a single behaviour
of the related Front End (3.11)
[SOURCE: ISO 17575-1:2016, 3.17]
3.19
toll context data
information defined by the responsible toll charger as necessary to establish the toll (3.16) due for
using a vehicle on a particular toll context (3.18) and to conclude the toll transaction
[SOURCE: ISO 12855:2015, 3.15]
3.20
toll domain
area or part of a road network where a certain toll regime (3.21) is applied
[SOURCE: ISO 17573:2010, 3.18, modified — “certain” has been added.]
3.21
toll regime
set of rules, including enforcement rules, governing the collection of toll (3.16) in a toll domain (3.20)
[SOURCE: ISO 17573:2010, 3.20]
3.22
toll scheme
organizational view of a toll regime (3.21), including the actors and their relationships
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
ADU Application data unit (ISO 14906)
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
CCC Compliance check communication (ISO 12813)
4 © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
CN Cellular network
DSRC Dedicated short-range communication (ISO 14906)
DST Daylight saving time
EFC Electronic fee collection (ISO 14906)
GDF Geographic Data Files (ISO 14825)
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 that apply in a toll domain. This includes information regarding
tariffs, vehicle classes, description of the charge objects, etc.
The data elements may be made available to the Front End using the communication services described
in ISO 17575-2:2016.
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 toll context to which the application data belong. Finally, the ADU
header carries a sequence number.
This part of ISO 17575 is based on the assumption that one toll scheme may consist of multiple parts.
The data requirements provided in this part of ISO 17575 support this concept. In addition, Front Ends
may be used in more than one toll scheme. In such cases, the Front End might have the capability to
manage multiple sets of toll context data elements (one per toll scheme). See Figure 2.
ISO 17575-3:2016(E)
Figure 2 — Logical structure of toll context descriptions in a Front End
There may be a maximum number of toll contexts a Front End can manage. This number may depend on
the memory size, the complexity of the toll context data 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 scheme
only. Other Front End designs may support context descriptions for more than one toll scheme.
Context data are structured into logical data sets (see 8.3). Figure 3 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 3 — Context data overview
A single toll scheme (and related toll context data) may be split into several parts. Each part of the toll
scheme may be of different charging type (i.e. section charging, area charging and cordon charging),
may have an individual layout and thus may require different toll context data. This part of ISO 17575
supports this concept by so-called toll context partitions. Details are specified in Clause 8.
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 17575.
6 © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
6 Procedural requirements and encoding rules
6.1 General
This clause provides normative requirements with regards to
— communication services to be applied for the exchange of context data,
— provisions offered in this part of ISO 17575 in order to enable version and validity control of
context data, and
— encoding rules to be applied for context data.
6.2 Communication services
For the purpose of transmitting ADUs from the Back End to the Front End, the communication services
defined in ISO 17575-2:2016 or any other appropriate communication services may be used.
NOTE 1 Details with respect to communication services are usually agreed between the operating entities of
Back End and Front End.
NOTE 2 State-of-the-art communication frameworks (so-called middleware) designed for data exchange
between IT systems and subsystems are appropriate candidate solutions.
6.3 Version and validity handling
6.3.1 Protocol versioning
The Back End shall provide, with each submission of toll context data to the Front End, the
application interface definition (syntax and semantics) that is used by the Back End by means of the
protocolVersion.
The protocolVersion information shall be part of the ADU header of the message. The specification
of the protocolVersion information is provided in 7.4 and in A.2.
In cases where the receiving Front End does not support the application interface definition (as
indicated by the protocolVersion) the Back End requests, the Front End shall provide a negative
response to the Back End.
NOTE ISO/TS 17575-3:2011 id not support the version handling of application interface definitions by means
of protocolVersion.
6.3.2 Context data versioning
Each EFC attribute includes an optional data element containing version and validity information
applicable for the respective EFC attribute. The data type of this data element shall always be
VersionAndValidity. This data type shall comprise two data elements:
— version;
— validFrom.
The data element version shall give the version number of the respective EFC attribute. The data type
shall be VersionId defined in ISO 17575-1:2016. The version number shall be used in an increasing order.
NOTE 1 This concept enables the Front End to autonomously detect missing versions of context data and
potentially initiate an action to update the respective information in the Front End.
The data element validFrom shall give the start date and time of the validity of the respective EFC
attribute. The data type shall be GeneralizedTime as defined in ISO 14906:2011/Amd1:2015.
ISO 17575-3:2016(E)
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 context data are reached, previous versions (having a version number
lower than the current one) become obsolete. The Front End can 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 shall be 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. For
example, the tariff table version can 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 17575.
The optional data element tollContextVersion shall be used for the version identification for
the entire toll context description. This data element is a component of the data type Iso17575-
3AduBody. The data type shall be Int1.
NOTE 5 If and how such context version identification is composed, using the version information of the
underlying attributes and data elements (i.e. vehicle class definitions, layout description, charge reporting
events, charge report configuration, tariff definitions), depends on the particular operational requirements and
implementation solution.
NOTE 6 One potential use of such context version identification is in relation to compliance check communication
(CCC) and the related data exchange. ISO 12813:2015 specifies a context version identifier (also of type Int1) that
may be provided from the Front End to enforcement facilities. Based on such data, a simple check is possible to
identify Front Ends in enforcement processes that use an outdated version of the toll context description.
6.4 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 (see Annex A).
The encoding rules (e.g. Basic, Packed or XML Encoding Rules, BER, PER or XER) are not specified in
this part of ISO 17575 because the physical implementation of the ISO 17575 interface can vary widely.
Therefore, the choice of encoding rules shall be adapted to the specific needs (e.g. coding efficiency,
compatibility with existing software environments, etc.).
6.5 Acknowledgement and behaviour on errors
The interface between Front End and Back End is located within the realm of the entity acting
as toll service provider. Therefore, it can be expected that this interface is not necessarily an
interoperable interface.
In order to keep the freedom and flexibility for existing and future implementation options and to not
over-specify requirements that are in the sole realm of one designing entity, this part of ISO 17575
does not contain any requirements with regards to acknowledgements and behaviour on errors. It is
expected that the entity designing this interface makes the appropriate provisions to ensure a reliable
and stable operation of this interface and the transfer of toll context data under any possible conditions.
7 Application data units
7.1 General
This clause provides normative requirements with regards to information used to manage the exchange
of toll context data. In order to provide the receiving end with the interface appropriate management
information, such data are made available, in addition to the toll context data, in a dedicated protocol
header (see 7.3). The header consists of various data elements, as specified in 7.4 below. The context
8 © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
data are considered as the “payload” of the data exchange and are made available in the ADU body (see
7.3 and 7.5).
7.2 Message authentication (data type Iso17575-3-InformationContent)
To ensure an uninterrupted chain of trust, security mechanisms are implemented for proof of
authenticity and integrity of the transmitted application data units.
To support an integer and secure transfer of toll context data from the Back End to the Front End,
optional authentication mechanisms have been introduced and may be used by the involved entities.
Consequently, and depending on the use of the optional authentication, the information content is either
an
— unauthenticated application data unit (notAuthenticatedIso17575-3Adu of type
Iso17575-3Adu); or
— authenticated application data unit (authenticatedIso17575-3Adu of type
AuthenticatedIso17575-3Adu).
The detailed specification of the data type Iso17575-3Adu is provided in 7.3.
The data type AuthenticatedIso17575-3Adu comprises the following data elements:
— iso17575-3AduPer;
— messageAuthenticator.
The data element iso17575-3AduPer is a container (of type BIT STRING) that shall hold a data
element of type Iso17575-3Adu, which is encoded using ASN.1 Packed Encoding Rules aligned
according to ISO/IEC 8825-2.
The data element messageAuthenticator (of type MessageAuthenticator) shall hold the
authenticator, which shall be calculated over the single bit string content of iso17575-3AduPer.
NOTE The data type MessageAuthenticator is imported from and defined in ISO 17575-1:2016. Details
with respect to functionalities, data elements and options provided in the entire message authentication data
structure are described in ISO 17575-1:2016, ISO/TS 19299:2015 and in the underlying data security standards
as referenced by ISO 17575-1:2016.
7.3 Application data unit structure (data type Iso17575-3Adu)
For the purpose of context data transfer and context data identification, the message content shall be
structured into application data units (ADU), see Figure 4.
Each ADU shall consist of an
— ADU header (of data type Iso17575-3AduHeader), and
— ADU body (of data type Iso17575-3AduBody).
Figure 4 — Structure of an ISO 17575-3 ADU
ISO 17575-3:2016(E)
7.4 Application data unit header (data type ISO 17575-3AduHeader)
The ADU header shall provide management information that applies in relation to the payload (i.e.
context data) provided in the ADU body. The Front End may need this information for internal processes
of context data management, storage and processing.
The information provided in the ADU header is valid for the entire set of context data provided in
the ADU body.
The ADU header shall consist of the following data fields (Figure 5):
— applied protocol version;
— information sender identification;
— information originator identification;
— toll context identification;
— ADU sequence number;
— message date.
Figure 5 — 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
specified in Annex A.
10 © ISO 2016 – All rights reserved

ISO 17575-3:2016(E)
Table 1 — Data elements of the ADU Header
Data type (in-
Data element Definition of semantic Remarks
formative)
protocolVersion AidIdentifier Identifier of the version of the ASN.1 data e.g. “1” = ISO17575-
specification (version of ISO 17575) t
...