EN ISO 12855:2012

SLOVENSKI STANDARD
01-maj-2012
Elektronsko pobiranje pristojbin - Izmenjava informacij med ponudnikom in
operatorjem cestninjenja (ISO 12855:2012)
Electronic fee collection - Information exchange between service provision and toll
charging (ISO 12855:2012)
Elektronische Gebührenerhebung - Informationsaustausch zwischen Dienstleistern und
Gebühreneinzugsunternehmen (ISO 12855:2012)
Perception du télépéage - Échange d'informations entre la prestation de service et la
perception du péage (ISO 12855:2012)
Ta slovenski standard je istoveten z: EN ISO 12855:2012
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN ISO 12855
NORME EUROPÉENNE
EUROPÄISCHE NORM
February 2012
ICS 35.240.60; 03.220.20
English Version
Electronic fee collection - Information exchange between service
provision and toll charging (ISO 12855:2012)
Perception du télépéage - Échange d'informations entre la Elektronische Gebührenerhebung - Informationsaustausch
prestation de service et la perception du péage (ISO zwischen Dienstleistern und Gebühreneinzugsunternehmen
12855:2012) (ISO 12855:2012)
This European Standard was approved by CEN on 28 January 2012.

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

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

Contents Page
Foreword .3
Foreword
This document (EN ISO 12855:2012) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN, in collaboration with Technical
Committee ISO/TC 204 "Intelligent transport systems".
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 2012, and conflicting national standards shall be withdrawn at
the latest by August 2012.
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.
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, 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.
INTERNATIONAL ISO
STANDARD 12855
First edition
2012-02-15
Electronic fee collection — Information
exchange between service provision and
toll charging
Perception du télépéage — Échange d'informations entre la prestation
de service et la perception du péage

Reference number
ISO 12855:2012(E)
©
ISO 2012
ISO 12855:2012(E)
©  ISO 2012
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 2012 – All rights reserved

ISO 12855:2012(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.2
3 Terms and definitions .3
4 Symbols and abbreviated terms .7
5 Architectural concept.8
5.1 Main roles in the Toll Charging environment .8
5.2 Information exchange between Toll Charging and Provision .8
6 Computational specification .16
6.1 Overview.16
6.2 Application Protocol Data Units .19
6.3 RequestADU data structure.21
6.4 AcknowledgeADU data structure .22
6.5 StatusADU data structure.22
6.6 TrustObjectsADU data structure .23
6.7 EFCContextDataADU data structure .24
6.8 ExceptionListADU data structure .24
6.9 ReportAbnormalOBEADU data structure .25
6.10 RetrieveTollDeclarationADU data structure .26
6.11 Toll DeclarationADU data structure.26
6.12 BillingDetailsADU data structure.27
6.13 PaymentClaimADU data structure.31
6.14 RetrieveUserDetailsADU data structure.32
6.15 ProvideUserDetailsADU data structure.32
6.16 RetrieveCCCEventADU data structure.33
6.17 ReportCCCEventADU data structure .34
6.18 Report QA data structure.34
7 Transfer mechanisms and supporting functions.35
7.1 Transfer mechanisms .35
7.2 Supporting functions .35
Annex A (normative) Data type specifications .36
Annex B (normative) Protocol Implementation Conformance Statement .52
Annex C (informative) How to use road network data attributes coded in GDF format .64
Annex D (informative) Example enforcement process applying standardized message exchanges.67
Annex E (informative) Data flow in a toll domain.73
Bibliography.75

ISO 12855:2012(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.
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 12855 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in collaboration
with Technical Committee CEN/TC 278, Road transport and traffic telematics.

iv © ISO 2012 – All rights reserved

ISO 12855:2012(E)
Introduction
The widespread use of tolling also requires provisions for users of vehicles that are circulating through many
different toll domains. Users should be offered a single contract for driving a vehicle through various toll
domains. Where those vehicles require a form of on-board equipment (OBE) this should be interoperable with
the toll systems in the various toll domains. In Europe, for example, this need has been officially recognized
and legislation on interoperability has already been adopted (see Directive 2004/52/EC). There is both a
commercial and economic justification in respect to the OBE and the toll systems for standards enabling
interoperability.
The system architecture defined in ISO 17573 is the basis for all standards that relate to tolling systems in the
toll domain. From this system architecture standard, other standards have consistently reused
⎯ common definitions of terms and concepts and basic system functionalities and structure,
⎯ common terminology, and
⎯ identified interfaces that are or need to be defined.
ISO 17573 uses ISO/IEC 10746-3 for the description of the architecture.
The following figure shows the scope of the group of electronic fee collection (EFC) related standards based
upon the architecture standard.
ISO/TS 17575-3
- Context data
Proxy
Toll Service Provider
ISO/TS 17575-1
(back office)
- Charging data
OBE
ISO 14906 ISO 12855 ISO 12855
- Charging identification & - Trust objects - Trust objects
Transfer Charing information - Exception list - Toll context data
- Transit information - QA parameters - Billing details
- User identification - Address data - Payment claims
ISO/TS 12813 for enforcement - QA parameters
- OBE interrogation
ISO/TS 13141 - Toll declaration
- RSE localisation data (GNSS)
Other proprietary Toll Charger
specific configuration data
Toll Charger
RSE
Toll declaration (DSRC, video,
(back office)
vehicle measurements .)
Figure 1 — Scope of EFC related standards
ISO 12855:2012(E)
A given transport service for a given vehicle is fully identified by one or several toll declarations, made
available to the Toll Charger. Toll declarations have to be made available according to the rules of the toll
regime of the toll domain.
The amount due for a given transport service used by a vehicle liable to toll is concluded by the Toll Charger
(TC) with the use of toll declarations (as described above) and calculation is made according to the rules of
the toll regime (formula, tariff tables, specific situations rules, traffic conditions, etc.).
The information above, associated with a given transport service, is named billing details; for a given transport
service, the billing details are referring to one or several toll declarations.
Depending on the toll regime, billing details are elaborated with information collected by the Toll Charger
and/or the relevant Toll Service Provider (TSP); they are concluded by the toll charger.
The Toll Charger elaborates and makes the payment claims (or toll payment claims) available to each Toll
Service Provider, according to the bilateral agreements it has with each Toll Service Provider, referring to
billing details. These payment claims include an amount due taking into account any specific commercial
conditions applicable to a vehicle, a fleet of vehicles or a given Toll Service Provider.
This International Standard identifies and specifies the set of messages exchanged between two actors in the
roles of Toll Service Provider and Toll Charger as defined in ISO 17573. To specify these interfaces, this
International Standard uses the enterprise description of the toll environment, and the interactions defined
between the named classes of roles, as defined in ISO 17573. This allows for a complete specification of the
data that is transferred between those identified entities. In addition to that, a number of computational
interfaces are identified, where interactions in terms of sequences of messages are defined.

vi © ISO 2012 – All rights reserved

INTERNATIONAL STANDARD ISO 12855:2012(E)

Electronic fee collection — Information exchange between
service provision and toll charging
1 Scope
This International Standard specifies
⎯ the interfaces between electronic fee collection (EFC) systems for vehicle related transport services, e.g.
road user charging, parking and access control; it does not cover interfaces for EFC systems for public
transport; an EFC system can include any EFC system, e.g. also systems automatically reading licence
plate numbers of vehicles passing a toll point;
⎯ an exchange of information between the central equipment of the two roles of service provision and toll
charging, e.g.
⎯ charging related data (toll declarations, billing details),
⎯ administrative data, and
⎯ confirmation data;
⎯ transfer mechanisms and supporting functions;
⎯ information objects, data syntax and semantics;
⎯ examples of data interchanges.
This International Standard supports any toll service and any technology used for charging.
It is defined as a toolbox standard of transactions and messages which can be used for the assigned purpose.
The detailed definitions of mandatory and optional elements in a real implementation are defined elsewhere. It
does not define all communication sequences, communication stacks and timings.
The scope of this International Standard is illustrated in Figure 2. The data types and associated coding
related to the data elements described in Clause 6 are defined in Annex A, using the abstract syntax notation
one (ASN.1) according to ISO/IEC 8824-1.
ISO 12855:2012(E)
Central equipment
Toll Service Provider
Scope of this
International
Standard
Central equipment
Toll Charger
Figure 2 — Scope of this International Standard
Any communication between Toll Charger and/or Toll Service Provider with any other involved party is outside
the scope of this International Standard. Any communication between elements of the Toll Charger and the
Toll Service Provider which is not part of the back office communication is outside the scope of this
International Standard.
The processes regarding the payments and exchanges of fiscal, commercial or legal accounting documents
are outside the scope of this International Standard.
The definitions of service communication channels, protocols and service primitive to actually transfer the
messages are outside the scope of this International Standard.
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 17573, Electronic fee collection — System architecture for vehicle-related tolling
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO/TS 17575-1, Electronic fee collection — Application interface definition for autonomous systems —
Part 1: Charging
ISO/TS 17575-3, Electronic fee collection — Application interface definition for autonomous systems —
Part 3: Context data
ISO/TS 17575-4, Electronic fee collection — Application interface definition for autonomous systems —
Part 4: Roaming
2 © ISO 2012 – All rights reserved

Trust objects
Context Data
Exception list
Toll declarations (GNSS)
Billing details
Payment claims
QA parameter
Address data for enforcement
ISO 12855:2012(E)
ISO/IEC 9646-7, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 7: Implementation Conformance Statements
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-4, Information technology — ASN.1 encoding rules: XML Encoding Rules (XER)
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
billing detail
for a given transport service, all necessary data required to determine and/or verify the amount due for the
service user
NOTE 1 If the data is accepted by both the Toll Charger and the Toll Service Provider then it is called a concluded
billing detail which can be used to issue a payment claim.
NOTE 2 For a given transport service, the billing detail is referring to one or several valid toll declaration(s). A valid
billing detail has to fulfil formal requirements, including security requirements, agreed between the Toll Service Provider
and the Toll Charger.
3.2
charge report
data structure transmitted from the front end to the Back End to report road usage data and supplementary
related information
NOTE In 2009/750/EC charge report is referred to as “toll declaration”.
3.3
charging data
toll relevant data produced by the on-board equipment and sent to the Toll Service Provider's back-office
systems
3.4
computational specification
decomposition of a system into objects performing individual functions and interacting at well defined
interfaces
3.5
context data
information defined by the responsible Toll Charger necessary to establish the toll due for circulating a vehicle
on a particular toll domain and to conclude the toll transaction
[ISO 17573, definition 3.1]
3.6
customer
person or legal entity that uses the service of a Toll Service Provider
[ISO 17573, definition 3.2]
NOTE Depending on the local situation, the customer can be the owner, lessor, lessee, keeper, (fleet) operator,
holder of the vehicle's registration certificate, driver of the vehicle, or any other third person.
ISO 12855:2012(E)
3.7
driver
person who drives a vehicle
[ISO 17573, definition 3.3]
NOTE The driver is assumed to operate (use/serve) the on-board equipment (e.g. the setting of the number of axles).
3.8
electronic fee collection
EFC
toll charging by electronic means via a wireless interface
NOTE 1 Adapted from ISO 17573, definition 3.4.
NOTE 2 The actual payment (collection of the fee) may take place outside the toll system.
3.9
enforcement
process of compelling observance of a law, regulation, etc.
[ISO 17573, definition 3.5]
NOTE In this context: the process of compelling observance of a toll regime.
3.10
interface
abstraction of the behaviour of an object that consists of a subset of the interactions of that object together
with a set of constraints on when they may occur
[ISO/IEC 10746-2]
3.11
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
[ISO 17573, definition 3.7]
NOTE For tolling, interoperability aims at enabling a vehicle to drive through various toll domains while having only
one on-board equipment operating under one contract with a Toll Service Provider.
3.12
on-board equipment
OBE
equipment fitted within or on the outside of a vehicle and used for toll purposes
[ISO 17573, definition 3.9]
NOTE The OBE does not need to include payment means.
3.13
one(s) liable for toll
person(s) or legal entities liable to pay toll under the operation of a toll regime
[ISO 17573, definition 3.10]
NOTE A toll regime can designate more than one person to be (jointly and severally) liable for paying the toll.
4 © ISO 2012 – All rights reserved

ISO 12855:2012(E)
3.14
payment claim
recurring statement referring to concluded billing details made available to the Toll Service Provider by the Toll
Charger who indicated and justified the amount due
NOTE The payment claim is used by the Toll Service Provider to issue financial objects to its customers (e.g.
invoices on behalf of the Toll Charger). A given toll payment claim is referring to billing details and takes into account any
specific commercial conditions applicable to a vehicle, a fleet of vehicles, a customer of a Toll Service Provider and/or a
Toll Service Provider. A valid “payment claim” has to fulfil formal requirements, including security requirements, agreed
between the Toll Service Provider and the Toll Charger.
3.15
roadside equipment
RSE
equipment located along the road transport network, for the purpose of communication and data exchanges
with on-board equipment
[ISO 14906, definition 3.1]
3.16
service user
see user (3.29)
3.17
tariff scheme
set of rules to determine the fee due for a vehicle in a toll domain for a tolled object at a certain day and time
[ISO 17573, definition 3.14]
EXAMPLE A table that shows the fee for various classes of vehicles.
3.18
toll
charge, tax, fee, or duty in connection with using a vehicle within a toll domain
[ISO 17573, definition 3.15]
NOTE The definition is a 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.19
Toll Charger
TC
legal entity charging toll for using a vehicle within a toll domain
[ISO 17573, definition 3.16]
NOTE In other documents the terms “operator” or “toll operator” can be used.
3.20
toll declaration
statement to a Toll Charger that confirms the presence of a vehicle in a toll domain in a format agreed
between the Toll Service Provider and the Toll Charger
[ISO 17573, definition 3.17]
NOTE A valid toll declaration has to fulfil formal requirements, including security requirements, agreed between the
Toll Service Provider and the Toll Charger.
ISO 12855:2012(E)
3.21
toll domain
area or part of a road network where a toll regime is applied
[ISO 17573, definition 3.18]
3.22
toll point
location within a toll domain where the on-board equipment has to issue a toll declaration
[ISO 17573, definition 3.19]
EXAMPLE A part of a toll plaza for electronic fee collector.
3.23
toll regime
set of rules, including enforcement rules, governing the collection of a toll in a toll domain
[ISO 17573, definition 3.20]
3.24
toll service
service enabling users having only one contract and one set of on-board equipment to use a vehicle in one or
more toll domains
[ISO 17573, definition 3.22]
3.25
Toll Service Provider
TSP
legal entity providing to its customers toll services on one or more toll domains for one or more classes of
vehicles
[ISO 17573, definition 3.23]
NOTE 1 In other documents the terms “issuer” or “contract issuer” can be used.
NOTE 2 The Toll Service Provider can provide the on-board equipment or can provide only a magnetic card or a smart
card to be used with on-board equipment provided by a third party.
NOTE 3 The Toll Service Provider is responsible for the operation (functioning) of the on-board equipment.
3.26
toll system
off-board equipment and possible other provisions used by a Toll Charger for the collection of toll for vehicles
NOTE 1 The on-board equipment is excluded from the definition. On-board equipment should be part of any toll system
for which it may be used.
NOTE 2 The actual payment (collection of the fee) may take place outside the toll system.
3.27
tolled object
distinguished part of a toll domain for which one or more tariff schemata apply
EXAMPLE An area, all public roads within an area, a bridge, a zone, or a stretch of a road (network).
6 © ISO 2012 – All rights reserved

ISO 12855:2012(E)
3.28
trust object
information object that is exchanged between entities to ensure mutual trust
EXAMPLE An electronic signature or an electronic certificate.
3.29
user
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
[ISO 17573, definition 3.26]
4 Symbols and abbreviated terms
ADU Application Data Unit
ANPR Automatic Number Plate Reading
APCI Application Protocol Control Information
APDU Application Protocol Data Unit (ISO 14906)
CCC Compliance Check Communication (ISO/TS 12813)
CRL Certificate Revocation List
DSRC Dedicated Short Range Communication (ISO 14906)
EFC Electronic Fee Collection (ISO 17573)
GNSS Global Navigation Satellite System
ICS Implementation Conformance Statement
IEC International Electrotechnical Commission
IUT Implementation Under Test
ITU International Telecommunication Union
LPN Licence Plate Number
OBE On-Board Equipment (ISO 14906)
OBU On-Board Unit
OCSP Online Certificate Status Protocol
OSI Open Systems Interconnection
PAN Personal Account Number (ISO 14906)
PICS Protocol Implementation Conformance Statement
QA Quality Assurance
RSE Roadside Equipment (ISO 14906)
SLA Service Level Agreement
SU Service User
SUT System Under Test (ISO 14907-1)
TC Toll Charger
TSP Toll Service Provider
ISO 12855:2012(E)
5 Architectural concept
5.1 Main roles in the Toll Charging environment
This International Standard is built upon ISO 17573. ISO 17573 defines the four main roles shown in Figure 3.

Figure 3 — Roles in the Toll Charging environment
Information exchanges are agreed upon between Toll Charger and Service Provider also taking into account
privacy regulations. The information exchanges needed by the Toll Charger and the Toll Service Provider to
perform their roles are described in this clause.
5.2 Information exchange between Toll Charging and Provision
5.2.1 General
The information exchange between the Service Provision and the Toll Charging roles supports the provision of
the following functionalities, which are all based on the EFC system behaviour definitions in ISO 17573:
⎯ Exchange Trust Objects
⎯ Originating and providing EFC context data
⎯ Manage Exception list
⎯ Report Toll declarations
⎯ Report Billing details
⎯ Claim payment for service usage
⎯ Exchange Enforcement data
⎯ Exchange Quality assurance parameters
8 © ISO 2012 – All rights reserved

ISO 12855:2012(E)
This International Standard leaves implementers the freedom of defining suitable protocol procedures, i.e. for
complex transactions, hence it only defines:
⎯ A basic interaction protocol (request – response) for information exchange
⎯ Basic protocol mechanisms, to be used to build more complex protocol procedures
⎯ The semantics and the format of the messages that are exchanged
The following subclauses describe the functionalities listed above.
5.2.2 Basic interaction protocol
Information exchanges happen by means of Application Protocol Data Unit (APDU) transfers.
Some APDU transfers need to be acknowledged. When this happens, related protocol procedures are
specified. This International Standard defines no provisions for complex transfers (transactions), i.e. APDU
transfers that cover several APDUs. Instead, this International Standard defines basic protocol mechanisms,
to be used by implementations that need to identify transactions.
5.2.3 Basic protocol mechanisms
5.2.3.1 General approach
This International Standard provides the following basic protocol mechanisms, which shall be implemented to
exchange information between the Toll Service Provider’s and the Toll Charger’s central equipment. These
basic protocol mechanisms consist of:
⎯ An identification schema for the messages that are exchanged.
⎯ A generic interaction (i.e. not related to any specific functionality) that allows requesting a specific
information exchange from the counterpart. This interaction is provided by the “Request” message.
⎯ A generic acknowledge mechanism (i.e. not related to any specific functionality) that allows
acknowledging a specific interaction. This mechanism is provided by the “Acknowledge” message.
⎯ A generic status mechanism (i.e. not related to any specific functionality) that allows providing status
information for a specific interchange. This mechanism is provided by the “Status” message.
By means of the above mechanisms, an implementation can build more complex protocol procedures,
including rollback, recovery, checkpointing or restart.
This International Standard does not specify timings and retry procedures for acknowledgements. Timeouts
can be defined as agreements between Toll Charger and Toll Service Provider to cover the case of missing
acknowledgments. To handle any lost messages a timeout system can be implemented.
5.2.3.2 Identification schema
Each interaction is performed by means of one or more message exchanges. Each message shall contain a
unique identifier in the namespace of the originator of the message. The combination of originator identifier
and message identifier ensures that all messages are uniquely identified.
5.2.3.3 Request message
The Request message may be used to:
⎯ Alert the counterpart that one is ready to accept any kind of information exchange.
⎯ Inform the counterpart that one is ready to accept a specific type of message, by indicating the type of
message one is ready to accept.
ISO 12855:2012(E)
⎯ Request the counterpart to re-issue a specific message, by indicating the type and the identifier of the
message.
⎯ Request for information identified by the type and message content.
5.2.3.4 Acknowledge message
The “Acknowledge” message is used whenever a specific message in an information exchange needs to be
confirmed. The “Acknowledge” message indicates the specific message to be acknowledged by specifying its
identifier. It may additionally carry an indication of a positive or negative acknowledgment.
5.2.3.5 Status message
The “Status” message is used to provide the counterpart general status information on the interface or inform
about status on previously transferred information. It may be used to:
⎯ Provide general information on the status of the interface.
⎯ Alert the counterpart that some previously provided information becomes invalid without any new
information being currently available.
⎯ Alert the counterpart that the previous information contained an error and has to be recalled.
5.2.4 Exchange Trust Objects
The “Exchange Trust Objects” functionality is derived from the EFC system behaviours “Adding (or excluding)
a new Toll Charger” and “Adding (or excluding) a new Service Provider”. Actions performed when executing
the above behaviours shall exchange Trust Objects to be used in order to secure their bilateral communication.
The functionality may also be used whenever an entity sees the need to update its own Trust Objects or
another entity may ask for the update of an already existing Trust Object.
NOTE Examples of Trust Objects are:
⎯ Asymmetric public keys
⎯ Certificates
⎯ Symmetric Keys
⎯ Certificate Revocation Lists
The Exchange Trust Objects functionality can be used by either the Toll Service Provider or Toll Charger.
The initiator of the exchange can request the sending of Trust Objects from the receiver by sending a
“Request” message. The “Request” message may contain an optional indicator that specifies already issued
Trust Objects. When no indicator is specified, the Trust Objects to be transferred shall be the current ones.
After receiving a “Request” message that asks for Trust Objects, the requested Trust Objects are generated
(or retrieved) by the recipient of the request and sent to the requesting party who shall acknowledge the
reception by issuing an “Acknowledge” message.
After acknowledgement, the exchanged Trust Objects shall be considered immediately valid unless they
contained a validity starting date. The validity period in this last case starts from the time indicated in the Trust
Objects.
5.2.5 Originating and providing EFC context data
The “Originating and providing EFC context data” functionality is derived from ISO 17573 as defined in the
EFC system behaviour “Adding, modifying or closing a toll regime”.
10 © ISO 2012 – All rights reserved

ISO 12855:2012(E)
The usage of the “Originating and providing EFC context data” functionality may be used by a Toll Charger
when any change of a toll domain or toll regime occurs, including the start of a new toll domain, by issuing an
“EFC Context Data” message.
Any Toll Service Provider may request from any Toll Charger at any time for any reason to send the current or
any previous version of the toll context data for a toll domain under its responsibility. This operation is
performed by means of a “Request” message.
Reception of an “EFC Context Data” message shall be acknowledged by means of an “Acknowledge”
message.
The information describing a toll regime uses one or more sets of EFC Context Data. It is defined through its
tolled objects and the rules associated with them. These data elements are defined in detail in
ISO/TS 17575-3 and extended in this International Standard for DSRC systems and other extensions.
Other toll regime properties to be configured by the Toll Charger are the interrelations a toll regime may have
in relation to others. These rules and configuration parameters are defined in ISO/TS 17575-4 and are
addressed within this International Standard as Toll Context interrelations.
5.2.6 Manage Exception list
5.2.6.1 General
The “Manage Exception list” functionality originates from ISO 17573 defined in the EFC system behaviours
“Collecting toll information – User billing” and “Collecting charging information (autonomous systems)”.
NOTE 1 To avoid the term of blacklist, which has a different meaning in various existing EFC systems, and to include
another list with a similar meaning [e.g. grey list or black list of Personal Account Numbers (PAN, as defined in ISO 14906),
list of blocked license plates, white list, etc.], this International Standard uses the term “Exception list” to summarize all
possibilities of limiting the usability of an OBE or giving information on the special handling of an OBE in a toll regime.
Other standards may still use differing terms, but they are all included in the term “Exception list”.
NOTE 2 The conditions and the periods of time of the acceptance of an OBE within a toll regime are limited, by putting
it on the Exception list or removing it. This is solely the responsibility of the Toll Service Provider that issued the OBE. Any
information sufficient for the identification of a specific vehicle or OBE by the Toll Charger (e.g. OBE ID, PAN, license
plate) may be included in the Exception list as agreed between TC and TSP.
5.2.6.2 Exception list entry requested by a Toll Charger
The “Manage Exception list” functionality may be used by a Toll Charger when it registers violations by a
specific Service User or wrong technical behaviour by a specific OBE.
NOTE 1 In this case the Toll Charger may issue a “Report Abnormal OBE” message to request the inclusion of this
OBE in the Exception list.
The Toll Service Provider shall acknowledge the decision to include the OBE on the Exception list by means
of an “Acknowledge” message.
NOTE 2 This may be due to non-conforming behaviour of the Service User or of a malfunctioning OBE or others.
5.2.6.3 Exception list entry decided by the Toll Service Provider
A Toll Service Provider can unilaterally add, modify or delete items in its Exception list.
The functionality is performed by issuing the “Exception List” message. This offers the Toll Service Provider
the opportunity to provide any information about an OBE of a Service User to the Toll Charger.
ISO 12855:2012(E)
NOTE 1 The message can include among others one of the following reasons:
⎯ Toll Service Provider has terminated its support/responsibility for a vehicle/OBE
⎯ An OBE was lost or stolen
⎯ The Toll Service Provider has started/accepted its support/responsibility for a vehicle/OBE
⎯ The Toll Charger is informed about the commercial conditions to apply to an OBE (e.g. discount for a group of
vehicles)
NOTE 2 The Exception list can be used to provide additional information on a vehicle/OBE for a toll regime (e.g.
specific commercial conditions) and/or limit or restrict the acceptance of an OBE within a toll regime operated via the road
infrastructure of a Toll Charger, where an exchange of data between Toll Service Provider and Toll Charger is needed.
Upon reception the Toll Charger may semantically check the received Exception list. If an error is detected in
the Exception list, the whole Exception list shall be disputed by sending an “Acknowledge” message indicating
the detected error.
The Toll Service Provider may then rectify the problem and transmit a new Exception list. Until a valid
Exception list is transmitted, the last correct list remains active in the systems of the Toll Charger.
If a new valid Exception list is received by the Toll Charger it shall be acknowledged by sending an
“Acknowledge” message.
5.2.7 Report Toll declarations
The “Report Toll declarations” functionality originates from ISO 17573 defined in the EFC system behaviour
“Collecting charging information (autonomous systems)”.
NOTE 1 The Charging data generated by an OBE is used to report a Service User entering, moving around in or
leaving a toll domain. A Service usage statement with an amount due can be made either by a single tolled object or by a
combination of several tolled objects. Any Service usage is reported as Charging data through an exchange of data
between an OBE/proxy (Front End system) and the central equipment (Back End system) managed by a Toll Service
Provider. This interface between Front End and Toll Service Provider is specified in ISO/TS 17575 Parts 1 to 4 and is not
covered by this International Standard.
The gathered Charging data shall be collected in the central system of the Toll Service Provider. If the Toll
Service Provider needs to enrich the Charging data in its central equipment, it may do so before sending it as
Toll declarations to the Toll Charger who offered the transport service. This optional possibility to enrich the
Charging data enables the concept of shared user data, where only limited information may be included in the
OBE, while the rest is held centrally at the issuing Toll Service Provider.
The Toll declarations shall contain all information required by the Toll Charger to calculate the amount due for
the use of a toll domain or verify the calculation done by the Toll Service Provider. Details about configuration
parameters for Charge reports are defined by the Toll Charger in the EFC context data.
A toll declaration shall be reported to the Toll Charger operating a toll domain, by means of a “Toll
Declaration” message.
NOTE 2 The toll declarations may be delivered periodically in an agreed frequency (e.g. weekly, daily, hourly, in real
time …) or upon triggering th
...