Incident management is an art, but it should be a science!

Published in
9 min readSep 10, 2020


When it comes to roads, almost everyone looks at the vehicles themselves. And with CAVs positioned as the perfect solution, it is easy to forget that when things go wrong–and they inevitably will–how will those monitoring our roads respond?

Most roads around the world are not monitored, but for those that are, the steps taken in managing an incident vary depending on the type of incident and the resources available. For simplicity, we’ll break incident management into 6 steps: Detection, classification & validation, Prioritisation, Response, monitoring, resolution.

Detection and Validation

You can’t respond or manage incidents you don’t know about, but the detection phase is the first, and probably most lacking step in incident management. There are a number of ways control centres are informed about incidents (in order of reliability):

  • Patrol: Highway Patrols are resources that are available to the busiest of road networks. However, as with many resources, Highway Patrols are scarce and most often come across incidents serendipitously, rather than deliberately. As such, their usefulness in detecting incidents is limited.
  • CCTV: An amazing tool for understanding an incident, but they are not continually being monitored and coverage is often limited. CCTV can be augmented with Automatic Incident Detection (AID), but this is vulnerable to false alerts, which severely reduces the trust in the output.
  • Loops/Radar: Loops and sidefire radar are in the best cases installed every 500m, and can be used to detect incidents. However, they rely on an incident having a measurable impact on overall traffic flow (unlikely in the case of stopped-vehicles at low flow periods). This also means that it is not possible to detect incidents that have happened during congested hours, as flow is already low.
  • General Public: Millions of drivers use the road network everyday, and many of them report risks they see on the road (this is the basic principle behind Waze). While this is useful, because the general public often don’t know exactly where they saw a risk, the information is often unreliable.

Even with all of these potential sources of information, incident detection is a manual task. Which means most incidents go undetected and therefore the risks go unmitigated.

If we take a vehicle stopped in a live lane as an example, Control Centres take on average 17 minutes to be notified, and this is based on the cases they are aware of, there are countless more incidents that occur without the control center ever knowing about them, and every second that an incident goes undetected increases the likelihood of a more severe incident taking place.

“Control centres can take an average of 17 minutes to spot a broken-down vehicle”

Step Duration: 17 Minutes

Classification and validation

Often, the first detection comes from an unreliable source: public phone calls or vehicle counters. This only provides the control centre with an indication that an incident has happened (become someone called it in, or because we saw a slowdown in traffic) within a wide area. The road operator does not know the nature of the event, nor its precise location.

Following a detection, the operator must gain a better understanding of the nature of the event (location and type) and validate that it is indeed an ongoing event (they receive many false alerts). Validation is an important step as response resources have significant implications (e.g., closing a lane in peak hour), scarce and often not dedicated to the road (e.g., ambulance). Validation often leverages either the CCTV network or Highway Patrol, and its purpose is to fully understand an incident in terms of location, severity, lane affected and how best to respond. This can take between 5 and 20 minutes, depending on how the incident is validated, and when these resources are not available, incidents often go unvalidated.

Step Duration: 10–20 Minutes


On large road networks, multiple events are often happening simultaneously. Highways England recently estimated that they have 1.6 broken down vehicles / mile / day and an order of magnitude more discretionary stops. Once an incident has been detected and validated, the next step is to prioritise your response (road operators often have more than one incident at a time). To prioritise incidents the operator needs to understand the context in which an incident has occurred. For example, if a vehicle stops on a hard shoulder of a very quiet road, the risk is lower than if a car stops in a live lane when visibility is poor.

Currently, prioritisation is a very light touch step as most incidents are not reported (so there aren’t many incidents to prioritise), and operators do not have access to a comprehensive source of information that would allow them to assess the context. As a result, a first-come first-served approach is taken, which means the response to more urgent incidents is delayed by 5–20 minutes.

Step Duration: 5–20 minutes

Plan and execute response

Once an operator is aware of an incident and understand the context in which it is happening, they can start to plan their response. Their response depends on a number of factors, such as ‘priority’ and resources available. Two methods you might see on U.K. motorways are Variable Messaging Signs (VMS) and Highway Patrols. If these tools are available, the operator will manually set a message on the sign, and radio the HIghway Patrol the known details about the incident.

These processes take time (3–5 minutes) and are prone to human error. Often we see signs to be aware of a risk ahead, after we have already passed the incident. Assuming everything goes well, the response itself can take between 16 minutes for a stopped vehicle and 57 minutes for an accident. This has of course been extended because of the time it initially took to trigger the response, during which the incident could have deteriorated and traffic would have worsened.

Step Duration: 3–5 Minutes


Once the operator has responded to an incident, they now manually monitor the incident. This is usually done using CCTV (when available) or feedback from a Highway Patrol unit. If the incident has become more risky, the operator will update their response accordingly. This manual loop of monitoring and responding continues until the incident has been resolved.


Once an incident has been resolved, the operator must manually remove any signals set, inform any patrols or emergency personnel that the incident is over and they can stand down.

The road operators that are in charge of our roads work day-and-night to keep us moving safely. But, the tools they rely on create a process that can take 45 to 120 minutes to resolve even a simple incident. To put things in context, one of our main partners, the Ayalon Highway, estimates that an incident impacting traffic in just one lane can reduce overall road capacity by 50%. More urgently, every additional minute whereby an incident is unresolved increases the chance of an accident by 2.8%. This means that a three-lane toll road in peak hour can lose between $7,200 and $16,200 per incident and reduce the safety of their road during that time by 56%.

What could this process look like if we leveraged data and new technologies?

As you can see, the steps taken in incident management are still manually performed, decisions are often made without all the necessary information and most incidents go unidentified and unmitigated. The question is, what can be done to improve this process?

As with many processes that currently require human interaction, then can often be improved by giving the user all the necessary information needed to make a decision, rather than requiring them to hunt for the information. While this doesn’t seem revolutionary, it requires a new way of thinking about how roads are managed and what technologies and data sets are available to support this.

Here is an example of how new technologies can help support the decision making process by automating certain decisions and providing necessary information to the decision maker when automation is not suitable.


Prevention is almost always more beneficial than reaction.

Before an incident has even occurred, data is being collected about current traffic conditions and environmental conditions to provide a road with a risk profile. This risk profile can be used to assess whether or not preventative actions, such as reducing speed limits or sending out an alert to drivers should be taken.


  • Detect — As soon as an incident has happened, the control center will receive an alert notifying that an incident has occurred on the road. This alert will be powered purely by data collected from the road.
  • Classify — The data collected regarding the incident will be used to classify its nature, such as a stationary vehicle or accident.
  • Verify — The nearest camera will automatically pan to the incident, and provide the operator with an instant visual. This visual can be used to verify that an incident has occurred.

If the control center has lots of incidents happening simultaneously, the alerts would be prioritised based on ongoing calculations of risk associated with that incident.

Plan and execute response

As soon as the control center has been notified, they will be provided with a list of suggested responses based on the type of incident and resources available. From here the operator will be able to deploy the resources with minimal actions.

Certain responses, such as setting VMS will be triggered automatically with a predefined message. This quick action will act to reduce the risk of a secondary incident.

As more cars become connected, vital safety messages could be displayed within the vehicles themselves. This would reduce the likelihood of a driver missing such a message and increase the message’s effectiveness.


Now an incident is being dealt with, rather than requiring the operator to periodically check the incident for updates, they will automatically be provided with updates when necessary. These updates could be changes in the risk profile or a secondary incident notification. These updates will be accompanied by additional action advice if necessary.

As before, this loop of monitoring and responding continues until the incident is over.


Once an incident has been resolved, the operator will be provided with a notification that the incident has been resolved. At this point, the responses deployed, such as VMS, will be turned off and the incident marked as solved.

As you can see in this example, the amount of manual tasks operators are required to perform have been reduced, they are provided with more contextual information regarding the incident meaning they can make better decisions, and the actions they do need to perform have been simplified. All of this combined aims to make the road networks safer and more efficient.

Valerann Smart Road System

Valerann’s Smart Road System has been designed from the ground up to change the way our roads are managed. Leveraging modern system architecture, advanced data analytics and a proprietary data source, Valerann can understand everything that is happening on the road in real time, and have an impact on each of the steps in incident management and decision making:

Pre-incident — We are monitoring every vehicle and risk on the road and continually assessing the likelihood of an incident.


  • Detect — Valerann’s Smart Road System is collecting data on the movements of all the vehicles on the road. When the system detects an anomaly (i.e. traffic behaviour that is not typical), it provides the control center with an incident alert.
  • Classify — Using the same data collected to detect the incident, Valerann can use this data to understand and classify the type of incident.
  • Verify — By precisely location an incident on the road, and by leveraging CCTV cameras, Valerann can provide the operator with an instant visual of the incident for verification.

Plan and execute response — With modern architecture and systems, we are able to integrate into wide-variety of ancillary systems to help plan and execute a response to an incident.

Monitor — By continually monitoring the road and the incident, we are able to determine when an incident has been resolved or changed in state. This eliminates the need for an operator to periodically check in on an incident.

Resolve — With the same means by which VMS or other response we’re activated, once an incident has been resolved, it is a simple task to deactivate these responses.

Valerann has deployed its system on the largest motorways in the US, UK, Spain, and Israel, and has partnered with Jaguar Land-Rover and Bosch to develop a data marketplace for autonomous vehicles. Learn more at!Incident management is an art, but it should be a science!



Editor for

Developing operating systems for roads, transforming them into data generating infrastructure that make our journeys safer, faster, and autonomy ready