NZ614132B - Method for electronically processing a traffic offense and onboard-unit therefor - Google Patents
Method for electronically processing a traffic offense and onboard-unit thereforInfo
- Publication number
- NZ614132B NZ614132B NZ614132A NZ61413213A NZ614132B NZ 614132 B NZ614132 B NZ 614132B NZ 614132 A NZ614132 A NZ 614132A NZ 61413213 A NZ61413213 A NZ 61413213A NZ 614132 B NZ614132 B NZ 614132B
- Authority
- NZ
- New Zealand
- Prior art keywords
- traffic violation
- beacon
- obu
- onboard unit
- parking
- Prior art date
Links
- 230000004044 response Effects 0.000 claims description 18
- 238000004891 communication Methods 0.000 claims description 14
- 150000002500 ions Chemical class 0.000 claims description 7
- 102100004612 PIGP Human genes 0.000 claims description 6
- 108060006224 PIGP Proteins 0.000 claims description 6
- 239000000969 carrier Substances 0.000 claims description 2
- 230000000875 corresponding Effects 0.000 description 9
- 238000010295 mobile communication Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 229910052454 barium strontium titanate Inorganic materials 0.000 description 3
- 238000000034 method Methods 0.000 description 3
- 229920001690 polydopamine Polymers 0.000 description 3
- 238000005259 measurement Methods 0.000 description 2
- 241001622623 Coeliadinae Species 0.000 description 1
- 241000282619 Hylobates lar Species 0.000 description 1
- 230000003466 anti-cipated Effects 0.000 description 1
- 230000001413 cellular Effects 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000002349 favourable Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006011 modification reaction Methods 0.000 description 1
- 230000000576 supplementary Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Abstract
614132 Disclosed is a method for electronically processing a traffic violation of a vehicle (1). The vehicle (1) has an on-board unit (5) which has a transceiver, an input device and an output device. A traffic violation message is transferred from a beacon (7) to the transceiver of the on-board unit (5). The message is then output on the output device and a user selects one of two options via the input device. If the user selection indicates the first option, the traffic violation message is transferred from the on-board unit (5) to a remote central facility. If the user selection indicates the second option, a debit transaction is generated which is related to the traffic violation and the debit transaction is charged against a user account. unit (5). The message is then output on the output device and a user selects one of two options via the input device. If the user selection indicates the first option, the traffic violation message is transferred from the on-board unit (5) to a remote central facility. If the user selection indicates the second option, a debit transaction is generated which is related to the traffic violation and the debit transaction is charged against a user account.
Description
Patents Form 5
NZ. No. 614132
NEW ZEALAND
Patents Act 1953
COMPLETE SPECIFICATION
METHOD FOR ELECTRONICALLY PROCESSING A TRAFFIC OFFENSE AND ONBOARD—
UNIT THEREFOR
We, KAPSCH TRAFFICCOM AG, do hereby declare the invention, for which we pray that a
patent may be granted to us, and the method by which it is to be performed, to be particularly
bed in and by the ing statement:—
Method for Electronically Processing a c Offense and
Onboard—Unit Therefor
The present invention relates to a method for
electronically ssing ea traffic violation of a. vehicle,
which ses an onboard unit having a transceiver, an input
device and an output . The invention further relates to
an onboard unit for carrying out this method.
Onboard. units (OBUs) are electronic devices carried. by
vehicles so as to be able to identify the vehicles in a
wireless the billing tolls
manner, for example for purpose of
in electronic road toll systems. OBUs can be implemented in the
form of active or e radio transponders, radio frequency
identification (RFID) chips, near field ication (NFC)
chips, dedicated short range communication (DSRC) transceivers
for radio or infrared data transmission, wireless access in
vehicular environments (WAVE) and wireless local area network
(WLAN) nodes, or the like. It is the object of the ion to
render such OBUs usable for processing traffic violations such
as speed limit violations, parking time violations or the like.
In a first aspect of the invention, this object is
achieved by a method for electronically processing a traffic
violation of a vehicle, which comprises an onboard unit having
a transceiver, an input device and an output device,
comprising:
transmitting a traffic violation message from a beacon to
the transceiver of the onboard unit and outputting the traffic
3O violation e on the output device of the onboard unit;
accepting a user selection concerning two options via the
input device of the onboard unit;
if the user selection indicates the first option,
transmitting the traffic violation message from. the onboard
unit to a remote central facility;
_ 3 _
if the user selection indicates the second ,
generating a debit transaction related to the traffic violation
and charging the debit transaction against a user account.
The invention allows traffic enforcement officials, such
as law enforcement officers, policemen, parking enforcement
officers, parking space managers and the like, to write a
detected traffic violation, such as a speed limit or parking
time violation, directly to the d unit of the violating
vehicle in the form of an electronic traffic violation message
by a . that is implemented. as a handheld device, for
example, using radio or infrared. The vehicle user es the
violation message on the onboard. unit via voice output or
graphic display and can then decline or accept the violation
via the input device. In the first case, the c violation
e is forwarded. to a central ty for conventional
violation processing, for example so as to print and mail a
penalty notice to the user, who may then also lodge an appeal.
In the second case, if the user accepts the violation, the user
can immediately pay the fine with the aid of the onboard unit
in that the onboard unit generates a corresponding debit
transaction and charges it against a user t or at least
initiates this step.
It shall be noted here that an onboard processing unit is
known from the document US 6,163,277, which, after analyzing
data. received 'via vehicle sensors and. road—side signboards,
detects speeding violations of the vehicle and, with
appropriate ty of the violation, automatically contacts
the police, who can then read out the violation data from the
processing unit. The police officer can then establish separate
3O voice communication with the vehicle driver and offer to have
the vehicle driver pick up the ticket or to have it .
The user selection made by the user can preferably be
med. by entering a PIN code so as to increase system
security; this can prevent unauthorized persons from confirming
or declining a traffic violation, for example.
It is also favorable if a cryptographic signature of the
OBU is transmitted together with the traffic violation message,
and in particular if the OBU signs and/or encrypts the traffic
violation message with a cryptographic signature. Authenticated
data can thus be generated for penalty notices, offering
maximum legal safeguards.
According to a particularly preferred embodiment of the
invention, the user selection can be made in particular by way
of an NFC connection in the input device. For e, a mobile
telephone, hone, PDA, tablet PC or the like having an NFC
chip can be used as the input device (and also as the output
device), and. the user selection can be made by this device
approaching' an. OBU that is integrated. in or mounted. on the
vehicle. In this way, for example, the user selection can be
set to the second option, this being the confirmation of the
violation and generation of a debit transaction, simply by the
device ching the unit.
The actual debit against the user account can take place
in a wide variety of ways, depending on where the user account
is kept. 5, ing to a first ment of the invention,
the user t is kept directly in the onboard. unit, the
onboard unit can also directly generate the debit transaction
and carry out a corresponding debit against the user account.
If an NFC—compatible input device is used, the user t can
also be kept on a data carrier, which is debited by way of such
an NFC connection. For example, one of the above devices, these
being mobile telephone, smartphone or the like, can be used as
the input device, the NFC connection can be established by the
device ching the remaining OBU part and, for example, a
3O payment transaction for the data r can be generated in
this device or sent to the mobile communication network via a
mobile communication connection and the debit transaction can
be charged t a user account there.
If the user account is kept in the central facility, the
onboard unit can, for example, transmit the traffic violation
message together with the user selection to the central
facility, so that the debit transaction is charged there
against the user account. As an alternative, if the user
account is kept in the central facility, the onboard unit can
transmit a completed debit transaction to the central facility,
which is then applied there to the user account.
An advantageous embodiment of the invention is
characterized by the preceding step of transmitting a status of
the onboard unit to the beacon and creating the traffic
violation message in the beacon depending on the received
status. For example, the status of the d unit can relate
to an operating mode of the d unit and/or of the vehicle,
such as standstill or movement, speed, ing mode,
"parking", the readiness to pay a particular parking fee,
claiming a particular priority, for example emergency vehicle,
multi—occupant status for so—called high ncy vehicle
(HOV) lanes, the result of an earlier toll transaction, parking
fee transaction or e inspection or the like. Depending on
the status that is read out from the onboard unit, the
inspecting officer can compile the corresponding c
violation message on the beacon or the beacon can te it
automatically, for example based on its own control
measurements on the vehicle or the OBU, and can write the
ion message to the OBU.
The communication between the beacon and onboard unit
preferably takes place according to the dedicated short range
communication (DSRC) standard, for example the CEN—DSRC
standards using radio or infrared data transmission, ITS—G5,
IEEE 802.11p, wireless local area network (WLAN), wireless
3O access in lar environments (WAVE), radio frequency
identification (RFID), near field communication (NFC), or the
like.
In a second aspect, the invention s an onboard unit
for a vehicle, comprising a eiver, an input device and an
output device, which is configured
to receive a traffic violation message from a beacon and
output it on the output device;
accept a user selection. concerning’ two options via. the
input device;
if the user selection indicates the first option, transmit
the traffic violation message to a remote central facility; or
if the user selection indicates the second option, to
initiate the generation of a debit ction for a user
account related to the traffic ion.
The d unit preferably comprises a stored modifiable
status and is configured to it the status via the
eiver to the beacon in response to a wireless poll. The
onboard unit is particularly preferably configured to keep a
user t and charge the debit transaction against the same.
Reference is made to the above comments regarding the
method in terms of the advantages and characteristics of the
onboard unit according to the invention.
The invention will be described in greater detail
hereafter based on an exemplary embodiment, which is shown in
the accompanying drawings. In the drawings:
shows a schematic overview of the communication of
an onboard unit in the tolling mode with tolling beacons on
their way on a road;
shows a schematic overview of the ication of
onboard units in the parking mode with a parking beacon during
parking;
is a block diagram and is a front view of an
exemplary onboard unit according to the ion;
is a state transition diagram of a part of a method
for generating parking fee transactions that is carried out in
an onboard unit;
is a flow chart of a part of a method for
generating parking fee transactions that is carried out in a
parking beacon;
is a schematic illustration of a road traffic
check, during the course of which a part of the method
according to the invention is carried out; and
shows the method of the invention in the form of
the signal flows between the components ed in the method.
In a vehicle 1 is moving on a road 2 at a speed
and in a driving direction 3, and in several vehicles 1
are parked in each case in a parking space 4 of the road 2. The
road 2 can be any arbitrary traffic or g area, for
example an expressway, a highway or an entire road system in
or a shoulder, a large parking space or‘ a parking
garage in all of these are ered to be covered by
the general concept of "road" 2.
Each of the vehicles 1 is equipped with an onboard unit
(OBU) 5, which is able to carry out wireless communication 8
with roadside beacons (roadside units, RSUs) 6, 7. The OBUs 5
can be te devices or an al part of the vehicle
electronics systemd The communication 8 is short range or
dedicated short range communication (DSRC), preferably
2O according to the CEN—DSRC standards using radio or infrared
data transmission, ITS—G5, IEEE 802.11p, WAVE, WLAN, RFID, NFC
or the like. The beacons 6, 7 thus have a respective locally
delimited radio or infrared coverage range 9, 10.
FIGS. 1 and 2 show two different types of beacons 6, 7 and
application scenarios of the described components. The beacons
6 of are ng" beacons ng roadside units, T—
RSUs) that are set up in a geographically distributed manner
along the road 2. With the aid of periodically broadcast polls
11, the tolling beacons 6 request all passing OBUs 5 to
3O ish communication 8, as is illustrated based on the
exemplary response 12. So as not to "miss" any g OBU 5
due to the potentially high speed of the vehicle 1, the polls
ll of the tolling beacons 6 are broadcast at relatively short
intervals, for example every 100 ms or less. For the polls ll,
for example, led wave service announcement (WSA) messages
are used in the WAVE standard, and so—called beacon service
table (BST) messages are used in the CEN—DSRC standard.
Successful ication 8 with a passing OBU 5
demonstrates that the OBU 5 is located in the locally delimited
coverage range 9 of the tolling beacon 6, whereby a fee
("toll") can be charged. for usage of the location of the
tolling beacon 6. For example, the tolled location usage can be
the driving (n1 a road section, the entering of aa particular
territory ("city toll") or the like.
In contrast, ng" beacons (parking roadside units, P—
RSUS) 7 are employed in the g scenario of which
use a poll 11, for example a WSA or BST message, to request all
the OBUs 5 located in the coverage range 10 to e response
messages 12 so as to charge a fee for the usage of the parking
spaces 4, as will be described in greater detail hereafter. To
this end, a parking beacon 7 may be in charge of one or more
parking spaces 4, which together form a parking area P.
Because parked vehicles 1 are stopped, a parking beacon 7
can broadcast its polls 11 at considerably longer time
intervals AT than the tolling beacon 6 of for example
every 10 minutes, which also defines the time resolution of the
parking time billing.
The coverage range 10 of the parking beacon 7 can be
adapted to the spatial expansion of the parking spaces 4 using
optional measures, for example directional antennas, so as to
avoid responses 12 of OBUs 5 of es 1 that are not parked,
for example passing vehicles. As an alternative or in on,
the OBUs 5 of the vehicles 1 can also be caused. to assume
different operating modes, which are d in each case to
3O the scenarios of FIGS. 1 and 2, and more particularly a first
toll ing" mode ng‘ mode, TM) for responses 12 to
polls 11 from tolling beacons 6, and a second parking operating
mode (parking' mode, PM) for responses 12 to polls 11 from
parking beacons 7. In the polls 11, the beacons 6, 7 can
optionally broadcast a respective beacon identifier, which
_ g _
indicates whether it is a tolling beacon 6 or a parking beacon
7. The beacon identifier can, for example, be indicated as a
service of the beacon as part of a WSA or BST message.
Of course, the tolling beacons 6 and parking beacons 7 can
also be implemented by one and the same physical unit, which
alternately or simultaneously performs the functions of a
tolling beacon and a g beacon 6, 7. Such a combined unit
6, 7 can thus ast polls 11 with the beacon identifier of
a g beacon, for example continually at short intervals,
and polls ll with the beacon identifier of a parking beacon 7
at longer intervals AT, which is to say onally
"interspersed". Such a beacon 6, 7 is then in charge of both
charging a toll for a road section of the road 2 and charging a
fee for a parking area P, for e.
Depending on the operating mode TM or PM of the OBU 5, and
depending on the received beacon identifier, the OBU 5 can, for
example, respond only to tolling beacons 6 if the OBU is in the
tolling mode TM or only to g beacons 7 if the OBU is in
the parking mode PM.
The operating mode of an OBU 5 can further be encoded as a
data the
message (status) st and transmitted as part of
response 12. A. beacon 6, 7 can appropriately evaluate the
status st received in a response 12, so that tolling beacons 6
only charge tolls for the passage of OBUs 5 where status st =
TM, and parking beacons 7 only Charge fees for the parking of
those OBUs 5 where status st = PM. Moreover, the OBUs 5 can
also measure their own respective positions p and. transmit
these to the parking' beacons 7, which. compare the received
positions p to the respective parking areas P and only charge
3O fees for the g of those OBUs 5, the ons p of which
are within the respective parking area P. This will be
described in more detail hereafter with reference to FIGS. 3 to
shows an ary block diagram, shows an
exemplary outside view, and shows an exemplary state
_ 10 _
transition diagram of an OBU 5, which can be switched between
(at least) two operating modes TM and PM in accordance with the
ation scenarios of FIGS. 1 and 2. According to to
this end an OBU’ 5 comprises a transceiver 13 (for example
according to one 0: said DSRC standards) for carrying out the
ication 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
implemented in a manner that differs from the shown keyboard
and. monitor output, for example by way of voice input and
output, sensor systems, advisory tones and the like. The input
and. output s 16, 17 can also be formed. by’ physically
te components such. as car radios, navigation devices,
smartphones, PDAs, tablets and the like and can be connected to
the microprocessor 14 by wire or ssly, for example by way
of NFC, Bluetooth®, WLAN or infrared.
The OBU 5 can optionally also comprise a nt sensor
18, for example in the form of a satellite navigation receiver
for a global navigation satellite system (GNSS), such as GPS,
GLONASS, GALILEO and the like; instead of a GNSS receiver, it
is also possible to use any other type of movement sensor 18,
for example an a sensor (inertial measurement unit, IMU)
or a sensor that is connected to components of the vehicle 1,
for example a connection to the speedometer or engine of the
e 1.
In the st case, the movement sensor 18 can also be
only a connection to the vehicle electronics system, for
example the ignition lock of the vehicle, so that the position
of the key (engine running — not running), for example,
3O indicates the (anticipated) movement or parking status of the
vehicle.
The OBU 5 can optionally also be equipped with a position
determination device 18', which is able to ine the
current position p of the OBU 5 — in response to a poll,
periodically or continuously. The position determination device
_ 11 _
18' can operate in any manner that is known in the art, for
example by way of radio triangulation in a k 0;
geographically distributed radio stations, which can be formed
directly by the beacons 6, 7 or by base stations of a mobile
communication network, for example, or by way of evaluation of
the cell identifiers of a cellular mobile communication
network, and the like. The position ination device 18' is
preferably a satellite navigation receiver for position
determination in a GNSS and in particular can also be formed by
the same GNSS receiver that is used for the movement sensor 18.
In addition. to the riate application. and control
and data, the memory 15 of the OBU 5 includes
programs a unique
identifier id of the OBU 5, which is established and saved, for
example, during the output or user—specific lization of
the OBU 5 and which ly identifies the OBU 5 and/or the
user thereof and/or the vehicle 1 and/or a settlement account
of the user. The OBU identifier id is transmitted together with
12 from the OBU 5 to a beacon 6, 7
every se message so as
to uniquely identify the OBU 5 with respect to the beacon 6, 7.
The memory 15 can further include the status st, which
indicates the operating mode TM or PM of the OBU 5 for the
corresponding scenario of or 2. The status st can be
modified. or adjusted. both. depending' on a Inovement (or non—
movement) of the OBU 5 measured by the movement sensor 18 or by
a user selection via the input device 16. For this purpose, the
input device 16 may, for example, comprise a lockable button
16' (, which is labeled "PM" for "parking mode" PM and
switches the OBU 5 to the parking' mode PM. by pressing‘ and
g and set the status st to the value "PM". The OBU 5 is
3O reset to the tolling mode TM and the status st is set to the
value "TM" by releasing or unlocking the button 16'. The output
device 17 can optionally output appropriate advisory and/or
confirmation messages.
shows several of the possible operating states of
the OBU 5 again in detail in the form of a state transition
_ 12 _
diagram. The OBU 5 can be switched from the tolling mode TM
into the parking mode PM by pressing the button 16' and/or if
the movement sensor 18 ines no movement of the OBU 5 over
a minimum time period for 5 s, for example. The OBU can
be set from the parking mode PM back to the tolling mode TM by
releasing the button 16' and/or by a Hmvement of the OBU 5
detected by the movement sensor 18.
In the parking mode PM, the OBU 5 can temporarily assume a
power—saving' sleep mode ("sleep"), and. more particularly as
soon as it has received a poll 11 from a parking beacon 7 and
sent a response 12. The OBU 5 can also wake up from the sleep
mode after a predetermined time period At has lapsed and return
to the parking' mode PM. The time period At is preferably
shorter than the time period At n consecutive wireless
polls 11 of a g beacon 7. As an alternative or in
addition, the OBU 5 could also be awakened again by receiving a
subsequent wireless poll 11.
shows the method for generating parking fee
transactions in the application scenario of that is
being carried out in a parking beacon 7 in cooperation with the
OBU 5 of FIGS. 3 to 5.
In a first step 19, a poll 11 is broadcast by the parking
beacon 7 so as to request the OBUs 5 located in the coverage
range 10 to provide responses 12. In step 20, the responses 12
ng from the OBUs 5 are received, n each response 12
includes at least the respective identifier idi of the OBU 5
with. the index i. and ‘-
—— ally the status sti f
and/or the position pi thereof determined by the position
determination device 18'. The received identifiers idh
3O statuses sti and positions pi are temporarily stored in the
parking beacon 7 as a current dataset setmmr.
Thereafter, a check is carried out within a loop 21
covering all received identifiers idi as to whether or not the
respective status sti is set to the parking' mode "PM", see
decision 22. In addition (or as an alternative), it can be
_ 13 _
checked in the decision 22 whether or not the tive
position pi -
— provided this was transmitted falls within a
predetermined geographical region, more particularly the
parking area P of the g beacon 7. If only some of the
conditions that are checked in decision 22 are met (branch "n"
of 22), the subsequent steps 23 and 24 are d and the loop
21 is continued, or exited for step 25 upon completion. In
contrast, if all the conditions are met, which is to say in the
present case: sti = PM and pi e P (branch "y" of 22), it is
checked in a further decision 23 whether the respective
identifier idi corresponds to a previously stored "old"
identifier idLlwt/ which is to say whether or not it occurs in
a dataset setlfit{idLlfit} of old identifiers idLlflt. These "old"
identifiers idLlfit were determined during an earlier execution
of the Hethod and stored in the dataset setmm” as will be
described hereafter.
If the respective current identifier idi does not agree
with any old identifier idLlfit, which is to say does not occur
in the t setlmm (branch "n" of 23), the loop 21 is
continued or exited for step 25 after it is completed; if there
is agreement (branch "y" of 23), the method branches to step
24, in which a parking fee transaction ta(idi) is generated for
the current identifier idi, as will described in r detail
later.
After step 24, the loop 21 is continued or, after
completion thereof, a transition is made to step 25.
In step 25, the current identifiers idi ined in step
are resaved as "old" identifiers idlem, which is to say the
t dataset setcurr is (now) stored. as an "old" dataset
3O setiast -
Thereafter, in step 26, a wait is carried. out for the
ined. time period. AT, which. is between the individual
polls 11 of the parking' beacon 7, and then the method is
repeated (loop 27).
_ 14 _
During the next repetition in the loop 27, the usly
determined current fiers idi now* constitute the "old"
identifiers idiJa“, and. if in step 20 again "new" current
identifiers idi are determined, these can then be compared in
step 23 to the "old" identifiers idLlfit from the last dataset
setlfit. As a result, it is Checked during each loop execution
27 whether or not an OBU identifier idi determined by a parking
beacon 7 based on a poll 11 was already present during a poll
11 dating' back by the time period. AT; if so, a vehicle 1
comprising an OBU 5 having this identifier has sly spent
at least the time period AT in the coverage range 10 of the
parking beacon 7, so that a corresponding parking fee
transaction ta(idi) can be generated for the OBU identifier idi
for parking over the time period AT (step 24).
The parking fee ctions ta(idi) generated in step 24
can be settled directly by the beacon 7, for example by
charging these to a user account that is kept in the beacon 7.
Alternatively, the parking fee transactions ta(idi) can be
forwarded by the beacon 7 to a remote central ty (not
shown), which keeps user accounts, toll accounts, bank
accounts, credit accounts and the like under the identifiers
idi, so that the parking fee transactions ta(idi) can be
charged there against a corresponding ment account.
However, it is also possible for the ted. parking' fee
transaction(s) ta(idi) to be returned from the beacon 7 to the
OBU 5 with the fier idi and to be charged there against a
settlement account (an "electronic ) that is kept in the
OBU 5.
Another option is to temporarily store the parking' fee
3O transaction(s) ta(idi) returned from the parking beacon 7 to
the OBU 5 in the OBU 5 and, when the OBU 5 returns to the
tolling" mode TM, have the OBU 5 send. it/then1 to a tolling
beacon 6 on the way for settlement purposes, as if it were a
toll transaction. shows a corresponding operating mode
"post ta", which the OBU 5 temporarily assumes after returning
_l5_
fron1 the parking mode PM and in which it awaits the next
tolling beacon 6 on the way, so as to deliver the parking fee
transaction(s) ta(idi) to the same, whereupon. the OBU again
returns to the "normal" tolling mode TM.
The procedures shown in can, of course, be
appropriately modified according to programming methods known
to a person skilled in the art. For example, the decision 22
could be eliminated or included in step 20, and it could be
chcckcd whether the status sti of an identifier idi is set to
"PM" and/or the position pi of an identifier idi falls in the
area P, wherein then only those identifiers idi, where status
sti = "PM" or position pi E P, are stored as current
identifiers in the current t setmmr. The loop 21 could
also be implemented differently and, for example, steps 22 to
24 or 23 to 24 could be d out immediately after receipt
of a response 12 for an identifier idi if this takes place so
quickly in terms of data processing that this can be done
between consecutively arriving responses 12. It should be noted
in this regard. that, according' to some DSRC standards, the
responses 12 of several OBUs 15 replying to one common wireless
poll 11 are variably spread over time so as to prevent
collisions of ses 12, whereby sufficient time can remain
between dual ses 12 for steps 22 to 24 or 23 to 24.
A g beacon 7, the coverage range 10 of which covers
several parking spaces 4, at the same time receives a complete
overview of the occupancy status of the parking spaces 4 in its
parking area P as a result of the responses 12 of the OBUs 5 in
step 20. For this purpose, the beacon only needs to compare the
number of identifiers idi received in step 20 to the number of
3O parking spaces 4 in the area P, so as to obtain a proportional
or percentage—based ation rate of the parking spaces 4,
for example "80%" if 4 out of 5 parking spaces are occupied,
and so forth. The parking space occupancy status thus
determined can be sent to a central facility for parking area
management es, for example.
_ 16 _
shows a first part of the method for electronically
processing traffic violations based on a control io, in
which a control person 31 checks a vehicle 1 comprising the OBU
thereof with the aid of a transportable beacon 32, which is
implemented as a handheld device, for example. In the example
shown, the vehicle 1 is parked. in a parking space 4. The
parking mode PM was set by the user in the OBU 5, which is to
say the status st in the memory 15 of the OBU 5 is accordingly
set to "PM". With the aid of the OBU 5 and one of the bed
parking s 7, for example, corresponding parking fee
ctions ta are generated, as was described based on FIGS.
1 to 6.
The control person 31 now carries out a road traffic check
with the aid of the beacon 32. In the illustrated example, this
person checks the correct setting of the parking mode PM in the
OBU 5.
As is shown in for this purpose in a first step 33
the identifier id and (optionally) the status st of the OBU 5
of the checked vehicle 1 are read out into the beacon 32 via a
2O communication 8. Optionally, additional data such as the
starting time t1 of a parking process (time at which the
parking mode PM is entered), the maximum d parking
duration at this location in the form of a time window or an
allowed ending time t2, one or more of the last parking fee
transactions taifit processed in the OBU 5, traffic violation
es that were previously stored in the OBU 5 or the like,
can also be read out.
Depending on the information received in the beacon 32,
for example whether the status st in a parking space 4 was set
correctly to "PM" by the user, a traffic violation message rec
is compiled in a step 34 based on a visual comparison by the
control person 31 — or also in a partially or entirely
automated fashion directly by the beacon 32, if it has
appropriate sensors. If the beacon 32 carries out step 34
mously, instead of being a handheld device, it can also
_ l7 _
be set up in a stationary manner, for e, or carried by a
patrol vehicle. It is also possible for the beacon 32 to be
implemented in the form of one of the beacons 6 or 7 and to
generate traffic violation messages rec, for example in the
case of speed limit violations, g time violations in a
short—term parking zone or pping zones with time limits
and the like.
Thereafter, in a step 35, the traffic violation message
rec is transmitted in a communication 8 to the OBU 5, where the
message is output on the output device 17 to the user of the
e 1, for example via voice output or graphic display.
Using’ the input device 16, for example voice input or the
keyboard, the user of the vehicle 1 can now accept ("y"), or
not accept ("n"), the traffic violation for payment and make a
corresponding user selection y/n. On a supplementary basis, in
the case of acceptance "y", additionally' a PIN code may’ be
requested to be entered so as to further se the payment
security, for example so as to prevent third—party selection in
the case of open convertibles or by vehicle users in rental
cars who are not authorized to access the t.
For example, if the input and output devices l6, 17 are
configured as a smartphone with an NFC connection, the
violation can be accepted and a payment process can be
red simply by the smartphone approaching the processor
part of the OBU 5.
In a step 36 then, the user selection y/n is transmitted
via the eiver l3 — or another transceiver of the OBU 5,
for example a mobile communication module or via WAVE/LAN
access of the buted beacons — to a remote central
3O facility 37 together with the traffic violation message rec and
the identifier id of the OBU 5. The l facility 37 can
take on any arbitrary form, for example a central facility of a
road toll system, parking fee billing system, a bank computer,
a credit card account processor and the like, which is
connected wirelessLy or by wire to one of the beacons 6, 7
_ l8 _
and/or 32. The central ty 37 can even be directly
implemented by one of the beacons 6, 7 or 32.
If the user selection y/n related to the declination of
the indicated traffic violation ("n"), in a step 38 thereafter
a "conventional" ticket 39 is created from the traffic
violation message ), for example it is printed out and
mailed to the user of the e 1 together a notice of the
legal es that are available.
During the transmission of the user selection y/n in step
30, the authenticity of the user can optionally be checked by
additionally transmitting a cryptographic OBU signature that is
stored in the OBU 5 and/or the OBU 5 can sign and/or encrypt
the user selection y/n and/or the traffic violation message
rec(id) with the OBU signature and/or an OBU key. In this way,
ts of the user interaction that hold up in court can be
generated.
If the user selection y/n related to the acceptance of the
traffic violation ("y"), in step 40 a debit transaction ta(id)
is generated from the traffic violation message ) and
charged against a user account 41, for example by debiting the
user account 41 with a fine indicated in the traffic ion
message rec(id). Alternatively or additionally, in step 42 the
debit transaction ta(id) can also be returned to the OBU 5 via
a communication 8 and d there against a user account (an
"electronic ") kept directly in the OBU 5. The user
account 41 could also be kept in a part of the input and output
device 16, 17, for example if the same is implemented by a
mobile terminal such as mobile telephone, smartphone, PDA,
tablet PC or the like connected wirelessly, for example via
3O NFC, Bluetooth® or the like. In this case, the OBU 5 can be
programmed so that an appropriate message is sent to this
wirelessly connected part of the input and output device 16, 17
for debiting the user account 41 and there, for example, a user
account 41 in this terminal is debited or the debit transaction
_ 19 _
ta(id) is forwarded by the , for example to a billing
center of a mobile communication network.
Alternatively, it is possible for the debit transaction
ta(id) to be generated directly in the OBU 5 from the c
violation message rec(id) and charged t a user account 41
kept in the OBU 5, in which case step 36, this being’ the
forwarding of the traffic violation message rec(id), only
becomes necessary if the traffic violation is declined ("n");
or a debit transaction ta (id) that is directly generated in
the OBU 5 is transmitted to the central facility 37 for
processing in step 36 — instead of the violation message
If after an extended period, for example one month, the
user has not entered a user selection y/n, the user selection
y/n can be set to a predetermined value directly by the OBU 5
and can be r processed accordingly. The user selection is
then ably set to the value "n" so as to not to debit an
incorrect account or cause an early expiration of a deadline in
the case of a ticket.
After the user selection y/n has been entered into the OBU
, the traffic violation message rec(id) in the OBU 5 is
deleted or marked as processed.
The invention is not limited to the shown embodiments, but
encompasses all variants and modifications that are covered by
the scope of the accompanying claims.
_ 20 _
Claims (13)
1. A method for electronically processing a traffic violation of a le which has an onboard. unit having a transceiver, an input device and an output device, comprising: transmitting a traffic violation message from a beacon to the transceiver of the onboard unit and outputting the traffic violation message on the output device of the onboard unit; accepting a user selection d to two options via the 10 input device of the onboard unit; if the user selection indicates the first option, transmitting the traffic violation e fron1 the onboard unit to a remote l facility; if the user selection indicates the second option, 15 generating a debit transaction related to the traffic violation and charging the debit transaction against a user account.
2. The method. according to clainl 1, characterized in that the user selection must be confirmed by entering a PIN code. 20
3. The method according to claim 1 or 2, characterized in that a graphic ure of the onboard unit is transmitted together with the traffic violation message.
4. The method according 1x3 any (MKB of claims 1. to 3, characterized in that the onboard unit signs and/or encrypts 25 the traffic violation message with a cryptographic signature.
5. The method ing 11) any (MME of claims 1. to 4, characterized in that the user selection takes place by way of an NFC tion in the input .
6. The method according to any one of claims 1 to 5, 3O characterized in that the user account is kept in the onboard unit and. the debit transaction is generated. in the onboard unit.
7. The method according ix) any one (If claims 1. to 5, characterized in that the user account is kept on a data 35 carrier, which is debited via an NFC connection. .21_
8. The method according to any one of claims 1 to 5, characterized in that the user account is kept in the central facility, and the traffic violation message is transmitted together with the user selection to the central facility, where. the debit transaction is generated.
9. The method according to any one of claims 1 to 5, characterized in that the user account is kept in the l ty and the debit transaction is generated in the onboard unit and transmitted to the central facility.
10 10. The method according to any one of claims 1 to 9, characterized. by the step of transmitting' a status of the onboard unit to the beacon and creating the traffic ion message in the beacon depending on the received status.
11. The method according to any one of claims 1 to 10, 15 characterized in that the communication between the beacon and the onboard unit takes place according to the DSRC standard.
12. An onboard unit for a vehicle, comprising a transceiver, an input device and an output device, characterized in that the d unit is ured: 20 to receive a traffic violation e from a beacon and output it on the output device; to accept a user ion concerning two options via the input device; if the user selection indicates the first option, to 25 transmit the traffic violation message to a remote central facility; or if the user selection tes the second option, to initiate the generation of a debit transaction for a user account related to the traffic violation. 3O
13. The d unit according to claim 12, characterized by comprising a stored modifiable status and being configured to transmit the status via the transceiver to the beacon in response to a wireless poll.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP12184677.8 | 2012-09-17 |
Publications (1)
Publication Number | Publication Date |
---|---|
NZ614132B true NZ614132B (en) | 2014-01-28 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2013216638B2 (en) | Method for electronically processing a traffic offence and onboard-unit therefor | |
CN108701377B (en) | Vehicle parking and mass transit beacon system | |
US9373197B2 (en) | Methods and systems for electronic payment for on-street parking | |
US5767505A (en) | Method and system for determining toll charges for traffic routes and/or areas | |
US8634804B2 (en) | Devices, systems and methods for location based billing | |
US9996831B2 (en) | Mobile wireless payment and access | |
RU2390846C2 (en) | Passenger transportation system and ticketing method for said system | |
US8026832B2 (en) | Mobile system for exacting parking tolls | |
US11443397B2 (en) | Method and apparatus for sharing toll charges among several toll service subscribers | |
EP2854110A2 (en) | Vehicle mountable unit and road toll system | |
US20140081718A1 (en) | Method, radio beacon and onboard unit for generating parking fee transactions | |
JP2003526854A (en) | Automatic billing system for fees | |
CN103337022A (en) | A public transport electronic system | |
US20100287621A1 (en) | Method For The Use-Specific Initialization Of Vehicle Devices | |
JP2002506541A (en) | Parking management system | |
KR20090018129A (en) | Toll collection system | |
EP1805718B1 (en) | Wireless toll collection system | |
Porter et al. | An RFID-enabled road pricing system for transportation | |
CN107038762A (en) | Method of work and system based on the trip management and control of Big Dipper space-time data | |
CN201887799U (en) | Vehicle-mounted information service terminal and real-time payment system thereof | |
NZ614132B (en) | Method for electronically processing a traffic offense and onboard-unit therefor | |
Patil et al. | Smart Toll Booth System Using Smart Contract | |
JP2003044889A (en) | On-vehicle terminal equipment and toll reception system | |
KR20070040031A (en) | System and method for payment using of telematics terminal | |
JP2004326230A (en) | Settlement system |