U.S. patent application number 10/058591 was filed with the patent office on 2002-10-03 for vehicle trip determination system and method.
Invention is credited to Kavner, Douglas M..
Application Number | 20020140579 10/058591 |
Document ID | / |
Family ID | 26950537 |
Filed Date | 2002-10-03 |
United States Patent
Application |
20020140579 |
Kind Code |
A1 |
Kavner, Douglas M. |
October 3, 2002 |
Vehicle trip determination system and method
Abstract
A method for determining a vehicle trip on a roadway includes
providing a plurality of vehicle detections from a plurality of
gateways, determining a maximum travel time between corresponding
pairs of the plurality of gateways, correlating corresponding pairs
of the plurality of vehicle detections by determining that a travel
time between each of the gateways of each of the corresponding
pairs of detections is less than a corresponding maximum travel
time, determining a plurality of chainable detections, and
determining the boundaries of the trip.
Inventors: |
Kavner, Douglas M.; (Orange,
CA) |
Correspondence
Address: |
DALY, CROWLEY & MOFFORD, LLP
SUITE 101
275 TURNPIKE STREET
CANTON
MA
02021-2310
US
|
Family ID: |
26950537 |
Appl. No.: |
10/058591 |
Filed: |
January 28, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60264498 |
Jan 26, 2001 |
|
|
|
60264424 |
Jan 26, 2001 |
|
|
|
Current U.S.
Class: |
340/988 ;
340/928; 340/933 |
Current CPC
Class: |
G07B 15/063 20130101;
G08G 1/017 20130101; G07B 15/06 20130101 |
Class at
Publication: |
340/988 ;
340/928; 340/933 |
International
Class: |
G08G 001/123 |
Claims
What is claimed is:
1. A method for determining a vehicle trip on a roadway, the method
comprising: providing a plurality of vehicle detections from a
plurality of gateways; determining a maximum travel time between
corresponding pairs of the plurality of gateways; correlating
corresponding pairs of the plurality of vehicle detections by
determining that a travel time between each of the gateways of each
of the corresponding pairs of detections is less than a
corresponding maximum travel time; determining a plurality of
chainable detections; and determining the boundaries of the
trip.
2. The method of claim 1 wherein providing the plurality of vehicle
detections comprises providing at least one license plate image
corresponding to one of the plurality of vehicle detections.
3. The method of claim 2 further comprising: determining a vehicle
license plate number; and processing the at least one license plate
image for verifying the vehicle license plate number
4. The method of claim 1 wherein providing the plurality of vehicle
detections comprises filtering a plurality of vehicle transactions
for providing the plurality of vehicle detections.
5. The method of claim 4 wherein the plurality of vehicle
transactions includes at least one ambiguous transaction; and
further comprising eliminating at least one ambiguous transaction
from the plurality of vehicle transactions.
6. The method of claim 5 wherein the at least one ambiguous
transaction includes a conflicting gateway crossing.
7. The method of claim 4 further comprising eliminating dual
transactions from the plurality of vehicle detections.
8. The method of claim 1 wherein correlating the corresponding pair
of the plurality of vehicle detections further comprises
determining whether each of the pair of detections is provided by a
corresponding pair of gateways that are disposed logically
consistent with the roadway topology.
9. The method of claim 1 wherein correlating the corresponding pair
of the plurality of vehicle detections further comprises
determining that the travel time between each of the detections is
greater than a minimum travel time.
10. The method of claim 1 wherein determining a maximum travel time
comprises determining an incident free maximum travel time.
11. The method of claim 10 further comprising: determining an
expected travel time; and determining that the maximum travel time
is the longer of the expected travel time and the incident free
maximum travel time.
12. The method of claim 11 further comprising: detecting a traffic
incident; and modifying the expected travel time in response to the
traffic incident.
13. The method of claim 1 further comprising waiting for the
plurality of chainable detections to be initially processed.
14. The method of claim 1 further comprising waiting for the
plurality of chainable detections to be verified.
15. The method of claim 13 further comprising determining a latest
time for the plurality of detections.
16. The method of claim 1 wherein determining the boundaries
comprises detecting the end of the trip.
17. The method of claim 16 wherein detecting the end of the trip
comprises: determining a maximum detection time for the plurality
of chainable detections; determining a current boundary time;
comparing the current boundary time to the maximum detection time;
and declaring the end of the trip in response to determining that
the current boundary time is greater than the maximum detection
time.
18. The method of claim 1 wherein determining the boundaries
comprises detecting the start of the trip.
19. The method of claim 1 further comprising forming the trip by
chaining the plurality of chainable detections.
20. The method of claim 1 further comprising waiting for the
plurality of chainable detections.
21. The method of claim 20 wherein waiting for all detections that
might chain comprises: determining a first time wherein each of the
plurality of chainable detections has a first extrapolation region
terminating earlier than the first time.
22. The method of claim 21 further comprising: determining a second
time wherein each of the plurality of chainable detections
occurring later than the first time has a second extrapolation
region terminating earlier than the second time, is evaluated for
verifying.
23. The method of claim 22 verifying transactions occurring between
the first time interval and the second interval time using a video
image of a license plate number captured at the time of the
detection.
24. The method of claim 22 wherein verifying transactions comprises
automatically recognizing the license plate number from the
image.
25. The method of claim 22 wherein verifying transactions comprises
manually reading the license plate number from the image.
26. The method of claim 1 wherein the plurality of vehicle
transactions is provided by at least one of: an enforcement
gateway; and a toll gateway sensor.
27. The method of claim 1 wherein each of the plurality of vehicle
detections comprises: a time of the detection; and the location of
the detection.
28. The method of claim 1 wherein determining the boundaries of the
trip comprises using at least one of: a traffic incident; and a set
of billing policies.
29. A method for determining a vehicle trip on a roadway having a
plurality of gateways disposed according to a roadway topology, the
method comprising: providing a model of the topology including
gateway connectivity, a plurality of minimum travel times between
pairs of gateways, and a plurality of incident free maximum travel
times between pairs of gateways; providing a plurality of vehicle
detections; providing a set of rules for applying the model;
correlating the plurality of vehicle detections by applying the
rules to the plurality of vehicle detections; and determining a
plurality of chainable vehicle detections forming the trip.
30. The method of claim 29 further comprising determining a
plurality of expected travel times between the pairs of
gateways.
31. The method of claim 30 further comprising chaining the
plurality of chainable vehicle detections for forming a potential
trip.
32. The method of claim 31 further comprising verifying a license
plate reading corresponding to at least one of the plurality of
chainable vehicle detections.
33. The method of claim 32 further comprising waiting for required
verification of at least one of the plurality of chainable vehicle
detections in the potential trip; and chaining the plurality of
chainable vehicle detections to form the trip.
34. A toll collection system comprising: a plurality of gateways; a
trip determination processor comprising: a transaction processor; a
vehicle detection correlation processor coupled to the transaction
processor; a transaction filter processor coupled to the vehicle
detection correlation processor; an end of a trip detection
processor coupled to the transaction filter processor; a start of a
trip detection processor coupled to the transaction filter
processor; and a trip formation processor coupled to the
transaction filter processor, the end of a trip detection
processor, and the start of a trip detection processor.
35. The system of claim 34 wherein the plurality of gateway is
adapted for an open ticket tolling system.
36. The system of claim 34 wherein the plurality of gateway is
adapted for a closed ticket tolling system.
37. The system of claim 34 wherein the plurality of gateway is
adapted for an open ticket enforcement system.
38. The system of claim 34 wherein the plurality of gateway is
adapted for a mixed open ticket, closed ticket tolling system.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 60/264,498 filed on Jan. 26, 2001, and U.S.
Provisional Application No. 60/264,424 filed on Jan. 26, 2001, each
of which is incorporated herein in its entirety.
FIELD OF THE INVENTION
[0002] This invention relates generally to toll collection systems
and more particularly to a system and method to determine vehicle
trips in a tolling system.
BACKGROUND OF THE INVENTION
[0003] In electronic or automatic toll collection applications, it
is desirable to correctly identify a vehicle traveling on the
roadway and to determine the path of the vehicle on the toll
roadway for billing purposes. Furthermore, vehicles are identified
by vehicle transponders which are read by automatic vehicle
identification (AVI) readers located along a roadway or at toll
collection stations. Automatic toll collection systems also
identify vehicles by reading license plate numbers. License plate
reading systems include cameras which capture license plate images
that are subsequently read by an automatic optical character
recognition (OCR) processors and manually read by human operators
to provide license plate numbers. Both the transponder system and
license plate reading system are subject to errors which degrade
performance and reduce revenues of the toll collection system.
[0004] In an open ticket toll collection system (also referred to
as an open-road, no lane barrier system), toll gateways are placed
along the mainline roadways as opposed to a closed ticket system
which includes toll gateways at the roadway entry and exit points.
Open ticket systems are desirable due to reduced infrastructure
requirements, but it is difficult to determine when vehicles
actually enter and exit the roadway since there is no positive
confirmation of these events. As a result, it is not possible to
bill vehicles on a trip basis or develop a traffic model of how
vehicles are actually using the roadways.
[0005] One conventional solution has been to bill a set amount for
each toll gateway crossed. While simple, this approach cannot
support trip based billing which is desirable for many reasons
including: (1) support for minimum and/or maximum trip charges; (2)
simplified statements; (3) accurate traffic models; and (4)
reducing losses from non-functional tolling equipment.
[0006] Conventional systems use a combination of electronic and
manual toll collection and the system operators have chosen to
treat the electronic portion merely as a convenience, (e.g. `fast
lanes" or "express lanes" to allow drivers to bypass manual toll
booths). These conventional systems automate existing manual
systems and keep the same rules that apply to the manual system
rather than attempt true trip based billing.
[0007] In complicated automatic toll collection systems, there is a
high probability that a system data error will produce incorrect
billing information. The automatic toll collection system is also
subject to toll evasion by several means including stolen or
improperly used transponders and license plates. In typical
automatic toll systems, incorrect identification of a vehicle or
non- identification of a vehicle is costly. In conventional systems
the error rate ranges from two percent to ten percent. An error in
a license plate reading results in lost revenue, increased customer
support expenses and customer dissatisfaction when a customer is
incorrectly billed. When a vehicle identification cannot be made
either by a transponder or license plate reading, the toll revenue
is not collected.
[0008] It would, therefore, be desirable to provide a reliable trip
determination system in an open ticket toll collection system and
combined open ticket and closed ticket system to support trip based
billing. It would be further desirable to provide a method to
determine system malfunctions and to identify possible toll
evaders.
SUMMARY OF THE INVENTION
[0009] In accordance with one aspect of the present invention, a
toll collection system includes a plurality of gateways and a trip
determination processor. The trip determination processor includes
a transaction processor, a vehicle detection correlation processor
coupled to the transaction processor, a transaction filter
processor coupled to the vehicle detection correlation processor,
an end of a trip detection processor coupled to the transaction
filter processor, a start of a trip detection processor coupled to
the transaction filter processor, and a trip formation processor
coupled to the transaction filter processor, the end of a trip
detection processor, and the start of a trip detection processor.
With such an arrangement, the system automatically determines
vehicle trips, reduces the number of manual reads, and supports
trip based billing, in an open ticket toll collection system, an
open ticket tolling enforcement system, a complex closed ticket
system involving a network of roads or a combination open/closed
ticket system.
[0010] In accordance with a further aspect of the present
invention, a method is provided for determining a vehicle trip on a
roadway including providing a plurality of vehicle detections from
a plurality of gateways, determining a maximum travel time between
corresponding pairs of the plurality of gateways, correlating
corresponding pairs of the plurality of vehicle detections by
determining that a travel time between each of the gateways of each
of the corresponding pairs of detections is less than a
corresponding maximum travel time, determining a plurality of
chainable detections, and determining the boundaries of the trip.
Such a technique reliably determines trips in an open ticket toll
collection system and combined open ticket and closed ticket
system, supports trip based billing and provides a method to
determine system malfunctions, and to identify possible toll
evaders. Such a technique further determines when it would be
premature to declare a trip complete. Thus, once a decision is made
to declare that a vehicle has completed a billable trip, there is a
relatively small probability of an error in that decision. This
final trip decision simplifies the billing and accounting
processes.
[0011] In accordance with a still further aspect of the present
invention, a method is provided to determine a vehicle trip having
a plurality of gateways disposed according to a roadway topology.
The method includes providing a model of the topology including
gateway connectivity, a plurality of minimum travel times between
pairs of gateways, and a plurality of incident free maximum travel
times between pairs of gateways, providing a plurality of vehicle
detections, providing a set of rules for applying the model,
correlating the plurality of vehicle detections by applying the
rules to the plurality of vehicle detections, and determining a
plurality of chainable vehicle detections forming the trip. Such a
technique is flexible enough to apply to most roadway
configurations and can be used to determine complete trips in a
network of toll roads where vehicles can make loop trips or have
multiple routes to a destination.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The foregoing features of this invention, as well as the
invention itself, may be more fully understood from the following
description of the drawings in which:
[0013] FIG. 1 is a schematic diagram of an automatic roadway toll
collection and management system including a trip determination
subsystem according to the invention;
[0014] FIG. 2 is a schematic diagram of a segment of an exemplary
roadway topology;
[0015] FIG. 3 is a block diagram of a trip determination sub-system
according to the invention;
[0016] FIG. 4 is a flow diagram illustrating the steps of
determining a trip according to the invention;
[0017] FIG. 5 is a flow diagram illustrating the steps of
correlating and chaining detections to form a trip according to the
invention;
[0018] FIG. 6A is a timing diagram showing transactions being
processed during one iteration of the trip determination and
chaining method of FIGS. 4 and 5; and
[0019] FIG. 6B is a timing diagram showing transactions being
processed during an iteration subsequent to the iteration of FIG.
6A.
DETAILED DESCRIPTION OF THE INVENTION
[0020] Before providing a detailed description of the invention, it
may be helpful to define some of the terms used in the description.
Video Image Processing includes but is not limited to locating a
license plate within an image automatically, providing a sub-image
which includes the license plate number, reading a license plate
number using optical character recognition (OCR) techniques,
matching license plate images using correlation techniques and
other image processing methods. Video Exception Processing includes
locating a license plate image, providing a sub-image and manually
reading the license plate number from the sub-image. A registered
plate (also referred to as a transponder registered license plate
number) is a license plate associated with a transponder and
registered to a customer account for toll billing purposes. A video
user is a customer who does not have a registered transponder. In
one embodiment, an unregistered user is considered a "video user"
by default.
[0021] A Non-Final Plate Read is a processing condition indicating
that a plate number has been read but may be subject to being
re-read manually if it is later determined that there is a
relatively high probability the license plate number previously
read is in error. A Final Plate Read is a processing condition
indicating that a plate has been read with sufficient confidence so
no further re-reads of the plate image are required.
[0022] A transaction is a record of a vehicle crossing a toll
gateway or other roadside device on the roadway where a record of
the vehicle crossing the point can be recorded. A detection is
provided by a trip processor processing a transaction or group of
transactions to filter out duplicate transactions and certain
ambiguous transactions.
[0023] A Trip is a complete journey on the Toll Road by an
individual vehicle. A single gateway trip is a trip which includes
a single detection. A time marker t-dot ({dot over (t)}) is defined
as the time of oldest detection in the system that is in an initial
processing state. A time marker t-double-dot ({umlaut over (t)}) is
defined as the time of the oldest detection in the system that has
transitioned out of the initial processing state, but which is
awaiting verification. A license plate number (also referred to as
license plate characters) initially associated with a transaction
for use in trip chaining may be identified as suspect as a result
of the trip chaining processing, particularly for single gateway
trips. Those license plate characters may be altered through manual
review using manual reads at a later point in time. This manual
review of the single gateway trip is referred to as single gateway
verification. Verification of license plate numbers includes
confirming by manually reading a license plate image that an OCR
reading or previous manual reading is correct.
[0024] When required, an AVI reading can be confirmed by processing
the plate image using the VIP or by manually reading the plate
image. Now referring to FIG. 1, an automatic roadway toll
collection and management system 100 for a toll roadway includes a
roadside toll collection subsystem 10 and a transaction and toll
processing subsystem (TTP) 12 which are interconnected, for
example, via a network 36. The roadside toll collection subsystem
10 includes a plurality of roadside toll collectors (RTC) 14a-14n
(generally referred to as RTC 14). Each RTC 14 is coupled to a
plurality of traffic probe readers (TPR) 16a-16m (generally
referred to as TPR 16), a plurality of enforcement gateways 17a-17l
(generally referred to as enforcement gateways 17), and a plurality
of toll gateways (TG) 18a-18k (generally referred to as TGs 18)
which are interconnected via the network 36. The enforcement
gateways 17 and TGs 18 are collectively referred to as gateways.
The TPRs 16, enforcement gateways 17, and TGs 18 are collectively
referred to as roadside devices. The transaction and toll
processing (TTP) subsystem 12 includes a plurality of transaction
processors 24a-24k (generally referred to as transaction processor
(TP) 24) coupled to an image server 30, at least one electronic
plate reading video image processor (VIP) 22a, a manual plate
reading processor 26 (also referred to as a video exception
processor (VEP) 26), a toll processor 28, and a real-time
enforcement processor 32. Each TP 24 processes a plurality of
transactions 44 and associated images 43. The toll processor 28
includes a trip determination processor 40. The system 100
optionally includes additional VIPs (shown as VIP 22n). The system
100 further includes a traffic monitoring and reporting subsystem
(TMS) 20 which is connected to the TTP 12 via the network 36.
[0025] The blocks denoted "processors," or "subsystems" can
represent computer software instructions or groups of instructions.
Portions of the RTCs 14, can also be implemented using computer
software instructions. Such processing may be performed by a single
processing apparatus which may, for example, be provided as part of
the automatic roadway toll collection and management system
100.
[0026] In operation, the RTCs 14 control the collection of
transaction data when a vehicle is detected. The detection includes
transaction data and in certain situations described below, license
plate images which are transmitted over the network 36 for
processing by the plurality of transaction processors 24 included
in the TTP 12. In one embodiment the images are stored on the image
server 30. The transactions are processed in order to provide
detections to the toll processor 28 to enable billing the customer
for travel on the toll roadway. Such processing includes
determining when a vehicle completes a trip (described below in
further detail in conjunction with FIGS. 5-6).
[0027] A vehicle is detected, for example, when the vehicle enters
a detection zone of one of the TPRs 16, enforcement gateways 17 or
TGs 18 on the roadway. After detection or simultaneous with the
detection of the vehicle, a transponder reading is collected if
possible. If the vehicle does not have a transponder, the
transponder fails, or verification of the use of the transponder is
required, a video image is collected. The image is initially
processed by the RTC 14 and then transmitted to the image server
30. The image is processed automatically by one of the VIP
processors 22 using OCR techniques or correlation matching
techniques using at least one verified image of the vehicles
license plate. If the image cannot be processed automatically or
the reading is required to be verified, then the image must be
viewed manually by a human operator using the VEP 26 to determine
the plate number. The real-time enforcement processor 32 processes
information relating to law enforcement issues and distributes such
information to law enforcement personnel.
[0028] The trip determination processor 40 processes vehicle
detections and other roadway usage information and determines the
most likely set of detections forming a trip. The roadway usage
information considered is: roadway topology, time of each gateway
detection, incidents along the roadway near the gateway detection
times, billing policies, and tolling system delays. Using this
information, the trip determination processor 40 determines the
boundaries of each actual trip.
[0029] The trip determination processor 40 determines when it would
be premature to declare the trip complete. Thus, once the trip
determination processor 40 decides to declare the trip complete, it
does not reprocess the detections included in that decision, thus
simplifying the billing and accounting processes.
[0030] The TMS 20 includes an incident detection system which
provides information used to account for expected transactions
which are overdue. This information can assist the trip
determination processor 40 in the determination of trips completed
by vehicles traveling in the toll roadway. The incident detection
system can be of a type described in U.S. patent application Ser.
No. 09/805,849, entitled Predictive Automatic Incident Detection
Using Automatic Vehicle Identification filed Mar. 14, 2001, said
patent application assigned to the assignee of the present
invention, and incorporated herein by reference.
[0031] Now referring to FIG. 2, a roadway schematic 45 shows a
simplified exemplary roadway topology including a plurality of
gateways 46a-46g, for example, here TGs 18 (FIG. 1). "G" is the
number of gateways in the toll roadway independent of roadway
topology. It will be appreciated by those of ordinary skill in the
art that enforcement gateways 17 and TPRs 16 and other sensors are
used as detection devices in addition to the TGs 18. The gateways
46a-46g are interconnected by a plurality of roadway segments
48a-48m. The trip determination processor 40 can operate in a
roadway having an arbitrary topology including but not limited to
toll roads where vehicles can make loop trips or have multiple
routes to a destination. The topology of the exemplary roadway is
described by the matrices as shown in Table I in which:
[0032] G=number of gateways in the toll road network. Gateways are
numbered 1, . . . , G, independent of road network topology.
1TABLE I 1 S = 0 1 1 0 2 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2
T max = 0 10 11 0 15 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 T
min = 0 1 1 0 2 0 0 0 0 2 0 0 0 0 0 0 6 6 0 0 0 0 0 0 0
[0033] Note that the above exemplary road network includes a "Y"
configuration (formed by roadway segments 48d and 48f). It will be
appreciated by those of ordinary skill in the art that other
roadway configurations are possible including more complex
topologies.
[0034] Segment Connectivity is represent by matrix S(i, j) the
minimum number of road segments connecting any two gateways 46 i
and j in the road network when traveling from i to j. S(i, j) is 0
if there is no connectivity within the road network from gateway i
to gateway j. This matrix is used to identify which transactions
can be chained together into a single trip as a function of the
roadway. For example, G=5 for the topology of Table I, and S(1,5)=2
indicates that traveling from TG.sub.1 46a to TG.sub.5 46g the
minimum number of road segments connecting these gateways is two,
including roadway segments 48d and 48e.
[0035] A maximum travel time is represented by T.sub.max (i, j) the
incident free maximum travel time from gateway i to gateway j when
no incidents exist along the route from i to j. T.sub.max (i, j) is
zero if there is no connectivity within the road network from
gateway i to gateway j. When a traffic incident causing a severe
blockage of traffic is detected, the traffic incident data is used
to extend the maximum time allowed until the incident is cleared.
Presumably, most vehicles will eventually get from point i to j.
T.sub.max, (i, j) is set to zero only for cases where it is
physically impossible to travel from i to j based on the road
geometry. In the exemplary roadway of Table I, the maximum travel
time from gateway TG.sub.1 to gateway TG.sub.5, T.sub.max (1,G), is
15 arbitrary time units.
[0036] An expected maximum travel time is represented by T.sub.exp
(t, i, j) (not shown) that is the expected maximum travel time from
gateway TGi to gateway TGj at time t including the effect of
incidents along the route from TGi to TGj. T.sub.exp (t, i, j) is 0
if there is no connectivity within the road network from gateway
TGi to gateway TGj. T.sub.exp (t, i, j)>=T.sub.max (i, j). After
a traffic incident is detected, the expected travel times are
modified in response to traffic incidents. This matrix is used to
separate successive trips. The minimum travel time is represented
by T.sub.min (i, j) the minimum travel time from gateway i to
gateway j regardless of whether there is connectivity between
gateways TGi and TGj within the road network. This matrix is used
to optionally filter erroneous vehicle detections. No filtering is
performed when T.sub.min is all zeros.
[0037] Now referring to FIG. 3, the trip determination processor 40
includes a vehicle detection correlation processor 54. The vehicle
detection correlation processor 54 is coupled to a transaction
filter processor 56. The transaction filter processor 56 is coupled
to an end of a trip detection processor 58, and a start of a trip
detection processor 60. The transaction filter processor 56, the
end of a trip detection processor 58, and the start of a trip
detection processor 60 are coupled to a trip formation processor
62. A transaction processor 24 (FIG. 1) is coupled to the vehicle
detection correlation processor 54.
[0038] The blocks denoted "processors" can represent computer
software instructions or groups of instructions performed by a
processing apparatus or a digital computer. Such processing may be
performed by a single processing apparatus that may, for example,
be provided as part of the trip determination processor 40 such as
that to be described below in conjunction with method described in
FIGS. 4-5. Alternatively, the processing blocks represent steps
performed by functionally equivalent circuits such as a digital
signal processor circuit or an application specific integrated
circuit (ASIC).
[0039] The following Trip Notation is used to explain the operation
of the processors 54-62. Trips are formed from chained detections
on a single vehicle. D.sub.n represents the n.sub.th detection of a
plurality of detections which are currently being processed for the
vehicle;
[0040] D.sub.n.fwdarw.D.sub.n+1 indicates that D.sub.n+1 chains to
preceding detection D.sub.n;
[0041] .parallel.D.sub.n indicates that D.sub.n is the first
detection in the trip; 4 D n D n + 1 indicates that D n + 1 chains
to preceding detection D n ; ; D n indicates that D n is the first
detection in the trip ; D n r; indicates that D n is the last
detection in the trip ; { D 1 , D 2 , D 3 } ; D 1 D 2 D 3 r; {
shows that the given set of 3 detections chain together into a
single trip ; and { D 1 , D 2 , D 3 } ; D 1 r; ; D 2 r; ; D 3 r; {
shows that the given set of 3 detections form 3 single gateway
trips .
[0042] In operation, the transaction processor 24 receives a
plurality of transactions provided by vehicle detections from one
of the plurality of RTCs 14 which is coupled to at least one of the
plurality of TPRs 16, enforcement gateways 17 and TGs 18. After the
transaction is initially processed and converted into a detection,
it is sent to the vehicle detection correlation processor 54. Each
of the detections includes a time of detection of the vehicle and
location identifying information. The location identifying
information is provided as a unique ID or location data sufficient
to provide an indication of the physical position of the detecting
equipment.
[0043] It will be appreciated by those of ordinary skill in the
art, that several parameters are used to tune the trip detection
operation of processors 54-62. One such parameter is a Tolling
Policy Parameter, s.sub.max, which defines the maximum number of
missed detections allowable between successive detections of a
vehicle on a given trip.
[0044] The trip determination processor 40 forms trips at time T
for vehicle k by processing a set of candidate detections provided
by the transaction processors 24. If a particular vehicle k is
detected during the interval {t.sub.m,t.sub.n}, the set of
detections on that vehicle are:
[0045] .delta..sub.k(t.sub.m,t.sub.n)={D.sub.l,i=1, . . .
,N.sub.k}, where
[0046] N.sub.k=number of detections of vehicle k during
{t.sub.m,t.sub.n};
[0047] D.sub.l=(g.sub.l,t.sub.l) is the ith detection in the
interval, reported from gateway g.sub.l at time t.sub.l;
[0048] k is the vehicle number with having a unique
identification;
[0049] t.sub.m is the time of the first detection on vehicle k not
already declared as part of a trip or already declared ineligible
for trip formation, as of time T; and
[0050] t.sub.n is the latest time for which all detections are
known to have been received.
[0051] Further, without loss of generality, the detections are time
ordered, i.e.:
t.sub.m.ltoreq.t.sub.l.ltoreq.t.sub.2.ltoreq. . . .
.ltoreq.t.sub.N.sub..sub..lambda..ltoreq.t.sub.n.
[0052] It should be noted that the constraint imposed by t.sub.n
prevents trips from being formed prematurely due to transactions
arriving out of time order.)
[0053] The vehicle detection correlation processor 54 correlates
vehicle detections using the following criteria:
[0054] For 1.ltoreq.i.ltoreq.N.sub.k and j>i, the correlation
index .rho.(D.sub.l,D.sub.j) is defined as: 5 ( D i , D j ) = { 1
if 0 < S ( g i , g j ) ( s max + 1 ) and T min ( g i , g j )
< t j - t i < T exp ( t j , g i , g j ) 0 otherwise ( 1 )
[0055] The definition indicates that D.sub.l and D.sub.j are
positively correlated if the detections come from gateways that are
logically consistent with the roadway topology, and the travel time
between them is reasonable, i.e. within a predetermined limit of
the expected travel time under prevailing traffic conditions.
[0056] A detection chains to Di if the correlation index =1 as
represented in:
D.sub.l.fwdarw.D.sub.j if .rho.(D.sub.l,D.sub.j)=1, for the
smallest j where j>i and any detections between D.sub.i and
D.sub.j are filtered according to equation (3) below. (2)
[0057] For example, using the roadway topology of FIG. 2, an
exemplary set of detections includes the following detections
(gateway, time in arbitrary units) which have been collected for
vehicle V:
{D.sub.l=(1,100),D.sub.2=(2,105),D.sub.3=(3,110)}
[0058] Then, according to equation (1), each correlation index is
determined as follows:
.rho.((1,100), (2,105))=1
.rho.((1,100), (3,110))=1
.rho.((2,105), (3,110))=0
[0059] Note that D.sub.2 and D.sub.3 do not correlate because S(2,
3)=0, i.e. there is no connectivity within the road network from
gateway 2 to gateway 3. 6 ; D 1 D 2 r; { shows that the given set
of 2 detections chain together into a single trip
[0060] Note that even though (1, 100) correlates to (3, 110), the
detections are not chained because (1, 100) will be chained to the
first possible detection which is (2, 105). This is the case even
if (2, 105) is received after (3, 110).
[0061] The transaction filter processor 56 filters erroneous
transactions, which do not meet various time and topology criteria
as provided in:
[0062] D.sub.l is filtered if:
T.sub.min(g.sub.l-1,g.sub.l)>0 and
t.sub.l-t.sub.l-1<T.sub.min(g.sub- .l-1,g.sub.l) for i>1
(3)
[0063] The trip determination processor 40 forms trips by
identifying start points, end points, and correlated
detections.
[0064] The start of a trip Detection Processor 60 determines a
start to a trip using the following criteria: 7 Start of Trip r; D
i if { i = 1 i > 1 and ( D i - 1 , D i ) = 0 ( 4 )
[0065] The technique doesn't allow trips to be formed prematurely,
thus the first unchained detection must be the start of a new trip
rather than a continuation of a trip already formed. In addition,
if two given detections do not correlate, it reflects a break
between two trips where the second detection is the start of the
second trip.
[0066] In the example above, the following start of trip is
detected:
[0067] .parallel.(1, 105) indicates the first detection in the trip
is the start of the trip.
[0068] The end of a trip Detection Processor 58 determines an end
to a trip using the following criteria: 8 End of Trip D i r; if { i
< N k and ( D i , D i + 1 ) = 0 and t n > t i + T exp ( t i +
T max ( g i , g j ) , g i , g j ) for each j in which 0 < S ( g
i , g j ) s max + 1 i = N k and t n > t i + T exp ( t i + T max
( g i , g j ) , g i , g j ) for each j in which 0 < S ( g i , g
j ) s max + 1 ( 5 )
[0069] The first condition excludes detection, D.sub.i from being
the end of the trip if it correlates to D.sub.i+1. The second
condition in equation (5) requires that sufficient time has elapsed
to determine that there cannot be an outstanding detection that
would correlate to the detection being processed. To determine
this, all possible subsequent gateways, as defined by S and
s.sub.max must be considered. For each possible subsequent gateway
beyond D.sub.i, the maximum detection time that could possibly
chain is computed. The maximum detection time within which
detections that could possibly chain is illustrated in FIGS. 6A and
6B and referred to as an extrapolation region. It is determined
whether the latest detection time (also referred to as the current
boundary time), t.sub.n, is greater than the maximum detection time
that could possibly chain. If the current boundary time, t.sub.n,
is greater than the maximum detection time that could possibly
chain, the end of trip is declared because there are no detections
with a time of less then t.sub.n that will be received later and
thus no future detections can possibly chain to D.sub.i. The latest
time for which all detections are known to have been received,
t.sub.n, is calculated in a reliable manner taking into
consideration all places in the tolling system where a transaction
could be buffered, including but not limited to, the memory of the
various processors, hard disks, and the network.
[0070] In other words, before the end of the trip can be declared,
the trip determination processor 40 must wait for all the
detections that could possibly chain on to the last detection. At
some point in the detection time space, t.sub.n, it is no longer
possible to have a detection which will chain to the last known
detection which is then declared the end of the trip. The latest
time, t.sub.n, is referred to as time marker {dot over (t)} for
potential trips (described below in conjunction with step 120, FIG.
4) and to time marker {umlaut over (t)} for firm trips (described
below in conjunction with step 142 FIG. 4). The latest time,
t.sub.n, is referred to below as the "trip boundary time" in
conjunction with step 254 (FIG. 5).
[0071] In the example above assuming there are no incidents, the
following end of trip (2,105) .parallel.
[0072] is not detected until t.sub.n=113 because T.sub.max(2, 5)=8
and 105+8=113.
[0073] A key feature of this invention is the determination of when
it would be premature to declare a trip complete. Thus, once a
decision is made to declare that a vehicle has completed a billable
trip, there is a relatively small probability of an error in that
decision. This final determination process simplifies the billing
and accounting processes.
[0074] The Trip Formation Processor 62 forms trips by chaining
detections between the boundaries located by the end of a trip
Detection Processor 58 and the start of a trip detection processor
60. Trip Formation Processor 62 chains detections according to the
criteria of equation (2). For example, detection D.sub.l chains
with D.sub.j if D.sub.l and D.sub.j are correlated. In the example
above, the following trips are formed:
[0075] .parallel.(1, 105).fwdarw.(2,105).parallel. .parallel.(3,
110).parallel., here .parallel.(3, 110).parallel. is a single
gateway trip.
[0076] In the flow diagrams of FIGS. 4-5, the rectangular elements
are herein denoted "processing blocks" (typified by element 202 in
FIG. 5) and represent computer software instructions or groups of
instructions. The diamond shaped elements in the flow diagrams are
herein denoted "decision blocks" (typified by element 214 in FIG.
5) and represent computer software instructions or groups of
instructions which affect the operation of the processing blocks.
Alternatively, the processing blocks represent steps performed by
functionally equivalent circuits such as a digital signal processor
circuit or an application specific integrated circuit (ASIC). It
will be appreciated by those of ordinary skill in the art that some
of the steps described in the flow diagrams may be implemented via
computer software while others may be implemented in a different
manner (e.g. via an empirical procedure). The flow diagrams do not
depict the syntax of any particular programming language. Rather,
the flow diagrams illustrate the functional information used to
generate computer software to perform the required processing. It
should be noted that many routine program elements, such as
initialization of loops and variables and the use of temporary
variables, are not shown. It will be appreciated by those of
ordinary skill in the art that unless otherwise indicated herein,
the particular sequence of steps described is illustrative only and
can be varied without departing from the spirit of the
invention.
[0077] Referring now to FIG. 4, at step 110 processing commences to
determine if any additional detections which form a trip taken by
an individual vehicle add information which is useful in
determining and verifying the plate number of the vehicle. For
example, if the same plate number is read at two consecutive TGs 18
and the transit time between the two TGs 18 was reasonable for
current traffic conditions, there is a relatively high confidence
that the plate number is correct. License plate images are
generally included in the detections when the RTC 14 determines the
images are required. The inclusion of the images in a detection can
result in manual read operations. The consecutive reads described
above, for example, provide a reduction in the number of manual
reads because, here, no manual read would be required for
verification purposes for the two detections even if the detections
included video images.
[0078] In one embodiment, in which the system 100 includes a high
percentage of vehicles equipped with transponders, the majority of
the transactions and resulting detections will include only AVI
readings and under normal circumstances no verification of these
AVI readings will be required. A detection is result of processing
one or more transactions and represents the actual event of a
vehicle being detected by the roadside equipment. Although most
detections no not require verification, there are several situation
where video images are required and made available to the trip
determination sub-system 40. In systems with a relatively lower
percentage of AVI readings and systems which rely to a greater
extent on video capture a relatively larger number of verifications
is required. Table I illustrates four different types of detection
categories used for trip processing. A vehicle ID is a unique
number assigned to each vehicle identified by the system. The
vehicle ID is associated with a license plate number (also referred
to as plate characters).
2 TABLE I Detection Types Components Source of Vehicle ID A AVI
Only IVU ID A' AVI + Video IVU ID V Video Only Plate Characters V'
Video + AVI Plate Characters
[0079] For example, an "A" type detection includes only a
transponder reading. The "A" type detection is the normal detection
in the case of a transponder user where there are no hardware
problems, no class mismatch, and no reported problems with the
customer account associated with the AVI reading. An A' detection
is, for example, a detection that might indicate that a customer
has switched a transponder from one vehicle to another without
authorization, and the system 100 has determined that video images
are required to determine which vehicle actually is using the
transponder. In both the A and A', detections, the IVU ID is used
to determine the Vehicle ID.
[0080] The V' detection is, for example, a detection also including
a video image with a transponder reading, but might be used when a
transponder has been reported stolen. In this situation, the
transponder is likely to be on a different vehicle than the one
identified by the Vehicle ID registered to the transponder so the
system 100 will try to read the plate image to determine the
license plate number. It is important to verify at least one of the
A' and V' detections if there are any in a trip, and in many
situations this will involve manual reads using the VEP 26.
[0081] The Vehicle ID is normally derived from the IVU ID when a
detection has both AVI and Video components. The specific
conditions under which the Vehicle ID is derived depend on the
roadway operator's policy.
[0082] Additional manual reads can result from verifications
requested by the trip processor described below in steps 380 to
424. Verifications place a load on the manual read sub-system which
also must process images for which there is no other means of
identification. A reduction in the number of verifications reduces
the overall number of required manual reads. An example of a
required verification occurs when the system discovers a vehicle
class mismatch. This might occur when a transponder is moved from a
car to a truck. The system will detect this situation and capture a
video image of the license plate to determine which vehicle is
using the transponder. Another situation where verification is
required with transponder usage occurs when a transponder is
stolen. In this situation, it is important to verify the license
plate because law enforcement is likely to be involved.
[0083] At step 112, duplicated transactions 44 and conflicting
gateway crossings are filtered out by using a unique internal
system ID assigned to each transaction 44. Duplicate transactions
44 can occur, for example, when the network erroneously retransmits
the transaction 44. Conflicting gateway crossing can be caused by a
vehicle leaving the roadway having transactions 44 indicating a
break between two trips or a crossing not physically possible to
reach in the amount of elapsed time. In case of such ambiguous
transactions 44, the transaction is filtered, optionally billed
separately, and the transaction is logged since it may indicate a
toll evader. In one embodiment, ambiguities are eliminated by
filtering and giving priority to the first transaction in an
ambiguous set. Processing continues at step 114.
[0084] At step 114, it is determined if video image of the license
plate is unverified and selected for a random audit. If the video
image is unverified and selected for a random audit, processing
continues at step 116, otherwise processing continues at step
118.
[0085] At step 116, the plate read is verified. Verification is
performed manually by tasking an operator who has not yet viewed
the sub-image to read the plate number. If the operator reads the
same plate number, verification is successful. Otherwise,
additional processing is performed by the VEP 26 to attempt to
determine the true plate number by manually reading the plate
image. At step 116, if verification doesn't result in a change to
the plate characters or an "unreadable" plate processing will
resume at step 142. If the plate characters change, the detection
will be reprocessed and possibly chained into a different trip at
steps 142 and 144.
[0086] At step 118, dual detection filtering filters out the
extraneous video detections, i.e. detections with available license
plate images, and processing continues at step 120. It is possible
due to equipment degradation to get separate video and AVI
detections for the same toll gateway crossing. In one embodiment,
in step 118, the detections are tagged as to the type A, A', V or
V'.
[0087] At step 120, the system waits for all detections that might
chain to be initially processed and audited. Audits and
verifications are processed identically, but occur for different
reasons. In one embodiment, the operator can adjust the percentage
of images sent back for audit, which are selected at random. In
order to reduce manual reads, the trip determination processor 40
can determine if license plate reads which might fit into a trip do
not have to be verified manually. To reduce manual reads, the trip
processor must wait for all possible detections which might be part
of a trip. Because some detections might be delayed before they
become available for processing or because some detections might be
delayed in the auditing process, the system must wait for some
detections to be processed and audited. The trip determination
processor 40 can either wait a long time relative to transaction
processing or use a sliding time window process which identifies
the time frame of available transactions for trip determination.
The process for manually reading license plate images is described
in further detail in U.S. patent application Ser. No. 10/______,
entitled System And Method For Reading License Plates filed January
__, 2002, said patent application assigned to the assignee of the
present invention, and incorporated herein by reference. All the
detections that might chain can be processed as a group with the
possibility that the number of verifications is reduced. A
potential trip can have any combination of A, A', V or V'
detections in any number or sequence limited only by the road
geometry. In practice, a single potential trip containing both A'
and V' detections is rare, but the possibility does exist.
[0088] At step 121 the plurality of detections which might form a
potential trip, are chained together and processing continues at
step 122.
[0089] At step 122, it is determined if there are any A' detections
in the potential trip, for example if the measured class of the
vehicle corresponding to the original detection is a mismatch. If
there is an A' detection then processing continues at step 124,
otherwise processing continues at step 126. It should be noted that
all remaining detections in the potential trips are included in the
detections which are processed in steps 124 and 126.
[0090] At step 124, it is determined if any A' detection is a
detection having video with a final plate read. If there is a final
plate read, then processing continues at step 126, otherwise
processing continues at step 144. It should be noted that all
remaining detections in the potential trips are included in the
detections which are processed in step 144 and 126.
[0091] At step 144, the first A' detection in the potential trip is
selected for verification at step 116. Remaining unselected
detections (if any) which bypass verification are processed at step
126. At step 144, instead of verifying all of the video images in
the A' detections, a single detection, here being the first A'
detection, is verified resulting in fewer manual read
operations.
[0092] At step 126, it is determined if there is one and only one
detection in the potential trip which is either a V or a V'
detection, including for example a single gateway video trip, or a
multi-gateway trip with either one video V detection or one V'
detection including AVI data. Steps 126, 127, 128, 130, 134, 136,
and 138 determine whether there is a relatively high probability of
an error in the vehicle ID associated with one of the detections in
the potential trip due to a misread of the plate characters in an
image. By forcing a manual read or reread of such images, the
system is able to focus VEP operator resources on the images with
the highest probability of error to achieve a significant reduction
in billing errors without excessively increasing VEP operator
workload. A single gateway video trip occurs where a vehicle
crosses a single gateway, a video image of the license plate is
captured and the vehicle leaves the toll road. Such trips have a
higher probability of error than trips with only A and A'
detections or multi- gateway video trips because of the possibility
of a single misread directly resulting in a billing error. However,
it is not desirable to verify all single gateway video trips if
there are a large number of such trips being traveled or RTC
equipment failure at a specific location causes a large number of
video only (V) detections to be created for what would otherwise be
A detections. While a single gateway video trip is the simplest
example of a trip that will be routed to step 127 for further
consideration of the need to perform verification, step 126 also
allows for the more general case of any trip with exactly one V or
V' detection, but not both together in the same trip since that
would be a multi-gateway video trip. If there is one and only one V
or V' detection, processing continues at step 127, otherwise
processing continues at step 142.
[0093] At step 127, the V or V' detection (of which there is only
one) is selected from the plurality of detections and processed at
step 128, the remaining (unselected detections) are processed at
step 142.
[0094] At step 128, it is determined if this is the final plate
read for this image, i.e. is the one video detection from step 127
marked as "Final Plate Read" or "Non-final" Plate Read. If this is
the final plate read for the video detection then processing
continues at step 142, otherwise processing continues at step
130.
[0095] At step 130, it is determined if the customer associated
with the selected detection is a video user, i.e. there is no
registered transponder for the read plate. An unregistered user is
considered a "video user" by default in one embodiment. If this
customer is a Video User then processing continues at step 138,
otherwise processing continues at step 134.
[0096] At step 134, it is determined if a fault or maintenance
activity has occurred at the location where the detection was
captured. If either of these activities has occurred and is
associated with the current detection then processing continues at
step 142, otherwise processing continues at step 136. In step 134,
A or A' detections which were captured as V detections due to
equipment failure or maintenance, (e.g., an AVI RF antenna was
turned off), are not verified in order to reduce the manual read
workload.
[0097] At step 136, the plate read is verified and if verification
doesn't result in a change to the plate characters or an
"unreadable" plate processing will resume at step 142 when all
required verifications for detections which include license plate
images for the vehicle which might chain have been completed. If
the plate characters change, the detection will be reprocessed and
possibly chained into a different trip at steps 142 and 144.
[0098] At step 138, it is determined if the VIP Match is good, i.e.
a prior correlation with a verified image resulted in a match over
threshold. If the VIP Match is good then processing continues at
step 142, otherwise processing continues at step 136.
[0099] At step 142, the system 100 waits for required verification
of all detections that might chain (similar to step 120). After the
detections that might chain are available for processing and have
been verified as required, processing continues at step 146. One
embodiment waits for detections by using a batch processing
technique as described below in further detail in conjunction with
FIGS. 6A and 6B. After a batch of detections is processed,
processing continues at step 146. In one embodiment, the toll
processor 28 can include a delay before processing the transactions
44. In an alternate embodiment, the toll processor 28 can include a
sliding time window, which is a different window than the window in
step 120.
[0100] At step 146, the detections are chained together to form a
firm trip and processing continues at step 148. At step 146, trips
in addition to trips having selected/non-selected detections are
formed. Step 146 is described below in further detail in
conjunction with FIG. 5.
[0101] At step 148, the plate reading and trip chaining process is
complete and the trip if one is determined can be rated and posted
and the customer can be billed. After a firm trip is determined,
there are no more plate reads for the chained detections. All
verification and evaluation of potential trips occurs before the
trip is formed. Thus, trip determination simplifies the interface
to the billing system and reduces the number of manual reads. Trip
processing does affect plate reading by sending detections back for
manual verification, but this occurs as the result of evaluating
potential trips, not firm trips. Processing continues at step
150.
[0102] At step 150, it is determined if there is IVU Fault or Plate
Mismatch. If there is IVU Fault or Plate Mismatch then a notice
and/or a class mismatch fine is sent to the customer in step 152
and processing terminates at step 154. At step 154, processing
terminates.
[0103] Referring now to FIG. 5, a flow diagram illustrates the
steps in one embodiment for processing a plurality of vehicle
transactions including detecting a trip start point, correlating a
plurality of vehicle detections, and determining the boundaries of
the trip in response to a plurality of roadway usage factors and
the correlated detections.
[0104] In conjunction with FIG. 5 the following notation is used to
describe some of the steps for chaining detections to form trips or
potential trips:
[0105] PT=the previous detection;
[0106] CT=the current detection;
[0107] Gi=gateway of PT;
[0108] Gj=gateway of CT;
[0109] S(Gi, Gj): segment connectivity table;
[0110] Tmax(Gi, Gj): max travel time table;
[0111] Tmin(Gi, Gj): min travel time;
[0112] s.sub.max: max # of skipped gateways allowed; and
[0113] S(Gi, Gj), Tmax(Gi, Gj), Tmin(Gi, Gj), and s.sub.max are
configurable parameters adjusted by the roadway operator.
[0114] FIG. 5 is an illustration of the detailed process flow of
forming a trip as described above in conjunction with step 121
(FIG. 4) and with step 146 (FIG. 4). In step 121 potential trips
are formed, and in step 146 firm trips are formed. In one
particular embodiment, the process of forming a trip uses the
techniques embodied in equations (1-5) above.
[0115] At step 200, a vehicle for which there is at least one
transaction is selected and the trip determination process is
started. The process described in FIG. 4 operates on transactions
which have been verified and can be associated with a specific
vehicle with a relatively high probability.
[0116] At step 202, a determination is made as to whether all
detections for the selected vehicle, which might chain together
have been collected. If there might be more detections available
processing of another vehicle resumes at step 200. After collecting
detections, which potentially form a trip, processing continues at
step 204. One embodiment waits for detections by using a batch
processing technique and is described below in further detail in
conjunction with FIGS. 6A and 6B.
[0117] A trip is formed in steps 204-260 by identifying start
points, end points, and correlated detections as described in the
following steps. At step 204, a trip transaction for the selected
vehicle is retrieved, for example, from a transaction processor or
a transaction database. The transactions are processed to generate
a set of detections for a vehicle. As described above a transaction
provides a time and location with a vehicle identification. A
roadside device using an AVI reader, a license plate reading
system, a card reader or any system which can provide an
identification of a vehicle can generate a transaction sufficient
to provide detection information.
[0118] At step 206, the number of gateways traversed per trip (NG)
is initialized to 1 and the ID of each gateway in the current
detection is stored for later use. At step 210 it is determined if
the current transaction is the last transaction for the selected
vehicle. If it is determined that there are more transaction for
the selected vehicle processing continues at step 212, otherwise
processing continues at step 240.
[0119] Steps 212 to 232 are repeated for the remaining group of
transactions for the selected vehicle. If there are no more
transactions for the selected vehicle processing continues at step
240.
[0120] At step 212 the previous and current detections are checked
for a positive correlation to determine if a pair of detections can
be chained together. The previous detection is retrieved and
correlated with the current detection in steps 214 and 216.
[0121] At step 214, it is determined, for example by using the
constraint of equation (3), whether the travel time between two
gateways is reasonable using the following comparison:
[time(CT)-time(PT)]>Tmin(Gi, Gj);
[0122] where Tmin(Gi, Gj) is the min travel time between gateways
Gi, Gj . If the travel time is reasonable processing continues at
step 216 to further test for positive correlation, otherwise
processing continues at step 234.
[0123] In one embodiment, the trip processor uses equation (1), for
example, in steps 216, 218 and 220 to correlate the detections. At
step 216, it is determined whether the detected gateways are
logically consistent with the road topology, using a gateway
segment connectivity table S(Gi, Gj) and with the following
test:
is 0<S(Gi, Gj)<=(s.sub.max+1);
[0124] where s.sub.max is the maximum number of skipped gateways
allowed. In one embodiment, s.sub.max is based on the business
rules of the roadway operator including such things as any minimum
trip charge and for the possibility that the RTC 14 occasionally
fails to detect a vehicle due to equipment failure. If the
detections are positively correlated (i.e. they come from gateways
that are logically consistent with the road topology, and the
travel time between them is reasonable) then processing continues
at step 218, otherwise processing continues at step 226. as. At
step 218, the expected time T.sub.exp to the next gateway is
retrieved, for example, from a travel time table database which
includes the expected travel time between pairs of roadside devices
which detect vehicles.
[0125] At step 220, it is determined whether the difference between
the time of the current detection and the time of the previous
detection is less than a maxTime, where maxTime is the maximum of
Texp[time(CT), Gi, Gj] and Tmax(Gi, Gj). In other words, maxTime is
the longest permissible travel time between the two given gateways
without breaking the detections into separate trips. "time
difference" is the actual travel time between the two detections.
If the time difference is less than the maximum time allowed for
the detections to be chained then processing continues at step 222,
otherwise processing continues at step 226.
[0126] At step 222, the current detection is chained to the
potential trip or firm trip containing the previous detection, the
chaining determined, for example, by using the constraint of
equation (2). Processing resumes at step 210.
[0127] At step 226, the previous and current detections (PT and CT)
are split into two groups, which can either be processed serially
or in parallel. Processing continues at steps 228 and 230.
[0128] At step 228 the current transaction (CT) is processed as if
it is the start of a new trip according to the constraints of
equation (4). Processing continues at step 232. At step 232, the
current gateway ID is stored as a new first gateway ID and the
number of gateways is reset (NG=1). Processing resumes at step
210.
[0129] At step 230, if a firm trip is being formed (step 146 FIG.
5), the firm trip is formed with PT being last transaction of the
trip. If a potential trip is being formed (step 120 FIG. 5), the
potential trip is formed with PT being last transaction of the
trip. Processing resumes at step 210.
[0130] At step 234, the filtered transaction is handled according
to roadway rules, for example the rules below:
[0131] Single Gateway Filtered AVI transactions: Bill or Discard
(Default=discard)
[0132] Single Gateway Filtered Video transactions: Bill or Discard
(Default=discard)
[0133] Multiple Gateway Filtered transactions (AVI/video mix): Bill
or Discard (Default=bill)
[0134] The exemplary default settings are based on an assumption
that single gateway anomalies are more likely a system problem and
multi-gateway anomalies are more likely due to a toll evader.
Processing resumes at step 210.
[0135] At step 240, the last gateway crossed during the current
potential trip (Gi) is retrieved.
[0136] At step 242, the process initializes a loop on the segment
connectivity matrix at gateway i (Gi) in order to compute the
extrapolated times for this potential trip or firm trip. Using the
example from above for the following detections:
[0137] .parallel.(1,105).fwdarw.(2,105), here
[0138] i=2, so the process loops through S for j=1, 3, 4, 5.
[0139] At step 244, it is determined if is there another gateway j
(Gj) in S in order to end the processing loop. If there is another
gateway processing continues at step 250, otherwise processing
continues at step 246.
[0140] At step 246, gateway information for the trip is stored in
memory or a database, including the number of gateways (NG) and all
IDs of gateways traversed in the current trip. Processing continues
at step 248, where the potential trip is formed and reported to the
transaction processor. Processing for the current vehicle
terminates at step 260.
[0141] At step 248, a trip is formed and declared complete and sent
to the toll processor 28 (FIG. 1) for billing purposes if a firm
trip is being formed (step 146 FIG. 5). If a potential trip is
being formed (step 120 FIG. 5), the detections forming the
potential trip are processed as a group.
[0142] At step 250, the segment connectivity table is queried to
see if there is connectivity between Gi and Gj in the current
potential trip. If 0<S(Gi, Gj)<=(s.sub.max+1) then there is
connectivity between Gi and Gj and processing continues at step
252, otherwise processing continues at 242.
[0143] In the example described above, for the j=1, 3, 4 cases in
the example, S(i, j)=0 so processing continues at 242. For j=5,
processing continues at 252.
[0144] At step 252 the Extrapolated time is equal to the maximum
time for detection of the next chainable transaction. The gateway's
travel time table information and timestamp of last gateway
traversed is used in the computation. Processing continues at step
254.
[0145] At step 254, it is determined whether the extrapolated
time<trip boundary time, t.sub.n. The trip boundary time is time
marker {dot over (t)} (described in conjunction with FIGS. 6A and
6B for potential trips or {umlaut over (t)} for firm trips
(described below in conjunction with FIGS. 6A and 6B). If the
extrapolated time is less than the trip boundary then processing
continues at step 258. Otherwise processing continues at step 242
to continue looping on the segment connectivity matrix. In the
example described above, T.sub.max(2, 5)=8. Assuming that
T.sub.exp(2, 5, 105) is <=8, then if t.sub.n is >=113,
processing continues at 242, otherwise processing continues at
258.
[0146] At step 258, it is reported to the transaction processor
that the transactions do not form a trip and processing for the
current vehicle terminates at step 260. The current vehicle may
have more transactions not captured in this group of transactions,
an alternatively it is possible to try to chain the filtered
transactions, as well as to decide on whether or not to bill
them.
[0147] AVI information is not used to chain trips if it is suspect.
In particular, IVU IDs are not used for chaining in the case of:
lost IVUs, stolen IVUs, link validation failure , invalid agency
programmed into transponder, or when the transponder is associated
with an habitual violator. A link validation failure occurs the
roadside toll collection subsystem 10 suspects a transponder may
have been tampered with. Chaining of such suspect transactions is
based on read plates only, i.e. the AVI information is ignored in
the case of a transaction with both AVI and video information.
[0148] Now referring to FIGS. 6A and 6B, one method of waiting for
vehicle transactions with associated vehicle detections is
illustrated. In order to correctly determine a vehicle trip, the
trip processor must wait for all possible transactions which might
be part of a trip as described in conjunction with step 202 of FIG.
5 and steps 120 and 142 of FIG. 4. Because some transactions might
be delayed before they become available for processing or because
some transactions might be delayed in the verification process, the
system must wait for some transactions to be processed and audited.
The system 100 can either wait a long time relative to transaction
processing or use a sliding time window process which identifies
the time frame of available transactions for trip
determination.
[0149] Now referring to FIG. 6A, a timing diagram 300 represents a
pass n, occurring at current time T, of the process as described in
the flow diagram of FIG. 4. The timing diagram 300 includes a
plurality detections 314-332 which have been collected at various
times in the past. The timing diagram 300 includes timing marker
{dot over (t)} 310 and a plurality of adjacent extrapolation
regions 304a-304n and timing marker {umlaut over (t)} 308 and a
plurality of adjacent extrapolation regions 306a-306n.
Extrapolation region 304a includes detection 318, extrapolation
region 304b includes detection 314, extrapolation region 304c
includes detection 322, extrapolation region 304d includes
detection 332 and extrapolation region 304n includes detection 328.
Extrapolation region 306a includes detection 324 and extrapolation
region 306a includes detection 338. The detections 314-332 can be
in one of a number of states, for example, detection 316 is being
audited; detections 314 and 322 are in an unknown verify state;
detections 334 and 336 have completed verification; detections 330
and 332 do not need verification because they are chainable
detections and neither is an A' detection.
[0150] Timing marker {dot over (t)} 310 is the detection time for
the oldest detection in the system that has not been made available
to trip processing. This includes detections delayed at the
roadside, detections waiting for OCR, and detections waiting for
initial or audit manual reads. Waiting occurs at step 120 (FIG. 4)
. Here for example, Timing marker {dot over (t)} 310 is being
restricted by detection 316, which is a detection in process of
being audited by the VEP subsystem 26 because there is no final
license plate read on the image associated with the detection 316.
There might however, be a preliminary read of the license plate
number on the image associated with the detection 316 by using the
OCR.
[0151] It should be noted that both {dot over (t)} and {umlaut over
(t)} can never go backwards. It is required that {umlaut over
(t)}.ltoreq.{dot over (t)}.ltoreq. current_time. At some point in
time, detections which cannot be verified and which are limiting
the updating of timing marker {umlaut over (t)} 348 or timing
marker {dot over (t)} 310, detection may be deleted go by the
system operator. The duration of each extrapolation region 304 and
306 is related to the maximum detection time within which
detections could possibly chain. ]The duration of extrapolation
regions 304a-304n and 306a-306n vary as a function of each specific
detection, the roadway topology, and traffic conditions including,
for example, traffic incidents. The duration of the extrapolation
regions 304a-304n and 306a-306n are determined, for example, by the
constraints of equation (5). In one embodiment, the determination
of timing markers {dot over (t)} 310 and {umlaut over (t)} 308 can
be used to provide a means for batch processing a plurality of
detections which are in one of several possible states, for
example: (i) Not yet reported by the RTC; (ii)Verified by manual
read; (iii) Being audited; (iv) Unknown verify state (also referred
to as Need for Verification Undecided); and (v)Verification in
progress. When, for example, an extrapolation region 304a crosses
the timing marker {dot over (t)} 310, detection 318 cannot be
determined to be the end of a trip because there might exist a
detection (here detections 316 or 320) occurring later than timing
marker {dot over (t)} 310 which has not yet been verified/ audited
and which might chain to detection 318.
[0152] Timing marker {umlaut over (t)} 308 is the detection time
for the oldest detection in the system that has not been made
available to trip processing or has not been evaluated for possible
verification, or is in the process of being verified. Timing marker
{umlaut over (t)} 308 is associated with step 142 in the process of
FIG. 5. The plurality of detections located in time to the right of
timing marker {umlaut over (t)} 308 cannot be used to form a firm
trip because the state of a detection within this time frame can
possibly change and therefore the detections would be excluded from
forming a firm trip.
[0153] In operation, once timing markers {dot over (t)} 310 and
{umlaut over (t)} 308 are determined at some point in time, and
each detection can be processed according to the detection position
in time relative to timing markers {dot over (t)} 310 and {umlaut
over (t)} 308. In the sliding window embodiment, the constraints of
equation (5) are used, for example, to process each detection. The
sliding window embodiment includes simple processing rules, for
example: do not process any detection to the right (later than) of
{dot over (t)} 310, here detection 320 is completely excluded from
processing, and detections to the left of timing marker {umlaut
over (t)} 308 and within regions 306a-306n have completed
verification, if any was required. Detections 314, 322 and 332 can
be evaluated to determine if they need to be verified because
regions 304b, 304c and 304d end to the left of timing marker {dot
over (t)} 310.
[0154] In one embodiment a batch approach is used to process the
vehicle detections. For example, at the start of each iteration of
the steps in FIG. 5, the current {dot over (t)} and {umlaut over
(t)} are calculated and then used for processing detections during
that iteration. On the next iteration, a new t and t are calculated
effectively sliding a moving window over the detections available
for processing in the attempt to chain detections to form
trips.
[0155] Now referring to FIG. 6B, a timing diagram 340 represents
pass n+1 of the process as described in the flow diagram of FIG. 5.
The timing diagram 340 includes timing marker {dot over (t)} 346
and adjacent extrapolation region 342a-342n and timing marker
{umlaut over (t)} 348 and adjacent extrapolation region 344a-344n.
The timing diagram 340 includes a plurality detections 314'-332'
which represent like detections of FIG. 6A as of time T' which is
the current time at which pass n+1 is executed. A detection 322
(represented by a cross in FIG. 6A), for example, is represented as
a triangle detection 322' because it has been single gateway
verified and can be chained to detection 324' to potentially form a
trip. Any detection to the right (recorded later in time) of timing
marker {umlaut over (t)} 348 can potentially be associated with any
earlier detection, for example, if a detection includes a video
plate image which must be resolved with a manual plate read which
has not occurred by timing marker {umlaut over (t)} 348. A firm
trip can be formed by chaining detections 334', 336', and 338', for
example, because extrapolation region 344n does not cross the
timing marker {umlaut over (t)} 348, and therefore detection 338'
can be determined to be the end of the trip because no verified or
audited detection can occur which chains to detection 338'.
[0156] All publications and references cited herein are expressly
incorporated herein by reference in their entirety.
[0157] Having described the preferred embodiments of the invention,
it will now become apparent to one of ordinary skill in the art
that other embodiments incorporating their concepts may be used. It
is felt therefore that these embodiments should not be limited to
disclosed embodiments but rather should be limited only by the
spirit and scope of the appended claims.
* * * * *