ISO 17575-2:2016

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 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .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
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

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

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

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

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.
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 Conirm
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 immediately are limited to those API calls that can quickly return a
result (InitialiseInstance and GetParameter). Other API calls are asynchronous and return
their results via the event mechanism that is initialized during InitialiseInstance.
NOTE 2 This prevents threads from locking while waiting for information to be returned and so reduces the
requirement for multithreaded programming, which is often inappropriate for embedded applications such as
those typically seen in the field of application.
Figure 6 shows an example of the relationship and interactions between different states, which are
visible across the API.
EXAMPLE Illustration of message flow for cases where the FE Application wishes to establish a session,
exchange some information with the BE, and them terminate the session. The references to API Events refer to
the definition in Annex A.
6 © ISO 2016 – All rights reserved

Back End
Back End
Application API
Events Activity
Activity Events
(Informative) (Informative)
InitialiseInstance (A.2.1)
Initialisation
Idle
SetParameter (A.2.2)
Start Session
StartSession (A.2.7)
Session
ACK
Setup InstanceStateChange (A.3.1)
Session
Active
Set of ADUs
Send ADUs
ADUReceived (A.3.4) Communications
Subsystem
ADUReceived (A.3.4)
ADUReceived (A.3.4)
ACK
Data
SendADUSetStart (A.2.10)
Transfer
SendADUSetStart
ADUSendOK (A.3.6) ACK
Receive ADUs
SendADU (A.2.11)
Set of ADUs
ADUSent (A.3.5)
End Session
EndSession (A.2.8)
Idle
Session
Termination
Figure 6 — Example message flow and session state chart
5.2 Initialization phase
5.2.1 General
The FE Application shall initialize the communications interfaces that it wishes to make use of by means of
calls to InitialiseInstance. For each instance created, the FE Application defines which underlying
communications stack is to be used. More than one interface may be used at the same time and the choice
between interfaces is the decision of the FE Application. The FE Application also provides a set of event
reception capabilities, which are used by the API to inform the FE Application of status changes.
Any additional parameterization of the instance that is required is performed by repeated calls to
SetParameter. A set of parameters are recognised by the communications API itself and those which
are not are passed through transparently to the underlying stack. Queries for the existing state of
parameters may be made via calls to GetParameter.
Once this process has been completed, the FE Application now has access to a (set of) communication
instances. State changes for events that occur on any of these interfaces will be delivered by means of
an InstanceStateChange event notification.
A chart showing the relationship and interactions between each of these states is shown in the example
given in Figure 6.
5.2.2 Incoming (BE to FE Application) session request
The BE may wish to establish communications with the FE. In this case, it performs whatever actions
are appropriate for the particular communications technology concerned. This will result in the FE
Application being informed of the request at some point in time by means of a SessionRequested
event with a datum SessionHandle indicating the identifier that the FE Application should use for the
session. From here, the process is the same as for an outgoing session establishment, as shown in 5.2.3.
NOTE The FE Application might defer a session request for an arbitrary length of time, subject to
operational constraints.
5.2.3 Outgoing (FE Application to BE) session establishment
The FE Application, either asynchronously or via the process in 5.2.2, requests a session within the
chosen communication context by means of StartSession, parameterized with information about
the session to be established. This returns immediately while also starting the process of creating the
session within the communications technology layers below.
Once the session is established, an InstanceStateChange event informs the FE Application. The
session is now active and communications between the FE Application and the BE can take place
within its context.
5.3 Point-to-point communication service primitives
5.3.1 General
Once the session is active, ADUs can be sent to the BE by the FE Application. Both structured (i.e.
context aware) and unstructured (context unaware) communications capabilities are provided. All
ADUs (structured and unstructured) are opaque to the communications layers and the distinction is
only made to avoid the overhead of higher layer demultiplexing.
Within the context of the communication session the FE Application is considered the master and has
control of the session.
5.3.2 Unstructured messages (ADUs)
A facility is provided to transit unformatted ADUs over the communications infrastructure. This
facility is typically used for the purpose of software upgrades and various other manufacturer-specific
information exchanges.
ADUs are sent via calls to SendUnformattedADU. The maximum size of ADU that can be sent via
this mechanism is available via a parameter from the API. Once the message has been transmitted, an
indication shall be provided (ADUSent) that it has been received successfully by the remote end and
that further transactions are possible.
5.3.3 Structured messages (ADUs)
Structured ADUs shall be sent in sets. A set shall be constructed for transmission via a call to
SendADUSetStart. This requests a permission to enter into structured ADU-sending mode from the
far end. ADUs are added to the set to be sent via calls to SendADU, which shall return the amount of
space remaining in the transmit buffer. The set shall be closed with a call to SendADUSetEnd. Once
transmission has been competed the FE Application shall be informed via an ADUSent event.
This is an implementation optimization option as ADUs are transmitted while the set is still being
assembled. This means that the available buffer space indicated by the return from SendADU should be
trusted more than local calculations in the FE Application as more space can be made available when
elements are transmitted.
5.4 Session end
When it is time for a session to end, the FE Application shall make a call to EndSession and provide
a suitable reason code. This shall start the process of ending the session within the underlying
communications technology. Session termination may not be immediate and transactions that
are in process will be completed before closure occurs. FE Application implementers shall expect
8 © ISO 2016 – All rights reserved

to have to handle activities from the open session until an InstanceStateChange to state
STNoSession is received.
5.5 Session failure
A session may end through no fault of the BE or the FE Application by means of intervening
communications infrastructure failure. In this instance, the FE Application shall be informed of the
fact by means of an InstanceStateChange to STErrored. Any ADUs sent by the FE Application for
which it has not received an ADUSent confirmation shall be assumed to have failed.
The communications technology shall not attempt to automatically re-establish the session; that is the
responsibility of the FE Application. If the communications session was as a result of the BE request
then the session shall be re-established at the first convenient opportunity. If the session was as a result
of an FE Application event then the decision to re-establish is left to the FE Application.
Note that some communications technologies are, by their nature, intermittently available. To support
these a StackAvail call is provided to allow the FE Application to make intelligent choices between
available infrastructures. If a medium fails during a session this shall be indicated according to the
processes noted above.
5.6 Security considerations
All communications should be encrypted. Certificate handling and encryption mechanisms are outside
of the scope of this part of ISO 17575.
5.7 Media selection options
Media may be selected between means of having several instances instantiated with independent
communication technologies. The capabilities of each medium can be determined via GetParameter
calls, and the local availability of any specific medium in an active instance can be determined through
calls to StackAvail.
6 The use of a communication stack
6.1 General
This part of ISO 17575 allows for multiple communications technologies to be used at the same time,
and for the FE Application to be able to select amongst them the one most appropriate for the specific
communication to take place. Implementations shall use this capability for “multi-mode” OBEs to allow
for the use of different technologies depending upon the urgency of the communication, their capability
and the extent of the available infrastructures.
There are, however, a number of underlying capabilities that any communication technology (or rather,
stack that sits on top of the technology) needs to provide.
6.2 Requirements for an underlying communication technology
This part of ISO 17575 allows for a wide range of underlying communications technologies. However,
the following list of properties for these stacks shall be provided:
— capability of supporting or emulating a “session”;
— capability of reliably transferring ADUs, in sequence, bidirectionally across the link;
— capability of reporting the safe receipt of ADUs at the remote end of the link;
— capability of transporting data elements of arbitrary length between the FE and the BE;
— capability of establishing a session from the FE to the BE;
— some means of signalling a demand from the BE to the FE Application that the BE wishes a session
to be established;
— capability of reliably detecting the loss of a session and of delivering that information to the
communications API;
— delivery of ADUs across the link in a timely fashion;
— capability of carrying an appropriate amount of data.
6.3 Mobile terminated calls
The approach taken within this part of ISO 17575 never requires an incoming, in-band communication
port to be open. If a BE wishes to make a connection to an FE Application for any purpose, it can use
out-of-band signalling; these mechanisms are outside the scope of this part of ISO 17575. The range of
out-of-band signalling options is considerable (e.g. SMS messages, push button on the unit, broadcast
signal, etc.). A consequence of this approach, to use out-of-band signalling, is that there is never any
requirement for an IP addressable end point for a mobile terminated call. This avoids security issues
and also simplifies issues of network address translation and private subnets, since the FE Application
will only ever need to make an outgoing connection.
NOTE A consequence of this approach is that there is never any requirement for an IP addressable end
point for a mobile terminated call. This avoids the security issues discussed above but also simplifies issues
of network address translation and private subnets, since the FE Application will only ever need to make an
outgoing connection.
10 © ISO 2016 – All rights reserved

Annex A
(normative)
Abstract API definition
A.1 General
This annex defines the properties of commands and data flow at the API between the EFC specific
software – the Front End (FE) Application – and the interface layer of the communications subsystem
of the platform used to run the EFC application, see also Figure 4. Examples of how this interface can be
realized are provided in Annex C and Annex D.
The communications API consists of a “down” API, from the FE Application to the communications stack,
and an “up” API, from the communications stack to the FE Application. Each will be considered in turn.
A.2 Down API (FE Application to communications stack)
A.2.1 InitialiseInstance
Purpose: Initialize the communications API for use. The interface is initialized in
STNoSession condition.
StackID
Takes: Underlying communications stack to be employed
Callbacks
Reference to the event handlers to be used for this instance, see
5.2
Precondition: The interface must not have been previously initialized
Returns: A handle to the instance of the API. This handle is used for all communications
Errors: Returns an invalid instance if it was not possible to create the instance
A.2.2 SetParameter
Purpose: Set a parameter for this instance of the API. All parameters and values are ex-
pressed as strings.
Instance
Takes: The instance to which this parameter relates
Parameter
The parameter to be set
value
The value to give to the parameter
Precondition: A valid instance is required
Returns: Error code
ERNoError, ERNotSet
Errors:
A.2.3 GetParameter
Purpose: Get a parameter value for this instance of the API
Instance
Takes: The instance to which this parameter relates
Parameter
The parameter to be set
Precondition: A valid instance is required
Returns: The specified parameter value as a string
Errors: Invalid string if the parameter is not known
A.2.4 DeleteParameter
Purpose: Delete a parameter from this instance of the API
Instance
Takes: The instance to which this parameter relates
Parameter
The parameter to be deleted
Precondition: A valid instance is required
Returns: Error code
ERNoError, ERNotSet
Errors:
A.2.5 StackAvail
Purpose: Indicate if the communications stack is currently available
Instance
Takes: The instance to which this check relates
Precondition: A valid instance is required
Returns: Boolean indicating if the stack is currently available
Errors: Will return FALSE in the case of an error
A.2.6 DropInstance
Purpose: Delete an API interface
Instance
Takes: The instance to which this drop request relates
Severity
Speed with which this interface should be removed (SENormal,
SEUrgent, SEUnconditional)
Precondition: A valid instance in the STNoSession state (for SENormal and SEUrgent) is
required
Returns: Error code
ERUnknownInstance, ERBadState, ERNoError
Errors:
A.2.7 StartSession
Purpose: Start the process to establish a session in the context of this interface (i.e. using the
established communications channel and parameters). Session establishment is
defined by an event indicating a change to STSessionIdle when the session is in
place. Parameterization of the session is via the SetParameter/GetParameter
methods.
12 © ISO 2016 – All rights reserved
...

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 2016
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2016, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .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
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

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

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

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

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

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ème central et le proxy. La liaison entre le proxy
et l’équipement embarqué (OBE) n’est pas décrite dans la présente partie de l’ISO 17575. Lorsqu’aucun
proxy n’est présent (« client intelligent »), le sous-système de communication définit les communications
entre l’équipement embarqué et le système central.
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
Anglais Français
Front End Application Application du système frontal
7. Application 7. Application
Communications API API de communication
UP API Indications Indications de l’API ASCENDANTE
DOWN API Requests Demandes de l’API DESCENDANTE
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 4 — Relation entre l’application et la pile de protocole
Le sous-système de communication se subdivise en outre en deux composants distincts. L’API de
communication proprement dite apporte les fonctions de communication à l’application du système
frontal. Elles reposent sur la technologie de communication sous-jacente qui fournit les fonctionnalités
que l’API représente de manière abstraite. Bien que l’API soit indépendante de la technologie sous-jacente,
elle comporte un certain nombre d’exigences fonctionnelles vis-à-vis de celle-ci. Pour cette raison, les
exigences fonctionnelles de la technologie de communication sous-jacente sont répertoriées en 6.2.
Certaines technologies sous-jacentes ont plus d’aptitudes que d’autres. Lorsqu’une technologie très
performante est utilisée, le code assurant l’interface entre l’API et la technologie sous-jacente ne servira
guère qu’à transmettre des instructions. Dans le cas de technologies plus simplistes de la couche de
transport, le sous-système de communication devra en faire beaucoup plus.
On s’attend à ce que ces API soient « reflétées » dans le système central de manière que les systèmes
frontaux et centraux puissent communiquer via des architectures porteuses arbitraires. La définition
de l’API abstraite est décrite en détail à l’Annexe A. La spécification de l’API du système central n’entre
pas dans le cadre de la présente partie de l’ISO 17575.
4.2 Relations avec l’ensemble de l’architecture EFC
L’API de communication fournit les couches basses de l’interface illustrées à la Figure 5. L’API n’a
aucune connaissance sémantique des unités de données d’application (ADU) qu’elle transporte. Elle fait
cependant la distinction entre les ADU « spécifiques normalisées » et « arbitraires », mais ne possède
pas de connaissance sémantique de leur signification. Elle se limite à les transporter sous forme de flux
d’octets transparents par-dessus une porteuse arbitraire sélectionnée au moment de l’exécution.
5 Services de communication EFC (fonctions)
5.1 Concept général
L’API transporte deux « types » de messages (ADU): les éléments structurés directement liés aux
définitions d’autres parties de l’ISO 17575, ainsi que les éléments non structurés qui n’entrent pas dans
le cadre de la présente partie de l’ISO 17575 et n’y sont pas davantage traités.
L’identification des éléments de données requis pour la transmission et la charge associée n’entre pas
dans le domaine d’application de la présente partie de l’ISO 17575.
NOTE 1 L’attribut protocolVersion (qui fait partie de ChargeReport) tel que défini dans
l’ISO 17575-1:2016 ainsi que les attributs protocolVersion et tollContext (qui font tous deux partie
de aduHeader) tel que défini dans l’ISO 17575-3:2016 peuvent être utiles lors de l’implémentation d’une ou
plusieurs transactions spécifiques.
L’API abstraite des services de communication peut être implémentées dans tout environnement de
programmation définissant le concept de distribution d’événements, permettant à l’API de reporter
les informations ou de transmettre les résultats des opérations à l’application FE. L’ordre général des
événements est le suivant
— initialisation et paramétrage de l’interface de communication,
— établissement d’une session de communication,
— transfert des données dans le contexte de la session,
— arrêt de la session de communication, et
— arrêt de l’interface de communication.
Normalement, l’application du système frontal initialise les interfaces de communication (un certain
nombre) au premier démarrage. Une session active est alors établie soit directement par l’application du
système frontal, soit en réponse à une demande entrante émise par une session provenant du système
6 © ISO 2016 – Tous droits réservés

central. Le déroulement des événements est illustré dans 5.2 à 5.7, et les définitions correspondantes
à l’Annexe A.
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 Conirm
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
Anglais Français
Unknown Instance Instance inconnue
No Session Aucune session
Errored Erreur
Session Starting Démarrage de session
Ending Fin
Awaiting ADU Confirm En attente de la confirmation d’ADU
Session Idle Session inactive
Session RX ADUs ADU RX de session
Sending ADU Envoi d’ADU
Sending ADU Request Envoi de la demande d’ADU
Sending Unformatted ADU Envoi d’ADU non mise en forme
Figure 5 — Diagramme d’état de session
Dans la pile de communication, les appels descendants de l’API appartiennent à deux classes: les appels
synchrones et les appels asynchrones. Les appels synchrones renvoyant les résultats immédiatement
sont limités aux appels d’API qui peuvent renvoyer un résultat rapidement (InitialiseInstance
et GetParameter). Les autres appels d’API sont asynchrones; ils renvoient leurs résultats via le
mécanisme d’événement initialisé pendant l’exécution de la méthode InitialiseInstance.
NOTE 2 Cela évite le blocage de threads en attente de renvoi d’informations et réduit l’exigence d’une
programmation multithread, souvent mal adaptée aux applications embarquées telles que celles qu’on rencontre
habituellement dans le domaine d’application.
La Figure 6 montre un exemple de la relation et des interactions entre différents états, visibles à tous
les niveaux de l’API.
EXEMPLE Exemple de flux de message pour les cas où l’application FE souhaite ouvrir une session, échanger
des informations avec le système central puis mettre fin à la session. Les références aux événements d’API se
rapportent à la définition donnée dans l’Annexe A.
8 © ISO 2016 – Tous droits réservés

Back End
Back End
Application API
Events Activity
Activity Events
(Informative) (Informative)
InitialiseInstance (A.2.1)
Initialisation
Idle
SetParameter (A.2.2)
Start Session
StartSession (A.2.7)
Session
ACK
Setup InstanceStateChange (A.3.1)
Session
Active
Set of ADUs
Send ADUs
ADUReceived (A.3.4) Communications
Subsystem
ADUReceived (A.3.4)
ADUReceived (A.3.4)
ACK
Data
SendADUSetStart (A.2.10)
Transfer
SendADUSetStart
ADUSendOK (A.3.6) ACK
Receive ADUs
SendADU (A.2.11)
Set of ADUs
ADUSent (A.3.5)
End Session
EndSession (A.2.8)
Idle
Session
Termination
Anglais Français
Application Activity Activité de l’application
Initialisation Initialisation
Session Setup Configuration de session
Data Transfer Transfert de données
Session Termination Fin de session
API Events Événements d’API
Communications Subsystem Sous-système de communication
Back End Events (Informative) Événements du système central (informatif)
Start Session Démarrer session
Set of ADUs Ensemble d’ADU
End Session Terminer session
Back End Activity (Informative) Activité du système central (informatif)
Idle Inactif
Session Active Session active
Send ADUs Envoyer ADU
Receive ADUs Recevoir ADU
Figure 6 — Exemple de flux de message et de graphique d’état de session
5.2 Phase d’initialisation
5.2.1 Généralités
L’application FE doit initialiser les interfaces de communication qu’elle souhaite utiliser au moyen
d’appels de méthode InitialiseInstance. Pour chaque instance créée, l’application du système
frontal définit quelle pile de communication sous-jacente doit être utilisée. Plus d’une interface peuvent
être utilisées en même temps, et le choix des interfaces est décidé par l’application du système frontal.
L’application du système frontal fournit également un ensemble de fonctions de réception d’événements,
qui sont utilisées par l’API pour signaler les changements d’état à l’application du système frontal.
Tout paramétrage supplémentaire nécessaire de l’instance est effectué par des appels répétés de la
méthode SetParameter. Un jeu de paramètres est reconnu par l’API de communication proprement
dite et celles qui ne sont pas transmises de manière transparente à la pile sous-jacente. Les requêtes de
l’état existant des paramètres peuvent être effectuées au moyen d’appels de méthode GetParameter.
A l’issue de ce processus, l’application du système frontal a accès à des instances de communication
ou un ensemble d’instances de communication. Les changements d’état des événements se
produisant dans une ou plusieurs des interfaces seront communiqués par notification d’événement
InstanceStateChange.
La Figure 6 montre un graphique illustrant les relations et les interactions qui existent entre chacun
de ces états.
5.2.2 Demande d’une session entrante (du système central à l’application du système frontal)
Le système central peut souhaiter établir la communication avec le système frontal. Dans ce cas, il
effectue les opérations correspondant à la technologie de communication concernée. L’application
du système frontal est alors informée de la demande à un moment donné au moyen d’un événement
SessionRequested dont la date SessionHandle indique l’identifiant qu’il convient que l’application
du système frontal utilise pour la session. Dès lors, le processus est identique à celui de l’établissement
d’une session sortante, comme défini en 5.2.3.
NOTE L’application du système frontal pourrait différer une demande de session pendant une durée
arbitraire en raison de contraintes opérationnelles.
5.2.3 Etablissement d’une session sortante (de l’application du système frontal au système
central)
L’application du système frontal peut, en mode synchrone ou via le processus décrit en 5.2.2, demander
l’établissement d’une session dans le contexte de communication choisi au moyen d’un appel de méthode
StartSession, paramétré avec les informations relatives à la session à établir. Cet appel renvoie
immédiatement une réponse tout en démarrant le processus de création de la session au niveau des
couches basses de la technologie de communication.
Une fois la session établie, un événement InstanceStateChange en informe l’application du système
frontal. La session est alors active et la communication entre l’application du système frontal et le
système central peut être établie dans ce contexte.
5.3 Primitives de service de communication point à point
5.3.1 Généralités
Une fois la session active, les unités de données d’application (ADU) peuvent être envoyées au système
central par l’application du système frontal. Des fonctions de communication structurées (sensibles au
contexte) et non structurées (insensibles au contexte) sont fournies. Toutes les ADU (structurées et non
structurées) sont opaques pour les couches de communication. La distinction sert uniquement à éviter
la surcharge liée au démultiplexage des couches plus hautes.
10 © ISO 2016 – Tous droits réservés

Dans le contexte de la session de communication, l’application du système frontal est considérée comme
le maître et n’exerce aucun contrôle sur la session.
5.3.2 Messages non structurés (ADU)
Une fonctionnalité permet de transmettre des ADU non mises en forme via l’infrastructure de
communication. Elle est généralement utilisée dans le cadre des mises à niveau de logiciels et d’échanges
divers d’informations spécifiques au fabricant.
Les ADU sont envoyées via des appels de méthode SendUnformattedADU. La taille maximale des
ADU pouvant être envoyées par ce mécanisme est disponible via un paramètre provenant de l’API. Une
fois le message transmis, une indication doit être fournie (ADUSent) pour informer que la réception a
été effectuée par le destinataire et que d’autres transactions sont possibles.
5.3.3 Messages structurés (ADU)
Les ADU structurées doivent être envoyées par lots. Un lot doit être constitué pour la transmission via
un appel de méthode SendADUSetStart. Il demande la permission de passer en mode envoi d’ADU
structurée du côté destinataire. Les ADU sont ajoutées au lot à envoyer via des appels de méthode
SendADU, qui doivent renvoyer l’espace restant dans le tampon de transmission. Le lot doit être clos
par un appel de méthode SendADUSetEnd. Une fois la transmission terminée, l’application du système
frontal doit être informée via un événement ADUSent.
Il s’agit d’une option d’optimisation de l’implémentation, car les ADU sont transmises alors que le lot
est encore en cours d’assemblage. Cela signifie qu’il convient que l’espace tampon disponible indiqué
par l’événement SendADU soit considéré comme plus fiable que les calculs effectués localement dans
l’application du système frontal; en effet, davantage d’espace peut être libéré lorsque les éléments
sont transmis.
5.4 Fin de session
Lorsque le moment est venu de mettre fin à une session, l’application du système frontal doit appeler
la méthode EndSession et fournir un code de motif adéquat. Cela doit entraîner le démarrage du
processus de fin de session dans la technologie de communication sous-jacente. La fin de la session peut
ne pas être immédiate, et les transactions en cours seront achevées avant la clôture. Les responsables
de l’implémentation de l’application du système frontal doivent s’attendre à devoir gérer le
...