Overview
In public transport, bus bunching refers to a group of two or more transit vehicles (such as buses or trains), which were scheduled to be evenly spaced running along the same route, instead running in the same location at the same time. Dave Sprogis, Volunteer Software Developer, and Data Analyst in Watertown, MA, used AnyLogic to confirm his thesis that preventing "Bus Bunching" would improve the experience of public transit bus riders. Specifically, he proved that long waits at bus stops would be eliminated and bus crowding would be dampened by preventing minor delays to an individual bus before they snowball into the phenomenon we call "Bus Bunching."
Problem
Residents of Watertown, MA, have long complained about poor service on the bus routes that service the town. Knowing that the Massachusetts Bay Transportation Authority (MBTA) that serves Watertown had published an API through which real-time bus data could be collected, Dave volunteered to build a SaaS system to collect it into a data warehouse for analysis. The results of the analysis were clear, buses lost significant efficiency servicing the route when they bunched together, typically at Rush Hour when riders needed consistency and reliability most.
While the results were convincing, a solution remained elusive. Should full buses skip past riders waiting at stops allowing a trailing bus to pick them up? Should bus schedules be updated to reflect dynamically changing road conditions and rider demands? Alternatively, could simply slowing buses to prevent Bus Bunching pay dividends in the long run?
Solution
Dave had a hunch that slowing buses would pay dividends but needed a way to prove it. Proving it would require simulation because the problem is not deterministic. Dave wanted to observe the impact of slowing the bus on the overall rider experience. What are the trade-offs? For example, would reducing wait times increase the ride time for passengers and to what degree? Moreover, if the ride times are increased, wouldn't the passenger loads increase as well? Only through simulation in which variables can be tweaked and results measured, could these questions be answered.
Dave modeled an existing route using AnyLogic's GIS features. The model allows Dave to simulate the current situation and his proposed solution, collecting metrics in both scenarios and comparing the results. Dave developed the model with the following components:
- Bus stops.
- Buses, bus behavior, and operation constraints.
- Riders and rider behavior.
- Trips.
The model also includes parameters that can be adjusted before and during run-time (i.e. number of riders, rider load time, rider unload time, max bus speed, and the choice between two policies).
Outcome
The model allows Dave to visualize the problem and proposed solutions. The best results were seen in the solution Dave titled “equilibrium,” which is to devise a way to maintain distances between buses. Using the equilibrium policy, buses will no longer follow the route freely, but by making continued adjustments and slowing down or stopping until sufficient space in front of them is available.
When the “equilibrium” policy is used, the number of riders on each bus is more uniform and the wait time is a more predictable distribution, which eliminates excessively long wait times and dampens overcrowding of buses.
Dave recommends that the MBTA implement “uber-fication” of buses – a simple “connected” app that advises drivers when to wait based on network metrics, enforcing the “equilibrium” policy.
The transition from Insight to Action is often unclear. Implementation can be costly and/or risky. Simulation, where applicable, is a great middle step, refining direction and creating confidence before investments are made. Sharing the AnyLogic model with the MBTA will assist decision makers in visualizing the problem and the proposed solution, ultimately improving service for riders.