Satellite navigation based charging systems. Part 1

    Today, we are planning a tour to the cutting edge of practical technologies for collecting tolls on roads based on satellite navigation. Despite the apparent simplicity of the question, for a real understanding of this topic from the perspective of system architecture, it is necessary to understand a number of conceptual provisions. Most of them were developed by the international community by walking on a technical rake, including both unsuccessful "pilots" and failed "adult" projects with multi-million budgets. Some projects failed for political reasons, but in each failure, no matter where the last fatal blow came from, there is a fair amount of technical errors. And we, colleagues, are well aware that honest information about an error is worth ten success reports.

    The essence of the technology is to collect information about the movement of vehicles using specialized on-board devices, analyze this information and calculate fares for toll roads.

    Often, for the purpose of monitoring the charging process on the road, special equipment is installed - a stationary monitoring system (CCK), technically identical to the MLFF equipment described in the previous article .

    Roles of participants in the fee collection process and the main business processes of the SVP

    The Western function-oriented approach, which I described in detail earlier , requires starting the design of the system architecture from basic business processes, from which we smoothly move to functions, and from functions to technical solutions.

    The generalization of experience and analysis of existing projects led to the emergence of a number of business models that somehow describe the relationships of all participants. In this article I propose to limit myself to European experience.

    The CESARE model , developed by ASECAP (community of toll road operators and manufacturers of equipment for them) with the assistance of the European Union, is designed to develop and implement common approaches to collecting fees for all participants in the toll highway market.

    Alternative Model "GNSS enabled Services Convergence (GSC) is being promoted by a number of the largest participants in the European hardware and software market with the active assistance of the European Union and is designed to develop common architectural approaches in building fee collection systems based on GNSS and EGNOS (the European system for improving GPS accuracy).

    Roles in CESARE models The CESARE

    model has three main roles:

    • User (Service User) - vehicle owner registered in the SVP.
    • Operator SVP (Toll Charger) - is responsible for the implementation of correct settlements with users.
    • Service Provider (Service Provider) - is responsible for the information and technical support of the Operator through one or more Service Level Agreements (SLAs).

    There is also a fourth role in the diagram - the Interoperability Manager , which provides technological compatibility of various SVPs, as well as provides clearing services for settlements between operators. This role is typical for Europe, where SVPs developed in parallel, and the issue of integration has long been very serious. I really hope that we can avoid the need to create such complex circuits.

    The SVP provider is the owner of the Platform - a hardware-software complex that is a means of implementing services.

    The Provider also implements a number of business processes that can be divided into three types:

    1. Commercial processes- contact with the user, billing, logistics of on-board devices, etc. In general, the business process model of the commercial unit is very similar to the telecom eTOM. But I, nevertheless, would not advise to borrow this model directly. For the needs of the SVP, it is too redundant and at the same time does not take into account a number of the most important nuances (which can be discussed a lot and separately). When an order for SVP falls on our brother-integrator, then his specialists (usually savvy in telecoms) immediately take the eTOM model and automation tools from related projects (some kind of billing from a gentleman’s shoulder, or, even worse, a boxed monster from a major vendor). To bring in a project to a nearby customer and cut the budget, this is quite a ride. But if you need to honestly build a working business, forget about telecom! This experience will certainly come in handy
    2. Operational (technological) processes - collection and verification of information about the use of toll roads, tariff calculation, fraud control, etc. business-specific processes. We will dwell on them in detail below.
    3. Technical operation processes that are common to any IT economy: a block of “classic” ITSM processes, including routine maintenance management, a number of specific processes to ensure the safety of repair work on the road, etc.

    A little bit about on-board devices

    On-board device used in Slovakia

    The basis for invoicing the user is the established fact of using a toll road (or its element). A similar function in telecom is performed by the prebilling module, which collects heterogeneous information about the use of communication equipment.

    Information on the use of roads is provided by on-board devices installed on cars. Until recently, these were separate “boxes” attached to the windshield of a car; now they have begun to seriously talk about using conventional smartphones with navigation and a corresponding application as the control unit.

    Algorithms for calculating the fact of use are different. For instance:

    • The car drove a certain number of kilometers on paid segments - an invoice is issued for the distance traveled.
    • The car drove more than half of the toll segment - a toll road segment is billed.
    • The car drove through the selected area on the paid segment (control point) - the entire segment is billed.
    • The car drove through two areas - the "entry" and "exit". The invoice is issued as a ride on a classic closed section of a toll road.

    The data source for calculating the fact of use is the GPS or GLONASS coordinates.

    If the control unit transmits these coordinates through the cellular network to the central system, where the facts of use are calculated, then this control unit is called “thin”. It is cheap, but it generates a lot of traffic and is not very suitable for poor cellular coverage.

    If the control unit itself determines the facts of use and transfers to the central system not the coordinates, but, for example, the identifiers of the segments passed, then such a control unit is called “intelligent”. It has increased memory requirements (it is necessary to store the parameters of segments or detection areas), to the processor (it is necessary to process coordinate sequences), but it does not load the channel so much and is capable of working autonomously for a considerable time.

    But the most pleasant bonus of an “intellectual” client is the possibility of offline receiving on the spot through short-wave communication a list of passed segments - the best practical tool to combat rogues, which allows you to let out mobile control groups on the roads or equip DPS outfits with readers.

    The transfer of functions from the central system to the control unit and vice versa allows maneuvering over a wide range and flexibly adjusting to the capabilities and prices of local communication providers, charging rules, local laws on the protection of personal data, etc.

    For example, in Germany, a motorist can continue driving if he is not notified of a low account balance. Therefore, a control unit in Germany can count the balance - together with the segment identifiers, the current tariff table is loaded into its memory.

    On-board device for levying environmental tax on trucks in Germany

    Slovenia has severe laws on the protection of PDs, which include any travel information, so the on-board device there can send to the center only the amount to be debited and some subscriber identifier, no segments, tracks, names and last names!

    The on-board device that was planned to be used in Slovenia. It didn’t go beyond the pilot.

    In France, it is forbidden to transmit coordinates outside toll roads, therefore, despite the fact that they have chosen a model of a “thin” control unit that drives the coordinates for processing to the center, the control road graph is stored in the control unit memory, at the exit from which the coordinate stream is sent to the center here but it stops.

    On-board device for collecting environmental tax in France

    In New Zealand, truck owners must pay an environmental toll on all roads, but they do not always use them, and the state is required to deduct virgin land. Until recently, they used mechanical meters on wheels (hub meters) there, but gradually began to switch to on-board devices, which accurately consider passage on roads and do not consider passage on fields.

    New Zealand. Mechanical hubmeter (advanced model).

    New Zealand. Control unit for replacing a mechanical hubodometer.

    That is, there are many nuances in different countries, as well as architectural solutions.

    In terms of iron, there are also options. Someone makes lightweight and productive devices with programming in C and C ++, someone uses more heavyweight Java - processors. Recently, the influence of integrated solutions on a single chip, such as NXP ATOP, has been intensified when JVM, memory, three processors, a security module, a GSM modem, a GPS receiver and a bunch of interfaces, including car CAN, are squeezed into a tiny case.

    Appearance of the NXP ATOP chip NXP Atop

    architecture ( source )

    The second part of the article will consider a set of standards and general approaches to organizing information exchange between elements of the SVP telematics platform.

    Also popular now: