Business architecture of car toll systems using satellite navigation data

The Breton Bonnets Rouges harness the Ecotaxe system control portals. Photo Europe1.fr

More than a year has passed since the last posting on satellite-based charging systems. During this time, much has changed, and has changed conceptually. New industry standards have been released, the business logic of fee collection has changed. So often happens in new areas. Therefore, before continuing the story about technical nuances, I would like to briefly tell you about the new business model and the prerequisites for its appearance.

History reference

In Europe, there are only three full-fledged charging systems based on GPS data - in Germany ( TollCollect ), in Slovakia ( SkyToll ) and in Hungary ( Hu-Go ).

The German system is the oldest, put into operation in 2005 with a significant backlog. The system collects data for 40,000 km. roads with 1.5 million on-board devices installed on trucks. The system is being expanded to cover roads and other types of transport. By the way, users of on-board devices give 90% of the profits, although the rules also provide for declarative travel without onboard equipment (electronic ticket).
')
The Slovak system was commissioned in 2010 and provides data collection for 2500 km. roads with 232,000 onboard devices (trucks over 3.5 tons). In October last year, e-tickets were abolished, and now every truck must travel around Slovakia with the included on-board device, which can be obtained free of charge at the border or at one of the service points. Now also expanding the coverage of the system by the number of roads.

The Hungarian system in this trinity is the youngest, put into operation last July at 6500 km. selected by the local road. Using the on-board device in Hungary is not necessary, the main means of payment is to buy an “electronic ticket”, and electronic devices are introduced solely for convenience of payment, since their use eliminates the need to pre-plan a route and strictly adhere to it.

To control the implementation of toll rules on the roads, portals of control were established in special places, in Germany there are 300, in Slovakia 46 or so, and in Hungary around 25. In order to introduce a surprise factor along the roads, mobile counterparts of control portals are also being moved - specially equipped vans, one for every 2-3 stationary supports, and a local traffic cop with a pistol who takes the penalty on the spot is present in the Slovak van.

Similar in scope, the project of creating a system for collecting environmental tax on trucks was conceived in France. But at the implementation stage in August last year, outraged truck drivers from Brittany in funny hats came out on the road and began to burn and throw down expensive roadside equipment. The French government shrugged and froze the project for a year. Now the project has again been uncovered, but already in a cut volume on a limited number of roads (the southern regions, of course, are excluded from the volumes).

As for Russia, Rosavtodor also announced a competition to create a system ideologically similar to Slovakia. At the time of this writing, the fate of the competition was very vague . But one thing is clear - a similar system will appear in Russia sooner or later. We will not here (and in the comments, too) discuss the social and economic aspects of the idea of ​​collecting money on the roads as such, but rather try to form the right technical view on approaches to solving automation problems of this class. Under the “right” is proposed to understand the view, based on the modern understanding of the architecture and functions of the components of the charging system, as recorded in European standards.

We work on architecture

We begin by defining the roles of participants in the collection process. I must say right away that the processes of determining roles have been settled in the EU for the last fifteen years, and the analysis of fluctuations of analytical thought in this direction is worthy of a separate post. Stepping on a lot of rakes and breaking a hundred copies in the bargaining battles, the technical community has developed a simple and understandable role model that meets modern needs. No matter how ridiculous it sounds, Europe currently has, in the field of charging systems, an exemplary patchwork automation multiplied by feudal disunity, in turn multiplied by a superposition of the interests of business, government structures and road users.

Therefore, it is not surprising that attempts to introduce a unified system, within which the user could travel across Europe with a single onboard device, have so far failed consistently. Brussels regularly allocates substantial money to solve the problem of interoperability, which is used for endless pilot projects, writing tons of paper, and things are still there. Only this year, the light came to light at the end of the tunnel, the EU profile commission decided to cut the Gordian knot in a very unpleasant way - by introducing what could not be entered voluntarily - those very standards of information exchange between all members of the mytnogo business.

Roles in the latest standards are defined at the feature level:

• Toll Charging (TC) - the role of the “owner of the road”, the organization that built the road or received the road to management and intends to fight money with cars passing on the road.
• Toll Service Provisioning (TSP) - the role of direct provision of toll collection services using automation tools.

There is a caveat here (do not let the experts know the billing systems). In the west, the owner of the asset (road) very often performs the function of directly calculating the tariff. That is, a dialogue like this happens between TC and TSP:

TSP: Look, here the user traveled 150 kilometers along the toll road, here’s the data for charging
TC: OK, everything seems to be right. (The sound of the cash register). Take him 5 euros, here are the data for the account.
TSP: Hey, user, drive money for travel, here's a bill from the owner of the road

Western people stubbornly distribute the billing functionality and CRM functionality across different systems, as the owner of the resource is directly involved in the information processing chain. In Russia, on the contrary, they like to combine under the name “billing”, including the functions of working with contracts, payments, and even subscriber equipment. Because the operator "billing" traditionally serves the users and calculates the tariff, and he does not need to logically separate these functions. In principle, this is not a problem, since it is easier to combine entities than to separate them.

But for the real design of general philosophical definitions is not enough. We need to take into account both our local specifics and the way of thinking of our specialists. There is an objective reality that you can safely rely on when designing an architecture - a technological chain of processing satellite positioning data to turn it into money. Here is a picture that I picked from the wonderful book “Road User Charging and Electronic Toll Collection” ( link to Amazon )


Stages of data processing in SVP based on satellite positioning data

Positioning occurs in the onboard device. In this case, additional information may be collected. Often a three-axis accelerometer is installed in the control unit, less often a gyroscope. Even less often add the ability to connect to the CAN bus of the car to remove data on-board computer. BU for the purposes of charging drivers usually set themselves (except Germany, where it does an authorized center). Therefore, no complicated manipulations are foreseen during the installation - he stuck it on the windshield, stuck it in the cigarette lighter and drove off.

Data from the CU enters the front-end system, the main task of which is to turn the coordinate sequences into evidence of the use of toll road segments (as well as bridges, tunnels, crossings, etc.). Tracks can be attached to the edges of the road graph, as household navigators do, or the decision to use a segment can be made on the basis of the fact that the car passes through a certain area (virtual gateway). It should be noted separately that in Slovakia and in Germany, the primary processing of tracks takes place directly in the control unit (the so-called “smart-control unit”). Modern architectures, on the other hand, are more inclined towards the use of light control systems, sending only coordinates and some service information, and all processing takes place in central systems.

The route analysis function is designed to hide segment detection errors. For example, if we lost the track, or the data came unreliable, then, knowing that the teleport has not yet been invented, you can complete the route by the available points and quietly add the user to the account. Of course, such analytical data have a special mark for billing and are evaluated by individual KPIs.

The usage data is simply the identifiers of the segments associated with the identifier of the car. They are processed in the billing system similar to the data on the use of communication services. In principle, in this part you can safely use the eTom business model. Each segment is associated with a tariff, there are modifiers for time, car class, etc.

The following picture shows the European standards used at each stage of information processing, which can be relied upon when designing SVPs.


The process of processing information about the use of the toll road

As can be seen, only the central, technological part of the chain is standardized. The format of the data from the control unit to the front-end system is not standardized. In Europe, traditionally, this part is given to suppliers of controllers who use their own protocols and often supply a set of controllers and the corresponding front end. I think the standardization of interfaces in this part is yet to be.

A bit of essence.

• Charge Report - a data format in a standard format, transmitted from the front-end, containing information about the used road segments and related information.
• Toll Declaration is a regularly formed TSP document of the established type based on the Charge Report, which contains the information necessary for TC to calculate the amount of the tariff. Element of official document flow between TSP and TC (not typical for the Russian Federation). In Western business schemes, the tariff calculation function is often performed directly at the TC level. The TSP prepares data for calculating the tariff, on the basis of their TC calculates the amount of the tariff, and then returns it in the form of an official TSP document, which on its basis issues an invoice to the user.
• Billing Detail is a data set, necessary and sufficient to determine the amount of the invoice on the TC side.
• Payment Claim is a regularly generated TC based on the Billing Detail document containing the payment amount. Similar to Toll Declaration, only in the opposite direction - from TC to TSP

The interaction between the roles turned out to be quite simple and logical, which made it possible to develop and apply standards for measuring the business KPI of the entire charging process, both end-to-end and for each step separately (see ISO 17444).

The architecture of the SVP as a whole, described in ISO 17573, is built around the basic charging process. When I tried to ground the theory into our local reality, I got the following picture:


The scheme of information interaction of participants in the process of charging

I divided the Provision level directly into TSP = "SVP Operator" and into a separate role "Provider of information gathering services for information management systems". The separation is of fundamental nature, since it seems to me logical to separate the functions of user services (personal data!) And the functions of collecting telematics of controllers. Moreover, there may be a lot of suppliers of controllers. In the same Hungary, for example, there are about 20 suppliers of accounting systems, each of which has its own data processing system. All of them generate standardized usage reports (Toll Declaration), which are already processed in a single state system.

Charging level is represented by three roles. The toll road operator is TC (Toll Charger). In Russia, the TC functions in the SVP are reduced to financial control, the formation of charging rules and the direct control of their execution.

The function of analyzing control data has been relegated to a separate role “Operator of the payment control system”. If TC wishes, he can create a violation analysis department himself, but often this function is entrusted to a separate specialized company that collects photo and video fixation data from the control framework, verifies unrecognized numbers and generates debt collection documents.

The role of the “Traffic Information Collection Service Provider” includes the functions of the direct operation of control portals. My country is wide, there are a lot of portals for it, and they will be installed along all the main roads. It is difficult to serve all this economy from the center, therefore it is logical to single out these functions into a hotel role that can be performed by several companies throughout the country. They will deliver data for analysis in a uniform format.

Today I have everything. I will not declare the topic of the following material, since the last time after such a statement more than a year has passed. I would rather hear your opinion on this matter, dear habrazhiteli. This topic is new, so any idea can find its embodiment. Just ask again - let's not delve into the social and political sphere. I myself personally for world peace, free autobahns without traffic jams and without speed limits :)