The smart intersection has an unglamorous problem: somebody has to keep it smart on Tuesday morning, long after the demonstration ends.
That person needs functioning detectors, trustworthy timestamps, an intelligible controller configuration, working communications, a way to recognize bad data, and authority to act on what the software recommends. They also need a signal face that gives road users the approved indication. A convincing dashboard cannot supply any of those conditions by itself.
The U.S. Department of Transportation (USDOT) reports that Congress reallocated $204.912 million in unobligated SMART program balances in 2026. USDOT says no new SMART notices of funding will be issued, while existing agreements for 122 Stage 1 and seven Stage 2 projects will continue. Those figures describe the portfolio, not new signal awards or projected LED purchases.
The practical question is what these projects will prove about running a connected or AI-assisted intersection after the pilot. My answer is to evaluate ownership, failure behavior, maintenance, and field acceptance as carefully as the technology.
In brief: A smart traffic signal procurement should specify the safety objective, detection and data quality, controller authority, communications, analytics, staff responsibilities, fallback operation, acceptance tests, and the exact visible LED indication as distinct deliverables. Their integration should then be tested at the intersection.
A funding shift with an operational consequence
The SMART program was designed to let public agencies demonstrate advanced transportation technologies. The 2026 reallocation is a funding action, not a finding that a particular signal technology failed. Existing projects continue, and their implementation reports can still inform future purchases under other funding and agency budgets.
USDOT’s SMART news page described Manchester, New Hampshire’s smart-intersection kickoff on August 13, 2026. It also described the July 22 site visit to a Las Vegas project installing communications infrastructure for passive pedestrian detection. Both examples are project activity, not proof of a general safety outcome. Outcomes require each project’s own evaluation.
An operating contract has to describe staff time, data access, subscriptions, maintenance, updates, retesting, and how the agency will know whether the system still works.
The field report that complicates the dashboard story
USDOT has begun posting Stage 1 final implementation reports. One useful case is the Mid-America Regional Council’s Operation Green Light program in the Kansas City region. Its public report record and supporting dataset describe a network of more than 750 signalized intersections and an uneven operating reality: incomplete or delayed data, limited analytical resources, and the cost of advanced equipment and functioning detection across participating agencies. The underlying dataset dates to 2025; USDOT posted its final-report page in May 2026.
This is why I am cautious when “AI-enabled” becomes the entire sales story. An agency may first need to repair detection, reconcile phase labels, or train staff. The comparison that matters includes the volume of usable information and the time needed to turn it into an authorized decision.
The same point applies to passive pedestrian sensing. USDOT’s SS4A ITS use-case guidance, updated March 27, 2026, describes eligible demonstration examples involving pedestrian detection and walk-time adjustment, as well as mobile accessible signal systems and conflict warnings. Eligibility for a demonstration is not approval of every device, timing plan, or site design. Each proposed field use still needs its owner’s engineering review and acceptance criteria.
The intersection has several suppliers—and one public owner
A smart intersection combines assets that obey different rules. The detector observes. The controller executes an approved plan. Communications carry records and commands. The analytics layer interprets data. The visible indication tells a person what the traffic-control system is displaying. An LED module does not create detector events, optimize timing, produce V2X messages, or validate an AI model.
For procurement, I would put these layers in a responsibility register before evaluating software demos. Name an owner for each interface and an authority for every change. An integrator may coordinate the system, but the road authority needs a record of what was installed, approved, and tested. Our V2X signal procurement analysis discusses a related boundary for connected-vehicle messages.
Begin with the decision the system is allowed to make
“Optimize traffic” is too broad to serve as a test. An agency might want to identify corridors for retiming, reduce transit delay, respond to a pedestrian call, find detector faults, or warn about a potential conflict. Each use case has different inputs, timing sensitivity, legal authority, and consequences when the data are wrong.
The concept of operations should state the decision in one sentence. Flagging an intersection for engineer review requires a different contract from adjusting a signal setting automatically.
Ask what data are required, who may approve a change, what happens during an outage, and which metric will show improvement against a baseline. “The platform handles it” leaves the scope incomplete.
In my view, decision authority is the cleanest way to separate decision support from automation. A dashboard can help an engineer prioritize work without touching field timing. An automated control function needs a far more explicit account of its limits, fallback, and field test. A procurement should not let the two descriptions drift together.
Data readiness comes before platform selection
The Federal Highway Administration (FHWA) describes automated traffic signal performance measures as measures, collection, and analysis tools that support operations, maintenance, management, and design. Those functions rely on the quality of the underlying records.
A connected cabinet is not automatically a data-ready cabinet. A detector can report events while its zone no longer matches a changed lane. A controller clock can be inconsistent with another system. A phase name can mean something different across agencies. The resulting analytics may look precise but answer the wrong question.
Sample actual event data at representative intersections before choosing a platform: controller and firmware, detector coverage, timestamps, phase mapping, network availability, export format, and construction changes. Inventory signal heads and modules if renewal is in scope.
Then classify each location for the use case: ready, ready after repair, or requiring an upgrade. This planning judgment makes the rollout and budget more credible than a count of connected intersections.
Specify what happens when the inputs are bad
Missing data are a normal operating condition, not an edge case to discover after launch. The solicitation should name the events needed for each metric, define completeness and latency thresholds, and require the platform to mark or suppress conclusions when those thresholds are not met.
I would ask vendors to show three live states: valid input with a usable result; degraded input with an explicit confidence or quality warning; and unavailable input with no implied recommendation. The owner should be able to see which detector or interface caused the downgrade and what work order or escalation follows.
Also require versioned configuration records. If lane geometry, detection zones, controller firmware, timing, or software changes, an analyst must know which data were generated under which configuration. Data export, retention, and access after the contract ends belong in the same discussion. A proprietary model can still provide a clear account of its inputs, limits, status, and audit trail.
This is an engineering issue as much as a software issue. If an operator cannot reproduce the basis of a recommendation after a crash complaint or signal malfunction report, the platform’s apparent precision has little value.
A system needs a shift schedule as well as a software license
Operation Green Light’s experience points to a familiar gap between deployment and operations. An alert is useful only when somebody can review it, determine whether it is a field fault or a data problem, and close the case. Regional partners may have very different staff capacity.
Assign recurring work: detector checks, configuration updates after lane work, timing approval, account management, vendor escalation, spares, and validation after a component change.
Price hosting, connectivity, software, calibration, field service, retention, and training during the contract and after grant support. A low installation price can conceal heavy operating work, especially for smaller agencies.
FHWA’s signal-systems training material emphasizes the work before, during, and after implementation and the integration of performance measures into everyday agency practice. Procurement should specify role-based training and a handoff that new staff can use without the original project team.
Acceptance is a field event, not a slide deck
Acceptance criteria should be set before vendors install equipment. I recommend four gates that follow the order in which evidence becomes meaningful.
1. Field baseline. Confirm the approved controller configuration, detection zones, communications, signal indications, cabinet records, and known exceptions. A platform should not inherit undocumented faults and then be judged against them.
2. Data and interfaces. Verify identifiers, timestamps, event completeness, latency, export, and outage behavior. Reconcile a sample of platform data against the field record.
3. Use-case behavior. Test the approved function under representative conditions. For a recommendation, compare its output with an independent engineering review. For an authorized automatic action, test limits, fallback, and recovery as specified by the owner.
4. Operations handoff. Confirm training, accounts, manuals, support terms, maintenance routines, change control, record retention, and a path for retesting after material changes.
Each gate needs a sign-off owner and recorded result. Changes in detector placement, lane geometry, timing, firmware, software, or communications should trigger review of the affected tests under an agreed change procedure.
The visible indication still needs a model number
The LED signal module is the part of the system a driver or cyclist sees. For that reason, it should have a precise submittal. A smart-intersection specification does not make the display interchangeable with the detector, controller, or platform.
When visible hardware is renewed, identify the indication and color, size, lens treatment, operating voltage, terminals, head fit, current technical sheet, applicable performance evidence, agency approval, warranty, and drawing revision. The Frontier product overview and technical library help buyers locate families and documents; the exact order code and project requirements govern the final choice.
For a conventional AC-powered roadway signal, Frontier’s public page identifies 433 Series ball modules in 8- and 12-inch circular indications at 80–135 Vac. The 431/432 Series arrow page identifies 12-inch red, yellow, and green arrow indications at 80–135 Vac. These are examples of visible signal products for evaluation, not a claim that they include AI, detection, communications, or blanket approval for a particular project. Confirm the current exact-model sheet and the owner’s acceptance list.
If a project also includes pedestrian, bicycle, bus, or railroad indications, select the appropriate product family and governing design separately. USDOT’s broader ITS use-case list does not turn a visual pedestrian display into an accessible pedestrian signal system or a crossing light into a prediction platform.
The request for proposal in one page
An agency can make this more practical by including a one-page schedule in the solicitation. It should require every proposer to identify the planned deliverable, its owner, the evidence at acceptance, and the recurring cost after handoff.
| Question in the solicitation | Evidence to make the answer reviewable |
|---|---|
| What safety or operating decision will improve? | Defined use case, baseline, and measurable outcome |
| What is the available field inventory? | Controller, detector, network, signal face, and configuration register |
| What makes data usable? | Required events, quality thresholds, exception rules, and export test |
| Who may change field operation? | Named authority, permitted bounds, approval and rollback procedure |
| What happens during a failure? | Fallback, alarms, escalation owner, and recovery test |
| How will the project be accepted? | Field test plan, evidence record, sign-off, and retest triggers |
| Who pays after the pilot? | Year-by-year staffing, service, license, hosting, and repair costs |
| Which visible hardware is proposed? | Exact model, current sheet, agency acceptance, and inspection record |
That schedule is a better basis for comparing bids than a list of adjectives such as “open,” “real time,” or “AI powered.” Each adjective needs a definition and a test. The schedule also makes gaps visible early, while the agency can still change the procurement rather than negotiate a repair after installation.
The next competitive edge is an operation that can be inherited
The decisive test may be whether a new traffic engineer can inherit the system: identify a fault, reproduce a record, authorize a change, replace a component, and revalidate the operation.
My recommendation is to begin every smart traffic signal procurement with a bounded use case and a field-readiness sample. Assign ownership to each layer, specify data failure behavior, budget recurring work, and make field acceptance a contract deliverable. The resulting project may be less flashy in a presentation. It will be easier to operate and easier to explain to the public.
Where the scope includes conventional roadway indications, evaluate the exact Frontier 433 ball or Frontier 431/432 arrow module against the approved face, electrical system, housing, and current agency specification. For model-specific submittal support, contact Frontier.
Frequently asked questions
Does an AI traffic signal require replacing every LED module? No. The owner should define the use case and inspect the condition and compatibility of existing indications. A software, detection, or controller project may have a separate visible-hardware scope.
What is the first readiness test for a smart signal pilot? Sample real controller and detector records at representative intersections. Check event completeness, timestamps, phase mapping, communications, and the intended operating decision before comparing platform features.
Who approves a change in signal timing? The responsible road authority through its approved engineering process. A dashboard recommendation and a vendor product sheet do not constitute site-specific authorization.
How should buyers evaluate an AI platform when data are missing? Require the platform to show degraded and unavailable input states, suppress unsupported conclusions, identify the source of the issue, and record the escalation. Set the thresholds and tests in the contract.
What can Frontier provide within this kind of project? Frontier lists LED modules for roadway and other signal applications. A buyer can evaluate an exact listed model for its visible indication, voltage, size, lens, documentation, and agency requirements; control and analytics functions need separate suppliers and acceptance evidence.
References (APA)
Federal Highway Administration. (n.d.). Automated traffic signal performance measures. U.S. Department of Transportation. Retrieved September 28, 2026, from https://ops.fhwa.dot.gov/arterial_mgmt/performance_measures.htm
Federal Highway Administration. (n.d.). Training and workshops: Arterial Management Program. U.S. Department of Transportation. Retrieved September 28, 2026, from https://ops.fhwa.dot.gov/arterial_mgmt/training.htm
LEOTEK Frontier. (n.d.). Frontier Arrow 12-inch 80–135 Vac ITE LED traffic light module. Retrieved September 28, 2026, from https://frontier.leotek.com/product/frontier-arrow-12-inch-80-135v-ite-led-traffic-light-module/
LEOTEK Frontier. (n.d.). Frontier Ball 8-inch/12-inch 80–135 Vac ITE LED traffic light module. Retrieved September 28, 2026, from https://frontier.leotek.com/product/frontier-ball-8-12-inch-120v-ite-led-traffic-light-module/
LEOTEK Frontier. (n.d.). Traffic signal product resources and downloads. Retrieved September 28, 2026, from https://frontier.leotek.com/resources/
U.S. Department of Transportation. (2026, February 26). SMART Stage 2. https://www.transportation.gov/grants/smart/smart-stage-2
U.S. Department of Transportation. (2026, March 27). Intelligent Transportation Systems use cases for Safe Streets and Roads for All. https://www.transportation.gov/grants/ss4a/ITS-use-cases
U.S. Department of Transportation. (2026, May 7). FY22 SMART final implementation report: Mid-America Regional Council—Missouri. https://www.transportation.gov/grants/smart/fy22-smart-fir-mid-america-regional-council-missouri
U.S. Department of Transportation. (2026). SMART news. Retrieved September 28, 2026, from https://www.transportation.gov/grants/smart/smart-news
Webb, R., Eichorn, K., Stretz, J., Rotering, K., Hare, M., Hansen, B., Azu, M., Zeng, L., Kondyli, A., Masud, S. S. B., Francis, L., & Viss, B. (2025). Traffic signal performance measures and analysis [Data set]. Strengthening Mobility and Revolutionizing Transportation Program. https://doi.org/10.21949/442k-1z92
Editorial scope: This analysis uses public sources available through September 28, 2026. The diagrams are decision frameworks, not site engineering drawings or proof of product compliance. Confirm the exact model and current owner requirements for every project.
