Tolling

Applications
Title	Tolling
Author(s)	Rui Barradas Pereira.
Level	Basic
Year of Publication	2011

It is foreseen that traditional ways of road tolling will be substituted by solutions based on positioning by means of GNSS. On the other hand there's the need of implement urban tolling that is usually called Congestion Charge Zone (CCZ) with the aim to avoid urban pollution and urban traffic congestion. The use of GNSS for Electronic Tolling Collection (ETC) has many advantages with respect to other technologies as it allows for a flexible and scalable system with minimum specific roadside infrastructure. This translates directly into a simple and cost efficient system. In fact, the interoperability directive 2004/52/EC adopted by EU in 2004 prescribed the development and deployment of a European Electronic Tolling Service (EETS), recommending the GNSS technology as the one to be adopted.

Road and urban tolling based on GNSS implies that the position and trajectory of a vehicle is determined using GNSS in order to decide if the vehicle must be charged or not and to compute the charging value. This must be done along with the determination of an accuracy level and the acquisition/generation of some kind of irrefutable evidences that can prove the amount of applied charges.

Application Architecture

ETC applications are implemented using On Board Units (OBUs) developed for that specific purpose that use GNSS data to compute the charging values. Some OBUs also integrate information from additional sensors - such as gyroscopes, accelerometers or OBD (On-Board Diagnostics) input data - in order to increase accuracy and minimize incorrect charges. In particular, to prevent the charging of vehicles that are not using the road or urban area subject to toll.

The data collected by the OBUs is usually sent to a central server that consolidates the payment information for the users of the system. These systems require a communication channel between the OBU and the central equipment. Cellular network is generally used but other means of communication can also be used such as Wi-Fi, Bluetooth, DSRC. Cellular network communication relies on existing public networks while the other communication methods might require specific road side infrastructures.

These OBUs can rely on Satellite Based Augmentation Systems (SBAS) like EGNOS or WAAS to achieve better accuracy and to make decisions based on the integrity and availability provided by those systems. There are also devices equipped with built-in autonomous algorithms that handle and decrease the effects of local errors, such as non-line-of-sight multipath. These kinds of mechanisms may guarantee an acceptable protection level (PL) for a ETC system, dismissing the use of additional sensors that would add complexity and cost to the systems.

In terms of hardware requirements the devices used for tolling are very similar to vehicle trackers. To support tolling, a device should have GNSS support and have wireless communication abilities either through WANs (e.g. cellular network) or LANs (e.g. Wi-Fi, Bluetooth, DSRC). Some systems can have user interface, although this is not mandatory for tolling applications. The only specific requirement - that might not be present in vehicle trackers - is integrity support, since tolling is a liability critical application. Depending on the architecture and on the pricing complexity, the OBU might have different requirements in terms of processing and storage capabilities.

Tolling Process

The electronic fee collection (EFC) process implemented by this application can be divided in the following steps:

• Position Determination - Determination of the PVT (Position, Velocity and Time) using the GNSS data available that might be combined with other sensor data such as gyroscopes, accelerometers or OBD.
• Road Usage - Determination of the roads features used by the vehicle being tolled. This information includes the time at which the vehicle used those road features.
• Charge Calculation - Determination of the price to be charged to the owner or user of the vehicle.
• Payment - Payment of the charge

Although the main steps described previously are common to all EFC applications, the architecture of these systems can differ depending on which part of the system they are run: in the OBU or in the central system. Some possible approaches are.

• Fully Centralized: In this architecture the OBU is a very light footprint and cost-effective device, with a reduced processing power. Its only task is Position Determination, i.e. to calculate the PVT (Position, Velocity and Time), to combine it with the identification of the vehicle and to transmit the data to the central server. The central server receives the PVT data and is responsible for the remainder of the EFC process (road usage calculation and charge calculation).
• Partially Centralized: The OBU uses the PVT to calculate Road Usage and sends this information to the central server.
• Fully Decentralised: The OBU makes the Charge Calculation step calculating the charge. This architecture might even include the payment in the OBU using electronic purse cards.

The choice of the adequate architecture is a trade-off between the cost of OBU and the operation cost. Centralized architectures can use cheaper OBUs with less memory while decentralised architectures will require more processing power to calculate road usage and the charges, as well as more memory to store context data such as maps and tariff information. Centralized architectures require more upload bandwidth to send road usage information to the central server, whereas decentralized architectures require more download bandwidth to update context data. Other relevant factors in the choice of architecture will be privacy and enforcement. These are usually conflicting factors since centralized architectures might raise privacy concerns since they are more easily monitored for fraud. Conversely, decentralized architectures are more protective of the user privacy, hence more difficult to monitor for fraud.

These applications are considered liability-critical applications.

Application Characterization

Road Features Examples

The goal of this kind of application is having an “error-free” charging computation which will make this application acceptable by institutions and users and with high utility value. Providing integrity of the computed position allows ensuring that vehicles are not charged incorrectly. This is done establishing a threshold value for the position protection level, i.e. if a computed position corresponds to a protection value that exceeds the threshold value that position it will not be used to compute charging values.

From the user point of view tolling application will be working in a transparent way since the user doesn’t have to operate the OBU that are installed on its vehicle. Eventually the user receive a monthly detailed report justifying the charged amount.

GNSS-based tooling relies on the detection of road features that will determine the road usage to be charged. The charge to be applied will be determined from a tariff that combines the road usage with other related information to reach the price to be charged.

The road features that normally are be used for charging are

• Zone - The car is charged when inside (or outside) a geographical zone.
• Corridor - The car is charged when it goes through a geographical corridor or a sequence of corridors. A corridor normally corresponds to a road (although it can correspond to a set of parallel roads). A corridor is usually a rectangle that is crossed by the vehicle longitudinally. Direction might be relevant depend on the charge policy.
• Virtual Gantry - The car is charged when crosses a virtual perpendicular line on the road in the same way as in going through a toll booth. A virtual gantry consists of two quadrilaterals joined by one side. The common side defines the line that when crossed triggers the charge. One of the quadrilaterals signals that the vehicle is entering the gantry and other that is exiting the gantry. To be changed the vehicle needs to cross the entry quadrilateral, the virtual line and the exit quadrilateral in sequence.

Several road features can be combined to make more complex road features.

The identification of this road features are them combined with other information to determine a charge. Some of this information can be:

• Vehicle Characteristics
• Time and Date
• Actual distance run - Determined by the GNSS information.
• Theoretical distance run - Determined from maps based on the features crossed.
• Speed

The concept of road tolling can be used for other similar application such as CO² charging and pay what you drive insurance schemes.

Application Examples

The main tolling applications providers are

• Intelligent Mechatronic Systems: Has developed the DriveSync® product which is a modular vehicle telematics system that uses Global Positioning System (GPS) and cellular technologies to track vehicles.
• GMV: Developed the allroadTM product which is a standalone OBU which guarantees a 99,99% of reliability bellow the established protection level (22 m in open sky environment and 75 m in urban environment).
• Satellic: Developed platform makes it possible to implement flexible road toll solutions based on free-flow-systems.
• Skymeter: Has developed an OBU that is installed along with an LCD display to show the charged tool and some other informations.
• Toll Collect: Has developed and is running the toll billing system for trucks (LKW-MAUT) on German motorways.
• Kapsch TrafficCom: On-board units are read/write devices designed to ensure high data security and integrity with high speed internal processing
• EFKON: The OBU autonomously determines the position of the vehicle, identifies road sections subject to toll according to predefined rules, calculates the charge if required inside the OBU, and transmits the result to the toll centre
• Siemens VDO: A hybrid OBU (on-board unit) in the vehicle manages both microwave and satellite-based toll systems