Traffic Signal Management Software: Knowing a Detector Failed Before the Public Does

The dark signal you learn about from a resident

A call comes into 311 at 8:40 on a Tuesday morning. A signal is flashing red at a major intersection. By the time the call is routed to traffic operations, a technician is dispatched and the cabinet is opened, it has been dark or in flash for over an hour during peak, and someone from the council office has already asked why the city did not know.

That is the visible failure. The expensive one is invisible. A left turn detector on an arterial goes stuck on, calling its phase every cycle whether or not a vehicle is present. Nothing goes dark. No one calls. The signal simply serves a phase to an empty lane, several times a minute, every day, breaking coordination for everyone behind it. That failure can persist for a year, and in agencies without controller level monitoring it usually does, until the next retiming study finds it.

Both failures come from the same gap: the controllers know, and nobody is listening. Modern signal controllers log events at high resolution, including detector actuations, phase changes, preemption calls and coordination status. That data is the difference between running signals on complaint counts and running them on evidence. Most agencies have the data available in the cabinet and collect none of it.

Problem 1: your controller estate is mixed and your central system is not

A city of any age has controllers from more than one manufacturer, because purchases happen over decades and through different capital projects. Econolite in the corridors done in one era, Cubic Trafficware from a later contract, some Yunex or Q Free units where a developer built the intersection, and a range of firmware versions inside each make.

Vendor central systems are strongest with their own hardware. Run Econolite Centracs and your Econolite controllers are fully integrated; the other makes are supported to the extent that standard communication protocols cover them, which is real but limited. NTCIP 1202 gives you a common language for actuated signal controller status and parameters, and that is genuinely useful, but the high resolution event logging that drives performance measures is not uniformly exposed in the same way across makes and firmware.

So agencies end up with a working central system covering most of the network for control, and a blind spot for data covering the rest. The practical answer is an abstraction layer: a collector that speaks NTCIP where it can, uses vendor specific retrieval where it must, normalises event codes into one schema, and treats each controller make and firmware version as a supported configuration with its own tests. That is unglamorous engineering and it is the whole foundation.

Problem 2: detector health is invisible until timing quietly stops working

Every timing plan you deploy assumes the detection works. Loops get cut by utility trenching. Video detection drifts out of alignment after a pole is struck. Radar units lose power on a shared circuit. A detector card fails and the phase goes to recall.

None of this announces itself. What a monitoring layer does is profile each detector against its own history: expected actuation counts by hour and day of week, expected occupancy patterns, and then alert on the deviations that matter. Zero actuations on a detector that normally sees eight hundred vehicles in a morning peak is a failure. Continuous occupancy is a stuck detector. A count that has fallen by half over three weeks is a camera drifting or a loop degrading.

Getting this right is mostly about alert discipline. An operations group that receives forty alerts a day will read none of them. Alerts should be ranked by impact, meaning a stuck left turn detector on a coordinated arterial outranks a failed pedestrian push button on a low volume approach, and they should carry the evidence with them so a technician is dispatched with a diagnosis rather than a complaint.

Problem 3: the high resolution data exists and nobody collects it

Signal performance measures built from high resolution controller event data are the most useful development in traffic operations in twenty years, and the work originated in the public sector at Utah DOT with Purdue research and has been supported by FHWA, with open source implementations available. That matters for your build versus buy decision and we will come back to it.

What the measures give you, per approach, per hour, without sending anyone into the field:

• Arrivals on green and platoon ratio, which is whether your coordination is actually working on that approach at that time of day
• Split failures, meaning the phase ran out of time with vehicles still waiting, which is the earliest sign a timing plan no longer matches demand
• Purdue coordination diagrams that show, cycle by cycle, where the platoon arrives relative to the green
• Pedestrian delay and actuation counts, which is how you answer accessibility complaints with data
• Detector counts and health, which doubles as your volume data source and removes a lot of tube count spending
• Yellow and red actuation counts, a useful surrogate for red light running exposure at an approach

Agencies typically retime corridors on a three to five year cycle because retiming is a consultant engagement. With continuous performance measures, retiming becomes targeted: you fix the six approaches that are failing rather than restudying forty that are fine. That is the operating case for the whole system.

Problem 4: timing plans are deployed with no version control and no rollback

Ask a traffic engineer what changed on a corridor eight months ago and you will usually get a memory, a consultant report and a spreadsheet of splits. The controller database has been edited in the field, in the office, and by a contractor during a project, and there is no record that ties a change to a person, a date and a reason.

This is a solved problem in every other engineering discipline and it should be solved here. Timing plans belong in a repository with versions, a readable difference between any two versions, a deployment record showing what was pushed to which controller and when, and a one action rollback. Attach the performance measures to the deployment and you get the thing engineers actually want: a before and after on the same approach, computed automatically, which is also precisely the evidence a corridor grant application under a federal safety or congestion program needs.

What Centracs, ATMS, Iteris and Yunex actually do

Econolite Centracs and Cubic Trafficware ATMS are mature central systems and they do control, monitoring and database management properly for their own hardware. Yunex Traffic offers the same profile from the Siemens lineage. Iteris is strongest in detection and the data products around it. None of these are bad products, and this is important: the honest criticism is not quality, it is that a central system is optimised for the vendor's controller line and for the operations room, and your estate is mixed and your questions increasingly are not operational but analytical.

The second honest point is about the open source option. Because signal performance measures came out of a public agency and are supported by FHWA, there are deployable open source implementations. If your requirement is performance measures on a homogeneous controller estate, deploy one of those and hire someone to operate it. That is the cheapest correct answer and any developer who does not mention it is selling.

What to build, and the one thing you should not

Our position, stated plainly: do not build a replacement for signal control, conflict monitoring or anything that touches the safety critical path in the cabinet. That function sits inside a hardware, standards and liability environment where a custom build is the wrong instrument, and the existing central systems earn their keep there. Build the layer above it.

• A collection service that retrieves high resolution event logs across mixed controller makes and firmware, with store and forward for unreliable field communications
• A device inventory covering controller make, model, firmware, cabinet, detectors with channel mapping, communications link and power source
• Detector and communications health monitoring with impact ranked alerting and diagnostic context attached
• Signal performance measures computed per approach and rolled up to corridor, with automatic before and after comparison around any timing change
• A timing plan repository with versioning, difference views, deployment records and rollback
• Preemption and transit priority event logging with reporting, because fire and transit agencies will ask
• Integration with 311 and your work order system so a complaint attaches to the device and to what the data was doing at that time
• Reporting packaged for grant applications and for the annual presentation to your governing body

What this costs and how long it takes

From Digital Heroes delivery experience on device data collection and analytics platforms, the monitoring and performance layer runs $70,000 to $160,000 across 14 to 20 weeks. The full platform adding preemption and priority reporting, 311 and work order integration, timing plan management and multi agency access runs $200,000 to $500,000 phased over 9 to 18 months.

What moves the number here: the number of distinct controller makes and firmware versions, because each is a supported configuration with its own retrieval quirks and its own test coverage. Field communications quality, since a network on cellular modems with intermittent coverage needs far more resilience engineering than one on fibre. Intersection count, which changes the data volume architecture. And whether high resolution logging is even enabled and accessible on your controllers, which is worth verifying in a handful of cabinets before you scope anything, because on older units it may require firmware work or hardware replacement that belongs in a capital budget rather than a software one.

When you should not build this

Under roughly 50 signals on a single controller make with a functioning central system, do not build. Turn on the vendor's performance measures module or deploy an open source implementation and spend the money on detection maintenance, which will produce a bigger operational improvement than any software you buy this year. Also do not build if your controllers cannot produce high resolution event data, because the analytics have no input; the correct first project is a controller and detection upgrade programme.

How to choose a developer for traffic operations systems

Ask them how they will handle three controller makes and five firmware versions. If the answer does not include a normalisation layer with per configuration testing, they are going to build against whatever they can reach and hand you a partial network.

Ask what happens when a cellular modem is offline for two days. Store and forward at the collector with gap detection and backfill is the correct answer. Silent data gaps are worse than no data, because a performance measure computed over a gap looks like a real result.

Ask whether they intend to touch anything in the control path. The right answer is no, with a clear architectural boundary between reading data and commanding equipment, and you should confirm that boundary with your own signal engineer.

Ask who owns the code, the cloud accounts and the collected data, in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A sensible next step: pick one corridor with mixed controller makes, confirm high resolution logging is available in those cabinets, and scope a pilot on that corridor alone. It will tell you more about feasibility than any proposal document.