DE102005031419A1 - Device and method for data exchange of toll-related data in DSRC systems - Google Patents

Abstract

The invention relates to a method and an apparatus for processing toll-related data for a plurality of DSRC toll operators. In this case, an on-board unit (OBU) is attached to the vehicle and receives signals from a beacon (16). This toll-related data is forwarded by the on-board unit (OBU) to a central back-office (BO). The central back-office (BO) is in communication with the respective toll operators via an interface.

Description

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

The The invention relates in particular to toll systems which are based on a so-called DSRC communication based (DSRC Dedicated Short Range Communication).

So far Prior art DSRC systems include a DSRC tag that has a unique DSRC tag Contains code. The tag can be designed as a small box on the car or can be attached to the windshield. It is a one-definite Relation between a vehicle and a DSRC tag provided so over the DSRC tag the respective vehicle are clearly identified can. About that In addition, the system includes beacons located on the street and electronic modules for exchanging data with the DSRC tag and optionally formed with further units. A vehicle passing the respective beacon will be over DSRC tag clearly registered and recorded by the beacon.

at The previously known systems must now the data collected by the beacon to a local back office of the respective toll operator which processes this data for the purposes of toll collection. Usually will from the electronic module in the beacon a corresponding Communication always initiates as soon as a vehicle with a DSRC tag passes the DSRC beacon. As part of the data exchange between DSRC tag and DSRC beacon sends the DSRC tag its identification to the beacon and the DSRC tag can receive all relevant data of the beacon. In the known systems, the electronic module is the beacon formed as a transmitting and receiving module and is with respect to the DSRC data exchange the active component. Accordingly sends the beacon the relevant data, in particular the identification of the Vehicle and a timestamp of data collection continue to the Back office of the respective toll operator to there the tariff calculation and do the billing to be able to.

One However, a major disadvantage of DSRC communication is to see that they are only for short Distances, especially for those under 8 meters, is designed and is only very limited operational. Furthermore, such prior art systems are susceptible to errors since no alternative options to collect toll-related data. That is, if the data acquisition of a passing vehicle in the beacon not or not completely or incorrectly executed is, the toll calculation can not be performed. Alternative ways to provide the necessary data in other ways are not possible due to the limitation to short distances.

One very significant disadvantage lies in the interface problem, especially if a data collection in an international context, So should be done by several toll operators in several countries. So far results in a very high administrative burden, as a previous DSRC tag specific to a particular DSRC area or for a particular DSRC toll operator is designed. Would like to for example, a truck that has registered in France, at a French Tolling operators cover a distance from France via Austria to Italy, he would have to acquire multiple DSRC tags that would be handled decentrally, each via the associated local or local toll operator billing system. Interoperability between systems of different toll operators of different countries so far not or only very limited possible.

The The present invention has therefore set itself the task of a To show the way with which it is possible will, interoperability of different toll-related systems so that it becomes possible to the exchange of toll-related data, in particular the related Synchronization effort, to improve and to ensure greater flexibility.

The desired flexibility is particularly relevant if more toll operators are added should and / or if toll-related data of an existing toll operator change. This is relatively common the case, since on the one hand the legal provisions and the other the technical requirements of the local toll operators relatively change at short notice can.

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 route of the driving zeuges, forwards.

The The present invention is based on the basic concept that a variety of mobile on-board units (each attached to a vehicle are and in a one-to-one relation with the respective vehicle and a central back-office, a so-called Europe OBU system, provided to the respective toll operators via a uniform interface are connected. In alternative embodiments Is it possible, to provide further instances, e.g. separate transaction instances, the additional intended for the respective toll operator. Core idea is it that the processing of toll-related data is no longer decentralized takes place at the respective toll operator, but centrally in the OBU system, ie in the central back office.

The present invention solves the above object by forming an on-board unit so that toll-related data or all data relevant for toll collection, to the central back office. In the preferred embodiment In this invention, the toll system is a DSRC system. The toll-related data is thus transferred from the beacon to the on-board unit sent individually or collectively to the central back-office.

at Previous DSRC systems, the respective beacon sends a DSRC request to the passing vehicle that sends its DSRC tag identification the beacon sends. The beacon sends the received from the DSRC tag Data and a timestamp of data collection continue to the back-office for tariff calculation and invoicing. So far this is receiving DSRC tag or the well-known on-board unit of the vehicle also a Record that includes all relevant data of the current beacon. However, this data will not be used further. The from the Prior art known on-board unit stores this data only for control purposes. So far, so the beacon is the active element, the toll-related Sends data to the assigned toll operator while the DSRC tag or the known on-board unit remains passive.

in the In contrast, the beacon is inventively designed as a passive element and serves all relevant data of the beacon only to the on-board unit transferred to and not - like so far - on further instances. In contrast, is the on-board unit formed as an active element that received by the beacon Data - if applicable after a buffering in a buffer memory - to the central OBU back office sends.

One An essential advantage of the solution according to the invention is the fact that the existing DSRC systems do not need to be changed and are fully covered the present inventive solution used can be. Of the will be sent by the beacon anyway sent to the on-board unit record only further processed, so that the unique beacon information and a timestamp to be transmitted to the central back-office.

in the In return, the data received from the beacon will be the on-board unit from the on-board unit in principle not further processed. In an alternative embodiment however, it is possible the data received from the beacon of the on-board unit for control purposes to other entities, e.g. to the respective local toll operator and / or to forward to the central back office. This data transfer is however optional and for the Function of the system not necessary.

Basically the DSRC technology used by the different toll operators differ. In particular, with regard to the DSRC protocol used, with regard to used frequencies, signal coding etc. Is it necessary toll-related data from different toll operators - where appropriate with different DSRC techniques - exchange, so must one interoperability between the respective DSRC techniques.

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-supported 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. As a rule, however, there are several toll operators in one country (eg for private roads), so it is necessary to determine in which toll carrier area the vehicle is located. On the basis of the data collected in relation to the current toll operator, the OBU can then automatically determine which communication technology the respective toll operator uses, eg which protocol and / or the required syntax and / or semantics for the data exchange. After that, the On-board unit to automatically configure the interface between the beacon and the on-board unit, depending on the determined communication technology of the toll operator. 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).

In order to can the flexibility of the toll collection system are significantly increased by the current requirements for the data exchange is automatically recorded and implemented or generated become. About that In addition, the risk of error due to a wrong or incorrect Data exchange and / or by an incorrect adaptation to the respective Requirements for data exchange significantly reduced become.

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" is intended to 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.

To the other may be the road network an open system, e.g. in Austria. The term "open" is intended to indicate here the entry and exit to / from the toll road network not necessarily coupled with the passage through a beacon have to be. Then when passing through a beacon a predefinable toll route length Are defined. This toll route in relation to the beacon belongs in this Case also related to the toll related data and is in the back office deposited.

The traveled route can be calculated according to the invention in the back office become. The inventive method and in particular the calculation of the traveled route will be independent executed whether the toll route network is an open or is 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 detection 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 technique of the toll operator.

In the preferred embodiment is the on-board unit according to the invention formed with a position detection module so that it becomes possible automatically determine the exact position of the vehicle. In the Usually this is satellite-based, via a corresponding GPS receiver and / or a Galileo receiver or similar receivers for satellite-based position data. Due to the detected position data, it is possible that the on-board unit according to the invention an activation and / or deactivation of the interface between the on-board unit and the beacon initiated. 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 DSRC communication is located and if so, the beacon interface activates and / or otherwise disables the beacon interface. This has the advantage that an unwanted data exchange over the Interface can be avoided.

In a further advantageous embodiment of the invention the beacon interface designed so that each beacon at least one uniquely beacon identification and / or a timestamp of the data collection to the respective on-board unit of the passing Vehicle transmits. In alternative embodiments of the invention more records, e.g. Data relating to predecessor and / or Transfer successor beacons etc. become.

In general, the communication between the beacon and the on-board unit is based on the DSRC communication technique. In principle, it is possible to use different physical characteristics of the DSRC standard, such as the CEN standard (Comité Européen de Normalisati on / European Commitee for Standardization) or the UNI Standard (UNInfo Italian Standard UNI 10607).

The Back-office interface, that is the interface between the on-board unit and the back-office, is usually designed to that the on-board unit old toll-related data of the vehicle, in particular the data exchange with the beacons, to the central back-office transfers. In a advantageous development of the invention, it is provided that the central back office after the transfer of toll related Data from the on-board unit to the back-office a corresponding receipt acknowledgment to the on-board unit, which should signal a faultless communication exchange. Likewise it can be provided that a successful data exchange over the Beacon interface, So between the on-board unit and the beacon, by a corresponding Signal is signaled to the on-board unit and / or to the beacon.

Basically different modalities for the transmission the toll-related data provided by the on-board unit to the central back-office. For one thing, it is possible that several toll related records be cached in a buffer and configured as configurable Time intervals and / or dependent from the occurrence of a configurable event (e.g., shutdown a particular route or a request from the back office or another instance) to the back-office. On the other hand can The data is transferred directly to the back-office. Basically the modalities of data transfer configurable. So it is particularly adjustable, according to which Time interval or after which event the data is transmitted should be. This can be over a corresponding user input via a user interface done in the back office.

Usually these are the interfaces, especially the beacon interface and at the back-office interface to air interfaces. The data exchange can about that Mobile network are handled. Alternatively, it is possible infrared interfaces or other wireless interfaces.

One An essential 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 uniformly formed. This has the Advantage that extensions of the system are easily implemented can.

in the Difference to the systems of the prior art is the interface, especially the back-office interface - ie the interface between the on-board unit and the central back-office - independent of Toll operator. This will make it possible one and the same on-board unit for a variety of different Toll operators to use without further reconfigurations necessary are.

In the preferred embodiment The invention provides that all toll - related data streams in the central back-office converge. The central back-office is correspondingly with interfaces to the respectively connected Trained toll operators and / or to other instances, if such as. to transaction systems, billing systems, etc. It is but also possible merely providing an interface to billing systems, depending on which one Application, the system according to the invention used shall be.

The The present invention is particularly concerned with interoperability between different toll-related systems or different toll operators directed. With the solution presented here it is possible that an international user, ie a user of a vehicle in international Operation also a foreign one DSRC system and only needs to register once. It is according to the invention no longer necessary to re-register with each toll operator and decentralized. Registration and / or billing or the toll collection takes place only once, preferably at a local Toll operator and / or a billing partner. At the registration the user gives all countries where he wants a toll collection. However, it is also possible that Indication of countries, in which the system should be activated, specify later. An additional selection of countries is possible at any time and easily and is stored in the central back office. After registration will be the vehicle data and all other registration data in the central The back office of the European OBU system is saved and the user receives one European OBU with a unique identification number, a so-called OBU-ID.

• 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. 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. 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, in short OBU ID. 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 an electronic access to a table in which the allocation relation between the identification of the Europe OBU system and the identification of the local toll operator is stored.
• 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.

at There are two options for the second variant:

2a. Separate transmission:

To the registration of a vehicle with a local toll operator the respective toll operator sends a corresponding mapping information back to the European 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 mapping between local OBU-ID and central Europe OBU ID guaranteed is. The transfer the ID is for each registration individually.

2 B. Parcel forwarding the identification numbers:

alternative For the above procedure, it is also possible that a toll operator if necessary a complete number range at identification numbers of its local one System sends in advance to the European OBU system. In this case, done no information about the new user at the local local toll operator. Instead, will in the central Europe OBU system automatically the next free identification number of the local Toll operator for an identification of a vehicle used. This is done via the Access to the mapping table, in which - as described above - a one-to-one Relation between the two identification numbers is stored.

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

Especially in the cases 2a) all activated toll operators are assigned an identification number for a registered vehicle informed. This will ensure that the system is interoperable and also in international use can be used. Furthermore, this can be ensured Be sure to always have the correct local or local OBU identification number (according to mapping table) is used. In case 2b, the above called information transmission not necessarily take place. The toll operator gives a number range free, which can then be activated. In this case, the toll operator knows not when an ID is mapped with the Europa OBU.

All from the local toll operator to the central Europe OBU system Identification numbers are provided by the respective local toll operator as valid Identification numbers marked. This also applies to packet-transmitted Identification numbers and for already transmitted in the past Number ranges.

A further flexibility the solution according to the invention to see that a vehicle or its users in the OBU system can register in different ways: For one thing, he can be at the local Toll operators register, which then via an interface the Submit registration data to the central OBU system. To the He can also register others directly with the European OBU system.

In order to A high level of security can be ensured in the preferred embodiment a security mechanism is provided, which is the interface between monitors the on-board unit and the central back-office. In particular, should be achieved with that a transfer of manipulated records limited or completely can be 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 generated on the basis of an asymmetric key pair and is only valid for a certain time. The period of validity of the key pair is also adjustable.

First after successful generation of a session key is the on-board unit ready to survey and can receive data from the beacon. Before the generation a session key or an unsuccessful generation the same is the interface between the on-board unit and the Bake deactivated. beats the attempt to generate the session key fails, at least a renewed attempt will be started. How many retries possible are also presettable. Hits the generation - if necessary after multiple retries - fail, the on-board unit All communication requests or all transactions with the DSRC system acknowledge negatively or alternatively no response to the DSRC requests give. The local DSRC beacon recognizes this negative or failed communication and can due to the detected miscommunication corresponding further measures initiate. Usually will be here for the Mollpreller initiated a so-called enforcement process. If the lifetime a session key has expired, it is envisaged that the On-board unit generated on time and in advance a new session key.

A further safety measure is to make sure that everyone sent by the beacon toll-related data stored in the on-board unit, also forwarded to the back office. Is now an error in the interface between the on-board unit and the central Back-office before making a transfer this toll-related data is no longer possible, it must be ensured be that the data previously collected in the on-board unit is not get lost. For this purpose, it is foreseen that whether after a configurable number of received DSRC records this successfully transferred to the back-office. For the maximum Number a threshold can be defined. Is this threshold the exceeded maximum entries been without a successful transfer to the back office has taken place, the interface between the on-board unit and the beacon deactivated. That means the on-board unit provides any DSRC communication one. Leading to ensure that no new data is collected and the data collected so far Data continues to be stored in the buffer memory.

at All of the above safety measures are safety-critical Cases, that is called in cases, which lead to a non-compulsory on-board unit, the Users of the vehicle is informed by a signal to the fault. The Signal can be acoustic and / or visual. The signal is used as an indication that onward journey is not possible as the on-board unit not ready for collection. He is therefore asked to pay the toll Street to leave. Alternatively or cumulatively, it may be provided that the error signal to the beacon and / or to the central back-office is sent. This makes it possible further recovery measures initiate.

A additional task solution lies in a device or in a device for processing toll-related Data of a vehicle, the vehicle with an on-board unit which in turn has a beacon interface for data transmission with a variety of on roads arranged beacons and the one back-office interface for transmission with a central back office, with the back office to Processing of toll-related data is determined and where the data exchange between the beacon and the on-board unit, in particular on a DSRC communication technique based.

The Inventive on-board unit can therefore also be called "virtual DSRC tag ". It is preferably designed 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 to cache and store toll-related data that it receives from the beacon this after a configurable time interval to the central back office over the Forward back office interface.

The Advantages, features, and alternative embodiments described above with respect to the inventive method mentioned have been, according to also for the device according to the invention be valid.

One particular advantage of the inventive solution is the fact that the process steps, preferably all process steps, automatically accomplished become. It is no longer necessary for the user to manually enter the processing event intervenes. This can make the error prone of the overall system can be significantly reduced.

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

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

Furthermore Is it 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.

Further advantageous embodiments emerge from the dependent claims.

In The following detailed description of the figures are not restrictive Understanding embodiments with their features and other advantages with reference to the drawing discussed. In this show:

1 An overview of components according to a preferred embodiment of the invention and the respective data exchange between the components,

2 an overview of interfaces between different toll operators,

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

4 an overview of interfaces with a central back-office.

The The following detailed description of the figures is with regard to the preferred application of the solution according to the invention, which is based on the Tolling is targeted. In alternative embodiments However, the invention can also for other processing of toll-related data. In addition to the toll collection here are e.g. the use in other billing 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 are beacons 16 arranged, comprising 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 who's the one from the beacon 16 can cache data received.

As in 1 As shown, the on-board unit OBU consists of a receiving unit for receiving toll-related data from the beacon 16 and a transmitting unit 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 marked as beacon interface BSS.

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

As in 1 represented by a dotted line, it is possible, but not mandatory, that the beacon 16 sends toll-related data relating to a passing vehicle to a local toll operator. According to the invention, this is only provided 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 yourself. Preferably, the beacon sends 16 however no data to the local toll operator. The decentralized local toll operators are connected via an appropriate transaction interface to the central back office BO.

below becomes the fundamental Proceed according to a preferred embodiment the method according to the invention shown.

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, during the journey, further areas or further 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 detects which interface-specific parameters for the data exchange between the on-board unit OBU and the current beacon 16 are necessary, 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 ,

by virtue of the automatically acting configuration module, it is possible that a uniform on-board unit OBU for different toll operators is usable without the user having to intervene, e.g. by Exchange of DSRC tags - like so far - or by switching from 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 from the beacon 16 all toll-relevant data. 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. However, in alternative embodiments, it is also possible to have further data of the beacon here 16 or other instances. The advantage of this embodiment is that the transmission method between the on-board unit OBU and the beacon 16 from the previously known systems can be fully maintained and does not need to be changed.

In an alternative advantageous embodiment of the invention, it is provided, the previously known data exchange between on-board unit OBU and beacon 16 to change so that the beacon 16 is designed 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 this 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 from the on-board unit OBU can either be forwarded directly to the central back office BO or in a buffer memory 10 be cached. The data records stored in the cache 10 can be held above a threshold. Once the threshold is reached, the data records are removed from the buffer memory 10 the on-board unit OBU via the back-office interface BoSS forwarded 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. This is the back office BO with a transaction unit 14 which is designed to process the accumulated toll-related data records to form an overall toll collection result. 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 embodiment of the invention, however, it is also possible, to use another known protocol here. The beacon interface BSS is based on DSRC communication technology. It is, however in principle different physical characteristics of the DSRC technique possible. The respective physical expression The DSRC technology of the respective toll operator can be used by the on-board unit OBU are automatically detected. This information is according to the invention for the configuration the beacon interface BSS used.

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. This includes the back office BO is a mapping unit 12 , The mapping table is managed 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 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 is the assignment of identification numbers from the OBU ID number range, the a toll operator available can arrange, so organized, that the respective identification numbers like a list and used sequentially with each new registration of a vehicle become.

As in 2 As shown, it is possible according to the invention to provide an interoperable exchange between any number of toll operators. The respective toll operators are located 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 According to 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 can be a international use of the system will be greatly simplified, a user also foreign DSRC systems without using a new DSRC tag must or that without further manual intervention are necessary.

In 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 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.

Now the vehicle passes a beacon 16 , DSRC communication between the on-board unit OBU and the beacon takes place 16 , The DSRC beacon 16 recognizes the on-board unit OBU or the virtual DSRC tag and does not itself generate a transaction record for its own toll operator. The DSRC beacon data is stored in the on-board unit OBU in a transaction list.

As marked at point 3, after passing the nth Bake all previously collected DSRC transaction data over an air interface transferred to the European OBU back office BO. Here is the parameter n configurable. The configuration of the parameter n depends on local Provisions, such as the maximum retention period of transactions in the on-board unit OBU, from the credit limit of the user, from the local one Position (border crossing), from the storage capacity of Transaction list and / or the maximum time interval between two communication cycles of the on-board unit OBU.

In point 4 it should be shown that the central back-office BO on the transaction unit 14 accesses in which a rate 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 a user's assigned billing partner for the billing. This is shown under point 5.

Under Point 6 shows that the home toll operator is toll-related Data transmitted to the user. Thus, the user only has to interact with the home toll operator and no carry out further actions with foreign toll operators, even if he 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 is done in such a way that a communication based on the technology used 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 in 4 The "European OBU system" is the central back-office BO. Here, the toll-related data converge and are redistributed 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 can advantageously remain unchanged. An adjustment is not required here.

The central European OBU system BO communicates with the transaction and / or transaction partners a unified transaction interface, resulting in a fast and easy interoperability are created. the interface between the back office or the European OBU system BO and the local Toll operators can also use any interface and no need be wireless connection.

In conclusion, be noted that the description of the invention and the embodiments in principle not restrictive in view of a particular physical implementation of the invention to be understood. For a relevant one It is particularly obvious to a person skilled in the art that the invention as a heterogeneous system partially or completely in software and / or hardware and / or to several physical products - in particular also computer program products - distributed can be realized.

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)

Method for processing toll-related data of a vehicle, the vehicle comprising an on-board unit (OBU) that is equipped with a plurality of beacons ( 16 ), which are located on a trafficable road, via a beacon interface (BSS) in data exchange, wherein the on-board unit (OBU) the toll-related data of the data exchange between the on-board unit (OBU) and the of vehicle beacons ( 16 ) via a back office interface (BoSS) to a central back office (BO) for processing the toll related data related to the traveled route of the vehicle. Method according to claim 1, characterized, that the on-board unit (OBU) carries out the following method steps: - Automatic Capture the current toll operator via a satellite-based position capture of the vehicle, - automatic Determining the communication technique used by the toll operator involved, in particular a transmission protocol, - automatic Configure the beacon interface (BSS) depending on from the determined communication technology of the toll operator. Method according to at least one of the preceding Claims, characterized in that the on-board unit (OBU) automatically detects whether the vehicle is in an area of a toll operator with a DSRC communication by the on-board unit (OBU) recorded the position of the vehicle by satellite, and if so, 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 and / or a time stamp for a data collection to the respective on-board unit (OBU) that is passing through. Method according to at least one of the preceding claims, characterized in that the back-office interface (BoSS) is designed so that the on-board unit (OBU) all toll-related data of the vehicle, in particular the Data exchange with the beacons ( 16 ) to the central back office (BO). Method according to at least one of the preceding Claims, characterized in that the on-board unit (OBU) the toll related data cached and at configurable intervals and / or dependent on from the occurrence of at least one configurable event to the Back Office (BO) transfers. Method according to at least one of the preceding Claims, characterized in that the interface (BSS, BoSS) a Air interface is. Method according to at least one of the preceding Claims, characterized, the beacon interface (BSS) automatically is configurable and / or that the back-office interfaces (BoSS) uniform and / or independent from the respective toll operator. Method according to at least one of the preceding Claims, characterized in that to the back office (BO) more toll operators and / or additional instances connected to the processing of toll-related data can be. Method according to at least one of the preceding Claims, characterized in that each vehicle having access to a a unique assignment rule an identification number which is decentralized by a local toll operator or can be assigned centrally by the back office (BO). Method according to at least one of the preceding Claims, characterized in that the traveled distance of the vehicle, in particular a length the route traveled is calculated in the back office (BO). Method according to at least one of the preceding Claims, characterized in that the road at least a toll road network which 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 ), and which comprises a back-office interface (BoSS) for data transmission with a central back-office (BO), the back-office (BO) being intended for processing the toll-related data. Device for processing toll-related data a vehicle comprising means for performing at least one step and preferably all steps of a method according to at least one of the preceding method claims are set up. Device for determining the position of a mobile equipment (OBU), with at least one mobile device (OBU) that interfaces to a back office (BO), with a back office (BO), an interface to the at least one mobile device (OBU) and means for calculating the position of the mobile equipment (OBU) based on "pseudo range "data, where these funds are provided in the back office (BO).