The present invention generally relates to a real-time vehicle traffic simulation. More particularly, the present invention relates to a system, method and computer program product for forecasting a vehicle traffic condition in a near future.
Traditional traffic management models are used for analyzing details of a road network (e.g., traffic signal timing, lane configurations and closures, and other aspects of a road network). J. Barceló, et al., “Online Microscopic Traffic Simulation Supports Real-time Traffic-management Strategies,” SIAM News, Volume 40, Number 9, November 2007, wholly incorporated by reference as if set forth herein, describes a real-time traffic management model. A traffic management model is often also known as traffic microscopic simulation, traffic microsimulation, or traffic simulation program, because it emulates a traffic flow on a road network at a relatively fine, or micro, level of detail, e.g., a level of an individual vehicle movement.
Benefits of emulating the traffic flow on the traffic road network at this level of detail are numerous, as the emulation can be used to: minimizing congestion, minimizing travel time or delay, reducing emissions, etc. For example, if this emulation could provide information that is communicated in real-time to a vehicle driver about a possible congestion on a particular road, the driver may detour the particular road and use an alternative route to arrive his destination. Thus, the driver may be able to arrive at his/her destination on time.
However, tools for emulating of traffic have not been successfully applied to real-time traffic analysis for a number of reasons. One reason has to do with the computation time required by traffic emulation. In spite of advances in a computation power, the traffic microsimulation tools are not fast enough to be run in real-time and thus their output (e.g., the number of vehicles on a particular road route) could not have been used in a real-time setting. Another reason is that a physical communication network link installed between a traffic road and a traffic emulation tool was not stable. Thus, traffic emulation tools do not readily incorporate typical real-time traffic data (e.g., real-time traffic speed and volume).
The present invention is a system, method and computer program product for forecasting a vehicle traffic condition in a near future (e.g., 1 hour in advance).
In one embodiment, there is provided a system for forecasting a vehicle traffic condition in a near future. The system comprises a traffic prediction tool, a turning percentage prediction module and a simulation tool. One or more of the traffic prediction tool, the turning percentage prediction module and simulation tool is implemented in a computing system that comprises at least one processor and at least one memory device connected to the processor. The traffic prediction tool estimates a traffic speed and volume in a traffic link. A traffic link refers to a portion of a traffic road where the traffic prediction tool is installed. The turning percentage prediction module estimates a turning percentage in the traffic link based on the estimated traffic speed and traffic volume. The simulation tool computes, based on the estimated turning percentage, the estimated traffic speed and the estimated traffic volume, an expected traffic volume in the traffic link in the near future on the traffic link.
In a further embodiment, the turning percentage prediction module evaluates whether the traffic link is a congested regime. A congested regime has a traffic volume larger than a threshold. The turning percentage prediction module determines a link topology of the traffic link in response to determining that the traffic link is a congested regime. The determined link topology is one of: a diverge link, a merge link, an ordinary link, a source boundary link and a destination boundary link. The turning percentage prediction module computes the estimated turning percentage according to the determined link topology.
In a further embodiment, the turning percentage prediction module computes a historical turning percentage of the traffic link. The historical turning percentage represents an average of prior turning percentages in the traffic link. The turning percentage prediction module computes a weighted average turning percentage based on the historical turning percentage and a pre-determined weight assigned to the traffic link.
In a further embodiment, the simulation tool computes the expected traffic volume in the traffic link based on one or more of: the computed historical turning percentage of the traffic link and the weighted average turning percentage.
In a further embodiment, the turning percentage prediction module computes the estimated turning percentage of the traffic link in a free flow regime in response to determining that the traffic link is not a congested regime. A free flow regime has a traffic volume less than a threshold.
In a further embodiment, the simulation tool recommends to a user an alternative traffic management strategy based on the computed expected traffic volume and the incident occurrence.
In a further embodiment, the alternative traffic management strategy includes one or more of: detouring traffic in the traffic link through another traffic link, adjusting a traffic signal in the traffic link, adjusting a speed limit in the traffic link, and adjusting a fare of the traffic link.
The accompanying drawings are included to provide a further understanding of the present invention, and are incorporated in and constitute a part of this specification.
The real-time traffic prediction system 100 incorporates real-time traffic data 105 into the TPT 130 which predicts traffic volume and speed (e.g., average speed) in a near future (e.g., 1 hour in advance). Real-time traffic data 105 includes, but is not limited to: the number of vehicles on the traffic link, average speed of the vehicles on the traffic link, etc. In one embodiment, the real-time traffic prediction system 100 receives the real-time traffic data via a wireless or wired communication network from a vehicle counter (e.g., Radar-based Field Vehicle Counter TC-RS50-D from SenSource, Inc.) that counts the number of moving and/or stationary vehicles on a portion of a road. In a further embodiment, the real-time traffic data may be an array format that includes multiple fields, i.e., one element in the array includes multiple fields (e.g., a road identification number, the number of vehicles on the road, a time and date when the vehicle counter counted the vehicles on the road, etc.).
Optionally, there is provided a module to run DEA (Data Expansion Algorithm). In one embodiment, there may be two separate entities to compute DEA: a real-time entity 120 and an offline entity 110. The offline entity 110 receives a collection of historical traffic data (e.g., last year's traffic data on the traffic link including, but not limited to, the number of incoming vehicles to the traffic link, the number of outgoing vehicles to each branch on the traffic link, etc.), e.g., from a database (not shown). The database may store the historical traffic data as a table (not shown) per traffic link. Upon receiving the historical traffic data (not shown), the offline entity 110 runs DEA and generates historical turning percentages 115 (i.e., proportions of turns taken by drivers in past, e.g., 25% drivers took right turn on the traffic link in the last year). The offline entity 110 may provide the generated historical turning percentages, e.g., in an array format in which an element having multiple fields. Each field in the array element may represent each turning percentage in the traffic link. Upon receiving the historical turning percentages 115 from the offline entity 110 and the real-time traffic data 105 from the vehicle counter (not shown), the real-time entity 120 runs DEA to compute likelihoods 125 that real-time incoming traffic to the traffic link are divided in the traffic link, i.e., probabilities of traffic splitting in the traffic link. For example, the real-time entity 120 sums traffic flows entering a node (intersection, for example) and then divides an outgoing traffic flow on each outgoing road link by the total traffic inflow at the node.
The real-time entity 120 may provide the computed likelihoods to the TPT 130, e.g., in an array format in which each element includes multiple fields. Each field in the array element may represent a probability that the real-time incoming traffic to the traffic link is divided at each branch in the traffic link. A co-pending and commonly owned U.S. Patent Application No. 2009-0099760, entitled “Method and system for expansion of real-time data on traffic networks,” wholly incorporated by reference as if set forth herein, describes DEA in detail.
Upon receiving the real-time traffic data 105, e.g., from the vehicle counter, and the computed likelihood 125 from the real-time entity 120, the TPT 130 estimates a traffic speed (e.g., average speed of vehicles) and volume (i.e., the number of vehicles) in the traffic link over a pre-determined time period (e.g., 1, 10, 15, 30, 45 or 60 minutes). In one embodiment, the TPT 130 estimates the traffic speed and volume in real-time, e.g., less than 5 minute delay, over an entire prediction stage (e.g., These estimated traffic speed and volume are available at least 1 hour before being used by the turning percentage prediction module 140 and/or the traffic microsimulation tool 160). In a further embodiment, the TPT 130 generates the estimated traffic speed and volume in the traffic link, e.g., in an array format in which each element has multiple fields. These fields in the array element include, but are not limited to, an identification number or symbol of the traffic link, the estimated traffic speed of the traffic link, the estimated traffic volume of the traffic link, etc. The TPT 130 provides the estimated traffic speed 145 to the turning percentage prediction module 140. The TPT 130 provides the estimated traffic volume 150 to the traffic microsimulation tool 160. Commonly owned, co-pending U.S. Patent Application Publication No. 2008/0175161 A1 filed on Jan. 24, 2007, wholly incorporated by reference as if set forth herein, describes a TPT in detail. Commonly owned, co-pending U.S. Patent Application Publication No. 2010/0063715 A1 filed on Nov. 16, 2009, wholly incorporated by reference as if set forth herein, describes a TPT in detail.
The turning percentage prediction module 140 receives the estimated traffic speed 145, e.g., in the array format generated by the TPT 130 as described above. Optionally, the turning percentage prediction module 140 also receives the historical turning percentage 115, e.g., in the array format generated by the offline entity 110 as described above. The turning percentage prediction module 140 uses the estimated traffic speed and/or the historical turning percentages 115 to estimate each turning percentage of incoming traffic at each intersection for predicting a traffic condition in a future time horizon. In one embodiment, the turning percentage prediction module 140 may generate its own historical turning percentages directly from the traffic predictions, e.g., according to an equation (19) described below.
Notation
At step 200 in
At step 215, if the turning percentage prediction module 140 determines that the traffic link is a congested regime, the turning percentage prediction module 140 evaluates a link topology of the traffic link. A link topology includes, but is not limited to the following link categories: a diverge link shown in
At steps 220-245, the turning percentage prediction module 140 estimates a turning percentage of the traffic link being evaluated according to the determined link topology. In one embodiment, if a traffic link (j,jld) is a congested regime, the turning percentage prediction module 140 computes a turning percentage, βj,j
If a relationship between a traffic flow (q) and a traffic density (k) is of a form
q=min{νk,qmax,w(kj−k)}, for 0≦k≦kj (1),
then a single traffic link can be approximated by a set of difference equations where current traffic conditions (e.g., real-time traffic data 105, estimated traffic speed 145, estimated traffic volume 150, and/or historical turning percentage 115) are updated at every time interval:
ni,j(t+1)=ni,j(t)+yi(t)−yj(t) (2)
Since ñi,j(t+1)=ni,j(t+1)+ζi,j(t+1), the equation (2) can be represented as
ñi,j(t+1)=ñi,j(t)+yi(t)−yj(t)+εi,j(t+1) (3),
where εi,j(t+1)=ζi,j(t+1)−ζi,j(t) that combines errors in vehicle count estimations on a traffic link (i,j) at time t+1.
The following describes how the turning percentage prediction module 140 derives yj
Source Boundary Link
A source boundary link is defined as a traffic link that enters vehicles into a traffic road. This source boundary link includes a location from where vehicles start a journey, for example, including, but not limited to: a public parking facility, parking lot, a city center, or neighborhood center, etc.
ño,i(t+τ+1)=ño,i(t+τ)+yo(t+τ)−yi(t+τ)+εo,i(t+τ+1) (4),
where yo(t) is a boundary input volume at time interval t+τ, given by
yo(t+τ)=min{din(t+τ),Qo,i(t+τ),(wo,i(t+τ))/νo,i(t+τ)))×(No,i(t+τ)−ño,i(t+τ))} (5)
Thus,
yi(t+τ)=ño,i(t+τ+1)−ño,i(t+τ)−yo(t+τ)+εo,i(t+τ+1) (6)
The turning percentage prediction module 140 computes a turning percentage βo,i in the exemplary source boundary link, e.g., by calculating yi(t+τ)/yo(t+τ).
Destination Boundary Link
A destination boundary link is defined as a traffic link that absorbs vehicles out of a traffic road. This destination boundary link may include an actual destination location of a vehicle including, but not limited to: a parking facility, a parking lot, a working place, a neighborhood center, etc.
yi(t+τ)=ñi,D(t+τ+1)+εi,D(t+τ+1) (7)
The turning percentage prediction module 140 computes a turning percentage βi,D in the exemplary destination boundary link, e.g., by calculating yD(t+τ)/yi(t+τ).
Ordinary Link
An ordinary link is a traffic link that has one incoming and one outgoing branch.
yi
Otherwise, if yi(t+τ), the inflow of node i at time interval t+τ, is unknown,
yi(t+τ)=min{nñi
Thus,
yi
The turning percentage prediction module 140 computes a turning percentage βi,i
Merge Link
A merge link is a traffic link that has more than one incoming branches.
In
Otherwise, if yii
for ∀lεΓ−1(i),
where pi
Thus,
The turning percentage prediction module 140 computes a turning percentage βi,i
yii
Diverge Link
A diverge link is a traffic link that has more than one outgoing branches.
yi
Otherwise, if yi(t+τ) is unknown, the inflow of node i to downstream node ild for link (i, ild) can be derived from the existing vehicles and outflow of this link:
yi
And,
Thus, turning percentage prediction module 140 computes a turning percentage βi,i
Returning to
In a free flow regime, a turning percentage in other link topologies (e.g., merge link, ordinary link, destination boundary link, and source boundary link) is equal to 1 since there is no congestion in the traffic link.
Returning to
In one embodiment, the historical turning percentage remains constant over a period of time (e.g., 1 day or 1 week). George H. Born, “Gauss-Markov Theorem,” Dec. 8, 2004, http://ccar.colorado.edu/ASEN5070/handouts/Gauss_Markov—2004.pdf, whose contents are wholly incorporated by reference as if set forth herein, describes Gauss-Markov Theorem in detail.
Returning to
{circumflex over (β)}i,i
Returning to
In one embodiment, the traffic microsimulation tool 160 computes the expected traffic volume in the traffic link based on the historical turning percentage computed at step 250 in
In one embodiment, the traffic microsimulation tool 160 receives the turning percentage 155 and the estimated traffic volume 150 in advance, e.g., 1 hour earlier from starting its computation for a traffic link. Thus, the traffic microsimulation tool 160 completes one or more simulations of possible traffic outcomes based on one or more scenarios. The simulations may project the impact on traffic conditions and the relative effectiveness of different possible actions on the traffic link being evaluated. Returning to
In one embodiment, the real-time traffic prediction system 100 operates according to a rolling horizon approach as shown in
A graph 535 in
Outputs of the function (21) is a predicted traffic volume (ñ(t+τ)/Δ) in the traffic link and a predicted traffic speed ({tilde over (ν)}(t+τ)) in the traffic link in a subsequent rolling period, where Δ is the length of the rolling period. The corresponding traffic link density and shockwave speed w can be derived as D(t)=G−1(V(t)) and
respectively.
In one embodiment, the real-time prediction system 100 does not use an origin-destination matrix (not shown) that represents every traffic link with its origin and its destination. The real-time prediction system 100 reduces computation times compared to traditional traffic prediction systems and reduces resource requires (e.g., memory storage) because data (e.g., computed turning percentage 155, real-time traffic data 105, estimated traffic speed and volume) are not stored in any a memory or storage device (not shown) but directly provided from its generating component (i.e., a component generating the data; e.g., TPT 130) to its receiving component (i.e., a component receiving the data; e.g., the turning percentage prediction module 140), e.g., via a wired or wireless communication link (e.g., a communication link 145).
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a system, apparatus, or device running an instruction.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a system, apparatus, or device running an instruction.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may run entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which run via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which run on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more operable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be run substantially concurrently, or the blocks may sometimes be run in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Number | Name | Date | Kind |
---|---|---|---|
5646853 | Takahashi et al. | Jul 1997 | A |
7236881 | Liu et al. | Jun 2007 | B2 |
7363144 | Liu et al. | Apr 2008 | B2 |
20080069000 | Muck | Mar 2008 | A1 |
20080175161 | Amemiya et al. | Jul 2008 | A1 |
20090099760 | Lederman et al. | Apr 2009 | A1 |
20100063715 | Wynter et al. | Mar 2010 | A1 |
Entry |
---|
Barcelo, J., et al., “Online Microscopic Traffic Simulation Supports Real-time Traffic-management Strategies”, Siam News, 2007, vol. 40, No. 9. |
Van Gasteren, et al., “The Binary Search Revisited”, Educational Issues of Formal Methods Academic Press, 1996. |
Jain, A.K., et al., “Data Clustering: a Review”, ACM Computing Surveys, Sep. 1999, vol. 3, No. 31. |
Ziliaskopoulos, A., “A Linear Programming Model for the Single Destination System Optimum Dynamic Traffic Assignment Problem”, Transportation Science, Feb. 2000, pp. 37-49, vol. 34, No. 1. |
Born, G.H., “Gauss-Markov Theorem”, http://ccar.colorado.edu/ASEN5070/Handouts/Gauss—Markov—2004.pdf, Dec. 8, 2004. |
Gerstman, B., “Regression” in StatPrimer, http://www.sjsu.edu/faculty/gerstman/StatPrimer/regression.pdf, Mar. 4, 2004. |
Lederman, R., et al., “Real-Time Traffic Estimation Using Data Expansion”, Elsevier, Apr. 26, 2010Man, R., et al., “Real-Time Traffic Estimation Using Data Expansion”, Elsevier, Apr. 26, 2010. |
Murphy, K.P., “Linear Regression”, http://citeseerx.ist.psu.edu/viewdoc/similar?doi=10.1.1.121.3661, Mar. 13, 2007. |
Williams, C.A., et al., “Mining Sequential Association Rules for Traveler Context Prediction”, International Conference on Mobile and Ubiquitous Systems Proceedings of the 5th Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking, and Services, ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2008. |
Alford, B., et al., “An Analysis of Various Spline Smoothing Techniques for Online Auctions”, AMSC Interaction Team 689, Dec. 10, 2004. |
Daganzo, C.F., “The Cell Transmission Model, Part II: Network Traffic”, Transpn. Res.-B, 1995, pp. 79-93, vol. 29B, No. 2. |
Hahn, K., “Lagrange Multiplier Method for finding Optimums”, http://www.karlscalculus.org/pdf/lagrange.pdf, 2008. |
Liao, L., et al., “Learning and Inferring Transportation Routines”, Artificial Intelligence, Apr. 2007, pp. 311-331, vol. 171, Issue 5-6, Elsevier Science. |
Newell, C.J., et al., “Appendix A.2: Statistical Trend Analysis Methods”, Air Force Center for Environmental Excellence, AFCEE Monitoring and Remediation Optimization System Software, Version 2.2, Feb. 2007. |
Williams, C.A., “A Data Mining Approach to Rapidly Learning Traveler Activity Patterns for Mobile Applications”, Ph.D. Dissertation, Department of Computer Science, University of Illinois at Chicago, Apr. 2010. |
Number | Date | Country | |
---|---|---|---|
20120109506 A1 | May 2012 | US |