Traffic Signal Management Software Problems: The 6 That Waste Green Time, and How to Avoid Them

Why does the project get scoped against one controller make?

Because the pilot corridor is whichever one the agency knows best, and that corridor is usually homogeneous. A city of any age has controllers bought over decades through different capital projects: Econolite in the corridors done in one era, Cubic Trafficware from a later contract, some Yunex or Q Free where a developer built the intersection, and a spread of firmware versions inside each make. The proof of concept runs on twelve intersections of one make, works, and gets extended to a scope covering the network.

What surfaces in month four is that high resolution event logging is not uniformly exposed across makes and firmware. NTCIP 1202 gives you a common language for actuated signal controller status and parameters, which is genuinely useful, and it does not solve the retrieval of the detailed event logs that performance measures are computed from. So the build reaches most of the corridors it was demonstrated on and none of the rest, and the agency has paid for a partial network.

Scope it the other way round. Pick a pilot corridor deliberately chosen because it has mixed makes, and verify in a handful of cabinets that high resolution logging is enabled and retrievable before anything is priced. Require a normalisation layer that speaks NTCIP where the standard covers what you need, uses vendor specific retrieval where it does not, and treats each make and firmware version as a supported configuration with its own tests. That layer is unglamorous engineering and it is the whole foundation.

What goes wrong when field communications drop and nobody notices?

Signal networks run on a mixture of fibre, leased circuits and cellular modems, and the cellular sites drop for days rather than minutes. If the collector simply polls and moves on, the result is a data gap, and a silent gap is worse than missing data because a performance measure computed across it looks like a real result and gets acted on. An engineer sees arrivals on green improve on an approach and credits a timing change that did nothing, because half the cycles that week were never collected.

The second version of the same problem is partial data. A controller reboots, its log buffer clears, and you receive the events after the reboot with no indication that anything preceded them. Counts look low, a detector health rule fires, and a technician is dispatched to a cabinet with nothing wrong.

The design requirement is store and forward at the collector with explicit gap detection and backfill. Every computed measure should carry the completeness of the underlying data for that period, and the interface should refuse to draw a confident conclusion over a period it knows is incomplete. Ask a prospective developer what happens when a modem is offline for two days, and listen for whether the answer includes backfilling from the controller's own buffer and marking the remaining gap explicitly. If the answer is that the chart will have a hole in it, the analysis built on top will mislead your engineers.

Why do the 311, work order and central system links break after launch?

The value of connecting a complaint to a device is that a technician arrives knowing what the data was doing at the time. What breaks that link after launch is device identity. Your 311 system knows an intersection by a street name pair typed by a call taker, your work order system knows an asset number, your central system knows a controller address, and none of the three agree. The mapping works on the day it is built and drifts as intersections are rebuilt, renumbered and reassigned.

The second break is with the central system itself. Econolite Centracs, Cubic Trafficware ATMS and the Yunex equivalents are mature products doing control, monitoring and database management properly for their own hardware, and they are upgraded on the vendor's schedule. If your collection layer reads from the central system rather than from the controllers, a central system upgrade can change what you receive without anyone telling the team that built the analytics.

Hold a single device inventory as the authority: controller make, model, firmware, cabinet, detectors with channel mapping, communications link and power source, with the external identifiers from 311, work orders and the central system attached as aliases. Then any renumbering is one record edit rather than three broken joins. Prefer collecting from the controller where the make allows it, so a central system upgrade cannot silently reshape your data.

What happens when alert ranking and plan rollback are not covered?

Two operational gaps decide whether the system is used after month three. The first is alert discipline. An operations group receiving forty alerts a day will read none of them, and the build that generates alerts without ranking them has produced a new way to ignore the same problems. Detector alerts have to be ranked by traffic impact, so a stuck left turn detector on a coordinated arterial outranks a failed pedestrian push button on a low volume approach, and each alert has to carry its evidence so a technician is dispatched with a diagnosis rather than a complaint.

The second is timing plan change control. Controller databases get edited in the field, in the office and by contractors during projects, and in most agencies nobody can say what changed on a corridor eight months ago, by whom or why. This is a solved problem everywhere else in engineering. 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 performance measures to the deployment and you get the thing engineers actually want, which is an automatic before and after on the same approach. That is also precisely the evidence a corridor grant application under a federal safety or congestion program asks for, and the reason this feature usually pays for itself faster than the monitoring does.

Should you build custom or configure what you already own?

Configure if you operate under roughly 50 signals of a single controller make with a functioning central system. Turn on the vendor's performance measures module and spend the difference on detection maintenance, which will produce a bigger operational improvement than any software you buy this year.

Deploy rather than build if your estate is homogeneous and your requirement is performance measures. The work originated in the public sector at Utah DOT with Purdue research and has been supported by FHWA, and deployable open source implementations exist. Stand one up and hire someone to operate it. That is the cheapest correct answer, and any developer who does not raise it before quoting is selling rather than advising.

Build when your estate is genuinely mixed and the standard implementation cannot reach a large share of your intersections, when you need detector health alerting integrated with 311 and work orders, or when timing plan governance across multiple agencies or a county wide network is the actual problem. State the boundary plainly in the contract: this system reads data and does not command equipment. Signal control and conflict monitoring sit in a safety critical hardware, standards and liability environment where the established central systems are the right instrument, and a custom replacement is not. Have your own signal engineer confirm that boundary in the architecture before work starts.

How do hidden costs get into the quote?

Controller make and firmware count is the largest hidden variable. Each combination is a supported configuration with its own retrieval quirks and its own test coverage, and a quote priced against a pilot corridor has priced one of them. Ask for a per configuration figure and supply a real inventory, including the firmware versions, which many agencies have never compiled.

The second is enabling high resolution logging. On older controllers it may require a firmware upgrade or hardware replacement, which belongs in a capital budget rather than a software one, and discovering it after the software contract is signed produces a system with no input. Open a handful of cabinets and check before scoping anything.

The third is communications. A network on cellular modems with intermittent coverage needs substantially more resilience engineering than one on fibre, and that cost is invisible in a feature list. Be honest about your worst links rather than your best.

The fourth is data volume architecture. Intersection count changes the storage and query design, and a system built for eighty signals does not simply scale to six hundred. Give the developer your five year signal count, not today's.

What separates a build that works from one that fails here?

Builds that work start with one deliberately awkward corridor. Mixed makes, at least one marginal communications link, and a known detector problem you can use to validate the alerting. That corridor tells you more about feasibility than any proposal document, and it produces a real cost per intersection to extend from. Builds that fail start with the easy corridor, prove nothing, and discover the estate in production.

The second differentiator is whether operations staff shaped the alerting. Engineers want measures and technicians want a work order with a diagnosis attached, and a system that serves only the first will be praised in a presentation and ignored in the shop. Sit with the people who open cabinets before designing the alert ranking.

The third is whether the boundary against the control path was drawn and enforced. Reading data is a different risk category from commanding equipment, and blurring the two turns a useful analytics project into a safety review.

Finally, settle ownership before kickoff. You should own the repository, the cloud accounts and all collected event and performance data, with the right to hire another firm. At Digital Heroes the client owns the code from the first commit. Your event history is what makes trend analysis and before and after evidence possible in later years, and it should never sit behind a vendor's platform.