CEN/TR 16152:2011

SLOVENSKI STANDARD
01-maj-2011
Elektronsko pobiranje pristojbin - Personalizacija in montaža OBE za prvo
vgradnjo
Electronic fee collection - Personalisation and mounting of first mount OBE
Elektronische Gebührenerfassung - Personalisierung und Montage der ersten
bordeigenen Ausrüstung
Perception de télépéage - Personnalisation et installation des équipements embarqués
en première monte
Ta slovenski standard je istoveten z: CEN/TR 16152:2011
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT
CEN/TR 16152
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
March 2011
ICS
English Version
Electronic fee collection - Personalisation and mounting of first
mount OBE
Perception de télépéage - Personnalisation et installation Elektronische Gebührenerhebung - Personalisierung und
des équipements embarqués en première monte Einbau von Fahrzeuggeräten der Erstausstattung

This Technical Report was approved by CEN on 17 January 2011. It has been drawn up by the Technical Committee CEN/TC 278.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 16152:2011: E
worldwide for CEN national Members.

Contents Page
Foreword .3
Introduction .4
1 Scope .5
1.1 Background and expected benefits of first-mount OBE .5
1.2 Personalisation concept .5
2 Normative references .6
3 Terms and definitions .6
4 Symbols and abbreviations .6
5 Context Description .7
5.1 General .7
5.2 Actors and Roles .8
5.3 Overview of Assets . 10
5.4 Use cases . 12
5.4.1 Initialisation: Mounting of OBE . 12
5.4.2 Initialisation: Assignment of individual data . 12
5.4.3 Initialisation: Assignment of vehicle data . 13
5.4.4 Contracting of the OBE with the Service Provider . 14
5.4.5 Enabling long range mobile communication . 15
5.4.6 Change of the vehicle for the same contract . 16
5.4.7 Cancellation of an existing contract . 17
5.4.8 Change of the contract for the same vehicle . 17
5.4.9 Normal EFC use cases: charging and enforcement . 18
5.4.10 Repair and upgrade of the OBE . 19
5.4.11 Change of vehicle properties . 20
5.4.12 Decommissioning and replacement of the OBE . 21
6 Personalisation concept . 22
6.1 Overall requirements . 22
6.1.1 Functional requirements . 22
6.1.2 Security Requirements . 26
6.2 Vehicle interface requirements and constraints . 34
6.2.1 Introduction . 34
6.2.2 Installation principles . 35
7 Personalisation data . 35
7.1 EFC Attibutes . 35
7.2 OBE related data . 37
7.3 Access protection information . 37
7.4 Vehicle registration data . 37
8 Recommendations . 38
Bibliography . 40

Foreword
This document (CEN/TR 16152:2011) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN shall not be held responsible for identifying any or all such patent rights.
Introduction
With the increased use of OBE for EFC, the need for effective distribution is growing. The OBE could
potentially be integrated into the vehicle by the vehicle manufacturer as part of manufacturing process. The
EETS provider (according to EC's European Electronic Toll Service business model) would in such a scenario
be faced with the issue on how to personalize the data in the OBE, including the data related to the contract
between him and the user. This issue is relevant for both DSRC and satellite based OBEs.
The issues addressed by the document include:
1) vehicle interfacing requirements and constraints
a) vehicle data buses
b) requirements and constraints from the automotive industry (e.g. in terms of electronic,
mechanics…)
c) safety
d) security
2) personalization requirements and constraints
a) Access to the protected data inside the OBE e.g. ContractNumber
b) Where are the EETS and contract data located? (inside the OBE or in a smart card).
c) Activation and deactivation of the OBE
This Technical Report is not a substitute for regulations and standards and these should always be respected
and used by manufacturers.
1 Scope
1.1 Background and expected benefits of first-mount OBE
It could be foreseen that in future the DSRC OBE will be delivered by car manufacturer as a feature of the
vehicle as they do today with car radio which are parts of the most sold vehicles. For the vehicle owner, the
OBE supplier is the car manufacturer acting as an OEM (Original Equipment Manufacturer).
The integration of first mount OBE by car manufacturer is the only way to create a future mass market for EFC
application based upon DSRC as well as GNSS/CN, as at present the integration of this type of OBEs cannot
be achieved except for heavy goods vehicles. Regarding DSRC, this is also an opportunity to extend the
capability of today’s EFC technologies by providing increased quality of service, and possibly a greater range
of services using in-vehicle electronics and resources.
1.2 Personalisation concept
The personalisation procedure is the procedure where the EFC Service Provider initialize, customise, and
finally activate the EFC interoperable service to OBE, for a customer with or without existing account. Two
different kinds of personalisation methods can be defined:
a) the personalisation procedure can be done “over the air”. In such case, personalisation data can be
encoded in the OBE by the Service Provider over a secure air-link, or
b) personalisation data can be loaded directly by the driver into the OBE or Service Provider via a personal
storage media.
Theses are two fundamentally different approaches. The second method is perfectly fitted for critical
initialisation data, such as encryption keys, to enable the driver to use the same EFC contract in different
vehicles, and also to send personalisation data via post to a large number of customers.
In any case, the personalisation procedure shall be implemented in a practical way. It was reminded that the
very large majority of Service Provider distribution networks (and related point of sales) are not suited to allow
point-to-point communication with vehicles. They are suited mainly for front-desk operations such as
initialisation of an account, data collection of user information, and so on.
For both methods, all access protection information, OBE contract information, shall be stored in a secure
storage area within the OBE. During the personalisation procedure, any OBE and Service Provider service
point will only communicate, but only further to a successful check of access rights.
The use of an air-link for personalisation purposes includes some risks with respect to the security of the EFC
system. The present document addresses appropriate measures to counteract these risks. Security services
such as integrity protection and authentication protocols shall be defined to prevent unauthorised access to
the content of the OBE memory area retaining personalisation data. This statement of principles summarises
essential aspects to be taken into account for the personalisation of OBE. These principles are valid:
a) whether the EFC system is based upon DSRC, GNSS-CN, or a combination of both technologies;
b) for permanently installed OBE;
c) for both original equipment manufacturers (first mount) and after sales permanently attached to the
vehicle by OBE manufacturers.
2 Normative references
The following referenced documents are indispensable for the application 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.
EN ISO 14906, Road transport and traffic telematics — Electronic fee collection — Application interfaces
definition for dedicated short-range communication (ISO 14906:2004)
CEN ISO/TS 17575–1, Electronic fee collection — Application interface definition for autonomous systems —
Part 1: Charging (ISO/TS 17575-1:2010)
ISO 11568-2, Banking — Key management (retail) Part 2: Symmetric ciphers, their key management and life
cycle
prEN ISO 17573, Electronic fee collection — System architecture for vehicle related tolling (ISO 17573:2010)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
on-Board Equipment (OBE)
equipment fitted within or on the outside of a vehicle and used for toll purposes
3.2
electronic fee collection (EFC)
toll charging by electronic means via a wireless interface
3.3
roadside equipment
equipment located along the road transport network, for the purpose of communication and data exchanges
with on-board equipments
3.4
Toll Charger
legal entity charging toll for vehicles in a toll domain
3.5
Toll Service Provider
legal entity providing to his customers toll services on one or more toll domains for one or more classes of
vehicles
NOTE The Toll Service Provider may provide the OBE or may provide only a magnetic card or a smart card to be
used with OBE provided by a third party (like a mobile telephone and a SIM card can be obtained from different parties).
The Toll Service Provider is responsible for the operation (functioning) of the OBE.
4 Symbols and abbreviations
CC  Common Criteria
AID  Application Interface Definition
BST  Beacon Service Table
CESARE Common EFC System for ASECAP Road tolling European system
DSRC Dedicated Short-Range Communication
DTCO Digital TaCOgraph
EAcK Element Access Key
EAuK Element Authentication Key
EC  European Commission
ECU Electronic Control Unit
EID  Element Identifier
EFC Electronic Fee Collection
HGV Heavy Goods Vehicle
KVC Key Verification Code
L1  Layer 1 of DSRC (Physical Layer)
L2  Layer 2 of DSRC (Data Link Layer)
L7  Layer 7 of DSRC (Application Layer)
LLC  Logical Link Control
MAC Message Authentication Code
MEAcK Master Element Access Key
MEAuK Master Element Authentication Key
MMI  Man-Machine Interface
OBE On-Board Equipment
OBU On-Board Unit
PAN Personal Account Number
RSE Road-Side Equipment
T-APDU Transfer-Application Protocol Data Unit
VST  Vehicle Service Table
5 Context Description
5.1 General
In many existing systems OBEs are delivered by the Service Provider. The process to add vehicle and service
user data is normally a part of the contract between the Service Provider and the OBE manufacturer. In this
situation there is one Security Domain within which full trust must exist. As it is foreseen that the OBE will be
integrated with the vehicle the personalization process of the OBE must support that the OBE is mounted to
the Vehicle when the personalisation takes place.
Furthermore, it is possible that different contracts issued by different Service Providers will be in place and
related sets of personalisation assets implemented in the same OBE throughout its lifetime.
5.2 Actors and Roles
The following actors have been identified as actors who are related to assets related to the OBE.
a) Toll Charger. He is responsible for the collection of road usage charges on a specific part of the road
infrastructure. He is interested in personalisation data as far as he needs them for the determination or
checking of the charges. His special interest is in the correctness of the vehicle data and of the Service
Provider identification (assuming that the Service Provider guarantees him for the payment of the fees if
he can proof the usage of the road infrastructure).
b) Service Provider. He offers the EFC service to users of the road infrastructure. A user subscribing to the
service will pay the fees to the Service Provider who will forward them to the appropriate toll charger
according to the usage. To contribute to the determination of the road usage and the charges due, the
Service Provider will operate the OBE mounted to the vehicle of the service user, after having added his
personalization data to it. Anyway, the personalization data responsibility is kept by the Service Provider
towards the User and the Toll Charger. His interest is that only road usages of customers having
subscribed his service are charged to him and that he can assign the charges to the appropriate service
user.
c) OBE Manufacturer. He produces the OBE and delivers it to the vehicle manufacturer to be mounted to a
vehicle.
d) Vehicle Manufacturer. He is responsible for the integration of the OBE into the vehicle.
e) Vehicle registration authority. The involvement of this actor in the personalization of first mount OBE is to
be defined. In any case it may serve as a trusted source of at least part of the vehicle data.
f) EFC service user. He subscribes to the EFC service of a Service Provider for a specific vehicle with an
OBE. His interest is that he is charged only for his road usage.
g) Mobile communication provider (in case of GNSS system). He offers a wide range communication service
that may be used not only during EFC, but also for personalization of the OBE. The OBE has to be
initialized for the specific service before it can use the communication channel.
These actors are present in the EFC environment independent from the issue of personalisation of first mount
OBE. Not all of them must have an active role in personalisation - some of them may just have a specific
interest (like for instance the toll charger).
For retrofitted OBE it is usually assumed that the overall responsibility for this OBE is at the Service Provider.
This also covers the responsibility for the personalisation. The Service Provider may get the OBE from the
OBE Manufacturer at a stage where part of the personalisation took place already. But as soon as the Service
Provider takes over the OBE, the OBE Manufacturer is not involved any more and in case there is some
information needed on the personalisation or something is found to be wrong with it, the Service Provider is
the actor to be addressed.
For first mount OBE the responsibilities are not that obvious. For instance the OBE may be mounted to the
vehicle at a stage where there is no Service Provider. There may be several Service Providers over the OBE
lifetime. The way to deal with this situation, as proposed for this technical report, is to introduce roles related
to the personalisation of first mount OBE. Each role has to be assigned to an actor, but for some of the roles
there are several candidates. Assigning the roles to specific actors leads to an implementation of the
personalisation on the organisational level.
The following roles with no clear assignment to an actor are introduced:
Mob. comm. provider
EFC service user
Vehicle registration
authority
Vehicle manufacturer
OBE manufacturer
Service Provider
Toll Charger
h) OBE issuer. He has the overall control on the OBE lifecycle. For retrofitted OBE it is clear that the Service
Provider takes this role. For first mount OBE there is no need for a Service Provider to be assigned to the
OBE during the whole OBE lifetime. Therefore it has to be determined which actor takes the role of the
OBE issuer. As soon as there is a valid contract for the OBE, the Service Provider is responsible towards
the Toll Charger for the correct functioning of the OBE. In case he does not take himself the role of the
OBE issuer from the beginning of the OBE lifetime, he has to rely on the OBE issuer to fulfil his
obligations towards the Toll Charger. Therefore it is assumed that there is some contractual relation
between OBE issuer and Service Provider.
i) Vehicle data issuer. He collects the relevant vehicle data of the vehicle, to which the OBE is mounted,
and transfers them to the OBE. As soon as there is a valid contract for the OBE, the Service Provider is
responsible towards the Toll Charger for the correctness of the vehicle data. In case he does not take
himself the role of the vehicle data issuer, he has to rely on the vehicle data issuer to fulfil his obligations
towards the Toll Charger. Therefore it is assumed that there is some contractual relation between vehicle
data issuer and Service Provider.
j) OBE owner. This is expected to be the same as the vehicle owner, as the OBE is mounted to the vehicle
at the time it is sold.
k) OBE repairer. He is contacted to repair or replace the OBE in case it does not work correctly. As soon as
there is a valid contract for the OBE, the Service Provider is responsible towards the Toll Charger for the
correct functioning of the OBE. In case he does not assume himself the role of the OBE repairer, he has
to rely on the OBE repairer to fulfil his obligations towards the Toll Charger. Therefore it is assumed that
there is some contractual relation between OBE repairer and Service Provider.
l) Mobile communication customer. He is the holder of the mobile telecommunication agreement with the
Mobile Communication Provider.
Possible assignments of actors to roles shows possible assignments of roles to actors. Note that some roles
can be assigned to different actors during the OBE lifetime. At any time it should be assigned only to one
actor.
Table 1 — Possible assignments of actors to roles

OBE issuer X X X
Vehicle data issuer X X X X
OBE owner X X X X
OBE repairer X X X
Mob. comm.
X X X X
customer
Currently there are too many open issues to go for a specific role assignment. Developing a concept for first
mount OBE based on the roles without assigning actors to them, leaves the flexibility not to be in conflict with
future decisions and local specialities.
5.3 Overview of Assets
Figure 1 below identifies different set of assets in the OBE. An asset is something that has a value to the
system and needs protection measures to be taken. Examples of protection measures which might apply are
authorisation before access, detection of manipulation, verification of authenticity and provision of
confidentiality. In Figure 1 the different assets that are used in an EFC system are identified.

Figure 1 — Overview of Assets
The following assets exist:
a) Transaction Data Assets
b) Personalisation assets
c) OBE Manufacturer Specific Assets
The Transaction Data Assets consists of assets that are updated during a transaction e.g. when the OBE
passes a DSRC station or GPS positions are received from satellites. These assets have to be taken care of
during decommissioning and replacement of the OBE.
The Personalisation Assets consists of assets that are used by the Service Provider and are under his
responsbility. The issue is how to enter, remove and update them in the OBE in a controlled way when the
OBE has already been integrated to the vehicle. Each Service Provider might have its own set of
personalisation assets that he is responsible for. The most common case up to now is that only one set of
personalisation assets exists.
The Personalisation Assets consists of Application keys, Application Data and Vehicle data.
The Application keys consists of Access keys are used in service to grant access to application data
Authentication keys which are used to secure the authenticity of the OBE and the data integrity of the
application data assets. At personalisation of an application defined by the DSRC standard a number
generation of Authentication keys may be loaded.
The Application Data consist of data that is used by the Service Provider to support a service. Example of
Application data is Contract Data in CEN ISO/TS 17575-1, Payment Means and EFC Context Mark in
EN ISO 14906.
Vehicle data is also part of the personalisation assets but it is reasonable that this asset is common to all
applications.
The OBE Manufacturer Specific Assets are assets that are put into the OBE before integration to the vehicle.
The way of adding these assets will be manufacturer specific and is outside the scope of this document.
Typical examples of these assets are Data structure, Application software, physical individual calibration
values and Individual IDs.
A number of roles have been identified and their responsibilities are indicated. Responsibility in this context
means ensuring the correctness of the assets it is responsible for. It is foreseen that more than one Service
Provider may exist.
The role of the Service Provider is defined in prEN ISO 17573. According to prEN ISO 17573 he is
responsible for the operation (functioning) of the OBE. This implies that he is responsible for the correctness
of the personalisation assets towards the Service user and the Toll Charger. As has been pointed out already,
for first mount OBE there might exist no Service Provider at the time of personalisation. In this case entities
different from the Service Provider take over the OBE personalization role. The responsibility of these entities
towards the Service Provider and their contractual relation with the Service Provider is an issue to be dealt
with.
It is the Service Provider who sets the access conditions and decides who shall have the possibility to read or
write the assets.
The OBE issuer should have a contract with the OBE Manufacturer which allows him to put in the initial
elements in the OBE which are necessary in order to personalise the OBE.
The OBE Manufacturer is responsible for adding hardware specific data to make the OBE work.
5.4 Use cases
5.4.1 Initialisation: Mounting of OBE
It is the basic assumption in this technical report that the mounting of the OBE is part of the manufacturing
process of the vehicle, which means that it is done before the vehicle is delivered to the customer. The OBE
may be a standard component of the vehicles of a given make, or may be an option for the customer. In any
case it must be possible to mount whole series of OBE with the same hardware and software to series of
vehicles.
On a technical level the mounting of the OBE includes the fixing of the OBE housings to the vehicle, if
required the connection to the power supply of the vehicle, possibly the establishment of a communication link
between the OBE and the vehicle electronics, the installation of a human machine interface (HMI) and the
fitting of antennas for the mobile communication of the OBE (at least DSRC and long range communication). It
is possible that some components of the OBE are shared with other applications, like for instance the mobile
communication devices, road map data and the HMI.
OBE
OBE manufacturer
Mounting of OBE
Vehicle
Vehicle manufacturer
Figure 2 — Use case “Mounting of OBE” involving the OBE, the OBE manufacturer, the vehicle and
the vehicle manufacturer
5.4.2 Initialisation: Assignment of individual data
Initially all OBE of a given OBE make look the same. At the final stage of the OBE mounting it must be
possible to address individual OBE, which means that each OBE must have some property allowing to
distinguish it from all others. Thus some individual properties have to be assigned to each OBE, like a serial
number (which for instance could include the VIN of the vehicle, to which the OBE is mounted). At least some
of these properties must be available when exchanging data with the OBE and therefore corresponding data
have to be stored in the OBE. But in general there is also a need to centrally store data corresponding to the
individual properties of each OBE, such that they can be used to record further data related to specific OBE.
As a consequence, the process of assigning individual properties to an OBE includes both data storage in the
OBE and at some place outside the OBE. The assignment of the individual properties is the starting point of
the OBE lifetime.
The assignment of individual properties can take place before the OBE is mounted to the vehicle or
afterwards. The two processes are independent from each other.
Assignment of
individual data
OBE
OBE issuer
Figure 3 — Use case “Assignment of individual data” involving the OBE and the OBE issuer
5.4.3 Initialisation: Assignment of vehicle data
Each OBE is mounted to one specific vehicle. As the charging may depend on vehicle properties and
identification of the vehicle may be part of the compliance checking with interrogation of the OBE (see 5.4.9),
data related to the vehicle have to be available in the OBE, which means that they have to be stored there
before starting the EFC process.
There is an important difference between first mount OBE and retrofitted OBE. Retrofitted OBE is assigned to
one specific provider of the EFC service in the personalisation phase. It is the responsibility of this Service
Provider to record the vehicle data and to make them available at the OBE in the way he uses them for the
EFC service. In case of a first mount OBE, it is reasonable to consider the assignment of vehicle data as a
process not necessarily involving the Service Provider. With this, the vehicle data can be assigned at an early
stage when no Service Provider has been selected for the OBE.
For this reason a specific role is introduced to take the responsibility for the assignment of the vehicle data to
the OBE and for the correctness of the vehicle data stored in the OBE: the vehicle data issuer. Depending on
the set-up of the whole EFC organisational model this may be the vehicle manufacturer, an authority
responsible for vehicle registration, the user or the first Service Provider operating the OBE.
Assignment of
vehicle data
OBE
Vehicle data issuer
Figure 4 — The use case “assignment of vehicle data” involving the OBE and the vehicle data issuer
5.4.4 Contracting of the OBE with the Service Provider
For EFC there must be a contract between the user of the EFC service and the Service Provider (see for
instance prEN ISO 17573). The contract is assigned to a specific vehicle or group of vehicles with specific
OBE. Charges for a vehicle are recorded with a reference to this contract, such that the Service Provider is
able to claim the payment from the appropriate user under appropriate terms. Therefore data related to the
contract must be available at the OBE during the charging process as application data (see 5.3). They have to
be transmitted to the OBE to enable the use of the OBE for charging.
The use case deals neither with the way the contract is established nor with the content of the contract as
such. It just establishes the transfer of the contract related data to the OBE, and the transfer of the OBE or
vehicle related data to the Service Provider at the contracting stage, if such a transfer is required.
As soon as the contract is valid, the OBE can start its normal EFC operation and determine fees based on the
contract. From this time on the Service Provider has to guarantee the correct functioning of the OBE towards
the Toll Charger. This means that within the contracting process the Service Provider has make sure that the
OBE is properly manufactured and installed, that it has the right personalisation data and that it has not been
changed in an inappropriate manner since its installation. For this he has to verify information that the OBE
manufacturer, the OBE issuer, the vehicle data issuer and the OBE repairer have generated.
In some cases the Service Provider intends to use his own software or configuration data in the OBE. Then
the download of this software or data is part of the contracting use case.
The user as a contracting party has to agree not only on the contract as such, but also on the intention to link
the contract to the OBE of his vehicle. Therefore, the user is an actor in this use case, even though in some
scenarios his contribution may only be modest.
Service Provider
Establishment of
contract
OBE
User
Figure 5 — The use case “Establishment of contract” involving the OBE, the Service Provider and the
user
5.4.5 Enabling long range mobile communication
OBE supporting GNSS/CN based charging requires a long range mobile communication link. It is assumed
that this link is enabled based on a commercial arrangement with a mobile communication provider. Data
related to this agreement have to be present at the OBE, such that the payment for the use of the
communication link can be managed.
It is reasonable not to invent new procedures for this use case and to introduce new technical means for it, but
to use what is common in the mobile telecommunication domain (like for instance a SIM card for the
agreement related data). Nevertheless the use case is relevant in the context of first mount OBE, because it
interacts with the other use cases.
There are different options on who is the customer towards the mobile communication provider: it may be for
instance the service user, the OBE issuer or the Service Provider. Not to prejudge a specific choice, the
corresponding actor is just called mobile communication customer.
Mobile communication
provider
Enabling long range
mobile
communication
OBE
Mobile communication
customer
Figure 6 — The use case “Enabling long range mobile communication” involving the OBE, the mobile
communication provider and the mobile communication customer
5.4.6 Change of the vehicle for the same contract
It is assumed that a first mount OBE stays in the same vehicle during the whole lifetime of this vehicle. If a
user changes his vehicle, then there is the option that he gets a new OBE. In case he had a contract with a
Service Provider assigned to the old vehicle and OBE, he might want to continue the contractual relation with
this Service Provider. Of course it will be possible in any case to cancel the contract assigned to the old
vehicle and OBE, and to sign a new contract for the new vehicle and OBE. But it would be practical if the
Service Provider could, in some cases, offer the possibility that the old contract is kept and assigned to the
new vehicle and OBE.
A seamless handover from the old OBE and vehicle to the new OBE and vehicle is crucial for this use case.
As soon as the contract is assigned to the new OBE and vehicle, it must be guaranteed that it is not used any
more for the old OBE and vehicle.
The use case may involve a first mount OBE for the old vehicle, for the new vehicle or for both of them.
Service Provider Old OBE
Change of the
vehicle for the same
contract
New OBE
User
Figure 7 — The use case “Change of the vehicle for the same contract” involving the Service Provider,
the user, the old and the new OBE
5.4.7 Cancellation of an existing contract
Both the Service Provider and the user may want to cancel an existing contract for a specific vehicle and
OBE. It is not sufficient for them to inform the other side about the cancellation. It must be guaranteed that
from the time of the cancellation on the OBE is not used any more. For this the OBE has to be involved in the
use case to adapt its contract information. As long as no new contract is established, the OBE has to remain
inactive. Note that the immediate replacement of the contract with a new one is covered in the next use case.
Service Provider
Cancellation of an
existing contract
OBE
User
Figure 8 —The use case “Cancellation of an existing contract” involving the Service Provider, the user
and the OBE
5.4.8 Change of the contract for the same vehicle
There are various reasons to change the contract with the Service Provider for the same vehicle and OBE:
a) The contract may have expired, without an option to extend its validity period;
b) The user may wish to contract with a different Service Provider;
c) The Service Provider or the user may want to switch to a contract with different contract terms;
d) The Service Provider may want to terminate the contractual relation with the user and the user has to find
a new Service Provider;
e) The vehicle may have been sold to a different owner.
The use case consists of two parts: the old contract is cancelled and the new contract is established. For the
OBE this means that the data related to the old contract have to be deleted or made ineffective, whereas the
data related to the new contract have to be stored and prepared for use.
The actors in this use case are essentially the same as in the contracting use case (see 5.4.4), with the
difference that there may be a different Service Providers and a different user for the old and new contract.
Old Service Provider New Service
Change of the
contract for the same
vehicle
OBE
Old user New user
Figure 9 — Use case “Change of the contract for the same vehicle” involving the OBE, the old and
new Service Provider (possibly being identical) and the old and new user (possibly being identical)
5.4.9 Normal EFC use cases: charging and enforcement
The use cases of the normal OBE operation – charging and compliance checking – are not part of the
personalisation, but are listed here because they have implications for the personalisation process. Charging
involves the OBE as a supplier of charging data and in some cases for the recording and processing of such
data. The OBE may be interrogated to check if it complies with the intended charging process and to identify
the responsible party in case of non-compliance.
The use case as such is not part of the personalisation and will not further be described. But it is relevant as it
is based on the personalisation, and listed here to give a complete picture of all personalisation aspects.
Service Provider
Charging
OBE
Compliance checking
Toll charger
Figure 10 — The use cases “Charging” and “Compliance checking” involving the OBE, the Service
Provider and the toll charger.
5.4.10 Repair and upgrade of the OBE
This use case applies to changes of the OBE intended to re-establish or to improve its normal operation. A
defect or the need for an upgrade is reported to a repairer, who then performs the required changes. The
change may consist of a repair or replacement of hardware components, the addition of new hardware
components or the update of the software. The use case involves the user of the OBE, who has to bring the
OBE to the repairer in case a remote repair (via the long range mobile communication link) is not possible.
Even though the OBE is only operational when a contract has been established, repair or upgrades may also
be required at times when there is no contract, just to avoid a situation where a contract is established but the
OBE is not immediately ready for operation.
In any case the Service Provider having established a contract for the OBE (see 5.4.4) has to verify and
accept the repair or upgrade. If there is a contract at the time of the repair or upgrade, then the acceptance
process may be part of the use case, which means that the Service Provider is directly involved. If the contract
is established later on, then the acceptance process is part of the use case establishing the contract (see
5.4.4).
OBE repairer
Repair and upgrade
(no contract
established)
OBE
User
Figure 11 — The use case “Repair and upgrade” involving the OBE, the OBE repairer and the user

OBE repairer Service Provider
Repair and upgrade
(contract established)
User OBE
Figure 12 — The use case “Repair and upgrade” in case a contract with a Service Provider is
established. The use case involves the OBE, the OBE repairer, the Service Provider and the user
5.4.11 Change of vehicle properties
The vehicle data relate, among others, to vehicle properties relevant for charging. This includes the problem of
presence of the trailer, and related personalisation. These properties may be static or variable. Some changes
of vehicle properties, like for instance those related to attaching and detaching trailers, may happen frequently
and there may be specific features of the OBE to cope with them, like for instance their detection via a
communication link to the vehicle electronics or the possibility for the user to declare them via HMI. Such
changes are excluded from this use case, as they are covered in the normal charging use case (see 5.4.9).
The use case only deals with property changes that are handled essentially in the same way as the initial
assignment of vehicle data, which means that those properties not applying any more are deleted within the
vehicle data and the new properties are added to them. Reasons for such a change of vehicle properties may
be as follows:
a) an error in the vehicle data has been detected;
b) non-revocable changes to the vehicle have been executed, like a change of the vehicle colour or the
change of the emission properties leading to the assignment of a different emission class;
c) some administrative procedure leads to different vehicle properties, like for instance the change of the
maximum allowed weight in the vehicle registration document.
The use case involves the same actors as the assignment of vehicle data. Clarification is needed on how the
vehicle data issuer gets the information that the vehicle properties have changed. If the user profits from the
change (in terms of lower fees), then it can be expected that he initiates the procedure of the use case. Else
the use case has to be linked to some administrative procedures.
Change of vehicle
properties
OBE
Vehicle data issuer
Figure 13 — The use c
...