ISO/FDIS 17573-1

ISO/DISFDIS 17573-1
ISO/TC 204
Secretariat: ANSI
Date: 2026-07-1709-29
Electronic fee collection — System architecture for vehicle-related
tolling —
Part 1:
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
TTTTTTTTTThhhhhhhhhhiiiiiiiiiissssssssss dr dr dr dr dr dr dr dr dr draaaaaaaaaafffffffffftttttttttt i i i i i i i i i issssssssss     susususususususususubbbbbbbbbbmmmmmmmmmmiiiiiiiiiitttttttttttttttttttteeeeeeeeeed d d d d d d d d d ttttttttttoooooooooo     aaaaaaaaaa     ppppppppppaaaaaaaaaarrrrrrrrrraaaaaaaaaallellellellellellellellellellel l l l l l l l l l vvvvvvvvvvooooooooootttttttttteeeeeeeeee i i i i i i i i i innnnnnnnnn     IIIIIIIIIISSSSSSSSSSOOOOOOOOOO,,,,,,,,,,     CCCCCCCCCCEEEEEEEEEEN.N.N.N.N.N.N.N.N.N.
VVVVVVoooooottttttiiiiiinnnnnng bg bg bg bg bg beeeeeegigigigigiginsnsnsnsnsns o o o o o on:n:n:n:n:n: 2 2 2 2 2 2020202020202666666------000000111111------010101010101
VoVoVoVoVoVottttttinininininingggggg  te teteteteterrrrrrminminminminminminaaaaaatetetetetetessssss o o o o oonnnnnn:::::: 2 2 2 2 22000000222222666666------000000333333------222222666666

DISFDIS stage
ISO/DISFDIS 17573-1:2026(en)
© ISO 2026
All rights reserved. Unless otherwise specified,
This ISO publication is protected by copyright and is owned by ISO and/or its licensors.
The content of this ISO publication is provided under licence, not sold. Use is subject to the applicable licence terms issued
by ISO, an ISO member body, or an authorized third-party distributor.
Except as required in the context of its for implementation or expressly permitted by a separate licence, no part of this
ISO publication may be reproduced or utilized otherwise, distributed, modified, used, or made available in any form or
by any means, – electronic or mechanical, including photocopying, scanning, recording, or posting on internal or external
digital platforms.
Any use beyond the internet or an intranet, without prior written permission. Permission can be requested from either
ISO at the address below or ISO’s member body in the countryscope of the requestergranted rights is prohibited and may
result in legal action.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
E-mailEmail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
iii
ISO/DISFDIS 17573-1:2026(en)
Contents
Foreword . iv
Introduction . iv
Scope . iv
Normative references . iv
Terms and definitions . iv
Symbols and abbreviated terms . iv
Symbols . iv
Abbreviated terms . iv
The EFC community: roles . iv
General . iv
Other ITS systems and services . iv
Sensors, vehicle system and common equipment . iv
Infrastructure sourced data . iv
Financial and commercial systems . iv
Telecommunication systems . iv
Jurisdiction and Authorities . iv
Standardization bodies . iv
Common service rights provider . iv
Roles internal to the EFC domain . iv
General . iv
EFC domain roles . iv
Interoperability manager. iv
Toll service provider . iv
User of the service . iv
Toll charger role . iv
EFC functional roles and responsibilities . iv
Services . iv
Overview . iv
Sub-services involving toll charger, toll service provider and interoperability manager rolesiv
Sub-services involving the toll service provider and user . iv
Sub-services involving the toll charger and toll service provider . iv
(informative) Mapping EFC architecture to the C-ITS architecture . iv
(informative) Information schemata and basic information types . iv
(informative) Enterprise objects within roles . iv
Bibliography . iv
Foreword . vi
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
4.1 Symbols . 2
4.2 Abbreviated terms . 3
iv
ISO/DISFDIS 17573-1:2026(en)
5 The EFC community: roles . 4
5.1 General . 4
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 and commercial systems . 6
5.6 Telecommunication systems . 6
5.7 Jurisdiction and Authorities . 6
5.8 Standardization bodies . 7
5.9 Common service rights provider . 7
6 Roles internal to the EFC domain . 7
6.1 General . 7
6.2 EFC domain roles . 8
6.3 Interoperability manager . 10
6.4 Toll service provider . 11
6.5 User of the service . 12
6.6 Toll charger role . 13
6.7 EFC functional roles and responsibilities . 14
7 Services . 16
7.1 Overview . 16
7.2 Sub-services involving toll charger, toll service provider and interoperability manager
roles . 18
7.3 Sub-services involving the toll service provider and user . 38
7.4 Sub-services involving the toll charger and toll service provider . 48
Annex A (informative) Mapping EFC architecture to the C-ITS architecture . 81
Annex B (informative) Information schemata and basic information types . 87
Annex C (informative) Enterprise objects within roles . 95
Bibliography . 106

v
ISO/DISFDIS 17573-1:2026(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. 1. In particular, the different approval criteria needed for the different types
of ISO document 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 drawnISO draws attention to the possibility that some of the elementsimplementation of this
document can bemay involve the subjectuse of (a) patent(s). ISO takes no position concerning the evidence,
validity or applicability of any claimed patent rights. ISO is not in respect thereof. As of the date of publication
of this document, ISO had not received notice of (a) patent(s) which may be required to implement this
document. However, implementers are cautioned that this may not represent the latest information, which
may be obtained from the patent database available at www.iso.org/patents. 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 (ITS), in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 278,
Intelligent Transport Systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
[1]
This second edition of cancels and replaces the first edition (ISO 17573-1:2019),ISO 17573-1:2019 ), which
has been technically revised.
The main changes are as follows:
— Clause 3 has been updated and ISO 17573-2 has been made the primary source for terms and definitions;
— the reference model has been extended (i.e. image-based tolling schemes have been included);
— the action and schematic diagrams have been visually adapted;
— the enterprise objects descriptions in Annex C have been corrected.
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.
vi
ISO/DISFDIS 17573-1:2026(en)
Introduction
The widespread use of road tolling demands provisions for users of vehicles that are roaming through multiple
toll domains. Users can 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. It can also be possible to have such a contract without the necessity of having OBE
on-board. In Europe, for example, this need has been recognized and legislation on interoperability has been
[2] [3] [4] [2] [3] [4]
adopted in  .
In addition to specialized standards there is also a need for a system architecture that:
— provides an architectural “umbrella” for other electronic fee collection (EFC) standards in terms of a
common definition of 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 and descriptions,
— to simplify the communication between experts from different regions, 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.
Road toll schemes conforming to this document can be used for various purposes including measured
distance-based 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 can be
[7]
desirable from a policy and from a user point of view. In the past, ISO 24014-1ISO 24014-1 used ISO
[6]1)
17573:2010ISO 17573 as a starting point. This document has benefited from that relationship and has also
[7]
taken ISO 24014-1:2015ISO 24014-1:2015 into account.
[8]
In this document, ISO/IEC 10746-3 [the Open Distributed Processing (ODP) ISO/IEC 10746-3 standard] is
used for the description of the architecture.
[8]
TheISO/IEC 10746-3 (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

1)
Cancelled and replaced by this document.

vii
ISO/DISFDIS 17573-1:2026(en)
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 recent years, the development of concepts and standards in the field of Cooperative ITS (C-ITS, ISO/TC 204
and CEN/TC 278) brought forward the possibility to deliver EFC services based on C-ITS architecture. Such
mapping of services and roles between EFC and C-ITS architectures is possible also due to the use of the ODP
standards to model a complex system, defined concepts and terms for the realm of C-ITS.
This document gives a description of the architecture of the EFC schemes environment from the enterprise
viewpoint, by refining and extending what had been already achieved in ISO 17573-1:2019.ISO 17573-
[1]
1:2019 . Correspondences between concepts and terms in this document and those inISO 17427-1 ISO
[9]
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.
viii
ISO/DISFDIS 17573-1:2026(en)
Electronic fee collection — System architecture for vehicle-related
tolling —
Part 1:
Reference model
1 Scope
This document definesspecifies 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.
This document 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;
— a decomposition of the EFC systems environment into its main enterprise objects;
— the roles and responsibilities of the main actors. This document does not imply that all roles perform all
indicated responsibilities. The responsibilities associated with a role can be shared between two or more
stakeholders. Specifying 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.
From a process point of view the architectural description focuses on toll determination, toll charging,
provision of EFC 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 suitable 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 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.
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 17573-2, Electronic fee collection — System architecture for vehicle related tolling — Part 2: Vocabulary
3 Terms and definitions
For the purpose of this document, the terms and definitions given in ISO 17573-2 and the following apply.
ISO/DISFDIS 17573-1:2026(en)
ISO and IEC maintain terminologicalterminology databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at httphttps://www.electropedia.org/
Field Code Changed
3.1
artefact, noun
physical object of material or physical piece of information or a system or subsystem that is used in an ITS
system
4 Symbols and abbreviated terms
4.1 Symbols
In action diagrams, the following graphical conventions apply:
ISO/DISFDIS 17573-1:2026(en)
Rounded corner box indicates responsibilities and related activities within
roles
Arrow crossing borders between roles indicates information exchanges
between roles
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
ISO/DISFDIS 17573-1:2026(en)
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
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
EFC is an intelligent transport systems (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 is usually implemented in equipment installed in the vehicle or without
it, 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 ISO/IEC
[10]
15414ISO/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 (for the description of the enterprise
objects within EFC architecture roles, see Annex C) . External enterprise objects are involved in the provision
of the EFC service (see Annex B for basic information types covered by 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 briefly described in clause 5.1 to give the complete picture of the EFC
community. Figure 1 shows the external objects in the EFC community.
ISO/DISFDIS 17573-1:2026(en)
Figure 1 — Enterprise objects of the EFC community
Subclauses 5.2 to 5.9 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.
ISO/DISFDIS 17573-1:2026(en)
5.2 Other ITS systems and services
An ITS service can generally build on data provided by other ITS systems or ITS services. Objects in the EFC
domain can for instance receive data from other traffic management or information systems as input to pricing
algorithms used in an EFC system.
NOTE The information exchange between EFC and Traffic management is specified in ISO/TS 21192.ISO/TS
[11]
21192 .
5.3 Sensors, vehicle system and common equipment
An EFC domain can 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 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 can be either in the vehicle or elsewhere, (e.g. a computer installed within the EFC
domain.).
NOTE Shipped goods can become relevant in future EFC schemes.
5.4 Infrastructure sourced data
An EFC domain can use data from environmental sensors for the fee calculation. A dynamic road pricing
scheme can for instance use both the pollution measurements from environmental sensors and the data on
traffic flows and speeds for the dynamic fee calculation. Sensors that are solely installed for the purpose of
EFC are defined as part of the internal enterprise objects.
EXAMPLE Environmental sensors can be used to measure air pollution or noise.
5.5 Financial and commercial systems
The functionality requested from financial and commercial systems is to provide the financial services
requested by EFC internal enterprise objects. The services cover mainly the transfer of money between
entities in the EFC community. The EFC internal enterprise objects handle charging data while the financial
and commercial systems handle payment information (‘money’). The charging data also includes payment-
relevant information (e.g. an amount subject to invoice). However the processing of the payments and relevant
transfers of monetary means is in the scope of financial and commercial systems.
5.6 Telecommunication systems
The functionality requested from the telecommunication systems is to provide telecom services requested by
the EFC domain.
EXAMPLE Such services can be cable network for transfer of data between the operators of the EFC internal
enterprise objects or 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 and Authorities
The responsibilities of the external enterprise object called Jurisdiction and 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:
ISO/DISFDIS 17573-1:2026(en)
— Road and transport authorities, can define policies related to the type of and availability, reliability and
quality of the transport service subject to a fee. The authorities can also, in co-operation with the financial
authorities, define policies for tariffing principles that are used in an EFC domain. The authorities can 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
EFC contract issuer and the operator taking the role of TC.
— Vehicle registration authorities can 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 can define policies for the use of telecom systems.
EXAMPLE 3 Such policies can cover the definition of the frequencies used in wireless communication systems.
— Financial authorities can define policies for an EFC domain and the financial environment it operates, and
the split of roles between the EFC domain and the financial systems.
EXAMPLE 4 Such policies can cover the definition of the nature of the fee (tax, charge or duty) or allowed payment
means (e.g. electronic purses).
— Data protection authorities can define policies for the security and privacy in an EFC domain.
— Public key infrastructure (PKI) certificates are issued by the trusted entity within the PKI. The trusted
entity issues, signs and manages the 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 the EFC domain. There are interactions with an EFC domain concerning EFC
standards that are used for EFC domain as well as input from EFC domain to the standardization bodies,.
EXAMPLE These interactions can involve TCs or operators taking part in the preparation of EFC standard.
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 usage of a single
means of payment. Its role, responsibilities, and requirements on EFC systems, as well as its interactions with
[12]
the roles internal to the EFC domain are standardized in ISO/TS 21193.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
ISO/DISFDIS 17573-1:2026(en)
responsibilities that are logically related to each other, either by their objectives or the actors that can 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 is
summarized by the diagram in Figure 2.
ISO/DISFDIS 17573-1:2026(en)
ISO/DISFDIS 17573-1:2026(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 provides the services in the ITS service group called EFC. For a mapping of the
EFC roles and their responsibilities to roles defined within the C-ITS architecture, see Annex A.
Subclauses 6.3 to 6.6 describe the EFC roles identified in Figure 2 .,, 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 defines
the policy of a given regime or of the overall EFC domain. ion.
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.
ISO/DISFDIS 17573-1:2026(en)
— 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 EFC is performed by means of electronic OBE,
— providing the EFC service to the user without OBE, if toll scheme 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 user,
— managing the customer relationships related to the use of the EFC 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 schemes,
— 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,
— providing and managing the EFC contract including the service rights for the toll service user.
ISO/DISFDIS 17573-1:2026(en)
— Providing toll declaration, including:
— making sure that the OBE is reporting information needed for the toll charging in a secure way,
— providing positioning information of a vehicle (e.g. by means of an autonomous OBE),
— collection of information needed for toll charging from other sources than OBE,
— providing toll context data originated elsewhere in a way that they can be installed in the OBE.
— Customizing the OBE, including customizing the OBE in a secure way.
— Maintaining the OBE, including maintaining the functionality of the OBE.
— Providing the licence plate number (LPN) and other required vehicle information to the TC,.
— Exchanging the relevant trust objects with the TC.
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 can encompass a road network, a specific section of a road or a specific area offering a service.
EXAMPLE 1 Such services offered can cover distance-based 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.
It can also be any service related to the use of a vehicle in the road transport system.
EXAMPLE 2 Such services can cover payment for the petrol at the petrol station by mean of EFC.
The role that covers the consumption of the services provided by the EFC system is commonly referred to as
a use of the service. Responsibilities of this role pertain to the functional operation of the system.
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 required in toll scheme (e.g. mandatory if tolling is performed
via an image-based tolling system without an OBE),
— providing data about the vehicle and official vehicle documents to the TSP,
— adhering to the toll regime for a toll domain.
— Owning or operating a vehicle, including:
— signing a contract with a TSP,
ISO/DISFDIS 17573-1:2026(en)
— signing a contract with the issuer of the EFC contract means accepting responsibility for compliance
to the rules related to the use of the EFC service,
— acquiring an OBE,
— installing and eventually de-installing the OBE in the vehicle,
— terminating the contractual relation to the TSP,
— receiving the bill, (e.g. by means of an invoice,) for a service usage, and ,
— 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
6.6.1 Short description
The TC role defines the toll regime, operates the toll system and can 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 TSP roles.
6.6.2 Responsibilities
The responsibilities of the TC role include:
— Basic charging, including:
— providing, if applicable, the transport service,
EXAMPLE 1 Such service the use of road network, parking spaces or ferry crossings.
— defining the charging principles for the service offered,.
— Calculating the toll (directly or by delegation to the TSP), 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, OBE (if its use is required by the TC).
— Originating toll context data, including:
— informing the TSP about the toll context data and the toll charging principles.
— 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
[13]
domain. This process is also known as localization augmentation (ISO 13141),ISO 13141 ),
ISO/DISFDIS 17573-1:2026(en)
— informing the driver of the vehicle about the EFC availability and toll charging principles, (e.g. through
signs and messages either directly or via the OBE,),
— 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,
— accepting the service rights stored in the OBE, i.e. th
...