Automatic incident detection (AID) algorithms sit between the sensor network and the signal controller, watching traffic streams for patterns that indicate a crash, a stalled vehicle, or a sudden blockage. Most traffic engineers are familiar with adaptive signal control as a concept, but the incident detection layer that enables a rapid response to non-recurrent events is less often examined in detail.
Why incident detection is a distinct problem
Standard traffic management deals with recurrent congestion: morning peaks, school zones, event surges. Incident detection addresses non-recurrent events, which are, by definition, unpredictable in location and timing. A fixed timing plan can accommodate predictable demand. It cannot respond to a vehicle stopped in a lane without external detection telling the controller something is wrong.
The challenge is speed. Research from the US Federal Highway Administration has found that traffic conditions deteriorate rapidly after an incident: secondary crashes become a real risk within minutes if upstream queues form unchecked. An AID algorithm needs to identify an incident and trigger a response faster than a human operator monitoring CCTV could reasonably act.
The main algorithmic approaches
Three broad families of algorithm are deployed in operational traffic systems today.
Comparative pattern algorithms measure occupancy, speed, and volume at adjacent detector stations and flag when downstream measurements diverge from upstream. The California algorithm, one of the earliest formalisations of this approach, compares occupancy at consecutive loop detectors. A sharp occupancy drop downstream of a rise upstream suggests a blockage. It's computationally lightweight, which made it practical during an era when roadside hardware had limited processing capacity.
Statistical process control algorithms treat the traffic stream as a process with defined baseline behaviour. McMaster and CUSUM (cumulative sum) algorithms monitor departures from a rolling baseline. When observed speed or flow crosses a control limit, the system raises an alert. These approaches perform well where baseline traffic conditions are stable and well-characterised, such as motorway corridors with years of historical data.
Machine learning classifiers represent the current frontier. Support vector machines, neural networks, and ensemble methods trained on labelled incident datasets can incorporate far more input variables simultaneously: loop occupancy, radar-derived speed profiles, weather data, time of day, and even signal state history. The trade-off is that these models require substantial labelled training data and ongoing performance monitoring to catch model drift as traffic patterns evolve. Adaptive signal control systems that incorporate ML-based detection are now being trialled on arterial networks in several Australian capital cities.
Key performance metrics: DR, FAR, and MTTD
Any AID algorithm is evaluated against three metrics.
- Detection rate (DR): the proportion of real incidents the algorithm correctly identifies.
- False alarm rate (FAR): the proportion of alarms that do not correspond to a real incident.
- Mean time to detect (MTTD): the average elapsed time between incident occurrence and alert generation.
These metrics pull against each other. Tuning an algorithm for a higher detection rate typically raises the false alarm rate too. A high false alarm rate erodes operator trust: if controllers learn to ignore algorithm alerts because most are spurious, the system's value collapses. Practical deployments target a FAR below 1 per cent per hour of operation, with MTTD under 90 seconds for motorway-class facilities.
Sensor inputs and their effect on algorithm performance
Algorithm performance is only as good as the sensor data it receives. Inductive loop detectors remain the most common source of occupancy and volume data in Australian networks, but they are point measurements. They tell the algorithm what is happening at a specific location, not between stations. Wide detector spacing, common on arterial roads, creates blind spots that delay detection.
Video analytics have changed the picture considerably. Camera-based detection can monitor an entire lane segment continuously and identify stopped vehicles by their absence of movement over multiple frames. Radar and lidar sensors add speed profiles without the occlusion vulnerabilities that affect optical systems in rain or direct sun. The most capable AID implementations fuse multiple sensor types, using each to compensate for the other's weaknesses. Vehicle detection technology choices made at the design stage directly constrain which algorithm families are viable later.
Integration with signal response plans
Detection alone doesn't improve traffic outcomes. The algorithm must trigger a defined response. In practice this means one of three things: a timing plan switch that extends green time on unaffected approaches to clear upstream vehicles, a message to a variable message sign warning drivers of the incident ahead, or an alert to a traffic management centre operator who initiates a manual response.
The quality of the response depends heavily on how well the detection event is classified. Knowing that something has happened is less useful than knowing whether a lane is fully or partially blocked. More sophisticated classifiers attempt to categorise severity, not just flag a binary incident/no-incident state. Partial blockage events call for a different signal response than a full lane closure.
The Austroads guidance on traffic management systems acknowledges incident detection integration as a requirement for any network operating at the SCATS or SCOOT level of sophistication, and specifies that detection systems feeding adaptive controllers must meet minimum availability and accuracy standards.
Common deployment failures
Poorly tuned detection thresholds are the most common operational problem. Thresholds calibrated during initial commissioning on low-traffic conditions often produce excessive false alarms during peak periods, and vice versa. Seasonal recalibration, particularly in cities with strong wet/dry season variation in traffic patterns, is frequently skipped.
Detector faults are a second failure mode. A loop detector with a degraded inductive signature returns anomalous occupancy data that the algorithm interprets as an event. Without a sensor health monitoring layer, the AID system raises spurious alerts continuously until a maintenance crew identifies and replaces the faulty detector. This directly connects to how spillback detection systems handle upstream queue data: a corrupted detector feed produces the same pattern as a genuine queue, so sensor integrity and algorithmic reliability are inseparable.
Finally, system integration gaps between the detection platform and the controller software mean that even accurate detections sometimes fail to trigger the right response. This isn't an algorithm problem. It's a systems engineering problem, and it surfaces most often when hardware from different vendors is combined without thorough interface testing during commissioning.
Specifying AID for new projects
For transport engineers specifying an adaptive system, the key questions at tender stage are: what algorithm families does the platform support, what sensor inputs does it accept, what DR/FAR performance is warranted at what detection spacing, and how are response plans configured and updated post-deployment? Vendors often lead with headline detection rates from controlled test environments. Pressing for operational performance data from comparable deployed networks gives a more honest basis for comparison.
Incident detection is not a set-and-forget feature. Threshold review and retraining cycles for ML-based systems should be written into the maintenance schedule from day one, with defined performance benchmarks that trigger a review obligation rather than leaving it to operational discretion.