ISO 17575-2:2016
(Main)Electronic fee collection — Application interface definition for autonomous systems — Part 2: Communication and connection to the lower layers
Electronic fee collection — Application interface definition for autonomous systems — Part 2: Communication and connection to the lower layers
ISO 17575-2:2016 defines how to convey all or parts of the data element structure defined in other parts of ISO 17575 over any communication stack and media suitable for this application. It is applicable only to mobile communication links (although wired links, i.e. back office connections, can use the same methodology). To establish a link to a sequence of service calls initializing the communication channel, addressing the reception of the message and forwarding the payload are required. The definition provided in this part of ISO 17575 includes the required communication medium independent services, represented by an abstract application programming interface (API). The communication interface is implemented as an API in the programming environment of choice for the Front End (FE) system. The specification of the Back End (BE) API is outside the scope of this part of ISO 17575. The definition of this API in concrete terms is outside of the scope of this part of ISO 17575. This part of ISO 17575 specifies an abstract API that defines the semantics of the concrete API as illustrated in Figure 3 and its protocol implementation conformance statement (PICS) proforma (see Annex B). An example of a concrete API is presented in Annex C. Where no distinction is made between the abstract and concrete communications APIs, the term "communications API" or just "API" can be used. ISO 17575-2:2016 also provides a detailed specification for the structure of associated API statements, an example on how to implement it and its role in a complex toll cluster such as the EETS (see Annex A to Annex E). Media selection policies, certificate handling and encryption mechanisms are outside of the scope of this part of ISO 17575.
Perception du télépéage — Définition de l'interface d'application pour les systèmes autonomes — Partie 2: Communications et connexions aux couches basses
ISO 17575-2:2016 définit comment transposer tout ou partie de la structure des éléments de données définis dans les autres parties de l'ISO 17575 via une pile de communication et des supports adaptés à cette application. Elle s'applique uniquement aux liaisons de communication mobile (bien que les liaisons filaires, comme celles de back-office, puissent utiliser la même méthode). Pour établir une liaison avec une séquence d'appels de service initialisant le canal de communication, la réception du message et le réacheminement de la charge doivent être gérés. La définition fournie dans la présente partie de l'ISO 17575 englobe les services indépendants du support de communication; ils sont représentés par une interface de programmation d'application (API). L'interface de communication est implémentée dans l'environnement de programmation choisi pour le système frontal (FE, Front End) sous la forme d'une API. La spécification de l'API du système central (BE, Back End) n'entre pas dans le cadre de la présente partie de l'ISO 17575. La définition de cette API en termes concrets n'entre pas dans le cadre de la présente partie de l'ISO 17575. La présente partie de l'ISO 17575 spécifie une API abstraite qui définit la sémantique de l'API concrète comme illustré à la Figure 3 et son formulaire de déclaration de conformité d'implémentation de protocole (PICS, Protocol Implementation Conformance Statement) comme décrit à l'Annexe B. L'Annexe C fournit un exemple d'API concrète. Aucune distinction n'étant faite entre les API de communication abstraites et concrètes, les termes « API de communication » ou simplement « API » peuvent s'utiliser indifféremment. ISO 17575-2:2016 fournit également une spécification détaillée de la structure des déclarations API associées, un exemple de la manière de l'implémenter, ainsi que son rôle dans un groupe de péage complexe tel que le SET (voir Annexe A à Annexe E). Les règles de sélection des supports et les mécanismes de chiffrement et de gestion des certificats n'entrent pas dans le cadre de la présente partie de l'ISO 17575.
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 17575-2
First edition
2016-01-15
Electronic fee collection —
Application interface definition for
autonomous systems —
Part 2:
Communication and connection to
the lower layers
Perception du télépéage — Définition de l’interface d’application pour
les systèmes autonomes —
Partie 2: Communications et connexions aux couches basses
Reference number
ISO 17575-2:2016(E)
©
ISO 2016
---------------------- Page: 1 ----------------------
ISO 17575-2:2016(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 17575-2:2016(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Terms and definitions . 2
3 Abbreviated terms . 3
4 EFC Front End communication architecture . 4
4.1 General . 4
4.2 Relationship with the overall EFC architecture . 5
5 EFC communication services (functions) . 5
5.1 General concept . 5
5.2 Initialization phase . 7
5.2.1 General. 7
5.2.2 Incoming (BE to FE Application) session request . 7
5.2.3 Outgoing (FE Application to BE) session establishment . 8
5.3 Point-to-point communication service primitives . 8
5.3.1 General. 8
5.3.2 Unstructured messages (ADUs) . 8
5.3.3 Structured messages (ADUs) . 8
5.4 Session end . 8
5.5 Session failure . 9
5.6 Security considerations . 9
5.7 Media selection options . 9
6 The use of a communication stack . 9
6.1 General . 9
6.2 Requirements for an underlying communication technology . 9
6.3 Mobile terminated calls .10
Annex A (normative) Abstract API definition .11
Annex B (normative) Protocol implementation conformance statement (PICS) proforma .17
Annex C (informative) API requirements .22
Annex D (informative) Examples of definitions for appropriate languages.23
Annex E (informative) Use of this part of ISO 17575 for the EETS .26
Bibliography .28
© ISO 2016 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 17575-2:2016(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
This edition of ISO 17575-2 cancels and replaces ISO/TS 17575-2:2010, which has been technically
revised. The following changes have been made:
— conversion from a Technical Specification to an International Standard;
— editorial and formal corrections as well as changes to improve readability.
ISO 17575 consists of the following parts, under the general title Electronic fee collection — Application
interface definition for autonomous systems:
— Part 1: Charging
— Part 2: Communication and connection to the lower layers
— Part 3: Context data
In this edition of the ISO 17575-series the contents of ISO/TS 17575-4:2011 were incorporated into
ISO 17575-3:2016. ISO/TS 17575-4:2011 will be withdrawn once ISO 17575-3 has been published.
iv © ISO 2016 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 17575-2:2016(E)
Introduction
0.1 Autonomous systems
ISO 17575 is a series of standards defining the information exchange between the Front End and the
Back End in electronic fee collection (EFC) based on autonomous on-board equipment (OBE). EFC
systems automatically collect charging data for the use of road infrastructure including motorway
tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels, distance-
based charging and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-
area technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Networks (CN).
These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, the terms GPS/GSM systems and wide-area charging systems are also in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such
as gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map
containing the charged geographic objects, such as charged roads or charged areas. From the charged
objects, the vehicle characteristics, the time of day and other data that are relevant for describing road
use, the tariff and ultimately the road usage fee are determined.
Two strengths of the autonomous approach to electronic fee collection are its flexibility, allowing
the implementation of almost all conceivable charging principles, and its independence from local
infrastructure, thereby predisposing this technology towards interoperability across charging systems
and countries. Interoperability can only be achieved with clearly defined interfaces, which is the aim
and justification of ISO 17575.
0.2 Business architecture
This part of ISO 17575 complies with the business architecture defined in ISO 17573. According to this
architecture, the toll charger is the provider of the road infrastructure and, hence, the recipient of the
road usage charges. The toll charger is the actor associated with the toll charging role (see Figure 1).
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
Figure 1 — The role-based model underlying ISO 17575
Service providers issue OBE to the users of the road infrastructure. Service providers are responsible
for operating OBE that will record the amount of road usage in all toll charging systems the vehicle
passes through and for delivering the charging data to the individual toll chargers. In general, each
service provider delivers charging data to several toll chargers and, in general, each toll charger
receives charging data from more than one service provider. Interoperability management, as shown in
Figure 1, comprises all specifications and activities that define and maintain a set of rules that govern
the overall toll charging environment.
© ISO 2016 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO 17575-2:2016(E)
0.3 Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects
the fact that some processing functionalities can either be allocated to the OBE or to an associated off-
board component (proxy). An example of processing functionality that can be realized either on- or off-
board is map-matching, where the vehicle locations in terms of measured coordinates from GNSS are
associated to geographic objects on a map that either reside on- or off-board. Also, the computation of
tariffs can be done with OBE tariff tables and processing, or with an off-board component.
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Back End
Front End
Road Usage Data
Context Data
Figure 2 — Assumed technical architecture and interfaces
The combined functionality of OBE and proxy is denoted as Front End. A Front End implementation
where processing is predominately on the OBE-side is known as a smart client (or intelligent client,
fat client) or edge-heavy. A Front End where processing is mostly done off-board is denoted as thin-
client or edge-light architecture. Many implementations between the “thin” and “thick” extremes are
possible, as depicted by the gradual transition in the wedges in Figure 2. Both extremes of architectural
choice have their merits and are one means where manufacturers compete with individual allocations
of functionality between on-board and central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the
transfer of localization data between OBE and off-board components, where proprietary algorithms are
used for data reduction and data compression. Standardization of this transfer is neither fully possible
nor beneficial.
0.4 Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices,
the primary scope of ISO 17575 is the data exchange between Front End and Back End (see the
corresponding vertical line in Figure 2). For every toll regime, the Back End will send context data, i.e.
a description of the toll regime in terms of charged objects, charging rules and, if required, the tariff
scheme to the Front End, and will receive usage data from the Front End.
It has to be noted also that the distribution of tasks and responsibilities between service provider and
toll charger will vary individually. Depending on the local legal situation, toll chargers will require
“thinner” or “thicker” data, and might or might not leave certain data processing tasks to service
providers. Hence, the data definitions in ISO 17575 may be useful on several interfaces.
vi © ISO 2016 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 17575-2:2016(E)
ISO 17575 also provides for basic media-independent communication services that may be used for
communication between Front End and Back End, which might be line-based or an air-link, and can also
be used for the air-link between OBE and central communication server.
0.5 The parts of ISO 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End.
The contents of charge reports might vary between toll regimes, hence, attributes for all requirements
are offered, ranging from attributes for raw localization data, for map-matched geographic objects and
for completely priced toll transactions. A toll regime comprises a set of rules for charging, including the
charged network, the charging principles, the liable vehicles and a definition of the required contents of
the charge report.
Part 2: Communication and connection to lower layers, defines basic communication services for data
transfer over the OBE air-link or between Front End and Back End. The data defined in ISO 17575-1 and
ISO 17575-3 can but need not be exchanged using the communication stack as defined in ISO 17575-2.
Part 3: Context data, defines the data to be used for a description of individual charging systems in
terms of charged geographical objects and charging and reporting rules. For every toll charger’s system,
attributes as defined in ISO 17575-3 are used to transfer data to the Front End in order to instruct it on
which data to collect and report.
0.6 Application needs covered by ISO 17575
The ISO 17575 series of standards
— is compliant with the architecture defined in ISO 17573:2010,
— supports charges for use of road sections (including bridges, tunnels, passes, etc.), passage of
cordons (entry/exit) and use of infrastructure within an area (distance, time),
— supports fee collection based on units of distance or duration, and based on occurrence of events,
— supports modulation of fees by vehicle category, road category, time of usage and contract type (e.g.
exempt vehicles, special tariff vehicles, etc.),
— supports limiting of fees by a defined maximum per period of usage,
— supports fees with different legal status (e.g. public tax, private toll),
— supports differing requirements of different toll chargers, especially in terms of
— geographic domain and context descriptions,
— contents and frequency of charge reports,
— feedback to the driver (e.g. green or red light), and
— provision of additional detailed data on request, e.g. for settling of disputes,
— supports overlapping geographic toll domains,
— supports adaptations to changes in
— tolled infrastructure,
— tariffs, and
— participating regimes, and
— supports the provision of trust guarantees by the service provider to the toll charger for the data
originated from the Front End.
© ISO 2016 – All rights reserved vii
---------------------- Page: 7 ----------------------
INTERNATIONAL STANDARD ISO 17575-2:2016(E)
Electronic fee collection — Application interface definition
for autonomous systems —
Part 2:
Communication and connection to the lower layers
1 Scope
This part of ISO 17575 defines how to convey all or parts of the data element structure defined in other
parts of ISO 17575 over any communication stack and media suitable for this application. It is applicable
only to mobile communication links (although wired links, i.e. back office connections, can use the same
methodology).
To establish a link to a sequence of service calls initializing the communication channel, addressing the
reception of the message and forwarding the payload are required. The definition provided in this part
of ISO 17575 includes the required communication medium independent services, represented by an
abstract application programming interface (API).
The communication interface is implemented as an API in the programming environment of choice for
the Front End (FE) system. The specification of the Back End (BE) API is outside the scope of this part
of ISO 17575.
The definition of this API in concrete terms is outside of the scope of this part of ISO 17575. This part
of ISO 17575 specifies an abstract API that defines the semantics of the concrete API as illustrated in
Figure 3 and its protocol implementation conformance statement (PICS) proforma (see Annex B). An
example of a concrete API is presented in Annex C. Where no distinction is made between the abstract
and concrete communications APIs, the term “communications API” or just “API” can be used.
Front End Application
7. Application
Communications
API
6. Presentation
Communications
Subsystem 5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Figure 3 — Scope of this part of ISO 17575
This part of ISO 17575 also provides a detailed specification for the structure of associated API
statements, an example on how to implement it and its role in a complex toll cluster such as the EETS
(see Annex A to Annex E).
© ISO 2016 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO 17575-2:2016(E)
Media selection policies, certificate handling and encryption mechanisms are outside of the scope of
this part of ISO 17575.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
attribute
addressable package of data consisting of a single data element or structured sequences of data elements
[SOURCE: ISO 17575-1:2016, 3.2]
2.2
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
2.3
Back End
BE
part of a back office system interfacing to one or more Front Ends (2.6)
[SOURCE: ISO 17575-1:2016, 3.4]
2.4
data element
coded information, which might itself consist of lower level information structures
[SOURCE: ISO 17575-1:2016, 3.9]
2.5
data integrity
property that data has not been altered or destroyed in an unauthorized manner
2.6
Front End
FE
part of a tolling system consisting of an OBE (2.9) and possibly a proxy (2.10) where road tolling
information and usage data are collected and processed for delivery to the Back End (2.3)
[SOURCE: ISO/TS 19299:2015, 3.17]
Note 1 to entry: The Front End comprises the on-board equipment (2.9) and an optional proxy (2.9).
2.7
Front End application
part of the Front End above the API
2.8
interoperability
ability of systems to exchange information and to make mutual use of the information that has
been exchanged
[SOURCE: ISO/IEC/TR 10000-1:1998, 3.2.1, modified.]
2 © ISO 2016 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 17575-2:2016(E)
2.9
on-board equipment
OBE
all required equipment on-board a vehicle for performing required EFC functions and
communication services
Note 1 to entry: Other sub-units should be considered optional.
2.10
proxy
optional part of a Front End (2.6) that communicates with external equipment and processes the data
received into an agreed format to be delivered to the Back End (2.3)
[SOURCE: ISO 17575-1:2016, 3.13]
2.11
service primitive
elementary communication service provided by the application layer protocol to the application processes
Note 1 to entry: The invocation of a service primitive by an application process implicitly calls upon and uses
services offered by the lower protocol layers.
[SOURCE: ISO 14906:2011, 3.18, modified — the subject has been deleted.]
2.12
toll service provider
entity providing toll services in one or more toll domains
[SOURCE: ISO 17573:2010, 3.23, modified — the definition has been condensed.]
2.13
toll
charge, tax or duty levied in connection with using a vehicle in a toll domain
[SOURCE: ISO/TS 19299:2015, 3.42, modified — “any” has been deleted from before “charge”.]
Note 1 to entry: The definition is the generalization of the classic definition of a toll as a charge, a tax, or a duty
for permission to pass a barrier or to proceed along a road, over a bridge, etc. The definition also includes fees
regarded as an (administrative) obligation, e.g. a tax or a duty.
2.14
toll charger
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO 17573:2010, 3.16, modified — “legal” has been deleted from before “entity” and “the use
of” has been added.]
3 Abbreviated terms
For the purpose of this document, the following abbreviated terms apply unless otherwise specified.
ADU Application data unit (ISO 14906)
APDU Application protocol data unit (ISO 14906)
AP Application process (ISO 14906)
API Application programming interface
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
© ISO 2016 – All rights reserved 3
---------------------- Page: 10 ----------------------
ISO 17575-2:2016(E)
BE Back End
CN Cellular network
EID Element identifier (ISO 14906)
FE Front End
GNSS Global Navigation Satellite System
OBE On-board equipment (ISO 14906)
VAT Value added tax
4 EFC Front End communication architecture
4.1 General
A communications subsystem is required to establish the communication link between a Front End
(FE) and a Back End (BE) Application. It provides data transport for the tolling FE Application via the
communications session that takes part across the line shown in Figure 4. In cases where a proxy is
present in the FE system, the communications subsystem defines the communications between the BE
and the proxy. The link between the proxy and the on-board equipment (OBE) is out of the scope of
this part of ISO 17575. In cases where no proxy is present (the “smart client”), the communications
subsystem defines the communications between the OBE and the BE.
Front End Application
7. Application
UP API
Indications
Communications
API
DOWN API
Requests
6. Presentation
Communications
Subsystem 5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Figure 4 — Relationship between Application and Protocol Stack
The communications subsystem is further subdivided into two distinct components. The
communications API itself offers communications functionality to the FE Application. Below this is
the underlying communications technology, which provides the functionality that the API abstracts.
Although the API is independent of the underlying technology, it does place a number of functional
demands upon it. For this reason, the functional requirements on the underlying communications
technology are listed in 6.2.
4 © ISO 2016 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 17575-2:2016(E)
Some underlying technologies are more capable than others. In cases where a very capable technology
is in use, the code interfacing the API to the underlying technology will serve little more function than
a simple pass through. For more simplistic transport layer technologies the communications subsystem
will have to do considerably more.
It is expected that these APIs will be “reflected” in the BE such that FEs and BEs can communicate over
arbitrary bearer infrastructures. Details of the abstract API definitions are specified in Annex A. The
specification of the BE API is outside the scope of this part of ISO 17575.
4.2 Relationship with the overall EFC architecture
The communications API provides the lower layers of the interface shown in Figure 5. The API has no
semantic knowledge of the application data units (ADUs) it is carrying. It does differentiate between
“standard specific” and “arbitrary” ADUs but it has no semantic knowledge about what these mean
and simply carries them as transparent octet streams atop an arbitrary communication bearer that is
selected at runtime.
5 EFC communication services (functions)
5.1 General concept
The API carries two “types” of message (ADU): structured elements relating directly to the definitions
in other parts of ISO 17575, and unstructured elements, which are outside of the scope of this part of
ISO 17575 and receive no further consideration within it.
It is outside the scope of this part of ISO 17575 to identify the data elements for transmission and the
associated payload.
NOTE 1 The protocolVersion (part of ChargeReport) as defined in ISO 17575-1:2016 and
protocolVersion and tollContext (both part of aduHeader) as defined in ISO 17575-3:2016 can be useful
when implementing specific transaction(s).
The abstract API for the communications services can be implemented in any programming environment
that defines the concept of event delivery, allowing the API to report information or to deliver results of
operations to the FE Application. The general sequence of events is
— initialize and parameterize the communications interface,
— establish a communications session,
— transfer data in the context of the session,
— terminate the communications session, and
— de-initialize the communications interface.
In a normal case, the FE Application will initialize (a number of) communications interfaces when it
first starts. An active session is then established either as a direct action by the FE Application or in
response to an incoming request for a session from the BE. The flow of events through the lifetime are
shown in 5.2 to 5.7 and relevant definitions are given in Annex A.
© ISO 2016 – All rights reserved 5
---------------------- Page: 12 ----------------------
ISO 17575-2:2016(E)
Session R:Ended/
StartSession/
Ending
Starting
Unknown
Instance
R:Started/ EndSession/
InitialiseInstance/
R:ADUsReceived/
DropInstance/
ADUSent
R:ADURequest/
ADURequest
R:ReceiveADUsReq/
No
Session Awaiting
Session
ADU Con irm
Session RX
Idle
ADUs
R:SesstionRequest/
SessionRequest
R:UnformattedADU/
UnformattedADUReceived
EndSession/ R:ReceiveADUsEnd/ R:ADU/
ADUReceived
Error/ SendADUSetEnd/ R:Reject/
!ADUSendOK
Sending
SendADUSetStart/ SendUnformattedADU/
Errored
ADU
R:MessageSent/
ADUSent
Sending ADU Sending
R:Accept/
ADUSendOK Request Unformatted ADU
Figure 5 — Session state diagram
API calls down the communications stack fall into two classes: synchronous and asynchronous.
Synchronous calls giving results
...
DRAFT INTERNATIONAL STANDARD
ISO/DIS 17575-2
ISO/TC 204 Secretariat: ANSI
Voting begins on: Voting terminates on:
2013-12-12 2014-05-12
Electronic fee collection — Application interface definition
for autonomous systems —
Part 2:
Communication and connection to the lower layers
Perception du télépéage — Définition de l’interface d’application pour les systèmes autonomes —
Partie 2: Communications et connexions aux couches plus basses
[Revision of first edition (ISO/TS 17575-2:2010 )]
ICS: 35.240.60;03.220.20
ISO/CEN PARALLEL PROCESSING
This draft has been developed within the International Organization for
Standardization (ISO), and processed under the ISO lead mode of collaboration
as defined in the Vienna Agreement.
This draft is hereby submitted to the ISO member bodies and to the CEN member
bodies for a parallel five month enquiry.
Should this draft be accepted, a final draft, established on the basis of comments
received, will be submitted to a parallel two-month approval vote in ISO and
THIS DOCUMENT IS A DRAFT CIRCULATED
formal vote in CEN.
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
To expedite distribution, this document is circulated as received from the
IN ADDITION TO THEIR EVALUATION AS
committee secretariat. ISO Central Secretariat work of editing and text
BEING ACCEPTABLE FOR INDUSTRIAL,
composition will be undertaken at publication stage.
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 17575-2:2013(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2013
---------------------- Page: 1 ----------------------
ISO/DIS 17575-2:2013(E)
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as
permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract
from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO’s
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2013 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/DIS 17575-2
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviations . 4
5 EFC Front End communication architecture . 4
5.1 General . 4
5.2 Relations to the overall EFC architecture . 5
6 Initialize transactions . 5
6.1 General . 5
6.2 Addressing requested parts of a hierarchical data element structure . 6
6.3 Identifying payloads for transmission . 6
7 EFC communication services (functions) . 6
7.1 General concept . 6
7.2 Initialization phase . 7
7.2.1 General . 7
7.2.2 Incoming (BE to FE Application) Session Request . 8
7.2.3 Outgoing (FE Application to BE) session establishment . 8
7.3 Point-to-point communication service primitives . 8
7.3.1 General . 8
7.3.2 Unstructured messages (ADUs) . 9
7.3.3 Structured messages (ADUs) . 9
7.4 Session ending . 9
7.5 Session failure . 9
7.6 Security considerations . 9
7.7 Media selection options . 10
8 The use of a communication stack . 10
8.1 General . 10
8.2 Requirements on a underlying communication technology . 10
8.3 Mobile terminated calls . 10
Annex A (normative) Abstract API definition . 11
A.1 General . 11
A.2 Down API (Front End Application to communications stack) . 11
A.2.1 InitialiseInstance . 11
A.2.2 SetParameter . 11
A.2.3 GetParameter . 11
A.2.4 DeleteParameter . 12
A.2.5 StackAvail . 12
A.2.6 DropInstance . 12
A.2.7 StartSession . 12
A.2.8 EndSession . 13
A.2.9 SendUnformattedADU . 13
A.2.10 SendADUSetStart . 13
A.2.11 SendADU . 13
A.2.12 SendADUSetEnd . 14
A.2.13 CommsQuery . 14
iii
© ISO 2013 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/DIS 17575-2
A.3 Up API (Communications Stack to Front End Application).14
A.3.1 InstanceStateChange .14
A.3.2 UnformattedADUReceived .15
A.3.3 ADURequest .15
A.3.4 ADUReceived .15
A.3.5 ADUSent .15
A.3.6 ADUSendOK .15
A.3.7 SessionRequest .15
Annex B (normative) Protocol implementation conformance statement (PICS) proforma .16
B.1 Introduction .16
B.2 Transactions support .16
B.2.1 General .16
B.2.2 Support of the down API .16
B.2.3 Support of the Up API .18
B.3 Use of communication stacks .19
B.3.1 Supported communication stacks .19
B.4 Front End Storage capacity .20
B.4.1 Storage capacity for modules and contact details .20
B.4.2 Generic values .20
B.4.3 Security of communication .20
Annex C (informative) API requirements.21
C.1 Introduction .21
C.1.1 General .21
C.1.2 Non-functional requirements .21
C.1.3 Functional requirements .21
Annex D (informative) Examples of definitions for appropriate languages .22
D.1 General .22
D.2 API Definition in C.22
Annex E (informative) Example of message flow .25
Annex F (informative) Use of this standard for the EETS .26
F.1 General .26
F.2 Overall relationship between European standardisation and the EETS .26
F.3 European standardisation work supporting the EETS .26
F.4 Correspondence between this standard and the EETS .27
Bibliography .28
iv
© ISO 2013 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/DIS 17575-2
Foreword
- conversion from a Technical Specification to an International Standard
- editorial and formal corrections as well as changes to improve readability
- minor technical corrections
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 17575-2 was prepared by Technical Committee ISO/TC 204, Intelligent Transport Systems,
Subcommittee SC , and by Technical Committee CEN/TC 278, Intelligent Transport Systems in collaboration.
This second/third/. edition cancels and replaces the first/second/. edition (), [clause(s) / subclause(s) /
table(s) / figure(s) / annex(es)] of which [has / have] been technically revised.
ISO 17575 consists of the following parts, under the general title Electronic fee collection — Application
interface definition for autonomous systems:
¾ Part 1: Charging
¾ Part 2: Communication and connection to the lower layers
¾ Part 3: Context data
¾ Part 4: Roaming
v
© ISO 2013 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/DIS 17575-2
Introduction
Autonomous systems
This part of ISO 17575 is part of a series of specifications defining the information exchange between the
Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board equipment
(OBE). EFC systems automatically collect charging data for the use of road infrastructure including motorway
tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels, distance-based
charging and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-area
technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Communications Networks
(CN). These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, also the terms GPS/GSM systems, and wide-area charging systems are in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such as
gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map containing
the charged geographic objects, such as charged roads or charged areas. From the charged objects, the
vehicle characteristics, the time of day and other data that are relevant for describing road use, the tariff and
ultimately the road usage fee are determined.
Some of the strengths of the autonomous approach to electronic fee collection are its flexibility, allowing the
implementation of almost all conceivable charging principles, and its independence from local infrastructure,
thereby predisposing this technology towards interoperability across charging systems and countries.
Interoperability can only be achieved with clearly defined interfaces, which is the aim and justification of
ISO 17575.
Business architecture
This part of ISO 17575 complies with the business architecture defined in the International Standard
ISO 17573. According to this architecture, the Toll Charger is the provider of the road infrastructure and,
hence, the recipient of the road usage charges. The Toll Charger is the actor associated with the Toll
Charging role. See Figure 1.
Figure 1 — The role-based model underlying this Standard
vi
© ISO 2013 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/DIS 17575-2
Service Providers issue OBE to the users of the road infrastructure. Service Providers are responsible for
operating the OBE that will record the amount of road usage in all toll charging systems the vehicle passes
through and for delivering the charging data to the individual Toll Chargers. In general, each Service Provider
delivers charging data to several Toll Chargers, as well as each Toll Charger in general receives charging
data from more than one Service Provider. Interoperability Management in Figure 1 comprises all
specifications and activities that, in common, define and maintain a set of rules that govern the overall toll
charging environment.
Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects the fact
that some processing functionalities can either be allocated to the OBE or to an associated off-board
component (Proxy). An example of processing functionality that can be realized either on- or off-board is map-
matching, where the vehicle locations in terms of measured coordinates from GNSS are associated to
geographic objects on a map that either reside on- or off-board. Also tariffication can be done with OBE tariff
tables and processing, or with an off-board component.
Figure 2 — Assumed technical architecture and interfaces
The combined functionality of OBE and Proxy is denoted as Front End. A Front End implementation where
processing is predominately on OBE-side is known as a smart client (or intelligent client, fat client) or edge-
heavy. A Front End where processing is mostly done off-board is denoted as thin-client or edge-light
architecture. Many implementations between the “thin” and “thick” extremes are possible, as depicted by the
gradual transition in the wedges in Figure 2. Both extremes of architectural choices have their merits and are
one means where manufacturers compete with individual allocations of functionality between on-board and
central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the transfer of
localization data between OBE and off-board components, where proprietary algorithms are used for data
reduction and data compression. Standardization of this transfer is neither fully possible nor beneficial.
vii
© ISO 2013 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/DIS 17575-2
Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices, the primary
scope of ISO 17575 is the data exchange between Front End and Back End (see the corresponding dotted
line in Figure 2). For every toll regime, the Back End will send context data, i.e. a description of the toll regime
in terms of charged objects, charging rules and, if required, the tariff scheme to the Front End, and will receive
usage data from the Front End.
It has to be noted also that the distribution of tasks and responsibilities between Service Provider and Toll
Charger will vary individually. Depending on the local legal situation, Toll Chargers will require “thinner” or
“thicker” data, and might or might not leave certain data processing tasks to Service Providers. Hence, the
data definitions in ISO 17575 may be useful on several interfaces.
ISO 17575 also provides for basic media-independent communication services that may be used for
communication between Front End and Back End, which might be line-based or an air-link, and can also be
used for the air-link between OBE and central communication server.
The parts of ISO 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End. The
required attributes will differ from one Toll Charger to another, hence, attributes for all requirements are
offered, ranging from attributes for raw localization data, for map-matched geographic objects and for
completely priced toll transactions.
Part 2: Communication and connection to lower layers, defines basic communication services for data transfer
over the OBE air-link or between Front End and Back End.
Part 3: Context Data, defines the data to be used for a description of individual charging systems in terms of
charged geographical objects and charging and reporting rules. For every Toll Charger's system, attributes as
defined in part 3 are used to transfer data to the Front End in order to instruct it which data to collect and
report.
Part 4: Roaming, defines the functional details and data elements required to operate more than one EFC
regime in parallel. The domains of these EFC regimes may or may not overlap. The charge rules of different
overlapping EFC regimes can be linked, i.e. they may include rules that an area pricing scheme will not be
charged if an overlapping toll road is used and already paid for.
viii
© ISO 2013 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/DIS 17575-2
Figure 3 — Scope of ISO 17575
Application needs covered by ISO 17575
¾ The parts of ISO 17575 are compliant with the architecture defined in the future International Standard
ISO 17573.
¾ The parts of ISO 17575 support charges for use of road sections (including bridges, tunnels, passes,
etc.), passage of cordons (entry/exit) and use of infrastructure within an area (distance, time).
¾ The parts of ISO 17575 support fee collection based on units of distance or duration, and based on
occurrence of events.
¾ The parts of ISO 17575 support modulation of fees by vehicle category, road category, time of usage and
contract type (e.g. exempt vehicles, special tariff vehicles, etc.).
¾ The parts of ISO 17575 support limiting of fees by a defined maximum per period of usage.
¾ The parts of ISO 17575 support fees with different legal status (e.g. public tax, private toll).
¾ The parts of ISO 17575 support differing requirements of different Toll Chargers, especially in terms of
¾ geographic domain and context descriptions,
¾ contents and frequency of charge reports,
¾ feedback to the driver (e.g. green or red light), and
¾ provision of additional detailed data on request, e.g. for settling of disputes.
¾ The parts of ISO 17575 support overlapping geographic toll domains.
ix
© ISO 2013 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/DIS 17575-2
¾ The parts of ISO 17575 support adaptations to changes in
¾ tolled infrastructure,
¾ tariffs, and
¾ participating regimes.
¾ The parts of ISO 17575 support the provision of trust guarantees by the Service Provider to the Toll
Charger for the data originated from the Front End.
x
© ISO 2013 – All rights reserved
---------------------- Page: 10 ----------------------
DRAFT INTERNATIONAL STANDARD ISO/DIS 17575-2
Electronic fee collection — Application interface definition for
autonomous systems — Part 2: Communication and connection
to the lower layers
1 Scope
This part of ISO 17575 defines how to convey all or parts of the data element structure defined in other parts
of ISO 17575 over any communication stack and media suitable for this application. It is focussed on mobile
communication links. Wired links, i.e. back office connections, can use the same methodology, .
To establish a link to a sequence of service calls initializing the communication channel, addressing the
reception of the message and forwarding the payload are required. The required communication medium
independent services are part of the definition of this part of ISO 17575, represented by an abstract
application programming interface (API).
The communication interface is implemented as an API in the programming environment of choice for the
Front End (FE) system. The definition of this API in concrete terms is outside of the scope of this part of
ISO 17575. This part of ISO 17575 specifies an abstract API that defines the semantics of the concrete API
and its protocol implementation conformance statement (PICS) proforma (see Annex B). An example concrete
API is presented in Annex C. Where no distinction is made between the abstract and concrete
communications APIs, the term “communications API” or just “API”, can be used.
Certificate handling and encryption mechanisms are outside of the scope of this part of ISO 17575.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation — Part 1
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17573, Electronic fee collection — Systems architecture for vehicle related tolling
ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems — Part 3:
Context data
ISO 17575-4, Electronic fee collection — Application interface definition for autonomous systems — Part 4:
Roaming
© ISO 2013 – All rights reserved
1
---------------------- Page: 11 ----------------------
ISO/DIS 17575-2
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
attribute
application information formed by one or by a sequence of data elements, used for implementation of a
transaction
[ISO 14906:2011, definition 3.3]
3.2
authentication
provision of assurance that a claimed characteristic of an entity is correct
[ISO 27000]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[ISO 14906:2011, definition 3.4]
3.4
Back End
generic name for the computin
...
NORME ISO
INTERNATIONALE 17575-2
Première édition
2016-01-15
Perception du télépéage — Définition
de l’interface d’application pour les
systèmes autonomes —
Partie 2:
Communications et connexions aux
couches basses
Electronic fee collection — Application interface definition for
autonomous systems —
Part 2: Communication and connection to the lower layers
Numéro de référence
ISO 17575-2:2016(F)
©
ISO 2016
---------------------- Page: 1 ----------------------
ISO 17575-2:2016(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2016, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 17575-2:2016(F)
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Termes et définitions . 2
3 Abréviations . 4
4 Architecture de communication de système EFC frontal . 5
4.1 Généralités . 5
4.2 Relations avec l’ensemble de l’architecture EFC . 6
5 Services de communication EFC (fonctions) . 6
5.1 Concept général . 6
5.2 Phase d’initialisation .10
5.2.1 Généralités .10
5.2.2 Demande d’une session entrante (du système central à l’application du
système frontal) . .10
5.2.3 Etablissement d’une session sortante (de l’application du système frontal
au système central) . .10
5.3 Primitives de service de communication point à point .10
5.3.1 Généralités .10
5.3.2 Messages non structurés (ADU) .11
5.3.3 Messages structurés (ADU) .11
5.4 Fin de session .11
5.5 Echec de session .11
5.6 Considérations sur la sécurité .12
5.7 Options de sélection des supports .12
6 Utilisation d’une pile de communication .12
6.1 Généralités .12
6.2 Exigences relatives à une technologie de communication sous-jacente .12
6.3 Appels mobiles terminés .12
Annexe A (normative) Définition de l’API abstraite .14
Annexe B (normative) Formulaire PICS.20
Annexe C (informative) Exigences de l’API .25
Annexe D (informative) Exemples de définition pour les langages concernés .27
Annexe E (informative) Utilisation de la présente partie de l’ISO 17575 pour le SET .30
Bibliographie .32
© ISO 2016 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 17575-2:2016(F)
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer
un engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à
l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes
de l’OMC concernant les obstacles techniques au commerce (OTC), voir le lien suivant: Avant-propos —
Informations supplémentaires.
L’ISO 17575-2 a été élaborée par le comité technique ISO/TC 204, Systèmes intelligents de transport.
Cette deuxième édition annule et remplace la première édition (ISO/TS 17575-2:2010), qui a fait l’objet
d’une révision technique.
L’ISO 17575 comprend les parties suivantes, présentées sous le titre général Perception du télépéage —
Définition de l’interface d’application pour les systèmes autonomes:
— Partie 1: Imputation
— Partie 2: Communications et connexions aux couches basses
— Partie 3: Données du contexte
Dans la présente édition de l’ISO 17575, le contenu de la norme ISO/TS 17575-4:2011 a été incorporé à
la norme ISO 17575-3:2016. La norme ISO/TS 17575-4:2011 sera retirée lorsque la norme ISO 17575-3
aura été publiée.
iv © ISO 2016 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 17575-2:2016(F)
Introduction
0.1 Systèmes autonomes
L’ISO 17575 est une série de normes relatives à l’échange d’informations entre le système frontal et le
système central des applications de perception de télépéage (EFC, Electronic Fee Collection) reposant
sur un équipement embarqué (OBE, On-Board Equipment) autonome. Les systèmes EFC collectent
automatiquement les données de perception pour l’usage de l’infrastructure routière (notamment
les péages autoroutiers et les péages pour les ouvrages spéciaux comme les ponts et les tunnels), la
tarification basée sur la distance parcourue et les redevances de stationnement.
Un OBE autonome fonctionne sans s’appuyer sur une infrastructure dédiée en bord de route en faisant
appel à des technologies à couverture étendue telles que les systèmes mondiaux de navigation par
satellite (GNSS) et les réseaux cellulaires (CN). Plusieurs termes sont utilisés pour faire référence à ces
systèmes EFC. Outre les termes « systèmes autonomes » et « systèmes GNSS/CN », les termes « systèmes
GPS/GSM » et « systèmes de localisation par satellite » sont également utilisés.
Grâce à un système de localisation par satellite souvent combiné à d’autres technologies de détection
(gyroscopes, compteurs kilométriques et accéléromètres), les systèmes autonomes localisent le
véhicule sur une carte géographique contenant les informations de tarification des routes et portions
payantes. Ces informations de tarification permettent de déterminer les caractéristiques du véhicule,
l’heure et les autres données pertinentes pour définir l’usage routier, le tarif et la redevance associée.
Ces systèmes EFC autonomes présentent une réelle flexibilité permettant d’implémenter presque
tous les principes d’imputation existants et ne dépendent pas de l’infrastructure routière favorisant
l’interopérabilité de cette technologie dans les pays et les systèmes de perception. Seules des interfaces
clairement définies peuvent permettre cette interopérabilité, ce qui représente le but et la justification
de l’ISO 17575.
0.2 Architecture opérationnelle
La présente partie de l’ISO 17575 est conforme à l’architecture opérationnelle définie dans l’ISO 17573
selon laquelle le percepteur de péage est le fournisseur de l’infrastructure routière et, de ce fait, le
bénéficiaire des redevances d’usage routier. Le percepteur de péage est associé au rôle de perception du
péage (voir Figure 1).
© ISO 2016 – Tous droits réservés v
---------------------- Page: 5 ----------------------
ISO 17575-2:2016(F)
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
Anglais Français
Interoperability Management Gestion de l’interopérabilité
Service Provision Fourniture du service
Toll Charging Perception du péage
Service Usage Utilisation du service
Figure 1 — Modèle basé sur les rôles servant à l’ISO 17575
Les prestataires de services fournissent des équipements embarqués aux usagers de l’infrastructure
routière. Les prestataires de services sont responsables de l’exploitation des équipements embarqués
qui consignent le taux d’usage du réseau routier dans les systèmes de perception du péage par lesquels
transitent les véhicules et fournissent les données de perception à chaque percepteur de péage. En
général, chaque prestataire de services transmet des données de perception à plusieurs percepteurs
de péage, de même que chaque percepteur de péage reçoit généralement des données de perception
provenant de plusieurs prestataires de services. La gestion de l’interopérabilité illustrée à la Figure 1
inclut toutes les spécifications et activités qui permettent de définir et de tenir à jour un ensemble de
règles régissant l’environnement de perception du péage.
0.3 Architecture technique
L’architecture technique de la Figure 2 ne dépend d’aucune réalisation pratique en particulier.
Elle reflète le fait que certaines fonctionnalités de traitement peuvent être allouées soit à l’OBE soit
à un composant associé non embarqué (proxy). Par exemple, le repérage cartographique est une
fonctionnalité pouvant être traitée par un équipement embarqué ou non embarqué; les coordonnées de
localisation des véhicules mesurées par le système GNSS sont associées aux objets géographiques sur
une carte hébergée sur un équipement embarqué ou non embarqué. Le calcul des tarifs peut également
être effectué à l’aide de tables tarifaires et d’un traitement dans l’OBE, ou à l’aide d’un composant
non embarqué.
vi © ISO 2016 – Tous droits réservés
---------------------- Page: 6 ----------------------
ISO 17575-2:2016(F)
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Front End Back End
Road Usage Data
Context Data
Anglais Français
Scope of ISO 17575 Domaine d’application de l’ISO 17575
Processing Equipment Equipement de traitement
Front End Système frontal
Back End Système central
Road Usage Data Données d’utilisation du réseau routier
Context Data Données du contexte
Figure 2 — Architecture technique supposée et interfaces
La fonctionnalité combinée de l’OBE et du proxy est appelée système frontal. L’implémentation
d’un système frontal dans lequel le traitement est essentiellement réalisé du côté OBE est connue
en tant que client intelligent (client lourd) ou « edge-heavy ». Un système frontal dont le traitement
est principalement réalisé sur un équipement non embarqué est appelé client léger ou architecture
légère (« edge-light »). Il existe beaucoup d’autres implémentations possibles entre ces deux extrêmes,
comme l’indiquent les flèches de transition de la Figure 2. Ces deux architectures extrêmes offrent de
nombreux avantages et représentent un enjeu concurrentiel entre les fabricants qui proposent chacun
des fonctionnalités différentes d’affectation des ressources embarquées et centrales.
Dans le cas spécifique des équipements embarqués de client léger, les fabricants sont amenés à concevoir
de multiples optimisations pour le transfert des données de localisation entre l’équipement embarqué
et les composants non embarqués, en utilisant des algorithmes de propriété pour la réduction et la
compression des données. La normalisation de ce transfert n’est ni possible ni avantageuse.
0.4 Localisation de l’interface de spécification
Pour se soustraire et devenir indépendant de ces choix d’implémentation architecturale, le principal
domaine d’application de l’ISO 17575 est l’échange de données entre le système frontal et le système
central (voir la ligne verticale correspondante à la Figure 2). Pour chaque régime de péage, le système
central envoie les données du contexte (ex: description du régime contenant des objets d’imputation,
des règles de tarification et, si nécessaire, régime tarifaire) au système frontal et reçoit des données
d’utilisation de la part de ce dernier.
© ISO 2016 – Tous droits réservés vii
---------------------- Page: 7 ----------------------
ISO 17575-2:2016(F)
Par ailleurs, on doit également noter que la répartition des tâches et des responsabilités entre le
prestataire de services et le percepteur de péage varie selon les cas. En fonction du contexte juridique
local, les percepteurs de péage ont besoin de données « légères » ou « lourdes » et pourraient confier ou
non certaines tâches de traitement des données aux prestataires de services. De ce fait, les définitions
de données fournies dans l’ISO 17575 peuvent être pertinentes pour plusieurs interfaces.
La norme ISO 17575 traite également des services basiques de communication indépendants du
support pouvant être utilisés lors de la communication entre le système frontal et le système central,
qui pourraient être basés sur des lignes ou des ondes hertziennes, et pouvant également servir pour la
liaison hertzienne entre l’équipement embarqué et le serveur de communication central.
0.5 Parties de la norme ISO 17575
Partie 1: Imputation, définit les attributs pour le transfert des données d’utilisation du système frontal
au système central. Le contenu des rapports de perception peut varier d’un régime de péage à l’autre; la
présente partie fournit en conséquence des attributs pour toutes les exigences, y compris des attributs
pour les données brutes de localisation, pour les objets géographiques de repérage cartographique et
pour les transactions de péage dont le prix est fixé. Un régime de péage comprend un ensemble de règles
d’imputation, y compris le réseau soumis à péage, les principes d’imputation, les véhicules assujettis au
péage et une définition du contenu exigé du rapport de perception.
Partie 2: Communications et connexions aux couches basses, définit les services de communication de
base pour le transfert des données sur la liaison aérienne de l’OBE ou entre le système frontal et le
système central. Les données définies dans l’ISO 17575-1 et l’ISO 17575-3 peuvent, mais ne doivent
pas nécessairement être échangées au moyen d’une pile de communication telle que définie dans
l’ISO 17575-2, mais cet échange n’est pas nécessaire.
Partie 3: Données du contexte, définit les données à utiliser pour la description de chaque système
de perception en termes d’objets géographiques soumis à redevance et de règles d’imputation et
d’établissement de rapports. Pour chaque système de percepteur de péage, les attributs définis dans la
norme ISO 17575-3 sont utilisés pour transférer des données vers le système frontal afin de lui indiquer
quelles données il doit collecter et utiliser pour générer des rapports.
0.6 Besoins en termes d’application couverts par l’ISO 17575
La série de normes ISO 17575
— est conforme à l’architecture définie dans l’ISO 17573:2010,
— prend en charge les tarifications liées à l’usage des portions routières (y compris les ponts, les tunnels,
les ouvrages spéciaux, etc.), le passage de cordons (entrée/sortie) et l’usage d’infrastructures dans
un périmètre délimité (distance, durée),
— prend en charge la perception basée sur des unités de distance ou de durée, et sur l’occurrence
d’événements,
— prend en charge la modulation des redevances selon la catégorie du véhicule, la catégorie de la route,
l’heure d’usage et le type de contrat (ex: véhicules exemptés ou soumis à des tarifs spéciaux, etc.),
— prend en charge la limitation des redevances pour un maximum défini par période d’usage,
— prend en charge les redevances avec différents statuts juridiques (ex: taxes publiques et péages privés).
— prend en charge les diverses exigences des percepteurs de péage, notamment en termes de
— descriptions du domaine géographique et du contexte,
— contenu et fréquence des rapports de perception,
— retour d’informations au conducteur (ex: voyant rouge ou vert), et
viii © ISO 2016 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO 17575-2:2016(F)
— fourniture de données détaillées supplémentaires sur demande, par exemple pour le
règlement des litiges,
— prend en charge les domaines géographiques de péage qui se chevauchent,
— prend en charge les adaptations aux modifications apportées dans
— d’infrastructure à péage,
— de tarifs, et
— les régimes concernés, et
prend en charge la provision de garanties fiables par le prestataire de services au percepteur de
péage pour les données issues du système frontal.
© ISO 2016 – Tous droits réservés ix
---------------------- Page: 9 ----------------------
NORME INTERNATIONALE ISO 17575-2:2016(F)
Perception du télépéage — Définition de l’interface
d’application pour les systèmes autonomes —
Partie 2:
Communications et connexions aux couches basses
1 Domaine d’application
La présente partie de l’ISO 17575 définit comment transposer tout ou partie de la structure des éléments
de données définis dans les autres parties de l’ISO 17575 via une pile de communication et des supports
adaptés à cette application. Elle s’applique uniquement aux liaisons de communication mobile (bien que
les liaisons filaires, comme celles de back-office, puissent utiliser la même méthode).
Pour établir une liaison avec une séquence d’appels de service initialisant le canal de communication, la
réception du message et le réacheminement de la charge doivent être gérés. La définition fournie dans
la présente partie de l’ISO 17575 englobe les services indépendants du support de communication; ils
sont représentés par une interface de programmation d’application (API).
L’interface de communication est implémentée dans l’environnement de programmation choisi pour le
système frontal (FE, Front End) sous la forme d’une API. La spécification de l’API du système central
(BE, Back End) n’entre pas dans le cadre de la présente partie de l’ISO 17575.
La définition de cette API en termes concrets n’entre pas dans le cadre de la présente partie de
l’ISO 17575. La présente partie de l’ISO 17575 spécifie une API abstraite qui définit la sémantique
de l’API concrète comme illustré à la Figure 3 et son formulaire de déclaration de conformité
d’implémentation de protocole (PICS, Protocol Implementation Conformance Statement) comme décrit
à l’Annexe B. L’Annexe C fournit un exemple d’API concrète. Aucune distinction n’étant faite entre les
API de communication abstraites et concrètes, les termes « API de communication » ou simplement
« API » peuvent s’utiliser indifféremment.
© ISO 2016 – Tous droits réservés 1
---------------------- Page: 10 ----------------------
ISO 17575-2:2016(F)
Front End Application
7. Application
Communications
API
6. Presentation
Communications
Subsystem
5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Anglais Français
Communications API API de communication
Front End Application Application du système frontal
7. Application 7. Application
Communications Subsystem Sous-système de communication
6. Presentation 6. Présentation
5. Session 5. Session
Underlying Communications Technology Technologie de communication sous-jacente
4. Transport 4. Transport
3. Network 3. Réseau
2. Datalink 2. Liaison de données
1. Physical 1. Physique
Figure 3 — Domaine d’application de la présente partie de l’ISO 17575
La présente partie de l’ISO 17575 fournit également une spécification détaillée de la structure des
déclarations API associées, un exemple de la manière de l’implémenter, ainsi que son rôle dans un
groupe de péage complexe tel que le SET (voir Annexe A à Annexe E).
Les règles de sélection des supports et les mécanismes de chiffrement et de gestion des certificats
n’entrent pas dans le cadre de la présente partie de l’ISO 17575.
2 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
2.1
attribut
ensemble de données adressables consistant en un élément de données unique ou des séquences
structurées d’éléments de données
[SOURCE: ISO 17575-1:2016, 3.2]
2 © ISO 2016 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 17575-2:2016(F)
2.2
authentificateur
données (pouvant être chiffrées) qui sont utilisées à des fins d’authentification
[SOURCE: EN 15509:2014, 3.3]
2.3
système central
BE (Back End)
partie du système de back-office assurant l’interface avec un ou plusieurs systèmes frontaux (2.6)
2.4
élément de données
information codée, qui peut elle-même être constituée de structures d’information de niveau inférieur
[SOURCE: ISO 17575-1:2016, 3.9]
2.5
intégrité des données
propriété indiquant que les données n’ont pas été altérées ni supprimées d’une manière non autorisée
2.6
système frontal
FE (Front End)
partie d’un système de péage composé de l’équipement embarqué (OBE) (2.9) et éventuellement d’un
proxy (2.10) où les informations de péage routier et les données d’utilisation sont collectées et traitées à
des fins de livraison au système central (2.3)
[SOURCE: ISO/TS 19299:2015, 3.17]
Note 1 à l’article: à l’Article Le système frontal comporte l’équipement embarqué et un proxy facultatif.
2.7
application du système frontal
partie du système frontal située au-dessus de l’API
2.8
interopérabilité
aptitude des systèmes à échanger des informations et à faire mutuellement usage des informations
échangées
[SOURCE: ISO/IEC/TR 100001:1998, 3.2.1, modifiée.]
2.9
équipement embarqué
OBE (On-Board Equipment)
équipement situé à bord d’un véhicule ayant la capacité d’échanger des informations avec des
systèmes externes
Note 1 à l’article: à l’Article Il convient de considérer les autres sous-unités comme facultatives.
2.10
proxy
partie optionnelle d’un système frontal (2.6) qui communique avec un équipement externe et traite les
données reçues dans un format convenu et devant être transmises au système central (2.3)
[SOURCE: ISO 17575-1:2016, 3.13]
© ISO 2016 – Tous droits réservés 3
---------------------- Page: 12 ----------------------
ISO 17575-2:2016(F)
2.11
primitive de service
service de communication élémentaire fourni par le protocole de couche d’application aux processus
d’application
Note 1 à l’article: à l’Article L’invocation d’une primitive de service par un processus d’application appelle
implicitement et utilise les services fournis par les couches basses de protocole.
[SOURCE: ISO 14906:2011, 3.18, modifiée.]
2.12
prestataire de services de péage
entité offrant des services de péage dans un ou plusieurs domaines de péage
[SOURCE: ISO 17573:2010, 3.23, modifiée.]
2.13
péage
redevance, taxe ou droit prélevé en rapport avec l’utilisation d’un véhicule dans un domaine de péage
Note 1 à l’article: à l’Article Cette définition généralise la définition classique selon laquelle un péage correspond
à une redevance permettant de franchir une barrière ou une route, un pont, etc. La définition ci-dessus inclut
également les redevances considérées comme obligations administratives, telles que les taxes et les impôts.
[SOURCE: ISO/TS 19299:2015, 3.42, modifiée.]
2.14
percepteur de péage
entité qui perçoit le péage pour l’utilisation de véhicules dans un domaine de péage
[SOURCE: ISO 17573:2010, 3.16, modifiée.]
3 Abréviations
Pour les besoins du présent document, les abréviations suivantes s’appliquent, sauf spécification contraire.
ADU (Application Data Unit) Unité de données d’application (ISO 14906)
APDU (Application Protocol Data Unit) Unité de données d’application (ISO 14906)
AP (Application Process) Processus d’application (ISO 14906)
API (Application Programming Interface) Interface de programme d’application
ASN.1 (Abstract Syntax Notation One) Notation de syntaxe abstraite numéro un (ISO/IEC 88241)
BE (Back End) Système central
CN Réseau cellulaire
EID (Element IDentifier) Identifiant d’élément (ISO 14906)
FE (Front End) Système frontal
GNSS (Global Navigation Satellite System) Système mondial de navigation par satellite
OBE (On-Board Equipment) Equipement embarqué (ISO 14906)
TVA Taxe sur la valeur ajoutée
4 © ISO 2016 – Tous droits réservés
---------------------- Page: 13 ----------------------
ISO 17575-2:2016(F)
4 Architecture de communication de système EFC frontal
4.1 Généralités
Un sous-système de communication est nécessaire pour établir la liaison de communication entre
l’application d’un système frontal (FE) et d’un système central (BE). Il assure la transmission
des données pour l’application du système frontal via la session de communication établie sur la
ligne illustrée à la Figure 4. Lorsqu’un proxy est présent sur le système frontal, le sous-système de
communication définit les communications entre le systèm
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.