August 5, 2014 at 11:44

Business architecture of car charging systems using satellite navigation data


    The Breton Bonnets Rouges harness the Ecotaxe control portals. Photo by Europe1.fr More than a year has passed

    since the last publication on charging systems using satellite geolocation. During this time, much has changed, and has changed conceptually. New industry standards have been released, the business logic of organizing the collection of fees has changed. This often happens in new areas. Therefore, before continuing the story about the technical nuances, I would like to briefly talk about the new business model and the prerequisites for its appearance.

    Historical reference


    In Europe, there are currently only three fully functional GPS charging systems - in Germany ( TollCollect ), Slovakia ( SkyToll ) and Hungary ( Hu-Go ).

    The German system is the oldest, commissioned in 2005 with a significant lag behind the schedule. The system collects data over 40,000 km. roads with 1.5 million on-board devices mounted on trucks. Now the system is expanding to cover roads and other types of vehicles. By the way, it’s just the users of the on-board devices that give 90% of the profit, although the rules provide for the declarative nature of travel without on-board equipment (electronic ticket).

    The Slovak system was commissioned in 2010 and provides data collection over 2500 km. roads with 232,000 airborne devices (trucks over 3.5 tons). Last October, electronic tickets were canceled, and now each truck must travel in Slovakia with the on-board device turned on, which can be obtained free of charge at the border or at one of the service points. Now the system is also expanding in terms of the number of roads.

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

    To monitor the implementation of the rules for charging on roads in special places, control portals were installed, in Germany there were 300, in Slovakia 46 or so, and in Hungary in the region of 25. In order to introduce a factor of surprise, mobile analogues of control portals are also moving along the roads - specially equipped vans, somewhere for one for every 2-3 stationary supports, and in the Slovak van there is a local traffic cop with a gun that takes a penalty on the spot.

    A similar in scope project to create a system for collecting environmental tax from trucks was conceived in France. But at the implementation stage in August last year, indignant truck drivers from Brittany in funny hats stepped onto the roads and set about burning and dumping expensive roadside equipment. The French government shrugged and froze the project for a year. Now the project has been uncovered again, but in a cut volume on a limited number of roads (the southern regions, of course, are excluded from the volumes).

    As for Russia, here Rosavtodor also announced a competition to create a system ideologically similar to the Slovak one. At the time of this writing, the fate of the contest was very foggy.. But one thing is clear - a similar system in Russia will appear 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 a correct technical view of approaches to solving automation problems of this class. By “correct” it is proposed to understand the view based on the modern understanding of the architecture and functions of the components of the charging system, fixed in European standards.

    Let's work on architecture


    We begin by identifying the roles of participants in the collection processes. I must say right away that the processes of determining roles have been settled in the EU for the past fifteen years, and the analysis of fluctuations in analytical thought in this direction is worthy of a separate post. Having stepped on a lot of rakes and breaking a hundred copies in the negotiation battles, the technical community has developed a simple and understandable role model that meets modern requirements. It may sound ridiculous, but Europe currently has in the sphere of toll systems an exemplary example of patchwork automation multiplied by feudal disunity, which in turn is multiplied by a superposition of interests of business, government agencies and road users.

    Therefore, it is not surprising that attempts to introduce a single system, within which the user could travel all over Europe with one on-board device, have so far failed consecutively. Brussels regularly allocates substantial money to solve the problem of interoperability, for which they conduct endless pilot projects, write tons of paper, and things are still there. Only this year, 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 - directing by introducing what it was not possible to introduce voluntarily - the very standards of information exchange between all participants of the wash business.

    The roles in the latest versions of the standards are defined at the level of functions:

    • Toll Charging (TC) - the role of the “owner of the road”, the organization that built the road or got the road to management and intends to tear money from cars passing along the road.
    • Toll Service Provisioning (TSP) is the role of directly providing fee collection services using automation tools.

    There is one caveat (connoisseurs of billing systems do not let lie). In the west, the owner of an asset (road) very often performs the functions of direct tariff calculation. That is, something like this happens between TC and TSP:

    TSP: Look, here the user traveled 150 kilometers on a toll road, here is the data for
    TC billing : OK, everything seems to be right. (The sound of the cash register). Take 5 euros from him, here are the details for the account.
    TSP: Hey user, drive the money for the fare, here's an account from the owner of the road

    Western people stubbornly distribute 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 are very fond of combining the functions of working with contracts, payments, and even with subscriber equipment under the name “billing”. Because the billing operator traditionally serves users and calculates the tariff, and it does not need to logically separate these functions. In principle, this is not a problem, since combining entities is easier than separating them.

    But for real design general philosophical definitions are not enough. It is necessary to take into account both our local specificity and the way of thinking of our specialists. There is an objective reality that you can safely rely on when designing architecture - the technological chain of processing satellite positioning data to turn it into money. Here is a picture that I torn 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 takes place in the on-board 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 take data on-board computer. For charging purposes, drivers usually install a control unit for themselves (except Germany, where an authorized center does this). Therefore, no complicated manipulations are provided during installation - it stuck to the windshield, stuck it in the cigarette lighter and drove off.

    Data from the control unit enters the front-end system, the main task of which is the transformation of coordinate sequences into certificates on the use of segments of toll roads (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 Germany the primary processing of tracks takes place directly in the control unit (the so-called “smart control unit”). Modern architectures gravitate more to the use of light control units that send 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 a track, or the data came in incorrect, 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 on separate KPIs.

    Usage data is simplified by identifiers of segments associated with a vehicle identifier. They are processed in a billing system similar to 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 by time, car class, etc.

    The following picture shows the European standards used at each of the stages of information processing that you can rely on when designing an SVP.


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

    As you can see, only the central, technological part of the chain is standardized. The format of the data coming from the control unit to the front-end system is not standardized. In Europe, traditionally, this part has been left to the 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 remains to be done.

    A little in essence.

    • Charge Report - a data structure in a standard format, transmitted from the front end, containing information about the used road segments and related information.
    • Toll Declaration - a regularly generated TSP document of the established type based on the Charge Report, containing the information TC needs to calculate the amount of the tariff. The element of the official document flow between TSP and TC (not typical for the Russian Federation). In Western business schemes, often the tariff calculation function is performed directly at the TC level. TSP prepares data for calculating the tariff, on the basis of which TC calculates the tariff amount, and then returns it in the form of an official TSP document, which on the basis of this invoices the user.
    • Billing Detail - a data set that is necessary and sufficient to determine the amount of the bill on the TC side.
    • Payment Claim is a regularly generated document based on the Billing Detail 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 allowed us to develop and apply standards for measuring business KPI of the entire charging process, both end-to-end and for each step separately (see ISO 17444).

    Around the basic charging process, the overall SVP architecture, described in ISO 17573, is built. When I tried to land the theory in our local reality, I got the following picture:


    Information interaction scheme of the charging participants

    I divided the Provision level directly into TSP = “SVP Operator” and into a separate role, “Provider of information collection services BU”. The separation is fundamental, since it seems logical to me to separate the functions of user service (personal data!) And the functions of collecting telematics BU. Moreover, there may be many suppliers of used equipment. In Hungary, for example, there are about 20 suppliers of control units, 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.

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

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

    The role “Traffic information collection service provider” includes the functions of the direct operation of control portals. My country is wide, my home, a lot of portals are needed for it, and they will be installed on all the main roads. It is difficult to service all this economy from the center, therefore it is logical to single out these functions in the hotel role, which can be performed by several companies across the country. They will be supplied with parsing data in a single format.

    That's all for today. I will not declare the topic of the following material, since the last time after such a statement more than a year has passed. Better listen to your opinion on this matter, dear hawkers. This topic is new, so any idea can find its embodiment. Once again I ask - let's not delve into the social and political sphere. I personally am for world peace, free autobahns without traffic jams and without speed limits :)
    Tags:

    Also popular now: