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 also integrate with additional sensors such gyroscopes, accelerometers or OBD (On-Board Diagnostics) input data to minimize the effect of positioning errors may have in collecting incorrect charges and, 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 the OBUs is sent to a central server that consolidated 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 by other means of communication can also be used such as Wi-Fi, Bluetooth, DSRC. Cellular network communication relies on the 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 achieving better accuracy and making decisions based on the integrity, reliability 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 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 [[Wikipedia:Wide area network|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 requirement that might not be present in vehicle trackers is integrity support that is required 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 will include the time at which the vehicle used those road features.
• Charge Calculation - Determination of the price to be charge to the owner or user of the vehicle.
• Payment - Payment of the charge

Although the main steps described before are mostly common to all EFC applications, the architecture of these systems can differ depending on which part of the system is run on 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 to calculate the PVT (Position, Velocity and Time), combine it with the identification of the vehicle and 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 the Road Usage and send 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 will be a balance 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 and more memory to store context data such as maps and tariff information. Centralized architectures will require more upload bandwidth to send road usage to the central server while decentralized will requires more download bandwidth to update context data. Another relevant factors in the choice of architecture will be privacy and enforcement. These are usually conflicting factors since centralized architectures might raise more privacy concerns while are more easily monitored for fraud and decentralized architectures will be more protective of the user privacy while 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