traffic-signal-control

How it is built

Architecture overview

A traffic signal control system decides, second by second, which movements at a junction get green, and over minutes and hours how long cycles are, how green is split between approaches and how neighbouring junctions are offset so that platoons meet green lights. It runs at three layers. A local controller in the roadside cabinet holds the phase logic, reads detectors and drives the lamps; it must work alone. A safety monitor independent of that logic forces a flashing state if the outputs would show conflicting greens. A central or regional layer collects detector data, optimises cycle, splits and offsets, and sends them down; if it fails the controller falls back to its own timing plan. The one idea that makes it work is the split of duties: fast, local, safety-critical decisions stay in the cabinet, slow, networked optimisation sits above and only ever adjusts parameters inside limits the controller enforces. SCOOT, SCATS and SURTRAC are the best-documented adaptive systems; ATSPM and SUMO are the open tools for measuring and testing.

Parts:

• Detection — vehicle presence, counts and occupancy from loops, radar or video — Object detection, Multi-object tracking, Kalman filter, Non-maximum suppression, Assignment problem (Hungarian), Robust statistics, change-point-detection (no page yet), Convolutional networks
• Local controller — phases, rings, min/max green, clearance, pre-emption — ring-barrier-phase-controller (no page yet), Hierarchical state machine, Fixed-rate control loop, Clock synchronization
• Safety — conflict monitoring, watchdog, safe flash — Watchdog timer, safety-monitor-architecture (no page yet), fault-detection-isolation-recovery (no page yet), redundancy-voting (no page yet)
• Adaptive optimiser — cycle, split, offset from predicted flow — signal-split-cycle-offset-optimization (no page yet), Time series forecasting, Exponential smoothing, queueing-theory (no page yet), Policy gradient (PPO) for learned controllers
• Central system and data — configuration, logs, performance measures, remote updates — Time-series chunk storage, Gorilla XOR compression, Time partitioning, Rollup aggregation, Primary-backup replication, Health checking, Mutual TLS, A/B partition OTA updates, Signed update metadata, mqtt-protocol (no page yet), publish-subscribe-event-bus (no page yet), Point-in-time recovery, Process supervision, Graceful draining, hdr-histogram (no page yet)
• Simulation and test — replay, what-if, controller-in-the-loop — discrete-event-simulation (no page yet), Deterministic simulation testing, Monte Carlo, Explicit Euler, dynamic-traffic-assignment (no page yet), Coverage-guided fuzzing

 loops / radar / video ──► local controller (cabinet) ──► load switches ──► lamps
        │ events                │  ▲ plan, limits            ▲
        │                       │  │                         │ monitors outputs
        ▼                       ▼  │                  conflict monitor / MMU ──► flash
  event log (0.1 s) ───► regional / central ◄──► operators, priority (bus, emergency)
                              │  optimiser: cycle · split · offset
                              ▼
                     performance measures, what-if in a simulator

How the parts fit together

Detection

Detectors are the only sensors. SCOOT expects them "on every link", usually at the upstream end of the approach, normally inductive loops (TRL Traffic Advisory Leaflet 7/99); SCATS places loops in every lane at the stop line, with video as an alternative (Ta, arXiv 1606.01010, a secondary description). The two placements imply two different measurements. An upstream detector sees arrivals early enough to predict when platoons reach the stop line, which suits models that propagate flow along the link. A stop-line detector sees discharge and occupancy, which suits the degree of saturation, the ratio of demand to discharge flow at the stop line. Video and radar detection replace loops with a model: Object detection with Non-maximum suppression on each frame, then Multi-object tracking (Kalman filter for motion, Hungarian assignment for matching) to turn boxes into counts crossing a line. The contract to the controller is not an image but a detector call: a logical channel that is on or off, plus timestamps. Faults (a loop stuck on, a camera blinded) must be detected with robust statistics on occupancy and flagged, because a stuck detector either holds a phase to its maximum or never calls it; change-point-detection (no page yet) catches slow drift.

The detector in a video unit is a Convolutional network: a small backbone of convolution layers turns each frame into feature maps that a detection head reads as boxes of vehicles, bicycles and pedestrians, and the same network can output a stop-line occupancy mask directly. It must run on the unit at the roadside, at the camera frame rate and on a few watts, so the network is small, quantised and tested on the junction's own night, rain and glare footage; its output is turned into detector calls by the tracking step, and a drop in the network's confidence is reported as a detector fault rather than as an empty approach.

Local controller

The controller implements the standard dual-ring, barrier structure: eight phases in two rings of four, where phases 1, 2, 5, 6 (typically the main street) sit on one side of a barrier and 3, 4, 7, 8 on the other, and the barrier guarantees that conflicting phases in different rings never time together (FHWA, CORSIM actuated-control documentation). Within a ring one phase is active; phases in different rings on the same side of the barrier can run concurrently. Each phase has minimum green, a passage (gap) time, a maximum green, and yellow plus all-red clearance; a call from a detector extends or requests it. This is a hierarchical state machine (a ring, a phase, an interval inside it) written as ring-barrier-phase-controller (no page yet), driven by a fixed-rate loop (the high-resolution logs below are stamped to 0.1 s) with absolute deadlines so jitter does not accumulate. Coordination needs agreement on time: each controller keeps a local cycle clock and an offset relative to a common reference, typically set from a shared time source (Clock synchronization). In coordinated-actuated operation the plan typically sets the cycle and offsets, while detectors still allow unused green to end early.

Safety

The controller software is not trusted to be the last line of defence. A separate unit watches the outputs of the cabinet: under NEMA TS 2 it is the malfunction management unit (MMU; the older TS 1 equivalent is the conflict monitoring unit), which detects conflicting or improper signal indications and then puts the intersection into flashing operation (as described in manufacturer and patent literature; the exact conflict-matrix rules are in the NEMA TS 2 text, which I did not read). This is the doer/checker pattern of safety-monitor-architecture (no page yet): the checker has its own, much simpler logic, its own power sense and no dependency on the controller's code, plus fault-detection-isolation-recovery (no page yet) for what to do next. A Watchdog timer resets a hung controller process; redundancy-voting (no page yet) matters mostly for central servers, not for the cabinet. The central optimiser may propose cycle, split and offset; it never writes lamp outputs, and the controller clamps every proposal to its configured minimums, maximums and clearance times. That clamp is what lets the optimiser be an experimental, frequently changed piece of software.

Adaptive optimiser

Three families, from oldest to newest.

Plan selection and parameter control. A library of fixed-time plans keyed by time of day, or by pattern matching on detector data. Fixed plans are computed offline; for a single junction the classic Webster cycle length is C₀ = (1.5L + 5)/(1 − Y), with L the total lost time per cycle and Y the sum of critical flow ratios (Webster, 1958, Road Research Technical Paper 39). With L = 12 s and Y = 0.7 this gives about 77 s; at Y = 0.9 it gives 230 s, which is why the formula is for undersaturated junctions only. TRL's own leaflet notes that plans go stale, by about 3 % a year on average, as traffic changes.

Incremental on-line optimisation (SCOOT). SCOOT divides a network into regions of nodes that share a cycle time and runs three optimisers. The split optimiser acts at every stage change and moves it earlier, later or not at all, in steps of 1-4 s. The offset optimiser acts once per cycle per node, in 4 s steps, using cyclic flow profiles predicted for each link. The cycle-time optimiser runs per region every five minutes (every 2.5 minutes if cycle times are rising fast), finds the critical node, aims for 90 % link saturation on each of its stages and changes cycle length in steps of 4, 8 or 16 s. Detector pulses are converted into a link profile unit, a mix of flow and occupancy, and accumulated into a cyclic flow profile per link. A performance index of predicted delay and stops per link scores each small change (TRL Traffic Advisory Leaflet 7/99). The design choice is many small moves: short-term flow prediction is hard, so the system never makes a big jump. In SCATS, as secondary sources describe it, local controllers make tactical choices (extend, terminate early, skip a phase), while a regional computer chooses cycle length, splits and offsets for subsystems; cycle length ranges roughly from 20 to 240 s in 4-7 s green increments (Ta 2016). SCATS has been installed at more than 60,000 intersections in about 200 cities (SCATS, NSW Government).

Schedule-driven and learning controllers. SURTRAC computes at each intersection, asynchronously, a schedule for the traffic currently approaching, and shares projected outflows with downstream neighbours; there is no fixed cycle (Smith, Barlow, Xie, Rubinstein, ICAPS 2013, nine-intersection pilot in Pittsburgh). Max-pressure control picks the phase with the largest sum of upstream queue minus downstream queue over its movements, and is proven to stabilise queues whenever any control could (Varaiya, 2013). Reinforcement-learning controllers such as PressLight train a policy-gradient or value-based agent in simulation (Wei et al., 2019); they are research tools today, and their deployment contract is the same clamp described above. Short-term forecasts (Exponential smoothing, Time series forecasting) feed all of them, and queueing-theory (no page yet) gives the capacity bounds.

Central system and data

Controllers speak NTCIP, a family of standards maintained by the Joint Committee on the NTCIP: NTCIP 1202 defines the objects of an actuated signal controller, 1201 the global objects, 1103 the transport and management protocols, and 1211 signal control and prioritisation for bus and emergency vehicles (NTCIP published-standards list). Use these instead of a vendor protocol so that one central system can talk to several controller brands. Mutual TLS is one way to authenticate an IP link; older serial lines had no such protection.

The most valuable open data format is the Indiana high-resolution event log: each controller records time-stamped events (phase begin green, yellow, detector on and off, pedestrian calls) to the nearest 0.1 s, and agencies such as GDOT retrieve them over FTP, typically every 10 to 15 minutes (Sturdevant et al., Purdue/INDOT; GDOT ATSPM FAQ). UDOT's ATSPM software turns these logs into performance measures such as vehicle volumes, arrivals on red, pedestrian delay and split failures (ATSPM README). Storage is time-series data: chunks of consecutive events compressed with delta-of-delta timestamps (Time-series chunk storage, Gorilla XOR compression), partitioned by day (Time partitioning) and rolled up into coarser bins (Rollup aggregation).

Operations are ordinary fleet management with tighter reliability needs: Primary-backup replication for the central server, Health checking of every controller link, A/B partition updates with signed metadata for firmware, and configuration backups.

Roadside sensors that are not tied to one controller (radar units, video units, bluetooth readers) push their counts to the centre over mqtt-protocol (no page yet): each unit publishes small messages on a topic per site and detector, a broker holds the last value and delivers to subscribers, and a unit that goes quiet is announced by its last-will message. Inside the centre, a publish-subscribe-event-bus (no page yet) carries these counts, the controllers' event-log records and the alarms to independent subscribers: the performance-measure builder, the adaptive optimiser, the fault monitor and the operators' map. Publishing is decoupled from consuming, so a slow report job does not delay the optimiser's inputs.

The central configuration and the event store are a system of record for what every junction runs. Point-in-time recovery restores the signal timing database and the stored logs to a moment before a wrong bulk timing upload or a bad import, and the restored timing plans are compared with the controllers' reported plans before any is pushed back. The central services (event ingestion, retrieval of controller logs, the optimiser, the update service) run under Process supervision and are replaced with Graceful draining: a retrieval or update job finishes the controller transfer it has started, since a half-written firmware or timing file is worse than a late one, and the new instance takes over the controller list afterwards.

hdr-histogram (no page yet) holds the latency percentiles that decide whether the centre is useful: detector event to optimiser input, command (a plan change or a pre-emption request) to the controller's acknowledgement, and log retrieval age per controller. The tail identifies the junctions whose links are slow or lossy, and the maximum matters more than the mean for pre-emption requests.

Simulation and test

Nothing new should reach a junction without a run in a simulator. SUMO (Eclipse SUMO) models traffic lights as tlLogic programs of type static, actuated, delay_based or NEMA, and lets an external program set phases, durations and whole programs through TraCI (SUMO documentation). A controller can therefore be tested in the loop: SUMO produces detector events, the real controller logic reacts, and the result is compared with the previous plan. Reproducibility comes from seeded pseudo-random generators and the idea of Deterministic simulation testing: same seed, same trace, so a failing scenario can be replayed. Explicit Euler is only a baseline for continuous models (queue ODEs); microscopic simulators are discrete-event (discrete-event-simulation, no page yet). Demand for a corridor comes from route choice, handled by dynamic-traffic-assignment (no page yet).

Coverage-guided fuzzing is aimed at what the controller and the centre parse from outside: NTCIP/SNMP requests and responses, the controller event-log files, the detector and sensor messages, and configuration uploads. A malformed packet must be rejected without disturbing the signal sequence, and a fuzz run on the controller's parser is a safety test, not only a security one.

Data and control flow

One detector call to a lamp change (cabinet)

1. A loop or radar closes; the detector card debounces it and the controller sees a call on a phase at the next 0.1 s tick.
2. The ring-barrier logic compares the call with the active phase: minimum green not yet served, gap timer running, max timer.
3. On gap-out or max-out the phase moves to yellow, then all-red, then the next phase in the ring that has a call and does not conflict across the barrier.
4. Outputs go through the load switches; the MMU senses them, and any conflict forces flash regardless of step 3.
5. Each event is logged with a 0.1 s timestamp.

One adaptive update (regional)

1. Controllers send counts and occupancy every few seconds; the optimiser converts them to link profiles.
2. It predicts the effect of small changes (split ±1-4 s, offset ±4 s) on delay and stops, and picks the best.
3. The new split or offset is sent down; the controller checks it against its limits and applies it at the next safe point in the cycle.
4. Every five minutes the cycle optimiser re-examines the critical node (SCOOT).

One what-if before a change

1. Export a day of event logs and the network model into the simulator.
2. Run the old and the new plan with fixed seeds and several demand scenarios; compare delay, stops and queue spillback.
3. Release the new plan to a pilot corridor, watch ATSPM measures, then widen.

Scaling

1. Safety and correctness per junction. Fixed by the MMU and clamp, not by compute. Lever: independent monitor, tested conflict tables.
2. Detector quality. Adaptive control is only as good as its data. Lever: fault detection on every detector, cheap redundancy (two loops, or loop plus video).
3. Optimiser horizon. Larger regions need common cycle time and more interaction between nodes. Lever: region boundaries at long links where lack of coordination matters little (TRL), or fully decentralised schedulers like SURTRAC.
4. Link capacity and latency. Central optimisers need data every few seconds. Lever: aggregate in the controller, send summaries.
5. Fleet operations. Thousands of cabinets mean staged firmware rollout and configuration drift. Lever: A/B updates, signed metadata, health checks.

Failure modes

Real implementations

I found no open-source production signal controller firmware or open adaptive controller to list; the open parts are tools, simulators and standards.

Sources

• TRL / DETR, The "SCOOT" Urban Traffic Control System, Traffic Advisory Leaflet 7/99, 1999. pdf
• F. V. Webster, Traffic Signal Settings, Road Research Technical Paper 39, HMSO, 1958.
• S. F. Smith, G. J. Barlow, X.-F. Xie, Z. B. Rubinstein, Smart Urban Signal Networks: Initial Application of the SURTRAC Adaptive Traffic Signal Control System, ICAPS 2013. doi
• P. Varaiya, Max pressure control of a network of signalized intersections, Transportation Research Part C 36, 2013. doi
• H. Wei et al., PressLight: Learning Max Pressure Control to Coordinate Traffic Signals in Arterial Network, KDD 2019. doi
• H. Zhang et al., CityFlow: A Multi-Agent Reinforcement Learning Environment for Large Scale City Traffic Scenario, WWW 2019. doi
• P. A. Lopez et al., Microscopic Traffic Simulation using SUMO, ITSC 2018. doi · SUMO traffic lights
• V. T. Ta, Automated Road Traffic Congestion Detection and Alarm Systems: Incorporating V2I communications into ATCSs, 2016 (secondary description of SCATS). paper
• NSW Government, SCATS. site
• FHWA, CORSIM actuated control (NEMA phases, rings, barriers). page
• NTCIP, published standards list (1201, 1202, 1103, 1211). list
• J. R. Sturdevant et al., Indiana Traffic Signal Hi Resolution Data Logger Enumerations, INDOT/Purdue, 2012. doi · ATSPM
• GDOT, Automated Traffic Signal Performance Measures FAQ (event log retrieval). page
• National Academies, Signal Timing Manual, Second Edition. page