EP2709071A9 - Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen - Google Patents

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

Info

Publication number
EP2709071A9
EP2709071A9 EP12184676.0A EP12184676A EP2709071A9 EP 2709071 A9 EP2709071 A9 EP 2709071A9 EP 12184676 A EP12184676 A EP 12184676A EP 2709071 A9 EP2709071 A9 EP 2709071A9
Authority
EP
European Patent Office
Prior art keywords
identifier
radio
radio beacon
parking fee
parking
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP12184676.0A
Other languages
English (en)
French (fr)
Other versions
EP2709071B9 (de
EP2709071A1 (de
EP2709071B1 (de
Inventor
Alexander Leopold
Robert Povolny
Oliver Nagy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kapsch TrafficCom AG
Original Assignee
Kapsch TrafficCom AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kapsch TrafficCom AG filed Critical Kapsch TrafficCom AG
Priority to SI201230208T priority Critical patent/SI2709071T1/sl
Priority to PL12184676T priority patent/PL2709071T3/pl
Priority to PT121846760T priority patent/PT2709071E/pt
Priority to ES12184676.0T priority patent/ES2535933T3/es
Priority to EP20120184676 priority patent/EP2709071B9/de
Priority to DK12184676.0T priority patent/DK2709071T3/en
Priority to CA2822376A priority patent/CA2822376A1/en
Priority to SG2013059258A priority patent/SG2013059258A/en
Priority to NZ614100A priority patent/NZ614100A/en
Priority to AU2013219213A priority patent/AU2013219213A1/en
Priority to US14/023,769 priority patent/US20140081718A1/en
Priority to CN201310416266.XA priority patent/CN103679822A/zh
Priority to ZA2013/06914A priority patent/ZA201306914B/en
Priority to CL2013002653A priority patent/CL2013002653A1/es
Priority to RU2013142266/07A priority patent/RU2013142266A/ru
Publication of EP2709071A1 publication Critical patent/EP2709071A1/de
Publication of EP2709071A9 publication Critical patent/EP2709071A9/de
Application granted granted Critical
Publication of EP2709071B1 publication Critical patent/EP2709071B1/de
Publication of EP2709071B9 publication Critical patent/EP2709071B9/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/017—Detecting movement of traffic to be counted or controlled identifying vehicles
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the present invention relates to a method for generating a parking fee transaction for a vehicle having an onboard unit with an identifier.
  • the invention further relates to a radio beacon and an onboard unit for carrying out this method.
  • Onboard units are electronic devices that are carried by vehicles in order to be able to identify the vehicles wirelessly by radio, for example, for charging tolls in electronic road toll systems.
  • OBUs may be in the form of active or passive radio transponders, radio frequency identification (RFID) chips, near field communication (NFC) chips, dedicated short range communication (DSRC) transceivers, WAVE (wireless access in vehicular environments), and WLAN Nodes (wireless local area networks) and so on.
  • RFID radio frequency identification
  • NFC near field communication
  • DSRC dedicated short range communication
  • WAVE wireless access in vehicular environments
  • WLAN Nodes wireless local area networks
  • the invention is based on the recognition that by comparing the funkabfragbaren at a certain time identifiers located in the radio coverage of the beacon OBUs with identifiers interrogated at an earlier point in time can identify those identifiers and thus OBUs and their vehicles which were present at both times in the radio coverage area and therefore have parked there with high probability. In this way, an astonishingly simple method for generating parking fee transactions, scalable to any number of parking spaces in the radio coverage area of a radio beacon, is created.
  • a position of the on-board unit is funkabrati with the identifier and the parking fee transaction is only generated if in addition to said identity identity, the position is within a predetermined range.
  • radio coverage of the radio beacon can be intercepted, i. if the parking area is smaller than the radio coverage area of the radio beacon.
  • a status of the on-board unit is funkabrati with the identifier and the parking fee transaction is only generated if in addition to the identity of identity mentioned also the status is equal to a predetermined value.
  • parking fee transactions are generated only for those OBUs which have set a corresponding "parking status". For example, OBUs of vehicles that are only temporarily in the radio coverage area of the beacon because they are temporarily stuck in traffic along with parked cars can be ignored; conversely, by deliberately setting the park status on a user's OBU, a user may indicate that he now parks and wants to pay parking fees.
  • the parking fee transactions generated can be further processed and billed in a variety of ways.
  • the parking fee transactions are sent by the radio beacon via radio to the onboard unit and charged there, for example, as a debit transaction to a credit held in the onboard unit (an "electronic purse").
  • the generated parking fee transactions sent from the radio beacon to a central office, for example, a toll center of a road toll system, a bank computer, a credit card accounting center, etc. and there charged to a bank, credit or debit account of the user assigned to the OBU identifier.
  • the method according to the invention operates in steps of the predetermined waiting time period and can accordingly charge park stays in these time units. It is advantageous if the predetermined period of time is 1 to 30 minutes, preferably 5 to 20 minutes, particularly preferably 10 minutes, whereby short stays less than 10 minutes remain toll-free and sufficient time accuracy is achieved for longer stays.
  • the invention provides a radio beacon for generating a parking fee transaction for a vehicle having an on-board unit with an identifier
  • the radio beacon has a radio coverage area covering at least one parking lot and is configured to: to request the identifier of an on-board unit in its radio coverage area as the current identifier, if the current identifier is similar to a stored old identifier, generating a parking fee transaction for that identifier, save the current ID as an old ID, and repeat these steps after a predetermined period of time.
  • the radio beacon is configured to also request a position of the onboard unit with the identifier and to generate the parking fee transaction only if, in addition to the identity of identity mentioned above, the position lies within a predetermined range.
  • the radio beacon is configured to also request a status of the onboard unit with the identifier and to generate the parking fee transaction only if, in addition to the identity of identity mentioned, the status also equals a predetermined value.
  • the radio beacon has a radio coverage area which covers at least two parking spaces and is designed to to request the identifiers of all on-board units in their radio coverage area as current identifiers, for each current identifier, which is similar to a stored old identifier, to generate a parking fee transaction, save the current identifiers as old identifiers, and to repeat these steps after the given period of time.
  • the radio beacon can calculate a parking lot occupancy status from a comparison of the number of current identifiers and number of parking spaces in its radio coverage area.
  • the invention provides an on-board unit for a vehicle, having a unique identifier, a stored variable status, and a transceiver for communicating the identifier and status to a radio beacon of a beacon, which onboard unit is characterized by having a first operating mode and a second operating mode between which it is switchable by means of a switch, the status indicating the respective operating mode of the onboard unit.
  • the on-board unit of the invention is therefore particularly suitable for those embodiments of the method and the radio beacon in which they take into account a set status in the OBU and generate parking fee transactions only for those OBUs for which the user has set the park mode or parking status ,
  • the on-board unit is preferably equipped with a position-determining device for determining its current position and is designed to transmit its position to a radio query of the radio beacon.
  • the on-board unit may be equipped with a motion sensor which switches over to a threshold value exceeding movement of the onboard unit this in the first operating mode and / or at a minimum time exceeding the absence of movement of the onboard unit this switches to the second operating mode.
  • a motion sensor which switches over to a threshold value exceeding movement of the onboard unit this in the first operating mode and / or at a minimum time exceeding the absence of movement of the onboard unit this switches to the second operating mode.
  • the on-board unit toll mode of operation in which it communicates with toll-beacons on its way can be exploited according to the invention for a parking-fee transaction via the infrastructure of the road toll system obtained in the park operating mode from a park beacon settle.
  • the OBU After leaving the parking mode and the radio coverage area of the park radio beacon, for example, the OBU sends the parking fee transaction to the first toll radio beacon that it encounters on its way so as to settle the parking fee through the charging system of the toll radio beacons.
  • the on-board unit has a power-saving third operating mode in which it temporarily expires in the second operating mode after receiving a radio query or parking fee transaction. Since the radio interrogations of a park radio beacon are comparatively rare, e.g. every 10 minutes, the on-board unit can save a considerable amount of power in this way.
  • a vehicle 1 moves on a road 2 at a speed and direction 3 and in Fig. 2 park several vehicles 1 each on a parking lot 4 of the road 2.
  • the road 2 may be any traffic or parking space, such as a highway, highway or a whole road network in Fig. 1 or a parking strip, a large parking area or a parking garage in Fig. 2 ; All this is understood here by the generic term "road" 2.
  • the vehicles 1 are each equipped with an onboard unit (OBU) 5, which can handle wireless roadside units (RSUs) 6, 7 radio communications 8.
  • OBUs 5 may be stand-alone devices or components of the vehicle electronics.
  • the radio communications 8 are dedicated short range communications (DSRC) communications, preferably according to the standards CEN-DSRC, ITS-G5, IEEE 802.11p, WAVE, WLAN, RFID, NFC or the like.
  • the radio beacons 6, 7 thereby each have a locally limited radio coverage area 9, 10.
  • the radio beacons 6 of Fig. 1 are tolling roadside units (T-RSUs) geographically distributed along the road 2.
  • the toll radio beacons 6 request, with the aid of periodically radiated radio interrogations 11, all the OBUs 5 passing through them for radio communication 8, as illustrated by the exemplary answer 12.
  • the radio interrogations 11 of the toll beacons 6 are broadcast in relatively short time intervals, for example every 100 ms.
  • WSA messages wave service announcements
  • BST messages beacon service tables
  • a successful radio communication 8 with a passing OBU 5 proves that the OBU 5 is located in the local radio coverage area 9 of the toll radio beacon 6, whereby the use of the location of the toll radio beacon 6 can be charged ("marred”).
  • the exploited locality may, for example, driving on a piece of road, entering a certain area ("city toll”) or the like. his.
  • parking roadside units (P-RSUs) 7 are used which, with a radio interrogation 11, for example a WSA or BST message, prompt all OBUs 5 in their radio coverage area 10 for reply messages 12 in order to use them parking lots 4, as discussed in detail below.
  • a park radio beacon 7 can be responsible for one or more parking spaces 4, which together form a parking area P.
  • a park radio beacon 7 can transmit its radio interrogations 11 at much greater intervals ⁇ T than the toll radio beacon 6 of FIG Fig. 1 for example, every 10 minutes, which simultaneously defines the time resolution of parking time accounting.
  • the radio coverage area 10 of the park radio beacon 7 can be adapted to the spatial extent of the parking spaces 4 by optional measures, for example directional antennas, in order to avoid responses 12 of OBUs 5 from non-parking, eg passing vehicles 1.
  • the OBUs 5 of the vehicles 1 in different, the scenarios of Fig. 1 and 2 each adapted operating modes are offset, namely, a first tolling mode (TM) for reply 12 to radio polls 11 of toll beacons 6, and a second parking mode (PM) for answer 12 to radio polls 11 of park radio beacons 7.
  • the radio beacons 6, 7 in the radio inquiries 11 can each emit a beacon identifier indicating whether it is a toll radio beacon 6 or a park radio beacon 7.
  • the beacon identifier may be specified as the service of the beacon as part of a WSA or BST message.
  • the toll radio beacons 6 and parking radio beacons 7 can also be realized by one and the same physical unit which, alternately or simultaneously, performs the functions of a toll and a parking radio beacon 6, 7.
  • a combined unit 6, 7 can be e.g. consecutively at short intervals radio interrogations 11 with beacon identification of a toll radio beacon and at longer intervals ⁇ T, i. occasionally "interspersed", send radio queries 11 with beacon ID of a park radio beacon 7.
  • Such a radio beacon 6, 7 is then responsible, for example, both for the Vermauten a street piece of the road 2 and the charging of a parking area P.
  • the OBU 5 may e.g. only toll beacons 6 respond when in the toll mode TM, or only park beacons 7 when in the park mode PM.
  • the operating mode of an OBU 5 can also be coded as a data message (status) st and sent in the response 12.
  • the OBUs 5 may also each measure their own positions p and send them to the park radio beacons 7, which receive the received positions p with their respective parking areas P and only the parking of such OBUs 5 fees whose positions p fall in their respective parking area P. This will now be with reference to the Fig. 3 - 6 explained in more detail.
  • Fig. 3 shows an exemplary block diagram
  • Fig. 4 an exemplary exterior view
  • Fig. 5 an exemplary state diagram of an OBU 5, which between (at least) two operating modes TM and PM according to the application scenarios of Fig. 1 and 2 is switchable.
  • an OBU 5 has a transceiver 13 (eg according to one of the DSRC standards mentioned) for carrying out the radio communications 8, a microprocessor 14 controlling the transceiver 13, a memory 15, an input device 16 and an output device 17.
  • the input and output devices 16, 17 can also be realized in other ways than by the illustrated keyboard and screen output, for example, by voice input and output, sensors, cues, etc.
  • the input and output devices 16, 17 can also be physically separated Components such as car radios, navigation devices, smart phones, PDAs, tablets etc. formed and wired or wireless, eg via NFC, Bluetooth ® , WLAN or infrared, be connected to the microprocessor 14.
  • Components such as car radios, navigation devices, smart phones, PDAs, tablets etc. formed and wired or wireless, eg via NFC, Bluetooth ® , WLAN or infrared, be connected to the microprocessor 14.
  • the OBU 5 may also include a motion sensor 18 in the form of e.g. a satellite navigation receiver for a global navigation satellite system (GNSS) such as GPS, GLONASS, GALILEO, etc .;
  • GNSS global navigation satellite system
  • any other type of motion sensor 18 could be used, for example an inertial measurement unit (IMU) or a sensor connected to components of the vehicle 1, for example a connection to the speedometer or engine of the vehicle 1.
  • IMU inertial measurement unit
  • the motion sensor 18 may also be a mere connection to the vehicle electronics, for example the ignition lock of the vehicle, so that, for example, the key position (motor running - does not run) indicates the (probable) movement or parking status of the vehicle.
  • the OBU 5 may optionally be further equipped with a position-determining device 18 ', which is capable of determining the current position p of the OBU 5 - on interrogation, periodically or continuously.
  • the position determiner 18 ' may operate in any manner known in the art, e.g. by means of radio-triangulation in a network of geographically distributed radio stations, e.g. may be formed by the radio beacons 6, 7 itself or base stations of a mobile network, or by means of evaluation of the cell identifiers of a cellular mobile network, etc., etc.
  • the position determining means 18 ' is a satellite navigation receiver for position determination in a GNSS and in particular by the same GNSS receiver be formed, which is used for the motion sensor 18.
  • the memory 15 of the OBU 5 contains - in addition to the appropriate application and control programs and data - a unique identifier id the OBU 5, which is set and stored for example in the output or user-specific initialization of the OBU 5 and the OBU 5 and / or their User and / or the vehicle 1 and / or a billing account of the user uniquely identified.
  • the OBU identifier id is sent in each response message 12 from the OBU 5 to a radio beacon 6, 7 in order to uniquely identify the OBU 5 with respect to the radio beacon 6, 7.
  • the memory 15 may further include the status st indicating the operating mode TM or PM of the OBU 5 for the corresponding scenario of FIG Fig. 1 or 2 indicates.
  • the status st can be changed or set both as a function of a movement (or non-movement) of the OBU 5 measured by the motion sensor 16 and by a user selection via the input device 16.
  • the input device 16 can, for example, a latchable button 16 '( Fig. 4 ), which is labeled "PM" for "Park Mode” PM and by pressing and locking, the OBU 5 switches to the park operating mode PM and sets the status st to the value "PM".
  • the output device 17 can optionally output corresponding notification and / or confirmation messages.
  • Fig. 5 shows some of the possible operating states of the OBU 5 again in detail in the form of a state diagram (state transition diagram).
  • the OBU 5 can be placed in the park mode of operation PM by depressing the button 16 'and / or if the motion sensor 18 detects no movement of the OBU 5 for a minimum period of, for example, 5 minutes.
  • this can be put back from the park operating mode PM back into the toll mode TM.
  • the OBU 5 may temporarily go into a sleep mode, as soon as it has received a radio interrogation 11 of a park radio beacon 7 and has responded with an answer 12.
  • the OBU 5 may wake up from the sleep mode after a predetermined period of time ⁇ t and return to the park mode PM.
  • the time interval .DELTA.t is preferably shorter than the time period .DELTA.T which lies between successive radio requests 11 of a park radio beacon 7.
  • the OBU 5 could also be woken up again by receiving a next radio interrogation 11.
  • Fig. 6 shows that in a park radio beacon 7 in conjunction with the OBU 5 of Fig. 3-5 ongoing processes for generating parking fee transactions in the application scenario of Fig. 2 ,
  • a radio poll 11 is sent by the park radio beacon 7 to request the OBUs 5 in its radio coverage area 10 for responses 12.
  • the responses arriving from the OBUs 5 become 12 each response 12 contains at least the respective identifier id i of the OBU 5 with the index i and optionally its status st i and / or its position p i determined by the position determination device 18 '.
  • the received identifiers id i , stati st i and positions p i are temporarily stored as the current record set curr in the park radio beacon 7.
  • Id i running loop 21 is then within one of all received identifiers checks whether the current status st i is set to parking mode of operation "PM" or not, see decision 22.
  • a further decision 23 checks whether the respective identifier id i of a previously stored "old" identifier id i, last , that is, in a record set last ⁇ id i, last ⁇ of old identifiers id i, last occurs or not.
  • These "old" identifiers id i, last were determined in an earlier process run and stored in the record set last , as explained below.
  • step 24 the process branches to step 24, in which a parking fee transaction ta (id i ) is generated for the current identifier id i , as explained in more detail later.
  • step 24 the loop 21 is continued or after its completion, moved to step 25.
  • step 25 the current identifiers id i determined in step 20 are then re-stored as "old" identifiers id i, last , ie the current data setset curr is stored as (now) "old” data set set last .
  • step 26 the predetermined period .DELTA.T is waited, which lies between the individual radio queries 11 of the park radio beacon 7, and then the procedure repeated (loop 27).
  • the previously determined current identifiers id i now represent the "old" identifiers id i, last , and if "new" current identities id i are determined again in step 20, these can then be determined in step 23 with the "old" identifiers id i, last from the last record set last .
  • each loop pass 27 it is checked in each loop pass 27 whether an OBU identifier id i determined by a park radio beacon 7 on the basis of a radio query 11 has already been present at a radio poll 11 past the time interval ⁇ T or not; if yes, a vehicle 1 with an OBU 5 of this identifier id i has apparently spent at least the time interval .DELTA.T in the radio coverage area 10 of the park radio beacon 7, so that for the parking over the period .DELTA.T a corresponding parking fee transaction ta (id i ) for the OBU Identifier id i may be generated (step 24).
  • the parking fee transactions ta (id i ) generated in step 24 can be billed by the radio beacon 7 itself, for example by loading a user account carried in the radio beacon 7 with it.
  • the parking fee transactions ta (id i ) may be forwarded from the radio beacon 7 to a remote center (not shown) which carries user accounts, toll accounts, bank accounts, credit accounts, etc. among the identities id i such that the parking fee transactions ta (id i ) there a corresponding billing account can be charged.
  • the generated parking fee transaction (s) ta (id i ) from the radio beacon 7 to be sent back to the OBU 5 with the identifier id i , where it is stored in the OBU 5 charged billing account (an "electronic purse") is / are charged.
  • Fig. 5 shows a corresponding operating mode "post ta" in which the OBU 5 temporarily enters after returning from the parking operating mode PM and waits for the next toll radio beacon 6 on its way to process the parking fee transaction (s) ta (id i ), after which it returns to the "normal" toll mode TM.
  • Fig. 6 shown sequences can be modified according to known in the art programming methods accordingly.
  • the loop 21 could be implemented differently and, for example, immediately after receiving a response 12 for an identifier id i, steps 22-24 and 23-24, respectively, could be performed if this is done so rapidly computationally that between successive incoming responses 12 can be performed. It should be noted that, according to some DSRC standards, the responses 12 from multiple OBUs 5 that replicate to a common radio interrogation 11 are variably time-spanned to avoid collisions of responses 12 so that there is quite enough time between responses 12 Steps 22 - 24 or 23 - 24 may remain.
  • the Parking occupied status determined in this way can be sent, for example, to a parking management center.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Traffic Control Systems (AREA)
  • Navigation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein 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:
- Funkabfragen der Kennung (id) von einer straßenseitigen Funkbake (7) aus als aktuelle Kennung (idi);
- wenn die aktuelle Kennung (idi) einer gespeicherten alten Kennung (idi,last) gleicht, Erzeugen einer Parkgebührentransaktion (ta) für die Kennung (id);
- Speichern der aktuellen Kennung (idi, setcurr) als alte Kennung (idi,last, setlast) ;
- Abwarten einer vorgegebenen Zeitspanne (ΔT);

Wiederholen der vorgenannten Schritte.
Die Erfindung betrifft ferner eine Funkbake (7) und eine Onboard-Unit (5) zur Durchführung des Verfahrens.

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 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 Funkabdeckungsbereich 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 idi der OBU 5 mit dem Index i und - optional - deren Status sti und/oder deren von der Positionsbestimmungseinrichtung 18' bestimmte Position pi enthält. Die empfangenen Kennungen idi, Stati sti und Positionen pi werden als aktueller Datensatz setcurr in der Park-Funkbake 7 vorübergehend gespeichert.
  • Anschließend wird innerhalb einer über alle empfangenen Kennungen idi laufenden Schleife 21 überprüft, ob der jeweilige Status sti 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 pi - 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: sti = PM und pi ∈ P (Zweig "y" von 22), wird in einer weiteren Entscheidung 23 überprüft, ob die jeweilige Kennung idi einer zuvor gespeicherten "alten" Kennung idi,last entspricht, d.h. in einem Datensatz setlast{idi,last} von alten Kennungen idi,last vorkommt oder nicht. Diese "alten" Kennungen idi,last wurden in einem früheren Verfahrensdurchlauf ermittelt und im Datensatz setlast gespeichert, wie gleich im Anschluss erläutert wird.
  • Wenn die jeweilige aktuelle Kennung idi keiner alten Kennung idi,last entspricht, d.h. nicht im Datensatz setlast 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(idi) für die aktuelle Kennung idi 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 idi als "alte" Kennungen idi,last umgespeichert, d.h. der aktuelle Datensatz setcurr als (nun) "alter" Datensatz setlast 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 idi die "alten" Kennungen idi,last dar, und wenn im Schritt 20 wieder "neue" aktuelle Kennungen idi ermittelt werden, können diese dann in Schritt 23 mit den "alten" Kennungen idi,last aus dem letzten Datensatz setlast verglichen werden. Dadurch wird bei jedem Schleifendurchlauf 27 überprüft, ob eine von einer Park-Funkbake 7 aufgrund einer Funkabfrage 11 ermittelte OBU-Kennung idi 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 idi 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(idi) für die OBU-Kennung idi erzeugt werden darf (Schritt 24).
  • Die in Schritt 24 erzeugten Parkgebührentransaktionen ta(idi) 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(idi) von der Funkbake 7 an eine entfernte (nicht dargestellte) Zentrale weitergesandt werden, welche Benutzerkonten, Mautkonten, Bankkonten, Kreditkonten usw. unter den Kennungen idi führt, sodass die Parkgebührentransaktionen ta(idi) dort einem entsprechenden Abrechnungskonto angelastet werden können. Es ist aber auch möglich, dass die erzeugte(n) Parkgebührentransaktion(en) ta(idi) von der Funkbake 7 an die OBU 5 mit der Kennung idi 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(idi) 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(idi) 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 sti einer Kennung idi auf "PM" steht und/oder die Position pi einer Kennung idi in den Bereich P fällt, wobei dann überhaupt nur solche Kennungen idi als aktuelle Kennungen im aktuellen Datensatz setcurr gespeichert werden, deren Status sti = "PM" bzw. Position pi ∈ 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 idi 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 idi 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 (17)

  1. 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:
    - Funkabfragen der Kennung (id) von einer straßenseitigen Funkbake (7) aus als aktuelle Kennung (idi);
    - wenn die aktuelle Kennung (idi) einer gespeicherten alten Kennung (idi,last) gleicht, Erzeugen einer Parkgebührentransaktion (ta) für die Kennung (id);
    - Speichern der aktuellen Kennung (idi, setcurr) als alte Kennung (idi,last, setlast);
    - Abwarten einer vorgegebenen Zeitspanne (ΔT);
    Wiederholen der vorgenannten Schritte.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mit der Kennung (idi) auch eine Position (pi) der Onboard-Unit (5) funkabgefragt und die Parkgebührentransaktion (ta) nur dann erzeugt wird, wenn zusätzlich zur genannten Kennungsgleichheit die Position (pi) in einem vorgegebenen Bereich (P) liegt.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass mit der Kennung (idi) auch ein Status (sti) der Onboard-Unit (5) funkabgefragt und die Parkgebührentransaktion (ta) nur dann erzeugt wird, wenn zusätzlich zur genannten Kennungsgleichheit auch der Status (sti) einem vorgegebenen Wert (PM) gleicht.
  4. 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.
  5. 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.
  6. 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.
  7. 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) hat und dafür ausgebildet ist,
    die Kennung (id) einer in ihrem Funkabdeckungsbereich (10) befindlichen Onboard-Unit (5) als aktuelle Kennung (idi) funkabzufragen,
    wenn die aktuelle Kennung (idi) einer gespeicherten alten Kennung (idi,last) gleicht, eine Parkgebührentransaktion (ta) für diese Kennung (idi) zu erzeugen,
    die aktuelle Kennung (idi, setcurr) als alte Kennung (idi,last, setlast) zu speichern, und
    diese Schritte nach einer vorgegebenen Zeitspanne (ΔT) zu wiederholen.
  8. Funkbake nach Anspruch 7, dadurch gekennzeichnet, dass die Funkbake (7) dafür ausgebildet ist, mit der Kennung (idi) auch eine Position (pi) der Onboard-Unit funkabzufragen und die Parkgebührentransaktion (ta) nur dann zu erzeugen, wenn zusätzlich zur genannten Kennungsgleichheit die Position (pi) in einem vorgegebenen Bereich (P) liegt.
  9. Funkbake nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass die Funkbake (7) dafür ausgebildet ist, mit der Kennung (idi) auch einen Status (sti) der Onboard-Unit (5) funkabzufragen und die Parkgebührentransaktion (ta) nur dann zu erzeugen, wenn zusätzlich zur genannten Kennungsgleichheit auch der Status (sti) einem vorgegebenen Wert (PM) gleicht.
  10. Funkbake nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass die Funkbake (7) einen Funkabdeckungsbereich (10) hat, der zumindest zwei Parkplätze (4) abdeckt, und dafür ausgebildet ist,
    die Kennungen (idi) aller in ihrem Funkabdeckungsbereich (10) befindlicher Onboard-Units (5) als aktuelle Kennungen (idi) funkabzufragen,
    für jede aktuelle Kennung (idi), die einer gespeicherten alten Kennung (idi,last) gleicht, eine Parkgebührentransaktion (ta) zu erzeugen,
    die aktuellen Kennungen (idi, setcurr) als alte Kennungen (idi,last, setlast) zu speichern, und
    diese Schritte nach der vorgegebenen Zeitspanne (ΔT) zu wiederholen.
  11. Funkbake nach Anspruch 10, dadurch gekennzeichnet, dass die Funkbake (7) aus einem Vergleich der Anzahl von aktuellen Kennungen (idi) und Anzahl von Parkplätzen (4) in ihrem Funkabdeckungsbereich (10) einen Parkplatzbelegungsstatus berechnet.
  12. 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), dadurch gekennzeichnet, dass die Onboard-Unit (5) einen ersten Betriebsmodus (TM) und einen zweiten Betriebsmodus (PM) hat, zwischen denen sie mittels eines Schalters (16') umschaltbar ist, wobei der Status (st) den jeweiligen Betriebsmodus der Onboard-Unit (5) anzeigt.
  13. Onboard-Unit nach Anspruch 12, dadurch gekennzeichnet, dass sie mit einer Positionsbestimmungseinrichtung (18') zur Bestimmung ihrer aktuellen Position (pi) ausgestattet und dafür ausgebildet ist, auf eine Funkabfrage (11) der Funkbake (7) hin ihre Position (pi) zu übermitteln.
  14. 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.
  15. Onboard-Unit nach einem der Ansprüche 12 bis 14, dadurch gekennzeichnet, dass sie mit einem Bewegungssensor (18) ausgestattet ist, welcher bei einem einen Mindestzeitspanne (ΔT) überschreitenden Ausbleiben einer Bewegung der Onboard-Unit (5) diese in den zweiten Betriebsmodus (PM) umschaltet.
  16. 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.
  17. 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.
EP20120184676 2012-09-17 2012-09-17 Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen Not-in-force EP2709071B9 (de)

Priority Applications (15)

Application Number Priority Date Filing Date Title
SI201230208T SI2709071T1 (sl) 2012-09-17 2012-09-17 Postopek, radijska boja in enota na krovu vozila za tvorjenje parkirninskih transakcij
PL12184676T PL2709071T3 (pl) 2012-09-17 2012-09-17 Sposób, radiolatarnia i urządzenie pokładowe do generowania transakcji opłat za parkowanie
PT121846760T PT2709071E (pt) 2012-09-17 2012-09-17 Método, radiofarol e unidade embarcada para gerar transacções de taxas de estacionamento
ES12184676.0T ES2535933T3 (es) 2012-09-17 2012-09-17 Procedimiento, radiobaliza y unidad de a bordo para la generación de transacciones de tarifa de aparcamiento
EP20120184676 EP2709071B9 (de) 2012-09-17 2012-09-17 Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen
DK12184676.0T DK2709071T3 (en) 2012-09-17 2012-09-17 PROCEDURE, WIRELESS RADIO FIRE AND ONBOARD DEVICE FOR GENERATION OF PARKING FEE TRANSACTIONS
CA2822376A CA2822376A1 (en) 2012-09-17 2013-07-31 Method, radio beacon and onboard-unit for generating parking fee transactions
SG2013059258A SG2013059258A (en) 2012-09-17 2013-08-01 Method, radio beacon and onboard unit for generating parking fee transactions
NZ614100A NZ614100A (en) 2012-09-17 2013-08-09 Method, radio beacon and onboard-unit for generating parking fee transactions
AU2013219213A AU2013219213A1 (en) 2012-09-17 2013-08-22 Method, radio beacon and onboard-unit for generating parking fee transactions
US14/023,769 US20140081718A1 (en) 2012-09-17 2013-09-11 Method, radio beacon and onboard unit for generating parking fee transactions
ZA2013/06914A ZA201306914B (en) 2012-09-17 2013-09-13 Method, radio beacon and onboard-unit for generating parking fee transactions
CL2013002653A CL2013002653A1 (es) 2012-09-17 2013-09-13 Metodo para generacion de transacciones de tarifas de estacionamientos para un vehiculo que comprende una unidad a bordo que tiene un identificador , radiobaliza y unidad de bordo.
CN201310416266.XA CN103679822A (zh) 2012-09-17 2013-09-13 产生停泊费事务的方法、无线电导航台和机载单元
RU2013142266/07A RU2013142266A (ru) 2012-09-17 2013-09-16 Способ, радиомаяк и бортовой модуль для генерирования транзакций для оплаты стоянки

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20120184676 EP2709071B9 (de) 2012-09-17 2012-09-17 Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen

Publications (4)

Publication Number Publication Date
EP2709071A1 EP2709071A1 (de) 2014-03-19
EP2709071A9 true EP2709071A9 (de) 2014-04-23
EP2709071B1 EP2709071B1 (de) 2015-02-25
EP2709071B9 EP2709071B9 (de) 2015-05-20

Family

ID=47018785

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20120184676 Not-in-force EP2709071B9 (de) 2012-09-17 2012-09-17 Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen

Country Status (15)

Country Link
US (1) US20140081718A1 (de)
EP (1) EP2709071B9 (de)
CN (1) CN103679822A (de)
AU (1) AU2013219213A1 (de)
CA (1) CA2822376A1 (de)
CL (1) CL2013002653A1 (de)
DK (1) DK2709071T3 (de)
ES (1) ES2535933T3 (de)
NZ (1) NZ614100A (de)
PL (1) PL2709071T3 (de)
PT (1) PT2709071E (de)
RU (1) RU2013142266A (de)
SG (1) SG2013059258A (de)
SI (1) SI2709071T1 (de)
ZA (1) ZA201306914B (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160342979A1 (en) * 2014-04-08 2016-11-24 Capital One Services, Llc Systems and methods for transaction authentication using dynamic wireless beacon devices
WO2016135711A1 (en) * 2015-02-27 2016-09-01 Veniam Inc. Method and system for operating a vehicular data network based on a layer-2 periodic frame broadcast, in particular a routing protocol
EP3332370A4 (de) * 2015-08-06 2019-03-20 Capital One Services, LLC Systeme und verfahren zur interaktionsauthentifizierung mit dynamischen drahtlosen bakenvorrichtungen
EP3536064B1 (de) * 2016-11-03 2021-09-08 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren und anordnungen zur unterstützung der positionierung einer drahtlosen vorrichtung in einem drahtloskommunikationsnetzwerk
US10708808B2 (en) * 2018-05-14 2020-07-07 Denso International America, Inc. Systems and methods for receiving/transmitting basic safety messages and IP communications with a DSRC radio
JP2021530033A (ja) * 2018-09-24 2021-11-04 パナソニックＩｐマネジメント株式会社 コミュニティ定義されたスペース
EP4058961A4 (de) * 2019-11-11 2023-11-01 Brock Watson Zahlungstransaktionen für parkgebühren
CN112203256B (zh) * 2020-09-11 2024-03-22 北京万集科技股份有限公司 车载单元的控制方法和装置、存储介质及电子装置
CN112712598B (zh) * 2020-12-04 2022-10-25 北京握奇智能科技有限公司 停车场etc收费管理系统及方法
CN112735175B (zh) * 2020-12-28 2022-01-28 四川科瑞纳信息技术有限公司 一种基于无线信标的停车方法及系统
CN114228554B (zh) * 2021-11-17 2024-03-15 深圳市金溢科技股份有限公司 电动车辆的充电扣费方法、rsu控制器、设备及介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5751973A (en) * 1990-05-17 1998-05-12 At/Comm Incorporated Electronic parking and dispatching management method and apparatus
WO1994027256A1 (de) * 1993-05-18 1994-11-24 Siemens Aktiengesellschaft Gebührenerfassungssystem für die benutzung innerstädtischer strassen bzw. verkehrsflächen
JP4375415B2 (ja) * 2007-02-28 2009-12-02 株式会社デンソー 自動料金収受システム、車載装置及び端末
US9829560B2 (en) * 2008-03-31 2017-11-28 Golba Llc Determining the position of a mobile device using the characteristics of received signals and a reference database
EP2148305A1 (de) * 2008-07-22 2010-01-27 Kapsch Trafficcom AG Verfahren zum Vergebühren von Ortsnutzungen einer mobilen Station
US8330624B2 (en) * 2009-08-10 2012-12-11 Eric Groft Enhancements to meterless remote parking monitoring systems
ITTO20100684A1 (it) * 2010-08-09 2012-02-10 Elsag Datamat Spa Metodo e sistema di determinazione dello stato di occupazione di uno stallo di sosta
US9264673B2 (en) * 2011-11-20 2016-02-16 Magna Electronics, Inc. Vehicle vision system with enhanced functionality
US11222482B2 (en) * 2014-10-28 2022-01-11 Enzo Stancato System and method for an integrated parking management system

Also Published As

Publication number Publication date
RU2013142266A (ru) 2015-03-27
SI2709071T1 (sl) 2015-07-31
US20140081718A1 (en) 2014-03-20
EP2709071B9 (de) 2015-05-20
PL2709071T3 (pl) 2015-08-31
EP2709071A1 (de) 2014-03-19
SG2013059258A (en) 2014-04-28
PT2709071E (pt) 2015-06-01
DK2709071T3 (en) 2015-05-26
CL2013002653A1 (es) 2014-07-18
CA2822376A1 (en) 2014-03-17
NZ614100A (en) 2014-07-25
ES2535933T3 (es) 2015-05-19
AU2013219213A1 (en) 2014-04-03
ZA201306914B (en) 2014-05-28
EP2709071B1 (de) 2015-02-25
CN103679822A (zh) 2014-03-26

Similar Documents

Publication Publication Date Title
EP2709071B1 (de) Verfahren, Funkbake und Onboard-Unit zum Erzeugen von Parkgebührentransaktionen
EP2709051B1 (de) Verfahren zum elektronischen Verarbeiten eines Verkehrsdelikts und Onboard-Unit hierfür
EP2624233B1 (de) Verfahren zur Kontrolle in einem Straßenmautsystem
EP2362362B1 (de) Verfahren zum Laden von Elektrofahrzeugen in geographisch verteilten Ladestationen
EP2835788B1 (de) Verfahren zur Ein- und Ausfahrtskontrolle bei Parkhäusern und Parkanlagen
EP2431945B1 (de) Verfahren und Fahrzeuggerät zur Funkkommunikation in einem Strassenmautsystem
EP2610815B1 (de) Verfahren zum Ermitteln von Verkehrsflussdaten in einem Straßennetz
CN105225521A (zh) 基于物联网的停车管理系统及方法
CN103578150B (zh) 基于一体化功能标签的停车收费系统及其方法
EP1783692A2 (de) Enforcement mit verringerten Umlaufzeiten
AT411500B (de) Duales mautsystem
EP2820634A1 (de) Verfahren und system zur übermittlung von verkehrsmittel-/fahrstreckendaten in einem verkehrsmittel an ein mobilfunkgerät und zur ermittlung von abrechnungsrelevanten daten
EP2249313A1 (de) Verfahren zur nutzungsspezifischen Initialisierung von Fahrzeuggeräten
CN103150768A (zh) 一种计算高速公路行车费用的方法
EP2500869B1 (de) Verfahren zum Zurverfügungstellen von ortsbezogenen Datendiensten
Kabir et al. An IoT based intelligent parking system for the unutilized parking area with real-time monitoring using mobile and web application
DE10032409A1 (de) Vorrichtung zu flexiblen Gebührenerfassung
EP2690601B1 (de) Mautkontrollverfahren und Mautkontrolleinrichtungen sowie Mautsystem mit derartigen Mautkontrolleinrichtungen
WO2013139455A1 (de) Verfahren zur anzeige von parkplätzen
WO2020165034A1 (de) Konzept zum bereitstellen von parkplatzverfügbarkeitsinformationen
CN103489332A (zh) 智慧社区的车位搜索网络
EP3921820B1 (de) Verfahren und netzwerk zur vorkonditionierung zumindest einer komponente eines kraftfahrzeugs
WO2007073748A1 (de) SYSTEM UND VERFAHREN ZUR BESTIMMUNG DER NUTZUNGSGEBÜHREN FÜR MAUTPFLICHTIGE STRAßENABSCHNITTE UND/ODER GEBIETE
EP2026311B1 (de) System zur Ermittlung von Verkehrsinformationen
EP2665044B1 (de) Verfahren zum Messen der Leistungsfähigkeit eines Straßenmautsystems

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130212

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 502012002338

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G07B0015060000

Ipc: G07C0005000000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: G07B 15/06 20110101ALI20141002BHEP

Ipc: G08G 1/00 20060101ALI20141002BHEP

Ipc: G07B 15/02 20110101ALI20141002BHEP

Ipc: G07C 5/00 20060101AFI20141002BHEP

INTG Intention to grant announced

Effective date: 20141016

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502012002338

Country of ref document: DE

Effective date: 20150409

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 712539

Country of ref document: AT

Kind code of ref document: T

Effective date: 20150415

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2535933

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20150519

REG Reference to a national code

Ref country code: DK

Ref legal event code: T3

Effective date: 20150520

REG Reference to a national code

Ref country code: PT

Ref legal event code: SC4A

Free format text: AVAILABILITY OF NATIONAL TRANSLATION

Effective date: 20150429

REG Reference to a national code

Ref country code: SE

Ref legal event code: TRGR

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: NO

Ref legal event code: T2

Effective date: 20150225

Ref country code: LT

Ref legal event code: MG4D

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

Ref country code: FI

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

Effective date: 20150225

Ref country code: HR

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

Effective date: 20150225

Ref country code: LT

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

Effective date: 20150225

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

Ref country code: GR

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

Effective date: 20150526

Ref country code: RS

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

Effective date: 20150225

Ref country code: LV

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

Effective date: 20150225

Ref country code: IS

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

Effective date: 20150625

REG Reference to a national code

Ref country code: PL

Ref legal event code: T3

REG Reference to a national code

Ref country code: SK

Ref legal event code: T3

Ref document number: E 18685

Country of ref document: SK

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 4

REG Reference to a national code

Ref country code: HU

Ref legal event code: AG4A

Ref document number: E024444

Country of ref document: HU

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

Ref country code: EE

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

Effective date: 20150225

Ref country code: RO

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

Effective date: 20150225

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502012002338

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20151126

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

Ref country code: LU

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

Effective date: 20150917

Ref country code: MC

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

Effective date: 20150225

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

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

Ref country code: IE

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

Effective date: 20150917

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 5

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

Ref country code: CH

Payment date: 20160920

Year of fee payment: 5

Ref country code: DK

Payment date: 20160920

Year of fee payment: 5

Ref country code: NL

Payment date: 20160920

Year of fee payment: 5

Ref country code: GB

Payment date: 20160920

Year of fee payment: 5

Ref country code: NO

Payment date: 20160922

Year of fee payment: 5

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

Ref country code: PL

Payment date: 20160914

Year of fee payment: 5

Ref country code: SI

Payment date: 20160829

Year of fee payment: 5

Ref country code: SK

Payment date: 20160916

Year of fee payment: 5

Ref country code: HU

Payment date: 20160915

Year of fee payment: 5

Ref country code: PT

Payment date: 20160915

Year of fee payment: 5

Ref country code: CZ

Payment date: 20160916

Year of fee payment: 5

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

Ref country code: BE

Payment date: 20160920

Year of fee payment: 5

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

Ref country code: IT

Payment date: 20160922

Year of fee payment: 5

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

Ref country code: MT

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

Effective date: 20150225

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

Ref country code: BG

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

Effective date: 20150225

Ref country code: SM

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

Effective date: 20150225

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

Ref country code: CY

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

Effective date: 20150225

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 6

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

Ref country code: FR

Payment date: 20170928

Year of fee payment: 6

Ref country code: DE

Payment date: 20170928

Year of fee payment: 6

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

Ref country code: SE

Payment date: 20170921

Year of fee payment: 6

Ref country code: AT

Payment date: 20170922

Year of fee payment: 6

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

Ref country code: ES

Payment date: 20171031

Year of fee payment: 6

REG Reference to a national code

Ref country code: HU

Ref legal event code: HC9C

REG Reference to a national code

Ref country code: DK

Ref legal event code: EBP

Effective date: 20170930

Ref country code: NO

Ref legal event code: MMEP

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

Ref country code: CZ

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

Effective date: 20170917

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: NL

Ref legal event code: MM

Effective date: 20171001

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

Effective date: 20170917

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

Ref country code: PT

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

Effective date: 20180319

REG Reference to a national code

Ref country code: SK

Ref legal event code: MM4A

Ref document number: E 18685

Country of ref document: SK

Effective date: 20170917

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20170930

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

Ref country code: TR

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

Effective date: 20150225

Ref country code: MK

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

Effective date: 20150225

Ref country code: NL

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

Effective date: 20171001

REG Reference to a national code

Ref country code: SI

Ref legal event code: KO00

Effective date: 20180508

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

Ref country code: SK

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

Effective date: 20170917

Ref country code: CH

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

Effective date: 20170930

Ref country code: NO

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

Effective date: 20170930

Ref country code: LI

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

Effective date: 20170930

Ref country code: GB

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

Effective date: 20170917

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

Ref country code: IT

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

Effective date: 20170917

Ref country code: BE

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

Effective date: 20170930

Ref country code: HU

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

Effective date: 20170918

Ref country code: SI

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

Effective date: 20170918

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

Ref country code: AL

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

Effective date: 20150225

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

Ref country code: DK

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

Effective date: 20170930

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502012002338

Country of ref document: DE

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

Ref country code: PL

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

Effective date: 20170917

REG Reference to a national code

Ref country code: SE

Ref legal event code: EUG

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 712539

Country of ref document: AT

Kind code of ref document: T

Effective date: 20180917

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

Ref country code: SE

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

Effective date: 20180918

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

Ref country code: DE

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

Effective date: 20190402

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

Ref country code: FR

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

Effective date: 20180930

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20191030

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

Ref country code: AT

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

Effective date: 20180917

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

Ref country code: ES

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

Effective date: 20180918