Satellite navigation toll systems. Part 1
Today we have an excursion on the leading edge of practical technologies for collecting tolls on highways based on satellite navigation. Despite the seeming simplicity of the question, for a true understanding of this topic from the perspective of the system architecture, it is necessary to understand a number of conceptual points. Most of them are developed by the international community by walking on technical rakes, including both unsuccessful “pilots” and failed “adult” projects with multi-million dollar budgets. Some projects failed for political reasons, but in each failure, regardless of where the last fatal blow was struck, there is a fair amount of technical errors. And we, colleagues, are well aware that honest error information is worth ten reports of success. We begin with a brief description of the technology, then in the following sections we turn to information flows and standards, and end with the traditional project gossip.
The essence of the technology is to collect information about the movement of vehicles using specialized on-board devices, analyzing this information and calculating the fare on toll sections of roads.
Often, for the purpose of monitoring the process of charging, special equipment is installed on the road - a stationary control system (SSC), technically identical to the MLFF equipment described in the previous article .
The Western functional-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.
')
Summarizing the experience and analysis of existing projects led to the emergence of a number of business models that in one way or another describe the relationships of all participants. In this article, I propose to limit the European experience.
The CESARE model , being developed by ASECAP (a community of toll road operators and equipment manufacturers for them) with the assistance of the European Union, is designed to develop and implement uniform approaches to collecting fees for all toll motorway market participants.
The 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 for building GNSS and EGNOS-based fee collection systems (the European GPS accuracy improvement system) .
Roles in the CESARE model
The CESARE model assumes three main roles:
The diagram also has a fourth role - Interoperability Manager , which ensures the technological compatibility of different SVPs, as well as provides clearing services for mutual settlements between operators. This role is characteristic of Europe, where the SVP developed in parallel, and the issue of integration has been standing for a long time and extremely seriously. I really hope that we can avoid the need to create such complex schemes.
The SVP provider owns the Platform , a hardware and software complex that is a means of implementing services.
The Provider also implements a number of business processes, which can be divided into three types:
On-board unit used in Slovakia
The basis for invoicing the user is the established fact of using the toll road (or its element). A similar function in the telecom is performed by the pre-billing module, which collects diverse information about the use of communication equipment.
Information about the use of roads is supplied by on-board devices installed on cars. Until recently, these were separate "boxes" attached to the windshield of the car, now they began to seriously talk about using conventional smartphones with navigation and the corresponding application as the CU.
Algorithms for calculating the fact of use are different. For example:
The data source for the calculation of the fact of use are the coordinates of GPS or GLONASS.
If the CU transmits these coordinates through the cellular network to the central system, where the calculation of the facts of use takes place, then this CU is called “thin”. It is cheap, but it generates a lot of traffic and is not very suitable for conditions of poor cellular coverage.
If the CU itself determines the facts of use and transmits to the central system not the coordinates, but, for example, the identifiers of the passed segments, then this CU is called “intellectual”. It has high memory requirements (it is necessary to store the parameters of the segments or detection areas), the processor (it is necessary to process the coordinate sequences), but it does not load the channel so much and is able to work autonomously for a long time.
But the most pleasant bonus of an “intelligent” client is the possibility of offline receiving on-site through a short-wave connection of the list of traversed segments - the best practical tool for dealing with rogues, allowing you to put mobile monitoring teams on the roads or equip readers with DPS outfits.
The transfer of functions from the central system to the CU and back allows maneuvering in wide ranges and flexibly adjusting to the possibilities and prices of local communication providers, to the rules of charging, to 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, the BU in Germany can read the balance - along with the identifiers of the segments, the actual tariff table is loaded into its memory.
On-board device for collecting environmental tax on trucks in Germany
In Slovenia, there are harsh laws on the protection of PD, which include any information about the movement, so the on-board device there can send to the center only the amount to be debited and some subscriber ID, no segments, tracks, names and surnames!
The onboard device that was planned to be used in Slovenia. The pilot did not go further.
In France, it is forbidden to transmit coordinates outside toll roads, so despite the fact that they chose a model of “thin” CU, which drives the coordinates for processing to the center, the count of toll roads is stored in the CU’s memory, at the exit from which sending a stream of coordinates to the center here it stops.
On-board device for environmental tax collection 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 obliged to deduct tolls on virgin soil. Until recently, they used a mechanical counter on wheels (hubodometers) there, but gradually they began to switch to onboard devices that neatly consider traveling on the roads and not counting driving through the fields.
New Zealand. Mechanical Hubometer (advanced model).
New Zealand. Control unit for replacing mechanical handwheel
That is, there are many nuances in different countries, as well as architectural solutions.
In terms of iron, there are also variants of performance. Someone makes light and high-performance devices with C and C ++ programming, someone uses heavier Java processors. Recently, the influence of integrated solutions on a single chip, such as NXP ATOP, has intensified when a 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.
The appearance of the chip NXP ATOP
NXP Atop Architecture ( source )
In the second part of the article, a set of standards and general approaches to the organization of information exchange between elements of the SVP telematics platform will be considered.
The essence of the technology is to collect information about the movement of vehicles using specialized on-board devices, analyzing this information and calculating the fare on toll sections of roads.
Often, for the purpose of monitoring the process of charging, special equipment is installed on the road - a stationary control system (SSC), technically identical to the MLFF equipment described in the previous article .
The roles of participants in the collection process and the main business processes of the MRA
The Western functional-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.
')
Summarizing the experience and analysis of existing projects led to the emergence of a number of business models that in one way or another describe the relationships of all participants. In this article, I propose to limit the European experience.
The CESARE model , being developed by ASECAP (a community of toll road operators and equipment manufacturers for them) with the assistance of the European Union, is designed to develop and implement uniform approaches to collecting fees for all toll motorway market participants.
The 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 for building GNSS and EGNOS-based fee collection systems (the European GPS accuracy improvement system) .
Roles in the CESARE model
The CESARE model assumes three main roles:
- User (Service User) - the owner of the vehicle, registered in the SVP.
- The Toll Charger operator is responsible for the implementation of correct calculations with Users.
- Provider SVP (Service Provider) - is responsible for the information and technical support of the Operator through one or more Service Level Agreements (SLA).
The diagram also has a fourth role - Interoperability Manager , which ensures the technological compatibility of different SVPs, as well as provides clearing services for mutual settlements between operators. This role is characteristic of Europe, where the SVP developed in parallel, and the issue of integration has been standing for a long time and extremely seriously. I really hope that we can avoid the need to create such complex schemes.
The SVP provider owns the Platform , a hardware and software complex that is a means of implementing services.
The Provider also implements a number of business processes, which can be divided into three types:
- Commercial processes - user contact, billing, onboard device logistics, etc. In general, the business unit model of a commercial unit is very similar to the telecom eTOM. But I, nevertheless, would not recommend borrowing this model directly. For the needs of the SVP, it is too redundant and at the same time it does not take into account a number of the most important nuances (about which one can speak a lot and separately). When an order for an SVP falls on our brother-integrator, his specialists (usually telecom-savvy) immediately take the eTOM model and automation equipment from related projects (some kind of billing from the man’s shoulder, or, even worse, boxed monster from a major vendor). For the introduction of the project to a distant customer and cutting the budget, this is quite a ride. But if you need to honestly build a working business, forget about telecom! This experience will undoubtedly be useful for you, but it needs to be significantly enriched for this area.
- Operational (technological) processes - collection and verification of information on the use of toll roads, tariff calculation, fraud control, etc. business specific processes. We will discuss them in detail below.
- Technical operation processes common to any IT industry: a block of “classic” ITSM processes, including the management of maintenance work, a number of specific processes to ensure the safety of road maintenance, etc.
Something about onboard devices
On-board unit used in Slovakia
The basis for invoicing the user is the established fact of using the toll road (or its element). A similar function in the telecom is performed by the pre-billing module, which collects diverse information about the use of communication equipment.
Information about the use of roads is supplied by on-board devices installed on cars. Until recently, these were separate "boxes" attached to the windshield of the car, now they began to seriously talk about using conventional smartphones with navigation and the corresponding application as the CU.
Algorithms for calculating the fact of use are different. For example:
- The car traveled a certain number of kilometers on the paid segments - billed for the distance traveled.
- The car drove more than half of the paid segment - billed for the toll road segment.
- The car drove through the selected area on the paid segment (control point) - billed for the entire segment.
- The car drove through two areas - "entry" and "exit". The bill is billed as a fare on the classic closed section of the toll road.
The data source for the calculation of the fact of use are the coordinates of GPS or GLONASS.
If the CU transmits these coordinates through the cellular network to the central system, where the calculation of the facts of use takes place, then this CU is called “thin”. It is cheap, but it generates a lot of traffic and is not very suitable for conditions of poor cellular coverage.
If the CU itself determines the facts of use and transmits to the central system not the coordinates, but, for example, the identifiers of the passed segments, then this CU is called “intellectual”. It has high memory requirements (it is necessary to store the parameters of the segments or detection areas), the processor (it is necessary to process the coordinate sequences), but it does not load the channel so much and is able to work autonomously for a long time.
But the most pleasant bonus of an “intelligent” client is the possibility of offline receiving on-site through a short-wave connection of the list of traversed segments - the best practical tool for dealing with rogues, allowing you to put mobile monitoring teams on the roads or equip readers with DPS outfits.
The transfer of functions from the central system to the CU and back allows maneuvering in wide ranges and flexibly adjusting to the possibilities and prices of local communication providers, to the rules of charging, to 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, the BU in Germany can read the balance - along with the identifiers of the segments, the actual tariff table is loaded into its memory.
On-board device for collecting environmental tax on trucks in Germany
In Slovenia, there are harsh laws on the protection of PD, which include any information about the movement, so the on-board device there can send to the center only the amount to be debited and some subscriber ID, no segments, tracks, names and surnames!
The onboard device that was planned to be used in Slovenia. The pilot did not go further.
In France, it is forbidden to transmit coordinates outside toll roads, so despite the fact that they chose a model of “thin” CU, which drives the coordinates for processing to the center, the count of toll roads is stored in the CU’s memory, at the exit from which sending a stream of coordinates to the center here it stops.
On-board device for environmental tax collection 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 obliged to deduct tolls on virgin soil. Until recently, they used a mechanical counter on wheels (hubodometers) there, but gradually they began to switch to onboard devices that neatly consider traveling on the roads and not counting driving through the fields.
New Zealand. Mechanical Hubometer (advanced model).
New Zealand. Control unit for replacing mechanical handwheel
That is, there are many nuances in different countries, as well as architectural solutions.
In terms of iron, there are also variants of performance. Someone makes light and high-performance devices with C and C ++ programming, someone uses heavier Java processors. Recently, the influence of integrated solutions on a single chip, such as NXP ATOP, has intensified when a 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.
The appearance of the chip NXP ATOP
NXP Atop Architecture ( source )
In the second part of the article, a set of standards and general approaches to the organization of information exchange between elements of the SVP telematics platform will be considered.
Source: https://habr.com/ru/post/179905/
All Articles