GB2617461A - Road user charging - Google Patents

Abstract

A system is provided for calculating a fee for a vehicle, the system having an on-board unit located inside the vehicle and a central server, the on-board unit having a private memory unit to store data representative of the location history of the vehicle and receives road usage tariff data from the central server. The on-board unit periodically transmits fee summary data to the central server, where the fee summary data is calculated using the data representative of the location history of the vehicle and the tariff. The private memory unit is only accessible by using a private decryption key. The fee summary data may be used to charge a fee to a user associated with the vehicle. The system may include a road-side unit which communicates with the on-board unit to determine the status of the on-board unit or determine if the on-board unit is malfunctioning. The private memory unit may record evidence of the communication exchange with the road-side unit. The road-side may also detect and identify the vehicle and may include a camera arranged to capture an image of the vehicle.

Description

Road User Charging

BACKGROUND OF THE INVENTION

Many countries in Europe have introduced distance-based fees for heavy goods vehicles. This type of Road User Charging makes vehicles pay parts of the marginal external cost of road transport. Traditionally the external costs are covered by vehicle ownership fees and fuel tax. The shift to electric vehicles changes the fiscal revenues for road operators and governments. Combined with the "polluter pays" principle there is a need to rework the tax system for vehicles.

Adopting the Heavy Goods Vehicles (HGV) Road User Charging system for private cars may be difficult for many reasons, but privacy and technology are major obstacles.

In many countries, the government has large yearly fiscal incomes from vehicles and traffic. This may be composed differently in different countries, but usually some of: vehicle purchase tax, value added tax, registrations fees, yearly ownership fees, vignettes, road tolls, and fuel tax.

A trend that has been going on for a long time is that vehicles are improving fuel efficiency. With the transition to electrical and other zero emission vehicles that don't use fuel at all, the average fuel consumption is decreasing rapidly. Many governments have goals about increasing the amount of zero emission vehicles. This is needed to reach the European goal on 55% reduction in CO2 emissions by 2030. Reduced fuel sales will reduce government fiscal incomes from fuel tax.

In many countries (e.g. Norway), there are incentives in place to encourage people to buy electric cars. One incentive in Norway is discounted toll rates, this further reduced the income to road operators and governments. The result of this policy is that those left with fossil fuel engines will pay more and, in the end, there is none. This is not sustainable; the fee policy must be changed. -2 -

In 2017, the European Commission initiated a large modernisation of the legal framework for mobility and transport. The goal of the legislative package is to make traffic safer; encourage smart road charging; reduce CO2 emissions, air pollution and congestion; cut red-tape for businesses; fight illicit employment and ensure proper conditions and rest times for workers.

Many countries in Europe, and elsewhere, have already implemented Road User Charging for heavy goods vehicles (HGV). This concept is well established, and interoperability is governed by the European Electronic Tolling Service (EETS) directive and regulations detailed in International Organization for Standardization (ISO) and European Committee for Standardization (CEN) standards.

The current solution for HGV Road User Charging cannot directly be deployed to private vehicles. There are challenges with privacy and physical installation. Most HGV schemes collect a detailed log of time and position and process this in multiple steps in a long value chain. The risk for unlawful privacy breach is high. Furthermore, there is a risk that the collected data may be used for other purposes mandated by national laws.

The "eCall" system used in vehicles across the EU which automatically makes a free 112 emergency call if your vehicle is involved in a serious road accident avoids this tracking by using SIM-less mobile devices to communicate to the PSAP (Public Safety Answering Points). A Road User Charging system should be designed according to the same principles as eCall, not make it mandatory to be online with the mobile network at all times, this would create a lot of traces in the mobile networks.

This invention seeks to provide a novel concept for Road User Charging with focus on privacy and cyber security making it more fit for private cars and small vehicles.

SUMMARY OF THE INVENTION

From a first aspect, the invention provides a system for calculating a fee for a vehicle comprising an on-board unit and a central server; -3 -wherein the on-board unit is located inside the vehicle, and comprises a private memory unit arranged to store data representative of the location history of the vehicle; wherein the on-board unit is arranged to receive road usage tariff data from the central server; wherein the on-board unit is arranged to periodically transmit fee summary data to the central server, the fee summary data being calculated using the data representative of the location history of the vehicle; and wherein the private memory unit is only accessible by using a private decryption key.

Thus it will be seen that, in accordance with embodiments of the invention, the design of the on-board unit protects private data at the same time as it enables the driver to verify their driving history for comparison with an invoice generated by the central system. The design conforms to the principles of General Data Protection Regulation (GDPR) with extreme data minimalization and makes it impossible to use the data for other purposes. The current view from national data protection authorities is that strong privacy is a key success factor to RUC for private cars.

In a set of embodiments, the central server is arranged to use the fee summary data to charge a fee to a user associated with the vehicle.

In a set of embodiments, the data representative of the location history of the vehicle comprises tuples of data, each tuple comprising a coordinate location of the vehicle and a corresponding time-stamp.

In a set of embodiments, the on-board unit comprises a hardware security module.

In a set of embodiments, the system comprises a road-side unit, wherein the road-side unit is arranged to communicate with the on-board-unit to determine the status of the on-board-unit. In a set of embodiments, the private memory unit is arranged to record evidence of the communication exchange with the road-side unit.

In a set of embodiments, the road-side unit is arranged to determine if the on-board unit is malfunctioning, and if the unit is determined to be malfunctioning, the road-side -4 -unit is arranged to store data comprising the nature of the problem and an identifier of the on-board unit, and transmit said data to the central system.

In a set of embodiments, the road-side unit it arranged to detect and identify the vehicle. The road-side unit may comprise a receiver arranged to receive data transmissions from the on-board unit of a vehicle and may comprise a camera arranged to capture an image of said vehicle.

Features of any aspect or embodiment described herein may, wherever appropriate, be applied to any other aspect or embodiment described herein. Where reference is made to different embodiments or sets of embodiments, it should be understood that these are not necessarily distinct but may overlap.

BRIEF DESCRIPTION OF THE DRAWINGS

Certain preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows privacy as a function of the entity responsible for fee calculation; Figure 2 shows the CEN/ISO model for Road User Charging in accordance with ISO 17573 EFC Architecture with fee calculation options; Figure 3 shows the main components of the GeoFlow system proposed in accordance with the invention; Figure 4 shows the fee calculation process which takes place in the on-board unit in accordance with the invention.

DETAILED DESCRIPTION

Privacy Current distance-based schemes in Europe for heavy goods vehicles are less concerned about privacy. It is not a primary objective when addressing the truck fleet.

Trucks are typically a work-environment and privacy is different in an employer/employee relation. For distance-based tolling (RUC) to be acceptable to the general public, privacy must be addressed. The approach described herein seeks to avoid creating a system which makes citizens feel like they are being watched by the state. Our approach is the "thick client" model, where position/time data does not leave -5 -the vehicle at all. The personally identifiable information (PII) is protected by signatures and encryption such that the driver/owner has 100% control of the data. This is a very radical approach compared with HGV tolling.

Cyber security The security measures in CEN DSRC tolling (as it is known in Europe) are limited by the small bandwidth available on the radio link. Trust and security are based on bi-lateral agreements between Toll Service Providers (TSP) and Toll Chargers (TC) implementing symmetrical key exchange without any common trust anchor. This creates problems for cross-border trust relations and the trust web is increasingly difficult to manage as the number of connected TSP and TC grows. In the GeoFlow pilot implemented in accordance with the invention described herein, we will abandon the established CEN DSRC security model and replace it with modern cryptosystem based on Cooperative Intelligent Transport Systems (C-ITS) with role-based security using certificates secured by Elliptic Curve Digital Signatures and strong encryption. All of this using state-of-the-art procedures and best practice recommended by security experts. The European Commission has already established a top-level Public Key Infrastructure (PKI) root and is managing certificates and key distribution based on the C-ITS Security Policy. The pilot will use this PKI. In this way, the trust of devices, infrastructure, toll context data, etc. are connected to the common EU top-level trust anchor and there is no need for bi-lateral key exchange.

Tolling scheme The Norwegian GeoFlow pilot implemented in accordance with the invention described herein will use a simple zone-based scheme where the fee is larger in city centres and low in rural areas. This removes the need for map matching and reduces the implementation cost. There are no unique fees for specific roads. The scheme may be combined with virtual gantries to allow extra payment (on top of the km fee) for accessing e.g. a bridge or a specific motorway section. City congestion zones can also be applied. The tariffs may vary with time-of-day and other factors decided by the authorities. Tariff information and zone information comprises geographic boundaries of the zones, are published with version information such that all actors and components in the system can unambiguously assess the correctness and validity at any time. The thick client architecture allows for any tolling scheme. -6 -

General Data Protection Regulation The EU General Data Protection Regulation went into effect on May 25, 2018. It requires organizations everywhere to comply with European law if they collect data related to people in Europe. The GDPR also clarifies that position information is private data and that it is relatively easy to link a drive track to a person. GDPR sets out seven key principles: Lawfulness, fairness and transparency * Purpose limitation Data minimisation Accuracy Storage limitation Integrity and confidentiality * Accountability The GeoFlow pilot implemented in accordance with the invention described herein tries to address all these items with the thick client approach.

Thin client vs thick client There is no strict definition of these terms and variations exists. Most GNSS-based tolling system implemented for truck tolling today are using the thin client design. Table 1 below compares the difference in operation of the server and the on-board equipment (OBE) in thin clients and thick clients.

Table 1: Thin and thick clients compared Thin client Thick client Position and timestamp processing In a central server, multiple entities. In the OBE in the vehicle Position and timestamp storage In a central server, typically through a long chain of data processors. In the OBE in the vehicle Price list and geographical information In a central server Must be up-to-date in each OBE Network usage High volume and frequent Low volume and infrequent Real time cost available to driver No Yes Secondary use of data Possible Impossible -7 -The transmission of data from the OBE to the central systems requires a mobile data modem (3G, LTE, 5G) and when the modem is turned on, it is tracked by the mobile operator and its use is recorded per Data Retention Directive (Directive 2006/24/EC) or similar laws. The thick client can operate autonomously, without network access for prolonged times without network usage thus limiting this side-channel tracking.

Figure 1 shows privacy as a function of the entity responsible for fee calculation. The reduced privacy when going right in the Figure comes from the assumption that when more entities are involved in the data processing, the higher is the risk for information leaks, data breach, and unlawful and lawful information disclosure. Politicians, police, researchers, and other may argue that the data collected in a RUC system may be useful for other purposes after it has been collected. This can be traffic statistics, speed violations, red light violations, accident investigations, crime investigations. The list is almost endless.

Figure 2 shows the CEN/ISO model for Road User Charging in accordance with ISO 17573 EEC Architecture with fee calculation options.

The on-board equipment 100 is arranged to communicate with the Road Side Equipment (RSE) 102. The RSE 102 is also arranged to communicate with a Toll Charger 104, and the Toll Charger 104 and Toll Service Provider 106 are in communication with each other. The Proxy 108 is shown as arranged to communicate with the Toll Service Provider 106, as well as the Trusted third party (TTP) 110 as a possible entity for fee calculation, possibly extended with a pseudonymising entity.

The RSE 102 provides toll declaration information 112 to the Toll Charger 104. This toll declaration information 112 can include video and vehicle measurements determined by the RSE 102 in communication with the OBE 100, for example, The model shows what interfaces that are standardized, as annotated by the CEN, EN and ISO labels. Note that the OBE 100 and OBE/Proxy interface are not covered by any standard. -8 -

The GeoFlow project, implemented in accordance with the invention described herein, focusses on this area, i.e. the interface between the OBE 100 and the Proxy 108. In the pilot, the Proxy 108 and the Toll Service Provider (TSP) 106 is one entity and the Toll Charger 104 does not exist. In an operational system based on this invention, the TSP ad TC will be separated according to business practice.

GeoFlow and the C-ITS Architecture The main components of the GeoFlow system proposed in accordance with the invention described herein are shown in Figure 3. The system comprises 4 main components (ISO 21217 terms in parenthesis): The on-board equipment 200 (Vehicle ITS station) The road side equipment 202 (Roadside ITS station) The back office 206 (Central ITS station) The human-machine interface (HMI) 224 (Personal ITS station) The OBE 200, RSE 202, and back office 206 are ITS stations, i.e. a bounded secured managed domain as described in ISO 21217. The HMI 224 is typically a smartphone, that with an appropriate app, can be a personal ITS station.

The OBE 200 has a small mounted windscreen device (WSM) 220, which is connected to a dashboard mounted unit (DBM) 222 comprising the main processing unit and storage.

HGVs typically have industrial-type equipment installed in the cab. The focus is not on aesthetics. In a private car, aesthetics is much more important. The GeoFlow unit is a two-piece concept with a small windscreen device (WSM) measuring 3 by 10 centimetres. The DBM may be hidden in the glove compartment or under the seat. Driver safety is also an important aspect. Large devices on suction cup in the window may be a safety hazard to drivers and passengers.

GeoFlow implementation details The GeoFlow project will implement a Thick client. The goal is to maximize privacy and minimize risk for information leaks. Both the designed and implemented privacy is important, but even more important is the perceived privacy as experienced by a user not skilled in cryptographic functions and procedures. -9 -

Figure 4 shows the fee calculation process which takes place in the OBE.

In the GeoFlow thick client all fee calculations 300 are performed in the OBE 200 in the vehicle. Evidence data 302 is stored in a private vault inside the OBE 200. The vault is only accessible locally (near within the OBE 200), when the OBE 200 is switched on and by the vehicle owner/driver. The decryption key for the vault is stored in the smartphone app, protected by a PIN code or password.

When a vehicle owner is using the OBE 200 for the first time, he must choose the secret PIN code, this can later be used to unlock the private vault 304. There is no central storage or other key recovery mechanism for the PIN. If the PIN code is lost, the vault is lost. The ensures that no-one can access the vault 304 without knowing the PIN. This distributed private vault storage scheme makes it virtually impossible to do large scale collection of the data in the private vaults 304.

The invoice log file 306 is stored locally in the OBE 200 during the invoicing period and transferred to the central systems 308, only in summary at the end of each invoice period. The central system 308 will create a financial invoice and collect the payment.

Invoice period can be one week or one month.

The thick client model has a challenge when the customer (driver) wants to file a complaint to the invoice. For a meaningful complaint process, there must be access to the base data, the position data that went into the fee calculation. It must be possible to access this evidence data 302 in a complaint handling process. This is solved with the private vault 304 in the GeoFlow architecture.

The invoice log file 306 contains information to link back to the private vault evidence records to determine what time/position records formed the data for the invoice calculation. The linkage is a hashed timestamp or other identifier without any physical interpretation other than providing a pointer back to the vault. This linking enables a future invoice complaint to be matched to the time period in the vault 304 related to this invoice.

-10 -The private vault 304 and the invoice log file 306 contain information about geographic zone file version and price list version used for the fee calculation 300 enabling auditing and validation. Invoice summary and server receipt (acknowledgement of the successful archiving of the file in the back office) is also stored in the private vault 304.

The private vault 304 contains evidence 302 about driving: position and time. It can be opened only by the vehicle owner when they enter their private PIN code into a smartphone application that in turn communicates with the OBE over Wi-FiE using TLS 1.3 and ISO 21177. Private vault 304 is a write-only service, as seen from the OBE 200. It can only be decrypted by the smartphone, at the smartphone, after presenting the PIN. No software on the OBE 200 can decipher information in the vault 304 because the encrypted private key is only stored in the smartphone. The corresponding public key is known by the OBU and used when writing to the vault.

Vault requirements: * Confidentiality -the evidence data is encrypted and only available to the holder of the PIN code.

Integrity -The evidence data has not been tampered with.

Non-repudiation -the evidence data was recorded by one specific OBE linked to the specific account.

* Availability -The evidence data in only accessible locally. It is by design lost if the PIN code is lost.

This remaining part of this section describes briefly the security functions and procedure for the vault.

One private/public key pair is used for encryption. The Elliptic Curve Digital Signature Algorithm (ECDSA) key pair is generated on the smartphone and private key is encrypted and stored on the smartphone using a key derived from the password code chosen by the vehicle owner for safe storage. The password is stored nowhere.

The public key is sent to the OBE 200 and stored there.

* One private/public key pair is used for signing. This is a Cooperative Intelligent Transport Systems (C-ITS) certificate. The private key remains in OBE 200 (HSM) and is used for signing the encrypted messages. The format of the signed records is compatible with IEEE 1609.2.

The vault 304 stores blocks (or batches) of evidential data. Each block is encrypted and signed individually.

Each block has a hash value that is an identifier of this block in addition to a sequence number. The invoice also has a hash value and links the invoice to a batch of vault blocks. This is needed for data retention and evidence readout. The linked hashes enabled detection of inserted or removed records.

* Blocks are retained in the vault 304 for some specified time period. Blocks are stored in the file system on the OBE 200.

* Current block is kept in memory and not encrypted, when end of the block is reached (number of entries, time, distance, or cost criteria), the invoice is calculated, and the block is encrypted, signed and added to the vault 304. A new block is started.

* The private vault 304 can be read (decrypted) only if two cryptographical assets are known: The vault password (known by the user) and the encrypted private certificate (stored in the smartphone). The vault password and the private certificate may be backed up in various ways.

Certificate and key management Certificate are issued by a Certificate Authority CA compatible with the European C-ITS security policy. This policy does not currently cover the tolling (road user charging) application, but can easily be extended. The project will propose communication standards and security profile in line with the current set of ITS applications supported by the policy. Applicable standards and policies: EU C-ITS security credential management system (EU CCMS) Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport Systems (C-ITS) C-ITS Point of Contact (CPOC) Protocol EIS! TS 102 941 Intelligent Transport Systems (ITS); Security; Trust and Privacy Management The Hardware Security Module (HMS) is located inside the On-Board equipment 200.

The data exchange between CA and OBE 200 are designed so that private keys are accessible only to the HSM. Communication between the host processor (inside DBM 222) and HSM is protected with encryption. Tampering with the HSM will lock down the HSM and render it permanently unusable and inaccessible.

-12 -When an OBE 200 passes an RSE 102 on the road, typically an enforcement gantry, the RSE 102 will ask OBE 200 for its status. This is described in ISO TS 12813, the CCC process. This process is typically combined with cameras to ensure that all passing vehicles has a functional OBE 200 that can reply to the CCC request. The CCC reply contains some information about the OBE 200. If there are malfunctioning OBE 200, this is flagged in the central system 308 for manual processing. A CCC process will be recorded in the private vault 304. It is not visible in the invoice log file 306.

A successful CCC process is not recorded in the RSE 102 or central system 308, possibly only stored temporary and removed after a very short retention time (a few seconds). A CCC process with problems is stored and forwarded to the central system 308 for further investigation.

In an enforcement system, the primary task is to identify vehicles that have no functional OBE 200 present or vehicles that otherwise have a non-compliant behaviour (swapping OBE to another vehicle, missing payments, GNSS jamming/spoofing, etc). The process has multiple steps: * Vehicle detection. This can be based on magnetic loop detectors, laser scanners, radar, lidar, or cameras.

* Vehicle classification. This can be based on length and height measurement from laser scanners.

* Identification. License plates must be read and information about vehicle class and size/length must be retrieved.

Communication with the OBE using C-ITS communications protocols.

Matching of vehicles from cameras to the radio communication. This process must ensure that the vehicle in the camera is the same as the vehicle identified from radio communication. With a C-ITS based RUC, this process is made simpler with the CAM messages. See ETSI TR 103 579.

It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but is not limited to these embodiments; many variations and modifications are possible, within the scope of the accompanying claims.

Claims (10)

1. -13 -CLAIMS 1. A system for calculating a fee for a vehicle comprising an on-board unit and a central server; wherein the on-board unit is located inside the vehicle, and comprises a private memory unit arranged to store data representative of the location history of the vehicle; wherein the on-board unit is arranged to receive road usage tariff data from the central server; wherein the on-board unit is arranged to periodically transmit fee summary data to the central server, the fee summary data being calculated using the data representative of the location history of the vehicle and the tariff; and wherein the private memory unit is only accessible by using a private decryption key.
2. 2. The system of claim 1, wherein the central server is arranged to use the fee summary data to charge a fee to a user associated with the vehicle.
3. 3. The system of claim 1 or 2, wherein the data representative of the location history of the vehicle comprises tuples of data, each tuple comprising a coordinate location of the vehicle and a corresponding time-stamp.
4. 4. The system of any preceding claim, wherein the on-board unit comprises a hardware security module.
5. 5. The system of any preceding claim, wherein the system comprises a road-side unit, wherein the road-side unit is arranged to communicate with the on-board-unit to determine the status of the on-board-unit.
6. 6. The system of claim 5, wherein the private memory unit is arranged to record evidence of the communication exchange with the road-side unit.
7. 7. The system of claims 5 or 6, wherein the road-side unit is arranged to determine if the on-board unit is malfunctioning, and if the unit is determined to be malfunctioning, the road-side unit is arranged to store data comprising the nature of -14 -the problem and an identifier of the on-board unit, and transmit said data to the central system.
8. 8. The system of any of claims 5 to 7, wherein the road-side unit it arranged to detect and identify the vehicle.
9. 9. The system of any of claims 5 to 8, wherein the road-side unit comprises a receiver arranged to receive data transmissions from the on-board unit of a vehicle.
10. 10. The system of any of claims 5 to 8, wherein the road-side unit comprises a camera arranged to capture an image of said vehicle.