SUMO lets a traffic controller advance the clock

A green light cannot empty a blocked junction. In SUMO, the open-source traffic simulator, testing a better signal controller means connecting several distinct things: a road network, vehicles trying to use it, a clock, and code that changes the lights. Following those connections explains what the controller actually controls—and why an attractive journey-time result can leave the worst queue out of view.[1][4][9]

SUMO models individual vehicles and their interactions. Its surrounding tools build networks and prepare demand; an external program can then intervene while the simulation runs. An independent tutorial by Davide Andrea Guastella and colleagues makes the preparation visible: importing roads, defining trips, assigning routes, and configuring outputs are separate stages. A recognizable street map is only the beginning of a traffic experiment.[1][2]

DLR monitoring equipment mounted above a snowy Braunschweig intersection, with cars blurred in motion below. — DLR's research intersection in Braunschweig, where researchers study interactions among drivers, pedestrians, and cyclists. Such observed interactions give traffic models something to be checked against. Photograph credit: Jenoptic / DLR.[10]

The junction has an interior

Consider an illustrative experiment: a controller that extends the green light when a queue builds on one approach. The experiment is hypothetical; the photograph identifies a real research site, not a claimed deployment of this controller.

SUMO receives the road network through --net-file and traffic demand through --route-files. Additional files can supply signal programs, detectors, and other infrastructure. Route files are normally read incrementally, so departures must be ordered by time. These are different inputs with different jobs: knowing where a road goes does not establish how many people will use it.[3]

The space between the stop lines matters too. SUMO normally represents movement through junctions with internal lanes. If internal links are disabled, vehicles still obey signals and right-of-way rules, but jump across the intersection after passing the stop line. They cannot wait or obstruct one another inside it.[4]

For our proposed controller, that is a consequential change. If the research question concerns vehicles blocking the middle of a junction, removing its interior removes part of the phenomenon being tested. A clean-looking animation could therefore reflect a simpler model rather than a better green-time decision. This is an inference from the documented model behavior, not a performance claim about a particular controller.

The external program advances simulated time

TraCI, the Traffic Control Interface, connects an external client to SUMO over TCP. The simulator exposes operations for reading its state and changing it. A client might inspect a detector, choose whether to extend a green, and call simulationStep() to advance the world before observing again.[5]

That call is a synchronization point. In a setup with several clients, all must request the next step before the simulation advances; each also specifies an execution order. A controller and another participating application consequently share a clock, with an explicit order for their commands. If one client stops reaching the synchronization point, the others cannot simply continue simulating future traffic.[5]

Clock resolution is a separate setting. SUMO's default step is one simulated second; --step-length can make it smaller. More frequent steps also mean more opportunities for insertion, lane changes, and, by default, speed adaptation. Reducing the interval changes model execution as well as computational cost. It should therefore be recorded as an experimental setting, not treated as a cosmetic smoothness control.[3]

TraCI also changes shutdown responsibility: the server ignores --end, leaving the client to close the simulation. getMinExpectedNumber() helps detect when demand has been exhausted and vehicles have left. A control loop needs an explicit stopping condition.[5]

Changing green comes with a transition

A traffic-light state in SUMO describes signals controlling lane-to-lane connections. One approach can contain several movements, so selecting a light by the road's name is insufficient; the connection indices matter.[6]

The documented adaptive-control pattern preserves a signal program in the simulator. Give its green phases long durations, then use traci.trafficlight.setPhase() to enter the appropriate yellow transition when the controller decides to end a green. SUMO can run the configured yellow and all-red phases before the next green. The script chooses when to release the approach while the program retains the transition sequence.[6]

There is a more direct interface, setRedYellowGreenState(). After that call, SUMO holds the supplied state until further instructions or a program change. The script becomes responsible for every phase and transition. These two APIs therefore allocate different work to the controller: choosing a transition versus supplying the complete changing signal state.[6]

For the illustrative queue experiment, I would begin with a reviewed phase program and change only the green-extension decision. That keeps a mistaken transition from becoming an unacknowledged second experiment.

Crossing the process boundary costs time

Repeated TraCI requests cross a process boundary. When this overhead matters, libsumo offers access to the simulator as a library, with a closely related API. Python scripts can often use import libsumo as traci, subject to documented differences.[7]

This is a deployment choice with constraints. Libsumo has stricter type handling, limitations around GUI operation, and different arrangements for multiple clients; parallel Python simulation instances require multiprocessing. The familiar function names should not be read as a promise that every existing orchestration pattern transfers unchanged.[7]

For a small research team, a sensible progression is to make one junction understandable first, then measure where batch runs spend their time. Moving to libsumo can address communication overhead. It cannot correct a missing turning movement or establish that synthetic demand resembles the street.

Count the vehicles still waiting

The final interface is the result file. SUMO may delay a vehicle's insertion when there is insufficient space at its departure point. That vehicle waits in an insertion queue, and its eventual departDelay records time spent waiting to enter. Demand supplied to the model is therefore not identical to traffic already moving within it.[8]

TripInfo introduces another distinction. By default, a vehicle receives a trip record when it arrives. Vehicles still travelling when a run stops do not appear unless unfinished-trip output is enabled with --tripinfo-output.write-unfinished.[9]

Suppose two controllers run for the same fixed period. One clears a lightly used approach quickly but leaves a busy approach congested. Comparing only completed journeys could reward the easy trips while overlooking the vehicles still stuck. That is a selection problem implied by the output rule; it is not evidence that SUMO itself reports a false measurement.

Read completed trips alongside unfinished traffic and insertion delays. Also choose the quantity deliberately: waitingTime measures near-standstill time, whereas timeLoss includes driving below the vehicle's ideal speed. They answer different questions.[9]

The independent tutorial's emphasis on real demand data is a useful final constraint: an experiment needs evidence about who travels, not just a road network that looks familiar.[2] Keep those inputs, the controller, and the SUMO release together; the online manual describes ongoing development, while release downloads include their own documentation.[1] The controller can advance the simulated clock. Establishing what that experiment says about a real junction remains the researcher's job.

cronfeed.work