ISO 17575-1:2016

INTERNATIONAL ISO
STANDARD 17575-1
First edition
2016-01-15
Electronic fee collection —
Application interface definition for
autonomous systems —
Part 1:
Charging
Perception du télépéage — Définition de l’interface d’application pour
les systèmes autonomes —
Partie 1: Imputation
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 .v
Introduction .vi
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 3
4 Abbreviated terms . 5
5 Architectural considerations . 5
5.1 Business architecture . 5
5.2 Technical architecture . 6
5.3 Location of the specification interface . 7
6 Procedural requirements . 8
6.1 General . 8
6.2 Toll collection process . 8
6.3 Charge report . 8
6.4 Charge report response . 9
7 Data elements . 9
7.1 Overview of data elements . 9
7.2 Reporting .10
7.2.1 ChargeReport .10
7.2.2 ChargeReportResponse .11
7.3 Data group General.11
7.3.1 timeOfReport .11
7.3.2 reportPeriod .11
7.3.3 sumVatForThisSession .12
7.3.4 chargeReportCounter .12
7.3.5 mileage .12
7.3.6 Distance .12
7.3.7 Position .12
7.3.8 Period .12
7.3.9 Duration.13
7.4 Data group Security .13
7.4.1 AuthenticatedChargeReport .13
7.4.2 AuthenticatedChargeReportResponse .13
7.4.3 AuthenticatedUsageStatement .13
7.4.4 AuthenticatedReloadAccount .13
7.4.5 AuthenticatedNewAccountLimit . .14
7.4.6 AuthenticatedAddToAccount .14
7.4.7 MessageAuthenticator .14
7.4.8 MacMessageAuthenticator .14
7.4.9 MessageAuthenticatorEfc .14
7.5 Data group Contract .14
7.5.1 obeId .14
7.5.2 vehicleLPNr .15
7.5.3 paymentMeans .15
7.5.4 serviceProviderContract .15
7.5.5 tollContext .15
7.5.6 chargeReportFinalRecipient .15
7.5.7 obeStatusForDriver .15
7.5.8 ObeStatus .16
7.5.9 chargeReportRespSender .16
7.6 Data group Usage .16
7.6.1 usageStatementList .16
7.6.2 UsageStatement .16
7.6.3 usageStatementID .17
7.6.4 aggregatedFee .17
7.6.5 aggregatedSingleTariffClassSession .17
7.6.6 currentTariffClass .18
7.6.7 VehicleDescription .18
7.6.8 listOfChargeObjects and DetectedChargeObject .18
7.6.9 ChargeObjectId .19
7.6.10 ListOfRawUsageData, measuredRawData .19
7.6.11 NmeaData . .19
7.6.12 additionalGnssData .20
7.6.13 ListOfDSRCUsageData .20
7.6.14 additionalUsageInformation .21
7.6.15 DataReceived .21
7.7 Data group Account .21
7.7.1 accountStatus .21
7.7.2 accountUpdate .21
7.7.3 reloadAccount .22
7.7.4 setAccount .22
7.7.5 addToAccount .22
7.8 Data group Versioning .22
7.8.1 protocolVersion.22
7.8.2 versionInfo .22
7.8.3 versionResponse .23
7.9 Data group Compliance Checking — listOfCCCAttributes and CCCAttributes .23
Annex A (normative) Data type specifications .24
Annex B (normative) Protocol implementation conformance statement (PICS) proforma .25
Annex C (informative) Hierarchical data structure illustration .33
Annex D (informative) Use of this part of ISO 17575 for the EETS .36
Bibliography .38
iv © ISO 2016 – All rights reserved

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-1 cancels and replaces ISO/TS 17575-1:2010, 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;
— adoption of security prescriptions previously located in other standards for specification of
authenticated data structures;
— editorial and formal corrections as well as changes to improve readability.
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.
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 like bridges and tunnels, distance-
based charging and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-
area technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Networks (CN). These
EFC systems are referred to by a variety of names. In addition to the terms autonomous systems and
GNSS/CN systems, the terms GPS/GSM systems and wide-area charging systems are also in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such
as gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map
containing the charged geographic objects, such as charged roads or charged areas. From the charged
objects, the vehicle characteristics, the time of day and other data that are relevant for describing road
use, the tariff and ultimately the road usage fee are determined.
Two strengths of the autonomous approach to electronic fee collection are its flexibility, allowing
the implementation of almost all conceivable charging principles, and its independence from local
infrastructure, thereby predisposing this technology towards interoperability across charging systems
and countries. Interoperability can only be achieved with clearly defined interfaces, which is the aim
and justification of ISO 17575.
0.2 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 this part of
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.3 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 (depending on 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,
vi © ISO 2016 – All rights reserved

— 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 toll service provider to the toll charger for the
data originated from the Front End.
INTERNATIONAL STANDARD ISO 17575-1:2016(E)
Electronic fee collection — Application interface definition
for autonomous systems —
Part 1:
Charging
1 Scope
This part of ISO 17575 defines the format and semantics of the data exchange between a Front End
(OBE plus optional proxy) and corresponding Back Ends in autonomous toll schemes. It defines the data
elements that are used to generate charge reports containing information about the road usage of a
vehicle for certain time intervals, sent from the Front End to the Back End. It also defines the data that
can be used to re-configure the ongoing process of gathering charge relevant information in the Front
End. The scope is shown in Figure 1.
The constitution of the charge report is dependent on configuration data that are assumed to be present
in the Front End. The assembly of charge reports can be configured for each individual toll scheme
according to local needs. Charge reports generated in accordance with this part of ISO 17575 are
consistent with the requirements derived from the architectural concept defined in ISO 17573:2010.
The definitions in this part of ISO 17575 comprise
— reporting data, i.e. data for transferring road usage data from Front End to Back End, including a
response from the Back End towards the Front End,
— data for supporting security mechanisms,
— contract data, i.e. data for identifying contractually essential entities,
— road usage data, i.e. data for reporting the amount of road usage,
— account data for managing a payment account,
— versioning data, and
— compliance checking data, i.e. data imported from ISO 12813:2015, which are required in compliance
checking communication.
Annex A contains the data type specifications 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 data elements described in Clause 7.
Annex D provides information on how this part of ISO 17575 can be used in EETS environment and how
the requirements that are specified in the EU-Decision 2009/750 are addressed by this standard.
Figure 1 — Scope of ISO 17575-1
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 6709:2008, Standard representation of geographic point location by coordinates
ISO/IEC 8824-1, 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/IEC 9594-8:2014, Information technology — Open Systems Interconnection — The Directory —
Part 8: Public-key and attribute certificate frameworks
ISO 12813:2015, Electronic fee collection— Compliance check communication for autonomous systems
ISO 13141:2015, Electronic fee collection— Localisation augmentation communication for autonomous
systems
ISO 14906:2011/Amd1:2015, Electronic fee collection — Application interface definition for dedicated
short-range communication
ISO 17573:2010, Electronic fee collection — Systems architecture for vehicle-related tolling
2 © ISO 2016 – All rights reserved

ISO 17575-3:2016, Electronic fee collection— Application interface definition for autonomous systems—
Part 3: Context data
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
IETF RFC 5035:2007-08, Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
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
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data elements
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.12)
3.5
charge object
geographic or road related object for the use of which a charge is applied
3.6
charge report
information containing road usage and related information originated at the Front End (3.12)
3.7
cordon
border line of an area
3.8
cordon charging
charging for the crossing of a cordon (3.7)
3.9
data element
coded information, which might itself consist of lower level information structures
3.10
data group
class of closely related attributes (3.2)
3.11
toll cluster
group of toll schemes operating under a common agreement providing interoperability for road users
having a contract with a toll service provider being part of the cluster
3.12
Front End
part of a tolling system consisting of an OBE and possibly a proxy (3.13) 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]
3.13
proxy
optional part of a Front End (3.12) that communicates with external equipment and processes the data
received into an agreed format to be delivered to the Back End (3.4)
3.14
road section charging
tolling principle where the fee is due if predefined sections of roads are used
3.15
tariff modifier
four classes (vehicle class, time class, user class and location class) on which the tariff depends for a
given road usage
3.16
toll
charge, tax or duty levied in connection with using a vehicle in a toll domain (3.19)
[SOURCE: ISO/TS 19299:2015, 3.42, modified — “any” has been deleted from before “charge”.]
3.17
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.12)
3.18
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.17) and to conclude the toll transaction
[SOURCE: ISO 12855:2015, 3.15]
3.19
toll domain
area or a part of a road network where a certain toll regime (3.20) is applied
[SOURCE: ISO 17573:2010, 3.18, modified — “certain” has been added.]
3.20
toll regime
set of rules, including enforcement rules, governing the collection of toll (3.16) in a toll domain (3.19)
[SOURCE: ISO 17573:2010, 3.20]
3.21
transaction
whole of the exchange of information between two physically separated communication facilities
3.22
transaction model
functional model describing the structure of electronic payment transactions
[SOURCE: ISO 14906:2011, 3.25, modified — “fee collection” has been deleted.]
4 © ISO 2016 – All rights reserved

4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply unless otherwise specified.
ADU Application data unit (ISO 14906)
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
CCC Compliance check communication (ISO 12813)
CN Cellular network
DSRC Dedicated short-range communication (ISO 14906)
EFC Electronic fee collection (ISO 14906)
LAC Localisation augmentation communication (ISO 13141)
GNSS Global Navigation Satellite System
GPS Global positioning system
GSM Global system for mobile communications
HMI Human-machine interface
MAC Message authentication code
OBE On-board equipment
PICS Protocol implementation conformance statements
RSE Roadside equipment (ISO 14906)
VAT Value added tax
5 Architectural considerations
5.1 Business architecture
This clause deals with the complete ISO 17575-series, i.e. ISO 17575-1 to ISO 17575-3.
The definitions of ISO 17575 are relevant not only for interoperable EFC (as described below) but for all
possible autonomous EFC schemes.
ISO 17575 complies with the business architecture defined in ISO 17573:2010. According to this
architecture, the toll charger is the provider of the road infrastructure and, hence, the recipient of the
road usage charges. The toll charger is the actor associated with the toll charging role (see Figure 2).
As defined in ISO 17573:2010, the role of the toll charger includes the provision of the toll context data.
The ISO 17575 concept defines a one-to-one relationship between toll charger ID and toll context.
Therefore, it is justified to use the data type provider, as defined in ISO 14906:2011/Amd1:2015,
Annex A, to identify a toll context. If a toll charger operates more than one toll scheme, separate
identifiers shall be applied for in the central registry as defined in ISO 14906:2011/Amd1:2015.
Figure 2 — The role-based model underlying ISO 17575
Toll service providers issue OBE to the users of the road infrastructure. Toll service providers are
responsible for operating OBE that will record the amount of road usage in all toll charging systems the
vehicle passes through and for delivering the charging data to the individual toll chargers. In general,
each toll service provider delivers charging data to several toll chargers, and, in general, each toll
charger receives charging data from more than one toll service provider. Interoperability management,
as shown in Figure 2, comprises all specifications and activities that define and maintain a set of rules
that govern the overall toll charging environment.
5.2 Technical architecture
The technical architecture shown in Figure 3 is independent of any particular practical realization.
It reflects the fact that some processing functionalities can either be allocated to the OBE or to an
associated off-board component (proxy). An example of processing functionality that can be realized
either on- or off-board is map-matching, where the vehicle locations in terms of measured coordinates
from GNSS are associated to geographic objects on a map that either resides on- or off-board. Also, tariff
determination can be done with OBE tariff tables and processing, or with an off-board component.
6 © ISO 2016 – All rights reserved

Figure 3 — Assumed technical architecture and interfaces
The combined functionality of OBE and proxy is denoted as Front End. A Front End implementation
where processing is predominately on the OBE-side is known as a smart client (or intelligent client,
fat client) or edge-heavy. A Front End where processing is mostly done off-board is denoted as thin-
client or edge-light architecture. Many implementations between the “thin” and “thick” extremes are
possible, as depicted by the gradual transition in the wedges in Figure 3. Both extremes of architectural
choice have their merits and are one area where manufacturers compete with individual allocations of
functionality between on-board and central resources.
NOTE Especially for thin, but also for smart client, OBE manufacturers might devise a wide variety of
optimizations of the transfer of charge data between OBE and off-board components, where proprietary
algorithms are used for data reduction and data compression.
5.3 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 3). For every toll regime, the Back End shall send toll context data,
i.e. a description of the toll regime in terms of charge objects, charging rules and, if required, the tariff
scheme to the Front End, and shall receive usage data from the Front End.
It also has to be noted that the distribution of tasks and responsibilities between toll 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 toll 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.
6 Procedural requirements
6.1 General
This part of ISO 17575 is intended to be used in autonomous toll systems set up according to the overall
architecture described in ISO 17573:2010.
It defines the format and semantics of charge reports and charge report responses, which are part of
the end-to-end information flow.
6.2 Toll collection process
On-board equipment (OBE) collects data on the road usage of an individual vehicle. These data are
aggregated and processed regarding their relevance for charging either in the OBE or in a proxy. The
combination of OBE and proxy is referred to as a Front End.
This part of ISO 17575 defines the data required for communicating charge relevant road usage data for
an individual vehicle from the Front End to the Back End. The Front End shall accumulate road usage data
into charge reports and send the charge reports to the Back End. The Back End shall confirm reception
of a charge report (ChargeReport) with a charge report response (ChargeReportResponse).
For supporting an uninterrupted chain of trust this part of ISO 17575 supports the authentication of
several data structures using the following data types:
— AuthenticatedChargeReport;
— AuthenticatedChargeReportResponse;
— AuthenticatedUsageStatement;
— AuthenticatedReloadAccount;
— AuthenticatedNewAccountLimit;
— AuthenticatedAddToAccount.
NOTE The use of and the combination of these data types with their unauthenticated counterparts
are left to agreements between the parties implementing this part of ISO 17575. For example, an
AuthenticatedChargeReport can be combined with an unauthenticated ChargeReportResponse, if this
is considered appropriate under specific circumstances.
6.3 Charge report
All data elements comprising the type ChargeReport are coded as optional (except for the
usageStatementList, which ultimately also contains only optional elements).
For every toll context, the Back End shall send context data to the Front End. Context data is a
description in terms of charge objects, charging rules and, if required, the tariff scheme. The definition
of the context data can be found in ISO 17575-3:2016.
Toll context data defines which data elements shall be present and which shall not. The Back End shall
communicate the toll context data defining the requested charge report contents to the Front End
before the OBE is expected to collect road usage data. Upon reception of toll context data the Front End
shall start to collect, process and accumulate road usage data into charge reports as requested. Toll
context data shall also define upon which events charge reports shall be communicated.
NOTE 1 The charge report content requirements defined by the toll context data allow setting the report
contents as required by the properties of the toll regime. These properties include the basic toll system
types such as
8 © ISO 2016 – All rights reserved

— road section charging (the charge relevant parameter is the sum of the road section lengths or tariff
used by the vehicle),
— area charging (the charge relevant parameter is either the distance driven inside the area or the time
stayed inside the area), and
— cordon charging (the charge relevant parameter is the event of crossing the cordon around an area).
NOTE 2 Depending on local needs, toll chargers may require more or less processed data to varying levels
of detail. Privacy considerations, enforcement approach and legal nature of the charge will also influence the
choices agreed between toll charger and toll service provider regarding the requested contents of charge reports.
Charge reports support
— reporting a list of charge objects that are declared as being used by the vehicle including associated
tariff modifiers; this report may or may not include the calculated fee or tax,
— reports of road usage sessions within a single set of tariff modifiers; this report may or may not
include the calculated fee or tax,
— report of contiguous sessions on a toll road or area where just the aggregated fee and the associated
reference time is reported,
— reports where only the total fee within a predefined report period is forwarded (in this case it is
anticipated that other means, outside the scope of this part of ISO 17575, are used to allow a certain
degree of validation of the charging process), and
— any combination of the reports listed above.
6.4 Charge report response
The Back End shall respond to every received charge report with a charge report response. A description
of which optional elements of the attribute ChargeReportResponse are present is not defined in
this part of ISO 17575.
NOTE The contents of the charge report response depend on the make and type of the Front End and on the
application software of the Front End and Back End as defined by the business requirements of the individual
toll service provider. This part of ISO 17575 only offers data elements for the response but does not impose
restrictions upon the implementation and business choices by requiring mandatory content.
7 Data elements
7.1 Overview of data elements
Data elements are grouped in logical groups for readability only.
The data group Reporting contains the main data elements of the charge report communication. These
elements are the top level, overarching data structures containing all data elements described in this
part of ISO 17575.
The data group General contains data elements and types that are not explicitly part of other groups.
The data group Security contains the data structures necessary for implementing authenticated
exchange of data using security mechanisms.
The data group Contract contains data elements and types related to road user contract information.
The data group Usage contains the information necessary to describe the usage of infrastructure
causing eligibility for fees. These data are necessary for calculating the charges and for setting up
correct bills and for settling disputes. The main data elements of this group present in the charge report
and charge report response are, respectively, usageStatementList and dataReceived.
The data group Account contains the elements necessary to ensure that the correct account (and road
user) is charged with the toll fees. The elements in the group account are used for managing road user
accounts in the Front End. These Front End accounts can contain the following types of data:
— credit: the account holds a value corresponding to a monetary amount;
— distance: the account holds a value representing a distance;
— time: the account holds a value representing a point in time;
— duration: the account holds a value representing time duration;
— event: the account holds a value representing a number of events.
The main data elements of this group present in the charge report and charge report response are,
respectively, accountStatus and accountUpdate.
NOTE The kind of event counted in the respective option of the account data type is left to the implementation.
The data group Versioning contains data elements for version control of elements on the OBE.
The data group Compliance Checking provides information exchanged in compliance checking
communication (CCC), as defined in ISO 12813:2015. Some of the data exchanged by CCC are already
covered by other data elements, but for complete information about the content of CCC the data in this
group are necessary.
7.2 Reporting
The two data types ChargeReport and ChargeReportResponse described in 7.2.1 and 7.2.2 cover
the complete charge report communication.
7.2.1
...

NORME ISO
INTERNATIONALE 17575-1
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 1:
Imputation
Electronic fee collection — Application interface definition for
autonomous systems —
Part 1: Charging
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 .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 3
4 Abréviations . 5
5 Considérations architecturales . 6
5.1 Architecture commerciale . 6
5.2 Architecture technique . 7
5.3 Emplacement de l’interface de spécification . 8
6 Spécifications relatives aux procédures . 8
6.1 Généralités . 8
6.2 Perception du péage . 8
6.3 Rapport de perception . 9
6.4 Réponse à un rapport de perception .10
7 Eléments de données .10
7.1 Vue d’ensemble des éléments de données .10
7.2 Etablissement de rapports .11
7.2.1 ChargeReport (rapport de perception) .11
7.2.2 ChargeReportResponse (réponse au rapport de perception) .12
7.3 Groupe de données Général .12
7.3.1 timeOfReport (date et heure du rapport) .12
7.3.2 reportPeriod (période du rapport) .12
7.3.3 sumVatForThisSession (TVA pour cette session) .12
7.3.4 chargeReportCounter (compteur de rapport de perception) .13
7.3.5 mileage (kilométrage) .13
7.3.6 Distance .13
7.3.7 Position .13
7.3.8 Period (période) .13
7.3.9 Duration (durée) .13
7.4 Groupe de données Sécurité .14
7.4.1 AuthenticatedChargeReport (rapport de perception authentifié) .14
7.4.2 AuthenticatedChargeReportResponse (réponse au rapport de
perception authentifié) .14
7.4.3 AuthenticatedUsageStatement (déclaration d’utilisation authentifiée) .14
7.4.4 AuthenticatedReloadAccount (recharge du compte authentifié) .14
7.4.5 AuthenticatedNewAccountLimit (limite de compte nouveau authentifiée) .14
7.4.6 AuthenticatedAddToAccount (ajout au compte authentifié) .15
7.4.7 MessageAuthenticator (authentifiant de message) .15
7.4.8 MacMessageAuthenticator (authentificateur de message mac) .15
7.4.9 MessageAuthenticatorEfc (EFC d’authentificateur de message) .15
7.5 Groupe de données Contrat .15
7.5.1 obeId (ID de l’OBE) .15
7.5.2 vehicleLPNr (n° d’immatriculation du véhicule) .15
7.5.3 paymentMeans (moyen de paiement) .16
7.5.4 serviceProviderContract (contrat du fournisseur de services) .16
7.5.5 tollContext (contexte de péage) .16
7.5.6 chargeReportFinalRecipient (destinataire final du rapport de perception) .16
7.5.7 obeStatusForDriver (statut de l’OBE pour le conducteur) .16
7.5.8 obeStatus (statut de l’OBE) .17
7.5.9 chargeReportRespSender (expéditeur de la réponse au rapport de perception) 17
7.6 Groupe de données Utilisation .17
7.6.1 usageStatementList (liste des déclarations d’utilisation) .17
7.6.2 UsageStatement (déclaration d’utilisation) .17
7.6.3 usageStatementID (ID de déclaration d’utilisation).18
7.6.4 aggregatedFee (redevance agrégée) .18
7.6.5 aggregatedSingleTariffClassSession (session de classe tarifaire
unique agrégée) .18
7.6.6 currentTariffClass (classe tarifaire actuelle) .19
7.6.7 VehicleDescription (description du véhicule) .19
7.6.8 listOfChargeObjects (liste d’objets d’imputation) et DetectedChargeObject
(objet d’imputation détecté) . .19
7.6.9 ChargeObjectId (ID d’objet d’imputation) .20
7.6.10 ListOfRawUsageData (liste des données d’utilisation brutes),
measuredRawData (données brutes mesurées) .20
7.6.11 NmeaData (données NMEA) .21
7.6.12 additionalGnssData (données GNSS supplémentaires) .22
7.6.13 ListOfDSRCUsageData (liste des données d’utilisation DSRC) .22
7.6.14 additionalUsageInformation (informations supplémentaires
concernant l’utilisation) .22
7.6.15 DataReceived (données reçues) .22
7.7 Groupe de données Compte .23
7.7.1 accountStatus (statut du compte) .23
7.7.2 accountUpdate (mise à jour du compte) .23
7.7.3 reloadAccount (recharge du compte) .23
7.7.4 setAccount (définir le compte) .23
7.7.5 addToAccount (ajout au compte) .24
7.8 Groupe de données Contrôle des versions.24
7.8.1 protocolVersion (version du protocole) .24
7.8.2 versionInfo (informations concernant la version) .24
7.8.3 versionResponse (réponse à la version) .24
7.9 Groupe de données Contrôle de conformité — listOfCCCAttributes (liste des
attributs CCC) et CCCAttributes (attributs CCC) .24
Annexe A (normative) Spécifications des types de données .26
Annexe B (normative) Formulaire de déclarations de conformité d’implémentation de
protocole (PICS).27
Annexe C (informative) Illustration de la structure hiérarchique des données .36
Annexe D (informative) Utilisation de la présente partie de l’ISO 17575 pour le SET .39
Bibliographie .41
iv © ISO 2016 – Tous droits réservés

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 17575-1 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-1:2010), qui fait l’objet
d’une révision technique.
L’ISO 17575 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:2016, 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 de perception relatives à l’utilisation d’une infrastructure routière,
comprenant les péages d’autoroute, les redevances dans certaines zones urbaines, les péages relatifs
à une infrastructure particulière telles que ponts et tunnels, les imputations basées sur la distance
parcourue et les frais de stationnement.
Un OBE autonome fonctionne sans s’appuyer sur une infrastructure dédiée en bord de route en faisant
appel à des technologies à couverture étendue telles que les systèmes mondiaux de navigation par
satellite (GNSS) et les réseaux cellulaires (CN). Ces systèmes EFC ont diverses dénominations. Outre les
termes «systèmes autonomes» et «systèmes GNSS/CN», les termes «systèmes GPS/GSM» et «systèmes
de localisation par satellite» sont également utilisés.
Les systèmes autonomes utilisent la localisation par satellite, souvent combinée à des technologies de
détection supplémentaires telles que des gyroscopes, des odomètres et des accéléromètres, pour localiser
le véhicule et trouver sa position sur une carte contenant les objets géographiques soumis à redevance, tels
que des routes ou des zones soumises à péage. A partir des objets soumis à redevance, des caractéristiques
du véhicule, de l’heure de la journée et d’autres données pertinentes pour décrire l’utilisation du réseau
routier, le tarif et finalement la redevance d’utilisation du réseau routier sont déterminés.
Ces systèmes EFC autonomes présentent une réelle flexibilité permettant d’implémenter presque
tous les principes d’imputation existants et ne dépendent pas de l’infrastructure routière favorisant
l’interopérabilité de cette technologie dans les pays et les systèmes de perception. L’interopérabilité
ne peut être obtenue qu’avec des interfaces clairement définies, ce qui est l’objectif et la justification
de l’ISO 17575.
0.2 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 de perception 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 de perception.
Partie 2: Communications et connexions aux couches basses, définit les services de communication de base
pour le transfert des données sur la liaison aérienne de l’OBE ou entre le système frontal et le système
central. Les données définies dans la présente partie de l’ISO 17575-1 et de 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 la description de chaque système
de perception en termes d’objets géographiques soumis à redevance et de règles d’imputation et
d’établissement de rapports. Pour chaque système de percepteur de péage, les attributs définis dans la
norme ISO 17575-3 sont 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.3 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,
vi © ISO 2016 – Tous droits réservés

— traite des redevances liées à l’utilisation de tronçons de route (y compris ponts, tunnels, passages,
etc.), au franchissement de cordons (entré/sortie) et à l’utilisation d’une infrastructure dans une
zone (distance, temps),
— traite de la perception d’un péage fondée sur des unités de distance ou de durée, et fondée sur
l’occurrence d’événements,
— traite de la modulation des redevances par catégorie de véhicule, catégorie de route, durée
d’utilisation et type de contrat (par exemple véhicules exemptés, véhicules à tarif spécial, etc.),
— traite de la limitation des redevances par un maximum défini par période d’utilisation,
— traite des redevances ayant un statut juridique différent (par exemple taxe publique, péage privé),
— traite des exigences variables des différents percepteurs de péage, notamment en termes de
— descriptions du domaine géographique et du contexte,
— contenu et fréquence des rapports de perception,
— retour d’information au conducteur (par exemple feu vert ou rouge), et
— fourniture de données détaillées supplémentaires sur demande, par exemple pour le
règlement des litiges,
— traite des domaines géographiques de péage se chevauchant,
— traite des adaptations relatives aux changements
— d’infrastructure à péage,
— de tarifs, et
— fait partie de systèmes de péage, et
— traite de la fourniture par le prestataire de services au percepteur de péage de garanties de confiance
pour les données provenant du système frontal.
NORME INTERNATIONALE ISO 17575-1:2016(F)
Perception du télépéage — Définition de l’interface
d’application pour les systèmes autonomes —
Partie 1:
Imputation
1 Domaine d’application
La présente partie de l’ISO 17575 définit le format et la sémantique pour l’échange de données entre
un système frontal (OBE plus proxy optionnel) et des systèmes centraux correspondants dans des
systèmes de péage autonomes. Elle définit les éléments de données utilisés pour générer des rapports
de perception contenant des informations sur l’utilisation du réseau routier par un véhicule pendant
des intervalles de temps donnés, envoyées du système frontal au système central. Elle définit également
les données qui peuvent être utilisées pour reconfigurer le processus de collecte permanente des
informations d’imputation pertinentes dans le système frontal. Son domaine d’application est
représenté à la Figure 1.
La constitution d’un rapport de perception dépend des données de configuration supposées être
présentes dans le système frontal. L’ensemble des rapports de perception peut être configuré pour
chaque système de péage individuel selon les besoins locaux. Les rapports de perception générés
conformément à la présente partie de l’ISO 17575 concordent avec les exigences dérivées du concept
architectural défini dans l’ISO 17573:2010.
Dans la présente partie de l’ISO 17575, les définitions comprennent
— les données des rapports, c’est-à-dire les données permettant de transférer des données d’utilisation
du réseau routier d’un système frontal à un système central, y compris une réponse du système
central au système frontal,
— les données de prise en charge des mécanismes de sécurité,
— les données contractuelles, c’est-à-dire les données permettant d’identifier les entités
contractuellement essentielles,
— les données d’utilisation du réseau routier, c’est-à-dire les données permettant de communiquer
l’utilisation qui est faite du réseau routier,
— les données de compte pour gérer un compte de paiement,
— les données de contrôle des versions,
— les données de contrôle de conformité, c’est-à-dire les données importées de l’ISO 12813:2015, qui
sont requises dans les communications de contrôle de conformité.
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 éléments de données décrits
à l’Article 7.
L’Annexe D fournit des informations sur la façon dont la présente partie de l’ISO 17575 peut être
appliquée dans un environnement SET et sur la manière dont la présente norme couvre les exigences
spécifiées dans la Décision de la Commission 2009/750.
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-1
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).
2 © ISO 2016 – Tous droits réservés

ISO 6709:2008, Représentation normalisée de la localisation des points géographiques par coordonnées
ISO/IEC 8824-1, Technologies de l’information — Notation de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base — Partie 1
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
ISO/IEC 9594-8:2014, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) —
L’annuaire — Partie 8: Cadre général des certificats de clé publique et d’attribut
ISO 12813:2015, Perception du télépéage — Communication de contrôle de conformité pour systèmes
autonomes
ISO 13141:2015, Perception de télépéage — Communications d’augmentation de localisations 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 17573:2010, Perception du télépéage — Architecture de systèmes pour le péage lié aux véhicules
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
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)
IETF RFC 5035:2007-08, Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
(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
3.2
attribut
ensemble de données adressables consistant en un élément de données unique ou des séquences
structurées d’éléments de donnée
3.3
authentifiant
données (pouvant être chiffrées) qui sont utilisées à des fins d’authentification
[SOURCE: EN 15509:2014, 3.3]
3.4
système central
partie du système de back-office assurant l’interface avec un ou plusieurs systèmes frontaux (3.12)
3.5
objet d’imputation
objet géographique ou associé à une route dont l’utilisation est assujettie à une redevance
3.6
rapport de perception
informations contenant l’utilisation du réseau routier et les informations connexes provenant du
système frontal (3.12)
3.7
cordon
ligne délimitant une zone
3.8
péage de cordon
péage lié au franchissement d’un cordon (3.7)
3.9
élément de données
information codée, qui peut elle-même être constituée de structures d’information de niveau inférieur
3.10
groupe de données
classe d’attributs (3.2) étroitement liés
3.11
cluster de péage
groupe de systèmes de péage fonctionnant dans le cadre d’un accord commun assurant
l’interopérabilité pour les usagers de la route ayant un contrat avec un prestataire de services de
péage faisant partie du groupe
3.12
système frontal
partie d’un système de péage composé de l’équipement embarqué (OBE) et éventuellement d’un proxy
(3.13) où les informations de péage et les données d’utilisation sont collectées et traitées à des fins de
livraison au système central (3.4)
[SOURCE: ISO/TS 19299:2015, 3.17]
3.13
proxy
partie optionnelle d’un système frontal (3.12) qui communique avec un équipement externe et traite les
données reçues dans un format convenu et devant être transmises au système central (3.4)
3.14
tarification de portion routière
principe de péage selon lequel la redevance est due si des sections de routes prédéfinies sont utilisées
3.15
modificateur de tarif
quatre classes (véhicule, temps, usager et lieu) dont dépend le tarif pour un usage donné du réseau routier
3.16
péage
redevance, taxe ou droit prélevé en rapport avec l’utilisation d’un véhicule dans un domaine de péage (3.19)
[SOURCE: ISO/TS 19299:2015, 3.42]
3.17
contexte de péage
vue logique telle que définie par des attributs (3.2) et fonctions d’éléments de base d’un système de
péage, incluant un principe de péage de base, une répartition spatiale des objets d’imputation (3.5) et un
comportement unique du système frontal (3.12) associé
4 © ISO 2016 – Tous droits réservés

3.18
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.17) spécifique et conclure
la transaction de péage
[SOURCE: ISO 12855:2015, 3.15]
3.19
domaine de péage
zone ou tronçon routier où est appliqué un régime de péage (3.20) donné
[SOURCE: ISO 17573:2010, 3.18, modifiée — «donné» a été ajouté.]
3.20
régime de péage
ensemble de règles, y compris les règlements de contrôle sanction, régissant la perception d’un péage
(3.16) dans un domaine de péage (3.19)
[SOURCE: ISO 17573:2010, 3.20]
3.21
transaction
ensemble des échanges d’informations entre deux installations de communication physiquement séparées
3.22
modèle de transaction
modèle fonctionnel décrivant la structure des transactions de paiement électronique
[SOURCE: ISO 14906:2011, 3.25, modifiée — «perception de péage» a été supprimé.]
4 Abréviations
Pour les besoins du présent document, les abréviations suivantes s’appliquent, sauf spécification contraire.
ADU Unité de données d’application (ISO 14906)
ASN.1 Notation de syntaxe abstraite numéro un (ISO/IEC 8824-1)
CCC Communication de contrôle de conformité (ISO 12813)
CN Réseau cellulaire
DSRC Communications dédiées à courte portée (ISO 14906)
EFC Perception du télépéage (ISO 14906)
LAC Communications d’augmentation de localisations (ISO 13141)
GNSS Système mondial de navigation par satellite
GPS Système mondial de localisation
GSM Système mondial de communications mobiles
IHM Interface homme-machine
MAC Code d’authentification de message
OBE Equipement embarqué
PICS Déclaration de conformité d’implémentation de protocole
RSE Equipement en bord de route (ISO 14906)
VAT Taxe sur la valeur ajoutée (TVA)
5 Considérations architecturales
5.1 Architecture commerciale
Le présent article traite de toute la série ISO 17575, c’est-à-dire de l’ISO 17575-1 à l’ISO 17575-3.
Les définitions de l’ISO 17575 s’appliquent non seulement aux systèmes EFC interopérables (décrits ci-
dessous), mais aussi à tous les systèmes EFC autonomes.
L’ISO 17575 est conforme à l’architecture commerciale définie dans l’ISO 17573:2010. Selon cette
architecture, le percepteur de péage est le fournisseur de l’infrastructure routière et donc le bénéficiaire
des redevances d’utilisation du réseau routier. Le percepteur de péage est l’acteur associé au rôle de
perception du péage (voir Figure 2).
Comme le définit l’ISO 17573:2010, le rôle du percepteur de péage prévoit la mise à disposition des
données de contexte de péage. Le concept de l’ISO 17575 définit une relation biunivoque entre l’ID du
percepteur de péage et le contexte de péage. En conséquence, l’utilisation du fournisseur du type de
données tel que défini dans l’ISO 14906:2011/Amd1:2015, Annexe A est justifiée pour identifier un
contexte de péage. Si un percepteur de péage applique plus d’un système de péage, des identifiants
séparés doivent être demandés dans le registre central, tel que défini dans l’ISO 14906:2011/Amd1:2015.
Anglais Français
Interoperability Management Gestion de l’interopérabilité
Service Provision Fourniture du service
Toll Charging Perception du péage
Service Usage Utilisation du service
Figure 2 — Modèle basé sur les rôles servant à l’ISO 17575
Les prestataires de services fournissent un OBE aux utilisateurs de l’infrastructure routière. Les
prestataires de services sont responsables du fonctionnement de l’OBE qui enregistrera l’utilisation
du réseau routier dans tous les systèmes de perception du péage franchis par le véhicule, et de la
transmission des données de perception aux percepteurs de péage individuels. En général, chaque
prestataire de services transmet des données de perception à plusieurs percepteurs de péage, de même
que chaque percepteur de péage reçoit généralement des données de perception provenant de plusieurs
6 © ISO 2016 – Tous droits réservés

prestataires de services. La gestion de l’interopérabilité illustrée dans la Figure 2 inclut toutes les
spécifications et activités qui permettent de définir et de tenir à jour un ensemble de règles régissant
l’environnement de perception du péage.
5.2 Architecture technique
L’architecture technique de la Figure 3 ne dépend d’aucune réalisation pratique en particulier. Elle reflète
le fait que certaines fonctionnalités de traitement peuvent être allouées soit à l’OBE soit à un composant
associé non embarqué (proxy). Un exemple de fonctionnalité de traitement pouvant être réalisée à bord
ou à l’extérieur du véhicule est la corrélation d’images, dans laquelle les positions du véhicule en termes
de coordonnées mesurées par GNSS sont associées à des objets géographiques sur une carte qui réside
à bord ou à l’extérieur du véhicule. La détermination du tarif peut également être effectuée à l’aide de
tables tarifaires et d’un traitement dans l’OBE, ou à l’aide d’un composant non embarqué.
Anglais Français
Scope of ISO 17575 Domaine d’application de l’ISO 17575
Proxy Proxy
OBE OBE
Processing Equipment Equipment de traitement
Front End Système frontal
Back End Système central
Road Usage Data Données d’utilisation du réseau routier
Context Data Données du contexte
Figure 3 — Architecture technique et interfaces supposées
La fonctionnalité combinée de l’OBE et du proxy est appelée système frontal. L’implémentation d’un
système frontal dans lequel le traitement est essentiellement réalisé du côté OBE est connue en tant
que client intelligent (client lourd) ou «edge-heavy». Un système frontal dans lequel le traitement
est essentiellement réalisé à l’extérieur est appelé architecture de clients légers ou «edge-light». De
nombreuses implémentations entre les extrêmes «léger» et «lourd» sont possibles, comme indiqué
par la transition progressive des flèches à la Figure 3. Les deux extrêmes du choix architectural ont
chacun leurs avantages et sont l’un des moyens par lesquels les fabricants se font concurrence par des
allocations individuelles de fonctionnalité entre les ressources embarquées et centrales.
NOTE Dans le cas spécifique des clients légers, mais également des clients intelligents, les fabricants
d’OBE sont amenés à concevoir un large éventail d’optimisations pour le transfert des données d’imputation
entre l’OBE et les composants non embarqués, en utilisant des algorithmes propriétaires pour la réduction et la
compression des données.
5.3 Emplacement 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 3). Pour chaque régime de péage, le système
central doit envoyer des données de contexte de péage (ex: description du régime de péage en termes
d’objets d’imputation, de règles d’imputation et, si nécessaire, de régime tarifaire) au système frontal et
recevoir des données d’utilisation de celui-ci.
Il faut également noter que la répartition des tâches et des responsabilités entre le prestataire de
services de péage et le percepteur de péage variera individuellement. Selon la situation juridique locale,
les percepteurs de péage demanderont des données «plus légères» ou «plus lourdes» et pourraient
ou non laisser certaines tâches de traitement des données aux prestataires de services de péage. Par
conséquent, les définitions de données de l’ISO 17575 peuvent être utiles à 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.
6 Spécifications relatives aux procédures
6.1 Généralités
La présente partie de l’ISO 17575 est destinée à être utilisée dans des systèmes de péage autonomes
configurés conformément à l’architecture globale décrite dans l’ISO 17573:2010.
Elle définit le format et la sémantique des rapports de perception et des réponses aux rapports de
perception qui font partie du flux d’informations de bout en bout.
6.2 Perception du péage
Un équipement embarqué (OBE) collecte des données sur l’utilisation de la route par un véhicule individuel.
Ces données sont agrégées et traitées en ce qui concerne leur pertinence pour le péage, soit dans l’OBE soit
dans un proxy. La combinaison d’un OBE et d’un proxy est désignée en tant que système frontal.
La présente partie de l’ISO 17575 définit les données requises pour que le système frontal communique
au système central les données d’utilisation du réseau routier pertinentes pour le péage pour un
véhicule individuel. Le système frontal doit regrouper les données d’utilisation du réseau routier dans
des rapports de perception et transmettre ceux-ci au système central. Le système central doit confirmer
la réception d’un rapport de perception (ChargeReport) par une réponse au rapport de perception
(ChargeReportResponse).
Pour la prise en charge d’une chaîne de confiance ininterrompue, la présente partie de l’ISO 17575
reconnaît l’authentification de plusieurs structures de données au moyen des types de données suivants:
— AuthenticatedChargeReport;
— AuthenticatedChargeReportResponse;
8 © ISO 2016 – Tous droits réservés

— AuthenticatedUsageStatement;
— AuthenticatedReloadAccount;
— AuthenticatedNewAccountLimit;
— AuthenticatedAddToAccount.
NOTE L’utilisation et la combinaison de ces types de données avec leurs contreparties non authentifiées sont
laissées à l’appréciation des parties qui, en concertation, implémentent la présente partie de l’ISO 17575. Par
exemple, un type AuthenticatedChargeReport peut être combiné avec un type ChargeReportResponse
non authentifié, si cette démarche est considérée comme appropriée en les circonstances.
6.3 Rapport de perception
Tous les éléments de données constituant le type ChargeReport sont codés comme optionnels
(excepté l’élément de données usageStatementList, qui finalement ne contient lui aussi que des
éléments optionnels).
Pour chaque contexte de péage, le système central doit envoyer des données du contexte au système
frontal. Les données du contexte sont une description en termes d’objets d’imputation, de règles
d’imputation et, si nécessaire, de régime tarifaire. La définition des données du contexte peut être
trouvée dans l’ISO 17575-3:2016.
Les données de contexte de péage définissent les éléments de données devant être présents et ceux
ne devant pas être présents. Le système central doit transmettre au système frontal les données de
contexte de péage définissant le contenu du rapport de perception demandé avant que l’OBE ne collecte
les données d’utilisation du réseau routier. A réception des données de contexte de péage, le système
frontal doit commencer à collecter, traiter et accumuler les données d’utilisation du réseau routier dans
des rapports de perception conformes à la demande. Les données de contexte de péage doivent également
définir les événements pour lesquels des rapports de perception d’événement doivent être transmis.
NOTE 1 Les exigences relatives au contenu du rapport de perception définies par les données de contexte de
péage permettent de paramétrer le contenu de rapport comme requis par les propriétés du régime de péage. Ces
propriétés comprennent les types de système de péage de base tels que
— tarification de portion routière (le paramètre pertinent pour le péage est la somme des longueurs de section
de route ou le tarif utilisé par le véhicule),
— péage de zone (le paramètre pertinent pour le péage est soit la distance parcourue dans la zone soit le temps
passé dans la zone), et
— péage de cordon (le paramètre pertinent pour le péage est l’événement de franchissement du cordon
délimitant une zone).
NOTE 2 Selon les besoins locaux, les percepteurs de péage peuvent exiger des données plus ou moins
traitées à des niveaux de détail variables. Les considérations relatives au respect de la vie privée, la méthode de
contrôle-sanction et la nature juridique du péage auront également une incidence sur les choix convenus entre le
percepteur de péage et le prestataire de services
...