Electronic fee collection - System architecture for vehicle-related tolling - Part 1: Reference model (ISO/DIS 17573-1:2025)

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

Elektronische Gebührenerhebung - Systemarchitektur für fahrzeugbezogene Maut - Teil 1: Referenzmodell (ISO/DIS 17573-1:2025)

Perception de 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/DIS 17573-1:2025)

Le présent document définit l'architecture d'environnements de systèmes de péage dans lesquels un client disposant d'un contrat peut utiliser un véhicule dans une grande variété de domaines de péage et avec un exploitant de péage différent pour chaque domaine.
Les systèmes de péages conformes au présent document peuvent servir à différents usages comprenant le péage routier (réseau), le péage par domaines, la perception des redevances pour l'emprunt de ponts, de tunnels, de bacs, pour l'accès ou pour le stationnement. D'un point de vue technique, les systèmes de péage utilisent un équipement électronique à bord d'un véhicule.
D'un point de vue processus, la description de l'architecture se concentre sur la détermination du péage, sur la facturation du péage et sur les mesures de contrôle-sanction associées. La perception effective du péage, c'est-à-dire la perception des paiements, ne fait pas partie du domaine d'application du présent document.
Dans le présent document, l'architecture est définie sans plus de détails que ce qui est nécessaire pour une vue d'ensemble générale, un langage commun, une identification du besoin d'autres normes et des interactions entre ces normes et l'élaboration de ces normes.
L'ensemble du présent document donne:
— Le point de vue d'entreprise de l'architecture concernée par l'objet, la portée et les politiques régissant les activités du système spécifié au sein de l'organisation dont il fait partie;
— Les termes et les définitions pour un usage commun dans un environnement de péage;
— Une décomposition de l'environnement des systèmes de péage selon ses principaux objets d'entreprise;
— Les rôles et responsabilités des principaux acteurs;
— L'identification des services offerts au moyen de diagrammes d'action qui soulignent les échanges normalisés nécessaires.
— L'identification des interfaces d'interopérabilité pour les systèmes de télépéage à spécifier dans des normes spécialisées.

Elektronsko pobiranje pristojbin - Sistemska arhitektura za cestninjenje vozil - 1. del: Referenčni model (ISO/DIS 17573-1:2025)

General Information

Status
Not Published
Publication Date
01-Aug-2027
Current Stage
4020 - Submission to enquiry - Enquiry
Start Date
25-Dec-2025
Completion Date
25-Dec-2025

Relations

Effective Date
26-Mar-2025
Draft

prEN ISO 17573-1:2026 - BARVE

English language
58 pages
Preview
Preview
e-Library read for
1 day

Get Certified

Connect with accredited certification bodies for this standard

BSI Group

BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.

UKAS United Kingdom Verified

Great Wall Tianjin Quality Assurance Center

Established 1993, first batch to receive national accreditation with IAF recognition.

CNAS China Verified

Hong Kong Quality Assurance Agency (HKQAA)

Hong Kong's leading certification body.

HKAS Hong Kong Verified

Sponsored listings

Frequently Asked Questions

prEN ISO 17573-1 is a draft published by the European Committee for Standardization (CEN). Its full title is "Electronic fee collection - System architecture for vehicle-related tolling - Part 1: Reference model (ISO/DIS 17573-1:2025)". This standard covers: 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).

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

prEN ISO 17573-1 is classified under the following ICS (International Classification for Standards) categories: 03.220.20 - Road transport; 35.240.60 - IT applications in transport. The ICS classification helps identify the subject area and facilitates finding related standards.

prEN ISO 17573-1 has the following relationships with other standards: It is inter standard links to EN ISO 17573-1:2019. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

prEN ISO 17573-1 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.

Standards Content (Sample)


SLOVENSKI STANDARD
01-marec-2026
Elektronsko pobiranje pristojbin - Sistemska arhitektura za cestninjenje vozil - 1.
del: Referenčni model (ISO/DIS 17573-1:2025)
Electronic fee collection - System architecture for vehicle-related tolling - Part 1:
Reference model (ISO/DIS 17573-1:2025)
Elektronische Gebührenerhebung - Systemarchitektur für fahrzeugbezogene Maut - Teil
1: Referenzmodell (ISO/DIS 17573-1:2025)
Perception de 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/DIS 17573-1:2025)
Ta slovenski standard je istoveten z: prEN ISO 17573-1
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
International
Standard
ISO/DIS 17573-1
ISO/TC 204
Electronic fee collection — System
Secretariat: ANSI
architecture for vehicle-related
Voting begins on:
tolling —
2026-01-01
Part 1:
Voting terminates on:
2026-03-26
Reference model
Perception de télépéage — Architecture de systèmes pour le
péage lié aux véhicules —
Partie 1: Modèle de référence
ICS: 03.220.20; 35.240.60
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO/DIS 17573-1:2026(en)
DRAFT
ISO/DIS 17573-1:2026(en)
International
Standard
ISO/DIS 17573-1
ISO/TC 204
Electronic fee collection — System
Secretariat: ANSI
architecture for vehicle-related
Voting begins on:
tolling —
Part 1:
Voting terminates on:
Reference model
Perception de télépéage — Architecture de systèmes pour le
péage lié aux véhicules —
Partie 1: Modèle de référence
ICS: 03.220.20; 35.240.60
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2026
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: +41 22 749 01 11
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ISO/DIS 17573-1:2025(en)
ii
ISO/DIS 17573-1:2025(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms. 2
4.1 Symbols .2
4.2 Abbreviated terms .3
5 The EFC community: roles . 4
5.1 General .4
5.2 Other ITS systems and services .5
5.3 Sensors, vehicle system and common equipment .5
5.4 Infrastructure sourced data.5
5.5 Financial/Commercial systems .6
5.6 Telecommunication systems .6
5.7 Jurisdiction/Authorities .6
5.8 Standardization bodies .6
5.9 Common service rights provider . .7
6 Roles internal to the EFC domain . 7
6.1 General .7
6.2 EFC domain roles .7
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 General .14
7.2.2 Adding or deleting a new toll charger .14
7.2.3 Adding or deleting a new toll service provider .16
7.2.4 Adding or modifying a toll regime . .17
7.2.5 Defining rules .18
7.2.6 Monitoring operations .19
7.2.7 Handling disputes . 20
7.3 Sub-services involving the toll service provider and user . 22
7.3.1 General . 22
7.3.2 Providing EFC contract . 22
7.3.3 Providing customer care .24
7.3.4 User billing . 26
7.4 Sub-services involving the toll charger and toll service provider .27
7.4.1 General .27

iii
ISO/DIS 17573-1:2025(en)
7.4.2 Collecting transit information in short-range communication systems .27
7.4.3 Collecting charging information (autonomous systems) . 29
7.4.4 Collecting transit information (image-based systems) . 30
7.4.5 Providing payment information . 30
7.4.6 Detecting Exceptions .32
7.4.7 Trust objects exchange . 33
7.4.8 Handling exceptions . 34
7.4.9 Providing local information . 35
Annex A (informative) Mapping EFC architecture to the C-ITS architecture .36
Annex B (informative) Information schemata and basic information types .39
Annex C (informative) Enterprise objects within roles .45
Bibliography .50

iv
ISO/DIS 17573-1:2025(en)
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. 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 can be the subject of
patent rights. ISO is not 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 (ITS).
[1] [2]
This second edition of EN ISO 17573-1 cancels and replaces the first edition (EN ISO 17573-1:2019 ),
which has been technically revised.
The main changes are as follows:
— Clause 3 has been updated and ISO/FDIS 17573-2 has been made the primary source for terms and
definitions;
— extension of the reference model (i.e. inclusion of image-based tolling schemes);
— visual unification of the action and schematic diagrams;
— corrections of the enterprise objects descriptions in the Annex C.
[3]
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.

v
ISO/DIS 17573-1:2025(en)
Introduction
The widespread use of tolling also demands 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 can be equipped with an 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 2019/520).
In addition to specialized 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.
Although there are many differences, collecting a toll for vehicles can, to some extent, be compared with
collecting a fare for public transport. Architectural harmonization of the collection of fee and fare may be
[4]
desirable from a policy and from a user point of view. In the past, ISO 24014-1 prepared by ISO TC 204
[5]
used ISO 17573:2010 as a starting point. This document has benefited from that and has also taken EN
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), 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.
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
[6]
(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
[5]
viewpoint, by refining and extending what had been already done in ISO 17573:2010 . Correspondences

vi
ISO/DIS 17573-1:2025(en)
[7]
between concepts and terms in this document and those in EN ISO 17427-1 are shown in Annex A. In
addition, this document gives in Annex B the foundations of the information viewpoint by identifying
[5]
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
[8] [9]
and prEN ISO 17574 .
This document is Part 1 of a multipart standard that is made up of the following parts:
[1]
— EN ISO 17573-1 , Electronic fee collection — System architecture for vehicle related tolling — Part 1:
Reference model (this document)
[10]
— ISO/FDIS 17573-2 , Electronic fee collection — System architecture for vehicle related tolling — Part 2:
Vocabulary
[11]
— EN ISO 17573-3 , Electronic fee collection — System architecture for vehicle related tolling — Part 3:
Data dictionary
vii
DRAFT International Standard ISO/DIS 17573-1:2025(en)
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 can use a vehicle in a variety of toll domains with a different toll charger (TC)
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 can identify vehicles subject to tolling by means of electronic OBE
in a vehicle or by other means that are image-based (e.g. automatic number plate recognition, ANPR).
From a process point of view the architectural description focuses on toll determination, toll charging,
provision of toll service to the user, 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 specific to this standard, in addition to those provided in ISO/FDIS 17573-2;
— 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 can 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
standardized exchanges;
— identification of the interoperability interfaces for EFC systems, in specialized standards.
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/FDIS 17573-2, Electronic fee collection — System architecture for vehicle related tolling — Part 2:
Vocabulary
ISO/DIS 17573-1:2025(en)
EN ISO 12855, Electronic fee collection - Information exchange between service provision and toll charging
(ISO 12855:2022)
EN ISO 17427-1, Intelligent transport systems - Cooperative ITS - Part 1: Roles and responsibilities in the context
of co-operative ITS architecture(s) (ISO 17427-1:2018)
EN ISO 17573-1:2019, Electronic fee collection - System architecture for vehicle-related tolling - Part 1: Reference
model (ISO 17573-1:2019)
EN ISO 24014-1, Public transport - Interoperable fare management system - Part 1: Architecture
(ISO 24014-1:2015)
3 Terms and definitions
For the purpose of this document, the terms and definitions given in ISO/FDIS 17573-2 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
artefacts
physical objects of material or physical piece of information or a system or subsystem that are used in an
ITS system
3.2
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
4 Symbols and abbreviated terms
4.1 Symbols
In action diagrams, the following graphical conventions apply:
Rounded corner box indicates responsibilities and related activities within
roles
Arrow crossing borders between roles indicates information exchanges
between roles
ISO/DIS 17573-1:2025(en)
Vertical arrow within activities represents execution steps
Partially coloured circle represents end of activities
Solid coloured circle represents start of activities
Solid horizontal rhombus represents decision gate
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
EEA European economic area
EETS European electronic toll service
EFC electronic fee collection
ISO/DIS 17573-1:2025(en)
GNSS global navigation satellite systems
IFMSA interoperable fare management system architecture
ITS intelligent transport systems
LPN licence plate number
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
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
[12]
ISO/IEC 15414 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.
ISO/DIS 17573-1:2025(en)
Figure 1 — Enterprise objects of 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.
[13]
NOTE The information exchange between EFC and Traffic management is standardized in ISO/TS 21192 .
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.
EXAMPLE 1 Examples of such sensors and data stores are global navigation satellite systems (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).
EXAMPLE 2 The data stores could be either in the vehicle or elsewhere, e.g. a computer installed within the EFC domain.
NOTE Shipped goods can 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.
ISO/DIS 17573-1:2025(en)
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’).
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 artefacts.
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.
EXAMPLE 1 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.
— Vehicle registration authorities may register, manage and exchange registration information related to
vehicles.
EXAMPLE 2 European Car Registration and Driving licence Information System (EUCARIS) is an initiative
established in 1994 to facilitate vehicle and driving licences information sharing.
— 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 Standardization bodies
The responsibilities of the standardization 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 standardization bodies, e.g. by
toll charging operators taking part in the preparation of EFC standards.

ISO/DIS 17573-1:2025(en)
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. Its role, responsibilities, and
requirements on EFC systems, as well as its interactions with the roles internal to the EFC domain are
[14]
standardized in ISO/TS 21193 .
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.

ISO/DIS 17573-1:2025(en)
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 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 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 based on regulations. Given its general nature, this role will not be specified
further in this document.
ISO/DIS 17573-1:2025(en)
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 organizations 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
6.4.1 Short description
The TSP 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 TC role, and the user role.
6.4.2 Responsibilities
Responsibilities of the TSP role include:
— Providing basic provisions, including:
— providing the OBE, when tolling is performed by means of electronic OBE,
— providing the toll service to the user without OBE, if tolling mechanism does not require it,
— guaranteeing the payment of the toll to the entity performing the TC 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,
— monitoring the actual operational quality relative to service level agreements (SLAs).
— Acting as a contract agent, including:
— offering contractual relations according to defined conditions to interested users and concluding
contractual agreements,
ISO/DIS 17573-1:2025(en)
— 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,
— collection of information needed for toll charging from other sources than OBE,
— 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.
— Maintaining the licence plate number (LPN) relevant data and other required vehicle information.
6.5 User of the service
6.5.1 Short description
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 TSP role.
6.5.2 Responsibilities
Responsibilities of the user role include:
— Being liable for the toll including:
— using the OBE, when tolling is performed by means of OBE, 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,
— providing the LPN information, when tolling is performed without an OBE,
— behaving according to the r
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...