Online Control of Traffic Lights

77

Transcript of Online Control of Traffic Lights

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

Figure 1.2: Situation of junctions on the N47

Figure 1.3: Detailed drawning of the setting

5

(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

Figure 1.5: Data as given

9

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

Figure 2.5: Simulink model of three connected junctions

14

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

Figure 2.7: Behaviour of the queues, in response of the traffic light

18

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

Figure 3.2: Section of Simulink model that calculated the average waiting time

24

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

Figure C.2: Simulink model of controller based on arrivals

52

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

Figure C.7: Simulink model of controller based on arrivals - 3 junctions

62

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