This simulation is a small digital twin of a road network: a 3×3 grid of signalised intersections connected by two-way streets. Vehicles spawn at the twelve edge entry points at a configurable arrival rate, are routed toward a random exit point, and physically queue behind red lights — cars stack up bumper-to-bumper when the light ahead is red and flow forward at a capped rate once it turns green, exactly like a real approach lane.
Two signal-control strategies can be run and compared. Fixed-time control cycles every intersection between north–south green and east–west green on a rigid timer, regardless of demand. Adaptive control uses a simple actuated-signal rule: each intersection reads the live queue length on every approach and keeps the current direction green as long as it still has queued traffic and the maximum green time hasn't been reached; once that limit is hit, or the queue on the red approach exceeds the green approach's queue, it switches. Run each mode, watch vehicles in system, completed trips, average wait time and throughput update live, and compare the resulting average wait time between the two strategies once you've run both.
What does "adaptive" or actuated traffic signal control actually mean in real deployments?
An actuated signal uses sensors — inductive loops cut into the road surface, video detection, or radar — to detect vehicles present on each approach and adjust the signal timing in response, instead of running a pre-set fixed cycle. The simplest actuated logic, which this simulation implements, holds a phase green while vehicles keep arriving on that approach (extending green up to a maximum) and switches once the demand shifts to the other approach. Real deployments add extra sensors placed a few seconds upstream of the stop line so the controller can decide whether to extend green before the last car in the platoon arrives, avoiding an unnecessary stop.
Why do fixed-time signals waste green time?
A fixed-time controller allocates a rigid, pre-computed split of the cycle to each direction — for example, 20 seconds north–south and 20 seconds east–west — based on average expected demand. But real traffic arrives unevenly: at 2am a direction with zero cars still gets its full 20 seconds of green while the perpendicular direction (even if empty too) sits on red. During rush hour the reverse happens: a heavily loaded direction still only gets its fixed share even though the queue is growing every cycle. Because the split can't respond to what's actually waiting at the stop line right now, fixed-time signals systematically give green time to empty approaches while congested approaches overflow.
What is a digital twin, and how does this relate to smart-city traffic planning?
A digital twin is a live, continuously updated software model of a physical system — in this case a small road network — that mirrors its real dynamics closely enough to test "what if" scenarios before touching the real world. City traffic engineers build much larger versions of exactly this idea (tools like SUMO, VISSIM or Aimsun) to simulate an entire district's signals, feed them real sensor data, and trial a new signal-timing plan or adaptive-control algorithm in simulation first, because a bad change deployed live can gridlock a city for hours. This page is a minimal, transparent version of that same workflow: a model you can inspect, tune and re-run instantly.
Traffic arrivals aren't smooth — they're bursty. Even if the long-run average arrival rate is comfortably below what the grid can process, vehicles don't arrive at perfectly even intervals; by chance several cars cluster together on one approach while another sits empty. Queueing theory shows that as utilisation (demand ÷ capacity) climbs toward 1, the variability in arrivals causes queue length and wait time to grow non-linearly, not linearly — a network running at 90% of capacity on average can still produce large, visible queues purely from random clustering, well before the "textbook" capacity limit is reached. Try raising the arrival rate slider gradually and watch queues appear well before the grid is nominally saturated.
Surtrac, developed at Carnegie Mellon and deployed across Pittsburgh, extends the same core idea — read real-time demand, allocate green accordingly — with a decentralised scheduling optimisation at each intersection that predicts each vehicle's arrival time (not just whether a queue exists) and computes a short rolling schedule of phase switches that minimises total projected delay, then communicates that plan to neighbouring intersections so green waves can form dynamically across the corridor rather than each junction acting alone. Field deployments reported double-digit percentage reductions in travel time and braking events. This simulation's rule — extend while the current direction still has demand, else switch to whichever side has the longer queue — is the conceptual seed of that system, without the predictive scheduling or intersection-to-intersection coordination.
Wait time (delay) for a trip is the total simulated time that vehicle spent stationary — queued behind another car or stopped at a red light — summed across its whole journey from entry to exit, excluding time spent actually moving. This matches how traffic engineers typically define control delay at a signal. The simulation accumulates this per vehicle as it travels and only folds a completed trip's wait time into the running average once that vehicle has reached its destination and left the network, so the "avg wait time" stat reflects genuinely finished trips, not vehicles still queued mid-journey.
This is a deliberately simplified model: it has no turning-movement restrictions beyond the routed path, no pedestrians, no left-turn phases or protected turns, uniform vehicle behaviour (no trucks, cyclists or varying driver aggressiveness), and a single fixed free-flow speed with a simple minimum-gap car-following rule rather than a calibrated driver model. Real tools such as SUMO or VISSIM model individual lane geometry, acceleration/deceleration curves, driver reaction time, and validate arrival patterns against measured sensor data before any signal-timing change is trusted. What this simulation preserves faithfully is the core mechanism that makes adaptive control outperform fixed-time control: reading real queue state and allocating green time to where the demand actually is.