ISO/DIS 17573-1

ISO/TC 204

Secretariat: ANSI

Date: 2025-11-06

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

DIS stage

Warning for WD’s and CD’s

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

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.

© ISO 2025

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.

ISO copyright office

CP 401 • Ch. de Blandonnet 8

CH-1214 Vernier, Geneva

Phone: + 41 22 749 01 11

E-mail: copyright@iso.org

Website: www.iso.org

Published in Switzerland

Contents

Foreword iv

Introduction v

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 6

5.5 Financial/Commercial systems 6

5.6 Telecommunication systems 6

5.7 Jurisdiction/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 7

6.3 Interoperability manager 8

6.4 Toll service provider 9

6.5 User of the service 10

6.6 Toll charger role 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 15

7.3 Sub-services involving the toll service provider and user 26

7.4 Sub-services involving the toll charger and toll service provider 32

Annex A (informative) Mapping EFC architecture to the C-ITS architecture 46

Annex B (informative) Information schemata and basic information types 49

Annex C (informative) Enterprise objects within roles 56

Bibliography 62

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

This second edition of EN ISO 17573-1^[1] cancels and replaces the first edition (EN ISO 17573-1:2019^[2]), 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.

A list of all parts in the ISO 17573^[3] 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.

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 desirable from a policy and from a user point of view. In the past, ISO 24014-1^[4] prepared by ISO TC 204 used ISO 17573:2010^[5] 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 (ISO 17427-1^[6]) 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^[5]. Correspondences between concepts and terms in this document and those in EN ISO 17427-1^[7] 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^[5], this document removes all security requirements on interfaces, which are better and more generally dealt with in ISO 19299^[8] and prEN ISO 17574^[9].

This document is Part 1 of a multipart standard that is made up of the following parts:

• EN ISO 17573-1^[1], Electronic fee collection — System architecture for vehicle related tolling — Part 1: Reference model (this document)
• ISO/FDIS 17573-2^[10], Electronic fee collection — System architecture for vehicle related tolling — Part 2: Vocabulary
• EN ISO 17573-3^[11], Electronic fee collection — System architecture for vehicle related tolling — Part 3: Data dictionary

Electronic fee collection — System architecture for vehicle-related tolling —

Part 1:
Reference model

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.

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

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)

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/

artefacts

physical objects of material or physical piece of information or a system or subsystem that are used in an ITS system

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

In action diagrams, the following graphical conventions apply:

For the purpose of this document, the following abbreviated terms apply throughout the document unless otherwise specified.

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 ISO/IEC 15414^[12] 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.

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.

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.

NOTE The information exchange between EFC and Traffic management is standardized in ISO/TS 21192^[13].

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.

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.

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.

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.

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.

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.

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 standardized in ISO/TS 21193^[14].

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.

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

The following clauses describe the above identified EFC roles, indicating the responsibilities for each role.

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.

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.

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.

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

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.

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 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 TSP,
• 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,
• terminating the contractual relation to the TSP,
• 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.

The TC 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 TSP 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 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 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 localization 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,
• 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.

Figure 3 summarises the EFC roles, adding their responsibilities and mutual interactions.

Figure 3 — EFC roles and responsibilities

The main aim of the architecture is to identify those services that lead to interactions that should 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 is not required 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 be compliant to those herein specified, to achieve interoperability among systems belonging to different organizations, or implementations by different suppliers.

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 context 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 to a decision. Not all possibilities are shown, and this simplification is done 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^[15] is the associated conformity assessment standard for ISO 12813^[16]), but which is not cited in this document.

Figure 5 shows the sub-services that involve TC, TSP and interoperability manager.

Figure 5 — Sub-services involving toll charger, toll service provider and interoperability manager

Adding at least one TC to a community acting as interoperable EFC scheme is a precondition to starting the overall operation. This sub-service is initiated by a candidate TC applying for accreditation. If the certification is granted, it is forwarded to all known actors playing the TSP 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 TSP role fulfils the basic provision responsibilities.

Figure 6 — Adding/deleting a new toll charger to/from an interoperability region

Adding a new TC implies a new version of the tolling system overview to be generated and exchanged. Also, the new TC will exchange Trust objects with the service providers that will operate within its domain.

Deleting a previously certified TC will follow a similar logical sequence, the only difference being that the service can be initiated by a request of either the TC 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 standardized 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 standardized in ISO 12855^[17].

In terms of service interactions:

• The interoperability manager shall act as service provider when certifying a TC, 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 TSP.
• The TSP shall act as content provider when exchanging Trust objects with the TC.

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 TSP applying for accreditation. When the accreditation is granted it will be forwarded by the interoperability manager to all known TCs to start to negotiate bilateral agreements on common operations.

Figure 7 shows the related action diagram. The actor playing the TSP role fulfils the basic provision responsibilities.

Figure 7 — Adding/deleting a new service provider to/from an interoperability region

Accrediting a new TSP implies a new version of the tolling system overview to be generated and exchanged. Also, the new TSP will exchange Trust objects with the TCs for toll domains in which it intends to operate.

Deleting a previously accredited TSP will follow a similar logical sequence, the only difference being that the service can be initiated by a request of either the TSP or the interoperability manager.

The following interactions are identified:

1. A certification of EFC constituent interaction, that allows TSPs to be certified to operate.
2. A system overview interaction, which allows standardized tolling system characteristics to be 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 standardized in EN ISO 12855.

In terms of service interactions:

• The interoperability manager shall act as service provider when certifying a TSP, and as content provider when distributing the updated system overview to all other actors.
• The TC shall act as content provider when exchanging Trust objects with the TSP.
• The TSP shall act as service recipient when certified by the interoperability manager, and as content provider when exchanging Trust objects with the TC.

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

Note that using context data and system overview by the TSP role implies further information exchanges inside the TSP that may require to be standardized if the involved responsibilities/activities are played by different actors. In particular, customisation of OBE in 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.

The following interactions are identified:

1. A toll scheme interaction that allows the actor playing the role to inform the change of toll scheme.
2. A system overview interaction, which allows standardized tolling system characteristics to be exchanged.
3. A context data interaction, which allows context data to be communicated to an actor playing the role of the TSP. context data exchanges are standardized in EN ISO 12855 and EN 16986^[18].
4. A customisation information interaction, which allows context data information to be updated in the OBE, when this is present. Customisation information interaction is standardized in ISO 17575-3^[19].

NOTE EN 16986^[18] is cited in the EETS legislation that is relevant to the EEA. This applies for any further reference to the this standard in this document.

In terms of service interactions:

• 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 TSP.
• The TSP shall act as information sink for the defined information exchanges.

One responsibility of the interoperability manager is to define rules for the EFC community and to diffuse them to the toll service providers and toll chargers. Figure 9 shows the related action diagram.

Figure 9 — Defining rules

The following interactions are identified:

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.

In terms of service interactions:

• The interoperability manager shall act as content provider when distributing EFC rules.
• The TC shall act as information sink for the defined information exchange.
• The TSP shall act as information sink for the defined information exchange.

One responsibility of the manager is to monitor the EFC activities. Figure 10 shows the related action diagram.

Figure 10 — Monitor operations

The following interactions are identified:

1. An operations report interaction, that allows the actors playing the TSP and TC roles to inform the interoperability manager about the current operation status.

In terms of service interactions:

• The interoperability manager shall act as information sink for the defined information exchange.
• The TC shall act as content provider for the defined information exchange.
• The TSP shall act as content provider for the defined information exchange.

One responsibility of the manager is to handle disputes between involved actors playing the roles of TC and TSP. Disputes can be initiated by either the TC role or by the TSP role when disagreements in the toll service operation cannot be solved. The result of handling disputes can cause the permission to operate as TC or TSP be revoked (see 7.2.2 and 7.2.3). Figure 11 shows the related action diagram.

Figure 11 — Handling disputes

According to the result of the dispute, either the actor playing the TC role or the actor playing the TSP role, or both, may have their accreditations revoked. Termination of a contract shall be notified to the users that are contracted with the interested TSPs. This can be done in various ways, such as, e.g., using additional information in the user billing interaction (see 7.3.4).

The following interactions are identified:

1. A Complain interaction that allows the actors playing the TSP and TC 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.

In terms of service interactions:

• The interoperability manager shall act as content provider for the Certification revocation operation, and as a Service Provider for the Complain interaction.
• The TC shall act as a service user for the Complain interaction and as an information sink for the Certification revocation interaction.
• The TSP shall act as a service user for the Complain interaction and as an information sink for the Certification revocation interaction.

Figure 12 shows the sub-services involving the TSP and the user.

Figure 12 — Sub-services involving the toll service provider and user

Providing an EFC contract requires that the TSP 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, if an OBE is used for tolling (e.g. in image-based tolling systems) . In the general case, the OBE will be subsequently loaded with appropriate information before it is ready for operation. No OBE is provided to the user, if no OBE is used for tolling.

Figure 13 shows the related action diagram.

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 those actions do not occur.

Note also that Figure 13 shows some actions that involve interactions and related information exchanges inside the same role (TSP). These information exchanges may be standardized 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.

The following interactions are identified:

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 information interaction, that allows customisation of the OBE with contractual information when an OBE is used in the specific toll domain. Customisation information exchanges are standardized in ISO/DIS 21719-1^[20] concerning the framework, CEN ISO/TS 21719-2^[21] and ISO/TS 21719-3^[22] using DSRC and ICC respectively.

In terms of service interactions:

• The TSP 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 information interaction.
• The user shall act as a content provider for the Signed contract and as information sink for the Contractual information.

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 User to the TSP includes all types of requests and complaints, including those that may cause the TSP to subsequently interact with other actors.

EXAMPLE Such requests are e.g. reports on stolen or lost OBEs, which can cause the TSP to inform TCs by means of exception lists that those OBEs are no longer valid.

The following interactions are identified:

1. A Help, information or complain interaction, that allows the user to request customer care.
2. A Customer care interaction, that allows the TSP to communicate the results of the service.

In terms of service interactions:

• The TSP shall act as service provider for the Help, information and complain interaction, as content provider for the Customer care information.
• The user shall act as a service user for the Help, information and complain interactions and as information sink for the Customer care information.

User billing is performed by means of a series of interactions between the TSP and the user. Exceptions happening in performing user billing may cause contracts to be revoked, and related information to be transmitted to TCs by using Handling Exceptions sub-services (see 7.4.8). 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

The following interactions are identified:

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 TSP 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 standardized in ISO 12855^[17] and EN 16986^[18]

In terms of service interactions:

• The user shall act as information sink for the user bill, and as a content provider for the Financial objects.
• The TSP shall act as content provider for the Exception list and for the user bill, and as information sink for the Financial objects.

Figure 16 shows the sub-services involving the TC and the TSP.

Figure 16 — Sub-services involving the toll charger and the toll service provider

Collection of transit information in short-range communication (SRC)-based EFC systems is performed by an actor performing the role of TC in various ways, which generally do not involve interactions with the user. Figure 17 shows an activity diagram where interactions happen between TC and TSP in an SRC-based system. Collection of transit information happens in an SRC domain when an actor playing the role of TC recognises the presence of an OBE. To cover the most general case, exchange of mutual identification information is shown in the diagram, at the end of which the TC identifies the user, and the TSP recognises the charging domain.

Figure 17 — Collecting transit information (SRC systems)

The following interactions are identified:

1. A User identification interaction, to verify customer’s credentials by means of TSP’s available information.
2. A Charging identification interaction, to verify TC’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 standardized in ISO 14906^[23] and EN 15509^[24] respectively.

NOTE EN 15509^[24] is cited in the EETS legislation that is relevant to the EEA. This applies for any further reference to the this standard in this document.

In terms of service interactions:

• The TC 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 TSP shall act as service provider for the user identification, Charging identification and Transit information exchanges, and information sink for the Charging information exchange.

In autonomous tolling systems, collection of transit information is performed by the TSP, 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 TC in the form of toll declarations. The set of activities to collect charging information in autonomous systems is performed almost entirely within the TSP, and is detailed in Figure 18 solely for the sake of clarity.

Figure 18 — Collecting charging information (autonomous systems)

The granularity of toll declarations depends on specific agreements between the actors playing the TC and TSP roles. The TSP may invalidate a user (e.g. in case of credit threshold overridden) subsequently to the processing of usage data, and consequently put it on an exception list. Exchange and usage of exception lists is detailed in 7.4.6.

The following interactions are identified:

1. A toll declaration interaction, to notify charging information related to one or more transits. toll declaration exchanges are standardized in ISO 12855^[17] and EN 16986^[18] respectively.
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 standardized in ISO 17575-1^[25].

NOTE Usage data can be collected via data shared by vehicles (i.e. without dedicated OBE).

In terms of service interactions:

• The TSP 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.

Collection of transit information happens in such a tolling domain when an actor playing the role of TC recognises the presence of a vehicle and is able to identify the user without any direct interactions with either the user or the TSP.

Vehicle identification, together with transit information, is subsequently provided by the TC to the TSP by means of the Providing payment information sub-service, detailed in 7.4.5.

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 TC, which requires the TSP the payment of a number of transits related to previously exchanged billing details;
2. spontaneously by the TSP, which only notifies the TC 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 Interoperability Manager can be involved to settle the dispute, as detailed in 7.2.7.

Figure 19 — Providing payment information

The following interactions are identified:

1. A Billing details interaction, which allows either the TC or the TSP to notify transit information, possibly with associated charging information.
2. A Payment claim interaction, which allows TCs to request payments.
3. A Payment notification interaction, which allows the TSP to notify payments.

All above interactions are standardized in ISO 12855^[17] and EN 16986^[18] respectively.

In terms of service interactions:

• The TSP 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 TSP shall act as service provider for the Payment claim interaction.
• The TC 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 TC shall act as service user for the Payment claim interaction.

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 TC to detect exceptions, which include collecting own data (from, i.e. sensors) or interacting with the user OBE to get data, or both. 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 TC role to request OBE’s operational parameters and status. OBE interrogation interactions are standardized in ISO 12813^[16].

NOTE ISO 12813^[16] is cited in the EETS legislation that it relevant to the EEA. This applies for any further reference to the this standard in this document.

In terms of service interactions:

• The TC shall act as service user.
• The TSP shall act as service provider.

The Trust object exchange sub-service is symmetrical and not necessarily solicited, i.e.:

1. Both the TC and the TSP can provide or request Trust objects.
2. Trust objects may be provided by either the TC or the TSP without a previous request.

Figure 21 summarises the Trust object exchange action.

Figure 21 — Trust object exchange

The following interactions are identified:

1. A Trust object transaction interaction, which allows either the TC or the TSP to request a Trust object to its counterpart.
2. A Trust object notification interaction, which allows the either the TC or the TSP to deliver a Trust object to its counterpart.

All above interactions are standardized in ISO 12855^[17] and EN 16986^[18] respectively.

In terms of service interactions:

• Either the TSP or the TSP 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 TC or the TSP 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.

Exceptions can be detected (see 7.4.6) by either the TC when, e.g. an OBE transiting in the TC’s domain is inspected or when a vehicle’s license plate is not recognised as valid (e.g. by using the ANPR technology), or by the TSP 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.

Figure 22 — Handling Exceptions

The following interactions are identified:

1. A Notify anomaly interaction that allows an actor playing the TC role to inform the TSP of some detected anomalies, e.g. in an OBE’s operational parameters or status.
2. An Exception list interaction that allows the TSP to inform an actor playing the role of TC about change of status for one user.

All above interactions are standardized in ISO 12855^[17] and EN 16986^[18].

In terms of service interactions:

• The TC shall act as content provider for the Notify anomaly.
• The TSP shall act as content provider for the Exception list.

When detecting a user’s vehicle entering a charging zone, the TC may provide local information if the vehicle has an OBE (e.g. localization data, that is provided to improve location accuracy). Figure 23 shows an action diagram where such an action is performed.

Figure 23 — Providing local information

The following interaction is identified:

1. A Provide data to OBE interaction that allows an actor playing the TC role to inform the OBE about local information. Localization information interaction is standardized in ISO 13141^[26].

NOTE EN ISO 13141^[26] is cited in the EETS legislation that it relevant to the EEA. This applies for any further reference to the this standard in this document.

In terms of service interactions:

• The TC shall act as service provider.
• The TSP shall act as service user.

1. 
   (informative)
   
   Mapping EFC architecture to the C-ITS architecture
   1. General

ISO 17427-1^[6] defines the organizational 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 organizational architecture (ISO 17427-1^[6])

The scope of ISO 17427-1^[6] is related to the System operation role and the Functional operation role. The two other major roles in a C-ITS organizational architecture defined in ISO 17427-1^[6] are out of the scope of this document.

• 1. System operation and Functional operation roles
     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, organization 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.

• • 1. Functional operation

The Functional operation role is split into two sub-roles in ISO 17427-1^[6]. 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.

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 TSP, TC, and user of the service.
• The responsibilities of the C-ITS role Content provider are shared between the EFC roles TSP, TC, 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 TSP, TC, 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 TSP, TC, 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 of a service provided by an ITS application in ITS. 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 (EN ISO 17427-1^[7]).

Figure A.3 shows the mapping between the C-ITS roles defined in ISO 17427-1^[6] and the roles identified in this document.

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 EN 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^[6], has been defined in this document (see 7.1).

1. 
   (informative)
   
   Information schemata and basic information types
   1. General

The ODP model ISO/IEC 10746-2^[27]ISO/IEC 10746-3^[28] (ISO/IEC 10746-2 to ISO/IEC 10746-4^[29]) 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 gives a succinct Information viewpoint description.

• 1. Static schema

The following Table B.1 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 TC belongs to the same class of the “administrative info” exchanged between the user and the TSP, although the actual data contents may be different (one more 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

The static schema synthesized by the previous Table B.1 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.

• 1. 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:

1. 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 TSP.
2. Transit information, as that class that represents all information objects relevant for toll calculation.
3. Operational information, as that class that represents all information objects relevant for the management of the EFC system.
4. Payment information, as that class that represents all information objects relevant for the transfer of financial data.
   1. EFC rules
      1. Overview

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

Objects in the EFC rules class are listed in Table B.2.

Table B.2 — Information objects in the EFC rules class

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

• • 1. Operational information

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

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

• • 1. Payment information

Objects in the Payment information class are listed in Table B.5.

Table B.5 — Information objects in the payment information class

• 1. Dynamic schema

The information objects identified previously as not invariant (i.e. not listed in Table B.6) 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

1. 
   (informative)
   
   Enterprise objects within roles
   1. General

Each role in the functional operation can be described by enterprise objects on the following three levels:

1. Organizational level, where different enterprise objects describe the assigned responsibilities.
2. Equipment level, where enterprise objects identify the artefacts, e.g. the OBE or LPN, used by actors to perform their roles.
3. 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.

• 1. Toll service provider
     1. General

The TSP domain includes enterprise objects that are summarised in Figure C.1.

NOTE Vehicles do not belong to the TSP domain.

Figure C.1 — Toll service provider domain

• • 1. Organizational level

The TSP 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, if tolling requires an OBE, only one OBE to use a vehicle in one or more toll domains. If tolling does not require an OBE, tolling service enables users having only one contract to use vehicle in one or more toll domain without OBE.

The TSP may purchase services from other legal persons or organizations operating on its behalf. These organizations are often given names that reflect the responsibilities they have taken, e.g. OBE provider and contract provider or issuer. Any distinction between a TSP and entities acting on its behalf is outside of the scope of this document.

A TSP may as well act as the TC for one or more toll domains.

The TSP controls the OBE and is responsible for its operation (functioning) as well as proper LPN information storage and management (for tolling without OBE).

NOTE 1 The OBE can function without payment means support.

NOTE 2 The TSP 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.

• • 1. Equipment level

The OBE is used by a TSP for providing toll services to the user of the toll service. In case of the image-based tolling system, the LPN is used to provide toll services. The Central Equipment (CE) is used by TSP to collect, store and process charging data (that may originate from the OBE or other sources). The CE may consist of other types of equipment depending on the allocation of roles within the TSP organizational level (see Figure C.2).

The OBE is initialised and eventually maintained by the TSP.

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

• • 1. Transport service level

The OBE may be and LPN is 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.

• 1. User of the toll service
     1. General

The enterprise objects in the user domain are summarised in Figure C.3.

Figure C.3 — User domain

• • 1. Organizational level

The “customer” is the customer of the TSP.

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 haulier 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 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) if one is required by the tolling scheme or to provide the vehicle information (e.g. the LPN and the number of axles).

• • 1. Equipment level

The off-board equipment used by a customer in relation to its toll duties is called its CE, e.g. the CE of a fleet manager having several EFC contracts (e.g. self-care provided by TSP to the customer). The OBE (if required by the tolling system) or LPN is part of the Service provision responsibilities.

• • 1. Transport service level

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

• 1. Toll Charger
     1. General

The enterprise objects in the TC domain are summarised in Figure C.4.

Figure C.4 — Toll charger domain

• • 1. Organizational level

The TC 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 TC may purchase services from other legal persons or organizations operating on its behalf. These organizations are often given names that reflect the responsibilities they have taken, e.g. EFC operator and enforcement operator.

A TC is said to control the toll domain and for each toll domain there is only one TC that controls it.

NOTE 1 Which legal entity will act as the TC 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 TC.

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

• • 1. Equipment level

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 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 (RSE), including mobile equipment and equipment above the road or in its surface.
• CE 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.

• • 1. Transport service level

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.

Bibliography

[1] EN ISO 17573-1, Electronic fee collection - System architecture for vehicle-related tolling - Part 1: Reference model (ISO 17573-1:2019)

[2] EN ISO 17573-1:2019, Electronic fee collection - System architecture for vehicle-related tolling - Part 1: Reference model (ISO 17573-1:2019)

[3] ISO 17573, Electronic fee collection — Systems architecture for vehicle-related tolling

[4] ISO 24014-1, Public transport — Interoperable fare management system — Part 1: Architecture

[5] ISO 17573:2010, Electronic fee collection — Systems architecture for vehicle-related tolling

[6] ISO 17427-1, Intelligent transport systems — Cooperative ITS — Part 1: Roles and responsibilities in the context of co-operative ITS architecture(s)

[7] 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)

[8] ISO 19299, Electronic fee collection — Security framework

[9] prEN ISO 17574, Electronic fee collection - Guidelines for security protection profiles (ISO/DIS 17574:2025)

[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 (ISO 17573-3:2023)

[12] ISO/IEC 15414, Information technology — Open distributed processing — Reference model — Enterprise language

[13] ISO/TS 21192, Electronic fee collection — Support for traffic management

[14] ISO/TS 21193, Electronic fee collection — Requirements for EFC application interfaces on common media

[15] ISO 13143, Electronic fee collection — Evaluation of on-board and roadside equipment for conformity to ISO 12813

[16] ISO 12813, Electronic fee collection — Compliance check communication for autonomous systems

[17] ISO 12855, Electronic fee collection — Information exchange between service provision and toll charging

[18] EN 16986, Electronic fee collection - Interoperable application profiles for information exchange between service provision and toll charging

[19] ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems — Part 3: Context data

[20] ISO/DIS 21719-1, Electronic fee collection — Personalization of on-board equipment (OBE) — Part 1: Framework

[21] CEN ISO/TS 21719-2, Electronic fee collection - Personalization of on-board equipment (OBE) - Part 2: Using dedicated short-range communication (ISO/TS 21719-2:2022)

[22] ISO/TS 21719-3, Electronic fee collection — Personalization of on-board equipment (OBE) — Part 3: Using integrated circuit(s) cards

[23] ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range communication

[24] EN 15509, Electronic fee collection - Interoperability application profile for DSRC

[25] ISO 17575-1, Electronic fee collection — Application interface definition for autonomous systems — Part 1: Charging

[26] ISO 13141, Electronic fee collection — Localization augmentation communication for autonomous systems

[27] ISO/IEC 10746-2, Information technology — Open Distributed Processing — Reference Model: Foundations

[28] ISO/IEC 10746-3, Information technology — Open Distributed Processing — Reference Model: Architecture

[29] ISO/IEC 10746-4, Information technology — Open Distributed Processing — Reference Model: Architectural semantics — Part 4: