Side-lane merging in an Aimsun Next mesoscopic model

June 2022 — Technical note #70

Mohammad Saifuzzaman

Product Specialist

The mesoscopic model in Aimsun Next offers a link and lane-based simulation of individual vehicles with a simplified behavior compared to that used in microsimulation. These simplifications make it good enough to represent the driver interactions in car-following, lane-changing, and gap-acceptance while reducing the computations and thus reducing the runtime compared to its more detailed microscopic counterpart.

The mesoscopic model in Aimsun Next has been proved to produce realistic travel times in urban networks and in most freeway situations. However, when it comes to merging behavior at on-ramps, the lack of cooperative behavior sometimes poses a challenge in calibrating the congestion produced at that type of bottleneck. We have acknowledged the limitation and in Aimsun Next 20 we introduced a specific mesoscopic merging behavior model controlled by two additional parameters: cooperation gap and merging gap. This technical note aims to explain how these parameters can be used to control the merging behavior and to match the observed traffic flow and congestion.

 

Background

Reproducing the exact congestion at a side lane merging site is always challenging. It depends on the road geometry, and it is highly impacted by driver behavior; for example, in the same situation you can have a vastly different split of congestion between mainline and ramp depending on the degree of cooperation.

The microscopic version of Aimsun Next has several parameters to calibrate side lane merging behavior (e.g., cooperation, aggressiveness, cooperation distance, merging distance, and simultaneous merging options). After a detailed analysis of the real data at various side-lane merging areas, we have designed a new merging model for the mesoscopic simulation. It is controlled by two parameters, cooperation gap and merging gap.

 

Cooperation gap: It is the headway (in seconds) the mainline vehicles will be forced to have when leaving the section whenever merging vehicles are present on the ramp. This is to facilitate the incorporation of traffic. Thus, a higher degree of cooperation from the mainline traffic can be achieved by increasing the value of this parameter. The default is 0.0 sec and means no cooperation, which is the same as previous versions. Only the vehicles on the first mainline lane adjacent to the side lane will be delayed. When the cooperation gap increases, the merging flow from the side-lane should increase at the expense of more congestion on the adjacent lane on the mainline.

Merging gap: It is the minimum gap that vehicles on the side lane (on-ramp) look for to merge into the mainline. When the merging gap increases the probability of merging flow from the side-lane decreases.

These two parameters can be found in a merging section under the “Dynamic Models” tab as highlighted in Figure 1 below. Both offer additional delays to the vehicle to proceed to the next downstream section. With a trial-and-error approach, these two parameters can effectively help mimic the side-lane merging behavior in any circumstances. As the mesoscopic model does not offer a 2D visualization of individual driver behavior, priority should be given to matching the flow (and speed) on both mainline and side lane road sections.

Figure 1 Side lane merging parameters for mesoscopic simulation

In the next section, a small-scale sensitivity test has been conducted for the two parameters on a test model.

 

Test Model

A simple model of merging behavior is prepared from a network in the Sydney M4 motorway. The test site has historical traffic flow data on the side lane and mainline traffic. Therefore, the model would allow us to check the impact of different parameter values and compare those with the default value and with the observed traffic data. The following options will be tested:

  • Default values for the parameters
  • Impact of the cooperation gap
  • Impact of the merging gap
  • A set of values that match the simulated flow with the observed flow data.

The merging area on the M4 Motorway eastbound direction is shown in the Figure below. A set of data from the morning peak period (6-10 AM) of one day has been collected. The motorway carries high city-bound traffic during the morning peak period.

Figure 2: Merging area in Sydney M4 motorway Eastbound direction

Default parameters

The model with default Aimsun Next merging behavior did not allow the ramp flow to merge freely. Figure 3 below shows that the mainline flow on both upstream and downstream locations matches perfectly. However, the ramp flow is capped at around 1000 veh/hr. The default merging parameters in the mesoscopic model usually gives priority to the mainline traffic which would decrease the merging flow from the ramps as observed in the figure below. 

Figure 3: Impact of default merging parameters

Impact of cooperation gap

The cooperation gap would create an additional delay for the traffic on the first mainline lane adjacent to the side lane. It would represent a situation where vehicles on the mainline would cooperate to create a gap for the merging vehicles. When the cooperation gap increases, the merging flow from the side-lane is likely to increase. In the figure below different values of the cooperation gap have been tested.

Figure 4: Impact of cooperation gap values

It is observed from Figure 4 that the average flow over the 4hr period on the mainline upstream detector did not change by increasing the cooperation gap from 0 to 9s. However, a high cooperation gap value seems to reduce the peak flow on the upstream detector. To better understand the driver behavior of the mainline traffic with higher cooperation gaps, the simulated traffic flow plots for each lane are also presented in the above Figure 4.

It is evident that the flow on lane 1 (the nearest lane to the ramp, i.e. most impacted lane by merging traffic) has been significantly reduced with a higher cooperation gap. On the contrary, the flow on lane 3 has increased with the increase of the cooperation gap. Therefore, a clear shift in lane use has been observed in this test where a proportion of lane 1 traffic has been moved to the furthest lane from the ramp to avoid the delay caused by the merging traffic. The test result suggests that with the increase of the cooperation gap a shift of traffic from lane 1 (the adjacent lane to the side lane) to other available lanes could occur. When the other lanes do not have the capacity to hold this additional traffic, congestion would occur and propagate upstream.

 

Impact of merging gap

With the increase in merging gap value, the vehicles on the side lane are likely to wait longer to merge with the mainline traffic. When the mainline traffic volume is close to the capacity, a slight increase in the merging gap could cause a significant reduction in merging flow. In this example, a merging gap value of 2s, 4s, and 6s has been tested. The following figure displays the flow profile of the side lane traffic for different merging values. The figure shows that with a slight increase in merging gap value, the traffic flow on the ramp drops significantly. 

Figure 5: Impact of merging gap on-ramp flow

Calibration to the observed traffic flow

After some trial and error with the merging parameters, a 2s cooperation gap and 0.0s merging gap were found sufficient to match the simulated merging behavior with the observed flow on both ramp and mainline detectors.  It allowed the side-lane vehicles to easily merge with the mainline traffic without reducing the peak of the flow on the upstream detector.

The following figure shows the simulated and observed flow profile on-ramp detectors and the two mainline detectors. With the 2s cooperation gap, the mainline traffic cooperated by creating gaps for the merging movement. As a result, the side lane vehicles were able to merge freely which increased the ramp flow as shown in the figure.

Figure 6: simulated vs observed flow with calibrated side lane parameters

Concluding thoughts

Before calibrating the side lane merging parameters, you must be sure that the demand both on the mainline and on the ramp is correct.

A traffic model contains many merging areas but not all of them require a local calibration. A common value for these parameters should be first set at the road type level. Any local changes should be introduced only where a mismatch with the observed traffic flow is found, or the merging traffic is causing unexpected congestion.

When calibrating a mesoscopic model, you should focus on matching the flow (and speed) of the entire section rather than the values for individual lanes.

More technical notes

  • 有问题吗? 请联系我们。

    我们在这里提供帮助!

  • 有问题吗? 请联系我们。

    我们在这里提供帮助!

分享

引用Aimsun Next

Aimsun Next 20

Aimsun (2021). Aimsun Next 20 User's Manual, Aimsun Next Version 20.0.3, Barcelona, Spain. Accessed on: May. 1, 2021. [In software].
Available: qthelp://aimsun.com.aimsun.20.0/doc/UsersManual/Intro.html


Aimsun Next 8.4

Aimsun (2021). Aimsun Next 8.4 User's Manual, Aimsun Next Version 8.4.4, Barcelona, Spain. Accessed on: May. 1, 2021. [In software]. Available: qthelp://aimsun.com.aimsun.8.4/doc/UsersManual/Intro.html

Aimsun Next 20

@manual {​​​​​​​​AimsunManual,

title = {​​​​​​​​Aimsun Next 20 User's Manual}​​​​​​​​,

author = {​​​​​​​​Aimsun}​​​​​​​​,

edition = {​​​​​​​​​​​​​​​Aimsun Next 20.0.3}​​​​​​​​​​​​​​​,

address = {​​​​​​​​​​​​​​​Barcelona, Spain}​​​​​​​​​​​​​​​,

year = {​​​​​​​​​​​​​​​2021. [In software]}​​​​​​​​​​​​​​​,

month = {​​​​​​​​​​​​​​​Accessed on: Month, Day, Year}​​​​​​​​​​​​​​​,

url = {​​​​​​​​​​​​​​​qthelp://aimsun.com.aimsun.20.0/doc/UsersManual/Intro.html}​​​​​​​​​​​​​​​,

}​​​​​​​​​​​​​​​


Aimsun Next 8.4

@manual {​​​​​​​​AimsunManual,

title = {​​​​​​​​Aimsun Next 8.4 User's Manual}​​​​​​​​,

author = {​​​​​​​​Aimsun}​​​​​​​​,

edition = {​​​​​​​​​​​​​​​Aimsun Next 8.4.4}​​​​​​​​​​​​​​​,

address = {​​​​​​​​​​​​​​​Barcelona, Spain}​​​​​​​​​​​​​​​,

year = {​​​​​​​​​​​​​​​2021. [In software]}​​​​​​​​​​​​​​​,

month = {​​​​​​​​​​​​​​​Accessed on: Month, Day, Year}​​​​​​​​​​​​​​​,

url = {​​​​​​​​​​​​​​​qthelp://aimsun.com.aimsun.8.4/doc/UsersManual/Intro.html}​​​​​​​​​​​​​​​,

}​​​​​​​​​​​​​​​

Aimsun Next 20

TY - COMP

T1 - Aimsun Next 20 User's Manual

A1 - Aimsun

ET - Aimsun Next Version 20.0.3

Y1 - 2021

Y2 - Accessed on: Month, Day, Year

CY - Barcelona, Spain

PB - Aimsun

UR - [In software]. Available: qthelp://aimsun.com.aimsun.20.0/doc/UsersManual/Intro.html


Aimsun Next 8.4

TY - COMP

T1 - Aimsun Next 8.4 User's Manual

A1 - Aimsun

ET - Aimsun Next Version 8.4.4

Y1 - 2021

Y2 - Accessed on: Month, Day, Year

CY - Barcelona, Spain

PB - Aimsun

UR - [In software]. Available: qthelp://aimsun.com.aimsun.8.4/doc/UsersManual/Intro.html

</