A detector specification usually starts to go wrong long before procurement – when the requirement is defined as a product type rather than a traffic outcome. If you are working out how to specify traffic detectors, the key is to begin with what the detector must achieve on the network, then narrow that down to the sensing method, mounting arrangement, outputs and support needed to make it work reliably in the field.
That matters because “vehicle detection” is not one requirement. A stop line presence detector for signal control, a cycle approach detector on a side road, an above-ground replacement for failed loops, and a multi-lane count and classification application each place very different demands on the technology. A weak specification can still attract compliant bids on paper, but leave you with blind spots, poor call rates, awkward installations or data that does not support operational decisions.
Start with the traffic management objective
The most effective specifications are written backwards from the operational use case. Before naming radar, AI video or wireless sensing, define what problem the detector is there to solve. Is the aim to improve MOVA or VA performance, extend detection without further carriageway cuts, pick up cyclists more reliably, reduce unnecessary stage calls, support road safety interventions, or gather classified traffic data for scheme appraisal?
Each of those objectives changes the detector requirement. For signal control, latency, stable presence detection and dependable outputs into the controller matter more than rich analytics. For network monitoring, the quality of speed, count, classification and directional data may be the priority. For active travel schemes, the specification needs to consider smaller targets, mixed traffic and the real geometry of cycle approaches rather than assuming a standard vehicle-only scenario.
If the objective is not explicit, suppliers will fill in the gaps differently. That is where mismatched solutions creep in.
How to specify traffic detectors by application
A practical way to approach how to specify traffic detectors is to group requirements by application rather than by technology family. That keeps the focus on measurable performance.
Signal control and stop line detection
For UTC, MOVA, VA and related signal applications, define the detection zones required, the lane arrangement, the need for presence versus pulse, and the interface to the controller or outstation. Include whether the detector is replacing loops directly or supporting a revised layout. You should also state expected performance in queues, closely spaced traffic and poor weather, because these are the situations where a nominally suitable detector can behave very differently in service.
Mounting constraints are equally important. If there is limited pole availability, challenging sight lines, wide carriageways or cluttered urban streets, say so. Above-ground systems can remove the need for lane closures and civil works, but only if the specification reflects the physical realities of the site.
Cyclist and pedestrian detection
Cycle detection is often under-specified. Writing “must detect cyclists” is not enough. You need to define approach speed, likely trajectory, filtering requirements and whether the detector must discriminate between cycles, motor vehicles and pedestrians. A shared space, early release arrangement or side-road crossing all require different zone design and logic.
For pedestrian-related applications, be clear whether the detector is monitoring presence in a waiting area, movement in the crossing, or both. If the detector is intended to support accessibility and safer crossing operation, specify the environmental and behavioural conditions it must handle, such as groups waiting near the kerb or partial occlusion.
Counting, classification and speed data
Where the main requirement is data collection, the specification should state the reporting outputs and quality standard expected, not just the fact that traffic counts are needed. Class intervals, vehicle classes, directional split, speed bins, lane-by-lane reporting, cycle counts and occupancy all need to be set out if they matter.
It is also worth defining whether the detector is being used for permanent monitoring, temporary surveys or before-and-after scheme evaluation. The acceptable installation method, power arrangement, communications path and validation process may vary significantly between those cases.
Specify performance, not just hardware
One of the most common mistakes is to specify the device in detail but say very little about performance. A better specification explains what the detector must do under real operating conditions.
That includes detection accuracy, false call tolerance, missed detection tolerance, update rate, and the ability to maintain performance across relevant traffic states. A detector that performs well in free-flow conditions may be less dependable in standing queues, and one that works well for cars may need different tuning to detect motorcycles or cyclists consistently.
Where possible, define the required detection area or corridor rather than relying on generic statements. If a side-road approach needs advance detection to manage calls more efficiently, state the length and lane coverage needed. If a roundabout arm requires queue monitoring, make that explicit. Precise geometry helps suppliers design a credible solution and gives you a basis for testing acceptance.
Do not ignore site constraints
A technically capable detector can still be the wrong choice if the site does not support it. Good specifications include the conditions that affect installation, aiming and maintenance.
Describe carriageway width, number of lanes, pole locations, mast arm availability, mounting height, likely obstructions, street lighting columns, trees, street furniture and any known line-of-sight issues. If the location is exposed to spray, low winter sun, headlight glare or heavy turning traffic, those details are relevant too.
This is where above-ground technologies often offer a clear operational advantage over embedded detection. If minimising roadworks disruption, reducing possessions or avoiding repeated carriageway intervention is part of the business case, say so in the requirement. That allows the evaluation to reflect installation impact and whole-life practicality, not just detector functionality.
Define interfaces, data outputs and integration
Detector performance is only part of the story. The specification also needs to cover how the device connects into the wider traffic system.
For traffic signals, state the interface requirements clearly, including output types, protocol expectations and any constraints within the existing controller or cabinet arrangement. For monitoring applications, define how data will be exported, viewed or passed into existing platforms. If your authority or consultant team needs raw data, event logs, occupancy, speed or classified outputs in a particular format, build that in from the start.
This is also the point to specify time synchronisation, remote access, health monitoring and alarm reporting where these matter operationally. A detector that produces good data but is difficult to supervise at scale can create unnecessary maintenance burden.
Allow for verification and tuning
If you want dependable field performance, your specification should not stop at installation. It should require commissioning, validation and tuning against the actual site conditions.
That means setting out what acceptance looks like. It may include on-street observation, comparison against manual counts, controller call verification, or checks across different traffic periods. This is particularly important for AI video and radar systems, where zone configuration and filtering can materially influence results.
There is a balance to strike here. Overly rigid factory-style tolerances may not reflect real street conditions, but vague acceptance wording leaves too much open to interpretation. The answer is usually an application-based test plan with agreed scenarios and measurable outputs.
Write the specification to be future-usable
Detector requirements rarely stay static. A junction initially specified for vehicle actuation may later need better cycle detection, queue monitoring or network analytics. If the site is likely to evolve, avoid writing a specification so narrow that useful capability is excluded.
That does not mean buying complexity for its own sake. It means thinking carefully about scalability, software configurability, additional detection zones and access to data that may support future operational changes. In many cases, a non-intrusive detector can do more than a like-for-like loop replacement, but only if the specification leaves room to use that capability.
A practical checklist for how to specify traffic detectors
When deciding how to specify traffic detectors, your document should make clear six things: the traffic objective, the application type, the site geometry, the required detection performance, the integration method, and the validation process. If any one of those is weak, the procurement may still move forward, but the risk shifts to installation and operation.
It also helps to separate mandatory requirements from desirable ones. That allows proper technical comparison without forcing every scheme into the same template. A rural speed management site, an urban signalised junction and a cycle-priority crossing do not need identical detector criteria, even if they are procured within the same framework.
For authorities and consultants across the UK and Ireland, that pragmatic approach is often the difference between specifying a detector and specifying a working outcome. The technology should fit the network, the controller strategy and the operational problem – not the other way round.
The best detector specification is the one that leaves very little to assumption, while still giving enough room for a technically better solution to be proposed.