DE202005021985U1

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

Info

Publication number: DE202005021985U1
Application number: DE200520021985
Authority: DE
Original assignee: M2C Solutions GmbH
Current assignee: M2C Solutions GmbH
Priority date: 2005-03-09
Filing date: 2005-06-27
Publication date: 2012-03-23
Anticipated expiration: 2015-06-28
Also published as: DE102005031419A1; DE102005030030A1

Abstract

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, wobei die Positionsberechnungs-Instanz (15) die Daten in Abhängigkeit von Anforderungen der Service-Instanz (16) berechnet und in einem konfigurierbaren Format bereitstellt, – 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, wobei von zumindest einer stationären Referenzstation...

Description

Die Erfindung betrifft ein System und eine Anordnung zur Verarbeitung von Positions-bezogenen Daten, wobei die Positions-bezogenenen Daten mithilfe der vorliegenden Erfindung auf einer Vielzahl von mobilen On-Board-Units (OBU) erfasst werden können und über ein Mobilfunknetz als Schnittstelle an ein zentrales und stationäres Back-Office (BO) zur weiteren Verarbeitung übertragen werden können. 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 können dann weiteren Service-Instanzen (16) zur weiteren Verarbeitung weitergeleitet werden.
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 und eine Anordnung mit Mitteln gemäß den beiliegenden Hauptansprüchen gelöst.
Das System und die Anordnung gemäß der vorliegenden Erfindung eignet sich insbesondere zur Durchführung eines Verfahrens 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 ist dabei 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 weiterer 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.
Besonders vorteilhaft ist dabei, dass das Berechnen der normalisierten Positionsdaten aus den eingelesenen, positionsbezogenen Daten in dem Back-Office nach voreinstellbaren Parametern konfiguriert werden kann.
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 das erfindungsgemäße System 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 Kommunikatians-Technologien verwendbar, insbesondere dann, wenn vorstehend genannte Technologien nicht zur Verfügung stehen, wie z. B. ”Data-over-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.
Es ist ebenfalls 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 möglich, 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.
Es kann zudem 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-bezogenen 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 DSRCTags.
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 an stehende 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äte-Seriennummer. 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 Identifizierungsnummer 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 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.
Bevorzugt 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.
Besonders bevorzugt wird eine automatische Ausführung der Einheiten oder Module des Systems oder der Anordnung. 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 Anordnung zur Verarbeitung von positions-bezogenen Daten gelöst, mit Mitteln, die zur Ausführung zumindest eines der vorstehend erwähnten Verfahren ausgelegt sind.
Die vorstehenden Ausführungen betreffend bevorzugte Verwendungen und Verfahren des erfindungsgemäßen Systems und der erfindungsgemäßen Anordnung sind auch entsprechend auf das System und die Anordnung an sich anzuwenden.
Die vorstehend beschriebenen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen Verfahrens veranlasst wird und dessen Programmcode durch einen Prozessor ausgeführt wird.
Eine alternative Lösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten 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:
1 eine übersichtsartige Darstellung von Einheiten und möglichen Datenströmen gemäß einer vorteilhaften Ausführungsform der Erfindung,
2 eine übersichtsartige Darstellung von Einheiten gemäß einer vorteilhaften Weiterbildung der Erfindung,
3 eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von positions-bezogenen Daten in einem Back-Office,
4 eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von Satellitenpositionsdaten im Back-Office,
5 eine übersichtsartige Darstellung eines Prozesses zur Verarbeitung von positions-bezogenen Daten über ein Road-Identification-Interface und
[6 eine übersichtsartige Darstellung eines Prozesses für die Datenerhebung in der On-Board-Unit.
In Zusammenhang mit 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.
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 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. Dabei 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 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 Zigaretten-Anzü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 2 die wesentlichen Komponenten gemäß der vorteilhaften Ausführungsform der Erfindung erläutert:
Wie in 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 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-Betreibern) bereitgestellt wird. Er ist, wie in 2 dargestellt, als externe Komponente dem Back-Office zugeordnet. Die Mobilfunk-Betreiber 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 Dieser Text wurde durch das DPMA aus Originalquellen übernommen. Er enthält keine Zeichnungen. Die Darstellung von Tabellen und Formeln kann unbefriedigend sein. 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-IDs). – 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. XMLTelegramme).
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 „GPSPosition-Interface”. Diese Schnittstelle nimmt entweder auf Anforderung oder im Batch-Betrieb in zyklischen Abständen die verfügbaren positionsbezogenen 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 DSRC-basierten 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 3 ist ein möglicher Ablauf der Datenverarbeitung im Back-Office BO, insbesondere in der Positions-Berechnungsinstanz 15 dargestellt, die in 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 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 4 ist übersichtsartig ein Prozess der Datenverarbeitung von Satellitenpositionsdaten-Daten in dem Back-Office BO dargestellt. In der Positions-Berechnungsinstanz 15, die in 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 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 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.
Zudem ist es möglich, 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 6 ist beispielhaft gezeigt, wie die Datenerhebung 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 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

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, wobei die Positionsberechnungs-Instanz (15) die Daten in Abhängigkeit von Anforderungen der Service-Instanz (16) berechnet und in einem konfigurierbaren Format bereitstellt, – 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, wobei 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
System nach zumindest einem der vorstehenden Ansprüche 1 bis 12, 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.