EN ISO 17575-2:2016

SLOVENSKI STANDARD
01-julij-2016
1DGRPHãþD
SIST-TS CEN ISO/TS 17575-2:2010
Elektronsko pobiranje pristojbin - Definicija aplikacijskega vmesnika za
avtonomne sisteme - 2. del: Komunikacija in povezovanje z nižjimi plastmi (ISO
17575-2:2016)
Electronic fee collection - Application interface definition for autonomous systems - Part
2: Communication and connection to the lower layers (ISO 17575-2:2016)
Elektronische Gebührenerhebung - Definition der Anwendungsschnittstelle für autonome
Systeme - Teil 2: Kommunikation und Verbindung mit den unteren Schichten (ISO 17575
-2:2016)
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 (ISO
17575-2:2016)
Ta slovenski standard je istoveten z: EN ISO 17575-2:2016
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 17575-2
EUROPEAN STANDARD
NORME EUROPÉENNE
February 2016
EUROPÄISCHE NORM
ICS 35.240.60; 03.220.20 Supersedes CEN ISO/TS 17575-2:2010
English Version
Electronic fee collection - Application interface definition
for autonomous systems - Part 2: Communication and
connection to the lower layers (ISO 17575-2:2016)
Perception du télépéage - Définition de l'interface Elektronische Gebührenerhebung - Definition der
d'application pour les systèmes autonomes - Partie 2: Anwendungsschnittstelle für autonome Systeme - Teil
Communications et connexions aux couches basses 2: Kommunikation und Verbindung mit den unteren
(ISO 17575-2:2016) Schichten (ISO 17575-2:2016)
This European Standard was approved by CEN on 11 December 2015.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 17575-2:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
European foreword
This document (EN ISO 17575-2:2016) has been prepared by Technical Committee ISO/TC 204
“Intelligent transport systems” in collaboration with Technical Committee CEN/TC 278 “Intelligent
transport systems” the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by August 2016, and conflicting national standards shall
be withdrawn at the latest by August 2016.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
This document supersedes CEN ISO/TS 17575-2:2010.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Endorsement notice
The text of ISO 17575-2:2016 has been approved by CEN as EN ISO 17575-2:2016 without any
modification.
INTERNATIONAL ISO
STANDARD 17575-2
First edition
2016-01-15
Electronic fee collection —
Application interface definition for
autonomous systems —
Part 2:
Communication and connection to
the lower layers
Perception du télépéage — Définition de l’interface d’application pour
les systèmes autonomes —
Partie 2: Communications et connexions aux couches basses
Reference number
ISO 17575-2:2016(E)
©
ISO 2016
ISO 17575-2:2016(E)
© 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

ISO 17575-2:2016(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Terms and definitions . 2
3 Abbreviated terms . 3
4 EFC Front End communication architecture . 4
4.1 General . 4
4.2 Relationship with the overall EFC architecture . 5
5 EFC communication services (functions) . 5
5.1 General concept . 5
5.2 Initialization phase . 7
5.2.1 General. 7
5.2.2 Incoming (BE to FE Application) session request . 7
5.2.3 Outgoing (FE Application to BE) session establishment . 8
5.3 Point-to-point communication service primitives . 8
5.3.1 General. 8
5.3.2 Unstructured messages (ADUs) . 8
5.3.3 Structured messages (ADUs) . 8
5.4 Session end . 8
5.5 Session failure . 9
5.6 Security considerations . 9
5.7 Media selection options . 9
6 The use of a communication stack . 9
6.1 General . 9
6.2 Requirements for an underlying communication technology . 9
6.3 Mobile terminated calls .10
Annex A (normative) Abstract API definition .11
Annex B (normative) Protocol implementation conformance statement (PICS) proforma .17
Annex C (informative) API requirements .22
Annex D (informative) Examples of definitions for appropriate languages.23
Annex E (informative) Use of this part of ISO 17575 for the EETS .26
Bibliography .28
ISO 17575-2:2016(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
This edition of ISO 17575-2 cancels and replaces ISO/TS 17575-2:2010, which has been technically
revised. The following changes have been made:
— conversion from a Technical Specification to an International Standard;
— editorial and formal corrections as well as changes to improve readability.
ISO 17575 consists of the following parts, under the general title Electronic fee collection — Application
interface definition for autonomous systems:
— Part 1: Charging
— Part 2: Communication and connection to the lower layers
— Part 3: Context data
In this edition of the ISO 17575-series the contents of ISO/TS 17575-4:2011 were incorporated into
ISO 17575-3:2016. ISO/TS 17575-4:2011 will be withdrawn once ISO 17575-3 has been published.
iv © ISO 2016 – All rights reserved

ISO 17575-2:2016(E)
Introduction
0.1 Autonomous systems
ISO 17575 is a series of standards defining the information exchange between the Front End and the
Back End in electronic fee collection (EFC) based on autonomous on-board equipment (OBE). EFC
systems automatically collect charging data for the use of road infrastructure including motorway
tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels, distance-
based charging and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-
area technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Networks (CN).
These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, the terms GPS/GSM systems and wide-area charging systems are also in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such
as gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map
containing the charged geographic objects, such as charged roads or charged areas. From the charged
objects, the vehicle characteristics, the time of day and other data that are relevant for describing road
use, the tariff and ultimately the road usage fee are determined.
Two strengths of the autonomous approach to electronic fee collection are its flexibility, allowing
the implementation of almost all conceivable charging principles, and its independence from local
infrastructure, thereby predisposing this technology towards interoperability across charging systems
and countries. Interoperability can only be achieved with clearly defined interfaces, which is the aim
and justification of ISO 17575.
0.2 Business architecture
This part of ISO 17575 complies with the business architecture defined in ISO 17573. According to this
architecture, the toll charger is the provider of the road infrastructure and, hence, the recipient of the
road usage charges. The toll charger is the actor associated with the toll charging role (see Figure 1).
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
Figure 1 — The role-based model underlying ISO 17575
Service providers issue OBE to the users of the road infrastructure. Service providers are responsible
for operating OBE that will record the amount of road usage in all toll charging systems the vehicle
passes through and for delivering the charging data to the individual toll chargers. In general, each
service provider delivers charging data to several toll chargers and, in general, each toll charger
receives charging data from more than one service provider. Interoperability management, as shown in
Figure 1, comprises all specifications and activities that define and maintain a set of rules that govern
the overall toll charging environment.
ISO 17575-2:2016(E)
0.3 Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects
the fact that some processing functionalities can either be allocated to the OBE or to an associated off-
board component (proxy). An example of processing functionality that can be realized either on- or off-
board is map-matching, where the vehicle locations in terms of measured coordinates from GNSS are
associated to geographic objects on a map that either reside on- or off-board. Also, the computation of
tariffs can be done with OBE tariff tables and processing, or with an off-board component.
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Back End
Front End
Road Usage Data
Context Data
Figure 2 — Assumed technical architecture and interfaces
The combined functionality of OBE and proxy is denoted as Front End. A Front End implementation
where processing is predominately on the OBE-side is known as a smart client (or intelligent client,
fat client) or edge-heavy. A Front End where processing is mostly done off-board is denoted as thin-
client or edge-light architecture. Many implementations between the “thin” and “thick” extremes are
possible, as depicted by the gradual transition in the wedges in Figure 2. Both extremes of architectural
choice have their merits and are one means where manufacturers compete with individual allocations
of functionality between on-board and central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the
transfer of localization data between OBE and off-board components, where proprietary algorithms are
used for data reduction and data compression. Standardization of this transfer is neither fully possible
nor beneficial.
0.4 Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices,
the primary scope of ISO 17575 is the data exchange between Front End and Back End (see the
corresponding vertical line in Figure 2). For every toll regime, the Back End will send context data, i.e.
a description of the toll regime in terms of charged objects, charging rules and, if required, the tariff
scheme to the Front End, and will receive usage data from the Front End.
It has to be noted also that the distribution of tasks and responsibilities between service provider and
toll charger will vary individually. Depending on the local legal situation, toll chargers will require
“thinner” or “thicker” data, and might or might not leave certain data processing tasks to service
providers. Hence, the data definitions in ISO 17575 may be useful on several interfaces.
vi © ISO 2016 – All rights reserved

ISO 17575-2:2016(E)
ISO 17575 also provides for basic media-independent communication services that may be used for
communication between Front End and Back End, which might be line-based or an air-link, and can also
be used for the air-link between OBE and central communication server.
0.5 The parts of ISO 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End.
The contents of charge reports might vary between toll regimes, hence, attributes for all requirements
are offered, ranging from attributes for raw localization data, for map-matched geographic objects and
for completely priced toll transactions. A toll regime comprises a set of rules for charging, including the
charged network, the charging principles, the liable vehicles and a definition of the required contents of
the charge report.
Part 2: Communication and connection to lower layers, defines basic communication services for data
transfer over the OBE air-link or between Front End and Back End. The data defined in ISO 17575-1 and
ISO 17575-3 can but need not be exchanged using the communication stack as defined in ISO 17575-2.
Part 3: Context data, defines the data to be used for a description of individual charging systems in
terms of charged geographical objects and charging and reporting rules. For every toll charger’s system,
attributes as defined in ISO 17575-3 are used to transfer data to the Front End in order to instruct it on
which data to collect and report.
0.6 Application needs covered by ISO 17575
The ISO 17575 series of standards
— is compliant with the architecture defined in ISO 17573:2010,
— supports charges for use of road sections (including bridges, tunnels, passes, etc.), passage of
cordons (entry/exit) and use of infrastructure within an area (distance, time),
— supports fee collection based on units of distance or duration, and based on occurrence of events,
— supports modulation of fees by vehicle category, road category, time of usage and contract type (e.g.
exempt vehicles, special tariff vehicles, etc.),
— supports limiting of fees by a defined maximum per period of usage,
— supports fees with different legal status (e.g. public tax, private toll),
— supports differing requirements of different toll chargers, especially in terms of
— geographic domain and context descriptions,
— contents and frequency of charge reports,
— feedback to the driver (e.g. green or red light), and
— provision of additional detailed data on request, e.g. for settling of disputes,
— supports overlapping geographic toll domains,
— supports adaptations to changes in
— tolled infrastructure,
— tariffs, and
— participating regimes, and
— supports the provision of trust guarantees by the service provider to the toll charger for the data
originated from the Front End.
INTERNATIONAL STANDARD ISO 17575-2:2016(E)
Electronic fee collection — Application interface definition
for autonomous systems —
Part 2:
Communication and connection to the lower layers
1 Scope
This part of ISO 17575 defines how to convey all or parts of the data element structure defined in other
parts of ISO 17575 over any communication stack and media suitable for this application. It is applicable
only to mobile communication links (although wired links, i.e. back office connections, can use the same
methodology).
To establish a link to a sequence of service calls initializing the communication channel, addressing the
reception of the message and forwarding the payload are required. The definition provided in this part
of ISO 17575 includes the required communication medium independent services, represented by an
abstract application programming interface (API).
The communication interface is implemented as an API in the programming environment of choice for
the Front End (FE) system. The specification of the Back End (BE) API is outside the scope of this part
of ISO 17575.
The definition of this API in concrete terms is outside of the scope of this part of ISO 17575. This part
of ISO 17575 specifies an abstract API that defines the semantics of the concrete API as illustrated in
Figure 3 and its protocol implementation conformance statement (PICS) proforma (see Annex B). An
example of a concrete API is presented in Annex C. Where no distinction is made between the abstract
and concrete communications APIs, the term “communications API” or just “API” can be used.
Front End Application
7. Application
Communications
API
6. Presentation
Communications
Subsystem 5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Figure 3 — Scope of this part of ISO 17575
This part of ISO 17575 also provides a detailed specification for the structure of associated API
statements, an example on how to implement it and its role in a complex toll cluster such as the EETS
(see Annex A to Annex E).
ISO 17575-2:2016(E)
Media selection policies, certificate handling and encryption mechanisms are outside of the scope of
this part of ISO 17575.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
attribute
addressable package of data consisting of a single data element or structured sequences of data elements
[SOURCE: ISO 17575-1:2016, 3.2]
2.2
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
2.3
Back End
BE
part of a back office system interfacing to one or more Front Ends (2.6)
[SOURCE: ISO 17575-1:2016, 3.4]
2.4
data element
coded information, which might itself consist of lower level information structures
[SOURCE: ISO 17575-1:2016, 3.9]
2.5
data integrity
property that data has not been altered or destroyed in an unauthorized manner
2.6
Front End
FE
part of a tolling system consisting of an OBE (2.9) and possibly a proxy (2.10) where road tolling
information and usage data are collected and processed for delivery to the Back End (2.3)
[SOURCE: ISO/TS 19299:2015, 3.17]
Note 1 to entry: The Front End comprises the on-board equipment (2.9) and an optional proxy (2.9).
2.7
Front End application
part of the Front End above the API
2.8
interoperability
ability of systems to exchange information and to make mutual use of the information that has
been exchanged
[SOURCE: ISO/IEC/TR 10000-1:1998, 3.2.1, modified.]
2 © ISO 2016 – All rights reserved

ISO 17575-2:2016(E)
2.9
on-board equipment
OBE
all required equipment on-board a vehicle for performing required EFC functions and
communication services
Note 1 to entry: Other sub-units should be considered optional.
2.10
proxy
optional part of a Front End (2.6) that communicates with external equipment and processes the data
received into an agreed format to be delivered to the Back End (2.3)
[SOURCE: ISO 17575-1:2016, 3.13]
2.11
service primitive
elementary communication service provided by the application layer protocol to the application processes
Note 1 to entry: The invocation of a service primitive by an application process implicitly calls upon and uses
services offered by the lower protocol layers.
[SOURCE: ISO 14906:2011, 3.18, modified — the subject has been deleted.]
2.12
toll service provider
entity providing toll services in one or more toll domains
[SOURCE: ISO 17573:2010, 3.23, modified — the definition has been condensed.]
2.13
toll
charge, tax or duty levied in connection with using a vehicle in a toll domain
[SOURCE: ISO/TS 19299:2015, 3.42, modified — “any” has been deleted from before “charge”.]
Note 1 to entry: The definition is the generalization of the classic definition of a toll as a charge, a tax, or a duty
for permission to pass a barrier or to proceed along a road, over a bridge, etc. The definition also includes fees
regarded as an (administrative) obligation, e.g. a tax or a duty.
2.14
toll charger
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO 17573:2010, 3.16, modified — “legal” has been deleted from before “entity” and “the use
of” has been added.]
3 Abbreviated terms
For the purpose of this document, the following abbreviated terms apply unless otherwise specified.
ADU Application data unit (ISO 14906)
APDU Application protocol data unit (ISO 14906)
AP Application process (ISO 14906)
API Application programming interface
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
ISO 17575-2:2016(E)
BE Back End
CN Cellular network
EID Element identifier (ISO 14906)
FE Front End
GNSS Global Navigation Satellite System
OBE On-board equipment (ISO 14906)
VAT Value added tax
4 EFC Front End communication architecture
4.1 General
A communications subsystem is required to establish the communication link between a Front End
(FE) and a Back End (BE) Application. It provides data transport for the tolling FE Application via the
communications session that takes part across the line shown in Figure 4. In cases where a proxy is
present in the FE system, the communications subsystem defines the communications between the BE
and the proxy. The link between the proxy and the on-board equipment (OBE) is out of the scope of
this part of ISO 17575. In cases where no proxy is present (the “smart client”), the communications
subsystem defines the communications between the OBE and the BE.
Front End Application
7. Application
UP API
Indications
Communications
API
DOWN API
Requests
6. Presentation
Communications
Subsystem 5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Figure 4 — Relationship between Application and Protocol Stack
The communications subsystem is further subdivided into two distinct components. The
communications API itself offers communications functionality to the FE Application. Below this is
the underlying communications technology, which provides the functionality that the API abstracts.
Although the API is independent of the underlying technology, it does place a number of functional
demands upon it. For this reason, the functional requirements on the underlying communications
technology are listed in 6.2.
4 © ISO 2016 – All rights reserved

ISO 17575-2:2016(E)
Some underlying technologies are more capable than others. In cases where a very capable technology
is in use, the code interfacing the API to the underlying technology will serve little more function than
a simple pass through. For more simplistic transport layer technologies the communications subsystem
will have to do considerably more.
It is expected that these APIs will be “reflected” in the BE such that FEs and BEs can communicate over
arbitrary bearer infrastructures. Details of the abstract API definitions are specified in Annex A. The
specification of the BE API is outside the scope of this part of ISO 17575.
4.2 Relationship with the overall EFC architecture
The communications API provides the lower layers of the interface shown in Figure 5. The API has no
semantic knowledge of the application data units (ADUs) it is carrying. It does differentiate between
“standard specific” and “arbitrary” ADUs but it has no semantic knowledge about what these mean
and simply carries them as transparent octet streams atop an arbitrary communication bearer that is
selected at runtime.
5 EFC communication services (functions)
5.1 General concept
The API carries two “types” of message (ADU): structured elements relating directly to the definitions
in other parts of ISO 17575, and unstructured elements, which are outside of the scope of this part of
ISO 17575 and receive no further consideration within it.
It is outside the scope of this part of ISO 17575 to identify the data elements for transmission and the
associated payload.
NOTE 1 The protocolVersion (part of ChargeReport) as defined in ISO 17575-1:2016 and
protocolVersion and tollContext (both part of aduHeader) as defined in ISO 17575-3:2016 can be useful
when implementing specific transaction(s).
The abstract API for the communications services can be implemented in any programming environment
that defines the concept of event delivery, allowing the API to report information or to deliver results of
operations to the FE Application. The general sequence of events is
— initialize and parameterize the communications interface,
— establish a communications session,
— transfer data in the context of the session,
— terminate the communications session, and
— de-initialize the communications interface.
In a normal case, the FE Application will initialize (a number of) communications interfaces when it
first starts. An active session is then established either as a direct action by the FE Application or in
response to an incoming request for a session from the BE. The flow of events through the lifetime are
shown in 5.2 to 5.7 and relevant definitions are given in Annex A.
ISO 17575-2:2016(E)
Session R:Ended/
StartSession/
Ending
Starting
Unknown
Instance
R:Started/ EndSession/
InitialiseInstance/
R:ADUsReceived/
DropInstance/
ADUSent
R:ADURequest/
ADURequest
R:ReceiveADUsReq/
No
Session Awaiting
Session
ADU 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

ISO 17575-2:2016(E)
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
ISO 17575-2:2016(E)
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

ISO 17575-2:2016(E)
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
...