ISO/TS 17573:2003

Road Transport and Traffic Telematics - Electronic Fee Collection (EFC) - Systems architecture for vehicle related transport services

ISO/TS 17573:2003 specifies a system architecture for electronic fee collection (EFC) systems concerning vehicle related transport services such as the use of toll roads, zone access, parking and route guidance. ISO/TS 17573:2003 does not cover person related transport services such as public transport. However, some of the clauses in ISO/TS 17573:2003 may also be applicable for fare collection. NOTE Fare collection architecture in public transport is covered by other Working Groups in CEN/TC278 and ISO/TC204, e.g. WG3 Public Transport in CEN/TC278. ISO/TS 17573:2003 provides the overview of, and inter-relationship among, the set of standards for design, development, testing and operation of applications in the field of EFC. ISO/TS 17573:2003 is also applicable to the ITS Fundamental Service called Electronic Financial Transactions which is the use of electronic, or "cashless" payment systems for transportation. Hence, ISO/TS 17573:2003 covers toll collection systems, parking fee collection systems, systems for road and congestion pricing and integrated payment systems for transport services.

Télématique de la circulationet du transport routier — Perception du télépéage — Architecture système pour systèmes de transport embarqués sur le véhicule

General Information

• Status: Withdrawn
• Publication Date: 15-Jun-2003
• Withdrawal Date: 15-Jun-2003
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 5 - Fee and toll collection
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 13-Dec-2010
• Completion Date: 13-Dec-2025

Relations

• Consolidates: ISO 7375-2:1998 - Road vehicles - Coiled tube assemblies for air brake connection between towing and towed vehicles - Part 2: Performance requirements
• Effective Date: 06-Jun-2022
• Revised: ISO 17573:2010 - Electronic fee collection - Systems architecture for vehicle-related tolling
• Effective Date: 15-Apr-2008

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 17573
First edition
2003-06-01
Road Transport and Traffic Telematics —
Electronic Fee Collection (EFC) —
Systems architecture for vehicle related
transport services
Télématique de la circulation et du transport routier — Perception du
télépéage (EFC) — Architecture système pour systèmes de transport
embarqués sur le véhicule
Reference number
©
ISO 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2003 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee
casting a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 17573 was prepared by the European Committee for Standardization (CEN) in collaboration with
Technical Committee ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on
technical cooperation between ISO and CEN (Vienna Agreement).
Throughout the text of this document, read “.this European pre-Standard.” to mean “.this Technical
Specification.”.
Contents
Foreword.v
Introduction .vi
1 Scope .1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviations. 6
5 Conceptual architecture.7
5.1 General .7
5.2 Payment means and Payment method .7
5.3 Payment system .8
5.4 Model for EFC used for vehicle related transport services.9
6 Logical architecture.11
6.1 Definitions .11
6.2 The Use case diagram for EFC systems.11
7 Interfaces.15
7.1  General. 15
7.2  The User – Transport Service Provider interface .15
7.3 The User - Collection Agent interface.16
7.4 Other interfaces .17
8 Security in EFC systems.18
8.1  General. 18
8.2 Security and Privacy.18
8.3 Data Protection Framework.18
8.4 Data Protection measures .19
8.5 Data Protection and EFC System architecture.19
8.6 Keys and keys management .21
8.6.1 General. 21
8.6.2 Keys.21
8.6.3 Key management.22
8.6.4 Key distribution .22
Annex A (informative) Functional architecture .24
Annex B (informative) Class diagram.27
Annex C (informative) Bibliography .29
iv © ISO 2003 – All rights reserved

Foreword
This document (CEN ISO/TS 17573:2003) has been prepared by Technical Committee CEN/TC 278, "Road
Transport and Traffic Telematics" the secretariat of which is held by NEN in collaboration with Technical Committee
ISO/TC 204, “Intelligent transport systems”.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Czech Republic, Denmark,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway,
Portugal, Slovak Republic, Spain, Sweden, Switzerland and the United Kingdom.
Introduction
There are several standards covering the sector of Electronic Fee Collection (EFC) within Road Transport and
Traffic Telematics (RTTT). Most of the standards are related to the different interfaces that are found in EFC
systems, but with few or no references to other EFC standards. Due to this a need has arisen for an ‘umbrella’ or
Architecture standard for EFC.
The objective of this standard is to define a reference system architecture for EFC used for vehicle related transport
services. The standard provides a framework of conditions for EFC that should be considered during the
specification and implementation. The given information is technology independent as far as possible to enable
various forms of EFC systems. Specific details with regard to e.g. payment means, communication medium and
design of equipment are intentionally kept out of the scope.
The standard provides details with regard to following aspects:
— Terminology, definitions;
— List of relevant standards, regulations and other relevant documents;
— Architecture model for EFC with regard to all relevant parties and facilities (entities);
— Identification of interfaces, including references to relevant (Pre-)standards / Technical Specifications;
EFC encompasses all systems designed to collect fees from users in a non-manual way for vehicle related
transport services. Generally EFC is characterised by the use of electronic means of payment, by absence of any
action from the user at the moment that payment or transaction is made and that payment or transaction for the
transport service may be collected whether or not the vehicle is moving or stationary. EFC does not exclude
manual payment, conventional money transaction, nor does it include payment by means of sticker, vignettes,
tickets, or magnetic stripe cards etc.
The applications to which EFC is related are Toll Collection, Road Pricing, Parking and Individual Traveller and
Traffic Information. EFC systems for public passenger transport or comparable applications that do not require
vehicle related EFC equipment are excluded.
Vision
To provide enabling standards for the collection of fees from road users by automatic means, primarily by use of an
air interface.
Mission
It is the mission of this standard to describe the overall system architecture for Electronic Fee Collection with the
Road Transport and Traffic Telematics.
vi © ISO 2003 – All rights reserved

1 Scope
This Technical Specification specifies a system architecture for electronic fee collection (EFC) systems concerning
vehicle related transport services such as the use of toll roads, zone access, parking and route guidance.
This Technical Specification does not cover person related transport services such as public transport. However,
some of the clauses in this standard may also be applicable for fare collection.
NOTE Fare collection architecture in public transport is covered by other Working Groups in CEN/TC278 and ISO/TC204, e.g.
WG3 Public Transport in CEN/TC278.
This Technical Specification provides the overview of, and inter-relationship among, the set of standards for design,
development, testing and operation of applications in the field of EFC.
This Technical Specification is also applicable to the ITS Fundamental Service called Electronic Financial
Transactions which is the use of electronic, or ‘cashless’ payment systems for transportation. Hence, this standard
covers toll collection systems, parking fee collection systems, systems for road and congestion pricing and
integrated payment systems for transport services.
2 Normative references
This Technical Specification incorporates, by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed hereafter. For
dated references, subsequent amendments to or revisions of any of these publications apply to this Technical
Specification only when incorporated in it by amendment or revision. For undated references the latest edition of
the publication referred to applies (including amendments).
prCEN ISO/TS 17574 Road Transport and Traffic Telematics (RTTT) - Electronic Fee Collection (EFC) System -
– Security service Framework – Guidelines for EFC security protection profiles.
ENV ISO 14904 Road Transport and Traffic Telematics – Automatic fee collection (AFC) - - Interface
specification for clearing between operators.
ISO/IEC 11770-1 Information technology - Security techniques - Key management - Part 1: Framework.
3 Terms and definitions
For the purposes of this Technical Specification, the following terms and definitions apply.
3.1
actor
class external to the EFC system, e.g. the User and the Vehicle
3.2
availability (1)
definition related to Security: Data and information are available to authorised parties
3.3
availability (2)
definition related to operation of EFC systems: Dependability with respect to the readiness for usage. Measure of
correct service delivery with respect to the alternation of correct and incorrect service
3.4
central account
account which is containing service rights and which is kept and administrated by the issuer of the payment means
or by an entity acting on behalf of the issuer
3.5
Central Communication Unit
part of the Central Equipment serving as mobile communication interface to the OBU
3.6
Central Equipment
system components at fixed centralised locations
NOTE Central equipment is not the same as Central system. Central equipment is used in GNSS/CN based EFC systems.
3.7
charging point
physical point or zone where the use of the transport service is registered. In case of a DSRC based system the
communication between the OBE/OBU and RSU takes place to exchange the information needed to charge the
user by EFC. Charging point also covers the physical point or zone where a fee is collected manually
3.8
charging Point Equipment
equipment installed at a charging point, e.g. a toll station, enabling the operator to collect the fee by the different
payment methods offered to the users
3.9
class
descriptor for a set of objects with similar structure, behaviour and relationships
3.10
class diagram
diagram that shows the classes of the system and their internal relationships (a static structure of a system)
3.11
classification
process of dividing vehicles into various classes according to certain classification parameters (e.g. weight, length,
purpose of use, engine type, number of axles, actual number of passengers)
3.12
clearing Operator
entity that collects and possibly aggregates transactions from one or more Transport Service Providers for delivery
to the Issuer(s). The Clearing Operator can also handle the Apportionment between the Transport Service
Providers. In the financial world this operator is equivalent to an Acquirer
3.13
collection agent
entity responsible for selling, reloading or delivering the Payment Means to the User and collecting the payment
from the User on behalf of the Issuer. The Collection Agent can also collect user related application specific data
from the User. The Collection Agent is also referred to as Retailer
3.14
Conceptual Architecture
overall description of an EFC system incorporating operational concepts and user requirements, together with its
known inter-relationships with other systems
3.15
confidentiality
sensitive data and information are available only to authorised parties (confidentiality of contents)
3.16
contract
expression of an agreement between two or more parties in a payment system or between payment systems. An
example of a contract is the specific relationship between a User and an Issuer in a payment system where the
contract may be explicit or implicit
2 © ISO 2003 – All rights reserved

3.17
contractual interoperability
intention of operators to co-operate recorded in a contractual agreement
3.18
Declared Vehicle Characteristics
data set stored in the OBE/OBU containing vehicle characteristics of the vehicle the OBU is related to
3.19
Electronic Fee Collection
collection of a fee for a transport service where the fee is collected via the exchange of data, e.g. via an air-link
communication, enabling the user to pay for the transport service with electronic values, e.g. an electronic purse or
via a central account
3.20
Electronic Purse
application on an IC-card (integrated circuit card) or a similar device that can store, credit, debit and protect
electronic values having their equivalent in money
3.21
enforcement
measures or actions performed by enforcement authorities or other organisations to achieve compliance with laws,
rules and regulations
3.22
enforcement Operator
entity handling the enforcement of users
3.23
exception handling
process of dealing with system errors or passages that might possibly not be paid for. The outcome of the
Exception handling might lead to that the user is enforced or that the fee can be collected, e.g. by correlating a
pictured licence plate number with the contract register
3.24
Functional Architecture
description of the system in terms of functions and information flows between the functions
3.25
Integrity
sensitive data, information and message sequencing are guarded in such a way that any alteration or destruction
by unauthorised parties is detected (integrity of contents, integrity of message sequence)
3.26
Interoperability
ability of systems to provide services to and accept services from other systems and to use these services to
enable the systems to operate effectively together (see contractual, procedural and technical interoperability)
3.27
Issuer
entity responsible for the payment system and responsible for issuing the Payment Means to the User
3.28
Logical Architecture
determines the nature of the system as being based on Information, Control, or Functions, and describes the inter-
relationships of these aspects. A logical architecture is independent of any hardware or software approach and can
be described either from an Object oriented or Process oriented perspective
3.29
non-repudiation
protection against the denial, by one of the parties involved in the communication through the interface, of having
participated in all or part of the communications
3.30
On-Board Account
account, which is containing service rights and which is being held under the responsibility of the user, e.g. data
stored on an IC-card
3.31
On-Board Equipment
equipment located within the vehicle and supporting the information exchange with the Road Side Unit or the
Central Communication Unit. It is composed of the On-Board Unit and other sub-units whose presence has to be
considered optional for the execution of a Transaction
3.32
On-Board Unit (OBU)
minimum component of an On-Board Equipment, whose functionality always includes at least the support of the
DSRC interface or/and the Central Communication Unit and the protection of the data stored in the OBU
3.33
Operator
generic term for the entities Issuer, Clearing Operator, Collection Agent, Transport Service Provider, Enforcement
Operator or Trusted Third Party
3.34
payment means
expression of a Contract between the User and the Issuer (or via a Collection Agent) that allows the User to access
the transport services available in the Payment System, e.g. an account in a credit card system or an Electronic
Purse
See also 5.2.
3.35
payment medium
carrier of payment means (such as ticket, card or on-board unit)
3.36
payment method
combination of a Payment Means, a Payment Mode and a Payment Scope
3.37
payment mode
parameter defining the time dimension in payment by the User, i.e. Pre-payment, Immediate payment or Post-
payment
3.38
payment scope
application extent of the Payment Method, e.g. national transport or inter-sector
3.39
payment system
financial system that includes the complete process of issuing and use of payment means, clearing and settlement
of transactions
See also 5.3.
4 © ISO 2003 – All rights reserved

3.40
Privacy
right of individuals to control or influence what information related to them may be collected and stored and by
whom and to whom that information may be disclosed
3.41
procedural interoperability
existence of common data element definitions, the same working procedures and data delivery and common format
of presentation in different sets of equipment required to communicate
3.42
Roadside Equipment
equivalent to Transport service Provider Equipment in those charging point where DSRC is used for
communication between the On-Board Equipment and Transport service Provider Equipment, e.g. in a traditional
toll station
3.43
Roadside Unit
DSRC part of the Roadside Equipment whose functionality is to communicate and exchange data with vehicles
passing the charging point
3.44
Transport service
road Transport facility provided by a Transport Service provider. Normally a type of infrastructure, e.g. a toll road or
a road network inside a toll ring
3.45
Transport service Provider
person, company, authority or abstract entity offering a transport service to the User for which the user has to pay a
fee (the fee will in some cases be zero, e.g. emergency vehicles)
3.46
Transport service Provider Equipment
all equipment installed at the Charging point being used for EFC, e.g. communication equipment, classification
systems, vehicle detection systems and signs and signals to the User
3.47
System Architecture
an overall description of an Electronic Fee collection system incorporating the main elements, the main interfaces
and the main functions of the system
3.48
Technical interoperability
capability of different sets of equipment to work together through interconnection, co-ordinated execution or sharing
of resources
3.49
Toll Collection System
equipment and functions enabling the collection of a fee for the use of road infrastructure
3.50
Toll Plaza
See Charging point
3.51
Toll Station
See Charging point
3.52
Transport service
road transport related facility provided by a Transport service Provider. Normally a type of infrastructure, e.g. a toll
toad or a road network inside a toll ring, the use of which is offered to the User for which the User is requested to
pay
3.53
Trusted Third Party
entity who might be responsible for operation monitoring, system and security assessment (including security key
management) as well as granting licences
3.54
User Equipment
any equipment held by the User enabling him to communicate with the collection agent updating his service rights,
e.g. with a PC and a modem
3.55
User
(client, customer, consumer)
entity that uses a transport service provided by the Transport service Provider according to the terms of an
agreement. The User may also be described as the subscriber of an EFC contract, the vehicle owner and the driver
in those cases where these are not the same person or company
3.56
Use Case
abstraction of similar and closely connected scenarios where a scenario is a typical interaction between one or
more actors and the EFC system
EXAMPLE Fee collection at the Charging point.
3.57
Use Case Diagram
graphical model that shows the relationships among the actors and the use cases
4 Abbreviated terms
For the purposes of this Technical Specification the following abbreviated terms apply.
4.1
CN
Cellular Networks
4.2
CPE
Charging Point Equipment
4.3
DES
Data Encryption Standard
4.4
DSRC
Dedicated Short Range Communication
4.5
EFC
Electronic Fee Collection
4.6
GNSS
Global Navigation Satellite Systems
6 © ISO 2003 – All rights reserved

4.7
ICC
IC-card
4.8
ID
Identification
4.9
ITS
Intelligent Transport Systems
4.10
MMI
Man-Machine Interface
4.11
OBE
On-Board Equipment
4.12
OBU
On-Board Unit
4.13
RSE
Roadside Equipment
4.14
RSU
Roadside Unit
4.15
RTTT
Road Transport and Traffic Telematics
4.16
SAM
Secure Application Module
5 Conceptual architecture
5.1 General
This clause defines three essential issues related to Electronic Fee Collection:
a) Payment means and payment method;
b) Payment system;
c) Model for EFC used for vehicle related transport services.
5.2 Payment means and Payment method
By payment means is meant the expression of a Contract between the User and the Issuer that allows the User to
access the transport services available in the Payment System.
EXAMPLE 1 An example of a payment means is an account issued by VISA or MasterCard. The expression of the Contract
will be the information stored on the card and in the written contract between the User and the Issuer. For the User and the
Transport service provider the card will be the crucial information carrier and for this reason the card itself becomes the symbol
of the contract and is often referred to as the payment means. An On-Board Unit may also be related to an account. In this case
the On-Board Unit becomes the symbol of the contract and is referred to as the payment means even though the real payment
means is the contract and the account behind the On-Board Unit. This perception of the On-Board Unit as the payment means
is strengthened in those cases where the payment means is an electronic purse on an IC-card inserted in the On-Board Unit.
The User will see the combination of the On-Board Unit and the IC-card as the payment means even though the payment
means is the information (electronic values) stored on the IC-card. In reality the OBU is just a physical device enabling
communication between the electronic purse (the payment means) and the charging point equipment at the roadside.
EXAMPLE 2 Another example of a payment means is illustrated by the situation where a User makes a call to the operator
to purchase his User rights via the phone. The User will give some information to the operator, e.g. a bank account number or
credit card number or even his vehicle licence plate number. The information (the ‘contract’) is stored somewhere in the EFC
system enabling the User to benefit from the transport service and the operator to charge the User for the transport service
provided, e.g. by debiting a bank account or sending an invoice based on information from the national vehicle register.
Payment means also cash, cheques etc. used for any manual fee collection at the charging point.
Payment mode means the concept defining the time dimension in payment (pre-payment, immediate payment or
post-payment).
Payment scope means the field of application in which the payment means is accepted, e.g. national transport
services.
By Payment method is meant the combination of Payment means, payment mode and payment scope. An example
will be a post-paid central account that can be used in all EFC systems within one country.
5.3 Payment system
5.3.1 General
By payment system is meant a financial system that includes the complete process of issuing and use of payment
means, clearing and settlement of transactions.
The payment means to give the holder of the payment access to the transport services related to the payment system.
Any transport related payment system can be described by means of the abstract definition given in Figure 1.
Figure 1 — The basic entities in a Payment system for EFC
5.3.2 The User
The User, i.e. the user of the Transport service, will receive a transport service from a Transport Service Provider
and the User shall pay for the transport service. The transport service can be the use of a tolled motorway or
parking in a parking house. The User can use values like electronic values on an IC-card for payment or he can
use payment information, e.g. a credit card number or a reference to a central account held by the Issuer. The
reference can be the unique identity of an electronic tag installed in the vehicle used by the User.
8 © ISO 2003 – All rights reserved

5.3.3 The Transport Service Provider
The Transport Service Provider will receive the payment from the user for the transport service he has provided. If
the payment is in an electronic form or in form of payment data, the Transport Service provider has to convert the
values or information into real money. If the values are electronic values on an IC-card he will send a claim to the
issuer of the electronic values to exchange the values into money. If the payment is payment information the
Transport Service provider has to send a claim to the issuer of the payment means, e.g. a credit card company or a
toll operator, including the payment information required and the fee to be paid. When the issuer has checked the
claim he will transfer money to the Transport service provider.
5.3.4 The Issuer
The Issuer is the company or institution that has issued the payment means. If the user has used a credit card or a
credit card account number as payment information the issuer will be the Credit card company. If the user has used
an electronic purse the issuer will be the bank or financial institution that issued the electronic values in the purse.
Another example is a toll operator that has issued a central account to be used in several interoperable EFC
systems.
Between the user and the issuer there will be an implicit or explicit contract depending on the type of payment
means that is used. A person using a credit card account as payment information will have a contract with a credit
card company. A person using values in an electronic purse will have an implicit contract saying that the holder of
the electronic values can use them wherever they are accepted similar to ordinary coins and bank notes. A person
using an electronic tag (On-Board Equipment) carrying payment data linking the tag to a central account held by
the issuer, e.g. a toll operator, will have a contract with the issuer.
It is not unusual to have more than one payment system at the charging point of the transport service. One
payment system can be EFC, one can be manual payment with credit cards and one can be manual payment with
cash. The payment systems has to be seen as logically separated payment systems, although they may have
some common physical elements like toll plaza computers and signals and signs to the drivers.
The privacy of the user is protected in the scheme shown in Figure 1. The Transport Service Provider will have no
information about the User as the payment information transmitted by the OBE will only include an identification of
the issuer and the contract. The claim from the Transport Service Provider will include this information and only the
issuer will be able to link the contractual information collected by a Transport Service Provider to a specific User.
The payment to the Transport Service Provider will always go via the Issuer. In an interoperable environment with
one or more Issuers and two or more Transport Service Providers the Transport Service Providers will never know
who the users are.
5.4 Model for EFC used for vehicle related transport services
Figure 2 illustrates the model for vehicle related transport services. The model is formed by the complete set of
entities (see clause 3 for their definitions) needed to operate an EFC system, including the three entities from the
payment system. The complete set of entities consists of:
— Issuer;
— Transport Service Provider;
— User;
— Collection agent;
— Clearing operator;
— Enforcement operator;
— Trusted third party.
The entities in the model constitute abstract entities and not real organisations.
The conceptual model neither implies nor requires that there should always be a separate organisation for each
abstract entity in any real system. Depending on the particular business arrangements and resulting organisational
models, the abstract entity may or may not have direct counterparts in the real world.
This model is one model able to fully support the transport world while being highly compatible with the models
used in the financial world (by the banking industry and the inter-sector Electronic Purse). In reading this standard,
no assumptions should be made concerning the presence or absence of competing organisations that seek to, or
undertake, one or more of the organisational roles. Consequently an Issuer can act as an Issuer for one or more
EFC systems, e.g. several or all EFC systems on a national level. Similarly, one or many organisations can act as
Transport Service Providers or Collection Agents. However, there are likely to be fewer Clearing Operators than
EFC systems.
The model along with the distinction and naming of the type of relation between the entities is shown in Figure 2.
The inner chain of flows in the diagram (counter clockwise) corresponds to the data flow, the outer circle
(clockwise) to the money and service flow.
Figure 2 — The conceptual model
The fundamental separation between payment applications from transport service applications is implied by the
conceptual model since Issuer and Transport service Provider are independent abstract entities. Besides
interoperability, the freedom for individual, technical development of system components in line with the basic
constraints has to be respected.
NOTE Figure 2 is simplified and does not by any means exclude other relationships between the entities. Several other links
exist, e.g. a direct contact between the User and the Issuer, which means there is no Collection Agent. This is often the situation
in real life. The Collection Agent is always acting on behalf of the Issuer and does not have to be there in those cases where the
entity acting as the Issuer has all the contact with its users without any agent network. Another link that is often found is
between the Transport Service Provider and the Issuer. The Issuer can be Issuer for several EFC systems operated by different
Transport Service Providers who all send their claims directly to the Issuer without any Clearing operator. The flexibility of the
model is described by several examples in ENV ISO 14904.
10 © ISO 2003 – All rights reserved

6 Logical architecture
6.1 Definitions
The Logical architecture is presented as Use case diagram and Class diagram according to the Unified Modelling
Language (UML) syntax. The Class diagram is shown in Annex B.
6.2 The Use case diagram for EFC systems
Figure 3 shows the Use case diagram for EFC systems. The diagram includes the external Classes (the Actors) to
the EFC system. Hence, the actors will be objects (persons, things, other systems etc) that interact with the EFC
system. The diagram also shows the Use cases.
The following Actors are shown in the diagram:
— Clearing Operator;
— Collection Agent;
— Enforcement Operator;
— Issuer of On-Board Equipment;
— Issuer of payment means;
— On-Board Equipment;
— Transport service Provider;
— User;
— Trusted Third Party;
— Vehicle.
The On-Board Equipment is seen as an external class (object) to an EFC system in an interoperable environment
where an OBE may be used as a payment media in several EFC systems. The OBE will be provided by the Issuer
of the On-Board Equipment, which in most cases will be the Issuer of the Payment method or a Transport service
Provider.
The following Use cases are shown in the diagram in Figure 3:
— Management of Service Rights;
— Management of charges;
— Claims and payment settlements;
— EFC system and control.
Table 1 to Table 4 contain further information on these Use cases.
Figure 3 — Use case diagram for EFC systems
12 © ISO 2003 – All rights reserved

Table 1 — Use case: Management of service rights
Use case name Management of Service Rights
Outline Management of Service rights of a User enabling him to benefit from a
transport service paying by means of EFC.
Triggered by A User who wants to acquire, update or terminate his Service Rights.
Actor(s) User
On-Board Equipment
Issuer of Payment means
Issuer of On-Board Equipment
Collection Agent
Transport Service Provider
Use Case description Management of Service Rights comprises the acquisition of the Service
Rights by the EFC users. The actors interact with the EFC system enabling
the User to establish the contractual relationships between the User and
the EFC system as well as having the required payment means and
medium, e.g. an electronic purse and an OBE. The Use case also covers
the scenarios where the User updates or terminates his User rights, i.e.
any updating of his electronic purse or Central account as well as
contractual changes or termination.
The use case uses information from other use cases, e.g. operational
constraints from ‘EFC system control’ and payment conditions from the
‘Claims and payments settlement’.
Table 2 — Use case: Management of charges
Use case name Management of charges
Outline A User benefits from a transport service and the Transport Service
Provider (operator of the Charging point) collects the charging and
payment information enabling him to get paid for the transport service
provided.
Triggered by The Use of Service Rights, e.g. a vehicle passes through the Charging
point.
Actor(s) User
On-Board Equipment
Vehicle
Transport service Provider
Use Case description Manage charges comprises the scenario where a user benefits from a
transport service, e.g. travels on a tolled road and passes through a
charging point (toll plaza). It mainly consists of detection of the vehicle,
classification of the vehicle, communication with the OBU, calculation of
the fee (can also be done off-line in case of Central Account) and collection
of the information required to follow up the suspected non-payers. The Use
case uses information from other Use cases, e.g. black lists from the EFC
system control and contract information from the Management of Service
Rights.
Table 3 — Use case: Claims and payments settlements
Use case name Claims and payments settlements
Outline The clearing process between different entities in one or more EFC
systems based on claims from Transport service providers and payments
from the Users.
Triggered by A claim from a Transport service provider that has provided a transport
service to a User, e.g. a User driving on a tolled motorway.
Actor(s) Transport service Provider
Clearing Operator
Issuer of Payment means
Use Case description Claims and Payment settlement comprises the scenario where the
information from the Management of Service Rights and Management of
charges is used to settle or reconcile the transport services provided and
the payment collected (or to be collected). Hence, it will be a settlement
between the claims from the different transport service providers having
provided transport services and the issuer of the payment means having
received the payment/payment information from the users (via the
Collection Agent if applicable).
The Use case uses information from ‘Management of charges’ and the
‘Management of Service Rights’. The first one will be the charging and
payment information forming a claim from the Transport service Provider.
The latter will be the contractual information collected as part of the
Payment method and On-Board Equipment issuing.
Table 4 — Use case: EFC system and control
Use case name EFC System control
Outline The overall control of the EFC system and its users.
Triggered by Any abnormal event, e.g. malfunctions, errors, non-paying users and
access attempt from unauthorised persons.
Actor(s) Transport service Provider
Enforcement operator
User
Trusted Third Party
Use Case description EFC System Control comprises the scenario that should guarantee the
EFC system operation, system security and reliability of all system
processes. This includes both control of processes and provision of
information to the processes. The use case also includes for instance the
life-cycle management of the security keys, OBE, RSE and if applicable
Central Equipment, the exception handling, the maintenance of the system,
tariff information and black list management.
The Use case uses information from the ‘Management of charges’, which
will be for instance pictures from violating users. It also uses information
from ‘Management of Service Rights’; e.g. information of Users not fulfilling
their contractual obligations as for payment for transport services provided.
The Trusted Third Party may generate and distribute security keys both
used in the use case Management of Service rights (e.g. initialisation of an
OBE) as well as the use case Management of Charges (e.g. authentication
of equipment). However, this is seen as part of the use case EFC system
control.
14 © ISO 2003 – All rights reserved

7 Interfaces
7.1 General
An interface is found between any combination of entities in
...