ISO 17575-2:2016

DRAFT INTERNATIONAL STANDARD
ISO/DIS 17575-2
ISO/TC 204 Secretariat: ANSI
Voting begins on: Voting terminates on:
2013-12-12 2014-05-12
Electronic fee collection — Application interface definition
for autonomous systems —
Part 2:
Communication and connection to the lower layers
Perception du télépéage — Définition de l’interface d’application pour les systèmes autonomes —
Partie 2: Communications et connexions aux couches plus basses
[Revision of first edition (ISO/TS 17575-2:2010 )]
ICS: 35.240.60;03.220.20
ISO/CEN PARALLEL PROCESSING
This draft has been developed within the International Organization for
Standardization (ISO), and processed under the ISO lead mode of collaboration
as defined in the Vienna Agreement.
This draft is hereby submitted to the ISO member bodies and to the CEN member
bodies for a parallel five month enquiry.
Should this draft be accepted, a final draft, established on the basis of comments
received, will be submitted to a parallel two-month approval vote in ISO and
THIS DOCUMENT IS A DRAFT CIRCULATED
formal vote in CEN.
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
To expedite distribution, this document is circulated as received from the
IN ADDITION TO THEIR EVALUATION AS
committee secretariat. ISO Central Secretariat work of editing and text
BEING ACCEPTABLE FOR INDUSTRIAL,
composition will be undertaken at publication stage.
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 17575-2:2013(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2013

---------------------- Page: 1 ----------------------
ISO/DIS 17575-2:2013(E)

Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as
permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract
from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO’s
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2013 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/DIS 17575-2
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviations . 4
5 EFC Front End communication architecture . 4
5.1 General . 4
5.2 Relations to the overall EFC architecture . 5
6 Initialize transactions . 5
6.1 General . 5
6.2 Addressing requested parts of a hierarchical data element structure . 6
6.3 Identifying payloads for transmission . 6
7 EFC communication services (functions) . 6
7.1 General concept . 6
7.2 Initialization phase . 7
7.2.1 General . 7
7.2.2 Incoming (BE to FE Application) Session Request . 8
7.2.3 Outgoing (FE Application to BE) session establishment . 8
7.3 Point-to-point communication service primitives . 8
7.3.1 General . 8
7.3.2 Unstructured messages (ADUs) . 9
7.3.3 Structured messages (ADUs) . 9
7.4 Session ending . 9
7.5 Session failure . 9
7.6 Security considerations . 9
7.7 Media selection options . 10
8 The use of a communication stack . 10
8.1 General . 10
8.2 Requirements on a underlying communication technology . 10
8.3 Mobile terminated calls . 10
Annex A (normative) Abstract API definition . 11
A.1 General . 11
A.2 Down API (Front End Application to communications stack) . 11
A.2.1 InitialiseInstance . 11
A.2.2 SetParameter . 11
A.2.3 GetParameter . 11
A.2.4 DeleteParameter . 12
A.2.5 StackAvail . 12
A.2.6 DropInstance . 12
A.2.7 StartSession . 12
A.2.8 EndSession . 13
A.2.9 SendUnformattedADU . 13
A.2.10 SendADUSetStart . 13
A.2.11 SendADU . 13
A.2.12 SendADUSetEnd . 14
A.2.13 CommsQuery . 14
iii
© ISO 2013 – All rights reserved

---------------------- Page: 3 ----------------------
ISO/DIS 17575-2
A.3 Up API (Communications Stack to Front End Application).14
A.3.1 InstanceStateChange .14
A.3.2 UnformattedADUReceived .15
A.3.3 ADURequest .15
A.3.4 ADUReceived .15
A.3.5 ADUSent .15
A.3.6 ADUSendOK .15
A.3.7 SessionRequest .15
Annex B (normative) Protocol implementation conformance statement (PICS) proforma .16
B.1 Introduction .16
B.2 Transactions support .16
B.2.1 General .16
B.2.2 Support of the down API .16
B.2.3 Support of the Up API .18
B.3 Use of communication stacks .19
B.3.1 Supported communication stacks .19
B.4 Front End Storage capacity .20
B.4.1 Storage capacity for modules and contact details .20
B.4.2 Generic values .20
B.4.3 Security of communication .20
Annex C (informative) API requirements.21
C.1 Introduction .21
C.1.1 General .21
C.1.2 Non-functional requirements .21
C.1.3 Functional requirements .21
Annex D (informative) Examples of definitions for appropriate languages .22
D.1 General .22
D.2 API Definition in C.22
Annex E (informative) Example of message flow .25
Annex F (informative) Use of this standard for the EETS .26
F.1 General .26
F.2 Overall relationship between European standardisation and the EETS .26
F.3 European standardisation work supporting the EETS .26
F.4 Correspondence between this standard and the EETS .27
Bibliography .28


iv
© ISO 2013 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/DIS 17575-2
Foreword
- conversion from a Technical Specification to an International Standard
- editorial and formal corrections as well as changes to improve readability
- minor technical corrections
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 17575-2 was prepared by Technical Committee ISO/TC 204, Intelligent Transport Systems,
Subcommittee SC , and by Technical Committee CEN/TC 278, Intelligent Transport Systems in collaboration.
This second/third/. edition cancels and replaces the first/second/. edition (), [clause(s) / subclause(s) /
table(s) / figure(s) / annex(es)] of which [has / have] been technically revised.
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
¾ Part 4: Roaming
v
© ISO 2013 – All rights reserved

---------------------- Page: 5 ----------------------
ISO/DIS 17575-2
Introduction
Autonomous systems
This part of ISO 17575 is part of a series of specifications defining the information exchange between the
Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board equipment
(OBE). EFC systems automatically collect charging data for the use of road infrastructure including motorway
tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels, distance-based
charging and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-area
technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Communications Networks
(CN). These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, also the terms GPS/GSM systems, and wide-area charging systems are in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such as
gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map containing
the charged geographic objects, such as charged roads or charged areas. From the charged objects, the
vehicle characteristics, the time of day and other data that are relevant for describing road use, the tariff and
ultimately the road usage fee are determined.
Some of the strengths of the autonomous approach to electronic fee collection are its flexibility, allowing the
implementation of almost all conceivable charging principles, and its independence from local infrastructure,
thereby predisposing this technology towards interoperability across charging systems and countries.
Interoperability can only be achieved with clearly defined interfaces, which is the aim and justification of
ISO 17575.
Business architecture
This part of ISO 17575 complies with the business architecture defined in the International Standard
ISO 17573. According to this architecture, the Toll Charger is the provider of the road infrastructure and,
hence, the recipient of the road usage charges. The Toll Charger is the actor associated with the Toll
Charging role. See Figure 1.

Figure 1 — The role-based model underlying this Standard
vi
© ISO 2013 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/DIS 17575-2

Service Providers issue OBE to the users of the road infrastructure. Service Providers are responsible for
operating the OBE that will record the amount of road usage in all toll charging systems the vehicle passes
through and for delivering the charging data to the individual Toll Chargers. In general, each Service Provider
delivers charging data to several Toll Chargers, as well as each Toll Charger in general receives charging
data from more than one Service Provider. Interoperability Management in Figure 1 comprises all
specifications and activities that, in common, define and maintain a set of rules that govern the overall toll
charging environment.
Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects the fact
that some processing functionalities can either be allocated to the OBE or to an associated off-board
component (Proxy). An example of processing functionality that can be realized either on- or off-board is map-
matching, where the vehicle locations in terms of measured coordinates from GNSS are associated to
geographic objects on a map that either reside on- or off-board. Also tariffication can be done with OBE tariff
tables and processing, or with an off-board component.

Figure 2 — Assumed technical architecture and interfaces
The combined functionality of OBE and Proxy is denoted as Front End. A Front End implementation where
processing is predominately on OBE-side is known as a smart client (or intelligent client, fat client) or edge-
heavy. A Front End where processing is mostly done off-board is denoted as thin-client or edge-light
architecture. Many implementations between the “thin” and “thick” extremes are possible, as depicted by the
gradual transition in the wedges in Figure 2. Both extremes of architectural choices have their merits and are
one means where manufacturers compete with individual allocations of functionality between on-board and
central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the transfer of
localization data between OBE and off-board components, where proprietary algorithms are used for data
reduction and data compression. Standardization of this transfer is neither fully possible nor beneficial.
vii
© ISO 2013 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/DIS 17575-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 dotted
line in Figure 2). For every toll regime, the Back End will send context data, i.e. a description of the toll regime
in terms of charged objects, charging rules and, if required, the tariff scheme to the Front End, and will receive
usage data from the Front End.
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.
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
required attributes will differ from one Toll Charger to another, hence, attributes for all requirements are
offered, ranging from attributes for raw localization data, for map-matched geographic objects and for
completely priced toll transactions.
Part 2: Communication and connection to lower layers, defines basic communication services for data transfer
over the OBE air-link or between Front End and Back End.
Part 3: Context Data, defines the data to be used for a description of individual charging systems in terms of
charged geographical objects and charging and reporting rules. For every Toll Charger's system, attributes as
defined in part 3 are used to transfer data to the Front End in order to instruct it which data to collect and
report.
Part 4: Roaming, defines the functional details and data elements required to operate more than one EFC
regime in parallel. The domains of these EFC regimes may or may not overlap. The charge rules of different
overlapping EFC regimes can be linked, i.e. they may include rules that an area pricing scheme will not be
charged if an overlapping toll road is used and already paid for.
viii
© ISO 2013 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/DIS 17575-2

Figure 3 — Scope of ISO 17575
Application needs covered by ISO 17575
¾ The parts of ISO 17575 are compliant with the architecture defined in the future International Standard
ISO 17573.
¾ The parts of ISO 17575 support charges for use of road sections (including bridges, tunnels, passes,
etc.), passage of cordons (entry/exit) and use of infrastructure within an area (distance, time).
¾ The parts of ISO 17575 support fee collection based on units of distance or duration, and based on
occurrence of events.
¾ The parts of ISO 17575 support modulation of fees by vehicle category, road category, time of usage and
contract type (e.g. exempt vehicles, special tariff vehicles, etc.).
¾ The parts of ISO 17575 support limiting of fees by a defined maximum per period of usage.
¾ The parts of ISO 17575 support fees with different legal status (e.g. public tax, private toll).
¾ The parts of ISO 17575 support 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.
¾ The parts of ISO 17575 support overlapping geographic toll domains.
ix
© ISO 2013 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/DIS 17575-2
¾ The parts of ISO 17575 support adaptations to changes in
¾ tolled infrastructure,
¾ tariffs, and
¾ participating regimes.
¾ The parts of ISO 17575 support the provision of trust guarantees by the Service Provider to the Toll
Charger for the data originated from the Front End.

x
© ISO 2013 – All rights reserved

---------------------- Page: 10 ----------------------
DRAFT INTERNATIONAL STANDARD ISO/DIS 17575-2

Electronic fee collection — Application interface definition for
autonomous systems — Part 2: Communication and connection
to the lower layers
1 Scope
This part of ISO 17575 defines how to convey all or parts of the data element structure defined in other parts
of ISO 17575 over any communication stack and media suitable for this application. It is focussed on mobile
communication links. Wired links, i.e. back office connections, can use the same methodology, .
To establish a link to a sequence of service calls initializing the communication channel, addressing the
reception of the message and forwarding the payload are required. The required communication medium
independent services are part of the definition of this part of ISO 17575, represented by an abstract
application programming interface (API).
The communication interface is implemented as an API in the programming environment of choice for the
Front End (FE) system. The definition of this API in concrete terms is outside of the scope of this part of
ISO 17575. This part of ISO 17575 specifies an abstract API that defines the semantics of the concrete API
and its protocol implementation conformance statement (PICS) proforma (see Annex B). An example concrete
API is presented in Annex C. Where no distinction is made between the abstract and concrete
communications APIs, the term “communications API” or just “API”, can be used.
Certificate handling and encryption mechanisms are outside of the scope of this part of ISO 17575.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation — Part 1
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17573, Electronic fee collection — Systems architecture for vehicle related tolling
ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems — Part 3:
Context data
ISO 17575-4, Electronic fee collection — Application interface definition for autonomous systems — Part 4:
Roaming



© ISO 2013 – All rights reserved
1

---------------------- Page: 11 ----------------------
ISO/DIS 17575-2
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
attribute
application information formed by one or by a sequence of data elements, used for implementation of a
transaction
[ISO 14906:2011, definition 3.3]
3.2
authentication
provision of assurance that a claimed characteristic of an entity is correct
[ISO 27000]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[ISO 14906:2011, definition 3.4]
3.4
Back End
generic name for the computin
...

NORME ISO
INTERNATIONALE 17575-2
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 2:
Communications et connexions aux
couches basses
Electronic fee collection — Application interface definition for
autonomous systems —
Part 2: Communication and connection to the lower layers
Numéro de référence
ISO 17575-2:2016(F)
©
ISO 2016

---------------------- Page: 1 ----------------------
ISO 17575-2:2016(F)

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

---------------------- Page: 2 ----------------------
ISO 17575-2:2016(F)

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Termes et définitions . 2
3 Abréviations . 4
4 Architecture de communication de système EFC frontal . 5
4.1 Généralités . 5
4.2 Relations avec l’ensemble de l’architecture EFC . 6
5 Services de communication EFC (fonctions) . 6
5.1 Concept général . 6
5.2 Phase d’initialisation .10
5.2.1 Généralités .10
5.2.2 Demande d’une session entrante (du système central à l’application du
système frontal) . .10
5.2.3 Etablissement d’une session sortante (de l’application du système frontal
au système central) . .10
5.3 Primitives de service de communication point à point .10
5.3.1 Généralités .10
5.3.2 Messages non structurés (ADU) .11
5.3.3 Messages structurés (ADU) .11
5.4 Fin de session .11
5.5 Echec de session .11
5.6 Considérations sur la sécurité .12
5.7 Options de sélection des supports .12
6 Utilisation d’une pile de communication .12
6.1 Généralités .12
6.2 Exigences relatives à une technologie de communication sous-jacente .12
6.3 Appels mobiles terminés .12
Annexe A (normative) Définition de l’API abstraite .14
Annexe B (normative) Formulaire PICS.20
Annexe C (informative) Exigences de l’API .25
Annexe D (informative) Exemples de définition pour les langages concernés .27
Annexe E (informative) Utilisation de la présente partie de l’ISO 17575 pour le SET .30
Bibliographie .32
© ISO 2016 – Tous droits réservés iii

---------------------- Page: 3 ----------------------
ISO 17575-2:2016(F)

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-2 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-2:2010), qui a 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, 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.
iv © ISO 2016 – Tous droits réservés

---------------------- Page: 4 ----------------------
ISO 17575-2:2016(F)

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 pour l’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.
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). Plusieurs termes sont utilisés pour faire référence à ces
systèmes EFC. 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.
Grâce à un système de localisation par satellite souvent combiné à d’autres technologies de détection
(gyroscopes, compteurs kilométriques et accéléromètres), les systèmes autonomes localisent le
véhicule sur une carte géographique contenant les informations de tarification des routes et portions
payantes. Ces informations de tarification permettent de déterminer les caractéristiques du véhicule,
l’heure et les autres données pertinentes pour définir l’usage routier, le tarif et la redevance associée.
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. Seules des interfaces
clairement définies peuvent permettre cette interopérabilité, ce qui représente le but et la justification
de l’ISO 17575.
0.2 Architecture opérationnelle
La présente partie de l’ISO 17575 est conforme à l’architecture opérationnelle définie dans l’ISO 17573
selon laquelle le percepteur de péage est le fournisseur de l’infrastructure routière et, de ce fait, le
bénéficiaire des redevances d’usage routier. Le percepteur de péage est associé au rôle de perception du
péage (voir Figure 1).
© ISO 2016 – Tous droits réservés v

---------------------- Page: 5 ----------------------
ISO 17575-2:2016(F)

Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
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 1 — Modèle basé sur les rôles servant à l’ISO 17575
Les prestataires de services fournissent des équipements embarqués aux usagers de l’infrastructure
routière. Les prestataires de services sont responsables de l’exploitation des équipements embarqués
qui consignent le taux d’usage du réseau routier dans les systèmes de perception du péage par lesquels
transitent les véhicules et fournissent les données de perception à chaque percepteur de péage. 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 prestataires de services. La gestion de l’interopérabilité illustrée à la Figure 1
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.
0.3 Architecture technique
L’architecture technique de la Figure 2 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). Par exemple, le repérage cartographique est une
fonctionnalité pouvant être traitée par un équipement embarqué ou non embarqué; les coordonnées de
localisation des véhicules mesurées par le système GNSS sont associées aux objets géographiques sur
une carte hébergée sur un équipement embarqué ou non embarqué. Le calcul des tarifs peut également
être effectué à l’aide de tables tarifaires et d’un traitement dans l’OBE, ou à l’aide d’un composant
non embarqué.
vi © ISO 2016 – Tous droits réservés

---------------------- Page: 6 ----------------------
ISO 17575-2:2016(F)

Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Front End Back End
Road Usage Data
Context Data
Anglais Français
Scope of ISO 17575 Domaine d’application de l’ISO 17575
Processing Equipment Equipement 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 2 — Architecture technique supposée et interfaces
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 dont le traitement
est principalement réalisé sur un équipement non embarqué est appelé client léger ou architecture
légère (« edge-light »). Il existe beaucoup d’autres implémentations possibles entre ces deux extrêmes,
comme l’indiquent les flèches de transition de la Figure 2. Ces deux architectures extrêmes offrent de
nombreux avantages et représentent un enjeu concurrentiel entre les fabricants qui proposent chacun
des fonctionnalités différentes d’affectation des ressources embarquées et centrales.
Dans le cas spécifique des équipements embarqués de client léger, les fabricants sont amenés à concevoir
de multiples optimisations pour le transfert des données de localisation entre l’équipement embarqué
et les composants non embarqués, en utilisant des algorithmes de propriété pour la réduction et la
compression des données. La normalisation de ce transfert n’est ni possible ni avantageuse.
0.4 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 2). Pour chaque régime de péage, le système
central envoie les données du contexte (ex: description du régime contenant des objets d’imputation,
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.
© ISO 2016 – Tous droits réservés vii

---------------------- Page: 7 ----------------------
ISO 17575-2:2016(F)

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 aux prestataires de services. De ce fait, les définitions
de données fournies dans l’ISO 17575 peuvent être pertinentes pour plusieurs interfaces.
La norme ISO 17575 traite également des services basiques de communication indépendants du
support pouvant être utilisés lors de la communication entre le système frontal et le système central,
qui pourraient être basés sur des lignes ou des ondes hertziennes, et pouvant également servir pour la
liaison hertzienne entre l’équipement embarqué et le serveur de communication central.
0.5 Parties de la norme 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 l’ISO 17575-1 et l’ISO 17575-3 peuvent, mais ne doivent
pas nécessairement ê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.6 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 de perception,
— retour d’informations au conducteur (ex: voyant rouge ou vert), et
viii © ISO 2016 – Tous droits réservés

---------------------- Page: 8 ----------------------
ISO 17575-2:2016(F)

— 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
— d’infrastructure à péage,
— de tarifs, et
— les régimes 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.
© ISO 2016 – Tous droits réservés ix

---------------------- Page: 9 ----------------------
NORME INTERNATIONALE ISO 17575-2:2016(F)
Perception du télépéage — Définition de l’interface
d’application pour les systèmes autonomes —
Partie 2:
Communications et connexions aux couches basses
1 Domaine d’application
La présente partie de l’ISO 17575 définit comment transposer tout ou partie de la structure des éléments
de données définis dans les autres parties de l’ISO 17575 via une pile de communication et des supports
adaptés à cette application. Elle s’applique uniquement aux liaisons de communication mobile (bien que
les liaisons filaires, comme celles de back-office, puissent utiliser la même méthode).
Pour établir une liaison avec une séquence d’appels de service initialisant le canal de communication, la
réception du message et le réacheminement de la charge doivent être gérés. La définition fournie dans
la présente partie de l’ISO 17575 englobe les services indépendants du support de communication; ils
sont représentés par une interface de programmation d’application (API).
L’interface de communication est implémentée dans l’environnement de programmation choisi pour le
système frontal (FE, Front End) sous la forme d’une API. La spécification de l’API du système central
(BE, Back End) n’entre pas dans le cadre de la présente partie de l’ISO 17575.
La définition de cette API en termes concrets n’entre pas dans le cadre de la présente partie de
l’ISO 17575. La présente partie de l’ISO 17575 spécifie une API abstraite qui définit la sémantique
de l’API concrète comme illustré à la Figure 3 et son formulaire de déclaration de conformité
d’implémentation de protocole (PICS, Protocol Implementation Conformance Statement) comme décrit
à l’Annexe B. L’Annexe C fournit un exemple d’API concrète. Aucune distinction n’étant faite entre les
API de communication abstraites et concrètes, les termes « API de communication » ou simplement
« API » peuvent s’utiliser indifféremment.
© ISO 2016 – Tous droits réservés 1

---------------------- Page: 10 ----------------------
ISO 17575-2:2016(F)

Front End Application
7. Application
Communications
API
6. Presentation
Communications
Subsystem
5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Anglais Français
Communications API API de communication
Front End Application Application du système frontal
7. Application 7. Application
Communications Subsystem Sous-système de communication
6. Presentation 6. Présentation
5. Session 5. Session
Underlying Communications Technology Technologie de communication sous-jacente
4. Transport 4. Transport
3. Network 3. Réseau
2. Datalink 2. Liaison de données
1. Physical 1. Physique
Figure 3 — Domaine d’application de la présente partie de l’ISO 17575
La présente partie de l’ISO 17575 fournit également une spécification détaillée de la structure des
déclarations API associées, un exemple de la manière de l’implémenter, ainsi que son rôle dans un
groupe de péage complexe tel que le SET (voir Annexe A à Annexe E).
Les règles de sélection des supports et les mécanismes de chiffrement et de gestion des certificats
n’entrent pas dans le cadre de la présente partie de l’ISO 17575.
2 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
2.1
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ées
[SOURCE: ISO 17575-1:2016, 3.2]
2 © ISO 2016 – Tous droits réservés

---------------------- Page: 11 ----------------------
ISO 17575-2:2016(F)

2.2
authentificateur
données (pouvant être chiffrées) qui sont utilisées à des fins d’authentification
[SOURCE: EN 15509:2014, 3.3]
2.3
système central
BE (Back End)
partie du système de back-office assurant l’interface avec un ou plusieurs systèmes frontaux (2.6)
2.4
élément de données
information codée, qui peut elle-même être constituée de structures d’information de niveau inférieur
[SOURCE: ISO 17575-1:2016, 3.9]
2.5
intégrité des données
propriété indiquant que les données n’ont pas été altérées ni supprimées d’une manière non autorisée
2.6
système frontal
FE (Front End)
partie d’un système de péage composé de l’équipement embarqué (OBE) (2.9) et éventuellement d’un
proxy (2.10) 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 (2.3)
[SOURCE: ISO/TS 19299:2015, 3.17]
Note 1 à l’article: à l’Article Le système frontal comporte l’équipement embarqué et un proxy facultatif.
2.7
application du système frontal
partie du système frontal située au-dessus de l’API
2.8
interopérabilité
aptitude des systèmes à échanger des informations et à faire mutuellement usage des informations
échangées
[SOURCE: ISO/IEC/TR 100001:1998, 3.2.1, modifiée.]
2.9
é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
Note 1 à l’article: à l’Article Il convient de considérer les autres sous-unités comme facultatives.
2.10
proxy
partie optionnelle d’un système frontal (2.6) 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 (2.3)
[SOURCE: ISO 17575-1:2016, 3.13]
© ISO 2016 – Tous droits réservés 3

---------------------- Page: 12 ----------------------
ISO 17575-2:2016(F)

2.11
primitive de service
service de communication élémentaire fourni par le protocole de couche d’application aux processus
d’application
Note 1 à l’article: à l’Article L’invocation d’une primitive de service par un processus d’application appelle
implicitement et utilise les services fournis par les couches basses de protocole.
[SOURCE: ISO 14906:2011, 3.18, modifiée.]
2.12
prestataire de services de péage
entité offrant des services de péage dans un ou plusieurs domaines de péage
[SOURCE: ISO 17573:2010, 3.23, modifiée.]
2.13
péage
redevance, taxe ou droit prélevé en rapport avec l’utilisation d’un véhicule dans un domaine de péage
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.
[SOURCE: ISO/TS 19299:2015, 3.42, modifiée.]
2.14
percepteur de péage
entité qui perçoit le péage pour l’utilisation de véhicules dans un domaine de péage
[SOURCE: ISO 17573:2010, 3.16, modifiée.]
3 Abréviations
Pour les besoins du présent document, les abréviations suivantes s’appliquent, sauf spécification contraire.
ADU (Application Data Unit) Unité de données d’application (ISO 14906)
APDU (Application Protocol Data Unit) Unité de données d’application (ISO 14906)
AP (Application Process) Processus d’application (ISO 14906)
API (Application Programming Interface) Interface de programme d’application
ASN.1 (Abstract Syntax Notation One) Notation de syntaxe abstraite numéro un (ISO/IEC 88241)
BE (Back End) Système central
CN Réseau cellulaire
EID (Element IDentifier) Identifiant d’élément (ISO 14906)
FE (Front End) Système frontal
GNSS (Global Navigation Satellite System) Système mondial de navigation par satellite
OBE (On-Board Equipment) Equipement embarqué (ISO 14906)
TVA Taxe sur la valeur ajoutée
4 © ISO 2016 – Tous droits réservés

---------------------- Page: 13 ----------------------
ISO 17575-2:2016(F)

4 Architecture de communication de système EFC frontal
4.1 Généralités
Un sous-système de communication est nécessaire pour établir la liaison de communication entre
l’application d’un système frontal (FE) et d’un système central (BE). Il assure la transmission
des données pour l’application du système frontal via la session de communication établie sur la
ligne illustrée à la Figure 4. Lorsqu’un proxy est présent sur le système frontal, le sous-système de
communication définit les communications entre le systèm
...