Automated Approach for Generating and Evaluating Traffic Incident Response Plans ^†

Abstract

Traffic incidents usually have negative effects on transportation systems such as delays and traffic jams. Therefore, a traffic incident response plan can guide management actors and operators to take action effectively and timely after traffic incidents. In this paper, an approach has been proposed to generate and evaluate traffic incident response plans automatically when a traffic incident is detected. In this approach, a library of response action templates has been constructed beforehand to be used in the real-time generation process of a response plan template. According to the type and severity of the detected and confirmed traffic incident, a combination of relevant response action templates will provide a set of response plans. In addition, we have developed a simulation model for the study area by using Aimsun Next software (version 20.0.3), developed by Aimsun, to evaluate the performance of the generated response plans. Therefore, the simulation outcomes determine the rank of the generated response plans including the optimal response plans. The proposed approach considers the characteristics of input traffic incidents and transport road networks to generate response plans. Furthermore, the choice of the optimal response plan considers the characteristics of the input traffic incident. The implementation results show that the generated response plans can enhance and improve the overall network performance and conditions efficiently. In addition, the response plan ranking is considered to be a supportive tool in the network operators’ decision-making process in terms of the optimal response plan to be implemented or propagated.

1. Introduction

Traffic incidents may cause property damage, injuries, and fatalities. Furthermore, they can quickly lead to congestion and associated travel delay, increased pollutant emissions, and wasted fuel. An incident represents any unpredictable occurrence that disrupts traffic flow and reduces roadway capacity such as a broken-down vehicle, accidents and collisions, fires, or hazardous material spills. Traffic management represents a crucial tool in minimizing the impact of incidents and the negative consequences on network safety and efficiency [1]. Moreover, traffic incident management represents an important component of intelligent transportation systems for reducing the durations and impacts of traffic incidents through systematic, coordinated, and pre-planned use of human resources and equipment [2]. Therefore, once an incident is detected and confirmed, the incident response management system must operate in order to maintain a reasonable level of safety for all road users, preserve and protect human life, and minimise travel delay [3].

Generally, a traffic incident response plan can be defined as a preprepared artificial document containing some guidance and instructions for responders and traffic network actors in order to make a decision rapidly, accurately, and orderly during incident response [4]. Therefore, road users must be supplied with timely, useful, and accurate information to minimise the traffic impact of an incident (e.g., advise them to avoid the problem area by using variable message signs—VMS). In addition, the traffic management operator must review and approve the response plan before sending the messages (e.g., encouraging diversion) out to the signs [3]. An emergency response plan may include the following elements: traffic diversion, traffic flow regulation, and the dynamic dissemination of information (e.g., traffic conditions, traffic speeds, routing, and changes in roadway geometry) to road users [1].

Emerging situations on the different transportation services (e.g., traffic incident) can be defined and will delineate scenarios by using various predictive analysis and anomaly detection algorithms. For each scenario, different response plans can be generated in a dynamic manner. Response plans may contain multiple device level mitigation measures ranging from a “light” response to a “severe” response, and it is expected that the “intensity” of the response plans depends on or is proportional to the severity of the traffic incident. The mitigation measures within each response can be different, and the response variables can be configured according to the severity of the traffic incident. Each response plan can be evaluated with the use of simulations, or data-driven analytics, and the results of the evaluations can be presented to the network’s operators for further arbitration and decision-making.

In this paper, we describe an automated approach for generating and evaluating traffic incident response plans that is being developed in the context of FRONTIER, an EU funded research project. The proposed approach involves two main components: the Response Plans Generation Module (RPG) and the Response Plans Scoring Module (RPS). The first component will generate a list of response plans based on the scenarios that may be enacted on the network. Essentially, each response plan represents a configuration of a pre-defined template that includes a sequence of network management actions such as the opening and closing of road lanes, variable speed limiting, and traffic redirection. However, the second component, RPS, measures and assesses the impact of each response plan on the network performance (e.g., traffic flow, speed, density, and travel time). This response plan evaluation may support the decision-making process that needs to be done at some point by traffic management and network’s operators. We have developed and calibrated a simulation model for the study area using Aimsun Next software to be used for simulating and assessing the impact of different response actions of each response plan generated.

The remainder of this paper is organised as follows. In Section 2, we discuss related work, and in Section 3, we present the proposed approach and describe the details of its elements. Then, in Section 4, we discuss the implementation of the proposed approach, describe some example experiments, and demonstrate the results of these experiments. Finally, in Section 5, we conclude with a summary of the current status and future work regarding the proposed methodology.

2. Related Work

Traffic incident response plans guide traffic management actors and operators to take actions effectively and timely after traffic incidents. Considering and using such response plans will alleviate traffic congestion, save many losses, and increase safety.

An innovative real-time incident management platform has been introduced in [5] to detect and then classify incidents into two types, recurrent and non-recurrent, based on their frequency and characteristics. When an accident is detected and confirmed by the system, the platform triggers either a data-driven machine learning module (if the incident is recurrent) or traffic simulation modules (if the incident is non-recurrent). Therefore, for the non-recurrent incidents, the process of choosing the most appropriate response plan will mainly depend on the simulation output.

In another study, a real-time management system for traffic incident response plans has been developed in [4] in order to automatically and timely generate and manage traffic incident response plans. Three indicators were used to measure the system performance: precision, P; recall, R; and indicator, F. The method contains four procedures: case representation, case retrieval, case revision, and case learning. Therefore, when a traffic incident is verified, the response plans database will be triggered by the emergency management centre to generate response plans.

Additionally, a traffic management system has been proposed in [6] at a traffic control centre to support traffic management authorities in the traffic flow management task in Beijing. The system consists of a traffic modelling system, a traffic plan builder, and a traffic plan selector. It generates optimum traffic response plans based on traffic incidents, and for a given traffic incident, the traffic operations are analysed and simulated to provide the quantitative evaluation results for these alternatives. A traffic plan builder provides several features to help the operator to select the needed traffic measures (traffic diversion, entry gating, of promoting traffic flows of diversion routes) in response to a specific incident and automatically suggests the corresponding traffic control aspects.

To minimise an incidents impact (i.e., congestion, queues, and travel delays) on traffic, [1] designed a system to support traffic control operators when they select traffic incident response measures. The system uses a set of parameters such as demand, incident severity, and duration to select the most suitable traffic response plan. It predicts the duration of the input incident and estimates the impact area extent and the travel delays that will be caused by the incident in order to select a response plan. Each response plan includes a number of strategies to manage traffic flow such as diversion traffic volumes, diversion points, termination points for diversion, diversion routes, VMSs state, and new timing for traffic signals.

In order to achieve a state-of-the-art traffic management software system, ref.[7] implemented traffic incident response strategies using a real-time knowledge-based expert system. The real-time incident response plan generation subsystem provides response plans that are customised for the characteristics of the given incident. Response plans can be generated from incident data and can support various actions such as messaging signs and sending emergency vehicles to the location of the incident. Generating device states to support a response plan represents a key function of this subsystem. Six types of devices were involved: lane use signals (LUS), variable message signs (VMS), variable speed limit signs (VSLS), traffic signals (TS), blankout signs (BOS), and highway advisory radio (HAR).

In addition to this, some of the earlier studies that address traffic incidents, response plans and strategies, incident impacts, and evaluation of response plans have been reviewed and are described in

Table 1. Examples of some studies related to traffic incidents and response plans.

Reference	Description
[8]	Designed a simulation and evaluation framework to model an emergency response system for highway traffic safety and security or for minimising the average response times associated with different accidents on the road.
[9]	Assessed and enhanced traffic incident management techniques by using a scenario-based assessment methodology involving macroscopic traffic simulations, traffic performance calculations, and cost–benefit analysis.
[10]	Evaluated the impacts of incident management strategies such as ramp metering, VMS, and VSLS using a large-scale microsimulation model.
[11]	Analysed the impact of incidents in an urban traffic system by using flow data collected from loop detectors.
[12]	Analysed a wide range of traffic incidents and responses for the set of critical locations on a test network by using VISSIM microsimulation.
[13]	Introduced a method for deriving an optimal dispatching strategy for incident response by integrating GIS, traffic simulation, and optimisation systems.
[14]	Introduced a discrete time train and passenger simulation engine for urban railway networks and a mixed integer programming formulation for the problem of finding an optimal action plan as a response to an incident.
[15]	Examined and improved indicators for better incident prioritisation and development of rapid incident response plans.

.

The existing research efforts regarding real-time generation of traffic incident response plans as part of traffic incident management systems are somehow limited. In addition, most of these efforts address the problem without considering the effects of some traffic incident characteristics, such as incident location, start time, duration, type, and severity, on the generated response plans. Therefore, the performance and effectiveness of the existing real-time methods are uncertain. Therefore, our suggested approach for generating and evaluating traffic incident response plans represents a contribution to address the limitations of current practices by considering the following:

• The library of response action templates used to generate the appropriate response plans has been principally constructed by considering the characteristics of the road network (e.g., motorway or urban area) of the study area.
• The characteristics of the input traffic incident (i.e., incident type and severity) have been used to determine which response actions will be included in the response plan template.
• The impact of input traffic incident characteristics (i.e., incident location, time, and duration) has been considered in the response plan application and evaluation process. Therefore, ranking and suggesting optimal response plans will be largely affected by the traffic incident characteristics.

3. Approach

The proposed approach uses the anomalies and critical situations detected in the traffic network as input to generate many response plans aiming to optimise the transport network. Each response plan contains a set of actions that can adjust supply or/and demand features of a transport network in an optimal way. In addition, this approach uses Aimsun Next simulation framework to assess the response plans generated. Therefore, this approach aims to be enacted after an incident has been identified in the network to provide capabilities for the generation of appropriate response plans along with their scores. Each response plan includes a number of measures that aim to alleviate the network-wide congestion and restore the network conditions to normal. The overview diagram of the response plans generation and evaluation approach is depicted in Figure 1. It contains two main components: Response Plans Generation Module (RPG) and Response Plans Scoring Module (RPS).

3.1. Response Plans Generation Module—RPG

This component is responsible for building and constructing the traffic incident response plans when a traffic incident is detected and verified (Figure 1). It has been assumed that the input traffic incident can be identified through automatic (e.g., via a dedicated incident detection system) or manual means (e.g., the network operators insert a traffic incident in the corresponding traffic management system). Figure 1 illustrates that the Network Monitoring System—NMS—(for example) is responsible for detecting critical network anomalies that require specific remedial actions and response plans. In addition, NMS is responsible for making the detected incidents (i.e., timestamp, duration, location, type, and severity) available to the RPG (e.g., via a message or through a dedicated dashboard). Therefore, the RPG will be triggered by traffic incidents detected and verified by the NMS. Figure 2 shows an example for the main characteristics of a verified traffic incident. For each detected and verified traffic incident, the RPG will generate a collection of response plans that will assist in the mitigation of the incident’s impact on the network capacity or demand conditions. It has also been considered in the proposed approach that the types of input traffic incidents can be categorised into five key categories (

Table 2. Types of input traffic incidents.

ID	Description	Examples
U1	Unplanned: road-based incident	Overturning of a truck, road accident, accident, traffic congestion, broken down vehicle, closed road, obstacle on the roadway, impassable water, pedestrians crossing the road, live animal on the roadway.
U21	Unplanned: public transport-based incident—road	Disrupted bus service, diverted bus service.
U22	Unplanned: public transport-based incident—rail	Metro station closure, broken down train, voltage drop in railway network, obstacle on the railway.
U3	Unplanned: other incidents	severe weather conditions, flood, fire, strong wind, tornado.
P	Planned incident	Sport event, recurring congestion, concert, exhibition, demonstrations, protests, road work, forecasted extreme weather.

), and the severities of the input traffic incidents can be categorised into three key categories (

Table 3. Severities of input traffic incidents.

ID	Description	Examples
M	Minor incident	Minor, low impact, slight, small, insignificant, trivial, negligible.
J	Major incident	Major, medium, substantial, great, considerable, significant.
C	Critical incident	Critical, high, severe, extreme, acute, crucial, serious, strong.

).

Figure 3 shows the main subcomponents of Response Plans Generation Module (RPG), including the Response Plans Template Manager (RPTM) and the Response Plans Building Module (RPBM). Effectively, the library of response action templates (RPTM) must be constructed in advance and before it can be utilised by the RPBM. Therefore, the RPBM will use this built library of response action templates every time an input traffic incident triggers the RPG.

In the proposed approach, a library of pre-defined templates of response actions is required to facilitate the operation of the RPG and the real-time generation of appropriate response plans. Additionally, these pre-defined templates need to be categorised according to the characteristics of potential input traffic incidents to support the process of selecting the suitable response actions. Each template will specify what required or optional actions are applicable for each incident and some default values for the initialisation of the response plan. For example, a template that can be used as a response plan for a bomb threat at a metro station will have a required action to ‘suspend a specific metro service (or all services)’. The default initialisation value would be to suspend all services that pass through the station for which the thread has been made.

3.1.1. Response Plans Template Manager—RPTM

This subcomponent is responsible for creating a library of categorised templates of response actions that mainly construct the templates of response plans as a basis for generating traffic incident response plans. In the proposed approach, constructing this library considered the literature review of the related studies and the response logic (i.e., traffic management systems) of network operators in the study area, which is the Athens Airport—Metamorfosis corridor. The response logic algorithms and heuristics express the qualitative knowledge for the handling of traffic incidents by each actor. Therefore, the traffic management procedures of network operators (Attiki Odos, Attiko Metro, and OASA) of the Athens corridor have been considered and utilised for developing and constructing the mentioned library of categorised response action templates. As a result of extensive consideration of the related literature and the concept of operation for the different network operators, twenty-nine abstract response action templates have been identified. These templates include informative, executable, and simulatable response actions. Despite the templates having a unified format, the values of their variables may differ from one response action template to another.

Each response action template is labelled by both of the related incident types (i.e., U1, U21, U22, U3, and/or P in Table 2) and the related incident severities (i.e., M, J, and/or C in Table 3). These categorised templates of response actions are stored in a dedicated data storage (or a file system) to be accessed and used by the Response Plans Building Module—RPBM.

Table 4. Examples of identified response action templates.

ID	Response Action Name	Type					Severity
		U1	U21	U22	U3	P	M	J	C
2	Inform and advise the road users via a specific VMS (i.e., to redirect or change mode).	✓	✓	✓	✓	✓	✓	✓	✓
8	Close an upstream corridor/motorway entrance.	✓							✓
10	Close some or all lanes of a section/road.	✓			✓	✓	✓	✓	✓
15	Send more staff to a metro station for assistance.			✓				✓	✓
23	Temporary alteration and redirection of a bus service route.	✓			✓	✓			✓

represents some examples of these identified templates of response actions. As mentioned above, constructing the library of response action templates needs to be accomplished just once for a given study area before the approach can deal with any input traffic incident and generate the appropriate response plans (RPBM in Figure 3).

3.1.2. Response Plans Building Module—RPBM

This subcomponent is responsible for generating a set of response plans for each detected and verified traffic incident. According to the type and severity of the input incident, this subcomponent picks up the relevant templates of response actions (that were constructed earlier and stored in the data storage) to build a response plan template. Therefore, the generated response plan template represents a combination of all relevant response action templates, and each response plan represents a configuration of this created response plan template. Response Plans Template Manager—RPTM—identified all possible configurations for each template of response actions and possible values of its variables according to the incident severity. Therefore, the number of possible configurations for a response plan template determines the number of response plans that can be generated for a given traffic incident. Having the input traffic incident shown in Figure 2, the RPBM generates the response plan template demonstrated in

Table 5. The generated response plan template for the traffic incident in Figure 2.

ID	Response Action	Values	Simulation
1	Providing information to the road users via media and call centre.
2	Inform and advise the road users via a specific VMS (i.e., to redirect or change mode).
3	Inform and advise metro/train passengers via a specific VMS at metro stations.
4	Inform and advise passengers via app & DMS at bus stops and in-vehicle screens.
5	Contact the traffic police and exchange information.
6	Activate a VSLS in a specific road/location.
7	Divert/redirect traffic from a specific corridor/road to other major arterials.	75, 90	✓
8	Close an upstream corridor/motorway entrance.		✓
9	Temporary application of variable speed limiting at specific roads/sections.	75, 90	✓
10	Close some or all lanes of a section/road.		✓
11	Open the toll in a specific interchange.
12	Apply dynamic toll pricing.	60, 80
13	Divert/redirect some road users to a P&R station/facility.	5	✓
14	Send patrols, ambulance, and traffic police for assistance.
17	Increase the frequency of a metro service.	50, 100
18	Increase the frequency of a bus service.	50, 100
19	Deployment of an on-demand bus service.	5
21	Divert/redirect m% of traffic/users to bus services.	3, 4	✓
22	Divert/redirect n% of traffic/users to metro/train services.	3, 4	✓
23	Temporary alternation and redirection of a bus service route.
29	Control of a specific signalised intersection.

. This template includes 21 templates of response actions that can provide 128 response plans (combinations of all possible values of variables).

3.2. Response Plans Scoring Module—RPS

This component is responsible for assessing and evaluating the impact of the response plans generated by the RPG component. It uses the simulation framework (i.e., Aimsun Next) to calculate Key Performance Indicators (KPIs) for each response plan. For a given response plan, the RPS calculates and compares two scenarios: the baseline scenario, where only the actions representing the traffic incident (e.g., closing two lanes) are considered and simulated, and the response scenario, where all actions representing both the traffic incident and response plan are considered and simulated. Therefore, Aimsun Next framework simulates these scenarios for each response plan and produces relevant KPIs. The latter are used to assess the traffic conditions both at baseline conditions, as well as assess generated response plans. A list with all possible KPIs is specified within the online Aimsun Next manual [16]. Therefore, amongst the types of output that the Aimsun Next can provide, statistical data is of special relevance and, more specifically, a selection of relevant KPIs will be consumed by the RPS. Such KPIs may, but are not limited to, include delay time, density, flow, speed, mean queue, and travel time.

It has been assumed that some of the response actions that construct the generated response plan can be simulated (tic sign in Table 5) while other actions are either non-simulatable (e.g., contact the traffic police and exchange information) or have a trivial effect on the simulation outcomes (e.g., deployment of an on-demand bus service). Considering the response plan template in Table 5, sixteen response plans can be simulated and evaluated (a combination of actions 7, 9, 21, and 22). Here, the baseline scenario represents the simulation of action 10 while the response scenario represents the simulation of actions 7, 8, 9, 10, 13, 21, and 22.

As a result, these calculated KPIs may be used to rank the response plans generated for a given traffic incident. This ranking of response plans can support the stakeholders or network operators to select and follow the optimal response plan. Alternatively, these KPIs can be used by another component or service (recommendation system in Figure 1 and Figure 3) that can further analyse and process these KPIs along with other aspects of the response plans (e.g., safety, environmental impact, and passengers’ satisfaction) to more precisely suggest and recommend the optimal response plan.

4. Results and Discussion

The proposed approach is being implemented using a micro-services architecture in order to ensure that it can be integrated with other potential components and secure the interoperability of the suite of integrated services. Various traffic conditions, strategies, and mechanisms have been used with Aimsun Next software to simulate different traffic response actions (defined as simulatable actions) of response plans. At this stage, this mainly includes lane closure, speed reduction, forced turn, and demand reduction. Therefore, the simulatable response actions of a given response plan have been represented within the simulation network and model using the python scripting approach that is offered and supported by Aimsun Next software.

We have tested the proposed approach through a number of experiments in order to investigate its efficiency and performance. Various input traffic incidents (with different types and severities) have been applied in these experiments to demonstrate the details of the generated response plans. Furthermore, the impact of the generated response plans on the network performance has been assessed by using Aimsun Next software and a network simulation model for the Athens Attiki Odos corridor, which we have developed and calibrated.

After constructing the library of response action templates, the response plan template (e.g., Table 5) and all generated response plans represent the main outcome of the proposed approach. However, the results of simulating these generated response plans represent their evaluation (or rank), which needs to be considered in the process of selecting the optimal response plan. Figure 4 shows the results of simulating the generated response plans from Table 5. Each variable value (e.g., the most top left circle on the blue polyline—speed) for each response plan (e.g., speed for response plan 1) represents the percentage by which this variable value has been changed from the baseline scenario (do-nothing) to the response scenario (response plan application). For example, the most top left circle indicates that the application of the first response plan (RP1) will increase the traffic speed by 38.30% compared to the “do-nothing” or baseline scenario. Figure 4 shows that almost all of the variables seem to be rather invariant across the different response plans. This is because the differences among the generated response plans are trivial and each response plan generated is similar to another one after slightly tweaking the value of one variable related to one of this response plan’s actions. For example, the difference between RP1 and RP2 is that the variable value of response action 21 is 3 in RP1 while it is 4 in RP2. Therefore, these minor differences among response plans show just a slight change in the simulation results.

Table 6. The results of the proposed approach using five input traffic incidents.

Incident	Speed	Flow	Density	Delay Time	Travel Time	Mean Queue
1: U22-C	−5.67	5.45	−12.80	−39.04	−7.03	−42.69
2: P-C	−10.18	1.66	−20.64	−17.52	−10.58	−25.12
3: U1-C	38.82	−13.27	−58.90	−71.44	−40.20	−88.75
4: U3-C	11.19	3.47	−29.02	−27.90	−11.80	−57.73
5: P-J	−4.00	4.33	−16.34	−18.16	−10.00	−24.75

represents the aggregated results for all response plans generated and simulated when five different traffic incidents are used as input to the proposed approach. For instance, the incident 3: U1-C in this table represents the aggregated results shown in Figure 4, as the “Speed” value represents the average value of the 16 values depicted on the top blue polyline in Figure 4.

To find the optimal response plans out of the different response plans generated for a particular traffic incident (e.g., 16 response plans in Figure 4), a particular ranking approach can be used. In addition, such ranking methods may consider various characteristics or attributes of the generated response plans (e.g., network performance, environmental aspects, easiness to apply, and user satisfaction). For instance, if only the simulation results and network statistics (i.e., Speed, Flow, Density, Delay Time, Travel Time, and Mean Queue) have been considered and have the same weight, the response plans in Figure 4 can be ranked from the optimal one as follows: 12, 16, 4, 8, 10, 11, 2, 3, 14, 15, 6, 7, 9, 13, 1, 5. However, alterative ranking methods can be investigated and implemented by selecting and considering some of these network variables along with other characteristics of response plans.

The proposed approach generated and evaluated different response plans for each input traffic incident. Moreover, the assessment process of the generated response plans revealed that application of these generated response plans improves the network performance and conditions. Table 6 shows that the delay time and travel time have decreased significantly for all tested incidents as a result of using the proposed approach for generating the related response plans.

5. Conclusions

In this paper, we presented an automated approach for generating and evaluating traffic incident response plans. Firstly, a library of response action templates had been constructed, taking into account the characteristics of the road network of study area that was the Athens Attiki Odos corridor. For a given traffic incident, the approach used the constructed library of response actions to build a response plan template and, therefore, generate a set of response plans according to the incident characteristics. Aimsun Next software and a developed simulation model for the Athens corridor had been used to evaluate the generated response plans. Effectively, the outcomes of simulating and evaluating response plans reflected the different characteristics of the input traffic incident. Thus, the implementation of the generated response plans demonstrated how the network performance and conditions had been generally improved when compared to the baseline (do-nothing) scenario. In a later stage, the evaluated response plans had been ranked to define the optimal response plans to be considered and propagated by the network traffic management operators. However, future research directions can involve:

• The integration of the proposed solution as a part of traffic management system, acquiring some feedback, and improving the performance of the approach.
• The development of a general approach for generating and evaluating traffic incident response plans that considers all types of road networks through extending the library of response actions and utilising additional traffic incident characteristics to define the response plan template.
• The improvements of modelling and the representation of different response actions in the simulation framework to correctly measure the impact of real response plans on the network performance.
• The investigation of ranking methods for the generated response plans by considering the outcomes of implementing different response plans and their potential impact on users’ satisfaction, network performance, and environment.