online control of traffic lights
Post on 10-Oct-2014
38 Views
Preview:
TRANSCRIPT
c©2011 Pieter Callebaut. All rights reserved. The author gives permission to make thismaster dissertation available for consultation and to copy parts of this master disser-tation for personal use. In the case of any other use, the limitations of the copyrighthave to be respected, in particular with regard to the obligation to state expressly thesource when quoting results from this master dissertation.
GentJune 4, 2011Pieter Callebaut
Preface
The selection of this thesis subject comes out of an interest in computer simulationthat has originated in playing Rollercoaster Tycoon during my childhood years. As Iwas confronted with programming simulators myself during my engineering education,I started to appreciate this way of solving very difficult and complex problems by goingover all its possible outcomes.
I would hereby like to thank my promoter, prof. dr. Rene Boel, for the introduc-tory course on simulation last year, and for our biweekly meetings in which he showedgreat interest in my progress and helped solving theoretical and practical problemswith the simulator.
Next I would also like to thank Herman Sutarto of the SYSTeMS research group forhis ideas about implementing the simulator in Simulink and for his good suggestionsduring the first interim presentation of this thesis. Thanks to these suggestions, I wasable to finish the simulator ahead of schedule.
I wish to express my greatest thanks to my parents and sister, for their everlastinginterest in my work, their encouragements and for reviewing my text. Further I wishto thank my colleagues and friends, especially the board of VTK Gent, for helping mewith putting this text together. Finally I would like to thank my girlfriend for herpatience during all the hours of programming and writing.
iv
On-line Control ofTraffic Lights
by
Pieter CALLEBAUT
Master dissertation written to obtain the academic degree ofMaster in Industrial Engineering and Operations Research
Promoter: Prof. dr. R. BOELAssistance by SUTARTO and N-E. MARINICA
Ghent UniversityFaculty of Engineering and Architecture
Academic year 2010-2011
Department of Electrical Energy, Systems and AutomationHead: Prof. dr. ir. J. MELKEBEEK
Summary
The goal of this master thesis is to design and test a traffic light controller that willreduce the total waiting time in front of the traffic light. Data has been provided forthree junctions on the N47, the road between Lokeren and Dendermonde, Belgium. Inorder to test the controller, a simulator has been built in Simulink. This simulator isverified for one single junction and can easily be used to simulate multiple adjacentjunctions. Six different controllers will be designed for controlling the traffic lights.Three will be used to optimize the waiting time at one junction; the other three will beused to reduce the waiting time in a system of three junctions. Almost all the controllerswere able to reduce the waiting time in comparison with the original situation. Thebest results have been obtained with controllers that clear the queues of the intersectingroads. These controllers were able to reduce the total waiting time with over 45%.
Keywords
Traffic lights, simulation, control, waiting time reduction
v
On-line regeling vanverkeerslichten
door
Pieter CALLEBAUT
Masterproef ingediend tot het behalen van de academische graad vanMaster in de ingenieurswetenschappen: bedrijfskundige systeemtechnieken en
operationeel onderzoek
Promotor: Prof. dr. R. BOELBegeleiders: SUTARTO en N-E. MARINICA
Universiteit GentFaculteit Ingenieurswetenschappen en Architectuur
Academiejaar 2010-2011
Vakgroep Elektrische energie, Systemen en AutomatiseringVoorzitter: Prof. dr. ir. J. MELKEBEEK
Samenvatting
Het doel van deze thesis is het ontwerpen en testen van een regelaar voor verkeerslichtendie de totale wachttijd voor deze lichten verkort. Testdata is beschikbaar van driekruispunten op de N47, de provinciale weg tussen Lokeren en Dendermonde, Belgie.Om deze regelaar te testen is er een simulator gebouwd in Simulink. Deze simulatoris geverifieerd voor een enkel kruispunt, maar kan makkelijk uitgebreid naar meerderekruispunten op dezelfde weg. Zes verschillende regelaars zullen ontworpen worden omde verkeerslichten te regelen. Drie regelaars zullen de wachttijd optimaliseren aaneen enkel kruispunt; de andere drie proberen de wachttijd voor een systeem van driekruispunten laag te houden. Bijna alle regelaars slaagden in hun opzet, en reduceerdende wachttijd ten opzichte van de originele situatie. De beste resultaten zijn bereiktmet regelaars die de wachtrijen van de zijstraten laten leeg lopen wanneer deze volzijn. Deze regelaars zijn in staat om de totale wachttijd terug te brengen met 45%.
Sleutelwoorden
Verkeerslichten, simulatie, regeling, reductie van wachttijd
vi
On-line Control of Traffic LightsPieter Callebaut
Supervisors: Rene Boel, Herman Sutarto, Nicolae-Emanuel Marinica
Abstract— The article describes the design and testing of a traffic lightcontroller that will reduce the total waiting time in front of the traffic light.Data has been provided for three junctions on the N47, the road betweenLokeren and Dendermonde, Belgium. In order to test the controller, a sim-ulator has been built in Simulink. This simulator is verified for one singlejunction and can easily be used to simulate multiple adjacent junctions. Sixdifferent controllers will be designed for controlling the traffic lights. Threewill be used to optimize the waiting time at one junction; the other three willbe used to reduce the waiting time in a system of three junctions. Almostall the controllers were able to reduce the waiting time in comparison withthe original situation. The best results have been obtained with controllersthat clear the queues of the intersecting roads. These controllers were ableto reduce the total waiting time with over 45%.
Keywords—Traffic lights, simulation, control, waiting time reduction
I. INTRODUCTION
EVERY day, a great amount of time and money is lost due toheavy traffic and its resulting traffic jams. Although traffic
information only tells us about traffic jams on highways, manypeople also lose valuable minutes in front of traffic lights. Pre-vious studies [1] [2] [3] already have been trying to solve thisproblem, some with remarkable results. Reductions up to 50%in waiting time were reached. The thesis on which this articleis based, had the same objective of reducing the waiting of carsin front of a traffic light. Therefore we first needed a workingsimulator that could simulate the arrivals, queues and departuresof cars at a junction. Instead of working with single arrivals,this simulator will work with flows of cars. Simulink, a Mat-Lab toolbox, will be perfectly suited for this approach. Data totest the simulator will be provided for three junctions on a roadbetween Lokeren and Dendermonde, Belgium. This data wascollected from counting lines in the streets around the junction.Because input and output was available, the simulator can easilybe tested.
II. CONSTRUCTION OF SIMULATOR IN SIMULINK
Data from the counting lines were transformed into a flow inintervals of 10 seconds. Next, this input data will be feed tothe simulator. The basic operation will be the calculation of thequeue size. This will be done with the simple formula:
dqtdt
= (λt − µt) (1)
in which qt is the size of the queue at moment t, λt the inflowof cars in a lane at moment t, and µt the maximal outflow that ispossible on t. This maximal outflow is dependent on the state ofthe traffic light and the queue. In a red state, this outflow will bezero. When the light turns green and there are cars in the queue,this outflow will be the maximal capacity of the junction. In agreen period without a queue, the outflow will equal the inflow,and the queue won’t grow npr shrink. This operation as it isintegrated in Simulink is shown in Figure 1.
Fig. 1. Basic building block in Simulink that will calculate the size of the queueand the outflow
One building block will be used per lane and they will all beinterconnected with each other. The amount of cars that is goingstraight, left and right is derived from the data. The cycle timeof the traffic light of the junction can easily be found by lookingat the flows of cars. If significant flows are detected, conclusionscan be drawn.The simulator has been verified by comparing the calculatedoutflows with the measured outflows. Overall, the simulatorperformed well, estimating flows at the right moment and cal-culating the queues as hoped. The only negative point is thatthe simulator fails to estimate the amount of flow accurately, be-cause of the lack of data of cars going left and right. Fortunately,the controllers can still be tested by comparing the calculateddata before and after controlling.
III. BUILDING A CONTROLLER
Three different types of controllers have been designed. Ev-ery controller uses different data as input: incoming flows, theaverage waiting times and the queue sizes.
A. Controller using flows as input
The first controller is based on the principles of statistical pro-cess control ([4]), used in manufacturing environments to makesure that products keep meeting the specifications. Changes inthe process will be detected when the properties of the partscross a predetermined boundary. This boundary is calculatedby using the mean and variance of the previous products.This controller will work the same way. It will constantly mea-sure the inflow of cars on the main street and when it detects asignificant increase in flow, it will adjust its cycle time in orderto give more green to this street. When the intensity of the flowstarts to decrease again, the controller will adjust likewise, andgreen periods will shorten for the main street, resulting in lesswaiting time for the intersecting streets. After the first tests, theneed to add a limitation to the increase in cycle time was ob-served, so that the intersecting roads wouldn’t need to wait for
hours.When this controller is used to control the cycle times of mul-tiple junctions, an extra module will be integrated that creates agreen wave for the direction that carries the most traffic.
B. Controller using waiting times as input
Since the goal of the controller is to reduce the overall wait-ing time, the next controller that is built will use this waitingtime as an input. The average waiting time at any moment isthe total waiting time divided by the total time elapsed. Whencars need to wait less, this average waiting time will start to de-crease. Based on the principles of optimization along a convexcurve [5], this controller will constantly calculate this averagewaiting time and adjust the cycle time in order to get even betteraverages. When it notices a decrease in waiting time after it hasincreased the cycle time, it will continue increasing this cycletime, hoping for even better results. If the waiting time seemsto be rising again, it will change its policy, and start to decreasethe cycle time.
C. Controller using queues as input
The last controller is based on the principles of clearing awhole queue [2]. Because it is not desirable that the main roadonly gets green when its queues need to be cleared, the methodwill only be applied to the intersecting roads. From the moment5 or more cars are waiting in the queue, the lights will turn green.Because in very calm streets this could take a while, a maximumamount of time that the first car is allowed to be waiting will beselected. From the moment the queue is empty, the lights willturn red again.
IV. RESULTS OF SIMULATIONS WITH CONTROLLER
Simulations for one junction were done with data of threeconsecutive days; simulations for a system of three adjacentjunctions were done with data of five days. This because somecounting loops failed during measuring and because of memorycapacity.
A. Controlling one junction
The flow controller and average waiting time controller willbe tested for different maximums in cycle time. Both will beexamined for maximums going from 60 seconds up to 120 sec-onds. The green time for the intersecting roads was fixed at 25seconds. For the clearing queues controller, the maximum wait-ing time for the intersecting roads was varied, going from 10seconds up to 70 seconds. For the flow controller, the best re-sults were achieved when setting the maximum cycle time to 80seconds, which lead to a reduction of 3.5% in total waiting time(Figure 2). The average waiting time controller didn’t give anypositive results. The best setting increased the waiting time with21%. Since this controller didn’t seem to perform as desired, itisn’t used anymore for the following section. The most aston-ishing results however were reached with the clearing queuescontroller. When the maximum waiting time was set to 30 sec-onds, this controller reduced total waiting time with 48.73%.This means the total waiting time over the three simulated dayscould be reduced with more than 6 days.
Fig. 2. Comparison of the best policy for each controller when controlling onejunction
B. Controlling three junctions
Since the average waiting time controller failed to fulfill thespecifications, research continued with the two other controllers.The flow controller was once used to control the whole system ofjunctions and once to control only one junction, independentlyof adjacent junctions. The clearing queues controller was againonly used at its own junction and will not interact with con-trollers at other junctions either. The controller that is managingthe whole system was modified to provide a green wave for thebusiest direction. Simulations for the three flow controllers, oneat every junction, lead to a reduction in waiting time of 7.3%,slightly better than in the previous section. The other controller,the one that manages all the junctions together, could only reacha reduction of 0.39%. This is due to the green wave, which isuseful on roads that are entering a city, but not on roads in be-tween two cities, where the traffic is similar in both directions.The clearing queues controller performed again the best with areduction in waiting time of 47%.
V. CONCLUSION
After building a working simulator, three controllers havebeen designed to reduce the total waiting time in a system ofadjacent junctions with traffic lights. Most of the designed con-trollers succeeded in reducing the waiting times, some more suc-cessfully than others. The best controller turned out to be thecontroller that clears the queues of the intersecting roads when-ever they contain a certain amount of cars or when the waitingtime is too long. Controllers that control the whole system andare providing green waves were not as successful as hoped for.However, the setting of the test location was not fit to test thiscontroller.
REFERENCES
[1] A. Ceder and I. Reshetnik, “An algorithm to minimize queues at signalizedintersections,” Journal of the Operational Research Society.
[2] P. Kumar and T. Seidman, “Dynamic instabilities and stabilization methodsin distributed real-time scheduling of manufacturing systems,” IEEE Trans-actions on Automatic Control, vol. 35, no. 3, pp. 289–298, 1990.
[3] E. Lefeber and J. Rooda, “Controller design for switched linear sys-tems with setups,” Physica A: Statistical Mechanics and its Applications,vol. 363, no. 1, pp. 48–61, 2006.
[4] D. C. Montgomery, Statistical Quality Control: A Modern Introduction.John Wiley and Sons.
[5] R. Boel, Monte Carlo and Stochastic Simulation. Ghent University.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vExtended abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
1 Introduction 11.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Outflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Acquiring data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Readfiles.m and Readtime.m . . . . . . . . . . . . . . . . . . . . 61.4.2 Createflow.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Possible applications in real life . . . . . . . . . . . . . . . . . . . . . . 8
2 Building a simulator 102.1 Simulink Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Basic building block . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 Determine output for one lane . . . . . . . . . . . . . . . . . . . 112.1.3 Calculating all the lanes . . . . . . . . . . . . . . . . . . . . . . 112.1.4 Main building block . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Verify the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Qualitative verification . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Quantitative verification . . . . . . . . . . . . . . . . . . . . . . 17
3 Building a controller 193.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Controller based on arrivals . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Controller based on average waiting time . . . . . . . . . . . . . . . . . 223.4 Controller based on queues of intersecting roads . . . . . . . . . . . . . 22
4 Results 254.1 Controlling one junction . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 Controller based on arrivals . . . . . . . . . . . . . . . . . . . . 254.1.2 Controller based on average waiting time . . . . . . . . . . . . . 264.1.3 Controller based on queues of intersecting roads . . . . . . . . . 274.1.4 Comparison between the best settings . . . . . . . . . . . . . . . 29
4.2 Controlling three junctions . . . . . . . . . . . . . . . . . . . . . . . . . 30
ix
4.2.1 Controller based on arrivals at single junction . . . . . . . . . . 314.2.2 Controller based on arrivals in the system . . . . . . . . . . . . 324.2.3 Controller based on queues of intersecting roads . . . . . . . . . 344.2.4 Comparison between the best settings . . . . . . . . . . . . . . . 34
4.3 More detailed results of clearing queues controller . . . . . . . . . . . . 354.3.1 Practical implementation . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A M-files discussed in Introduction 40A.1 Readfiles.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.2 Readtime.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42A.3 Createflow.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B M-files discussed in the Simulator chapter 49B.1 Verify the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
C Overview of controllers 51C.1 Controlling one traffic light based on flow input . . . . . . . . . . . . . 51
C.1.1 Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.1.2 MatLab code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
C.2 Controlling one traffic light based on average waiting time . . . . . . . 54C.2.1 Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . 54C.2.2 MatLab code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
C.3 Controlling one traffic light based on queue-sizes . . . . . . . . . . . . . 56C.3.1 Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . 56C.3.2 MatLab code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
C.4 Controlling three traffic lights based on flow input . . . . . . . . . . . . 58C.4.1 Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.4.2 MatLab code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Bibliography 61
x
List of Figures
1.1 Expected behaviour of Q en v . . . . . . . . . . . . . . . . . . . . . . . 31.2 Situation of junctions on the N47 . . . . . . . . . . . . . . . . . . . . . 51.3 Detailed drawning of the setting . . . . . . . . . . . . . . . . . . . . . . 51.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Data as given . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Basic building block . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Calculations for one lane . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Calculations for all the lanes . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Overview of main buildig block and its in and outputs . . . . . . . . . 132.5 Simulink model of three connected junctions . . . . . . . . . . . . . . . 142.6 Comparison between measured (yellow) and calculated (purple) outflow 162.7 Behaviour of the queues, in response of the traffic light . . . . . . . . . 18
3.1 Evolution of cycle time with arrival based controller without limitations.The 3σ-boundaries are shown in red . . . . . . . . . . . . . . . . . . . . 21
3.2 Section of Simulink model that calculated the average waiting time . . 24
4.1 Evolution of cycle time after controlling . . . . . . . . . . . . . . . . . . 264.2 Comparison of total waiting times of several cycle time limitations -
Arrival based controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Comparison of total waiting times of several cycle time limitations - Avg
WT controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Comparison of total waiting times of several maximum waiting time
limitations - Q controller . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 Comparison of best policies - Controlling 1 junction . . . . . . . . . . . 304.6 Comparison of total waiting times of several cycle time limitations -
Single junction controller . . . . . . . . . . . . . . . . . . . . . . . . . . 334.7 Creating a green wave through the system . . . . . . . . . . . . . . . . 334.8 Comparison of total waiting times of several cycle time limitations -
Total system controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.9 Comparison of total waiting times of several maximum waiting time
limitations - Q controller . . . . . . . . . . . . . . . . . . . . . . . . . . 364.10 Comparison of best policies - Controlling 3 junctions . . . . . . . . . . 364.11 Average waiting time per car before and after controlling with clearing
queues controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.12 Queues before and after controlling with clearing queues controller . . . 38
xi
C.1 Simulink model of simulator with controller based on arrivals . . . . . . 51C.2 Simulink model of controller based on arrivals . . . . . . . . . . . . . . 52C.3 Simulink model of simulator with controller based on average waiting
times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55C.4 Simulink model of controller based on average waiting times . . . . . . 55C.5 Simulink model of simulator with controller based on clearing queues . 57C.6 Simulink model of controller based on clearing queues . . . . . . . . . . 57C.7 Simulink model of controller based on arrivals - 3 junctions . . . . . . . 62
xii
List of Tables
2.1 Error percentages of simulator . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Results of controller based on arrivals . . . . . . . . . . . . . . . . . . . 274.2 Results of controller based on average waiting time . . . . . . . . . . . 274.3 Results of controller based on queues of intersecting roads . . . . . . . 304.4 Results of controller based on arrivals at single junction - 3 junctions . 314.5 Results of controller based on arrivals in the system - 3 junctions . . . . 324.6 Results of controller based on queues of intersecting roads - 3 junctions 35
xiii
Chapter 1
Introduction
1.1 Objectives
Every day, 11.605 hours were lost due to traffic jams on the Belgian roads [8]. This
leads to a loss of almost 150.000 euro, every day. Most of these traffic jams occur on
Belgium’s dense network of highways, but one can’t neglect the amount of time wasted
in the city centres and on provincial roads because of waiting in front of traffic lights.
We all have already experienced to be waiting in front of a traffic light, which turns
green, but red again before you could make it through. Another point many people
find frustrating is to be waiting in front of a traffic light for ages before the light turns
green for your direction.
The reason why traffic lights don’t seem to be able to cope with the right amount
of traffic at some moments, is because the switching times of the lights have been
determined earlier, when the system was installed or by means of an operator in a
control centre. Although these systems work fairly well when the traffic situation is
like predicted, they fail to adapt when the situation suddenly changes.
The aim of this thesis is to design a system which can control traffic lights on-line,
i.e. decides in real-time when and where to switch. It assumes that all the data of
the incoming flow is known. This data can be gathered by means of counting loops,
cameras, microphones ... The system will work autonomously, without interference of
an operator. If desired, it could work together with other traffic lights up- and down-
stream in order to establish a green wave for the dominant direction.
Other studies have been able to reduce waiting time with 50% after optimizing the
traffic lights [2]. The aim of this thesis is to get the same results, by designing a
controller from scratch. In order to test this controller, the first objective is to build
1
a simulator which can predict the flow over a junction with traffic lights accurately.
After this simulator has been verified, the same input data will be used, but this time
the lights will be controlled by the controller. We hope that this controller will reduce
the waiting time significantly, compared to the original situation.
1.2 Formulas
1.2.1 Queue
The main building block of the simulator is based on the formula that determines the
change in queue size, given the inflow and outflow parameters. Based on the size of
the queue, we will also be able to define the outflow rate of each lane. We will make
use of the following elements:
µt: Maximum outflow rate at time t
λt: Arrival rate at time t
qt: Size of the queue at time t
µt can take two different values. It will be 0 when the light is red and will take the
value of the capacity of the junction during green periods. The change in queue size is
dependent one both the arrival and outflow rate, and on the fact whether the queue is
empty or not. The formula can be written as follows:
dqtdt
= (λt − µt) if (qt > 0) (1.1)
dqtdt
= 0 if (qt = 0 ∧ µt ≥ λt) (1.2)
From equation 1.1 we can see that if the queue is not empty, the queue-size will
change according to the inflow and outflow parameter. If the traffic light is red for
one lane, the maximum outflow will be zero and the queue will grow. If the light
turns green, the queue will shrink. This because we expect that the inflow rate will be
smaller than the maximum outflow rate. If the queue becomes zero and if the inflow
rate remains smaller than the outflow rate (Eq. 1.2), the case when there is normal
traffic going on during green light, the queue size will not change anymore and remain
empty. It will stay zero until the light turns red. Then, the inflow becomes bigger than
the outflow capacity, because this capacity is zero during red lights. At this moment,
the queue will again start to grow, and the cycle repeats itself.
2
1.2.2 Outflow
The moment the size of the queue is known, we can determine what the real outflow
rate will be. If the queue is empty and the arriving cars can immediately continue their
journey past the traffic light, we can expect that the outflow rate out of the system
will be the same as the inflow rate. If the light turns red, no car can pass the light
anymore, and the outflow becomes zero. The moment it turns green again, cars are
waiting at the traffic light. This means that they now can use the full capacity of the
junction from the moment they are allowed to continue. This is the fastest way to
empty the queue. After emptying the queue, the outflow rate drops again and equals
the inflow rate.
qt > 0 : µt (1.3)
qt = 0 : λt (1.4)
Figure 1.1: Expected behaviour of Q en v
In Figure 1.1 we can see what to expect after implementing these formulas into a
simulator. In region 1, there is no outflow, which means that the light has turned red.
Immediately after the flow has fallen to zero, we see the queue growing. At the moment
the light switches (region 2), we see the outflow at its maximum rate, i.e. the maximum
capacity of the junction, and the queue is emptying itself. From the moment the queue
is empty, the outflow rate will equal the inflow rate and the queue will remain empty,
since all the cars can easily pass by (region 3). Behind region 3, the light has turned
3
red again and the queue starts growing again.
1.3 Setting
Data has been provided for three traffic lights on the N47, the road between Lokeren
and Dendermonde, in Flanders, Belgium. The traffic lights are situated between the
E17 highway and the roundabout with the Dendermondebaan, in the industrial estate
of the town of Zele (junctions A, B and C in Figure 1.2). The first sketch of the setting
that was given had the north in the wrong direction, which means that the upward
direction is actually to the south (Figure 1.3), in the direction of Dendermonde. As
a consequence, the downward direction is to the north, in the direction of Lokeren.
Streets coming from the left and the right are as indicated on Figure 1.3. Junctions
A and B are 400 metres away from each other, junction B and C 600 metres. These
distances can be used to calculate the time a car needs to drive from one junction to
another. An average speed of 50 km/h between every junction is assumed, which leads
to the following calculations:
400m
50000m/3600s= 28.8s ≈ 30s (1.5)
600m
50000m/3600s= 43.2s ≈ 40s (1.6)
We have rounded the seconds to a multiple of ten, because in the future we will
always work with intervals of 10 seconds.
Traffic at every junction was measured by means of lines on the asphalt at the
junction. These lines provide information about the outflow at every junction and the
inflow during a green period. We only have data for green periods because the lines
were situated behind the stopping line of the cars during red light. Because of this,
we can’t know what the inflow in the queue was during a red period. We can only
define the cycle time of the traffic lights by comparing the flows in the two directions.
Luckily there were also loops installed on the main road in the up and downstream
direction. So these signals will predict the arrival stream at the next junction. Loops
more upstream were not installed on the intersecting roads, so we only know how many
cars passed by the loops during the green period. To estimate the arrival of cars at
the side-roads, we will have to average the number of cars we counted during the green
period out over the whole cycle. Every loop has been given a number, for which an
overview can be found in Figures 1.4(a), 1.4(b) and 1.4(c).
4
(a) Junction A (b) Junction B
(c) Junction C
Figure 1.4
1.4 Acquiring data
All the data of the lines has been saved in text files like one shown in Figure 1.5. Every
time a car drives over a line, one line is added to the file, containing a serial number,
the date, the time, the thousands of a second, and which line detected the car. Because
every car consists of two axels, one car is equal to two lines in the text file. A truck
has mostly more than two axels, but will be counted as 1.5 cars.
Calculations on this data will be done by MatLab. Every text file will be read,
analysed and a flow of cars will be extracted out of it.
1.4.1 Readfiles.m and Readtime.m
The complete code of Readfiles.m can be found in Appendix A.1, we will here only dis-
cuss this program briefly. For every junction and every lane, the text files are scanned
by the function OpenFile(). If one street has multiple counting lines, the data is saved
in the same matrix, to make everything easily accessible. In the OpenFile() function,
the data and line number are extracted from the line. The date, time and thousands
of a second are then all merged together to a format that is readable for MatLab. The
number of the line is stored in another array, but at the same position as the timestamp.
6
The Readtime-function (Appendix A.2) then uses the lines generated by Readfiles
to create the flow of one lane. It needs the arrays with time and line info, and a start
and end time of the analysis. Finally it also needs to know a cycle time, which will
be the smallest interval in which we want to know the flow. We will always make use
of intervals of 10 seconds. This means that we will know how many cars per second
were going over the line in an interval of ten seconds. A ten seconds interval is a good
balance between accuracy and a compensation for counting lines that were not working
all the time.
The program first converts the start and end time to a readable MatLab format, after
which it will iterate over the input array until it has reached the starting point. Next,
an array is constructed where the calculated flows will be stored. Then the program
goes into a loop, where it adds 1 to the flow array every time it spots a signal at the
correct counting line (sometimes there is data of two counting lines in one file, of which
one was mostly noise. So this needs to be filtered out). If a street has two counting
lines, it repeats the process for the other line in the other loop. At the end, the flow
is divided by 2, since every car consists of two axels, and by the interval in which it
measures the flow.
1.4.2 Createflow.m
Depending on the junction that is chosen during the call of the function, the funtion
saves all the flows of every lane in the appropriate variables (Appendix A.3). The
data of the inflow on the main roads is collected from more upstream counting lines.
Therefore this signals need to be delayed with the amount of time needed for the car
to travel from the counting line to the junction. In this way, the car arrives at the
right time at the junction. The program then uses the data to determine the red-green
cycle of the traffic lights. Since the counting lines are behind the stopping line, there
will only be cars detected when they are allowed to pass the traffic light, which means
when they have green. If traffic is detected on one of the two intersecting roads, we
conclude that they were having green light. Unfortunately, there were a lot of intervals
when traffic was detected on all the four lanes. This is because the lights switched
during the interval of 10 seconds, which leads to traffic on all the four roads. If we
detect this, we look at the flow in the previous and in the next interval. By doing this,
we can determine which lanes were waiting for a red light and which lanes were driving
through. If no change from red to green is detected, we will ascribe the detection of
traffic on intersecting streets to noise in the detectors. Next the function determines
the cycle and split times of the traffic light over the whole measuring period. This data
can later be used for statistics.
7
At every junction, cars can go straight, left and right. To make the best simulator
as possible, we have to be able to estimate these percentages correctly. In a loop we
will be checking how much flow went straight when flow was detected at the input. Ef-
fort has been put in the calculations of cars going left and right, but no valuable results
were obtained. So for this reason, there will be assumed that half of the remaining
percentage has gone left and the other half has gone right.
Finally, the function determines the arrival stream at the intersecting roads. We have
data of arriving cars at the main road, from counting lines more upstream, but not
from the intersecting roads. So the flows from left and right that are measured during
a green period are averaged out over the whole cycle. This gives us an estimate of the
arrival of cars during the whole cycle.
1.5 Possible applications in real life
The results of this thesis can be applied in many real-life situations, like on real junc-
tions. But it will also be applicable for manufacturing situations or any other system
with several queues and one processing device.
For the application in real-life traffic situations, the junction and its surroundings will
have to be equipped with sufficient measuring devices and connections to the con-
trollers. The controllers will have to know the exact amount of cars that are arriving
at any time, in order to switch the lights at the right moments and to calculate the
queues in front of the lights accurately. When a single controller is controlling several
junctions at the same time, these junctions also need to be connected to each other.
Because the setting consists of a busy main road and calmer intersecting roads, the
results will also only be applicable to these situations. Junctions with four busy direc-
tions will not be investigated in this thesis.
Another field of application is in manufacturing environments. It occurs that several
types of products need to be processed by the same machine. Nowadays, the number
of products that will be processed in one run is mostly calculated by using batch cal-
culations. Some machines also use a policy of processing a product until its queue is
empty before switching to another product. With this controllers, the total waiting
time of all the products will be optimized. This will reduce the lead time of the whole
factory.
8
Chapter 2
Building a simulator
2.1 Simulink Model
2.1.1 Basic building block
The basic building block of the simulator will be the implementation of Eq. 1.1. We
will need to subtract the capacity from the inflow and integrate this to obtain the size
of the queue. We assume an initial queue size of zero. This is a good approximation
when we start simulating during the night. Otherwise, we will make a mistake during
the first periods of the simulation, but this will be solved once the queue goes empty
again. The basic building block can be found in Figure 2.1. The inflow is calculated
using the given data; the capacity is the maximum capacity when the lights are green
for that lane, zero when they are red.
Figure 2.1: Basic building block
10
2.1.2 Determine output for one lane
By using the basic building block, we will be able to implement equations 1.3 and 1.4
in Figure 2.2. The size of the queue will be given by this basic block; the outflow rate
out of the lane will be dependent on the queue size. The input number 3, cycle, gives
us the red and green periods of the lane, 1 when it’s green and 0 when it’s red. The
first switch forwards the capacity of the lane to the basic block and to another switch.
This second switch determines the outflow. If the queue is not empty, which means
that the lane has a red light and the queue is building, or that it just turned green
and the queue is emptying at maximum capacity, the switch decides that the outflow
is at full capacity or zero. Otherwise, when the queue is empty, cars are just passing
without having to slow down, which means that the outflow of the lane will be the
same as the inflow.
Figure 2.2: Calculations for one lane
2.1.3 Calculating all the lanes
In Figure 2.3, the previous block is used four times to calculate queue sizes and outflow
rates of all the four lanes. They forward their calculated outflows to a splitter, which
splits the outflow of the lane in flows that are going left, right and straight. The
percentage of cars that are going straight has been determined when all the data has
been read and the flows have been calculated. We have divided the outgoing flow by
the incoming flow to come to the percentage of cars going straight. Since no working
algorithm for determining how many cars were going left and right was found, we
assumed half of the remaining cars will go left and the other half will go right. All the
11
outflows from one lane to the others are added together and sent to the main block.
Before the outflow and queue size can be calculated, the cycle input of each block needs
to be determined. This happens in the left bottom corner. A 1 is used to give green to
left and right, a 0 means that the up and down lane can drive. The zero is converted
into a one by multiplying it by -1 and adding 1. The transport delays before each
switch are used to simulate the orange period of each red-green cycle. When the cycle
switches from 0 to 1 in the upper half, this signal will be delayed with 5 seconds. This
means that it will be red for all the lanes during 5 seconds. The same happens if the
cycle goes from 1 to 0.
Figure 2.3: Calculations for all the lanes
2.1.4 Main building block
Figure 2.4 shows the main block for one junction. The upper blocks are all hidden
behind the big central block. The inflows and red-green are calculated before the sim-
ulation in a MatLab program, the capacity is determined manually. This capacity was
first set to the maximum outflow rate observed. But since this was 1.75 cars per sec-
ond, an unrealistically high number, it has been reduced to 1.2. The Scope out can be
used to check if the determined outflows in Scope v are similar to the measured ones.
By adding all the queues together and integrating them over time, the total waiting
12
time can be determined. This can be used as the input of an optimization controller.
This main building block can easily be used to extent the simulation to multiple junc-
tions. The in- and outputs can be connected to other main building blocks, the output
of one block will then be used as input for another block. Because the outputs of one
block would be forwarded to another block immediately, one needs to make sure to add
delays in between two blocks, to take the driving time in between the real junctions into
account. Signals between junctions A and B will be delayed by 30 seconds, the signals
between B and C by 40 seconds. We will also add some noise on the interconnecting
signals, not every car will drive at the same speed to another junction. The resulting
model can be found in Figure 2.5. In this model, the controller was already added.
This controller will be designed in Chapter 3.
Figure 2.4: Overview of main buildig block and its in and outputs
2.2 Verify the simulator
2.2.1 Qualitative verification
To verify if the simulator is working as desired, its output will be compared with the
real output that was measured. If the results are satisfying, the simulator can be
13
used test the influence of the controllers on the system. We will check if it produces
a feasible solution, if the calculated flows are seen at the right time and if they are
in correspondence with the measured flows. Further, we will also check if the queues
are feasible and if their cycles occur correctly. The simulator will only be verified for
one junction. Verifying the simulator for multiple connected junctions wouldn’t give
feasible results, because there are too many unknowns. Firstly we couldn’t estimate
the percentages of cars going left and right correctly, so the measured outflows at the
intersecting roads cannot be used to compare with the calculated ones. Secondly, we
are far from sure of the speed of the cars in between two junctions. We estimated
this in the beginning at 50 km/h, before there was known which traffic lights we were
dealing with. It turned out that the real speed limit was higher than 50 km/h, so the
measured flow will probably not occur at the same time as the calculated one.
We will first have a look at the measured and calculated outflows. Figure 2.6 shows
both signals for each lane, after a simulation over 1000 seconds. Measured data at
the inputs has been provided to the model, together with an estimation of the per-
centage of cars going straight at every interval. The calculated outflows can then be
compared with the measured ones. The purple signal is the calculated signal, which is
characterized by its three states: a maximum outflow of 1.2 cars/sec, the feedthrough
of the incoming traffic and 0 during a red period. The yellow signal is the flow that has
been measured right behind the junction. We can see immediately that the right and
left flows are overestimated by the simulator. This is because no good estimation for
the percentages could be made. Fortunately, this is not a big problem. Our objective
of reducing the overall waiting times will be more focused on the main street in the
up/down direction, so the intersecting roads are of minor importance. Also the number
of cars entering the system via these intersecting roads is very small compared to the
input from the main direction.
For the up and down direction, the simulator gives much better results. To verify
if the flow stops and starts at the correct time, we will have a look at the third and
fourth panel of the figure. In the third panel, the upper lane, we see a good overlap
between the yellow and purple signals. Thus the corresponding flows start and stop at
the same time. Similar results can be found in the fourth panel, although the simulator
seems to have underestimated the flow in the upward direction. Some peaks have also
been well estimated. In the fourth panel, around 70, 600 and 950 seconds, peaks have
been calculated at the same time as there had been one measured.
Although the simulator seems to be working as good as possible, it is obvious that the
15
yellow and purple signals are not 100% the same. It is quite hard to make an estimation
of the interaction between the cars at every moment or of the way they move on after
waiting for a red light. This all leads to the fact that you can try to simulate the flows
over a junction, but it will never be the same as it was in reality.
Figure 2.6: Comparison between measured (yellow) and calculated (purple) outflow
Although we can not check the sizes of the real queues at the traffic light, we will
still discuss Figure 2.7 to see if the behaviour of the queues is as expected. The yellow
block signal corresponds with the cycle of the traffic light as calculated in section 1.4.2,
the purple lines are the queues in every direction. The block wave is 0 when the green
light is for the up and downward direction, 1 if the intersecting roads can pass. We see
at the top two panels that, when the light turns red, the queue immediately starts to
grow. Because we had no data of arrivals at the left and right roads, we had to average
the flow during green out over the whole period. That’s why there are cars arriving
all the time and the queue will always be growing. When the light turns green, the
queue empties itself and stays zero until it becomes red. The queues for up and down
are more irregular, because we know the arrivals during every 10 seconds interval. The
queues in this figure can grow up to 15 cars just before the green period, a number we
will try to reduce by building a controller in the next chapter.
16
2.2.2 Quantitative verification
After a visual check of the simulator, a more quantitative inspection will be performed.
For this, we have run the simulator over a period of 17.000 seconds. To quantify the
errors the simulator has made, four error percentages have been defined:
• Pcm: the number of times the simulator expected flow, but no flow was measured
• Pmc: the number of times flow was measured, but no flow was calculated by the
simulator
• P50: the number of times the simulator expected 50% more or less flow than
measured
• Ptot: the total error percentage
The program that is used to do this verification can be found in Appendix B.1. The
results are shown in Table 2.1. The three percentages are on average quite acceptable.
22% of the time, the simulator has predicted flow but none was detected in the mea-
surements. In 15% of the cases, flow was measured but not calculated. Finally, in 22%
of the time, the simulator over- or underestimated the right amount of flow.
On average, almost 59% of the time mistakes are made by the simulator. The right lane
has been simulated the worst and the upper lane the best. This seems an unacceptable
high number, but has to be seen in a nuanced light. Although the total error is quite
high, the individual error percentages are still acceptable. As we already noticed in the
previous section, a perfect simulator can never be built. Also, because we will always
make use of calculated data to make comparisons, it won’t be a big problem that the
simulator does not optimally resemble the real-life situation.
Table 2.1: Error percentages of simulator
Left Right Up Down Average
Pcm 43,52 27,97 12,42 3,59 21,88Pmc 3,34 16,70 8,35 30,68 14,77P50 8,99 19,902 28,62 30,14 21,91
Ptot 55,85 64,58 49,40 64,41 58,56
17
Chapter 3
Building a controller
3.1 Introduction
Much research has been done about optimizing the cycle of traffic lights in order to
significantly reduce the total waiting time. In [2] the authors could reduce the lengths
of the queues with around 50% for undersaturated and oversaturated junctions. Since
controlling the flow of cars over a junction is very similar to controlling the flow of
products through one single machine, we also note the promising results of [5]. These
authors have first defined a desired behaviour after which they derived the right policy.
This is an interesting way of tackling the problem, but it won’t be useful in our case,
since we don’t have constant arrival rates like they have in a manufacturing environ-
ment.
The idea of this thesis was to just think about controllers without getting influenced by
previous research. Although we now know how other authors performed, their results
cannot be used in this case, the setting is completely different. After designing one
controller whose results turned out to be insufficient, two extra controllers have been
designed and tested. The Simulink models and MatLab code of all the controllers can
be found in Appendix C.
3.2 Controller based on arrivals
The first controller is based on the principles of statistical process control (SPC), the
application of statistical methods to monitor and control a process and ensure that
it operates at its full potential to produce conforming products. For every product
produced, the method checks whether it satisfies the specifications. Because there will
always be variation in the product, the method allows deviations in between specific
boundaries [7].
19
The controller will make use of the measurements of the incoming flow on the main
road. If it notices an increase in intensity, it will change the cycle time of the traffic
lights in order to give more capacity to the main road. If the intensity drops again,
for example during night-time, there is no longer need to give long green periods to
the main roads and the cycle time can be reduced again to the original level. We have
chosen to work with the cycle time and not with the split time. This means that the
intersecting roads will get a fixed amount of green during every cycle, and the rest of
the time it will be green for the more important roads. This controller will always give
25 seconds of green to the intersecting roads, a number that is chosen without any
calculations or research. Choosing this fixed amount of seconds for the less important
roads means that when the cycle time increases or decreases, the green time for the
main roads does the same.
Like in SPC, we will have to find some boundaries to determine if the inflow of cars is
changing significantly or whether it is just some variability in the system. This will be
done by keeping track of the data of the last 50 minutes and calculating its mean and
standard deviation σ. We will declare the following boundaries:
• 3σ-boundaries: mean± 3σ
• 2σ-boundaries: mean± 2σ
• 1σ-boundaries: mean± σ
During the day, the controller will calculate every minute the average inflow in the
system. If this inflow is significantly different from the other minutes, the controller will
decide there is need for a change in the system. If the flow is significantly increasing, it
will give longer green to the main roads. On the other hand, if the flow is decreasing, it
will give less green, which will also lead to less waiting for the intersecting roads. The
rules to determine if the flow is going out of bound are based on the Western Electric
rules for instability:
• Any single data point falls outside the 3σ-limit from the centreline
• Two consecutive points fall beyond the 2σ-limit
• Three consecutive points fall beyond the 1σ-limit
If one of these rules is breached, the controller will change the cycle time, increase
it if a boundary above the centreline is breached, and decrease it on the other hand. In
Figure 3.1 this process is illustrated, where the red lines resemble the 3σ-boundaries.
It is obvious that we have forgotten to put a limit on the cycle time. After 14000
20
seconds the cycle time is already 220 seconds, which means 195 seconds of waiting for
the intersecting roads, an unrealistic high number. We will experiment with several
limitations on the cycle time in the next chapter.
Figure 3.1: Evolution of cycle time with arrival based controller without limitations. The3σ-boundaries are shown in red
We will end this discussion with an overview of the algorithm as it was implemented
in the controller (Figures C.1 and C.2). The complete code can be found in Appendix
C. When several junctions are connected to each other, we will also have to implement
a green wave for the busiest direction. This will be controlled in the same way as the
cycle time is changed. The controller will calculate the average flow in both directions
of the last 10 minutes and decide which lane is the busiest. Then the lights at every
junction will be controlled in such a way that they turn green at the moment the main
flow from the upstream junction is arriving.
if |flow_last_minute| > significant level
adjust cycle time
recalculate significant levels
end
provide green wave for busiest direction
21
Finally, in Figure C.7, the Simulink model can be found of the controller that also
implements the green wave. In the left top corner, the average of the inflow in the
system is calculated, on the right the signals leave for the traffic lights. All the other
elements are needed to store temporary information, since it is not possible in Simulink
to save variables in the normal way.
3.3 Controller based on average waiting time
The next controller will try to optimize the total waiting time for all the driving
directions by focusing on minimizing the average waiting time. Unlike the previous
controller, this one will take every road into account. The average waiting time will
be calculated as in Figure 3.2. The total queue length will be integrated over time to
find the total waiting time. This at its turn will be divided by the total elapsed time
to come to the average waiting time at every moment in time. We will make use of
the following algorithm which has been based upon the optimization process along a
convex curve with the gradient method [1].
if avg_wt(t) < avg_wt(t-...)
adjust cycle time in same way as before
else
adjust cycle time in the opposite way as before
end
The controller will start working after ten minutes of simulation, when the transient
part seems to be over. The controller will store the average waiting time every minute,
after which it will compare this average with previous averages. If it sees a constant
decrease in average waiting time, it will conclude that it is changing the cycle time in a
good way, and will keep on changing the cycle time in the same way in order to get to
even better results. On the other hand, if the controller notices that changing the cycle
time doesn’t lead to the desired effect, it will start changing the cycle time in the other
way. The cycle time will be limited to minimum 50 seconds, and a maximum with
which will be experimented in the next chapter. The green time for the intersecting
roads is again fixed to 25 seconds.
3.4 Controller based on queues of intersecting roads
Many algorithms of clearing policies exist, like clearing the whole queue or clearing
a fraction [4]. Clearing a fraction of a queue can be a good policy in manufacturing
22
environments, but is not desired in real-life traffic situations. As already described
above, no one likes to wait in front of a traffic light for multiple cycles. So the last
algorithm we are going to implement in a controller will be clearing a whole queue
before giving red again. In manufacturing environments, this policy is applied to all
the product streams. In that case, you will always find yourself in some kind of queue,
a static one or one which is clearing itself. This because from the moment the queue
is empty, the light will turn red and the queue will start growing again. This way, cars
will always have to slow down when approaching a junction, to get to a halt or because
the queue is still emptying and the flow is not yet smooth. This is not desired for the
main roads with the most important flows. So we will only implement the clearing
policy for the intersecting roads, where less traffic is expected and where we can afford
waiting time a little bit more.
if size of one of the queues > 5 || waiting time of single car > max_WT
give green until queues are empty
end
Like the previous controller that is based on the average waiting times, this con-
troller also makes use of the calculated queues in the simulator. There are two con-
ditions that can be used to make the light switch: the size of the queue or the time
a car is already waiting in front of the light. This controller will allow a maximum of
5 cars in the queue before it decides to clear it completely. On the other hand, if the
first car in the queue is waiting longer than a particular amount of time, it will also
be allowed to pass the light. Again there will be experimented with different maximal
waiting times in the next chapter. The number of 5 cars maximum has been chosen so
that neither queue becomes too large. Waiting for 5 cars also prevents the traffic light
from giving green to the intersecting roads all the time. A lower number would lead
to negative results for the main roads.
23
Chapter 4
Results
4.1 Controlling one junction
After designing and implementing the controllers in MatLab, we will now test them
and compare their results for different settings with the other controllers and with the
original situation. Every controller in this section has been tested with the data of
Junction C in Figure 1.3. Simulations have been performed over a period of three
consecutive days. Where the controllers of multiple junctions in the following section
will be tested over a whole week, we could only use 3 consecutive days here because
of a failure in the measuring loops in between junction C and B after three days.
Fortunately, the results after these three days are already a very good indicator of the
strength of the controllers. All the results are compared to the total waiting time of the
original junction without a controller. We will always make use of the calculated data to
make comparisons, not of the measured data. So we can always make valid conclusions,
even though a real-life implementation at the real junction would be leading to other
numbers.
4.1.1 Controller based on arrivals
The first controller that is being tested is the controller that has the arrivals in the
system as input. When it sees a significant increase in arrivals on the main road, it
will give more green to those lanes. This will only be done for the main roads, the
intersecting roads will always get 25 seconds of green during each cycle. As we saw
in Figure 3.1, we also had to limit the green period for the main roads, otherwise the
intersecting queues would explode. In Figure 4.1, we have limited the cycle time to 80
seconds, which means that there will be maximum 55 seconds of green for the main
roads. We see that on Monday the controller doesn’t go to 80 seconds yet, and after
25
the evening rush it drops to around 65 seconds. However during the Tuesday morning
rush, it has to limit the cycle time to 80 seconds due to the significant increase in traffic.
The process repeats the following days. The cycle time is rising during the morning
rush, dropping a little at noon and rising during evening rush. After the evening rush,
it drops to the night level.
Figure 4.1: Evolution of cycle time after controlling
In order to determine the best maximum cycle time, we have run simulations for
different maxima, going from 60 seconds (35 seconds of green for the main roads) to
120 seconds (95 seconds of green for the main roads). The results are shown in Table
4.1 and Figure 4.2. We see the curves progressing all in the same way, steeper during
daytime and flatter at night. Some curves however perform better than others. The
worst setting is the one with a maximum cycle time of 60 seconds. This setting doesn’t
give better results, it increases the total waiting time by 7.72%. The best results are
achieved with a maximum cycle time of 80 seconds, which decreases the maximum
waiting times by 3.5%. After three days, the cars’ total waiting time will be reduced
by 93.807 seconds, or more than 11 hours.
4.1.2 Controller based on average waiting time
The controller that is based on the average waiting time of the four lanes will also be
limited in cycle time. We will again run simulations for different settings, going from
26
Table 4.1: Results of controller based on arrivals
Max CT (s) Total WT (s) Change (%)
60 1225923 7,7270 1124233 -1,2180 1098236 -3,5090 1101744 -3,19
100 1100906 -3,26110 1104636 -2,94120 1104636 -2,94
No controller 1138043
60 to 120 seconds of maximum cycle time. The results in Table 4.2 and Figure 4.3 are
not as promising as with the previous controller. We see that the controller with a
maximum cycle time of 120 seconds already has problems to follow the original curves
during the first hours. The 60, 70 and 90 seconds curves were able to control the lights
normally on Monday, but also went skyrocketing on Tuesday. None of the controllers
was able to decrease the total waiting time, the least bad result is reached with 80
seconds, which gives an increase of 20% in total waiting time.
Table 4.2: Results of controller based on average waiting time
Max CT (s) Total WT (s) Change (%)
60 2530597 122,3670 2527184 122,0680 1373941 20,7390 2976564 161,55
100 1396506 22,71110 1391927 22,31120 3247107 185,32
No controller 1138043
4.1.3 Controller based on queues of intersecting roads
The best results will be obtained with the last controller. This controller will give
green to the intersecting roads from the moment there are more then five cars waiting
or when the first car in the queue is waiting longer than a maximum amount of time.
27
Figure 4.2: Comparison of total waiting times of several cycle time limitations - Arrivalbased controller
Figure 4.3: Comparison of total waiting times of several cycle time limitations - Avg WTcontroller
28
Simulations have been conducted for maximum waiting times going from 10 seconds up
to 70 seconds. Figure 4.4 shows promising results for most of the controllers, except for
the one that limits the maximum waiting times to 10 seconds. Since cars are arriving all
the time at the intersecting roads (because there was no data available from upstream,
we had to average everything out), the traffic lights will have to change almost all the
time, if we also take the 5 seconds of yellow into count. That’s why the limitation of
10 seconds performs dramatically.
Table 4.3 shows the results of all the controllers in detail. Again we see that all the
controllers, except for the 10 seconds, perform better than in the original situation
without a controller. All results lie around a reduction of 40%, with the best result
reached for a maximum waiting time of 30 seconds. This setting reduces the total
waiting time with as much as 48.73%. This result is comparable with the results
obtained in [2]. Where the total amount of waiting time without a controller during
these three days exceeded 13 days, cars will now only have to wait for 583458 seconds,
or more than 6 days less.
Figure 4.4: Comparison of total waiting times of several maximum waiting time limitations- Q controller
4.1.4 Comparison between the best settings
Figure 4.5 will give an overview of the best results of the three controllers. It is obvious
that the controller which clears the intersecting roads is the most promising and that
29
Table 4.3: Results of controller based on queues of intersecting roads
Max WT (s) Total WT (s) Change (%)
10 7338574 544,8420 601667 -47,1330 583458 -48,7340 613797 -46,0750 655629 -42,3960 695494 -38,8970 732595 -35,63
No controller 1138043
the controller based on the arrivals is also giving desirable results. The average waiting
time controller is performing terribly, and will no longer be considered in the following
section.
Figure 4.5: Comparison of best policies - Controlling 1 junction
4.2 Controlling three junctions
After promising results in the previous section, the controllers have been implemented
in the system of three adjacent junctions. The controller that is based on the arrivals
30
is once used as in the previous section, only controlling its own traffic light, and in a
modified version where extra code has been added to implement a green wave. The
last controller that will be investigated is again the controller that clears the queues of
the intersecting roads. Simulations have been performed over a period of 5 days, from
Monday morning until Saturday morning. There was sufficient data to simulate even
more, but memory problems prevented us from doing so. But again, the results will
be already very clear.
4.2.1 Controller based on arrivals at single junction
The first controller doesn’t take the interactions between the different junctions into
account. Like in the previous section, this controller only uses the arrivals at its own
junction. This means that there will be three controllers in the system, one for every
junction. We will again run simulations for different maximum cycle times, going from
60 to 120 seconds and will look at the total waiting time over the three junctions for
comparisons.
Table 4.4 and Figure 4.6 show the results of these simulations. All the settings lie very
close to the original one with three settings performing better and 4 performing worse.
Like in the situation with only one junction, this controller also performs best when
the cycle time is limited to 80 seconds, with a reduction of 7.31% in total waiting in
comparison with the junctions without controllers. This means that this controller is
performing better than in the one junction case, even without creating a green wave.
Table 4.4: Results of controller based on arrivals at single junction - 3 junctions
Max CT (s) Total WT (s) Change (%)
60 4062938 11,3370 3724200 2,0580 3382641 -7,3190 3463011 -5,11
100 3534565 -3,15110 3671091 0,59120 3723188 2,02
No controller 3649440
31
4.2.2 Controller based on arrivals in the system
The next controller is based on the previous one, but had to be adjusted for imple-
menting a green wave. The input data is now not longer the arrivals at every junction,
but will be the arrivals in the system via the main roads. To create a green wave, the
controller determines which road had to handle most traffic over the last 10 minutes,
after which it adjusts the lights in such a way that they turn green when the wave of the
previous junctions arrives. The process is shown in Figure 4.7. The dominant flow has
been determined to go from junction A to junction C. When the light turns green for
junction A, the cars start moving to junction B. Since this travel time is calculated to be
around 30 seconds, the lights in B will switch to green 25 seconds after junction A. So
when the cars arrive at junction B, they will be able to go through without much delay.
The same happens at junction C, 40 seconds after the cars have gone passed junction B.
Simulations have been performed for the same number of maximum cycle times as
before, the results can be found in Table 4.5 and Figure 4.8. Although the implemen-
tation of the green wave seemed to work and we were hoping for better results, we see
that controlling the whole system is not very successful. The best reduction obtained
is only 0.39%, the others are all above the original situation. The graphs show the
same, all the curves are close to each other, none performing much better or worse.
These results can be explained by the actual location of the junctions. Since the N47 is
basically a connecting road between two major cities and not really an access road to a
city, the amount of flow going to both directions is quite similar. We don’t see a large
difference between morning and evening traffic on a specific road, so giving preference
to one lane is not going to give much benefit. If we would have had data of the roads
around Brussels or Antwerp, maybe other results would have been obtained.
Table 4.5: Results of controller based on arrivals in the system - 3 junctions
Max CT (s) Total WT (s) Change (%)
60 3837163 5,1470 3635118 -0,3980 3780332 3,5990 3659711 0,28
100 3664906 0,42110 3775197 3,45120 3897144 6,79
No controller 3649440
32
Figure 4.6: Comparison of total waiting times of several cycle time limitations - Singlejunction controller
Figure 4.7: Creating a green wave through the system
33
Figure 4.8: Comparison of total waiting times of several cycle time limitations - Total sys-tem controller
4.2.3 Controller based on queues of intersecting roads
We will conclude this section with a discussion of the most promising controller of
the previous section, implemented in a situation with three junctions. This is again
a situation were the controller only controls its own junction, so we have a situation
with three controllers at three junctions. Here we will again look at the results with
different maximal waiting times at the intersecting roads. In Figure 4.9 we see the
same pattern as we saw in the previous section, all the controllers performing much
better than without a controller, except for the one with a maximum waiting time of 10
seconds, which again performs dramatically. Table 4.6 shows that the best results are
achieved when the intersecting roads have to wait for maximal 20 seconds after arriving
at the junction. This setting reduced the total waiting time with 46.64%. In five days,
cars in the system will have been waiting almost 20 days less than they should have
been waiting without a controller.
4.2.4 Comparison between the best settings
To conclude this section, an overview of the best of the above three controllers are
shown in Figure 4.10. Like in the situation with one junction, the controller that clears
the intersecting roads again performs significantly better than the two others. They
34
Table 4.6: Results of controller based on queues of intersecting roads - 3 junctions
Max WT (s) Total WT (s) Change (%)
10 13023187 256,8520 1947290 -46,6430 1953538 -46,4740 2082588 -42,9350 2239160 -38,6460 2408327 -34,0170 2573448 -29,48
No controller 3649440
all perform better than without a controller, although the difference with the single
controller for the whole system can hardly be seen. At the end of the simulation, the
cars in the clearing controller situation have waited 1.947.290 seconds. This is as long
as the cars in the normal situation have been waiting after only 2.4 days.
4.3 More detailed results of clearing queues con-
troller
It is obvious that the last controller, the one that clears the queues of the intersecting
roads, is by far the best controller designed. The results for one junction and for the
three connected are quite similar. For this reason we will only discuss extra results for
one of the two situations: the system with only one junction.
The total waiting times have already been discussed in previous section. In Figure
4.11, the average waiting time per car for the best controller is shown: the controller
with maximum waiting time set to 30 seconds. Although we would expect the averages
to be close to each other in the beginning, we already see a significant difference in
averages. This means the controller is already delivering good work from the start. At
the end of the simulation, the average waiting time also has been reduced with 48.73%,
from an average waiting time per car of 3 seconds to only 1.5 seconds.
Next, we will examine how the queues behave differently with and without control-
ling. Figure 4.12 shows the behaviour of the four queues over three days. Remarkable
results have been reached for the left, right and down lane, where the blue queue of
the original situation is clearly much higher than the green queue after controlling.
35
Figure 4.9: Comparison of total waiting times of several maximum waiting time limitations- Q controller
Figure 4.10: Comparison of best policies - Controlling 3 junctions
36
Only the queue of the up lane behaves more similar to the original. So apparently, the
controller has had less effect on this queue.
This observation is confirmed by the numbers. The total queue of left and right has
been reduced by exactly 50%, the queue of the down lane even by 55%. These numbers
are similar to the reduction in waiting time, and the same as found in other research
papers. The upper queue has only been reduced by 31%, but still a remarkable high
number. In total, the queues have been reduced by almost 49%.
4.3.1 Practical implementation
No high financial investments in infrastructure are required when implementing this
controller. The only things that need to be installed in the surrounding of the junction
are
• Sensors in the intersecting roads, at least 5 carlengths away from the stopping
line
• An extra controller in the traffic light controller
The sensors need to be installed at least 5 carlengths away from the lights because
this is the queue size on which the controller will trigger the light to change. If the
lines were closer to the lights, a queue of 5 cars or more could never be seen if only
real data is used and no predictions of arrivals are made. Because the sensors will be
installed in the intersecting roads, the main roads don’t need to be closed and traffic
won’t suffer from extra delays. The implementation of the controller will also be no
great deal. As can be seen in Appendix C.3.2, the extra code is quite limited.
4.4 Summary
In total, six simulation runs have been executed to test the controllers that have been
designed in Chapter 3. Three runs concerned the controllers at one single junction,
the other were for simulating the flows at a system of three junctions. In all cases, a
comparison was made between all the different settings of the controller. Most of the
controllers gave promising results by decreasing the total waiting time in the system.
Only a few were completely incapable of controlling the flows in a desired way. Other
controllers were not giving the desired results, partly because the real setting of the
traffic lights was not one where this controller could be of great help.
In both cases, the best controller turned out to be the controller that cleared the
intersecting queues after 5 cars were waiting in one, or when the first car was waiting for
37
Figure 4.11: Average waiting time per car before and after controlling with clearing queuescontroller
Figure 4.12: Queues before and after controlling with clearing queues controller
38
a maximum amount of time. In the situation of one junction, this controller has reduced
the total waiting time on all the four lanes by 48.73%. When dealing with a situation of
three junctions, one controller was installed at every junction and controlling its lights
independently of the other junctions. This lead to a reduction of 46.64% in waiting
time for the whole system.
39
Appendix A
M-files discussed in Introduction
A.1 Readfiles.m
function [] = Readfiles()
%READFILES Reads textfiles and converts them to usable array
%Junction A
%Inputs at junction A
[ld1A,lline1A,ld2A,lline2A] = OpenFile(’03008_Deel2_Vehicles.txt’,’ ’);
[rd1A,rline1A,rd2A,rline2A] = OpenFile(’03018_Deel2_Vehicles.txt’,
’03020_Deel2_Vehicles.txt’);
[ud1A,uline1A,ud2A,uline2A] = OpenFile(’03013_Deel2_Vehicles.txt’,
’03014_Deel2_Vehicles.txt’);
[dd1A,dline1A,dd2A,dline2A] = OpenFile(’03001_Deel2_Vehicles.txt’,
’03002_Deel2_Vehicles.txt’);
%Outflow at junction A
[lod1A,loline1A,lod2A,loline2A] = OpenFile(’03012_Deel2_Vehicles.txt’,’ ’);
[rod1A,roline1A,rod2A,roline2A] = OpenFile(’03021_Deel2_Vehicles.txt’,’ ’);
[uod1A,uoline1A,uod2A,uoline2A] = OpenFile(’03016_Deel2_Vehicles.txt’,
’03017_Deel2_Vehicles.txt’);
[dod1A,doline1A,dod2A,doline2A] = OpenFile(’03004_Deel2_Vehicles.txt’,
’03005_Deel2_Vehicles.txt’);
%Input before junction A
[Idd1A,Idline1A,Idd2A,Idline2A] = OpenFile(’02014_Deel2_Vehicles.txt’,
’02015_Deel2_Vehicles.txt’);
[Iud1A,Iuline1A,Iud2A,Iuline2A] = OpenFile(’03022_Deel2_Vehicles.txt’,
’03023_Deel2_Vehicles.txt’);
%Junction B
%Inputs at junction B
[ld1B,lline1B,ld2B,lline2B] = OpenFile(’02007_Deel2_Vehicles.txt’,’ ’);
40
[rd1B,rline1B,rd2B,rline2B] = OpenFile(’02016_Deel2_Vehicles.txt’,’ ’);
[ud1B,uline1B,ud2B,uline2B] = OpenFile(’02010_Deel2_Vehicles.txt’,
’02012_Deel2_Vehicles.txt’);
[dd1B,dline1B,dd2B,dline2B] = OpenFile(’02001_Deel2_Vehicles.txt’,
’02003_Deel2_Vehicles.txt’);
%Outflow at junction B
[lod1B,loline1B,lod2B,loline2B] = OpenFile(’02009_Deel2_Vehicles.txt’,’ ’);
[rod1B,roline1B,rod2B,roline2B] = OpenFile(’02018_Deel2_Vehicles.txt’,’ ’);
[uod1B,uoline1B,uod2B,uoline2B] = OpenFile(’02014_Deel2_Vehicles.txt’,
’02015_Deel2_Vehicles.txt’);
[dod1B,doline1B,dod2B,doline2B] = OpenFile(’02005_Deel2_Vehicles.txt’,
’02006_Deel2_Vehicles.txt’);
%Input before junction B
[Idd1B,Idline1B,Idd2B,Idline2B] = OpenFile(’01016_Deel2_Vehicles.txt’,
’01017_Deel2_Vehicles.txt’);
[Iud1B,Iuline1B,Iud2B,Iuline2B] = OpenFile(’03004_Deel2_Vehicles.txt’,
’03005_Deel2_Vehicles.txt’);
%Junction C
%Inputs at junction
[ld1C,lline1C,ld2C,lline2C] = OpenFile(’01009_Deel2_Vehicles.txt’,’ ’);
[rd1C,rline1C,rd2C,rline2C] = OpenFile(’01018_Deel2_Vehicles.txt’,’ ’);
[ud1C,uline1C,ud2C,uline2C] = OpenFile(’01012_Deel2_Vehicles.txt’,
’01014_Deel2_Vehicles.txt’);
[dd1C,dline1C,dd2C,dline2C] = OpenFile(’01003_Deel2_Vehicles.txt’,
’01005_Deel2_Vehicles.txt’);
%Outflow at junction
[lod1C,loline1C,lod2C,loline2C] = OpenFile(’01011_Deel2_Vehicles.txt’,’ ’);
[rod1C,roline1C,rod2C,roline2C] = OpenFile(’01020_Deel2_Vehicles.txt’,’ ’);
[uod1C,uoline1C,uod2C,uoline2C] = OpenFile(’01016_Deel2_Vehicles.txt’,
’01017_Deel2_Vehicles.txt’);
[dod1C,doline1C,dod2C,doline2C] = OpenFile(’01007_Deel2_Vehicles.txt’,
’01008_Deel2_Vehicles.txt’);
%Input before junction
[Idd1C,Idline1C,Idd2C,Idline2C] = OpenFile(’01001_Deel2_Vehicles.txt’,
’01002_Deel2_Vehicles.txt’);
[Iud1C,Iuline1C,Iud2C,Iuline2C] = OpenFile(’02005_Deel2_Vehicles.txt’,
’02006_Deel2_Vehicles.txt’);
save data.mat;
clear all;
41
end
function [d1,line1,d2,line2] = OpenFile(file1,file2)
fid1=fopen(file1);
C1=textscan(fid1, ’%*d %s %s %s %d’);
temp=strcat(C1{1}, {’ ’} ,C1{2},’.’,C1{3});
d1=datenum(temp,’dd/mm/yyyy HH:MM:SS.FFF’);
line1=C1{4};
d2=0;
line2=0;
if(file2 ~= ’ ’)
fid2=fopen(file2);
C2=textscan(fid2, ’%*d %s %s %s %d’);
temp=strcat(C2{1}, {’ ’} ,C2{2},’.’,C2{3});
d2=datenum(temp,’dd/mm/yyyy HH:MM:SS.FFF’);
line2=C2{4};
end
fclose(’all’);
end
A.2 Readtime.m
function [flow] = Readtime(d1,line1,n1,d2,line2,n2,cycle,start,final)
%READTIME Scans every line if it matches the counting line and creates a
%flow
%Define start en final timestamp
start=datenum(start,’dd/mm/yyyy HH:MM:SS.FFF’);
final=datenum(final,’dd/mm/yyyy HH:MM:SS.FFF’);
stop=addtodate(start, cycle, ’second’);
i=1;
%Go to start in array
while d1(i)<start
i=i+1;
end
%Create array with intervals
j=round((d1(i)-start)*24*60*60/cycle)+1;
flow1=zeros(round((final-start)*24*60*60/cycle+j),2); %Time - Cars/sec
for k=2:length(flow1)
flow1(k,1)=flow1(k-1,1)+cycle;
42
end
while stop<d1(i)
stop=addtodate(stop, cycle, ’second’);
end
%Start counting
while i < length(d1) && d1(i)<=final
while d1(i)<stop && i<length(d1)
if line1(i)==n1
flow1(j,2)=flow1(j,2)+1;
end
i=i+1;
end
j=j+1;
stop=addtodate(stop, cycle, ’second’);
end
if(d2 > 0)
i=1;
while d2(i)<start
i=i+1;
end
stop=addtodate(start, cycle, ’second’);
while stop<d2(i)
stop=addtodate(stop, cycle, ’second’);
end
j=round((d2(i)-start)*24*60*60/cycle)+1;
flow2=zeros(round((final-start)*24*60*60/cycle+j),2); %Time - Cars/sec
for k=2:length(flow2)
flow2(k,1)=flow2(k-1,1)+10;
end
while i<length(d2) && d2(i)<=final
while d2(i)<stop && i<length(d2)
if line2(i)==n2
flow2(j,2)=flow2(j,2)+1;
end
i=i+1;
end
j=j+1;
stop=addtodate(stop, cycle, ’second’);
end
43
flow1=flow1(1:min(length(flow1),length(flow2)),:);
flow2=flow2(1:min(length(flow1),length(flow2)),:);
%Flow is sum over two lines
flow=[flow1(:,1) flow1(:,2)+flow2(:,2)];
else
flow=flow1;
end
%Flow in interval is total flow divided by the axels and cycle
flow(:,2)=flow(:,2)/2/cycle;
end
A.3 Createflow.m
function [flowleft, flowright, flowup, flowdown, flowleftout, flowrightout,
flowupout, flowdownout, flowdownin, flowupin, redgreen, redgreencycle,
pdownstraight, pupstraight, pleftstraight, prightstraight] =
CreateFlow(cycle,start,final,junction)
%% Create flow in interval
if junction==’A’
load(’data.mat’,’ld1A’,’lline1A’,’ld2A’,’lline2A’,’rd1A’,’rline1A’, ...
flowleft = Readtime(ld1A,lline1A,03008,ld2A,lline2A,0,cycle,start,final);
flowright = Readtime(rd1A,rline1A,03018,rd2A,rline2A,03020,cycle, ...
flowup = Readtime(ud1A,uline1A,03013,ud2A,uline2A,03014,cycle,start, ...
flowdown = Readtime(dd1A,dline1A,03001,dd2A,dline2A,03002,cycle, ...
len1=min(min(min(length(flowleft),length(flowright)),length(flowup)),
length(flowdown));
flowleftout = Readtime(lod1A,loline1A,03012,lod2A,loline2A,0,10, ...
flowrightout = Readtime(rod1A,roline1A,03021,rod2A,roline2A,0,10, ...
flowupout = Readtime(uod1A,uoline1A,03016,uod2A,uoline2A,03017,10, ...
flowdownout = Readtime(dod1A,doline1A,03004,dod2A,doline2A,03005,10, ...
len2=min(min(min(length(flowleftout),length(flowrightout)),
length(flowupout)), length(flowdownout));
flowdownin = Readtime(Idd1A,Idline1A,02014,Idd2A,Idline2A,02015, ...
flowdownin = [flowdownin(1:end-2,1) flowdownin(3:end,2)];
flowupin = Readtime(Iud1A,Iuline1A,03022,Iud2A,Iuline2A,03023,cycle, ...
flowupin = [flowupin(1:end-3,1) flowupin(4:end,2)];
len=min(min(min(len1,len2),length(flowdownin)),length(flowupin));
44
flowleft=flowleft(1:len,:);
flowright=flowright(1:len,:);
flowup=flowup(1:len,:);
flowdown=flowdown(1:len,:);
flowleftout=flowleftout(1:len,:);
flowrightout=flowrightout(1:len,:);
flowupout=flowupout(1:len,:);
flowdownout=flowdownout(1:len,:);
flowdownin=flowdownin(1:len,:);
flowupin=flowupin(1:len,:);
end
if junction==’B’
load(’data.mat’,’ld1B’,’lline1B’,’ld2B’,’lline2B’,’rd1B’,’rline1B’, ...
flowleft = Readtime(ld1B,lline1B,02007,ld2B,lline2B,0,cycle, ...
flowright = Readtime(rd1B,rline1B,02017,rd2B,rline2B,0,cycle, ...
flowup = Readtime(ud1B,uline1B,02010,ud2B,uline2B,02012,cycle, ...
flowdown = Readtime(dd1B,dline1B,02001,dd2B,dline2B,02003,cycle, ...
len1=min(min(min(length(flowleft),length(flowright)),
length(flowup)),length(flowdown));
flowleftout = Readtime(lod1B,loline1B,02009,lod2B,loline2B,0,10, ...
flowrightout = Readtime(rod1B,roline1B,02018,rod2B,roline2B,0,10, ...
flowupout = Readtime(uod1B,uoline1B,02014,uod2B,uoline2B,02015,10, ...
flowdownout = Readtime(dod1B,doline1B,02005,dod2B,doline2B,02006,10, ...
len2=min(min(min(length(flowleftout),length(flowrightout)),
length(flowupout)),length(flowdownout));
flowdownin = Readtime(Idd1B,Idline1B,01016,Idd2B,Idline2B,01017, ...
flowdownin = [flowdownin(1:end-5,1) flowdownin(6:end,2)];
flowupin = Readtime(Iud1B,Iuline1B,03004,Iud2B,Iuline2B,03005,cycle, ...
flowupin = [flowupin(1:end-3,1) flowupin(4:end,2)];
len=min(min(min(len1,len2),length(flowdownin)),length(flowupin));
flowleft=flowleft(1:len,:);
flowright=flowright(1:len,:);
flowup=flowup(1:len,:);
flowdown=flowdown(1:len,:);
flowleftout=flowleftout(1:len,:);
45
flowrightout=flowrightout(1:len,:);
flowupout=flowupout(1:len,:);
flowdownout=flowdownout(1:len,:);
flowdownin=flowdownin(1:len,:);
flowupin=flowupin(1:len,:);
end
if junction==’C’
load(’data.mat’,’ld1C’,’lline1C’,’ld2C’,’lline2C’,’rd1C’,’rline1C’, ...
flowleft = Readtime(ld1C,lline1C,01009,ld2C,lline2C,0,cycle, ...
flowright = Readtime(rd1C,rline1C,01018,rd2C,rline2C,0,cycle, ...
flowup = Readtime(ud1C,uline1C,01012,ud2C,uline2C,01014,cycle, ...
flowdown = Readtime(dd1C,dline1C,01003,dd2C,dline2C,01005,cycle, ...
len1=min(min(min(length(flowleft),length(flowright)),length(flowup)),
length(flowdown));
flowleftout = Readtime(lod1C,loline1C,01011,lod2C,loline2C,0,10, ...
flowrightout = Readtime(rod1C,roline1C,01020,rod2C,roline2C,0,10, ...
flowupout = Readtime(uod1C,uoline1C,01016,uod2C,uoline2C,01017,10, ...
flowdownout = Readtime(dod1C,doline1C,01007,dod2C,doline2C,01008,10, ...
len2=min(min(min(length(flowleftout),length(flowrightout)),
length(flowupout)),length(flowdownout));
flowdownin = Readtime(Idd1C,Idline1C,01001,Idd2C,Idline2C,01002, ...
flowdownin = [flowdownin(1:end-2,1) flowdownin(3:end,2)];
flowupin = Readtime(Iud1C,Iuline1C,02005,Iud2C,Iuline2C,02006,cycle, ...
flowupin = [flowupin(1:end-3,1) flowupin(4:end,2)];
len=min(min(min(len1,len2),length(flowdownin)),length(flowupin));
flowleft=flowleft(1:len,:);
flowright=flowright(1:len,:);
flowup=flowup(1:len,:);
flowdown=flowdown(1:len,:);
flowleftout=flowleftout(1:len,:);
flowrightout=flowrightout(1:len,:);
flowupout=flowupout(1:len,:);
flowdownout=flowdownout(1:len,:);
flowdownin=flowdownin(1:len,:);
flowupin=flowupin(1:len,:);
46
end
%% Determine red-green cycle
if flowup(1,2)>0 || flowdown(1,2)>0
redgreen = [flowup(1,1) 0];
else
redgreen = [flowup(1,1) 1];
end
for i=2:length(flowleft)-1
%1: groen voor left/right
%0: groen voor up/down
if flowleft(i,2)>0 || flowright(i,2)>0
redgreen = [redgreen; flowup(i,1) 1];
else
redgreen = [redgreen; flowup(i,1) 0];
end
if (flowup(i,2)>0 || flowdown(i,2)>0) &&
(flowleft(i,2)>0 || flowright(i,2)>0)
if (flowup(i+1,2)>0 && flowup(i-1,2)==0) ||
(flowdown(i+1,2)>0 && flowdown(i-1,2)==0)
%interval erna is het groen voor up/down, ervoor rood
redgreen(end,:) = [flowup(i,1) 0];
else
redgreen(end,:) = [flowup(i,1) 1];
end
end
end
%Determine periods of same cycletime
if redgreen(1,2)==0
redgreencycle=[0 10 10]; %leftright - updown - total
else
redgreencycle=[10 0 10];
end
for i=2:length(redgreen(:,1))
if redgreen(i-1,2)~=redgreen(i,2) &&
(redgreencycle(end,1)>0 && redgreencycle(end,2)>0)
redgreencycle=[redgreencycle; 0 0 0];
end
if redgreen(i,2)==1
redgreencycle(end,1)=redgreencycle(end,1)+10; %leftright is driving
else
47
redgreencycle(end,2)=redgreencycle(end,2)+10; %updown is driving
end
redgreencycle(end,3)=redgreencycle(end,1)+redgreencycle(end,2);
end
%% Determine percentages
pdownstraight=[flowupout(:,1) zeros(length(flowupout(:,1)),1)];
pupstraight=[flowupout(:,1) zeros(length(flowupout(:,1)),1)];
pleftstraight=[flowupout(:,1) zeros(length(flowupout(:,1)),1)];
prightstraight=[flowupout(:,1) zeros(length(flowupout(:,1)),1)];
for i=1:length(flowupout(:,1))
if flowdown(i,2)~=0
pdownstraight(i,:)=
[flowupout(i,1) min(flowupout(i,2)./flowdown(i,2),1)];
end
if flowup(i,2)~=0
pupstraight(i,:)=
[flowdownout(i,1) min(flowdownout(i,2)./flowup(i,2),1)];
end
if flowleft(i,2)~=0
pleftstraight(i,:)=
[flowrightout(i,1) min(flowrightout(i,2)./flowleft(i,2),1)];
end
if flowright(i,2)~=0
prightstraight(i,:)=
[flowleftout(i,1) min(flowleftout(i,2)./flowright(i,2),1)];
end
end
%% Calculate arrivals in system of intersecting roads
temp=1;
for i=2:length(redgreen)
if redgreen(i,2)==redgreen(temp,2) && redgreen(i-1,2)~=redgreen(temp,2)
%at the end of a redgreen-cycle
flowleft(temp:i,2)=ones(i-temp+1,1).*
sum(flowleft(temp:i,2))/(flowleft(i,1)-flowleft(temp,1))*cycle;
flowright(temp:i,2)=ones(i-temp+1,1).*
sum(flowright(temp:i,2))/(flowright(i,1)-flowright(temp,1))*cycle;
temp=i;
end
end
48
Appendix B
M-files discussed in the Simulatorchapter
B.1 Verify the simulator
function [Pcm,Pmc,P50,Ptot] =
verify_sim(leftout,leftoutm,rightout,rightoutm,upout,upoutm,downout,downoutm)
%Pcm = Percentage flow calculated but no flow measured
%Pmc = Percentage flow measured but not calculated
%P50 = Percentage flow calculated 50% more/less than measured
Pcm=zeros(1,5);
Pmc=zeros(1,5);
P50=zeros(1,5);
[Pcm(1),Pmc(1),P50(1),Ptot(1)] = verifier (leftout,leftoutm);
[Pcm(2),Pmc(2),P50(2),Ptot(2)] = verifier (rightout,rightoutm);
[Pcm(3),Pmc(3),P50(3),Ptot(3)] = verifier (upout,upoutm);
[Pcm(4),Pmc(4),P50(4),Ptot(4)] = verifier (downout,downoutm);
Pcm(5)=mean(Pcm(1:4));
Pmc(5)=mean(Pmc(1:4));
P50(5)=mean(P50(1:4));
Ptot(5)=mean(Ptot(1:4));
end
function [Pcm,Pmc,P50,Ptot] = verifier (outc,outm)
Pcm=0;
Pmc=0;
P50=0;
%Iterate over all intervals to check correctness
49
for i=1:length(outc)
if outc(i)==0 && outm(i)~=0
Pmc=Pmc+1;
else if outc(i)~=0 && outm(i)==0
Pcm=Pcm+1;
else if outc(i)>1.5*outm(i) || outc(i)<0.5*outm(i)
P50=P50+1;
end
end
end
end
Pmc=100*Pmc/i;
Pcm=100*Pcm/i;
P50=100*P50/i;
Ptot=Pcm+Pmc+P50;
end
50
Appendix C
Overview of controllers
C.1 Controlling one traffic light based on flow input
C.1.1 Simulink model
Figure C.1: Simulator and controllerFigure C.2: Inside the controller
Figure C.1: Simulink model of simulator with controller based on arrivals
C.1.2 MatLab code
function [controlstream1,tempmean1,countstream1,CL1,sigma1,gemnul,gemcyclus,
out] = controller(stream,controlstream,time,tempmean,countstream,CL,sigma,
gemnulin,gemcyclusin,maxCT)
countstream=countstream+1;
51
gemcyclus=gemcyclusin;
if mod(time,60)==0 && time > 0
controlstream=[tempmean ; controlstream(1:end-1)];
if time>50*60 %After 50 minutes enough data gathered
%Check every boundary
if tempmean>CL+3*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, +1);
end
if tempmean<CL-3*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, -1);
end
if tempmean>CL+2*sigma && controlstream(2)>CL+2*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, +1);
end
if tempmean<CL-2*sigma && controlstream(2)<CL-2*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, -1);
end
if tempmean>CL+sigma && controlstream(2)>CL+sigma &&
controlstream(3)>CL+sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, +1);
end
if tempmean<CL-sigma && controlstream(2)<CL-sigma &&
controlstream(3)<CL-sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, -1);
end
end
tempmean=stream;
countstream=0;
else
%% Calculating mean over period of x minutes
tempmean=tempmean+(stream-tempmean)/countstream;
53
end
gemcyclus=min(gemcyclus,maxCT);
gemnul=gemcyclus-25;
%Determine red or green
if mod(time,gemcyclus)>=gemnul
out=1;
else out=0;
end
%% Update variables
tempmean1=tempmean;
countstream1=countstream;
controlstream1=controlstream;
CL1=CL;
sigma1=sigma;
end
function [CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, updown)
gemnul=gemnulin;
gemcyclus=gemcyclusin+updown;
CL=mean(controlstream);
sigma=std(controlstream);
end
C.2 Controlling one traffic light based on average
waiting time
C.2.1 Simulink model
Figure C.3: Simulator and controllerFigure C.4: Inside the controller
C.2.2 MatLab code
function [avgwtarray1,gemcyclus,dir1,out] =
controller(avgwt,avgwtarray,time,gemcyclusin,dir,MaxCT)
54
Figure C.3: Simulink model of simulator with controller based on average waiting times
Figure C.4: Simulink model of controller based on average waiting times
55
gemcyclus=gemcyclusin;
if mod(time,60)==0 && time > 600
avgwtarray=[avgwt ; avgwtarray(1:end-1)];
if avgwt<avgwtarray(2) || avgwt<avgwtarray(3)
gemcyclus=max(50,min(gemcyclus+dir,MaxCT));
else
dir=-dir;
gemcyclus=max(50,min(gemcyclus+dir,MaxCT));
end
end
gemnul=gemcyclus-25;
if mod(time,gemcyclus)>=gemnul
out=1;
else out=0;
end
%% Update variables
avgwtarray1=avgwtarray;
dir1=dir;
end
C.3 Controlling one traffic light based on queue-
sizes
C.3.1 Simulink model
Figure C.5: Simulator and controllerFigure C.6: Inside the controller
C.3.2 MatLab code
function [stamp1,emptying1,out] =
controller(QLeft,QRight,time,stamp,emptying,maxWT)
%First car has arrived in queue
if (QLeft>0 || QRight>0) && stamp==0
stamp=time;
end
%More than 5 cars in queue, or waiting longer than maxWT
56
Figure C.5: Simulink model of simulator with controller based on clearing queues
Figure C.6: Simulink model of controller based on clearing queues
57
if (QLeft>5 || QRight>5) || (time-stamp)>maxWT
emptying=1;
end
%Queues are empty
if emptying && QLeft==0 && QRight==0
emptying=0;
stamp=0;
end
%Green for intersecting while clearing
if emptying
out=1;
else
out=0;
end
stamp1=stamp;
emptying1=emptying;
end
C.4 Controlling three traffic lights based on flow
input
C.4.1 Simulink model
Figure C.7: Inside the controller
C.4.2 MatLab code
function [controlstream1,tempmean1,countstream1,CL1,sigma1,gemnul,gemcyclus,
outA,outB,outC,tempA1,tempC1,dir1] = controller(stream,controlstream,time,
tempmean,countstream,CL,sigma,gemnulin,gemcyclusin,inA,inC,tempA,tempC,dir,
maxCT)
countstream=countstream+1;
gemcyclus=gemcyclusin;
if mod(time,60)==0 && time > 0
controlstream=[tempmean ; controlstream(1:end-1)];
if time>50*60 %After 50 minutes enough data gathered
58
%Check for every boundary
if tempmean>CL+3*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, +1);
end
if tempmean<CL-3*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, -1);
end
if tempmean>CL+2*sigma && controlstream(2)>CL+2*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, +1);
end
if tempmean<CL-2*sigma && controlstream(2)<CL-2*sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, -1);
end
if tempmean>CL+sigma && controlstream(2)>CL+sigma &&
controlstream(3)>CL+sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, +1);
end
if tempmean<CL-sigma && controlstream(2)<CL-sigma &&
controlstream(3)<CL-sigma
[CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, -1);
end
end
tempmean=stream;
countstream=0;
else
%% Calculating mean over period of x minutes
tempmean=tempmean+(stream-tempmean)/countstream;
end
%% Determine which direction is busiest
if mod(time,600)==0 && time > 0
if tempA>tempC
dir=-1;
else
59
dir=1;
end
tempA=inA;
tempC=inC;
else
tempA=tempA+(inA-tempA)/(mod(time,600)+1);
tempC=tempC+(inC-tempC)/(mod(time,600)+1);
end
gemcyclus=min(gemcyclus,maxCT);
gemnul=gemcyclus-25;
%% Determine green wave
% A->B: 30s
% B->C: 40s
if dir==1 % Flow from C -> A
if mod(time,gemcyclus)>=gemnul
outC=1;
else outC=0;
end
if mod(time-35+gemcyclus,gemcyclus)>=gemnul
outB=1;
else outB=0;
end
if mod(time-60+gemcyclus,gemcyclus)>=gemnul
outA=1;
else outA=0;
end
else % Flow from A -> C
if mod(time,gemcyclus)>=gemnul
outA=1;
else outA=0;
end
if mod(time-25+gemcyclus,gemcyclus)>=gemnul
outB=1;
else outB=0;
end
if mod(time-60+gemcyclus,gemcyclus)>=gemnul
outC=1;
else outC=0;
end
end
60
%% Update variables
tempmean1=tempmean;
countstream1=countstream;
controlstream1=controlstream;
CL1=CL;
sigma1=sigma;
tempA1=tempA;
tempC1=tempC;
dir1=dir;
end
function [CL, sigma, gemnul, gemcyclus]=
Change(controlstream, gemnulin, gemcyclusin, updown)
gemnul=gemnulin+updown;
gemcyclus=gemcyclusin+updown;
CL=mean(controlstream);
sigma=std(controlstream);
end
61
Bibliography
[1] Rene Boel. Monte Carlo and Stochastic Simulation. Ghent University, 2009. Syl-labus.
[2] A. Ceder and I. Reshetnik. An algorithm to minimize queues at signalized inter-sections. Journal of the Operational Research Society, (52):615–622, 2001.
[3] T. Chan, G. Golub, and R. LeVeque. Algorithms for computing the sample variance:Analysis and recommendations. The American Statistician, (37):242–247, 1983.
[4] P.R. Kumar and T.I. Seidman. Dynamic instabilities and stabilization methods indistributed real-time scheduling of manufacturing systems. IEEE Transactions onAutomatic Control, 35(3):289–298, 1990.
[5] E. Lefeber and J.E. Rooda. Controller design for switched linear systems withsetups. Physica A: Statistical Mechanics and its Applications, 363(1):48–61, 2006.
[6] R. Ling. Comparison of several algorithms for computing sample means and vari-ances. Journal of the American Statistical Association, 69(348):859–866, 1974.
[7] Douglas C. Montgomery. Statistical Quality Control: A Modern Introduction. JohnWiley and Sons, 6th edition, 2008.
[8] F. Vanhove. Analyse van de mobiliteit op de belgische autosnelwegen. Technicalreport, Transport and Mobility Leuven, June 2008.
63
top related