FAQ

The costs of a toll system do not only depend on how many vehicles are required to pay toll and on the size and complexity of the toll road network. It also depends on the complexity of the system you are looking at. That means it depends on system and service components which are included in the toll system e.g. automatic recognition, booking/ticketing system, enforcement/control equipment, etc.). Costs also increase with the level of requirements such as system accuracy and availability. The toll system which was established in Germany can serve as an example for a system that consists of a number of components. In addition to automatic toll collection with a GNSS/CN OBU, there is also equipment for posting systems available which is designed in such a way that it can function as a fallback system and manage any posting loads that are generated as a result of all TRUCK journeys, if the automatic system is not available. All components for controlling proper toll payment, i.e., automatic control points, stationary control equipment and technical equipment of the mobile control vehicles and operating control are also part of the scope of the German toll system. As well as the technical and workstation equipment which the customer requires to prosecute toll cheaters, to monitor the work of toll operators and also for the legally prescribed storage of toll data. With a network spanning roughly 12,000 km, the system currently includes the largest number of toll roads worldwide with just a single road operator.

As a result of the built-in modules and the scope of functions, OBUs for satellite-based toll collection are more expensive than OBUs with microwave-based toll collection. However, in most cases there is no need for a road infrastructure with collection beacons, and the toll road network can be flexibly and quickly expanded at any time. The microwave-based OBU merely responds to the signals received from the toll bridge and therefore relies on a road infrastructure which is the key cost driver in DSRC systems. There are different approaches for satellite-based toll collection on the basis of an on-board unit (OBU). In principle, two vehicle variants for satellite-based toll collection can be distinguished. Both variants may have slightly different characteristics, depending on the provider and the local requirements. The OBUs of all alternatives comprise subcomponents (modules for GPS, mobile communication, computer, memory, etc.), which are produced in large quantities and also for other applications in order to optimize costs. The price for an OBU is currently mainly determined by the sum of the costs of the individual components. Only if the number of countries and people using the combination of these technologies increases, will the OBU price fall beyond the price development of the individual components as a result of the integration of functions on dedicated chips. The complete alternative, the “Smart client OBU” or “Thick client OBU” offers the largest scope of functions. This device has a programmed digital toll route map, a rate model, a display and various other modules. Only data relating to the use of toll roads is collected. This type of OBU informs the user directly about the toll payable but can be designed to be interoperable and used for value added services. A “Smart client” offers the highest degree of data privacy while providing full local transparency for the user at the same time. The second variant, the “Dumb client” or “Thin client OBU” continuously sends positioning data to data processing center, which determines the use of a toll road and calculates the toll. The user does not receive information from the OBU indicating whether he is driving along a toll road, nor does he find out what charges apply. This can lead to a higher rate of complaints and thus to higher processing efforts. Another disadvantage lies in the inadequate protection of the user’s privacy and in possible violations of data privacy guidelines, since it is possible to determine the vehicle’s movement at any time as well as any data that can be derived from this. This variant achieves very low savings with regard to the OBU hardware (compared to the “Smart client”) but incurs significantly higher communication costs which can become very expensive, in particular when operating in several countries (interoperability, GSM roaming). In between, there are functionally reduced solutions which combine certain characteristics of the “Thick client OBU” and the “Thin client OBU”. One solution variant, for example, includes a digital map and is therefore able to independently determine the toll roads. The toll payable, however, is calculated at data processing center. With this type of OBU, the user can also be directly informed by the OBU that he is using a toll road, but not about the amount of toll payable. In principle, the characteristics of the solution are designed for the local general conditions and requirements which differ between countries.

While – as a matter of principle – it is always necessary and unavoidable for systems with road-based infrastructure and DSRC tags to create a central movement profile of all vehicles required to pay toll, if they are situated on a toll road, only smart GNSS clients are able to ensure full data privacy while producing a maximum level of user transparency at the same time. Privacy protection is a particularly important aspect when it comes to tolls – both from a legal perspective and also with regard to acceptance by the public. A frequently voiced concern is comprehensive and full monitoring of all movements of users as a result of continuous positioning. In the case of the “Smart client OBU”, the toll road network is stored in the local memory of the OBU. The comparison with the actual route taken already takes place in the OBU. As a result, the use of toll roads is already determined in the OBU and the data is passed on to data processing center. The “Smart client OBU” independently also determines the toll incurred. This makes it possible to operate the OBU in such a way that only the amounts incurred, e.g., for a day or a week and their distribution over the rates is passed on to data processing center - i.e., only as an aggregated total similar to an electricity bill. All information about the movement of the vehicle then remains in the OBU where it can be fully viewed or copied by the user (full user transparency). In addition, it is of course possible at all times (if the user agrees), to transfer to data processing center the detailed data of the use of toll roads and to make it available to the user in the shape of an itemized trip document – similar to current telephone bills: only the totals on the summary sheet of a bill or a list of individual calls – and in the case of the toll only the total amounts per vehicle, rate and billing cycle or a list of trips are displayed. For reasons of understandability, Germany has legal provision in place (Motorway Toll Act (Autobahngesetz)) for handing over trip data to the road operator (the Federal Government/Bund). As a rule, every country determines individually whether the trip data may be used in an anonymized/non-anonymized form or with/without the user’s consent for inspection or statistics purposes (e.g., for operational or traffic monitoring reasons). If a “Dumb client OBU” is used, detailed position data is actually transferred continuously from the vehicle to data processing center in order to track the movement in the road network and to be able to calculate the correct toll. Since the “Dumb client” itself is unable to distinguish between toll roads and roads that are toll-free, movements on toll-free roads are also sent to data processing center since only data processing center is able to recognize and filter out the toll roads. As a rule, this system approach always provides data processing center with information which allows for the movement of the vehicle to be tracked by location and time. For data privacy reasons, this procedure in the design shown is not suitable for toll collection.

To start with, the OBU is protected against mechanical tampering by means of tampering sensors. The data saved in the OBU is stored in encrypted format is special, tampering-protected storage areas while data communication with the outside is encrypted and requires authentication. Tampering attempts and extraordinary events such as the power supply being switched off, device faults or failure of GPS supply are saved in a log file and transferred to data processing center where they are evaluated with the help of fraud detection systems. In addition, data processing center evaluates redundant data and carries out extended plausibility checks in order to uncover any tampering attempts. Any manipulation of the GPS signals to that extent that the position the OBU derives from the signals is always next to the real position is extremely costly and has never been observed so far. It is theoretically feasible to block the signals by means of a jammer, both stationary and in relation to vehicles. Longer, vehicle-specific downtimes are recognized by the OBU and reported as a fault to the user as well as to the operator. Stationary faults can be detected by the operator by means of location-sensing evaluations of GPS fault reports which are carried out as standard as part of operational optimization processes. Following this, the authorities responsible are able to take the relevant action (removal, securing of evidence).

Without any additional measures, recognition accuracy depends on the relationship between the size of the structure to be resolved and the GPS resolution. With today’s technology, however, it is easy to push this limit below the scales that are relevant for inner-city areas, as is clearly demonstrated by the convincing functions and quality of the various PNDs (personal navigation devices). Highly exact positioning with processes that are also cost-optimized for the relevant resolution is one of the key qualifications of Satellic. In the future, OBU-based GNSS processes will be offering ways – in inner-city areas, in particular – to collect fees that are in proportion to use. The introduction of city tolls based on satellite OBUs makes economic sense particularly where the platform is also used for other (national) toll schemes.

If OBUs are obligatory, the problem of infrequent users in the form of merely sporadically used domestic vehicles (vintage cars) and vehicles from abroad which enter the country only rarely, affects both system approaches, i.e., both satellite-based as well as the microwave-based toll collection in the same way. A solution for this requires distribution logistics and the necessary “point of sale” channels for issuing and taking back the OBUs incl. billing. When handling temporary customers, handling time plays an important part – also with regard to EU law which regulates access for foreigners that is free from discrimination. To fulfil these requirements, all relevant processes were optimized and automated as much as possible, which achieved a reduction in the existing service duration. Starting with the registration and ending with OBU output and OBU returns handling, the customer processes including billing currently take 5 minutes. A supplementary variant for the obligatory OBU is offered by the declarative posting system (eVignette with short-term validity, possibly graded by roads, zones and times of day). However, the rates in this variant are not identical to the satellite-based recognition system and may have to be higher in order to prevent misuse.

In general, system costs for toll system depend on a number of basic parameters which include the number and fluctuation of vehicles to be equipped with OBUs and the complexity of the rate model (number of sections, measurements of distances, location and/or time-dependent toll collection, city tolls etc. as well as possible combinations of these variants). Costs of satellite-based solutions rather tend to be determined by the quantity of OBUs required, while costs of DSRC solutions depend more on the complexity of the toll road networks (number of sections). In addition, there will be an increasing number of external scaling aspects in the future such as co-use of the OBU in or by interoperable toll systems in other countries. The current development in many countries shows that the volume of toll roads pricing is continually changing and expanded. A satellite-based road-pricing solution is able to perform these changes at short-notice and without the need for any additional investment. Complex rate models such as location and time-dependent distance-based rates require the use of satellite-based solutions anyway. It may therefore also make perfect sense for smaller networks to operate with a satellite-based road-pricing solution.