TransportBench Suite: Modular Transit Simulation

• TransportBench Suite is a modular simulation framework designed for comparative evaluation of various transit operations using controlled demand scenarios.
• It integrates a discrete-event simulation kernel with core modules like demand generation, fleet management, and dispatch routing to benchmark routing strategies and vehicle assignment policies.
• Its extensible design supports diverse network topologies and service models, offering reproducible research insights and clear tradeoffs among transit paradigms.

TransportBench Suite is an open-source, modular simulation framework designed for rigorous, comparative evaluation of public and personal transit operations, including fixed-route, semi-flexible, on-demand microtransit, and personal rapid transit (PRT) network scenarios. The suite enables systematic benchmarking of management-level heuristics, routing strategies, and vehicle assignment policies under controlled input and demand scenarios, facilitating reproducible research and operational insight into transit network performance (Mieścicki et al., 2017, Yoon et al., 2021).

1. System Architecture and Workflow

TransportBench Suite is built around a modular, discrete-event or discrete-time simulation kernel that supports a variety of transit paradigms and can be extended for new network layouts or algorithms. The architecture consists of four core modules:

• Demand Generator: Synthesizes trip requests either by Poisson process or from explicit OD-lists. Each request is characterized by origin and destination coordinates, group size, and status.
• Fleet & Vehicle Manager: Maintains dynamic records of all vehicles, their locations, route plans, real-time loads, and segment slack-times (in flexible services).
• Dispatch & Routing Engine: Manages vehicle assignment and route planning according to user-selected policies: fixed-route, flexible-route (extended MAST), or on-demand microtransit. Optionally incorporates insertion heuristics and capacity/detour/wait-time feasibility constraints.
• Simulation Controller: Advances the system state in discrete time steps (e.g., Δt = 1 s), triggers event updates, processes arrivals, manages vehicle movement, passenger status, and logs system metrics.

Output and analysis modules aggregate and post-process run statistics, supporting batch scenario sweeps and CSV/MATLAB-format export (Yoon et al., 2021).

2. Reference Network Models and Topological Benchmarks

To support algorithmic comparability, the suite incorporates canonical PRT network topologies as reference models:

• City Model: A 12-station network with peripherally placed capacitors and roundabouts; two principal loops—one inner-downtown (diameter 3,000 m) and an outer double-track highway (diameter 4,000 m) with 2,000 m radial spurs. Total track-length ≈ 52,000 m.
• SeaShore Model: A linear double-track corridor of 4 beachfront stations (2,000 m apart) with four 1,000 m branches to inland resort stations. Total track-length ≈ 30,400 m.
• TwinCity Model: Dual circular “campus” sub-networks (each with 4 stations and a capacitor), single-track rings (diameter 1,400 m), chords across rings, and a double-track 3,000 m connector. Total track-length ≈ 23,000 m (Mieścicki et al., 2017).

These spatial templates are designed for plug-and-play evaluation of routing, loading, and scheduling heuristics.

3. Service Models and Algorithmic Scenarios

TransportBench supports three principal transit service paradigms:

• Fixed-Route Transit: Vehicles run on a predetermined stop list at optimized headways/frequencies. The objective function jointly considers operator cost and user time penalties. Route-cycle time is

$t_c = \frac{L}{v_o} + S\,(t_s + \beta\,\bar{n})$

where $L$ (route length), $v_o$ (speed), $S$ (number of stops), $t_s$ (dwell delay), $\beta$ (per-passenger dwell), $\bar{n}$ (mean pax/load per stop).

• Semi-Flexible (Extended MAST): Vehicles must only visit "checkpoints" but may detour within segment slack-time and a global backtracking budget. Passengers off the baseline may be picked up if insertion is feasible (capacity, slack, wait constraints). Segment slack is

$$\Delta t^{slack}_\ell = t^{sched}_\ell - \frac{d_\ell}{v_o}$$

• On-Demand Microtransit: No fixed routes. Vehicle-passenger assignments use insertion heuristics to identify feasible pickup/delivery slots, subject to vehicle capacity, rider wait-time ($J_w$), and detour constraints ($\delta$ for detour ratio). For each active route of $n$ stops, there are $\frac{n(n+1)}{2}$ insertion position pairs.

Empty-vehicle management, routing, and coordination (collision avoidance, docking, buffer management) are user-selectable and can be systematically varied in simulation (Yoon et al., 2021, Mieścicki et al., 2017).

4. Demand, Vehicle, and Passenger Generation Parameters

Arrival streams are modeled as stationary Poisson processes, with group sizes uniformly distributed over {1,2,3,4} (mean 2.5). Key baseline parameters for PRT scenarios include:

• Fleet size: 30–60 vehicles (parameter sweep recommended).
• Vehicle specs: Capacity = 4, max speed = 10 m/s (ordinary track), 15 m/s (highway), acceleration = 2 m/s², separation = 10 m.
• Station configuration: 5 berths per node, entry/exit buffer = 5.
• Boarding/alighting: triangular(10 s, 20 s, 30 s).
• Passenger arrivals: Station-rate $\lambda_i$ determined by local density (e.g., downtown = 3,000 inh/km² → λ ≈ 42 groups/h per station).
• Operational equilibrium: Input load should remain ≤0.5 × network maximum capacity for comparability (Mieścicki et al., 2017).

Flexible and microtransit simulation parameters additionally include virtual stop walk thresholds ($J_a$), slack, backtracking, max wait, and detour ratios (Yoon et al., 2021).

5. Experimental Protocols and Performance Metrics

Comparative experiments are configured to ensure Caeteris Paribus evaluation across algorithms:

• Input scenarios: Stationary Poisson demand, uniform OD distribution, single-destination per group, no ride-sharing (for PRT scene).
• Parameter sweeps: Fleet size $N$, load factor, empty-vehicle management settings, buffer sizes, speed limits, dwell time randomization.
• Replication: Multiple independent runs (≥ 30) for statistic confidence estimation.

Core system-level metrics include:

Metric	Formula	Description
Avg. waiting time ($W$)	$$W = \frac{1}{N_p} \sum_{k=1}^{N_p}(t_{pickup,k} - t_{arrival,k})$$	Wait before pickup
Avg. trip/in-vehicle ($T$, $V$)	$$T = \frac{1}{N_p} \sum_{k=1}^{N_p}(t_{dropoff,k} - t_{pickup,k})$$	Time spent in vehicle
Avg. access/walking ($A$)	$A = \frac{1}{N}\sum_{i=1}^N a_i$	Walk time to/from stop
System throughput ($\Theta$)	$\Theta = N_p / T_{sim}$	Groups/passengers per hour
Vehicle utilization ($U$)	$$U = (1/N_v)\sum_{j=1}^{N_v}(busy_{time,j} / T_{sim})$$	Fraction of time vehicle is busy
Vehicle-miles traveled (VMT)	$VMT = \sum_v \sum_t \Delta d_v(t)$	Total vehicle distance
Weighted travel time ($Y$)	$Y = Y_a A + Y_w W + Y_v V$	Weighted by value-of-time

Buffer wait levels, network occupancy, and fraction served are also reported (Yoon et al., 2021, Mieścicki et al., 2017).

6. Case Study, Open-Source Implementation, and Comparative Insights

A representative application is the Brooklyn B63 corridor evaluation, which exercised fixed-route (existing and optimized), semi-flexible (MAST, Sc=10 and 20 checkpoints), and on-demand microtransit configurations under three demand levels ($\lambda=$ 80, 200, 400 pax/h). Fleet and vehicle parameters, as well as simulation horizon, were systematically prescribed (Yoon et al., 2021).

Open-source implementation is available in MATLAB: (https://github.com/BUILTNYU/FTA_TransitSystems), with scenario configuration and result export routines. Reproduction involves editing scenario files, executing the main simulation, and post-processing aggregated outputs.

Key comparative findings include:

• Fixed-route yields highest served ridership and lowest VMT at the cost of relatively higher passenger travel times.
• Headway/stop optimization dramatically reduces VMT with marginal impact on average travel time, particularly effective at lower demand.
• Semi-flexible (MAST) designs serve more passengers via off-route accommodation but exhibit increased average trip times due to detours.
• On-demand microtransit achieves the lowest user times but incurs much higher VMT (up to 2–3×) and substantial request rejection rates under limited fleet size.

Metric comparisons (rounded):

Demand (pax/h)	Fixed-Ex	Fixed-Opt	Flex(20cp)	Flex(10cp)	OnDemand
Ridership (80)	61.9	61.9	70.0	71.0	47.6
Ridership (400)	243.5	243.5	291.5	329.3	210.8
VMT (400)	335.7	228.8	362.9	423.4	1072.5
$Y$ (400, min)	58.9	58.9	71.4	77.1	53.5

These results delineate key tradeoffs among paradigms vis-à-vis operational cost, user time, and coverage/efficiency (Yoon et al., 2021).

7. Extensibility and Community Guidelines

The suite's specification encourages community-driven extensions:

• Network topology: Addition of grids, trees, mixed-mode nodes.
• Demand variation: Non-stationary rates, surge profiles, novel OD structures.
• Ridesharing and multi-stop routing: Inclusion of multi-group assignments.
• Intermodal simulation: Integration with bikeshare, on-demand buses.
• Standardization: Adoption of JSON/XML for input/output interoperability (Mieścicki et al., 2017).

Guidelines for replicable experimentation include systematic scenario sweeps, parameterized control strategies, and statistical reporting to support robust, Caeteris Paribus benchmarking across algorithms and service models. The explicit adoption of reference networks and performance metrics underpins methodological rigor and result comparability.

---

References:

(Mieścicki et al., 2017, Yoon et al., 2021)