ISO/TS 17575-2:2010
(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/TS 17575‑2:2010 defines how to convey all or parts of the data element structure defined in ISO/TS 17575‑1 over any communication stack and media suitable for this application. It is focussed on mobile communication links. However, wired links shall use the same methodology. The communication interface shall be 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 ISO/TS 17575‑2:2010. ISO/TS 17575‑2:2010 specifies an abstract API that defines the semantics of the concrete API. 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.
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
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 17575-2
First edition
2010-06-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 plus basses
Reference number
ISO/TS 17575-2:2010(E)
©
ISO 2010
---------------------- Page: 1 ----------------------
ISO/TS 17575-2:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from 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
Published in Switzerland
ii © ISO 2010 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 17575-2:2010(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviations.3
5 EFC Front End communication architecture.3
5.1 General .3
5.2 Relations to the overall EFC architecture.4
6 Initialize transactions.4
6.1 General .4
6.2 Addressing requested parts of a hierarchical data element structure .5
6.3 Identifying payloads for transmission .5
7 EFC communication services (functions).5
7.1 General concept .5
7.2 Initialization phase .6
7.3 Point-to-point communication service primitives.7
7.4 Session ending .8
7.5 Session failure .8
7.6 Security considerations.8
7.7 Media selection options.8
8 The use of a communication stack.8
8.1 General .8
8.2 Requirements on a underlying communication technology.9
8.3 Mobile terminated calls.9
Annex A (normative) Abstract API definition.10
Annex B (normative) PICS proforma .15
Annex C (informative) API requirements .20
Annex D (informative) Examples of definitions for appropriate languages.21
Annex E (informative) Example of message flow .24
Bibliography.25
© ISO 2010 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 17575-2:2010(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.
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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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/TS 17575-2 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with Technical Committee ISO/TC 204,
Intelligent transport systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
ISO/TS 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
iv © ISO 2010 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 17575-2:2010(E)
Introduction
Autonomous systems
This part of ISO/TS 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/TS 17575.
Business architecture
This part of ISO/TS 17575 complies with the business architecture defined in the draft of the future
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.
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
Figure 1 — The rolebased model underlying this Technical Specification
© ISO 2010 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/TS 17575-2:2010(E)
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.
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Front End Back 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 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.
Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices, the primary
scope of ISO/TS 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.
vi © ISO 2010 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/TS 17575-2:2010(E)
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/TS 17575 may be useful on several interfaces.
ISO/TS 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/TS 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.
Figure 3 — Scope of ISO/TS 17575
© ISO 2010 – All rights reserved vii
---------------------- Page: 7 ----------------------
ISO/TS 17575-2:2010(E)
Applicatory needs covered by ISO/TS 17575
⎯ The parts of ISO/TS 17575 are compliant with the architecture defined in the future International Standard
ISO 17573.
⎯ The parts of ISO/TS 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/TS 17575 support fee collection based on units of distance or duration, and based on
occurrence of events.
⎯ The parts of ISO/TS 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/TS 17575 support limiting of fees by a defined maximum per period of usage.
⎯ The parts of ISO/TS 17575 support fees with different legal status (e.g. public tax, private toll).
⎯ The parts of ISO/TS 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/TS 17575 support overlapping geographic toll domains.
⎯ The parts of ISO/TS 17575 support adaptations to changes in
⎯ tolled infrastructure,
⎯ tariffs, and
⎯ participating regimes.
⎯ The parts of ISO/TS 17575 support the provision of trust guarantees by the Service Provider to the Toll
Charger for the data originated from the Front End.
viii © ISO 2010 – All rights reserved
---------------------- Page: 8 ----------------------
TECHNICAL SPECIFICATION ISO/TS 17575-2:2010(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/TS 17575 defines how to convey all or parts of the data element structure defined in
ISO/TS 17575-1 over any communication stack and media suitable for this application. It is focussed on
mobile communication links. However, wired links shall 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/TS 17575, represented by an abstract API.
The communication interface shall be 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/TS 17575. This part of ISO/TS 17575 specifies an abstract API that defines the semantics of the concrete
API. 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.
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:2004, Road transport and traffic telematics — Electronic fee collection — Application interface
definition for dedicated short-range communication
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
3.2
authenticator
data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to
prove the source and/or the integrity of the data unit and protect against forgery
[ISO 14906:2004, definition 3.4]
© ISO 2010 – All rights reserved 1
---------------------- Page: 9 ----------------------
ISO/TS 17575-2:2010(E)
3.3
Back End
generic name for the computing and communication facilities of the Service Provider and/or the Toll Charger
3.4
data element
datum which might itself consist of lower level data elements
3.5
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[ISO 14906:2004, definition 3.10]
3.6
Front End
part(s) of the toll system where road usage data for an individual road user are collected, processed and
delivered to the Back End
NOTE The Front End comprises the on-board equipment and an optional proxy.
3.7
Front End application
part of the Front End above the API
3.8
interoperability
ability of systems to provide services to and accept services from other systems and to use the services so
exchanged to enable them to operate effectively together
3.9
on-board equipment
OBE
equipment located within or on the outside of the vehicle and supporting the information exchange across the
interfaces of its sub-units, composed of the On Board Unit (OBU)
NOTE Other sub-units should be considered optional.
3.10
proxy
optional component part of the Front End that communicates with on-board equipment and processes road-
usage data into a format compliant with this Technical Specification and delivers the data to the Back End
3.11
road
any stretch of land that can be navigated by a vehicle
3.12
service primitive (communication)
elementary communication service provided by the Application layer protocol to the application processes
[ISO 14906:2004, definition 3.16]
NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services offered
by the lower protocol layers.
3.13
service provider (toll)
legal entity providing its customers with toll services in one or more toll domains for one or more classes of
vehicle
2 © ISO 2010 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/TS 17575-2:2010(E)
3.14
system
something of interest as a whole or as comprised of parts
NOTE A system can be referred to as an entity. A component of a system can itself be a system, in which case it can
be called a subsystem.
3.15
tarrification
calculation of the tariff
3.16
toll
charge, tax, fee or duty in connection with using a vehicle within a toll domain
NOTE 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 above also includes fees regarded as an
(administrative) obligation, e.g. a tax or a duty.
3.17
toll charger
legal entity charging toll for vehicles in a toll domain
3.18
user
generic term used for the customer of a Toll Service Provider, one liable for toll, the owner of the vehicle, a
fleet operator, a driver, etc. depending on the context
4 Abbreviations
For the purpose of this document, the following abbreviations 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 (See ISO/IEC 8824-1.)
⎯ BE Back End
⎯ EFC Electronic Fee Collection (ISO 14906); here used equivalently to the term toll
⎯ EID Element Identifier (ISO 14906)
⎯ FE Front End
⎯ GNSS Global Navigation Satellite System
⎯ VAT Value added tax
5 EFC Front End communication architecture
5.1 General
The communications subsystem is required to establish the communication link between a Front End (FE)
Application and a Back End (BE). It provides data transport for the tolling FE Application via the
© ISO 2010 – All rights reserved 3
---------------------- Page: 11 ----------------------
ISO/TS 17575-2:2010(E)
communications session that takes part across the line in Figure 4. For the case where a proxy is present in
the Front End system the communications subsystem defines the communications between the BE and the
Proxy. The link between the Proxy and the OBE is out of scope. For the case that no Proxy is present (the
“Fat Client”) the communications subsystem defines the communications between the OBE and the BE.
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 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 8.2.
Some underlying technologies will be much more capable than others. For the case 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 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. The specification of the BE API is outside the scope of this part of
ISO/TS 17575.
5.2 Relations to 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 ADUs that 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 bearer that is selected at runtime.
6 Initialize transactions
6.1 General
The API carries two “types” of message (ADU). Structured elements relating directly to the definitions in
ISO/TS 17575-1, and unstructured elements which are outside of the scope of this part of ISO/TS 17575 and
receive no further consideration within it.
4 © ISO 2010 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/TS 17575-2:2010(E)
6.2 Addressing requested parts of a hierarchical data element structure
It is intended that the means and mechanisms of identifying data elements for transmission be defined in a
projected part 3 of this Technical Specification.
6.3 Identifying payloads for transmission
It is intended that the means and mechanisms of identifying payloads for transmission be defined in a
projected part 3 of this Technical Specification.
7 EFC communication services (functions)
7.1 General concept
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 Front End 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;
⎯ 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 depicted above is covered
in the sections that follow and cross-referenced to the abstract API definition in Annex A.
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 5 — Up/down interfaces
© ISO 2010 – All rights reserved 5
---------------------- Page: 13 ----------------------
ISO/TS 17575-2:20
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.