[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1708144A2 - Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen - Google Patents

Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen Download PDF

Info

Publication number
EP1708144A2
EP1708144A2 EP06004736A EP06004736A EP1708144A2 EP 1708144 A2 EP1708144 A2 EP 1708144A2 EP 06004736 A EP06004736 A EP 06004736A EP 06004736 A EP06004736 A EP 06004736A EP 1708144 A2 EP1708144 A2 EP 1708144A2
Authority
EP
European Patent Office
Prior art keywords
toll
obu
board unit
vehicle
office
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP06004736A
Other languages
English (en)
French (fr)
Other versions
EP1708144B1 (de
EP1708144A3 (de
Inventor
Peter Selmayr
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
M2C Solutions GmbH
Original Assignee
Ages Internat & Co KG GmbH
Ages International & Co KG GmbH
MPS Solutions GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=36659950&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP1708144(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from DE200510010888 external-priority patent/DE102005010888A1/de
Priority claimed from DE202005009152U external-priority patent/DE202005009152U1/de
Priority claimed from DE102005030030A external-priority patent/DE102005030030A1/de
Application filed by Ages Internat & Co KG GmbH, Ages International & Co KG GmbH, MPS Solutions GmbH filed Critical Ages Internat & Co KG GmbH
Publication of EP1708144A2 publication Critical patent/EP1708144A2/de
Publication of EP1708144A3 publication Critical patent/EP1708144A3/de
Application granted granted Critical
Publication of EP1708144B1 publication Critical patent/EP1708144B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles

Definitions

  • 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.
  • 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.
  • 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.
  • a corresponding communication is initiated by the electronic module in the beacon whenever a vehicle with a DSRC tag passes the DSRC beacon.
  • the DSRC tag sends its identification to the beacon and the DSRC tag can receive all relevant data of the beacon.
  • 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.
  • DSRC communication 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.
  • 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.
  • a so-called Europe OBU system to which the respective toll operators are connected via a single interface.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data of the on-board unit received by the beacon is in principle not further processed by the on-board unit.
  • this data transmission is optional and not necessary for the operation of the system.
  • the DSRC technique used by the different toll operators may differ.
  • 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.
  • the on-board unit Due to the inventively extended functionality of the on-board unit, it is possible that this automatically detects their position.
  • 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.
  • 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.
  • 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.
  • the flexibility of the toll collection system can be significantly increased by the current requirements for data exchange automatically recorded and implemented or generated.
  • 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.
  • 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.
  • 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.
  • 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.
  • a position detection module 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.
  • 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.
  • 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.
  • further data sets e.g. Data relating to predecessor and / or successor beacons, etc. are transmitted.
  • the communication between the beacon and the on-board unit is based on the DSRC communication technique.
  • 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.
  • 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.
  • 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.
  • the toll-related data In principle, different modalities are provided for the transfer of the toll-related data from the on-board unit to the central back-office.
  • a plurality of toll-related data records 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.
  • the data can be transferred directly to the back-office.
  • 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.
  • the interfaces are air interfaces.
  • the data exchange can be handled via the mobile network.
  • 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.
  • 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.
  • all toll-related data streams are merged in the central back-office.
  • the central back office is accordingly with interfaces to each
  • the present invention is particularly directed to the interoperability between different toll related systems and different toll operators.
  • an international user ie a user of a vehicle in international operation
  • Registration and / or billing or toll collection takes place only once, preferably at a local toll operator and / or at a billing partner.
  • the user indicates all countries where he wants a toll collection.
  • 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.
  • 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.
  • a toll operator can 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.
  • the central Europe OBU system operates with the number range or with the identification numbers of the local toll operators.
  • 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.
  • 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.
  • a security mechanism is provided in the preferred embodiment that monitors the interface between the on-board unit and the central back-office.
  • 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.
  • the on-board unit 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the invention may also be used to otherwise process the toll related data.
  • 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.
  • 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.
  • 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 takes place centrally in the back-office BO.
  • 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.
  • the beacon 16 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.
  • 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 nachzulit.
  • the on-board unit OBU comprises a position detection unit which is intended to detect the current position of the vehicle.
  • 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.
  • OBU automatic on-board unit 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.
  • the on-board unit OBU sends its OBU identification number to the beacon 16 and receives all toll-relevant data from the beacon 16.
  • the toll-relevant data in this case is a beacon identification number and a timestamp for a survey of the data record.
  • 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.
  • beacon 16 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.
  • 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.
  • 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 back office BO comprises a mapping unit 12.
  • the management of the mapping table takes place in the back office BO.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG 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:
  • a session key is generated at point 1 by the on-board unit OBU and by the European OBU back-office BO.
  • 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.
  • 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.
  • 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.
  • the "Europe OBU system” is the central back office BO.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Position Fixing By Use Of Radio Waves (AREA)

Abstract

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Verarbeitung von mautbezogenen Daten für eine Vielzahl von DSRC-Mautbetreibern. Dabei ist eine On-Board-Unit (OBU) an dem Fahrzeug befestigt und empfängt Signale einer Bake (16). Diese mautbezogenen Daten werden von der On-Board-Unit (OBU) an ein zentrales Back-Office (BO) weitergeleitet. Das zentrale Back-Office (BO) steht über eine Schnittstelle in Datenaustausch mit den jeweils beteiligten Mautbetreibern.

Description

  • Die vorliegende Erfindung betrifft eine Vorrichtung und ein Verfahren für eine Mauterhebung und/oder für die Erfassung und Berechnung von mautbezogenen Daten eines Fahrzeugs.
  • Die Erfindung betrifft insbesondere solche Mautsysteme, die auf einer so genannten DSRC-Kommunikation basieren (DSRC-Dedicated-Short-Range-Communication).
  • Bisher bekannte DSRC-Systeme aus dem Stand der Technik umfassen ein DSRC-Tag, das einen eindeutigen Code enthält. Das Tag kann als kleine Box ausgebildet sein, das an dem Auto bzw. an der Windschutzscheibe befestigt werden kann. Es ist eine ein-eindeutige Relation zwischen einem Fahrzeug und einem DSRC-Tag vorgesehen, sodass über das DSRC-Tag das jeweilige Fahrzeug eindeutig identifiziert werden kann. Darüber hinaus umfasst das System Baken, die an der Strasse angeordnet sind und elektronische Module umfassen, die zum Datenaustausch mit dem DSRC-Tag und gegebenenfalls mit weiteren Einheiten ausgebildet sind. Ein an der jeweiligen Bake vorbeifahrendes Fahrzeug wird über sein DSRC-Tag von der Bake eindeutig registriert und erfasst.
  • Bei den bisher bekannten Systemen müssen nun die von der Bake erfassten Daten an ein lokales Back-Office des jeweiligen Mautbetreibers übertragen werden, das diese Daten zum Zwecke der Mauterfassung weiter verarbeitet. Üblicherweise wird von dem elektronischen Modul in der Bake eine entsprechende Kommunikation immer dann initiiert, sobald ein Fahrzeug mit einem DSRC-Tag die DSRC-Bake passiert. Im Rahmen des Datenaustauschs zwischen DSRC-Tag und DSRC-Bake sendet das DSRC-Tag seine Identifikation an die Bake und das DSRC-Tag kann alle relevanten Daten der Bake empfangen. Bei den bekannten Systemen ist das elektronische Modul der Bake als Sende- und Empfangs-Modul ausgebildet und ist in bezug auf den DSRC-Datenaustausch die aktive Komponente. Dementsprechend sendet die Bake die relevanten Daten, insbesondere die Identifikation des Fahrzeugs und einen Zeitstempel der Datenerhebung weiter an das Back-Office des jeweiligen Mautbetreibers, um dort die Tarifberechnung und die Fakturierung ausführen zu können.
  • Ein wesentlicher Nachteil der DSRC-Kommunikation ist jedoch darin zu sehen, dass sie nur für kurze Distanzen, insbesondere für solche unter 8 Meter, ausgelegt ist und nur sehr begrenzt einsatzfähig ist. Des weiteren sind solche Systeme aus dem Stand der Technik fehleranfällig, da keine alternativen Möglichkeiten zur Erhebung von mautbezogenen Daten bestehen. Das heißt, falls die Datenerfassung eines passierenden Fahrzeugs in der Bake nicht oder nicht vollständig oder fehlerhaft ausgeführt worden ist, kann die Mautberechnung nicht durchgeführt werden. Alternative Möglichkeiten, um die notwendigen Daten auf anderen Wegen bereitzustellen, sind aufgrund der Begrenzung auf kurze Distanzen nicht möglich.
  • Ein sehr wesentlicher Nachteil liegt in der Schnittstellen-Problematik, insbesondere dann, wenn eine Datenerhebung in internationalem Rahmen, also von mehreren Mautbetreibern in mehreren Ländern erfolgen soll. Bisher ergibt sich ein sehr hoher Verwaltungsaufwand, da ein bisheriges DSRC-Tag spezifisch für ein bestimmtes DSRC-Gebiet bzw. für einen bestimmten DSRC-Mautbetreiber ausgelegt ist. Möchte nun beispielsweise ein Lkw, der sich in Frankreich registriert hat, bei einem französischen Mautbetreiber eine Strecke von Frankreich über Österreich nach Italien zurücklegen, so müsste er mehrere DSRC-Tags erwerben, die dezentral abgewickelt werden würden, jedes über das zugehörige örtliche bzw. lokale Mautbetreiber-Abrechnungssystem. Eine Interoperabilität zwischen den Systemen verschiedener Mautbetreiber verschiedener Länder ist bislang nicht oder nur sehr eingeschränkt möglich.
  • Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem es möglich wird, eine Interoperabilität von verschiedenen mautbezogenen Systemen zu gewährleisten, sodass es möglich wird, den Datenaustausch von mautbezogenen Daten, insbesondere den damit verbundenen Synchronisations-Aufwand, zu verbessern und eine höhere Flexibilität zu gewährleisten.
  • Die gewünschte Flexibilität ist insbesondere dann relevant, wenn weitere Mautbetreiber hinzugefügt werden sollen und/oder wenn mautbezogene Daten eines bestehenden Mautbetreibers sich ändern. Dies ist relativ häufig der Fall, da sich zum einen die gesetzlichen Bestimmungen und zum anderen die technischen Voraussetzungen der örtlichen Mautbetreiber relativ kurzfristig ändern können.
  • Diese Aufgabe wird durch ein Verfahren zur Verarbeitung von mautbezogenen Daten eines Fahrzeugs gelöst, wobei das Fahrzeug eine On-Board-Unit umfasst, die mit einer Vielzahl von Baken in Datenaustausch steht, die auf einer mautpflichtigen Straße angeordnet sind, wobei die On-Board-Unit die Daten des Datenaustauschs zwischen der On-Board-Unit und den von dem Fahrzeug befahrenen Baken über eine Back-Office-Schnittstelle an ein zentrales Back-Office zur Verarbeitung der mautbezogenen Daten, insbesondere zur Berechnung einer Maut für die befahrene Strecke des Fahrzeuges, weiterleitet.
  • Die vorliegende Erfindung basiert auf dem grundlegenden Konzept, dass eine Vielzahl von mobilen On-Board-Units (die jeweils an einem Fahrzeug befestigt sind und in einer ein-eindeutigen Relation mit dem jeweiligen Fahrzeug stehen) und ein zentrales Back-Office, ein so genanntes Europa-OBU-System, vorgesehen sind, an das die jeweiligen Mautbetreiber über eine einheitliche Schnittstelle angebunden sind. In alternativen Ausführungsformen ist es möglich, noch weitere Instanzen vorzusehen, z.B. separate Transaktions-Instanzen, die zusätzlich zu dem jeweiligen Mautbetreiber vorgesehen sind. Kerngedanke ist es, dass die Verarbeitung von mautbezogenen Daten nicht mehr dezentral bei dem jeweiligen Mautbetreibern erfolgt, sondern zentral in dem OBU-System, also in dem zentralen Back-Office.
  • Die vorliegende Erfindung löst die obenstehend genannte Aufgabe, indem eine On-Board-Unit so ausgebildet wird, dass sie mautbezogene Daten bzw. alle Daten, die für eine Mauterhebung relevant sind, an das zentrale Back-Office weiterleitet. In der bevorzugten Ausführungsform dieser Erfindung handelt es sich bei dem Mautsystem um ein DSRC-System. Die mautbezogenen Daten werden also von der Bake an die On-Board-Unit gesendet, die diese einzeln oder gesammelt an das zentrale Back-Office weiterleitet.
  • Bei bisherigen DSRC-Systemen sendet die jeweilige Bake eine DSRC-Ahfrage an das passierende Fahrzeug, das seine DSRC-Tag-Identifikation an die Bake sendet. Die Bake sendet die von dem DSRC-Tag empfangenen Daten und einen Zeitstempel der Datenerhebung weiter an das Back-Office zur Tarifberechnung und zur Fakturierung. Bisher empfängt das DSRC-Tag bzw. die bekannte On-Board-Unit des Fahrzeugs auch einen Datensatz, der alle relevanten Daten der aktuellen Bake umfasst. Diese Daten werden allerdings nicht weiter verwendet. Die aus dem Stand der Technik bekannte On-Board-Unit speichert diese Daten lediglich für Kontrollzwecke. Bisher ist also die Bake das aktive Element, das die mautbezogenen Daten an den zugeordneten Mautbetreiber sendet, während das DSRC-Tag bzw. die bekannte On-Board-Unit passiv verbleibt.
  • Im Gegensatz dazu, ist die Bake erfindungsgemäß als passives Element ausgebildet und dient dazu, alle relevanten Daten der Bake lediglich an die On-Board-Unit zu übertragen und nicht - wie bisher - an weitere Instanzen. Demgegenüber ist die On-Board-Unit als aktives Element ausgebildet, das die von der Bake empfangenen Daten - gegebenenfalls nach einer Zwischenspeicherung in einem Pufferspeicher - an das zentrale OBU-Back-Office sendet.
  • Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass die bestehenden DSRC-Systeme nicht geändert werden müssen und uneingeschränkt im Rahmen der vorliegenden erfindungsgemäßen Lösung verwendet werden können. Der von der Bake ohnehin an die On-Board-Unit gesendete Datensatz wird lediglich weiterverarbeitet, sodass die eindeutige Baken-Information und ein Zeitstempel an das zentrale Back-Office übertragen werden.
  • Im Gegenzug werden die von der Bake empfangenen Daten der On-Board-Unit von der On-Board-Unit grundsätzlich nicht weiterverarbeitet. In einer alternativen Ausführungsform ist es jedoch möglich, die von der Bake empfangenen Daten der On-Board-Unit für Kontrollzwecke an weitere Instanzen, z.B. an den jeweiligen lokalen Mautbetreiber und/oder an das zentrale Back-Office weiterzuleiten. Diese Datenübertragung ist jedoch fakultativ und für die Funktion des Systems nicht notwendig.
  • Grundsätzlich kann sich die von den unterschiedlichen Mautbetreibern verwendete DSRC-Technik unterscheiden. Insbesondere hinsichtlich des verwendeten DSRC-Protokolls, hinsichtlich der verwendeten Frequenzen, der Signalcodierung etc. Ist es notwendig, mautbezogene Daten von verschiedenen Mautbetreibern - gegebenenfalls mit unterschiedlichen DSRC-Techniken - auszutauschen, so muss eine Interoperabilität zwischen den jeweiligen DSRC-Techniken gewährleistet sein.
  • Dies ist erfindungsgemäß möglich. Aufgrund der erfindungsgemäß erweiterten Funktionalität der On-Board-Unit ist es möglich, dass diese automatisch ihre Position erkennt. In der bevorzugten Ausführungsform der Erfindung ist es vorgesehen, dass die On-Board-Unit ihre Position automatisch über die Erfassung von satellitengestützten Positionsdaten erkennt. Diese Daten können mit einem Geofile abgeglichen werden, sodass es möglich wird, automatisch zu erfassen, in welchem Mautbetreiber-Gebiet sich das Fahrzeug aktuell befindet. Ist es vorgesehen, dass nur jeweils ein Mautbetreiber für ein Land in das System eingebunden werden soll, so kann die Information über den Mautbetreiber über die Länderkennung erhalten werden. In der Regel gibt es aber mehrere Mautbetreiber in einem Land (z.B. auch für Privatstrassen), sodass es notwendig ist, festzustellen, in welchem Mautbetreiber-Gebiet sich das Fahrzeug befindet. Anhand der erfassten Daten in bezug auf den jeweils aktuellen Mautbetreiber kann die OBU anschließend automatisch ermitteln, welche Kommunikations-Technik der jeweilige Mautbetreiber verwendet, z.B. welches Protokoll und/oder die erforderliche Syntax und/oder Semantik für den Datenaustausch. Daran anschließend kann die On-Board-Unit die Schnittstelle zwischen der Bake und der On-Board-Unit automatisch konfigurieren, in Abhängigkeit von der ermittelten Kommunikations-Technik des Mautbetreibers. Damit wird es möglich, dass die On-Board-Unit die Schnittstelle zwischen der Bake und der On-Board-Unit jeweils automatisch spezifisch konfiguriert, in Abhängigkeit von den Anforderungen des jeweils aktuellen Mautbetreibers. Damit entsteht der sich in der Praxis als sehr wesentlich erweisende Vorteil, dass ein und dieselbe On-Board-Unit für unterschiedliche DSRC-Gebiete und/oder für unterschiedliche physikalische Ausprägungen der DSRC-Technik verwendet werden kann. Im Gegensatz zum Stand der Technik ist es nicht mehr notwendig, ein DSRC-Tag gegen ein anderes auszutauschen bzw. die jeweilige On-Board-Unit von Hand (in der Regel vom Benutzer des Fahrzeugs) umzuprogrammieren.
  • Damit kann die Flexibilität des Mauterfassungs-Systems deutlich gesteigert werden, indem die aktuellen Voraussetzungen für den Datenaustausch automatisch erfasst und umgesetzt bzw. generiert werden. Darüber hinaus kann die Fehlergefahr durch einen falschen bzw. fehlerhaften Datenaustausch und/oder durch eine falsche Anpassung an die jeweiligen Erfordernisse hinsichtlich des Datenaustauschs deutlich gesenkt werden.
  • Die vom Fahrzeug befahrene Strecke gehört einem mautpflichtigen Straßennetz an. Es gibt grundsätzlich mehrere Möglichkeiten für die Ausbildung des jeweiligen mautpflichtigen Straßennetzes:
    • 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.
  • Zum anderen kann das Straßennetz ein offenes System sein, wie z.B. in Österreich. Der Begriff ,offen' soll hier kennzeichnen, dass das Ein- und Ausfahren in das / aus dem mautpflichtige/n Straßennetz nicht notwendigerweise mit der Durchfahrt durch eine Bake gekoppelt sein muss. Dann wird bei der Durchfahrt durch eine Bake eine vorbestimmbare mautpflichtige Streckenlänge definiert. Diese mautpflichtige Streckenlänge in Bezug auf die Bake gehört in diesem Fall ebenfalls zu den mautbezogenen Daten und ist in dem Back-Office hinterlegt.
  • Die befahrene Strecke kann erfindungsgemäß im Back-Office berechnet werden. Das erfindungsgemäße Verfahren und insbesondere die Berechnung der befahrenen Strecke werden unabhängig davon ausgeführt, ob es sich bei dem mautpflichtigen Streckennetz um ein offenes oder um ein geschlossenes System handelt.
  • In einer bevorzugten Ausführungsform umfasst das Verfahren zusätzlich folgende Verfahrensschritte:
    • 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 der bevorzugten Ausführungsform ist die erfindungsgemäße On-Board-Unit mit einem Positions-Erfassungs-Modul ausgebildet, sodass es möglich wird, automatisch die exakte Position des Fahrzeugs zu bestimmen. In der Regel erfolgt dies satelliten-gestützt, über einen entsprechenden GPS-Receiver und/oder über einen Galileo-Receiver oder ähnlichen Empfangsgeräten für satelliten-gestützte Positionsdaten. Aufgrund der erfassten Positionsdaten ist es möglich, dass die erfindungsgemäße On-Board-Unit eine Aktivierung und/oder eine Deaktivierung der Schnittstelle zwischen der On-Board-Unit und der Bake initiiert. In dieser Ausführungsform ist es vorgesehen, dass die On-Board-Unit automatisch erfasst, ob sich das Fahrzeug gerade in einem Gebiet eines Mautbetreibers mit DSRC-Kommunikation befindet und falls ja, die Baken-Schnittstelle aktiviert und/oder anderenfalls die Baken-Schnittstelle deaktiviert. Dies hat den Vorteil, dass ein ungewollter Datenaustausch über die Schnittstelle vermieden werden kann.
  • In einer weiteren, vorteilhaften Ausführungsform der Erfindung ist die Baken-Schnittstelle so ausgelegt, dass jede Bake zumindest eine ein-eindeutige Baken-Identifikation und/oder einen Zeitstempel der Datenerhebung an die jeweilige On-Board-Unit des passierenden Fahrzeugs überträgt. In alternativen Ausführungsformen der Erfindung können weitere Datensätze, z.B. Daten in Bezug auf Vorgänger- und/oder Nachfolger-Baken etc. übertragen werden.
  • In der Regel basiert die Kommunikation zwischen der Bake und der On-Board-Unit auf der DSRC-Kommunikations-Technik. Grundsätzlich ist es möglich, hier unterschiedliche physikalische Ausprägungen des DSRC-Standards, wie z.B. den CEN-Standard (Comite Europeen de Normalisation / European Commitee for Standardisation) oder den UNI-Standard (UNlnfo Italian Standard UN110607).
  • Die Back-Office-Schnittstelle, das heißt die Schnittstelle zwischen der On-Board-Unit und dem Back-Office, ist in der Regel so ausgelegt, dass die On-Board-Unit alle mautbezogenen Daten des Fahrzeugs, insbesondere den Datenaustausch mit den befahrenen Baken, an das zentrale Back-Office überträgt. In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass das zentrale Back-Office nach der Übertragung der mautbezogenen Daten von der On-Board-Unit an das Back-Office eine entsprechende Empfangsquittierung an die On-Board-Unit zurücksendet, die einen fehlerfreien Kommunikations-Austausch signalisieren soll. Ebenso kann es vorgesehen sein, dass ein erfolgreicher Datenaustausch über die Baken-Schnittstelle, also zwischen der On-Board-Unit und der Bake, durch ein entsprechendes Signal an die On-Board-Unit und/oder an die Bake signalisiert wird.
  • Grundsätzlich sind unterschiedliche Modalitäten für die Übertragung der mautbezogenen Daten von der On-Board-Unit an das zentrale Back-Office vorgesehen. Zum einen ist es möglich, dass mehrere mautbezogene Datensätze in einem Pufferspeicher zwischengespeichert werden und nach konfigurierbaren Zeitintervallen und/oder abhängig vom Eintreten eines konfigurierbaren Ereignisses (z.B. das Abfahren einer bestimmten Strecke oder eine Anfrage des Back-Offices oder einer anderen Instanz) an das Back-Office übertragen werden. Zum anderen können die Daten unmittelbar an das Back-Office übertragen werden. Grundsätzlich sind die Modalitäten der Datenübertragung konfigurierbar. So ist es insbesondere einstellbar, nach welchem Zeitintervall oder nach welchem Ereignis die Daten übertragen werden sollen. Dies kann über eine entsprechende Benutzereingabe über eine Benutzer-Schnittstelle im Back Office erfolgen.
  • Üblicherweise handelt es sich bei den Schnittstellen, insbesondere bei der Baken-Schnittstelle und bei der Back-Office-Schnittstelle um Luft-Schnittstellen. Der Datenaustausch kann über das Mobilfunknetz abgewickelt werden. Alternativ ist es möglich, Infrarot-Schnittstellen oder andere drahtlose Schnittstellen vorzusehen.
  • Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass die Schnittstellen, insbesondere die Schnittstellen zwischen den On-Board-Units und dem Back-Office, einheitlich ausgebildet sind. Dies hat den Vorteil, dass Erweiterungen des Systems leicht umgesetzt werden können.
  • Im Unterschied zu den Systemen aus dem Stand der Technik ist die Schnittstelle, insbesondere die Back-Office-Schnittstelle - also die Schnittstelle zwischen der On-Board-Unit und dem zentralen Back-Office - unabhängig vom Mautbetreiber. Damit wird es möglich, ein- und dieselbe On-Board-Unit für eine Vielzahl von unterschiedlichen Mautbetreibern zu verwenden, ohne dass weitere Umkonfigurationen notwendig sind.
  • In der bevorzugten Ausführungsform der Erfindung ist es vorgesehen, dass alle mautbezogenen Datenströme in dem zentralen Back-Office zusammenfließen. Das zentrale Back-Office ist entsprechend mit Schnittstellen zu dem jeweils angebundenen Mautbetreibern ausgebildet und/oder gegebenenfalls zu weiteren Instanzen, wie z.B. zu Transaktionssystemen, Abrechnungssystemen etc. Es ist jedoch auch möglich, lediglich eine Schnittstelle zu Abrechnungssystemen vorzusehen, je nachdem für welche Anwendung das erfindungsgemäße System eingesetzt werden soll.
  • Die vorliegende Erfindung ist insbesondere auf die Interoperabilität zwischen unterschiedlichen mautbezogenen Systemen bzw. unterschiedlichen Mautbetreibern gerichtet. Mit der hier vorgestellten Lösung ist es möglich, dass ein internationaler Nutzer, also ein Nutzer eines Fahrzeugs in internationalem Betrieb auch ein ausländisches DSRC-System nutzen kann und sich nur einmal registrieren muss. Erfindungsgemäß ist es nicht mehr notwendig, sich bei jedem Mautbetreiber erneut zu registrieren und dezentral abzurechen. Die Registrierung und/oder die Abrechnung bzw. die Mauterhebung erfolgt nur einmal, vorzugsweise bei einem örtlichen Mautbetreiber und/oder bei einem Abrechnungs-Partner. Bei der Registrierung gibt der Nutzer alle Länder an, in denen er eine Mauterhebung wünscht. Es ist jedoch auch möglich, die Angabe der Länder, in denen das System aktiviert sein soll, nachträglich anzugeben. Eine nachträgliche Auswahl von Ländern ist jederzeit und einfach möglich und wird in dem zentralen Back-Office gespeichert. Nach der Registrierung werden die Fahrzeugdaten und alle weiteren Registrierungsdaten im zentralen Back-Office des Europa-OBU-Systems gespeichert und der Nutzer erhält eine Europa-OBU mit einer eindeutigen Identifikations-Nummer, eine so genannte OBU-ID.
  • Für die Mautberechnung ist es wesentlich, dass ein Fahrzeug eindeutig identifiziert werden kann, um dem Fahrzeug die automatisch ermittelten, mautbezogenen Datensätze auf ein-eindeutige Weise zuordnen zu können. Erfindungsgemäß sind dafür zwei Möglichkeiten vorgesehen:
    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.
  • Bei der zweiten Variante gibt es wiederum zwei Möglichkeiten:
    • 2a. Separate Übertragung:
  • Nach der Registrierung eines Fahrzeugs bei einem lokalen Mautbetreiber sendet der jeweilige Mautbetreiber eine entsprechende Mapping-Information zurück an das Europa-OBU-System. Die Mapping-Information wird vorzugsweise in Form einer Mapping-Tabelle in dem Europa-OBU-System verwaltet, sodass eine ein-eindeutige Zuordnung zwischen örtlicher OBU-ID und zentraler Europa-OBU-ID gewährleistet ist. Die Übertragung der ID erfolgt für jede Registrierung einzeln.
    • 2b. Paketweise Übermittlung der Identifikations-Nummern:
  • Alternativ zum vorstehend genannten Vorgehen ist es ebenso möglich, dass ein Mautbetreiber bei Bedarf einen kompletten Nummernkreis an Identifikations-Nummern seines lokalen Systems vorab an das Europa-OBU-System sendet. In diesem Fall erfolgt keine Information über den neuen Nutzer bei dem lokalen örtlichen Mautbetreiber. Stattdessen wird im zentralen Europa-OBU-System automatisch die nächste freie Identifikations-Nummer des örtlichen Mautbetreibers für eine Identifikation eines Fahrzeugs herangezogen. Dies erfolgt über den Zugriff auf die Mapping-Tabelle, in der - wie vorstehend beschrieben - eine ein-eindeutige Relation zwischen den beiden ldentifikations-Nummern abgelegt ist.
  • In den Fällen 2a) und 2b) arbeitet das zentrale Europa-OBU-System mit dem Nummernkreis bzw. mit den Identifikations-Nummern der lokalen Mautbetreiber.
  • Insbesondere in den Fällen 2a) werden alle aktivierten Mautbetreiber über die Vergabe einer Identifikations-Nummer für ein registriertes Fahrzeug informiert. Damit wird gewährleistet, dass das System interoperabel ist und auch im internationalen Einsatz zur Anwendung kommen kann. Des Weiteren kann damit sichergestellt werden, dass stets die korrekte lokale bzw. örtliche OBU-Identifikations-Nummer (laut Mapping-Tabelle) herangezogen wird. Im Fall 2b muss die vorstehend genannte Informationsübermittlung nicht zwingend stattfinden. Der Mautbetreiber gibt einen Nummernkreis frei, der dann auch aktiviert werden kann. In diesem Fall weiß der Mautbetreiber nicht, wann eine ID mit der Europa OBU gemappt wird.
  • Alle von dem lokalen Mautbetreiber an das zentrale Europa-OBU-System übermittelten Identifikations-Nummern werden bei dem jeweiligen lokalen Mautbetreiber als gültige Identifikations-Nummern gekennzeichnet. Dies gilt auch für paketweise übermittelte Identifikations-Nummern und für in der Vergangenheit bereits übermittelte Nummernkreise.
  • Eine weitere Flexibilität der erfindungsgemäßen Lösung ist darin zu sehen, dass ein Fahrzeug bzw. dessen Nutzer sich in dem OBU-System auf unterschiedliche Art und Weise registrieren kann: Zum einen kann er sich bei dem örtlichen Mautbetreiber registrieren, der dann über eine Schnittstelle die Registrierungsdaten an das zentrale OBU-System weiterleitet. Zum anderen kann er sich auch direkt bei dem Europa-OBU-System zentral registrieren.
  • Damit ein hoher Sicherheitslevel sichergestellt werden kann, ist in der bevorzugten Ausführungsform ein Sicherheits-Mechanismus vorgesehen, der die Schnittstelle zwischen der On-Board-Unit und dem zentralen Back-Office überwacht. Insbesondere soll damit erreicht werden, dass ein Übertragen von manipulierten Datensätzen beschränkt bzw. vollständig ausgeschlossen werden kann.
  • Der Sicherheits-Mechanismus hat folgende Funktion:
    In vorbestimmbaren zeitlichen Abständen, die über eine Benutzer-Schnittstelle parametrisierbar sind, generiert die On-Board-Unit und das zentrale Back-Office einen gemeinsamen OBU-abhängigen Session-Key. Dieser Key wird auf der Basis eines asymmetrischen Schlüsselpaares generiert und ist nur für eine gewisse Zeit gültig. Die Zeitdauer der Gültigkeit des Schlüsselpaares ist ebenfalls einstellbar.
  • Erst nach erfolgreicher Generierung eines Session-Keys ist die On-Board-Unit erhebungsbereit und kann Daten von der Bake empfangen. Vor der Generierung eines Session-Keys oder bei einer nicht erfolgreichen Generierung desselben ist die Schnittstelle zwischen der On-Board-Unit und der Bake deaktiviert. Schlägt der Versuch einer Generierung des Session-Keys fehl, kann zumindest ein erneuter Wiederholungsversuch gestartet werden. Wieviele Wiederholungsversuche möglich sind, ist ebenfalls voreinstellbar. Schlägt die Generierung - gegebenenfalls nach mehrfachen Wiederholungsversuchen - fehl, wird die On-Board-Unit alle Kommunikationsanfragen bzw. alle Transaktionen mit dem DSRC-System negativ quittieren oder alternativ auf die DSRC-Anfragen keine Antwort geben. Die örtliche DSRC-Bake erkennt diese negative bzw. fehlgeschlagene Kommunikation und kann aufgrund der erfassten Fehlkommunikation entsprechende weitere Maßnahmen einleiten. Üblicherweise wird hier für den Mautpreller ein so genannter Enforcement-Prozess eingeleitet. Falls die Lebenszeit eines Session-Keys abgelaufen ist, so ist es vorgesehen, dass die On-Board-Unit rechtzeitig und im Vorfeld einen neuen Session-Key erzeugt.
  • Eine weitere Sicherheitsmaßnahme besteht darin, sicherzustellen, dass alle von der Bake gesendeten mautbezogenen Daten, die in der On-Board-Unit gespeichert werden, auch an das Back-Office weitergeleitet werden. Liegt nun ein Fehler in der Schnittstelle zwischen der On-Board-Unit und dem zentralen Back-Office vor, sodass eine Übertragung dieser mautbezogenen Daten nicht mehr möglich ist, so muss sichergestellt sein, dass die bisher erhobenen Daten in der On-Board-Unit nicht verloren gehen. Zu diesem Zweck ist es vorgesehen, dass überprüft wird, ob nach einer konfigurierbaren Anzahl an empfangenen DSRC-Datensätzen diese auch erfolgreich an das Back-Office übertragen worden sind. Für die maximale Anzahl kann ein Schwellwert definiert werden. Ist dieser Schwellwert der maximalen Einträge überschritten worden, ohne dass eine erfolgreiche Übertragung an das Back-Office stattgefunden hat, wird die Schnittstelle zwischen der On-Board-Unit und der Bake deaktiviert. Das heißt die On-Board-Unit stellt jegliche DSRC-Kommunikation ein. Das führt dazu, dass keine neuen Daten erhoben werden und die bisher erfassten Daten werden in dem Pufferspeicher weiter gespeichert.
  • Bei allen der vorstehend genannten Sicherheitsmaßnahmen wird in sicherheitskritischen Fällen, das heißt in Fällen, die zu einer nicht-erhebungsbereiten On-Board-Unit führen, der Nutzer des Fahrzeugs durch ein Signal auf die Störung hingewiesen wird. Das Signal kann akustisch und/oder visuell erfolgen. Das Signal dient als Hinweis, dass eine Weiterfahrt nicht möglich ist, da die On-Board-Unit nicht erhebungsbereit ist. Er wird deshalb aufgefordert, die mautpflichtige Straße zu verlassen. Alternativ oder kumulativ kann es vorgesehen sein, dass das Fehlersignal an die Bake und/oder an das zentrale Back-Office gesendet wird. Damit ist es möglich, weitere Recovery-Maßnahmen einzuleiten.
  • Eine weitere Aufgabenlösung liegt in einer Vorrichtung bzw. in einem Gerät zur Verarbeitung von mautbezogenen Daten eines Fahrzeugs, wobei das Fahrzeug mit einer On-Board-Unit ausgestattet ist, die ihrerseits eine Baken-Schnittstelle zur Datenübertragung mit einer Vielzahl von auf Straßen angeordneten Baken und die eine Back-Office-Schnittstelle zur Übertragung mit einem zentralen Back-Office umfasst, wobei das Back-Office zur Verarbeitung der mautbezogenen Daten bestimmt ist und wobei der Datenaustausch zwischen der Bake und der On-Board-Unit insbesondere auf einer DSRC-Kommunikations-Technik basiert.
  • Die erfindungsgemäße On-Board-Unit kann demnach auch als "virtuelles DSRC-Tag" bezeichnet werden. Sie ist vorzugsweise in Form eines integrierten Schaltkreises ausgebildet und somit eine intelligentere und komplexere Lösung als das bisherige DSRC-Tag. Der erfindungsgemäße virtuelle DSRC-Tag kennzeichnet sich durch eine erhöhte Funktionalität. Im Gegensatz zu bisherigen Systemen ist die erfindungsgemäße On-Board-Unit dazu ausgelegt, mautbezogene Daten, die sie von der Bake empfängt, zwischenzuspeichern und diese nach einem konfigurierbaren Zeitintervall an das zentrale Back-Office über die Back-Office-Schnittstelle weiterzuleiten.
  • Die Vorteile, Merkmale und alternativen Ausführungsformen, die vorstehend in bezug auf das erfindungsgemäße Verfahren erwähnt worden sind, sollen entsprechend auch für die erfindungsgemäße Vorrichtung gelten.
  • Ein besonderer Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass die Verfahrensschritte, vorzugsweise alle Verfahrensschritte, automatisch ausgeführt werden. Es ist nicht mehr notwendig, dass der Nutzer manuell in das Verarbeitungsgeschehen eingreift. Damit kann die Fehleranfälligkeit des Gesamtsystems deutlich reduziert werden.
  • Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird und dessen Programmcode durch einen Prozessor ausgeführt wird.
  • Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computer-implementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
  • Darüber hinaus ist es möglich, dass einzelne Komponenten des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit - sozusagen als verteiltes System - ausgeführt werden können.
  • Weitere vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
  • In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
    • 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.
  • Die nachstehende detaillierte Figurenbeschreibung ist im Hinblick auf die bevorzugte Anwendung der erfindungsgemäßen Lösung beschrieben, die auf die Mauterhebung ausgerichtet ist. In alternativen Ausführungsformen kann die Erfindung jedoch ebenso zur anderweitigen Verarbeitung der mautbezogenen Daten verwendet werden. Neben der Mauterhebung sind hier z.B. die Verwendung in anderweitigen Abrechnungssystemen, Clearing-Systeme, Flotten-Management-Systeme oder dergleichen zu nennen.
  • Jedes Fahrzeug, das das Europa-OBU-System nutzen möchte, ist mit einer On-Board-Unit OBU ausgestattet. Die Mauterfassung basiert auf der DSRC-Technik. Auf einer mautpflichtigen Straße sind Baken 16 angeordnet, die elektronische Module umfassen, die zum Datenaustausch mit einem entsprechenden Modul im Fahrzeug bestimmt sind. Bei den Verfahren im Stand der Technik handelte es sich bei den elektronischen Modulen, die im Fahrzeug angeordnet sind, um so genannte DSRC-Tags. Die Funktionalität der bisher bekannten DSRC-Tags ist von der Funktionalität der erfindungsgemäß eingesetzten On-Board-Units OBU umfasst. Die erfindungsgemäßen On-Board-Units OBU weisen eine komplexere Funktionalität auf und umfassen vorzugsweise einen Pufferspeicher 10, der die von der Bake 16 empfangenen Daten zwischenspeichern kann.
  • Wie in Fig.1 gezeigt, besteht die On-Board-Unit OBU aus einer Empfangseinheit zum Empfang von mautbezogenen Daten von der Bake 16 und aus einer Sendeeinheit, die dazu bestimmt ist, die so empfangenen Daten an ein zentrales Back-Office BO weiterzuleiten. Die Schnittstelle zwischen dem Back-Office BO und der On-Board-Unit OBU ist als Back-Office-Schnittstelle BoSS gekennzeichnet. Die Schnittstelle zwischen der On-Board-Unit OBU und der Bake 16 ist als Baken-Schnittstelle BSS gekennzeichnet.
  • Die Verarbeitung der mautbezogenen Daten, insbesondere die Mauterhebung erfolgt zentral im Back-Office BO. Dazu werden die mautbezogenen Daten nicht mehr wie bisher von der Bake 16 an das Back-Office BO übertragen, sondern von der mobilen On-Board-Unit OBU über die Back-Office-Schnittstelle BoSS.
  • Wie in Fig.1 durch eine gepunktete Linie dargestellt, ist es möglich, aber nicht zwingend erforderlich, dass die Bake 16 mautbezogene Daten in Bezug auf ein passierendes Fahrzeug an einen lokalen Mautbetreiber sendet. Erfindungsgemäß ist dies lediglich dann vorgesehen, wenn ein zusätzliches Kontrollverfahren gewünscht wird. Der lokale Mautbetreiber empfängt dann mautbezogene Daten sowohl vom zentralen Back-Office BO, als auch von der Bake 16 selbst. Vorzugsweise sendet die Bake 16 jedoch keine Daten an den lokalen Mautbetreiber. Die dezentral organisierten lokalen Mautbetreiber sind über eine entsprechende Transaktions-Schnittstelle an das zentrale Back-Office BO angeschlossen.
  • Nachstehend wird das grundsätzliche Vorgehen gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens dargestellt.
  • Ein Fahrzeug registriert sich beim lokalen Mautbetreiber oder beim Back-Office BO, und erhält eine Identifikations-Nummer, über die sein Fahrzeug eindeutig identifizierbar wird. Falls sich der Nutzer beim lokalen Mautbetreiber registriert hat, werden die Registrierungsdaten über die Transaktions-Schnittstelle an das zentrale Back-Office BO übermittelt. Bei dem Registrierungsvorgang kann der Nutzer angeben, in welchen Ländern bzw. in welchen Gebieten er eine Freischaltung des erfindungsgemäßen Verfahrens bzw. der Mauterhebung wünscht. Es ist jedoch auch möglich, nachträglich, also sozusagen während der Fahrt, weitere Gebiete bzw. weitere Länder nachzuschalten.
  • In der bevorzugten Ausführungsform umfast die On-Board-Unit OBU eine Positions-Erfassungs-Einheit, die dazu bestimmt ist, die aktuelle Position des Fahrzeugs zu erfassen. Unter Zugriff auf ein Geofile kann die On-Board-Unit OBU selbständig und automatisch ermitteln, ob sich das Fahrzeug zurzeit in einem der registrierten Mautbetreiber-Gebiete befindet. Üblicherweise handelt es sich bei den Gebieten um DSRC-Gebiete. Falls sich das Fahrzeug nicht in einem solchen Gebiet befindet, bleiben die Schnittstellen deaktiviert. Anderenfalls kann die On-Board-Unit OBU automatisch ermitteln auf welcher Kommunikations-Technik der Datenaustausch des jeweiligen Mautbetreibers basiert. Die On-Board-Unit OBU erkennt also automatisch, welche schnittstellen-spezifischen Parameter für den Datenaustausch zwischen der On-Board-Unit OBU und der aktuellen Bake 16 notwendig sind, insbesondere welches Übertragungsprotokoll, welche Codierung etc. notwendig ist. Entsprechend den ermittelten kommunikations-technischen Daten konfiguriert die On-Board-Unit OBU automatisch und selbständig die Baken-Schnittstelle BSS zwischen der On-Board-Unit OBU und der Bake 16.
  • Aufgrund des automatisch agierenden Konfigurations-Moduls ist es möglich, dass eine einheitliche On-Board-Unit OBU für unterschiedliche Mautbetreiber verwendbar ist, ohne dass der Nutzer eingreifen muss, z.B. durch Austausch von DSRC-Tags - wie bisher - oder durch Umschalten von bestimmten Funktionen.
  • Passiert ein Fahrzeug mit einer registrierten On-Board-Unit OBU nun eine Bake 16, so sendet die On-Board-Unit OBU ihre OBU-Identifikations-Nummer an die Bake 16 und erhält von der Bake 16 alle maut-relevanten Daten. Alternativ ist es auch möglich, dass (evtl. kumulativ) auch die örtliche (gemappte) OBU ID gesendet wird, falls dies der Mautbetreiber wünscht. Bei den maut-relevanten Daten handelt es sich in diesem Fall um eine Baken-Identifikations-Nummer und um einen Zeitstempel für eine Erhebung des Datensatzes. In alternativen Ausführungsformen ist es jedoch auch möglich, hier weitere Daten der Bake 16 oder anderer Instanzen zu übertragen. Der Vorteil dieser Ausführungsform ist darin zu sehen, dass das Übertragungsverfahren zwischen der On-Board-Unit OBU und der Bake 16 aus den bisher bekannten Systemen vollständig beibehalten werden kann und nicht verändert werden muss.
  • In einer alternativen vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, den bisher bekannten Datenaustausch zwischen On-Board-Unit OBU und Bake 16 dahingehend zu verändern, dass die Bake 16 nur als Sende-Einheit ausgebildet ist. Die Bake 16 empfängt dann keine Daten, insbesondere keine Identifikations-Nummer der On-Board-Unit OBU und kann demnach diese auch nicht mehr an lokale Mautbetreiber zu Kontrollzwecken weiterleiten. Sie ist lediglich dazu ausgelegt, baken-spezifischen Daten und gegebenenfalls weitere mautbezogenen Daten an die On-Board-Unit zu übertragen.
  • Die von der On-Board-Unit OBU empfangenen mautbezogenen Daten können entweder unmittelbar an das zentrale Back-Office BO weitergeleitet werden oder in einem Pufferspeicher 10 zwischengespeichert werden. Die Datenrecords, die in dem Pufferspeicher 10 gehalten werden, können über eine Schwelle bestimmt werden. Sobald die Schwelle erreicht ist, werden die Datenrecords aus dem Pufferspeicher 10 der On-Board-Unit OBU über die Back-Office-Schnittstelle BoSS an das Back-Office BO weitergeleitet.
  • Passiert ein Fahrzeug nun eine Vielzahl von DSRC-Gebieten verschiedener Mautbetreiber, so ist es erfindungsgemäß möglich, dass all die mautbezogenen Daten der verschiedenen Mautbetreiber zentral im Back-Office BO verarbeitet werden. Dazu ist das Back-Office BO mit einer Transaktions--Einheit 14 ausgebildet, die dazu bestimmt ist, die akkumulierten mautbezogenen Datensätze zu einem Gesamtergebnis für die Mauterhebung zu verarbeiten. Die erhobene Maut wird dann über die Schnittstelle an den jeweiligen Mautbetreiber zugeführt, bei dem sich der Nutzer registriert hat. Damit wird es möglich, ein interoperables Mautsystem zur Verfügung zu stellen, dessen Verwaltungsaufwand durch die zentrale Verarbeitung deutlich minimiert werden kann und insgesamt einfacher ausgebildet ist und mehr Funktionalität bietet.
  • Die Back-Office-Schnittstelle BoSS basiert vorzugsweise auf einem proprietären Protokoll. In einer alternativen Weiterbildung der Erfindung ist es jedoch auch möglich, hier ein anderes bekanntes Protokoll einzusetzen. Die Baken-Schnittstelle BSS basiert auf der DSRC-Kommunikations-Technik. Es sind jedoch grundsätzlich unterschiedliche physikalische Ausprägungen der DSRC-Technik möglich. Die jeweilige physikalische Ausprägung der verwendeten DSRC-Technik des jeweiligen Mautbetreibers kann von der On-Board-Unit OBU automatisch erkannt werden. Diese Information wird erfindungsgemäß für die Konfiguration der Baken-Schnittstelle BSS verwendet.
  • Die unterschiedlichen Mautbetreiber arbeiten mit eigenen Identifikations-Nummer-Kreisen. Ein besonderer Vorteil der Erfindung ist darin zu sehen, dass die Identifikations-Nummern der lokalen Mautbetreiber auch in dem Europa-OBU-System verwendet werden können. Dazu umfasst das Back-Office BO eine Mapping-Einheit 12. Die Verwaltung der Mapping Tabelle erfolgt im Back Office BO. Ein aktueller Auszug der Tabelle muss jedoch in der On-Board- Unit OBU gehalten werden, um ggf. die korrekte OBU-ID verwenden zu können. Die Mapping-Einheit 12 ist ausgelegt, um eine ein-eindeutige Zuordnungsvorschrift zwischen den lokalen Identifikations-Nummern des Mautbetreibers und den Identifikations-Nummern des zentralen OBU-Systems vorzusehen. Damit wird es möglich, dass das Europa-OBU-System wahlweise mit einer zentralen Identifikations-Nummern-Vergabe arbeitet oder mit den Identifikations-Nummern des lokalen Mautbetreibers.
  • Üblicherweise ist die Vergabe von Identifikations-Nummern aus dem OBU-ID-Nummernkreis, den ein Mautbetreiber zur Verfügung stellen kann, so organisiert, dass die jeweiligen Identifikations-Nummern listenartig zur Verfügung stehen und sequenziell bei jeder neuen Registrierung eines Fahrzeuges verwendet werden.
  • Wie in Fig.2 dargestellt, ist es erfindungsgemäß möglich, einen interoperablen Austausch zwischen einer beliebigen Anzahl von Mautbetreibern zur Verfügung zu stellen. Die jeweiligen Mautbetreiber befinden sich über die DSRC-Schnittstelle mit den jeweiligen Baken 16 im Datenaustausch und stehen neben dem Datenaustausch mit dem zentralen Back-Office BO zusätzlich noch untereinander in Datenaustausch. Dies erfolgt üblicherweise über eine einheitliche Transaktions-Schnittstelle und/oder über eine einheitliche Schnittstelle zum Austausch von Nutzer-, Fahrzeug- und/oder Identifikations-Nummern-Daten. Alternativ können noch zusätzliche weitere mautbezogene Daten über diese Schnittstelle ausgetauscht werden. Durch die erfindungsgemäße zentrale Verarbeitung im Back-Office kann der Synchronisations-Aufwand deutlich gesenkt werden. Darüber hinaus sind System-Erweiterungen einfach realisierbar. Im Gegensatz zu bekannten Verfahren ist es nicht mehr notwendig, dass sich ein Nutzer auch in einem solchen Mautbetreiber-Gebiet registriert, in dem er nicht fahren wird. Damit können die Transaktions- und die Verwaltungskosten gesenkt werden.
  • In der bevorzugten Ausführungsform der Erfindung ist das Back-Office BO als Europa-OBU-System ausgebildet. Alle Fahrzeugdaten werden zentral im Europa-OBU-System gespeichert. Damit kann eine internationale Nutzung des Systems deutlich vereinfacht werden, indem ein Nutzer auch ausländische DSRC-Systeme nutzen kann, ohne dass er ein neues DSRC-Tag einsetzen muss oder dass ohne weitere manuelle Eingriffe notwendig sind.
  • In Fig.3 ist der zeitliche Verlauf der erfindungsgemäßen Mauterhebung dargestellt. Dabei erfolgt der Zeitlauf entsprechend dem von links nach rechts weisenden Pfeil in Fig.3. Die in den Kreisen dargestellten Nummern 1 bis 6 kennzeichnen folgende Verfahrensschritte:
    Nach einer erfolgreichen Registrierung des Nutzers im Europa-OBU-System wird bei Punkt 1 von der On-Board-Unit OBU und von dem Europa-OBU-Back-Office BO ein Session-Key generiert.
    Passiert nun das Fahrzeug eine Bake 16, so erfolgt eine DSRC-Kommunikation zwischen der On-Board-Unit OBU und der Bake 16. Die DSRC-Bake 16 erkennt die On-Board-Unit OBU bzw. den virtuellen DSRC-Tag und generiert selbst keinen Transaktions-Datensatz für den eigenen Mautbetreiber. Die DSRC-Baken-Daten werden in der On-Board-Unit OBU in einer Transaktions-Liste gespeichert.
    Wie bei Punkt 3 gekennzeichnet, werden nach dem Passieren der n-ten Bake alle bisher gesammelten DSRC-Transaktions-Daten über eine Luftschnittstelle an das Europa-OBU-Back-Office BO übertragen. Dabei ist der Parameter n konfigurierbar. Die Konfiguration des Parameters n ist abhängig von örtlichen Bestimmungen, wie der maximalen Verweildauer von Transaktionen in der On-Board-Unit OBU, vom Kreditlimit des Nutzers, von der örtlichen Position (Grenzüberschreitung), von der Speicherkapazität der Transaktions-Liste und/oder von dem maximalen Zeitintervall zwischen zwei Kommunikationszyklen der On-Board-Unit OBU.
    In Punkt 4 soll dargestellt sein, dass das zentrale Back-Office BO auf die Transaktions-Einheit 14 zugreift, in der eine Tariftabelle abgelegt ist. Das Back-Office BO kann die eingelesene DSRC-Transaktion somit bepreisen. Das Back-Office BO sendet die ermittelte Mauterhebung und/oder die DSRC-Transaktionen an den jeweiligen Heimat-Mautbetreiber oder an einen zugeordneten Transaktions--Partner des Nutzers für die Fakturierung. Dies ist unter Punkt 5 dargestellt.
    Unter Punkt 6 ist dargestellt, dass der Heimat-Mautbetreiber die mautbezogenen Daten dem Nutzer übermittelt. Somit muss der Nutzer nur noch mit dem Heimat-Mautbetreiber interagieren und keine weiteren Handlungen bei fremden Mautbetreibern vornehmen, auch wenn er deren Gebiet durchfahren hat.
  • Die On-Board-Unit OBU erkennt anhand der aktuellen Position (die automatische Positions-Ermittlung erfolgt vorzugsweise satelliten-gestützt), ob sie sich in einem Gebiet eines DSRC-Mautbetreibers befindet. Falls ein DSRC-Gebiet erkannt wird, wird von der OBU-Applikation automatisch das integrierte DSRC-Modem konfiguriert. Es ist jedoch auch möglich, dass die On-Board-Unit OBU mit mehreren DSRC-Modems ausgestattet ist. Die Konfiguration erfolgt derart, dass eine Kommunikation auf der Basis der eingesetzten Technik des Mautbetreibers stattfinden kann. Das bedeutet, dass die OBU-Applikation das Protokoll und den semantischen Inhalt abhängig vom jeweiligen Mautbetreiber steuert. Lediglich für unterschiedliche physikalische Ausprägungen der DSRC-Technik (CEN, UNI) sind unterschiedliche DSRC-Module/-Modems in der On-Board-Unit OBU notwendig. Wie in Fig.4 dargestellt, ist das "Europa-OBU-System" das zentrale Back-Office BO. Hier laufen die mautbezogenen Daten zusammen und werden an die jeweiligen Mautbetreiber bzw. an deren Transaktions--Partner weiterverteilt. Die Mautbetreiber kommunizieren mit dem Back-Office BO über eine Schnittstelle, über die insbesondere die bereitgestellten Identifikations-Nummern-Kreise vergeben werden. Die Übergabe der Identifikations-Nummern kann automatisch aber auch manuell erfolgen. Das heißt, dass die Identifikations-Nummern-Kreise automatisch über eine Schnittstelle aus einer bereitgestellten Datei eingelesen werden können. Ebenso ist es möglich, dass die Nummern-Kreise auf anderen Kommunikations-Kanälen eingelesen werden, wie z.B. durch eine manuelle Eingabe über eine Benutzer-Schnittstelle, eine Eingabe über E-mail etc. Die Schnittstelle zwischen den jeweiligen Mautbetreibern und den von ihnen betriebenen Baken 16 kann vorteilhafter Weise unverändert bleiben. Eine Anpassung ist hier nicht erforderlich.
  • Das zentrale Europa-OBU-System BO kommuniziert mit den Transaktions- und/oder Transaktions--Partnern über eine einheitliche Transaktions-Schnittstelle, wodurch eine schnelle und eine einfache Interoperabilität geschaffen werden. Die Schnittstelle zwischen dem Back-Office bzw. dem Europa-OBU-System BO und den lokalen Mautbetreibern kann auch eine beliebige Schnittstelle und muss keine drahtlose Verbindung sein.
  • Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Für einen einschlägigen Fachmann ist es insbesondere offensichtlich, dass die Erfindung als heterogenes System teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte - dabei insbesondere auch Computerprogrammprodukte - verteilt realisiert werden kann.
    • Bezugszeichenliste: ,
    • OBU
    On-Board-Unit
    BO
    Back-Office
    BSS
    Baken-Schnittstelle
    BoSS
    Back-Office-Schnittstelle
    10
    Pufferspeicher
    12
    Mapping-Einheit
    14
    Transaktions-Einheit
    16
    Bake

Claims (15)

  1. Verfahren zum Verarbeiten von mautbezogenen Daten eines Fahrzeugs, wobei das Fahrzeug eine On-Board-Unit (OBU) umfasst, die mit einer Vielzahl von Baken (16), die auf einer befahrbaren Straße angeordnet sind, über eine Baken-Schnittstelle (BSS) in Datenaustausch steht, wobei die On-Board-Unit (OBU) die mautbezogenen Daten des Datenaustauschs zwischen der On-Board-Unit (OBU) und den von dem Fahrzeug befahrenen Baken (16) über eine Back-Office-Schnittstelle (BoSS) an ein zentrales Back-Office (BO) zur Verarbeitung der mautbezogenen Daten in Bezug auf die befahrene Strecke des Fahrzeugs weiterleitet.
  2. Verfahren nach Anspruch 1,
    dadurch gekennzeichnet, dass die On-Board-Unit (OBU) folgende Verfahrensschritte ausführt:
    - Automatisches Erfassen des jeweils aktuellen Mautbetreibers über eine satelliten-gestützte Positionserfassung des Fahrzeugs,
    - automatisches Ermitteln der von dem erfassten Mautbetreiber verwendeten Kommunikations-Technik, insbesondere eines Übertragungs-Protokolls,
    - automatisches Konfigurieren der Baken-Schnittstelle (BSS) in Abhängigkeit von der ermittelten Kommunikations-Technik des Mautbetreibers.
  3. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die On-Board-Unit (OBU) automatisch erfasst, ob sich das Fahrzeug in einem Gebiet eines Mautbetreibers mit einer DSRC-Kommunikation befindet, indem die On-Board-Unit (OBU) die Position des Fahrzeugs satelliten-gestützt erfasst, und falls ja, die Baken-Schnittstelle (BSS) aktiviert und/oder anderenfalls deaktiviert.
  4. Verfahren nach zumindest einem der vorstehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die Baken-Schnittstelle (BSS) so ausgelegt ist, dass jede Bake (16) zumindest eine eindeutige Baken-Identifikations-Kennziffer und/oder einen Zeitstempel für eine Datenerhebung an die jeweils passierende On-Board-Unit (OBU) überträgt.
  5. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die Back-Office-Schnittstelle (BoSS) so ausgelegt ist, dass die On-Board-Unit (OBU) alle mautbezogenen Daten des Fahrzeugs, insbesondere den Datenaustausch mit den befahrenen Baken (16), an das zentrale Back-Office (BO) überträgt.
  6. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die On-Board-Unit (OBU) die mautbezogenen Daten zwischenspeichert und in konfigurierbaren Zeitabständen und/oder in Abhängigkeit vom Eintreten zumindest eines konfigurierbaren Ereignisses an das Back-Office (BO) überträgt.
  7. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die Schnittstelle (BSS, BoSS) eine Luft-Schnittstelle ist.
  8. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    die Baken-Schnittstelle (BSS) automatisch konfigurierbar ist und/oder dass die Back-Office-Schnittstellen (BoSS) einheitlich und/oder unabhängig vom jeweiligen Mautbetreiber sind.
  9. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass an das Back-Office (BO) weitere Mautbetreiber und/oder weitere Instanzen zur Verarbeitung von mautbezogenen Daten angeschlossen werden können.
  10. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass jedem Fahrzeug unter Zugriff auf eine ein-eindeutige Zuordnungsvorschrift eine Identifikations-Nummer zugeordnet wird, die dezentral von einem örtlichen Mautbetreiber oder zentral von dem Back-Office (BO) vergeben werden kann.
  11. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die befahrene Strecke des Fahrzeugs, insbesondere eine Länge der befahrenen Strecke, im Back-Office (BO) berechnet wird.
  12. Verfahren nach zumindest einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet,
    dass die Strasse zumindest einem mautpflichtigen Straßennetz zugeordnet ist, das eine offenes oder ein geschlossenes System ist.
  13. Vorrichtung zur Verarbeitung von mautbezogenen Daten eines Fahrzeugs, wobei das Fahrzeug mit einer On-Board-Unit (OBU) ausgestattet ist, die ihrerseits eine Baken-Schnittstelle (BSS) zur Datenübertragung mit einer Vielzahl von auf Straßen angeordneten Baken (16), und die eine Back-Office-Schnittstelle (BoSS) zur Datenübertragung mit einem zentralen Back-Office (BO) umfasst, wobei das Back-Office (BO) zur Verarbeitung der mautbezogenen Daten bestimmt ist.
  14. Vorrichtung zur Verarbeitung von mautbezogenen Daten eines Fahrzeugs, umfassend Mittel, die zur Ausführung zumindest eines Schrittes und vorzugsweise aller Schritte eines Verfahrens nach zumindest einem der vorstehenden Verfahrens-Ansprüche eingerichtet sind.
  15. Vorrichtung zur Positionsbestimmung eines mobilen Geräts (OBU), mit wenigstens einem mobilen Gerät (OBU), das eine Schnittstelle zu einem Back Office (BO) aufweist, mit einem Back Office (BO), das eine Schnittstelle zu dem wenigstens einen mobilen Gerät (OBU) aufweist, und mit Mitteln zum Berechnen der Position des mobilen Geräts (OBU) anhand von "pseudo range" Daten, wobei diese Mittel im Back Office (BO) vorgesehen sind.
EP06004736A 2005-03-09 2006-03-08 Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen Not-in-force EP1708144B1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE200510010888 DE102005010888A1 (de) 2005-03-09 2005-03-09 Verfahren und Anordnung zur Positionsbestimmung
DE202005009152U DE202005009152U1 (de) 2005-03-09 2005-03-09 Anordnung zur Positionsbestimmung
DE102005030030A DE102005030030A1 (de) 2005-03-09 2005-06-27 System zur Verarbeitung von positions- und/oder mautbezogenen Daten für Fahrzeuge

Publications (3)

Publication Number Publication Date
EP1708144A2 true EP1708144A2 (de) 2006-10-04
EP1708144A3 EP1708144A3 (de) 2007-04-25
EP1708144B1 EP1708144B1 (de) 2010-12-15

Family

ID=36659950

Family Applications (2)

Application Number Title Priority Date Filing Date
EP06004736A Not-in-force EP1708144B1 (de) 2005-03-09 2006-03-08 Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen
EP06004735A Withdrawn EP1708143A3 (de) 2005-03-09 2006-03-08 System zur Verarbeitung von positions-und/oder mautbezogenen Daten für Fahrzeuge

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP06004735A Withdrawn EP1708143A3 (de) 2005-03-09 2006-03-08 System zur Verarbeitung von positions-und/oder mautbezogenen Daten für Fahrzeuge

Country Status (1)

Country Link
EP (2) EP1708144B1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2242024B1 (de) 2009-04-14 2015-02-25 Kapsch TrafficCom AG Verfahren, Komponenten und Systeme zum Erzeugen von Mauttransaktionen
EP3132648B1 (de) 2014-04-14 2019-06-12 Continental Teves AG & Co. OHG Verfahren zum verarbeiten einer fahrzeug-zu-x-nachricht, fahrzeug-zu-x-kommunikationsmodul und speichermedium

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1944736A1 (de) * 2007-01-12 2008-07-16 Brisa-Auto-Estradas de Portugal S.A. Drahtloses Multi-Service Bezahlungssystem für Fahrzeuge
DE102007045479A1 (de) * 2007-09-21 2009-04-02 Deutsche Telekom Ag Verfahren zur Ermittlung streckenbezogener Straßenbenutzungsentgelte mittels einer Anordnung aus Fahrzeugendgerät und Dienstezentrale
EP2256694A1 (de) 2009-05-25 2010-12-01 Kapsch TrafficCom AG Verfahren und Komponenten zum Erzeugen von Mauttransaktionen
PL2602767T3 (pl) * 2011-12-05 2014-05-30 Kapsch Trafficcom Ag Sposób i jednostka pokładowa do sygnalizowania transakcji opłat drogowych w systemie opłat drogowych
DK2624218T3 (da) 2012-02-02 2014-08-18 Kapsch Trafficcom Ag Indretning og fremgangsmåde til kontrol i et vejafgiftssystem
EP2709051B1 (de) * 2012-09-17 2017-03-22 Kapsch TrafficCom AG Verfahren zum elektronischen Verarbeiten eines Verkehrsdelikts und Onboard-Unit hierfür
SI2860703T1 (sl) 2013-10-08 2016-10-28 Kapsch Trafficcom Ag Postopek preverjanja cestninskih transakcij in sestavni deli le-tega
ES2563789T5 (es) * 2013-10-23 2022-04-07 Kapsch Trafficcom Ag Unidad de a bordo y servidor de transacciones para un sistema de peaje de carreteras
NO336505B1 (no) 2013-12-20 2015-09-14 Q Free Asa Sonedeteksjon i et GNSS-system
DE102014202587A1 (de) * 2014-02-13 2015-08-13 Continental Automotive Gmbh Mauterfassungseinrichtung zum Erfassen einer Maut eines Kraftfahrzeuges
EP3174015A1 (de) * 2015-11-27 2017-05-31 Toll Collect GmbH Erkennung von fehlern in einer von einem fahrzeug mitgeführten fahrzeugeinrichtung eines mautsystems
DE102018204504A1 (de) * 2018-03-23 2019-09-26 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Betreiben eines Mautsystems, computerlesbares Medium, und System
DE102020110659A1 (de) 2020-04-20 2021-10-21 Bayerische Motoren Werke Aktiengesellschaft Betreiben eines Fahrzeugs sowie Fahrzeug und System
EP3920149A1 (de) * 2020-06-04 2021-12-08 Toll Collect GmbH Verfahren zum ermitteln einer mautgebühr, fahrzeuggerät und mautsystem
CN113379936B (zh) * 2021-03-29 2022-07-08 李任永 一种省市级公路费用计算方法和装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5289183A (en) * 1992-06-19 1994-02-22 At/Comm Incorporated Traffic monitoring and management method and apparatus
WO2000045343A1 (en) * 1999-01-27 2000-08-03 Marcello Federici Automatic charging system for vehicles
WO2001084503A1 (en) * 2000-04-28 2001-11-08 Powercom Ventures As System for handling of tolling collection and fees related to road and parking facilities
DE10104499A1 (de) * 2001-01-31 2002-08-14 Daimler Chrysler Ag Strassengebührenerfassungssystem
US20040200899A1 (en) * 2003-04-08 2004-10-14 Bor-Shenn Jeng Automatic toll collection architecture and method combining short-range and long-range communication schemes

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19733579A1 (de) * 1997-08-02 1999-02-04 Kdm Sicherheitstechnik Gmbh Verfahren und Einrichtung zum Überwachen von Personen und/oder beweglichen Objekten
DE19755142B4 (de) * 1997-11-28 2004-03-18 Krönke, Matthias Verfahren und System zur Transport- und Positionsüberwachung beweglicher Objekte
DE19906529A1 (de) * 1999-01-18 2000-07-20 Volkswagen Ag System und Verfahren zur Erfassung und Übertragung von Fahrzeugpositionsdaten
EP1200937B1 (de) * 1999-08-04 2005-06-01 Vodafone Holding GmbH Mautsystem zur zentralen erhebung von nutzungsgebühren von fahrzeugen in einem gebührenpflichtigen wegstreckennetz
US6484096B2 (en) * 2000-06-06 2002-11-19 Satellite Devices Limited Wireless vehicle monitoring system
AT411941B (de) * 2000-11-28 2004-07-26 Frv Electronics Vertriebs Und Verfahren zum erfassen von mindestens einem fahrzeug bzw. verkehrsteilnehmer auf öffentlichen verkehrsflächen
DE10155501A1 (de) * 2001-11-13 2003-05-28 Vodafone Ag Erfassungssystem für flächige Bereiche zum Erfassen von Fahrzeugen mit GPS
US6657557B1 (en) * 2002-05-08 2003-12-02 Te Hsin Hsu Information communicating apparatus for vehicles
DE10228401A1 (de) * 2002-06-25 2004-01-22 Daimlerchrysler Ag Vorrichtung zur Bestimmung von Benutzungsgebühren und Gebührenerfassungssystem
EP1400937A1 (de) * 2002-09-12 2004-03-24 TeamSharp Space Tech Inc. Kommunikations- und Diebstahlschutzsystem für Motorräder
GB2399441A (en) * 2003-03-11 2004-09-15 Sema Uk Ltd Road use charging system using a mobile telecommunications network
EP1475752A3 (de) * 2003-05-05 2005-12-14 Vodafone Holding GmbH Verfahren und System zur elektronischen Erhebung von Nutzungsgebühren
DE20319131U1 (de) * 2003-12-10 2004-03-18 KNÜPFER, Jürgen Vorrichtung für die Überwachung von Ladegut (Ladegutüberwachung)

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5289183A (en) * 1992-06-19 1994-02-22 At/Comm Incorporated Traffic monitoring and management method and apparatus
WO2000045343A1 (en) * 1999-01-27 2000-08-03 Marcello Federici Automatic charging system for vehicles
WO2001084503A1 (en) * 2000-04-28 2001-11-08 Powercom Ventures As System for handling of tolling collection and fees related to road and parking facilities
DE10104499A1 (de) * 2001-01-31 2002-08-14 Daimler Chrysler Ag Strassengebührenerfassungssystem
US20040200899A1 (en) * 2003-04-08 2004-10-14 Bor-Shenn Jeng Automatic toll collection architecture and method combining short-range and long-range communication schemes

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2242024B1 (de) 2009-04-14 2015-02-25 Kapsch TrafficCom AG Verfahren, Komponenten und Systeme zum Erzeugen von Mauttransaktionen
EP3132648B1 (de) 2014-04-14 2019-06-12 Continental Teves AG & Co. OHG Verfahren zum verarbeiten einer fahrzeug-zu-x-nachricht, fahrzeug-zu-x-kommunikationsmodul und speichermedium
US10952042B2 (en) 2014-04-14 2021-03-16 Continental Teves Ag & Co. Ohg Method and apparatus for processing vehicle-to-X communications
EP3132648B2 (de) † 2014-04-14 2022-06-29 Continental Teves AG & Co. OHG Verfahren zum verarbeiten einer fahrzeug-zu-x-nachricht, fahrzeug-zu-x-kommunikationsmodul und speichermedium
US11477620B2 (en) 2014-04-14 2022-10-18 Continental Teves Ag & Co. Ohg Vehicle-to-X communication in the USA and Europe using a standard transmitter

Also Published As

Publication number Publication date
EP1708144B1 (de) 2010-12-15
EP1708143A2 (de) 2006-10-04
EP1708143A3 (de) 2007-04-25
EP1708144A3 (de) 2007-04-25

Similar Documents

Publication Publication Date Title
EP1708144B1 (de) Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen
EP2195796B1 (de) Verfahren zur bereitstellung von fahrbetriebsdaten
EP2920777B1 (de) Verfahren zum bereitstellen von fahrstreckeninformationen mittels zumindest eines kraftwagens
EP2567371B1 (de) Verfahren zum ermitteln von kraftfahrzeugnah beparkbarem parkraum und hierfür geeignetes fahrzeug-assistenzsystem
DE102012216994A1 (de) Verfahren zur Parkplatzvermittlung und Freier-Parkplatz-Assistenzsystem
EP3482574B1 (de) Bereitstellen einer information aus einem verbund mehrerer kraftfahrzeuge
DE112018005737T5 (de) Fahrzeugflottenmanagement mit einer hiearachie von prioritätsfaktoren
DE102015201420A1 (de) Parkraum-Zufahrtskontrollsystem sowie Verfahren zur Kontrolle der Zufahrt in einen Parkraum
DE112019001611T5 (de) Fahrassistenzsystem, fahrzeuginterne Vorrichtung, Verfahren und Computerprogramm
EP2690601B1 (de) Mautkontrollverfahren und Mautkontrolleinrichtungen sowie Mautsystem mit derartigen Mautkontrolleinrichtungen
DE102018008730A1 (de) Verfahren und Vorrichtung zum Erheben von fahrzeugbasierten Datensätzen für vorgegebene Streckenabschnitte
DE102016216152A1 (de) Verfahren zum Vermessen eines Fahrereignisses, Servervorrichtung und System aus der Servervorrichtung und mehreren Kraftfahrzeugen
DE102014002632A1 (de) Verfahren und System zur Bewirtschaftung kostenpflichtiger Verkehrsräume
EP1741077A1 (de) Verfahren und system zur übermittlung von informationen über parklücken
DE102005031419A1 (de) Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen
DE202006021041U1 (de) Vorrichtung und System zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen
DE102005058033A1 (de) Verfahren zur Überprüfung einer Benutzungsberechtigung
EP3242205A1 (de) Verfahren zur aktualisierung der konfiguration einer fahrzeugeinrichtung, fahrzeugeinrichtung, zentrale datenverarbeitungseinrichtung und mautsystem
DE102018204538A1 (de) Verfahren und System zum Ermitteln einer Zugänglichkeit von Parkplätzen
EP3113118B1 (de) Verfahren zur verfolgung mautpflichtiger fahrzeuge in einem mautsystem sowie mautsystem
DE10361628A1 (de) Inbetriebnahme einer Anwendung in einem mobilen Klienten
DE112012004816T5 (de) Speichernetzwerksystem
DE102019001735B3 (de) Erheben von fahrzeugbasierten, ortsbezogenen Datensätzen
DE102018008731A1 (de) Verfahren und Vorrichtung zum Erheben von fahrzeugbasierten Datensätzen für vorgegebene Streckenabschnitte
DE102016105583A1 (de) Parkraumüberwachungssystem sowie Verfahren zur Parkraumüberwachung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

17P Request for examination filed

Effective date: 20070626

17Q First examination report despatched

Effective date: 20070727

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MPS SOLUTIONS GMBH

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 502006008489

Country of ref document: DE

Date of ref document: 20110127

Kind code of ref document: P

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

LTIE Lt: invalidation of european patent or patent extension

Effective date: 20101215

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110315

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110415

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110326

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110415

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110316

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

PLAZ Examination of admissibility of opposition: despatch of communication + time limit

Free format text: ORIGINAL CODE: EPIDOSNOPE2

PLBI Opposition filed

Free format text: ORIGINAL CODE: 0009260

BERE Be: lapsed

Owner name: MPS SOLUTIONS G.M.B.H.

Effective date: 20110331

26 Opposition filed

Opponent name: TOLL COLLECT GMBH

Effective date: 20110915

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110331

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: DE

Ref legal event code: R026

Ref document number: 502006008489

Country of ref document: DE

Effective date: 20110915

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110331

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110331

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110331

RAP2 Party data changed (patent owner data changed or rights of a patent transferred)

Owner name: M2C SOLUTIONS GMBH

REG Reference to a national code

Ref country code: NL

Ref legal event code: SD

Effective date: 20120213

PLBG Opposition deemed not to have been filed

Free format text: ORIGINAL CODE: 0009274

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 502006008489

Country of ref document: DE

Representative=s name: STOLMAR SCHEELE & PARTNER, DE

26D Opposition deemed not to have been filed

Opponent name: TOLL COLLECT GMBH

Effective date: 20111225

REG Reference to a national code

Ref country code: DE

Ref legal event code: R081

Ref document number: 502006008489

Country of ref document: DE

Owner name: M2C SOLUTIONS GMBH, DE

Free format text: FORMER OWNER: MPS SOLUTIONS GMBH, 94560 OFFENBERG, DE

Effective date: 20120316

Ref country code: DE

Ref legal event code: R082

Ref document number: 502006008489

Country of ref document: DE

Representative=s name: SCHWARZ & BALDUS PATENTANWAELTE, DE

Effective date: 20120316

Ref country code: DE

Ref legal event code: R082

Ref document number: 502006008489

Country of ref document: DE

Representative=s name: PATENTANWAELTE SCHWARZ & BALDUS PARTNERSCHAFT , DE

Effective date: 20120316

REG Reference to a national code

Ref country code: GB

Ref legal event code: 732E

Free format text: REGISTERED BETWEEN 20120614 AND 20120620

REG Reference to a national code

Ref country code: AT

Ref legal event code: PC

Ref document number: 492008

Country of ref document: AT

Kind code of ref document: T

Owner name: M2C SOLUTIONS GMBH, DE

Effective date: 20120518

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20130321

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110308

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101215

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20140328

Year of fee payment: 9

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 502006008489

Country of ref document: DE

Representative=s name: SCHWARZ & BALDUS PATENTANWAELTE, DE

Ref country code: DE

Ref legal event code: R082

Ref document number: 502006008489

Country of ref document: DE

Representative=s name: PATENTANWAELTE SCHWARZ & BALDUS PARTNERSCHAFT , DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20140308

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140308

PLAB Opposition data, opponent's data or that of the opponent's representative modified

Free format text: ORIGINAL CODE: 0009299OPPO

R26D Opposition deemed not to have been filed (corrected)

Opponent name: TOLL COLLECT GMBH

Effective date: 20111225

REG Reference to a national code

Ref country code: NL

Ref legal event code: MM

Effective date: 20150401

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 11

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20150401

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20180328

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20180327

Year of fee payment: 13

Ref country code: FR

Payment date: 20180321

Year of fee payment: 13

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502006008489

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 492008

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190308

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191001

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190308

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190331