EP1708143A2 - System zur Verarbeitung von positions-und/oder mautbezogenen Daten für Fahrzeuge - Google Patents

System zur Verarbeitung von positions-und/oder mautbezogenen Daten für Fahrzeuge Download PDF

Info

Publication number
EP1708143A2
EP1708143A2 EP06004735A EP06004735A EP1708143A2 EP 1708143 A2 EP1708143 A2 EP 1708143A2 EP 06004735 A EP06004735 A EP 06004735A EP 06004735 A EP06004735 A EP 06004735A EP 1708143 A2 EP1708143 A2 EP 1708143A2
Authority
EP
European Patent Office
Prior art keywords
data
obu
office
board unit
related data
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.)
Withdrawn
Application number
EP06004735A
Other languages
English (en)
French (fr)
Other versions
EP1708143A3 (de
Inventor
Peter Selmayr
Christian Dr. Robl
Rolf Herzog
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.)
Ages International & Co KG GmbH
MPS Solutions GmbH
Original Assignee
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=EP1708143(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from DE202005009152U external-priority patent/DE202005009152U1/de
Priority claimed from DE200510010888 external-priority patent/DE102005010888A1/de
Priority claimed from DE102005030030A external-priority patent/DE102005030030A1/de
Application filed by Ages International & Co KG GmbH, MPS Solutions GmbH filed Critical Ages International & Co KG GmbH
Publication of EP1708143A2 publication Critical patent/EP1708143A2/de
Publication of EP1708143A3 publication Critical patent/EP1708143A3/de
Withdrawn legal-status Critical Current

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 is in the field of location-related data acquisition and processing in systems generally related to transportation, such as toll systems, toll collection systems, clearing systems, fleet management systems, and the like.
  • Starting point of the present invention is the transmission of data from a plurality of mobile devices to a central, stationary instance, the so-called back-office.
  • a so-called on-board unit which is attached to the vehicle, is provided in each case.
  • the data must be processed by a large number of on-board units.
  • an air interface is provided, via which the data exchange takes place.
  • the on-board units are mobile units mounted on the vehicle, and the back-office is at least one central stationary unit which is advantageously designed so that here main data processing takes place. It is desirable to design the on-board unit as small, simple and inexpensive as a "thin client" with only a minimum of business logic.
  • the on-board unit has a relatively large business logic and includes a variety of data processing modules. This is disadvantageous in many respects.
  • the on-board units are becoming relatively expensive and, due to their complexity, prone to error, making it difficult to maintain and troubleshoot mobile on-board units.
  • the communication links between the on-board units and the back office are claimed by the high volume of data, especially in cross-border applications (by reloading geodata and applications), which can sometimes lead to bottlenecks and thus errors.
  • existing systems for processing position-related data are to be simplified and improved.
  • An essential core idea of the present invention is to be seen in that the position-related data are not processed directly in the on-board unit, but completely, partially and / or transformed are forwarded to the back-office, and then further processed there centrally to become.
  • This has the advantage that the mobile unit can be designed as a "thin client", which is cheaper to produce, easier to maintain and less error prone.
  • a second essential aspect of the present invention is that the system can be adapted adaptively to the particular application situation and is thus easily expandable. It is not limited to a specific application.
  • the position-related data acquired by the mobile on-board unit can be sent for further processing in various and varied ways. It is irrelevant whether the further processing is used in the context of a toll system, a fleet management system or a clearing and / or billing system for toll operators.
  • the central storage and processing of the position-related data makes it possible to dynamically generate the normalized position data. This means that the back office can control and execute the transformation or the calculation of the normalized position data so that downstream further processing steps can be simplified and facilitated. The calculation can thus be designed according to the invention on the further processing of the position data.
  • the calculation of the normalized position data from the read-in, position-related data in the back-office can be configured according to presettable parameters.
  • the further processing is carried out by a plurality of different service instances.
  • the service instances can be designed as part of the back office and on the other hand-in an alternative embodiment-as independent and separate units.
  • a service instance can therefore be a toll service, a billing system within a toll service, which carries out the tariff calculation, etc.
  • the present invention is applied to the toll sector.
  • the service instances are maintained by different toll operators.
  • the data recorded by the on-board unit are prepared and transmitted according to current requirements and requirements. It is possible to provide the back-office with a geo-object manager and / or with a road-identification interface, so that it can be determined what tolls were incurred for the driven route of the respective vehicle. This is done by comparing the recorded, transmitted and processed position data with data records of a database in which current tariff data are stored for each geo-object, in particular for each route.
  • the position-related data can be queried in online operation and, second, the position-related data in batch mode according to configurable parameters.
  • the position-related data that are transmitted from the respective on-board units to the central back-office instance are usually satellite position data records that are received from a corresponding receiver, in particular from a GPS and / or Galileo receivers in which mobile on-board device has been received.
  • satellite raw data in particular so-called pseudo-range data, vector data or other geo-data sets.
  • position-related data in the context of this invention means all satellite-based position-related data in arbitrary formats which have a relation to a position of an object and are preferably in digital form. This includes GPS data, Galileo data, GLONASS data and / or position-related data from other systems. It should be noted at this point that the use of the term “GPS data” in this patent is to be understood as illustrative and not restrictive and includes other satellite based positional data from other systems or systems to be created in the future , GPS data is used because it is currently the most common.
  • a specific air interface is provided between the respective on-board unit and the back-office, which is formed in particular via at least one mobile radio network.
  • this is based on a packet-oriented communication technology, such as GPRS and UMTS.
  • GPRS Packet Radio Service
  • UMTS Universal Mobile Subscriber Identity
  • other communication technologies may be used, especially if the aforementioned technologies are not available, such as e.g. "Dataover Voice (GSM) -BS26".
  • GSM Dataover Voice
  • the data will be transmitted in encrypted form between the respective on-board unit and the back-office.
  • an asynchronous key pair is generated, which comprises a public key and a private key.
  • the encryption and cryptographic algorithms known in the art such as PGP, can be used.
  • another structural safety measure can be provided by the on-board unit is equipped with a housing which is secured by a manipulation switch. Unauthorized opening of the on-board unit can thus be ruled out, since it is ensured that the housing of the on-board unit can only be opened when the device has been returned.
  • the invention it is possible to reduce the number of data to be transmitted from the on-board unit to the back-office by transmitting the data in compressed form.
  • it can be set that not all fixes, that is all position determinations of the mobile unit, are transmitted, but only a selection of fixes.
  • additional fixes are inserted under access to an approximation module.
  • the approximation module accesses at least one approximation method, in particular a spline approximation, which sets the already acquired data in relation to one another and generates the missing data on the basis of an approximation algorithm and thus closes the gaps.
  • the on-board unit may be set at which times the data is transferred from the on-board unit to the back-office. It is possible to provide configurable time intervals here, which leads to a time-dependent transmission. Cumulatively or alternatively, it is possible to trigger the transmission as soon as a predeterminable threshold value is reached. If the on-board unit is designed, for example, with a buffer memory, then it can be set that the data is transmitted when a capacity of the buffer memory is almost reached. It is also possible that Form on-board unit without buffer storage. In this case, the data can be transmitted after receiving a specific data size.
  • Normalization of the data is performed in the back office.
  • the aim of the normalization is to be able to quickly and easily provide the required position data in the desired format, depending on the requirements of the downstream service or the stored calculations of the service instances.
  • the service instances can refine the processed data according to specific requirements.
  • the data transferred from the mobile on-board unit to the back-office is raw satellite data. These are transformed losslessly in the back office into another representation of the data, namely normalized position data. From the normalized position data all desired formats can be calculated.
  • a significant advantage of the solution according to the invention can be seen in the modularity of the system. This allows the system to be expanded arbitrarily and easily by adding additional service instances via suitable interfaces. As a rule, the service instances are those which are designed to process position-related data.
  • An on-board unit is each equipped with a receiver intended to receive position-related raw satellite data. Additionally or alternatively, it is possible that the respective on-board units form with an interface for a DSRC system (DSRC - D edicated- S hort- R reasonable ommunication C).
  • a DSRC system is disadvantageously only for short distances, especially those under 8 Meters, and includes a DSRC tag disposed on the mobile unit, and further requires road construction measures, particularly in the form of beacons comprising electronic modules, adapted to the "passing" DSRC tags of the respective ones Register vehicles. The data collected at the beacon is then transmitted to the back office. This system is used today in Austria, for example, in each case a toll section of two boundary beacons is bordered.
  • the solution according to the invention is designed so that it can interact with such DSRC systems. Therefore, the on-board unit according to the invention may be formed with at least one corresponding interface. In this case, the on-board unit according to the invention assumes the function of the normal DSRC tag. Thus, as soon as the DSRC communication is activated, the on-board unit according to the invention prepares and monitors the appropriate DSRC modem (or possibly several modems) for the pending communication. In addition, it is possible according to the invention to operate the on-board unit in a selectable dual mode. The DSRC data acquisition can thus alternatively and cumulatively to the satellite raw data survey via satellite position data (GPS / Galileo) take place.
  • GPS satellite position data
  • the preferred embodiment of the invention includes an activation mechanism that automatically enables / disables, or does not enable / disable, the transfer of position-related data from the on-board unit to the back-office according to adjustable criteria.
  • the criteria are based on a registered country code or area, in particular an area of an operator of mobile networks and / or toll systems.
  • the background to this feature is that there are countries for which there are none Toll collection or only toll collection for certain types of vehicles. With this feature, it is possible to inhibit or disable the communication between the on-board unit and the back-office until the collection of position-related data makes sense, for example, until a toll system is put into operation in that country has been.
  • the activation mechanism may also be based on other criteria (such as time of day intervals when no toll is charged for a particular route).
  • Each on-board unit can be uniquely identified by the back office. This is done in particular via components of a SIM card and / or a device serial number. This makes it possible to assign position-related data transmitted to the back office automatically and uniquely to an on-board unit.
  • several on-board units can also be combined to form a group of on-board units. This may be particularly useful in fleet management systems for a group of vehicles of a logistics company.
  • mapping is linked to the unique number of the on-board unit (mapping). If the on-board unit is in the area of this operator, the unique number is transmitted internally and the named virtual ID is transmitted externally to the operator. The processing with the internal ID is encapsulated for the operator, so that - as usual - he can use his proprietary ID.
  • the mapping rule is based on a one-to-one association relation.
  • a data structure can be generated in which a unique identification number is stored for each on-board unit and / or a virtual identification number Identification number of a service provider is stored, including mapping rules that define a one-to-one relation between the virtual identification number and identification number. If DSRC tags are used, corresponding DSRC virtual tag IDs can be used, which are then mapped to the internal DSRC tag IDs.
  • the back-office includes a central storage and / or control unit.
  • the respective on-board units are controlled by this control unit of the back-office.
  • the back-office storage unit serves to store the on-board unit position-related data and / or the normalized position data and / or other data records, e.g. status messages or the like. This makes it possible to forward data records (also in the past) to further processing without having to reread these data. It also makes it possible to subject already collected data to error checking and control. Errors can e.g. caused by incorrect acquisition of the satellite raw data. The satellite operators publish such error messages. According to the invention, these can be assigned to the position-related data thus erroneously detected and, overall, correct position data can be derived.
  • pseudo-range data is transferred from the on-board unit to the back-office, these data are subject to errors due to the acquisition method.
  • the error is based on the signal transit times between satellite and receiver (ie the on-board unit).
  • the signal transit times are measured in comparison to a receiver clock that is not synchronized with the transmission clocks (the satellite).
  • the "pseudo-ranges" are therefore only apparent distances and result from the product of the respective time and the propagation speed of the signal.
  • This error can be eliminated or eliminated according to the invention by detecting reference position signals from stationary reference stations. For example, four reference stations are used for one area of the Federal Republic of Germany.
  • the reference data acquired by the stationary reference stations are used in the calculation the normalized position data within the back office, in particular the position calculation instance used.
  • not pseudo-range data is transmitted from the on-board unit to the back-office, but already satellite position data data.
  • the position calculation entity may be made much slimmer and is preferably only for reading the respective data. If necessary, this data can be transformed into another format, depending on the requirements of the service instances for the further processing of the data.
  • At least one of the method steps and preferably all method steps are carried out automatically. It is thus possible to carry out the tolling fully automatically, without it being necessary to initiate certain calculations "by hand”.
  • the on-board unit Based on the determined current position, it is possible for the on-board unit to automatically and independently decide which operating mode is activated must, and that at any time a change can be made.
  • the operating mode is usually based on the detected country code.
  • a connection service is provided as a link between the back-office and the respective on-board units, which routes the telegrams or packets between the on-board units and the back-office and encrypted and decrypted, the signatures of Generates and checks telegrams and checks the on-board unit for a successful authentication.
  • a communication service is usually provided by one or more mobile operators in different countries. This component transfers the collected position-related data, any status messages or updates to the back-office. It is also possible to handle the control of the on-board units from the back-office via this communication channel.
  • the respective mobile on-board units are designed according to the invention as thin clients, and as far as possible all processing and computing instances are arranged in the back-office or assigned to this. It is possible to integrate the respective calculation instances in the back office. Alternatively, it is possible to provide the above-mentioned instances as separate modular components and to connect them via corresponding interfaces to the back-office.
  • the object of the invention is achieved by a device for processing position-related data, having means designed for carrying out at least one of the aforementioned methods.
  • 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.
  • a mobile on-board unit OBU is mounted on a vehicle. This is usually done by gluing on the windshield or other integration in the vehicle.
  • the system includes a variety of mobile on-board units OBU and a stationary, central back-office BO.
  • an on-board unit OBU for detecting position-related data in particular via a GPS and / or Galileo receiver 10 is designed.
  • the position-related data can be in one Buffer memory 12 are buffered and are then fed to a transmitting unit 14.
  • the transmitting unit 14 serves to transmit position-related data from the on-board unit OBU to the back-office BO.
  • the back office BO is intended for processing, in particular for finishing, the received position-related data.
  • the back office BO comprises a position calculation entity 15, which is intended to transform the received position-related data into normalized position data. This intermediate representation of the normalized position data is used for the simple transformation of the position data into further formats. This is done on the basis of requests that one or more service instances 16 of the position calculation entity 15 report.
  • the on-board unit OBU is as compact and simple as possible, while the back-office BO is used for centralized and comprehensive data processing.
  • the GPS and / or Galileo receiver 10 of the on-board unit OBU is intended to receive raw satellite data.
  • the position-related data received by satellite S are forwarded by the GPS and / or Galileo receiver 10 - possibly via a buffer memory 12 - to the transmitting unit 14 for transmission to the back-office BO.
  • the back office BO calculates normalized position data from these position-related data - if necessary with access to further modules.
  • the normalized position data may serve as input for further processing by the service instances 16.
  • the position-related data transmitted from the on-board unit OBU to the back-office BO can be pseudo-range data, GPS or Galileo data and / or vector data. If pseudo-range data is transmitted, the error due to the signal propagation delay in the back-office BO can be eliminated by the back-office BO on at least one Reference stations Ri accesses.
  • the reference stations Ri are arranged stationary and designed for the reception of satellite raw data.
  • the position reference data received from the reference stations Ri is forwarded to the position computing entity 15 of the back office BO. From a difference of the two signal runs an error-free normalized position signal can be tapped. This signal is supplied to the service instances 16 for further processing.
  • the dashed line around the satellites Si is intended to indicate that the respective satellites belong to a satellite operating company.
  • the satellite operators publish data from which errors with respect to the raw satellite data can be derived.
  • the position calculation entity 15 accesses these messages and calculates corrected normalized position data on the basis of these data.
  • the position calculation entity 15 in the back office BO can be configured such that the normalized position data it generates are generated so that they are designed for further processing by the respective service instances 16.
  • the respective service instances 16 it is necessary for the respective service instances 16 to report their requirements for the position data to the position calculation entity 15. Therefore, in this embodiment of the invention, there is also a data flow that runs from the service instances 16 to the back office BO, in particular to the position calculation entity 15 (this is not shown in FIG. 1, however).
  • a service entity 16 can in particular be used for processing the normalized position data for a toll collection system, for billing in a toll collection system or, for example, for clearing in a toll collection system.
  • other further processing methods are performed by service instances 16.
  • an on-board unit OBU comprises a housing, a processor, a GPS and / or Galileo receiver 10, a buffer memory 12, a power supply unit, a user interface, an integrated GPS / GSM and / or Galileo / GSM antenna and / or an integrated DSRC antenna, interfaces for further antennas or communication components, a cable set for a network connection via fixed installation and / or cigarette lighter, an operating system and application software and drivers.
  • the on-board unit OBU is designed so that only a wiring for the power supply and possibly for the antennas is needed.
  • the back office BO communicates with the respective service entity 16, here the toll operators A - C, or with the billing system. It is possible to provide further service instances 16. These may consist of administration / controlling, a call center, a complaint unit, an order and order unit, a software development and deployment unit, a geo-object update provider, a sales unit and a certification unit.
  • the back office BO comprises an OBU home operator, a connection service and a position interface.
  • the back office BO consists of the "standard back office” and the "Europe OBU service", which is intended for processing toll-related item data. This is represented in FIG. 2 by the two sub-boxes of the back-office BO.
  • a communication service is provided, which is preferably provided by one or more mobile operator (s). It is, as shown in Figure 2, assigned as an external component of the back-office. The mobile operators can belong to different states. This component transfers the captured position-related data (but also status messages or updates) to the back-office BO.
  • connection service is a link between the back office BO and the on-board unit OBU.
  • the task of this component is to route the data packets or telegrams to be transmitted between the on-board units OBU and the back-office BO, to encrypt and decrypt them, to generate and verify their signatures and with help of the OBU home operator to check the validity of the OBU (authentication process).
  • the position calculation entity 15 can consist of the "position interface".
  • This service receives the collected and acquired position-related data based on the GPS and / or Galileo data on the pseudo-range data or vector data, and calculates the normalized position data therefrom.
  • the position reference data of the reference stations R are additionally accepted.
  • this service serves to provide the satellite error information provided by the satellite operator and to calculate the normalized position data on the basis of the data received.
  • the position calculation entity 15 stores the data in a database and if necessary informs another component about this data or makes the normalized position data available to further service instances or components.
  • the OBU home operator provides the OBU parameters online.
  • the components within the back office BO communicate via a standardized protocol format (see XML telegrams).
  • the communication between on-board unit OBU and connection service is usually based on an optimized proprietary protocol.
  • system according to the invention can be designed with further interfaces in order to connect further components.
  • FIG 3 the basic flow of data processing according to a preferred embodiment in the back-office BO, in particular in the position calculation entity 15 is shown, which is marked in Figure 3 as a position data interface.
  • the on-board unit OBU detects position-related data in normal operation, which are compressed in an optimized manner.
  • data is reduced by transmitting not all fixes (that is, all position data acquisitions) but only selected ones. The distance traveled can be reconstructed with sufficient accuracy via mathematical approximation methods, in particular via a spline approximation.
  • FIG. 4 shows an overview of a process of data processing of satellite position data in the back-office BO.
  • the position calculation entity 15 which is marked with "GPS position interface” in FIG. 4
  • the position data are calculated and provided to each service provider or service entity 16 and further components in the desired format.
  • the service entity 16 is identified in FIG. 4 with the term "service provider”.
  • the process steps, which are shown between the two horizontal, dashed lines, refer to the position data transmission to the service providers or to the service instances 16.
  • FIG. 5 shows the data processing in the back-office BO, in particular in the RI interface.
  • the RI interface recognizes the toll-related geo-objects from the transferred position-related data and derives the necessary parameters from them.
  • the distance covered within the tolled Geo object is calculated, in order to derive therefrom a distance-dependent toll collection.
  • the RI interface communicates with both the "GPS Position InterFace" and the Geo-Object Manager to collect the toll-related data.
  • the process steps which are shown between the two horizontally extending, dashed lines, relate to a toll-subject object transfer to the respective service instances 16.
  • the service entity 16 blocks or deactivates a special on-board unit OBU via the OBU home operator. A corresponding confirmation of the blocking is reported back to the service entity 16. Such a blockage may be necessary if the service provider considers the conditions for blocking to be fulfilled.
  • FIG. 6 shows by way of example how the data collection takes place within the on-board unit OBU according to a preferred embodiment. Basically, there are two possibilities: the acquisition according to the DSRC principle and the acquisition of satellite position data.
  • the process steps illustrated in FIG. 6 between the first two horizontal dashed lines refer to DSRC communication with the service provider or service entity 16, respectively.
  • the process steps located thereunder relate on a back-office communication with the service provider.

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, eine Vorrichtung und ein System zur Verarbeitung von positions-bezogenen Daten, wobei die positions-bezogenen Daten auf einer Vielzahl von mobilen On-Board-Units (OBU) erfasst werden und über ein Mobilfunknetz als Schnittstelle an ein zentrales und stationäres Back-Office (BO) zur weiteren Verarbeitung übertragen werden. Das Back-Office (BO) umfasst eine Positions-Berechnungsinstanz (15), die dazu bestimmt ist, aus den eingelesenen positions-bezogenen Daten normalisierte Positionsdaten zu berechnen. Die normalisierten Positionsdaten werden dann weiteren Service-Instanzen (16) zur weiteren Verarbeitung weitergeleitet.

Description

  • Die vorliegende Erfindung liegt auf dem Gebiet der Erfassung von positions-bezogenen Daten und deren Verarbeitung in Systemen, die grundsätzlich auf den Transport bezogen sind, wie Mautsysteme, Abrechnungssysteme für Mautsysteme, Clearing-Systeme, Flotten-Management-Systeme und dergleichen.
  • Bei modernen Transport- und/oder Verkehrssystemen ist es notwendig, die aktuelle und exakte Position eines Fahrzeuges zu bestimmen, um diese Positionsdaten weiterzuverarbeiten. Es gibt grundsätzlich vielfältige Möglichkeiten, wie die Positionsdaten weiterverarbeitet werden sollen. Es ist möglich, die Daten für ein Mautsystem zu verwenden, so dass die gefahrene Strecke des Fahrzeugs automatisch abgeleitet werden kann, um zu bestimmen, welche mautpflichtigen Straßen gefahren worden sind. Des Weiteren ist es möglich abzuleiten, welche Mautkosten entstanden sind.
  • Ausgangsposition der vorliegenden Erfindung ist die Übertragung von Daten von einer Vielzahl von mobilen Geräten an eine zentrale, stationäre Instanz, das sogenannte Back-Office. Um die positions-bezogenen Daten der jeweiligen mobilen Geräte zu erfassen, ist jeweils eine so genannte On-Board-Unit vorgesehen, die an dem Fahrzeug angebracht ist. Grundsätzlich müssen die Daten von einer Vielzahl von On-Board-Units verarbeitet werden. Zwischen der jeweiligen On-Board-Unit und dem Back-Office ist eine Luft-Schnittstelle vorgesehen, über die der Datenaustausch erfolgt.
  • Üblicherweise handelt es sich bei den On-Board-Units um mobile Einheiten, die am Fahrzeug angebracht sind, und bei dem Back-Office um mindestens eine zentrale stationäre Einheit, die vorteilhafterweise so ausgelegt sein soll, dass hier die hauptsächliche Datenverarbeitung stattfindet. Wünschenswert ist es, die On-Board-Unit möglichst klein, einfach und kostengünstig als "Thin Client" mit nur einem Minimum an Geschäftslogik auszubilden.
  • Bei bisherigen Systemen weist die On-Board-Unit eine relativ umfangreiche Geschäftslogik auf und umfasst eine Vielzahl von Datenverarbeitungs-Modulen. Dies ist in vielfacher Hinsicht nachteilig. Einerseits werden die On-Board-Units relativ teuer und durch ihre Komplexität auch fehleranfällig, was die Wartung und Fehler-Recovery-Maßnahmen der mobilen On-Board-Units erschwert. Andererseits werden die Kommunikations-Verbindungen zwischen den On-Board-Units und dem Back-Office durch das hohe Datenvolumen vor allem bei grenzüberschreitenden Anwendungen (durch das Nachladen von Geodaten und Applikationen) beansprucht, was teilweise zu Engpässen und damit zu Fehlern führen kann.
  • Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem ein möglichst großer Anteil von der Verarbeitung von positions-bezogenen Daten in einer zentralen Einheit erfolgen kann und mit dem es möglich wird, von einem mobilen Gerät erfasste positions-bezogene Daten für eine Vielzahl von unterschiedlichen Weiterverarbeitungs-Möglichkeiten zu verwenden, ohne dass sie mehrfach übertragen werden müssen. Darüber hinaus sollen bisherige Systeme zur Verarbeitung von positions-bezogenen Daten vereinfacht und verbessert werden.
  • Diese Aufgabe wird durch ein System, ein Verfahren und eine Vorrichtung mit Mitteln gemäß den beiliegenden Hauptansprüchen gelöst.
  • Die Aufgabe wird insbesondere gelöst durch ein Verfahren zur Verarbeitung von positions-bezogenen Daten, mit folgenden Verfahrensschritten:
    • Erfassen von positions-bezogenen Daten von jeweils einer On-Board-Unit aus einer Vielzahl von On-Board-Units,
    • Übertragen der positions-bezogenen Daten an ein zentrales Back-Office über eine Luft-Schnittstelle,
    • Einlesen der positions-bezogenen Daten durch das Back-Office,
    • Berechnen von normalisierten Positionsdaten aus den eingelesenen positions-bezogenen Daten und
    • Weiterleiten der normalisierten Positionsdaten und/oder der positions-bezogenen Daten an zumindest eine Service-Instanz zur Weiterverarbeitung in einem wählbaren Format.
  • Ein wesentlicher Kerngedanke der vorliegenden Erfindung ist darin zu sehen, dass die positions-bezogenen Daten nicht unmittelbar in der On-Board-Unit verarbeitet werden, sondern vollständig, teilweise und/oder transformiert an das Back-Office weitergeleitet werden, um dann dort zentral weiterverarbeitet zu werden. Dies hat den Vorteil, dass die mobile Einheit als "Thin Client" ausgebildet werden kann, der kostengünstiger herstellbar ist, leichter gewartet werden kann und weniger fehleranfällig ist.
  • Ein zweiter wesentlicher Gesichtspunkt der vorliegenden Erfindung ist darin zu sehen, dass das System adaptiv an die jeweilige Anwendungs-Situation angepasst werden kann und somit leicht erweiterbar ist. Es ist nicht auf eine bestimmte Anwendung beschränkt. Die von der mobilen On-Board-Unit erfassten positions-bezogenen Daten können auf unterschiedliche und vielfältige Weise einer Weiterverarbeitung zugeführt werden. Dabei ist es unerheblich, ob die Weiterverarbeitung im Rahmen eines Mautsystems, eines Flotten-Management-Systems oder eines Clearings- und/oder Abrechnungssystems für Mautbetreiber verwendet wird. Durch die zentrale Speicherung und Verarbeitung der positions-bezogenen Daten wird es möglich, die normalisierten Positionsdaten dynamisch zu erzeugen. Das heißt, dass das Back-Office die Transformation bzw. die Berechnung der normalisierten Positionsdaten so steuern und ausführen kann, dass nachgelagerte Weiterverarbeitungsschritte vereinfacht und erleichtert werden können. Die Berechnung kann also erfindungsgemäß auf die Weiterverarbeitung der Positionsdaten hin ausgelegt werden.
  • In einer vorteilhaften Ausführungsform der Erfindung kann das Berechnen der normalisierten Positionsdaten aus den eingelesenen, positions-bezogenen Daten in dem Back-Office nach voreinstellbaren Parametern konfiguriert werden.
  • Insbesondere ist es möglich, die normalisierten Positionsdaten in einem wählbaren Format zu erzeugen, das von dem späteren Weiterverarbeitungsverfahren gefordert wird. Üblicherweise erfolgt die Weiterverarbeitung durch eine Vielzahl von unterschiedlichen Service-Instanzen. Die Service-Instanzen können zum einen als Bestandteil des Back-Office und zum anderen - in einer alternativen Ausführungsform - als unabhängige und separate Einheiten ausgebildet sein. Eine Service-Instanz kann also ein Maut-Service sein, ein Abrechnungssystem innerhalb eines Maut-Services, was die Tarifberechnung durchführt, etc.
  • Vorzugsweise wird die vorliegende Erfindung auf dem Mautsektor angewendet. Üblicherweise werden die Service-Instanzen von unterschiedlichen Mautbetreibern unterhalten. In der Maut-Service-Instanz des Back-Office werden die jeweils von der On-Board-Unit erfassten Daten entsprechend den aktuellen Anforderungen und Bedürfnissen aufbereitet und übertragen. Es ist möglich, das Back-Office mit einem Geo-Objekt-Manager und/oder mit einem Road-Identification-Interface auszustatten, so dass bestimmt werden kann, welche Mautgebühren für die gefahrene Strecke des jeweiligen Fahrzeugs angefallen sind. Dies erfolgt, indem die erfassten, übertragenen und aufbereiteten Positionsdaten mit Datensätzen einer Datenbank abgeglichen werden, in der zu jedem Geo-Objekt, insbesondere zu jeder Strecke, aktuelle Tarifdaten abgelegt sind. An dieser Stelle zeigt sich ein sehr wesentlicher Vorteil der erfindungsgemäßen Lösung, nämlich, dass die ständig notwendigen Aktualisierungen (Tarife, neue Streckennetze, Änderungen beim Mautbetreiber, Änderungen in Bezug auf die satellitengestützte Erfassung der Positionsdaten etc.) nun sehr vereinfacht an zentraler Stelle erfolgen können. Es ist nicht mehr notwendig, die diversen On-Board-Units mit den aktualisierten Daten zu versorgen. Damit können auch die Kommunikations-Kosten deutlich gesenkt werden.
  • Grundsätzlich ist es möglich, das Einlesen der positions-bezogenen Daten innerhalb des Back-Offices auf unterschiedliche Weise zu gestalten: Zum einen können die positions-bezogenen Daten im Online-Betrieb abgefragt werden und zum anderen können die positions-bezogenen Daten im Batch-Betrieb nach konfigurierbaren Parametern erfasst werden.
  • Bei den positions-bezogenen Daten, die von den jeweiligen On-Board-Units an die zentrale Back-Office-Instanz übertragen werden, handelt es sich üblicherweise um Satellitenpositionsdaten-Datensätze, die von einem entsprechenden Receiver, insbesondere von einem GPS- und/oder Galileo-Receiver, in dem mobilen On-Board-Gerät empfangen worden sind. Darüber hinaus ist es möglich, Satelliten-Rohdaten, insbesondere sogenannte Pseudo-Range-Daten, Vektor-Daten oder andere Geo-Datensätze zu übertragen.
  • Unter dem Begriff "positions-bezogene Daten" sind im Rahmen dieser Erfindung alle satelliten-basierten positions-bezogenen Daten in beliebigen Formaten zu verstehen, die einen Bezug zu einer Position eines Objektes haben und vorzugsweise in digitaler Form vorliegen. Hierunter fallen GPS-Daten, Galileo-Daten, GLONASS-Daten und/oder positions-bezogene Daten von anderen Systemen. Es sei an dieser Stelle darauf hingewiesen, dass die Verwendung des Begriffes "GPS-Daten" in dieser Patentschrift nur beispielhaft und nicht einschränkend zu verstehen ist und ebenso andere satelliten-gestützte positions-bezogene Daten von anderen Systemen oder von zukünftig noch zu schaffenden Systemen umfasst. GPS-Daten werden deshalb verwendet, weil sie zurzeit am meisten verbreitet sind.
  • Erfindungsgemäß ist zwischen der jeweiligen On-Board-Unit und dem Back-Office eine spezifische Luft-Schnittstelle vorgesehen, die insbesondere über zumindest ein Mobilfunknetz gebildet wird. Üblicherweise wird hier auf eine paketorientierte Kommunikations-Technologie, wie GPRS und UMTS aufgesetzt. Alternativ sind jedoch auch andere Kommunikations-Technologien verwendbar, insbesondere dann, wenn vorstehend genannte Technologien nicht zur Verfügung stehen, wie z.B. "Dataover-Voice (GSM)-BS26". Darüber hinaus können auch andere Übertragungs-Technologien und/oder andere optimierte proprietäre Protokolle eingesetzt werden.
  • Um die Sicherheit des Systems zu erhöhen und um einen Datenmissbrauch sicher auszuschließen ist es vorgesehen, dass die Daten zwischen der jeweiligen On-Board-Unit und dem Back-Office verschlüsselt übertragen werden. Üblicherweise wird dafür ein asynchrones Schlüsselpaar erzeugt, das jeweils einen öffentlichen Schlüssel und einen privaten Schlüssel umfasst. An dieser Stelle können die im Stand der Technik bekannten verschlüsselungs- und kryptografischen Algorithmen, wie z.B. PGP, eingesetzt werden. Darüber hinaus kann eine weitere bauliche Sicherheitsmaßnahme vorgesehen sein, indem die On-Board-Unit mit einem Gehäuse ausgestattet ist, das durch einen Manipulationsschalter gesichert ist. Ein unerlaubtes Öffnen der On-Board-Unit kann somit ausgeschlossen werden, da sichergestellt ist, dass das Gehäuse der On-Board-Unit nur dann geöffnet werden kann, wenn das Gerät eingeschickt worden ist.
  • Erfindungsgemäß ist es möglich, die Anzahl der zu übertragenden Daten von der On-Board-Unit an das Back-Office zu verringern, indem die Daten komprimiert übertragen werden. Darüber hinaus kann eingestellt werden, dass nicht alle Fixes, das heißt alle Positionsbestimmungen der mobilen Einheit, übertragen werden, sondern nur eine Auswahl der Fixes. Erweist es sich jedoch im Rahmen der Weiterverarbeitungen als notwendig, dass mehr Fixes zur Verfügung stehen müssen, als von der On-Board-Unit übertragen worden sind, so ist es erfindungsgemäß vorgesehen, dass zusätzliche Fixes unter Zugriff auf ein Approximations-Modul eingefügt werden. Das Approximations-Modul greift insbesondere auf zumindest ein Approximations-Verfahren, insbesondere auf eine Spline-Approximation zu, die die bereits erfassten Daten jeweils in Bezug zueinander setzt und aufgrund eines Näherungs-Algorithmus die fehlenden Daten generiert und somit die Lücken schließt.
  • In der bevorzugten Ausführungsform der Erfindung kann es eingestellt werden, zu welchen Zeitpunkten die Daten von der On-Board-Unit an das Back-Office übertragen werden. Es ist möglich, hier konfigurierbare Zeitintervalle vorzusehen, was zu einer zeitabhängigen Übertragung führt. Kumulativ oder alternativ ist es möglich, die Übertragung zu triggern, sobald ein vorbestimmbarer Schwellenwert erreicht ist. Ist die On-Board-Unit beispielsweise mit einem Pufferspeicher ausgebildet, so kann eingestellt werden, dass die Daten dann übertragen werden, wenn eine Kapazität des Pufferspeichers nahezu erreicht ist. Es ist auch möglich, die On-Board-Unit ohne Pufferspeicher auszubilden. In diesem Fall können die Daten nach Empfang einer bestimmten Datengröße übertragen werden.
  • Üblicherweise werden die von dem Back-Office berechneten normalisierten Positionsdaten in einem konfigurierbaren Format bereitgestellt. Das Format ist in der Regel an die Anforderungen der Service-Instanz für die Weiterverarbeitung angepasst. Neben dem kartesischen Koordinatensystem mit x-, y- und z-Achse können die Positionsdaten auch in einem beliebigen anderen Format bereitgestellt werden, wie z.B. in dem WGS84-Format.
  • Die Normalisierung der Daten wird im Back-Office ausgeführt. Ziel der Normalisierung ist es, abhängig von den Anforderungen des nachgelagerten Dienstes bzw. der nach gelagerten Berechnungen der Service-Instanzen schnell und einfach die benötigten Positionsdaten in dem gewünschten Format bereitstellen zu können. Die Service Instanzen können die so verarbeiteten Daten nach spezifischen Anforderungen weiter veredeln. Die Daten, die von der mobilen On-Board Unit an das Back-Office übertragen werden, sind Satellitenrohdaten. Diese werden im Back-Office verlustfrei in eine andere Repräsentation der Daten transformiert, nämlich in normalisierte Positionsdaten. Aus den normalisierten Positionsdaten können dann alle gewünschten Formate berechnet werden.
  • Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist in der Modularität des Systems zu sehen. Damit kann das System beliebig und auf einfache Weise erweitert werden, indem weitere Service-Instanzen über geeignete Schnittstellen hinzugefügt werden. In der Regel handelt es sich bei den Service-Instanzen um solche, die zur Verarbeitung von positions-bezbgenen Daten ausgelegt sind.
  • Eine On-Board-Unit ist jeweils mit einem Empfänger ausgestattet, der zum Empfang von positions-bezogenen Satelliten-Rohdaten bestimmt ist. Zusätzlich oder alternativ ist es möglich, die jeweiligen On-Board-Units mit einer Schnittstelle für ein DSRC-System auszubilden (DSRC - Dedicated-Short-Range-Communication). Ein DSRC-System ist nachteiliger Weise nur für kurze Distanzen, insbesondere solche unter 8 Meter, ausgelegt und umfasst einen DSRC-Tag, der an der mobilen Einheit angeordnet ist und erfordert weiterhin bauliche Maßnahmen auf der Straße, insbesondere in Form von Baken, die elektronische Module umfassen und dazu ausgelegt sind, die "vorbeifahrenden" DSRC-Tags der jeweiligen Fahrzeuge zu registrieren. Die an der Bake erfassten Daten werden dann an das Back-Office übertragen. Dieses System findet heute z.B. in Österreich Anwendung, indem jeweils ein mautpflichtiger Streckenabschnitt von zwei Begrenzungs-Baken eingefasst wird. Vorteilhafterweise ist die erfindungsgemäße Lösung so ausgebildet, dass sie mit solchen DSRC-Systemen interagieren kann. Deshalb kann die erfindungsgemäße On-Board-Unit mit zumindest einer entsprechenden Schnittstelle ausgebildet sein. In diesem Fall übernimmt die erfindungsgemäße On-Board-Unit die Funktion des normalen DSRC-Tags. Sobald also die DSRC-Kommunikation aktiviert wird, bereitet die erfindungsgemäße On-Board-Unit das entsprechende DSRC-Modem (oder gegebenenfalls mehrere Modems) für die anstehende Kommunikation vor und überwacht diese. Darüber hinaus ist es erfindungsgemäß möglich, die On-Board-Unit in einem wählbaren Dual-Modus zu betreiben. Die DSRC-Datenerfassung kann also alternativ und kumulativ zur Satelliten-Rohdaten-Erhebung über Satellitenpositionsdaten (GPS/Galileo) erfolgen. Dies ist insbesondere dann sinnvoll, falls eine durchgeführte DSRC-Erhebung nicht erfolgreich oder fehlerhaft ist und so über den alternativen Weg ausgeglichen werden kann. Mit diesem Merkmal können die Einsatzmöglichkeiten der erfindungsgemäßen Lösung deutlich erweitert werden und auch in bestehende Anwendungen integriert werden. Darüber hinaus können Fehlermöglichkeiten reduziert werden, die durch fehlerhafte Datenerfassung entstehen.
  • Die bevorzugte Ausführungsform der Erfindung umfasst einen Aktivierungs-Mechanismus, der automatisch nach einstellbaren Kriterien das Übertragen der positions-bezogenen Daten von der On-Board-Unit an das Back-Office ermöglicht/aktiviert oder nicht ermöglicht/deaktiviert. Üblicherweise basieren die Kriterien auf einer erfassten Länderkennung bzw. eines Gebiets, insbesondere eines Gebiets eines Betreibers von Mobilfunknetzen und/oder von Mautsystemen. Der Hintergrund für dieses Merkmal liegt darin, dass es Länder gibt, für die noch keine Mauterhebung eingeführt ist oder die nur eine Mauterhebung für bestimmte Fahrzeugtypen vorsehen. Mit diesem Merkmal ist es möglich, die Kommunikation zwischen On-Board-Unit und dem Back-Office so lange zu unterbinden bzw. zu deaktivieren, bis die Erhebung von positions-bezogenen Daten Sinn macht, z.B. bis ein Mautsystem in diesem Land in Betrieb genommen worden ist. Damit kann sichergestellt werden, dass die Kosten für den Verbindungsaufbau zwischen On-Board-Unit und dem Back-Office gesenkt werden können, die ansonsten durch ein unnötiges Senden von positions-bezogenen Daten entstehen würden. Alternativ kann der Aktivierungs-Mechanismus auch auf anderen Kriterien basieren (wie z.B. Tageszeit-Intervalle, in denen keine Maut für eine bestimmte Strecke erhoben wird).
  • Jede On-Board-Unit kann vom Back-Office eindeutig identifiziert werden. Dies erfolgt insbesondere über Bestandteile einer SIM-Karte und/oder einer GeräteSeriennummer. Damit ist es möglich, an das Back-Office übermittelte positions-bezogene Daten automatisch und eindeutig einer On-Board-Unit zuzuordnen. In einer alternativen Ausführungsform der Erfindung können auch mehrere On-Board-Units zu einer Gruppe von On-Board-Units zusammengefasst werden. Dies kann insbesondere bei Flotten-Management-Systemen für eine Gruppe von Fahrzeugen eines Logistik-Unternehmens sinnvoll sein.
  • Falls diese eindeutige ldentifizierungsnummer der On-Board-Unit mit den Betreibernummern kollidiert bzw. im Nummernkreis inkompatibel ist, kann ein Betreiber auf Wunsch eine eigene Nummer angeben, eine sogenannte virtuelle ID. Diese wird mit der eindeutigen Nummer der On-Board-Unit verknüpft (Mapping). Befindet sich die On-Board-Unit in dem Gebiet dieses Betreibers, wird intern die eindeutige Nummer und extern zum Betreiber die genannte virtuelle ID übermittelt. Die Verarbeitung mit der internen ID ist für den Betreiber gekapselt, sodass dieser - wie gewohnt - seine proprietäre ID verwenden kann. Erfindungsgemäß basiert die Mappingvorschrift auf einer eineindeutigen Zuordnungsrelation.
  • Es kann hierfür eine Datenstruktur erzeugt werden, in der für jede On-Board-Unit eine eindeutige Identifikationsnummer abgelegt ist und/oder eine virtuelle Identifikationsnummer eines Service-Providers abgelegt ist, umfassend Mappingvorschriften, die eine eineindeutige Relation zwischen virtueller Identifikationsnummer und Identifikationsnummer definieren. Falls DSRC-Tags verwendet werden, können entsprechend virtuelle DSRC-Tag-IDs verwendet werden, die dann auf die internen DSRC-Tag-IDs gemappt werden.
  • Das Back-Office umfasst eine zentrale Speicher- und/oder Steuer-Einheit. Die jeweiligen On-Board-Units werden durch diese Steuer-Einheit des Back-Office gesteuert. Die Speicher-Einheit des Back-Office dient zur Speicherung der positions-bezogenen Daten der On-Board-Unit und/oder der normalisierten Positionsdaten und/oder sonstiger Datensätze, z.B. von Statusmeldungen oder dergleichen. Damit wird es möglich, (auch zeitlich zurückliegende) Datensätze einer weiteren Verarbeitung zuzuführen, ohne dass diese Daten neu erhoben werden müssen. Auch wird es möglich, bereits erhobene Daten einer Fehlerüberprüfung und -kontrolle zu unterziehen. Fehler können z.B. durch eine fehlerhafte Erfassung der Satelliten-Rohdaten verursacht werden. Die Satelliten-Betreiber veröffentlichen solche Fehlermeldungen. Diese können erfindungsgemäß den somit fehlerhaft erfassten positions-bezogenen Daten zugeordnet werden und insgesamt können korrekte Positionsdaten abgeleitet werden.
  • Falls von der On-Board-Unit Pseudo-Range-Daten an das Back-Office übertragen werden, so sind diese Daten aufgrund der Erfassungsmethode mit Fehlern behaftet. Der Fehler basiert auf den Signal-Laufzeiten zwischen Satellit und Receiver (i.e. der On-Board-Unit). Bei einer Pseudo-Range-Messung werden die Signal-Laufzeiten im Vergleich zu einer Empfänger-Uhr gemessen, die nicht mit den Sende-Uhren (der Satelliten) synchronisiert ist. Die "Pseudo-Ranges" sind deshalb nur scheinbare Entfernungen und ergeben sich aus dem Produkt der jeweiligen Zeit und der Ausbreitungsgeschwindigkeit des Signals. Dieser Fehler kann erfindungsgemäß eliminiert bzw. herausgerechnet werden, indem Referenz-Positions-Signale von stationären Referenzstationen erfasst werden. Beispielsweise werden für ein Gebiet der Bundesrepublik Deutschland vier Referenzstationen verwendet. Die von den stationären Referenzstationen erfassten Referenzdaten werden bei der Berechnung der normalisierten Positionsdaten innerhalb des Back-Office, insbesondere der Positions-Berechnungsinstanz verwendet. Darüber hinaus ist es möglich, andere bekannte Fehlerbehebungs-Maßnahmen zur Bereinigung der Datensätze über entsprechende Schnittstellen an das erfindungsgemäße System anzubinden, um die Qualität der erfassten Positionsdaten zu erhöhen.
  • In einer vorteilhaften Weiterbildung der Erfindung werden nicht Pseudo-Range-Daten von der On-Board-Unit an das Back-Office übertragen, sondern bereits Satellitenpositionsdaten-Daten. In dieser Ausführungsform kann die Positions-Berechnungsinstanz wesentlich schlanker gestaltet werden und ist vorzugsweise lediglich zum Einlesen der jeweiligen Daten bestimmt. Gegebenenfalls können diese Daten in ein anderes Format transformiert werden, abhängig von den Anforderungen der Service-Instanzen für die weitere Verarbeitung der Daten.
  • In der bevorzugten Ausführungsform der Erfindung wird zumindest einer der Verfahrensschritte und vorzugsweise alle Verfahrensschritte automatisch ausgeführt. Es ist demnach möglich, die Bemautung vollautomatisiert auszuführen, ohne dass es notwendig ist, bestimmte Berechnungen "von Hand" anstoßen zu müssen.
  • Im Betrieb ist das erfindungsgemäße System so ausgelegt, dass nach dem Einschalten die jeweilige On-Board-Unit ihre aktuelle Position automatisch erkennt. Dies erfolgt üblicherweise über einen GPS-Receiver und/oder über einen Galileo-Receiver. Abhängig von der aktuellen Position und Konfiguration aktiviert die On-Board-Unit:
    • das automatische Erfassen und Speichern der positions-bezogenen Daten und/oder
    • eines der DSRC-Interfaces oder
    • keines der beiden.
  • Aufgrund der ermittelten aktuellen Position ist es möglich, dass die On-Board-Unit automatisch und selbständig entscheidet, welcher Betriebsmodus aktiviert werden muss, und dass jederzeit ein Wechsel durchgeführt werden kann. Üblicherweise basiert der Betriebsmodus auf der erfassten Länderkennung.
  • Um die Sicherheit des Systems zu erhöhen, ist es vorgesehen, dass jede Kommunikation zwischen der On-Board-Unit und dem Back-Office auf erfolgreiche Autorisierung überprüft wird. Vorzugsweise ist ein Connection-Service als Bindeglied zwischen dem Back-Office und den jeweiligen On-Board-Units vorgesehen, der die Telegramme bzw. Pakete zwischen den On-Board-Units und dem Back-Office routet und ver- und entschlüsselt, Signaturen der Telegramme generiert und prüft und die On-Board-Unit auf eine erfolgreiche Authentifizierung hin überprüft.
  • Ein Communication-Service wird üblicherweise durch einen oder mehrere Mobilfunkbetreiber in unterschiedlichen Ländern bereitgestellt. Über diese Komponente werden die gesammelten positions-bezogenen Daten, etwaige Statusmeldungen bzw. Updates an das Back-Office übertragen. Es ist auch möglich, die Steuerung der On-Board-Units ausgehend von dem Back-Office über diesen Kommunikations-Kanal abzuwickeln.
  • Darüber hinaus wird die Aufgabe durch ein System zur Verarbeitung von positions-bezogenen Daten gelöst, umfassend:
    • eine Vielzahl von mobilen On-Board-Units, wobei jeweils eine On-Board-Unit einem mobilen Gerät, insbesondere einem Fahrzeug, zugeordnet ist und dazu bestimmt ist, die positions-bezogenen Daten des Fahrzeugs zu erfassen,
    • ein zentrales Back-Office, das zur Verarbeitung der von der On-Board-Unit erfassten und übertragenen positions-bezogenen Daten bestimmt ist, und das zumindest eine Positions-Berechnungsinstanz umfasst, die dazu bestimmt ist, die von der On-Board-Unit erfassten Daten einzulesen und aus diesen Daten normalisierte Positionsdaten zu berechnen,
    • zumindest eine Service-Instanz, die dazu bestimmt ist, die normalisierten Positionsdaten und/oder die positions-bezogenen Daten weiterzuverarbeiten, wobei die On-Board-Unit und das Back-Office über eine spezifische Schnittstelle in Datenaustausch stehen.
  • Die jeweiligen mobilen On-Board-Units sind erfindungsgemäß als Thin Clients ausgebildet und möglichst alle Verarbeitungs- und Berechnungsinstanzen sind im Back-Office angeordnet oder diesem zugeordnet. Es ist möglich, die jeweiligen Berechnungsinstanzen in das Back-Office zu integrieren. Alternativ ist es möglich, die vorstehend erwähnten Instanzen als separate modulare Bauteile vorzusehen und über entsprechende Schnittstellen an das Back-Office anzubinden.
  • Darüber hinaus wird die Aufgabe der Erfindung durch eine Vorrichtung zur Verarbeitung von positions-bezogenen Daten gelöst, mit Mitteln, die zur Ausführung zumindest eines der vorstehend erwähnten Verfahren ausgelegt sind.
  • Das vorstehend in Bezug auf das erfindungsgemäße Verfahren Gesagte ist entsprechend auch auf die erfindungsgemäße Vorrichtung und auf das erfindungsgemäße System anzuwenden.
  • 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 Einheiten und möglichen Datenströmen gemäß einer vorteilhaften Ausführungsform der Erfindung,
    Figur 2
    eine übersichtsartige Darstellung von Einheiten gemäß einer vorteilhaften Weiterbildung der Erfindung,
    Figur 3
    eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von positions-bezogenen Daten in einem Back-Office,
    Figur 4
    eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von Satellitenpositionsdaten im Back-Office,
    Figur 5
    eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von positions-bezogenen Daten über ein Road-Identification-Interface und
    Figur 6
    eine übersichtsartige Darstellung eines Prozesses für die Datenerhebung in der On-Board-Unit.
  • In Zusammenhang mit Fig.1 werden nachfolgend die wesentlichen Bauteile gemäß einer vorteilhaften Ausführungsform der Erfindung erläutert:
  • Eine mobile On-Board-Unit OBU ist an einem Fahrzeug angebracht. Dies erfolgt üblicherweise über ein Verkleben an der Windschutzscheibe oder über eine sonstige Integration im Fahrzeug.
  • Das System umfasst eine Vielzahl von mobilen On-Board-Units OBU und ein stationäres, zentrales Back-Office BO. Dabei ist jeweils eine On-Board-Unit OBU zur Erfassung von positions-bezogenen Daten, insbesondere über einen GPS- und/oder Galileo-Receiver 10 ausgelegt. Die positions-bezogenen Daten können in einem Puffer-Speicher 12 zwischengespeichert werden und werden dann einer Sende-Einheit 14 zugeführt. Die Sende-Einheit 14 dient zur Übertragung von positions-bezogenen Daten von der On-Board-Unit OBU an das Back-Office BO. Das Back-Office BO ist zur Verarbeitung, insbesondere zur Veredlung, der empfangenen positions-bezogenen Daten bestimmt. Das Back-Office BO umfasst eine Positions-Berechnungsinstanz 15, die dazu bestimmt ist, die empfangenen positions-bezogenen Daten in normalisierte Positionsdaten zu transformieren. Diese Zwischendarstellung der normalisierten Positionsdaten dient zur einfachen Umformung der Positionsdaten in weitere Formate. Dies erfolgt anhand von Anforderungen, die eine oder mehrere Service-Instanzen 16 der Positions-Berechnungsinstanz 15 melden.
  • Grundsätzlich ist die On-Board-Unit OBU möglichst kompakt und einfach ausgebildet, während das Back-Office BO zur zentralen und umfangreichen Datenverarbeitung dient.
  • Der GPS- und/oder Galileo-Receiver 10 der On-Board-Unit OBU ist zum Empfang von Satelliten-Rohdaten bestimmt. Die von Satelliten S empfangenen positions-bezogenen Daten werden von dem GPS- und/oder Galileo-Receiver 10 - gegebenenfalls über einen Pufferspeicher 12 - an die Sende-Einheit 14 zur Übertragung an das Back-Office BO weitergeleitet.
  • Das Back-Office BO berechnet aus diesen positions-bezogenen Daten - gegebenenfalls unter Zugriff auf weitere Module - normalisierte Positionsdaten. Die normalisierten Positionsdaten können als Input für eine weitere Verarbeitung durch die Service-Instanzen 16 dienen.
  • Bei den von der On-Board-Unit OBU an das Back-Office BO übertragenen positions-bezogenen Daten kann es sich um Pseudo-Range-Daten, um GPS- bzw. Galileo-Daten und/oder um Vektor-Daten handeln. Falls Pseudo-Range-Daten übertragen werden, so kann der aufgrund der Signal-Laufzeit entstandene Fehler in dem Back-Office BO eliminiert werden, indem das Back-Office BO auf zumindest eine Referenzstationen Ri zugreift. Die Referenzstationen Ri sind stationär angeordnet und für den Empfang von Satelliten-Rohdaten ausgelegt. Die Positions-Referenzdaten, die von den Referenzstationen Ri empfangen werden, werden an die Positions-Berechnungsinstanz 15 des Back-Office BO weitergeleitet. Aus einer Differenzbildung der beiden Signal-Läufe kann ein fehlerfreies normalisiertes Positions-Signal abgegriffen werden. Dieses Signal wird den Service-Instanzen 16 zur weiteren Verarbeitung zugeführt.
  • In Fig.1 soll die gestrichelte Linie um die Satelliten Si andeuten, dass die jeweiligen Satelliten zu einer Satelliten-Betreibergesellschaft gehören. Die Satelliten-Betreiber veröffentlichen Daten, aus denen Fehler in bezug auf die Satelliten-Rohdaten abgeleitet werden können. In einer vorteilhaften Weiterbildung der Erfindung greift die Positions-Berechnungsinstanz 15 auf diese Meldungen zu und berechnet aufgrund dieser Daten korrigierte normalisierte Positionsdaten.
  • Erfindungsgemäß kann die Positions-Berechnungsinstanz 15 in dem Back-Office BO so konfiguriert werden, dass die von ihr erzeugten normalisierten Positionsdaten so erzeugt werden, dass sie für eine Weiterverarbeitung durch die jeweiligen Service-Instanzen 16 ausgelegt sind. Dazu ist es notwendig, dass die jeweiligen Service-Instanzen 16 ihre Anforderungen an die Positionsdaten an die Positions-Berechnungsinstanz 15 melden. Deshalb gibt es in dieser Ausführungsform der Erfindung auch einen Datenfluss, der von den Service-Instanzen 16 an das Back-Office BO, insbesondere an die Positions-Berechnungsinstanz 15 verläuft (dieser ist in Figur 1 jedoch nicht dargestellt).
  • Grundsätzlich kann eine beliebige Anzahl von unterschiedlichen Service-Instanzen 16 an das System angeschlossen werden. Eine Service-Instanz 16 kann insbesondere auf die Verarbeitung der normalisierten Positionsdaten für ein Mautsystem, für die Abrechnung in einem Mautsystem oder z.B. für das Clearing in einem Mautsystem herangezogen werden. Darüber hinaus ist es möglich, dass andere Weiterverarbeitungs-Verfahren durch Service-Instanzen 16 ausgeführt werden.
  • Üblicherweise umfasst eine On-Board-Unit OBU ein Gehäuse, einen Prozessor, einen GPS- und/oder Galileo-Receiver 10, einen Pufferspeicher 12, eine Stromversorgungs-Einheit, eine Benutzer-Schnittstelle, eine integrierte GPS/GSM- und/oder Galileo/GSM-Antenne und/oder eine integrierte DSRC-Antenne, Schnittstellen für weitere Antennen bzw. Kommunikations-Komponenten, einen Kabelsatz für eine Netzanbindung über Festinstallation und/oder ZigarettenAnzünder, ein Betriebssystem und Anwendungssoftware und Treiber. Optional ist es möglich, die On-Board-Unit OBU zusätzlich mit einem Flash-Disc, einem GSM-Interface inklusive SEM-Halter, LEDs, einem Krypto-Chip zur Ver- und Entschlüsselung und/oder mit einer Anbindung an ein Tachosignal auszubilden. Schaltungstechnisch ist die On-Board-Unit OBU so ausgelegt, dass lediglich eine Verkabelung für die Stromversorgung und gegebenenfalls für die Antennen benötigt wird. Optional kann es eine Anbindung an einen Tachosignalgeber geben.
  • Nachfolgend werden unter Bezugnahme auf Fig.2 die wesentlichen Komponenten gemäß der vorteilhaften Ausführungsform der Erfindung erläutert:
  • Wie in Fig.2 dargestellt, kommuniziert das Back-Office BO mit der jeweiligen Service-Instanz 16, hier den Maut-Betreibern A - C, bzw. mit dem Abrechnungssystem. Es ist möglich, weitere Service-Instanzen 16 vorzusehen. Diese können in der Verwaltung/dem Controlling, einem Call-Center, einer Reklamations-Einheit, einer Auftrags- und Bestelleinheit, einer Software-Entwicklungs- und Bereitstellungseinheit, einem Geo-Object-Update-Provider, einer Vertriebseinheit und einer Zertifizierungseinheit bestehen.
  • Darüber hinaus können Schnittstellen zu Herstellern von On-Board-Units OBU und/oder zu sogenannten Enforcement-Instanzen von Service-Providern bestehen. Die Enforcement-Instanzen dienen zum Schutz vor Manipulationen und können bei einem als illegal identifizierten Vorgehen innerhalb des Mautsystems entsprechende Gegenmaßnahmen triggern (z.B. das entsprechende Weiterleiten von Daten, das Aufnehmen eines Fotos etc.).
  • Neben den Referenzstationen Ri, die dem Back-Office BO zugeordnet sind, umfasst das Back-Office BO einen OBU-Home-Operator, einen Connection-Service und ein Position-Interface.
  • Das Back-Office BO besteht in der bevorzugten Ausführungsform aus dem "Standard Back Office" und dem "Europa OBU Service", der zur Verarbeitung von mautbezogenen Positionsdaten bestimmt ist. Dies ist in Figur 2 durch die beiden Teilkästen des Back-Office BO dargestellt.
  • Darüber hinaus ist ein Communication-Service vorgesehen, der vorzugsweise von einem oder mehreren Mobilfunk-Betreiber(n) bereitgestellt wird. Er ist, wie in Figur 2 dargestellt, als externe Komponente dem Back-Office zugeordnet. Die MobilfunkBetreiber können unterschiedlichen Staaten angehören. Über diese Komponente werden die erfassten positions-bezogenen Daten (aber auch Status-Meldungen bzw. Updates) an das Back-Office BO übertragen.
  • Der Connection-Service ist ein Bindeglied zwischen dem Back-Office BO und dem On-Board-Unit OBU. Die Aufgabe dieser Komponente ist es, die zu übertragenden Daten-Pakete bzw. Telegramme zwischen den On-Board-Units OBU und dem Back-Office BO zu routen, diese zu ver- und entschlüsseln, deren Signaturen zu erzeugen und zu überprüfen und mit Hilfe des OBU-Home-Operators auf Gültigkeit der OBU zu prüfen (Authentifizierungsvorgang).
  • In einer einfachsten Ausführungsform der Erfindung kann die Positions-Berechnungsinstanz 15 aus dem "Position-Interface" bestehen. Dieser Service nimmt die gesammelten und erfassten positions-bezogenen Daten, basierend auf den GPS- und/oder Galileo-Daten, auf den Pseudo-Range-Daten oder Vektor-Daten, entgegen und berechnet daraus die normalisierten Positionsdaten. Bei der Nutzung von Pseudo-Range-Daten werden zusätzlich die Positions-Referenzdaten der Referenzstationen R entgegengenommen. Darüber hinaus dient dieser Service dazu, die Satelliten-Fehlerinformationen, die vom Satelliten-Betreiber zur Verfügung gestellt werden, entgegenzunehmen und aufgrund der entgegengenommenen Daten die normalisierten Positionsdaten zu berechnen. Daraufhin legt die Positions-Berechnungsinstanz 15 die Daten in einer Datenbank ab und informiert bei Bedarf eine weitere Komponente über diese Daten bzw. stellt die normalisierten Positionsdaten weiteren Service-Instanzen bzw. Komponenten zur Verfügung.
  • Der OBU-Home-Operator ist eine zentrale Speicher- und Steuer-Einheit für alle On-Board-Units OBU. Diese Komponente stellt allen übrigen Komponenten Parameter zur Verfügung, die von der On-Board-Unit OBU abhängig sind. Der OBU-Home-Operator hat folgende Aufgaben:
    • Speichern aller gültigen Identifikationen der On-Board-Units OBU, wodurch eine eindeutige Identifikation aller On-Board-Units OBU und eine Authentifizierung derselben möglich wird;
    • Speichern von virtuellen OBU-IDs (z.B. DSRC-Tags-lDs).
    • Speichern von allgemeinen Konfigurations-Parametern für die On-Board-Units OBU;
    • Speichern von Parametern, die für jeweilige Service-Instanzen 16 notwendig sind, z.B. länderabhängige Parameter, Fahrzeugdaten, Datenbereitstellungs-Zyklen (Online, Batch);
    • Bereitstellen der notwendigen Schlüsselpaare zur Ver- und Entschlüsselung;
    • Speichern aller geräteabhängigen On-Board-Unit-Parameter;
    • Senden von Signalen eines Aktivierungs-Mechanismus, insbesondere von Aktivierungs- und Deaktivierungs-SMS.
  • Der OBU-Home-Operator stellt die OBU-Parameter online zur Verfügung.
  • Üblicherweise kommunizieren die Komponenten innerhalb des Back-Office BO über ein standardisiertes Protokollformat (vgl. XML-Telegramme). Die Kommunikation zwischen On-Board-Unit OBU und Connection-Service basiert überlicherweise auf einem optimierten proprietären Protokoll.
  • Besteht die Service-Instanz 16 aus einem Mautsystem, so weist das Back-Office BO folgende weitere Komponenten auf:
    • Einen "Geo-Objekt-Manager". Diese Komponente dient dazu, einzelne mautpflichtige Geo-Objekte und deren Parameter (Streckenberechnung, Fixe Länge, Straßentyp, Koordinaten etc.) bereitzustellen. Grundsätzlich kann für jedes Geo-Objekt ein Tarif abgelegt werden.
    • Ein "GPS-Position-InterFace". Diese Schnittstelle nimmt entweder auf Anforderung oder im Batch-Betrieb in zyklischen Abständen die verfügbaren positions-bezogenen Daten des Positionsdaten-Interface der On-Board-Unit OBU entgegen und berechnet aus diesen Daten die normalisierten Positions-Daten. Diese Berechnung erfolgt abhängig von den Anforderungen der Service-Instanzen 16. Insbesondere ist es möglich, die Berechnungen in einem speziellen Format bereitzustellen, insbesondere im kartesischen Koordinatensystem oder in dem WGS84-Format. Darüber hinaus ist es möglich, eine Approximation von positions-bezogenen Daten auszuführen. Dies ist insbesondere dann sinnvoll, wenn die Anzahl der Fixes für die Berechnung der jeweiligen Service-Instanz 16 nicht ausreicht und weitere GPS- bzw. Galileo-Fixes notwendig sind, die jedoch nicht erfasst sind. Dann können mit Hilfe dieses Approximations-Verfahrens die Lücken für die fehlenden GPS- bzw Galileo-Fixes nachgebildet werden.
    • Eine "Road-Identification-Schnittstelle". Diese Road-Identification-Schnittstelle (nachfolgend kurz RI-Interface genannt) nimmt die Positions-Daten entgegen und bestimmt daraus alle mautpflichtigen Geo-Objekte, z.B. mautpflichtige Abschnitte, Zonen, Strecken-Längen etc. Mit dem RI-Interface ist es möglich, auch virtuelle Baken zu bestimmen, die auch reale Baken nachbilden können. Somit kann auch eine Bemautung bei DSRCbasierten Strecken ausgeführt werden. Insgesamt dient das RI-Interface dazu, die berechneten mautpflichtigen Geo-Objekte bereitzustellen und gegebenenfalls zu speichern.
    • Ein Transaktions-System. Das Transaktions-System berechnet auf Basis der mautpflichtigen Geo-Objekte und der Tariftabellen die Mautgebühren für den Zeitpunkt, in dem das Objekt befahren wurde. Zusätzlich können in diesem System Prüfungen durchgeführt werden, die die erfassten Daten auf Korrektheit überprüfen. Hierunter fallen Überprüfungen hinsichtlich der logischen Reihenfolge der Geo-Objekte und Zeitstempel, Sprünge und Lücken, Geschwindigkeit etc. Das Transaktions-System speichert alle Transaktions-Daten und übermittelt diese online oder im Batch-Betrieb.
  • Des Weiteren kann das erfindungsgemäße System mit weiteren Schnittstellen ausgebildet sein, um weitere Komponenten anzuschließen.
  • In Fig.3 ist der grundsätzliche Ablauf der Datenverarbeitung gemäß einer bevorzugten Ausführungsform im Back-Office BO, insbesondere in der Positions-Berechnungsinstanz 15 dargestellt, die in Fig.3 als Positionsdaten-Interface gekennzeichnet ist. Die On-Board-Unit OBU erfasst im Normalbetrieb positions-bezogene Daten, die auf optimierte Art und Weise komprimiert werden. Darüber hinaus erfolgt eine Datenreduktion vor der Übertragung der Daten von der On-Board-Unit OBU an das Back-Office BO, indem nicht alle Fixes (das heißt alle Positionsdatenerfassungen) übertragen werden, sondern nur ausgewählte. Die gefahrene Strecke kann über mathematische Approximations-Verfahren, insbesondere über eine Spline-Approximation, mit hinreichender Genauigkeit rekonstruiert werden. Darüber hinaus ist es möglich, alternative Aufzeichnungsverfahren zu verwenden, wie z.B. die Aufzeichnung von Pseudo-Range-Daten, die eine wesentlich höhere Genauigkeit der Positionsdaten-Bestimmung erlauben, als dies bei GPS-, Galileo- oder Vektor-Daten der Fall ist und gleichzeitig eine hohe Komprimierung ermöglichen. Der in Fig.3 abgebildete Prozess zeigt, wie das Back-Office BO die erfassten und aufgezeichneten positions-bezogenen Daten verarbeitet. Die Schritte, die auf dem Positionsdaten-Interface zwischen dem horizontal gestrichelten Linien erfolgen, sind dann notwendig bzw. empfehlenswert, falls von der On-Board-Unit OBU Pseudo-Range-Daten übertragen werden. Sie sind nicht notwendig, falls bereits GPS-, Galileo- oder Vektor-Daten übergeben werden. Dann können die Positionsdaten unmittelbar in normalisierter Form abgespeichert werden.
  • In Fig.4 ist übersichtsartig ein Prozess der Datenverarbeitung von Satellitenpositionsdaten Daten in dem Back-Office BO dargestellt. In der Positions-Berechnungsinstanz 15, die in Fig.4 mit "GPS-Position-Interface" gekennzeichnet ist, werden die Positions-Daten berechnet und jedem Service-Provider bzw. jeder Service-Instanz 16 und weiteren Komponenten im gewünschten Format bereitgestellt. Die Service-Instanz 16 ist in Fig.4 mit dem Begriff "Service-Provider" gekennzeichnet. Die Prozess-Schritte, die zwischen den beiden horizontal verlaufenden, gestrichelten Linien dargestellt sind, beziehen sich auf die Positionsdatenübertragung an die Service-Provider bzw. an die Service-Instanzen 16.
  • In Fig.5 ist die Datenverarbeitung in dem Back-Office BO, insbesondere in dem RI-Interface dargestellt. Das RI-Interface erkennt aus den übertragenen positions-bezogenen Daten die mautpflichtigen Geo-Objekte und leitet daraus die notwendigen Parameter her. Hier wird auch der zurückgelegte Weg innerhalb des mautpflichtigen Geo-Objekts berechnet, um daraus eine streckenabhängige Mauterhebung abzuleiten. Das RI-Interface kommuniziert sowohl mit dem "GPS-Position-InterFace" als auch mit dem Geo-Objekt-Manager, um die mautbezogenen Daten zu erfassen. Die Prozess-Schritte, die zwischen den beiden horizontal verlaufenden, gestrichelten Linien dargestellt sind, beziehen sich auf eine mautpflichtige Objektübertragung an die jeweiligen Service-Instanzen 16.
  • In der bevorzugten Ausführungsform der Erfindung ist es vorgesehen, dass ein Event-Logging stattfindet. Damit wird es möglich, Fehlfunktionen nachzuvollziehen und gegebenenfalls zu diagnostizieren. Auch wird es damit möglich, Reklamationen über fehlerhafte Mauterfassungen oder falsche Gebührenberechnungen (auch zu einem späteren Zeitpunkt) zu bearbeiten. Grundsätzlich werden alle Aktivitäten der vorstehend besprochenen Einheiten und Instanzen archiviert und in einem Fehlerbericht zusammengefasst. Es ist auch möglich, nur eine Auswahl von Events mitzuführen.
  • Aufgrund der modularen Architektur des Systems ist es jederzeit und ohne Schwierigkeiten möglich, dem System eine neue Service-Instanz 16 hinzuzufügen. Dazu ist es lediglich notwendig, dass die jeweilige On-Board-Unit OBU über eine entsprechende Schnittstelle über die wesentlichen Parameter der neu aufgenommenen Service-Instanz 16 (wie z.B. Time-Out, Puffergröße, Gebiet etc.) informiert wird.
  • Es ist auch möglich, dass die Service-Instanz 16 über den OBU-Home-Operator eine spezielle On-Board-Unit OBU sperrt bzw. deaktiviert. Eine entsprechende Bestätigung der Sperrung wird an die Service-Instanz 16 zurückgemeldet. Eine solche Sperrung kann unter Umständen notwendig sein, falls der Service-Provider die Voraussetzungen für eine Sperrung als erfüllt ansieht.
  • In Fig.6 ist beispielhaft gezeigt, wie die Datenerhebung gemäß einer bevorzugten Ausführungsform innerhalb der On-Board-Unit OBU erfolgt. Grundsätzlich gibt es zwei Möglichkeiten: die Erfassung nach dem DSRC-Prinzip und die Erfassung von Satellitenpositionsdaten. Die Prozess-Schritte, die in Fig.6 zwischen den ersten beiden horizontalen, gestrichelten Linien dargestellt sind, beziehen sich auf eine DSRC-Kommunikation mit dem Service-Provider bzw. mit der Service-Instanz 16. Die darunter angeordneten Prozess-Schritte beziehen sich auf eine Back-Office-Kommunikation mit dem Service-Provider.
  • 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
    S
    Satellit
    BO
    Back-Office
    R
    Referenzstation
    10
    GPS- und/oder Galileo-Receiver
    12
    Pufferspeicher
    14
    Sende-Einheit
    15
    Positions-Berechnungsinstanz
    16
    Service-Instanz

Claims (20)

  1. System zur Verarbeitung von positions-bezogenen Daten, umfassend:
    - eine Vielzahl von mobilen On-Board-Units (OBU), wobei jeweils eine On-Board-Unit (OBU) an einem mobilen Gerät, insbesondere an einem Fahrzeug, angeordnet ist und dazu bestimmt ist, die positions-bezogenen Daten des Fahrzeugs zu erfassen,
    - einem zentralen und stationären Back-Office (BO), das zur Verarbeitung der von den On-Board-Unit (OBU) erfassten und übertragenen positions-bezogenen Daten bestimmt ist, und das zumindest eine Positions-Berechnungsinstanz (15) umfasst, die dazu bestimmt ist, die von der On-Board-Unit (OBU) erfassten Daten einzulesen und aus diesen normalisierte Positionsdaten zu berechnen,
    - zumindest eine Service-Instanz (16), die dazu bestimmt ist, die normalisierten Positionsdaten und/oder die positions-bezogenen Daten weiterzuverarbeiten,
    wobei die On-Board-Unit (OBU) und das Back-Office (BO) über eine spezifische Schnittstelle in Datenaustausch stehen.
  2. System nach Anspruch 1, dadurch gekennzeichnet, dass die positions-bezogenen Daten satelliten-basierte Daten sind, insbesondere Satellitenrohdaten, und/oder positions-bezogene Daten in beliebigen Formaten umfassen, wie GPS-, Galileo-, Vektordaten und/oder Pseudo-Range-Daten.
  3. System nach zumindest einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die On-Board-Unit (OBU) und das Back-Office (BO) über zumindest ein Mobilfunknetz in Datenaustausch stehen.
  4. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Daten zwischen der On-Board-Unit (OBU) und dem Back-Office (BO) verschlüsselt und/oder komprimiert übertragen werden.
  5. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Daten in der On-Board-Unit (OBU) über ein DSRC-System und/oder satellitengestützt , insbesondere über GPS oder Galileo erfasst werden.
  6. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass von zumindest einer stationären Referenzstation (Ri) erfasste Referenzdaten für die Berechnung der normalisierten Positionsdaten verwendet werden, falls von der On-Board-Unit (OBU) Pseudo-Range-Datensätze übertragen werden.
  7. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die On-Board-Unit (OBU) die erfassten positions-bezogenen Daten nach konfigurierbaren Zeitintervallen und/oder dann an das Back-Office (BO) überträgt, sobald ein vorbestimmbarer Schwellenwert erreicht ist.
  8. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Positionsberechnungs-Instanz (15) die Daten in Abhängigkeit von Anforderungen der Service-Instanz (16) berechnet und in einem konfigurierbaren Format bereitstellt.
  9. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das System jederzeit erweiterbar ist, indem weitere Service-Instanzen (16) über eine geeignete Schnittstelle hinzugefügt und eingebunden werden.
  10. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die On-Board-Unit (OBU) einen Receiver umfasst, der zum Empfang von Satellitenrohdaten bestimmt ist, insbesondere einen GPS-Receiver und/oder einen Galileo-Receiver.
  11. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das System einen Aktivierungsmechanismus umfasst, der automatisch nach einstellbaren Kriterien, insbesondere in Abhängigkeit von einer zu erfassenden Länderkennung bzw. eines Gebiets, insbesondere ein Gebiet eines Betreibers, das Übertragen von positions-bezogenen Daten von der On-Board-Unit (OBU) an das Back-Office (BO) aktiviert oder deaktiviert.
  12. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass jede On-Board-Unit (OBU) eindeutig vom Back-Office (BO) identifiziert werden kann, insbesondere über Bestandteile einer SIM-Karte und/oder einer Geräteseriennummer.
  13. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass es eine zentrale Speicher- und/oder Steuer-Einheit umfasst, wobei die jeweiligen On-Board-Units (OBU) durch diese Steuer-Einheit des Back-Office (BO) gesteuert werden und wobei die Speicher-Einheit des Back-Office (BO) zur Speicherung der positions-bezogenen Daten der On-Board-Unit (OBU) und/oder der normalisierten Positionsdaten und/oder sonstiger Datensätze, z.B. von Statusmeldungen, dient.
  14. System nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass es ein Approximations-Modul umfasst, das auf zumindest ein Approximations-Verfahren zugreift, insbesondere auf eine Spline-Approximation, die die bereits erfassten Daten jeweils in Bezug zueinander setzt und aufgrund eines Näherungs-Algorithmus nicht erfasste Positionsdaten rein rechnerisch generiert.
  15. Verwendung eines Systems nach zumindest einem der vorstehenden Ansprüche zur Nutzung für Mautsysteme, dadurch gekennzeichnet, dass das Back-Office (BO) zusätzlich einen Geo-Objekt-Manager und eine Road-Identification-Interface umfasst, die dazu bestimmt sind, mautbezogene Daten den normalisierten Positionsdaten zuzuordnen.
  16. Verwendung eines Systems nach zumindest einem der vorstehenden Ansprüche zur Nutzung für eine Abrechnung bei Mautsystemen, dadurch gekennzeichnet, dass das Back-Office (BO) zusätzlich einen Geo-Objekt-Manager und eine Transaktions-Instanz umfasst, die dazu bestimmt sind, automatisch aufgrund der erfassten und verarbeiteten normalisierten Positionsdaten Mautgebühren für die von dem Fahrzeug der On-Board-Unit (OBU) gefahrene Strecke zu berechnen.
  17. Verfahren zur Verarbeitung von positions-bezogenen Daten, mit folgenden Verfahrensschritten:
    A- Erfassen von positions-bezogenen Daten von jeweils einer On-Board-Unit (OBU) aus einer Vielzahl von On-Board-Units (OBU),
    B- Übertragen der positions-bezogenen Daten an ein zentrales Back-Office (BO) über eine Luft-Schnittstelle,
    C- Einlesen der positions-bezogenen Daten durch das Back-Office (BO),
    D- Berechnen von normalisierten Positionsdaten aus den eingelesenen positions-bezogenen Daten und
    E- Weiterleiten der normalisierten Positionsdaten an zumindest eine Service-Instanz (16) zur Weiterverarbeitung in einem gewünschten Format.
  18. Verfahren zur Positionsbestimmung eines mobilen Geräts (OBU), gekennzeichnet durch folgende Schritte:
    - Übertragen von Pseudo-Range-Daten von dem mobilen Gerät (OBU) an ein Back Office (BO),
    - Berechnen der Position des mobilen Gerätes im Back Office (BO) auf Basis der Pseudo-Range-Daten.
  19. Anordnung zur Positionsbestimmung eines mobilen Geräts (OBU), das eine Schnittstelle zu einem Back Office (BO) 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.
  20. System nach zumindest einem der vorstehenden Ansprüche 1 bis 14, dadurch gekennzeichnet, dass eine Datenstruktur erzeugt wird, in der für jede On-Board-Unit (OBU) eine eindeutige Identifikationsnummer und/oder eine virtuelle Identifikationsnummer einer Service-Instanz (16) abgelegt ist, umfassend Mappingvorschriften, die eine eineindeutige Relation zwischen virtueller Identifikationsnummer und Identifikationsnummer definieren.
EP06004735A 2005-03-09 2006-03-08 System zur Verarbeitung von positions-und/oder mautbezogenen Daten für Fahrzeuge Withdrawn EP1708143A3 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE202005009152U DE202005009152U1 (de) 2005-03-09 2005-03-09 Anordnung zur Positionsbestimmung
DE200510010888 DE102005010888A1 (de) 2005-03-09 2005-03-09 Verfahren und 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 (2)

Publication Number Publication Date
EP1708143A2 true EP1708143A2 (de) 2006-10-04
EP1708143A3 EP1708143A3 (de) 2007-04-25

Family

ID=36659950

Family Applications (2)

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
EP06004736A Not-in-force EP1708144B1 (de) 2005-03-09 2006-03-08 Vorrichtung und Verfahren zum Datenaustausch von mautbezogenen Daten bei DSRC-Systemen

Family Applications After (1)

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

Country Status (1)

Country Link
EP (2) EP1708143A3 (de)

Cited By (13)

* 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
EP2043051A1 (de) * 2007-09-21 2009-04-01 Deutsche Telekom AG Verfahren zur Ermittlung streckenbezogener Strassenbenutzungsentgelte 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
EP2624218A1 (de) * 2012-02-02 2013-08-07 Kapsch TrafficCom AG Vorrichtungen und Verfahren zur Kontrolle in einem Straßenmautsystem
EP2709051A1 (de) * 2012-09-17 2014-03-19 Kapsch TrafficCom AG Verfahren zum elektronischen Verarbeiten eines Verkehrsdelikts und Onboard-Unit hierfür
EP2860703A1 (de) * 2013-10-08 2015-04-15 Kapsch TrafficCom AG Verfahren zum Überprüfen von Mauttransaktionen und Komponenten hierfür
EP2866206A1 (de) * 2013-10-23 2015-04-29 Kapsch TrafficCom AG Onboard-Unit und Transaktionsserver für ein Straßenmautsystem
EP2887326A1 (de) 2013-12-20 2015-06-24 Q-Free ASA Zonendetektion in einem GNSS-System
EP3105742A2 (de) * 2014-02-13 2016-12-21 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
CN113379936A (zh) * 2021-03-29 2021-09-10 唐山市曹妃甸区陆月柒峰科技有限责任公司 一种省市级公路费用计算方法和装置
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

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DK2242024T3 (en) 2009-04-14 2015-06-01 Kapsch Trafficcom Ag Procedure components and systems for generation of transaction fee
SI2602767T1 (sl) * 2011-12-05 2014-03-31 Kapsch Trafficcom Ag Postopek in enota na krovu vozila za signaliziranje cestninskih transakcij v cestninskem sistemu
WO2015158591A1 (de) 2014-04-14 2015-10-22 Continental Teves Ag & Co. Ohg Car2x-kommunikation in usa und europa mit einheitlichem transmitter
DE102018204504A1 (de) * 2018-03-23 2019-09-26 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Betreiben eines Mautsystems, computerlesbares Medium, und System

Citations (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
DE19755142A1 (de) * 1997-11-28 1999-06-02 Matthias Kroenke 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
WO2001011571A1 (de) * 1999-08-04 2001-02-15 Vodafone Ag Mautsystem zur zentralen erhebung von nutzungsgebühren von fahrzeugen in einem gebührenpflichtigen wegstreckennetz
US20020038182A1 (en) * 2000-06-06 2002-03-28 Wong Carlos C.H. Wireless vehicle monitoring system
WO2002045047A1 (de) * 2000-11-28 2002-06-06 Frv-Electronics Vertriebs- Und Produktionsgesmbh Verfahren und einrichtung zum erfassen von mindestens einem fahrzeug
DE10155501A1 (de) * 2001-11-13 2003-05-28 Vodafone Ag Erfassungssystem für flächige Bereiche zum Erfassen von Fahrzeugen mit GPS
US20030210160A1 (en) * 2002-05-08 2003-11-13 Hsu Te Hsin Information communicating apparatus for vehicles
DE10228401A1 (de) * 2002-06-25 2004-01-22 Daimlerchrysler Ag Vorrichtung zur Bestimmung von Benutzungsgebühren und Gebührenerfassungssystem
DE20319131U1 (de) * 2003-12-10 2004-03-18 KNÜPFER, Jürgen Vorrichtung für die Überwachung von Ladegut (Ladegutüberwachung)
EP1400937A1 (de) * 2002-09-12 2004-03-24 TeamSharp Space Tech Inc. Kommunikations- und Diebstahlschutzsystem für Motorräder
EP1457928A1 (de) * 2003-03-11 2004-09-15 Atos Origin IT Services UK Ltd. Strassenabrechnungssytem
EP1475752A2 (de) * 2003-05-05 2004-11-10 Vodafone Holding GmbH Verfahren und System zur elektronischen Erhebung von Nutzungsgebühren

Family Cites Families (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
IT1306768B1 (it) * 1999-01-27 2001-10-02 Marcello Federici Sistema di addebito automatico per mezzi di trasporto.
NO310538B1 (no) * 2000-04-28 2001-07-16 Powercom Ventures As System for automatisert betaling av bompenger og parkeringsavgifter
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

Patent Citations (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
DE19755142A1 (de) * 1997-11-28 1999-06-02 Matthias Kroenke 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
WO2001011571A1 (de) * 1999-08-04 2001-02-15 Vodafone Ag Mautsystem zur zentralen erhebung von nutzungsgebühren von fahrzeugen in einem gebührenpflichtigen wegstreckennetz
US20020038182A1 (en) * 2000-06-06 2002-03-28 Wong Carlos C.H. Wireless vehicle monitoring system
WO2002045047A1 (de) * 2000-11-28 2002-06-06 Frv-Electronics Vertriebs- Und Produktionsgesmbh Verfahren und einrichtung zum erfassen von mindestens einem fahrzeug
DE10155501A1 (de) * 2001-11-13 2003-05-28 Vodafone Ag Erfassungssystem für flächige Bereiche zum Erfassen von Fahrzeugen mit GPS
US20030210160A1 (en) * 2002-05-08 2003-11-13 Hsu Te Hsin 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
EP1457928A1 (de) * 2003-03-11 2004-09-15 Atos Origin IT Services UK Ltd. Strassenabrechnungssytem
EP1475752A2 (de) * 2003-05-05 2004-11-10 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)

Cited By (20)

* 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
EP2043051A1 (de) * 2007-09-21 2009-04-01 Deutsche Telekom AG Verfahren zur Ermittlung streckenbezogener Strassenbenutzungsentgelte 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
EP2624218A1 (de) * 2012-02-02 2013-08-07 Kapsch TrafficCom AG Vorrichtungen und Verfahren zur Kontrolle in einem Straßenmautsystem
US8797181B2 (en) 2012-02-02 2014-08-05 Kapsch Trafficcom Ag Control devices and methods for a road toll system
EP2709051A1 (de) * 2012-09-17 2014-03-19 Kapsch TrafficCom AG Verfahren zum elektronischen Verarbeiten eines Verkehrsdelikts und Onboard-Unit hierfür
EP2860703A1 (de) * 2013-10-08 2015-04-15 Kapsch TrafficCom AG Verfahren zum Überprüfen von Mauttransaktionen und Komponenten hierfür
US10055899B2 (en) 2013-10-08 2018-08-21 Kapsch Trafficcom Ag Method for checking toll transactions and components therefor
US11335130B2 (en) 2013-10-08 2022-05-17 Kapsch Trafficcom Ag Method for checking toll transactions and components therefor
EP2866206A1 (de) * 2013-10-23 2015-04-29 Kapsch TrafficCom AG Onboard-Unit und Transaktionsserver für ein Straßenmautsystem
EP2866206B1 (de) 2013-10-23 2015-12-30 Kapsch TrafficCom AG Onboard-Unit und Transaktionsserver für ein Straßenmautsystem
EP2887326A1 (de) 2013-12-20 2015-06-24 Q-Free ASA Zonendetektion in einem GNSS-System
US9886804B2 (en) 2013-12-20 2018-02-06 Q-Free Asa Zone detection in a GNSS system
EP3105742A2 (de) * 2014-02-13 2016-12-21 Continental Automotive GmbH Mauterfassungseinrichtung zum erfassen einer maut eines kraftfahrzeuges
EP3105742B1 (de) * 2014-02-13 2022-10-19 Continental Automotive Technologies GmbH Verfahren 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
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
CN113379936A (zh) * 2021-03-29 2021-09-10 唐山市曹妃甸区陆月柒峰科技有限责任公司 一种省市级公路费用计算方法和装置
CN113379936B (zh) * 2021-03-29 2022-07-08 李任永 一种省市级公路费用计算方法和装置

Also Published As

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

Similar Documents

Publication Publication Date Title
EP1708143A2 (de) System zur Verarbeitung von positions-und/oder mautbezogenen Daten für Fahrzeuge
EP2860703B1 (de) Verfahren zum Überprüfen von Mauttransaktionen und Komponenten hierfür
EP1470033B1 (de) System und verfahren zur durchsetzung von fahrzeuguntersuchungen unter mehrfachdatenübertragungen auf der strasse
EP1358635B1 (de) Verfahren zum erfassen von strassenbenutzungsgebühren
EP2535737B1 (de) Verfahren und System zum Ermitteln der Position eines in einem Kraftfahrzeug angeordneten GNSS-Empfängers
EP1395957B1 (de) Duales mautsystem
EP2423885B1 (de) Vorrichtung und Verfahren zur Funktionsüberwachung eines Strassenmautsystems
EP1358634A1 (de) Kontrollverfahren zur strassengebührenerfassung
EP2924662B2 (de) Onboard-Unit und Verfahren zur Funktionsüberwachung in einem Straßenmautsystem
EP1866872A1 (de) Verfahren und vorrichtung zur automatisierten fahrstreckeneinbuchung
DE19836087A1 (de) Verfahren und System zur Überwachung des ordnungsgemäßen Betriebs eines Abbuchungsgeräts
EP0693742A2 (de) Verfahren und Geräteanordnung für einen gesicherten, anonymen Zahlungsverkehr
EP1442432A1 (de) Einrichtung zur kurzfristigen überbrückung des ausfalls des satellitennavigationssignals für duale satellitennavigationsbasierte mautsysteme
EP2994890B1 (de) Verfahren und vorrichtung zur bereitstellung von daten zur mauterhebung und mautsystem
DE102005058033A1 (de) Verfahren zur Überprüfung einer Benutzungsberechtigung
DE112016000584B4 (de) Fahrzeugkommunikationseinrichtung
EP2690601B1 (de) Mautkontrollverfahren und Mautkontrolleinrichtungen sowie Mautsystem mit derartigen Mautkontrolleinrichtungen
DE102007036497A1 (de) Positionierungsvorrichtung und Positionierungsverfahren für ein Satellitennavigationssystem
DE19744419A1 (de) Einrichtung an Kraftfahrzeugen zur Erfassung und Auswertung von Straßen- und Fahrzeugdaten
DE202005021985U1 (de) System zur Verarbeitung von positions- und/oder mautbezogenen Daten für Fahrzeuge
EP3495847B1 (de) Tachografenanordnung und verfahren zum betreiben einer tachografenanordnung
EP2490183A1 (de) Fahrzeuggerät, ad-hoc-Netzwerk und Verfahren für ein Strassenmautsystem
DE102014116756A1 (de) Vorrichtung zum Erheben einer Fahrzeugmaut
EP3211605A1 (de) Fahrzeugeinrichtung, system, strassenseitige einrichtung und verfahren zur durchführung wenigstens einer transaktion
EP2665044B1 (de) Verfahren zum Messen der Leistungsfähigkeit eines Straßenmautsystems

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

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20101012