A Multi-Hierarchical Strategy for On-Ramp Coordination

Abstract

Ramp metering (RM) is an access control for motorways, in which a traffic signal is placed at on-ramps to regulate the rate of vehicles entering the motorway and thus to preserve the motorway capacity. In general, RM algorithms fall into two categories by their effective scope: local control and coordinated control. Local control algorithm determines the metering rate based on the traffic condition on adjacent motorway mainline and the on-ramp. Conversely, coordinated RM strategies make use of measurements from the entire motorway network to operate individual ramp signals for optimal performance at the network level. This study proposes a multi-hierarchical strategy for on-ramp coordination. The strategy is structured in two layers. At the higher layer, a centralised, predictive controller plans the coordination control within a long update interval based on the location of high-risk breakdown flow. At the lower layer, reactive controllers determine the metering rates of those ramps involved in the ramp coordination with a short update interval. This strategy is modelled and applied to the northbound model of the Pacific Motorway in a micro-simulation platform (AIMSUN). The simulation results show that the proposed strategy effectively delays the onset of congestion and reduces total congestion with better managed on-ramp queues.

1 Introduction

Motorway congestion has become a worldwide problem that strongly reduces traffic throughput, fluidity and safety, as well as increasing trip times and environmental pollution. Taking Australia as an example, the cost of congestion was estimated at approximately $9.4 billion in 2005, and expected to rise to over $20.4 billion by 2020 according to the Australian Government Department of Transport and Regional Services Bureau of Transport and Regional Economics Department of Transport and Regional Services (2007).

Ramp metering (RM) uses a traffic signal at an on-ramp to regulate vehicles entering the motorway, and is considered to be the most effective tool currently available for motorway congestion, with its effectiveness already proven by field implementation results (M Papageorgiou and Kotsialos 2002). Without RM, high ramp flows merging into the motorway mainline increase the chance of flow breakdown and significantly reduce capacity as a result. In other words, the principal concept of RM is to temporarily hold ramp traffic to keep total demand at merging area around capacity for managing congestion; therefore, RM tends to give more priority to mainline traffic. However, ramp traffic might also gain an advantage, because the congestion in the mainline eventually reduces their opportunities to use the motorway.

In general, RM algorithms fall into two categories according to their effective scope: local control and coordinated control. The localised controller determines the metering rate adjacent traffic condition, including mainline and ramp link. This type of RM has limitations. In the field, limited ramp storage space and continuous high ramp flows at peak hours are likely to disable the localised controller quickly, because ramp traffic can only be held temporarily. Consequently, local congestion will build up from merging area, whilst other ramps might have no ramp queues at all. Therefore, the most significant disadvantage is the inefficiency in utilising ramp storage in the whole network, causing unevenly distributed ramp queues along the network.

In order to tackle the aforementioned limitation, a natural solution is to determine all metering rates in the same network based on network-wide traffic conditions: that is, coordinated RM. Coordinated RM (CRM) has been studied since the 1980s (Jacobson et al. 1989), which makes use of measurements from the entire motorway network to control ramp signals for the optimal performances at the network level. The availability of network-wide information enables operating ramp meters to achieve an enhanced efficiency of the whole motorway network, and to distribute ramp utilisation and ramp queues more evenly. Therefore, CRM represents the current best practice, and this study focuses on developing a CRM strategy for field implementation. Complex mathematical models and optimisation approaches require comprehensive and highly reliable traffic detector data, which is often implausible in reality. Thus, the proposed strategy in this paper takes the rule-based heuristic (model-free) framework with the feedback concept embedded in the control structure, which is simple, transparent, robust and less data-dependent.

The remainder of this paper is structured as follows. Section 2 briefly reviews two typical approaches for on-ramp coordination: model-based and heuristic rule-based. In the following section, the problem of CRM is stated and discussed from the practical point of view. In Section 4, the new CRM algorithm with the fundamental control concepts and components are introduced. The simulation evaluation results are presented in Section 5. Section 6 concludes this study.

2 Review of Existing Coordinated Ramp Metering

CRM studies have been undertaken extensively over the last three decades. According to the methods of determining the coordination among ramp meters, coordinated ramp metering strategies can be divided into two categories: the model-based optimisation method and the rule-based heuristic method.

2.1 Model-Based Optimisation Method

This type of algorithm attempts to optimise the metering rates of the ramps over an optimisation horizon. The algorithms in this category typically employ a macroscopic traffic flow model to estimate the current and the near future traffic conditions. The RM control is then treated as a system optimal problem in this approach; the interested motorway network is described in a state-space form:

$$ x\left(k+1\right)=f\left[x(k),u(k),d(k)\right] $$

(1)

where

$x(k)$is the network state vector, including occupancy, mean speed and queue length;

$u(k)$is the control input vector, including the metering rates of metered on-ramp;

$d(k)$is the external disturbance vector which is usually the traffic demand.

Typical control objectives adopted for optimisation are total vehicle travel time or total vehicle delay time, while field constraints can serve as a penalty term in the objective function. For numerical optimisation, techniques such as linear quadratic programming or nonlinear programming are used. Examples of this control approach include the Linear Programming algorithm (Yoshino et al. 1995), and the Advanced Motorway Optimal Control (Kotsialos et al. 2002).

Although this type of CRM attempts to achieve the optimal solution theoretically with network-wide information, application to the field is often impractical. One reason is a high number of inputs for the model requires many estimates and predicts for field implementation; therefore, the accuracy of the input data will profoundly impact the effectiveness of the model. Another important reason is that the coordination logic is not straightforward, but is embedded in the formulation of the objective function and parameter settings; therefore difficult for some field engineers to understand. At the end of any ramp metering application, field engineers conduct the implementation of the real system; the implicit logic makes the parameter calibration process very tough for the field engineers, and thereby reduces their willingness of implementing such systems.

2.2 Rule-Based Heuristic Method

This type of CRM algorithm decides metering rates for participating on-ramps by a series of pre-defined rules. Rules here are typically based on simple principles or extracted from historical analysis and expert experiences, for example, the Fuzzy logic technique based algorithm by Bogenberger et al. (2002). According to historical data analysis and expert experience, this algorithm generates several traffic patterns for the system-wide network, and also for each on-ramp and pre-defines a metering rate for each metered on-ramp of each defined pattern.

The major advantage of the heuristic approach is its good applicability as well as the transparent logic, and thus most of the field-implemented coordinated systems fall into this category, such as the Helper ramp algorithm (Lipp et al. 1991), the Sperry algorithm (Virginia Department of Transportation 1998), the HERO algorithm (Papamichail et al. 2010) and the new Minnesota algorithm (Geroliminis et al. 2011). Among these field-implemented systems, HERO is a recent and well-known system based on the master–slave concept. However, the details of HERO are not clear as it is a commercial system.

However, simple rules are always of feed-forward nature, which cannot accurately describe complicated traffic conditions, especially critical conditions. For example, a computing metering rate based on the demand-capacity principle requires capacity as an input data, which is widely acknowledged as having stochastic nature. Using a fixed capacity setting always causes mismatch between the control model and the prevailing traffic condition. From this point of view, additional mechanisms should be introduced to make the algorithm more stable and to reflect the actual traffic conditions in the metered ramps.

3 Problem Statement

The main reason for requiring ramp coordination is the unbalanced traffic distribution along motorway networks. Heavy ramp flows and lane reductions are the main cause of recurrent congestion in a motorway network. With only local control, it is impossible to handle those on-ramps with heavy traffic flow due to queue constraints. As a result, traffic queues, developed in those areas, propagate upstream, activating other bottlenecks. In addition, only the on-ramps located close to the bottleneck would take action, restricting the mainline access, given that localised RM is operated independently. Meanwhile, upstream ramps are not efficiently utilised because they would not detect congestion from their local information. To sum up, ramp coordination is required for better utilisation of network resources for congestion management.

According to the above analysis, ramp coordination is materialised by requiring upstream spare ramps to help the downstream critical ramp (an active bottleneck). Therefore, this study also considers the master–slave concept to plan the coordination. Any on-ramp may request coordination when the merging traffic condition and the on-ramp queue condition are approaching the critical level. This ramp becomes the master ramp and may recruit one or more upstream on-ramps to be its slave ramps included in the coordination control. Slave ramps assist the master ramp by reducing the metering rate.

Note that traffic conditions at the downstream bottleneck cannot be affected immediately by upstream ramps, due to the distance between upstream ramps and downstream bottleneck. In other words, there is a time lag between upstream contributors (slaves) and the downstream receiver (the master). A relatively long interval, covering the time lag, is necessary when considering coordination between ramps. With the long interval, the impact of coordination control executed in a previous interval can be measured by detectors at the downstream bottleneck. Accordingly, a new control decision can be made, based on those detector measurements. However, a relatively long interval slows down the speed of the control reacting to the high dynamics of traffic flows. For example, a large incoming platoon can suddenly disable one ramp from participating coordination, and can even make the ramp become an active bottleneck. Considering the high fluctuation of traffic flow requires a short interval to enable quick response of the coordination to traffic conditions. Accordingly, a compromise is needed to balance time lag and high traffic dynamics.

In addition, the objective of CRM is to prevent congestion or to delay congestion. This requires the coordination control to be proactive: that is, to plan in advance. Considering the time lag, the coordination control should be even more proactive. A proactive control would involve prediction, but no prediction can guarantee absolute accuracy; therefore, the proactive control would introduce some errors and mismatches to the system. The reactive control can adjust the prediction errors and mismatches, so as to improve the robustness of the coordination. Consequently, a coordination strategy needs to combine the advantage of proactive control and reactive control.

In summary, the purpose of this paper is to present a strategy for CRM, combining proactive and reactive control, to overcome the time lag and to provide quick response to traffic conditions.

4 Strategy Development

The proposed ramp coordination is designed to overcome the time lag and to provide quick response to traffic conditions. A multi-hierarchical control framework is developed (see Fig. 1).

Fig. 1

Multi-hierarchical control framework

The higher level layer (or coordination planning layer) is a centralised, predictive controller that plans the coordination control within a long update interval (coordination interval, CI). This is because planning the coordination affects a large part of motorway network (could be up to about a 10-km section). Also, the long update interval, covering the time lag, enables the updated plan to be reactive to the coordination operation in the previous interval. In addition, the coordination is planned proactively with predictive information. CI is 5 min in this study. One task undertaken at this layer is to activate coordination when the traffic measurements indicate an imminent flow breakdown. Another task is to dynamically define the coordination group based on the prevailing traffic condition at active bottlenecks.

The lower level layer (or coordination planning layer) incorporates reactive controllers that determine the metering rates of those ramps in the coordination group. In order to better overcome the time lag, a feedback controller is formulated and tested (see details in Section 4.5). The slave metering rate is calculated based on both the traffic density (loop detector occupancy) level in the downstream bottleneck area and its own ramp queue size. The control mechanism is a feedback approach that adjusts the slave metering rate continuously to achieve the desired traffic condition in the downstream bottleneck area. Compared with the coordination planning layer, this layer considers both the actual changes at the downstream bottleneck and the slave’s own condition, so a short update interval (time interval, TI) is adopted to enable quick feedback reaction on time.

Figure 2 shows the five logic components for ramp coordination. The first step is to identify the ramp(s) in need of coordination (coordination activation). A ramp with both mainline merge occupancy and the queue size exceeding a certain threshold becomes a “master” ramp that requests coordination. The slave selection component recruits one or more upstream ramps as “slaves”, switching their metering to the coordinated mode. A master ramp and its slave ramps are called a coordination group. The coordination group can be resized on a regular basis (coordination review). At each TI, a congested slave ramp will be released from the coordination, or a new slave ramp could be recruited to replace the released one or to give additional aid to the master ramp (slave status monitoring and renew). The coordination will be cancelled when the queue size in the master ramp reduces under a pre-specified level or all the available ramps are used up (coordination cancellation).

Fig. 2

Flowchart of the coordination strategy

The three components in the dashed line area work at the coordination planning layer, while the other two are at the coordination planning layer. The rest of this section introduces the five components.

4.1 Coordination Activation

This component identifies a master ramp and activates coordination. Three conditions would activate coordination: 1) a mainstream traffic state approaching the merging area capacity; 2) a ramp queue size exceeding a threshold level; and, 3) a ramp queue size projected to spill-over in the near future. The mainline occupancy measure is smoothed by the single exponential smoothing technique by Eq. 2, while the ramp queue size projection is also calculated by the single exponential smoothing technique (Gardner 1985).

$$ {x}^{sm}\left(t+1\right)=\alpha \cdotp x(t)+\left(1-\alpha \right)\cdotp {x}^{sm}(t) $$

(2)

where

“${x}^{sm}$”is the projected value by smoothing;

“α”is the smoothing parameter and 0.3 is used in this study.

The ramp queue size can be estimated using the on-ramp queue estimation algorithm presented in the literature (Lee et al. 2013). The algorithm is based on Kalman filter theory and uses counts and occupancy from three ramp-link loop detectors. The aforementioned three conditions to activate coordination can be formulated as follows. Condition 1 looks at the mainline merging condition, while the other two conditions review the ramp queuing conditions. Specifically, Condition 2 is for current queue length, and Condition 3 looks at the projected queue length for the next CI. Note that all three conditions must be satisfied.

$$ \left\{\begin{array}{c}{Occ}_i^{sm}(t)>{Occ}_i^{th}\\ {}{NV}_i^{est}(t)>{NV}_i^{th1}\\ {}{NV}_i^{prj}(t)>{NV}_i^{th2}\end{array}\right. $$

(3)

where

“Occ”is detector occupancy;

“i”is the ramp index starting from the most upstream one to downstream;

${Occ}_i$is the occupancy of mainline merging area at the downstream of ramp i;

“sm”indicates a smoothed value;

“th”indicates a threshold value;

“Est”indicates an estimated value which represents the best guess of current condition;

“prj”indicates a projected value for the near future;

“NV”is the queue length in ramp in terms of the number of vehicles;

${NV}_i^{th1}$is the queue length threshold to check if current queue size is in risk;

${NV}_i^{th2}$is the maximum manageable queue size; when the queue is over this threshold, it is high possible the ramp queue will spillover in the next coordination interval.

4.2 Slave Selection

The process of slave selection is to seek sufficient assistance from slave ramps for the master ramp. The first step is to estimate the level of assistance required. This requirement is for the excessive queue in the master ramp (the X symbol in Fig. 3) to mitigate through the coordination metering. It is defined as the difference between the projected queue size and the maximum manageable queue. In Fig. 3, the arriving vehicles are counted at the ramp entrance detector, while the departure vehicles are counted at the detector after the ramp signal stop-line. The maximum manageable queue is pre-set for each ramp, and is determined based on individual ramp storage space.

Fig. 3

Queue projection

The next step is to calculate the possible contribution from upstream ramps. The contribution is calculated for each ramp starting from the immediate upstream ramp of the master ramp until the sum of contributions exceeds the master requirement. For each slave, the potential contribution is also defined as the difference between the maximum acceptable queue size and the projected queue size (see Fig. 3). Note that the ramp with the projected queue size exceeding the maximum manageable queue will not be recruited. In addition, the maximal number of slaves for one master is five in this study (the most upstream slave should be less than 10 km to the master).

Both the requirement and the contribution are calculated based on the projection of ramp flow by the single exponential smoothing technique of Eq. 2.

4.3 Slave Status Monitoring and Renew

Although the decision to recruit a slave ramp is made based on the projected queue size, the queue projection is always subject to a forecasting error, so it is possible to create unacceptably long queues in the slave ramp. Once a slave ramp encounters its own queue problem, it must be released from the coordination and the mode of operation must also switch back to the normal local RM mode. In order to prevent those released ramps from taking benefit from other slaves located upstream, the module sets the maximum metering rate with the arrival flow rate. When one or more slave ramps are released from coordination, the module will search and recruit additional ramps to replace those released. The purpose of this module is to enable quick response to traffic condition; therefore, this module is running for every TI.

4.4 Coordination Cancellation

The coordination control might be cancelled by two conditions. One is that the master ramp is detected to be no longer in need of coordination because of enhanced traffic flow conditions. The other condition is that the master merging area falls into congestion so coordination is no longer an effective prevention measure. Either of these two conditions may cancel the coordination control and restore the local RM. These conditions can be formulated as follows:

$$ \left\{\begin{array}{c}\begin{array}{c}{NV}_i^{est}(t)<{NV}_i^{thd}\\ {} or\\ {}{Occ}_i^{sm}(t)<{Occ}_i^{thd}\end{array}\ \\ {} or\\ {}{Occ}_i^{sm}(t)\gg {Occ}_i^{cri}\end{array}\right. $$

(4)

where

${NV}_i^{thd}$is the deactivation queue length threshold;

${Occ}_i^{thd}$is the deactivation merge occupancy threshold;

${Occ}_i^{cri}$is the critical occupancy at the merge.

4.5 Coordinated Metering Control

This module controls the metering rate of all the metered ramps in the coordination group. This is a feedback controller and two strategies are included for master and slave ramps.

In the coordination mode, the master ramp will keep the local RM (based on ALINEA (Papageorgiou et al. 1997) plus an adaptive on-ramp queue management algorithm (Jiang et al. 2012)). The local RM keeps tracking the ramp queue length and will eventually increase metering rate once the queue becomes long. The slave metering control will be determined by a feedback controller based on PID theory.

The PID controller is the most widely and successfully used controller type, due to its simple and transparent form. The fundamental concept of the slave metering control is to meter slaves more restrictively to help the downstream master. This is realised by letting slaves react directly to the master ramp’s merging condition using a series of PD controllers (I-term is not used based on the below analyses and simulation tests). The physical meaning of proportional, integral and derivative terms are as follows:

• P-term: stands for “proportional” and the P-term is designed to react for the instant error between target value and instant measurement. Consequently, it is calculated as the change of the accumulative error at interval t. P-term changes the metering rate directly proportional to the occupancy change. This feature is useful to adjust the slave metering rate when the merging occupancy is gradually increasing but is yet under the target occupancy.

• I-term: means “integral”, which indicates that the I-term reacts to the accumulative error at current interval. I-term begins to reduce the metering rate only after the merging area occupancy rises over the target occupancy. This reaction of slave ramps is obviously too late, considering the time lag caused by the travel time between the master ramp and slave ramps. Therefore, the I-term is inappropriate for the slave metering control. Normally, I-term is mandatory for stationary error. Please note that the PD-controller (using measurement from the master’s merging area) only works for slave ramps when active in coordination, and the master ramp itself is based on ALINEA which is an I-controller. Consequently, the local controller of the master ramp will take care of the stationary error.

• D-term: equals “derivative”, and represents the trend of the instant error. In discrete form it is calculated as the change of the accumulative error change. When the master occupancy consistently changes either positively or negatively, the D-term accelerates the reaction (i.e., increasing or decreasing the metering rate) of slave ramps. Consequently, the D-term can be used to supplement the P-term to enable a quicker response of slave ramps when the master occupancy is rising quickly.

As analysed above, the discrete PD controller is given as follows:

$$ \mathrm{r}\left(\mathrm{t}+1\right)=\mathrm{r}\left(\mathrm{t}\right)+{\mathrm{K}}_{\mathrm{P}}\cdotp \left[\mathrm{e}\left(\mathrm{t}\right)-\mathrm{e}\left(\mathrm{t}-1\right)\right]+{\mathrm{K}}_{\mathrm{D}}\cdotp \left[\left[\mathrm{e}\left(\mathrm{t}\right)-\mathrm{e}\left(\mathrm{t}-1\right)\right]-\left[\mathrm{e}\left(\mathrm{t}-1\right)-\mathrm{e}\left(\mathrm{t}-2\right)\right]\right] $$

(5)

where

rrepresents metering rate;

${K}_P,{K}_D$are the coefficients for P- and D-term; and,

erepresents the error between measurement and desired value, given by:

$$ \mathrm{e}\left(\mathrm{t}\right)={Occ}^{*}-Occ\left(\mathrm{t}\right) $$

(6)

where

${Occ}^{*}$is the pre-defined desired occupancy, normally the critical density; and,

$Occ(t)$is the occupancy measurement at interval t.

Note that the detector occupancy is an aggregated measurement, so the error, e(t), calculated in the above equation, is the accumulative error during interval t.

Different slaves have different distance to the master, thereby having different time lag to the master. Therefore, the CRM classifies the metered ramps located upstream of the master ramp in a few categories by their travel time to the master ramp, applying different PD controller structures. Four groups and the default PD controller structures are defined as shown in Table 1. Note that the group setting presented in Table 1 is calibrated by simulation and can be adjustable for different test-beds.

Table 1 Slave groups and PD controller structures

Finally, the more restrictive metering rate between the local RM strategy and the PD controller is selected for implementation. Accordingly, the slave metering control can be formulated as follows:

$$ r=\mathit{\min}\left({r}^C,{r}^L\right) $$

(7)

where

${r}^C$is the coordinated metering rate calculated by Eq. 5;

${r}^L$is the local metering rate calculated from local RM algorithm (Jiang et al. 2012); and,

ris the final metering rate to implement.

5 Simulation Evaluation

5.1 Test-bed

The modelling platform used in the investigation is AIMSUN 6.1. The Pacific Motorway test-bed model was used for this research. The test-bed network is an approximately 30-km section of the northbound (inbound) Pacific Motorway (M3) from Logan City to the Brisbane CBD (see Fig. 4). The traffic volume is about 130,000 vehicles per day. This motorway section serves a large volume of commuter traffic in the morning peak hours, leading to heavy recurrent congestion. For these reasons, local authorities consider the M3 to be an ideal motorway on which to deploy RM to improve traffic efficiency. The major bottleneck for the northbound of the Pacific Motorway, however, is a weaving bottleneck caused by large off-ramp flow at the Gateway Motorway interchange. This might not be the best test-bed for demonstrating the effectiveness of ramp coordination. Therefore, this study uses part of the Pacific Motorway northbound: that is, from downstream of the Gateway Motorway interchange to the Brisbane CBD. There are 8 on-ramps and 8 off-ramps along the network. In the test-bed, the main bottlenecks are caused by merges from high ramp flows, and the most critical bottlenecks are the Stanley St. on-ramp and the Birdwood Rd. on-ramp.

Fig. 4

The Pacific Motorway in Brisbane, Australia

The simulation network used in this study was edited by the Queensland Department of Transport and Main Roads, and model parameters calibrated by the Smart Transport Research Centre (Rahman et al. 2011). The calibration process included two steps: the calibration was conducted first at a disaggregate level using the real dataset of individual vehicles at Vulture Street from the Queensland Department of Transport and Main Roads; and then the parameters were adjusted at a network-level by comparison of overall simulated traffic situation (contours of flow, speed and occupancy) with the reality. In A total of three test scenarios were modelled in the AIMSUN simulation network for evaluation of the CRM strategy:

Table 2, the key model parameters calibrated are listed, and more calibrated parameters can be found in the literature (Rahman et al. 2011). A complete scenario to depict the real traffic demand on the network was developed in terms of traffic state according to the PTDS (Public Transport Data Source) database. According to the whole day volume contour, the morning peak period was determined as a five-hour period from 5 am to 10 am, when the northbound (inbound) motorway witnessed high levels of recurrent congestion. Note that, considering such a long peak period with high demand, it is impossible for CRM to avoid congestion; therefore, CRM is expected to delay the onset of congestion and reduce total congestion with better managed on-ramp queues. Additionally, one simulation hour is added after 10 am to clear all the traffic generated. Consequently, the total simulation period is six hours.

Table 2 Key calibrated parameters (Rahman et al. 2011)

A total of three test scenarios were modelled in the AIMSUN simulation network for evaluation of the CRM strategy:

• Base case (BC) scenario assumes no RM control;

• Local RM (LRM) scenario operates the local RM control independently for all eight on-ramps along the northbound Pacific Motorway;

• CRM scenario operates the CRM control upon an activation of coordination. Otherwise, ramps will operate local RM.

5.2 Performance Indicator

Four aggregated performance indicators are used to demonstrate the benefits and costs of the CRM, compared with the LRM:

• Total Travel Time (TTT): the most widely used efficiency indicator at a system level for RM. It is calculated by summing up all the individual vehicle travel times in the network. The unit of TTT is veh∙h.

• Average mainline traffic delay (MTD): this indicator gives a sense of the coordination benefit. The test-bed is divided into 15 sections based on the location of metered ramps. For each section, individual vehicle travel time within the section is collected and aggregated into the average section travel time. The sum of average section travel times is the entire motorway travel time. The free flow travel time for the entire motorway is also calculated, assuming 80 km/h as the free flow speed. Finally, MTD is defined as the difference between the actual mainline traffic travel time and the free flow travel time. The unit of this indicator is sec/trip.

• Total queue spillover time (TQST): the sum of the total time for each on-ramp when ramp queue spills over to upstream arterials. In this study, the queue spillover is defined as 1-min time occupancy of the ramp entrance detector is over 70 %.

• Average ramp traffic delay (RTD): the way to calculate RTD is slightly different from MTD. Firstly, the aggregated travel time for each ramp is calculated by collecting individual vehicle travel times in ramp. The ramp travel time is collected from the ramp entrance to the downstream merge area. The free flow speed for this section is assumed at 70 km/h. The delay for each ramp is defined as the difference between the actual ramp travel time and the free flow travel time. To consider that the ramp traffic volume varies by each location, the average RTD is calculated using the following equation. The unit of this indicator is sec/veh.

$$ RTD=\raisebox{1ex}{$\sum_i{RTD}_i\cdotp {Q}_i$}\!\left/ \!\raisebox{-1ex}{$\sum_i{Q}_i$}\right. $$

(8)

where

${RTD}_i$is the ramp traffic delay for ramp i; and,

${Q}_i$is the total volume of ramp i.

5.3 Result and Analysis

In Table 3, the simulation results are summarised in terms of those four performance indicators from 10 simulated replications of each scenario, including the average and the standard deviation from the 10 replications. The base case scenario reveals the worst overall traffic condition, the highest TTT of 8509.2 veh∙h and the highest MTD of 604 s/trip. However, the ramp costs are the smallest, including the shortest TQST of 147.6 min and the lowest RTD of 24.5 s/veh.

Table 3 CRM evaluation results summary

Installation of the LRM system made significant improvements to the overall traffic performance and the mainstream traffic. The TTT and the MTD decreased by 13.7 % (from 8509.2 to 7346.6 veh·h) and 33.5 % (from 604 to 401.6 s/trip) respectively. The LRM, however, negatively affects the TQST and the RTD.

Comparison of the LRM and the CRM clearly shows that the coordination control makes the mainstream flow even more quickly. The MTD decreases with the CRM by 10.9 % over the LRM. The coordinated control also improved the overall traffic condition. The TTT is 7092.9 veh·h, which is a 3.5 % further reduction over the LRM and 16.7 % reduction over the base case scenario. Besides, the RTD increases by 21.5 % with the coordinated control. Restricting the mainline access at additional metered ramps is a trade-off for the system benefit (TTT). It is noteworthy that the total queue spillover time slightly reduces, by 3 %. This implies that 1) the strategy responds to traffic conditions quickly; and 2) the coordination strategy can efficiently utilise the queue storage of the slave ramps without causing excessive queuing problems in those ramps.

In order to show the mechanism of the CRM, individual ramp measures, including the RTD and the ramp queue spillover time, are compared in Fig. 5 compares the mainline speed contour of the base case and the LRM scenario. The x axis is time, and the y axis is the location while traffic is travelling from the bottom to the top. The colour represents the speed. It can be seen clearly that the LRM reduces mainline congestion. Figure 6 shows the mainline speed contour comparison between the LRM and the CRM scenario, which demonstrates that the CRM can further improve mainline traffic conditions by ramp coordination: that is, to delay the onset of congestion and to reduce total congestion. In Fig. 6, red ramps are masters, while upstream black ramps are the slaves. Main Rd. on-ramp is in yellow colour because it switches between master and slave.

Fig. 5

Mainline speed contour comparison – base case vs. LRM

Fig. 6

Mainline speed contour comparison – LRM vs. CRM

Table 4 and Table 5. According to the individual RTD in Fig. 5 compares the mainline speed contour of the base case and the LRM scenario. The x axis is time, and the y axis is the location while traffic is travelling from the bottom to the top. The colour represents the speed. It can be seen clearly that the LRM reduces mainline congestion. Figure 6 shows the mainline speed contour comparison between the LRM and the CRM scenario, which demonstrates that the CRM can further improve mainline traffic conditions by ramp coordination: that is, to delay the onset of congestion and to reduce total congestion. In Fig. 6, red ramps are masters, while upstream black ramps are the slaves. Main Rd. on-ramp is in yellow colour because it switches between master and slave.

Table 4 Comparison of RTD by individual ramps (sec/veh)

Table 5 Comparison of ramp queue spillover time by individual ramps (minute)

Table 4, it shows the upstream ramps (the Logan Road, the Kessels Road and the Duke Street on-ramp) restrict their entrance for their downstream bottlenecks (the Birdwood Road and the Stanley Street on-ramp), especially the Logan Road on-ramp. This is because the Logan Road on-ramp is long and of high flow, making it an ideal slave to contribute to coordination. When comparing the individual ramp queue spillover time in Table 5, only the Logan Road on-ramp experiences a marginal increase of only 3.2 min, and all other ramps witness slight decreases. This means that the CRM strategy can manage the queue spillover problem more wisely through the network.

Figure 5 compares the mainline speed contour of the base case and the LRM scenario. The x axis is time, and the y axis is the location while traffic is travelling from the bottom to the top. The colour represents the speed. It can be seen clearly that the LRM reduces mainline congestion. Figure 6 shows the mainline speed contour comparison between the LRM and the CRM scenario, which demonstrates that the CRM can further improve mainline traffic conditions by ramp coordination: that is, to delay the onset of congestion and to reduce total congestion. In Fig. 6, red ramps are masters, while upstream black ramps are the slaves. Main Rd. on-ramp is in yellow colour because it switches between master and slave.

The macroscopic fundamental diagram (MFD) was first proposed by Daganzo (2005, 2007) who recognised that traffic in a large network can be modelled dynamically at an aggregated level. Geroliminis and Daganzo (2008) verified the existence of MFD using Yokohama data, and Geroliminis and Sun (2011) analysed the MFD for motorway networks. Although real data analysis showed that MFD in motorway networks is of high scatter and exhibits hysteresis phenomena, MFD is able to evaluate motorway traffic conditions at a system level.

In this analysis, the flow rate and density are aggregated for every five minutes, and the mainline MFD is defined as the weighted average flow rate against the average density of the mainline sections, based on the simulation data:

$$ {\overset{-}{q}}^w=\raisebox{1ex}{$\sum_i{q}_i\cdotp {l}_i$}\!\left/ \!\raisebox{-1ex}{$\sum_i{l}_i$}\right. $$

(9)

$$ \overset{-}{k}=\raisebox{1ex}{$\sum_i{k}_i$}\!\left/ \!\raisebox{-1ex}{$\sum_i1$}\right. $$

(10)

where subscript “i” represents the section index;

${\overset{-}{q}}^w$is the weighted average flow rate of the network;

qis section flow rate;

lis section length;

$\overset{-}{k}$is the average density of the network;

kis section density.

Figure 7 displays the MFDs for the LRM and the CRM scenario (the mainline MFDs are samples but all the replications produced similar patterns.). In the MFD, the arrows indicate the time sequences of the dots. Blue dots are from the LRM scenario, and red dots are from the CRM scenario. It can be seen from the MFD comparison that the maximum density in the CRM scenario is smaller, which means the maximum mainline queue length is shorter (this can be confirmed by cross-checking speed contours in Fig. 6).

Fig. 7

Mainline MFD comparison - LRM and CRM

6 Conclusion

This research presents a CRM strategy. A special emphasis was placed on the practicality of an algorithm to develop a field implementable strategy. Complex mathematical models and optimisation approaches were excluded because they require comprehensive and highly reliable traffic detector data, which is often implausible in the real traffic condition. The new strategy takes the rule-based heuristic (model-free) framework with the feedback concept embedded in the multi-hierarchical structure. The strategy is simple, transparent, and less data-dependent.

The performance of the proposed strategy was evaluated in simulation against the base case, assuming no ramp metering and a LRM scenario employing the LRM algorithm based on ALINEA (M. Papageorgiou et al. 1997) plus an adaptive on-ramp queue management algorithm (Jiang et al. 2012). The simulation results revealed the following:

• The mainstream traffic flow significantly improved with the coordinated strategy. The mainline traffic delay reduced by almost 40 % over the base case scenario.

• The coordinated scenario was more effective in improving the mainline traffic flow. The mainline vehicle delay time decreased by 10.9 % with the CRM scenario over the LRM scenario.

• The improved mainstream traffic flow was achieved by more balanced utilisation of ramp spaces to store traffic queues. Although the ramp delay time increased as a result of the coordination control, the total queue spillover time was managed even better at a network level, 3 % reduction as compared with the LRM scenario; this also indicates that the strategy responds to traffic conditions quickly.