ISO 17575-3:2016

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 2016
© 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

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
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 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
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

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.
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

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]
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

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.
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

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.
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

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
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

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) that is 3:2016
used in the application data units
(see also 6.3.1)
informationSender Provider Unique identifier of the entity which has Usually a service pro-
sent the entire message vider operating the Back
End, but may also be
e.g. a transport service
provider, toll charger
informationOriginator Provider Unique identifier of the entity which has e.g. transport service
created the context data provided in the provider, toll charger or
ADU body service provider
tollContext Provider Unique identifier of the entity which acts Consists of country code
as toll charger of the toll scheme to which and unique number
the toll context data belong within the 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’.
messageDate GeneralizedTime Date and time when the message is gener- Can be used for message
ated by the informationSender security purposes, e.g.
for the generation of the
authenticator
7.5 Application data unit body (data type ISO 17575-3AduBody)
The ADU body shall contain one or more EFC attributes describing the toll context. One ADU body shall
contain EFC attributes belonging to one single toll context only.
NOTE Very complex toll contexts (e.g. containing different types of toll schemes such as a cordon charging
and a section charging) can be split into more than one toll context partitions. Interdependencies (priorities)
between the individual toll context partitions are specified by means of priority rules.
The toll context for which the data in the ADU body provide detailed description is identified by
information given in data element tollContext 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 that hold toll context data are defined in Clause 8.
The ADU body also contains the optional data element tollContextVersion. This data element can
be used to specify the version of the entire toll context description (see also 6.3.2).
8 EFC Attributes
8.1 General
This clause provides normative requirements with regards to the EFC attributes holding the context
data in terms of their use, structure and semantics.
8.2 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 scheme or to unambiguously identify the
toll scheme as being not valid e.g. for the specific user, vehicle, moment in time.
Each EFC attribute being part of the context data shall be allocated to one single toll context.
8.3 Attributes and data sets
Each EFC context shall be described using one or more EFC attributes. The full set of EFC attributes
belonging to one EFC context shall contain all necessary information to enable proper functioning of
the Front End in the respective EFC scheme.
For readability, in this part of ISO 17575 the EFC attributes have been logically structured into data sets.
The following data sets are used:
— Context 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 17575.
8.4 EFC attributes authentication
This part of ISO 17575 provides measures that allow for optional authentication of the individual EFC
attributes. In contrast to the message authentication (see 7.2) this option can be used for true end-to-
end security covering the full chain from the originator of context data to the Front End.
EXAMPLE Such end-to-end security allows a Front End module (which can e.g. reside in an OBE) to check the
authenticity, completeness and integrity of a tariff table that is created by the toll charger.
EFC attributes being part of the ADU body can be present in an
— unauthenticated form (data element unsigned-data shall be used), or
— authenticated manner (data element signed-data shall be used).
In cases where the authenticated option is chosen, the data type shall be Signed{Payload}, which
comprises the following data elements:
— payload;
— timeOfAuthentication;
— authenticator.
The data element payload 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 parameter Payload is replaced by the data type of the individual EFC attribute.
The data element timeOfAuthentication shall hold the information of the point in time the
authenticator was calculated.
The data element authenticator (of type MessageAuthenticator) shall hold the authenticator,
which shall be calculated over the single bit string content of payload.
12 © ISO 2016 – All rights reserved

The data type MessageAuthenticator is imported from and defined in ISO 17575-1:2016. Details
with respect to functionalities and options provided in the entire message authentication data structure
are described in ISO 17575-1:2016, ISO/TS 19299:2015 (and the underlying data security standards as
referenced by ISO 17575-1:2016).
NOTE Not all of the possible options provided by the data structure described in ISO 17575-1:2016 are
appropriate for EFC attribute authentication.
8.5 EFC attributes data catalogue
8.5.1 General
The following EFC attrib
...

NORME ISO
INTERNATIONALE 17575-3
Première édition
2016-01-15
Perception du télépéage — Définition
de l’interface d’application pour les
systèmes autonomes —
Partie 3:
Données du contexte
Electronic fee collection — Application interface definition for
autonomous systems —
Part 3: Context data
Numéro de référence
©
ISO 2016
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2016, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
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 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 2
4 Abréviations . 5
5 Concept général et présentation . 5
6 Exigences procédurales et règles de codage. 8
6.1 Généralités . 8
6.2 Services de communication . 8
6.3 Gestion des versions et de la validité . 8
6.3.1 Contrôle de version du protocole . 8
6.3.2 Contrôle de version des données du contexte . 8
6.4 Règles de codage. 9
6.5 Confirmation et comportement en cas d’erreur . 9
7 Unités de données d’application .10
7.1 Généralités .10
7.2 Authentification des messages (type de données Iso17575-3-InformationContent) .10
7.3 Structure des unités de données d’application (type de données Iso17575-3Adu) .10
7.4 En-tête d’unité de données d’application (type de donnée ISO 17575-3AduHeader) .11
7.5 Champ d’unité de données d’application (de type ISO 17575-3AduBody) .12
8 Attributs EFC .13
8.1 Généralités .13
8.2 Règles relatives à la prise en charge des données du contexte .13
8.3 Attributs et ensembles de données .13
8.4 Authentification des attributs EFC .13
8.5 Catalogue de données des attributs EFC .14
8.5.1 Généralités .14
8.5.2 Exigences concernant la présentation du contexte .15
8.5.3 Exigences concernant les informations tarifaires .19
8.5.4 Exigences concernant la configuration du contexte .38
8.5.5 Exigences concernant les règles de génération de rapports .50
Annexe A (normative) Spécifications des types de données .65
Annexe B (normative) Formulaire PICS.66
Annexe C (informative) Illustration de la structure hiérarchique des données .106
Annexe D (informative) Utilisation des données du contexte pour définir les propriétés
d’un régime de perception de péage .111
Annexe E (informative) Directives d’utilisation de cartes numériques normalisées au
format GDF dans la description des configurations de contexte de péage basées sur
des portions .119
Annexe F (informative) Exemples d’utilisation des données du contexte EFCdans les
définitions de plan .123
Annexe G (informative) Utilisation de la présente partie de l’ISO 17575 pour le SET .128
Bibliographie .131
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer
un engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à
l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes
de l’OMC concernant les obstacles techniques au commerce (OTC), voir le lien suivant: Avant-propos —
Informations supplémentaires.
L’ISO 15757-3 a été élaborée par le comité technique ISO/TC 204, Systèmes intelligents de transport.
Cette deuxième édition annule et remplace la première édition (ISO/TS 17575-3:2011), qui a fait l’objet
d’une révision technique. Les modifications suivantes ont été apportées:
— passage d’une Spécification technique au stade de Norme internationale;
— amendements en vue de tenir compte des modifications des normes de base sous-jacentes, en
particulier de l’ISO 14906;
— modifications majeures:
— intégration de fonctionnalités pour la prise en charge de domaines de péage complexes
comprenant plus d’une division provenant de l’ISO/TS 17575-2:2010,
— modifications de détails du plan de sécurité,
— introduction d’une identification de la version de protocole,
— harmonisation de l’identification des contextes de péage dans les parties de l’ISO 17575,
— amélioration concernant la possibilité d’utiliser des règles d’arrondi,
— possibilité d’utiliser une deuxième devise dans les tarifs,
— adaptation de la configuration des rapports d’imputation dans l’ISO 17575-1:2016,
— activation de l’utilisation des divisions de contexte de péage qui peuvent être présentes dans un
même contexte de péage,
iv © ISO 2016 – Tous droits réservés

— prise en charge de la description reposant sur les fichiers de données géographiques (GDF)
facultatifs (utilisant les définitions de données provenant de l’ISO 12855:2012,
— termes et définitions révisés (Article 3), et
— intégration de corrections rédactionnelles et formelles, ainsi que de modifications pour
améliorer la lisibilité.
L’ISO 15757 comprend les parties suivantes, présentées sous le titre général Perception du télépéage —
Définition de l’interface d’application pour les systèmes autonomes:
— Partie 1: Imputation
— Partie 2: Communications et connexions aux couches basses
— Partie 3: Données du contexte
Dans la présente édition de l’ISO 17575, le contenu de la norme ISO/TS 17575-4:2011 a été incorporé à
la norme ISO 17575-3:2016 La norme ISO/TS 17575-4:2011 sera retirée lorsque la norme ISO 17575-3
aura été publiée.
Introduction
0.1 Systèmes autonomes
L’ISO 17575 est une série de normes relatives à l’échange d’informations entre le système frontal et le
système central des applications de perception de télépéage (EFC, Electronic Fee Collection) reposant
sur un équipement embarqué (OBE, On-Board Equipment) autonome. Les systèmes EFC collectent
automatiquement les données nécessaires à la tarification des redevances d’usage de l’infrastructure
routière (notamment les péages autoroutiers et les péages pour les ouvrages spéciaux comme les ponts
et les tunnels), la tarification basée sur la distance parcourue et les redevances de stationnement.
L’ISO 17575-1:2016 fournit des explications de présentation supplémentaires des systèmes autonomes
dans l’EFC et, en particulier, les considérations relatives à l’architecture commerciale et technique
constituant le fondement des interfaces dans ce système et leur spécification d’interopérabilité.
0.2 Localisation de l’interface de spécification
Pour se soustraire et devenir indépendant de ces choix d’implémentation architecturale, le principal
domaine d’application de l’ISO 17575 est l’échange de données entre le système frontal et le système
central (voir la ligne verticale correspondante à la Figure 1). Pour chaque plan de péage, le système
central envoie les données du contexte (ex: description du plan contenant des objets de facturation,
des règles de tarification et, si nécessaire, régime tarifaire) au système frontal et reçoit des données
d’utilisation de la part de ce dernier.
Par ailleurs, on doit également noter que la répartition des tâches et des responsabilités entre le
prestataire de services et le percepteur de péage varie selon les cas. En fonction du contexte juridique
local, les percepteurs de péage ont besoin de données « légères » ou « lourdes » et pourraient confier ou
non certaines tâches de traitement des données à des prestataires de services. De ce fait, les définitions
de données fournies dans l’ISO 17575 peuvent être pertinentes pour plusieurs interfaces.
L’ISO 17575 prévoit également des services de communication de base indépendants des moyens qui
peuvent être utilisés pour la communication (filaire ou aérienne) entre le système frontal et le système
central, qui peuvent également être utilisés pour la liaison aérienne entre l’OBE et le serveur central de
communication.
vi © ISO 2016 – Tous droits réservés

Anglais Français
Scope of the ISO 17575- series Domaine d’application de la série de normes ISO 17575
Back End Système central
Back End Application Application du système central
Back End calls Appel du système central
communication Functions for EFC Fonctions de communication pour l’EFC
communication service primitives Primitives de service de communication
ADU ADU
Front End Système frontal
Front End Application Application du système frontal
Front End calls Appel du système frontal
communication Functions for EFC Fonctions de communication pour l’EFC
communication service primitives Primitives de service de communication
data communication service Service de communication de données
Figure 1 — Domaine d’application de l’ISO 17575
0.3 Parties de l’ISO 17575
Partie 1: Imputation, définit les attributs pour le transfert des données d’utilisation du système frontal
au système central. Le contenu des rapports d’imputation peut varier d’un régime de péage à l’autre; la
présente partie fournit en conséquence des attributs pour toutes les exigences, y compris des attributs
pour les données brutes de localisation, pour les objets géographiques de repérage cartographique et
pour les transactions de péage dont le prix est fixé. Un régime de péage comprend un ensemble de règles
d’imputation, y compris le réseau soumis à péage, les principes d’imputation, les véhicules assujettis au
péage et une définition du contenu exigé du rapport d’imputation.
Partie 2: Communications et connexions aux couches basses définit les services basiques de
communication pour le transfert de données par voie hertzienne de l’équipement embarqué ou entre le
système frontal et le système central. Les données définies dans l’ISO 17575-1 et l’ISO 17575-3 peuvent
être échangées au moyen d’une pile de communication telle que définie dans l’ISO 17575-2, mais cet
échange n’est pas nécessaire.
Partie 3: Données du contexte, définit les données à utiliser pour décrire chaque système de perception
à l’aide d’objets géographiques de facturation et de règles de tarification et de génération de rapports.
Pour chaque système de percepteur de péage, les attributs définis dans la norme ISO 17575-3sont
utilisés pour transférer des données vers le système frontal afin de lui indiquer quelles données il doit
collecter et utiliser pour générer des rapports.
0.4 Besoins en termes d’application couverts par l’ISO 17575
La série de normes ISO 17575
— est conforme à l’architecture définie dans l’ISO 17573:2010,
— prend en charge les tarifications liées à l’usage des portions routières (y compris les ponts, les tunnels,
les ouvrages spéciaux, etc.), le passage de cordons (entrée/sortie) et l’usage d’infrastructures dans
un périmètre délimité (distance, durée),
— prend en charge la perception basée sur des unités de distance ou de durée, et sur l’occurrence
d’événements,
— prend en charge la modulation des redevances selon la catégorie du véhicule, la catégorie de la route,
l’heure d’usage et le type de contrat (ex: véhicules exemptés ou soumis à des tarifs spéciaux, etc.),
— prend en charge la limitation des redevances pour un maximum défini par période d’usage,
— prend en charge les redevances avec différents statuts juridiques (ex: taxes publiques et péages privés).
— prend en charge les diverses exigences des percepteurs de péage, notamment en termes de
— descriptions du domaine géographique et du contexte,
— contenu et fréquence des rapports d’imputation,
— retour d’informations au conducteur (ex: voyant rouge ou vert), et
— fourniture de données détaillées supplémentaires sur demande, par exemple pour le
règlement des litiges,
— prend en charge les domaines géographiques de péage qui se chevauchent,
— prend en charge les adaptations aux modifications apportées dans
— l’infrastructure du péage,
— les tarifs, et
— les plans de péage concernés, et
— prend en charge la provision de garanties fiables par le prestataire de services au percepteur de
péage pour les données issues du système frontal.
viii © ISO 2016 – Tous droits réservés

Perception du télépéage — Définition de l’interface d’application pour les systèmes autonomes
— Partie 3: Données du context
NORME INTERNATIONALE ISO 17575-3:2016(F)
Perception du télépéage — Définition de l’interface
d’application pour les systèmes autonomes —
Partie 3:
Données du contexte
1 Domaine d’application
La présente partie de l’ISO 17575 définit le contenu, la sémantique et le format de l’échange de données
réalisé entre un système frontal (équipement embarqué et proxy facultatif) et le système central associé
dans les systèmes autonomes de péage. Elle définit les éléments de données utilisés pour spécifier
et décrire le contexte de péage en détail. Les données du contexte sont transmises depuis le système
central vers le système frontal, afin de le configurer pour les processus de tarification du contexte de
péage associé.
Dans la norme ISO 17575, les données du contexte correspondent à la description des propriétés d’une
seule instance d’un contexte de perception électronique de télépéage (EFC). Cette instance unique de
perception électronique de télépéage fonctionne selon l’un des principes basiques de tarification:
— tarification de portion routière,
— péage de zone (selon la distance parcourue ou le temps passé), et
— péage de cordon.
Les données du contexte de perception de télépéage incluent un ensemble de règles de tarification,
dont une description du réseau facturé, des régimes de tarification, des véhicules concernés et une
définition du contenu obligatoire pour générer un rapport d’imputation. Cet ensemble de règles est
défini individuellement pour chaque contexte de perception de télépéage selon les exigences locales.
Les données et les procédures associées suivantes sont définies dans la présente partie de l’ISO 17575:
— données fournissant des informations générales sur le contexte de péage;
— données fournissant des informations tarifaires (incluant la définition des déterminants de tarif
requis, tels que les paramètres des véhicules, les classes temporelles, etc.);
— données fournissant des informations sur la configuration du contexte;
— données fournissant des informations sur les règles de génération de rapports.
La présente partie de l’ISO 17575 fournit également les définitions requises et les spécifications de
données à appliquer lorsqu’un même contexte de péage est réparti entre une ou plusieurs divisions de
contexte de péage. Elle s’applique dans les cas où un plan EFC et les règles appliquées ne peuvent pas
être décrits à l’aide d’un ensemble unique de données du contexte.
L’Annexe A donne la spécification du type de données dans la notation ASN.1.
Les formulaires PICS (déclaration de conformité d’implémentation de protocole) sont fournis en Annexe B.
L’Annexe C comprend une représentation graphique de la structure des données de contexte de péage.
Les Annexes D, E et F contiennent des informations et des descriptions supplémentaires pouvant aider à
mieux comprendre et implémenter les règles spécifiées dans la présente partie de l’ISO 17575.
L’Annexe G fournit des informations sur la manière dont la présente partie de l’ISO 17575 peut être
utilisée dans un environnement de Service Européen de Télépéage (SET), en référence à la Décision de
l’UE 2009/750.
2 Références normatives
Les documents ci-après, dans leur intégralité ou non, sont des références normatives indispensables à
l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 612, Véhicules routiers — Dimensions des automobiles et véhicules tractés — Dénominations et définitions
ISO 1176, Véhicules routiers — Masses — Vocabulaire et codes
ISO 4217, Codes pour la représentation des monnaies
ISO/IEC 8824-1:2008, Technologies de l’information — Notation de syntaxe abstraite numéro un (ASN.1):
spécification de la notation de base — Partie 1 (disponible en anglais seulement)
ISO/IEC 8825-2:2008, Technologies de l’information — Règles de codage ASN.1: spécification des règles de
codage compact (PER) — Partie 2 (disponible en anglais seulement)
ISO 12813:2015, Perception du télépéage — Communication de contrôle de conformité pour systèmes
autonomes
ISO 14906:2011/Amd1:2015, Perception du télépéage — Définition de l’interface d’application relative aux
communications dédiées à courte portée
ISO 17575-1:2016, Perception du télépéage — Définition de l’interface d’application pour les systèmes
autonomes — Partie 1: Imputation
EN 15509:2014, Perception de télépéage — Profil d’application d’interopérabilité pour 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 (disponible en anglais seulement)
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
3.1
péage de zone
péage basé sur l’utilisation du réseau routier dans une zone donnée
[SOURCE: ISO 17575-1:2016, 3.1]
3.2
attribut
paquetage de données adressable constitué d’un seul élément de données ou de séquences structurées
d’éléments de données
[SOURCE: ISO 17575-1:2016, 3.2]
3.3
authentificateur
données (pouvant être chiffrées) qui sont utilisées à des fins d’authentification
[SOURCE: EN 15509:2014, 3.3]
2 © ISO 2016 – Tous droits réservés

3.4
système central
partie du système de back-office assurant l’interface avec un ou plusieurs systèmes frontaux (3.11)
[SOURCE: ISO 17575-1:2016, 3.4]
3.5
objet de facturation
objet géographique ou routier dont l’utilisation est facturée
[SOURCE: ISO 17575-1:2016, 3.5]
3.6
rapport d’imputation
document contenant des informations sur l’usage du réseau routier et des informations provenant du
système frontal (3.11)
[SOURCE: ISO 17575-1:2016, 3.6]
3.7
cordon
ligne fermée entourant une zone définie
[SOURCE: ISO 17575-1:2016, 3.7]
3.8
péage de cordon
péage lié au franchissement d’un cordon (3.7)
[SOURCE: ISO 17575-1:2016, 3.8]
3.9
élément de données
informations codées pouvant se composer de structures d’informations de niveau inférieur
[SOURCE: ISO 17575-1:2016, 3.9]
3.10
ensemble de données
ensemble logique d’éléments de données (3.9) ayant une relation sémantique
Note 1 à l’article: à l’Article L’ensemble de données est uniquement utilisé pour une meilleure compréhension et
est entièrement indépendant des solutions d’implémentation.
3.11
système frontal
partie d’un système de péage composé d’une unité embarquée (OBU) (3.13) et éventuellement d’un
proxy (3.14) où les informations de péage routier et les données d’utilisation sont collectées et traitées à
des fins de livraison au système central (3.4)
Note 1 à l’article: à l’Article Le système frontal comporte l’équipement embarqué (3.13) et un proxy (3.14) facultatif.
3.12
configuration
description technique de la localisation des objets de péage, y compris leurs limites
3.13
équipement embarqué
OBE (On-Board Equipment)
équipement situé à bord d’un véhicule ayant la capacité d’échanger des informations avec des
systèmes externes
3.14
proxy
composant facultatif d’un système frontal (3.11) qui permet de communiquer avec un équipement
externe et de traiter les données reçues dans un format convenu afin de les transmettre au système
central (3.4)
[SOURCE: ISO 17575-1:2016, 3.13]
3.15
tarification de portion routière
principe de péage selon lequel une redevance doit être payée si des portions routières prédéfinies
sont empruntées
[SOURCE: ISO 17575-1:2016, 3.14]
3.16
péage
frais, taxes ou redevances perçu(e)s dans le cadre de l’utilisation d’un véhicule dans un domaine de
péage (3.20)
[SOURCE: ISO/TS 19299:2015, 3.42]
Note 1 à l’article: à l’Article Cette définition généralise la définition classique selon laquelle un péage correspond
à une redevance permettant de franchir une barrière ou une route, un pont, etc. La définition ci-dessus inclut
également les redevances considérées comme obligations administratives, telles que les taxes et les impôts.
3.17
zone à péage
zone géographique pour laquelle un péage (3.16) est applicable pour l’utilisation du réseau routier
3.18
contexte de péage
vue logique telle que définie par des attributs (3.2) et fonctions d’éléments de base d’un plan de péage,
incluant un principe de péage de base, une répartition spatiale des objets de facturation (3.5) et un
comportement unique du système frontal (3.11) associé
[SOURCE: ISO 17575-1:2016, 3.17]
3.19
données de contexte de péage
informations définies par le percepteur de péage en charge, qui sont nécessaires pour établir la
redevance associée à l’utilisation d’un véhicule dans un contexte de péage (3.18) spécifique et conclure
la transaction de péage (3.16)
[SOURCE: ISO 12855:2015, 3.15]
3.20
domaine de péage
zone ou partie d’un réseau routier dans laquelle un régime de péage (3.21) s’applique
[SOURCE: ISO 17573:2010, 3.18]
3.21
régime de péage
ensemble des règles, y compris de contrôle-sanction, applicable au recouvrement des péages (3.16) dans
un domaine de péage (3.20)
[SOURCE: ISO 17573:2010, 3.20]
3.22
plan de péage
vue organisationnelle d’un régime de péage (3.21) incluant les acteurs et leurs relations
4 © ISO 2016 – Tous droits réservés

4 Abréviations
Pour les besoins du présent document, les termes suivants s’appliquent.
ADU (Application Data Unit) Unité de données d’application (ISO 14906)
ASN.1 (Abstract Syntax Notation one) Notation de syntaxe abstraite numéro un (ISO/
IEC 8824-1)
CCC (Compliance Check Communication) Communication de contrôle de conformité (ISO 12813)
CN (Cellular Network) Réseau cellulaire
DSRC (Dedicated short-range communica- Communications dédiées à courte portée (ISO 14906)
tion)
DST (Daylight Saving Time) Heure d’été
EFC (Electronic Fee Collection) Perception du télépéage (ISO 14906)
GDF (Geographic Data Files) Fichiers de données géographiques (ISO 14825)
GNSS (Global Navigation Satellite System) Système mondial de navigation par satellite
HOT (High Occupancy Tolling) Péage lié au taux d’occupation élevé des véhicules
ID Identifiant
OBE (On-Board Equipment) Equipement embarqué
PICS (Protocol Implementation Conformance Déclaration de conformité d’implémentation de protocole
Statement)
UTC (Coordinated Universal Time) Temps universel coordonné
TVA Taxe sur la valeur ajoutée
5 Concept général et présentation
Pour qu’un système frontal fonctionne correctement de manière autonome dans un domaine de péage,
un ensemble spécifique d’éléments de données contenant des données d’application doit être disponible
dans le système frontal. Ces éléments de données doivent contenir une description des règles qui
s’appliquent dans le domaine de péage. Cette description inclut des informations relatives aux tarifs,
aux classes de véhicules, aux objets de facturation, etc.
Les éléments de données peuvent être mis à disposition du système frontal à l’aide des services de
communication décrits dans la norme ISO 17575-2:2016.
Pour transférer les données, une unité de données d’application (ADU) est définie, contenant un en-tête
(incluant principalement des informations sur l’identification et la gestion des données) et un champ de
données (incluant les éléments de données d’application).
L’en-tête de l’ADU permet d’identifier l’émetteur et le destinataire des données. Il contient également
des informations relatives au contexte de péage auquel les données d’application se rapportent. Enfin,
l’en-tête de l’ADU comporte un numéro de séquence.
La présente partie de la norme ISO 17575 s’appuie sur l’hypothèse qu’un plan de péage peut être
constitué de plusieurs parties. Les exigences de la présente partie de l’ISO 17575 concernant les données
soutiennent ce concept. En outre, des systèmes frontaux peuvent être utilisés dans plus d’un plan de
péage. Dans ces cas, le système frontal peut être en mesure de gérer plusieurs ensembles d’éléments de
données de contexte de péage (un par plan de péage). Voir Figure 2.
Anglais Français
Context Data of Toll Scheme A Données du contexte du plan de péage A
Context Overview Présentation du contexte
Tariff Information Informations tarifaires
Context Layout Configuration du contexte
Toll Regime Reporting Rules Règles de génération de rapports du régime de péage
Toll Context ID: n ID du contexte de péage: n
Context Data of Toll Scheme B Données du contexte du plan de péage B
Toll Context ID: m ID du contexte de péage: m
Context Data of Toll Scheme Z Données du contexte du plan de péage Z
Toll Context ID: p ID du contexte de péage: p
Front end Système frontal
Figure 2 — Structure logique des descriptions de contexte de péage dans un système frontal
Il se peut qu’un système frontal soit limité à un nombre maximal de contextes de péage. Ce nombre
peut varier selon la taille de la mémoire, la complexité des données de contexte de péage et l’utilisation
prévue du système frontal. Certains systèmes frontaux peuvent également être conçus de manière à
prendre en charge la description de contexte pour un seul plan de péage spécifique. D’autres peuvent
être conçus pour prendre en charge des descriptions de contexte pour plusieurs plans de péage.
Les données du contexte sont structurées en ensembles de données logiques (voir 8.3). La Figure 3
présente ces ensembles de données et le type d’information associé à chaque ensemble de données.
Chaque ensemble de données contient un ou plusieurs attributs EFC. Les attributs EFC contiennent les
données d’application. Ils sont définis dans l’Article 8.
6 © ISO 2016 – Tous droits réservés

Anglais Français
Context Data Données du contexte
Context Overview Présentation du contexte
- Toll context identification - Identification du contexte de péage
- Toll context structure (partitions) - Structure du contexte de péage (divisions)
- Liable vehicle classes - Classes de véhicule concernées
- Type of toll context - Type de contexte de péage
- Operational status - Statut opérationnel
- Time zone - Fuseau horaire
Reporting Rules Règles de génération de rapports
- Reporting events - Événements de génération de rapports
- Content of the charge report - Contenu du rapport d’imputation
Tariff Information Informations tarifaires
- Vehicle class definitions - Définitions de classes de véhicules
- Time class definitions - Définitions de classes temporelles
- User class definitions - Définitions de classes d’usagers
- Tariff class definitions - Définitions de classes tarifaires
- Tariff table - Table tarifaire
Context Layout Configuration du contexte
- Layout description for section, area, cordon and - Description de configuration pour plans de portion,
road objects schemes de zone, de cordon et d’objets routiers
Figure 3 — Présentation des données du contexte
Un plan de péage unique (et les données de contexte de péage associées) peut être divisé en plusieurs
parties. Chaque partie du plan de péage peut être d’un type de péage différent (tarification de portion,
péage de zone et péage de cordon), peut avoir sa propre configuration et, en conséquence, peut exiger
des données de contexte de péage différentes. La présente partie de l’ISO 17575 soutient ce concept au
moyen de ce qu’elle appelle des divisions de contexte de péage. Les détails sont spécifiés dans l’Article 8.
L’organisation de la mémoire et la structure physique des données au sein d’un système frontal n’entrent
pas dans le cadre de la présente partie de la norme ISO 17575.
6 Exigences procédurales et règles de codage
6.1 Généralités
Le présent article spécifie les exigences normatives concernant
— les services de communication à appliquer à l’échange des données du contexte,
— les dispositions de la présente partie de l’ISO 17575 pour permettre le contrôle des versions et de la
validité des données du contexte, et
— les règles de codage à appliquer aux données du contexte.
6.2 Services de communication
Pour transférer les ADU du système central au système frontal, les services de communication définis
dans l’ISO 17575-2:2016 ou tout autre service de communication approprié peuvent être utilisés.
NOTE 1 En règle générale, les détails concernant les services de communication sont convenus entre les
entités opérationnelles du système central et du système frontal.
NOTE 2 Des structures de communication de pointe (appelées intergiciels) conçues pour l’échange de données
entre systèmes informatiques et sous-systèmes sont des solutions candidates appropriées.
6.3 Gestion des versions et de la validité
6.3.1 Contrôle de version du protocole
Pour chaque soumission de données de contexte de péage au système frontal, le système central doit
fournir la définition de l’interface d’application (syntaxe et sémantique) utilisée par le système central
au moyen de protocolVersion.
Les informations protocolVersion doivent être incluses dans l’en-tête ADU du message. La
spécification des informations protocolVersion est indiquée dans le Paragraphe 7.4 et l’Annexe A.2.
Si le système frontal récepteur ne prend pas en charge la définition d’interface d’application (indiquée
par protocolVersion) demandée par le système central, il doit lui renvoyer une réponse négative.
NOTE L’ID ISO/TS 17575-3:2011 ne reconnaît pas la gestion des versions des définitions d’interface
d’application au moyen de protocolVersion.
6.3.2 Contrôle de version des données du contexte
Chaque attribut EFC inclut un élément de données facultatif, qui comprend des informations sur sa version
et sa validité. Cet élément de données doit toujours être du type de données VersionAndValidity.
Ce type de données doit inclure deux éléments de données:
— version;
— validFrom.
L’élément de données version doit indiquer le numéro de version de l’attribut EFC correspondant. Le
type de données doit être VersionId, tel que défini dans l’ISO 17575-1:2016. Les numéros de version
doivent être utilisés dans l’ordre croissant.
NOTE 1 Ce concept permet au système frontal de détecter de manière autonome les versions manquantes des
données du contexte. Le cas échéant, il lance une action visant à mettre à jour les informations concernées sur le
système frontal.
8 © ISO 2016 – Tous droits réservés

L’élément de données validFrom doit indiquer la date et l’heure de début de validité de l’attribut EFC
correspondant. Le type de données doit être GeneralizedTime, tel que défini dans la norme
ISO 14906:2011/Amd1:2015.
Les informations relatives à la version et à la validité des attributs EFC permettent au système frontal de
détecter de manière autonome l’existence de données du contexte mises à jour dans le système central.
NOTE 2 Lorsque la date et l’heure de début de validité des données du contexte sont atteintes, les versions
antérieures (celles ayant un numéro de version inférieur au numéro en cours) deviennent obsolètes. Le système
frontal peut décider (selon les paramètres locaux) d’initier l’activation des données du contexte valides et la
désactivation (et suppression) des éventuelles versions antérieures.
Les informations fournies sur la version et la validité doivent être exclusivement valides pour
l’attribut EFC auquel elles sont associées.
NOTE 3 Ce concept permet d’utiliser de manière efficace les différentes versions pour plusieurs types de
données du contexte. Par exemple, la version de la table tarifaire peut être gérée indépendamment de la version
valide pour la configuration du contexte et les règles de génération de rapports. Cela permet de réduire la
quantité de données à mettre à jour.
NOTE 4 Le processus de mise à jour en lui-même n’entre pas dans le cadre de la présente partie de l’ISO 17575.
L’élément de données facultatif tollContextVersion doit être utilisé pour identifier la version de
la description complète du contexte de péage. Cet élément de données est un composant du type de
données Iso17575-3AduBody. Le type de données doit être Int1.
NOTE 5 Les exigences opérationnelles spécifiques et la solution d’implémentation déterminent si oui ou
non, et comment, l’identification de la version de contexte est composée à l’aide des informations de version
des attributs et des éléments de données sous-jacents (ex: définitions des classes de véhicules, description de
la configuration, événements de génération de rapport d’imputation, configuration des rapports d’imputation,
définition des tarifs).
NOTE 6 L’identification de la version de contexte peut par exemple être utilisée pour la communication de
contrôle de conformité (CCC) et l’échange de données associé. La norme ISO 12813:2015 spécifie un identifiant
de version du contexte (également du type Int1) qui peut être fourni par le système frontal au système de
contrôle. Grâce à ces données, un simple contrôle permet d’identifier les systèmes frontaux, dans les processus
d’application, qui utilisent une version périmée de la description du contexte de péage.
6.4 Règles de codage
Les types de données et le codage associé liés aux éléments de données décrits dans les Articles 7 et 8
sont définis à l’aide de la technique de notation de syntaxe abstraite numéro un (ASN.1) conformément
à l’Annexe A de la norme ISO/IEC 8824-1.
Les règles de codage (par ex. règles de codage de base, condensées ou XML, BER, PER ou XER) ne sont pas
spécifiées dans la présente partie de la norme ISO 17575 car l’implémentation physique de l’interface
ISO 17575 peut varier considérablement. En conséquence, le choix des règles de codage doit être adapté
aux besoins spécifiques (par exemple, efficacité du codage, compatibilité avec les environnements
logiciels existants, etc.).
6.5 Confirmation et comportement en cas d’erreur
L’interface entre le système frontal et le système central se trouve dans le domaine de l’entité agissant
en tant que prestataire de services de péage. En conséquence, on peut se trouver dans le cas où cette
interface n’est pas nécessairement interopérable.
Pour préserver la liberté et la flexibilité pour les options d’implémentation existantes et futures, et
éviter les exigences excessives du seul domaine d’une entité conceptrice, la présente partie de la norme
ISO 17575 ne comprend aucune exigence concernant les confirmations et le comportement en cas
d’erreurs. L’entité qui conçoit cette interface doit en principe prendre les dispositions nécessaires pour
assurer sa fiabilité et sa stabilité, ainsi que pour la transmission des données de contexte de péage dans
toutes les conditions possibles.
7 Unités de données d’application
7.1 Généralités
Le présent article spécifie les exigences normatives concernant les informations utilisées pour gérer
l’échange de données de contexte de péage. Pour fournir les informations de gestion d’interface
adéquates au récepteur, ces données sont mises à disposition, en plus des données de contexte de
péage, dans un en-tête de protocole dédié (voir 7.3). L’en-tête consiste en divers éléments de données,
comme spécifié au 7.4 ci-dessous. Les données du contexte sont considérées comme la « charge utile »
de l’échange de données, et sont mises à disposition dans le champ ADU (voir 7.3 et 7.5).
7.2 Authentification des messages (type de données Iso17575-3-InformationContent)
Pour assurer une chaîne de confiance ininterrompue, des mécanismes de sécurité sont implémentés
pour prouver l’authenticité et l’intégrité des unités de données d’application transmises.
Pour la prise en charge des entiers et de la transmission sécurisée des données de contexte de péage
du système central au système frontal, des mécanismes d’authentification facultatifs qui peuvent être
utilisés par les entités impliquées ont été introduits.
En conséquence, et selon l’utilisation qui est faite de l’authentification facultative, le contenu des
informations est soit
— une unité de données d’application non authentifiée (notAuthenticatedIso17575-3Adu
de type Iso17575-3Adu); soit
— une unité de données d’application authentifiée (authenticatedIso17575-3Adu de type
AuthenticatedIso
...