ISO 12855:2022
(Main)Electronic fee collection — Information exchange between service provision and toll charging
Electronic fee collection — Information exchange between service provision and toll charging
This document specifies: — the interfaces between electronic fee collection (EFC) back-office systems for vehicle-related transport services, e.g. road user charging, parking and access control; — an exchange of information between the back end system of the two roles of service provision and toll charging, e.g.: — charging-related data (toll declarations, billing details), — administrative data, and — confirmation data; — transfer mechanisms and supporting functions; — information objects, data syntax and semantics. This document is applicable for any vehicle-related toll service and any technology used for charging. The data types and associated coding related to the data elements described in Clause 6 are defined in Annex A, using the abstract syntax notation one (ASN.1) according to ISO/IEC 8824‑1. This document specifies basic protocol mechanisms over which implementations can specify and perform complex transfers (transactions). This document does not specify, amongst others: — any communication between toll charger (TC) or toll service provider (TSP) with any other involved party; — any communication between elements of the TC and the TSP that is not part of the back-office communication; — interfaces for EFC systems for public transport; — any complex transfers (transactions), i.e. sequences of inter-related application data units (ADUs) that can possibly involve several application protocol data unit (APDU) exchanges; — processes regarding payments and exchanges of fiscal, commercial or legal accounting documents; and — definitions of service communication channels, protocols and service primitives to transfer the APDUs.
Perception de télépéage — Échange d'informations entre la prestation de service et la perception du péage
Le présent document spécifie: — les interfaces entre les systèmes de back-office de perception de télépéage (EFC) pour les services de transport associés aux véhicules, tels que la tarification des usagers de la route, le stationnement et le contrôle d’accès; — l’échange d’informations entre les systèmes centraux des deux rôles de prestataire de services et d’exploitant de péage, par exemple: — données liées à la perception (déclarations de péage, détails de facturation); — données administratives; et — données de confirmation; — les mécanismes de transfert et fonctions de support; — les objets d’informations, syntaxe et sémantique des données. Le présent document est applicable à tout service lié à des véhicules et à toute technologie utilisée pour la perception. Les types de données et le codage associé aux éléments de données décrits à l’Article 6 sont définis en Annexe A, à l’aide de la notation de syntaxe abstraite numéro un (ASN.1) conformément à l’ISO/IEC 8824‑1. Le présent document spécifie les mécanismes de protocole de base sur lesquels des réalisations peuvent spécifier et exécuter des transferts (transactions) complexes. Le document ne spécifie pas, entre autres: — toute communication entre l’exploitant de péage, ou le fournisseur de service de péage, et toute autre partie prenante; — toute communication entre éléments de l’exploitant de péage et du fournisseur de service de péage ne faisant pas partie de la communication de back-office; — les interfaces pour systèmes de télépéage destinés aux transports publics; — tous transferts complexes (transactions), c’est-à-dire des séquences d’unités de données d’application (ADU) pouvant éventuellement mettre en jeu plusieurs échanges d’unités de données de protocole d’application (APDU); — les processus concernant les paiements et les échanges de documents comptables fiscaux, commerciaux ou juridiques; ni — la définition des canaux de communication de services, des protocoles et des primitives de service permettant de transférer les APDU.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 12855
Third edition
2022-04
Electronic fee collection —
Information exchange between service
provision and toll charging
Perception du télépéage — Échange d'informations entre la
prestation de service et la perception du péage
Reference number
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms.3
5 Architectural concepts and information exchanges . 4
5.1 Main roles in the toll charging environment . 4
5.2 Information exchange between toll charging and provision . 5
5.2.1 General . 5
5.2.2 Basic protocol mechanisms . 7
5.2.3 Exchange trust objects functionality . 8
5.2.4 Originating and providing EFC context data functionality . 8
5.2.5 Provide contract issuer information functionality . 9
5.2.6 Manage exception list functionality . 9
5.2.7 Report toll declarations functionality . 10
5.2.8 Report billing details functionality . 10
5.2.9 Payment settlement functionality . 11
5.2.10 Exchange enforcement data functionality .12
5.2.11 Process user complaints functionality . 13
5.2.12 Exchange quality assurance parameters functionality .13
5.2.13 Provide media settlement data functionality . . 14
6 Computational specification .14
6.1 Overview . 14
6.2 Application protocol data units . 17
6.2.1 General . 17
6.2.2 Application protocol control information (APCI) . 19
6.2.3 Application data units .20
6.2.4 ADU identification .20
6.2.5 ADU action code . 21
6.2.6 User identification . 21
6.3 RequestAdu data structure . .22
6.4 AckAdu data structure .25
6.5 StatusAdu data structure . 32
6.6 TrustObjectAdu data structure . 32
6.7 EfcContextDataAdu data structure . 39
6.7.1 General .39
6.7.2 GeneralContextData type .40
6.7.3 MeshedContextData type . 57
6.7.4 Common data structures .66
6.8 ContractIssuerListAdu data structure .88
6.9 ExceptionListAdu data structure .90
6.10 ReportAbnormalObeAdu data structure .94
6.11 TollDeclarationAdu data structure . 95
6.12 BillingDetailsAdu data structure.99
6.12.1 General .99
6.12.2 UsageList data type.101
6.12.3 AssociatedEventData data type . 111
6.13 PaymentClaimAdu data structure . 117
6.14 PaymentAnnouncement Adu data structure . . 119
6.15 ProvideUserDetailsAdu data structure .121
6.16 ReportCccEventAdu data structure .125
iii
6.17 ProvideUserIdListAdu data structure .126
6.18 Report QA data structure.127
6.19 User complaint data structure .128
6.20 User complaint response data structure.129
6.21 Media settlement data structure .131
7 Transfer mechanisms and supporting functions . 132
7.1 Transfer mechanisms .132
7.2 Secure communication channel .133
7.3 Supporting functions .133
7.3.1 Communication services .133
7.3.2 Authenticators .133
7.3.3 Signature and hash algorithms .135
7.3.4 Keys encryption .135
Annex A (normative) Data type specifications . 136
Annex B (informative) Example enforcement process applyingstandardized APDU
exchanges . 137
Annex C (informative) Example of data flows in a toll domain .142
Annex D (informative) Example of rounding differences .145
Annex E (informative) Example of fee calculation using EFC context data . 149
Bibliography . 153
iv
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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC
278, Intelligent transport systems, in accordance with the Agreement on technical cooperation between
ISO and CEN (Vienna Agreement).
This third edition cancels and replaces the second edition (ISO 12855:2015), which has been technically
revised.
The main changes are as follows:
— addition of new application data units (ADUs);
— alignment of the ASN.1 data definitions with the current edition of ISO 14906;
— removal of all dependencies on the ISO 17575 series ASN.1 data types and creation of corresponding
definitions;
— re-classification of the electronic fee collection (EFC) context types by tolling and geographical
characteristics and removal of the previous distinction based on tolling technology;
— splitting of the ASN.1 module into two modules: one containing ISO 12855-specific definitions, and
another containing data-type definitions that are common to other standards in the EFC domain.
This common data types module has then been moved to ISO/TS 17573-3;
— clarification of the semantics of all parameters in ADUs;
— alignment of the structure of all major clauses in a consistent manner to improve readability.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
The widespread use of road tolling requires provisions for users of vehicles that circulate through many
different toll domains. Users should be offered a single contract for driving a vehicle through various
toll domains. Where those vehicles require on-board equipment (OBE) this should be interoperable
with the toll systems in the various toll domains. In Europe, for example, this need has been officially
[8]
recognized and legislation on interoperability has already been adopted (see Directive 2019/520 ,
[10]
related Commission delegated regulation 2020/2003 and Commission implementing regulation
[9]
2020/204 ). There is both a commercial and economic justification regarding the OBE and the toll
systems for International Standards supporting interoperability.
The system architecture defined in ISO 17573-1 is the basis for all International Standards that relate
to tolling systems in the toll domain. With respect to ISO 17573-1, this document:
— adopts its definitions of terms and concepts and basic system functionalities and structure,
— uses its terminology, and
— specifies the interfaces identified therein.
ISO 17573-1 uses ISO/IEC 10746-3 for the description of the architecture.
Figure 1 shows the scope of the group of International Standards related to electronic fee collection
(EFC) based upon the ISO 17573-1 system architecture.
vi
Key
DSRCdedicated short-range communication
QA quality assurance
RSE roadside equipment
Figure 1 — Scope of EFC-related International Standards
A given transport service for a given vehicle is fully identified by one or several toll declarations made
available to the toll charger (TC). It is necessary to make toll declarations available according to the
rules of the toll regime of the toll domain.
The amount due for a given transport service used by a vehicle liable to toll is finalized by the TC with
the use of toll declarations (as described above) and calculations are made according to the rules of the
toll regime (formula, tariff tables, specific situations rules, traffic conditions, etc.). This means that the
TC has the authority to decide on the amount due, even if it decides to assign the toll service provider
(TSP) the task of calculating the amount due.
The information above, associated with a given transport service, is referred to as "billing details"; for a
given transport service, the billing details refer to one or several toll declarations.
Depending on the toll regime, billing details are computed by means of the information collected by the
TC and/or the relevant TSP; they are finalized by the TC or by the TSP if the TC has assigned this task to
the TSP.
The TC settles the payment claims (or toll payment claims) and makes them available to each TSP, or
requires the TSP to send payment announcements, according to the bilateral agreements it has with
each TSP, referring to billing details. These payment claims include an amount due, taking into account
any specific commercial conditions applicable to a vehicle, a fleet of vehicles or a given TSP.
vii
This document defines a set of interactions in support of technical interoperability between back-office
systems of TCs and TSPs. The EFC service and the EFC system model on which this document is based
are defined in ISO 17573-1.
This document does not provide a full solution for interoperability and it does not define other parts
of the EFC system, other services, other technologies and non-technical elements of interoperability. It
is defined as a toolbox International Standard of application protocol data units (APDUs), which can be
used for the assigned purpose. The detailed definitions of mandatory and optional elements in a real
implementation are defined elsewhere. It does not define all communication sequences, communication
stacks and timings.
The development of a common European Electronic Toll Service (EETS), as a part of the already cited
European EFC Directive and related Regulation and Implementing acts, also calls for the definition
of an interoperable EFC service. It should be noted that CEN/TS 16986 (to be revised and converted
into a European Standard) specifies interoperable application profiles (IAP), applicable based on
this document. These profiles define a specific coherent set of transactions, triggers, conditions,
data elements, transfer mechanisms and supporting functions for an interoperable exchange of data
between the back end system of TCs and TSPs. CEN/TS 16986 is consistent with and is intended to
provide support for the technical specification of the EETS.
This document identifies and specifies the set of APDUs exchanged between two actors in the roles of
TSP and TC as defined in ISO 17573-1. To specify these interfaces, this document uses the enterprise
description of the toll environment, and the interactions defined between the named classes of roles,
as defined in ISO 17573-1. This supports a complete specification of the data that is transferred
between those identified entities. In addition, a number of computational interfaces are identified and
interactions in terms of sequences of application protocol data units are defined.
viii
INTERNATIONAL STANDARD ISO 12855:2022(E)
Electronic fee collection — Information exchange between
service provision and toll charging
1 Scope
This document specifies:
— the interfaces between electronic fee collection (EFC) back-office systems for vehicle-related
transport services, e.g. road user charging, parking and access control;
— an exchange of information between the back end system of the two roles of service provision and
toll charging, e.g.:
— charging-related data (toll declarations, billing details),
— administrative data, and
— confirmation data;
— transfer mechanisms and supporting functions;
— information objects, data syntax and semantics.
This document is applicable for any vehicle-related toll service and any technology used for charging.
The data types and associated coding related to the data elements described in Clause 6 are defined in
Annex A, using the abstract syntax notation one (ASN.1) according to ISO/IEC 8824-1.
This document specifies basic protocol mechanisms over which implementations can specify and
perform complex transfers (transactions).
This document does not specify, amongst others:
— any communication between toll charger (TC) or toll service provider (TSP) with any other involved
party;
— any communication between elements of the TC and the TSP that is not part of the back-office
communication;
— interfaces for EFC systems for public transport;
— any complex transfers (transactions), i.e. sequences of inter-related application data units (ADUs)
that can possibly involve several application protocol data unit (APDU) exchanges;
— processes regarding payments and exchanges of fiscal, commercial or legal accounting documents;
and
— definitions of service communication channels, protocols and service primitives to transfer the
APDUs.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 612, Road vehicles — Dimensions of motor vehicles and towed vehicles — Terms and definitions
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 1176, Road vehicles — Masses — Vocabulary and codes
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
code
ISO 4217, Codes for the representation of currencies
ISO 8583-1, Financial transaction card originated messages — Interchange message specifications — Part
1: Messages, data elements and code values
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification
of basic notation
ISO/IEC 8825-4, Information technology — ASN.1 encoding rules — Part 4: XML Encoding Rules (XER)
ISO/IEC 9594-8, Information technology — Open systems interconnection — Part 8: The Directory: Public-
key and attribute certificate frameworks
ISO/IEC 9797-1:2011, Information technology — Security techniques — Message Authentication Codes
(MACs) — Part 1: Mechanisms using a block cipher
ISO/IEC 10118-3, IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions
ISO/IEC 11770-3, Information security — Key management — Part 3: Mechanisms using asymmetric
techniques
ISO 13616-1, Financial services — International bank account number (IBAN) — Part 1: Structure of the
IBAN
ISO/IEC 14888-2:2008, Information technology — Security techniques — Digital signatures with appendix
— Part 2: Integer factorization based mechanisms
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO/TS 17444-1, Electronic fee collection — Charging performance — Part 1: Metrics
ISO/TS 17573-2, Electronic fee collection — System architecture for vehicle related tolling — Part 2:
Vocabulary
ISO/IEC 18033-2, Information technology — Security techniques — Encryption algorithms — Part 2:
Asymmetric ciphers
ISO 19299, Electronic fee collection — Security framework
ISO 20524-1:2020, Intelligent transport systems — Geographic Data Files (GDF) GDF5.1 — Part 1:
Application independent map data shared between multiple sources
IETF RFC 4347, Datagram Transport Layer Security, April 2006
IETF RFC 5246, The Transport Layer Security (TLS) Protocol, August 2008
IETF RFC 5746, Transport Layer Security (TLS) Renegotiation Indication Extension, February 2010
IETF RFC 6040, Tunnelling of Explicit Congestion Notification, February 2013
W3C Recommendation XML Signature Syntax and Processing Version 1.1
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 17573-2 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Symbols and abbreviated terms
ADU application data unit
ANPR automatic number plate recognition
APCI application protocol control information
APDU application protocol data unit
BIC bank identifier code
CCC compliance check communication
CRL certificate revocation list
cXER canonical XML encoding rules
DSRC dedicated short-range communication
DST daylight saving time
DTLS datagram transport layer security
EFC electronic fee collection
FTP file transfer protocol
GDF geographical data file
GNSS global navigation satellite system
HOT high occupancy tolling
HTTPS hyper-text transfer protocol secure
IANA internet assigned numbers authority
IBAN international bank account number
ICC integrated circuit card
IEC International Electrotechnical Commission
ITU International Telecommunication Union
LAC localization augmentation communication
LPN licence plate number
NMEA National Marine Electronics Association
OBE on-board equipment
OBU on-board unit
OCSP online certificate status protocol
OSI open systems interconnection
PAN personal account number
QA quality assurance
RINEX receiver independent exchange format
RSA Rivest, Shamir and Adleman
RSE roadside equipment
SLA service level agreement
SMTP simple mail transfer protocol
SU service user
TC toll charger
TLS transport layer security
TSP toll service provider
UTC coordinated universal time
VAT value added tax
VPN virtual private network
VRM vehicle registration mark
XER XML encoding rules
NOTE RSA is an algorithm for public-key cryptography, also referred to as asymmetrical cryptographic
technique.
5 Architectural concepts and information exchanges
5.1 Main roles in the toll charging environment
This document is built upon ISO 17573-1.
ISO 17573-1 specifies the four main roles shown in Figure 2.
Figure 2 — Roles in the toll charging environment
Information exchanges are agreed upon between TC and TSP, taking into account privacy regulations.
The information exchanges needed by the TC and the TSP to perform their roles are described in this
clause.
5.2 Information exchange between toll charging and provision
5.2.1 General
The information exchange between the service provision and the toll charging roles supports the
provision of functionalities that are based on the EFC system service specifications in ISO 17573-1.
Figure 3 gives a general picture of the functionalities provided in this document.
Figure 3 — Functionalities of this document (ISO 12855)
These functionalities are listed below, in the order in which they are given in Clause 5:
— basic protocol mechanisms;
— exchange trust objects;
— provide EFC context data;
— provide contract issuer list;
— manage exception list;
— report toll declarations;
— report billing details;
— payment settlement:
— claim payment for service usage,
— announce payments.
— exchange enforcement data:
— exchange of user details,
— exchange of compliance check communication (CCC) events,
— exchange of UserId lists,
— process user complaints:
— provide a user complaint;
— response to a user complaint.
— exchange quality assurance parameters.
— provide media settlement data.
This document leaves implementers the freedom of specifying suitable protocol procedures, i.e. for
complex transactions. Therefore, it only specifies:
— a basic interaction protocol (request – response) for information exchange;
— basic protocol mechanisms, to be used to build more complex protocol procedures; and
— the semantics and the format of the APDUs that are exchanged.
These functionalities are described in 5.2.2 to 5.2.13.
5.2.2 Basic protocol mechanisms
5.2.2.1 General approach
Information exchanges are performed by means of APDU transfers.
Some APDU transfers need to be acknowledged. When this happens, related protocol procedures are
specified. This document specifies no provisions for complex transfers (transactions), i.e. sequences of
inter-related ADUs which may involve several APDU exchanges. Instead, this document specifies basic
protocol mechanisms to be used by implementations that need to specify and perform transactions.
This document provides the following basic protocol mechanisms to exchange information between the
TSP’s and the TC’s back end system. These basic protocol mechanisms consist of:
— an identification schema for the APDUs that are exchanged,
— a generic interaction (i.e. not related to any specific functionality) that supports requesting a specific
information exchange from the counterpart. This interaction is provided by the “request” ADU,
— a generic acknowledge mechanism (i.e. not related to any specific functionality) that supports
acknowledging a specific interaction. The “ack” ADU provides this mechanism, and
— an optional generic status mechanism (i.e. not related to any specific functionality) that supports
providing status information for a specific interchange. This mechanism is provided by the “status”
ADU.
By means of the above mechanisms, an implementation can build more complex protocol procedures,
including rollback, recovery, checkpoint or restart.
This document does not specify timings and retry procedures for acknowledgements. Timeouts can be
specified as agreements between TC and TSP to cover the case of missing acknowledgements.
5.2.2.2 Identification schema
Each APDU contains a unique identifier in the namespace of the originator of the APDU. The combination
of originator identifier and APDU identifier ensures that all APDUs are uniquely identified.
5.2.2.3 Request functionality
The request functionality is used to:
— alert the counterpart that one is ready to accept any kind of information exchange,
— inform the counterpart that one is ready to accept a specific type of ADU, by indicating the type of
ADU one is ready to accept,
— request the counterpart re-issue a specific APDU, by indicating the type and the identifier of the
APDU, and
— request information identified by type and ADU content.
5.2.2.4 Acknowledgement functionality
The acknowledgement functionality is used to inform the counterpart that a specific ADU has been
received correctly, or that errors have been detected.
5.2.2.5 Status functionality
The status functionality may be used to provide the counterpart with general status information about
the interface or to inform it about a status on previously transferred information. It is used to:
— provide general information on the status of the interface,
— alert the counterpart that some previously provided information becomes invalid without any new
information being currently available, and
— alert the counterpart that the previous information contained an error and should be recalled.
5.2.3 Exchange trust objects functionality
The exchange trust objects functionality is derived from the EFC system service “trust object
exchange”. The functionality is used whenever an entity, both TC and TSP, needs to send unsolicitedly
new or updated trust objects to its counterpart or when asked by its counterpart to update or resend
an already existing trust object.
NOTE Examples of trust objects are: asymmetric public keys, certificates, symmetric keys and certificate
revocation lists.
Requiring the counterpart to send trust objects is performed by means of a “request” ADU. The “request”
ADU supports requesting already issued trust objects to be resent, as well as requesting newly issued
trust objects.
The exchange trust objects functionality provides the “trust objects” ADU to transfer the requested or
newly generated trust objects to the counterpart, which has the possibility of confirming or rejecting
the received trust objects by using the acknowledgement functionality.
The exchanged trust objects are valid from either the time of their acknowledgment or from the validity
starting, if specified in the “trust object” ADU. Trust objects may also become valid based on bilateral
agreements between TSP and TC (as defined in the implementation conformance statement).
5.2.4 Originating and providing EFC context data functionality
The originating and providing EFC context data functionality is derived from ISO 17573-1 as specified
in the EFC system service “adding or modifying a toll regime”.
The originating and providing EFC context data functionality gives a TC the possibility to communicate
any change of a toll domain or toll regime, including the start of a new toll domain, by issuing an “EFC
context data” ADU.
A TSP has the possibility of requiring a TC to provide information about the toll context data for a toll
domain under its responsibility by using a “request” ADU. The TC provides the information requested
by this “request” ADU by using an “EFC context data” ADU.
The TSP has the possibility to confirm reception of an “EFC context data” ADU by using the
acknowledgement functionality.
5.2.5 Provide contract issuer information functionality
The contractual information functionality supports a TSP in delivering to the TC any type of user
contract related information that is stored in the OBE, among which the personal account number
(PAN), the supported security level and the key set to be used in the calculation of dedicated short-
range communication (DSRC) authenticators. This functionality supports, among others, the TC in
comparing data retrieved from the OBEs with information received by the TSP.
5.2.6 Manage exception list functionality
5.2.6.1 General
The manage exception list functionality originates from ISO 17573-1 and is specified in the EFC system
service “exceptions handling”.
NOTE 1 This document uses the term “exception list” to summarize all possibilities of limiting the availability
of transport services to a user or giving information on the special handling of an OBE in a toll regime. Other
standards use different terms, but they are all included in the term “exception list”.
NOTE 2 The conditions and the periods of time that a user can be accepted within a toll regime are limited by
putting it on the exception list or removing it. This is solely the responsibility of the related TSP. Any information
sufficient for the identification of a specific vehicle or OBE by the TC, e.g. OBE ID, PAN, LPN (licence plate number),
are included in the exception list as agreed between TC and TSP.
5.2.6.2 Exception list entry requested by a toll charger
The manage exception list functionality supports a TC in notifying a TSP about detected violations by a
specific service user or wrong technical behaviour by a specific OBE by using a “report abnormal OBE”
ADU. The “acknowledgement” functionality is used to confirm reception of a “report abnormal OBE”
ADU. Subsequently, this OBE may be included in the exception list of the TSP.
5.2.6.3 Exception list entry decided by the toll service provider
The manage exception list functionality supports a TSP in notifying a TC about additions, modifications
or deletions of items in its exception lists by using the “exception list” ADU.
NOTE 1 The ADU can include, among others, one of the following reasons:
— the TSP has terminated its support/responsibility for a vehicle/OBE;
— an OBE was lost or stolen;
— the TSP has started/accepted its support/responsibility for a vehicle/OBE;
— the TC is informed about the commercial conditions to apply to an OBE (e.g. discount for a group of vehicles).
NOTE 2 The exception list can be used to provide additional information on a vehicle/OBE for a toll regime (e.g.
specific commercial conditions) and/or limit or restrict the acceptance of an OBE within a toll regime operated
via the road infrastructure of a TC, where an exchange of data between TSP and TC is needed.
NOTE 3 The exception list can be used to provide information on the country of registration of a vehicle and a
value added tax identifier (VAT ID) to support a TC in the correct application of VAT for ferry operations, where
this information is needed for handling of reverse charge VAT in the EU.
The TC may dispute the received exception list by using the acknowledgment functionality and
transmitting an error code. In this case, the last correct list remains active in the systems of the TC until
a newly transmitted list has been positively acknowledged by using the acknowledgement functionality.
5.2.7 Report toll declarations functionality
The report toll declarations functionality originates from ISO 17573-1 and is specified in the EFC system
service “collecting charging information (autonomous systems)”.
NOTE 1 The charging data generated by an OBE is used to report a service user (SU) entering, moving around
in or leaving a toll domain. A service usage statement with an amount due can be made either by a single tolled
object or by a combination of several tolled objects. Any service usage is reported as charging data through an
exchange of data between an OBE/proxy (front-end system) and the back end system managed by a TSP. This
interface between front-end and TSP is specified in ISO 17575-1 and ISO 17575-3, and is not covered by this
document.
The TSP has the possibility to enrich the gathered charging data that are stored in its back end system,
before sending that data as a “toll declarations” ADU to the TC. This possibility supports the concept of
shared user data, where only limited information may be included in the OBE, while the rest of it is held
centrally at the issuing TSP.
The “toll declarations” ADU provides the TC with all information needed to calculate the amount due
for the use of a toll domain or to verify the calculation done by the TSP, or it may contain only summary
data, according to the optional data elements that are implemented.
NOTE 2 The toll declarations can be delivered periodically in an agreed frequency (e.g. weekly, daily, hourly, in
real time, etc.) or upon triggering the delivery and with the quantity of information agreed for a toll regime.
The TC has the possibility to confirm a received “toll declaration” ADU by using the acknowledgement
functionality.
NOTE 3 If the TC detects a contradiction between the toll declarations provided by the TSP and its own
data (e.g. CCC data, LPN reading, etc.), it has the possibility to ask the TSP for additional information about the
provided toll declarations for a specific vehicle or service user by sending a “request” ADU to the TSP to provide
any detailed toll declarations for a specific service user and/or a specific period of time. This enables the TC to
receive only summation records of the use of its toll domain from the TSP and to produce its billing details in
normal operation without any detailed knowledge about each segment passed by an OBE. When the TC detects a
contradiction in the provided high level toll declarations during comparison with the CCC data it recorded, it can
ask the TSP for detailed toll declarations for this specific vehicle or Service User.
The procedure for handling a possible negative “ack” ADU as a response to a “toll declaration” ADU is
outside the scope of this document.
5.2.8 Report billing details functionality
Depending on the characteristics of a toll system, a TC either acquires the toll declarations directly
from the roadside equipment (RSE) it operates (e.g. DSRC-based systems) or receives it from the TSP's
back end system (e.g. autonomous systems). That information is then used for the generation of billing
details.
A single billing detail may refer to one or more toll declarations. The generation of billing details is
based on the requirements specified for the toll regime. Thus, a billing detail may consist of:
— an elementary usage of a transport service (e.g. regarding the toll for a road section);
— several usages of a transport service within a given period of time (a day, a week, a month, etc.); or
— several elementary usages of a transport service within a given journey.
If some relevant information is missing to build a billing detail out of the available toll declarations, the
TC has the possibility to request it from the back end system of the TSP (see 5.2.7).
The TC and TSP can
...
NORME ISO
INTERNATIONALE 12855
Troisième édition
2022-04
Perception de télépéage — Échange
d'informations entre la prestation de
service et la perception du péage
Electronic fee collection — Information exchange between service
provision and toll charging
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2022
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction .vii
1 Domaine d’application . 1
2 Références normatives .2
3 Termes et définitions . 3
4 Symboles et abréviations .3
5 Concepts d’architecture et échanges d’informations . 4
5.1 Principaux rôles dans l’environnement de perception du péage . 4
5.2 Échange d’informations entre la perception du péage et la prestation . 5
5.2.1 Généralités . 5
5.2.2 Mécanismes de protocole de base . 7
5.2.3 Fonctionnalité «exchange trust objects» (échange d’objets de confiance) . 8
5.2.4 Fonctionnalité «originating and providing EFC context data» (création et
fourniture de données de contexte d’EFC) . 9
5.2.5 Fonctionnalité «provide contract issuer information» (fourniture
d’informations sur l'émetteur du contrat) . 9
5.2.6 Fonctionnalité «manage exception list» (gestion de la liste des exceptions) . 9
5.2.7 Fonctionnalité «report toll declarations» (transmission des déclarations
de péage) . 10
5.2.8 Fonctionnalité «report billing details» (transmission des détails de
facturation) . 11
5.2.9 Fonctionnalité «payment settlement» (règlement des sommes dues) .12
5.2.10 Fonctionnalité «exchange enforcement data» (échange de données de
contrôle sanction) . 13
5.2.11 Fonctionnalité «process user complaints» (traitement de réclamations
d’utilisateur) . 14
5.2.12 Fonctionnalité «exchange quality assurance parameters» (échange de
paramètres d’assurance qualité) . 15
5.2.13 Fonctionnalité «provide media settlement data» (fourniture de données
de règlement au moyen de supports) . 15
6 Spécification fonctionnelle par objets .16
6.1 Vue d’ensemble . 16
6.2 Unités de données de protocole d’application . 19
6.2.1 Généralités . 19
6.2.2 Information de contrôle de protocole d’application (APCI) .20
6.2.3 Unités de données d’application . 22
6.2.4 Identification des ADU .23
6.2.5 Code d’action d’ADU . 23
6.2.6 Identification d’utilisateur . 23
6.3 Structure de données RequestAdu . 24
6.4 Structure de données AckAdu .28
6.5 Structure de données StatusAdu . 35
6.6 Structure de données TrustObjectAdu . 35
6.7 Structure de données EfcContextDataAdu . 42
6.7.1 Généralités . 42
6.7.2 Type GeneralContextData .44
6.7.3 Type MeshedContextData. 62
6.7.4 Structures de données communes .72
6.8 Structure de données ContractIssuerListAdu .96
6.9 Structure de données ExceptionListAdu .98
6.10 Structure de données ReportAbnormalObeAdu .102
6.11 Structure de données TollDeclarationAdu .104
iii
6.12 Structure de données BillingDetailsAdu .108
6.12.1 Généralités .108
6.12.2 Type de données UsageList . 110
6.12.3 Types de données AssociatedEventData .121
6.13 Structure de données PaymentClaimAdu .127
6.14 Structure de données PaymentAnnouncementAdu .129
6.15 Structure de données ProvideUserDetailsAdu .132
6.16 Structure de données ReportCccEventAdu .136
6.17 Structure de données ProvideUserIDListAdu .137
6.18 Structure de données «Report QA» .138
6.19 Structure de données de réclamation d'un utilisateur .140
6.20 Structure de données de réponse à la réclamation d'un utilisateur . 141
6.21 Structure de données de règlement au moyen d’un support . 142
7 Mécanismes de transfert et fonctions de support . 144
7.1 Mécanismes de transfert .144
7.2 Canal de communication sécurisé . 145
7.3 Fonctions de support . 145
7.3.1 Services de communication . 145
7.3.2 Authentifiants . 145
7.3.3 Signature et algorithmes de hachage . 147
7.3.4 Chiffrement des clés . 147
Annexe A (normative) Spécifications des types de données . 148
Annexe B (informative) Exemple de processus de contrôle sanction appliquantdes
échanges d’APDU normalisés . 149
Annexe C (informative) Exemple de flux de données dans un domaine de péage .154
Annexe D (informative) Exemple de différences d’arrondi . 157
Annexe E (informative) Exemple de calcul de redevance à l’aide des données de contexte
d’EFC . 162
Bibliographie .167
iv
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 attiré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 nature volontaire des normes, 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’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 204, Systèmes de transport intelligents,
en collaboration avec le comité technique CEN/TC 278, Systèmes de transport intelligents, du Comité
européen de normalisation (CEN) conformément à l’Accord de coopération technique entre l’ISO et le
CEN (Accord de Vienne).
Cette troisième édition annule et remplace la deuxième édition (ISO 12855:2015), qui a fait l’objet d’une
révision technique.
Les principales modifications sont les suivantes:
— ajout de nouvelles unités de données d’application (ADU);
— alignement des définitions de données ASN.1 avec l’édition actuelle de l’ISO 14906;
— suppression de toutes les dépendances par rapport aux types de données ASN.1 de la série ISO 17575
et création des définitions correspondantes;
— reclassification des types de contexte de perception de télépéage (EFC) en fonction du péage et des
caractéristiques géographiques et suppression de la distinction qui était faite précédemment sur la
base de la technologie de péage;
— scission du module ASN.1 en deux modules: un premier qui contient les définitions propres à
l’ISO 12855 et un autre qui contient les définitions des types de données communs aux autres
normes du domaine télépéage. Ce module de données communes a été déplacé vers la norme
ISO/TS 17573-3;
— clarification de de la sémantique de tous les paramètres des ADU;
v
— alignement de la structure des paragraphes les plus importants de manière cohérente afin d'en
améliorer la lisibilité.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www.iso.org/fr/members.html.
vi
Introduction
L’utilisation répandue du péage routier nécessite des dispositions pour les utilisateurs de véhicules qui
circulent dans différents domaines de péage. Il convient de proposer aux usagers un contrat unique pour
conduire un véhicule sur plusieurs domaines de péage. Lorsque les véhicules ont besoin d’un équipement
embarqué (OBE), il convient que ce dernier soit interopérable avec les systèmes de péage des différents
domaines de péage. En Europe, par exemple, ce besoin a été officiellement reconnu et une législation
[8]
de l’interopérabilité a déjà été adoptée (voir la Directive 2019/520, le Règlement délégué 2020/2003
[10] [9]
de la Commission qui s’y rapporte et le Règlement d'application 2020/204 de la Commission ). Les
normes internationales au service de l’interopérabilité des équipements embarqués et des systèmes de
péage sont justifiées tant du point de vue commercial que du point de vue économique.
L’architecture des systèmes définie dans l’ISO 17573-1 forme la base de toutes les normes internationales
relatives aux systèmes de péage dans le domaine du péage. Vis-à-vis de l'ISO 17573-1, le présent
document:
— adopte ses définitions de termes et de concepts ainsi que les fonctionnalités et la structure du
système de base;
— utilise sa terminologie; et
— précise les interfaces mentionnées dans le document.
L'ISO 17573-1 utilise l’ISO/IEC 10746-3 pour la description de l’architecture.
La Figure 1 présente le domaine d’application du groupe de normes internationales relatives à la
perception de télépéage (EFC) sur la base de l’architecture de système de l’ISO 17573-1.
vii
Légende
DSRC communication dédiée à courte portée
QA assurance qualité
RSE equipement en bord de route
Figure 1 — Domaine d’application des normes internationales relatives à la perception de
télépéage
Un service de transport donné pour un véhicule donné est entièrement identifié par une ou plusieurs
déclarations de péage mises à la disposition de l’exploitant de péage (TC). Il est nécessaire de rendre
disponibles les déclarations de péage conformément aux règles du régime de péage du domaine de
péage.
Le montant dû pour un service de transport donné utilisé par un véhicule soumis au paiement du péage
est finalisé par l’exploitant de péage (TC) à l’aide d’une ou plusieurs déclarations de péage (tel que cela
est décrit ci-dessus) et les calculs sont effectués conformément aux règles du régime de péage (formule,
tableaux tarifaires, règles pour les situations spécifiques, conditions de trafic, etc.). Cela signifie que
l’exploitant de péage a l’autorité de décider du montant dû, même s’il décide d’attribuer au fournisseur
de service de péage la tâche de calculer le montant dû.
Ces informations, associées à un service de transport donné, sont appelées «détails de facturation». Pour
un service de transport donné, les détails de facturation font référence à une ou plusieurs déclarations
de péage.
En fonction du régime de péage, les détails de facturation sont calculés au moyen des informations
collectées par l’exploitant de péage et/ou le fournisseur de service de péage (TSP) concerné. Ils sont
finalisés par l’exploitant de péage.
viii
L’exploitant de péage établit les demandes de paiement (ou demandes de paiement de péage) et les met
à la disposition de chaque fournisseur de service de péage ou demande au fournisseur de service de
péage d’envoyer les annonces de paiement, conformément aux accords bilatéraux passés avec chaque
fournisseur de service de péage, en se référant aux détails de facturation. Ces demandes de paiement
comprennent un montant dû tenant compte de toute condition commerciale spécifique applicable à un
véhicule, une flotte de véhicules ou un fournisseur de service de péage donné.
Le présent document définit un ensemble de messages échangés en vue de l’interopérabilité technique
des systèmes de back-office d’exploitants de péage et de fournisseurs de service de péage. Le service de
télépéage et le modèle de système de télépéage sur lesquels le présent document se fonde sont définis
dans l’ISO 17573-1.
Le présent document ne fournit pas une solution complète pour l’interopérabilité et il ne définit pas non
plus d’autres parties du système de télépéage, d’autres services, d’autres technologies ou des éléments
non techniques d’interopérabilité. Il se veut une Norme internationale de type «boîte à outils» pour
les unités de données de protocole d’application (APDU) pouvant être utilisées pour l’objectif prévu.
Les définitions détaillées des éléments obligatoires et facultatifs dans une mise en œuvre réelle sont
données par ailleurs. Le document ne définit pas toutes les séquences de communication, les piles de
communication et les délais.
Le développement d’un service européen de télépéage commun (SET) dans le cadre de la directive
européenne de perception électronique du télépéage déjà citée appelle également à la définition d’un
service de télépéage interopérable. Il convient de noter que la norme CEN/TS 16986 (appelée à être
révisée et à devenir une norme européenne) spécifie des profils d'application interopérable (IAP),
applicables sur la base du présent document. Ces profils définissent un ensemble cohérent spécifique
de transactions, de déclencheurs, de conditions, d'éléments de données, de mécanismes de transfert
et de fonctions de support pour un échange interopérable de données entre les systèmes centraux des
exploitants de péage et des fournisseurs de service de péage. La norme CEN/TS 16986 est en cohérence
avec la Spécification technique du SET et vise à la soutenir.
Le présent document identifie et spécifie l’ensemble des APDU échangées entre deux acteurs dans les
rôles de fournisseur de service de péage et d’exploitant de péage, tels que définis dans l’ISO 17573-1.
Pour spécifier ces interfaces, le présent document utilise la description Entreprise de l’environnement
de péage, ainsi que les interactions définies entre les catégories de rôles, telles que définies dans
l’ISO 17573-1. Cela en vue d’une spécification complète des données qui sont transférées entre ces
entités identifiées. De plus, certaines interfaces fonctionnelles sont identifiées et des interactions sont
définies en termes d’unités de données de protocole d’application.
ix
NORME INTERNATIONALE ISO 12855:2022(F)
Perception de télépéage — Échange d'informations entre
la prestation de service et la perception du péage
1 Domaine d’application
Le présent document spécifie:
— les interfaces entre les systèmes de back-office de perception de télépéage (EFC) pour les services
de transport associés aux véhicules, tels que la tarification des usagers de la route, le stationnement
et le contrôle d’accès;
— l’échange d’informations entre les systèmes centraux des deux rôles de prestataire de services et
d’exploitant de péage, par exemple:
— données liées à la perception (déclarations de péage, détails de facturation);
— données administratives; et
— données de confirmation;
— les mécanismes de transfert et fonctions de support;
— les objets d’informations, syntaxe et sémantique des données.
Le présent document est applicable à tout service lié à des véhicules et à toute technologie utilisée pour
la perception.
Les types de données et le codage associé aux éléments de données décrits à l’Article 6 sont définis
en Annexe A, à l’aide de la notation de syntaxe abstraite numéro un (ASN.1) conformément à
l’ISO/IEC 8824-1.
Le présent document spécifie les mécanismes de protocole de base sur lesquels des réalisations peuvent
spécifier et exécuter des transferts (transactions) complexes.
Le document ne spécifie pas, entre autres:
— toute communication entre l’exploitant de péage, ou le fournisseur de service de péage, et toute
autre partie prenante;
— toute communication entre éléments de l’exploitant de péage et du fournisseur de service de péage
ne faisant pas partie de la communication de back-office;
— les interfaces pour systèmes de télépéage destinés aux transports publics;
— tous transferts complexes (transactions), c’est-à-dire des séquences d’unités de données d’application
(ADU) pouvant éventuellement mettre en jeu plusieurs échanges d’unités de données de protocole
d’application (APDU);
— les processus concernant les paiements et les échanges de documents comptables fiscaux,
commerciaux ou juridiques; ni
— la définition des canaux de communication de services, des protocoles et des primitives de service
permettant de transférer les APDU.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 612, Véhicules routiers — Dimensions des automobiles et véhicules tractés — Dénominations et
définitions
ISO 639-1, Codes pour la représentation des noms de langue — Partie 1: Code alpha-2
ISO 1176, Véhicules routiers — Masses — Vocabulaire et codes
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de
pays
ISO 4217, Codes pour la représentation des monnaies
ISO 8583-1, Messages initiés par cartes de transaction financière — Spécifications d'échange de messages
— Partie 1: Messages, éléments de données et valeurs de code
ISO/IEC 8824-1, Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1) —
Partie 1: Spécification de la notation de base
ISO/IEC 8825-4, Technologies de l'information — Règles de codage ASN.1 — Partie 4: Règles de codage
XML (XER)
ISO/IEC 9594-8, Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Partie 8:
Titre manque
ISO/IEC 9797-1:2011, Technologies de l'information — Techniques de sécurité — Codes d'authentification
de message (MAC) — Partie 1: Mécanismes utilisant un chiffrement par blocs
ISO/IEC 10118-3, Techniques de sécurité IT — Fonctions de brouillage — Partie 3: Fonctions de brouillage
dédiées
ISO/IEC 11770-3, Sécurité de l'information — Gestion de clés — Partie 3: Mécanismes utilisant des
techniques asymétriques
ISO 13616-1, Services financiers — Numéro de compte bancaire international (IBAN) — Partie 1: Structure
de l'IBAN
ISO/IEC 14888-2:2008, Technologies de l'information — Techniques de sécurité — Signatures numériques
avec appendice — Partie 2: Mécanismes basés sur une factorisation entière
ISO 14906, Perception du télépéage — Définition de l’interface d’application relative aux communications
dédiées à courte portée
ISO/TS 17444-1, Perception du télépéage — Performance d'imputation — Partie 1: Métrique
ISO/TS 17573-2, Perception de télépéage – Architecture de systèmes pour le péage lié aux véhicules —
Partie 2: Vocabulaire
ISO/IEC 18033-2, Technologies de l'information — Techniques de sécurité — Algorithmes de chiffrement —
Partie 2: Chiffres asymétriques
ISO 19299, Perception de télépéage — Cadre de sécurité
ISO 20524-1:2020, Systèmes de transport intelligents — Fichiers de données géographiques (GDF) GDF5.1
— Partie 1: Données cartographiques partagées entre sources multiples et indépendantes des applications
IETF RFC 4347, Datagram Transport Layer Security, avril 2006
IETF RFC 5246, The Transport Layer Security (TLS) Protocol, août 2008
IETF RFC 5746, Transport Layer Security (TLS) Renegotiation Indication Extension, février 2010
IETF RFC 6040, Tunnelling of Explicit Congestion Notification, février 2013
Recommandation W3C Syntaxe et traitement des signatures XML Version 1.1
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l’ISO/TS 17573-2 s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
4 Symboles et abréviations
ADU données d’application [application data unit]
ANPR lecture automatique des plaques d’immatriculation [automatic number plate recognition]
(LAPI)
APCI information de contrôle de protocole d’application [application protocol control information]
APDU unité de données de protocole d’application [application protocol data unit]
BIC code d’identification bancaire [bank identifier code]
CCC communication de contrôle de conformité
CRL liste de révocation de certificats [certificate revocation list]
cXER règles canoniques de codage XML [canonical XML encoding rules]
DSRC communication dédiée à courte portée [dedicated short-range communication]
DST heure d’été [daylight saving time]
DTLS sécurité de la couche transport des datagrammes [datagram transport layer security]
EFC perception du télépéage [electronic fee collection]
FTP protocole de transfert de fichiers [file transfer protocol]
GDF fichier de données géographiques [geographical data file]
GNSS système mondial de navigation par satellite [global navigation satellite system]
HOT modulation de péage pour les véhicules à fort taux d'occupation [high occupancy tolling]
HTTPS protocole de transfert hypertexte sécurisé [hyper-text transfer protocol secure]
IANA autorité chargée de l’attribution des numéros d’adresse internet [internet assigned numbers
authority]
IBAN numéro de compte bancaire international [international bank account number]
ICC carte à circuit intégré [integrated circuit card]
IEC Commission électrotechnique internationale [International Electrotechnical Commission]
UIT Union internationale des télécommunications
LAC Communication de complément de localisation [localization augmentation communication]
LPN numéro d'immatriculation [licence plate number]
NMEA National Marine Electronics Association
OBE équipement embarqué [on-board equipment]
OBU unité embarquée [on-board unit]
OCSP protocole de vérification de certificat en ligne [online certificate status protocol]
OSI interconnexion de systèmes ouverts [open systems interconnection]
PAN numéro de compte personnel [personal account number]
QA assurance qualité [quality assurance]
RINEX format d’échange indépendant du récepteur [receiver independent exchange format]
RSA Rivest, Shamir et Adleman
RSE équipement en bord de route [roadside equipment]
SLA accord de niveau de service [service level agreement]
SMTP protocole simple de transfert de courrier [simple mail transfer protocol]
SU utilisateur du service [service user]
TC exploitant de péage [toll charger]
TLS sécurité de la couche transport [transport layer security]
TSP fournisseur de service de péage [toll service provider]
UTC temps universel coordonné [coordinated universal time]
TVA taxe sur la valeur ajoutée
VPN réseau privé virtuel [virtual private network]
VRM numéro d’immatriculation de véhicule [vehicle registration mark]
XER règles de codage XML [XML encoding rules]
NOTE RSA est un algorithme pour cryptographie à clé publique, également connue sous le nom de
cryptographie asymétrique.
5 Concepts d’architecture et échanges d’informations
5.1 Principaux rôles dans l’environnement de perception du péage
Le présent document repose sur l’ISO 17573-1.
L’ISO 17573-1 spécifie les quatre rôles principaux présentés à la Figure 2.
Figure 2 — Rôles dans l’environnement de perception du péage
Les échanges d'informations sont convenus entre l’exploitant de péage et le fournisseur de service de
péage, en tenant compte de la réglementation en matière de protection de la vie privée. Les échanges
d'informations nécessaires à l’exploitant de péage et au fournisseur de service de péage pour remplir
leurs rôles sont décrits dans le présent paragraphe.
5.2 Échange d’informations entre la perception du péage et la prestation
5.2.1 Généralités
L’échange d’informations entre les rôles de prestataire de services et d’exploitant de péage prend en
charge la fourniture des fonctionnalités suivantes, qui ont toutes pour base les services de système
de télépéage spécifiés dans l’ISO 17573-1. La Figure 3 donne une vue d’ensemble des fonctionnalités
prévues dans le présent document.
Figure 3 — Fonctionnalités du présent document (ISO 12855)
Ces fonctionnalités sont énumérées ci-dessous, dans l'ordre où elles figurent à l’Article 5:
— mécanismes de protocole de base;
— échange d'objets de confiance;
— fourniture de données de contexte d’EFC;
— fourniture d’une liste d’émetteurs de contrats;
— gestion de la liste des exceptions;
— transmission des déclarations de péage;
— transmission des détails de facturation;
— règlement des sommes dues:
— demande de paiement pour l’utilisation du service;
— annonce de paiements;
— échange de données de contrôle sanction:
— échange de coordonnées d’utilisateur;
— échange d’événements de communication de contrôle de conformité (CCC);
— échange de listes de UserId;
— traitement de réclamations d’utilisateur:
— fourniture d’une réclamation d'un utilisateur;
— réponse à une réclamation d'un utilisateur;
— échange de paramètres d’assurance qualité;
— fourniture de données de règlement au moyen de supports.
Le présent document laisse aux personnes chargées de l’implémentation la liberté de spécifier des
procédures de protocoles appropriées, c’est-à-dire pour des transactions complexes. C’est la raison
pour laquelle il se borne à spécifier:
— un protocole d’interaction de base (requête – réponse) pour l’échange d’informations;
— des mécanismes de protocole de base, à utiliser pour construire des procédures de protocole plus
complexes; et
— la sémantique et le format des APDU qui ont été échangées.
Ces fonctionnalités sont décrites dans les paragraphes 5.2.2 à 5.2.13.
5.2.2 Mécanismes de protocole de base
5.2.2.1 Approche générale
Les échanges d’informations ont lieu par l’intermédiaire de transferts d’unités de données de protocole
d’application (APDU – Application Protocol Data Unit).
Certains transferts APDU nécessitent un accusé de réception. Le cas échéant, des procédures de
protocoles connexes sont spécifiées. Le présent document ne spécifie aucune disposition pour les
transferts (transactions) complexes, c'est-à-dire des séquences d’ADU interdépendantes qui peuvent
impliquer plusieurs échanges d'APDU. Il spécifie en revanche des mécanismes de protocole de base à
utiliser dans le cadre des implémentations nécessitant la spécification et la réalisation de transactions.
Le présent document fournit les mécanismes de protocole de base suivants pour l'échange
d'informations entre le système central du fournisseur de service de péage et celui de l’exploitant de
péage. Ces mécanismes de protocole de base comprennent:
— un schéma d’identification pour les APDU échangées;
— une interaction générique (c’est-à-dire non liée à une fonctionnalité spécifique quelconque)
permettant de demander à l’autre partie d’effectuer un échange d’informations spécifique, cette
interaction étant assurée par l’ADU «request»;
— un mécanisme d’accusé de réception générique (c’est-à-dire non lié à une fonctionnalité spécifique
quelconque) permettant d’accuser réception d’un échange spécifique, l’ADU «ack» assurant ce
mécanisme; et
— un mécanisme de statut générique (c’est-à-dire non lié à une fonctionnalité spécifique quelconque)
facultatif permettant de fournir des informations de statut pour un échange spécifique, ce
mécanisme étant assuré par l’ADU «status».
À l’aide des mécanismes ci-dessus, une implémentation peut construire des procédures de
protocoles plus complexes, incluant les fonctionnalités rollback (annulation de transaction), recovery
(récupération), checkpoint (réalisation d’un point de contrôle) ou restart (redémarrage).
Le présent document ne spécifie pas les paramètres temporels ni les procédures de relance pour les
accusés de réception. Des temporisations peuvent être spécifiées sous forme d’accords entre l’exploitant
de péage et le fournisseur de service de péage pour couvrir les cas d’accusés de réception manquants.
5.2.2.2 Schéma d’identification
Chaque APDU contient un identifiant unique dans l’espace de noms de l’initiateur de l’APDU. La
combinaison de l’identifiant de l’initiateur et de l’identifiant de l’APDU garantit que toutes les APDU sont
identifiées de façon unique.
5.2.2.3 Fonctionnalité «request» (requête)
La fonctionnalité «request» sert à:
— avertir l’autre partie que l’on est prêt à accepter n’importe quel type d’échange d’informations;
— informer l’autre partie que l’on est prêt à accepter un type spécifique d’APDU, en indiquant le type
d’APDU que l’on est prêt à accepter;
— demander à l’autre partie de renvoyer une APDU spécifique, en indiquant le type et l’identifiant de
l’APDU; et
— demander des informations identifiées par le type et le contenu de l’APDU.
5.2.2.4 Fonctionnalité «acknowledgement» (accusé de réception)
La fonctionnalité «acknowledgement» sert à informer l’autre partie qu’une ADU spécifique a été reçue
correctement, ou que des erreurs ont été détectées.
5.2.2.5 Fonctionnalité «status» (statut)
Il est admis d’utiliser la fonctionnalité «status» pour fournir des informations générales sur le statut
de l’interface à l’autre partie ou l’informer du statut d’informations précédemment transférées. Elle est
utilisée pour:
— fournir des informations générales sur le statut de l’interface;
— avertir l’autre partie du fait que certaines informations précédemment fournies deviennent invalides
sans nouvelles informations actuellement disponibles; et
— avertir l’autre partie du fait que les informations précédentes contenaient une erreur et qu’il
convient de les rappeler.
5.2.3 Fonctionnalité «exchange trust objects» (échange d’objets de confiance)
La fonctionnalité d’échange d’objets de confiance est issue du service de système de télépéage «trust
object exchange» (échange d’objets de confiance). Cette fonctionnalité est utilisée chaque fois qu'une
entité, qu'il s'agisse d'un exploitant de péage ou d'un fournisseur de service de péage, a besoin d’envoyer
spontanément à l’autre partie de nouveaux objets de confiance ou des objets de confiance mis à jour, ou
lorsque l’autre partie lui demande de mettre à jour ou de renvoyer un objet de confiance déjà existant.
NOTE Exemples d’objets de confiance: clés publiques asymétriques, certificats, clés symétriques, listes de
révocation de certificats.
Le fait de demander à l’autre partie d’envoyer des objets de confiance se fait au moyen d’une ADU
«request». L’ADU «request» permet de demander de renvoyer des objets de confiance qui ont déjà été
émis, ainsi que de demander des objets de confiance nouvellement émis.
La fonctionnalité d’échange d'objets de confiance permet à l’ADU «trust objects» (objets de confiance)
de transférer les objets de confiance demandés ou nouvellement générés à l’autre partie, qui a la
possibilité de confirmer ou de rejeter les objets de confiance reçus en utilisant la fonctionnalité d'accusé
de réception.
Les objets de confiance échangés sont valides à partir du moment où ils ont donné lieu à accusé de
réception, ou bien à partir de la date de début de validité, dans la mesure où elle est spécifiée dans
l’ADU «trust object». Il est également admis que les objets de confiance deviennent valides sur la base
d’accords bilatéraux passés entre le fournisseur de service de péage et l’exploitant de péage (comme
défini dans la déclaration de conformité de mise en œuvre).
5.2.4 Fonctionnalité «originating and providing EFC context data» (création et fourniture de
données de contexte d’EFC)
La fonctionnalité de création et de fourniture de données de contexte d’EFC est issue de l’ISO 17573-1,
comme spécifié dans le service de système de télépéage «adding or modifying a toll regime» (ajout ou
modification d'un régime de péage).
La fonctionnalité de création et de fourniture de données de contexte d’EFC donne à un exploitant
de péage la possibilité de communiquer toute modification d'un domaine de péage ou d'un régime de
péage, y compris le début d'un nouveau domaine de péage, en émettant une ADU «EFC context data»
(données de contexte d’EFC).
Un fournisseur de service de péage a la possibilité de demander à un exploitant de péage de donner des
informations sur les données contextuelles de péage pour un domaine de péage sous sa responsabilité
au moyen d’une ADU «request». L’exploitant de péage donne les informations demandées par cette ADU
«request» au moyen d’une ADU «EFC context data».
Le fournisseur de service de péage a la possibilité de confirmer la réception d’une ADU «EFC context
data» en utilisant la fonctionnalité d’accusé de réception.
5.2.5 Fonctionnalité «provide contract issuer information» (fourniture d’informations sur
l'émetteur du contrat)
La fonctionnalité d'informations contractuelles permet à un fournisseur de service de péage de
fournir à l’exploitant de péage tout type d'informations liées au contrat d’utilisateur et stockées dans
l’équipement embarqué, parmi lesquelles le numéro de compte personnel (PAN), le niveau de sécurité
pris en charge et le jeu de clés à utiliser pour le calcul des authentifiants du système de communications
dédiées à courte portée (DSRC). Cette fonctionnalité permet, entre autres, à l’exploitant de péage de
comparer des données récupérées des OBE avec les informations reçues par le fo
...
NORME INTERNATIONALE
Date: 2022-0406
ISO/TC 204/SC /WG 5
Secrétariat: ANSI
Perception du télépéage — Échange d'informations entre la prestation de service et la
perception du péage
Electronic fee collection — Information exchange between service provision and toll charging
ISO 12855:2022(F)
© ISO 2022
Tous droits réservés. Sauf indication contraire ou autre spécification dans le cadre de sa mise en
œuvre, 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
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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Téléphone: +41 22 749 01 11
E-mail: copyright@iso.org
Site web: www.iso.orgwww.iso.org
Imprimé en Suisse
ii © ISO 2022 – Tous droits réservés
Sommaire
Avant-propos . v
Introduction . vii
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 3
4 Symboles et abréviations . 3
5 Concepts d’architecture et échanges d’informations. 5
5.1 Principaux rôles dans l’environnement de perception du péage . 5
5.2 Échange d’informations entre la perception du péage et la prestation . 5
5.2.1 Généralités . 5
5.2.2 Mécanismes de protocole de base . 7
5.2.3 Fonctionnalité «exchange trust objects» (échange d’objets de confiance) . 8
5.2.4 Fonctionnalité «originating and providing EFC context data» (création et fourniture de données de
contexte d’EFC) . 9
5.2.5 Fonctionnalité «provide contract issuer information» (fourniture d’informations sur l'émetteur du
contrat) . 9
5.2.6 Fonctionnalité «manage exception list» (gestion de la liste des exceptions) . 9
5.2.7 Fonctionnalité «report toll declarations» (transmission des déclarations de péage) . 10
5.2.8 Fonctionnalité «report billing details» (transmission des détails de facturation) . 11
5.2.9 Fonctionnalité «payment settlement» (règlement des sommes dues) . 12
5.2.10 Fonctionnalité «exchange enforcement data» (échange de données de contrôle sanction) . 13
5.2.11 Fonctionnalité «process user complaints» (traitement de réclamations d’utilisateur). 15
5.2.12 Fonctionnalité «exchange quality assurance parameters» (échange de paramètres d’assurance qualité)
............................................................................................................................................................................................................. 15
5.2.13 Fonctionnalité «provide media settlement data» (fourniture de données de règlement au moyen de
supports). 16
6 Spécification fonctionnelle par objets . 16
6.1 Vue d’ensemble . 16
6.2 Unités de données de protocole d’application . 20
6.2.1 Généralités . 20
6.2.2 Information de contrôle de protocole d’application (APCI) . 21
6.2.3 Unités de données d’application . 23
6.2.4 Identification des ADU . 24
6.2.5 Code d’action d’ADU . 24
6.2.6 Identification d’utilisateur . 24
6.3 Structure de données RequestAdu . 25
6.4 Structure de données AckAdu . 30
6.5 Structure de données StatusAdu . 38
6.6 Structure de données TrustObjectAdu . 38
6.7 Structure de données EfcContextDataAdu . 46
6.7.1 Généralités . 46
6.7.2 Type GeneralContextData . 47
6.7.3 Type MeshedContextData . 67
6.7.4 Structures de données communes . 79
6.8 Structure de données ContractIssuerListAdu . 106
6.9 Structure de données ExceptionListAdu . 108
6.10 Structure de données ReportAbnormalObeAdu . 113
6.11 Structure de données TollDeclarationAdu . 115
© ISO 2022 – Tous droits réservés iii
ISO 12855:2022(F)
6.12 Structure de données BillingDetailsAdu . 120
6.12.1 Généralités. 120
6.12.2 Type de données UsageList . 122
6.12.3 Types de données AssociatedEventData . 134
6.13 Structure de données PaymentClaimAdu . 140
6.14 Structure de données PaymentAnnouncementAdu . 143
6.15 Structure de données ProvideUserDetailsAdu . 146
6.16 Structure de données ReportCccEventAdu . 151
6.17 Structure de données ProvideUserIDListAdu . 152
6.18 Structure de données «Report QA». 153
6.19 Structure de données de réclamation d'un utilisateur . 154
6.20 Structure de données de réponse à la réclamation d'un utilisateur . 156
6.21 Structure de données de règlement au moyen d’un support . 157
7 Mécanismes de transfert et fonctions de support .159
7.1 Mécanismes de transfert . 159
7.2 Canal de communication sécurisé . 160
7.3 Fonctions de support . 160
7.3.1 Services de communication . 160
7.3.2 Authentifiants . 161
7.3.3 Signature et algorithmes de hachage . 162
7.3.4 Chiffrement des clés . 162
Annex A (normative) Spécifications des types de données .163
Annex B (informative) Exemple de processus de contrôle sanction appliquant des échanges d’APDU
normalisés .164
Annex C (informative) Exemple de flux de données dans un domaine de péage.169
Annex D (informative) Exemple de différences d’arrondi .172
Annex E (informative) Exemple de calcul de redevance à l’aide des données de contexte d’EFC .177
Bibliographie .182
Avant-propos . vii
Introduction . ix
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 3
4 Symboles et abréviations . 3
5 Concepts d’architecture et échanges d’informations . 5
5.1 Principaux rôles dans l’environnement de perception du péage . 5
5.2 Échange d’informations entre la perception du péage et la prestation. 7
5.2.1 Généralités. 7
5.2.2 Mécanismes de protocole de base . 9
5.2.3 Fonctionnalité «exchange trust objects» (échange d’objets de confiance) . 11
5.2.4 Fonctionnalité «originating and providing EFC context data» (création et fourniture de données de
contexte d’EFC) . 11
5.2.5 Fonctionnalité «provide contract issuer information» (fourniture d’informations sur l'émetteur du
contrat) . 11
5.2.6 Fonctionnalité «manage exception list» (gestion de la liste des exceptions) . 12
5.2.7 Fonctionnalité «report toll declarations» (transmission des déclarations de péage). 13
5.2.8 Fonctionnalité «report billing details» (transmission des détails de facturation) . 14
iv © ISO 2022 – Tous droits réservés
5.2.9 Fonctionnalité «payment settlement» (règlement des sommes dues) . 15
5.2.10 Fonctionnalité «exchange enforcement data» (échange de données de contrôle sanction) . 16
5.2.11 Fonctionnalité «process user complaints» (traitement de réclamations d’utilisateur). 17
5.2.12 Fonctionnalité «exchange quality assurance parameters» (échange de paramètres d’assurance qualité)
............................................................................................................................................................................................................. 18
5.2.13 Fonctionnalité «provide media settlement data» (fourniture de données de règlement au moyen de
supports). 18
6 Spécification fonctionnelle par objets . 19
6.1 Vue d’ensemble . 19
6.2 Unités de données de protocole d’application . 22
6.2.1 Généralités . 22
6.2.2 Information de contrôle de protocole d’application (APCI) . 24
6.2.3 Unités de données d’application . 26
6.2.4 Identification des ADU . 27
6.2.5 Code d’action d’ADU . 27
6.2.6 Identification d’utilisateur . 28
6.3 Structure de données RequestAdu . 28
6.4 Structure de données AckAdu . 33
6.5 Structure de données StatusAdu . 41
6.6 Structure de données TrustObjectAdu . 42
6.7 Structure de données EfcContextDataAdu . 50
6.7.1 Généralités . 50
6.7.2 Type GeneralContextData . 52
6.7.3 Type MeshedContextData . 73
6.7.4 Structures de données communes . 85
6.8 Structure de données ContractIssuerListAdu . 114
6.9 Structure de données ExceptionListAdu . 116
6.10 Structure de données ReportAbnormalObeAdu . 121
6.11 Structure de données TollDeclarationAdu . 123
6.12 Structure de données BillingDetailsAdu . 128
6.12.1 Généralités . 128
6.12.2 Type de données UsageList . 130
6.12.3 Types de données AssociatedEventData . 143
6.13 Structure de données PaymentClaimAdu . 150
6.14 Structure de données PaymentAnnouncementAdu . 153
6.15 Structure de données ProvideUserDetailsAdu . 156
6.16 Structure de données ReportCccEventAdu . 161
6.17 Structure de données ProvideUserIDListAdu . 162
6.18 Structure de données «Report QA» . 163
6.19 Structure de données de réclamation d'un utilisateur . 165
6.20 Structure de données de réponse à la réclamation d'un utilisateur . 167
6.21 Structure de données de règlement au moyen d’un support . 168
7 Mécanismes de transfert et fonctions de support. 170
7.1 Mécanismes de transfert . 170
7.2 Canal de communication sécurisé . 170
7.3 Fonctions de support . 171
7.3.1 Services de communication . 171
7.3.2 Authentifiants . 171
7.3.3 Signature et algorithmes de hachage . 173
7.3.4 Chiffrement des clés . 173
Annexe A (normative) Spécifications des types de données . 174
Annexe B (informative) Exemple de processus de contrôle sanction appliquant des échanges d’APDU
normalisés . 175
Annexe C (informative) Exemple de flux de données dans un domaine de péage . 183
© ISO 2022 – Tous droits réservés v
ISO 12855:2022(F)
Annexe D (informative) Exemple de différences d’arrondi .188
Annexe E (informative) Exemple de calcul de redevance à l’aide des données de contexte d’EFC .193
Bibliographie .198
vi © ISO 2022 – Tous droits réservés
Avant-propos
L’ISOL'ISO (Organisation internationale de normalisation) est une fédération mondiale
d’organismesd'organismes nationaux de normalisation (comités membres de l’ISO). L’élaborationl'ISO).
L'élaboration des Normes internationales est en général confiée aux comités techniques de l’ISOl'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,l'ISO participent également aux travaux. L’ISOL'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’approbationd'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 définiesdonnées dans les Directives
ISO/IEC, Partie 2 (voir www.iso.org/directives).
L'attention est appeléeattiré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’ISOL'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’élaborationl'élaboration du document sont indiqués dans l’Introductionl'Introduction et/ou
dans la liste des déclarations de brevets reçues par l’ISOl'ISO (voir www.iso.org/patentsbrevets).
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 nature volontaire des normes, de la signification des termes et expressions
spécifiques de l’ISOl'ISO liés à l’évaluationl'évaluation de la conformité, ou pour toute information au
sujet de l’adhésionl'adhésion de l’ISOl'ISO aux principes de l’Organisation mondiale du commerce
(OMC) concernant les obstacles techniques au commerce (OTC), voir le lien suivant:
www.iso.org/iso/foreword.htmlavant-propos.
CeLe présent document a été élaboré par le Comitécomité technique ISO/TC 204, Systèmes de transport
intelligents, en collaboration avec le Comitécomité technique CEN/TC 278, Systèmes de transport
intelligents, du Comité européen de normalisation (CEN),) conformément à l’Accord de coopération
technique entre l’ISO et le CEN (Accord de Vienne).
Cette troisième édition annule et remplace la deuxième édition (ISO 12855:2015), qui a fait l'objet
d'unel’objet d’une révision technique.
Les principales modifications sont les suivantes:
— ajout de nouvelles unités de données d’application (ADU);
— alignement des définitions de données ASN.1 avec l’édition actuelle de l’ISO 14906;
— suppression de toutes les dépendances par rapport aux types de données ASN.1 de la série
ISO 17575 et création des définitions correspondantes;
— reclassification des types de contexte de perception de télépéage (EFC) en fonction du péage et des
caractéristiques géographiques et suppression de la distinction qui était faite précédemment sur la
base de la technologie de péage;
© ISO 2022 – Tous droits réservés vii
ISO 12855:2022(F)
— scission du module ASN.1 en deux modules : un premier qui contient les définitions propres à
l’ISO 12855 et un autre qui contient les définitions des types de données communs aux autres
normes du domaine télépéage. Ce module de données communes a été déplacé vers la norme
ISO/TS 17573--3 ;
— clarification de de la sémantique de tous les paramètres des ADU;
— alignement de la structure des paragraphes les plus importants de manière cohérente afin d'en
améliorer la lisibilité.
Il convient d’adresserque l’utilisateur adresse tout commentaireretour d’information ou toute question
à propos duconcernant le présent document à l’organisme national de normalisation national de
l’utilisateurson pays. Une liste complète de cesexhaustive desdits organismes est disponiblese trouve à
l’adresse www.iso.org/members.htmlwww.iso.org/fr/members.html.
viii © ISO 2022 – Tous droits réservés
Introduction
L’utilisation répandue du péage routier nécessite des dispositions pour les utilisateurs de véhicules qui
circulent dans différents domaines de péage. Il convient de proposer aux usagers un contrat unique
pour conduire un véhicule sur plusieurs domaines de péage. Lorsque les véhicules ont besoin d’un
équipement embarqué (OBE), il convient que ce dernier soit interopérable avec les systèmes de péage
des différents domaines de péage. En Europe, par exemple, ce besoin a été officiellement reconnu et une
[ [8] ]
législation de l’interopérabilité a déjà été adoptée (voir la Directive 2019/520 , , le Règlement délégué
[10]
2020/2003 de la Commission qui s’y rapporte et le Règlement d'application 2020/204 de la
[9]
Commission ). Les normes internationales au service de l’interopérabilité des équipements embarqués
et des systèmes de péage sont justifiées tant du point de vue commercial que du point de vue
économique.
L’architecture des systèmes définie dans l’ISO 17573--1 forme la base de toutes les normes
internationales relatives aux systèmes de péage dans le domaine du péage. Vis-à-vis de l'ISO 17573--1,
le présent document:
— adopte ses définitions de termes et de concepts ainsi que les fonctionnalités et la structure du
système de base;
— utilise sa terminologie; et
— précise les interfaces mentionnées dans le document.
L'ISO 17573--1 utilise l’ISO/IEC 10746-3 pour la description de l’architecture.
La Figure 1 présente le domaine d’application du groupe de normes internationales relatives à la
perception de télépéage (EFC) sur la base de l’architecture de système de l’ISO 17573--1.
© ISO 2022 – Tous droits réservés ix
ISO 12855:2022(F)
x © ISO 2022 – Tous droits réservés
Légende
DSRC Communicationcommunication dédiée à courte portée
QA Assuranceassurance qualité
RSE Équipementequipement en bord de route
Figure 1 — Domaine d’application des normes internationales relatives à la perception de
télépéage
Un service de transport donné pour un véhicule donné est entièrement identifié par une ou plusieurs
déclarations de péage mises à la disposition de l’exploitant de péage (TC). Il est nécessaire de rendre
disponibles les déclarations de péage conformément aux règles du régime de péage du domaine de
péage.
Le montant dû pour un service de transport donné utilisé par un véhicule soumis au paiement du péage
est finalisé par l’exploitant de péage (TC) à l’aide d’une ou plusieurs déclarations de péage (tel que cela
est décrit ci-dessus) et les calculs sont effectués conformément aux règles du régime de péage (formule,
tableaux tarifaires, règles pour les situations spécifiques, conditions de trafic, etc.). Cela signifie que
l’exploitant de péage a l’autorité de décider du montant dû, même s’il décide d’attribuer au fournisseur
de service de péage la tâche de calculer le montant dû.
Ces informations, associées à un service de transport donné, sont appelées «détails de facturation».
Pour un service de transport donné, les détails de facturation font référence à une ou plusieurs
déclarations de péage.
© ISO 2022 – Tous droits réservés xi
ISO 12855:2022(F)
En fonction du régime de péage, les détails de facturation sont calculés au moyen des informations
collectées par l’exploitant de péage et/ou le fournisseur de service de péage (TSP) concerné. Ils sont
finalisés par l’exploitant de péage.
L’exploitant de péage établit les demandes de paiement (ou demandes de paiement de péage) et les met
à la disposition de chaque fournisseur de service de péage ou demande au fournisseur de service de
péage d’envoyer les annonces de paiement, conformément aux accords bilatéraux passés avec chaque
fournisseur de service de péage, en se référant aux détails de facturation. Ces demandes de paiement
comprennent un montant dû tenant compte de toute condition commerciale spécifique applicable à un
véhicule, une flotte de véhicules ou un fournisseur de service de péage donné.
Le présent document définit un ensemble de messages échangés en vue de l’interopérabilité technique
des systèmes de back-office d’exploitants de péage et de fournisseurs de service de péage. Le service de
télépéage et le modèle de système de télépéage sur lesquels le présent document se fonde sont définis
dans l’ISO 17573--1.
Le présent document ne fournit pas une solution complète pour l’interopérabilité et il ne définit pas non
plus d’autres parties du système de télépéage, d’autres services, d’autres technologies ou des éléments
non techniques d’interopérabilité. Il se veut une normeNorme internationale de type «boîte à outils»
pour les unités de données de protocole d’application (APDU) pouvant être utilisées pour l’objectif
prévu. Les définitions détaillées des éléments obligatoires et facultatifs dans une mise en œuvre réelle
sont données par ailleurs. Le document ne définit pas toutes les séquences de communication, les piles
de communication et les délais.
Le développement d’un service européen de télépéage commun (SET) dans le cadre de la directive
européenne de perception électronique du télépéage déjà citée appelle également à la définition d’un
service de télépéage interopérable. Il convient de noter que la norme CEN/TS 16986 (appelée à être
révisée et à devenir une norme européenne) spécifie des profils d'application interopérable (IAP),
applicables sur la base du présent document. Ces profils définissent un ensemble cohérent spécifique de
transactions, de déclencheurs, de conditions, d'éléments de données, de mécanismes de transfert et de
fonctions de support pour un échange interopérable de données entre les systèmes centraux des
exploitants de péage et des fournisseurs de service de péage. La norme CEN/TS 16986 est en cohérence
avec la spécificationSpécification technique du SET et vise à la soutenir.
Le présent document identifie et spécifie l’ensemble des APDU échangées entre deux acteurs dans les
rôles de fournisseur de service de péage et d’exploitant de péage, tels que définis dans l’ISO 17573--1.
Pour spécifier ces interfaces, le présent document utilise la description Entreprise de l’environnement
de péage, ainsi que les interactions définies entre les catégories de rôles, telles que définies dans
l’ISO 17573--1. Cela en vue d’une spécification complète des données qui sont transférées entre ces
entités identifiées. De plus, certaines interfaces fonctionnelles sont identifiées et des interactions sont
définies en termes d’unités de données de protocole d’application.
xii © ISO 2022 – Tous droits réservés
NORME INTERNATIONALE ISO 12855:2022(F)
Perception du télépéage — Échange d'informations entre la
prestation de service et la perception du péage
1 Domaine d’application
Le présent document spécifie:
— les interfaces entre les systèmes de back-office de perception de télépéage (EFC) pour les services
de transport associés aux véhicules, tels que la tarification des usagers de la route, le stationnement
et le contrôle d’accès;
— l’échange d’informations entre les systèmes centraux des deux rôles de prestataire de services et
d’exploitant de péage, par exemple:
— données liées à la perception (déclarations de péage, détails de facturation);
— données administratives; et
— données de confirmation;
— les mécanismes de transfert et fonctions de support;
— les objets d’informations, syntaxe et sémantique des données.
Le présent document est applicable à tout service lié à des véhicules et à toute technologie utilisée pour
la perception.
Les types de données et le codage associé aux éléments de données décrits à l’articlel’Article 6 sont
définis en Annexe A, à l’aide de la notation de syntaxe abstraite numéro un (ASN.1) conformément à
l’ISO/IEC 8824-1.
Le présent document spécifie les mécanismes de protocole de base sur lesquels des réalisations
peuvent spécifier et exécuter des transferts (transactions) complexes.
Le document ne spécifie pas, entre autres:
— toute communication entre l’exploitant de péage, ou le fournisseur de service de péage, et toute
autre partie prenante;
— toute communication entre éléments de l’exploitant de péage et du fournisseur de service de péage
ne faisant pas partie de la communication de back-office;
— les interfaces pour systèmes de télépéage destinés aux transports publics;
— tous transferts complexes (transactions), c’est-à-dire des séquences d’unités de données
d’application (ADU) pouvant éventuellement mettre en jeu plusieurs échanges d’unités de données
de protocole d’application (APDU);
© ISO 2022 – Tous droits réservés 11
— les processus concernant les paiements et les échanges de documents comptables fiscaux,
commerciaux ou juridiques; ni
— la définition des canaux de communication de services, des protocoles et des primitives de service
permettant de transférer les APDU.
2 Références normatives
Les documents suivants sont mentionnéscités dans le texte d’une manière telle quede sorte qu’ils
constituent, pour tout ou partie de leur contenu constitue les, des exigences 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’appliques'applique (y compris les éventuels amendements).
ISO 612, Véhicules routiers — Dimensions des automobiles et véhiculésvéhicules tractés — Dénominations
et définitions
ISO 639-1, Codes pour la représentation des noms de langueslangue — Partie 1 : code: Code alpha-2
ISO 1176, Véhicules routiers — Masses — Vocabulaire et codes
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de
pays
ISO 4217, Codes pour la représentation des monnaies
ISO 8583-1, Messages initiés par cartes de transaction financière — Spécifications d'échange de messages
— Partie 1: Messages, éléments de données et valeurs de code
ISO/IEC 8824-1, Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1) —
Partie 1: Spécification de la notation de base
ISO/IEC 8825-4, Technologies de l’informationl'information — Règles de codage ASN.1 — Partie 4:
Règles de codage XML (XER)
ISO/IEC 9594-8, Technologies de l’informationl'information — Interconnexion de systèmes ouverts (OSI)
— L’annuaire — Partie 8: L’annuaire: Cadre général des certificats de clé publique et d’attributTitre
manque
ISO/IEC 9797-1:2011, Technologies de l'information — Techniques de sécurité — Codes
d'authentification de message (MAC) — Partie 1: Mécanismes utilisant un chiffrement par blocs
ISO/IEC 10118-3, Techniques de sécurité IT — Fonctions de brouillage — Partie 3: Fonctions de
brouillage dédiées
ISO/IEC 11770-3, Sécurité de l'information — Gestion de clés — Partie 3: Mécanismes utilisant des
techniques asymétriques
ISO 13616-1, Services financiers — Numéro de compte bancaire international (IBAN) — Partie 1:
Structure de l'IBAN
ISO/IEC 14888-2:2008, Technologies de l’informationl'information — Techniques de sécurité —
Signatures numériques avec appendice — Partie 2: Mécanismes basés sur une factorisation entière
2 © ISO 2022 – Tous droits réservés
ISO 14906, Perception du télépéage — Définition de l’interface d’application relative aux communications
dédiées à courte portée
ISO/TS 17444-1, Perception du télépéage — Performance d’imputation d'imputation — Partie 1:
Métrique
ISO/TS 17573-2, Perception dude télépéage — – Architecture de systèmes pour le péage lié aux
véhicules — Partie 2 : Vocabulaire
ISO/IEC 18033-2, Technologies de l’informationl'information — Techniques de sécurité — Algorithmes de
chiffrement — Partie 2 : Chiffres asymétriques
ISO 19299, Perception de télépéage — Cadre de sécurité
ISO 20524-1:2020, Systèmes de transport intelligents — Fichiers de données géographiques (GDF) GDF5.1
— Partie 1: Données cartographiques partagées entre sources multiples et indépendantes des applications
IETF RFC 4347, Datagram Transport Layer Security, avril 2006
IETF RFC 5246, The Transport Layer Security (TLS) Protocol, août 2008
IETF RFC 5746, Transport Layer Security (TLS) Renegotiation Indication Extension, février 2010
IETF RFC 6040, Tunnelling of Explicit Congestion Notification, février 2013
Recommandation W3C Syntaxe et traitement des signatures XML Version 1.1
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions donnés dansde l’ISO/TS 17573--2
s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques, destinées à être utilisées dans les
activités de en normalisation, consultables aux adresses suivantes ::
— Plateforme de navigation en ligne de l’ISO — ISO Online browsing platform: disponible à l’adresse
h
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...