Traffic management: where the fixed cycle breaks
Traffic management in most cities still relies on a fixed traffic signal cycle: phase durations are set by plan, switched on schedule, and repeated on all days with a similar demand profile.
The controller does not see how many vehicles are actually waiting on approaches—it counts time, while the flow in the intersection area is determined by the street, not by the control loop.
The bottleneck opens at peak. Intersection throughput is limited by how many vehicles manage to clear during green, and this depends on queue length at the entry, share of turning vehicles, and discharge of adjacent directions.
As soon as peak load on an approach exceeds the calculated value, not all demand clears in a phase: the residual queue accumulates with the next one, and congestion at the intersection grows faster than the arriving flow.
Then a chain reaction begins. The queue tail blocks the downstream intersection, and it loses capacity, even though its own plan is configured correctly.
Minor approaches receive a fixed share of the cycle regardless of actual demand: an empty exit holds green while the main one waits.
For the traffic management service, this turns into reactive mode: plans are adjusted after the problem, when complaints have already been collected and measurements taken.
Detector data goes into reporting, not control, so shifts in the demand profile are noticed with a delay of several weeks. Below we discuss how an adaptive loop closes this.
What adaptive control of traffic signal objects provides
Adaptive traffic signal control is a departure from the fixed cycle: phase durations are recalculated based on actual intensity from detectors, usually every few seconds, rather than according to a card taken when the object was commissioned. Let us look at two areas where the effect is visible in metrics.
Reducing delay on approaches
Delay is measured according to Highway Capacity Manual—average delay on an approach, so the effect is verifiable before and after at the same hours of day.
At an intersection with uneven loading, 20–35% of average vehicle delay is removed; the share of vehicles stopping on the minor direction falls more noticeably.
Traffic flow forecasting works ahead: growing load on neighboring sections suggests when to extend the phase for the problem direction—before a tail forms at the approach.
This eliminates the class of failures “congestion due to wrong phase,” and if communication is lost, the controller switches to a local plan and restores flow within minutes.
Public transport priority
A request to extend or early start a phase from a bus or tram is processed without breaking the overall cycle: passenger transport crosses the intersection on the first approach, and seconds lost by cross directions are returned in the next cycle.
Coordination of neighboring objects into a green wave adds effect on the arterial: travel time through the section and variability of travel time are reduced, so schedules hold without a buffer for congestion.
Comparison of approaches: adaptive, coordinated, local
Control mode is chosen not by the principle “the more complex, the better,” but for the geometry of the node and intensity.
A controller at a neighborhood exit and on an arterial requires different logic: either detection sits idle, or the queue runs into the previous intersection.
| Option | When suitable | Limitations |
|---|---|---|
| Local adaptation | Isolated intersection, uneven demand by directions, detectors available | Does not see neighboring nodes; under saturation transfers congestion further along the corridor |
| Coordinated control | Series of nodes on an arterial, even flow profile, priority for stop-free passage | Relies on plan schedules: a shift in peak or an accident breaks coordination until manual reconfiguration |
| Adaptive network control | Corridor or district with dense detection and communication channel | More difficult to accept: demand model, telemetry, and quality criteria are needed |
| Fixed schedule | Backup mode, repairs, loss of communication with the center | Does not react to actual demand—it is insurance, not the main mode |
When coordinated mode is needed
Coordination is enabled where nodes are close together and isolated adaptation works against the neighbor: one intersection releases a platoon of vehicles, the next cannot accept it in time.
The schedule is shifted by travel time between stop lines, and local adaptation adjusts phase durations within the corridor.
Coordination is designed for normal flow: during repairs or a peak shift, the mode is revised—automatically or with dispatcher confirmation.
Implementation stages: from survey to handover to operation
The order of work is the same for a single intersection and for a corridor of dozens of nodes—only the scope of the survey changes. The logic is this: first record what actually happens at the object, then build control, and only then release it onto the live street.
- Survey of the road node—we capture approach geometry, permitted directions by lane, actual intensities by hour of day, measure existing delays and queue lengths.
- Phase and cycle scheme—we lay out phases and conflicting flows, durations, transition intervals, separate modes for morning peak, off-peak, evening, and weekends.
- Control algorithm setup—we choose logic for the flow character: fixed plan where load is stable, adaptive control by detectors where it fluctuates.
- Model validation before launch—we run scenarios without going to the object.
- Trial operation—the node operates under engineer supervision: we compare actual delays with calculated ones and adjust detector sensitivity.
- Handover to operation—maintenance regulations, settings passport, and training for your shift.
Model validation before launch
The model is built on survey data: geometry, intensities, turning shares, flow composition. We run a full day, including non-standard scenarios—detector failure, congestion at the exit, switching to manual mode. We look not at average speed, but at tails: maximum queue and number of stops on the approach.
If a scenario does not pass, we adjust phases and logic on the model: this is many times cheaper than rolling back settings on a live node. What goes to the street is a variant that has already worked through a full daily cycle without falling apart.
What we hand over to the customer: configurations, schemes, regulations
We hand over not a “working system,” but a complete set that your team can use to support it without us: configurations, schemes, regulations, and instructions. Below is what remains in the customer’s hands.
Phase and cycle schemes
- Documentation for the control system: logic description, module responsibility boundaries, list of external integrations and failure points.
- Phase and cycle schemes for each intersection: durations, phase order, transition conditions, manual and adaptive modes.
- “Sensor—detector—phase” mapping: which telemetry is used to make a decision and what happens when signal is lost.
Maintenance regulations and dispatcher roles
- Maintenance regulations: inspection frequency, alert thresholds, actions during degradation, and rollback to the previous configuration.
- Access policies and roles: who changes parameters, who only observes, who approves edits—with an action log.
- Dispatcher instructions: handling typical scenarios, manual control, switching an intersection to local mode.
- Stand and production loop configurations as separate files: changes are first tested on a copy, not on a live object.
We deliver each document in working form—with versions and the date of the last review, so logic does not have to be reconstructed from memory.
Case: relieved an arterial without building interchanges
The section is four intersections in a row at the exit from a residential area to a business center: in the morning flow goes into the city, in the evening back, and fixed traffic signal cycles did not account for this unevenness.
At peak, a driver waited through 2–3 phases in a row, the queue tail blocked exits from courtyards, and the same congestion reproduced at the same hours.
Before work, we recorded baseline metrics: travel time through the section in the morning peak, share of stops on the route, number of repeated congestion events per week.
These same indicators became acceptance criteria—without them, the effect of tuning cannot be distinguished from seasonal flow fluctuations.
What was changed and what was achieved
Vehicle detectors were installed on intersection approaches, phase durations were recalculated, and coordinated plans for morning and evening peaks were introduced: the “green wave” was tuned to actual flow speed, not calculated speed.
ATMS was deployed—it rebuilds the cycle based on current load and gives a priority phase to public transport; if a detector fails, the section automatically returns to the calculated plan, and the dispatcher sees this in monitoring.
Travel time through the section at peak decreased from 18 to 11 minutes, share of stops—from 62% to 34%: a vehicle more often passes intersections without a full stop.
Repeated congestion events during peak hours fell from 8–9 to 1–2 per week and remain at this level even with growing flow.
How is traffic recognition different from flow forecasting?
Traffic recognition answers the question “what is happening now”: video analytics at the intersection identifies objects frame by frame, tracks them along trajectories, and counts by lanes and directions.
The result is an instant snapshot: how many vehicles are on the approach, what share are trucks and buses, who is standing in queue.
Requirements here apply to detection and tracking of objects: not to lose a vehicle in occlusion, not to double-count it, to withstand rain and night.
Flow forecasting is a different class of task: estimate how much traffic will approach the stop line in the next interval.
It relies on accumulated time series, daily and weekly profile, calendar, and data from neighboring intersections, and the forecast horizon determines everything else.
On one control cycle, an inertial estimate is sufficient; on ten to twenty minutes, seasonality and reaction to events are already needed.
Hence different requirements for input data accuracy. Recognition needs completeness by classes: a missed truck distorts intensity more than an extra passenger car.
Forecasting needs series stability, because gaps and camera displacement create breaks that the model reads as a real surge in demand.
Errors from one loop leak into the other. Systematic undercounting at dusk turns into an underestimated forecast and a chronically short phase—the queue grows, although formally the model works.
Therefore perception and forecasting are kept separate, with different metrics, and input quality control is placed between them: outlier filtering, checking series continuity, and marking intervals where recognition worked unreliably.
Questions about integration and solution reliability
Before a project, the same doubts come up: how the solution will coexist with the existing control room, what happens if communication is lost, whether already installed controllers and detectors will need to be changed. Below are short answers, including manual intervention and fault-tolerance testing.
How does the system integrate with the existing control room?
We do not replace it, but embed into it: exchange goes through channels and formats already accepted at the object, and events—phase statuses, alarms, detector failures—reach the operator in familiar form.
Control logic remains on controllers; the central layer calculates modes and issues recommendations.
What happens if communication is lost?
Each node stores the phase program locally and, if the channel breaks, switches to autonomous mode using its own detectors.
After communication is restored, it transmits the accumulated log—the section does not drop out of the overall picture, and discrepancies are analyzed by event time.
Is the solution compatible with installed equipment?
In most cases yes: we read what controllers and sensors already output, without replacing the fleet. If a specific device does not output the required data, we install an interface gateway—it adds the missing telemetry.
Is manual control retained?
The operator retains priority at any moment: taking over control, forced phase for emergency vehicles, disabling adaptive mode on a section. Manual actions are written to the log alongside automatic decisions, so incident analysis relies on a complete timeline.
Let’s discuss the task: what is needed to assess your node
To make the assessment for a node substantive rather than approximate, it is enough to attach several groups of data for the first conversation. Below is what most strongly affects calculation accuracy and implementation timelines.
- Traffic management scheme with intersection boundaries, lane count, permitted directions, and pedestrian crossings.
- Equipment composition: traffic signal controllers, vehicle and pedestrian signals, vehicle detectors, call devices.
- Flow data—intensity by direction for a typical day and peak hour, turning shares, queue behavior.
- Current control modes: number of phases, durations, switching order, whether adaptive scenarios exist.
- Communication and power scheme for control cabinets, access to controllers, requirements for channels and redundancy.
- Node constraints: public transport stops, priority routes, rail tracks, operating mode of neighboring objects.
- Contact of the balance holder and the procedure for approving changes in traffic management.
If some data is missing, this does not stop work: we collect the missing part on site, with flow measurements and analysis of controller logs. Then we return with a work plan: delivery scope, stages, implementation timelines for each, and points where approvals are needed. Describe the task and attach what you already have—we will return with an estimate and plan.
