EP1708143A2 - System for processing position and/or toll related data for vehicles - Google Patents

Abstract

An on-board unit (OBU) is mounted in a vehicle to acquire position-related data of the vehicle. A central and stationary back office (BO) processes the position-related data to generate normalized position data. A service unit (16) processes the normalized position data. The on-board unit and back office have interfaces (15) to enable data exchange.

Description

The present invention is in the field of location-related data acquisition and processing in systems generally related to transportation, such as toll systems, toll collection systems, clearing systems, fleet management systems, and the like.

In modern transport and / or traffic systems, it is necessary to determine the current and exact position of a vehicle in order to process this position data. There are basically many possibilities how the position data should be processed. It is possible to use the data for a toll collection system so that the vehicle's traveled distance can be automatically derived to determine which toll roads have been driven. Furthermore, it is possible to deduce what tolls have been incurred.

Starting point of the present invention is the transmission of data from a plurality of mobile devices to a central, stationary instance, the so-called back-office. In order to detect the position-related data of the respective mobile devices, a so-called on-board unit, which is attached to the vehicle, is provided in each case. Basically, the data must be processed by a large number of on-board units. Between the respective on-board unit and the back-office, an air interface is provided, via which the data exchange takes place.

Typically, the on-board units are mobile units mounted on the vehicle, and the back-office is at least one central stationary unit which is advantageously designed so that here main data processing takes place. It is desirable to design the on-board unit as small, simple and inexpensive as a "thin client" with only a minimum of business logic.

In previous systems, the on-board unit has a relatively large business logic and includes a variety of data processing modules. This is disadvantageous in many respects. On the one hand, the on-board units are becoming relatively expensive and, due to their complexity, prone to error, making it difficult to maintain and troubleshoot mobile on-board units. On the other hand, the communication links between the on-board units and the back office are claimed by the high volume of data, especially in cross-border applications (by reloading geodata and applications), which can sometimes lead to bottlenecks and thus errors.

It is therefore an object of the present invention to provide a way by which as much of the processing of position-related data as possible can be carried out in a central unit and with which it is possible to obtain position-related data acquired by a mobile device for a variety of different processing options without having to be transmitted multiple times. In addition, existing systems for processing position-related data are to be simplified and improved.

This object is solved by a system, a method and a device having means according to the attached main claims.

• Erfassen von positions-bezogenen Daten von jeweils einer On-Board-Unit aus einer Vielzahl von On-Board-Units,
• Übertragen der positions-bezogenen Daten an ein zentrales Back-Office über eine Luft-Schnittstelle,
• Einlesen der positions-bezogenen Daten durch das Back-Office,
• Berechnen von normalisierten Positionsdaten aus den eingelesenen positions-bezogenen Daten und
• Weiterleiten der normalisierten Positionsdaten und/oder der positions-bezogenen Daten an zumindest eine Service-Instanz zur Weiterverarbeitung in einem wählbaren Format.

The object is achieved in particular by a method for processing position-related data, with the following method steps:

• Capturing position-related data from one on-board unit each from a plurality of on-board units,
• Transfer the position-related data to a central back-office via an air interface
• Reading the position-related data by the back-office,
• Calculating normalized position data from the read-in position-related data and
• Forwarding the normalized position data and / or the position-related data to at least one service entity for further processing in a selectable format.

An essential core idea of the present invention is to be seen in that the position-related data are not processed directly in the on-board unit, but completely, partially and / or transformed are forwarded to the back-office, and then further processed there centrally to become. This has the advantage that the mobile unit can be designed as a "thin client", which is cheaper to produce, easier to maintain and less error prone.

A second essential aspect of the present invention is that the system can be adapted adaptively to the particular application situation and is thus easily expandable. It is not limited to a specific application. The position-related data acquired by the mobile on-board unit can be sent for further processing in various and varied ways. It is irrelevant whether the further processing is used in the context of a toll system, a fleet management system or a clearing and / or billing system for toll operators. The central storage and processing of the position-related data makes it possible to dynamically generate the normalized position data. This means that the back office can control and execute the transformation or the calculation of the normalized position data so that downstream further processing steps can be simplified and facilitated. The calculation can thus be designed according to the invention on the further processing of the position data.

In an advantageous embodiment of the invention, the calculation of the normalized position data from the read-in, position-related data in the back-office can be configured according to presettable parameters.

In particular, it is possible to generate the normalized position data in a selectable format required by the later processing method. Usually, the further processing is carried out by a plurality of different service instances. The service instances can be designed as part of the back office and on the other hand-in an alternative embodiment-as independent and separate units. A service instance can therefore be a toll service, a billing system within a toll service, which carries out the tariff calculation, etc.

Preferably, the present invention is applied to the toll sector. Usually, the service instances are maintained by different toll operators. In the toll service instance of the back office, the data recorded by the on-board unit are prepared and transmitted according to current requirements and requirements. It is possible to provide the back-office with a geo-object manager and / or with a road-identification interface, so that it can be determined what tolls were incurred for the driven route of the respective vehicle. This is done by comparing the recorded, transmitted and processed position data with data records of a database in which current tariff data are stored for each geo-object, in particular for each route. At this point, a very significant advantage of the solution according to the invention, namely, that the constantly necessary updates (tariffs, new route networks, changes in the toll operator, changes in terms of the satellite-based recording of the position data, etc.) can now be very simplified at a central location , It is no longer necessary to provide the various on-board units with the updated data. Thus, the communication costs can be significantly reduced.

Basically, it is possible to configure the reading of the position-related data within the back-office in different ways: First, the position-related data can be queried in online operation and, second, the position-related data in batch mode according to configurable parameters.

The position-related data that are transmitted from the respective on-board units to the central back-office instance are usually satellite position data records that are received from a corresponding receiver, in particular from a GPS and / or Galileo receivers in which mobile on-board device has been received. In addition, it is possible to transmit satellite raw data, in particular so-called pseudo-range data, vector data or other geo-data sets.

The term "position-related data" in the context of this invention means all satellite-based position-related data in arbitrary formats which have a relation to a position of an object and are preferably in digital form. This includes GPS data, Galileo data, GLONASS data and / or position-related data from other systems. It should be noted at this point that the use of the term "GPS data" in this patent is to be understood as illustrative and not restrictive and includes other satellite based positional data from other systems or systems to be created in the future , GPS data is used because it is currently the most common.

According to the invention, a specific air interface is provided between the respective on-board unit and the back-office, which is formed in particular via at least one mobile radio network. Usually, this is based on a packet-oriented communication technology, such as GPRS and UMTS. Alternatively, however, other communication technologies may be used, especially if the aforementioned technologies are not available, such as e.g. "Dataover Voice (GSM) -BS26". In addition, other transmission technologies and / or other optimized proprietary protocols may be used.

In order to increase the security of the system and to reliably prevent misuse of data, it is envisaged that the data will be transmitted in encrypted form between the respective on-board unit and the back-office. Usually For this purpose, an asynchronous key pair is generated, which comprises a public key and a private key. At this point, the encryption and cryptographic algorithms known in the art, such as PGP, can be used. In addition, another structural safety measure can be provided by the on-board unit is equipped with a housing which is secured by a manipulation switch. Unauthorized opening of the on-board unit can thus be ruled out, since it is ensured that the housing of the on-board unit can only be opened when the device has been returned.

According to the invention, it is possible to reduce the number of data to be transmitted from the on-board unit to the back-office by transmitting the data in compressed form. In addition, it can be set that not all fixes, that is all position determinations of the mobile unit, are transmitted, but only a selection of fixes. However, if it proves necessary in the context of the further processing that more fixes must be available than have been transmitted by the on-board unit, then it is provided according to the invention that additional fixes are inserted under access to an approximation module. In particular, the approximation module accesses at least one approximation method, in particular a spline approximation, which sets the already acquired data in relation to one another and generates the missing data on the basis of an approximation algorithm and thus closes the gaps.

In the preferred embodiment of the invention, it may be set at which times the data is transferred from the on-board unit to the back-office. It is possible to provide configurable time intervals here, which leads to a time-dependent transmission. Cumulatively or alternatively, it is possible to trigger the transmission as soon as a predeterminable threshold value is reached. If the on-board unit is designed, for example, with a buffer memory, then it can be set that the data is transmitted when a capacity of the buffer memory is almost reached. It is also possible that Form on-board unit without buffer storage. In this case, the data can be transmitted after receiving a specific data size.

Typically, the normalized position data calculated by the back office is provided in a configurable format. The format is usually adapted to the requirements of the service instance for further processing. In addition to the Cartesian coordinate system with x, y and z axis, the position data can also be provided in any other format, such as. in the WGS84 format.

Normalization of the data is performed in the back office. The aim of the normalization is to be able to quickly and easily provide the required position data in the desired format, depending on the requirements of the downstream service or the stored calculations of the service instances. The service instances can refine the processed data according to specific requirements. The data transferred from the mobile on-board unit to the back-office is raw satellite data. These are transformed losslessly in the back office into another representation of the data, namely normalized position data. From the normalized position data all desired formats can be calculated.

A significant advantage of the solution according to the invention can be seen in the modularity of the system. This allows the system to be expanded arbitrarily and easily by adding additional service instances via suitable interfaces. As a rule, the service instances are those which are designed to process position-related data.

An on-board unit is each equipped with a receiver intended to receive position-related raw satellite data. Additionally or alternatively, it is possible that the respective on-board units form with an interface for a DSRC system (DSRC - D edicated- S hort- R reasonable ommunication C). A DSRC system is disadvantageously only for short distances, especially those under 8 Meters, and includes a DSRC tag disposed on the mobile unit, and further requires road construction measures, particularly in the form of beacons comprising electronic modules, adapted to the "passing" DSRC tags of the respective ones Register vehicles. The data collected at the beacon is then transmitted to the back office. This system is used today in Austria, for example, in each case a toll section of two boundary beacons is bordered. Advantageously, the solution according to the invention is designed so that it can interact with such DSRC systems. Therefore, the on-board unit according to the invention may be formed with at least one corresponding interface. In this case, the on-board unit according to the invention assumes the function of the normal DSRC tag. Thus, as soon as the DSRC communication is activated, the on-board unit according to the invention prepares and monitors the appropriate DSRC modem (or possibly several modems) for the pending communication. In addition, it is possible according to the invention to operate the on-board unit in a selectable dual mode. The DSRC data acquisition can thus alternatively and cumulatively to the satellite raw data survey via satellite position data (GPS / Galileo) take place. This is particularly useful if a DSRC survey carried out is unsuccessful or faulty and can thus be compensated for using the alternative route. With this feature, the capabilities of the solution according to the invention can be significantly expanded and integrated into existing applications. In addition, error possibilities caused by incorrect data acquisition can be reduced.

The preferred embodiment of the invention includes an activation mechanism that automatically enables / disables, or does not enable / disable, the transfer of position-related data from the on-board unit to the back-office according to adjustable criteria. Usually, the criteria are based on a registered country code or area, in particular an area of an operator of mobile networks and / or toll systems. The background to this feature is that there are countries for which there are none Toll collection or only toll collection for certain types of vehicles. With this feature, it is possible to inhibit or disable the communication between the on-board unit and the back-office until the collection of position-related data makes sense, for example, until a toll system is put into operation in that country has been. This can help to reduce the cost of establishing a connection between the on-board unit and the back-office, which would otherwise be caused by unnecessary sending of position-related data. Alternatively, the activation mechanism may also be based on other criteria (such as time of day intervals when no toll is charged for a particular route).

Each on-board unit can be uniquely identified by the back office. This is done in particular via components of a SIM card and / or a device serial number. This makes it possible to assign position-related data transmitted to the back office automatically and uniquely to an on-board unit. In an alternative embodiment of the invention, several on-board units can also be combined to form a group of on-board units. This may be particularly useful in fleet management systems for a group of vehicles of a logistics company.

If this unique identification number of the on-board unit collides with the operator numbers or is incompatible in the number range, an operator can optionally specify his own number, a so-called virtual ID. This is linked to the unique number of the on-board unit (mapping). If the on-board unit is in the area of this operator, the unique number is transmitted internally and the named virtual ID is transmitted externally to the operator. The processing with the internal ID is encapsulated for the operator, so that - as usual - he can use his proprietary ID. According to the invention, the mapping rule is based on a one-to-one association relation.

For this purpose, a data structure can be generated in which a unique identification number is stored for each on-board unit and / or a virtual identification number Identification number of a service provider is stored, including mapping rules that define a one-to-one relation between the virtual identification number and identification number. If DSRC tags are used, corresponding DSRC virtual tag IDs can be used, which are then mapped to the internal DSRC tag IDs.

The back-office includes a central storage and / or control unit. The respective on-board units are controlled by this control unit of the back-office. The back-office storage unit serves to store the on-board unit position-related data and / or the normalized position data and / or other data records, e.g. status messages or the like. This makes it possible to forward data records (also in the past) to further processing without having to reread these data. It also makes it possible to subject already collected data to error checking and control. Errors can e.g. caused by incorrect acquisition of the satellite raw data. The satellite operators publish such error messages. According to the invention, these can be assigned to the position-related data thus erroneously detected and, overall, correct position data can be derived.

If pseudo-range data is transferred from the on-board unit to the back-office, these data are subject to errors due to the acquisition method. The error is based on the signal transit times between satellite and receiver (ie the on-board unit). In a pseudo-range measurement, the signal transit times are measured in comparison to a receiver clock that is not synchronized with the transmission clocks (the satellite). The "pseudo-ranges" are therefore only apparent distances and result from the product of the respective time and the propagation speed of the signal. This error can be eliminated or eliminated according to the invention by detecting reference position signals from stationary reference stations. For example, four reference stations are used for one area of the Federal Republic of Germany. The reference data acquired by the stationary reference stations are used in the calculation the normalized position data within the back office, in particular the position calculation instance used. In addition, it is possible to connect other known troubleshooting measures to clean up the data sets via corresponding interfaces to the system according to the invention in order to increase the quality of the detected position data.

In an advantageous development of the invention, not pseudo-range data is transmitted from the on-board unit to the back-office, but already satellite position data data. In this embodiment, the position calculation entity may be made much slimmer and is preferably only for reading the respective data. If necessary, this data can be transformed into another format, depending on the requirements of the service instances for the further processing of the data.

In the preferred embodiment of the invention, at least one of the method steps and preferably all method steps are carried out automatically. It is thus possible to carry out the tolling fully automatically, without it being necessary to initiate certain calculations "by hand".

• das automatische Erfassen und Speichern der positions-bezogenen Daten und/oder
• eines der DSRC-Interfaces oder
• keines der beiden.

In operation, the system according to the invention is designed so that, after switching on, the respective on-board unit automatically recognizes its current position. This is usually done via a GPS receiver and / or a Galileo receiver. Depending on the current position and configuration, the on-board unit activates:

• the automatic detection and storage of the position-related data and / or
• one of the DSRC interfaces or
• neither.

Based on the determined current position, it is possible for the on-board unit to automatically and independently decide which operating mode is activated must, and that at any time a change can be made. The operating mode is usually based on the detected country code.

To increase the security of the system, it is intended that every communication between the on-board unit and the back-office be checked for successful authorization. Preferably, a connection service is provided as a link between the back-office and the respective on-board units, which routes the telegrams or packets between the on-board units and the back-office and encrypted and decrypted, the signatures of Generates and checks telegrams and checks the on-board unit for a successful authentication.

A communication service is usually provided by one or more mobile operators in different countries. This component transfers the collected position-related data, any status messages or updates to the back-office. It is also possible to handle the control of the on-board units from the back-office via this communication channel.

• eine Vielzahl von mobilen On-Board-Units, wobei jeweils eine On-Board-Unit einem mobilen Gerät, insbesondere einem Fahrzeug, zugeordnet ist und dazu bestimmt ist, die positions-bezogenen Daten des Fahrzeugs zu erfassen,
• ein zentrales Back-Office, das zur Verarbeitung der von der On-Board-Unit erfassten und übertragenen positions-bezogenen Daten bestimmt ist, und das zumindest eine Positions-Berechnungsinstanz umfasst, die dazu bestimmt ist, die von der On-Board-Unit erfassten Daten einzulesen und aus diesen Daten normalisierte Positionsdaten zu berechnen,
• zumindest eine Service-Instanz, die dazu bestimmt ist, die normalisierten Positionsdaten und/oder die positions-bezogenen Daten weiterzuverarbeiten, wobei die On-Board-Unit und das Back-Office über eine spezifische Schnittstelle in Datenaustausch stehen.

In addition, the object is achieved by a position-related data processing system comprising:

• a plurality of mobile on-board units, wherein in each case an on-board unit is assigned to a mobile device, in particular a vehicle, and is intended to record the position-related data of the vehicle,
• a central back-office dedicated to processing the position-related data acquired and transmitted by the on-board unit and comprising at least one position calculation entity designated to be acquired by the on-board unit Read data and calculate normalized position data from these data,
• at least one service entity, which is intended to process the normalized position data and / or the position-related data, where the on-board unit and the back-office are in communication via a specific interface.

The respective mobile on-board units are designed according to the invention as thin clients, and as far as possible all processing and computing instances are arranged in the back-office or assigned to this. It is possible to integrate the respective calculation instances in the back office. Alternatively, it is possible to provide the above-mentioned instances as separate modular components and to connect them via corresponding interfaces to the back-office.

Moreover, the object of the invention is achieved by a device for processing position-related data, having means designed for carrying out at least one of the aforementioned methods.

The statements made above in relation to the method according to the invention should accordingly also be applied to the device according to the invention and to the system according to the invention.

The above-described embodiments of the method according to the invention can also be embodied as a computer program product, wherein the computer is caused to carry out the method according to the invention described above and whose program code is executed by a processor.

An alternative task solution provides a storage medium which is intended to store the above-described computer-implemented method and is readable by a computer.

In addition, it is possible that individual components of the method described above in a salable unit and the remaining components in another salable unit - so to speak, as a distributed system - can be performed.

Further advantageous embodiments will become apparent from the dependent claims.

Figur 1

eine übersichtsartige Darstellung von Einheiten und möglichen Datenströmen gemäß einer vorteilhaften Ausführungsform der Erfindung,

Figur 2

eine übersichtsartige Darstellung von Einheiten gemäß einer vorteilhaften Weiterbildung der Erfindung,

Figur 3

eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von positions-bezogenen Daten in einem Back-Office,

Figur 4

eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von Satellitenpositionsdaten im Back-Office,

Figur 5

eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von positions-bezogenen Daten über ein Road-Identification-Interface und

Figur 6

eine übersichtsartige Darstellung eines Prozesses für die Datenerhebung in der On-Board-Unit.

In the following detailed description of the figures, non-limiting exemplary embodiments with their features and further advantages will be discussed with reference to the drawing. In this show:

FIG. 1

an overview of units and possible data streams according to an advantageous embodiment of the invention,

FIG. 2

an overview of units according to an advantageous embodiment of the invention,

FIG. 3

an overview of a process for processing position-related data in a back-office,

FIG. 4

an overview of a process for processing satellite position data in the back office,

FIG. 5

an overview of a process for processing position-related data via a road-identification interface and

FIG. 6

an overview of a process for collecting data in the on-board unit.

In connection with FIG. 1, the essential components according to an advantageous embodiment of the invention are explained below:

A mobile on-board unit OBU is mounted on a vehicle. This is usually done by gluing on the windshield or other integration in the vehicle.

The system includes a variety of mobile on-board units OBU and a stationary, central back-office BO. In each case, an on-board unit OBU for detecting position-related data, in particular via a GPS and / or Galileo receiver 10 is designed. The position-related data can be in one Buffer memory 12 are buffered and are then fed to a transmitting unit 14. The transmitting unit 14 serves to transmit position-related data from the on-board unit OBU to the back-office BO. The back office BO is intended for processing, in particular for finishing, the received position-related data. The back office BO comprises a position calculation entity 15, which is intended to transform the received position-related data into normalized position data. This intermediate representation of the normalized position data is used for the simple transformation of the position data into further formats. This is done on the basis of requests that one or more service instances 16 of the position calculation entity 15 report.

Basically, the on-board unit OBU is as compact and simple as possible, while the back-office BO is used for centralized and comprehensive data processing.

The GPS and / or Galileo receiver 10 of the on-board unit OBU is intended to receive raw satellite data. The position-related data received by satellite S are forwarded by the GPS and / or Galileo receiver 10 - possibly via a buffer memory 12 - to the transmitting unit 14 for transmission to the back-office BO.

The back office BO calculates normalized position data from these position-related data - if necessary with access to further modules. The normalized position data may serve as input for further processing by the service instances 16.

The position-related data transmitted from the on-board unit OBU to the back-office BO can be pseudo-range data, GPS or Galileo data and / or vector data. If pseudo-range data is transmitted, the error due to the signal propagation delay in the back-office BO can be eliminated by the back-office BO on at least one Reference stations Ri accesses. The reference stations Ri are arranged stationary and designed for the reception of satellite raw data. The position reference data received from the reference stations Ri is forwarded to the position computing entity 15 of the back office BO. From a difference of the two signal runs an error-free normalized position signal can be tapped. This signal is supplied to the service instances 16 for further processing.

In Fig. 1, the dashed line around the satellites Si is intended to indicate that the respective satellites belong to a satellite operating company. The satellite operators publish data from which errors with respect to the raw satellite data can be derived. In an advantageous development of the invention, the position calculation entity 15 accesses these messages and calculates corrected normalized position data on the basis of these data.

According to the invention, the position calculation entity 15 in the back office BO can be configured such that the normalized position data it generates are generated so that they are designed for further processing by the respective service instances 16. For this purpose, it is necessary for the respective service instances 16 to report their requirements for the position data to the position calculation entity 15. Therefore, in this embodiment of the invention, there is also a data flow that runs from the service instances 16 to the back office BO, in particular to the position calculation entity 15 (this is not shown in FIG. 1, however).

In principle, any number of different service instances 16 can be connected to the system. A service entity 16 can in particular be used for processing the normalized position data for a toll collection system, for billing in a toll collection system or, for example, for clearing in a toll collection system. In addition, it is possible that other further processing methods are performed by service instances 16.

Typically, an on-board unit OBU comprises a housing, a processor, a GPS and / or Galileo receiver 10, a buffer memory 12, a power supply unit, a user interface, an integrated GPS / GSM and / or Galileo / GSM antenna and / or an integrated DSRC antenna, interfaces for further antennas or communication components, a cable set for a network connection via fixed installation and / or cigarette lighter, an operating system and application software and drivers. Optionally, it is possible to additionally design the on-board unit OBU with a flash disc, a GSM interface including SEM holder, LEDs, a crypto chip for encryption and decryption and / or with a connection to a tacho signal. In terms of circuitry, the on-board unit OBU is designed so that only a wiring for the power supply and possibly for the antennas is needed. Optionally, there may be a connection to a speed sensor.

The essential components according to the advantageous embodiment of the invention are explained below with reference to FIG.

As illustrated in FIG. 2, the back office BO communicates with the respective service entity 16, here the toll operators A - C, or with the billing system. It is possible to provide further service instances 16. These may consist of administration / controlling, a call center, a complaint unit, an order and order unit, a software development and deployment unit, a geo-object update provider, a sales unit and a certification unit.

In addition, there may be interfaces to manufacturers of on-board units OBU and / or so-called enforcement instances of service providers. The enforcement authorities serve to protect against manipulation and can trigger countermeasures in the case of an illegal procedure within the toll collection system (eg the corresponding forwarding of data, the taking of a photo, etc.).

In addition to the reference stations Ri, which are assigned to the back office BO, the back office BO comprises an OBU home operator, a connection service and a position interface.

In the preferred embodiment, the back office BO consists of the "standard back office" and the "Europe OBU service", which is intended for processing toll-related item data. This is represented in FIG. 2 by the two sub-boxes of the back-office BO.

In addition, a communication service is provided, which is preferably provided by one or more mobile operator (s). It is, as shown in Figure 2, assigned as an external component of the back-office. The mobile operators can belong to different states. This component transfers the captured position-related data (but also status messages or updates) to the back-office BO.

The connection service is a link between the back office BO and the on-board unit OBU. The task of this component is to route the data packets or telegrams to be transmitted between the on-board units OBU and the back-office BO, to encrypt and decrypt them, to generate and verify their signatures and with help of the OBU home operator to check the validity of the OBU (authentication process).

In a simplest embodiment of the invention, the position calculation entity 15 can consist of the "position interface". This service receives the collected and acquired position-related data based on the GPS and / or Galileo data on the pseudo-range data or vector data, and calculates the normalized position data therefrom. When using pseudo-range data, the position reference data of the reference stations R are additionally accepted. In addition, this service serves to provide the satellite error information provided by the satellite operator and to calculate the normalized position data on the basis of the data received. Thereupon, the position calculation entity 15 stores the data in a database and if necessary informs another component about this data or makes the normalized position data available to further service instances or components.

• Speichern aller gültigen Identifikationen der On-Board-Units OBU, wodurch eine eindeutige Identifikation aller On-Board-Units OBU und eine Authentifizierung derselben möglich wird;
• Speichern von virtuellen OBU-IDs (z.B. DSRC-Tags-lDs).
• Speichern von allgemeinen Konfigurations-Parametern für die On-Board-Units OBU;
• Speichern von Parametern, die für jeweilige Service-Instanzen 16 notwendig sind, z.B. länderabhängige Parameter, Fahrzeugdaten, Datenbereitstellungs-Zyklen (Online, Batch);
• Bereitstellen der notwendigen Schlüsselpaare zur Ver- und Entschlüsselung;
• Speichern aller geräteabhängigen On-Board-Unit-Parameter;
• Senden von Signalen eines Aktivierungs-Mechanismus, insbesondere von Aktivierungs- und Deaktivierungs-SMS.

The OBU Home Operator is a central storage and control unit for all on-board units OBU. This component provides all other components with parameters that depend on the on-board unit OBU. The OBU Home Operator has the following tasks:

• Storing all valid identifications of the on-board units OBU, whereby a unique identification of all on-board units OBU and an authentication of the same is possible;
• Store virtual OBU IDs (eg DSRC tag lDs).
• Storing general configuration parameters for the on-board units OBU;
• Storing parameters necessary for respective service instances 16, eg, country dependent parameters, vehicle data, data provision cycles (online, batch);
• Providing the necessary key pairs for encryption and decryption;
• Storing all device-dependent on-board unit parameters;
• Sending signals of an activation mechanism, in particular of activation and deactivation SMS.

The OBU home operator provides the OBU parameters online.

Normally, the components within the back office BO communicate via a standardized protocol format (see XML telegrams). The communication between on-board unit OBU and connection service is usually based on an optimized proprietary protocol.

• Einen "Geo-Objekt-Manager". Diese Komponente dient dazu, einzelne mautpflichtige Geo-Objekte und deren Parameter (Streckenberechnung, Fixe Länge, Straßentyp, Koordinaten etc.) bereitzustellen. Grundsätzlich kann für jedes Geo-Objekt ein Tarif abgelegt werden.
• Ein "GPS-Position-InterFace". Diese Schnittstelle nimmt entweder auf Anforderung oder im Batch-Betrieb in zyklischen Abständen die verfügbaren positions-bezogenen Daten des Positionsdaten-Interface der On-Board-Unit OBU entgegen und berechnet aus diesen Daten die normalisierten Positions-Daten. Diese Berechnung erfolgt abhängig von den Anforderungen der Service-Instanzen 16. Insbesondere ist es möglich, die Berechnungen in einem speziellen Format bereitzustellen, insbesondere im kartesischen Koordinatensystem oder in dem WGS84-Format. Darüber hinaus ist es möglich, eine Approximation von positions-bezogenen Daten auszuführen. Dies ist insbesondere dann sinnvoll, wenn die Anzahl der Fixes für die Berechnung der jeweiligen Service-Instanz 16 nicht ausreicht und weitere GPS- bzw. Galileo-Fixes notwendig sind, die jedoch nicht erfasst sind. Dann können mit Hilfe dieses Approximations-Verfahrens die Lücken für die fehlenden GPS- bzw Galileo-Fixes nachgebildet werden.
• Eine "Road-Identification-Schnittstelle". Diese Road-Identification-Schnittstelle (nachfolgend kurz RI-Interface genannt) nimmt die Positions-Daten entgegen und bestimmt daraus alle mautpflichtigen Geo-Objekte, z.B. mautpflichtige Abschnitte, Zonen, Strecken-Längen etc. Mit dem RI-Interface ist es möglich, auch virtuelle Baken zu bestimmen, die auch reale Baken nachbilden können. Somit kann auch eine Bemautung bei DSRCbasierten Strecken ausgeführt werden. Insgesamt dient das RI-Interface dazu, die berechneten mautpflichtigen Geo-Objekte bereitzustellen und gegebenenfalls zu speichern.
• Ein Transaktions-System. Das Transaktions-System berechnet auf Basis der mautpflichtigen Geo-Objekte und der Tariftabellen die Mautgebühren für den Zeitpunkt, in dem das Objekt befahren wurde. Zusätzlich können in diesem System Prüfungen durchgeführt werden, die die erfassten Daten auf Korrektheit überprüfen. Hierunter fallen Überprüfungen hinsichtlich der logischen Reihenfolge der Geo-Objekte und Zeitstempel, Sprünge und Lücken, Geschwindigkeit etc. Das Transaktions-System speichert alle Transaktions-Daten und übermittelt diese online oder im Batch-Betrieb.

If the service instance 16 consists of a toll system, the back office BO has the following additional components:

• A "geo-object manager". This component is used to provide individual tolled geo-objects and their parameters (route calculation, fixed length, road type, coordinates, etc.). In principle, a tariff can be stored for each geo-object.
• A "GPS Position InterFace". This interface receives the available position-related data of the position data interface of the on-board unit OBU either on request or in batch mode at cyclic intervals and calculates the normalized position data from this data. This calculation is dependent on the requirements of the service instances 16. In particular, it is possible to provide the calculations in a special format, in particular in the Cartesian coordinate system or in the WGS84 format. Moreover, it is possible to perform an approximation of position-related data. This is particularly useful if the number of fixes for the calculation of the respective service instance 16 is not sufficient and further GPS or Galileo fixes are necessary, which are not recorded. Then, with the help of this approximation method, the gaps for the missing GPS or Galileo fixes can be reproduced.
• A "road identification interface". This road identification interface (hereafter referred to as the RI interface) accepts the position data and determines from this all toll-liable geo-objects, eg toll sections, zones, route lengths, etc. With the RI interface, it is also possible determine virtual beacons that can replicate real beacons. Thus, a toll on DSRCbasierte routes can be performed. Overall, the RI interface serves to provide the calculated tolling geo-objects and store them if necessary.
• A transaction system. The transaction system calculates tolls based on tolled geo-objects and tariff tables for the time the object was traveled. In addition, tests can be carried out in this system which check the recorded data for correctness. This includes checks for the logical order of geo-objects and timestamps, jumps and gaps, speed etc. The transaction system stores all transaction data and transmits it online or in batch mode.

Furthermore, the system according to the invention can be designed with further interfaces in order to connect further components.

In Figure 3, the basic flow of data processing according to a preferred embodiment in the back-office BO, in particular in the position calculation entity 15 is shown, which is marked in Figure 3 as a position data interface. The on-board unit OBU detects position-related data in normal operation, which are compressed in an optimized manner. In addition, before the data is transferred from the on-board unit OBU to the back-office BO, data is reduced by transmitting not all fixes (that is, all position data acquisitions) but only selected ones. The distance traveled can be reconstructed with sufficient accuracy via mathematical approximation methods, in particular via a spline approximation. In addition, it is possible to use alternative recording methods, such as the recording of pseudo-range data, which allow a much higher accuracy of the position data determination than is the case with GPS, Galileo or vector data and simultaneously allow a high compression. The process depicted in FIG. 3 shows how the back office BO processes the captured and recorded position-related data. The steps which take place on the position data interface between the horizontally dashed lines are then necessary or recommended if pseudo-range data is transmitted by the on-board unit OBU. They are not necessary, if already GPS, Galileo or vector data be handed over. Then the position data can be stored directly in normalized form.

FIG. 4 shows an overview of a process of data processing of satellite position data in the back-office BO. In the position calculation entity 15, which is marked with "GPS position interface" in FIG. 4, the position data are calculated and provided to each service provider or service entity 16 and further components in the desired format. The service entity 16 is identified in FIG. 4 with the term "service provider". The process steps, which are shown between the two horizontal, dashed lines, refer to the position data transmission to the service providers or to the service instances 16.

FIG. 5 shows the data processing in the back-office BO, in particular in the RI interface. The RI interface recognizes the toll-related geo-objects from the transferred position-related data and derives the necessary parameters from them. Here also the distance covered within the tolled Geo object is calculated, in order to derive therefrom a distance-dependent toll collection. The RI interface communicates with both the "GPS Position InterFace" and the Geo-Object Manager to collect the toll-related data. The process steps, which are shown between the two horizontally extending, dashed lines, relate to a toll-subject object transfer to the respective service instances 16.

In the preferred embodiment of the invention, it is provided that an event logging takes place. This makes it possible to understand malfunction and to diagnose it if necessary. It also makes it possible to handle complaints about incorrect toll collection or incorrect fee calculations (even at a later date). Basically, all activities of the units and instances discussed above are archived and included in one Error report summarized. It is also possible to carry only a selection of events.

Due to the modular architecture of the system, it is possible at any time and without difficulty to add a new service instance 16 to the system. For this purpose, it is only necessary for the respective on-board unit OBU to be informed about the essential parameters of the newly included service instance 16 (such as time-out, buffer size, area, etc.) via a corresponding interface.

It is also possible that the service entity 16 blocks or deactivates a special on-board unit OBU via the OBU home operator. A corresponding confirmation of the blocking is reported back to the service entity 16. Such a blockage may be necessary if the service provider considers the conditions for blocking to be fulfilled.

FIG. 6 shows by way of example how the data collection takes place within the on-board unit OBU according to a preferred embodiment. Basically, there are two possibilities: the acquisition according to the DSRC principle and the acquisition of satellite position data. The process steps illustrated in FIG. 6 between the first two horizontal dashed lines refer to DSRC communication with the service provider or service entity 16, respectively. The process steps located thereunder relate on a back-office communication with the service provider.

Finally, it should be noted that the description of the invention and the embodiments are not to be understood as limiting in terms of a particular physical realization of the invention. For a person skilled in the art, it is particularly obvious that the invention can be implemented as a heterogeneous system partially or completely distributed in software and / or hardware and / or on a plurality of physical products - in particular also computer program products.

LIST OF REFERENCE NUMBERS

OBU

On-board unit

S

satellite

BO

Back office

R

reference station

10

GPS and / or Galileo receiver

12

buffer memory

14

Transmitting unit

15

Position calculation Instance

16

Service instance

Claims (20)

A system for processing position-related data, comprising: - A variety of mobile on-board units (OBU), wherein in each case an on-board unit (OBU) on a mobile device, in particular on a vehicle, is arranged and intended to the position-related data of the vehicle to capture, a central and stationary back-office (BO), which is intended to process the position-related data acquired and transmitted by the on-board unit (OBU), and which comprises at least one position calculation entity (15) it is intended to read in the data recorded by the on-board unit (OBU) and to calculate normalized position data therefrom, at least one service entity (16), which is intended to further process the normalized position data and / or the position-related data, the on-board unit (OBU) and the back-office (BO) being in communication via a specific interface. System according to claim 1, characterized in that the position-related data are satellite-based data, in particular satellite raw data, and / or comprise position-related data in arbitrary formats, such as GPS, Galileo, vector data and / or pseudo-range data. Dates. System according to at least one of Claims 1 or 2, characterized in that the on-board unit (OBU) and the back-office (BO) are in data exchange via at least one mobile radio network. System according to at least one of the preceding claims, characterized in that the data is transmitted encrypted and / or compressed between the on-board unit (OBU) and the back-office (BO). System according to at least one of the preceding claims, characterized in that the data in the on-board unit (OBU) via a DSRC system and / or satellite-based, in particular via GPS or Galileo are detected. System according to at least one of the preceding claims, characterized in that from at least one stationary reference station (Ri) detected reference data are used for the calculation of the normalized position data, if the on-board unit (OBU) pseudo-range records are transmitted. System according to at least one of the preceding claims, characterized in that the on-board unit (OBU) transmits the detected position-related data after configurable time intervals and / or then to the back-office (BO) as soon as a predeterminable threshold value is reached , System according to at least one of the preceding claims, characterized in that the position calculation entity (15) calculates the data in dependence on requirements of the service entity (16) and provides it in a configurable format. System according to at least one of the preceding claims, characterized in that the system can be expanded at any time by adding more Service instances (16) are added and integrated via a suitable interface. System according to at least one of the preceding claims, characterized in that the on-board unit (OBU) comprises a receiver which is intended to receive raw satellite data, in particular a GPS receiver and / or a Galileo receiver. System according to at least one of the preceding claims, characterized in that the system comprises an activation mechanism which automatically according to adjustable criteria, in particular depending on a to be detected country identifier or an area, in particular an area of an operator, the transfer of position-related data Enabled or disabled from the on-board unit (OBU) to the back-office (BO). System according to at least one of the preceding claims, characterized in that each on-board unit (OBU) can be uniquely identified by the back-office (BO), in particular via components of a SIM card and / or a device serial number. System according to at least one of the preceding claims, characterized in that it comprises a central storage and / or control unit, wherein the respective on-board units (OBU) are controlled by this control unit of the back-office (BO) and wherein the storage unit of the back office (BO) is used for storing the position-related data of the on-board unit (OBU) and / or the normalized position data and / or other data records, eg status messages. System according to at least one of the preceding claims, characterized in that it comprises an approximation module which accesses at least one approximation method, in particular one Spline approximation, which sets the already acquired data in relation to each other and generates purely unidentified position data based on an approximation algorithm. Use of a system according to at least one of the preceding claims for use in toll systems, characterized in that the back-office (BO) additionally comprises a geo-object manager and a road-identification interface intended for toll-related data to be normalized Assign position data. Use of a system according to at least one of the preceding claims for use in billing toll systems, characterized in that the back-office (BO) additionally comprises a geo-object manager and a transaction instance, which are intended to be automatically based on the To collect and process normalized position data, tolls for the distance traveled by the vehicle of the on-board unit (OBU). Method for processing position-related data, comprising the following method steps: A- acquiring position-related data of one on-board unit (OBU) from a plurality of on-board units (OBU), B- transmitting the position-related data to a central back-office (BO) via an air interface, C-reading the position-related data by the back-office (BO), D- calculating normalized position data from the read-in position-related data and E- forwarding the normalized position data to at least one service entity (16) for further processing in a desired format. Method for determining the position of a mobile device (OBU), characterized by the following steps: Transferring pseudo-range data from the mobile device (OBU) to a back office (BO), Calculate the position of the mobile device in the back office (BO) based on the pseudo-range data. Arrangement for determining the position of a mobile device (OBU), which has an interface to a back office (BO), and means for calculating the position of the mobile device (OBU) on the basis of pseudo-range data, which means in the back office ( BO) are provided. System according to at least one of the preceding claims 1 to 14, characterized in that a data structure is generated in which for each on-board unit (OBU) a unique identification number and / or a virtual identification number of a service entity (16) is stored comprising mapping rules defining a one-to-one relation between virtual identification number and identification number.

Images