Une-En Iso 17573-12019

Copyrighted material licensed to IDOM.
No further reproduction or distribution permitted.

Printed / viewed by: [javier.crespo@idom.com] @ 2023-02-13
COPYRIGHT NOTICE
This document is the copyright of the Publisher. All rights reserved.
The contract allowing you to use this document contains the following terms of use which must be
followed:-
(a) You may view and print a single copy of a document contained in the Subscription for reference
purposes only and only for internal purposes within the site on which such copies are made,
providing such copies are dated and destroyed after the reference usage, typically no more than 60
working days after use, subject to the exception described in clause (b) below. Such copies may not
be filed to form part of any hard copy reference collection.
(b) Where you have a specification or tender requirement to reproduce a document or portions of a
document as part of its documentation for external submission in response to a tender, the
necessary pages of the document, including the whole document if required, may be reproduced
and submitted provided a copyright notice is included. You shall notify SAI Global of any such use.
For internal and archival purposes only, a paper copy may be attached to your documentation and
shall be considered a permanent part of that documentation.
(c) Under no circumstances are you permitted to reproduce all or part of any document for external
use or for use in any other site or group of sites, except as set forth in (b) above.
(d) You may not remove any proprietary markings or electronic watermarks, including any copyrights
and trademarks.
(e) You may copy a maximum of 25% of the content of a document within the Subscription and paste
it to another document for internal use. The copied content in the new document must contain a
copyright notice “Copyright [name of publisher] Date where date is the date of copyrighted material.
Such content is licensed for use only for the duration of the relevant Subscription.
(f) For ISO standards, the material is reproduced from ISO publications under International
Organization for Standardization (ISO) Copyright License number SAI GLOBAL/MCEA/2008. Not for
resale. No part of these ISO publications may be reproduced in any form, electronic retrieval system
or otherwise, except as allowed under the copyright law in the country of use, or with the prior
written consent of ISO (Case postale 56, 1211 Geneva 20, Switzerland, email: copyright@iso.org) or
ISO’s Members.
In USA and Canada Contact

SAI GLOBAL, 20 Carlson Court, Etobicoke, ON
M9W 7K6, Canada
+1 416 401 8730. Email: i2iSupport-US@saiglobal.com
In Europe Contact
SAI GLOBAL, Heron House, Davy Avenue, Knowlhill, Milton Keynes, MK5 8HJ, UK
+44 203 327 3140. Email: i2iSupport-EMEA@saiglobal.com
In Asia/Pacific Contact
SAI Global Ltd, Level 37, 680 George Street, Sydney, NSW 2000, Australia
+61 131 242. Email: i2iSupport-APAC@saiglobal.com
Web: www.saiglobal.com
Norma Española
UNE-EN ISO 17573-1:2019
Idioma: Inglés
Peaje electrónico. Arquitectura del sistema para peaje

relacionado con vehículos. Parte 1: Modelo de
referencia (ISO 17573-1:2019). (Ratificada por la
Asociación Española de Normalización en octubre de
2019.)
Asociación Española
de Normalización
Génova, 6 - 28004 Madrid
915 294 900
info@une.org
www.une.org
UNE-EN ISO 17573-1:2019
Peaje electrónico. Arquitectura del sistema para peaje relacionado con vehículos.
Parte 1: Modelo de referencia (ISO 17573-1:2019). (Ratificada por la Asociación
Española de Normalización en octubre de 2019.)
Electronic fee collection - System architecture for vehicle-related tolling - Part 1: Reference model (ISO
17573-1:2019) (Endorsed by Asociación Española de Normalización in October of 2019.)
Perception électronique du télépéage - Architecture de systèmes pour le péage lié aux véhicules - Partie 1:
Modèle de référence (ISO 17573-1:2019) (Entérinée par l'Asociación Española de Normalización en
octobre 2019.)
En cumplimiento del punto 11.2.5.4 de las Reglas Internas de CEN/CENELEC Parte 2, se ha

otorgado el rango de documento normativo español UNE al documento normativo europeo
EN ISO 17573-1:2019 (Fecha de disponibilidad 2019-09-04)
Este documento está disponible en los idiomas oficiales de CEN/CENELEC/ETSI.
Este anuncio causará efecto a partir del primer día del mes siguiente al de su publicación en
la revista UNE.
La correspondiente versión oficial de este documento se encuentra disponible en la Asociación Española de

Normalización (Génova 6 28004 MADRID, www.une.org).
Las observaciones a este documento han de dirigirse a:
Asociación Española de Normalización

Génova, 6
28004 MADRID-España
Tel.: 915 294 900
info@une.org
www.une.org
 UNE 2019
Prohibida la reproducción sin el consentimiento de UNE.
Todos los derechos de propiedad intelectual de la presente norma son titularidad de UNE.
UNE-EN ISO 17573-1:2019
EUROPEAN STANDARD EN ISO 17573-1

NORME EUROPÉENNE
EUROPÄISCHE NORM September 2019
ICS 03.220.20; 35.240.60
English Version
Electronic fee collection - System architecture for vehicle-

related tolling - Part 1: Reference model (ISO 17573-
1:2019)
Perception électronique du télépéage - Architecture de Elektronische Gebührenerhebung - Systemarchitektur
systèmes pour le péage lié aux véhicules - Partie 1: für fahrzeugrelevante Maut - Teil 1: Referenzmodell
Modèle de référence (ISO 17573-1:2019) (ISO 17573-1:2019)
This European Standard was approved by CEN on 7 July 2019.
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, Republic of North Macedonia, Romania, Serbia, 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: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 17573-1:2019 E
worldwide for CEN national Members.
UNE-EN ISO 17573-1:2019
EN ISO 17573-1:2019 (E) Printed / viewed by: [javier.crespo@idom.com] @ 2023-02-13
Contents Page
European foreword....................................................................................................................................................... 3
2
UNE-EN ISO 17573-1:2019
Printed / viewed by: [javier.crespo@idom.com] @ 2023-02-13 EN ISO 17573-1:2019 (E)
European foreword
This document (EN ISO 17573-1:2019) 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 March 2020, and conflicting national standards shall
be withdrawn at the latest by March 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
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, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Endorsement notice
The text of ISO 17573-1:2019 has been approved by CEN as EN ISO 17573-1:2019 without any
modification.
3
UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Contents Page
Foreword...........................................................................................................................................................................................................................................v
Introduction................................................................................................................................................................................................................................. vi
1 Scope.................................................................................................................................................................................................................................. 1
2 Normative references....................................................................................................................................................................................... 1
3 Terms and definitions...................................................................................................................................................................................... 2
4 Symbols and abbreviated terms............................................................................................................................................................ 4
4.1 Symbols.......................................................................................................................................................................................................... 4
4.2 Abbreviated terms................................................................................................................................................................................ 4
5 The EFC community: roles and objectives................................................................................................................................... 5
5.1 General............................................................................................................................................................................................................ 5
5.2 Other ITS systems and services................................................................................................................................................. 6
5.3 Sensors, vehicle system and common equipment..................................................................................................... 6
5.4 Infrastructure sourced data.......................................................................................................................................................... 6
5.5 Financial/Commercial systems................................................................................................................................................. 6
5.6 Telecommunication systems........................................................................................................................................................ 7
5.7 Jurisdiction/Authorities................................................................................................................................................................... 7
5.8 Standardisation bodies..................................................................................................................................................................... 7
5.9 Common service rights provider.............................................................................................................................................. 7
6 Roles internal to the EFC domain......................................................................................................................................................... 8
6.1 General............................................................................................................................................................................................................ 8
6.2 EFC domain roles................................................................................................................................................................................... 8
6.3 Interoperability manager................................................................................................................................................................ 8
6.3.1 Short description.............................................................................................................................................................. 8
6.3.2 Responsibilities.................................................................................................................................................................. 9
6.4 Toll service provider........................................................................................................................................................................... 9
6.4.1 Short description.............................................................................................................................................................. 9
6.4.2 Responsibilities.................................................................................................................................................................. 9
6.5 User of the service.............................................................................................................................................................................. 10
6.5.1 Short description........................................................................................................................................................... 10
6.5.2 Responsibilities............................................................................................................................................................... 10
6.6 Toll charger role................................................................................................................................................................................... 11
6.6.1 Short description........................................................................................................................................................... 11
6.6.2 Responsibilities............................................................................................................................................................... 11
6.7 EFC functional roles and responsibilities...................................................................................................................... 12
7 Services........................................................................................................................................................................................................................ 13
7.1 Overview.................................................................................................................................................................................................... 13
7.2 Sub-services involving toll charger, toll service provider and interoperability
manager roles........................................................................................................................................................................................ 14
7.2.1 Adding or deleting a new toll charger......................................................................................................... 14
7.2.2 Adding or deleting a new toll service provider................................................................................... 16
7.2.3 Adding or modifying a toll regime.................................................................................................................. 17
7.2.4 Defining rules................................................................................................................................................................... 18
7.2.5 Monitoring operations.............................................................................................................................................. 19
7.2.6 Handling disputes......................................................................................................................................................... 20
7.3 Sub-services involving the toll service provider and user.............................................................................. 21
7.3.1 Providing EFC contract............................................................................................................................................. 22
7.3.2 Providing customer care......................................................................................................................................... 24
7.3.3 User billing.......................................................................................................................................................................... 25
7.4 Sub-services involving the toll charger and toll service provider............................................................ 26
7.4.1 Collecting transit information in short-range communication systems........................ 26
7.4.2 Collecting charging information (autonomous systems)........................................................... 27
7.4.3 Collecting transit information (not OBE-based systems)........................................................... 28
© ISO 2019 – All rights reserved iii

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E) Printed / viewed by: [javier.crespo@idom.com] @ 2023-02-13
7.4.4 Providing payment information....................................................................................................................... 28

7.4.5 Detecting Exceptions.................................................................................................................................................. 30
7.4.6 Trust objects exchange............................................................................................................................................. 30
7.4.7 Handling exceptions................................................................................................................................................... 31
7.4.8 Providing local information................................................................................................................................. 32
Annex A (informative) Mapping EFC architecture to the C-ITS architecture............................................................34
Annex B (informative) Information schemata and basic information types............................................................37
Annex C (informative) Enterprise objects within roles..................................................................................................................43
Bibliography.............................................................................................................................................................................................................................. 48
iv © ISO 2019 – All rights reserved

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso
.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition of ISO 17573-1, cancels and replaces ISO 17573:2010, which has been technically
revised.
The main changes compared to ISO 17573:2010 are as follows:
— update of the normative references, terms and definitions and abbreviated terms clauses and the
Bibliography;
— relocation of previous Clause 8 (Information schemata and basic information types) to informative
Annex B;
— removal of Clauses 9 (interfaces and computational objects) and 10 (Points of observation and view
point correspondences), Annex A (Short Open Distributed Processing (ODP) description), Annex B
(Comparison with ISO/TS 17573:2003), Annex C (Relations with this International Standard and
IFMSA), Annex D (Relation with the European Electronic Tolls Service) and Annex E (Example of the
Japanese electronic toll system);
— addition of the new informative Annex A (Mapping of the EFC architecture onto the C-ITS
architecture) and Annex C (Enterprise objects within roles).
A list of all parts in the ISO 17573 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
© ISO 2019 – All rights reserved v

UNE-EN ISO 17573-1:2019
Introduction
The widespread use of tolling also requires provisions for users of vehicles that are roaming through
many different toll domains. Users should be offered a single contract for driving a vehicle through
various toll domains and those vehicles require on-board equipment (OBE) that is interoperable with
the toll systems in the various toll domains. In Europe, for example, this need has been recognised and
legislation on interoperability has been adopted (Directive 2004/52).
In addition to specialised standards there is also a need for a system architecture that:
— provides an architectural “umbrella” for other EFC standards in terms of a common definition of
terms and concepts, basic system functionalities, and structure;
— provides a common terminology which supports its users to improve the quality of specifications to
be used in an international market,
— to reduce the risk for conflicting interpretations of specifications (purchaser) and descriptions
(supplier),
— to simplify the communication between experts from different continents, and
— to enhance the potential use of other EFC standards;
— defines a common framework, which enables both:
— identification of potential activities subject to standardization, and
— maintaining a common and consistent view of the whole area;
— defines the boundaries between the EFC and external domains;
— identifies all architectural objects that lay inside the EFC boundaries;
— provides a basic understanding of EFC, EFC interoperability, and the EFC services being offered.
Toll systems conforming to this document may be used for various purposes including measured
distance toll, road segment toll, closed network toll, cordon toll, area toll, time-based toll and collecting
fees for the use of bridges, tunnels, ferries, or for parking.
ISO 17573:2010 was based on a conceptual model defined in ISO/TR 14904 (withdrawn standard). Since
then ideas on conceptual models have evolved in several regional projects and implementations, e.g. in
Japan and Europe. Those new models have been detailed to a further extent compared to ISO 17573:2010
and are closer to real life implementations. This document is based on these new conceptual models
and uses the associated terms and definitions.
Although there are many differences, collecting a toll for vehicles can, to some extent, be compared
with collecting a fare for public transport. Architectural harmonisation of the collection of fee and fare
may be desirable from a policy and from a user point of view. In the past, ISO 24014-1 prepared by
ISO TC 204 used ISO 17573:2010 as a starting point. This document has benefited from that and has
also taken ISO 24014-1 into account.
In this document, the Open Distributed Processing (ODP) standard is used for the description of the
architecture.
The ODP standard gives a vocabulary and modelling tools to see the architecture of a system from
different perspectives (the viewpoints), in order to cover, e.g. hardware components as well as network
protocols or interfaces or roles and general policies of the system itself. This is accomplished using
different sets of concepts and terminologies, each one of those expressed as a viewpoint language. A
complete description of a real system can only be achieved when all viewpoint models are designed.
This allows for a clear separation of concerns and an easier way to define a system.
vi © ISO 2019 – All rights reserved

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

In more recent years, the development of concepts and standards in the field of Cooperative ITS (C-ITS,
ISO TC 204 and CEN TC 278) led to the definition of a general enterprise viewpoint architecture for
C-ITS (ISO 17427-1) that, by following the same approach of using the ODP architecture to model a
complex system, defined concepts and terms for the more general realm of C-ITS.
This document gives a description of the architecture of the toll systems environment from the
enterprise viewpoint, by refining and extending what had been already done in ISO 17573:2010.
Correspondences between concepts and terms in this document and those in ISO 17427-1 are shown in
Annex A. In addition, this document gives in Annex B the foundations of the information viewpoint by
identifying information interactions and general information objects. With respect to ISO 17573:2010,
this document removes all security requirements on interfaces, which are better and more generally
dealt with in ISO 19299.
This document is Part 1 of a multipart standard that is made up of the following parts:
— ISO 17573-1, Electronic fee collection — System architecture for vehicle related tolling — Part 1:
Reference model (this document)
— ISO/TR 17573-21), Electronic fee collection — System architecture for vehicle related tolling — Part 2:
Terminology
1) Under development. Current stage: 30.99
© ISO 2019 – All rights reserved vii

UNE-EN ISO 17573-1:2019
UNE-EN ISO 17573-1:2019
INTERNATIONAL STANDARD ISO 17573-1:2019(E)
Electronic fee collection — System architecture for vehicle-

related tolling —
Part 1:
Reference model
1 Scope
This document defines the architecture of electronic fee collection (EFC) system environments, in
which a customer with one contract may use a vehicle in a variety of toll domains with a different toll
charger for each domain.
EFC systems conforming to this document can be used for various purposes including road (network)
tolling, area tolling, collecting fees for the usage of bridges, tunnels, ferries, for access or for parking.
From a technical point of view the considered toll systems may identify vehicles subject to tolling by
means of electronic equipment on-board in a vehicle or by other means (e.g. automatic number plate
recognition, ANPR).
From a process point of view the architectural description focuses on toll determination, toll charging,
and the associated enforcement measures. The actual collection of the toll, i.e. collecting payments, is
outside of the scope of this document.
The architecture in this document is defined with no more details than required for an overall overview,
a common language, an identification of the need for and interactions among other standards, and the
drafting of these standards.
This document as a whole provides:
— the enterprise view on the architecture, which is concerned with the purpose, scope and policies
governing the activities of the specified system within the organization of which it is a part;
— the terms and definitions for common use in an EFC environment;
— a decomposition of the EFC systems environment into its main enterprise objects;
— the roles and responsibilities of the main actors. This document does not impose that all roles
perform all indicated responsibilities. It should also be clear that the responsibilities of a role may
be shared between two or more actors. Mandating the performance of certain responsibilities is the
task of standards derived from this architecture;
— identification of the provided services by means of action diagrams that underline the needed
standardised exchanges;
— identification of the interoperability interfaces for EFC systems, in specialised standards (specified
or to be specified).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 7498-1:1994, Information technology — Open Systems Interconnection — Basic Reference Model:
The Basic Model — Part 1
© ISO 2019 – All rights reserved 1

UNE-EN ISO 17573-1:2019
ISO/IEC 10746-2, Information technology — Open distributed processing — Reference model:

Foundations — Part 2
ISO/IEC 10746-3, Information technology — Open distributed processing — Reference model:
Architecture — Part 3
ISO 14813-5, Transport information and control systems — Reference model architecture(s) for the TICS
sector — Part 5: Requirements for architecture description in TICS standard
ISO/IEC 15414, Information technology — Open distributed processing — Reference model — Enterprise
language
3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1:1994,
ISO/IEC 10746-2, ISO/IEC 10746-3, ISO 14813-5 and ISO/IEC 15414, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
automatic number plate recognition
technology that uses optical character recognition on images to read vehicle registration plates
3.2
artefact
physical object of material or physical piece of information or a system or subsystem that is used in an
ITS system
3.3
billing detail
information needed to determine or verify the amount due for the usage of a given service
3.4
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
3.5
electronic fee collection
fee collection by electronic means
Note 1 to entry: The actual payment (collection of the fee) may take place outside the toll system.
3.6
enforcement
measures or actions performed to achieve compliance with laws, regulations or rules
Note 1 to entry: In this context: the process of compelling observance of a toll regime.
3.7
interoperability
ability of systems to exchange information and to make mutual use of the information that has been
exchanged
EXAMPLE Tolling interoperability aims at enabling a vehicle to drive through various toll domains while
having only one OBE operating under one contract with a toll service provider.
2 © ISO 2019 – All rights reserved

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

3.8
localisation augmentation
information sent by the roadside equipment to the on-board equipment to augment the positioning for
autonomous systems
3.9
on-board equipment
all required equipment on-board a vehicle for performing required electronic fee collection (EFC)
functions and communication services
3.10
roadside equipment
equipment located along the road, either fixed or mobile
3.11
role
set of responsibilities
3.12
short-range communication
tolling technique based on transfer of information via a radio connection between a roadside equipment
and an on-board equipment
Note 1 to entry: This includes 5,8 GHz DSRC as well as ITS-G5 and RFID.
3.13
tariff scheme
set of rules to determine the fee due for a vehicle within a toll domain
3.14
toll
charge, tax or duty levied in connection to using a vehicle in a toll domain
3.15
Toll Charger
entity which levies a toll for the use of vehicles in a toll domain
3.16
toll declaration
statement to declare the usage of a given toll service to a toll charger
3.17
toll domain
area or part of a road network where a certain toll regime is applied
3.18
toll regime
set of rules, including enforcement rules, governing the collection of a toll in a toll domain
3.19
toll scheme
organizational view of a toll regime, including the actors and their relationships
3.20
toll service
service enabling users to pay a toll
3.21
Toll Service Provider
entity providing toll services in one or more toll domains

UNE-EN ISO 17573-1:2019
3.22
transport service
transport infrastructure related service which is offered to the user
3.23
trust object
information object that is exchanged between entities to ensure mutual trust
EXAMPLE Electronic signature or an electronic certificate.
4 Symbols and abbreviated terms
4.1 Symbols
In action diagrams, the following graphical conventions apply:
Rounded corner boxes indicate responsibilities and related activities

within roles
Arrows crossing borders between roles indicate information exchanges

between roles as activities performed within responsibilities
Vertical arrows within activities represent execution steps
Solid circles represent start of activities
Partially coloured circles represent end of activities
Solid horizontal bars represent decision gates
4.2 Abbreviated terms

For the purpose of this document, the following abbreviated terms apply throughout the document
unless otherwise specified.
ANPR Automatic Number Plate Recognition
CE Central Equipment
C-ITS Cooperative ITS
DSRC Dedicated Short-Range Communication
EETS European Electronic Toll Service
EFC Electronic Fee Collection
GNSS Global Navigation Satellite Systems

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

ID Identity
IFMSA Interoperable Fare Management System Architecture
ITS Intelligent Transport Systems
OBE On-board Equipment
ODP Open Distributed Processing
RFID Radio Frequency Identification
RSE Roadside Equipment
SAM Secure Application Module
SLA Service Level Agreement
SRC Short Range Communication
TC toll charger
TSP toll service provider
5 The EFC community: roles and objectives
5.1 General
Electronic fee collection (EFC) is an ITS service enabling the user of a vehicle-related transport service
to pay for the related transport service, e.g. the use of a tolled road, without manual intervention. The
ITS application providing the ITS service will usually be implemented in equipment installed in the
vehicle, at the roadside and in central systems. In some scenarios, it also includes personal equipment,
e.g. smartphones.
The EFC architecture can be described by a community of external and internal enterprise objects with
the objective of providing an EFC service with its benefits regarding traffic safety, traffic efficiency,
comfort and mobility to the EFC service user. External enterprise objects are involved in the provision
of the EFC service but are not set up for the sole purpose of EFC. This document only includes the
definition of the internal enterprise objects, but the external enterprise objects are shortly described
in this clause to give the complete picture of the EFC community. Figure 1 shows the external objects in
the EFC community.

UNE-EN ISO 17573-1:2019
Figure 1 — Enterprise objects in the EFC community
The following subclauses give a concise description of each enterprise object depicted in Figure 1.
Detailed responsibilities for roles defined within the EFC domain are dealt with in Clause 6.
5.2 Other ITS systems and services

An ITS service may generally build on data provided by other ITS systems or ITS services. Objects in the
EFC domain may for instance receive data from other traffic management or information systems as
input to pricing algorithms used in an EFC system.
5.3 Sensors, vehicle system and common equipment

An EFC domain may use information from vehicle sensors and data stores integrated in the vehicle
where the main purposes of the sensor or data store are not related to EFC. The information is retrieved
from the sensors and data stores and used for the toll or fee calculation. Examples of such sensors and
data stores are GNSS sensors (e.g. in devices used for navigation, fleet management), tachograph, trailer
sensor, suspension sensors, axle in use sensors and vehicle-related information stored in a secure
application module (SAM). The data stores could be either in the vehicle or elsewhere, e.g. a computer
installed within the EFC domain.
NOTE Shipped goods may become relevant in future tolling schemes.
5.4 Infrastructure sourced data

An EFC domain may use data from environmental sensors, e.g. pollution measurements, for the toll or
fee calculation. A dynamic road pricing scheme may for instance use both the pollution measurements
from environmental sensors and the data on traffic flows and speeds for the dynamic toll or fee
calculation. Sensors that are solely installed for the purpose of EFC are defined to be part of the internal
enterprise objects.
5.5 Financial/Commercial systems

The functionality requested from financial/commercial systems is to provide the financial services
requested by the EFC internal enterprise objects. The services will mainly be transfer of money
between entities in the EFC community. It is important to note that the EFC internal enterprise objects
handle charging data while the financial/commercial systems handle payment information (‘money’).

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

This document makes a strict distinction between the payment (financial) domain supporting the EFC
domain and the charging domain within the EFC domain itself. Only the charging in the EFC domain is
covered by this document.
5.6 Telecommunication systems

The functionality requested from the telecommunication systems is to provide telecom services
requested by the EFC domain. Examples of such services could be cable network for transfer of data
between the operators of the EFC internal enterprise objects and air-interface network for transfer of
data between the EFC charging equipment and the OBE, when not covered by EFC specific artifacts.
5.7 Jurisdiction/Authorities
The responsibilities of the external enterprise object called Jurisdiction/Authorities is to define the
framework in which an EFC domain shall operate. The framework is defined by policies constituting
laws and regulations, mandates, constraints and requirements. Different authorities define different
policies:
— Road and transport authorities, e.g. a department of transport, may define policies related to the
type of and availability, reliability and quality of the transport service subject to a toll or fee. The
authorities may also, in co-operation with the financial authorities, define policies for tariffing
principles to be used in an EFC domain. The authorities may also, in co-operation with the financial
authorities, define the policies that govern the configuration of the EFC enterprise objects and
assignment of roles to enterprise objects as well as the environmental contracts that govern the
system. An example here would be that the authorities define the policy which is the basis for the
contract between an operator taking the role of issuing EFC contracts and the operators taking the
toll charging roles.
— Telecom authorities may define policies for the use of telecom systems, e.g. frequencies in air-
interface communication systems.
— Financial authorities may define policies for an EFC domain and the financial environment it shall
operate, e.g. whether the toll is a tax or a fee. They may also define policies for the use of certain
types of payment means, e.g. electronic purses, and the split of roles between the EFC domain and
the financial systems.
— Data protection authorities may define policies for the security and privacy in an EFC domain.
— Certification authorities may issue public key certificates.
The interactions between the EFC domain and the authorities also cover access to information kept by
the authorities, e.g. national vehicle registers.
5.8 Standardisation bodies

The responsibilities of the standardisation bodies are to provide EFC standards and other standards
or specifications relevant for EFC domain. There are interactions with an EFC domain concerning EFC
standards to be used for EFC domain as well as input from EFC domain to the standardisation bodies,
e.g. by toll charging operators taking part in the preparation of EFC standards.
5.9 Common service rights provider

The responsibilities of the common service rights provider are to provide the basic artefacts,
mechanism, organizational structure, and information transfer tools by which an EFC system can
interoperate with other transport systems. The common service rights provider allows, among other
things, for a single means of payment to be used, e.g. in both EFC systems and public transport systems.

UNE-EN ISO 17573-1:2019
Its role, responsibilities, and requirements on EFC systems, as well as its interactions with the roles
internal to the EFC domain are standardised in ISO/TS 211932)[5].
6 Roles internal to the EFC domain
6.1 General
This document describes the different roles in an EFC domain as the defined collections of
responsibilities in the EFC scope. Roles are described in general terms, i.e. as sets of responsibilities
where each set includes responsibilities that are logically related to each other, either by their objectives
or the actors that may take the role.
6.2 EFC domain roles

EFC domain roles can be grouped in two sets, one related to the functional operation of the systems,
and another one related to system operation. This document is built on the terminology of the EFC
domain that can be summarised by the diagram in Figure 2.
Figure 2 — Roles in a tolling environment
The functional operation roles are responsible for all activities related to the functional operation of
the system, in this case the system providing the services in the ITS service group called Electronic Fee
Collection (EFC).
The following clauses describe the above identified EFC roles, indicating the responsibilities for each role.
6.3 Interoperability manager
6.3.1 Short description
A specific role is identified to manage an EFC domain, i.e. defining and maintaining a set of rules that,
taken together, defines the policy of a given regime or of the overall EFC domain. These responsibilities
pertain to the system operation, and it is to be noted that, differently from other roles, the
2) Under development. Current stage: 30.99.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

interoperability manager role can hardly be fulfilled by a single actor. Rather, its responsibilities are in
real EFC systems often taken (if at all) by different actors and regulations. Given its general nature, this
role will not be specified further in this document.
6.3.2 Responsibilities
The responsibilities of the interoperability manager role include:

— Setting rules, including:
— Defining the supported security and privacy policies for the EFC system, acting as security
authority that defines the security interaction policy among the different security domains.
— Defining and maintaining ID-schemes and, if necessary, supporting the issuing of IDs ensuring
unique registration codes for organisations and components and unique identifiers or rules for
generating unique identifiers for the EFC applications and messages.
— Certifying EFC constituents, including:
— Defining the certification requirements for actors involved and equipment used in the EFC system,
— Giving or withdrawing permissions to operate to involved actors,
— Monitoring of operations via periodical report.
— Handling disputes, including:
— Defining the operational procedures among the operators,
— Managing disputes among operators.
6.4 Toll service provider
The toll service provider role is responsible for the contracts with the user role, and provides artefacts,
mechanisms, organizational structures, and information transfer tools needed to run an EFC system.
Responsibilities of this role pertain to the functional operation of the system. This role is fulfilled by
direct interactions with the interoperability manager role, the toll charger role, and the user role.
Responsibilities of the toll service provider role include:

— Providing basic provisions, including:
— providing the OBE, when tolling is performed by means of on-board electronic equipment,
— guaranteeing the payment of the toll to the entity performing the toll charger role,
— organizing the payment modalities for the user,
— collecting the money from the signer of the EFC contract,
— managing the customer relationships related to the use of the toll service concerning information,
claims, questions and answers, error handling and any contractual or financial matters,
— implementing and adhering to the security and privacy policies for the toll systems,

UNE-EN ISO 17573-1:2019
— monitoring the actual operational quality relative to agreed SLAs.

— Acting as a contract agent, including:
— offering contractual relations according to defined conditions to interested users and concluding
contractual agreements,
— providing and managing the EFC contract including the service rights for the toll service user.
— Providing toll declaration, including:
— making sure that the OBE is reporting information needed for the toll charging in a secure way,
— providing context data originated elsewhere (e.g. by a toll charger role) in a way that they can
be installed in the OBE.
— Customising the OBE, including customising the OBE in a secure way.
— Maintaining the OBE, including maintaining the functionality of the OBE.
6.5 User of the service
In this document, a transport service is related to the use of or the presence of a vehicle in a toll domain.
The toll domain may encompass a road network, a specific section of a road (e.g. a bridge or a tunnel)
or a specific area offering a service (e.g. a ferry, a parking lot, or access to a protected area in a city).
It could also be any service related to the use of a vehicle in the transport system (e.g. a petrol station
enabling the driver to buy petrol) by means of EFC.
A role is thus identified that covers all aspects of using the toll system and, if applicable, of the transport
service. Implementations of toll systems in various domains commonly refer to this role as, e.g. driver,
user or customer. Responsibilities of this role pertain to the functional operation of the system. This
role directly interacts with the toll service provider role.
Responsibilities of the user role include:

— Being liable for the toll including:
— using the OBE, when tolling is performed by means of on-board equipment, as a tool to fulfil its
obligations,
— interacting with the OBE when it is present on-board, e.g. declaring the vehicle characteristics
for the vehicle subject to toll or receiving messages and acting on the messages from the OBE,
— behaving according to the rules of a specific toll system, e.g. recognising a signal or a road sign.
— Owning or operating a vehicle, including:
— adhering to the toll regime for a toll domain,
— signing a contract with a toll service provider,
— signing a contract with the issuer of the EFC contract becoming responsible for compliance to
the rules related to the use of the toll service,
— acquiring an OBE,
— installing and eventually de-installing the OBE in the vehicle,

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

— terminating the contractual relation to the toll service provider,

— receiving the bill, e.g. by means of an invoice, for a service that has been used and a toll to be paid,
— paying the toll included in the bill,
— storing and protecting the contractual data and eventually the payment means, e.g. an electronic
purse, needed for the toll charging and communicating the data to other actors having roles
related to issuing or toll charging. This role is always bound to the OBE.
6.6 Toll charger role
The toll charger role defines the toll regime, operates the toll system and may provide transport
services. It provides artefacts, mechanisms, organizational structures, and information transfer tools
needed to run an EFC system. Responsibilities of this role pertain to the functional operation of the
system. This role is fulfilled by direct interactions with the interoperability manager and the toll
service provider roles.
The responsibilities of the toll charger role include:

— Basic charging, including:
— providing, if applicable, the transport service, e.g. access to a road network, a parking lot or a
ferry connection,
— defining the charging principles for the service offered, e.g. the tariffing principles for a tolled
road or zone.
— Calculating the toll (directly or by delegation to the toll service provider), including:
— possibly communicating to the user the result of the charging process,
— communicating in a secure way with actors having roles related to the issuing of the EFC
contract, payment means and OBE.
— Originating EFC context data, including:
— informing the driver of the vehicle about the EFC availability and the toll charging principles,
e.g. through signs and messages either directly or via the OBE.
— Communicating with passing vehicles, including, whenever applicable and according to the
technology chosen in the given toll domain:
— providing, if applicable, to autonomous systems geographical details of the charge objects in
the toll domain, as well as providing positioning information. This process is also known as
localisation augmentation.
— detecting a vehicle subject to a toll,
— collecting the characteristics of a vehicle enabling a correct classification of the vehicle used for
a toll calculation. The information collected can either be read from the OBE, measured (both
used for toll calculation or verification of data read from the OBE) or collected from a central
data base or vehicle register (off-line toll calculation),
— communicating in a secure way with the OBE, when present on-board, by exchanging information
needed for the toll charging,

UNE-EN ISO 17573-1:2019
— accepting the service rights stored in the OBE, i.e. the medium carrying the contractual data,
when the OBE is present on-board.
— collecting the information enabling the operator of the toll domain to identify the receiver of
a claim for a transport service provided, e.g. by licence plate recognition. The role enables toll
collection without an OBE installed in the vehicle.
— Operating enforcement, including:
— detecting, recording and handling exceptions (including fraud) whenever a vehicle passes
through a toll domain. Compliance check of autonomous systems is included in this responsibility.
— handling enforcement cases while protecting the privacy of the actors having taken the role
as driver,
— implementing and adhering to the security and privacy policies for the EFC domains.
6.7 EFC functional roles and responsibilities

Figure 3 summarises the EFC roles, adding their responsibilities and mutual interactions.
Figure 3 — EFC roles, their responsibilities and their interactions
The main aim of the architecture is to identify those services that lead to interactions that need to be
standardized, i.e.:
— interactions between different actors;
— interactions between distinct responsibilities, when actors undertaking those responsibilities may
be different (i.e. belonging to separate organizations).
A real tolling system that implements this architecture does not need to implement all roles and
responsibilities that are herein detailed and summarized in Figure 3. A real tolling system may
implement as many roles and responsibilities among those defined in this document as needed. The only
obligation is that those interactions among roles and information exchanges that are implemented shall

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

be compliant to those herein specified, in order to achieve interoperability among systems belonging to
different organizations, or implementations by different suppliers.
7 Services
7.1 Overview
The EFC service is performed by actors playing the four identified operational EFC roles (see Figure 4)
by means of a set of sub-services.
Figure 4 — Overall tolling service
In the course of a sub-service execution, each operational role may act as:
— A service provider, when the actor playing the role is providing the given service,
— A service recipient, when the actor playing the role is using the given service,
— A content provider, when the actor playing the role provides information,
— An information sink, when the actor playing the role receives information.
Detailed descriptions of all those sub-services that are performed internally within a role are outside
the scope of this document. However, for those services which imply interactions among different actors,
that is when separate organizations might be involved, a need for a standardized set of information
exchanges is present. These particular services are thus detailed in this clause.
Sub-services are grouped according to which roles are interacting. Groups and detailed descriptions of
the sub-services are specified in the following clauses.
Interaction diagrams that are shown in the following clauses focus on the information exchanges
between actors. Details of the execution of one actor’s internal activities are not shown, except for
clarification purposes, nor are they subject to standardization.
In each diagram, rounded corner boxes indicate the responsibilities or activities. Names in these
boxes can be slightly different from the names in Figure 3, to better explain the type of action that
is performed. Arrows in the diagrams show the direction of the information flows from information
exchange initiator to information recipient. Arrows are labelled with names that indicate the
information objects that are exchanged.
Decision gates are introduced in the diagrams to indicate when a particular behaviour may be subject
to a decision. In general, a decision gate only indicates that there is a number of different possible ways
to continue processing (for example, with different output data), or that the process might stop due

UNE-EN ISO 17573-1:2019
to a decision. Not all possibilities are shown, and this simplification is done in order to avoid over-
specification, as the activities performed by an actor are only shown to the level of detail needed for
understanding how information that is exchanged is generated.
While sub-services are in general independent of the tolling technology, there is a limited set of cases
where this is not true. Sub-services whose behaviour is dependent on the tolling technology are clearly
identified and described in separate clauses.
For each identified interaction existing technical standards, if any, are mentioned. Most of the mentioned
standards are accompanied by conformity assessment standards (e.g. ISO 13143 is the associated
conformity assessment suite of standards for ISO 12813), but which are not cited in this document.
7.2 Sub-services involving toll charger, toll service provider and interoperability
manager roles
Figure 5 shows the sub-services that involve toll charger, toll service provider and interoperability
manager.
Figure 5 — Sub-services involving toll charger, toll service provider and interoperability manager
7.2.1 Adding or deleting a new toll charger
Adding at least one toll charger to a community acting as interoperable EFC scheme is a precondition
to starting the overall operation. This sub-service is initiated by a candidate toll charger applying for
accreditation. If the certification is granted, it is forwarded to all known actors playing the toll service
provider role to start to negotiate bilateral agreements on common operations. This sub-service uses
the exchange Trust objects sub-service, which can be also used alone in other circumstances.
Figure 6 shows the related action diagram. The actor playing the toll service provider role fulfils the
basic provision responsibilities.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 6 — Adding/deleting a new toll charger to/from an interoperability region
Adding a new toll charger implies a new version of the tolling system overview to be generated and
exchanged. Also, the new toll charger will exchange Trust objects with the service providers that will
operate within its domain.
Deleting a previously certified toll charger will follow a similar logical sequence, the only difference
being that the service can be initiated by a request of either the toll charger or the interoperability
manager.
The following interactions are identified:
1. A certification of EFC constituent interaction, that allows toll chargers to be certified to operate.
2. A system overview interaction, which allows standardised tolling system characteristics to be
exchanged.
3. A Trust objects interaction, to exchange objects such as keys and certificates among actors in a
tolling system. Trust object exchanges are standardised in ISO 12855.
In terms of service interactions:
— The interoperability manager shall act as service provider when certifying a toll charger, and as
content provider when distributing the updated system overview to all other actors.
— The toll charger shall act as service recipient when certified by the interoperability manager, and
as content provider when exchanging Trust objects with the toll service provider.

UNE-EN ISO 17573-1:2019
— The toll service provider shall act as content provider when exchanging Trust objects with the toll
charger.
7.2.2 Adding or deleting a new toll service provider
Adding at least one provider to a community acting as interoperable EFC scheme is a precondition to
start overall operation. It is initiated by the candidate toll service provider applying for accreditation.
When the accreditation is granted it will be forwarded by the interoperability manager to all known
toll chargers to start to negotiate bilateral agreements on common operations.
Figure 7 shows the related action diagram. The actor playing the toll service provider role fulfils the
Basic Provision responsibilities.
Figure 7 — Adding/deleting a new service provider to/from an interoperability region
Accrediting a new toll service provider implies a new version of the tolling system overview to be
generated and exchanged. Also, the new toll service provider will exchange Trust objects with the toll
chargers for toll domains in which it intends to operate.
Deleting a previously accredited toll service provider will follow a similar logical sequence, the only
difference being that the service can be initiated by a request of either the toll service provider or the
interoperability manager.
1. A certification of EFC constituent interaction, that allows toll service providers to be certified to
operate.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)


exchanged.
3. A Trust objects interaction, to exchange objects such as, e.g. keys and certificates among actors in
a tolling system. Trust object exchanges are standardised in ISO 12855.
— The interoperability manager shall act as service provider when certifying a toll service provider,
and as content provider when distributing the updated system overview to all other actors.
— The toll charger shall act as content provider when exchanging Trust objects with the toll service
provider.
— The toll service provider shall act as service recipient when certified by the interoperability
manager, and as content provider when exchanging Trust objects with the toll charger.
7.2.3 Adding or modifying a toll regime
Adding at least one toll regime to a community acting as interoperable EFC scheme is a precondition
to start overall operation. It is initiated by the toll charger informing the interoperability manager
about the start of operation for a new EFC system under its responsibility. The same action is started
when a toll regime is modified. The interoperability manager includes the new regime into the list of
participating EFC schemes and informs all the actors providing toll service. If the new regime is added
according to the basic contractual agreements between the user and the contract holder, the actor
customising the OBE (when present) will include the new toll regime into the list of operational regimes
in the OBE of the user. The OBE is ready to operate according to the new EFC scheme if the context data
is provided.
Figure 8 shows the related action diagram.
Figure 8 — Adding or modifying a toll regime

UNE-EN ISO 17573-1:2019
Note that using context data and system overview by the toll service provider role implies further
information exchanges inside the toll service provider that may need to be standardised if the involved
responsibilities/activities are played by different actors. In particular, customisation of OBEs in
autonomous tolling system will be needed when a tolling regime changes.
Closing a previously included toll regime will follow the same logical sequence starting with the request
of the charging actor.
1. A toll scheme interaction that allows the actor playing the toll charger role to inform the change of
toll scheme.
exchanged.
3. A context data interaction, which allows context data to be communicated to an actor playing the
role of the toll service provider. Context data exchanges are standardised in ISO 12855.
4. A customisation info interaction, which allows context data information to be updated in the OBE,
when this is present. Customisation info interaction is standardised in ISO 17575-3.
— The interoperability manager shall act as content provider when distributing system overview
information.
— The toll charger shall act as content provider when communicating updated toll schema to the
interoperability manager, and when communicating updated context data to the toll service
provider.
— The toll service provider shall act as information sink for the defined information exchanges.
7.2.4 Defining rules
One responsibility of the manager is to define rules for the EFC community and to diffuse them to the
providers and chargers. Figure 9 shows the related action diagram.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 9 — Defining rules

1. An EFC rules interaction that allows the actor playing the interoperability manager role to inform
all other actors about the rules governing the EFC system.
— The interoperability manager shall act as content provider when distributing EFC rules.
— The toll charger shall act as information sink for the defined information exchange.
— The toll service provider shall act as information sink for the defined information exchange.
7.2.5 Monitoring operations
One responsibility of the manager is to monitor the EFC activities. Figure 10 shows the related action
diagram.

UNE-EN ISO 17573-1:2019
Figure 10 — Monitor operations

1. An operations report interaction, that allows the actors playing the toll service provider and toll
charger roles to inform the interoperability manager about the current operation status.
— The interoperability manager shall act as information sink for the defined information exchange.
— The toll charger shall act as content provider for the defined information exchange.
— The toll service provider shall act as content provider for the defined information exchange.
7.2.6 Handling disputes
One responsibility of the manager is to handle disputes between involved actors playing the roles of
toll charger and toll service provider. Disputes can be initiated by either the toll charger role or by the
toll service provider role when disagreements in the toll service operation cannot be solved. The result
of handling disputes can cause the permission to operate as toll charger or toll service provider be
revoked (see 7.2.1 and 7.2.2). Figure 11 shows the related action diagram.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 11 — Handling disputes
According to the result of the dispute, either the actor playing the toll charger role or the actor playing
the toll service provider role, or both, may have their accreditations revoked. Termination of a contract
shall be notified to the users that are contracted with the interested TSP(s). This can be done in various
ways, such as, e.g., using additional information in the user billing interaction (see 7.3.3).
1. A Complain interaction that allows the actors playing the toll service provider and toll charger
roles to request the interoperability manager to solve a dispute.
2. A Certification of EFC constituents revocation interaction, that allows the interoperability
manager to inform involved parties of a revocation of the permission to operate.
— The interoperability manager shall act as content provider for the Certification revocation
operation, and as a Service Provider for the Complain interaction.
— The toll charger shall act as a service user for the Complain interaction and as an information sink
for the Certification revocation interaction.
— The toll service provider shall act as a service user for the Complain interaction and as an
information sink for the Certification revocation interaction.
7.3 Sub-services involving the toll service provider and user

Figure 12 shows the sub-services involving the toll service provider and the user.

UNE-EN ISO 17573-1:2019
Figure 12 — Sub-services involving the toll service provider and user
7.3.1 Providing EFC contract
Providing an EFC contract requires that the toll service provider defines his conditions, offers its
service and reaches a potential user with this information. The user will contact the contracting agent
who will verify if the user fulfils the conditions. If the user does fulfil the conditions, a contract will
be established and signed. The contracting agent will initialise the issuing and customisation of a new
OBE, when an OBE is used for tolling. In the general case, the OBE will be subsequently loaded with
appropriate information before it is ready for operation. Figure 13 shows the related action diagram.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 13 — Providing EFC contract
Note that Figure 13 shows some actions that only occur when an OBE is used for the specific toll domain.
If no OBE is used (e.g. in ANPR tolling systems) those actions do not occur.
Note also that Figure 13 shows some actions that involve interactions and related information
exchanges inside the same role (toll service provider). These information exchanges may need to be
standardised if the involved responsibilities/activities are played by different actors.
Unsubscribing a previously signed service contract will follow the same logical sequence starting with
the definition of conditions.
1. A Contractual conditions interaction that allows transfer of the contractual information.
2. A Signed Contract interaction, that allows transfer of a signed contract.
3. A Customisation info interaction, that allows customisation of the OBE with contractual
information when an OBE is used in the specific toll domain. Customisation info exchanges are
standardised in ISO/TS 21719-1.
— The toll service provider shall act as content provider for the Contractual conditions, and as
information sink for the Signed contract and the OBE status. If the responsibilities of maintaining
the OBE and collecting usage data are performed by different actors, these will play the roles of
respectively service provider and service user for the Customisation info interaction.

UNE-EN ISO 17573-1:2019
— The user shall act as a content provider for the Signed contract and as information sink for the
Contractual information.
7.3.2 Providing customer care
Customer care interactions include all requests for help and information, as well as complaints, from
the user to the provider. Figure 14 shows the related action diagram.
Figure 14 — Provide customer care
Information transmitted by the Use to the Provision includes all types of requests and complaints,
including those that may cause the Provision to subsequently interact with other actors. Examples of
these latter events are, e.g. reports on stolen or lost OBEs, which may cause the Provision to inform
Chargers by means of exception lists that those OBEs are no longer valid.
1. A Help, info or complain interaction, that allows the user to request customer care.
2. A Customer care interaction, that allows the toll service provider to communicate the results of
the service.
— The toll service provider shall act as service provider for the Help, info and complain interaction,
as content provider for the Customer care info.
— The user shall act as a service user for the Help, info and complain interactions and as information
sink for the Customer care info.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

7.3.3 User billing
User billing is performed by means of a series of interactions between the toll service provider and the
user. Exceptions happening in performing user billing may cause contracts to be revoked, and related
information to be transmitted to toll chargers by using Handling Exceptions sub-services (see 7.4.7).
The exception list information will be used also by all the contract agents to detect users being known
as insolvent customers that try to sign new contracts. Figure 15 shows the related action diagram.
Figure 15 — User billing

1. A user bill interaction, to inform the user of a bill to be paid. This information may include also
notifications, e.g., termination of a contract (last bill).
2. A Financial object interaction, to inform the toll service provider about a payment.
3. An Exception list interaction, to possibly indicate users that are to be blacklisted due to e.g.
missing payments. Exception lists exchanges are standardised in ISO 12855.
— The user shall act as information sink for the user bill, and as a content provider for the Financial
objects.
— The toll service provider shall act as content provider for the Exception list and for the user bill,
and as information sink for the Financial objects.

UNE-EN ISO 17573-1:2019
7.4 Sub-services involving the toll charger and toll service provider
Figure 16 shows the sub-services involving the toll charger and the toll service provider.
Figure 16 — Sub-services involving the toll charger and the toll service provider
7.4.1 Collecting transit information in short-range communication systems
Collection of transit information in short-range communication (SRC)-based EFC systems is performed

by an actor performing the role of toll charger in various ways, which generally do not involve
interactions with the user. Figure 17 shows an activity diagram where interactions happen between
toll charger and toll service provider in an SRC-based system. Collection of transit information happens
in an SRC domain when an actor playing the role of toll charger recognises the presence of an OBE. In
order to cover the most general case, exchange of mutual identification information is shown in the
diagram, at the end of which the toll charger identifies the user, and the toll service provider recognises
the charging domain.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 17 — Collecting transit information (SRC systems)

1. A user identification interaction, to verify customer’s credentials by means of toll service
provider’s available information.
2. A Charging identification interaction, to verify toll charger’s credentials.
3. A Transit information interaction, to transfer transit related information.
4. A Charging information interaction, to notify the result of the charging transaction.
All above interactions are standardised in ISO 14906:2018.
— The toll charger shall act as service user for the user identification, Charging identification and
Transit information exchanges, and as content provider for the Charging information exchange.
— The toll service provider shall act as service provider for the user identification, Charging
identification and Transit information exchanges, and information sink for the Charging information
exchange.
7.4.2 Collecting charging information (autonomous systems)
In autonomous systems based tolling systems, collection of transit information is performed by the
toll service provider, which by means of the OBE recognises charge objects (locations, areas, road
segments), on the basis of available EFC context data, determines the transit information (in some cases
also the charging information), and communicates it to the toll charger in the form of toll declarations.
The set of activities to collect charging information in autonomous systems is performed almost entirely
within the toll service provider, and is detailed in Figure 18 solely for the sake of clarity.

UNE-EN ISO 17573-1:2019
Figure 18 — Collecting charging information (autonomous systems)
The granularity of toll declarations depends on specific agreements between the actors playing the toll
charger and toll service provider roles. The toll service provider may invalidate a user (for example, in
case of credit threshold overridden) subsequently to the processing of usage data, and consequently put
it in an exception list. Exchange and usage of exception lists is detailed in 7.4.5.
1. A toll declaration interaction, to notify charging information related to one or more transits. toll
declaration exchanges are standardised in ISO 12855.
2. A Usage data interaction, to notify the actor performing the function of providing toll operation of
the collected usage data. Usage data exchanges are standardised in ISO 17575-1.
— The toll service provider shall act as content provider for the toll declaration information. If
collecting usage data and providing toll declarations are performed by different actors, these actors
shall act as content provider and information sink, respectively, for the usage data interaction.
— The toll charger shall act as information sink.
7.4.3 Collecting transit information (not OBE-based systems)
Collection of transit information happens in such a tolling domain when an actor playing the role of
toll charger recognises the presence of a vehicle and is able to identify the user without any direct
interactions with either the user or the toll service provider.
Vehicle identification, together with transit information, is subsequently provided by the toll charger to
the toll service provider by means of the Providing payment information sub-service, detailed in 7.4.4.
7.4.4 Providing payment information
The Providing payment information sub-service is based on previous exchanges of billing details and
can be actualized in two ways:
1. on demand by the toll charger, which requires the toll service provider the payment of a number of
transits related to previously exchanged billing details;

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

2. spontaneously by the toll service provider, which only notifies the toll charger of an effected
payment, together with the indication of the billing details the payment is related to.
Figure 19 summarises the providing payment information action.
In case one of the partners complains that the other partner does not fulfil his obligations defined in the
certification, the Management can be involved to settle the dispute, as detailed in 7.2.6.
Figure 19 — Providing payment information

1. A Billing details interaction, which allows either the toll charger or the toll service provider to
notify transit information, possibly with associated charging information.
2. A Payment claim interaction, which allows toll chargers to request payments.
3. A Payment notification interaction, which allows the toll service provider to notify payments.
All above interactions are standardised in ISO 12855.
— The toll service provider shall act as content provider for Payment notifications, and information
sink or Content Provider for Billing details, according to the type of tolling system. The toll service
provider shall act as service provider for the Payment claim interaction.
— The toll charger shall act as information sink for Payment notifications, and information sink or
content provider for Billing details, according to the type of tolling system. The toll charger shall act
as service user for the Payment claim interaction.

UNE-EN ISO 17573-1:2019
7.4.5 Detecting Exceptions
Detecting Exceptions is an interaction which may be initiated when the user’s vehicle enters a charging
zone. Different actions can be performed by the charger in order to detect exceptions, which include
collecting own data (from, i.e. sensors) or interacting with the user OBE to get data, or both. In order to
cope with the general case, Figure 20 shows an action diagram where both actions are performed.
Figure 20 — Detecting Exceptions
The following interaction is identified:

1. An OBE interrogation interaction, that allows an actor playing the toll charger role to request
OBE’s operational parameters and status. OBE interrogation interactions are standardised in
ISO 12813.
— The toll charger shall act as service user.
— The toll service provider shall act as service provider.
7.4.6 Trust objects exchange
The Trust object exchange sub-service is symmetrical and not necessarily solicited, i.e.:
1. Both the toll charger and the toll service provider can provide or request Trust objects.
2. Trust objects may be provided by either the toll charger or the toll service provider without a
previous request.
Figure 21 summarises the Trust object exchange action.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 21 — Trust object exchange

1. A Trust object transaction interaction, which allows either the toll charger or the toll service
provider to request a Trust object to its counterpart.
2. A Trust object notification interaction, which allows the either the toll charger or the toll service
provider to deliver a Trust object to its counterpart.
— Either the toll service provider or the toll service provider shall act as service user for the
Trust object transaction interaction, depending on who is issuing the request for a Trust object.
Symmetrically, the counterpart shall act as a service provider.
— Either the toll charger or the toll service provider shall act as information sink for the Trust
object notification interaction, depending on who is delivering the Trust object. Symmetrically, the
counterpart shall act as content provider.
7.4.7 Handling exceptions
Exceptions can be detected (see 7.4.5) by either the toll charger when, e.g. an OBE transiting in the toll
charger’s domain is inspected or for ANPR systems when a vehicle’s license plate is not recognised as
valid, or by the toll service provider when, e.g. a user status is to be updated (user cancelled due to
missing payments, user put in a special list). The result of detecting an exception causes the interactions
depicted in Figure 22 to happen.

UNE-EN ISO 17573-1:2019
Figure 22 — Handling Exceptions

1. A Notify anomaly interaction that allows an actor playing the toll charger role to inform the toll
service provider of some detected anomalies, e.g. in an OBE’s operational parameters or status.
2. An Exception list interaction that allows the toll service provider to inform an actor playing the
role of toll charger about change of status for one user.
— The toll charger shall act as content provider for the Notify anomaly.
— The toll service provider shall act as content provider for the Exception list.
7.4.8 Providing local information
When detecting a user’s vehicle entering a charging zone, the toll charger may provide local information
if the vehicle has an OBE. A practical example of such information is localisation data, to be used to
improve location accuracy. Figure 23 shows an action diagram where such an action is performed.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Figure 23 — Providing local information
The following interaction is identified:

1. A Provide data to OBE interaction that allows an actor playing the toll charger role to inform the
OBE about local information. Localisation information interaction is standardised in ISO 13141.
— The toll charger shall act as service provider.
— The toll service provider shall act as service user.

UNE-EN ISO 17573-1:2019
Annex A
(informative)
Mapping EFC architecture to the C-ITS architecture
A.1 General
ISO 17427-1 defines the organisational architecture depicted in Figure A.1 which identifies abstract
roles which apply to all C-ITS systems.
Figure A.1 — High-level roles in the C-ITS organisational architecture (ISO 17427-1)
The scope of this document is related to the System operation role and the Functional operation role. The
two other major roles in a C-ITS organisational architecture defined in ISO 17427-1 are out of the scope
of this document.
A.2 System operation and Functional operation roles

A.2.1 System operation role
The System operation role is responsible for the proper execution of the application that provides the
end-to-end ITS service. In the case of EFC, it is the role that is responsible for the proper execution of
the applications providing the EFC service to the EFC service users. The responsibilities include the
reliability for the coordination, organisation and execution of the entire process. This may include the
provision of rules and guidelines for the EFC system, certification of EFC constituents, monitoring and
handling disputes.
A.2.2 Functional operation

The Functional operation role is split into two sub-roles in ISO 17427-1. The first sub-role is Generic
functional operation and the other sub-role is Specific functional operation. The sub-role Generic functional
role is further split into three sub-roles that covers the functionality defined in this document. The sub-
role Specific functional operation is split into 10 sub-roles that are outside the scope of this document.
Figure A.2 shows the C-ITS roles, being part of the generic C-ITS organisational architecture, that are
covered by this document.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

The role Content provider shall provide several types of content. This includes every type of data between
raw data and highly processed information. The main responsibilities of the Content provider are to
receive content requests, obtain content (data/information) and provide content (data/information).
Figure A.2 — C-ITS roles covered by this document
The role Service provider shall provide the C-ITS service to the Service recipient. The main responsibilities
of the Service provider are to receive service requests, select and operate the appropriate C-ITS service,
request and receive content for service execution and provide the service to the Service recipient.
The role Service recipient shall request and receive the C-ITS service. The main responsibilities of the
Service recipient are to subscribe to the service, request the service, receive the service and possibly
pay for the service.
From a role point of view the following mappings of the C-ITS and EFC roles apply:
— The C-ITS role System operation is in principal equal to the EFC role interoperability manager.
— The C-ITS role Generic Functional operation covers the EFC roles toll service provider, toll charger, and
user of the service.
— The responsibilities of the C-ITS role Content provider are shared between the EFC roles toll service
provider, toll charger, and user of the service. The three EFC roles are all responsible for the provision
of data/information that is needed for the provision of the EFC service.
— The responsibilities of the C-ITS role Service provider are shared between the EFC roles toll service
provider, toll charger, and user of the service. The three EFC roles are in a C-ITS environment all
responsible for providing C-ITS services.
— The responsibilities of the C-ITS role Service recipient are shared between the EFC roles toll service
provider, toll charger, and user of the service. The three EFC roles are in a C-ITS environment all
responsible for receiving C-ITS services.
It is important to note the difference between an ITS service and a C-ITS service. The EFC service is an
example on a service provided by an ITS application in intelligent transport systems. The C-ITS service
is a defined functionality to the system which requires a defined set of data as input, processes this
data and delivers a defined output (ISO 17427-1:2018).
Figure A.3 shows the mapping between the C-ITS roles defined in ISO 17427-1 and the roles identified in
this document.

UNE-EN ISO 17573-1:2019
Figure A.3 — Mapping of C-ITS and EFC roles
In Clause 7 EFC services are described by interactions between the EFC specific roles and by the roles’
generic functional operation sub-roles defined in ISO 17427-1 (service provider, service recipient, and
content provider). The additional functional operation sub-role of information sink, which is not present
in ISO 17427-1, has been defined in this document (see 7.1).

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Annex B
(informative)
Information schemata and basic information types
B.1 General
The ODP model (ISO/IEC 10746-2 to -4) defines an architecture made of concepts, definitions and rules
to combine them, which can be used as a framework to define any system.
The ODP standard defines five viewpoints that as a whole allow for a complete system specification.
Each viewpoint uses a specific language:
— Enterprise viewpoint. The enterprise model of a system views the roles of various agents (objects)
defined in the system, and the environment “around” the system. It describes the rules (policies)
that apply to the various roles, and the activities that are performed by the system. For the EFC
architecture, the enterprise model is fully exploited in this document.
— Information viewpoint. The information viewpoint deals with the information objects and their
schemata. In actuality, an information specification will see a system from the perspective of
information definition (which part is invariant, which part is exchanged among system components,
in which way and by which flows information is exchanged).
— Computational viewpoint. The computational viewpoint is the view of an application software
architect. Here, you will see a system as made of a set of interacting objects, which perform functions
by exchanging data at interfaces. Interaction details (the mechanisms, the coding techniques, the
system functions that are used to perform interactions) are not considered under this viewpoint, in
the same way as, e.g. disk access drivers are not seen by an application programmer.
— Engineering viewpoint. The engineering viewpoint is the system engineer perspective of a
system. Here, operating system details and supporting functions and protocols are considered, like
for example security, data transfer, physical distribution of applications or the like. This viewpoint
is the typical perspective of the deployment of a real system, and, as such, is the less probable model
to be viewed in a standard.
— Technology viewpoint. The technology viewpoint describes the physical objects in the system, in
terms of their characteristics. This includes, e.g. the standards that are used for the implementation
of the system.
While most of the body of this document deals with the Enterprise and the Computational viewpoint
description of the EFC architecture, and partly with a Technology viewpoint description, this Annex
gives a succinct Information viewpoint description.
B.2 Static schema

The following table synthesizes the information that is exchanged for the sole scope of tolling between
general roles as described in the action diagrams of Clause 7. Information exchanged is generally
indicated as classes of objects, which should be detailed in specific standards. Other information
exchanges, e.g. for compliance check or for enforcement, are not dealt with in this clause.
For each valid intersection, the classes of information that are exchanged between the two roles are
named. It has to be noted that the same class exchanged between different roles does not necessarily
represent an identical physical information exchange, e.g. the “administrative info” exchanged between
the user and the toll charger belongs to the same class of the “administrative info” exchanged between
the user and the toll service provider, although the actual data contents may be different (one more

UNE-EN ISO 17573-1:2019
detailed than the other one, for example). Information classes and their specializations are described
later in this document.
Table B.1 — Classes of information exchanges

Toll Service
User Toll charger Interoperability manager
Provider
invoices contract administrative
Toll service provider operational info
setup info
administrative info
User
contract agreement
Toll charger transit info operational info
Interoperability
regulations regulations regulations
Manager
The static schema synthesized by the previous table can be represented by the diagram in Figure B.1.
Figure B.1 — Static schema of information exchanges
The related information objects to be exchanged if actors are physically or organisationally separated
are identified in the following clauses.
B.3 Basic information objects

Among roles, information is exchanged in terms of classes of objects, which represent generalizations
and abstractions of the real information exchanges.
In terms of exchanged information objects, which are the only information objects within the scope of
this document, four basic classes are identified:
a) The EFC rules, as that class that contains permissions and obligations for the roles in the EFC
system, as well as terms of payment and user identification. This information class includes, but is
not limited to, the contractual data between the user and the toll service provider.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

b) Transit information, as that class that represents all information objects relevant for toll calculation.
c) Operational information, as that class that represents all information objects relevant for the
management of the EFC system.
d) Payment information, as that class that represents all information objects relevant for the transfer
of financial data.
B.4 EFC rules

The association among the different roles of the EFC system is expressed as the EFC rules, which
satisfies requirements and objectives as defined in the Enterprise specification. In the EFC rules, among
others, the rules for information transformations, including information exchanges, are expressed. An
EFC rules object, thus, does not only specify which is the relevant information in an EFC system, but
also the rules for manipulating it, in terms of who can do what to which information object. As different
types of rules may be envisaged, the association attribute is in fact a class, representing all possible
sets. Figure B.2 depicts this association concept, which is actually one type of correspondence between
Enterprise and Information specifications.
Figure B.2 — EFC rules as the association attribute among enterprise roles
The EFC rules specify also the Invariant schema in the EFC system, i.e. that information that does not
change during system operation. System operation means the period of time during which a given user,
with a given contract, is allowed to use a given EFC system. A number of different invariant schemata
may be considered for the same real system, if different sets of rules are available between users and
toll service providers.
Objects in the EFC rules class are listed in Table B.2.

UNE-EN ISO 17573-1:2019
Table B.2 — Information objects in the EFC rules class

Object Description Originating Recipient
role(s)/actor(s) role(s)/actor(s)
Interoperability Toll charger, Basic
Certification Permission to operate
Manager Provision
Contract with the user including all pa-
Basic Provision, Cus-
Contract rameters relevant for tolling, and the way Contract agent
tomising the OBE
they are handled
Contractual condi- Rules for the contract agent and user Basic Provision,
Contract agent, user
tions operation Contract agent
Rules governing the EFC system, e.g.,
Interoperability Toll charger, Basic
operational rules identifiers, service level Agreements,
Manager Provision
security rules
Usage admission, vehicle and contract Basic Provision, Cus- Customising the OBE,
Customisation
fixed parameters for a specific OBE tomising the OBE user
Basic Provision, toll Toll charger, Basic
Trust objects Certificates, signatures
charger Provision
B.4.1 Transit information

Objects in the Transit information class are listed in Table B.3.
Table B.3 — Information objects in the transit information class

Charging
SRC based transaction detail Toll charger Toll service provider
identification
Charging
identification &
SRC based transaction detail Toll charger Toll service provider
transfer charging
information
OBE interrogation OBE attribute list for compliance check Toll service provider Toll charger
Transit information SRC based transaction detail Toll charger Toll service provider
User identification SRC based transaction detail Toll charger Toll service provider
B.4.2 Operational information

Objects in the operational information class are listed in Table B.4.
Table B.4 — Information objects in the operational information class

To indicate that some contracts are no Contract agent, toll
Exception lists Basic Provision
more supported charger
Toll charger, Basic Interoperability
Complain Complain
Provision Manager
Providing EFC
Context data Raw EFC context Toll charger
context data
Providing EFC con-
Context data Refined EFC context User
text data
Interoperability
EFC Scheme New or amended EFC scheme Toll charger
Manager

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Table B.4 (continued)

General request by the user asking for
Providing customer
Help, info, complain clarification or action by the provision User
care
actor
Software status of the OBE to check if
OBE status User Maintaining the OBE
updates are requested.
Toll charger, Basic Interoperability
operational report Report on operations
Provision Manager
Customisation info, including updated Personalizing the OBE,
Customisation User
software Maintaining the OBE
Certified service providers, EFC Interoperability Toll charger, Basic
System overview
schemata, toll chargers Manager Provision
B.4.3 Payment information

Objects in the Payment information class are listed in Table B.5.
Table B.5 — Information objects in the payment information class

Refined charge report of the OBE up to
Providing toll
Billing details the level of details requested in the user Toll charger
declaration
bill including the payment claim
Providing toll
Charge data OBE charge report Basic provision
declaration
Amount of money the OBE is allowed to Providing toll
Limited autonomy Basic Provision
use autonomously. declaration
objects exchanged to manage a selling -
Toll charger, Basic Toll charger, Basic
Financial objects buying process or in case the fee is a tax,
Provision, Use Provision
managing the tax payment of the user
Payment means Confirmation or rejection of the validity Providing toll
Basic Provision
validity of the payment means of the customer declaration
Invoice for a period of service usage as
User bill Basic Provision User
agreed in the service contract
B.5 Dynamic schema

The information objects identified previously as not invariant (i.e. not listed in Table B.2) may vary in
time according to the operations that are performed. A dynamic schema for the identified information
objects has two aspects. Firstly, the effect that invoking operations have on the object and secondly, the
conditions under which these operations can be invoked. Table B.6 synthesizes informally the dynamic
schema for EFC. More refined and formal descriptions are left to specific standards on information
exchanges.
Table B.6 — Dynamic schema

Information object Modification Modifier Condition(s)
Billing details Create Providing toll declaration
Exception lists Create Basic Provision
Toll charger, Collecting
Charge data Create
usage data

UNE-EN ISO 17573-1:2019
Table B.6 (continued)

Information object Modification Modifier Condition(s)
Toll charger, Basic
Complain Create
Provision, Use
Context data Create Toll charger
Context data Re-format Providing EFC context data
charge data received and payment
Limited autonomy Write Providing toll declaration
means validated
EFC Scheme Create Toll charger
Toll charger, Basic
Financial objects Create
Provision, user
Help, info Create User
OBE status Create User new customisation received
operational report Create Toll charger, Basic Provision
Payment means validity Create Basic Provision billing details processed
Personalizing the OBE, variations in contractual or OBE
Customisation Write
Maintaining the OBE parameters
System overview Write Interoperability manager new toll regime created
User bill Create Basic Provision

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

Annex C
(informative)
Enterprise objects within roles
C.1 General
Each role in the functional operation can be described by enterprise objects on the following three levels:
a) Organisational level, where different enterprise objects describe the assigned responsibilities.
b) Equipment level, where enterprise objects identify the artefacts, e.g. the OBE, used by actors to
perform their roles.
c) Transport service level, where objects describe the type of services that are offered within the
domain.
The above roles interact with each other and with roles that manage the EFC domain. Responsibilities
in this latter role include managing the interoperability among different EFC domains and acting like an
advisory board, in the sense of not covering any commercial responsibility or risk.
The following clauses describe the enterprise objects specific to each functional role.
C.2 Toll service provider

C.2.1 General
The toll service provider domain includes enterprise objects that are summarised in Figure C.1.
NOTE Vehicles do not belong to the toll service provider domain.
Figure C.1 — Toll service provider domain

UNE-EN ISO 17573-1:2019
C.2.2 Organisational level

The toll service provider is the legal entity that provides the customers (users) with toll services in
one or more toll domains, for one or more classes of vehicles. A toll service is a service enabling users
having only one contract and one OBE to use a vehicle in one or more toll domains.
The toll service provider may purchase services from other legal persons or organisations operating on
its behalf. These organisations are often given names that reflect the responsibilities they have taken,
e.g. OBE provider and contract provider or issuer. Any distinction between a toll service provider and
entities acting on its behalf is outside of the scope of this document.
A toll service provider may as well act as the toll charger for one or more toll domains.
The toll service provider controls the OBE and is responsible for its operation (functioning).
NOTE 1 The OBE does not need to include payment means.
NOTE 2 The toll service provider can provide the OBE itself or it can provide only a magnetic card or a smart
card to be used with OBE provided by a third party, i.e. a mobile telephone and a SIM card can be obtained from
different parties.
C.2.3 Equipment level

The OBE used by a toll service provider for providing toll services is called Central Equipment (CE). The
CE may be split into different types of equipment depending on the allocation of roles within the toll
service provider organisational level (see Figure C.2).
The OBE is initialised and eventually maintained by the toll service provider.
The OBE may be connected to one or more external sensors, e.g. a GNSS sensor (e.g. in devices used for
navigation, fleet management), a tachograph, an odometer, a trailer sensor, suspension sensors, axle in
use sensors and vehicle related information stored in a SAM.
Figure C.2 — OBE and external sensors

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

C.2.4 Transport service level

The OBE may be linked to a specific vehicle (with its specific vehicle attributes) that is used at the
Transport service level. The vehicle may be used in one or several toll domains covered by the EFC
contract.
C.3 User of the toll service

C.3.1 General
The enterprise objects in the user domain are summarised in Figure C.3.
Figure C.3 — User domain

The “customer” is the customer of the toll service provider.
The one(s) liable for toll are the one(s) that are liable for paying the toll according to the local toll regime.
EXAMPLE The driver, the owner of the vehicle or the hauler can be separately or jointly liable for the toll.
Selection of the one liable for paying the toll for a vehicle is a local matter. It should facilitate enforcement
but is outside the scope of this document.
The customer may but does not have to be liable for paying the toll according to a toll regime.
The driver is the one who drives the vehicle for which the toll is levied.
The driver is assumed to operate (use/serve) the OBE (e.g. the setting parameters such as the number
of axles).

UNE-EN ISO 17573-1:2019

The off-board equipment used by a customer in relation to its toll duties is called its central equipment,
e.g. the central equipment of a fleet manager having several EFC contracts. The OBE is part of the
Service provision responsibilities.

A vehicle is controlled by its driver and is therefore part of the driver's domain.
C.4 Charger of the toll

C.4.1 General
The enterprise objects in the toll charger domain are summarised in Figure C.4.
Figure C.4 — Toll charger domain

The toll charger is the legal entity responsible for the collection of tolls in one or more toll domains, e.g.
areas or (parts of) a road network where a toll is collected according to some toll regime.
The toll charger may purchase services from other legal persons or organisations operating on its
behalf. These organisations are often given names that reflect the responsibilities they have taken, e.g.
EFC operator and enforcement operator.
A toll charger is said to control the toll domain and for each toll domain there is only one toll charger
that controls it.
NOTE 1 Which legal entity will act as the toll charger in an actual situation is outside the scope of this
document. It can be, e.g. a government or it can be delegated to a concessionaire (e.g. a toll operator). This
document only assumes that for each toll domain one legal entity exists that acts as its toll charger.

UNE-EN ISO 17573-1:2019
ISO 17573-1:2019(E)

NOTE 2 Any distinction between a toll charger and entities acting on their behalf is outside the scope of this
document, e.g. enforcement operators, who act on behalf of a toll charger are therefore not distinguished (but
can be distinguished in standards addressing more detailed issues).

The OBE and possible other provisions used by a toll charger for the collection of toll for vehicles is
called the toll system of this toll charger.
NOTE 1 The OBE is excluded from the definition.
Off-board should be read relative to the vehicle that is subjected to toll. However, it can include mobile
equipment, e.g. mobile enforcement equipment.
NOTE 2 The actual payment (collection of the toll) can take place outside the toll system.
Depending on the location of the equipment a toll system can be decomposed into:
— Roadside equipment, including mobile equipment and equipment above the road or in its surface.
— Central equipment as used in his offices.
The toll system may use data from other external sensors or systems for the calculation of the toll, e.g.
pollution level sensors and traffic speed and volume sensors.

A toll domain is an area or a part of a road network where a toll regime is applied and one or more
transport services may be offered. The toll regime consists of a set of rules, including enforcement
rules, governing the collection of toll in the toll domain.
NOTE Depending on the toll regime a toll domain can include private roads and off-road premises or terrain.
A toll domain may consist of one or more tolled objects (providing the transport service), being
distinguished parts of a toll domain for which one or more tariff schema applies.
EXAMPLE 1 A tolled object can be e.g. an area, all public roads within an area, a bridge, a zone, or a stretch of a
road (network).
EXAMPLE 2 For one tolled object both a national and a local tariff scheme can apply.

UNE-EN ISO 17573-1:2019
Bibliography
[1] ISO 12855, Electronic fee collection — Information exchange between service provision and toll
charging
[2] ISO 13141, Electronic fee collection — Localisation augmentation communication for
autonomous systems
[3] ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
[4] ISO 192993), Electronic fee collection — Security framework
[5] ISO/TS 21193, Electronic fee collection — Requirements for EFC application interfaces on
common media
[6] ISO 21217, Intelligent transport systems — Communications access for land mobiles (CALM) —
Architecture
[7] ISO/TS 21719-1, Electronic fee collection — Personalization of on-board equipment (OBE) — Part 1:
Framework
[8] ISO 24014-1, Public transport — Interoperable fare management system — Part 1: Architecture
[9] ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems —
Part 3: Context data
[10] ISO 12813, Electronic fee collection — Compliance check communication
[11] ISO 13143, Electronic fee collection — Evaluation of on-board and roadside equipment for
conformity to ISO 12813
[12] ISO 13140, Electronic fee collection — Evaluation of on-board and roadside equipment for
conformity to ISO 13141
[13] ISO/IEC 10746-4, Information technology — Open Distributed Processing — Reference Model:
Architectural semantics — Part 4
[14] ISO 17427-1, Intelligent transport systems — Cooperative ITS — Part 1: Roles and responsibilities in
the context of co-operative ITS architecture(s)
3) The current TS is under revision to become an International Standard which is currently at stage: 30.99.

UNE-EN ISO 17573-1:2019
UNE-EN ISO 17573-1:2019
ICS 03.220.20; 35.240.60

Price based on 48 pages
© ISO 2019 – All rights reserved

Une-En Iso 17573-12019

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Une-En Iso 17573-12019

Uploaded by

Copyright:

Available Formats

Copyrighted material licensed to IDOM.

No further reproduction or distribution permitted.

This document is the copyright of the Publisher. All rights reserved.

In USA and Canada Contact

M9W 7K6, Canada

+1 416 401 8730. Email: i2iSupport-US@saiglobal.com

+44 203 327 3140. Email: i2iSupport-EMEA@saiglobal.com

+61 131 242. Email: i2iSupport-APAC@saiglobal.com

Peaje electrónico. Arquitectura del sistema para peaje

En cumplimiento del punto 11.2.5.4 de las Reglas Internas de CEN/CENELEC Parte 2, se ha

Este documento está disponible en los idiomas oficiales de CEN/CENELEC/ETSI.

La correspondiente versión oficial de este documento se encuentra disponible en la Asociación Española de

Las observaciones a este documento han de dirigirse a:

Asociación Española de Normalización

EUROPEAN STANDARD EN ISO 17573-1

ICS 03.220.20; 35.240.60

Electronic fee collection - System architecture for vehicle-

This European Standard was approved by CEN on 7 July 2019.

EUROPEAN COMMITTEE FOR STANDARDIZATION

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels

© ISO 2019 – All rights reserved ﻿ iii

7.4.4 Providing payment information....................................................................................................................... 28

iv ﻿ © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved ﻿ v

vi ﻿ © ISO 2019 – All rights reserved

1) Under development. Current stage: 30.99

© ISO 2019 – All rights reserved ﻿ vii

Electronic fee collection — System architecture for vehicle-

© ISO 2019 – All rights reserved ﻿ 1

ISO/IEC 10746-2, Information technology — Open distributed processing — Reference model:

3 Terms and definitions

2 ﻿ © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved ﻿ 3

4 Symbols and abbreviated terms

Rounded corner boxes indicate responsibilities and related activities

Arrows crossing borders between roles indicate information exchanges

Vertical arrows within activities represent execution steps

Solid circles represent start of activities

Partially coloured circles represent end of activities

Solid horizontal bars represent decision gates

4.2 Abbreviated terms

ANPR Automatic Number Plate Recognition

C-ITS Cooperative ITS

DSRC Dedicated Short-Range Communication

EETS European Electronic Toll Service

EFC Electronic Fee Collection

GNSS Global Navigation Satellite Systems

4 ﻿ © ISO 2019 – All rights reserved

IFMSA Interoperable Fare Management System Architecture

ITS Intelligent Transport Systems

OBE On-board Equipment

ODP Open Distributed Processing

RFID Radio Frequency Identification

RSE Roadside Equipment

SAM Secure Application Module

SLA Service Level Agreement

SRC Short Range Communication

TSP toll service provider

5 The EFC community: roles and objectives

© ISO 2019 – All rights reserved ﻿ 5

Figure 1 — Enterprise objects in the EFC community

5.2 Other ITS systems and services

5.3 Sensors, vehicle system and common equipment

© ISO 2019 – All rights reserved iii

iv © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved v

vi © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved vii

© ISO 2019 – All rights reserved 1

2 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 3

4 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 5

6 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 7

8 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 9

10 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 11

12 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 13

14 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 15

16 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 17

18 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 19

20 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 21

22 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 23

24 © ISO 2019 – All rights reserved

© ISO 2019 – All rights reserved 25