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

Abstract

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

Description

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

OBU

On-Board-Unit

BO

Back-Office

BSS

Baken-Schnittstelle

BoSS

Back-Office-Schnittstelle

10

Pufferspeicher

12

Mapping-Einheit

14

Transaktions-Einheit

16

Bake

Claims (15)

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