Adaptive traffic signal control

Most city signals still run fixed-time plans that are retimed every few years, so they drift away from real demand. Adaptive control observes traffic continuously and adjusts green times, offsets and priorities in near real time, either through mature rule/optimisation-based systems or newer ML/RL approaches. Cities report fewer stops and shorter delays, faster buses and lower emissions, while keeping engineers in charge of safety.

Problem & value

• Today: signal plans are calibrated by traffic engineers from periodic counts, then run fixed-time or with simple vehicle-actuated logic. Plans age as land use, events, roadworks and mobility patterns change. Retiming is labour intensive, so many intersections are rarely touched.
• AI value: closed-loop control that reacts to actual arrivals, coordinates intersections along corridors and networks, and grants conditional priority to public transport, cyclists and emergency vehicles. Unlike VIS-012 (observes traffic) and PRED-019 (forecasts it), this use case acts on the signals.
• Evidence: Google's Project Green Light reports up to 30% fewer stops at participating intersections and an estimated up to 10% emission reduction there; these are company-reported figures from early deployments (about 70 intersections in 12-17 cities as reported), and Seattle describes it as a supplement to its traditional process [1][2]. Established adaptive systems (SCOOT, SCATS, Surtrac, Siemens/Yunex, PTV) publish many city case studies; treat vendor numbers as upper bounds and demand a before/after study on your own network [3][4].

Variants

• Corridor/arterial coordination: adaptive green waves on a main road with bus priority.
• City-wide network control: centralised or decentralised optimisation across hundreds of intersections (e.g. Hamburg, TfL, Bucharest are cited as deployments).
• Decentralised intersection control (Surtrac-style): each intersection schedules its own phases in real time and exchanges predicted arrivals with neighbours [3].
• Advisory "retiming as a service" (Google Green Light): cloud recommendations from Maps driving trends, applied by the city's engineers through existing controllers [1].
• Connected-vehicle / C-ITS: green-light optimal speed advisory (GLOSA), signal phase and timing (SPaT/MAP) broadcast to vehicles, emergency-vehicle preemption.
• Multimodal priority: tram/bus priority, pedestrian and cycle phases weighted by vulnerable-road-user policy.
• Private use: none; the capability is municipal. Drivers only consume GLOSA data via navigation or car apps.

How it works

1. detectors / cameras / probe data / PT AVL / C-ITS
2. data cleansing + state estimation (queues, arrival profiles, travel times)
3. short-term demand prediction (time-series, PRED-019)
4. optimiser (rule-based, MPC/search, or RL policy trained in a simulator)
5. safety layer (min greens, clearance, conflict monitor, max cycle bounds)
6. controller interface (NTCIP, UTMC, OCIT-C / OCIT-O, UTC protocol)
7. signal heads; KPI feedback loop

• Optimiser: classic adaptive systems use rule/optimisation (offset, split, cycle adjustment) with proven behaviour. ML approaches add demand prediction and reinforcement learning (multi-agent RL, graph networks) that learn policies in microscopic simulation (SUMO, PTV Vissim) before deployment.
• Safety layer: AI never bypasses the hardware conflict monitor; the controller guarantees no conflicting greens. Policies output bounded timing parameters, not raw signal states.
• Human-in-the-loop: engineers set objectives (delay vs. priority weights, pedestrian waits), approve plan changes in advisory mode, can fall back to fixed time at the push of a button, and review KPIs.

Data preparation

Data comes from detector loops, radar and cameras, floating-car feeds, public-transport systems (SIRI) and the signal controllers themselves. In a typical municipality this lives in a traffic-control centre, proprietary controller databases, vendor portals and sometimes paper signal-plan folders and PDF drawings. Typical gaps: undocumented detector locations, faulty or drifting loops, inconsistent lane and phase naming, signal plans only as scans, missing historic demand profiles and unclear data-sharing rights with navigation providers.

Preparation steps: build a detector and intersection inventory with geo-references; check detector health and fill gaps with probe data; digitise signal plans and safety constraints (clearance times, minimum greens) into a structured table; set up a calibrated simulation model of the network; define a common time base and stream pipeline. Camera counting should anonymise images at the edge so only counts leave the device.

Expect a high share of total effort, roughly 40-60 percent, in data and model preparation. Helpful starting points: PREP-001 for an inventory, PREP-005 for getting data out of legacy systems, PREP-006 for scanned plans and PREP-022 for anonymised video data. See also GUIDE-003.

Implementation paths

Which path for whom

• public (A): Road authorities need type-approved, safety-certified controllers and traffic-engineering support; mature vendors (e.g. Siemens, Swarco, Yunex) deliver adaptive control inside existing controller infrastructure.
• enterprise (B): Operators of private networks, logistics sites or ports usually need to integrate detectors and fleet data with their own systems, so a build on solvers plus a vendor controller interface fits best.
• developer (C): Open tools such as SUMO and RL libraries run on modest hardware and allow full control and experimentation, but must stay in advisory or simulation mode until validated.

Path A - Buy (recommended)

• Established UTC/adaptive suites: Yunex Traffic (Siemens spin-off; Sitraffic, EU), Swarco (AT, EU; acquired Dynniq Mobility in 2021), PTV / Umovity (DE, EU; PTV Balance/Epics), Kapsch TrafficCom (AT, EU), SCOOT (TRL/Peek, UK), SCATS (NSW, Australia), Surtrac (Rapid Flow Technologies, US) [3][4].
• Cloud advisory: Google Project Green Light (free to cities, recommendations only) [1].
• Check: controller protocol support (OCIT, NTCIP), cybersecurity certification, data location, priority logic, integration with existing UTC centre, FRIA/conformity support from the supplier.
• Choose A when: you are a municipality or road authority; procurement is public tender, safety case required.

Path B - Build on cloud APIs

• Limited. Use cloud for analytics around the controller: probe-data APIs (TomTom Traffic, HERE, INRIX; TomTom and HERE are EU-based) for travel-time KPIs, time-series forecasting services, and dashboards. Direct closed-loop actuation from a public cloud is rarely accepted; keep the control loop on-premise or in the traffic management centre.
• LLMs have a minor role: natural-language reports of KPIs, log summarisation, assistants for engineers (see OPT-018).

Path C - Self-host (open source)

• Simulation/training: Eclipse SUMO (open source microsimulation) with TraCI; RL toolkits built on it (e.g. SUMO-RL, RESCO benchmark environments, Ray RLlib/Stable-Baselines3) [5].
• Control: prototypes and research use open implementations of max-pressure, MPC and RL controllers. No widely deployed open-source production adaptive controller exists; production systems still require certified controllers and vendor safety cases.
• Hardware: HW1 at the edge (controller-side inference is small); training in simulation fits one GPU (HW2) or CPU clusters.

Path D - Custom training

Worth it for research institutes, large cities or vendors: train RL policies on a calibrated digital twin of the network (SUMO/Vissim, calibrated with detector data), then shadow-test against the live plan before limited deployment. Needs months of detector history and a validated simulation model. Sim-to-real gaps are the main risk.

State of the art (2026)

• Production practice remains dominated by robust, explainable adaptive algorithms (SCOOT, SCATS, Sitraffic, Surtrac) with ML mainly for prediction, detection and tuning.
• RL for traffic signals is a strong research field with standard benchmarks (e.g. RESCO) and promising simulated gains, but few certified, long-running city-wide RL deployments; generalisation across networks and detector failures are open problems [5].
• Camera-based detection (object detection and tracking) is replacing inductive loops at many sites; see VIS-012.
• Advisory cloud services (Green Light) show a pragmatic path: recommendations first, actuation by engineers [1][2].
• Limits/failure modes: detector faults and sparse data, sim-to-real gap, over-optimising car delay at the cost of pedestrians and cyclists, oscillating plans, lack of explainability, cyber attacks on signal infrastructure, and benefits that are modest on already well-tuned corridors.

Shared resources & combinations

• Same data/stack: VIS-012 traffic monitoring (detectors/cameras), PRED-019 demand forecasting (inputs), VIS-054 enforcement cameras (separate purpose, do not merge data flows).
• Combines with: OPT-020 (disruption management for rail/transit), OPT-028 (ridepooling dispatch), OPT-029 (emergency vehicle deployment and preemption), OPT-021 (EV fleet charging and depot logistics), OPT-018 (natural-language decision copilot for engineers).
• Shared building blocks: reinforcement-learning, simulation/digital twin, streaming ingestion, edge runtime.

Effort, cost & KPIs

• Path A: several months to years for procurement, detector upgrades and commissioning; cost dominated by hardware, detectors, communication and integration, not software licences. Advisory services like Green Light have low entry cost.
• Path C/D: research-grade; 6-18 months to a validated simulation and pilot corridor.
• KPIs: average delay and stops per vehicle, travel-time reliability, bus punctuality and priority success rate, pedestrian/cyclist waiting times, queue spillbacks, estimated CO2/NOx (modelled), safety incidents, fallback frequency, detector availability.

People & change

Involve the department lead (traffic engineering) and management from the start, because every timing change carries safety responsibility. IT and IT security must be involved before connecting controllers to external systems, since controllers are critical infrastructure. Control-room operators and field technicians are the end users; include them in the design of advisory mode and override rules. Suppliers of controllers and detectors have to be part of integration planning.

Works council: usually no co-determination under §87(1) no. 6 BetrVG, because the system monitors traffic, not employees. In public authorities check with the staff council (Personalrat) under the applicable state law, and inform it in good time about changed work processes (compare §90 BetrVG). Involve the data protection officer if cameras or connected-vehicle data are used; a DPIA is likely for camera-based detection at scale.

Start with an advisory pilot on one corridor, with engineers approving each change, and expand only after measured gains. Typical concerns are safety and loss of control: keep hard safety constraints in the certified controller, a manual fallback and a clear escalation path. Support staff with AI literacy measures. See GUIDE-009, GUIDE-005 and GUIDE-006.

Risks, regulation & compliance

• EU AI Act: Annex III point 2 lists AI systems intended as safety components in the management and operation of critical digital infrastructure and road traffic. Signal control that can affect safety is therefore likely high-risk (risk management, data governance, logging, human oversight, accuracy/robustness, conformity). Purely advisory retiming tools with engineer approval and a certified controller safety layer may fall outside; document the assessment [6]. Public deployers may need a fundamental rights impact assessment (Art. 27) if in scope. Not an Art. 5 practice.
• GDPR: loop counts are non-personal. Cameras, ANPR and connected-vehicle or floating-car data can be personal data (plates, trajectories): use on-device anonymisation to counts, short retention, DPIA, legal basis for public tasks. Avoid mixing with enforcement data (VIS-054).
• Cybersecurity: NIS2 treats transport as an essential sector; secure controller links, segment networks, signed updates. Follow national traffic-engineering rules (e.g. German RiLSA, EU C-ITS specs).
• Mitigations: hardware conflict monitor as final authority, bounded parameter ranges, shadow mode before closed loop, rollback to fixed-time, independent before/after evaluation, equity weighting for vulnerable road users, audit logs.

Getting started

1. Baseline one corridor: counts, delay, bus punctuality, detector health, current plans.
2. Build or acquire a calibrated SUMO/Vissim model and replay historic demand.
3. Pilot an advisory tool (e.g. Green Light or vendor adaptive module) on 5-10 intersections in shadow mode.
4. Define objectives, safety constraints and fallback with the traffic engineers; complete the AI Act risk assessment and DPIA.
5. Run a controlled before/after trial, publish KPIs, then extend step by step.

Sources

1. GeekWire - Google's Project Green Light uses AI to improve traffic flow in Seattle and elsewhere - https://www.geekwire.com/2023/googles-project-green-light-uses-ai-to-improve-traffic-flow-cut-emissions-in-seattle-and-elsewhere/
2. Scientific American - Can Google Make Stoplights Smarter? - https://www.scientificamerican.com/article/googles-project-green-light-uses-ai-to-take-on-city-traffic/
3. Rapid Flow Technologies - Surtrac adaptive signal control - https://www.rapidflowinc.com/
4. Yunex Traffic - Adaptive urban traffic control - https://www.yunextraffic.com/
5. Eclipse SUMO - Simulation of Urban Mobility - https://eclipse.dev/sumo/
6. Regulation (EU) 2024/1689 (AI Act), Annex III - https://eur-lex.europa.eu/eli/reg/2024/1689/oj