EP1708144A2 - Method and device for data exchange of toll related data for DSRC (Dedicated Short Range Communications) systems - Google Patents

Abstract

An on-board unit in a vehicle transmits toll-referred data to beacons arranged along a road. A central back office receives the toll-referred data through a back office interface and processes the data which indicate the distance traveled by the vehicle.

Description

The present invention relates to an apparatus and a method for toll collection and / or for the collection and calculation of toll-related data of a vehicle.

The invention relates in particular those toll systems that are based on a so-called DSRC communication (DSRC D edicated- S hort- R reasonable ommunication C).

Previously known DSRC systems of the prior art include a DSRC tag containing a unique code. The tag may be formed as a small box that can be attached to the car or to the windshield. A one-to-one relation between a vehicle and a DSRC tag is provided so that the DSRC tag can uniquely identify the particular vehicle. In addition, the system includes beacons arranged on the street and comprising electronic modules adapted for data exchange with the DSRC tag and optionally with further units. A vehicle passing the respective beacon is uniquely registered and detected by the beacon via its DSRC tag.

In the systems known hitherto, the data captured by the beacon must now be transmitted to a local back office of the respective toll operator, which further processes this data for the purpose of toll collection. Usually, a corresponding communication is initiated by the electronic module in the beacon whenever a vehicle with a DSRC tag passes the DSRC beacon. As part of the data exchange between DSRC tag and DSRC beacon, the DSRC tag sends its identification to the beacon and the DSRC tag can receive all relevant data of the beacon. In the known systems, the electronic module of the beacon is designed as a transmitting and receiving module and is with respect to the DSRC data exchange, the active component. Accordingly, the beacon sends the relevant data, in particular the identification of the vehicle and a timestamp of the data collection on to the back office of the respective toll operator, in order to be able to carry out the tariff calculation and invoicing there.

However, a major disadvantage of DSRC communication is the fact that it is designed for short distances, especially for those under 8 meters, and is only very limited operational capability. Furthermore, such prior art systems are susceptible to errors because there are no alternative ways to collect toll-related data. That is, if the data acquisition of a passing vehicle in the beacon has not been performed or is not completed or erroneous, the toll calculation can not be performed. Alternative ways to provide the necessary data in other ways are not possible due to the short distance limitation.

A very significant disadvantage lies in the interface problem, especially if a data collection in an international context, that is to be done by several toll operators in several countries. So far, there is a very high administrative burden, since a previous DSRC tag is designed specifically for a particular DSRC area or for a particular DSRC toll operator. For example, if a truck that has registered in France wants to travel a route from France via Austria to Italy with a French toll operator, it would need to purchase several DSRC tags that would be handled decentrally, each via its associated local or local toll operator billing system. Interoperability between the systems of different toll operators of different countries is not yet possible, or only to a very limited extent.

The object of the present invention is therefore to propose a way by which it becomes possible to ensure interoperability of various toll-related systems, so that it becomes possible to improve the data exchange of toll-related data, in particular the associated synchronization effort and to ensure greater flexibility.

The desired flexibility is particularly relevant if additional toll operators are to be added and / or if toll-related data of a existing toll operator change. This is relatively often the case, since on the one hand, the legal provisions and on the other hand, the technical requirements of the local toll operators can change relatively quickly.

This object is achieved by a method for processing toll-related data of a vehicle, the vehicle comprising an on-board unit which is in communication with a plurality of beacons arranged on a toll road, the on-board Unit the data of the data exchange between the on-board unit and the beacons traveled by the vehicle via a back-office interface to a central back-office for processing the toll-related data, in particular for calculating a toll for the traveled distance of the vehicle, forwards.

The present invention is based on the basic concept that a plurality of on-board mobile units (each attached to a vehicle and in one-to-one relation with the respective vehicle) and a central back-office, a so-called Europe OBU system, to which the respective toll operators are connected via a single interface. In alternative embodiments, it is possible to provide still further instances, e.g. separate transaction entities provided in addition to the respective toll operator. The central idea is that the processing of toll-related data is no longer decentralized to the respective toll operator, but centrally in the OBU system, ie in the central back-office.

The present invention solves the above problem by designing an on-board unit to forward toll-related data or all data relevant to toll collection to the central back-office. In the preferred embodiment of this invention, the toll system is a DSRC system. The toll-related data is thus sent from the beacon to the on-board unit, which forwards it individually or in a batch to the central back-office.

In previous DSRC systems, the respective beacon sends a DSRC request to the passing vehicle, which sends its DSRC tag identification to the beacon. The beacon sends the data received from the DSRC tag and a timestamp of the data collection to the back office for tariff calculation and to Invoicing. So far, the DSRC tag or the known on-board unit of the vehicle also receives a record that includes all relevant data of the current beacon. However, this data will not be used further. The known from the prior art on-board unit stores this data only for control purposes. So far, so the beacon is the active element that sends the toll-related data to the assigned toll operator while the DSRC tag or the known on-board unit remains passive.

In contrast, the beacon is inventively designed as a passive element and serves to transfer all relevant data of the beacon only to the on-board unit and not - as before - to other instances. In contrast, the on-board unit is designed as an active element which sends the data received from the beacon to the central OBU back-office, possibly after buffering in a buffer memory.

A significant advantage of the solution according to the invention is the fact that the existing DSRC systems need not be changed and can be used without restriction in the context of the present inventive solution. The data set sent by the beacon to the on-board unit anyway is merely processed further so that the unique beacon information and a time stamp are transmitted to the central back-office.

In return, the data of the on-board unit received by the beacon is in principle not further processed by the on-board unit. In an alternative embodiment, however, it is possible for the on-board unit data received from the beacon to be passed on to other entities, e.g. to the respective local toll operator and / or to the central back-office. However, this data transmission is optional and not necessary for the operation of the system.

In principle, the DSRC technique used by the different toll operators may differ. In particular with regard to the DSRC protocol used, with regard to the frequencies used, the signal coding, etc. If it is necessary to exchange toll-related data from different toll operators, possibly with different DSRC techniques, then interoperability between the respective DSRC techniques must be ensured.

This is possible according to the invention. Due to the inventively extended functionality of the on-board unit, it is possible that this automatically detects their position. In the preferred embodiment of the invention, it is provided that the on-board unit recognizes its position automatically via the detection of satellite-based position data. This data can be compared with a geo-file, so that it is possible to automatically detect in which toll carrier area the vehicle is currently located. If it is envisaged that only one toll operator per country should be integrated into the system, the information about the toll operator can be obtained via the country code. However, as a rule, there are several toll operators in a country (for example, also for private roads), so it is necessary to determine in which toll carrier area the vehicle is located. Based on the data collected with respect to the current toll operator, the OBU can then automatically determine which communication technique the respective toll operator uses, e.g. which protocol and / or the required syntax and / or semantics for the data exchange. Following this, the on-board unit can automatically configure the interface between the beacon and the on-board unit, depending on the toll operator's determined communication technology. This makes it possible for the on-board unit to automatically configure the interface between the beacon and the on-board unit, depending on the requirements of the current toll operator. This results in the advantage, which proves to be very significant in practice, that one and the same on-board unit can be used for different DSRC regions and / or for different physical characteristics of the DSRC technique. In contrast to the prior art, it is no longer necessary to exchange one DSRC tag for another or to reprogram the respective on-board unit by hand (usually by the user of the vehicle).

Thus, the flexibility of the toll collection system can be significantly increased by the current requirements for data exchange automatically recorded and implemented or generated. In addition, the risk of errors can be significantly reduced by a false or erroneous data exchange and / or by an incorrect adaptation to the respective requirements with regard to the data exchange.

• Zum einen kann es sich um ein geschlossenes System handeln, wie z.B. in Italien. Der Begriff ,geschlossen' soll in diesem Zusammenhang verdeutlichen, dass in das mautpflichtige Straßennetz nur eingefahren werden kann, wenn eine Bake passiert bzw. durchfahren wird und, dass das mautpflichtige Straßennetz nur verlassen werden kann, wenn ebenso eine Bake durchfahren wird. Die zurückgelegte Entfernung bzw. mautpflichtige Strecke des Fahrzeugs kann dann aus den Daten in Bezug auf die jeweiligen Standorte der Baken im Back-Office berechnet werden.

The road used by the vehicle belongs to a toll road network. There are basically several options for the training of the respective toll road network:

• On the one hand, it can be a closed system, such as in Italy. The term 'closed' should clarify in this context that in the toll road network can only be retracted when a beacon passes or is passed through and that the toll road network can only be left if a beacon is also passed through. The distance traveled or toll route of the vehicle can then be calculated from the data relating to the respective locations of the beacons in the back office.

On the other hand, the road network may be an open system, such as in Austria. The term "open" is intended here to indicate that the entry into and out of the toll road network does not necessarily have to be coupled with the passage through a beacon. Then, a predeterminable toll route length is defined when passing through a beacon. This toll route in relation to the beacon in this case also belongs to the toll-related data and is stored in the back-office.

The traveled route can be calculated according to the invention in the back office. The method according to the invention, and in particular the calculation of the route traveled, are carried out independently of whether the toll route network is an open system or a closed system.

• Automatisches Erfassen des jeweiligen Mautbetreibers bzw. des Mautbetreibergebietes über eine satelliten-gestützte Positionserfassung des Fahrzeugs seitens der On-Board-Unit,
• automatisches Ermitteln der von dem erfassten Mautbetreiber verwendeten Kommunikations-Technik, insbesondere eines Protokolls für den Datenaustausch seitens der On-Board-Unit,
• automatisches Konfigurieren der Schnittstelle zwischen der On-Board-Unit und der Bake in Abhängigkeit von der ermittelten Kommunikations-Technik des erfassten Mautbetreibers.

In a preferred embodiment, the method additionally comprises the following method steps:

• Automatic recording of the respective toll operator or the toll operator area via a satellite-supported position detection of the vehicle by the on-board unit,
• automatic determination of the communication technique used by the toll operator involved, in particular a protocol for the data exchange on the part of the on-board unit,
• automatic configuration of the interface between the on-board unit and the beacon depending on the determined communication technology of the toll operator.

In the preferred embodiment, the on-board unit according to the invention is formed with a position detection module, so that it is possible to automatically determine the exact position of the vehicle. As a rule, this is satellite-based, via a corresponding GPS receiver and / or via a Galileo receiver or similar receivers for satellite-supported position data. Due to the detected position data, it is possible for the on-board unit according to the invention to initiate activation and / or deactivation of the interface between the on-board unit and the beacon. In this embodiment, it is envisaged that the on-board unit automatically detects whether the vehicle is currently in an area of a toll operator with DSRC communication and, if so, activates the beacon interface and / or otherwise deactivates the beacon interface , This has the advantage that unwanted data exchange via the interface can be avoided.

In a further advantageous embodiment of the invention, the beacon interface is designed such that each beacon transmits at least one unambiguous beacon identification and / or a time stamp of the data collection to the respective on-board unit of the passing vehicle. In alternative embodiments of the invention, further data sets, e.g. Data relating to predecessor and / or successor beacons, etc. are transmitted.

In general, the communication between the beacon and the on-board unit is based on the DSRC communication technique. In principle, it is possible here to different physical characteristics of the DSRC standard, such as the CEN standard (Committee E uropeen de N ormalisation / European Commitee for Standardization) or the UNI standard (UNInfo Italian Standard UN110607).

The back-office interface, that is, the interface between the on-board unit and the back-office, is usually designed so that the on-board unit all toll-related data of the vehicle, especially the data exchange with the drivers Beacons, to the central back office transfers. In an advantageous embodiment of the invention, it is provided that the central back-office sends back a corresponding receipt acknowledgment to the on-board unit after the transfer of the toll-related data from the on-board unit to the back-office, the error-free communication To signal exchange. Likewise, it can be provided that a successful data exchange via the beacon interface, So between the on-board unit and the beacon, signaled by a corresponding signal to the on-board unit and / or to the beacon.

In principle, different modalities are provided for the transfer of the toll-related data from the on-board unit to the central back-office. On the one hand, it is possible for a plurality of toll-related data records to be buffered in a buffer memory and for configurable time intervals and / or depending on the occurrence of a configurable event (eg the departure of a particular link or a request from the back-office or another instance) to the backend Office are transmitted. On the other hand, the data can be transferred directly to the back-office. Basically, the modalities of data transmission are configurable. So it is particularly adjustable, after which time interval or after which event the data should be transmitted. This can be done via a corresponding user input via a user interface in the back office.

Usually, the interfaces, in particular the beacon interface and the back-office interface, are air interfaces. The data exchange can be handled via the mobile network. Alternatively, it is possible to provide infrared interfaces or other wireless interfaces.

A significant advantage of the solution according to the invention is the fact that the interfaces, in particular the interfaces between the on-board units and the back-office, are uniform. This has the advantage that extensions of the system can be easily implemented.

In contrast to the systems of the prior art, the interface, in particular the back-office interface - ie the interface between the on-board unit and the central back-office - independent of the toll operator. This makes it possible to use one and the same on-board unit for a variety of different toll operators, without further reconfigurations are necessary.

In the preferred embodiment of the invention, all toll-related data streams are merged in the central back-office. The central back office is accordingly with interfaces to each However, it is also possible to provide only an interface to billing systems, depending on the application for which the system according to the invention is to be used.

The present invention is particularly directed to the interoperability between different toll related systems and different toll operators. With the solution presented here it is possible that an international user, ie a user of a vehicle in international operation, can also use a foreign DSRC system and only has to register once. According to the invention, it is no longer necessary to register again with each toll operator and settle decentralized. Registration and / or billing or toll collection takes place only once, preferably at a local toll operator and / or at a billing partner. When registering, the user indicates all countries where he wants a toll collection. However, it is also possible to enter the details of the countries in which the system is to be activated later. Subsequent selection of countries is possible at any time and is stored in the central back office. After registration, the vehicle data and all other registration data are stored in the central back-office of the European OBU system and the user receives a European OBU with a unique identification number, a so-called OBU-ID.

1. 1. Es ist möglich, dass das Europa-OBU-System vollständig die Verwaltung der Identifikations-Nummern ausführt. Dann vergibt das Europa-OBU-System den Fahrzeugen, die sich registrieren eine eindeutige OBU-Identifikation, kurz OBU-ID. In diesem Fall werden die bisherigen Identifikations-Nummern der dezentralen Mautbetreiber nicht mehr verwendet. Darüber hinaus kann es vorgesehen sein, dass der jeweilige Mautbetreiber die Daten und Informationen über die verwendeten Nummern abrufen kann, insbesondere in Form eines elektronischen Zugriffs auf eine Tabelle, in der die Zuordnungs-Relation zwischen der Identifikation des Europa-OBU-Systems und der Identifikation des lokalen Mautbetreibers abgelegt ist.
2. 2. In der bevorzugten Ausführungsform ist es vorgesehen, dass der lokale Mautbetreiber seinen eigenen Nummernkreis für die Identifikations-Nummern weiter verwenden kann und nicht auf die OBU-System-Identifikations-Nummern umstellen muss. Dafür übergibt der lokale Mautbetreiber seine Identifikations-Nummern dem zentralen Back-Office, nämlich dem Europa-OBU-System. Das Europa-OBU-System verwaltet eine Mapping-Tabelle, die die Identifikations-Nummern des lokalen Mautbetreibers mittels einer ein-eindeutigen Zuordnungsvorschrift auf die Identifikations-Nummern des OBU-Systems überträgt und vice versa.

For the toll calculation, it is essential that a vehicle can be uniquely identified in order to be able to assign the automatically determined, toll-related data records to the vehicle in a unambiguous manner. According to the invention, two possibilities are provided for this:

1. 1. It is possible that the European OBU system will completely manage the identification numbers. Then the Europe OBU system awards the vehicles that register a unique OBU identification, OBU-ID for short. In this case, the previous identification numbers of the decentralized toll operators are no longer used. In addition, it can be provided that the respective toll operator can retrieve the data and information about the numbers used, in particular in the form of electronic access to a table in which the assignment relation is stored between the identification of the European OBU system and the identification of the local toll operator.
2. 2. In the preferred embodiment, it is contemplated that the local toll operator may continue to use his own number range for the identification numbers and not have to switch to the OBU system identification numbers. The local toll operator hands over its identification numbers to the central back-office, namely the Europe OBU system. The European OBU system manages a mapping table which transmits the identification numbers of the local toll operator to the OBU identification numbers by means of a unique assignment rule and vice versa.

In the second variant, there are two possibilities:

2a. Separate transmission:

After registration of a vehicle with a local toll operator, the respective toll operator sends corresponding mapping information back to the Europe OBU system. The mapping information is preferably managed in the form of a mapping table in the Europe OBU system, so that a one-to-one association between local OBU-ID and central Europe OBU-ID is ensured. The ID is transmitted individually for each registration.

2 B. Packet-wise transmission of the identification numbers:

As an alternative to the above procedure, it is also possible for a toll operator to send a complete number range of identification numbers of its local system to the Europe OBU system in advance if required. In this case, there is no information about the new user at the local local toll operator. Instead, in the central European OBU system, the next free identification number of the local toll operator is automatically used to identify a vehicle. This is done by accessing the mapping table, in which - as described above - a one-to-one relation between the two identification numbers is stored.

In cases 2a) and 2b), the central Europe OBU system operates with the number range or with the identification numbers of the local toll operators.

In particular in cases 2a) all activated toll operators are informed about the assignment of an identification number for a registered vehicle. This ensures that the system is interoperable and can also be used internationally. Furthermore, it can be ensured that the correct local or local OBU identification number (according to the mapping table) is always used. In case 2b, the above-mentioned transmission of information need not necessarily take place. The toll operator releases a number range, which can then be activated. In this case the toll operator does not know when an ID is mapped with the Europa OBU.

All identification numbers transmitted by the local toll operator to the central European OBU system are identified as valid identification numbers by the respective local toll operator. This also applies to packet-wise transmitted identification numbers and number ranges already transmitted in the past.

Another flexibility of the solution according to the invention can be seen in the fact that a vehicle or its users can register in the OBU system in different ways: First, he can register with the local toll operator who then the registration data via an interface to the central OBU system. On the other hand, he can also register centrally directly with the European OBU system.

To ensure a high level of security, a security mechanism is provided in the preferred embodiment that monitors the interface between the on-board unit and the central back-office. In particular, it should be achieved that a transfer of manipulated data records can be limited or completely excluded.

The security mechanism has the following function:
At predeterminable time intervals that can be parameterized via a user interface, the on-board unit and the central back-office generates a common OBU-dependent session key. This key is based on an asymmetric key pair and is only valid for a certain time. The period of validity of the key pair is also adjustable.

Only after successful generation of a session key, the on-board unit is ready to collect and can receive data from the beacon. Before the generation of a session key or an unsuccessful generation of the same, the interface between the on-board unit and the beacon is deactivated. If the attempt to generate the session key fails, at least one new retry attempt can be started. How many retries are possible is also presettable. If the generation fails - possibly after multiple retry attempts - the on-board unit will acknowledge all communication requests or all transactions with the DSRC system negatively or alternatively will not respond to the DSRC requests. The local DSRC beacon recognizes this negative or failed communication and may initiate appropriate further action based on the detected miscommunication. Usually, a so-called enforcement process is initiated here for the toll car. If the lifetime of a session key has expired, it is provided that the on-board unit generates a new session key in good time and in advance.

Another security measure is to ensure that all toll-related data sent by the beacon, which is stored in the on-board unit, is also forwarded to the back-office. If there is an error in the interface between the on-board unit and the central back-office so that it is no longer possible to transfer this toll-related data, it must be ensured that the data previously collected in the on-board unit do not get lost. For this purpose, it is provided that it is checked whether after a configurable number of received DSRC data records, these have also been transmitted successfully to the back-office. For the maximum number, a threshold value can be defined. If this threshold of maximum entries has been exceeded without a successful transfer to the back office, the interface between the on-board unit and the beacon is deactivated. That is, the on-board unit stops any DSRC communication. This means that no new data is collected and the data collected so far are stored in the buffer memory.

In all the above-mentioned safety measures in safety-critical cases, that is, in cases that lead to a non-preparatory on-board unit, the user of the vehicle is notified by a signal to the fault. The signal can be acoustic and / or visual. The signal serves as an indication that it is not possible to continue because the on-board unit is not ready for collection. He is therefore requested to leave the toll road. Alternatively or cumulatively, it may be provided that the error signal is sent to the beacon and / or to the central back-office. This makes it possible to initiate further recovery measures.

Another object solution lies in a device for processing toll-related data of a vehicle, wherein the vehicle is equipped with an on-board unit, which in turn has a beacon interface for data transmission with a plurality of beacons arranged on roads and which comprises a back-office interface for transmission with a central back-office, the back-office being intended for processing the toll-related data, and the data exchange between the beacon and the on-board unit being based in particular on a DSRC communication system. Technology based.

The on-board unit according to the invention can therefore also be referred to as a "virtual DSRC tag". It is preferably in the form of an integrated circuit and thus a smarter and more complex solution than the previous DSRC tag. The inventive virtual DSRC tag is characterized by increased functionality. In contrast to previous systems, the on-board unit according to the invention is designed to temporarily store toll-related data that it receives from the beacon and forward it to the central back-office via the back-office interface after a configurable time interval.

The advantages, features and alternative embodiments, which have been mentioned above with respect to the inventive method, should also apply accordingly to the device according to the invention.

A particular advantage of the solution according to the invention is that the method steps, preferably all method steps, are carried out automatically. It is no longer necessary for the user to manually enter the Processing activity intervenes. Thus, the error rate of the overall system can be significantly reduced.

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 Bauteilen gemäß einer bevorzugten Ausführungsform der Erfindung und dem jeweiligen Datenaustausch zwischen den Bauteilen,

Figur 2

eine übersichtsartige Darstellung von Schnittstellen zwischen verschiedenen Mautbetreibern,

Figur 3

eine übersichtsartige Darstellung der hauptsächlichen Transaktionswege für die erfindungsgemäße Verarbeitung von mautbezogenen Daten und,

Figur 4

eine übersichtsartige Darstellung von Schnittstellen mit einem zentralen Back-Office.

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 components according to a preferred embodiment of the invention and the respective data exchange between the components,

FIG. 2

an overview of interfaces between different toll operators,

FIG. 3

an overview of the main transaction paths for the processing of toll-related data according to the invention and,

FIG. 4

an overview of interfaces with a central back-office.

The following detailed description of the figures is described with regard to the preferred application of the solution according to the invention, which is aimed at toll collection. However, in alternative embodiments, the invention may also be used to otherwise process the toll related data. In addition to toll collection, here are e.g. to use in other accounting systems, clearing systems, fleet management systems or the like.

Every vehicle that wants to use the Europe OBU system is equipped with an on-board unit OBU. The toll collection is based on the DSRC technique. On a toll road beacons 16 are arranged, which include electronic modules that are intended for data exchange with a corresponding module in the vehicle. In the prior art methods, the electronic modules arranged in the vehicle were DSRC tags. The functionality of the previously known DSRC tags is encompassed by the functionality of the on-board units OBU used according to the invention. The on-board units OBU according to the invention have a more complex functionality and preferably comprise a buffer memory 10 which can buffer the data received by the beacon 16.

As shown in Figure 1, the on-board unit OBU consists of a receiving unit for receiving toll-related data from the beacon 16 and a transmitting unit which is intended to forward the data thus received to a central back-office BO. The interface between the back-office BO and the on-board unit OBU is identified as the back-office interface BoSS. The interface between the on-board unit OBU and the beacon 16 is identified as a beacon interface BSS.

The processing of the toll-related data, in particular the toll collection, takes place centrally in the back-office BO. For this purpose, the toll-related data is no longer transferred from the beacon 16 to the back-office BO as before, but by the mobile on-board unit OBU via the back-office interface BoSS.

As shown in FIG. 1 by a dotted line, it is possible, but not essential, for the beacon 16 to send toll-related data relating to a passing vehicle to a local toll operator. According to the invention this is provided only if an additional control method is desired. The local toll operator then receives toll related data from both the central back office BO and the beacon 16 itself. Preferably, however, the beacon 16 does not send data to the local toll operator. The decentralized local toll operators are connected via an appropriate transaction interface to the central back office BO.

The basic procedure according to a preferred embodiment of the method according to the invention will now be described.

A vehicle registers with the local toll operator or back-office BO, and receives an identification number that uniquely identifies its vehicle. If the user has registered with the local toll operator, the registration data is transmitted via the transaction interface to the central back office BO. In the registration process, the user can specify in which countries or in which areas he wishes to activate the method according to the invention or toll collection. However, it is also possible later, so to speak while driving, further areas or other countries nachzuschalten.

In the preferred embodiment, the on-board unit OBU comprises a position detection unit which is intended to detect the current position of the vehicle. By accessing a geo-file, the on-board unit OBU can autonomously and automatically determine whether the vehicle is currently located in one of the registered toll operator areas. Typically, the areas are DSRC areas. If the vehicle is not located in such an area, the interfaces remain disabled. Otherwise, the on-board unit OBU can automatically determine on which communication technology the data exchange of the respective toll operator is based. The on-board unit OBU thus automatically recognizes which interface-specific parameters are necessary for the data exchange between the on-board unit OBU and the current beacon 16, in particular which transmission protocol, which coding etc. is necessary. In accordance with the determined communication-technical data, the on-board unit OBU automatically and independently configures the beacon interface BSS between the on-board unit OBU and the beacon 16.

Due to the automatically acting configuration module, it is possible for a uniform on-board unit OBU to be usable for different toll operators without the user having to intervene, e.g. by exchanging DSRC tags - as before - or by switching certain functions.

If a vehicle with a registered on-board unit OBU now passes a beacon 16, the on-board unit OBU sends its OBU identification number to the beacon 16 and receives all toll-relevant data from the beacon 16. Alternatively, it is also possible that (possibly cumulatively) the local (mapped) OBU ID is sent, if the toll operator wishes. The toll-relevant data in this case is a beacon identification number and a timestamp for a survey of the data record. In alternative embodiments, however, it is also possible to transmit further data of the beacon 16 or other instances here. The advantage of this embodiment is the fact that the transmission method between the on-board unit OBU and the beacon 16 can be completely retained from the previously known systems and does not have to be changed.

In an alternative advantageous embodiment of the invention, it is provided to change the previously known data exchange between on-board unit OBU and beacon 16 to the effect that the beacon 16 is formed only as a transmitting unit. The beacon 16 then receives no data, in particular no identification number of the on-board unit OBU and therefore can no longer forward it to local toll operators for control purposes. It is only designed to transfer beacon-specific data and possibly other toll-related data to the on-board unit.

The toll-related data received by the on-board unit OBU can either be forwarded directly to the central back-office BO or buffered in a buffer memory 10. The data records held in the buffer memory 10 may be determined via a threshold. Once the threshold is reached, the data records are forwarded from the buffer memory 10 of the on-board unit OBU via the back-office interface BoSS to the back-office BO.

If a vehicle now passes through a plurality of DSRC areas of different toll operators, it is possible according to the invention for all the toll-related data of the various toll operators to be processed centrally in the back-office BO. For this purpose, the back office BO is formed with a transaction unit 14, which is intended to process the accumulated toll-related data records to a total result for the toll collection. The collected toll is then fed via the interface to the respective toll operator, in which the user has registered. This makes it possible to provide an interoperable tolling system, the administrative burden of which can be significantly minimized by the central processing and is generally simpler and offers more functionality.

The back-office interface BoSS is preferably based on a proprietary protocol. In an alternative development of the invention, however, it is also possible to use another known protocol here. The beacon interface BSS is based on the DSRC communication technology. However, fundamentally different physical characteristics of the DSRC technique are possible. The respective physical characteristics of the DSRC technology used by the respective toll operator can be automatically recognized by the on-board unit OBU. This information is used according to the invention for the configuration of the beacon interface BSS.

The different toll operators work with their own identification number circles. A particular advantage of the invention is the fact that the identification numbers of the local toll operators can also be used in the Europe OBU system. For this purpose, the back office BO comprises a mapping unit 12. The management of the mapping table takes place in the back office BO. However, a current extract of the table must be kept in the on-board unit OBU in order to be able to use the correct OBU ID, if necessary. The mapping unit 12 is designed to provide a one-to-one mapping rule between the toll operator's local identification numbers and the central OBU system's identification numbers. This makes it possible for the Europe OBU system to work either with a central identification number assignment or with the identification numbers of the local toll operator.

Usually, the allocation of identification numbers from the OBU-ID number range, which a toll operator can provide, is organized such that the respective identification numbers are available in a list and are used sequentially with each new registration of a vehicle.

As shown in Figure 2, it is possible according to the invention to provide an interoperable exchange between any number of toll operators. The respective toll operators are via the DSRC interface with the respective beacons 16 in the data exchange and are in addition to the data exchange with the central back-office BO in addition to each other in data exchange. This usually takes place via a uniform transaction interface and / or via a uniform interface for exchanging user, vehicle and / or identification number data. Alternatively, additional additional toll-related data can be exchanged via this interface. The central processing according to the invention in the back office, the synchronization effort can be significantly reduced. In addition, system extensions are easy to implement. In contrast to known methods, it is no longer necessary for a user to register in such a toll carrier area in which he will not drive. This can reduce transaction and administration costs.

In the preferred embodiment of the invention, the back-office BO is designed as a Europe OBU system. All vehicle data is stored centrally in the Europe OBU system. This makes it much easier to use the system internationally, allowing a user to use foreign DSRC systems without the need for a new DSRC tag, or without the need for further manual intervention.

In Figure 3, the time course of the toll collection according to the invention is shown. The time is corresponding to the arrow pointing from left to right in Fig.3. The numbers 1 to 6 shown in the circles indicate the following process steps:
After a successful registration of the user in the European OBU system, a session key is generated at point 1 by the on-board unit OBU and by the European OBU back-office BO.
If the vehicle then passes a beacon 16, a DSRC communication takes place between the on-board unit OBU and the beacon 16. The DSRC beacon 16 recognizes the on-board unit OBU or the virtual DSRC tag and generates it itself no transaction record for your own toll operator. The DSRC beacon data is stored in the on-board unit OBU in a transaction list.
As indicated at point 3, after passing the nth beacon, all previously collected DSRC transaction data is transmitted over an air interface to the Europe OBU back office BO. The parameter n is configurable. The configuration of the parameter n is dependent on local conditions such as the maximum length of stay of transactions in the on-board unit OBU, the credit limit of the user, the local position (border crossing), the storage capacity of the transaction list and / or the maximum time interval between two communication cycles of the on-board unit OBU.
Point 4 should show that the central back office BO accesses the transaction unit 14 in which a tariff table is stored. The back office BO can thus praise the read DSRC transaction. The back office BO sends the determined toll collection and / or the DSRC transactions to the respective home toll operator or to an assigned user of the user for billing. This is shown under point 5.
Point 6 shows that the home toll operator transmits the toll-related data to the user. Thus, the user only has to interact with the home toll operator and make no further action on foreign toll operators, even if he has passed through their territory.

The on-board unit OBU recognizes from the current position (the automatic position determination is preferably satellite-based) whether it is located in an area of a DSRC toll operator. If a DSRC area is detected, the OBU application automatically configures the integrated DSRC modem. However, it is also possible that the on-board unit OBU is equipped with several DSRC modems. The configuration takes place in such a way that communication can take place on the basis of the technology employed by the toll operator. This means that the OBU application controls the protocol and the semantic content depending on the respective toll operator. Only different physical characteristics of the DSRC technique (CEN, UNI) require different DSRC modules / modems in the on-board unit OBU. As shown in Fig. 4, the "Europe OBU system" is the central back office BO. Here, the toll - related data converges and is distributed to the respective toll operators or to their transaction partners. The toll operators communicate with the back office BO via an interface via which, in particular, the provided identification number circles are assigned. The transfer of the identification numbers can be done automatically but also manually. This means that the identification number circles can be automatically read in via an interface from a provided file. It is also possible that the number circles are read on other communication channels, such as by a manual input via a user interface, an input via e-mail, etc. The interface between the respective toll operators and operated by them beacons 16 may advantageously remain unchanged. An adjustment is not required here.

The central Europe OBU system BO communicates with the transaction and / or transaction partners via a unified transaction interface, providing fast and easy interoperability. The interface between the back office or the European OBU system BO and the local toll operators can also be any interface and need not be a wireless connection.

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 Numerals:

OBU

On-board unit

BO

Back office

BSS

Beacon interface

Boss

Back-office interface

10

buffer memory

12

Mapping unit

14

Transaction unit

16

bake

Claims (15)

A method for processing toll-related data of a vehicle, the vehicle comprising an on-board unit (OBU) provided with a plurality of beacons (16) arranged on a trafficable road via a beacon interface (BSS) in Data exchange, wherein the on-board unit (OBU) on a toll-related data exchange data between the on-board unit (OBU) and the vehicle used by beacons (16) via a back-office interface (BoSS) on central back office (BO) for processing the toll related data related to the traveled route of the vehicle. Method according to claim 1,
characterized in that the on-board unit (OBU) carries out the following method steps: Automatic detection of the current toll operator via a satellite-supported position detection of the vehicle, automatic determination of the communication technique used by the toll operator involved, in particular a transmission protocol, - Automatic configuration of the beacon interface (BSS) depending on the determined communication technique of the toll operator. Method according to at least one of the preceding claims,
characterized,
that the on-board unit (OBU) automatically detects whether the vehicle is in an area of a toll operator with DSRC-communication, detected by the on-board unit (OBU) the position of the vehicle satellite-supported, and if yes, the beacon interface (BSS) is activated and / or deactivated otherwise. Method according to at least one of the preceding claims,
characterized,
in that the beacon interface (BSS) is designed so that each beacon (16) transmits at least one unique beacon identification code number and / or one time stamp for a data collection to the respectively passing on-board unit (OBU). Method according to at least one of the preceding claims,
characterized,
that the back office interface (boss) is designed so that the on-board unit (OBU) all toll-related data of the vehicle, particularly the data exchange with the traffic beacon (16), to the central back office (BO) transfers. Method according to at least one of the preceding claims,
characterized,
that the on-board unit (OBU) buffers toll-related data and transmits at configurable time intervals and / or in dependence on the occurrence of at least one configurable event to the back office (BO). Method according to at least one of the preceding claims,
characterized,
that the interface (BSS, BoSS) is an air interface. Method according to at least one of the preceding claims,
characterized
the beacon interface (BSS) is automatically configurable and / or that the back office interfaces (BoSS) are uniform and / or independent of the respective toll operator. Method according to at least one of the preceding claims,
characterized,
that to the back office (BO) more toll operators and / or more Instances for the processing of toll related data. Method according to at least one of the preceding claims,
characterized,
that each vehicle is assigned, with access to a unique assignment rule, an identification number that can be allocated remotely by a local toll operator or centrally by the back office (BO). Method according to at least one of the preceding claims,
characterized,
that the traveled distance of the vehicle, in particular a length of the traveled route, in the back-office (BO) is calculated. Method according to at least one of the preceding claims,
characterized,
that the road is at least associated with a toll road network that is an open or a closed system. Device for processing toll-related data of a vehicle, the vehicle being equipped with an on-board unit (OBU), which in turn has a beacon interface (BSS) for data transmission with a plurality of beacons (16) arranged on roads, and the a back-office interface (BoSS) for data transmission with a central back-office (BO), wherein the back-office (BO) is intended for processing the toll-related data. Device for processing toll-related data of a vehicle, comprising means set up for carrying out at least one step and preferably all steps of a method according to at least one of the preceding method claims. Device for determining the position of a mobile device (OBU), with at least one mobile device (OBU) that interfaces with a back Office (BO), with a back office (BO), which has an interface to the at least one mobile device (OBU), and with means for calculating the position of the mobile device (OBU) on the basis of "pseudo range" data, wherein these funds are provided in the back office (BO).

Images