A vehicle detection zone should represent a roadway decision, not a rectangle drawn until the screen looks busy. Presence, passage, advance detection, queue, speed, turning movement, stopped vehicle, access control, and warning functions require different geometry, event semantics, latency, hold behavior, truth data, and failure response.
Table of Contents
Name the Road Decision and Its Owner
Identify whether the zone supports signal actuation, extension, count, speed, queue, wrong-way or approach warning, access control, stopped-vehicle alert, or analytics. Name the traffic engineer, controller owner, data owner, maintenance team, safety reviewer, and authority that approves the operating logic.
The MUTCD states that traffic-signal design and operation must consider the needs of all traffic modes. Include vehicles, motorcycles, bicycles, pedestrians, micromobility, transit, and site-specific users where the application requires them.
Write the action created by each event and the safe behavior when the event is missing, late, stuck, duplicated, or uncertain. A sensor output is not complete until the receiving controller or platform behavior is defined.
Separate Presence, Passage, Tracks, and Derived Events
Presence asks whether a target occupies a zone and may require reliable stopped-target behavior. Passage identifies a crossing. Tracks add position and identity over time. Count, speed, queue, dwell, turn, and warning events are derived from those observations and rules.
Do not assume that a device supporting one output supports all others. FHWA explains that traffic technologies vary in their ability to produce count, presence, speed, classification, weight, and multiple-zone data.
| Zone-register field | Example question | Acceptance evidence |
|---|---|---|
| Function | Presence, passage, queue, speed or warning? | Approved control/data requirement |
| Geometry | Which lane, polygon, range, height and direction? | Surveyed plan and configuration export |
| Event rule | Entry, exit, dwell, hold, debounce and timeout? | Time-coded scenario with expected output |
| Target scope | Which classes and movements are required? | Stratified truth set |
| Boundary cases | Spillover, edge stop, lane change, occlusion? | Representative field scenarios |
| Fail state | What happens on stale data, power, clock or network loss? | Fault-injection and controller record |
Survey the Road Before Drawing Zones
Capture lane edges, stop bars, shoulders, paths, medians, grades, curves, turn pockets, parking, signs, guardrails, poles, vegetation, buildings, construction, mounting coordinates, height, azimuth, tilt, and vibration. Record queues, weaving, lane changes, large-vehicle occlusion, glare, shadows, precipitation, spray, and relevant seasonal conditions.
FHWA’s detector handbook notes that radar zone setup can require careful aiming and calibration, followed by a manual count comparison and zone adjustment. Use current product instructions, but retain this independent truth discipline.
Freeze Coordinates and Event Semantics
Store zone polygons or range boundaries, coordinate axes, origin, lane and direction, height assumptions, mounting reference, and exclusion areas. Export the accepted configuration rather than relying on a screenshot.
Define event and track fields: timestamp, time source, zone, lane, direction, object or track ID, class, speed, occupancy, confidence, quality, sensor health, sequence, and update behavior. Specify whether the sensor or central platform owns debounce, dwell, hold, queue, or warning rules.
Align clocks and define late, duplicate, out-of-order, missing, and stale records. A correct detection delivered after the controller action window can still fail the use case.
Commission Edges, Queues, and Degraded States
Build truth scenarios for free flow, stop-and-go, full stop, creep, close following, turns, lane changes, straddling, large and small vehicles, motorcycles/bicycles where in scope, queues extending through zones, empty road, weather, and maintenance activity. Score each contracted function separately.
Test power, network, clock, blocked view, sensor movement, configuration loss, controller loss, and recovery. Confirm visible health and safe controller behavior. Use the traffic-radar procurement guide for broader sensor selection and the traffic-sensor calibration guide for lifecycle verification.
Govern Changes as Road Changes
Issue a change ticket for resurfacing, lane remarking, temporary traffic control, new poles or signs, vegetation, building work, sensor movement, firmware, analytics, controller logic, or event-schema change. Preserve the earlier configuration and run the relevant regression set.
Evaluate the TRVF-8221 radar-video sensor, TRVF-8221-SCO flow detector, and SW1 warning sensor against the zone register. The smart-transportation category, smart-city solution, and resource center support design and commissioning records.
FAQs
What is the difference between a presence and passage detection zone?
A presence zone reports occupancy while a vehicle remains in a defined area; a passage function reports a crossing or event. The sensor and controller logic must support the required behavior.
How should a vehicle detection zone be documented?
Record site coordinates, lane and direction, polygon or range limits, mounting reference, entry and exit logic, dwell and hold, latency, exclusions, event fields, controller action, fail state, and truth test.
When should traffic detection zones be retested?
Retest after sensor or pole movement, lane or marking changes, resurfacing, construction, vegetation or obstruction change, firmware or analytics updates, controller changes, and persistent data drift.
