Real-time road safety optimization through network-level data management

With the increasing connectedness of vehicles, real-time spatio-temporal data can be collected from citywide road networks. Innovative data management solutions can process the collected data for the purpose of reducing travel time. However, a majority of the existing solutions have missed the opportunity to better manage the collected data for improving road safety at the network level. We propose an efficient data management framework that uses network-level data to improve road safety for citywide applications. Our framework uses a graph-based data structure to maintain real-time network-level traffic data. Based on the graph, the framework uses a novel technique to generate driving instructions for individual vehicles. By following the instructions, inter-vehicular spacing can be increased, leading to an improvement of road safety. Experimental results show that our framework improves road safety, measured based on the time to collision between vehicles, from the state-of-the-art traffic data management solutions by a large margin while achieving lower travel times compared with the solutions. The framework is also readily deployable for large-scale real-time applications due to its low computation costs.


Introduction
With the increasing connectedness of vehicles, a vast amount of spatio-temporal data can be collected from large road networks at real time. An example of the data is the routes that vehicles will follow to reach their destinations. Using the collected data, it is possible to enhance traditional traffic engineering systems through integrating them with information systems [1]. A majority of the existing data-driven solutions are focused on reducing travel time [1][2][3][4][5] and have missed the opportunity to better manage the spatio-temporal data for improving road safety at the network level. To maximize road safety at the network level, there needs a global coordination of safety arrangements for all the individual vehicles. Although the current development of connected autonomous vehicle (CAV) technology can help improve road safety, the safety improvement is generally achieved within a limited scope such as a vehicle platoon [6] or an intersection [7], which is different to the coordinated safety arrangements at the network level. Our work is focused on network-level data management for improving road safety.
We aim to develop a data management solution that will give drivers detailed instructions for improving road safety based on the drivers' routes for the future. An ideal solution needs to address two major challenges. The first challenge is to strike a balance between road safety and travel time. Without a proper management scheme, an improved traffic efficiency can lead to a lower safety level [8]. On the other hand, it would be unwise to implement a naive data management solution that leads to the slowdown of all the vehicles. Such a naive solution would make road safer, but it would lead to long travel times for individuals. Therefore, the ideal solution needs to consider road safety improvement and its impact on travel time at the same time. The second challenge is to maintain a high level of computation efficiency for real-time applications. Due to the complexity and the amount of spatio-temporal data, the computation time spent on processing the data can be prohibitive for real-time applications. A number of emerging solutions use sophisticated techniques that are only computationally feasible for optimization in limited scopes such as a single road segment or a single intersection [9,10]. There is a lack of computationally efficient solutions for improving network-level road safety.
We formalize our research problem based on the balance between road safety and travel time. Our research problem is named Network-Level Safety Optimization (NSO). To achieve the balance between the two factors, our preliminary work develops Safest Platooning Graph (SPG), which is a prototype solution to give driving directions for safety improvements [11]. To build SPG, we model traffic conflicts in a graph and then resolve those conflicts on First-Come-First-Serve (FCFS) basis to decide the vehicle passing order at the conflicting locations, including lanes and intersections inside the road network. Then we space out vehicles iteratively while obeying the vehicle passing order and build the SPG. Though SPG helps space out vehicles while limiting the travel time increase, it has some drawbacks and limitations. First, it does not maintain comprehensive information about traffic conflicts in the graph structure. Second, it does not consider a non-FCFS passing order that can help achieve a better balance between travel time and safety. Third, it uses a computationally expensive algorithm for spacing out vehicles, which makes it less suitable for citywide real-time traffic optimization.
In this paper, we present a data management framework that is comprehensively improved from SPG by addressing its limitations. Our framework is named Conflict Zone Graph based Motion Planning (CZMP). The proposed framework has three major contributions over SPG. First, it uses an enhanced data structure to better represent network-level traffic information. Compared to the original data structure, the enhanced version contains more types of information related to traffic conflicts, enabling a more comprehensive view of the road network. Second, CZMP uses a delay planning algorithm to plan delays for vehicles based on a safety-oriented but efficient non-FCFS passing order at conflicting locations. The delay planning algorithm helps distribute the available spaces in the road network and the waiting times at vehicle queues for spacing out vehicles more effectively. Third, CZMP uses a significantly faster motion planning algorithm to generate vehicle trajectories based on the planned delays of vehicles. Different to SPG's motion planning algorithm, CZMP's motion planning algorithm decides the motion in a direct manner without incremental adjustments to the trajectories, achieving significant improvements in computation time, as we show in the results. In contrast, SPG iteratively plans the motions of vehicles and checks the amount of delay achieved by each vehicle. SPG needs to adjust the plan in more iterations if there exist vehicles that can get a further delay. By separating delay planning from trajectory computation, CZMP avoids the iterative process, thus CZMP improves the quality of the results and reduces the computation complexity significantly.
Our framework has three components. The first component is a data structure called Conflict Zone Graph (CZG), which is a time-dependent graph that keeps comprehensive information about conflict zones where vehicles would come close to each other for a particular time horizon under consideration. As CZG is time-dependent, it is constructed using real-time network-level spatio-temporal information. The second component is a heuristic algorithm called Incremental Delay Planning Algorithm. Using the information in CZG, the algorithm plans delays to modify the time that individual vehicles arrive at conflict zones, which helps space out vehicles. The third component is an algorithm called Safer Network Motion Plan Generation Algorithm. Based on the planned delays, the algorithm performs motion planning for the vehicles. The motion plans contain detailed instructions for vehicles to realize the planned delays. Our framework modularizes each important step in the workflow for better usability and extendability. Modularization increases the applicability of the framework for similar applications. The components shown in this paper can be replaced with other application-specific algorithm versions in the future.
We compare the CZMP framework against many existing spatio-temporal data management solutions for traffic optimization in a variety of experimental scenarios created with both synthetic and real data. Our experiments show that CZMP outperforms the existing solutions in achieving a good balance between road safety and travel time. For example, in synthetic data based experiments, CZMP improves the safety level, measured based on the time to collision between vehicles, by up to 68% from a state-of-the-art traffic-efficiency-oriented solution, Intersection Conflict Resolution (ICR) [12]. Interestingly, CZMP achieves a better traffic efficiency than ICR even though CZMP is safety-oriented and ICR is efficiencyoriented. CZMP reduces travel time by up to 60% from ICR. The comprehensive advantages of CZMP over ICR come from two key differences between the two solutions. First, ICR only imposes a minimal safety constraint based on fixed-size inter-vehicular spaces, whereas CZMP can improve safety by enlarging inter-vehicular spaces whenever possible. Second, ICR only considers traffic information at individual intersections when optimizing traffic. Differently, CZMP coordinates traffic at a larger scope as it considers network-level traffic information. This makes CZMP more effective in managing safety while having a positive side effect on traffic efficiency. Our experiments show that CZMP not only outperforms ICR, but also outperforms the prototype safety optimization solution SPG which is developed in our previous work. The advantage of CZMP over SPG is mostly noticeable in computation efficiency. CZMP consumes a significantly shorter computation time compared to SPG. For example, CZMP can generate travel plan for 1500 vehicles within 1 second while SPG spends 34 seconds to compute for the same number of vehicles. Even in real data based experiments, we achieve similar improvements in terms of traffic safety, traffic efficiency and computational efficiency. The main contributions of our work are summarized as follows.
• We formalize a research problem that is important to the management of traffic data.
The problem aims to improve road safety while minimizing the impact on travel time at the network level. The problem is named Network-Level Safety Optimization (NSO). • We develop a spatio-temporal data management framework, Conflict Zone Graph based Motion Planning (CZMP), which incorporates a novel time-dependent conflict graph and two algorithms to develop motion plans that are safety focused. • We compare road safety level, travel time and computation costs of CZMP against existing spatio-temporal data management solutions such as ICR and variants of the prototype solution developed in our previous work. Our results show that CZMP achieves a better balance between road safety and travel time compared to all other solutions, in both synthetic data and real data based experiment setups. With increasing levels of connectedness and autonomy in transport, our problem and solutions will be fundamental in optimizing traffic efficiency while considering road safety.

Related work
Information Systems for Traffic Management The rapid advancement of information systems has accelerated the development of various Intelligent Transportation Systems (ITSs) [1,[13][14][15], where information systems are integrated with traffic engineering. With the spatio-temporal data collected from vehicles and traffic infrastructures, ITSs can perform advanced real-time traffic optimization. There are different objectives of optimization such as minimizing the total travel delays of vehicles [5,16] or maximizing the throughput of the network [17,18]. The optimizations can be performed at a small scale, such as a particular highway segment [9], an intersection [19] or a traffic corridor [20]. The optimizations can also be performed at larger scales [4,14,21,22]. Large-scale traffic optimizations can give globally better results but they need to apply highly efficient spatio-temporal data management techniques for real-time applications.
In respect to road safety, most of the existing data management solutions for ITSs only impose minimum inter-vehicular spaces to prevent collisions in normal situations, which makes the solutions less robust for preventing accidents in many unpredictable events [23,24]. There exist solutions that improve mobility while having a positive side effect on road safety [5,25,26]. However, those solutions are not designed for optimizing inter-vehicular spacing. In contrast, our proposed framework is focused on improving road safety at the network level by optimizing inter-vehicular spacing. Our framework is also different to routingbased solutions that aim to provide personalized safer routes by navigating vehicles away from risky areas [27][28][29].
The connectivity and autonomy of CAVs have created more opportunities for ITSs to perform finer traffic optimization operations such as controlling vehicle trajectories and manipulating inter-vehicular spacing [30,31]. However, many of the existing solutions are not suitable for globally coordinated traffic optimizations due to their high computation complexity. Our proposed spatio-temporal data management framework uses efficient algorithms, which enables real-time network-level road safety optimization in an ITS.

Algorithms for Collective Trajectory Optimization
There exists a large body of work that uses well-known techniques such as linear programming, genetic algorithms, dynamic programming or gradient descent algorithms to optimize the trajectories of a group of vehicles collectively for improving mobility, safety, or fuel-efficiency [20,[30][31][32][33][34][35]. To the best of our knowledge, all the existing solutions in this area can only work well within limited scopes such as individual intersections [33], individual highway segments [31], or individual traffic corridors [20] using a limited set of spatio-temporal data. For example, Wei et al. [35] use a dynamic programming approach to adjust the trajectories of a group of vehicles between two intersections for improving safety and mobility performance. In addition to the algorithms that are dedicated to trajectory optimization, there exist other data management techniques that help improve the quality of trajectories indirectly. For example, Khondaker et al. [9] develop an algorithm to optimize variable speed limit signals for a freeway segment, which can result in better trajectories. Another recent study [36] develops a reinforcement learning-based approach to optimize traffic signals, which can result in safer trajectories. The approach performs optimization using a variety of spatio-temporal data such as traffic volume, queue length, shock wave area, and platoon ratio etc. Different to our proposed framework, none of the aforementioned solutions optimizes trajectories based on the globally optimized inter-vehicular spacing. Our approach produces trajectories that help improve road safety at the network level. In addition, our framework is more suitable for real-time applications compared with many existing solutions, which is due to the fact that our framework can use a novel graph-based data structure and heuristic algorithms to reduce computation costs.

Data Structures for Traffic Optimization
Due to the complexity of traffic optimization problems, innovative data structures are used for efficient spatio-temporal data management. For example, Giridhar et al. [2] develop an approach that uses a directed graph to represent spatio-temporal traffic data for scheduling automated traffic. The graph is based on a discrete-space model of a road network, where each lane is divided into one or more cells and each cell corresponds to a vertex in the graph. A similar cell-based representation of road network is used for deadlock prevention of self-driving vehicles [37].
Graph-based data structures have been used for modelling conflicts between vehicles, which is important to our work on road safety. Liu et al. [12] develop a method, which we call Intersection Conflict Resolution (ICR), to optimize the order that vehicles pass intersections. For a specific road intersection, the method models the sequence that vehicles arrive at the intersection using a type of conflict graph. Each vertex in the graph represents a vehicle and each edge connects to a pair of vehicles that will enter the intersection from conflicting approaches. Based on the graph, the method determines the order that conflicting vehicles arrive at the intersection. Lin et al. [38] develop a different conflict graph that uses three types of edges to represent different ways that traffic conflicts can be formed. The graph is used by a scheduling algorithm that resolves the conflicts while preventing deadlocks on the road. The aforementioned graphs only model traffic conflicts at individual road segments or individual intersections. Different to these conflict graphs, our previous work [11] develops a data structure called platooning graph, which is based on a conflict graph that models traffic conflicts in a continuous space. The conflict graph can model conflict zones that span multiple road segments and multiple intersections, which enables a significantly more effective representation of spatio-temporal data that suits network-level traffic management. In this work, we develop an enhanced version of the data structure for more efficient and more effective traffic safety management.

Problem definition
In this section, we present the formal problem formulation considering a set of vehicles moving in a road network. We assume that the traffic progresses in discrete time steps with a time step size Δt . In the rest of the section, we introduce the key concepts then define our research problem.

Road Graph
The road graph is a directed graph RG=(VR, ER), where VR is a set of vertices and ER is a set of edges. An edge is connected to a pair of vertices. Each vertex vr ∈ VR represents the end of a traffic lane or a point where two or more traffic lanes connect. Each edge er ∈ ER represents a traffic lane.
Vehicles Given a set of vehicles that are present at a specific time t, A(t), the state of a vehicle a i ⊆ A(t) has three elements, e i (t) , x i (t) , and vl i (t) . The element e i (t) is the edge where a i is located at the time, x i (t) is the distance between the start of edge e i (t) and the position of a i , and vl i (t) is the velocity of the vehicle at the time. Between two successive time steps t and t + Δt , a vehicle a i can make an acceleration action denoted by ac i (t) . The state of a i at time t + Δt depends on its state at time t and the acceleration ac i (t).

Time To Collision
Assuming two vehicles a i and a j keep moving without changing their speed, the period between a given time t and the future time that the two vehicles would collide is the Time To Collision (TTC) between the two vehicles at time t, denoted as ttc i,j (t).
TTC has been used as a surrogate safety measure for studying the safety impact of autonomous vehicles [39]. We assume that the TTC between any pair of vehicles must be equal to or larger than a minimum allowed TTC ( TTC mn ) to guarantee a minimum safety level. There is also an upper limit of TTC called TTC threshold ( TTC thr ), which is a constant where TTC thr > TTC mn . If the TTC between two vehicles is higher than TTC thr , we assume that the risk of a collision would be negligible, hence not a safety concern. The TTC of a specific vehicle a i at a specific time t is denoted as ttc i (t) . As shown in Eq. (1), ttc i (t) is either the lowest TTC between vehicle a i and any other vehicle at that time or the TTC threshold, whichever is lower. Distance to TTC Threshold Given a network motion plan and a TTC threshold TTC thr , we define a road safety metric, Distance to TTC Threshold (DTTC ), using Eq. (2) 1 , where A(t)

Network Motion Plan
(1) ttc i (t) = min min a j ∈A(t),∀i≠j (ttc i,j (t)), TTC thr 1 We chose to use a standard L2 loss function-based formulation rather than a simple sum for the equation. As shown later, our solution optimizes traffic based on the minimization of DTTC. During the optimization process, the sum of squares can help even out inter-vehicular spaces, which is useful for achieving universal safety improvements across the whole network. The relationship between the sum of squares and the TTCs of individual vehicles can be shown with the following example. Let a i and a j be two vehicles and the TTC threshold be 10s. In the first case, ttc i (t) = 2s and ttc j (t) = 8s , which results in DTTC( ) = 68s 2 . In the second case, ttc i (t) = 5s and ttc j (t) = 5s , which results in DTTC( ) = 50s 2 . As the example shows, a lower DTTC indicates that the TTCs are more uniform, which implies that the road safety is optimized more universally.
is the set of vehicles at a particular time t and ttc i (t) is the TTC of vehicle a i defined with Eq.
(1). Our previous study also measures road safety based on DTTC [11]. DTTC is derived from Time Integrated TTC [40] that has been widely adopted by the research community. Based on our definition of TTC Eq. (1), if the minimal TTC between vehicle a i and any other vehicle is equal to or higher than the TTC threshold, the value of (TTC thr − ttc i (t)) is 0 and does not contribute to DTTC. In other words, DTTC is aggregated based on the TTC values that are below the TTC threshold. When these TTC values are higher, the gap between the values and the TTC threshold is lower. Therefore, a lower DTTC corresponds to a better road safety level. where Π is the set of all the possible NMPs.

Fastest Travel Time
Due to the complexity of traffic systems, there is no efficient way to compute the theoretical optimum of DTTC. For this reason, we do not aim to find the exact NMP that achieves the theoretical optimum. Instead, we aim to find a NMP that approximates the hypothetical best case of DTTC, which is 0.

Conflict zone graph based motion planning framework
In this section, we detail the Conflict Zone Graph based Motion Planning (CZMP) framework, which we use to compute approximate solutions of the NSO problem defined in Section 3. CZMP can be applied to a transportation system where vehicles are connected to a traffic management system. Our strategy for improving road safety includes two steps. First, we find the common lane segments and intersections shared by the vehicles. These lane segments and intersections are the areas with a risk of vehicle collision. Second, we delay the time that certain vehicles arrive at these areas.
The framework consists of three main components ( Fig. 1), which includes a Conflict Zone Graph (CZG), an Incremental Delay Planning Algorithm, and a Safer Network Motion Plan Generation Algorithm. Due to the dynamic nature of traffic, CZMP re-optimizes traffic at a certain update interval because the effectiveness of an optimized motion plan may deteriorate when traffic condition changes in time. An update interval may last one or more time steps. During each update interval, CZMP performs optimization by constructing a new CZG and running the two algorithms.
When constructing a CZG, CZMP finds all the safety-critical areas based on the routes of vehicles moving in the road network. The safety-critical areas are called conflict zones in our work. A conflict zone is a part of the road network where collisions may happen in the future [12,38]. The information of conflict zones is maintained in the CZG. Based on this data structure, the framework uses the Incremental Delay Planning Algorithm to compute the delayed times that some of the vehicles should arrive at the conflict zones. The delays are planned for reducing the risk of collisions while considering various constraints such as the desired maximum travel time of vehicles. The delays change the order that vehicles arrive at conflict zones and enable a better distribution of available spaces and queue waiting times among all the vehicles. As shown in Fig. 1, the CZG is then updated with the delay information. In order to arrive at the conflict zones with the planned delays, vehicles may need to adjust their motion plan, which includes the acceleration of individual vehicles at future time steps. The framework runs the Safer Network Motion Plan (NMP) Generation Algorithm to compute the desired motion that is needed to achieve the delays. The algorithm uses a well-known car-following model, Intelligent Driver Model (IDM) [42], to generate a safe motion plan for each vehicle based on the information from the CZG. The output motion plan is an approximate solution to the optimization problem defined in Section 3.
As the distance that vehicles can travel within an update interval is limited by the speed limit of roads, CZMP only considers the conflict zones within a look ahead distance (LA) for each vehicle. We conducted an experiment to evaluate the impact of LA on safety, travel time and computation cost (Section 5.3.3). Our result shows that considering conflict zones beyond certain distance would not improve safety and travel time significantly but would increase computation cost.
The framework modularizes each important step of the workflow to improve usability in future applications. For example, it is possible to replace the incremental delay planning algorithm easily with a different algorithm version without changing other components. Similarly, we could use a different NMP generation algorithm based on other car-following or platooning strategies without changing other components.
In the rest of the section, we describe the three main components of the CZMP framework and how they work together to optimize traffic during an update interval. Table 1 highlights the key notations which are frequently used throughout the paper.
The set of vehicles on the road graph at time t e i (t) The edge where a i is located at time t The velocity of vehicle a i at time t The acceleration of vehicle a i between time t and t + Δt The TTC between vehicles a i and a j at time t

TTC mn
The minimum allowed TTC (the lower limit of TTC values) TTC thr The TTC threshold (the upper limit of TTC values) ttc i (t) The TTC of vehicle a i at time t (Eq.
The set of vehicle on the road graph at the update time t u C The set of conflicts between the vehicles in the set The planned delay of vehicle a i c i,j A conflict zone between the two vehicles a i and a j pat i The projected arrival time of vehicle a i to the conflict zone c i,j D A set of delay increments Δd k A delay increment in the set D Δs The time headway increment IDM Model AC mn The desired deceleration of vehicle a i AC mx The maximum acceleration of vehicle a i vl 0 The desired velocity of vehicle a i V mx The maximum velocity allowed for vehicle a i The free acceleration exponent Δv(t) The relative velocity between a i and the front vehicle a j at time t s(t) The distance between a i and the front vehicle a j at time t

Conflict zone graph (CZG)
is a set of vertices and C is a set of edges. CZMP constructs a new CZG at the start of an update interval t u based on the traffic data available at the time. A vertex in CZG represents a vehicle a i ∈ A(t u ) that is present when the graph is constructed. A vertex has two attributes. The first attribute is the fastest travel time ( ftt i ), which is the shortest time that the vehicle a i can travel the look ahead distance or the remaining part of its route, whichever is shorter, assuming the vehicle can travel at the speed limit. The second attribute is the planned delay ( d i ), which is the delay that should be applied to the vehicle. The d i value is set to zero when constructing the CZG. An edge represents a conflict zone ( c i,j ), where i and j represent two vehicles, a i and a j , respectively (Fig. 2). A conflict zone is a common/shared part of the routes of the two vehicles. The size of conflict zones can vary in different scenarios. For example, a conflict zone maybe a single intersection where the routes intersect. It may also start at an intersection, where the routes of the vehicles overlap (meet, followed by a set of continuous traffic lanes shared by the vehicles thereafter). We identify conflict zones based on the following two rules, • Rule 1: If two vehicles a i , a j use the same edge er ∈ ER in their path then er is a part of a conflict zone. • Rule 2: If two vehicles a i , a j use two crossing edges er, er � ∈ ER at an intersection in their paths then er and er ′ are also a part of a conflict zone. Figure 3a shows a fourlegged intersection connecting four two-way single-lane road segments. It shows the edges and vertices of the road graph and three different paths that start from edge er 1 . We consider a virtual grid inside the intersecting region based on the number of lanes   . For simplicity, we only show the road edges used by those two paths. The conflict zone c i,j between the two vehicles a i , a j is shaded in red and it includes the edges {er 3 , er 4 , er 5 , er 6 , er 7 , er 8 , er 9 } . The er 5 , er 6 , er 7 are common to both vehicle paths (Rule 1) and edge pairs (er 3 , er 4 ), (er 8 , er 9 ) are crossing edges (Rule 2). Figure 3d shows how we extend the road graph and virtual grid for a double lane intersection scenario. Similarly, we could extend this formulation into other types of intersections appropriately. When constructing the CZG, we only consider the conflict zones within the look-ahead distance from the current position of vehicles. The direction of an edge in CZG shows the car-following order, i.e., the edge points to the predecessor vehicle that enters the conflict zone first. An edge also maintains the projected arrival time (pat) for each of the vehicles, pat i and pat j . Initially, the value of pat is the fastest travel time that a vehicle can arrive at the conflict zone, assuming the vehicle always travels at the speed limit. The value will be increased during optimization when a delay is added to the vehicle.
A simple example of CZG is shown in Fig. 4. This example shows a scenario where three vehicles a 1 , a 2 and a 3 have conflicts between their paths (Fig. 4a). For simplicity of the example, we assume that each road segment has one traffic lane in each direction. There are three conflict zones, c 1,2 , c 2,3 and c 1,3 (Fig. 4b). Figure 4c shows the CZG based on the three conflict zones. The graph contains three vertices (vehicles) and three edges (conflict zones). Each edge points to the vehicle that arrives at the zone first. For example, for conflict zone c 1,2 , pat 1 is 0 and pat 2 is 2, which means vehicle a 1 arrives the conflict zone first. Therefore, the corresponding edge points to a 1 .
Computing CZG Given a set of vehicles at a particular update time t u ( A(t u ) ), a look-ahead distance (LA) and a road network (RG), the CZMP framework uses Algorithm 1 to compute CZG.
For each vehicle in the input set of vehicles, the algorithm builds a corresponding vertex in the CZG (Line 1-2). For each road lane within the look ahead distance on the path of a vehicle a i , the algorithm finds all the conflicting road lanes and the vehicles that use those lanes. An edge is built between a i and each of the found vehicles (Line 13).

Time complexity The time complexity of Algorithm 1 is
is the number of available vehicles at update time t u , |p mx | is the maximum number of edges on a path, |c mx | is the maximum number of crossing edges for an edge in the road graph.

Incremental delay planning algorithm
After building the CZG data structure, our framework uses Algorithm 2 to plan the delays of the vehicles' arrival at conflict zones. Adding delay to the arrival time can change the order of vehicle arrivals and help enlarge the inter-vehicular space between two vehicles, resulting in an improvement of road safety with a reduced conflict between the vehicles. The algorithm runs in iterations, where each iteration increases the delay by a value from a predefined sequence of delay increments. There are certain constraints that need to be obeyed when delaying vehicles. For example, the increased travel time caused by the delay cannot exceed the desired maximum travel time. If any of the constraints could not be satisfied for a vehicle, the delay will not be applied to the vehicle. Otherwise, the algorithm updates the delay value at the vehicle's corresponding vertex in CZG. The delay information in the updated CZG will be used for motion planning as detailed in Section 4.3.
Algorithm 2 checks four constraints when planning delays and filters out unsuitable vehicles for adding delays (Line 5-10). This procedure is detailed as follows. is the safety risk for the conflict zone between vehicle a i and vehicle a j when the additional delay ( Δd k ) is added to a i , and h c i,j is the safety risk without considering the additional delay. If risk_change i is negative, the delay is deemed as beneficial as the safety risk is reduced. The safety risk h c i,j can be computed using (Eq. 5), where TTC thr is the TTC threshold, pat i is the projected time that a i arrives at the conflict zone, and pat j is the projected time that a j arrives at the conflict zone. We should note that pat i should be replaced with pat i + Δd k when computing the risk with the added delay ( h ′ that enters the conflict zone first must also be the vehicle that leaves the zone first. The constraint does not apply if the conflict zone starts with a road intersection because a vehicle may need to give way to another vehicle from a conflicting direction according to road rules, even when the former vehicle arrives at the intersection first. The FIFO constraint can be checked as follows. Given a conflict zone c i,j between vehicles a i and a j , assuming the conflict zone starts with a lane, if a j enters the zone first, the projected arrival time of a i ( pat i ) must be greater than the projected arrival time of a j ( pat j ). If a delay of Δd k is added to the predecessor a j and pat i ≤ pat j + Δd k , the FIFO constraint is violated. The algorithm checks the constraint in Line 8.
After checking the constraints, the vehicles that can get an additional delay of Δd k are included in a set A C . Then the algorithm updates CZG using the additional delay Δd k . For updating CZG, the algorithm starts from the vehicle that would get the most significant benefit by adding a delay (Line 14). Once the delay is added to the vehicle's corresponding vertex and edges, the dependencies of the vehicle are removed from the set A C (Line 18). This is because delaying a vehicle and its dependencies at the same time would result in no benefit for any of the vehicles.
After planning delays for all vehicles, the algorithm updates the direction of certain edges in CZG (Line 19-21). The direction of an edge shows the order that a pair of vehicles arrive at the corresponding conflict zone. The order of arrival is important for making motion plans of vehicles, which will be detailed in Section 4.3. When delays are applied to vehicles, the order of arrival can change if the conflict zone starts at a road intersection because the vehicles have the opportunity to slow down and give way to other vehicles at intersections. Therefore, the algorithm updates the order of arrival for the conflict zones that start at road intersections. For such a conflict zone, the vehicle with the lower projected arrival time will be set as the first vehicle to reach the intersection. In the rare case that two vehicles have the same arrival time, the vehicle with the lower index in the database will be set as the first vehicle to reach the zone. Figs. 4 and 5a shows the initial status of a CZG when the algorithm starts. In this example, we assume that the desired maximum travel times of vehicle a 1 , a 2 and a 3 are 24s, 30s and 36s, respectively. The TTC threshold TTC thr is 10s and the set of candidate delay increments is D = [4s, 2s] . The edge direction for conflict zone c 1,2 is fixed from the beginning because the zone starts on a road segment, which means the order that the two vehicles arrive at the zone is deterministic. Differently, the direction of the other two conflict zones will be decided as the algorithm runs. We show the direction of the remaining conflict zones in Fig. 5d. Figure 5b and c show the state at each iteration of the algorithm. The algorithm may need to run multiple rounds for a particular delay increment. We start by taking the first delay increment, 4s, from D (line 1) and look for vehicles that are benefited from a 4s delay.

Algorithm 2 Example Based on the scenario in
1. Δd k = 4s Round 1: We check the potential impact of a 4s delay on each of the three vehicles. When adding the delay to a 1 , we see that the delay increment violates the  (line 8). Therefore, a 1 should not get the delay in this round. We find that both a 2 and a 3 would be benefited from the delay as they would get negative risk change values (line 6). As adding the delay to a 2 and a 3 would not violate other constraints, we consider them as the candidate vehicles that may actually get the delay (line 9, 10). Then, we apply the delay to a 2 and update the CZG because adding the delay to a 2 would result in a larger reduction of safety risk compared to adding a delay to a 3 (line [14][15][16][17]. We update the relevant numbers for a 2 in the CZG. The updated numbers are coloured in blue in Fig. 5b-Round 1. We then skip applying the delay to a 3 because a 3 is a dependent of a 2 , which means we should not apply the delay to both vehicles at the same time (line 18). Since there are vehicles that are benefited from a delay in this round, we start a second round to see whether a further 4s delay would help. 2. Δd k = 4s Round 2: In the second round, adding a further delay to vehicle a 2 violates the desired maximum travel time constraint (line 5). Adding the further delay to both a 1 and a 3 cannot lower their safety risk as their risk changes would be non-negative with the delay. Therefore, we cannot find any candidate vehicle that would be benefited from the further 4s delay. At this point, we are done with the 4s delay increment (line 11,12). There is no change to the CZG in this round. After that, we start to try a new delay increment, which is 2s in D (line 1). 3. Δd k = 2s Round 1: In this round, adding a 2s delay to a 2 violates the desired maximum travel time constraint. Adding the delay to a 1 gives a non-negative risk change value, which means the vehicle cannot be benefited from the delay. We find that vehicle a 3 's risk change value would be negative with the delay. We then apply the 2s delay to a 3 and update relevant numbers in the CZG (Fig. 5c-Round 1). Since there is a vehicle that is benefited from the 2s delay in this round, we start a new round to see whether adding a further 2s delay would help. 4. Δd k = 2s Round 2: In this round, adding a 2s delay to vehicle a 2 violates the desired maximum travel time constraint. Vehicle a 1 and a 3 are not benefited from the further delay as they would give non-negative risk change values. Therefore, there is no candidate vehicle for applying the delay (line 11, 12). The CZG is not changed in this round. The algorithm terminates as we have finished all the delay increments in D.
Finally, we decide the direction of each edge based on the final projected arrival times. Figure 5d shows the final direction of each edge.

Time complexity
The time complexity of Algorithm 2 is O(q|D|(|A(t u )| + |C|)) , where q is the maximum number of delay increments for a vehicle with a particular delay increment Δd k , |D| is the size of increment sequence D, |A(t u )| is the number of available vehicles at current update time t u and |C| is the number of conflict zones between the vehicles.

Safer network motion plan generation algorithm
To achieve the planned delays, vehicles need to adjust their motion in real time so that they can arrive at conflict zones with the planned delays. Our CZMP framework generates a network motion plan that includes the acceleration of all individual vehicles for each time step during an update interval. The motion plans can be distributed to connected vehicles, which can adjust their motion according to the plan. The network motion plan is generated with Algorithm 3.
The algorithm is based on a car-following model, Intelligent Driver Model (IDM) [42]. Given the state of a front vehicle a j and a back vehicle a i , the IDM model computes the desired acceleration of the back vehicle ac i (t) at a particular time t using Eqs. (6) and (7).
In Eqs. (6) and (7), AC mx is the maximum acceleration of vehicle a i , vl i (t) is the velocity of vehicle a i at time t, vl 0 is the desired speed (e.g. the maximum velocity allowed V mx ), is the free acceleration exponent, Δv(t) is the relative velocity between a i and a j at time t, s(t) is the bumper to bumper distance between a i and a j at time t, s * is the effective minimum gap, s 0 is the minimum bumper to bumper distance between vehicles, TH is the desired time headway for safety, and AC mn is the desired deceleration (i.e. the desired minimum acceleration). A key parameter of the model is time headway (TH), which is the time that the back vehicle takes to reach the current position of the front vehicle. When TH is increased, the space between the two vehicles increases, leading to a delay of the back vehicle and a reduction of traffic conflicts.
Algorithm 3 runs in two parts for each time step. In the first part, it finds the closest front vehicle (predecessor) of a i using CZG (Line 3-6). As mentioned earlier, a CZG edge represents a conflict zone that involves two vehicles. The direction of the edge points to the vehicle that arrives the conflict zone first. Therefore, an outward edge that starts from a i points to a vehicle in front of a i . While iterating over all the outward edges of a i , the algorithm finds the front vehicle that causes the lowest acceleration of a i based on the IDM model. This front vehicle has the most significant impact on a i 's safety among all the front vehicles. For example, in the CZG in Fig. 5d, vehicle a 1 does not have any vehicle in front and it could take the maximum acceleration AC mx . However, a 2 has vehicles a 1 and a 3 in front as shown in the CZG. As the CZG in Fig. 5 is based on the traffic scenario shown in Fig. 4, we consider the following two cases when determining the predecessor of a 2 .
• Regarding front vehicle a 1 : Vehicle a 2 should follow vehicle a 1 , and let a 1 cross the intersection before start turning at the intersection. • Regarding front vehicle a 3 : Vehicle a 2 should stop before the intersection and let a 3 cross the intersection before start turning at the intersection.
We compute a 2 's ideal acceleration in each case using the IDM model. Based on the two acceleration values, we select the front vehicle which leads to the lowest acceleration as the predecessor of a 2 . The predecessor has the most significant impact on a 2 's safety. Similarly, we can find predecessors in other cases as well.
In the second part, the algorithm computes the best acceleration value for a i , based on the state of a i and the front vehicle found in the first part, using the IDM model (Line 7-9). To do this, the algorithm computes a set of candidate acceleration values while increasing the TH value in the IDM model. Increasing TH leads to an increase of inter-vehicular space, thus an increase of the delay for vehicle a i . The TH values are varied between TTC mn and TTC thr with an increment of Δs between adjacent values. With each of candidate acceleration values, the algorithm predicts the next state of a i , i.e., the position and velocity of a i at the next time step. Different acceleration values would lead to different delays, which may or may not be close to the planned delay for a i , i.e., the value d i stored in the CZG. Among all the candidate acceleration values, the value that will be assigned to vehicle a i is the one that would result in a delay closest to d i .

Experimental methodology
To evaluate the performance of the proposed CZMP framework, we consider two experiment setups, Synthetic Data based Experiment Setup (SDE-Setup) and Real-world Data based Experiment Setup (RDE-Setup). First we perform comparative tests using both setups to evaluate the impact of several traffic parameters on CZMP and a set of baselines. Then, we perform parameter sensitivity tests using SDE-Setup to evaluate the impact of two parameters that are used by CZMP and a variant of CZMP. Our experiments are conducted with SMARTS 3 [43], a microscopic traffic simulator. We implement the CZMP framework and all the baseline approaches in Java 8. All the experiments are conducted on a computer equipped with an Intel(R) Core(TM) i7-8550U 1.80 GHz processor, 16 GB RAM and 64 bit Windows 10 Education operating system.

Baselines
ICR Intersection Conflict Resolution (ICR) is a state-of-the-art traffic-efficiency-oriented intersection scheduling method [12]. ICR uses an intersection-level conflict graph to model traffic condition around intersections such as the waiting time of vehicles. Based on the graph, ICR determines the order that vehicles pass through the intersections for improving traffic efficiency. In addition, ICR performs motion planning but it uses a vastly different approach compared to CZMP. To make a fair comparison between ICR and our framework, we replace the motion planning component of ICR with the motion planning model of CZMP.

ATSC Actuated Traffic Signal Control (ATSC) is a classical traffic management solution
that extends the active color phase if more traffic is observed in that phase [44].
FPG The Fastest Platooning Graph (FPG) algorithm is proposed in our previous work [11].
FPG is more focused on improving travel time rather than achieving a balance between travel time and road safety. FPG and CZMP use the same parameter settings where possible. We derive the following three baselines from FPG. SPG The Safest Platooning Graph (SPG) is also proposed in our previous work [11]. SPG is similar to CZMP as it aims to achieve a balance between road safety and travel time. However, SPG is computationally expensive. SPG and CZMP use the same parameter settings where possible.

CZMP-U CZMP-U is similar to CZMP except that it only uses a fixed delay increment
value, 2s. That is, CZMP-U does not allow different delay increment values as CZMP does.

Evaluation measures
Average Travel Time Ratio (ATTR ) As shown in our problem definition (Section 3), an ideal safety management solution would balance safety and travel time. We use the ATTR to evaluate the solutions from the traffic efficiency perspective. For a given vehicle a i , tt i ftt i is the ratio between the actual travel time ( tt i ) and the hypothetical shortest travel time ( ftt i ), which can be achieved when the vehicle travels at the road speed limit during its entire trip. ATTR is computed as 1 , where n is the number of vehicles. We evaluate traffic efficiency using ATTR rather than a simple summation of travel times because the later form is less suitable to reflect the travel time delays experienced by individual vehicles. The hypothetical optimum value of ATTR is 1, which is also the minimum value that can be achieved. A lower ATTR indicates that the actual travel times are closer to the hypothetical shortest travel times, which represents a better traffic efficiency.

Average Distance to TTC Threshold (ADTTC )
We use ADTTC to evaluate the solutions from the safety perspective. The value is calculated as 1 n DTTC , where DTTC is the road safety metric in our problem definition (Section 3) and n is the number of vehicles.

Update Interval Utilization (UIU)
We use UIU to measure computation costs. UIU is defined as Computation Time Update Interval . If the UIU of a solution is higher than 1, the solution is not suitable for real-time optimization as the computation cannot be completed within the update interval. Conversely, a solution is readily deployable in terms of computation efficiency if its UIU is below 1.

Parameter settings
Based on a range of experiment parameters, we evaluate the performance of all the solutions under different combinations of parameter settings. When varying the value of one parameter, all other parameters are set to their default values. The value ranges of parameters are shown in Table 2.
For a particular parameter combination, we run one simulation using each of the solutions. At the start of the simulation, a set of vehicle routes is loaded into the simulator. The simulation runs until all vehicles finish their journeys. The TTC values at each time step and the travel times of vehicles are computed and recorded. At the end of the simulation, we measure the performance of the solution based on the records.
To make a fair comparison between the solutions, all the solutions are tested with the same set of vehicle routes for a specific combination of parameter settings. The set of routes is generated based on the values of three parameters: road network, traffic volume and traffic distribution. We run a one-hour simulation using the FPG-1 baseline to generate the set of routes. The traffic volume is kept constant during this simulation, which means a new vehicle is put into the road network when a vehicle reaches its destination. More details of the experiment parameters are shown below. Other Parameters In all our experiments, the time step ( Δt ) is 1s, the minimum allowed TTC ( TTC mn ) is 2s, the TTC threshold ( TTC thr ) is 10s, the maximum velocity allowed ( V mx ) is 72kmh, the delay increment sequence (D) in Algorithm 2 is [8s, 4s, 2s], the increment of IDM's TH parameter ( Δs ) in Algorithm 3 is 1s, and the update interval (U) is 10s. In IDM model, vl 0 = V mx , s 0 = 2m , AC mx = 1.4ms −2 , B = −2.0ms −2 and = 4.

Real data based experiment setup (RDE-Setup)
In RDE-Setup, we use the same baselines and evaluation measures that are used in SDE-Setup. To set up the realistic road network and the traffic distribution, we consider two realworld taxi datasets, New York taxi dataset 4 and Beijing (T-Drive) taxi dataset 5 [45] along with the real maps available from Open Street Maps 6 .

New York Traffic Scenarios
Based on the area covered by New York taxi dataset, we consider two map areas approximately 3km × 3km in size as shown in Fig. 6a and b. For each map, we extract the taxi trips in the map area within a randomly selected hour of a randomly selected day (For example, we consider 7 am -8 am on 2015/04/11 for New York Midtown map). The two areas have different numbers of taxi trips, as shown in the real data. Then we generate background traffic (non-taxi vehicles) using the uniform traffic distribution (UTD) generation technique that we used in SDE-Setup. We consider three background traffic levels (3600, 5400 and 7200 vehicles/hour) for both maps considering the capacities of the road networks. The selected background traffic levels avoid potential gridlock scenarios for all the baselines as such scenarios could not provide a comparative result. Figure 6a shows the Central Business District (CBD) in New York Midtown area. There were nearly 3600 taxi trips within the hour we consider. For this map when the background traffic level is 3600 vehicles/hour scenario, we simulate 3600 taxi trips with 3600 non-taxi vehicles (total of 7200 vehicles) within the onehour period. Figure 6b shows the New York Manhattan Bridge area, which consists of nearly 2400 taxi trips within the period.
Beijing Traffic Scenarios Based on the area covered by Beijing taxi dataset (T-Drive), we consider two map areas approximately 3km × 3km in size as shown in Fig. 6c and d. For each map, we extract the taxi trips in the map area within a randomly selected hour of a randomly selected day. Then we generate background traffic considering three background traffic levels (5400, 7200 and 9000 vehicles/hour) similar to the New York traffic scenarios. Compared to the New York scenarios, we were able to add higher background traffic levels into the Beijing traffic scenarios, while avoiding potential gridlocks for baselines. Figure 6c shows an area near the Beijing railway station. There were nearly 1500 taxi trips within the period. Figure 6d shows a major intersection in the Beijing Chaoyang area. There were nearly 1200 taxi trips within the one-hour period.

Other parameters
We set the look-ahead distance (LA) to 600m. As the view of drivers is normally limited in real scenarios, especially for dense road networks in large cities like New York and Beijing, the look-ahead distance in RDE-Setup is shorter compared to SDE-Setup. For example, a 600m look-ahead distance in the New York Mid Town scenario covers around six intersections ahead, which is sufficient for city driving. The remaining parameter values are the same as default values in SDE-Setup.

Results
We present experimental results in three parts: comparative test results with SDE-Setup, comparative test results with RDE-Setup and parameter sensitivity test results with SDE-Setup. which is the maximum allowed update time utilization for real-time usage. CZMP's advantage over other solutions is most visible when the traffic volume is 750. For example, CZMP achieves a 60% reduction of ATTR and a 68% reduction of ADTTC compared to the state-of-the-art solution ICR. This shows the benefit of our approach that optimizes delays first then makes motion plan for all vehicles at once. This approach is only used by CZMP and CZMP-U. The only case where this approach does not work better than others is when traffic volume is at the lowest level (250). In that case, SPG and FPG-L perform better than CZMP in terms of road safety. CZMP only considers delaying a vehicle when there is one or more conflict zones within the look ahead distance from the vehicle. If the number of vehicles is low, the number of conflict zones tends to be low as well, leading to a lower effectiveness of CZMP.

Impact of Traffic Volume
The result shows that CZMP and CZMP-U are computationally efficient. For example, even with 1500 vehicles, the UIU of CZMP is still under 0.1, which means the computation time is under 1 second as the update interval is 10 seconds. This shows that CZMP-based solutions are suitable for real-time usage. The UIU of SPG grows over 1 when the traffic volume is higher than 750. For example, the UIU of SPG reaches 3.44 for 1500 vehicles, which means SPG runs more than 30 times slower than CZMP with that traffic volume. The high computation cost of SPG is due to the repetitive computation of motion plans as motion planning is combined with delay planning in SPG. We do not present the UIU of ICR and ATSC in Fig. 7 because the computation time of these two baselines are negligible due to the fact that they do not process network-level traffic information during optimization. All other solutions need to process network-level information, which can consume a considerable computation time. We also found that the construction of CZG only consumes a small portion of the computation time of CZMP. For example, in the 1500-vehicle scenario, only 12.5% of CZMP's computation time is spent on constructing CZG while the remaining computation time is spent on running Algorithm 2 and Algorithm 3. Although it would be possible to save some computation time if the CZG is updated incrementally rather than being constructed from scratch at each interval, the time saving can be limited based on the results.

Impact of Road Network
The results on different road networks are shown in the left part of Fig. 8. Same as Fig. 7, lower values are better in terms of ATTR, ADTTC and UIU. CZMP and CZMP-U achieve better safety level and travel time than other baselines in most cases. For example, in road network RG-3, CZMP achieves a 60% reduction of ATTR and a 67% reduction of ADTTC compared to ICR. CZMP and CZMP-U show better performance in double-lane networks (RG-3 and RG-4) than in single-lane networks (RG-1 and RG-2). As the density of vehicles is lower when the number of lanes is doubled, CZMP-based solutions have more opportunities to increase the inter-vehicular spacing, resulting in better safety levels and better travel times. Interestingly, in single-lane scenarios (RG-1 and RG-2), FPG-L achieves a better safety level compared to CZMP and CZMP-U. This is because the position-based variable spacing values in FPG-L encourage frequent changes of inter-vehicular spacing as vehicles move, which can help improve safety in dense traffic. CZMP-U and CZMP achieve similar ATTR and ADTTC except for road network RG-3, where CZMP performs better as inter-vehicular spacing is optimized using different delay increment values, which allows fine-tuning of the inter-vehicular spaces.
All the solutions, except SPG, can complete optimization in less than one tenth of the update interval. The UIU of SPG is above 1 in some of the scenarios, which makes it unsuitable for real-time usage in those scenarios. The results show that CZMP-based solutions can achieve a better balance between travel time and safety compared to others. They also have a good computation efficiency. Similar to the results in Fig. 7, the UIU of ICR and ATSC is not shown in Fig. 8 due to the fact that they do not process network-level traffic information, leading to negligible computation time.

Impact of Traffic Distribution
The right part of Fig. 8 compares the solutions with two traffic distributions. When the distribution is Gaussian (GTD), ATSC achieves a slightly better safety level compared to the CZMP-based solutions. In GTD, the traffic at the centre of the road network is highly congested, leading to a high probability of vehicle conflicts. ATSC achieves a better safety level in this case as it helps to eliminate a large portion of safety risks at road junctions using traffic signals. However, ATSC performs worse than CZMP-based solutions safety-wise in all other cases in the experiments.

Discussion on the Results of the Tests with SDE-Setup
As mentioned in Section 3, our network-level safety optimization problem aims to find the best solution for minimizing a safety metric, Distance to TTC Threshold (DTTC). DTTC is aggregated from the events where the time-to-collision (TTC) of vehicles is below the TTC threshold, beyond which the safety risks are negligible. As DTTC measures the distance to the threshold, a lower DTTC is more preferable because a lower DTTC indicates that vehicles' TTCs are higher, which means vehicles are less likely to collide with each other. The lowest value of DTTC is 0, which is the hypothetical optimum of the metric. When presenting our experimental results, we show the safety level on a per vehicle basis using ADTTC, which is DTTC Fig. 8 Results on traffic network and traffic distribution divided by the number of vehicles. We use ADTTC because comparing DTTCs directly is less meaningful as the number of vehicles can vary in different scenarios.
Although the ADTTCs of CZMP and CZMP-U are not exceptionally close to the hypothetical optimum, they are closer to the hypothetical optimum than other baselines in most cases (Figs. 7 and 8). In some cases, the reduction of ADTTC achieved by CZMP-based solutions is significant. For example, when the traffic volume is 1500, the ADTTC of CZMP is 59% smaller than that of the state-of-the-art solution ICR. There are only a few cases that the safety levels achieved by some other baselines are closer to the hypothetical optimum than CZMP-based solutions. However, in those cases, CZMP-based solutions outperform other baselines in terms of the travel time metric ATTR. For example, FPG-L achieves a lower ADTTC than CZMP in the RG-1 network but CZMP reduces ATTR from FPG-L by 16.5% in the same network. Overall, CZMP-based solutions achieve a better balance between road safety and travel time. CZMP-based solutions also have low computation costs comparable to other baselines.

Comparative tests with RDE-Setup
Results of New York Traffic Scenarios As shown in Fig. 9, CZMP and CZMP-U outperform other baselines in terms of road safety level and travel time in most cases, especially in moderate to high traffic volume cases. For example, in New York Midtown scenario (left), when background traffic rate is 5400, CZMP-U shows a 27% reduction of ATTR and a 63% reduction of ADTTC compared to the FPG-1 baseline. It shows a similar result with the 7200 background vehicle rate as well. Though FPG-L shows a better safety level at 3600 background vehicle rate, CZMP-U shows a better result travel time-wise. Although SPG shows a safety-wise better result compared to FPG-1 when the background traffic rate is 5400 and 7200, it is not a feasible solution at these two settings, where its UIU is greater than 1. In New York Manhattan Bridge scenario (right), CZMP-U outperforms all the other methods at all the background traffic levels. CZMP-U's advantage over other solutions is most visible when the background traffic rate is 5400. For example, CZMP-U achieves a 15% reduction of ATTR and a 39% reduction of ADTTC compared to FPG-1. Different to the results with SDE-Setup, where ICR showed better performance compared to FPG-1, FPG-1 performs better than ICR in the New York traffic scenarios. However, our solutions CZMP-U and CZMP are significantly better than both FPG-1 and ICR in New York traffic scenarios. When the background traffic rate is 3600, SPG's safety level is similar to CZMP. However, SPG takes a significantly longer computation time compared to CZMP. The result also shows that CZMP and CZMP-U are computationally efficient. In all the scenarios, the maximum value of UIU of our methods is under 0.25, which means the computation time is under 2.5 seconds as the update interval is 10 seconds. Fig. 10, CZMP and CZMP-U outperform other baselines in terms of road safety level and travel time in most cases, especially in moderate to high traffic volume cases, similar to the New York traffic scenarios. For example, in Beijing station area scenario, when back ground traffic rate is 7200, it shows a 2% reduction of ATTR and a 34% reduction of ADTTC compared to the FPG-1 baseline. Although FPG-2 and SPG perform better than CZMP in terms of safety, when the background vehicle rate is 5400, CZMP and CZMP-U show better results travel time-wise.

Results of Beijing Traffic Scenarios As shown in
In the Beijing Chaoyang area scenario (right), CZMP outperforms all the other methods in terms of safety at all the background traffic levels. In all cases, CZMP shows a minor ATTR reduction of around 1% with an ADTTC reduction ranging between 11%-22%. Although, the ICR baseline is the best method in terms of travel time in this scenario, it increases ADTTC by up to 66% compared to CZMP. SPG shows better safety levels compared to FPG-1 at 7200 and 9000 background traffic rates. However, SPG's computational complexity is several magnitudes higher than FPG-1 so it is not a feasible solution for these settings. The result shows that CZMP and CZMP-U are computationally efficient. In all the scenarios, the UIU of our methods is under 0.06, which means the computation time is under 0.6 seconds as the update interval is 10 seconds.

Discussion on the Results of the Tests with RDE-Setup Overall our methods CZMP and
CZMP-U show a better result when the road network is based on a grid plan, such as in the New York Midtown scenario. When the road network is dense (have intersections in closer proximity), the performance of other methods, especially ATSC and ICR, tend to degrade significantly. However, both CZMP and CZMP-U are capable of maintaining a good balance between efficiency and safety even in dense road networks.

Parameter sensitivity tests with SDE-Setup
In this section we discuss the impact of two parameters that are used by CZMP-based solutions. The results on the two parameters are shown in Fig. 11. Lower values are

Impact of Look-Ahead Distance
The left part of Fig. 11 shows the results on lookahead distance LA. When LA increases from 300m, the performance of CZMP improves but the improvement becomes smaller as LA increases. The result shows that a long look-ahead distance, such as 2100m, does not provide significant benefits to safety and travel time as it is difficult to predict traffic far into the future. The computation cost (UIU) increases with the look-ahead distance in a linear fashion, which is as expected because the amount of information that needs to be processed tends to increase when the look-ahead distance increases. For example, a longer look-ahead distance can lead to more conflict zones, which increases the computation cost of optimization. Based on the result, the default value of the look-ahead distance is set to 900m. We also observe that CZMP performs better than CZMP-U as the former solution uses multiple delay increment values to optimize inter-vehicular spacing while the later one only uses a fixed increment value.

Impact of Desired Maximum Travel Time Factor
The right part of Fig. 11 shows the results on the desired maximum travel time factor . When is 1, the framework cannot add delay to vehicles due to the constraint on desired maximum travel time (Section 4.2). With the increase of , CZMP tends to consider more vehicles into the optimization. The result shows that CZMP can improve safety level and achieve a good balance between safety and travel time when a limited set of vehicles get delayed. For example, when increases from 1 to 1.5, CZMP's ATTR reduces by 67% and its ADTTC reduces by 72%. When increasing beyond 1.5, both ATTR and ADTTC do not change significantly for CZMP. In terms of safety and travel time, CZMP-U performs worse than CZMP when is between 1.25 and 1.75. This shows that using a fixed delay increment (CZMP-U) is not as effective as using multiple delay increment values (CZMP). UIU remains largely unchanged when varying for both solutions.

Conclusions and future work
Our proposed CZMP framework can achieve a good balance between road safety and travel time using network-level spatio-temporal data. The framework is particularly suitable for real-time applications due to its low computation costs. Our experimental results show the significant advantages of the framework over other data management solutions. CZMP improves the safety level by up to 68% while reducing the travel time by up to 60% against the state-of-the-art traffic-efficiency-oriented solution ICR. CZMP also runs more than 30 times faster than our preliminary solution SPG in certain scenarios.
The current design of CZMP assumes that all the vehicles would follow the instructions given by the framework. A future work can evaluate the performance of the framework when a portion of the vehicles cannot follow the instructions. It would also be interesting to incorporate more types of information, such as weather conditions, into the framework. A future work can also extend CZMP for multi-modal transport that includes cars, trains and trams. Finally, in the current design of CZMP, we generate the conflict zone graph from scratch at each update interval. A future extension to CZMP can consider incremental updates of the graph. However, as we have discussed in the experimental results, only 12.5% of the computation time is spent on building the graph in our current design so the benefit of the incremental version may be limited. The framework decouples each major step of the workflow, and it enables better usability and extendability for future applications.

Author Contributions Not applicable.
Funding Open Access funding enabled and organized by CAUL and its Member Institutions Data availability The datasets generated during and/or analysed during the current study are available from the corresponding author on reasonable request.

Code availability
The code of our method(s) will be made publicly available on acceptance.

Conflicts of interest
The authors have no competing interests to declare that are relevant to the content of this article.

Ethics approval
We have considered the ethical implications and have none to report.

Consent for publication Not applicable.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http:// creat iveco mmons. org/ licen ses/ by/4. 0/. Hairuo Xie is a research fellow at the School of Computing and Information Systems, University of Melbourne. His current research interests include spatial algorithms, traffic management, traffic simulation and distributed computing. He architected a distributed microscopic traffic simulator that has been used extensively in the research community.
Egemen Tanin finished his PhD at the University of Maryland at College Park before joining the University of Melbourne. He is a professor at the School of Computing and Information Systems. He is an Associate Editor of ACM TSAS and served as a PC Chair for ACM SIGSPATIAL 2011 and 2012. He was elected to serve as the Treasurer for ACM SIGSPATIAL and served in this role till 2017. Dr Tanin was also elected to be the Secretary of the SIG, 2017-2020. He was elected to be the next Vice-Chair of SIG in 2020. He is the cofounder of ACM SIGSPATIAL Australia.
Shanika Karunasekera received the B.Sc. degree in electronics and telecommunications engineering from the University of Moratuwa, Sri Lanka, in 1990 and the Ph.D. degree in electrical engineering from the University of Cambridge, Cambridge, U.K., in 1995. From 1995 to 2002, she was a Software Engineer and a Distinguished Member of Technical Staff with Lucent Technologies, Bell Labs Innovations, USA. In January 2003, she joined the University of Melbourne, Victoria, Australia, and currently she is a professor in the School of Computing and Information Systems. Her current research interests include distributed system engineering, distributed data-mining and social media analytics.