A congested road can prompt an immediate request for more cameras, a control center or a larger information screen. Before choosing equipment, identify who experiences the problem, when it occurs and which decision the new data will support. Otherwise a system can collect more information without changing how anyone works.
This guide proposes a brief for discussing intelligent transport projects. Its measures and trial examples are planning suggestions, not a signal design or operating instruction for any road.
1. Describe the problem from the road user’s position
“Congestion outside the school” could mean a turning queue blocks a junction, children wait too long to cross, pick-up vehicles lack suitable space, or staff cannot identify a fault. Each interpretation requires different evidence and ownership.
FHWA’s signal-management guidance starts with objectives, context and performance measures, considering different users including pedestrians, cyclists and vehicles. [1] This is a useful reminder that maximising the number of vehicles through a junction is not a complete account of a place’s needs.
Begin with observation during the problem period, conversations with operators and a simple picture of how people travel through the site. Assess whether existing information answers the question before proposing additional collection.
2. Connect each data stream to a decision
For each item of information, identify who looks at it, when they look and what they can do next. A detailed queue display has limited operational value if nobody receives the alert or knows how to coordinate a response.
| Example problem | Information to consider | Decision requiring an owner |
|---|---|---|
| Queues block another junction | Timing, location and pattern of accumulation | An authorized engineering review of operations |
| Detection equipment appears unreliable | Device status and missing-data periods | A maintenance task and restoration follow-up |
| Pedestrians encounter crossing barriers | Use patterns and site conditions | A review with responsible staff and affected users |
| Reports from two systems disagree | Definitions, timestamps and data origins | An agreed verification method and reference source |
This is a way to examine the system’s role in a workflow, rather than a shopping list of devices.
Data becomes useful when someone can act on it and own the follow-through.TIIS Insights
3. Define measures and their limitations together
Choose a principal measure around the problem, then check other effects. A change intended to address queues may also affect other approaches or pedestrians. Determining whether a change is suitable requires competent assessment and the requirements of the location.
FHWA describes automated traffic signal performance measures as measures and data tools supporting objective-based operation and maintenance. [2] The presence of a dashboard does not itself mean signals are automatically adjusted or that conditions have improved.
Document coverage and missing periods. Explain how unusual conditions, such as road closures or weather, are treated and whether system clocks agree. Compare periods with reasonably similar contexts, and identify events that could explain a change. A precise-looking number should not hide uncertainty about the input.
4. Plan for missing data and failed equipment
A daily operating system should make stale or missing data visible. A frozen last value can otherwise look like a current observation. Show when information was last received, connection status and limitations the operator needs to understand.
Ask who receives a fault, who can access the device, what replacement arrangements exist and how work continues during repair. Where several suppliers are involved, define the troubleshooting boundary so the operator is not left coordinating an unclear chain of responsibility.
For images or identifying information, the responsible organization should determine purpose, access, retention and applicable requirements before operation. Collect the detail needed for the task and establish which information is appropriate for public display.
5. Trial a scope that can be evaluated
A useful trial might cover one clearly defined junction problem or a limited equipment group. Record the baseline, exercise the alert and maintenance workflow, then review the evidence with the intended users. Agree acceptance criteria beforehand: can a gap be detected, can the right owner receive a task, and can a report be checked back to its source?
Opening a dashboard successfully on one day is insufficient evidence of a repeatable process. Include realistic failures, reconnection and a change of operator in the exercise. Leave the organization with a usable guide and a clear responsibility record.
TIIS Smart Transportation & ITS provides a starting point for discussing a site problem, existing data and an appropriate project scope. A proposed solution requires site assessment and consideration by the responsible authority; it cannot be determined from a single photograph of a junction.
Before preparing a procurement brief
Knowing which decision the information will improve makes the equipment, budget and scope discussion more concrete. It also gives the parties a shared understanding of what the system needs to accomplish.
References and further reading
Use these primary sources to check the supporting information. Examples, tables and trial plans in this article are editorial proposals.
- Federal Highway AdministrationTraffic Signal Timing and Operations Strategies ↗
Objectives and measures that consider pedestrians, bicycles, transit and cars.
- Federal Highway AdministrationTraffic Signal Performance Measures ↗
Using data and measures to support signal operation and maintenance.
Discuss the site problem and data readiness
Start with the service information, then discuss a scope suited to your setting, users and goals.
Explore the related service
