Congestion

[jkarpen]

Congestion Pie Algorithm When configured to do so, PeMS attempts to assign causes to the observed congestion on the freeway system. The congestion pie algorithm is an optional component of PeMS which requires the incorporation of an incident data set. Please refer to your system documentation to determine if this feature has been enabled.

We commonly represent the breakdown of the congestion into different slices of a pie and hence we refer to this as the Congestion Pie Algorithm (CPA). The main references for this algorithm are:

• The Congestion Pie: Delay from Collisions, Potential Ramp Metering Gain, and Excess Demand. Kwon, J. and Varaiya, P. TRB 84th Annual Meeting, Washington, D.C., January 2005.
• Measuring recurrent and non-recurrent traffic congestion. Skabardonis, A., K. Petty, and P. Varaiya. TRB 82nd Annual Meeting, Washington, D.C., January 2003.

The CPA tries to assign the delay on the freeway to one of three large categories:

• Collisions: The delay caused by accidents. For this feature, PeMS uses the set of all all accidents that take place on the freeway system. Accidents account for a large fraction of the delay on the freeway system.
• Bottlenecks: The delay caused by bottlenecks. We define bottlenecks as anything caught by our bottleneck identification algorithm. The cause of a bottleneck on any one day is unknown. It could be an accident, a weaving or merging section, or a change in capacity. In the complete algorithm that we describe below we decompose the bottleneck delay further.
• Miscellaneous: This is all of the delay that can't be assigned to either of the two previous categories.

Obviously, there are many other factors that contribute to delay on the freeway that are not represented in the list above. They include adverse weather condition (e.g., rain, snow, and fog), special events (e.g., sport events and concerts), and lane closures. These are not incorporated in the current model mostly due to the lack of available data on them.

A couple of notes about how we run the algorithm before we describe it:

• The input data for the algorithm are: 1) the PeMS detector data, 2) the incident records, and 3) the bottleneck activation times and durations as identified by the bottleneck identification algorithm.
• The spatial unit of analysis is county-freeway-direction (e.g. Alameda-880-N).
• The congestion pie is constructed for each quarter (due to the way that we are computing the congestion pie it's not possible to further subdivide the temporal range).
• We construct the pie for the AM (5am-10am), noon (10am-3pm) and PM (3pm-8pm) shifts.
• We only use data from non-holiday weekdays.
• Since we require incident data for the algorithm, we only run the CPA for quarters where we have incident data. It should be pointed out that most incident data sets lag real-time significantly. You should check out the data inventory page to see where incident data has been collected.
• The steps that we follow to compute the congestion pie are as follows:

Compute Total Delay, Dtot

• For each county-freeway-direction we compute the average daily delay with respect to 60mph in the quarter.

Compute Delay Due to Collisions, Dcol

• We extract the number of collisions per day from the incident data set provided by the agency.
• We compute a straight linear regression relating the delay on each day to the number of collisions. The intercept, alpha, is the average daily delay for a collision-free day.
• We compute the delay due to collisions, Dcol = Dtot - alpha (limited below by zero, of course).

Compute Delay Due to Bottlenecks, Dbn

• We take the recurrent bottleneck locations that are active more than 20% of the days in the quarter.
• For these bottlenecks we estimate the average daily delay due to the bottleneck, Bbn, from the results of the bottleneck identification algorithm.
• We limit Dbn such that Dbn + Dcol <= Dtot

We compute the miscellaneous delay, Dmisc

• Any delay that we can't assign to either bottlenecks or collisions we call miscellaneous delay.
• This delay can be due to a wide variety of factors, including weather, lane closures, etc.
• By definition this is Dmisc = Dtotal - Dcol - Dbn.

We subdivide Dbn into potential delay savings, Dpot, and excess delay, Dexcess

• For each corridor, if there are any bottlenecks in the corridor then we compute the potential savings that we can get from running an ideal ramp metering algorithm at each bottleneck.
• An ideal ramp metering algorithm is a ramp metering strategy that restricts the rate at which vehicles can enter the freeway such that the traffic at this location operates at capacity.
• We define capacity as the maximum observed 15-minute flow at each location (we measure this).
• The result of restricting the demand at the bottleneck is that the freeway operates at free-flow conditions and the delay on the freeway is reduced to zero.
• The side effect of this is that the vehicles that have to wait at the ramps incur delay. This is delay that is simply due to too many vehicles attempting to use the freeway at the same time. We call this the excess delay, Dexcess.
• The difference between the bottleneck delay, Dbn, and the excess delay, Dexcess, is the potential delay savings due to running an ideal ramp metering algorithm. Dpot = Dbn - Dexcess.

We can now draw the complete congestion pie

• Dtot = Dcol + Dpot + Dexcess + Dmisc

The current implementation has the following limitations among others:

• As we mentioned above, we don't have information about weather, lane closures, or special events. Hence we can't assign any delay to those causes.
• We rely on the incident data set provided to us by the local agency. If this is incomplete or incorrect then it can bias our results.
• The incidents are (presumably) collected from the entire stretch of freeway in a county. In other words, there aren't sections of a freeway where incidents take place and then systematically aren't reported into incident data set provided by the agency. Unfortunately, the same is not true about the detection system. The detectors are in fixed locations on the freeway and they cover, or monitor, a fixed section. Hence there are sometimes large sections of a freeway that are unmonitored from a PeMS point of view. This leads to a mismatch between the regime covered by fixed measurement devices and the regime covered by the incident data collection. This can obviously lead to incorrect results.
• The Ideal Ramp Metering Algorithm (IRMA) that is used to compute the excess delay and the potential delay savings, relies on many ideal assumptions, which include:
• The ramps at each location have enough storage capacity to hold all the metered vehicles.
• It's politically feasible to run this algorithm.
• Drivers don't take any sort of detours or diversions.
• Thus, the potential delay savings result needs to be interpreted with care as an estimate of the maximum savings possible (rather than realizable savings).

[junlee-analytica]

Pending progress from #186

[jkarpen]

@britt-allen moving into next sprint (2024-15) but this is lower priority than the items you already have assigned. Reminder to meet with Ken and scope this out when time allows.

[kengodleskidot]

I added @thehanggit since he has a background in congestion and is ready to get started in dbt.