Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios
Author: Flurin Weber
Supervisor: Alexander Genser
Co-Supervisor: Dr. Mehdi Keyvan-Ekbatani (University of Canterbury, New Zealand)
Professor: Dr. Anastasios Kouvelas
Master Thesis
January 2020 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Acknowledgements I would like to extend my deepest gratitude to my supervisors Alexander Genser and Dr. Anastasios Kouvelas from ETH Zürich. Without your knowledge, support and advice, be it via e-mail, Skype, or in personal conversation, I would not have been able to complete this thesis.
Furthermore, my thanks go to my co-supervisor Mehdi Keyvan-Ekbatani from University of Canterbury (New Zealand), who took the time for regular skype meetings and supported me via e-mail. I could absolutely benefit from your knowledge of perimeter control.
I also would like to thank Richard de Witt and Franziska Baumgartner from the Departement für Bau, Verkehr und Umwelt (BVU) of Kanton Aargau for the meetings and interesting inputs from a more practical point of view, as well as for providing the access to the traffic management computers. Also, my thanks are extended to Manuel Kalt, who gave me valuable inputs about different kinds of signal control logic.
i Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Master Thesis, handed in on 27th of January 2020
Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios Flurin Weber IVT ETH Zurich Stefano-Franscini-Platz 5, 8093 Zurich, Switzerland
Phone: +41 79 684 48 24 E-Mail: [email protected]
Abstract
Nowadays, congestion in urban networks is abundant. Especially in the peak hours, this can lead to large delays for individual and public transport. The Swiss city of Baden is no exception, with lots of congestion focused on a few arterials during the peak hours. Perimeter control is a common traffic management tool which aims at maximising traffic flow within a pre-defined perimeter (here the city centre) and reducing overall delays. It creates queues at gating traffic lights that hold back vehicles such as not to exceed a certain vehicle accumulation inside the perimeter. Therefore, the goal of this thesis was to simulate MFD- based perimeter control in Baden and to compare the performance with the no-control case. In theory, this leads to an overall average travel time reduction. For this purpose, a simplified microsimulation model of the city of Baden in Vissim has been developed, together with a MATLAB script that controls Vissim during the simulation over the COM interface. Two control schemes (bang-bang control and PI control) were implemented, together with several scenarios regarding the controller’s occupancy set point, supplemented by a queue management strategy. The analyses have shown that single-region perimeter control using the demand of 2015 improves the traffic situation inside the perimeter, but fails to do so for the whole network, as the amount of congestion in the city centre is not enough. Therefore, several scenarios with increased demand have been implemented and tested, delivering the same results. This is due to an inhomogeneous spatial distribution of congestion inside the perimeter. A clustering approach with homogeneously congested subclusters might perform better overall. The results should be interpreted with care, however, because several important details are missing in the Vissim model.
Keywords
Perimeter Control; Gating; MFD; PI controller; Vissim; Bang-bang control; Microsimulation; Queue management
Preferred citation style
Weber, F. (2020) Perimeter Control in the Swiss City of Baden: Evaluation of different Scenarios, Master Thesis, IVT, ETH Zurich, Zurich.
ii Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table of contents
1 Introduction and motivation ...... 12
2 Theoretical Background ...... 13
2.1 Macroscopic fundamental diagram ...... 13
2.2 Perimeter Control ...... 16
2.3 Control Strategies ...... 18
2.3.1 Bang-bang control ...... 18
2.3.2 PI and PID controllers ...... 19
2.4 Traffic Simulation Tools ...... 22
2.4.1 Macroscopic, mesoscopic and microscopic simulation ...... 22
2.4.2 PTV Vissim ...... 23
2.4.3 Car-following model ...... 23
2.4.4 Lane-changing model ...... 24
2.4.5 Stochastic variations in microsimulation ...... 26
3 Case study and research questions ...... 27
4 Existing traffic control strategy implementation ...... 29
4.1 Description of existing traffic responsive strategy ...... 29
4.2 Implementation in Vissim ...... 35
4.2.1 Conversion of the macroscopic to a microscopic model ...... 35
4.2.2 Adaptive signal control of gating traffic lights with vehicle-actuated programming 37
4.2.3 Modelling intersections ...... 39
4.2.4 Modelling the demand ...... 44
4.2.5 Combination of perimeter control with today’s traffic-responsive strategy ...... 46
4.2.6 Unrealistic vehicle behaviour in Vissim ...... 47
4.3 Traffic assignment strategies ...... 49
5 Implementation of Perimeter Control ...... 51
5.1 Conceptual Framework ...... 51
5.2 Estimation of the macroscopic fundamental diagram ...... 53
5.3 Control strategies ...... 57
iii Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5.3.1 General considerations ...... 57
5.3.2 Bang-bang control ...... 58
5.3.3 PI controller ...... 59
5.3.4 Queue management strategy ...... 69
5.4 Evaluation measures ...... 72
5.4.1 VHT ...... 73
5.4.2 VKT ...... 74
5.4.3 Average speed ...... 75
5.4.4 Total vehicle delay ...... 76
5.4.5 Delays at gates ...... 76
5.4.6 Number of stops ...... 77
5.4.7 Percentage of vehicles in a queue ...... 77
5.4.8 Maximum relative queue length ...... 78
5.4.9 Excess green time due to QM ...... 78
5.4.10 Number of vehicles served ...... 78
5.5 Structure of code ...... 78
5.6 Analysed scenarios ...... 81
6 Results and Discussion ...... 83
6.1 No control / baseline (demand = 100%) ...... 83
6.2 Comparison of the scenarios (demand = 100%) ...... 88
6.3 Comparison of BBC and PI ...... 103
6.4 Selected results of PI control (demand = 100%) ...... 104
6.5 Results of scenarios with increased demand ...... 107
6.6 Why perimeter control is not beneficial ...... 114
6.7 Evaluation of queue management strategy (demand = 100%) ...... 118
6.8 Heterogeneity of the network ...... 119
7 Conclusion and outlook ...... 120
7.1 Concluding remarks ...... 120
7.2 Further work and outlook ...... 122
iv Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
8 Bibliography ...... 125
A Appendix ...... 132
A.1 Various figures ...... 132
A.2 MFD derived from Link Evaluation data ...... 139
A.3 Results of scenario with double demand (+100%) ...... 140
v Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
List of tables Table 1: Advantages and disadvantages of perimeter control (Keyvan-Ekbatani, et al., 2012) and (SNZ Ingenieure und Planer AG, 2013) ...... 17 Table 2: Impact of changing one gain independently (University of Michigan , 2019) ...... 22 Table 3: Output of the restrictor logic (Swarco and Kanton Aargau, 2019), own table ...... 32 Table 4: Comparison of daily traffic flows (traffic counter data and Visum flows), (Kanton Aargau, 2019d) and (Kanton Aargau, 2019e) ...... 35 Table 5: Green times per approach ...... 43 Table 6: Relative inflows per gating traffic light ...... 60 Table 7: Verification of gains (random seed 3) ...... 66
Table 8: Changing Ki during simulation − results ...... 68 Table 9: Tested gains for scenarios with increased demand ...... 68 Table 10: Chosen gains for scenarios with increased demand, considering 2 replications. .... 69 Table 11: Length of queueing spaces per gating point...... 70 Table 12: Changes in green time depending on relative queue length ...... 71 Table 13: Example of the "vehicle in PN" matrix. For vehicles never entering the PN, the matrix only contains zeros...... 73 Table 14: Example of the "vehicle enter/leave PN" matrix, based on Table 13. For vehicles never entering the PN, the matrix only contains zeros. The results are always recorded at the end of a time step...... 73 Table 15: Calculation of VHT, sample table ...... 74 Table 16: Critical occupancy per scenario ...... 81 Table 17: Summary of results (with QM), averages of 6 replications. Most important indicators in bold...... 89 Table 18: Results with increased demand (+30%), averages of 3 replications ...... 107 Table 19: Results with increased demand (+70%), averages of 3 replications ...... 108 Table 20: Evaluation of queue management strategy (ô = 32%), average of 6 replications .. 118 Table 21: Results with increased demand (+100%) ...... 140
vi Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
List of figures
Figure 1: Idealised MFD (Keyvan-Ekbatani, et al., 2015a), own figure ...... 14 Figure 2: Basic principle of gating (Keyvan-Ekbatani, et al., 2012) ...... 17 Figure 3: General setup of a PID controller (University of Michigan , 2019), own figure ..... 21 Figure 4: Sketch of the car-following model (PTV, 2018) ...... 24 Figure 5: Study area (green) with important arterials (blue), (Swiss Confederation, 2019), own figure ...... 27 Figure 6: Three subregions relevant for the existing traffic-responsive strategy. TG=Teilgebiet (SNZ Ingenieure und Planer AG, 2013) ...... 29 Figure 7: Map of intersection 373 (Landstrasse) (Swarco and Kanton Aargau, 2019)...... 33 Figure 8: Intersection 373 together with neighboring intersections. Red rectangles are traffic jam detectors (Erb+Partner AG & Marty+Partner AG, 2017) ...... 33 Figure 9: Intersection 373 with neighboring intersections (Swiss Confederation, 2019), own figure...... 34 Figure 10: Excerpt from the restrictor logic for intersection 373 (Swarco and Kanton Aargau, 2019) ...... 34 Figure 11: Graph of the Vissim network. Nodes are the blue circles, links are the red lines. . 37 Figure 12: Necessary input files for VAP. Source: (PTV, 2017) ...... 38 Figure 13: Traffic-actuated control logic of intersection 314 in VisVAP ...... 39 Figure 14: Conflict areas at Schulhausplatz ...... 41 Figure 15: Screenshot from the RVR. The circles in blue denote the coordinated traffic lights, the arrows in yellow the path for which coordination was implemented and the red ellipses the coordinated traffic lights in reality (Swarco and Kanton Aargau, 2019) ...... 42 Figure 16: Signal program for intersection 388 (Haselstrasse) in Vissig ...... 43 Figure 17: All modelled traffic lights within the PN. Source: (Swiss Confederation, 2019), own figure ...... 44 Figure 18: Demand pattern. 100% corresponds to around 23’000 veh/h...... 45 Figure 19: Demand pattern for scenarios with increased demand. 100% corresponds to around 23’000 veh/h...... 46 Figure 20: Perimeter control in combination with existing strategy ...... 47 Figure 21: Screenshot at intersection 312 (Schulhausplatz) ...... 48 Figure 22: Blocking gating intersection 314 (Kloster)...... 49 Figure 23: Defined perimeter (red) with gating traffic lights. Source: (Swiss Confederation, 2019), own figure ...... 52 Figure 24: Map of all 739 data collection points (top) and of the 20% most congested detectors (bottom). Links in red, detectors in blue...... 56 Figure 25: Fixed and adaptive cycle length ...... 58
vii Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 26: Structure of PI controller used in this thesis. Source: (University of Michigan , 2019), own figure ...... 59
Figure 27: Left: Plot of o(k) – o(k–1) over time (relevant for Kp). Right: Plot of ô –o(k) over time (relevant for Ki) ...... 62
Figure 28: Time series of Kp (o(k) – o(k–1)) + Ki (ô – o(k)) with Kp = 1100 and Ki = 360 ... 62
Figure 29: Inflow into PN with too large Ki (Ki = 2060) ...... 64
Figure 30: Ordered vs actual flow at the gates with too large Ki (Ki = 2060) ...... 64 Figure 31: Long simulations with 3 hours of peak demand. Plots of occupancy in the PN over time. Red line = set point of 31%. Here, one time step equals 90s...... 65
Figure 32: Comparison of gains. Left: Ki=350, right: Ki=1950. Note the different scaling of the y-axes...... 67 Figure 33: Settings of queue counters ...... 70 Figure 34: Structure of MATLAB code. Left branch: BBC, right branch: PI ...... 80 Figure 35: MFD (20% most congested det.) for baseline. 13 replications...... 84 Figure 36: MFD for all detectors. 13 replications...... 84 Figure 37: Number of vehicles over time. 13 replications. Note that the simulation time was later increased to 4h, to allow the network to clear entirely...... 85 Figure 38: Occupancy over time inside PN, for 20% most congested detectors. Data from 6 replications...... 86 Figure 39: Queue length at gates in the baseline. Average of 6 replications...... 87 Figure 40: Inflow into PN, baseline / no control. Average of 6 replications...... 87 Figure 41: Relative differences, baseline=1. VHT, avg. speed and vehicle delay ...... 90 Figure 42: Relative differences, baseline=1. Delays at gates and max. rel. queue length ...... 90 Figure 43: Production MFDs for the Barcelona network. Left: whole network, right: 4 subregions. Source: (Kouvelas, et al., 2017) ...... 91 Figure 44: Green splits of gating traffic lights for PI controller (above) and BBC (below), scenario “best trade-off”. For grey areas, the controller is inactive (and hence, the green split is 1)...... 93 Figure 45: Inflow into the protected network. PI (top): Output of controller (solid line) and as measured by data collection points at gates (dotted). BBC (bottom): as measured by data collection points at gates. Average of 6 replications ...... 95 Figure 46: Number of vehicles in the whole network. Average of 6 replications ...... 96 Figure 47: Time series of occupancy inside PN (from 20% most cong. det.), for BBC and PI ...... 97 Figure 48: MFD with no control and the three scenarios of BBC (top) and PI (bottom). Averages of 6 replications. Data from first 2 hours...... 98
viii Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 49: Speed-MFD with baseline and the three scenarios of BBC (top) and PI (bottom). Average of 6 replications ...... 100 Figure 50: Speed over time, for all scenarios and both control algorithms. Whole network, average of 4 replications ...... 102 Figure 51: Speed over time, for all scenarios and both control algorithms. Only in PN, average of 3 replications ...... 103 Figure 52: Time series of occupancy for PI, max. flow in PN ...... 104 Figure 53: MFD (20% most cong. det.), PI, max. flow in PN ...... 105 Figure 54: Ordered and actual flow for the three scenarios ...... 106 Figure 55: Occupancy over time of the 4 scenarios. Averages of 3 replications...... 110 Figure 56: MFDs for the 4 scenarios, containing data of the first 180 simulation minutes. Averages of 3 replications...... 111 Figure 57: Average speed (whole network). Average of 3 replications. Note that the sudden end of a line is due to an empty network...... 112 Figure 58: Average speed (inside PN). Average of 4 replications. Note that the sudden end of a line is due to an empty network...... 113 Figure 59: Number of vehicles over time. Averages of 3 replications...... 114 Figure 60: Map showing vehicle flows (in red), congested areas of baseline (in blue), and perimeter (in green). North is to the left...... 116 Figure 61: Variance of occupancy, random seed 2, demand = 100% ...... 117 Figure 62: Relation between occupancy standard deviation and production (average from 6 replications), demand =100% ...... 119 Figure 63: Possible smaller PN containing only the city centre. Source: (Swiss Confederation, 2019), own figure...... 124 Figure 64: Lane changing behaviour in Vissim ...... 132 Figure 65: Planned measures in Baden in scope of OASE. Source: (Kanton Aargau, 2019b) ...... 133 Figure 66: Scheme of the cascade relevant for axes Bruggerstrasse/Siggenthal. Source: (SNZ Ingenieure und Planer AG, 2013). Unfortunately, the original file does not offer a higher resolution...... 134 Figure 67: Decision tree structure used to find the optimal gains ...... 135 Figure 68: MFD for baseline and BBC, full 4 hours including offset of congestion ...... 136 Figure 69: MFD for baseline and PI, full 4 hours including offset of congestion ...... 136 Figure 70: Speeds as obtained by loop detectors. BBC (left), PI controller (right) ...... 137 Figure 71: MFDs of scenarios with increased demand including offset of congestion ...... 138 Figure 72: MFD obtained from Link Evaluation Data (grey: offset of congestion), one replication...... 140
ix Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
List of abbreviations 3D MFD Three-dimensional MFD
ANM Abstract Network Model
BVU Department für Bau, Verkehr und Umwelt
BVUATB Department für Bau, Verkehr und Umwelt – Abteilung Tiefbau (government authority of Kanton Aargau responsible for traffic management)
COM Component Object Model
DLC Discretionary Lane Change
DTA Dynamic Traffic Assignment
FESA Flexibel, Erweiterbar, Systemunabhängig, Anpassungsfähig
MATLAB Matrix Laboratory
MFD Macroscopic Fundamental Diagram
MLC Mandatory Lane Change
MPC Model Predictive Control
OASE Ostaargauische Strassenentwicklung
OD Origin-Destination
OPAC Optimised Policies for Adaptive Control
PI Proportional, Integral
PID Proportional, Integral, Derivative
PN Protected Network
QM Queue Management
RBC Ring Barrier Controller
RHODES RealTime Hierarchical Optimised Distributed Effective System
RVR Regionaler Verkehrsrechner
x Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
SCATS Sydney Coordinated Adaptive Traffic System
SCOOT Split Cycle and Offset Optimisation Technique
Siemens VA Siemens “verkehrsabhängig” (“traffic-dependent”)
VHT Vehicle Hours Travelled
Vissim Verkehr in Städten – Simulation
Visum Verkehr in Städten – Umlegung
VKT Vehicle Kilometres Travelled
VS-PLUS Verkehrssysteme Plus
xi Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
1 Introduction and motivation
The city of Baden is located in the Swiss canton of Aargau, around 20 km northwest of Zurich and has 19’200 inhabitants (Stadt Baden, 2020). Baden forms a continuous settlement area together with the municipalities of Ennetbaden, Neuenhof, Obersiggenthal, and Wettingen. The city centre of Baden can be termed as the centre of this settlement area. On a larger scale, it is one of the cores of the agglomeration Baden-Brugg, which encompasses 15 municipalities in the canton of Aargau with a total of 105’000 inhabitants (Kramer, 2015). This significant function as a centre makes Baden’s main arterials heavily congested by individual traffic, especially during peak hours. The actual core of Baden’s arterial road network is Hochbrücke with the two intersections Brückenkopf Ost and Schulhausplatz. At the latter, roads from all cardinal directions meet. It is one of the squares with the most traffic in whole of Switzerland and has recently been renovated to increase its attractiveness (Kanton Aargau, 2019a). In 2013, a new innovative traffic management system for the area Baden- Wettingen has been introduced, featuring traffic lights at specified gating locations at the city borders, with their purpose being to prevent too many vehicles from entering the city centre (SNZ Ingenieure und Planer AG, 2013). Furthermore, plenty of loop detectors have been placed in the city centre, collecting vast amounts of traffic data. This new system performs well in practice, but coordinates approaches to the city centre locally, not in a centralised way. Also, it is not based on the quite recent theory of the existence of a macroscopic fundamental diagram (MFD). The responsible authorities expect a potential for improvement if an MFD- based perimeter control system were to be introduced. This thesis shall therefore examine the potential benefits of several MFD-based perimeter control scenarios and compare them with today’s situation, using microsimulation tools. This is an essential step to prove the system’s performance before a real-world implementation of such a novel system can take place. To the author’s knowledge, there is as of now no real-world implementation anywhere in the world of an MFD-based perimeter control system. This thesis is organised as follows: Section 2 will begin by giving an overview of the most important theoretical concepts in the field of perimeter control. Section 3 will present the research goals, followed by an explanation of the current traffic management system in Section 4. Section 5 will deliver an in-detail overview of the practical implementation of perimeter control in microsimulation, and Section 6 will present and discuss the results. The thesis is finished with a conclusion and outlook in Section 7.
12 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
2 Theoretical Background
2.1 Macroscopic fundamental diagram
Greenshield proposed the existence of a fundamental diagram relating link density and flows (Greenshield, 1935), but the existence and general physical model of an MFD have only been proposed by (Godfrey, 1969). The MFD was later empirically verified and described by (Geroliminis & Daganzo, 2007) and (Geroliminis & Daganzo, 2008). An MFD is a relationship between average network traffic flow and average network density in an urban road network (Keyvan-Ekbatani, 2018). In order to achieve an MFD with low scatter following a well-defined curve, several regularity conditions must be met. These are, from (Geroliminis, 2019) and (Ambühl, 2018):
• Slow-varying and distributed demand • Homogenous spatial distribution of congestion • Redundancy of the network (meaning that every pair of points is connected by several route alternatives) Heterogenous networks, where congestion is unevenly distributed in space or the variance of link densities is high, often do not have a well-defined MFD. Especially in the descending branch of the MFD, there will be a significant amount of scatter, and furthermore, hysteresis phenomena to be found (Geroliminis & Sun, 2011). Because networks are never ideally homogenous, an empirical MFD (obtained through measurements) is always under the upper theoretical bound, which represents the “ideal” MFD, as has been examined in the literature, i.e. (Knoop, et al., 2012) or (Geroliminis & Sun, 2011).
To achieve a homogenous spatial distribution of congestion and reduce the amount of scatter, a city can be divided into homogeneously congested subregions, which have a small variance in link densities (Ji, et al., 2014). For each of those clusters, a separate MFD can be defined. Such clustering is useful because of the notion that traffic conditions in one road are spatially correlated with adjacent roads, and congestion propagates to adjacent links (Kouvelas, et al., 2017). Clustering algorithms such as the “Snake” algorithm can help clustering a road network (Geroliminis, 2019) by considering a heterogeneity index as the objective function to be minimized (Kouvelas, et al., 2017). Clusters should be compact in shape and should contain links that have similar densities and that experience the onset of congestion at similar times (Geroliminis, 2019). Figure 1 shows an idealised MFD. The MFD looks similar in shape to its link-based counterpart, the fundamental diagram (Loder, et al., 2017): It also has an ascending (uncongested) and descending (congested) branch. The MFD presented here links network
13 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
vehicle density (veh/km) with network (out-)flow (veh/h). Note that the MFD can also link accumulation (number of vehicles in the region) with production or trip completion flow (Haddad & Shraiber, 2014), with the difference being the weighting by link length. In the uncongested branch, the average network flow increases with average network density until reaching the critical density 푘crit, which is where maximum average flow 푞max occurs and where a road network should ideally be operated (Ambühl, 2018). Hence, it distinguishes between four traffic states: free flow, saturated conditions, over-saturated conditions and full gridlock (Keyvan-Ekbatani, et al., 2015a). Gridlock occurs at jam density 푘jam, at zero flow (Ambühl, 2018). Various studies have shown the existence of empirical MFDs in different cities around the world, for example Yokohama (Geroliminis & Daganzo, 2008), Shenzhen (Ji, et al., 2014) and Zurich (Ambühl, et al., 2017a). Empirical MFDs can be obtained by loop detector data and floating car data, with both methods having their advantages and disadvantages. The drawback of an MFD based on loop detector data is that its shape depends on the spatial distribution of the loop detectors within the link or the whole network (Loder, et al., 2017). On the other hand, an MFD based on floating car data depends on the spatial distribution of the probe vehicles in the network (Du, et al., 2016). Furthermore, probe vehicles (i.e. taxis) might not be a representative subset of the whole vehicle fleet, as shown in (Geroliminis & Daganzo, 2008). One possibility to reduce those drawbacks is the use of data fusion techniques such as shown in (Ambühl, et al., 2017a) or (Ambühl & Menendez, 2016), which are able to combine data, and the advantages of the different types of data, for MFD generation. This might lead to more reliable and/or realistic MFDs.
Figure 1: Idealised MFD (Keyvan-Ekbatani, et al., 2015a), own figure
14 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
As an MFD contains aggregated information on a network level, it is a very useful tool in traffic management and control since it avoids the necessity of modelling every single element in a large-scale network, as shown in (Haddad & Geroliminis, 2012) and (Aboudolas & Geroliminis, 2013). Thereby, mobility in urban networks can be improved and delays reduced (Haddad & Shraiber, 2014). Furthermore, it allows centralised control: It has been shown that decentralised control is inefficient in congested large-scale urban systems. This is since having a local optimum at every link, as achieved by decentralised control, does not directly imply that the whole system operates at its optimum (Keyvan-Ekbatani, et al., 2015b). Using an MFD, the entire system can be controlled in a coordinated way (Geroliminis, 2019). Such an approach is called perimeter control or gating and is described in Section 2.2. Other purposes or use-cases of the MFD include the impact of network topology on traffic performance, for example in (Knoop, et al., 2014) and in (Ortigosa, et al., 2015), or the effects of systems such as parking, for example in (Leclercq, et al., 2017) or (Geroliminis, 2015). The MFD was also used to evaluate the effects of cordon pricing (Zheng, et al., 2012). One more interesting and important property of an MFD is that it is theoretically independent of demand, meaning that for a traffic control scheme based on the MFD, there is no need to regularly identify the current demand patterns. Other traffic control schemes, such as ZuriTraffic which is used in Zurich, are not MFD-based but are based on level-of-service measurements on links in the city centre of Zurich instead (Ortigosa, et al., 2014). In such cases, the underlying static demand model needs to be updated due to changes in demand. Such control systems also differentiate only between two traffic states (congested and uncongested), while MFD-based control does not require such a binary system (Ortigosa, et al., 2014).
Recent MFD-related research has introduced multidimensional MFDs, mostly in order to include public transport. With a three-dimensional MFD (3D MFD), for instance, bi-modal traffic such as cars and buses can be represented. In those MFDs, the x- and y-axes represent the densities of the two modes, while the z-axis represents the total flow of the two modes (Loder, et al., 2017). As with standard MFDs, the x- and y-axis can also here stand for accumulation or occupancy instead of density, and the z-axis can stand for production. The 3D MFD can become relevant for perimeter control when the microsimulation model includes public transport vehicles (i.e. buses) (Dakic, 2018). If bus lanes are existing, for example, then the perimeter control for buses can be executed separately from perimeter control for cars (bi- modal control). Therefore, a 3D MFD can be used to quantify interactions between buses and cars and therefore be helpful for the design of multimodal transport networks (Dakic, 2018).
15 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
It is also possible to fit a functional form to an empirical MFD. Mainly the approach developed by (Ambühl, et al., 2018) will be mentioned here. They have formulated a minimisation problem delivering a parameter λ describing the form of the MFD curve. The functional form is thereby based on a smooth approximation of an MFD that is described as “upper bound of technologically feasible traffic states”. This method allows an exact specification for the critical occupancy or density, using the function curve’s highest point. This was not necessary in this work, because of disturbances caused by internal inflows and time delays of the flow entering the protected network until reaching the centre. These factors cause the critical occupancy to remain an approximation of the “true” value. Fitting a functional form to the MFD cannot alleviate this problem.
2.2 Perimeter Control
Several control strategies such as Split Cycle and Offset Optimisation Technique (SCOOT) and Sydney Coordinated Adaptive Traffic System (SCATS) are widely used in large-scale urban networks but do not perform as efficiently in saturated traffic conditions (Keyvan- Ekbatani, et al., 2012). Other, more complex traffic-responsive strategies such as Optimised Policies for Adaptive Control (OPAC) or RealTime Hierarchical Optimised Distributed Effective System (RHODES) are not suitable for (real-time) implementation in a large-scale urban network, since they are based on optimisation algorithms with exponential complexity (Keyvan-Ekbatani, et al., 2012). Therefore, real-time operation is a challenge. Perimeter control is one of the approaches to introduce a system in urban traffic control that performs well in real-time in saturated traffic conditions in a large urban network (Haddad & Geroliminis, 2012). Perimeter control strategies can help solve problems caused by oversaturated urban networks. MFD-based perimeter control has been examined for single-region cities, i.e. in (Keyvan- Ekbatani, et al., 2012) and for multi-region cities, i.e. in (Haddad & Geroliminis, 2012) and (Geroliminis, et al., 2013). The principle of gating or perimeter control consists of a so-called protected network (PN) that should at no point in time reach the over-saturated or descending branch of its MFD (or several MFDs, if the protected network has been subdivided into clusters), in order to avoid spillbacks and gridlocks (Keyvan-Ekbatani, et al., 2012). Because of this, if properly implemented, gating will increase the exit flow of the protected network. For that purpose, links leading to the protected network must be equipped with traffic lights at certain locations, that can hold back traffic and reduce network inflow, if needed. This will lead to queues and vehicle delays at the gating locations, but they will, in theory, be compensated by the higher exit flow (Keyvan-Ekbatani, et al., 2012).
16 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 2 shows the principle of gating. The flow being allowed to pass the gating location is called gated flow (푞g), of which a part (boundary flow, 푞b) may not enter the PN but continue in another direction. The inflow into the PN is denoted 푞in. However, there are other inflows into the PN, either non-gated or internal. These represent disturbances and are denoted 푞d.
Lastly, 푞out stands for the PN exit flow. If the number of vehicles 푁 inside the PN grows past a certain point, and the network reaches the oversaturated stage in Figure 2, 푞out will decrease because of spillbacks or, eventually, gridlocks. To avoid this so-called degradation of the network, perimeter control must reduce 푞in appropriately. The resulting delays at the gating points will, however, be smaller than the time saved due to larger PN exit flows, which is the main reason why the concept of perimeter control works. Perimeter control will overall be beneficial if the saved delays in the protected network are larger than its side-effects: the delays experienced by 푞b (Keyvan-Ekbatani, et al., 2012). Note that perimeter control works best if congestion is homogeneously distributed inside the PN, such that the PN has a well- defined MFD (Ortigosa, et al., 2014). If this is not the case, clustering is needed. A selection of advantages and disadvantages of perimeter control is listed in Table 1.
Figure 2: Basic principle of gating (Keyvan-Ekbatani, et al., 2012)
Table 1: Advantages and disadvantages of perimeter control (Keyvan-Ekbatani, et al., 2012) and (SNZ Ingenieure und Planer AG, 2013)
Advantages Disadvantages • Fewer emissions (noise, pollutants) in • Queues at city borders might be undesired the city centre → higher attractivity by nearby residents • Fewer queues in the city centre → • Perimeter control might be considered as higher attractivity unfair by drivers, in general, but especially • Queues at city border are more desirable for boundary flows than in the centre from an urban • Only advantageous when enough planning perspective congestion is present • Less VHT overall • Congestion must be homogeneously distributed in the network
17 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
In terms of algorithms, the control problem can be solved using 2 different methods:
• Model Predictive Control (MPC) approach, i.e. in (Geroliminis, et al., 2013) and (Haddad & Shraiber, 2014)
• Classical feedback control approach, i.e. in (Keyvan-Ekbatani, et al., 2012) and (Aboudolas & Geroliminis, 2013) When using the MPC approach, a prediction of the near-future demand is required. For the classical feedback control approach, demand prediction is not necessary, which could be advantageous in real-time situations (Haddad & Shraiber, 2014). For this reason, this thesis will design a feedback controller using the classical approach. For perimeter control, the area to be protected from excessive congestion, as well as locations for the mentioned traffic lights, must be defined in cooperation with the relevant authorities. The result of this is shown in Section 5.1. Perimeter control might cause queues at the gated intersections. In the literature, there are – generally speaking – two distinct approaches on how to handle these queues:
• Ignoring the effects of the queues at the gated intersections (such as spillbacks and blockages) while focusing on achieving a maximal vehicle throughput in the PN, such as in (Haddad & Shraiber, 2014) or (Keyvan-Ekbatani, et al., 2012). • Including the queues in the model with a queue management (QM) strategy, such as in (Keyvan-Ekbatani, et al., 2016) or (Keyvan-Ekbatani, et al., 2015b). This thesis will have a perspective of the whole network and not only of the PN, in order to potentially contribute to a real-world implementation of perimeter control in Baden. Therefore, a QM strategy will be included in the model.
2.3 Control Strategies
2.3.1 Bang-bang control
A very simple control tool is the so-called bang-bang control (BBC). It is based on the fundamental idea to allow as many vehicles as possible to enter the network while preventing the density or accumulation of vehicles to reach values corresponding to the descending branch of the MFD. Specifically, whenever the network currently is operating in the uncongested state (o(푘) < ô), all vehicles arriving at the gating locations can immediately enter the network, where o(푘) stands for the occupancy at the (discrete) time step 푘 and ô
18 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
denotes the set point of occupancy. This maximum inflow is denoted by 푞max. As soon as the current occupancy exceeds the critical occupancy and the congested state is reached (o(푘)
ô), only a pre-defined minimum flow of vehicles 푞min can enter the PN. This approach works well when the network has slow dynamics but causes an oscillatory behaviour between the two extremes of maximum and minimum inflow (Aboudolas & Geroliminis, 2013). The formula is taken from (Aboudolas & Geroliminis, 2013) and has been slightly modified:
푞max if o(푘) < ô, 푞in(푘) = { (1) 푞min otherwise.
Note that some works in the literature, also (Aboudolas & Geroliminis, 2013), use accumulation or density instead of occupancy as the relevant measure for perimeter control. These measures are not equal: a conversion from occupancy to density requires assumptions of the average vehicle length and detector length as well as the number of lanes per link. A conversion from density to accumulation requires weighting with link lengths (Kouvelas, 2018c). This controller has first been used by (Daganzo, 2007). He suggested not a minimum inflow when the critical density is exceeded, but an inflow of zero, which is hardly feasible in practice. The data requirements of BBC in terms of road infrastructure are the same as those of a PI controller, which is presented in the next section. Bang-bang control, as the name already alludes to, leads to an oscillation of occupancy/density around the set point, as well as to a strong oscillation of inflows into the PN. However, as there is a large range of average occupancy values for which average flow is maximised (i.e. 17-23%, refer to Figure 35), due to the MFD’s rather flat top, the oscillation does not necessarily make the system leave the area around the capacity flow (Keyvan-Ekbatani, et al., 2012). In any case, the large oscillations of PN inflows naturally result in large oscillations in green phase length at the gating traffic lights. This erratic behaviour may be undesired by the drivers or the relevant authorities or municipalities (Keyvan-Ekbatani, et al., 2012), and can lead to unstable traffic flows. The PI controller, as presented in the next section, delivers a much smoother control behaviour.
2.3.2 PI and PID controllers
A PID controller is a standard feedback controller widely used in all fields of engineering. PID is an acronym for proportional, integral, derivative. Figure 3 shows the general idea of feedback control using PID. The set point is the value where the system is operating ideally. The PID controller uses this set point together with a measured process variable, which is a
19 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
measurement of the current system state obtained by sensors. The difference between the measured process variable and the set point is called “error term”, and it triggers the controller to calculate in real-time an output which serves as a new input for the process (University of Michigan , 2019). The task of the controller is to minimise the error term. Note that there are disturbances that affect the process which cannot be directly measured. Their effects are only indirectly measured by the sensors and fed back to the controller. The result of the process is the process variable (Control Solutions Minnesota, 2019). This very general explanation will now be transferred to the process relevant in this thesis. Note that this thesis uses a proportional-integral (PI) controller, which is a simplification of the more universal PID controller without a derivative term. The PI controller is more frequently used than a complete PID controller (Brigham Young University, 2017). The set point in this work is the critical occupancy of the traffic network, which is obtained from the simulated MFD. The sensors are loop detectors, which are called “Data Collection Points” in Vissim. They are distributed all over the PN, measuring the current occupancy, aggregating the measurements and feeding them to the controller. Using the difference between the critical and current occupancy (error term), the PI controller calculates the inflow into the PN, which is then divided between all gating traffic lights (see Section 5.3.3), and then converted to the green times of the gating traffic lights. The “process” in Figure 3 is the simulation in Vissim, which is underlying disturbances such as uncontrolled inflows from within the PN. The same control loop can be applied to real-life conditions, if Vissim is replaced with the actual infrastructure of a city. Note that many studies from the field of Traffic Engineering so far have successfully applied a PI controller for perimeter control in urban regions, i.e. (Keyvan-Ekbatani, et al., 2012), and therefore this thesis will use a PI controller as well. A PI controller is a PID controller with the derivative term 퐾푑 = 0 (refer to Equation 2). Standard PI controllers may not be robust to modelling errors, as they rely on exact knowledge of the MFD and the set point (Kouvelas, et al., 2017). (Haddad & Shraiber, 2014) has therefore applied a robust perimeter controller which uses an uncertainty linear model. The PI controller then stabilises the system against uncertainties. This is not relevant in this thesis, due to reasons mentioned in Section 6.6. The issue concerning the inhomogeneity of congestion in the PN must be solved before applying these advanced techniques.
20 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 3: General setup of a PID controller (University of Michigan , 2019), own figure The output of a PID controller is calculated from the error term as follows (University of Michigan , 2019):
푑푒(푡) 푢(푡) = 퐾 푒(푡) + 퐾 ∫ 푒(푡)푑푡 + 퐾 , (2) 푃 푖 푑 푑푡 where 푢(푡) denotes the controller signal, 푒(푡) denotes the error term that shall be minimised, and 퐾푃, 퐾푖, 퐾푑 are called proportional, integral and derivative gains, respectively, and are constants. Note that equation 2 is in continuous time (denoted with 푡), but this thesis will work with a discrete time step 푘. The gains’ values need to be fixed beforehand, and each of those three constants has a different effect on the behaviour of the controller. One option to get suitable values for 퐾푃, 퐾푖 and 퐾푑 is by using the Laplace transform of the governing equation of the system in the time domain to obtain the so-called transfer function in the frequency domain. The transfer function can then be used as an input for PID tuners, which are toolboxes in programming environments such as MATLAB to easily retrieve fitting values for the gains (University of Michigan , 2019). However, this approach cannot be used for this thesis, because the governing equation that represents the system’s behaviour is the microsimulation in Vissim. Its behaviour is inherently complex and cannot be represented in one single equation. Therefore, a data-based approach will be used that analyses the system output, meaning that measured occupancy values from the simulation will be examined, as explained in Section 5.3.3. Table 2 shows the influence of the gains on the controller behaviour.
In order to have closed-loop stability of the system, there are a few important points to consider. According to the Jury-Blanchard criterion, if 퐾푖 > 0, the system can be stabilised even if 퐾푃 = 0, which leads to an I-type controller. This makes the fine-tuning of the gains easier. This approach works well if there is no time-delay in the process (i.e. gating applied directly at the PN border). However, when gating is applied further upstream from the PN,
21 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
then 퐾푃 becomes more relevant for the controller. If one sets 퐾푖 = 0, and only uses a P-type controller, then there will be a steady-state error, meaning that the set point may never be reached (Keyvan-Ekbatani, et al., 2012).
Table 2: Impact of changing one gain independently (University of Michigan , 2019)
Rise time Overshoots Settling time Steady-state error 퐾푃 decrease increase minor change decrease 퐾푖 decrease increase increase eliminate 퐾푑 minor change decrease decrease no effect
2.4 Traffic Simulation Tools
2.4.1 Macroscopic, mesoscopic and microscopic simulation
Most scientific studies differentiate between three forms of traffic simulation: macroscopic, mesoscopic and microscopic simulation. The advantages and disadvantages of each type will now be briefly analysed. Those types differ mostly in their level of abstraction, their degree of detail and computation time, and can be described as follows (from (Bienzeisler, 2013) and (Kouvelas, 2018b)):
• Macroscopic: This approach is based on the Lighthill-Whitham-Richards model, which stems from the field of fluid mechanics (Richards, 1956). Vehicles are modelled as a continuous stream, for which traffic flow, traffic density and mean speed can be formulated, much like for a liquid. This means that individual vehicles with individual characteristics are not represented in the model. This approach is mostly used for large-scale networks, thanks to the relatively low computation time. Furthermore, it is relevant for classical transport planning problems such as the evaluation of new policies such as road pricing or the increase of parking fees, as well as the effects of changes in infrastructure. One example of a commercial software package is PTV Visum. • Mesoscopic: Mesoscopic simulations are a combination of macroscopic and microscopic modelling and try to make use of the advantages of both types. They feature vehicle platoons which move through the network and have similar characteristics. Those models are still computationally efficient and can represent different vehicle types. However, vehicle interactions are not considered. • Microscopic: As opposed to macroscopic simulation, with the microscopic approach every single vehicle is modelled in detail. Every vehicle has individual parameters such as desired speed, lane-changing behaviour or route. The interactions between the
22 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
vehicles are represented using car-following and lane-changing models. This models the transport network in great level of detail, from which high computational effort follows. Also, the infrastructure (roads, traffic lights, etc.) as well as the demand must be modelled in large detail to achieve realistic output. Therefore, this technique is usually used for small-scale networks. The purpose of such models is mostly traffic management and control, such as evaluating the effect of changing speed limits or perimeter control. Microscopic simulation software includes Vissim by PTV AG, and Aimsun by Siemens. This is the type used in this thesis.
2.4.2 PTV Vissim This section briefly describes the theory behind Vissim (standing for “Verkehr in Städten – Simulation”, translating to “Traffic in cities – simulation”), the microsimulation program used for this thesis. Vissim can model multimodal transport, for example cars, lorries, buses, trams, pedestrians and bicycles. Vissim has been and is being developed by the German company PTV AG since 1992. It is the leading microsimulation tool used in German speaking countries (Bienzeisler, 2013). On a global scale, its most significant competitor is Aimsun. The simulation results strongly depend on how the behaviour of the individual agents is modelled, so much that the next subsection will shortly present the car-following model and lane- changing model underlying the simulation (Bienzeisler, 2013), (PTV, 2018). Vissim features the COM (component object model) interface. This is an interface between Vissim and a large array of programming languages such as C++, Visual Basic, Python or MATLAB. This allows writing scripts that interact with the simulation during the simulation run, which is otherwise not possible. This thesis uses MATLAB.
2.4.3 Car-following model
The general idea of car-following models is that the behaviour of the following vehicle only depends on the behaviour of the leading vehicle. In general, the response of a vehicle to the leading vehicle can be formalised as follows (Keyvan-Ekbatani, 2018):
푅(푡 + 푇) = 휆 ∗ 푠(푡), (3) where 푅(푡 + 푇) denotes the response at time 푡 + 푇, 휆 is the sensitivity and 푠(푡) stands for the stimulus at time 푡. This model includes the notion that drivers have a lag time of response 푇. For instance, the stimulus may be the difference in speed between two successive vehicles, the sensitivity may be the strength of the response and the response can be the rate of braking (Keyvan-Ekbatani, 2018).
23 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Vissim uses the perception model developed by (Wiedemann, 1974). Figure 4 shows the general concept of this specific car-following model. The black line is the trajectory of a certain vehicle. It is, in the beginning, moving faster than a car further downstream, reducing the headway of the leading vehicle 푑 (area 1). The speed difference between the two vehicles is denoted ∆푣. When the faster vehicle approaches the slower-moving leading vehicle, it slowly starts decelerating (3). The speed of the following vehicle then oscillates around the speed of the leading vehicle (2). This is because the driver of the following vehicle cannot exactly measure or estimate the speed of its leading vehicle. This means that there are slow but continuous deceleration and acceleration. The upper border of (4) denotes the minimum headway between the vehicles, below which the following vehicle does not want to fall. It is possible to model individual driver behaviour with individual desired speeds, individual maximum deceleration and acceleration and individual desired distance to the leader. Those variables are described by normal distributions (PTV, 2018). The car-following model has been calibrated by measurements performed by the Karlsruhe Institute of Technology. Car- following models have been researched extensively (Keyvan-Ekbatani, 2018).
Figure 4: Sketch of the car-following model (PTV, 2018)
2.4.4 Lane-changing model
Significantly less research has been conducted on lane-changing models than on car-following models. Nevertheless, lane changing is an important part of vehicle behaviour, and is relevant for effects on safety and traffic breakdowns. Refer to Section 4.2.6 for the relevance of this
24 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
topic in this thesis. Despite the contribution of research for a better understanding of lane changing in recent years, Vissim still uses a simple rule-based model originally designed by U. Sparmann in 1978 (Sparmann, 1978). As mentioned by (PTV, 2018) and (Gao, 2008), he investigated lane-changing behaviour on a two-lane motorway in Germany and categorised lane changing behaviour into changing to a slower- or faster-moving lane. According to (Moridpour & Rose, 2010), lane changing is a significant component in microsimulations of traffic. In fact, it is the main reason for oscillations in speed or flow, even more so than car-following behaviour. Also, lane changing can contribute to the capacity drop on highways. This makes the topic relevant to be briefly explained. Since the first works on this topic, lane changing has been divided into two groups that differ in the motivation to execute a lane change. Mandatory lane changes (MLC) happen because of an incident, a lane drop, or because a vehicle is about to enter the off-ramp of a motorway. Discretionary lane changes (DLC) encompass lane changes due to a driver wanting to travel at a different (usually higher) speed (Ramanujam, 2007). Vissim’s lane change model, as mentioned above, is based on three hierarchical questions that are evaluated (Gao, 2008):
• Does the driver desire to change lane? • Are driving conditions improved by changing to the adjacent lane? • Is it feasible to safely perform the lane change? Vissim includes these two types of lane changes but renames them to “necessary lane change” (corresponding to MLC) and “free lane change” (corresponding to DLC). There is a multitude of parameters that can be set to model lane change in Vissim, and they are shown in Figure 64 in Appendix A.1, and further explained in the Vissim manual (PTV, 2018). Note that even though the car-following model in Vissim includes stochastic variations, the lane-changing model does not. It also does not contain several driver behaviour types, but all vehicles are simulated to perform lane changes in the exact same way. This is not realistic, as regarding DLC, research has shown that 4 general types of DLC behaviour exist among real drivers. These are speed leading, speed leading with increased speed at overtaking, lane leading and traffic leading. In the Java-based microsimulation MOTUS, it has been shown that the different driver behaviours in lane changes affect the capacity flow of a network or link. Particularly, they can lead to lower capacity flows and average speeds (Keyvan- Ekbatani, 2018). Therefore, if Vissim was extended with additional lane changing behaviours, it would offer more options to the users.
25 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
2.4.5 Stochastic variations in microsimulation
In order to obtain a certain statistical reliability of the results, it is necessary to conduct several simulation runs with different random seeds (Keyvan-Ekbatani, et al., 2012). A random seed in Vissim is an integer number. The random seed influences how the vehicles inputs take place. If at one input vehicle location, 500 veh/h are inserted into the simulation, this is not in a uniform, but in a pseudo-random way, meaning that the random seed causes this process to be not entirely random. As such, two simulation runs with identical random seed deliver exactly identical simulation results. Therefore, it is essential to execute several simulation runs in Vissim using different random seeds (so-called “replications”). Section 6 of this thesis shows performance indicators that base on an average of six replications.
26 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
3 Case study and research questions
The study area is shown in Figure 5. It includes the municipalities of Baden, Wettingen, Ennetbaden, Obersiggenthal, Untersiggenthal, Turgi, and parts of Neuenhof. Marked in green is the extent of the given macroscopic cantonal transport model. Marked in blue are all important arterials passing through the study area. Note that the national motorway A1 also passes through the it.
The research questions are as follows:
• How can perimeter control in Baden be implemented in a microsimulation tool? • How are performance indicators describing the traffic situation of perimeter control strategies comparing to those of a baseline scenario? It is important to note that the road network of the study area will be changed significantly in the scope of the project “Regionales Gesamtverkehrskonzept Ostaargau” (regional traffic concept of Eastern Aargau). Of this concept, the part “Ostaargauer Strassenentwicklung” (road network development in Eastern Aargau, abbreviated with OASE) is of particular
Figure 5: Study area (green) with important arterials (blue), (Swiss Confederation, 2019), own figure
27 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
importance. OASE concerns the development of the road infrastructure network until 2040 and acknowledges that the number of inhabitants in the Eastern Aargau will increase by 30% and the number of jobs by 20% until 2040, which will have an impact on the traffic situation on the roads, and proposes a large array of measures for all modes of transport. It is planned to add the measures to the “Richtplan” (spatial concept plan) of the canton of Aargau until the end of 2020 (Kanton Aargau, 2019c). In the agglomeration of Baden, the most important projects are the closure of Hochbrücke for individual traffic. It will then be used exclusively by pedestrians, cyclists and the extended Limmattalbahn, a tramway that is currently circulating from Zurich to Schlieren, and that will be extended to Spreitenbach and in a last, planned stage on to Baden. As a replacement for car traffic, a new bridge over the Limmat river around 1 km south of Hochbrücke is planned. Finally, a planned tunnel will lead from Siggenthaler Brücke to Neuenhoferstrasse and shall relieve Baden’s city centre from through traffic (Kanton Aargau, 2019b). Those measures are visualised in the map in Figure 65 in Appendix A.1. The increase in population and therefore, presumably, car trips, is one of the reasons why scenarios with higher demand will be analysed.
28 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
4 Existing traffic control strategy implementation 4.1 Description of existing traffic responsive strategy
Today’s traffic management strategy has been developed in 2013 jointly by the two Swiss companies Erb+Partner and Marty+Partner, with contributions from SNZ Ingenieure und Planer AG. It divides the Baden-Wettingen area into three subregions (TG1, TG2, and TG3, refer to Figure 6), and proposes certain measures on the arterial roads in these subregions. It is based on the node system around Hochbrücke in the city center of Baden (especially the nodes Schartenstrasse, Schulhausplatz and the nodes along Bruggerstrasse), that are today at the limit of their capacities and are therefore decisive for the maximum flows of the whole system (SNZ Ingenieure und Planer AG, 2013). On each arterial approaching the city center, coordinated traffic lights make sure that the inflow of cars is not higher than what the node system Hochbrücke can process: So, if the demand is higher than capacity, vehicles are delayed at the innermost traffic light. If the queue length at the innermost traffic light exceeds a certain length, a second traffic light further upstream is activated, which will provide additional queueing space. Most links also have a third traffic light even further upstream. This corresponds to the “cascade” concept described further down. Note that the system is not coordinated in a global way like in MFD-based perimeter control, which means that the gating of traffic lights is only coordinated within each subregion (“Teilgebiet”) in Figure 6, but not among traffic lights of different subregions.
Figure 6: Three subregions relevant for the existing traffic-responsive strategy. TG=Teilgebiet (SNZ Ingenieure und Planer AG, 2013)
29 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
The gating traffic lights were implemented between 2014 and 2017. Since 2016, they have been controlled by a “regional traffic computer” (Regionaler Verkehrsrechner, RVR). This shall improve the coordination of traffic lights and the traffic flow (Erb+Partner AG, 2017). The perimeter of interest contains 36 signalised intersections. The author possesses read-only access to the RVR, therefore a detailed insight into the existing traffic control strategy can be obtained. Note that all signalised intersections in the perimeter have adaptive phase and cycle lengths, and public transport vehicles are prioritised at all relevant intersections. All relevant traffic lights in the perimeter are controlled by the signal control logic FESA (in German: “flexibel, erweiterbar, systemunabhängig, anpassungsfähig”, which translates to “flexible, extendable, system-independent, adaptive”). It allows public transport priority, and a traffic flow-dependent control. FESA was developed by the Swiss company FESA Logik GmbH from Winterthur and is used today in several cantons of Switzerland as the de-facto standard, those being Zurich (except the city of Zurich), Lucerne, Zug, Aargau, Schwyz, and Schaffhausen. FESA is also widely used in the cantons of Berne, Basel-Landschaft, and Glarus (FESA Logik GmbH, 2019). The traffic lights in the perimeter are all equipped with several loop detectors per approach (Swarco and Kanton Aargau, 2019):
• For vehicle actuation: advance detector, calling detector, stop-line detector • For gating: loop detectors for traffic jam detection further upstream (2 – 5 per intersection) In the next part, intersection 373 located in Obersiggenthal (to the northwest of Baden’s city centre) shall serve as an example, see the sketch in Figure 7. This node has calling and stop- line detectors, but no advance detectors. The three loops used for traffic jam detection are located 160, 350 and 440 metres upstream and are highlighted with a red circle. Figure 8 shows a sketch of intersection 373 (highlighted in orange) and its neighbouring intersections. The FESA logic files used to control the traffic lights in Baden can be accessed on the RVR. Therefore, the first idea was to directly import those files into Vissim, to achieve an exact model of the traffic lights’ behaviour. Unfortunately, this import is only possible for the world’s major signal control logic types, among those being SCOOT, SCATS, LISA+, VS- PLUS (Verkehrssysteme Plus), RBC (Ring Barrier Controller) and Siemens VA (“verkehrsabhängig”, standing for “vehicle actuated”), but not for FESA. This is probably due to the very small amount of traffic lights worldwide controlled by FESA, so that developing a Vissim interface for FESA would not make economic sense for either FESA Logik GmbH or PTV AG. Note that according to Manuel Kalt from BVUATB (Departement für Bau, Verkehr und Umwelt, Abteilung Tiefbau, the government authority at the Canton of Aargau responsible for traffic management), the German traffic engineering company Schlothauer & Wauer, which has developed LISA+, has programmed an unofficial code that can
30 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
automatically convert FESA logic files to LISA+ logic files, that could then be imported into Vissim using the existing interface (Kalt, 2019). However, Schlothauer & Wauer denied providing the code upon request. The behaviour of a signalised intersection in FESA is described in a large collection of tables, that can be found in the “Technische Unterlagen” (technical documentation). The following information stems from (Kalt, 2019). The behaviour of every signalised intersection in the study area is described in such a pdf document, that is around 40 to 120 pages in length, depending on the complexity of the intersection (number of approaches, complexity of gating, presence of bus priority, etc.). The documentation contains information about the signal groups and allowed combinations of signal phases, intergreen matrices, and different signal programs depending on the demand and on the time of day and year. All traffic lights which in the current traffic management system contribute to gating, contain an additional section “Drossellogik” (restrictor logic). This is a large collection of a few dozen “if-then-else” conditions that can change the minimum red time and maximum green time of an approach. An excerpt of this restrictor logic of gating traffic light 373 is shown in Figure 10. The input for this logic is, among others, the presence of traffic jams on the upstream traffic jam detectors, designated by S8121, S8122 and S8123 in this example (standing for a short, medium or long traffic jam, respectively). The detection of traffic jams happens either using an approximation of the speed (for example, if the occupation time of detector exceeds 3s, then the vehicle speed is lower than 11 km/h, which corresponds to a traffic jam) or using the occupancy value of a one-minute average. For instance, a traffic jam is detected when occupancy exceeds 35% and is considered dissolved when occupancy falls below 25%. The output of the three loop detectors S8121, S8122 and S8123 defines the maximum green time, so if S8121 detects congestion, then the max. green time is 30s. For the other loop detectors, it is 35s or 40s, respectively. This strategy of extending green times for long queues corresponds to queue management, similar to the one described in Section 5.3.4. Furthermore, data from traffic jam detectors of other intersections is used as input, and this is where the mentioned table of the restrictor logic becomes relevant. The data from detectors at other intersections (here: traffic jam detectors upstream of intersections 344 and 371) are the fields highlighted in yellow in Figure 10. The two columns “und-Verknüpfung” and “weder noch-Verknüpfung” in the table are logic connections: The left column stands for a logic “AND”, which means that all three subcolumns must yield “1” (i.e. traffic jam detected) for the condition to yield “1”. The right column stands for a logic “XOR”, meaning that none of the three subcolumns must yield “1” in order for the whole column to yield “1”. Z3.1 and Z3.2 in Figure 10 stand for a flow of 725-800 veh/h and 875-950 veh/h, respectively, and U49 designates the approach of a bus requesting priority. Row 3 of the table in Figure 10 shall serve as an example: It means that detectors 8221 and 8222 of intersection 371 must detect congestion,
31 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
but the detectors 8121, 8122 and 8123 and intersection 373 and detector 8124 at intersection 344 must not detect congestion. The output of the Table can be seen in the column “DrFkt”, which specifies the “aggressiveness” of the restrictor logic. There are 4 levels of this aggressiveness, with decreasing maximum green times and increasing minimum red times, as shown in Table 3. The output of the mentioned row 3, if the conditions are fulfilled, is DrFkt=1, which translates to a max. green time of 14 s and a min. red time of 18 s. This max. green time overrides the max. green times of 30/35/40 s as mentioned above. This example serves as proof that a detailed implementation of every single condition for the gating traffic lights will take a substantial amount of work that is outside of the scope of this thesis. This is underlined by the fact that it is not sufficient to model the gating intersections only, because the behaviour of one gating intersection potentially also depends on the behaviour of non-gating intersections, that would therefore need to be modelled as well. In the current traffic-responsive strategy, as mentioned before, there is not just only one gating traffic light per arterial leading towards the city centre, but up to five. Refer to Figure 66 in Appendix A.1. This is the case, for example, for the axis Untersiggenthal – Kirchdorf – Nussbaumen – Martinsberg, which means drivers must pass five gating traffic lights until reaching the centre of Baden. This is called a “cascade” of gating traffic lights (SNZ Ingenieure und Planer AG, 2013). In the sketch on Figure 8 and the map on Figure 9, this cascade corresponds to the traffic lights 376, 375, 373, 371 and 341 for vehicles on the way to Baden from Untersiggenthal. Figure 66 in Appendix A.1 shows more detailed information about the way this cascade is implemented. (SNZ Ingenieure und Planer AG, 2013) also mentions that the queueing spaces in the area are very limited: For 14 signalised intersections in the region, they forecasted from which year onwards the queueing space at the specific intersection will be full in the morning or evening peaks, using statistical data for traffic demand increase and the current traffic-responsive strategy. 8 of these 14 intersections already had a full queueing space in 2015. Most critical are the intersections in Wettingen, and Mellingerstrasse (K268, see Figure 5). Therefore, further measures can also be to include more intersections upstream or downstream in the cascade to generate more queueing space. The authors call this “a continuous task of traffic management”. This modular procedure to be able to add queueing spaces later is a big advantage of the current traffic-responsive strategy.
Table 3: Output of the restrictor logic (Swarco and Kanton Aargau, 2019), own table
Drosselfunktion Max. green [s] Min. red [s] (DrFkt) 1 14 18 2 12 20 3 10 23 4 8 26
32 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 7: Map of intersection 373 (Landstrasse) (Swarco and Kanton Aargau, 2019)
Figure 8: Intersection 373 together with neighboring intersections. Red rectangles are traffic jam detectors (Erb+Partner AG & Marty+Partner AG, 2017)
33 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 9: Intersection 373 with neighboring intersections (Swiss Confederation, 2019), own figure.
Figure 10: Excerpt from the restrictor logic for intersection 373 (Swarco and Kanton Aargau, 2019)
34 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
4.2 Implementation in Vissim
In order to compare the existing traffic management strategy with a novel perimeter control approach, it is essential to implement the existing strategy, as far as this is feasible, in a microsimulation software package. Vissim was chosen over the alternative Aimsun, because the model would be based on an existing macrosimulation model in Visum, which would allow using the existing interface between Visum and Vissim. Also, because the author had previous experience in Vissim.
4.2.1 Conversion of the macroscopic to a microscopic model
The demand of the given macroscopic model of the area shown in Figure 5 in Visum (extract of the cantonal transport model) was first validated using counting data. The Visum model contains the demand for the year 2015. The average weekday traffic volume (“durchschnittlicher Werktagsverkehr”) was extracted from the online map of official traffic flow counters of Kanton Aargau. Note that not all counter data is up-to-date: Some data in Baden-Wettingen is as old as 1994. To ensure sufficient relevance of the counter data, no data from before 2011 was used. Note that no up-to-date counter data is available near the main intersection Schulhausplatz or at the arterial Bruggerstrasse north of Schulhausplatz. Table 4 shows that the maximum deviation between average weekday traffic volume from the Visum model and the counting data is 12.6% (indicated in red), with an average of 4.5% and a standard deviation of 3.8%.
Table 4: Comparison of daily traffic flows (traffic counter data and Visum flows), (Kanton Aargau, 2019d) and (Kanton Aargau, 2019e)
Traffic counter Year of Traffic flow in Flow from number measurements Visum traffic counter Difference [%] 886 2015 24’648 24’743 0.4 3002 2014 12’087 10’916 -9.7 3003 2014 12’839 14’173 10.4 1570 2014 16’005 16’210 1.3 888 2015 13’895 12’731 -8.4 692 2018 10’150 10’866 7.1 1029 2018 14’672 14’385 -2.0 1121 2018 23’790 24’032 1.0 3009 2012 21’500 22’236 3.4 1095 2011 18’004 18’256 1.4 691 2011 17’820 17’587 -1.3 1217 2011 8’171 9’199 12.6 697 2015 21’797 22’551 3.5 1220 2012 19’026 18’034 -5.2 97 2017 134’017 131’336 -2.0 1402 2017 136’773 133’674 -2.3
35 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Another data source used to validate the model was traffic flow data from loop detectors collected on a sample day (Wednesday, the 24th of April 2019), which could be accessed on the RVR. This is node flow data (as opposed to link flow data in the Visum model) based on loop detector flow measurements, from 13 randomly selected nodes. However, using this dataset posed a few problems: On some nodes, not all lanes were equipped with loop detectors, therefore underestimating the flows. Some nodes contained counting data not relevant for this purpose (i.e. bicycle or bus flows). On the remaining eight nodes, the biggest deviation between the Visum flows and the loop detector flows was 15.2%, with an average deviation of 5.3% (Swarco and Kanton Aargau, 2019). Those deviations were deemed to be in order to use the macroscopic model for further processing. The macroscopic model was converted into a microscopic model in Vissim, using Visum’s built-in Abstract Network Model (ANM) export interface. In order to do this, the macroscopic model first needed to be pre-processed: there were 14 intersections which were represented in the model as two different nodes at virtually the same location, each connected by a link of a few millimetres in length. This was problematic as the ANM interface reported errors and aborted the export due to the short link length. Therefore, at those 14 intersections, one node each was deleted, which led to minor side roads not being connected to the model anymore. As these roads have zero or negligible traffic volume, this is an acceptable simplification. Also, no gross errors from the conversion were found in the model. As the given macroscopic model was especially detailed concerning the road network, it contained all relevant links in the perimeter. The resulting microscopic model, on the other hand, was lacking many elements normally present in a model on micro-level:
• Infrastructure elements: No traffic lights, pedestrian crossings, bus lanes, public transport stops, or priorities of approaches at intersections were implemented. Also, partially, separate lanes for right or left turns were missing. • Demand: No pedestrian, bicycle or public transport demand was implemented. The only modes implemented are cars and trucks. Furthermore, there was no time-dependent, detailed implementation of demand: The resulting Vissim model features a simulation time of one hour (morning peak hour), with constant demand. Figure 11 shows a graph of the network containing around 2500 nodes. Around 8000 links ensure the correct connectivity. The time available did not allow the creation of a detailed microscopic model of Baden- Wettingen. This would have exceeded the scope of this thesis. Therefore, only the most necessary adaptions to the automatically generated microscopic model were performed, to leave enough time for a thorough analysis of the implementation and analysis of perimeter control. Subsequent sections will explain the simplifications undertaken.
36 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 11: Graph of the Vissim network. Nodes are the blue circles, links are the red lines.
4.2.2 Adaptive signal control of gating traffic lights with vehicle-actuated programming
The detailed modelling of the gating traffic lights for the baseline scenario (no perimeter control) was conducted using the two Vissim add-ons VAP/VisVAP (standing for “vehicle actuated programming” and “visualisation vehicle actuated programming”, respectively), together with Vissig. VAP is a programming language to create a stage-based or phase-based signal control logic, with traffic actuation. VisVAP is a graphical user interface, which can be used to create a flowchart of the control logic, which is then automatically converted to VAP code that serves as input for Vissim (Koukol & Pribyl, 2013). The basic idea is to use maximum and minimum green and red times together with vehicle actuation. The behaviour of the gating traffic lights would later be modified when implementing MFD-based perimeter control, allowing a simplified, but valid comparison between the two systems baseline and perimeter control.
37 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 12: Necessary input files for VAP. Source: (PTV, 2017) The *.vap file from VisVAP is only one of the inputs for VAP, see Figure 12. Additionally, Vissim needs a *.pua file, that is generated by Vissig. Vissig is an add-on to Vissim and provides stage-based fixed time signal control. With Vissig, one can define stages graphically, and then generate interstages automatically (PTV, 2018). For the adaptive signal control using VisVAP, the *.pua file only contains the information which phase comes first (in this case, it is red). Note that Vissig will be more relevant at a later stage for the traffic lights within the perimeter. Figure 12 shows the files needed to use VAP. The files not used by VAP, the *.sig and *.vv files, contain very similar information as their counterparts, in a different format. These two formats are used to open the files in VisVAP or Vissig and change them at a later time. Figure 13 below shows the flowchart of the signal logic of gating traffic light 314 (Kloster) in VisVAP as an example. During the simulation, this flowchart is being evaluated every simulation second. Note that for the “if-then-else” condition, the branch going to the right is for when the condition is fulfilled, and the branch going down for when the condition is not fulfilled. At the beginning, there is a check if this is the first simulation second. In that case, the timer for red starts, and the traffic light shows red. Then, there is a check if the maximum red time of 25s is exceeded. If yes, and if the traffic light shows red, it is turned to green and the green timer is started. The next “if”-condition evaluates whether the traffic light is currently red, whether the red time is between its minimum and maximum, and whether detector 9 is occupied by a vehicle. In that case, the traffic light turns green together and starts the green timer. Then, it is evaluated if the maximum green time is exceeded and if the traffic light is currently green. In that case, it turns red. Finally, it is checked whether the traffic light is green, with its green time in between the minimum and maximum value, and if there is no vehicle detection. In that case, the traffic light turns red.
38 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 13: Traffic-actuated control logic of intersection 314 in VisVAP
4.2.3 Modelling intersections
After having modelled the signal controllers of the gating traffic lights, it is necessary to model the intersections within the perimeter in a realistic way, such that the traffic priorities are similar to those found in practice. To model intersections, Vissim offers three general options (PTV, 2018):
• Conflict areas: A simple way to model priority rules for conflicting traffic flows without traffic signals.
39 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
• Priority rules: The same idea as with conflict areas, but the Vissim manual recommends to use priority rules only if conflict areas do not deliver the desired example, and for very experienced users (PTV, 2018). • Signal controllers / signalised intersections Conflict areas are modelled in Vissim by changing the type of the conflict areas from the default setting “passive” to “undetermined” (meaning that none of the two relevant approaches has priority) or to “2 waits for 1” (meaning that approach 2 yields to approach 1) and “1 waits for 2”. Note that “passive” means that there is no conflict in the model, resulting in vehicles potentially driving through each other, without any disturbance. This would increase the total production of the intersection unrealistically. Also, note that a separate conflict area must be defined for every single conflicting traffic flow. On a larger intersection like the one in Figure 14, this can require around 40 conflict areas to be defined. The prioritised relations are shown in green and the yielding relations in red. Priority rules were not used in this work, as they are quite complex and time-consuming to model, i.e. they require several parameters such as the minimum gap time or the minimum headway to be defined and also need designated conflict markers and stop lines. The first attempt was to use conflict areas for all intersections within the perimeter. Figure 14 shows how intersection 321 (Schulhausplatz) looks like when using conflict areas. The problems with this approach are two-fold:
• For the intersections that are in reality signalised, there are of course no given traffic priorities. This means that it is not possible to define yielding and prioritized approaches in such a way that the intersection is modelled realistically. Note that if all conflict areas are set to “undetermined” for those intersections, large delays on all approaches are the consequence, because the drivers in Vissim are modelled as very careful and are slow decision-makers when several vehicles arrive at the intersection simultaneously. This results in a drastic reduction of the capacity of the intersection. • A change in priority (i.e. from “2 waits for 1” to “1 waits for 2”) of one single conflict area in a complex intersection can completely change the throughput per approach. If, for example, the left turn on the approach coming from the north in Figure 14 is given priority over the left turn and through lane on the approach coming from the east, the queue on the northern approach virtually disappears, whereas with the situation pictures, the queue length is substantial. Even if a combination of conflict areas is found that leads to a realistic queue length, it would be impossible in reality to explain drivers which relation is prioritized, and which is yielding, which makes conflict areas for complex intersections infeasible both in simulation and in reality.
40 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 14: Conflict areas at Schulhausplatz Due to the mentioned reasons, the main intersections within the perimeter have been modelled with fixed-time signal controllers, as shown in Figure 17. Unfortunately, because the Vissim license at ETH is limited to a total of 20 signal controllers, only the nine most important intersections within the perimeter could be equipped with traffic lights. The remaining 11 signal controllers are needed for perimeter control. The definition of the “main” intersections is clearly subjective and was done firstly according to how important they are for the overall performance of the network, and secondly according to the amount of traffic. Only intersections also equipped with a traffic light in practice were chosen. To obtain meaningful green and red times for the traffic lights within the perimeter, every approach of the relevant intersections is equipped with data collection points that deliver flow measurements per time interval. All flow values of the baseline scenario are summed up per approach so that the percentage of the total flow per approach can be calculated. The cycle time of these traffic lights was first set to 90s. However, this considerably high cycle time requires large vehicle queueing spaces, which are not available especially for the nodes Schulhausplatz, Brückenkopf Ost and Schartenstrasse. To reduce the queue length, a cycle time of 45s was chosen. For the sake of simplicity, each traffic light starts the cycle at the same time with green on the approach from the west, in a counter-clockwise fashion. An exception is intersection 321, that starts its cycle with an offset of 15s, and intersection 351, which has a cycle offset of 42s. The reason for this is that this allows for a very simple form of coordination of the traffic lights at intersections 321, 322 and 354_2 (refer also to Table 5), as it is already in place (in a more complex manner) in reality. Figure 15 shows a screenshot of the RVR. The blue circles denote coordinated traffic lights. The red ellipses indicate the two groups of coordinated traffic lights. The mentioned coordination of 321, 322 and 354_2 is
41 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 15: Screenshot from the RVR. The circles in blue denote the coordinated traffic lights, the arrows in yellow the path for which coordination was implemented and the red ellipses the coordinated traffic lights in reality (Swarco and Kanton Aargau, 2019) necessary in the simulation because the available queueing spaces when coming from the roundabout at intersection 354_1 over towards intersection 354_2, driving towards south, turning right at intersection 322 and passing over Hochbrücke to intersection 321 would not be enough (refer to the yellow arrows in Figure 15). More precisely, the western approach of intersection 354_2, the northern approach of intersection 322 and the eastern approach of intersection 321 would exceed their capacity. With this simple form of coordination, vehicles travelling on the described path experience a green wave, and no spillbacks are caused. Table 5 lists the nine intersections within the PN and the green times per approach. The stages and interstages were defined graphically in Vissig. Figure 16 shows the signal program for intersection 388 (Haselstrasse) as an example. Note that no intergreen matrix was defined to keep the model as simple as possible. Also note that the green times in Table 5 needed to be slightly modified when starting with the mentioned data from the data collection points, which was done for intersections 321, 322 and 354_2. In the case of 354_2, for example, the green time of the western and southern approaches needed to be increased (and the green time of the eastern approach reduced), in order to prevent queue spillbacks to the neighbouring intersections 354_1 and 322. Note that the traffic light 312 (Anschluss Neuenhof) is not
42 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
within the PN but is still modelled in Vissim. This is due to the essential role of this intersection. Long queues at its approaches, which occur when conflict areas are used, can lead to spillbacks onto the motorway passing beneath it. This would be certainly undesired.
The remaining intersections are modelled such that traffic coming from secondary approaches will yield to traffic on primary approaches, for which conflict areas are used as described above.
Figure 16: Signal program for intersection 388 (Haselstrasse) in Vissig
Table 5: Green times per approach
Intersection Intersection name Approaches and green time [s] number North West South East 312 Anschluss Neuenhof 14 16 15 -- 321 Schulhausplatz 16 10 10 9 322 Brückenkopf Ost 11 16 4 14 341 Martinsberg 18 19 -- 8 354_1 Schartenstrasse Kreisel 13 -- 17 15 354_2 Schartenstrasse Süd -- 16 23 6 371 Boldistrasse 4 27 7 7 387 Bruggerstrasse 15 -- 15 10 388 Haselstrasse 6 21 10 8
43 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 17: All modelled traffic lights within the PN. Source: (Swiss Confederation, 2019), own figure
4.2.4 Modelling the demand
A realistic demand pattern needed to be derived and implemented. The demand of the model after conversion from Visum was uniform in the morning peak (7 am to 8 am). The demand is represented by 171 vehicle input locations distributed all over the network, where vehicles are inserted into the simulation. Each vehicle input has a pre-defined input volume. The locations and volumes had been automatically defined by the export from Visum. However, the time before or after the morning peak was not modelled. This was done in 4 phases as follows (see also Figure 18).
• 6 am to 7 am – steady increase of traffic based on counting data: The traffic counting data already introduced in Section 4.2 was used to calculate the ratio of the average traffic flow at 6 am divided by the average traffic flow at 7 am, for every traffic counter. All ratios (one per traffic counter) were then averaged. The result is that the average flow at 6 am is 54.5% of the average flow at 7 am, with a standard deviation of 6.3%. The demand was then modelled to increase every 6 min in a step-wise fashion until reaching the maximum demand at 7 am, i.e. between 6:00
44 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
and 6:06, the flow was 54.5%, between 6:06 and 6:12 59.0% and so on.
• 7 am to 8 am – constant maximum inflow: The given constant demand was retained in the modelling process. This is not entirely realistic due to demand fluctuations in that time window shown in the counting data, but still an appropriate simplification. The total inflow into the network during this peak hour amounts to 23’064 veh/h.
• 8 am to 9 am – decrease of demand towards zero: The demand was reduced towards zero, using a similar step-wise fashion as during the onset of peak hour. This means that from 9:00 to 9:06, demand is 90%, from 9:06 till 9:12 it is 80% and so on.
• 9 am to 10 am – zero inflow: During this time, the network inflow remains zero. This allows all or nearly all vehicles of the network to finish their trip, depending on the scenario. An empty or nearly empty network at the simulation end is important to allow a fair comparison between scenarios.
Note that the period without demand originally was specified to be only 30 minutes long, until 9.30 am. However, simulations have shown that with perimeter control strategies that lead to large queues at the gating points, some queues can remain until after 9.30 am, such that these queues can dissolve.
Figure 18: Demand pattern. 100% corresponds to around 23’000 veh/h.
45 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 19 shows the demand patterns for the scenarios with increased demand that were needed because the normal demand of Figure 18 does not produce sufficient congestion such that perimeter control can perform efficiently. The bars in blue denote the demand pattern of Figure 18.
4.2.5 Combination of perimeter control with today’s traffic-responsive strategy
Section 4.1 has shown that today’s traffic responsive strategy cannot be implemented in Vissim in the scope of this thesis. Therefore, the question arises why such a simplified baseline scenario should at all be implemented, and whether it makes sense to compare perimeter control results with baseline results. The essential notion is that if the perimeter control scenario proves to perform better than the baseline scenario of this thesis, then perimeter control could be applied in combination with today’s traffic responsive strategy, which together could theoretically deliver even better results compared to on its own. Perimeter control is therefore not a replacement of the current traffic-responsive strategy but can complement it. This idea is sketched in Figure 20.
Figure 19: Demand pattern for scenarios with increased demand. 100% corresponds to around 23’000 veh/h.
46 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 20: Perimeter control in combination with existing strategy
4.2.6 Unrealistic vehicle behaviour in Vissim
There are several characteristics of driver behaviour in Vissim that do not coincide with reality, and therefore Vissim results always need to be interpreted with care. This section briefly presents these aspects, and what was done to partially mend it.
• Lane changes: Vehicles on a link approach which has separate right-, left- or through lanes and that need to perform an MLC to reach their destination, do not change lane in time, but continue all the way to the stop bar where they are waiting for a gap in traffic stream on the lane next to theirs. This means that when the traffic light turns green, they potentially need to wait almost till the end of the green time to change lane. During the waiting time, they block their lane for vehicles behind them. This does potentially occur at all traffic lights with more than one lane per approach, so for example at gating traffic lights 314 (Kloster) and 323 (Mellingerstrasse), or 321 (Schulhausplatz). At these intersections, it can significantly reduce flow. In other cases, a vehicle can change lane without blocking its lane for long, thanks to cooperating (decelerating) vehicles in the destination lane. But even then, there is still a reduction in total flow because lane changes are executed not at a reasonable distance upstream from the traffic light, as it would usually happen in reality, but close to the stop bar. As the cooperating vehicles in the destination lane slow down, the throughput is reduced. A Vissim screenshot of such a situation is shown in Figure 21. The yellow vehicle in the turquoise ellipse must perform an MLC, but the vehicles in the lane to its right do not usually behave cooperatively, so that the yellow vehicle stays at this exact spot
47 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 21: Screenshot at intersection 312 (Schulhausplatz) and blocks the left turn, until it is removed automatically by Vissim after 60 seconds, or can perform the MLC after having created a substantial queue.
• Blocking intersections: In the screenshot in Figure 22, it can be seen that the blue vehicle in the ellipse coming from the northwest blocks the intersection, such that the grey vehicle that wants to turn left and crossed the stop bar of the green traffic light cannot move on. This can be partially fixed by placing stop bars at the approaches without a traffic light. This helps to prevent the vehicles from entering the intersection whenever they cannot move on.
48 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 22: Blocking gating intersection 314 (Kloster)
4.3 Traffic assignment strategies
Traffic assignment is the last step of the 4-step model, which is an often-used tool in transport planning. In traffic assignment, vehicles that have a specified origin and destination are assigned to a certain route on the network. In the literature, there are three ways of implementing:
• Static traffic assignment: In static assignment, the routes of the vehicles are fixed, and stay the same for the whole simulation duration. Even if vehicles encounter congestion on their path through the network, they will not re-route. Also, when a new policy is implemented, drivers do not adapt their route, unlike in reality. Due to the low computation time, this category is by far the most often used in practice (Wang, et al., 2018). In Vissim, static traffic assignment is implemented by placing vehicle inputs with given traffic volumes, and routes (PTV, 2018). • Semi-dynamic traffic assignment: Semi-dynamic traffic assignment resembles a series of connected static traffic assignment models, in such a way that it has several time intervals for route choice (Wang, et al., 2018). • Real-time dynamic traffic assignment (DTA): In dynamic traffic assignment, new routes for the vehicles are calculated in every time interval. The computation time of this approach is orders of magnitude larger than for static assignment (Travel Forecasting Resource, 2019). Due to this reason, it is seldom used in practice (Wang, et al., 2018). In Vissim, for dynamic traffic assignment, no vehicle inputs or routes are
49 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
needed. Instead, an origin-destination (OD) matrix is defined, which contains the start and end points of each trip, and the number of trips between these locations (PTV, 2018).
This thesis uses static traffic assignment. This has two main reasons:
• On one hand, as the computation time of one simulation run amounts to around two hours (for the standard demand scenario), dynamic traffic assignment would increase this time significantly, which would make efficient testing and use of the model excessively time-consuming. • On the other hand, the used microsimulation model already has the static routes implemented, which come from the assignment step in the given (calibrated and validated) macroscopic cantonal transport model. Therefore, these routes are assumed to be in order.
Note that most scientific literature uses static traffic assignment, despite its lack of closeness to reality. This leads to situations close to gridlock at some very congested roads, whereas other roads are virtually empty, which causes a sudden drop in flow. In reality, or with dynamic traffic assignment, drivers could reroute, and the network would be able to support a higher vehicle density before leading to gridlock (Ortigosa, et al., 2014).
50 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5 Implementation of Perimeter Control
5.1 Conceptual Framework
One reason why this study was executed was that the topography of the urban region of Baden is very suitable for perimeter control. Baden is surrounded by hills on several sides, which means that the number of arterials leading towards the city, and that therefore will require gating traffic lights, is relatively small. Using studies with topographical maps, the following 9 arterials have deemed to be significant and therefore in need of control (refer to Figure 23). Thanks to Baden’s topography, there is no other arterial leading towards the centre.
• Bruggerstrasse (K117) from Brugg/Turgi • Landstrasse (K114) from Würenlingen and Untersiggenthal • Mellingerstrasse (K268) from Fislisbach, Mellingen, and Oberrohrdorf. Note that this road is also the access to the highway exit “Baden-West”. • Neuenhoferstrasse (K119) from Neuenhof. Note that this road is also the access to the highway exit “Baden-Ost” to/from Zurich. • Schwimmbadstrasse (K273) from Neuenhof. Note that this road is also the access to the highway exit “Baden-Ost” to/from Aarau. • Landstrasse (K275) from Wettingen and Würenlos • Tägerhardstrasse from Würenlos • Ehrendingerstrasse (K282) from Ehrendingen • Freienwilerstrasse (K427) from Freienwil and Lengnau
51 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 23: Defined perimeter (red) with gating traffic lights. Source: (Swiss Confederation, 2019), own figure The map in Figure 23 shows the situation and the location of the gating traffic lights. The blue lines denote the main arterials in the city and its surroundings, and the protected network is marked red. The gating traffic lights 314 and 323 each have two lanes leading into the PN. Both lanes obviously must be modelled, for which 2 additional signal controllers were introduced, named 201 and 202. Note that at all chosen gating locations except one, a gating traffic light is already present. Therefore, the investments to implement perimeter control will be minor later on. The last arterial on the list, Freienwilerstrasse, is a special case: Gating traffic light number 379 (Hertenstein) on the approach road to Nussbaumen would have prevented too many vehicles from entering the agglomeration of Baden. Despite the longer distance, vehicles bound for Baden would have needed to use this road too, as it was planned to close Hertensteinerstrasse (a shortcut to Ennetbaden and Baden city centre) for through traffic in rush hours. However, the municipalities of Obersiggenthal and Freienwil have objected to those plans: Obersiggenthal fears additional traffic volumes going through the Nussbaumen neighbourhood, and Freienwil is against the longer travel distance when driving to Baden (Kramer, 2018). It is, as of December 2019, unclear how the situation will be resolved and whether it will result in lengthy conflicts at court. Also, the gating traffic light 379 is currently not in operation. Due to the unclear future, in this thesis, it is assumed that
52 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Hertensteinerstrasse between Hertenstein and Ennetbaden will remain open both in the baseline scenario and in the perimeter control scenario. The gating traffic light 379 is not in operation in the baseline scenario, as it is in reality. For the perimeter control scenario, it will be placed before the village of Hertenstein when coming from Freienwil, see the map on Figure 23, so slightly upstream of the existing inactive traffic light. This means that after passing the traffic light 379, drivers can follow their route either towards Ennetbaden or Obersiggenthal.
There are several more municipal roads leading towards and into the perimeter, such as Zürcherstrasse from Neuenhof to Baden, or Rebbergstrasse from Ehrendingen to Ennetbaden, but those are closed to individual traffic so that they can be neglected for this analysis, as they will not carry traffic avoiding the perimeter control system.
The traffic lights on the nine arterials must be placed in locations where there is enough space available for queueing, so that upstream intersections will not be blocked by the queue. Moreover, they must be outside the perimeter (but not necessarily exactly at its border). Furthermore, they must be far enough from the centre such that there is no local road that can be used to circumnavigate the gating traffic light. To achieve an appropriate quality of the urban environment and to prevent excessive immissions of noise and pollutants to nearby residents, gating traffic lights should ideally be situated outside built-up areas. All chosen gating locations fulfil those requirements.
Lots of real-time data is needed to implement perimeter control: Numerous loop detectors continuously measure flows and report those flows to the controller, which can, therefore, monitor the system’s current state in the MFD. Studies have shown that ideally, one detector per link in the PN is installed, but even with only 25% of the detectors (randomly chosen subset), the resulting MFD will still have errors of the magnitude of less than 15 percentage points. The strategy which detectors to choose is more important than their number: a subset of 5% of the detectors chosen quasi-optimally can still deliver a more accurate MFD than with 40% of randomly chosen detectors (Ortigosa, et al., 2014). Specifically, it is important to choose detectors leading to a high homogeneity of the data used (Ambühl, et al., 2017b). Section 5.3 delivers an in-detail description of the used controllers.
5.2 Estimation of the macroscopic fundamental diagram
In addition to real-time measurements of the system’s traffic state, the MFD of the network is needed in order to have an empirical estimate of the critical density or critical occupancy, respectively. This value will later serve as a set point of the controller. Using Vissim, there are two basic ways of creating an MFD, that were both programmed and compared:
53 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Loop detector data
It is possible to set “Data Collection Points” on links in Vissim, which emulate loop detectors measuring occupancy and flow. 739 approximately evenly distributed data collection points were manually placed on links inside the PN in Vissim, such that every relevant link is equipped with a detector. In order to reduce scatter of the MFDs and increase the homogeneity of the data, only data from the 20% most congested detectors was used. To distinguish the loop detectors between “congested” and “non-congested”, the level of congestion is defined as the ratio of the average speed (of all time steps) per detector over the free-flow speed per detector (Kouvelas, 2018a). This indicator is called speed index (Ambühl, 2018). Note that every detector has a different free-flow speed, due to different road characteristics. Therefore, the free-flow speed is set to the 90th percentile of all speed measurements per detector. More formally, this looks as follows (Ambühl, 2018):
푣̅푖 푠푝푖 = , (4) 푣푓,푖
where 푠푝푖 is the speed index of detector 𝑖, 푣̅푖 is the average speed for detector 𝑖 over all time steps, and 푣푓,푖 is the 90th percentile of all speed measurements for detector 𝑖. The 20% most congested detectors are the 20%-subset of detectors with the smallest speed indices. Figure 24 shows a map of the network with all data collection points as well as with the 20% subset. Using the coordinates of the detectors, they could also be geo-referenced to the Swiss national coordinate system for further work. Note that the definition of the 20% most congested detectors is not that trivial: Depending on the random seed, the subset of detectors might be slightly different. Also, it might differ whether a baseline simulation run is considered, or a BBC or PI controller run, as traffic might be spatially distributed differently. Then, if a new simulation run is executed using the pre-defined data set of the 20% most congested detectors of a previous run, the set might again be different.
However, for the sake of simplicity, these influences were ignored in this work. The set of the 20% most congested detectors was defined using the baseline scenario run with random seed 12 and then kept constant for all future uses.
This approach would be feasible in a similar way in a real-world implementation, provided that enough loop detector data is available. The total runtime of the simulation outputting the MFD is approximately two hours.
54 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Link Evaluation data
Vissim has a feature called “Link Segment Evaluation”. This approach allows reading in real- time density, flow and speed of every link segment of the model. A link segment is defined as a segment of a link with 10m length. There are over 20’000 link segments in the network. Two different methods of MFD estimation with link evaluation data have been programmed, of which a sample result is shown in the Appendix A.2 on page 139.
Conclusion
The author decided against link evaluation data and in favour of loop detector data for MFD generation and perimeter control. This is because of runtime issues and better feasibility in a real-world implementation. However, the correctness of the MFD from loop detector data can be verified using the MFD from link evaluation data. The result is shown in Figure 72 and it looks very similar in shape to the MFD obtained from data collection points.
55 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 24: Map of all 739 data collection points (top) and of the 20% most congested detectors (bottom). Links in red, detectors in blue.
56 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5.3 Control strategies
This section refers to the general definitions of the bang-bang and PI controllers in Sections 2.3.1 and 2.3.2 and will document their concrete implementation in this thesis.
5.3.1 General considerations
The two control algorithms used, bang-bang control and proportional-integral control, use a very similar design of MATLAB code, which is explained in Section 5.5. Generally speaking, there are two ways to implement a controller that updates the green and red times of the gating traffic lights after every cycle, which are also shown in Figure 25:
• Fixed cycle length of gating traffic lights: After every time step of the controller (i.e. 60 seconds), new green times for every gating traffic light are calculated. The controller then immediately applies the green times, meaning that all gating traffic lights turn green at the same time, and turn red again after their (individual) green time has elapsed. • Adaptive cycle length of gating traffic lights: This more complex approach also calculates the green times of the gating traffic lights after every time step, but does not apply those times immediately, but only when the cycle of the relevant gating traffic light has elapsed. This means that every gating traffic light can have a different and variable cycle length.
The gating traffic lights were implemented using a fixed cycle length. This was decided based on information given to the author by Pouyan Hosseinialiabad in November 2019. From Mr Hosseinialiabad’s experience, both approaches will perform equivalently, because when judging a long period of time, their behaviour will coincide (Hosseinialiabad, 2019). Also, the approach with fixed cycle length is easier to implement. For the approach with adaptive cycle lengths, it would, theoretically, be simplest to create a new VAP file for the gating traffic lights at every time step, with updated maximum green times. However, according to the PTV Vissim customer support, it is not possible to re-read the VAP file during the simulation (Ko, 2019).
57 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 25: Fixed and adaptive cycle length
5.3.2 Bang-bang control
BBC is operating in Vissim using a constant cycle length of 퐶 = 60s. As mentioned previously, the minimum inflow into the PN needs to be predefined to apply BBC. This inflow is set to be the one obtained by summing up the minimum green (4s) and amber (3s) times as defined in the norm SN 640 837 (SNV, 2015). For simplicity, there is no transition to amber, but directly from green to red. Therefore, the green time under BBC is 7s and the red time is 53s. Using these green times at all 9 gating traffic lights (with two of them having two lanes, therefore 11 in total), and assuming a saturation flow of 1620 veh/h or 0.45 veh/s (refer to equation 6 for an explanation), we get a total inflow into the PN of 35 veh during one cycle length of 60s, which corresponds to an hourly inflow of 2100 veh/h. Simulations have shown that the maximum inflow into the PN in the morning peak in the baseline scenario is around 5800 veh/h, which means that the inflow under activated BBC is around 36% of the maximum unrestricted inflow in the morning peak. Note that no assumption of the saturation flow is needed to run BBC, and therefore it does not need to be verified. Also note that in the standard BBC scenario, all gating traffic lights have the same green and red times, no matter variations in demand or queue lengths across the gating traffic lights. Therefore, it was extended with a queue management feature explained in 5.3.4, affecting the green times of gating traffic lights with long queues.
58 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5.3.3 PI controller
The algorithm shown in Section 2.3.2 will be used. A PI controller also needs a pre-defined set point. When regulating the dynamic transport system around this set point, the system throughput can be maximised, or the total VHT minimised (Haddad & Shraiber, 2014). Figure 26 shows the idea from Figure 3 transferred to the use case of this thesis.
The output of the control algorithm is the total admissible inflow into the protected network
푞푖푛(푘), also called ordered inflow (from (Keyvan-Ekbatani, et al., 2012)):
푞푖푛(푘) = 푞푖푛(푘 − 1) − 퐾푃(표(푘) − 표(푘 − 1)) + 퐾푖(ô − 표(푘)). (5) This equation is based on equation 2, adapted for the purpose of perimeter control. It is used as such in various papers treating perimeter control. As opposed to equation 2, it is in discrete time and not continuous time.
This total inflow needs to be distributed among the gating points and afterwards converted into maximum green times of the corresponding gating traffic lights. The inflow is not distributed evenly among the gating locations, as this would be unjustifiable due to varying demand. Instead, the relative inflow into the PN (without any perimeter control system active) during the morning peak is evaluated and is shown in Table 6.
Figure 26: Structure of PI controller used in this thesis. Source: (University of Michigan , 2019), own figure
59 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 6: Relative inflows per gating traffic light
Gating traffic light Name Relative inflow [%] 315 Webermühle 13.4 323 Badenertor 8.0 344 Wylerloch 11.7 373 Landschriber 13.1 379 Hertenstein 10.1 356 Ehrendingerstr. 8.9 363 Geisswies 12.6 367 Tägerhard 1.5 314 Kloster 5.6 201 Kloster 12.4 202 Badenertor 2.7 TOTAL 100
The total ordered inflow into the PN is multiplied by those percentages, which delivers the inflow per gating traffic light 푞푖(푘). The green times per gating traffic light 𝑔푖(푘) are calculated as follows:
푞푖(푘) 퐶 (6) 𝑔 (푘) = ∗ , 푖 3600 [푠] 휇 where 휇 denotes the saturation flow and 퐶 the length of the time interval (in seconds), here 60s. The value for 휇 used was 0.45 veh/s. This is a bit lower than the standard value 0.5 veh/s from (Aboudolas & Geroliminis, 2013), but it was used here for the reason explained in Section 4.2.6, to make up for the unrealistic driver behaviour when waiting for MLC at the stop-line.
To use a PI controller, the values of 퐾푃 and 퐾푖 (gains) need to be determined. This section explains the workflow used to find the proper values of 퐾푃 and 퐾푖. Note that in hindsight, not all steps of this lengthy workflow were necessary. Still, the gains have large influence on the controller output (see equation 5), therefore requiring very careful fine-tuning and deserving detailed documentation. Two methods to find the gains are possible in general:
• The first approach is to use available occupancy data from the simulation. When looking at equation 2, it becomes clear that all values on the right-hand side of the
equation, apart from 퐾푃 and 퐾푖, are known at any given time in the simulation. Therefore, using data from a simulation run without perimeter control, one can evaluate the ranges in which the differences 표(푘) − 표(푘 − 1) and ô − 표(푘) lie, for every time
60 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
interval of the simulation. The inflow 푞푖푛(푘 − 1) will be known from the second
timestep, where PI is operating, onwards. This means that 푞푖푛(0), the inflow at the beginning of PI operation, must be known. It can be directly measured in the simulation using flow measurements from the data collection points. The PI controller is set such that it is activated when 3% of the set point of occupancy is reached. This is the case usually after around 3 or 4 time steps. Whenever the occupancy does not exceed this limit, the traffic-responsive strategy using VAP from Section 4.2.2 is used. Note that the PI controller could also be activated at a much later stage, for example when 40% of the set point is reached. However, the controller needs a lot of time to reach its steady-state, as shown later in this section, and therefore, this early point of activation is used. One possible caveat of the data-based approach is that for simplicity reasons, the gain values are obtained using data from the no-control case (which might show different conditions than with PI control). Another disadvantage of this approach is that the resulting gains always depend on the random seed used to obtain the underlying data. • The second approach of obtaining the gains is to use a Fourier-transform of the underlying equation describing the behaviour of the system and afterwards applying a PID toolbox for the fine-tuning of the gains (University of Michigan , 2019). This equation is not the PI control equation itself, but one describing the vehicle behaviour. However, this equation is not available in analytical form, because the car behaviour model is implemented in Vissim and is a “blackbox” from the user perspective. Therefore, unfortunately, fine-tuning using a PID toolbox is not possible in this use- case, and the first approach is used.
The following text describes how the gain values were found. Note that the gains’ values have the unit vehicles per hour, as all occupancy data is unitless.
Figure 27 can be used to derive suitable values for 퐾푃 and 퐾푖. The range of the change of o(k) over time is -5% − +5%, and the range of the difference between critical occupancy and current occupancy is -30% − +30%. Figure 28 shows the evolution of the resulting change in inflow, when the influence of the two parts is added up, using the gains 퐾푃 = 1100 and 퐾푖 = 360 that will be found at the end of this section. The maximum change in inflow between two time steps, therefore, is around 100 veh/h, as can be seen in Figure 28.
61 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 27: Left: Plot of o(k) – o(k–1) over time (relevant for Kp). Right: Plot of ô –o(k) over time (relevant for Ki)
Figure 28: Time series of Kp (o(k) – o(k–1)) + Ki (ô – o(k)) with Kp = 1100 and Ki = 360 The first approach was to give each parameter half of the impact on the controller output. The maximum value of 퐾푃(표(푘) − 표(푘 − 1)) and 퐾푖(ô − 표(푘)) is set to 1000 veh/h. Then, one 1000 1000 can divide this value by the percentage ranges above ( and ) and gets 퐾 = 10′000 0.1 0.6 푃 and 퐾푖 = 1670. As will be seen later in this section, the assumption of a change of inflow of 1000 veh/h per time step is too big, when comparing it to a maximum inflow of 5800 veh/h, as this would lead to an overly sensitive controller, that influences the result too strongly for small changes of occupancy.
Now, based on 퐾푃 = 10′000 and 퐾푖 = 1670, a decision tree structure (see Figure 67 in Appendix A.1 on page 135) was used to find the optimal gains. In every step, three variants with randomly changed gains are tested by running the simulation with these gains, using the
62 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
same random seed. The decision criterion is the relative queue length at the gates. Therefore, the two variants with the longest relative queues are discarded, and the best one is kept as a basis to further modify the gains. 5 steps in this tree with in total 15 scenarios were evaluated. In the end, a comparison between the best combinations of gains per step leads to the choice of the best scenario out of the five. This results in the gains 퐾푃 = 9650 and 퐾푖 = 2060.
However, there are three essential caveats of the approach above:
• The results are only valid for the random seed the analysis was executed with. A sensitivity analysis with a different seed was performed, using the «optimal» gains, and otherwise the exact same scenario. The maximum relative queue length was 1.8 instead of 0.8, which shows that this fine-tuning approach calibrates the gains for one specific random seed, which results in overfitting.
• There is no need for 퐾푃 to be that large. Looking at Figure 27, one can see that the
term with 퐾푃 mostly causes scatter and makes the inflow curve less smooth. Therefore, it is not that helpful in bringing the system to its desired state. Possibly, the term even causes switching the sign of the inflow from one timestep to the next.
Therefore, it was decided that 퐾푃 is drastically reduced. Also, there was a large
overshoot in the occupancy, as mentioned below. Because a larger value for 퐾푖 means
more overshooting and slower rise time, 퐾푖 was reduced to 400, in the hope of less overshoot. However, according to the findings in (Keyvan-Ekbatani, et al., 2012),
which are mentioned in Section 2.3.2, 퐾푃 is not set to zero, as there is still a time- delay between entry into the PN and vehicle detection by the loop detectors. As can be seen on Figure 24, some of the 20% most congested detectors are right at certain gating traffic lights, but for other approaches or gating traffic lights, such as 363 (Geisswies), 367 (Tägerhard) and 379 (Hertenstein), this is not the case. • The maximum queue length is not the only important criterion in the choice of the gains. The choice should also consider VHT, the number of stops or total vehicle delays.
Analyses have shown that not only the gains themselves, or the PI controller, cause the shape of the time series of occupancy within the PN. The demand is at least as relevant because if the PI controller demands very large inflows in the onset of congestion, those inflows are not possible when the demand is smaller. This means that with too large values of 퐾푖 (which is responsible for the distance to the set point), the controller might end up ordering an inflow that is substantially higher than the number of vehicles that actually want to enter the PN. Figure 29 shows an example. The controller demands an inflow into the PN of around 26’000 veh/h at its peak, but as mentioned, the maximum possible inflow is around 5800 veh/h. The
63 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
effects of this can be seen in Figure 30, which shows that the actual inflow at the gating traffic ligths (as measured by the loop detectors) is only around a fifth of the ordered inflow (as calculated by the controller). For a suitable value of 퐾푖, the difference between ordered and actual inflow would be much smaller. Therefore, 퐾푖 = 2060 is too large.
Figure 29: Inflow into PN with too large Ki (Ki = 2060)
Figure 30: Ordered vs actual flow at the gates with too large Ki (Ki = 2060)
64 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Also, initial experiments have shown large occupancy overshoots of around 10-12%, this can be seen for example in Figure 31. Many different gain values have been tried, each delivering a result that is similar in this aspect. To find out if the controller has a too slow rise time or a steady-state error, a fictive scenario has been constructed with the peak hour demand lasting for three hours instead of one hour, in order to give the controller the needed time to adapt, and to get closer to a steady-state. Figure 31 shows the results of this experiment with a set point of ô = 31%. All variants exceed the set point of occupancy. However, the variants with
퐾푃 = 6000 / 퐾푖 = 1500 and with 퐾푃 = 1100 / 퐾푖 = 360 reach a steady-state around the set point. Note that the demand starts dropping already at time step 160, and is zero from time step 180 onwards, but new vehicles continue to be generated for a certain time period because there is no available road space. After experimenting with a large array of gain values, the gains 퐾푃 = 1100 and 퐾푖 = 360 were chosen, for the main reason that this combination of gains had the smallest deviation of ordered and actual flow, which means that the controller is best adapted to the inflow demand, and also because it reaches the steady-state eventually.
ô ô
퐾푃 = 800 and 퐾푖 = 2800 퐾푃 = 1100 and 퐾푖 = 360
ô ô
퐾푃 = 2000 and 퐾푖 = 1000 퐾푃 = 6000 and 퐾푖 = 1500 Figure 31: Long simulations with 3 hours of peak demand. Plots of occupancy in the PN over time. Red line = set point of 31%. Here, one time step equals 90s.
65 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Of course, the found gain combination needed to be again tested and its performance verified. This was done with testing the gains’ performance against many other combinations of gains, using standard performance indicators.
Table 7 shows some performance indicators for every combination of gains. Interestingly, for gain values much larger than the chosen values 퐾푃 = 1100 and 퐾푖 = 360 (that have a 퐾푖 value to be deemed too large before, due to not being adapted to demand), VHT, vehicle delay, and queue length start dropping again, and the average speed increases. However, if large gains such as 퐾푃= 2800 and 퐾푖 = 1950 are used, the curve of occupancy over time is much higher than with the chosen gains. This means that with very high gain values, the simulation gets very similar to the baseline scenario, which is not desired because the controller does not really regulate or control traffic in this case. As will be shown in Section 6.2, the baseline indeed has the lowest VHT and total vehicle delay values, therefore it is plausible that the closer to the baseline one gets, the better the results. This is underlined by Figure 32 that compares the inflow over time as well as occupancy curves for both gain combinations. Note that the inflow into the PN for the high gains reaches values that are a multiple of the demand, which results in vehicles flowing into the PN almost without hindrance ( baseline). With the chosen gain values 퐾푃 = 1100 and 퐾푖 = 360, the overshoots in occupancy are significantly smaller, which means that the controller is “active” and regulates the inflow, as it is supposed to.
The order of magnitude of the gains used in this work seems high, especially compared with −1 −1 the paper (Keyvan-Ekbatani, et al., 2016), where 퐾푃 = 20ℎ and 퐾푖 = 5ℎ . However, that paper uses density and not occupancy values for perimeter control. As occupancy is in the range between 0 and 0.6, and density between 0 and 150 veh/km (jam density), this large difference in gains makes sense.
Table 7: Verification of gains (random seed 3)
Evaluation 퐾푝= 800 퐾푝= 1100 퐾푝= 1200 퐾푝= 1200 퐾푝= 1800 퐾푝= 1800 퐾푝= 1800 퐾푝= 2100 퐾푝= 2400 퐾푝= 2600 퐾푝= 2800
criterion 퐾푖 = 250 퐾푖 = 360 퐾푖 = 400 퐾푖 = 500 퐾푖 = 600 퐾푖 = 820 퐾푖 = 1020 퐾푖 = 1300 퐾푖 = 1550 퐾푖 = 1750 퐾푖 = 1950 VHT [h] 9428 8576 8636 8807 8922 8859 8520 7510 7453 7470 7338 Avg. speed [km/h] 19.7 21.8 22.1 22.6 22.6 23.3 24.3 25.1 24.8 25.5 26.2 total vehicle delay 6708 5811 5869 6038 6154 6090 5749 4736 4680 4695 4560 [h] max. rel. queue 2.1 1.5 1.8 2.5 2.8 3 3 1.03 1.03 1.03 1.03 length vehicles served 50554 50554 50554 50554 50554 50554 50554 50554 50554 50554 50554
66 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 32: Comparison of gains. Left: Ki=350, right: Ki=1950. Note the different scaling of the y-axes. Afterwards and finally, another idea of improving the system was tried: The gains do not need to stay fixed during the whole simulation. 퐾푖 can be reduced to 퐾푖,1 as long as ô − 표(푘) > 0
(critical occupancy not reached), in order to reduce overshoot, and increased to 퐾푖,2 when ô − 표(푘) < 0 (critical occupancy is exceeded), to bring the occupancy levels faster back to the set point. To evaluate this, several simulation runs with the same random seed, but
67 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
different amounts of changes to 퐾푖 were executed. The results are shown in Table 8. All scenarios that change 퐾푖 during the simulation have a higher VHT, vehicle delay, and max. queue length, and a lower average speed than with constant 퐾푖. Therefore, in further processing, 퐾푖 was kept constant at 360. The only caveat with keeping 퐾푖 constant is that it leads to a much larger difference between ordered and total flow at the gates, but this, in fact, does not lead to worse system performance. Also, these values are only for one random seed and might change, if many random seeds were averaged.
As will be mentioned in Section 5.6, other scenarios with increased demand (+30%, +70%, +100% and +180%) will be calculated. The gains are demand-dependent, therefore, new gains for these scenarios will be derived. For all increase levels, two combinations of gains will be tested, only using averages of two replications due to lack of time. Simulations have shown that the accumulation of vehicles in the network for the increased demand levels is higher than the accumulation with the standard demand multiplied by the increase percentage.
Therefore, the tested gains were also a bit higher than 퐾푃 = 1100 and 퐾푖 = 360 multiplied by the increase percentage.
Table 8: Changing Ki during simulation − results
Evaluation criterion 퐾푖,1= 퐾푖,2 = 360 퐾푖,1 = 0.9*360, 퐾푖,1 = 0.8*360, 퐾푖,1 = 0.6*360,
퐾푖,2 = 1.1*360 퐾푖,2 = 1.3*360 퐾푖,2 = 2*360 VHT [h] 7756 7878 8196 8810 VKT [km] 154’887 154’899 154’818 154’339 Avg. speed [km/h] 23.5 23.4 22.9 21.5 total vehicle delay [h] 4984 5106 5426 6052 max. rel. queue length 1.3 1.3 1.4 1.7 Avg. total difference 2223 1630 1137 212 ordered-actual flow [veh/h] vehicles served 50’554 50’554 50’554 50’554
Table 9: Tested gains for scenarios with increased demand
+30% +70% +100% +180% factor result factor result factor result factor result
1.3 퐾푃 = 1430 1.7 퐾푃 = 1870 2.1 퐾푃 = 2310 2.5 퐾푃 = 2750 퐾푖 = 470 퐾푖 = 610 퐾푖 = 760 퐾푖 = 900 1.6 퐾푃 = 1760 2.1 퐾푃 = 2310 2.7 퐾푃 = 2840 3.3 퐾푃 = 3630 퐾푖 = 570 퐾푖 = 760 퐾푖 = 980 퐾푖 = 1190
68 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
The gains that proved to perform best in terms of VHT are the following:
Table 10: Chosen gains for scenarios with increased demand, considering 2 replications.
+30% +70% +100% +180%
퐾푃 = 1430 퐾푃 = 1870 퐾푃 = 2310 퐾푃 = 2750
퐾푖 = 470 퐾푖 = 610 퐾푖 = 760 퐾푖 = 900
5.3.4 Queue management strategy
One major issue that can arise when implementing perimeter control is a lack of queueing space. When a queue from a gating traffic light propagates further upstream, it can block nodes upstream or even lead to a gridlock-like situation in a part of the network outside the PN. Each gating traffic light has its own queueing space given by the infrastructure and the distance to significant nodes upstream, derived using satellite images on Google Maps (Google, 2019). The results are shown in Table 11.
Simulations have shown that especially the queue at gating traffic light 314 (“Kloster”) exceeds its maximum length. This leads to congestion spilling back to the important intersection of Schwimmbadstrasse with Zürcherstrasse, which is the location of the on- and off-ramps of the motorway A1. The congestion then spreads further back on the off-ramp on the motorway coming from Bern, which finally blocks this motorway entirely, leading to a congestion situation that hardly clears up until the simulation end. This is why realistic perimeter control in Baden cannot be implemented without a queue management (QM) strategy.
First and foremost, note that the critical occupancy used as an input value for the PI controller is inversely proportional to the queue lengths at the gating points. This means that if the set point for the controller is increased (possibly exceeding the critical occupancy from the MFD), then more traffic is allowed to flow into the PN, therefore reducing the queue lengths at the gating points. Thus, to implement perimeter control in reality, one must make a trade- off between traffic flow inside the PN, and queue length at the gating points. It will be shown later that using the given infrastructure and demand, the system cannot operate at critical occupancy without leading to excessive queue lengths and spillbacks at the border of the PN.
This thesis uses an ad-hoc strategy, that is very simple to explain. It is making use of Vissim’s “Queue Counters”. The approach of every gating traffic light was equipped with a queue counter, that allows evaluating the current queue length at every time step of the simulation. Therefore, Vissim allows to modify its definition of a queue. In this work, the parameters in
69 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 11: Length of queueing spaces per gating point.
Gating traffic light Queueing space length [m] 315 730 323/202 660 344 2500 373 2500 379 2300 356 2000 363 630 367 800 314/201 480
Figure 33 were used. The speeds for “begin” and “end” mean that a queue is first registered if the vehicle speeds fall below 3 km/h, and a queue is considered as dissolved if speeds exceed 7 km/h. A queue is interrupted if distances between vehicles exceed 20 m. Also, the maximum queue length is set to 2.5 km, meaning that longer queues are also assigned a length of 2.5 km. This is due to simulation speed that can decrease for high maximum queue length settings (PTV, 2018). Obviously, all those settings influence the measured queue lengths and the behaviour of queue management drastically.
The measured queue lengths are divided by the maximum queue lengths as defined in Table 11, which delivers the degree of filling (≙ relative queue length) of each queueing space. The queue management strategy increases the green time of the corresponding gating traffic light under the conditions shown in Table 12. Note that after an evaluation in Section 6.7, only “weak” queue management was used in this thesis.
Figure 33: Settings of queue counters
70 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 12: Changes in green time depending on relative queue length
Level Degree of filling “Weak” QM - Increase “Strong” QM - Increase [%] in green time [s] in green time [s] 1 80 – 90 1 6 2 90 – 120 3 12 3 > 120 9 22
We refer here to the gating traffic lights with a relative queue length smaller than 80 % with “non-congested”, or with “Level 0”.
All green increase times due to QM are summed up per time step as follows:
𝑔tot = 퐿1 ∗ 𝑔1 + 퐿2 ∗ 𝑔2 + 퐿3 ∗ 𝑔3, (7)
with 𝑔tot the total green increase time, 퐿푖 the number of gating traffic lights on level 𝑖 and 𝑔푖 the corresponding green increase time of gating traffic lights from the table above.
In order not to change the overall sum of green times, the total green increase time is divided by the number of non-congested gating traffic lights 퐿0. This share is then subtracted from the green times of all non-congested gating traffic lights 𝑔cont,0 (output of the controller), in order to achieve the final green times of the non-congested traffic lights 𝑔final,0 as follows:
𝑔tot 𝑔final,0 = 𝑔cont,0 − . (8) 퐿0
This subtraction is important because otherwise, the total green time of all gating traffic lights is potentially larger than what the control algorithm demands. This would lead to extra inflow into the PN exceeding the ordered flow, which corresponds to additional disturbances inside the PN, similar to uncontrolled inflows within the PN. Note that this subtraction can still result in negative green times if 𝑔tot is too big. These negative green times are then truncated and set to 1s. This causes the difference between ordered and actual flow, as seen in Figure 54, and the “excess green time due to QM” in Section 5.4.
Note that this approach may not seem too “scientific”, but it was chosen because it is similar to the existing traffic-responsive strategy, that changes green times of (gating) traffic lights when certain levels of pre-defined queue lengths are exceeded.
71 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5.4 Evaluation measures
In order to compare the outcomes and performance of different scenarios, ten evaluation measures, some of which are often used in traffic engineering literature, shall be implemented and then compared using simulation data. These are:
• VHT (vehicle hours travelled), of the whole network and of the PN only • VKT (vehicle kilometres travelled) • Average speed, of the whole network and of the PN only • Total vehicle delay, of the whole network and of the PN only • Total delays at gates • Number of stops • Percentage of vehicles in a queue, of the whole network and of the PN only • Maximum relative queue length • Excess green time due to QM • Number of vehicles served
Vissim does not offer a straightforward way to output the mentioned measures after a simulation run. Some measures such as VHT, VKT, speed, delay, and number of stops could be derived from Vissim when accessing data from the “Network Performance” object. Unfortunately, this data cannot be accessed via the COM interface but would require cumbersome manual copying from Vissim and analysis in Excel after the end of the simulation run. Moreover, it does not deliver averages over the whole simulation, but only results per time step. Therefore, the performance measures are calculated and processed in MATLAB using the COM interface, which is an automated method without manual copying of results. The following subsections will describe how this was done. For more detail, refer to the MATLAB code.
For the measures inside the PN, it is necessary to differentiate between vehicles inside and outside the PN. Using a pre-calculated list of links which are inside PN (using a point-in- polygon algorithm), it is possible to determine for every vehicle whether it currently is inside the PN or not, by comparing the “link” attribute of the “Vehicle” object with this pre- calculated list. Based on this, two matrices are generated:
• Binary matrix containing 1 only if a vehicle is inside the PN, refer to Table 13
• Binary matrix containing 1 only if a vehicle enters or leaves the PN during this time step, refer to Table 14
72 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 13: Example of the "vehicle in PN" matrix. For vehicles never entering the PN, the matrix only contains zeros.
t=60s t=120s t=180s t=240s t=300s … Veh1 1 1 0 0 0 … Veh2 1 1 1 1 1 … Veh3 0 0 0 0 0 … Veh4 0 1 1 1 0 … Veh5 0 0 0 1 1 … … … … … … …
Table 14: Example of the "vehicle enter/leave PN" matrix, based on Table 13. For vehicles never entering the PN, the matrix only contains zeros. The results are always recorded at the end of a time step.
t=60s t=120s t=180s t=240s t=300s … Veh1 1 1 0 0 0 … Veh2 1 0 0 0 1 … Veh3 0 0 0 0 0 … Veh4 0 1 0 1 0 … Veh5 0 0 0 1 1 … … … … … … …
Note that the methodology used here only works correctly if a vehicle enters and/or leaves the PN not more than once. However, an analysis of the vehicle routes has shown that this constraint is never violated.
5.4.1 VHT
When accessing the “total time in network” attribute of the “Vehicle” object at every time step and summing up those values over all vehicles and time steps, the resulting value is too large. This is because the time in the network per time step is the total (cumulative) time the vehicle has spent so far, and the usual trip lasts for longer than one time step. Therefore, a matrix with all (cumulative) “total time in network” attributes is formed. A sample matrix is shown in Table 15.
73 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 15: Calculation of VHT, sample table
t=60s t=120s t=180s t=240s t=300s … Veh1 57 117 177 NaN NaN … Veh2 43 103 NaN NaN NaN … Veh3 NaN 12 72 152 NaN … Veh4 NaN NaN 31 NaN NaN … Veh5 NaN NaN 43 103 NaN … … … … … … …
The overall VHT is calculated as follows:
푀 1 푉퐻푇 = ∑ 푡 , (9) overall 3600 last,푚 푚=1 where 푡last,푚 (in green in Table 15) denotes the total time in network of the last time step where the vehicle 풊 is in the network, or the row maximum. These values are marked in green in the table above. The total number of vehicles ever having been in the network during the whole simulation run is 푀.
VHT inside PN, which is a measure for traffic conditions inside the PN, is calculated as follows:
푀 1 푉퐻푇 = ∑ 푡 − 푡 , (10) PN 3600 PN,leave,푚 PN,enter,푚 푚=1 where 푡PN,leave,푚 is the total time in network when vehicle 푚 leaves the PN and 푡PN,enter,푚 the total time in network when vehicle 푚 enters the PN. These values are obtained by an elementwise matrix multiplication of the “vehicle enter/leave PN” matrix 퐴enter/leave in
Table 14 with the VHT matrix from Table 15, as shown in equation 11. 푡PN,leave,푚 is the row maximum of 푉퐻푇enter/leave and 푡PN,enter,푚 the row minimum:
푉퐻푇enter/leave = 퐴enter/leave ∙ 푉퐻푇. (11)
5.4.2 VKT
Relevant is the “total travelled distance” attribute of the vehicle object. VKT is otherwise estimated similarly to VHT:
74 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
푀 1 푉퐾푇 = ∑ 푑 , (12) tot 1000 last,푚 푚=1 where 푑last,푚 is the total travelled distance of the last time step vehicle 푚 is in the network. This corresponds to the sum of row maxima of a table similar to Table 15.
5.4.3 Average speed
There are generally three different ways to estimate vehicle speeds in Vissim: using data from data collection points, data from the “Vehicle” object and data from the “Network Performance” object.
At every time step 푘 (with a duration of 60s), the average instantaneous speed of every vehicle 푣푚,푘 of this time step is obtained by accessing the “Speed” attribute of the “Vehicle” object via COM. The average speed per time step 푣̅overall,푘 and the average overall speed
푣̅overall are then calculated as follows:
푀 1 푣̅ = ∑ 푣 , overall,푘 푀 푚,푘 (13) 푚=1
퐾 1 푣̅ = ∑ 푣̅ , overall 퐾 overall,푘 (14) 푘=1
with 퐾 standing for the total number of time steps. The MATLAB function “nanmean” is used, as vehicles that are not currently in the network have a speed of NaN.
For the speeds inside the PN, we use an elementwise matrix multiplication of the vehicle in
PN matrix 퐴in PN as in Table 13 with the matrix 푉 containing all speed values for every vehicle and time step 푣푚,푘:
푉PN = 퐴enter/leave ∙ 푉. (15) Missing values are filled with NaN, therefore, the average speed in the PN
푣̅overall,PN can be calculated also using equations 13 and 14, even though 푀 is larger than the number of vehicles that have ever been in the PN after the end of the simulation run.
Note that this procedure forms an average over instantaneous speeds, which is in theory, according to the supervisor Anastasios Kouvelas, not the proper measure for average speed. For this reason, a comparison with the “AvgSpeed” attribute of the “Network Performance” object (serving as ground truth) was performed. The deviation of the average speed between
75 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
the ground truth and the vehicle speeds is less than 0.5% both for the average speed and for all speed values over time. Therefore, the use of the “Vehicle” object speeds is deemed in order. This uncommon approach is needed as it is the only way to differentiate between speeds inside the PN, and in the whole network. The speeds from the data collection points were not used due to the large deviation from the ground truth (around a factor of 2 in difference).
5.4.4 Total vehicle delay
The total vehicle delay 푑푒푙푡표푡 is estimated in the same way as VHT and VKT. The relevant attribute is “DelayTm” from the “Vehicle” object, which is cumulative. 푑푒푙푙푎푠푡,푚 is the delay at the last time step the vehicle 푚 is in the network (row maximum of a table similar to Table 15).
푀 1 푑푒푙 = ∑ 푑푒푙 (16) tot 3600 last,푚 푚=1 Vehicle delay is evaluated separately for the whole network and the PN only. For the delay inside the PN, we have:
푀 1 푑푒푙 = ∑ 푑푒푙 − 푑푒푙 , PN 3600 PN,leave,푚 PN,enter,푚 (17) 푚=1
where 푑푒푙PN,leave,푚 is the total delay when a vehicle leaves the PN and 푑푒푙PN,enter,푚 is the total delay when a vehicle enters the PN. This is done by a similar matrix multiplication as for
VHT, with 퐷 a matrix containing all delay values per vehicle and time step (푑푒푙푚,푘):
퐷PN = 퐴enter/leave ∙ 퐷. (18)
푑푒푙PN,leave,푚 and 푑푒푙PN,enter,푚 are then again the row maxima or minima of 퐷.
5.4.5 Delays at gates
Using Vissim’s travel time measurement feature, it is possible to measure the delay of each vehicle at the gating traffic lights. This is done by comparing the freeflow travel time with the actual travel time on the defined section. At every gating traffic light, a travel time measurement section is defined manually, from the beginning of the queuing space (as defined in Table 11) up to just after the stop bar. Vissim allows to directly get the delay of the last time step at gate 푠, 푑푒푙gate,푠,푘. The total delay at all gates over the whole simulation is then:
76 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
퐾 푆 1 푑푒푙 = ∑ ∑ 푑푒푙 , gate,푡표푡 3600 gate,푠,푘 (19) 푘 푠
for the gates 푠 ∈ 푆. This measure is also relevant for the no-control scenario: The gating traffic lights let vehicles pass almost without any hindrance. However, there are potential spillbacks from downstream intersections, that can cause a queue at a gating traffic light. This is especially the case for gating traffic lights 356, 344 and 379 in the baseline.
5.4.6 Number of stops
The number of stops 푠푡표푝푡표푡 is calculated similarly as VHT, VKT and total vehicle delay. The relevant attribute is “NumStops” from the “Vehicle” object. We have:
푀 푠푡표푝tot = ∑ 푠푡표푝last,푚, (20) 푚=1
with 푠푡표푝last,푚 the (cumulative) number of stops of vehicle 푚 at the last time step it is in the network. This value corresponds to the row maximum of row 푚 in a table similar to Table 15, filled with “NumStops” values.
5.4.7 Percentage of vehicles in a queue
The attribute “InQueue” of the “Vehicle” object contains a logical value 푞푢푘,푚 stating for every vehicle and time step whether it is in a queue at the moment (definition of being in a queue similar to the queue length measurements in Figure 33). The share of vehicles in queue per time step 푞푢푘 is:
푀 ∑푚=1 푞푢푘,푚 푞푢푘 = , (21) 푁푘
with 푁푘 the accumulation at time 푘. The overall average percentage of vehicles in queue is then:
퐾 1 푞푢 = ∑ 푞푢 , 퐾 푘 (22) 푘=1
which gives a measure of average congestion. For the PN value, at every time step, the number of vehicles in a queue inside the PN is divided by the total number of vehicles inside the PN at that time, very similarly as for the average speed inside the PN (equation 15).
77 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5.4.8 Maximum relative queue length
This value is not the average relative queue length at the gates, but the maximum relative queue length that has ever occurred during the whole simulation run. This value gives a measure of the “worst-case” concerning queue lengths at the gates.
5.4.9 Excess green time due to QM
The excess green time is simply the sum of all negative green times, which is the sum of all negative values of 𝑔푓푖푛푎푙,0 in equation 8 (before truncating them to 1s). This value should equal to zero and is different from zero when the queues are getting longer, so that queue management decides to modify the controller inflow decision.
5.4.10 Number of vehicles served
The number of vehicles served, which is mostly used for validation, is simply the number of rows of the matrices used for VHT, VKT, total vehicle delay and number of stops. It should be equal in all scenarios. If this is not the case, comparisons of performance indicators must be interpreted with care.
5.5 Structure of code
The algorithm that executes BBC and PI control as well as the baseline scenarios is coded in MATLAB. Its structure is explained here and shown graphically in Figure 34. After establishing a connection with Vissim and loading the network, all needed variables, constants and settings are defined. The code has two main blocks, of which only one is executed: One block is used for BBC, the other one for PI. Both blocks look similar in general structure. There is a loop over the simulation time, in steps of one second. The simulation stops, whenever the predefined time step has been reached (60 seconds). Then, the current occupancy, flow and speed values are measured using the data collection points. Also, data concerning the evaluation measures such as delays, queue lengths, VKT, and VHT is collected. The number of vehicles in the whole network and inside the PN is recorded for every time step. In the BBC case, there is a check if the set point of occupancy is exceeded. If it is, then only the minimum possible inflow into the PN is allowed. Otherwise, the normal adaptive VisVAP logic is used. After this check, the green times are modified using a simple queue management strategy. Then follows a lengthy part that sorts the green times in ascending order, then stops the simulation whenever the end of the green time of one gating traffic light is reached, and then switches it to red. In the 2nd block (PI controller), the basic
78 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
structure of the code with a loop over the simulation time and breaks after every time step is very similar. Also, the same data is collected in the beginning. But the PI controller is already active when the occupancy reaches 3% of the set point. As the PI controller needs the inflow of the previous time step as an input, and this variable is unknown when the PI controller operates for the first time, it is simply measured using data collection points at the gating locations. Otherwise, inflow data from the last time step is used. The set point of occupancy is then slightly modified to a “band” with a width of 1% around the ideal set point. This is to obtain a smoother behaviour of the controller. Then, the PI controller calculates the admissible inflow into the PN for this time step. The degree of filling of the queuing spaces is then calculated and used as input of a similar queue management strategy as in the BBC case. Afterwards, the same lengthy code is used to sort the green times and turn the traffic lights red again, after the individual green times have elapsed. The final part of the code is common for both controllers. It calculates all mentioned performance indicators both for the whole network and inside the PN and generates plots such as the MFD, time-series of occupancy, relative queue lengths, etc. Finally, the workspace is saved for later use and a *.txt-file containing the performance indicators is produced.
Note that the runtime of the model using BBC is around 110 minutes, and around 125 minutes using the PI controller (for the given demand of 2015). These figures are valid for a workstation equipped with an Intel Core i7 quad-core processor with 3.4 GHz.
79 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 34: Structure of MATLAB code. Left branch: BBC, right branch: PI
80 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
5.6 Analysed scenarios
This section shall describe which analyses are of interest in this thesis, before the next section moves on to presenting the results.
It is important to prominently mention one essential aspect of this part: During the process to build up and run the simulation, it became clear that with the given infrastructure and demand, it is not possible to introduce perimeter control such that the traffic within the perimeter constantly operates at critical occupancy (and maximum flow), and that the queues at the gating locations are in a range which is bearable for the surrounding network (i.e. not exceeding 100% of the queueing space). The reason is a lack of queueing space. Therefore, for each of the two control algorithms, three scenarios are presented. They attempt to demonstrate the trade-off between the traffic situation with the PN, and queueing lengths at the gating traffic lights.
• A system state with maximum flow within the PN (and very long queues with spillbacks at the border of the PN) → max. flow within PN • A system state with reasonable queue lengths not leading to spillbacks, but with high occupancy inside the PN, with an MFD predominantly in the congested branch → short queues • A state approximately in the middle of these two extremes → best trade-off
The scenario for which VHT is minimised according to (Haddad & Shraiber, 2014) is “max. flow within PN”.
For the same scenario, the two control algorithms use different set points, because they have different behaviour regarding overshoots. Note that the results of the “short queues” scenario will be nearly identical to the baseline, as the baseline is the scenario with the shortest queues possible. The critical occupancy values in Table 16 per scenario have been found through trial and error, such that the controller behaves as desired and the scenarios are sufficiently different from each other.
Table 16: Critical occupancy per scenario
Scenario Bang-bang PI control control max. flow within PN 16% 12% short queues 47% 40% best trade-off 35% 21%
81 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Moreover, five demand levels will be analysed:
• 100%, representing the demand of 2015, as explained in Section 4.2.4 • +30%, representing the (hypothetical) demand of 2040 • +70% • +100% • +180%
(Kanton Aargau, 2019c) mentions in the scope of OASE that the number of inhabitants in the region Baden-Wettingen will increase by 30% until 2040. Assuming the modal split will stay constant, this leads to an increase in the number of car journeys by 30%. Note that this will most likely not be the case in reality, as public transport and bicycle infrastructure will improve significantly. The federal office for spatial development predicts a passenger kilometre increase of individual motorized traffic of 18% between 2015 and 2040 (Bundesamt für Raumentwicklung, 2016). The 30% increase can, therefore, be seen as upper bound or “worst case”.
The demand levels larger than 100% are of interest mainly because the analysis will show that gating is not beneficial for the demand of 2015, as shown in Section 6, for the reason that there is not enough congestion in the PN for an efficient application of perimeter control (see Section 6.2). Therefore, the scenarios with the larger demand try to prove that gating can be beneficial for the network in these cases. However, note that with the demand larger than 130% of the 2015 numbers, queue lengths will become excessive in any case, because today’s road infrastructure was not built to handle these large amounts of traffic. Therefore, in all scenarios with increased demand, queues at the perimeter border and their effects on upstream intersections were neglected, and queue management was deactivated. Also, it is obvious that with the doubling of demand (or even more), gridlock and excessive spillbacks will occur. The purpose of these scenarios is to analyse if perimeter control can work in these extreme cases.
Because the simulation needs to run until the network is (nearly) empty, the simulation time needed to be increased from the 4h in the standard demand to 7.5h for +30% demand, 9.5h for +70% and +100% demand, and 12h for +180% demand. Note that the scenarios with increased demand lead to a higher run time of the simulation for two reasons: first because of the longer simulation time, and second because of the higher number of vehicles in the network slowing down computation.
82 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
6 Results and Discussion
The results section of this thesis shall show the outcomes of the no control (baseline) case and compare them with the outcomes of perimeter control with BBC and PI control, for the standard demand of 2015 and for the three scenarios presented in Section 5.6. The comparison will be done visually and by using the evaluation measures mentioned in Section 5.4. Then, the results of the scenarios with increased demand are presented and discussed.
6.1 No control / baseline (demand = 100%)
Figure 35 and 36 show the MFDs obtained using simulation data from Vissim, for the 20% most congested detectors and all detectors, respectively. The plots include data from 13 replications. Note that unlike a few later plots, no averaging between the seeds for these MFDs has been performed to show the scatter. For the case of the 20% most congested detectors (which is used to derive the critical occupancy for perimeter control), the capacity flow can be estimated to be around 450 veh/h, and the critical occupancy is in the range of 17- 23%. For the MFD using data from all detectors, the capacity flow is only around 200 veh/h and the critical occupancy is around 5-8%. These values are significantly lower than when using the congested detectors only, because some detectors have very low or even zero traffic flow. Due to scatter, an exact specification of critical occupancy is not possible when examining empirical MFDs.
83 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 35: MFD (20% most congested det.) for baseline. 13 replications.
Figure 36: MFD for all detectors. 13 replications.
84 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 37 shows a curve of the number of vehicles in the simulation over time. The different lines represent different replications. The maximum number of vehicles in the simulation is around 4500. This figure shows quite impressively that the differences between the random seeds are significant: one simulation run has a maximum number of vehicles in the network of only around 3600, which is 20% less.
A plot of occupancy over time (for the 20% most congested detectors) of the baseline can be seen on Figure 38. The occupancy reaches values of around 52%, which clearly exceeds the critical occupancy.
Figure 37: Number of vehicles over time. 13 replications. Note that the simulation time was later increased to 4h, to allow the network to clear entirely.
85 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 38: Occupancy over time inside PN, for 20% most congested detectors. Data from 6 replications. Figure 39 shows the queue length at the gating traffic lights, averaged for 6 replications. Naturally, the curves take a similar shape as the time-series of occupancy in Figure 38. As described in Section 5.4.5, there are spillbacks from downstream intersections for traffic lights 356 (Ehrendingerstr.) and 344 (Wylerloch) that cause (relatively short) queues at the gating traffic lights also in the baseline. The spillback at traffic light 356 is caused by the roundabout (intersection of Sonnenbergstr., Ehrendingerstr. and Wettingerstr.) that is controlled by traffic light 354 (Schartenstr.), and the one at traffic light 344 by spillback from the traffic light 341 (Martinsberg). Note that the reason for the queue length to not exceed 1200m for traffic light 356 is not that there is not more demand, but it is due to the geometry of the given Vissim network. This causes the relevant vehicle input upstream of traffic light 356 to hold back vehicles until space is freed up. However, this does not impact the course of the simulation, as the total vehicle input remains constant.
Finally, Figure 40 shows the inflow into the PN, as measured by loop detectors at the gating traffic lights. It is plausible that the shape of this curve roughly follows the demand curve. The deviations are due to time delays between vehicle generation and measurement at the gating locations.
86 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 39: Queue length at gates in the baseline. Average of 6 replications.
Figure 40: Inflow into PN, baseline / no control. Average of 6 replications.
87 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
6.2 Comparison of the scenarios (demand = 100%)
The results in Table 17 compare the baseline with three scenarios each of bang-bang and PI controllers. The bar plots in Figure 41 and Figure 42 show the same kind of information in relative numbers, always with the baseline as reference. It becomes clear that the baseline scenario performs best, meaning that it has the lowest value of VHT, the lowest vehicle delay, the shortest queues at gates, and the highest average vehicle speed. What is also interesting is that the scenario “max. flow in PN”, which is a strict application of perimeter control, performs worst in terms of VHT, average speed, and vehicle delay (all considering the whole network). This is true both for BBC and PI control. At first sight, this contradicts the scientific findings presented in Section 2.2. When considering the findings, it is plausible that the scenario “short queues” (with the lowest aggressiveness of perimeter control) is the best of the three scenarios, because it is very close to the baseline in all performance indicators. Regarding the delays at the gates, note that BBC performs significantly better than the PI controller for all three scenarios. The difference of the delays at the gates between the algorithms is biggest for the “max. flow in PN” scenario, but also substantial for the “best trade-off” scenario. For the “max. flow in PN” of PI control, the delays at gates are so large that not all vehicles can be served. This is confirmed by the percentage of vehicles in a queue, which tends to be higher for the PI controller than for BBC (and the baseline). The numbers of average speed inside the PN in Table 17 show that the scenarios “best trade-off” and “max. flow in PN” perform better than the baseline inside the PN, for both control algorithms. A similar finding yields the analysis of the speed time series inside the PN in Figure 51: In the scenarios “best trade-off” and “max. flow in PN” for both control algorithms, the average speed inside the PN is larger than the overall average speed of the baseline during most of the simulation time. In comparison, the baseline and the scenario “short queues” have a lower speed over time inside the PN. Also, the vehicle delay inside the PN for “best trade-off” and “max. flow in PN” is lower for both control algorithms compared to the baseline. These facts indicate that the most aggressive form of perimeter control but also the trade-off scenario successfully keep excessive traffic volumes outside of the PN, and therefore confirm that the control algorithms were properly implemented. Figure 51 also shows that perimeter control using PI control is especially beneficial inside the PN towards the end of the simulation (offset of congestion), when the biggest speed differences to the baseline occur. Concerning speeds inside the PN, BBC performs significantly worse during the offset of congestion and hardly any better than the baseline, possibly because the control actions are too erratic, and the traffic flow therefore instable.
88 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 17: Summary of results (with QM), averages of 6 replications. Most important indicators in bold.
Evaluation Baseline BBC (max. BBC BBC PI (max. PI (short PI (best criterion flow in (short (best flow in PN) queues) tradeoff) PN) queues) tradeoff) VHT [h] 7426 10’417 7578 8066 13’587 7788 9226 VHT in PN [h] 4532 2804 4388 3706 2177 4639 3120 VKT [km] 153’874 155’580 155’756 155’681 142’783 155’695 154’664 Avg. speed overall 25.7 24.4 25.5 25.3 15.4 24.1 20.9 [km/h] Avg. speed in PN 23.7 27.3 23.6 24.8 30.8 22.5 28.0 [km/h] Total vehicle 4667 7631 4788 5278 11’080 4999 6461 delay [h] Vehicle delay in 2978 1407 2840 2227 962 3076 1713 PN [h] Delays at gates [h] 83.9 378.1 106.6 183.2 1014.5 105.5 558.1 #Stops per veh-km 6.2 8.4 6.0 6.0 14.7 6.4 6.4 % of veh. in 45 47 45 46 67 48 55 queue [-] % of veh. in queue 53 44 52 51 42 56 45 in PN [-] Max. rel. queue 0.64 5.22 1.71 3.90 5.22 1.09 2.66 length [-] Excess green time -- 1707 0 167 5420 0 1183 due to QM [s] Veh. served 50’823 50’823 50’823 50’823 49’516 50’823 50’816
89 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 41: Relative differences, baseline=1. VHT, avg. speed and vehicle delay
Figure 42: Relative differences, baseline=1. Delays at gates and max. rel. queue length Judging from these results, the reason for gating not being beneficial for the whole network for the examined scenarios seems to be that the network is still relatively uncongested. This can be seen, for example, when examining the MFD of this work in Figure 35. It does have a congested, descending branch. But it is not as steep and does not contain any gridlock or close-to-gridlock situation. During the most congested time steps, the network has an average
90 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
flow that is still around 75-80% of the capacity flow. Refer to the Barcelona example from (Kouvelas, et al., 2017) and specifically to Figure 43 below for a counter-example. The production of the time steps with the highest vehicle accumulation is less than half of the production near the critical accumulation, and in subregions 1 and 3, jam density or gridlock are nearly reached. Also, the average speed inside the PN is around 6.3 km/h in the no-control case in (Kouvelas, et al., 2017), but 23.7 km/h in this thesis. Therefore, gating, in this thesis, creates “unnecessary” queues at the border of the perimeter, and the result is a worse overall traffic situation. Section 6.5 will therefore examine if gating in Baden can be beneficial for much higher demands. Note that the low amount of congestion in the network is not the main reason for perimeter control not being beneficial for the overall network. The main reason is shown in Section 6.6.
Figure 43: Production MFDs for the Barcelona network. Left: whole network, right: 4 subregions. Source: (Kouvelas, et al., 2017) Figure 44 compares the green splits of the gating traffic lights of the PI controller and BBC. The green split is defined as green time divided by cycle time. For the PI controller, it roughly corresponds to the output of the PI controller that is fed to the gating traffic lights (apart from the influence of QM). For all time steps without data (marked in grey), the controller is not active, and the traffic-adaptive signal control of the baseline is active. It can be seen that the PI controller delivers a relatively smooth control output. The green phase duration varies, but there are no big jumps in a short time frame, except for traffic light 315, where after around 100 minutes, QM becomes active. For BBC, the traffic-adaptive signal control is active most of the time and lets vehicles pass almost without hindrance. This corresponds to a green split of almost 1. However, when the bang-bang controller is active, green splits suddenly drop to 10% – 25%. This means there are huge jumps in green time when the controller switches on or off. This non-smooth behaviour is also shown in Figure 45, which shows the inflow into the PN for all three scenarios, averaged for 6 replications. In the PI case, the dotted line is the measurement by the data collection points at the gates, and the solid line is the output of the
91 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
controller, whereas in the BBC case, there is only the measurement by the data collection points at the gates. Also here, it is apparent that the result delivered by BBC is not smooth at all, but very erratic. The inflow ordered by the PI controller is very smooth and a bit less so for the actually measured inflow, but it is still much smoother than for BBC. The top plot of Figure 45 shows the difference over time between ordered and actual flow, which is what Figure 54 presents in an aggregated way. For the scenario “short queues”, the difference between the ordered and actual flow in Figure 45 is the lack of demand.
92 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 44: Green splits of gating traffic lights for PI controller (above) and BBC (below), scenario “best trade-off”. For grey areas, the controller is inactive (and hence, the green split is 1). Figure 46 shows the number of vehicles in the whole network, separately per control algorithm. The averages of 6 replications of the three scenarios are shown. The scenario “max. flow in PN” leads to very long queues at the perimeter border, which is why there are more vehicles in the network during the peak hour. The lower the accumulation, the better, and therefore, this plot also shows that the baseline scenario performs best overall. Figure 47 shows the time series of occupancy inside the PN. The shape of the curve is comparable to
93 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 46, but the curves of the scenarios “max. flows in PN” and “best-tradeoff” are much lower in the occupancy curves. This is because the time series of vehicles concern the whole network, whereas the time series of occupancy concern only the PN. This means that even if the total number of vehicles is somewhat comparable for all scenarios, the distribution of vehicles (inside compared to outside the PN) still is totally different. The reason for this is that the lower the set point of occupancy, the more vehicles are outside the PN and the fewer vehicles inside. Figure 46 also shows that for the “max. flow in PN” scenario of PI control, the network is not completely empty at the end of the simulation. This corresponds to Table 17, which shows that the number of vehicles served in this scenario is a bit lower than for the other scenarios.
94 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 45: Inflow into the protected network. PI (top): Output of controller (solid line) and as measured by data collection points at gates (dotted). BBC (bottom): as measured by data collection points at gates. Average of 6 replications
95 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 46: Number of vehicles in the whole network. Average of 6 replications
96 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 47: Time series of occupancy inside PN (from 20% most cong. det.), for BBC and PI
97 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 48: MFD with no control and the three scenarios of BBC (top) and PI (bottom). Averages of 6 replications. Data from first 2 hours.
98 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 48 (top) shows the MFD of the baseline and the three BBC scenarios. It can be seen that all scenarios have the same capacity flow, which is plausible because it is given by the infrastructure. However, the average flows of the scenarios “max. flow in PN” and “best trade-off” start dropping when a certain occupancy is reached, which approximately coincides with the set point of the controller. For the PI case, the behaviour is different, which is shown in Figure 48 (bottom). The flow values (and especially the capacity flow) for the scenarios “max. flows in PN” and “best trade-off” are lower than for the baseline. They behave differently than the baseline from the beginning onwards. For both control algorithms, the MFD reveals that perimeter control is not beneficial. Note that both MFDs only contain data up to the simulation minute 120 (up to the beginning of the offset of congestion). The remaining two hours (offset of congestion) are not shown here due to hysteresis loops, but are shown in the MFDs in Appendix A.1 (refer to Figure 68 and Figure 69 on page 136). What is interesting during the offset of congestion is that the average flows of the scenarios “max. flows in PN” and “best trade-off” are higher than for the baseline and the scenario “short for queues”. Still, because the onset of congestion shows higher flows overall, the losses in flows for “max. flows in PN” and “best trade-off” during the onset dominate the gains during the offset.
99 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 49: Speed-MFD with baseline and the three scenarios of BBC (top) and PI (bottom). Average of 6 replications
100 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 49 shows the speed MFDs for both control algorithms. It is interesting to see that all scenarios follow approximately the same curve but contain only parts of the curve of the baseline scenario, due to the limited ranges of occupancy. Note that these speeds cannot be compared with the speeds shown in Table 17, Figure 50, and Figure 51, as the MFDs contain speeds as measured by loop detectors, and the other plots contain vehicle speeds. Refer to Figure 70 in Appendix A.1 for a time series of detector speeds, that were not used any further in this thesis.
Figure 50 shows time series of speed, for the whole network, as well as for both control algorithms. As can be seen in the MFDs in Figure 68 and Figure 69 in the Appendix A.1 on page 136, and also in the BBC case here, the scenario “max. flow in PN” performs worse than the baseline during the onset of congestion, but better than the baseline during the offset.
Figure 51 shows a very similar result compared to Figure 50, but the speeds are only the vehicle speeds inside the PN, and not for the whole network. The higher scatter of Figure 51 compared to Figure 50 is due to the lower number of replications, but the tendency is clear: The control algorithms help to keep speeds inside the PN high, so the lower the set point of the controller, the higher the speeds in the PN, as desired.
101 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 50: Speed over time, for all scenarios and both control algorithms. Whole network, average of 4 replications
102 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 51: Speed over time, for all scenarios and both control algorithms. Only in PN, average of 3 replications
6.3 Comparison of BBC and PI
The results in Table 17 indicate that BBC performs better than PI control in all scenarios concerning VHT, average speed, and vehicle delay in total and at the gates. On the other hand, PI control leads to shorter maximum queue lengths at the gates. The reason for both observations is that BBC is theoretically the optimal control tool, as it efficiently keeps the network at the set point, but it behaves unpredictable and in a very erratic way. This leads to unstable vehicle flow and therefore longer maximum queue lengths at the gates. To be precise, with BBC, the total delays at gates are lower than with PI, but the variability of the delays at gates and the extreme queue lengths are larger. When only the PN itself is concerned, the PI controller is the better choice regarding all mentioned performance indicators, probably due to the smoother behaviour. The biggest difference between the performance of PI control and BBC is during the offset of congestion.
103 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Regarding the implementation of both control algorithms, it is obvious that BBC is much easier to implement. It does not require any fine-tuning like PI control does and is computationally more efficient. Also, 퐾푃 and 퐾푖 must be updated when the demand changes, and therefore need to be fine-tuned again. BBC, on the other hand, is robust to changes in demand. The big advantage of PI control is that it behaves much smoother.
6.4 Selected results of PI control (demand = 100%)
Figure 52 and 53 below show the time series of occupancy, as well as the MFDs for the 20% most congested data collection points only, for the scenario “max. flow in PN”. These figures are interesting mostly because in all previous figures of Section 6, averages of 6 replications were shown. Here, data from the 6 replications are plotted separately, which shows the scatter arising from the stochastic variations caused by different random seeds. Figure 52 shows the strong overshoots of the PI controller. While the set point for “max. flow in PN” is ô = 12%, the average maximum occupancy is around 21%. As illustrated in Figure 31, this is clearly an overshoot phenomenon and no steady-state error. The fast decrease in demand does not allow the controller to reach its steady state. A further decrease of 퐾푖 is not the solution, as it again increases the steady-state error and the rise time.
Figure 52: Time series of occupancy for PI, max. flow in PN
104 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 53: MFD (20% most cong. det.), PI, max. flow in PN The three bar plots in Figure 54 below compare the flow ordered by the controller with the actual traffic flow ( demand) that passed the gating traffic lights, for the three different scenarios. The y-axes are scaled the same in all three plots to highlight the differences. Firstly, the higher the set point of occupancy, the higher the inflow calculated by the controller, because the controller tends to decrease the number of vehicles outside the PN and increase the number of vehicles inside the PN. Secondly, it is obvious that for a high set point of occupancy, the controller orders a flow that significantly exceeds the demand. For the trade- off scenario, the ordered and actual flows are approximately the same. For the scenario with a very low set point of occupancy, the actual flow is higher, on average, than the ordered flow. This is the effect of the queue management, that partly overwrites the output of the controller, and leads to excess green times, as explained in Section 5.3.4.
105 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 54: Ordered and actual flow for the three scenarios
106 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
6.5 Results of scenarios with increased demand
Due to notion that demand might not be sufficient for beneficial perimeter control, increased demand scenarios were evaluated. Table 18 and 19 show the results of the scenarios with a demand increase of 30% and 70%, respectively. The corresponding statistics for the demand increase of 100% can be found in Table 21 in Appendix A.3. Note that evaluation measures concerning the queue situation at gates or queue management, such as the maximum relative queue length or the excess green time due to QM, are missing because this section will focus on the effect of perimeter control, and disregards effects of queues. Consequently, QM is switched off for these results. Due to the large demand, already in the +30% scenario the queues get considerably long, and the maximum relative queue length exceeds 5 in every scenario.
Table 18: Results with increased demand (+30%), averages of 3 replications
Evaluation criterion Baseline BBC (max. BBC (best PI (max. PI (best flow in PN) trade-off) flow in PN) trade-off) VHT [h] 19’192 33’826 22’636 39’434 26’765 VHT inside PN [h] 10’980 11’974 9902 9699 8186 Avg. speed overall [km/h] 16.7 12.0 14.2 9.5 13.9 Avg. speed in PN [km/h] 18.7 18.9 18.2 22.8 20.7 Total vehicle delay [h] 15’617 30’270 19’049 35’970 23’202 Vehicle delay in PN [h] 7905 8170 6809 6025 5127 #Stops per veh-km 13.5 23.2 16.6 26.5 18.1 % of veh. in queue 60 71 63 77 67 % of veh. in queue in PN 66 71 67 61 64 Veh. served [-] 65’994 65’994 65’994 65’994 65’994
107 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Table 19: Results with increased demand (+70%), averages of 3 replications
Evaluation criterion Baseline BBC (max. BBC (best PI (max. PI (best flow in PN) tradeoff) flow in PN) trade-off) VHT [h] 44’540 66’583 64’167 68’730 61’737 VHT inside PN [h] 24’404 31’642 31’953 29’566 25’138 Avg. speed overall [km/h] 11.4 6.6 8.1 4.8 7.5 Avg. speed in PN [km/h] 16.3 13.7 13.0 13.8 15.8 Total vehicle delay [h] 39’913 66’034 61’604 65’094 60’187 Vehicle delay in PN [h] 18’509 23’478 23’845 21’124 17’764 #Stops per veh-km 19.9 35.4 30.0 44.9 29.8 % of veh. in queue 70 80 78 91 79 % of veh. in queue in PN 74 80 80 89 76 Veh. served [-] 86’230 83’049 86’207 68’140 85’336
For +30% demand, the baseline scenario scores best in terms of overall VHT and overall speed. On the other hand, concerning all performance indicators inside the PN, both PI control scenarios and partially also the “best trade-off” scenario of BBC perform better than the baseline. Overall, the PI controller delivers significantly better results inside the PN than BBC. Therefore, perimeter control can show a large improvement inside the PN. Compared to the standard demand shown in Table 17, there is an increase of overall VHT, total vehicle delay, and number of stops per veh-km of a factor 2-4. This means that the results do not differ substantially from the ones in Table 17 with the standard demand. For +70% demand, the baseline scenario performs best of all, also inside the PN. Perimeter control is worsening the situation also inside the PN. Especially bang-bang control performs poorly. The reason can be seen in Figure 55. Both BBC scenarios fail to reach a steady-state around the set point; especially the “max. flow in PN” scenario shows large overshoots of occupancy compared to the set point of 16%. The “max. flow in PN” scenario of PI control holds back many vehicles at the gates, so that the number of vehicles served is around 20% lower than for the baseline. It follows that the simulation ends when there are still lots of vehicles in the network, which is shown in Figure 59. The time frame of the simulation is 9.5 hours, which underlines the large time it takes to serve all these vehicles with strict perimeter control. Theoretically, there are no more vehicle inputs after 2.5 hours (see Figure 18), but Vissim continues inputting vehicles afterwards, if there is no road space for them at the specified time. The average speeds inside the PN still seem very high for this high demand. This does not mean that there is no congestion, but that some links are highly congested with a speed of close to zero, and other links (smaller local streets) still have free-flow speed. This
108 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
is caused by the static routes, such that drivers cannot adapt their routes to congestion. Interestingly, the overall VHT and the total vehicle delay are around two to three times as high as for the +30% demand scenario, even though the demand increases by only around 30%. Same as for the large increase already observed at the +30% scenario, this indicates that important performance indicators are not proportional to traffic volume but grow much faster. The following figures show the timeseries of occupancy, of the speed (overall and inside PN), and of the number of vehicles inside the network, as well as the MFDs. When looking at Figure 55, 57 and 59, it becomes clear that the scenarios of +100% and +180% demand lead to total gridlocks, spillbacks and excessive travel times, because the average speed falls to almost zero, and does not increase again even after several hours without new demand. Also, the number of vehicles falls only very slowly after reaching the maximum (for +100%) or does not decrease anymore (+180%). The road infrastructure of Baden can simply not cope with these large demands. The results of the demand by 100% and 180% are therefore not interesting. The MFDs for increased demand in Figure 56 show a similar behaviour as the baseline MFDs, such that for BBC, the flows are very similar to the baseline, until they start dropping when reaching the critical density. For the PI controller, average flows are lower from the very start, but they experience a slower drop in their decreasing branch than for BBC. The MFDs for the scenario +100% and +180% consist almost only of a descending branch, and most time steps experience gridlock-like situations. Figure 71 in Appendix A.1 shows the MFDs including the offset of congestion. The speed timeseries in Figure 57 (for the whole network) and Figure 58 (for the PN only) largely confirm the findings above. Considering the whole network, the speeds of +100% and +180% demand are quickly dropping to almost zero and remain there, indicating gridlock. Moreover, for +30% and +70% demand, the baseline shows the highest speeds on average, with perimeter control speeds exceeding baseline speeds only during short intervals. Considering the PN only, the PI “best trade-off” and BBC “max. flow in PN” scenarios perform better until the offset of congestion begins (~150min). From that point onwards, the PI “max. flow in PN” scenario performs better. For +70% demand, the baseline performs best from around 150min onwards, because of overshoots in occupancy of gating as mentioned before. Therefore, perimeter control is not beneficial for the overall network in Baden, no matter how high the traffic demand. It is, for the standard demand and the increase by 30%, beneficial for inside the PN. The main reason for this result cannot be the lack of congestion, as assumed previously. The reasons for this are explained later in Section 6.6.
109 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 55: Occupancy over time of the 4 scenarios. Averages of 3 replications.
110 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 56: MFDs for the 4 scenarios, containing data of the first 180 simulation minutes. Averages of 3 replications.
111 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 57: Average speed (whole network). Average of 3 replications. Note that the sudden end of a line is due to an empty network.
112 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 58: Average speed (inside PN). Average of 4 replications. Note that the sudden end of a line is due to an empty network.
113 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 59: Number of vehicles over time. Averages of 3 replications.
6.6 Why perimeter control is not beneficial
The results so far have shown that perimeter control may improve the traffic conditions inside the PN (regarding average speed, VHT or vehicle delay) compared to the baseline. However, for the overall network, perimeter control is not beneficial, as it leads to longer travel times, slower speeds and higher delays when the whole network is concerned. This has been shown to be true for the standard demand, and for the demand increased by 30%. For the demand increased by 70%, the traffic situation inside the PN is again worse with perimeter control, as explained above.
114 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
The reason why perimeter control can improve traffic conditions inside the PN, as desired, but fails to deliver an overall improvement is most likely that the PN is inhomogeneously congested. This means that the PN contains links with lots of congestion during the entire rush hour, while local streets nearby experience almost no traffic at all. This means that some vehicles entering the PN travel through congested links and are therefore delayed at the perimeter for good reason. Many other vehicles, however, pass through relatively uncongested links inside the PN, and therefore stopping them is detrimental to the system. This means that only vehicles contributing to congestion should be stopped at the perimeter. With this reasoning, it is obvious the baseline performs best because no vehicle is stopped unnecessarily at the gates, so no unnecessary delays are incurred. And obviously, the time gains achieved by those travelling on the congested links inside the PN do not outweigh the time losses of those that use the non-congested links inside the PN and are unnecessarily delayed at the gates. Thus, the network violates one essential requirement for using perimeter control, as mentioned in Section 2.2 (homogeneous distribution of congestion in PN). Figure 60 explains this phenomenon graphically. The traffic flows on every link are shown in red, and the perimeter in green. The higher the transparency of each link, the more traffic it carries. Note that every link carrying more than 1000 veh/h is shown in dark red, in order to increase the visibility of the seldom-used local streets. Not every link with high traffic flow is congested: The blue lines along the links denote the congested areas at the beginning of the offset of congestion in the baseline scenario. Almost always, only one direction of a link is congested (blue line only on one side). This figure shows that only a small part of all used links is congested, which is mostly the approaches to major intersections. In fact, almost all of Wettingen and Obersiggenthal (in the northwest) is uncongested. The same is true for the local streets in Baden’s Bäderquartier north of the old town. Note that a large part of the local roads in the whole network is never used (compare Figure 60 with Figure 11). This is due to the static (fixed) routes, due to the lack of DTA. In fact, the inhomogeneity of congestion corresponds to the lack of congestion that was previously assumed as reason for gating not being beneficial: The inhomogeneous distribution of congestion means that there is lots of congestion in some places and almost no congestion in many others. On average, this means that the amount of congestion is somewhere in between these extremes and is not enough to successfully perform perimeter control. With much more congestion on almost every link, the inhomogeneity problem would be solved too, and perimeter control would work as expected. Therefore, DTA most likely would lead to a shifting of demand to the small local streets, leading to a more homogenous spatial distribution of congestion, and also to perimeter control work better. Whether this shift to local side roads is desired from a traffic and urban planning perspective, is another topic entirely.
115 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 60: Map showing vehicle flows (in red), congested areas of baseline (in blue), and perimeter (in green). North is to the left.
116 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
This does not imply that perimeter control in Baden cannot function at all with the given demand. For perimeter control to work as intended, clustering of the network could be beneficial, as it increases the homogeneity of congestion of each protected region. The notion of inhomogeneous distribution of congestion can be proved using simulation data. Figure 61 shows the typical relation of the variance of occupancy with occupancy itself. At low levels of average occupancies (i.e. the beginning and the end of the simulation), there is a low variance of occupancy, which means that there is little traffic everywhere. With increasing average occupancy, the curve is steadily increasing, because even during the morning peak, there is never a high occupancy on all roads/detectors, especially not with static traffic assignment (fixed vehicle routes). As already explained in above, this means that there are always heavily congested roads, and at the same time roads with significantly less traffic. This is a clear hint that traffic is in fact not homogenously distributed in the network, even not among the 20% most congested detectors. Therefore, this finding delivers a confirmation of the explanations of this section. Note that the shape of the curve in the plot is entirely plausible, considering that other researchers such as (Geroliminis & Sun, 2011) have found similar curves in their MFD study using data from Yokohama, Japan.
Figure 61: Variance of occupancy, random seed 2, demand = 100%
117 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
6.7 Evaluation of queue management strategy (demand = 100%)
As a side-note, this section shall show whether the queue management strategy presented in Section 5.3.4 actually works as it should. This is done by running the simulation with the setup below, with three different random seeds per setup, for the demand data of 2015.
• Bang-bang control with and without queue management strategy • PI control with and without queue management strategy
Table 20 below shows the average of the six simulation runs per setup, separate for each control algorithm and also for the two variants of queue management (“strong” and “weak”).
The results in the table indicate that for BBC, queue management fulfils its purpose to reduce travel times for the drivers. It reduces VHT and vehicle delays and increases average speed. The “strong” variant performs better than “weak” QM, which means that longer green times for congested links entering the PN are desirable. For PI control, queue management seems to have no significant effect, as the effect on VHT, average delay or speed is less than 1%. Still, it leads to the conclusion that analysing data from the variant with QM in Table 17 is reasonable, as the results are at least as good as without QM. Whether sophisticated QM strategies such as the optimisation-based strategy in (Keyvan-Ekbatani, et al., 2016) can help reduce VHT and increase speeds further, is as of now unclear.
Table 20: Evaluation of queue management strategy (ô = 32%), average of 6 replications
Evaluation Bang-bang control PI controller criterion no QM with QM with QM no QM with QM with QM (strong) (weak) (strong) (weak) VHT [h] 8690 7888 8293 7921 7941 7910 VKT [km] 155’489 155’770 155’666 155’717 155’716 155’776 Avg. speed 25.43 25.68 25.29 23.62 23.82 23.81 [km/h] Delays at 209 201 203 148 169 156 gates [h] Total vehicle 5906 5099 5506 5132 5152 5120 delay [h] Vehicles 50’823 50’823 50’823 50’823 50’823 50’823 served [-]
118 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
6.8 Heterogeneity of the network
As mentioned in (Keyvan-Ekbatani, et al., 2015b), the homogeneity of the network, such as a homogenous distribution of demand, is important for the performance of the controller and the proper functioning of perimeter control. Also, (Keyvan-Ekbatani, et al., 2015b) revealed that network production (e.g. VKT) and standard deviation of the link occupancy are inversely correlated, which could also be shown in this work, see Figure 62. It shows average curves from 6 replications with PI control, and the “best trade-off” scenario (ô = 21%). Therefore, if the variability of link occupancy could be further reduced, using smarter demand distribution techniques or partitioning of the network, higher production values could be expected.
Figure 62: Relation between occupancy standard deviation and production (average from 6 replications), demand =100%
119 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
7 Conclusion and outlook
7.1 Concluding remarks
The simulation and data analysis have shown that with the demand of 2015, which is given in the Visum model, perimeter control is not beneficial for the overall network but can improve traffic conditions inside the PN. The scenarios with increased demand have basically resulted in the same finding. Because of the inhomogeneous spatial distribution of congestion, perimeter control creates queues for many vehicles that should not be stopped at the gates, because they use non-congested roads inside the PN and do not contribute to congestion. In some sense, these vehicles passing through the PN on uncongested links correspond to the boundary flows 푞푏 in Figure 2, because there is no significant difference between boundary flows (that never enter the PN) and vehicles entering the PN, but not contributing to congestion there. So, perimeter control is not beneficial due to the too large delays caused to these boundary flows compared to the gains of these vehicles that travel faster on congested links inside the PN. This means that for the Canton of Aargau, implementing an MFD-based perimeter control system with today’s demand as shown in this thesis is rather not advisable.
Unfortunately, this thesis could only shed light on the theory behind today’s traffic management strategy but could not deliver a simulation-based assessment of its performance or compare it to MFD-based perimeter control, simply due to its high complexity. Therefore, it remains unclear whether today’s traffic responsive strategy using non-MFD-based gating is beneficial after all for overall VHT, although it certainly is beneficial for the quality of life inside the city centre due to less congestion there.
All results shown must be interpreted with care, because the simulation output might be far from reality: The microsimulation model lacks many important details such as public transport services and priority, bicycles, pedestrians, and many traffic lights. Another unrealistic aspect is the static route choice as implemented in the model used for this work, which makes drivers unable to adapt their route after the implementation of perimeter control. Moreover, the explanatory power of microsimulation results is always limited: They never are the truth, only a more or less coarse approximation of the truth.
The approaches to solve the problem of the spatial inhomogeneity of congestion are discussed in Section 7.2.
Should any perimeter control system ever be implemented in the region of Baden, it is essential to think about all the implications of such a system well in advance. Therefore, it is necessary to analyse possible reactions of all relevant stakeholders in advance. For example,
120 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
every affected municipality in the region of Baden must agree with the implementation of the policy and could otherwise block or delay the implementation by raising objections. Concerning perimeter control as implemented in this thesis, it is also questionable whether the residents living near the queueing spaces at the border of the PN will agree with the measures. Even though the author tried to optimise the location of the gating points in such a way that the queues are not in a built-up environment, some exceptions could not be prevented. This is the case especially at node 373 (Landschriber), where the queue can temporarily reach back all the way into the town of Kirchdorf. The same thing can occur at node 343 (Wylerloch), where the queues can reach the town of Turgi, or at node 356 (Ehrendingerstrasse), where the town Ehrendingen temporarily is reached. It would certainly be needed to seek the dialogue with the mentioned municipalities and residents, and possibly modify the system such that the negative effects on these stakeholders are less detrimental. The city of Baden and its intentions must be included in the planning process too, in order to have Baden approve the measures which will mostly take effects on cantonal roads.
Computation time is an important aspect of conducting microsimulations such as in this thesis. The rather high runtime of around two hours of the model with the demand of 2015 made debugging, testing and optimising the MATLAB code rather tedious and cumbersome, as evaluations can only be done after the simulation end. This problem was even more severe for the scenarios with higher demand (4 hours for +30% demand, 7 hours for +70% demand and up to 13 hours for the scenario with +180% demand), as more traffic on the network increases run time, and also the simulation time had to be increased. Unfortunately, Vissim does not – at the time of writing – truly support multi-core processors. This means that only one of the four CPU cores is used. If this issue could be mended, the simulation could potentially run at up to four times the speed. Similarly, it would be useful to have significantly faster computers available.
It has also become clear that, while in the literature very often being treated in separate papers (refer to Section 2.2), perimeter control and queue management do belong together. If the purpose of a perimeter control simulation is to apply a similar controller in reality, it does not make sense to focus on ideal traffic conditions with maximum flow inside the PN while neglecting the queues this may cause at the boundary. Both aspects need to be examined, as has been performed in this thesis, in order to get a system that can be deployed in practice. Unfortunately, one cannot optimise traffic flow within the PN and queueing at the perimeter at the same time: a trade-off is needed.
121 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
7.2 Further work and outlook
There are several gaps that this thesis leaves open for future work. The main reason for this is the vast amount of time needed to model the traffic infrastructure and demand in Baden in much larger detail. With greater resources, it would also be possible to include more modes of transport in the microsimulation, such as pedestrians, bicycles and public transport. However, including all buses including their schedules and bus priority at signalised intersections is cumbersome and would take a lot of effort. Moreover, with another Vissim license without any limitation concerning the number of signal controllers, it would be feasible to model all traffic lights in the area, and not only a subset of them. This would contribute to making the model more realistic and to increasing the explanatory power of the results. The caveat of increasing the level of detail in the model is the increased computation time.
One more aspect concerning traffic lights is relevant for future work: As of now, it is (unless the necessary time and financial resources are provided) not possible to model the signal logic that is used outside on the traffic light computer in a realistic way in Vissim. This is due to the mentioned lack of an interface between FESA and Vissim, as it already exists for other, more widespread kinds of signal control logic. If the developer of FESA programmed such an interface, it would be possible to model the traffic lights in a very realistic way with just a few clicks, provided that the FESA input file is given. Whether this makes sense for the developer, however, remains unclear, as FESA is only being used in a few cantons in Switzerland.
Moreover, bang-bang control and PI control are only two control algorithms of a vast array of possibilities. Therefore, one possible extension is the use of more sophisticated controllers, for example model predictive control.
It is unclear if a perimeter control system as modelled in this thesis could be implemented in practice with today’s loop detector infrastructure. While this work uses equally distributed loop detectors along the arterials, today’s traffic-responsive system uses detectors placed at signalised intersections, or slightly upstream. This means that loop detectors are not homogeneously distributed over the road network, and data from some arterials (the one without signalised intersections) cannot be collected at all. Whether this can prevent from conducting perimeter control successfully, must be proven by another study. If not, then the installation of additional loop detectors that are not connected to a traffic light, but feed information to the controller, must be considered.
This thesis has shown that the queueing spaces near the gating traffic lights are not sufficient to prevent the inside of the perimeter from exceeding the critical occupancy. Further work could show whether a perimeter control system using multiple layers (in a way similar to the
122 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
existing traffic-responsive strategy) could solve this problem, as several gating traffic lights at an arterial leading towards Baden’s centre have more queueing space than only one. However, this extension makes the coding more cumbersome. Of course, it would also theoretically be possible to build more lanes at the links, resulting in more available queueing space. Increasing the supply, however, is not what traffic engineering and management should nowadays aim at. Also, the queue management strategy used in this work is rather ad-hoc. Therefore, further work could replace it with a more sophisticated and systematic queue management strategy, that solves optimisation problem to keep all relative queue lengths the same over all gates, as done in (Keyvan-Ekbatani, et al., 2016).
Increasing demand and congestion in city centres in the future will help perimeter control systems gain relevance. On the other hand, the space for queues, which is already today very limited, will get even scarcer in the future, which has also been shown in this work with the scenarios of increased demand. A further study should examine if and how perimeter control systems might work in the city of Baden with forecasted demand from 2040 or 2050, while still offering reasonable queue lengths. Also, the planned infrastructure project OASE (see Section 3) could change car traffic demand substantially and will most likely also lead to another spatial and/or temporal distribution of demand. This means that a similar analysis like performed in this work would need to be done again in the scope of OASE, to analyse how and if perimeter control would work with the changed infrastructure and traffic flows.
Clustering of the network might help significantly increase network homogeneity by partitioning the network and implementing multi-region perimeter control. However, the implementation of multi-region perimeter control is much more difficult: Also, the flows between the subregions need to be controlled, so for every link crossing a boundary, a traffic light is needed. Considering the spatial distribution of the 20% most congested detectors in Figure 24, one cluster in the northwest of the PN (Nussbaumen) and one cluster in Baden city centre seems plausible, from a first visual analysis. Clustering algorithms could help verify this. Additionally, another Vissim license would be needed in order to model all traffic lights. Another possible solution, which is also a workaround for the license problem, is the definition of a much smaller perimeter, which could (as a suggestion) encompass the very centre of Baden with the most congested links, consisting of the intersections Schulhausplatz, Brückenkopf Ost, Schartenstrasse and, possibly, Bruggerstrasse between Schulhausplatz and the intersection with Brown-Boveri-Strasse, see Figure 63. Most links in this area are rather congested, therefore increasing network homogeneity of the new PN. In this case, the location of the gates as used in this thesis is not ideal: The gates are now placed very far away from the most congested core region shown on this map. This makes sense from an urban planning perspective, as queues are then not in built-up areas, but for efficient perimeter control, the
123 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
gates would need to be much closer to the centre, as shown on the map on Figure 63. Further work would need to determine the exact locations of the new gating traffic lights, which would be a trade-off between perimeter control requirements and urban planning or attractivity. These new locations would cause queues at very central and built-up environments, leading to a higher probability of causing spillbacks onto other intersections nearby, and to a higher chance of residents raising objections. The last approach to increase network homogeneity is the use of DTA. If drivers could freely choose their route and adapt to congestion, the congested links would experience less traffic volume, and the less congested links would be more often used. Further work could show the improvement in perimeter control performance and assess the impact on smaller local roads which would experience higher traffic volumes. Also, the reactions of the affected residents would need to be considered.
Figure 63: Possible smaller PN containing only the city centre. Source: (Swiss Confederation, 2019), own figure.
124 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
8 Bibliography
Aboudolas, K. & Geroliminis, N., 2013. Perimeter and boundary flow control in multi- reservoir heterogeneous networks. Transportation Research Part B, Volume 55, pp. 265-281.
Ambühl, L., 2018. A case study of Zurich’s two-layered perimeter control. Vienna, Transport Research Arena TRA 2018.
Ambühl, L. et al., 2017b. Introducing a re-sampling methodology for the estimation of empirical macroscopic fundamental diagrams, Working Paper: ETH Zürich.
Ambühl, L., Loder, A., Bliemer, M. C. & Menendez, M., 2018. A functional form with a physical meaning for the macroscopic fundamental diagram. Transportation Research Part B: Methodological.
Ambühl, L., Loder, A., Menendez, M. & Axhausen, K. W., 2017a. Empirical Macroscopic Fundamental Diagrams: New Insights from Loop Detector and Floating Car Data, Working Paper: ETH Zurich.
Ambühl, L. & Menendez, M., 2016. Data fusion algorithm for macroscopic fundamental diagram estimation. Transportation Research Part C, Volume 71, pp. 184-197.
Bienzeisler, L., 2013. Verkehrssimulation von Abschnitten eines innterstädtischen Strassennetzes mit Lichtsignalanlagensteuerung und Bevorrechtigung des ÖPNV, Braunschweig: Ostfalia Hochschule für angewandte Wissenschaften.
Brigham Young University, 2017. Proportional Integral (PI) Control. [Online] Available at: https://apmonitor.com/pdc/index.php/Main/ProportionalIntegralControl [Accessed 23 January 2020].
Bundesamt für Raumentwicklung, 2016. Verkehrsperspektiven 2040, Bern: Eidgenössisches Departement für Umwelt, Verkehr, Energie und Kommunikation .
Control Solutions Minnesota, 2019. PID for Dummies. [Online] Available at: https://www.csimn.com/CSI_pages/PIDforDummies.html [Accessed 24 November 2019].
Daganzo, C., 2007. Urban gridlock: Macroscopic modeling and mitigation approaches. Transportation Research Part B, 41(1), pp. 49-62.
125 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Daganzo, C. F., Gayah, V. & Gonzales, E., 2011. Macroscopic relations of urban traffic variables: Bifurcations, multivaluedness and instability. Transportation Research Part B, 45(1), pp. 278-288.
Dakic, I., 2018. Macroscopic modeling of multi-modal urban networks, Lecture in "Traffic Engineering" at ETH Zurich: ETH Zurich.
Du, J., Rakha, H. & Gayah, V. V., 2016. Deriving macroscopic fundamental diagrams from probe data: Issues and proposed solutions. Transportation Research Part C, Volume 66, pp. 136-149.
Erb+Partner AG & Marty+Partner AG, 2017. Technische Unterlagen Knoten 373 (Landschriber).
Erb+Partner AG, 2017. Verkehrsmanagement Baden-Wettingen. [Online] Available at: http://service.escapenet.ch/publisher/pictures/717/474267/ep_aktuell_vm_bawe.pdf [Accessed 22 October 2019].
FESA Logik GmbH, 2019. FESA - Die flexible Lösung für Lichtsignalsteuerungen. [Online] Available at: http://www.fesa.ch/ [Accessed 14 October 2019].
Gao, Y., 2008. Calibration and comparison of the VISSIM and INTEGRATION microscopic traffic simulation models, Master Thesis submitted to Virginia Polytechnic Instiutute and State University: Blacksburg.
Geroliminis, N., 2015. Cruising-for-parking in congested cities with an MFD representation. Economics of Transport, 4(3), pp. 156-165.
Geroliminis, N., 2019. MOOC: Intro to Traffic Flow Modeling and Intelligent Transport Systems. [Online] Available at: https://courseware.epfl.ch/courses/course-v1:EPFL+transport- systems+2019/about [Accessed 8 Dezember 2019].
Geroliminis, N. & Daganzo, C. F., 2007. Macroscopic modeling of traffic in cities. Washington DC, 86th Annual Meeting Transportation Research Board.
Geroliminis, N. & Daganzo, C. F., 2008. Existence of urban-scale macroscopic fundamental. Transportation Research Part B, 42(9), p. 759–770.
126 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Geroliminis, N., Haddad, J. & Ramezani, M., 2013. Optimal perimeter control for two urban regions with macroscopic fundamental diagrams: a model predictive approach. IEEE Transactions on intelligent transport systems, 14(1), pp. 348-359.
Geroliminis, N. & Sun, J., 2011. Properties of a well-defined macroscopic fundamental diagram for urban traffic. Transportation Research Part B, 45(3), pp. 605-617.
Godfrey, J., 1969. The mechanism of a road network. Traffic Engineering & Control, Issue 8, pp. 323-327.
Google, 2019. Google Maps. [Online] Available at: www.google.com/maps [Accessed 27 November 2019].
Greenshield, B., 1935. A study of highway capacity. Proceedings Highway Research, Volume 14, pp. 448-477.
Haddad, J. & Geroliminis, N., 2012. On the stability of traffic perimeter control in two-region urban cities. Transportation Research Part B, 46(9), pp. 1159-1176.
Haddad, J. & Shraiber, A., 2014. Robust perimeter control design for an urban region. Transportation Research Part B, Volume 68, pp. 315-332.
Hosseinialiabad, P., 2019. E-mail and Skype conversation [Interview] (24 November 2019).
Ji, Y., Luo, J. & Geroliminis, N., 2014. Empirical observations of congestion propagation and dynamic partitioning with probe data for large-scale systems. Transportation Research Records J, 2(2422), pp. 1-11.
Ji, Y., Luo, J. & Gerom, n.d. Empirical observations of congestion propagation and dynamic partitioning with probe data for large-scale systems.
Kalt, M., 2019. Conversation over e-mail and phone with Manuel Kalt from BVUATB [Interview] (12 October 2019).
Kanton Aargau, 2019a. Neugestaltung Schulhausplatz Baden. [Online] Available at: https://www.ag.ch/de/bvu/mobilitaet_verkehr/strasseninfrastruktur/strassenprojekte/baden___ zentrum/baden_zentrum_1.jsp [Accessed 23 December 2019].
127 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Kanton Aargau, 2019b. Oase – Raum Baden-Wettingen. [Online] Available at: https://www.ag.ch/de/bvu/mobilitaet_verkehr/mobilitaet/gesamtverkehrsplanung/oase/oase_ra um_baden/oase_raum_baden.jsp [Accessed 28 December 2019].
Kanton Aargau, 2019c. OASE – Regionales Gesamtverkehrskonzept Ostaargau. [Online] Available at: https://www.ag.ch/de/bvu/mobilitaet_verkehr/strasseninfrastruktur/strassenprojekte/ostaargau er_strassenentwicklung/oase_regionales_gesamtverkehrskonzept_ostaargau.jsp [Accessed 28 December 2019].
Kanton Aargau, 2019d. Onlinekarten Kanton Aargau. [Online] Available at: https://www.ag.ch/app/agisviewer4/v1/agisviewer.html [Accessed 8 October 2019].
Kanton Aargau, 2019e. Kantonales Gesamtverkehrsmodell, Auszug Region Baden-Wettingen. Aarau: BVU.
Keyvan-Ekbatani, M., 2018. Microscopic and Macroscopic Traffic: Modeling and Control, Lecture in "Traffic Engineering" at ETH Zurich: Zurich.
Keyvan-Ekbatani, M. et al., 2016. Queuing Under Perimeter Control: Analysis and Control Strategy. Rio de Janeiro, 19th International Conference on Intelligent Transportation Systems (ITSC).
Keyvan-Ekbatani, M., Kouvelas, A. & Papamichail, I., 2012. Exploiting the fundamental diagram of urban networks for feedback-based gating. Transportation Research Part B, 46(10), pp. 1393-1403.
Keyvan-Ekbatani, M., Papageorgiou, M. & Knoop, V., 2015a. Controller Design for Gating Traffic Control in Presence of Time-Delay in Urban Road Networks. Kobe, 21st International Symposium on Transportation and Traffic Theory.
Keyvan-Ekbatani, M., Yildirimoglu, M., Geroliminis, N. & Papageorgiou, M., 2015b. Multiple Concentric Gating Traffic Control in Large-Scale Urban Networks. IEEE Transactions on Intelligent Transport Systems, 16(4), pp. 2141-2155.
Knoop, V., de Jong, D. & Hoogendoorn, S., 2014. The influence of the road layout on the network fundamental diagram. Washington, D.C., 93rd Annual Meeting of the Transportation Research Board.
128 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Knoop, V., Van Lint, J. & Hoogendoorn, S., 2012. Routing strategies based on the macroscopic fundamental diagram. Transportation Research Records.
Ko, E., 2019. E-mail conversation with Eunbyeol Ko (Vissim costumer support) [Interview] (12 November 2019).
Koukol, M. & Pribyl, O., 2013. Design Methodology of a Fuzzy Control System in PTV VISSIM. Transactions on transport sciences, 6(4), pp. 177-184.
Kouvelas, A., 2018a. Graded exercise: Loop detector data and bus-bunching, ETH Zurich: Lecture in "Traffic Engineering".
Kouvelas, A., 2018b. Introduction and course overview, ETH Zurich: Lecture in "Traffic Engineering".
Kouvelas, A., 2018c. Real-time traffic management (TMC), ETH Zurich: Lecture in "Traffic Engineering" .
Kouvelas, A., Saeedmanesh, M. & Geroliminis, N., 2017. Enhancing model-based feedback perimeter control with data-driven online adaptive optimization. Transportation Research Part B, Volume 96, pp. 26-45.
Kramer, P., 2015. Badener Tagblatt: Agglo Baden-Brugg ist geschrumpft – Verstädterung um Zürich gewachsen. [Online] Available at: https://www.badenertagblatt.ch/aargau/baden/agglo-baden-brugg-ist- geschrumpft-verstaedterung-um-zuerich-gewachsen-128853839 [Accessed 21 December 2019].
Kramer, P., 2018. Badener Tagblatt: Einsprachen gegen Fahrverbot auf der Hertensteinstrasse. [Online] Available at: https://www.badenertagblatt.ch/aargau/baden/einsprachen-gegen-fahrverbot-auf- der-hertensteinstrasse-132951320 [Accessed 22 October 2019].
Leclercq, L., Sénécat, A. & G., M., 2017. Dynamic macroscopic simulation of on-street parking search: a trip-based approach. Transportation Research Board Part B, Volume 101, pp. 268-282.
Loder, A., Ambühl, L., Menendez, M. & Axhausen, K. W., 2017. Empirics of multimodal traffic networks - Using the 3D macroscopic fundamental diagram. Transportation Research Part C: Emerging Technologies, Volume 82, pp. 88-101.
129 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Moridpour, S. & Rose, G., 2010. Lane changing models: a critical review. The International Journal of Transportation Research, 2(3), pp. 157-175.
Ortigosa, J., Menendez, M. & Gayah, V., 2015. Analysis of network exit functions for various urban grid network configurations. Transportation Research Record: Journal of the Transportation Research Board, Volume 2, pp. 12-21.
Ortigosa, J., Menendez, M. & Tapia, H., 2014. Study on the number and location of measurement points for an MFD perimeter control scheme: a case study of Zurich. EURO J Transport Logistics, 3(3-4), p. 245–266.
PTV, 2017. Webinar: Creating a simple actuated signal control logic with VisVAP. [Online] Available at: https://www.youtube.com/watch?v=YKvNQA9jXhI [Accessed 18 October 2019].
PTV, 2018. PTV Vissim 11 User Manual, Karlsruhe: PTV AG.
Ramanujam, V., 2007. Lane changing models for arterial traffic, Master Thesis submitted to Massachusetts Institute of Technology: Cambridge.
Richards, P., 1956. Shockwaves on the Highway. Operations Research, February, 4(1), pp. 42-51.
SNV, 2015. SN 640 837: Lichtsignalanlagen, Übergangszeiten und Mindestzeiten, Winterthur: SNV.
SNZ Ingenieure und Planer AG, 2013. Verkehrsmanagement Baden - Wettingen, Steuer- und Leitdefinitionen. [Online] Available at: https://www.ag.ch/media/kanton_aargau/bvu/dokumente_2/mobilitaet___verkehr/mobilitaet_ 1/verkehrsmanagement_1/vm_um_grossraumbadenwettingen_steuerleit.pdf [Accessed 21 December 2019].
Sparmann, U., 1978. Spurwechselvorgänge auf zweispurigen BAB-Richtungsfahrbahnen. Forschung, Strassenbau und Strassenverkehrstechnik, Issue 263.
Stadt Baden, 2020. Kennzahlen. [Online] Available at: https://www.baden.ch/de/stadt-behoerde/portraet/kennzahlen.html/206 [Accessed 24 Januar 2020].
Swarco and Kanton Aargau, 2019. Regionaler Verkehrsrechner. [Online].
130 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Swiss Confederation, 2019. Official topographic map of Switzerland. [Online] Available at: map.geo.admin.ch [Accessed 9 December 2019].
Travel Forecasting Resource, 2019. Dynamic Traffic Assignment. [Online] Available at: http://tfresource.org/Dynamic_Traffic_Assignment [Accessed 24 December 2019].
University of Michigan , 2019. Introduction: PID Controller Design. [Online] Available at: http://ctms.engin.umich.edu/CTMS/index.php?example=Introduction§ion=ControlPID [Accessed 22 November 2019].
Wang, Y., Szeto, W., Han, K. & Friesz, T., 2018. Dynamic traffic assignment: A review of the methodological advances for environmentally sustainable road transportation applications. Transportation Research Part B, Volume 111, pp. 370-394.
Wiedemann, R., 1974. Simulation des Strassenverkehrsflusses, Karlsruhe: Karlsruher Institut für Technologie.
Zheng, N., Waraich, R., Axhausen, K. & Geroliminis, N., 2012. A dynamic cordon pricing scheme combining a macroscopic and an agent-based traffic model. Transportation Research Board Part A, 46(8), pp. 1291-1303.
131 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
A Appendix
A.1 Various figures
Figure 64: Lane changing behaviour in Vissim
132 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 65: Planned measures in Baden in scope of OASE. Source: (Kanton Aargau, 2019b)
133 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 66: Scheme of the cascade relevant for axes Bruggerstrasse/Siggenthal. Source: (SNZ Ingenieure und Planer AG, 2013). Unfortunately, the original file does not offer a higher resolution.
134 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 67: Decision tree structure used to find the optimal gains
135 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 68: MFD for baseline and BBC, full 4 hours including offset of congestion
Figure 69: MFD for baseline and PI, full 4 hours including offset of congestion
136 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 70: Speeds as obtained by loop detectors. BBC (left), PI controller (right)
137 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 71: MFDs of scenarios with increased demand including offset of congestion
138 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
A.2 MFD derived from Link Evaluation data
This section presents the two different methods to derive MFDs from link evaluation data.
• All links inside the PN: First of all, a loop over all links evaluates whether the start coordinates of every link are inside the PN, using a point-in-polygon algorithm. The result is a list of all links inside the PN, which is used for further processing. However, this does not need to be calculated again for every simulation run, but only once. Then, for every time step and for every link segment inside the PN, density, flow and segment length are stored. The traffic densities and flows are weighted using the segment length and the total link length inside the PN (Ambühl, et al., 2017a). Afterwards, the average densities and flows over all link segments per time step can be calculated and plotted. The total runtime of this approach is approximately 6 hours, which is due to the large number of links inside the PN. This is hardly feasible in reality, however, because determining the traffic density on every link of a network is cumbersome: using loop detectors, density can only be approximated. One would need cameras or an airborne view of the network to more properly estimate density. • Only the links on which the 20% most congested detectors are situated: Vissim allows to directly output a list of links, on which the data collection points are located. A subset of this list is formed, that contains only the links on which the 20% most congested detectors are located. The rest of this approach works similarly as when using all the links. The total runtime of this approach is around 2 hours, which is around the same as when using data collection points.
139 Perimeter Control in the Swiss City of Baden: Evaluation of Different Scenarios January 2020
Figure 72: MFD obtained from Link Evaluation Data (grey: offset of congestion), one replication.
A.3 Results of scenario with double demand (+100%)
Table 21: Results with increased demand (+100%)
Evaluation Baseline BBC (max. BBC PI (max. PI (best criterion flow in PN) (best flow in trade- tradeoff) PN) off) VHT [h] 76213 81498 82629 80128 78172 Avg. speed 5.3 4.4 4.6 3.9 4.4 overall [km/h] total vehicle 72900 78606 79846 77698 75395 delay [h] #stops per veh- 26.8 38.1 35.3 44.9 40.9 km % of veh. in 87 89 89 91 89 queue veh. served 79993 70602 70362 61256 66229
140