EP2709071B1

EP2709071B1 - Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen

Info

Publication number: EP2709071B1
Application number: EP12184676.0A
Authority: EP
Inventors: Alexander Leopold; Robert Povolny; Oliver Nagy
Original assignee: Kapsch TrafficCom AG
Current assignee: Kapsch TrafficCom AG
Priority date: 2012-09-17
Filing date: 2012-09-17
Publication date: 2015-02-25
Anticipated expiration: 2032-09-17
Also published as: EP2709071A9; SG2013059258A; AU2013219213A1; RU2013142266A; CA2822376A1; DK2709071T3; CL2013002653A1; PT2709071E; CN103679822A; SI2709071T1; EP2709071A1; EP2709071B9; ES2535933T3; ZA201306914B; PL2709071T3; NZ614100A; US20140081718A1

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Erzeugen einer Parkgebührentransaktion für ein Fahrzeug, das eine Onboard-Unit mit einer Kennung hat. Die Erfindung betrifft ferner eine Funkbake und eine Onboard-Unit zur Durchführung dieses Verfahrens.
Onboard-Units (OBUs) sind elektronische Geräte, die von Fahrzeugen mitgeführt werden, um die Fahrzeuge drahtlos über Funk identifizieren zu können, beispielsweise zur Abrechnung von Mautgebühren in elektronischen Straßenmautsystemen. OBUs können in der Form von aktiven oder passiven Funktranspondern, RFID-Chips (radio frequency identification), NFC-chips (near field communication), DSRC-Sendeempfängern (dedicated short range communication), WAVE- (wireless access in vehicular environments) und WLAN-Nodes (wireless local area networks) usw. ausgeführt sein. Die EP 2 299 409 A1 beschreibt die Verwendung eines RFID-Chips in einem Fahrzeug, um das Fahrzeug an Ein- und Ausfahrt eines Parkplatzes zu identifizieren und damit die Zeitdifferenz als Gesamtparkdauer des Fahrzeugs zu ermitteln. Die Erfindung setzt sich zum Ziel, derartige OBUs für die Abrechnung von Parkgebühren nutzbar zu machen.
Diese Ziel wird in einem ersten Aspekt der Erfindung mit einem Verfahren zum Erzeugen einer Parkgebührentransaktion für ein Fahrzeug erreicht, das eine Onboard-Unit mit einer Kennung hat,
umfassend die Schritte:

Funkabfragen der Kennung von einer straßenseitigen Funkbake aus als aktuelle Kennung;
wenn die aktuelle Kennung einer gespeicherten alten Kennung gleicht, Erzeugen einer Parkgebührentransaktion für die Kennung;
Speichern der aktuellen Kennung als alte Kennung;
Abwarten einer vorgegebenen Zeitspanne;

Wiederholen der vorgenannten Schritte.
Die Erfindung beruht auf der Erkenntnis, dass durch Vergleichen der zu einem bestimmten Zeitpunkt funkabfragbaren Kennungen von sich im Funlsabdeckungsbereich der Bake befindlichen OBUs mit zu einem früheren Zeitpunkt abgefragten Kennungen jene Kennungen und damit OBUs und deren Fahrzeuge festgestellt werden können, welche zu beiden Zeitpunkten im Funkabdeckungsbereich anwesend waren und daher mit hoher Wahrscheinlichkeit dort geparkt haben. Auf diese Weise wird ein verblüffend einfaches und auf eine beliebige Anzahl von Parkplätzen im Funkabdeckungsbereich einer Funkbake skalierbares Verfahren zum Erzeugen von Parkgebührentransaktionen geschaffen.
Gemäß einer bevorzugten Ausführungsform der Erfindung wird mit der Kennung auch eine Position der Onboard-Unit funkabgefragt und die Parkgebührentransaktion nur dann erzeugt, wenn zusätzlich zur genannten Kennungsgleichheit die Position in einem vorgegebenen Bereich liegt. Dadurch können Funküberreichweiten der Funkbake abgefangen werden, d.h. wenn der Parkbereich kleiner ist als der Funkabdeckungsbereich der Funkbake.
Bevorzugt wird mit der Kennung auch ein Status der Onboard-Unit funkabgefragt und die Parkgebührentransaktion nur dann erzeugt, wenn zusätzlich zur genannten Kennungsgleichheit auch der Status einem vorgegebenen Wert gleicht. Dadurch kann gewährleistet werden, dass nur für solche OBUs, die einen entsprechenden "Parkstatus" gesetzt haben, Parkgebührentransaktionen erzeugt werden. So können beispielsweise OBUs von Fahrzeugen, die sich nur vorübergehend im Funkabdeckungsbereich der Funkbake befinden, weil sie neben geparkten Autos vorübergehend im Stau stehen, ignoriert werden; umgekehrt kann ein Benutzer durch willentliches Setzen des Parkstatus an seiner OBUs angeben, dass er nun parkt und Parkgebühren entrichten möchte.
Die erzeugten Parkgebührentransaktionen können auf verschiedenste Art und Weise weiterverarbeitet und abgerechnet werden. In einer ersten bevorzugten Ausführungsform werden die Parkgebührentransaktionen von der Funkbake über Funk an die Onboard-Unit gesandt und dort beispielsweise als Abbuchungstransaktion einem in der Onboard-Unit geführten Guthaben (einer "elektronischen Geldbörse") angelastet. Gemäß einer alternativen bevorzugten Ausführungsform werden die erzeugten Parkgebührentransaktionen von der Funkbake an eine Zentrale gesandt, beispielsweise eine Mautzentrale eines Straßenmautsystems, einen Bankrechner, eine Kreditkartenabrechnungszentrale usw. und dort einem Bank-, Kredit- oder Debitkonto des der OBU-Kennung zugeordneten Benutzers angelastet.
Das erfindungsgemäße Verfahren arbeitet in Schritten der vorgegebenen Abwarte-Zeitspanne und kann demgemäß Parkaufenthalte in diesen Zeiteinheiten vergebühren. Vorteilhaft ist es, wenn die vorgegebene Zeitspanne 1 bis 30 min, bevorzugt 5 bis 20 min, besonders bevorzugt 10 min beträgt, wodurch Kurzaufenthalte unter 10 Minuten gebührenfrei bleiben und für längere Aufenthalte eine ausreichende Zeitgenauigkeit erreicht wird.
In einem zweiten Aspekt schafft die Erfindung eine Funkbake zum Erzeugen einer Parkgebührentransaktion für ein Fahrzeug, das eine Onboard-Unit mit einer Kennung hat, wobei die Funkbake einen zumindest einen Parkplatz abdeckenden Funkabdeckungsbereich hat und dafür ausgebildet ist,
die Kennung einer in ihrem Funkabdeckungsbereich befindlichen Onboard-Unit als aktuelle Kennung funkabzufragen,
wenn die aktuelle Kennung einer gespeicherten alten Kennung gleicht, eine Parkgebührentransaktion für diese Kennung zu erzeugen,
die aktuelle Kennung als alte Kennung zu speichern, und
diese Schritte nach einer vorgegebenen Zeitspanne zu wiederholen.
In vorteilhafter Weise ist die Funkbake dafür ausgebildet, mit der Kennung auch eine Position der Onboard-Unit funkabzufragen und die Parkgebührentransaktion nur dann zu erzeugen, wenn zusätzlich zur genannten Kennungsgleichheit die Position in einem vorgegebenen Bereich liegt.
Bevorzugt ist die Funkbake dafür ausgebildet, mit der Kennung auch einen Status der Onboard-Unit funkabzufragen und die Parkgebührentransaktion nur dann zu erzeugen, wenn zusätzlich zur genannten Kennungsgleichheit auch der Status einem vorgegebenen Wert gleicht.
Besonders günstig ist es, wenn die Funkbake einen Funkabdeckungsbereich hat, der zumindest zwei Parkplätze abdeckt, und dafür ausgebildet ist,
die Kennungen aller in ihrem Funkabdeckungsbereich befindlicher Onboard-Units als aktuelle Kennungen funkabzufragen,
für jede aktuelle Kennung, die einer gespeicherten alten Kennung gleicht, eine Parkgebührentransaktion zu erzeugen,
die aktuellen Kennungen als alte Kennungen zu speichern, und
diese Schritte nach der vorgegebenen Zeitspanne zu wiederholen.
Dabei kann die Funkbake aus einem Vergleich der Anzahl von aktuellen Kennungen und Anzahl von Parkplätzen in ihrem Funkabdeckungsbereich einen Parkplatzbelegungsstatus berechnen.
Hinsichtlich der Vorteile der erfindungsgemäßen Funkbake wird auf die obigen Ausführungen zum Verfahren verwiesen.
In einem dritten Aspekt schafft die Erfindung eine Onboard-Unit für ein Fahrzeug, mit einer eindeutigen Kennung, einem gespeicherten veränderbaren Status und einem Sendeempfänger zum Übermitteln der Kennung und des Status auf eine Funkabfrage einer Funkbake, welche Onboard-Unit sich dadurch auszeichnet, dass sie einen ersten Betriebsmodus und einen zweiten Betriebsmodus hat, zwischen denen sie mittels eines Schalters umschaltbar ist, wobei der Status den jeweiligen Betriebsmodus der Onboard-Unit anzeigt.
Die Onboard-Unit der Erfindung eignet sich damit insbesondere für jene Ausführungsformen des Verfahrens und der Funkbake, bei welchen diese auf einen in der OBU gesetzten Status Rücksicht nehmen und nur für solche OBUs Parkgebührentransaktionen erzeugen, für welche der Benutzer den Parkmodus bzw. Parkstatus eingestellt hat.
Bevorzugt ist die Onboard-Unit mit einer Positionsbestimmungseinrichtung zur Bestimmung ihrer aktuellen Position ausgestattet und dafür ausgebildet, auf eine Funkabfrage der Funkbake hin ihre Position zu übermitteln.
Gemäß einer besonders bevorzugten Ausführungsform der Erfindung kann die Onboard-Unit mit einem Bewegungssensor ausgestattet sein, welcher bei einer einen Schwellwert überschreitenden Bewegung der Onboard-Unit diese in den ersten Betriebsmodus umschaltet und/oder bei einem einen Mindestzeitspanne überschreitenden Ausbleiben einer Bewegung der Onboard-Unit diese in den zweiten Betriebsmodus umschaltet. Dadurch kann eine automatische, bewegungsgesteuerte Umschaltung zwischen den beiden Betriebsmodi, nämlich dem ersten (Maut-)Betriebsmodus für Bewegung und dem zweiten (Park-)Betriebsmodus für Stillstand über längere Zeit, erreicht werden.
Der Maut-Betriebsmodus der Onboard-Unit, in welchem diese beispielsweise als herkömmliche Straßenmaut-OBU mit Maut-Funkbaken auf ihrem Weg kommuniziert, kann erfindungsgemäß dazu ausgenützt werden, eine im Park-Betriebsmodus von einer Park-Funkbake erhaltene Parkgebührentransaktion über die Infrastruktur des Straßenmautsystems abzurechnen. Nach Verlassen des Parkmodus und des Funkabdeckungsbereichs der Park-Funkbake sendet die OBU die Parkgebührentransaktion beispielsweise an die erste Maut-Funkbake, der sie auf ihrem Weg begegnet, um so die Parkgebühr über das Abrechnungssystem der Maut-Funkbaken zu begleichen.
Besonders günstig ist es, wenn die Onboard-Unit einen stromsparenden dritten Betriebsmodus hat, in welchen sie im zweiten Betriebsmodus nach Empfang einer Funkabfrage oder Parkgebührentransaktion vorübergehend verfällt. Da die Funkabfragen einer Park-Funkbake vergleichsweise selten, z.B. alle 10 Minuten, ergehen, kann die Onboard-Unit auf diese Weise beträchtlich Strom sparen.
Die Erfindung wird nachstehend anhand eines in den beigeschlossenen Zeichnungen dargestellten Ausführungsbeispiels näher erläutert. In den Zeichnungen zeigt:

Fig. 1 die Kommunikation einer Onboard-Unit im Maut-Betriebsmodus mit Maut-Funkbaken auf ihrem Weg auf einer Straße schematisch im Überblick;
Fig. 2 die Kommunikation von Onbard-Units im Park-Betriebsmodus mit einer Park-Funkbake beim Parken schematisch im Überblick;
Fig. 3 ein Blockschaltbild und Fig. 4 eine Vorderansicht einer beispielhaften Onboard-Unit gemäß der Erfindung;
Fig. 5 ein Zustandsdiagramm des in einer Onboard-Unit ablaufenden Teils des erfindungsgemäßen Verfahrens; und
Fig. 6 ein Flussdiagramm des in einer Park-Funkbake ablaufenden Teils des erfindungsgemäßen Verfahrens.

In Fig. 1 bewegt sich ein Fahrzeug 1 auf einer Straße 2 mit einer Geschwindigkeit und Fahrtrichtung 3 und in Fig. 2 parken mehrere Fahrzeuge 1 jeweils auf einem Parkplatz 4 der Straße 2. Die Straße 2 kann eine beliebige Verkehrs- oder Abstellfläche sein, beispielsweise eine Schnellstraße, Autobahn oder ein ganzes Straßennetz in Fig. 1 oder ein Abstellstreifen, eine große Parkfläche oder ein Parkhaus in Fig. 2; all dies wird hier unter dem Oberbegriff "Straße" 2 verstanden.
Die Fahrzeuge 1 sind jeweils mit einer Onboard-Unit (OBU) 5 ausgestattet, welche mit straßenseitigen Funkbaken (roadside units, RSUs) 6, 7 Funkkommunikationen 8 abwickeln können. Die OBUs 5 können eigenständige Geräte oder Bestandteile der Fahrzeugelektronik sein. Die Funkkommunikation 8 sind Kurzreichweiten- bzw. DSRC-Funkkommunikationen (dedicated short range communications), bevorzugt nach den Standards CEN-DSRC, ITS-G5, IEEE 802.11p, WAVE, WLAN, RFID, NFC od.dgl. Die Funkbaken 6, 7 haben dadurch jeweils einen lokal begrenzten Funkabdeckungsbereich 9, 10.
In den Fig. 1 und 2 sind zwei verschiedene Arten von Funkbaken 6, 7 und Anwendungsszenarien der geschilderten Komponenten dargestellt: Die Funkbaken 6 von Fig. 1 sind entlang der Straße 2 geografisch verteilt aufgestellte "Maut"-Funkbaken (tolling roadside units, T-RSUs). Die Maut-Funkbaken 6 fordern mit Hilfe periodisch ausgestrahlter Funkabfragen 11 alle sie passierenden OBUs 5 zur Funkkommunikation 8 auf, wie anhand der beispielhaften Antwort 12 veranschaulicht ist. Um aufgrund der möglicherweise hohen Geschwindigkeit der Fahrzeuge 1 keine passierende OBU 5 zu "verpassen", werden die Funkabfragen 11 der Maut-Funkbaken 6 in verhältnismäßig kurzen Zeitabständen ausgestrahlt, beispielsweise alle 100 ms. Für die Funkabfragen 11 werden im WAVE-Standard beispielsweise sog. WSA-Nachrichten (wave service announcements) und im CEN-DSRC-Standard sog. BST-Nachrichten (beacon service tables) eingesetzt.
Eine erfolgreiche Funkkommunikation 8 mit einer passierenden OBU 5 belegt, dass sich die OBU 5 im lokal begrenzten Funkabdeckungsbereich 9 der Maut-Funkbake 6 befindet, wodurch die Benützung des Orts der Maut-Funkbake 6 vergebührt ("vermautet") werden kann. Die vermautete Ortsnutzung kann beispielsweise das Befahren eines Straßenstücks, der Eintritt in ein bestimmtes Gebiet ("City Maut") od.dgl. sein.
In dem Park-Szenario von Fig. 2 werden hingegen "Park"-Funkbaken (parking roadside units, P-RSUs) 7 eingesetzt, welche mit einer Funkabfrage 11, z.B. einer WSA- oder BST-Nachricht, alle in ihrem Funkabdeckungsbereich 10 befindlichen OBUs 5 zu Antwortnachrichten 12 auffordern, um die Nutzung der Parkplätze 4 zu vergebühren, wie weiter unten noch ausführlich erörtert. Eine Park-Funkbake 7 kann dabei für einen oder auch mehrere Parkplätze 4 zuständig sein, welche zusammen einen Parkbereich P bilden.
Da parkende Fahrzeuge 1 ruhen, kann eine Park-Funkbake 7 ihre Funkabfragen 11 in wesentlich größeren Zeitabständen ΔT aussenden als die Maut-Funkbake 6 von Fig. 1, beispielsweise alle 10 min, was gleichzeitig die Zeitauflösung der Parkzeitabrechnung definiert.
Der Funkabdeckungsbereich 10 der Park-Funkbake 7 kann durch optionale Maßnahmen, beispielsweise Richtantennen, an die räumliche Ausdehnung der Parkplätze 4 angepasst werden, um Antworten 12 von OBUs 5 von nicht-parkenden, z.B. passierenden Fahrzeugen 1 zu vermeiden. Alternativ oder zusätzlich können die OBUs 5 der Fahrzeuge 1 auch in verschiedene, den Szenarien der Fig. 1 und 2 jeweils angepasste Betriebsmodi versetzt werden, und zwar einen ersten Maut-Betriebsmodus (tolling mode, TM) zur Antwort 12 auf Funkabfragen 11 von Maut-Funkbaken 6, und einen zweiten Park-Betriebsmodus (parking mode, PM) zur Antwort 12 auf Funkabfragen 11 von Park-Funkbaken 7. Optional können die Funkbaken 6, 7 in den Funkabfragen 11 jeweils eine Bakenkennung aussenden, die angibt, ob es sich um eine Maut-Funkbake 6 oder eine Park-Funkbake 7 handelt. Die Bakenkennung kann beispielsweise als Dienst (service) der Bake im Rahmen einer WSA- oder BST-Nachricht angegeben werden.
Es versteht sich, dass die Maut-Funkbaken 6 und Park-Funkbaken 7 auch durch ein und dieselbe physische Einheit realisiert werden können, welche abwechselnd oder auch gleichzeitig die Funktionen einer Maut- und einer Park-Funkbake 6, 7 ausübt. So kann eine solche kombinierte Einheit 6, 7 z.B. fortlaufend in kurzen Zeitabständen Funkabfragen 11 mit Baken-Kennung einer Maut-Funkbake und in größeren Zeitabständen ΔT, d.h. gelegentlich "eingestreut", Funkabfragen 11 mit Baken-Kennung einer Park-Funkbake 7 aussenden. Eine solche Funkbake 6, 7 ist dann beispielsweise sowohl für das Vermauten eines Straßenstücks der Straße 2 als auch das Vergebühren eines Parkbereichs P zuständig.
Je nach Betriebsmodus TM oder PM, in dem sich eine OBU 5 befindet, und abhängig von der empfangenen Bakenkennung kann die OBU 5 z.B. nur Maut-Funkbaken 6 antworten, wenn sie sich im Maut-Betriebsmodus TM befindet, oder nur Park-Funkbaken 7, wenn sie sich im Park-Betriebsmodus PM befindet.
Der Betriebsmodus einer OBU 5 kann ferner als Datennachricht (Status) st kodiert werden und in der Antwort 12 mitgesandt werden. Eine Funkbake 6, 7 kann den in einer Antwort 12 empfangenen Status st entsprechend auswerten, sodass Maut-Funkbaken 6 nur die Passagen von OBUs 5 vermauten, deren Status st = "TM" ist, und Park-Funkbaken 7 nur das Parken solcher OBUs 5 vergebühren, deren Status st = "PM" ist. Ferner können die OBUs 5 auch jeweils ihre eigenen Positionen p messen und an die Park-Funkbaken 7 senden, welche die empfangenen Positionen p mit ihren jeweiligen Parkbereichen P vergleichen und nur das Parken solcher OBUs 5 vergebühren, deren Positionen p in ihren jeweiligen Parkbereich P fallen. Dies wird nun unter Bezugnahme auf die Fig. 3 - 6 näher erläutert.
Fig. 3 zeigt ein beispielhaftes Blockschaltbild, Fig. 4 eine beispielhafte Außenansicht und Fig. 5 ein beispielhaftes Zustandsdiagramm einer OBU 5, welche zwischen (zumindest) zwei Betriebsmodi TM und PM entsprechend den Anwendungsszenarien der Fig. 1 und 2 umschaltbar ist. Gemäß Fig. 3 weist eine OBU 5 dazu einen Sendeempfänger 13 (z.B. nach einem der genannten DSRC-Standards) zur Durchführung der Funkkommunikationen 8, einen den Sendeempfänger 13 steuernden Mikroprozessor 14, einen Speicher 15, eine Eingabeeinrichtung 16 und eine Ausgabeeinrichtung 17 auf. Die Ein- und Ausgabeeinrichtungen 16, 17 können auch auf andere Weise als durch die dargestellte Tastatur und Bildschirmausgabe realisiert werden können, beispielsweise durch Sprachein- und -ausgabe, Sensoriken, Hinweistöne usw. Die Ein- und Ausgabeeinrichtungen 16, 17 können auch durch physisch getrennte Komponenten wie Autoradios, Navigationsgeräte, Smartphones, PDAs, Tablets usw. gebildet und drahtgebunden oder drahtlos, z.B. über NFC, Bluetooth^®, WLAN oder Infrarot, an den Mikroprozessor 14 angebunden sein.
Optional kann die OBU 5 auch einen Bewegungssensor 18 in Form z.B. eines Satellitennavigationsempfängers für ein globales Satellitennavigationssystem (global navigation satellite system, GNSS), wie GPS, GLONASS, GALILEO usw. aufweisen; anstelle eines GNSS-Empfängers könnte auch jede andere Art von Bewegungssensor 18 verwendet werden, beispielsweise ein Trägheitssensor (inertial measurement unit, IMU) oder ein mit Komponenten des Fahrzeugs 1 verbundener Sensor, beispielsweise eine Anbindung an den Geschwindigkeitsmesser oder Motor des Fahrzeugs 1.
Im einfachsten Fall kann der Bewegungssensor 18 auch eine bloße Anbindung an die Fahrzeugelektronik, z.B. das Zündschloss des Fahrzeugs, sein, so dass z.B. die Schlüsselstellung (Motor läuft - läuft nicht) den (voraussichtlichen) Bewegungs- bzw. Parkstatus des Fahrzeugs angibt.
Die OBU 5 kann optional weiters mit einer Positionsbestimmungseinrichtung 18' ausgestattet sein, welche befähigt ist, die aktuelle Position p der OBU 5 - auf Abfrage, periodisch oder fortlaufend - zu bestimmen. Die Positionsbestimmungseinrichtung 18' kann auf jede in der Technik bekannte Art arbeiten, z.B. mittels Funktriangulation in einem Netz geografisch verteilter Funkstationen, die z.B. durch die Funkbaken 6, 7 selbst oder Basisstationen eines Mobilfunknetzes gebildet sein können, oder mittels Auswertung der Zellkennungen eines zellularen Mobilfunknetzes, usw. usf. Bevorzugt ist die Positionsbestimmungseinrichtung 18' ein Satellitennavigationsempfänger zur Positionsbestimmung in einem GNSS und kann insbesondere auch durch denselben GNSS-Empfänger gebildet sein, der für den Bewegungssensor 18 verwendet wird.
Der Speicher 15 der OBU 5 enthält - neben den entsprechenden Anwendungs- und Steuerungsprogrammen und -daten - eine eindeutige Kennung id der OBU 5, welche beispielsweise bei der Ausgabe oder benutzerspezifischen Initialisierung der OBU 5 festgelegt und eingespeichert wird und die OBU 5 und/oder ihren Benutzer und/oder das Fahrzeug 1 und/oder ein Abrechnungskonto des Benutzers eindeutig identifiziert. Die OBU-Kennung id wird in jeder Antwortnachricht 12 von der OBU 5 an ein Funkbake 6, 7 mitgesandt, um die OBU 5 gegenüber der Funkbake 6, 7 eindeutig zu identifizieren.
Der Speicher 15 kann ferner den Status st enthalten, welcher den Betriebsmodus TM oder PM der OBU 5 für das entsprechende Szenario von Fig. 1 oder 2 angibt. Der Status st kann sowohl in Abhängigkeit von einer vom Bewegungssensor 16 gemessenen Bewegung (oder Nicht-Bewegung) der OBU 5 als auch durch eine Benutzerauswahl über die Eingabeeinrichtung 16 verändert bzw. eingestellt werden. Die Eingabeeinrichtung 16 kann dazu beispielsweise eine einrastbare Taste 16' (Fig. 4) enthalten, die mit "PM" für "Park-Betriebsmodus" PM beschriftet ist und durch Drücken und Einrasten die OBU 5 in den Park-Betriebsmodus PM umschaltet und den Status st auf den Wert "PM" setzt. Durch Lösen bzw. Ausrasten der Taste 16' wird die OBU 5 wieder zurück in den Maut-Betriebsmodus TM geschaltet und der Status st auf den Wert "TM" gesetzt. Die Ausgabeeinrichtung 17 kann optional entsprechende Hinweis- und/oder Bestätigungsmeldungen ausgeben.
Fig. 5 zeigt einige der möglichen Betriebszustände der OBU 5 nochmals im Detail in Form eines Zustandsdiagramms (state transition-diagram). Aus dem Maut-Betriebsmodus TM kann die OBU 5 durch Drücken der Taste 16' und/oder wenn der Bewegungssensor 18 über eine Mindestzeitspanne von z.B. 5 min keine Bewegung der OBU 5 feststellt in den Park-Betriebsmodus PM versetzt werden. Durch Lösen der Taste 16' und/oder eine vom Bewegungssensor 18 detektierte Bewegung der OBU 5 kann diese vom Park-Betriebsmodus PM wieder zurück in den Maut-Betriebsmodus TM versetzt werden.
Im Park-Betriebsmodus PM kann die OBU 5 vorübergehend in einen stromsparenden Schlafmodus ("sleep") verfallen, und zwar sobald sie eine Funkabfrage 11 einer Park-Funkbake 7 empfangen und mit einer Antwort 12 beantwortet hat. Die OBU 5 kann aus dem Schlafmodus nach Ablauf einer vorgegebenen Zeitspanne Δt aufwachen und in den Park-Betriebsmodus PM zurückkehren. Die Zeitspanne Δt ist bevorzugt kürzer als jene Zeitspanne ΔT, die zwischen aufeinanderfolgenden Funkabfragen 11 einer Park-Funkbake 7 liegt. Alternativ oder zusätzlich könnte die OBU 5 auch durch den Empfang einer nächsten Funkabfrage 11 wieder aufgeweckt werden.
Fig. 6 zeigt das in einer Park-Funkbake 7 im Zusammenspiel mit der OBU 5 der Fig. 3 - 5 ablaufende Verfahren zur Erzeugung von Parkgebührentransaktionen in dem Anwendungsszenario von Fig. 2.
In einem ersten Schritt 19 wird eine Funkabfrage 11 von der Park-Funkbake 7 ausgesandt, um die in ihrem Funkabdeckungsbereich 10 befindlichen OBUs 5 zu Antworten 12 aufzufordern. Im Schritt 20 werden die von den OBUs 5 einlangenden Antworten 12 empfangen, wobei jede Antwort 12 zumindest die jeweilige Kennung id_i der OBU 5 mit dem Index i und - optional - deren Status st_i und/oder deren von der Positionsbestimmungseinrichtung 18' bestimmte Position p_i enthält. Die empfangenen Kennungen id_i, Stati st_i und Positionen p_i werden als aktueller Datensatz set_curr in der Park-Funkbake 7 vorübergehend gespeichert.
Anschließend wird innerhalb einer über alle empfangenen Kennungen id_i laufenden Schleife 21 überprüft, ob der jeweilige Status st_i auf Park-Betriebsmodus "PM" gesetzt ist oder nicht, siehe Entscheidung 22. In der Entscheidung 22 kann zusätzlich (oder alternativ) überprüft werden, ob die jeweilige Position p_i - soferne sie übermittelt wurde - in einen vorgegebenen geografischen Bereich, u.zw. den Parkbereich P der Park-Funkbake 7, fällt oder nicht. Wenn nicht alle in der Entscheidung 22 überprüften Bedingungen erfüllt sind (Zweig "n" von 22), werden die nachfolgenden Schritte 23 und 24 übersprungen und die Schleife 21 wird fortgesetzt bzw. bei Beendigung zu Schritt 25 hin verlassen. Wenn hingegen alle Bedingungen erfüllt sind, d.h. hier: st_i = PM und p_i ∈ P (Zweig "y" von 22), wird in einer weiteren Entscheidung 23 überprüft, ob die jeweilige Kennung id_i einer zuvor gespeicherten "alten" Kennung id_i,last entspricht, d.h. in einem Datensatz set_last{id_i,last} von alten Kennungen id_i,last vorkommt oder nicht. Diese "alten" Kennungen id_i,last wurden in einem früheren Verfahrensdurchlauf ermittelt und im Datensatz set_last gespeichert, wie gleich im Anschluss erläutert wird.
Wenn die jeweilige aktuelle Kennung id_i keiner alten Kennung id_i,last entspricht, d.h. nicht im Datensatz set_last vorkommt (Zweig "n" von 23), wird die Schleife 21 fortgesetzt bzw. nach ihrer Fertigstellung zu Schritt 25 hin verlassen; wenn doch (Zweig "y" von 23), wird zum Schritt 24 verzweigt, in welchem eine Parkgebührentransaktion ta(id_i) für die aktuelle Kennung id_i erzeugt wird, wie später noch ausführlicher erläutert.
Nach dem Schritt 24 wird die Schleife 21 fortgesetzt bzw. nach deren Vollendung zu Schritt 25 übergegangen.
Im Schritt 25 werden nun die im Schritt 20 ermittelten aktuellen Kennungen id_i als "alte" Kennungen id_i,last umgespeichert, d.h. der aktuelle Datensatz set_curr als (nun) "alter" Datensatz set_last gespeichert.
Anschließend wird in Schritt 26 die vorgegebene Zeitspanne ΔT abgewartet, welche zwischen den einzelnen Funkabfragen 11 der Park-Funkbake 7 liegt, und dann das Verfahren wiederholt (Schleife 27).
Bei der nächsten Wiederholung in der Schleife 27 stellen nun die vorher ermittelten aktuellen Kennungen id_i die "alten" Kennungen id_i,last dar, und wenn im Schritt 20 wieder "neue" aktuelle Kennungen id_i ermittelt werden, können diese dann in Schritt 23 mit den "alten" Kennungen id_i,last aus dem letzten Datensatz set_last verglichen werden. Dadurch wird bei jedem Schleifendurchlauf 27 überprüft, ob eine von einer Park-Funkbake 7 aufgrund einer Funkabfrage 11 ermittelte OBU-Kennung id_i schon bei einer um die Zeitspanne ΔT zurückliegenden Funkabfrage 11 vorhanden war oder nicht; wenn ja, hat ein Fahrzeug 1 mit einer OBU 5 dieser Kennung id_i offensichtlich mindestens die Zeitspanne ΔT im Funkabdeckungsbereich 10 der Park-Funkbake 7 verbracht, sodass für das Parken über die Zeitspanne ΔT eine entsprechende Parkgebührentransaktion ta(id_i) für die OBU-Kennung id_i erzeugt werden darf (Schritt 24).
Die in Schritt 24 erzeugten Parkgebührentransaktionen ta(id_i) können von der Funkbake 7 selbst abgerechnet werden, beispielsweise indem ein in der Funkbake 7 geführtes Benutzerkonto damit belastet wird. Alternativ können die Parkgebührentransatkionen ta(id_i) von der Funkbake 7 an eine entfernte (nicht dargestellte) Zentrale weitergesandt werden, welche Benutzerkonten, Mautkonten, Bankkonten, Kreditkonten usw. unter den Kennungen id_i führt, sodass die Parkgebührentransaktionen ta(id_i) dort einem entsprechenden Abrechnungskonto angelastet werden können. Es ist aber auch möglich, dass die erzeugte(n) Parkgebührentransaktion(en) ta(id_i) von der Funkbake 7 an die OBU 5 mit der Kennung id_i zurückgesandt und dort einem in der OBU 5 geführten Abrechnungskonto (einer "elektronischen Geldbörse") angelastet wird/werden.
Eine weitere Möglichkeit ist, dass die von der Park-Funkbake 7 an die OBU 5 zurückgesandte(n) Parkgebührentransaktion(en) ta(id_i) in der OBU 5 vorübergehend aufbewahrt und dann, wenn die OBU 5 wieder in den Maut-Betriebsmodus TM zurückkehrt, von der OBU 5 an eine Maut-Funkbake 6 auf ihrem Weg zwecks Verrechnung abgesetzt wird/werden, gleichsam wie eine Mautgebührentransaktion. Fig. 5 zeigt dazu einen entsprechenden Betriebsmodus "post ta", in welchem die OBU 5 nach Rückkehr aus dem Park-Betriebsmodus PM vorübergehend eintritt und auf die nächste Maut-Funkbake 6 auf ihrem Weg wartet, um bei dieser die Parkgebührentransaktion(en) ta(id_i) abzuliefern, wonach sie wieder in den "normalen" Maut-Betriebsmodus TM zurückkehrt.
Es versteht sich, dass die in Fig. 6 gezeigten Abläufe gemäß dem Fachmann bekannten Programmiermethoden entsprechend abgewandelt werden können. So könnte beispielsweise die Entscheidung 22 entfallen oder in den Schritt 20 mitaufgenommen und dort überprüft werden, ob der Status st_i einer Kennung id_i auf "PM" steht und/oder die Position p_i einer Kennung id_i in den Bereich P fällt, wobei dann überhaupt nur solche Kennungen id_i als aktuelle Kennungen im aktuellen Datensatz set_curr gespeichert werden, deren Status st_i = "PM" bzw. Position p_i ∈ P ist. Auch könnte die Schleife 21 anders implementiert werden und es könnten beispielsweise sofort nach Empfang einer Antwort 12 für eine Kennung id_i die Schritte 22 - 24 bzw. 23 - 24 durchgeführt werden, wenn dies rechentechnisch so schnell vonstatten geht, dass dies zwischen aufeinanderfolgend eintreffenden Antworten 12 durchgeführt werden kann. Dazu ist anzumerken, dass nach manchen DSRC-Standards die Antworten 12 von mehreren OBUs 5, die auf eine gemeinsame Funkabfrage 11 replizieren, variabel zeitlich gestreut werden, um Kollisionen von Antworten 12 zu vermeiden, so dass zwischen einzelnen Antworten 12 durchaus genügend Zeit für die Schritte 22 - 24 bzw. 23 - 24 verbleiben kann.
Eine Park-Funkbake 7, in deren Funkabdeckungsbereich 10 mehrere Parkplätze 4 fallen, erhält durch die Antworten 12 der OBUs 5 im Schritt 20 gleichzeitig auch eine vollständige Übersicht über den Belegungsstatus der Parkplätze 4 in ihrem Parkbereich P. Dazu braucht sie lediglich die Anzahl an im Schritt 20 erhaltenen Kennungen id_i mit der Anzahl an Parkplätzen 4 im Bereich P zu vergleichen, um eine anteilige bzw. prozentuelle Auslastung ihrer Parkplätze 4 zu erhalten, z.B. "80%", wenn 4 von 5 Parkplätzen belegt sind, usw. usf. Der so ermittelte Parkplatzbelegungsstatus kann beispielsweise an eine Zentrale für Parkraumbewirtschaftungsmaßnahmen gesendet werden.
Die Erfindung ist demgemäß nicht auf die dargestellten Ausführungsformen beschränkt, sondern umfasst alle Varianten und Modifikationen, die in den Rahmen der angeschlossenen Ansprüche fallen.

Claims

Verfahren zum Erzeugen einer Parkgebührentransaktion (ta) für ein Fahrzeug (1), das eine Onboard-Unit (5) mit einer Kennung (id) hat,
umfassend die Schritte in einer straßenseitigen Funkbake (7):
- Funkabfragen einer Kennung (id) von der Funkbake (7) aus als aktuelle Kennung (id_i);

- wenn die aktuelle Kennung (id_i) einer gespeicherten alten Kennung (id_i,last) gleicht, Erzeugen einer Parkgebührentransaktion (ta) für die Kennung (id) und damit für die Onboard-Unit (5) und deren Fahrzeug (1);

- Speichern der aktuellen Kennung (id_i, set_curr) als alte Kennung (id_i,last, set_last) ;

- Abwarten einer vorgegebenen Zeitspanne (ΔT);
Wiederholen der vorgenannten Schritte.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mit der Kennung (id_i) auch eine Position (p_i) der Onboard-Unit (5) funkabgefragt und die Parkgebührentransaktion (ta) nur dann erzeugt wird, wenn zusätzlich zur genannten Kennungsgleichheit die Position (p_i) in einem vorgegebenen Bereich (P) liegt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass mit der Kennung (id_i) auch ein Status (st_i) der Onboard-Unit (5) funkabgefragt und die Parkgebührentransaktion (ta) nur dann erzeugt wird, wenn zusätzlich zur genannten Kennungsgleichheit auch der Status (st_i) einem vorgegebenen Wert (PM) gleicht.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Parkgebührentransaktion (ta) von der Funkbake (7) über Funk an die Onboard-Unit (5) gesandt wird.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Parkgebührentransaktion (ta) von der Funkbake (7) an eine Zentrale gesandt wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die vorgegebene Zeitspanne (ΔT) 1 bis 30 min, bevorzugt 5 bis 20 min, besonders bevorzugt 10 min beträgt.
Funkbake zum Erzeugen einer Parkgebührentransaktion (ta) für ein Fahrzeug (1), das eine Onboard-Unit (5) mit einer Kennung (id) hat, wobei die Funkbake (7)
einen zumindest einen Parkplatz (4) abdeckenden Funkabdeckungsbereich (10) und
Mittel zum Funkabfragen der Kennung (id) einer in ihrem Funkabdeckungsbereich (10) befindlichen Onboard-Unit (5) als aktuelle Kennung (id_i),
Mittel zum Erzeugen einer Parkgebührentransaktion (ta) für die aktuelle Kennung (id_i), wenn diese Kennung (id_i) einer gespeicherten alten Kennung (id_i,last) gleicht, und damit für die Onboard-Unit (5) mit dieser Kennung (id_i) und deren Fahrzeug (1),
Mittel zum Speichern der aktuellen Kennung (id_i, set_curr) als alte Kennung (id_i,last, set_last), und
eine Zeitsteuerung zum wiederholten Auslösen der Mittel zum Funkabfragen, Erzeugen und Speichern nach einer vorgegebenen Zeitspanne (ΔT) hat.
Funkbake nach Anspruch 7, dadurch gekennzeichnet, dass die genannten Mittel der Funkbake (7) dafür ausgebildet sind, mit der Kennung (id_i) auch eine Position (p_i) der Onboard-Unit funkabzufragen und die Parkgebührentransaktion (ta) nur dann zu erzeugen, wenn zusätzlich zur genannten Kennungsgleichheit die Position (p_i) in einem vorgegebenen Bereich (P) liegt.
Funkbake nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass die genannten Mittel der Funkbake (7) dafür ausgebildet sind, eine Bakenkennung auszusenden, die angibt, dass es sich um eine Park-Funkbake handelt, mit der Kennung (id_i) der Onboard-Unit (5) auch einen Status (st_i) der Onboard-Unit (5) funkabzufragen und die Parkgebührentransaktion (ta) nur dann zu erzeugen, wenn zusätzlich zur genannten Kennungsgleichheit auch der Status (st_i) einem vorgegebenen Wert (PM) gleicht.
Funkbake nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass die Funkbake (7)
einen Funkabdeckungsbereich (10), der zumindest zwei Parkplätze (4) abdeckt, und
Mittel zum Funkabfragen der Kennungen (id_i) aller in ihrem Funkabdeckungsbereich (10) befindlicher Onboard-Units (5) als aktuelle Kennungen (id_i),
Mittel zum Erzeugen einer Parkgebührentransaktion (ta) für jede aktuelle Kennung (id_i), die einer gespeicherten alten Kennung (id_i,last) gleicht, und damit für die Onboard-Unit (5) mit dieser Kennung (id_i) und deren Fahrzeug (1),
Mittel zum Speichern der aktuellen Kennungen (id_i, set_curr) als alte Kennungen (id_i,last, set_last), und
eine Zeitsteuerung zum wiederholten Auslösen der Mittel zum Funkabfragen, Erzeugen und Speichern nach der vorgegebenen Zeitspanne (ΔT) hat.
Funkbake nach Anspruch 10, dadurch gekennzeichnet, dass die Funkbake (7) aus einem Vergleich der Anzahl von aktuellen Kennungen (id_i) und Anzahl von Parkplätzen (4) in ihrem Funkabdeckungsbereich (10) einen Parkplatzbelegungsstatus berechnet.
Onboard-Unit für ein Fahrzeug, mit einer eindeutigen Kennung (id), einem gespeicherten veränderbaren Status (st) und einem Sendeempfänger (13) zum Übermitteln (12) der Kennung (id) und des Status (st) auf eine Funkabfrage (11) einer Funkbake (7),
wobei die Onboard-Unit (5) einen ersten Betriebsmodus (TM) und einen zweiten Betriebsmodus (PM) hat, zwischen denen sie mittels eines Schalters (16') umschaltbar ist, und dafür ausgebildet ist, abhängig von der empfangenen Bakenkennung im zweiten Betriebsmodus (PM) nur auf Funkabfragen (11) einer nach Anspruch 9 ausgebildeten Funkbake (7) zu antworten, und
wobei der Status (st) den jeweiligen Betriebsmodus der Onboard-Unit (5) anzeigt.
Onboard-Unit nach Anspruch 12, dadurch gekennzeichnet, dass sie mit einer Positionsbestimmungseinrichtung (18') zur Bestimmung ihrer aktuellen Position (p_i) ausgestattet und dafür ausgebildet ist, auf eine Funkabfrage (11) der Funkbake (7) hin ihre Position (p_i) zu übermitteln.
Onboard-Unit nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass sie mit einem Bewegungssensor (18) ausgestattet ist, welcher bei einer einen Schwellwert überschreitenden Bewegung der Onboard-Unit (5) diese in den ersten Betriebsmodus (TM) umschaltet.
Onboard-Unit nach einem der Ansprüche 12 bis 14, dadurch gekennzeichnet, dass sie mit einem Bewegungssensor (18) ausgestattet ist, welcher bei einem eine Mindestzeitspanne (ΔT) überschreitenden Ausbleiben einer Bewegung der Onboard-Unit (5) diese in den zweiten Betriebsmodus (PM) umschaltet.
Onboard-Unit nach einem der Ansprüche 12 bis 15, dadurch gekennzeichnet, dass sie dafür ausgebildet ist, eine von einer Funkbake (7) im zweiten Betriebsmodus (PM) empfangene Parkgebührentransaktion (ta) im ersten Betriebsmodus (TM) an eine weitere Funkbake (6) zu senden.
Onboard-Unit nach einem der Ansprüche 12 bis 16, dadurch gekennzeichnet, dass sie einen stromsparenden dritten Betriebsmodus (sleep) hat, in welchen sie im zweiten Betriebsmodus (PM) nach Empfang einer Funkabfrage (11) oder Parkgebührentransaktion (ta) vorübergehend verfällt.