DEGREE PROJECT, IN , FIRST LEVELCOMPUTER SCIENCE

STOCKHOLM, SWEDEN 2015

A Comparison of a Genetic Algorithmand Simulated Annealing Applied to aTraffic Light Control Problem

A TRAFFIC INTERSECTION OPTIMIZATIONPROBLEM

BENJAMIN BURVALL AND JOHANNES OLEGÅRD

KTH ROYAL INSTITUTE OF TECHNOLOGY

CSC SCHOOL

A Comparison of a Genetic Algorithm and SimulatedAnnealing Applied to a Traffic Light Control Problem

A Traffic Intersection Optimization Problem

Burvall, Benjamin Olegård, Johannes

Degree Project in Computer Science, DD143X

Supervisor: Herman, PawelExaminer: Ekeberg, Örjan

School of Computer Science, Royal Institute of Technology, Sweden 2015-05-10

Abstract

This work compares a Genetic Algorithm (GA) and Simulated Annealing(SA) when applied to a variant of the Traffic Light Control Problem (TLCP).TLCP is about controlling the lights in one or more traffic intersections inorder to optimize traffic flow. This is important in order for society tofunction properly. The idea is that to solve this problem quickly, as wouldbe necessary in a real traffic situation, stochastic search algorithms like SAand GA should be used. GA and SA in particular are chosen because theyare often used in previous work.

A 4-way traffic intersection is simulated. GA and SA are used to find aschedule for lighting the traffic lights in such a way that for a given collectionof cars, the traffic flow is maximized. The goal is to study how traffic flowsin the solutions produced by GA and SA when the problem size increases.

The conclusion of this work is that SA seems to generally finds bettersolutions than GA in small search spaces and that SA and GA are comparablein larger search spaces.

i

Sammanfattning

Det här arbetet jämför en Genetisk Algoritm (GA) och Simulated An-nealing (SA) när de appliceras på en variant av Trafikljusstyrningsproblemet(TLCP). TLCP handlar om att styra trafikljus i en eller flera trafikkorsningarför att optimera trafikflödet genom dem. Detta är viktigt för att samhälletska fungera bra. Tanken för att lösa problemet tillräckligt snabbt för attfungera i verklig trafik är att använda sig av stokastiska algoritmer såsomGA och SA. Just GA och SA har valts eftersom de ofta används i liknandearbeten.

En 4-vägs trafikkorsning simuleras. GA och SA används för att hitta ettschema för hur trafikljusen ska styras för att trafikflödet ska optimeras, fören given mängd bilar. Målet är att studera hur trafikflödet för lösningarnaproducerade av GA och SA skalar när storleken på problemet växer.

Som slutsats konstateras att SA generellt hittar bättre lösningar på kor-tare tid än GA när det gäller mindre lösningar. För större lösningar var GAoch SA jämförbara.

ii

Contents

List of Figures iv

1 Introduction 1

1.1 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement and Scope . . . . . . . . . . . . . . . . . . 31.3 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 5

2.1 Traffic Light Control Problem (TLCP) . . . . . . . . . . . . . 5

3 Methods 9

3.1 Optimization Methods . . . . . . . . . . . . . . . . . . . . . . 93.1.1 Genetic Algorithms (GA) . . . . . . . . . . . . . . . . 93.1.2 Simulated Annealing (SA) . . . . . . . . . . . . . . . . 113.1.3 Implementations . . . . . . . . . . . . . . . . . . . . . 12

3.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.1 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Running Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Results 20

5 Discussion 24

5.1 The Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Criticism of Simulation . . . . . . . . . . . . . . . . . . . . . . 255.3 Possible Practical Applications . . . . . . . . . . . . . . . . . 26

6 Conclusion 27

7 Bibliography 28

iii

List of Figures

2.1 Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Example Configuration . . . . . . . . . . . . . . . . . . . . . . 143.3 All Lights Green With Collision Points . . . . . . . . . . . . . 153.4 Maximal Configuration . . . . . . . . . . . . . . . . . . . . . . 15

4.1 SA average traffic flows . . . . . . . . . . . . . . . . . . . . . 214.2 GA average traffic flows . . . . . . . . . . . . . . . . . . . . . 214.3 SA average running times . . . . . . . . . . . . . . . . . . . . 224.4 GA average running times . . . . . . . . . . . . . . . . . . . . 224.5 SA and GA traffic flow comparison . . . . . . . . . . . . . . . 234.6 SA and GA running time comparison . . . . . . . . . . . . . . 23

iv

Chapter 1

Introduction

Scheduling, in general, is about allocating the “what, when and where”. Forexample tasks, times and machines, or people, times and rooms. Oftenthere are many solutions and some solutions are more suitable than others.Therefore optimizing these problems often require computers.

1.1 Scheduling

This section introduces different scheduling problems and variations of theseproblems. Some real world applications include:

Meeting scheduling

Business meetings and university courses and exams can be timed tofulfill certain conditions, e.g. minimize collision, distribute workload& preferences.

Task planning

When 𝑛 tasks need to be performed by 𝑚 workers, scheduling can beused to minimize the total time (or cost), possibly fulfilling certainconditions. For example: tasks have different requirements, workershave different qualifications, workers need vacation, etc.

Traffic routing

Cars and network packets can be timed and routed to minimize conges-tion. Electric circuits can be routed to distribute heat and interferenceload across a board.

These problems are usually difficult; in fact most variations are NP-hard.Meaning, that finding an optimal solution deterministically generally takesa long time, even on computers. Compare e.g. traffic routing with the knownNP-hard traveling salesman problem (TSP).

1

CHAPTER 1. INTRODUCTION 1.1. SCHEDULING

It suffices to say, efficient and optimal schedulers are useful for many realworld applications.

The problem in focus in this work is a variation of traffic routing called theTraffic Light Control Problem (TLCP). Consider one or more traffic intersec-tions: with traffic lights, times and lanes. By scheduling green and red lightsfor the lanes in different ways it is possible to optimize the overall trafficflow. Efficient flow of traffic is necessary for society to function properly, e.g.for business, leisure and in case of emergency.

There are many ways to schedule a functional intersection, e.g. by green-lighting a single lane at a time. That would, however, stall the other lanes,and it is more efficient to greenlight multiple lanes at the same time. Fur-thermore, there are also safety constraints to take into consideration. Forexample, some lanes should not be greenlit at the same time to prevent col-lisions. In real traffic systems a short optimal schedule is usually chosenahead of time and is then cycled. [1–3] This way, the schedule can be reusedfor a long time. However, this is not necessarily efficient, since unoccupiedlanes may still be greenlit. Therefore, research has been spent on developingdynamic systems and efficient algorithms that can make decisions in realtime (e.g. [1–4]).

In this work a single 4-way intersection is modeled, with each arm con-sisting of two intersection-facing lanes: one lane for left-turning cars andone lane for cars continuing forward or to the right. The exact variation ofTLCP in this work, is the problem of finding a schedule of a given size thatis optimal for a specific collection of cars about to arrive at the intersection.The optimality of a schedule is represented by the evaluation value, whichis a real number in the range [0, 1] where 1 is optimal. The evaluation isdetermined by simulating the cars in the intersection with that schedule.

This problem is solved in this work by stochastically trying differentschedules in order to find a schedule as optimal as possible within a lim-ited amount of time.

There exists different algorithms for heuristically trying different sched-ules in this way. In this work, two such algorithms are tested: a geneticalgorithm (GA) and simulated annealing (SA). The goal of this work is tocompare these two algorithms when applied to the above TLCP.

Both algorithms work by starting with some (usually random) scheduleand by repeatedly making small stochastic changes to the schedule in orderobtain other schedules that are possibly closer to optimal.

GA works specifically by starting with a population of schedules andobtaining another population by combining the schedules in different ways.The idea is to repeatedly evolve the population like this, as by natural evo-lution. [5, 6]

2

CHAPTER 1. INTRODUCTION 1.2. PROBLEM STATEMENT AND SCOPE

SA works by walking from one schedule to the next. A candidate scheduleis chosen randomly, but is only accepted as the next schedule if it is betteror, by a probability based on the current temperature. The temperatureis initially high and decreases as time passes. The idea is that it initiallyis useful to accept a less optimal schedule in order to try vastly differentschedules as not to get stuck in a local optimum, i.e. a schedule that seemslike the best possible when only considering its immediate neighborhood ofsolutions. [7–9]

1.2 Problem Statement and Scope

The goal of this work is to study and compare the two stochastic optimizationalgorithms GA and SA, when applied to the TLCP. That is:

∙ How does the traffic flow of the solutions, found by the algorithms,scale with the problem size?

The primary motivation for the choice of algorithms is that they are citedin many works regarding optimization, both TLCP and other schedulingproblems. [1, 4, 10,11]

The focus of this work is on optimizing a single 4-way intersection whereall input is immediately available. This is not a study of online algorithms,where results can be produced from small pieces of input at a time. Incomparison, the algorithm presented in this work will require a larger amountof input to draw any conclusions.

1.3 Hypothesis

GA is expected to converge slowly, but surely. It is hypothesized that GAis not particularly well suited to take advantage of characteristics specific toTLCP.

SA is expected to be fast due to processing one solution at a time, butmay for the same reason not find a as high-quality solution overall comparedto GA which search in multiple places simultaneously. Though, this dependson how transitions between solutions are defined. Because of this, SA isexpected to find better solutions than GA in smaller search spaces when runfor the same amount of time.

SA is expected to find a good enough solution fast, but “stagnate” afterthat. In comparison GA is expected to take longer to find a good enoughsolution, but should stagnate at a slower rate. GA is expected to find bettersolutions than SA in larger search spaces when run for the same amount oftime.

Therefore it is hypothesized that GA scales better than SA.

3

CHAPTER 1. INTRODUCTION 1.4. OUTLINE

1.4 Outline

The following chapter, 2 Background, reviews TLCP in previous work.In chapter 3 Method a model for TLCP and its simulation are presented.

The two algorithms are explained and some implementation details shown.Following, in chapter 4 Result, diagrams for the performance of the im-

plementations are presented. These are then discussed in the final chapters.

4

Chapter 2

Background

This chapter provides an overview of TLCP and previous works.

2.1 Traffic Light Control Problem (TLCP)

As described in the previous chapter, TLCP is an optimization problem forone or more intersections where the goal is to optimize the overall trafficflow. There exists many variations and models of TLCP, some study asingle intersection [2,11] while most study multiple intersections in a network[1, 3, 4, 12].

Real traffic is usually control by using fixed cycles of phases. For example,let an intersection consist of 4 intersection-facing lanes. A simple cycle wouldbe to greenlight a single lane at a time as shown in figure 2.1a. It is also pos-sible to cycle in pairs of lanes, as shown in figure 2.1b. The former cycle hasfour phases and the latter has two phases. Note that the cycles do not neces-sarily have to greenlight each lane exactly once, e.g. (𝐴𝐵,𝐶,𝐴𝐵,𝐴,𝐷,𝐵),where 𝐴,𝐵,𝐶,𝐷 are different lanes is also a possible cycle.

Cycles are usually manually planned ahead of time and then repeatedindefinitely by the traffic lights in the intersection, hour by hour, day byday, year by year. Statistics are used to, for some measure, optimally choosea cycle and adjust the duration length for each phase of the cycle [1]. Forexample, if some lanes are more likely to have a larger amount of cars thanthe other lanes, they can be given more greentime in the cycle. Since cyclesare planned ahead of time, they are not adjusted in real time to the currenttraffic situation. This has some drawbacks, for example, lanes where thereare no cars currently may still be greenlit, possibly for a long duration oftime, making cars in other lanes wait unnecessarily.

5

CHAPTER 2. BACKGROUND 2.1. TRAFFIC LIGHT CONTROL PROBLEM (TLCP)

(a)

(b)

Figure 2.1: (a) and (b) show examples of cycles for a small intersection.Arrows indicate transitions in time.

Research on TLCP is mainly spent on:

∙ Finding optimal cycles and durations (as mentioned above).

∙ Finding efficient algorithms for making optimal decisions about whattraffic lights to light when and for how long.

The former seems less common in recent decades, probably due to fast com-puters making complex real time algorithms for the latter approach morefeasible.

6

CHAPTER 2. BACKGROUND 2.1. TRAFFIC LIGHT CONTROL PROBLEM (TLCP)

Below some papers are listed to give an overview of previous works.

Dunne and Potts (1964) [2] provided a simple algorithm for controlling asingle intersection with two crossing lanes where turning is forbidden. Thealgorithm uses a cycle of two phases (one for each lane) and works by re-peatedly making the decision whether it is time to switch phase or not. Thedecision is made based on the time since the last phase switch and how manycars are waiting in each lane. The algorithm ensures that phase lengths isnot too short or to long based on a minimum and maximum phase lengths.The algorithm will attempt to switch phase early if the number of cars in thecurrently greenlit lane becomes 0 or otherwise small compared to the otherlane.

Serafini and Ukovich (1989) [3] modeled fixed cycles for a system of morethan one intersection. This is done by constructing graphs where nodes areevents and edges represent relations and constraints between these events.An event refers to the event of switching a traffic light from green to red orfrom red to green. For a given total cycle length, the problem is to find cyclesfor all intersections that fits the constraints. They formulate the problem asa mixed integer linear programming problem using their model and provethat it is NP-complete. A simple backtracking algorithm to solve to problemis provided.

Jansson (2010) [11] evaluates the use of GA to optimize a more compli-cated intersection in real time on FPGA hardware. The intersection includescar, tram and pedestrian traffic.

Dong, Huang and Liu (2011) [1] propose variations of GA and particleswarm optimization (PSO): Chaos GA, Chaos PSO, SA PSO, CatastrophePSO. The algorithms are used to find optimal cycles for a simple grid of 3by 3 intersections.

A. Stevanovic, J. Stevanovic, Kergaye, and Martin (2011) [10] study theuse of traffic signal priority. That is, dynamically giving priority to e.g.buses. This may include e.g. making traffic lights stay green longer if abus is nearby. The GA-based traffic optimization program VISGAOST totest different traffic signal priority parameterizations and their effect on op-timization results when simulating.

Cui, Shin, Miyazaki and Lee (2013) [4] use machine learning to optimizeintersections in real time. They use cellular automata to simulate trafficand bayesian networks to predict probability distributions of congestions.Particle swarm optimization (an algorithm similar to GA) is then used tofind the phases to use next.

7

CHAPTER 2. BACKGROUND 2.1. TRAFFIC LIGHT CONTROL PROBLEM (TLCP)

Chen, et al. (2013) [13] propose a lane-level dynamic traffic control(LDTC) system. It uses vehicular networks and traffic cameras to collectinformation about lane position and turning intentions. The goal is to max-imize the intersection throughput and still be fair to other lanes. Meaning,while setting green light for the lanes with highest traffic flow for through-put maximization, it also sets green light for lanes with lower traffic flow forfairness provision.

8

Chapter 3

Methods

This chapter presents a model of the problem. Details for the algorithms,implementations and measurements are also presented.

3.1 Optimization Methods

This section explains the two algorithms and their implementations.

3.1.1 Genetic Algorithms (GA)

Genetic Algorithms (GA) are a family of stochastic algorithms inspired byevolution and are often used for optimization [5], especially nonlinear. Thesealgorithms come in many variations, but in general operate as shown inalgorithm 1 below.

Algorithm 1: Genetic Algorithm

P = sample(S);while max(fitness(p, P) for p in P) < goal do

parents = select(P);offspring = {};for (a,b) in parents do

children = crossover(a,b);offspring = offspring + children;

end

C = {mutate(c) for c in offspring};P = merge(C, P);

end

Let the search space 𝑆 be the set of all solutions to the problem instance.A solution is also called a chromosome [5], and is a bit string of length 𝐿.The basics of GA is changing, sampling and evaluating these chromosomesto find optimal chromosomes.

9

CHAPTER 3. METHODS 3.1. OPTIMIZATION METHODS

The algorithm starts by creating a population of chromosomes, usuallyrandomly [5]. From this population pairs are selected [5, 6] and, through aprocess called crossover [5,6], used to create offspring (more chromosomes).Each offspring may be then be mutated [5, 6]. Finally the offspring is usedto create the next generation [5,6] of chromosomes. This process is repeateduntil the population is good enough, in some measure.

An evaluation-function, or fitness-function, is used to measures the good-ness of chromosomes. The goal of the algorithm is to find chromosomes that(sufficiently) maximizes the evaluation function [5,6]. The meaning of evalu-ation and fitness vary between works and authors. Sometimes they are usedinterchangeably, other times evaluation is independent of the current pop-ulation while fitness is dependent on the current population [5]. The latterdefinition is used in this work.

The rest of the section is dedicated to describing the different parts ofGA and their different variations.

Selection [5,6] is the process of sampling pairs randomly from the popu-lation. Chromosomes of higher fitness are more likely to be selected.

The probably most common method of selection is the so called roulettewheel sampling [5,6]. The population is sampled (with replacement) and theprobability of a chromosome being chosen is proportional to its fitness. Ifthe evaluation-function is 𝑓 , then the fitness of chromosome 𝑥 can be definedas 𝑓(𝑥)/𝑓 , where 𝑓 is the average evaluation of the population [5]. Thesampled population is then sampled again to produce pairs. Other selectionmethods based on the roulette wheel mainly differ in how the fitness-functionis defined.

Another method is rank selection [5, 6], where the chromosomes areranked (sorted) according to evaluation. Basing the fitness on the rank(instead of directly on the evaluation) can help prevent the algorithm con-verging too early (i.e. getting stuck in local optima) [6].

A third way is tournament selection [5, 6]. Iteratively, two chromosomesare selected and the fittest of the two is chosen. The resulting set is sampledto produce pairs.

Crossover [6] is the process of using the selected parent pairs (from theselection) to generate offspring. There are many ways of doing this, e.g.by splitting the parents in half and combining one half from each parent:(𝐴1𝐴2, 𝐵1𝐵2) to (𝐴1𝐵2, 𝐵1𝐴2).

Mutation [6] is applied to some randomly chosen offspring. This coulde.g. involve flipping a randomly chosen bit in the chromosome. Mutationcan be used to create more variation and help explore the search space.

The merge-step is optional (the offspring can be used as the next gener-ation without modifications) and can be useful for implementing elitism [6].

10

CHAPTER 3. METHODS 3.1. OPTIMIZATION METHODS

Elitism forces part of the population to be reused in the next generation.This is e.g. to ensure that the chromosome with highest evaluation is notlost. Also, to prevent the population size from growing over generationssome less fit chromosomes could be purged in this phase.

3.1.2 Simulated Annealing (SA)

Simulated Annealing (SA) is another stochastic algorithm for performingcombinatorial optimization search.

The algorithm is originally based on another algorithm by Metropoliset al. [14] that simulates the behavior of collections of atoms at differenttemperatures [8].

Algorithm 2: Simulated Annealing

𝑥0 := choice(S);best = 𝑥0;for 𝑡 in 1..𝑛 do

prev := 𝑥𝑡−1;𝑦 := choice(N(prev));if C(𝑦) < C(prev) or rnd() < exp(-(C(𝑦) - C(prev)) / T(𝑡)) then

𝑥𝑡 := 𝑦 ; // new solution is good enough

if C(y) < C(best) thenbest = 𝑦;

end

else

𝑥𝑡 := prev ; // reuse last solution

end

end

Let the search space 𝑆 be the set of all solutions to the problem instance.The algorithm (see algorithm 2 above) starts at time 𝑡 = 0, where an ini-

tial solution 𝑥0 is chosen (e.g. randomly) from 𝑆. Each subsequent solutions𝑥𝑡, 𝑡 > 0, are computed using the previous solution 𝑥𝑡−1.

A candidate solution 𝑦 is chosen randomly from the neighbors of theprevious solution (𝑦 ∈ 𝑁(𝑥𝑡−1)). The goodness of a solution is determinedby a cost-function 𝐶 (smaller is better). If the cost of the candidate is lowerthan the cost of the last solution it is immediately used as the next solution.The candidate may still be used as the next solution with probability [7–9]:

𝑝(𝑦, 𝑡) = exp

(︂−𝐶(𝑦)− 𝐶(𝑥𝑡−1)

𝑇 (𝑡)

)︂where 𝑇 (𝑡) is the temperature. 𝑇 should be a non-increasing function, i.e.starts high and cools over time. Note how the probability decreases as 𝑇decreases. That is, the probability of choosing bad candidates decreases over

11

CHAPTER 3. METHODS 3.1. OPTIMIZATION METHODS

time. This is the main-idea of simulated annealing: accept some bad so-lutions early in order to explore the solutions space, and get stricter whenapproaching the final solution. Because of this, SA can avoid getting stuckin local optimum. The probability also depend on the difference in cost –this represents the difference in energy between the two states. A smallerdifference in energy increases the probability of the candidate being recon-sidered [7–9].

3.1.3 Implementations

GA Implementation

GA was implemented in Java using the JGap library [15]. JGap was chosendue to its ease of use. It defines a chromosome to be a finite sequence ofgenes. A TLCP configuration is represented by an integer gene boundedto the range [0, 7], i.e. enumerating the 8 maximal configurations. Chro-mosomes are evaluated by the function 𝑓(𝑥) = 1 + 𝐸(𝑥), where 𝐸 is theevaluation function presented in section 3.2.3. The implementations usesJGap’s DefaultConfiguration-class. This includes a selector, a crossover-operator and a mutator.

The crossover-operator is applied first in each iteration. Two chromo-somes are selected at a time. Each chromosome is selected randomly (note:uniformly) with replacement from the population. The crossover is per-formed by dividing the chromosomes in two at a random point in the range[0, 𝑛), and then swapping the genes at and after that point: (𝐴1𝐴2, 𝐵1𝐵2) to(𝐴1𝐵2, 𝐵1𝐴2). The two new chromosomes are then added to the population.

This crossover-operation is repeated 0.35 ·population size times (roundedto nearest integer) per population. Each time a new pair is selected.

After the crossover-operator, the mutator is applied. The mutator de-cides for each gene in each chromosome whether a mutation should be appliedto that gene. The decision is made randomly, with probability 1

12 .A mutation is applied to a gene 𝑔 by adding a random number in the

range [−8, 8). If this causes 𝑔 to deviate from the interval [0, 7] it is set to arandom number in that interval.

Finally, the selector is applied. The selector retrieves the𝑏 = 0.90 · population size most fit chromosomes (rounded to nearest integer)from the population. The remaining population size− 𝑏 of the chromosomesare removed and replaced by cloning the most fit individuals (of the keptpart) of the population. This is essentially a form of elitism rank selection.

Since the selector is applied last, JGap’s genetic algorithm differs fromthe one presented in the background section (algorithm 1). Note also howthe above selector introduces clones to the population. Algorithm 1 assumesthat the population is a set of unique chromosomes, making selection beforecrossover necessary to make the fitter chromosomes more likely to be chosen.

12

CHAPTER 3. METHODS 3.2. MODEL

This, however, requires an intermediate population which may be expensiveto compute. Since clones are allowed in JGap’s algorithm, the selection mayas well be applied after the crossover and mutation.

SA Implementation

SA was implemented in java specifically for this work and did not use anyexternal libraries. It follows the algorithm as described in algorithm 2.

Like the GA implementation, configurations are represented by integersbounded to the range [0, 7]. Initial solutions are generated randomly. Thecost function is defined as 𝐶(𝑥) = 1 − 𝐸(𝑥), where 𝐸 is the evaluationfunction presented in section 3.2.3.

The temperature function is defined as:

𝑇 (𝑡) =

{︃𝑘𝑒−𝜆𝑡 if 𝑡 < 𝑡𝑚𝑎𝑥

0 otherwise

for some constants 𝑘, 𝜆 and 𝑡𝑚𝑎𝑥. (based on the definition used in [16]).Candidates are generated by randomly selecting integers 𝑖 ∈ [0, 𝑛) and

𝑞 ∈ [1, 7]. The solution is then modified by the rule:

𝑐𝑖 ← rem8(𝑐𝑖 + 𝑞)

where 𝑐𝑖 is the 𝑖:th configuration in the solution sequence, and rem8 is afunction returning the remainder for division by 8. To obtain a candidatethe above rule is repeated (for different 𝑖 and 𝑞), for a random number oftimes in the interval [1, 10].

3.2 Model

This section describes a model of the problem.

3.2.1 Data

A single 4-way intersection is modeled. Each arm has 2 intersection-facinglanes: one for left turning cars and one for cars continuing forward eitherto the right. See figure 3.1. Let a problem instance (or input) consist of aninteger 𝑛 and a set 𝑅 of cars, where 𝑛 is the number of discrete time stepsto schedule. Each car in 𝑅 is represented by five values: source arm, turningdirection, a non-negative distance from the intersection center along thatarm, a maximum velocity and a maximum acceleration. Distance 0 indicatesa position directly in front of a traffic light and each unit of distance is a carlength. How these values are used is further explained in section 3.2.2.

13

CHAPTER 3. METHODS 3.2. MODEL

Figure 3.1: Turning behaviour based on lanes. Rotate the image to see thecorresponding behaviour for the other four arms.

A problem solution (or output) is a mapping from each time step 𝑡,0 ≤ 𝑡 < 𝑛, to a configuration 𝑐 ∈ 𝐶. Alternatively: a sequence of length 𝑛consisting of configurations from the set of all configurations 𝐶. A configu-ration decides the color (red or green) of each traffic lights at a given time.An example configuration is illustrated in figure 3.2: green lights on the eastarm right-hand lane and red lights everywhere else. Note, however, that thisparticular configuration may be inefficient since only one lane is moving. Amore efficient configuration might be to also greenlight the west arm rightlane.

Figure 3.2: An example configuration. The green and red (also crossed)disks indicate traffic lights. The green arrows indicate the allowed routes asa result of the traffic lights.

14

CHAPTER 3. METHODS 3.2. MODEL

All possible combinations of red and green lights are not necessarily ap-propriate configurations. If, for example, the east arm right lane and thesouth arm right lane are both green at the same time, cars from these lanesmay collide in the northeastern part of the intersection. All possible colli-sions are shown in figure 3.3. As such, by prohibiting specific configurationssome hard constraints can be enforced, e.g. prohibit collisions.

Figure 3.3: The crosses illustrates the collision points.

Some configurations, like all lanes greenlit, could also cause the intersec-tion to lock up (cars wait on each other in a cycle). Such configurations canbe seen as inefficient and not considering them speeds up the search. It isalso possible to simply penalize the choice of configuration when collisionshappen. E.g. result in lower fitness in GA.

A reason for allowing all configuration is that this could be well suited forGA. A configuration could be represented by a bit string where bit 𝑖 wouldcorrespond to lane 𝑖 (for some enumeration) being greenlit when the bit isset and redlit when the bit is not set.

In this work, the former way of prohibiting some configurations has beenchosen due to being more realistic and also simplifying the implementation.

Figure 3.4: Some base maximal configurations. By rotating the images all 8maximal configurations can be produced.

15

CHAPTER 3. METHODS 3.2. MODEL

Let a configuration be maximal if no additional red light can be turnedinto a green light without risking collisions. A subset of all maximal config-uration are shown in figure 3.4. All maximal configurations can be producedby rotation of the images. All 8 maximal configurations are used in thesimulation described in the next section. Only enabling the maximal config-urations is thought to be most efficient while also disabling collisions.

3.2.2 Simulation

To evaluate a solution is to simulate the intersection with the sequence ofconfigurations in the solution. The simulation works per algorithm 3 below.Due to the choice of configurations in the previous section, collisions cannothappen. Therefore, each lane can be simulated independently. Furthermore,the simulation has been simplified such that cars closer to the intersectionare moved first. Each car need only consider the position of the precedingcar after the preceding car has been moved. This simplification may not beentirely accurate since cars move and accelerate at different speeds which insome cases may slow down traffic slightly.

The configurations in the solution is simulated in turn as time steps.Each time step consist of 15 ticks, which is the unit of time cars move. Thesimulation first tries to move as many cars as possible across the intersec-tion. How many cars that get across depend on their: distances from theintersection, velocities, maximum velocities, maximum accelerations, wherethey will turn, and the time available. The cars may turn at their maximalvelocity, which is an unrealistic simplification. Note that the distance acrossthe intersection vary depending on where the cars will turns. Compare e.g.the relative lengths of the arrows in figure 3.1.

When a car gets across it simply gets deleted and is not considered again.This is not entirely correct since the cars will limit the available space on thedestination lane and prevent more cars from getting across. This was deemedunnecessary and have been simplified, e.g. how long should the destinationlane be if it needs to be simulated? The cars that are left are then eachmoved as far as possible towards (but not across) the intersection. The carswill have to decelerate when approaching the intersection or the car in front.

Amber (or yellow) lights have not been mention so far and are not explicitin the simulation. In the simulation the decision whether a car should crossthe intersection or wait at the lights is determined by whether it would makeit across in time or not. In a real situation this decision is made by the driverand is generally based on: speed, whether and when the lights turn. Theidea in the simulation is that the lights are amberlit in time to signal the nextdriver that they can not make it across in time. The actual amberlighting istherefore transparent in the simulation.

16

CHAPTER 3. METHODS 3.2. MODEL

Algorithm 3: Simulation

for h in lanes doC = cars in h ordered by increasing distance;t = 0;while t < n do

start = t;while t < n and is_green(t, h) do

t = t + 1;end

green_time = t - start;while t < n and not is_green(t, h) do

t = t + 1;end

red_time = t - start - green_time;if green_time ̸= 0 then

/* move as many cars as possible across

intersection */

for c in C do

dt = ticks(green_time);if not can_cross(c, dt) then

break ; // not enough time

end

delete(c) ; // car finished

end

end

/* move cars towards (but not across) intersection */

for c in C do

end_position = 0;end_velocity = 0;c2 = car preceding c;if c2 exists then

end_position = dist(c2);end_velocity = velocity(c2);

end

dt = ticks(green_time + red_ time);move_toward(end_position, end_velocity, c, dt);

end

end

end

17

CHAPTER 3. METHODS 3.3. RUNNING TESTS

Cars move in intervals with constant accelerations following the equa-tions:

𝑎(𝑡) = 𝑐𝑎

𝑣(𝑡) = 𝑐𝑎𝑡+ 𝑐𝑣

𝑝(𝑡) =𝑐𝑎2𝑡2 + 𝑐𝑝

based on acceleration (𝑎), velocity (𝑣), position (𝑝) and time (𝑡).Constants 𝑐𝑎 (acceleration), 𝑐𝑣 (initial velocity) and 𝑐𝑝 (initial position)

differ for each interval.When a car attempts to move from a point 𝑝0 (current position) to a point

𝑝1 (e.g. in front of a red light or behind another car), it will first attempt toaccelerate to its maximum velocity, then keep that velocity for some distance,and then decelerate. Cars always use their maximum acceleration whenaccelerating, and the negative maximum acceleration when decelerating. Inreality cars would move in smoother motions but this has been simplified.

3.2.3 Evaluation

Let the function 𝐸 : 𝐶𝑛 → R determine the traffic flow of a solution. Alarger value is better.

𝐸 is defined as:

𝐸(𝑥) = 1− time steps until all cars across

𝑛(3.1)

This will produce a value between 0 and 1. The flow is essentially definedas the percentage of the planned time necessary to get all cars across theintersection. The faster the intersection is emptied, the greater flow.

3.3 Running Tests

To test the algorithms, twelve input files were generated. Each file containsthe number 𝑛 of configurations to plan, and a number of cars with differentparameters as described in section 3.2.

Each lane was randomly generated in twelve approximately equally sizedsegments. The input file with number 𝑖 (𝑖 ∈ 1 . . . 12) uses the first 𝑖 segmentsof each lane. For each file the number of configurations to plan was 𝑛 = 100𝑖and the number of cars was approximately 500𝑖. The cars are randomlyplaced in each segment and their number per segment vary slightly.

The algorithms are then run on the files. The idea is to try a few differentparameterizations of the algorithms (e.g. different population sizes for GAand 𝜆 for SA) and study the results. The parameters tried have been chosenthrough experimentation are shown in the next chapter (4).

18

CHAPTER 3. METHODS 3.3. RUNNING TESTS

Each time a algorithm is run on a file, the following is recorded: the mostoptimal traffic flow found, the running time, and the simulation count. Thefirst refers to greatest evaluation value 𝐸(𝑥) found, the second to the actualtime in seconds to run the algorithm on the file, and the last to the totalnumber of simulations performed.

The main focus is the most optimal traffic flow found since this is ofrelevance to the problem statement. For discussion, the running time andnumber of simulations performed, will also be presented as results.

Note that since traffic flow is a normalized value, the relative differencesare studied rather than absolute differences.

Since the algorithms are stochastic, each parameterized run on a file isrepeated 50 times. Averages of traffic flow, running time and simulationcount are the actual values studied.

19

Chapter 4

Results

Tests ran on a laptop PC with:

Archlinux, linux 3.17.6-1

AMD E-350 Processor @ 2.4 GHz

2 Cores

RAM 3.5 GB

Tables 4.1 4.2 shows different parameterizations of SA and GA, respec-tively, that have been tried. The id of a parameterization will be used torefer to it.

id 𝑘 𝑡𝑚𝑎𝑥 𝜆 simulation count

SA1 4𝑛2/1000 200000/𝑛 0.01 200000/𝑛

SA2 6000 6000 0.02 2279

SA3 5𝑛 5𝑛 0.01 5𝑛

Table 4.1: SA parameterizations

id population size generation count simulation count

GA1 500 5 4750

GA2 190 15 5020

GA3 20 100 3420

Table 4.2: GA parameterizations

20

CHAPTER 4. RESULTS

Figures 4.1 and 4.2 shows the average traffic flows 𝐸(𝑥) for SA and GAparameterizations, respectively.

Figure 4.1: The average evaluation values for the different parameterizationsof SA.

Figure 4.2: The average evaluation values for the different parameterizationsof GA.

21

CHAPTER 4. RESULTS

Figures 4.3 and 4.4 shows the corresponding average running times.

Figure 4.3: The running times for the different parameterizations of SA.

Figure 4.4: The average running times for the different parameterizations ofGA.

22

CHAPTER 4. RESULTS

Figures 4.5 and 4.6 shows a comparison between SA2 and GA3 in trafficflow and running time, respectively. These parameterizations where cho-sen because they were considered to be be best of the ones tried, for eachalgorithm respectively.

Figure 4.5: The average evaluation values for the considered best parame-terizations for SA and GA.

Figure 4.6: The average running time for the considered best parameteriza-tions for SA and GA.

23

Chapter 5

Discussion

In this chapter the method and results are discussed and criticized.

It should be noted that the running time taken by the algorithms con-sists mainly of running simulations. Hence, any differences in running timebetween algorithms and parameterizations are mainly caused by how manysimulations are run. This is one of the reason why mainly traffic flow ismeasured, rather then execution time.

5.1 The Comparison

Figures 4.5 and 4.6 suggest that SA scales better than GA, both in trafficflow and running time, at least for the parameterizations used. GA evaluatesmore solutions and therefore takes more time. Still GA generally does notfind better solutions.

However, the margin between GA and SA seems to get smaller as the filesize increases. This is partially because of the way the evaluation functionis defined, i.e. variations look smaller due to being normalized. Anotherreason is likely because the search space increases considerably in size. Thismeans that in general more space has to be searched in order to find goodsolutions. Since the parameterizations SA2 and GA3 do not change withfile size, they do not try more solutions as file size increases although theincrease in search space size would require them to do so in order to findgood solutions. As such, both should get lower traffic flow as file size in-creases. From experiments SA has been shown to be very sensitive to itsparameterization (see e.g. figure 4.1) and because of this it is possible thatSA degrades faster than GA when file size increases and therefore decreasingthe margin between them. This would suggest SA scales worse than GA, orat least that SA requires finer tuning than GA to scale well.

The hypothesize was that SA be more suited to smaller search spacesand GA more suited to larger search space, when both algorithms run forthe same amount of time. The tests seem to agree SA2 finds better solutions

24

CHAPTER 5. DISCUSSION 5.2. CRITICISM OF SIMULATION

in shorter time than GA3 on smaller files (see figures 4.5 and 4.6). However,though the margin decreases as file size increases GA does not necessarilyseem to be passing SA. Rather, both algorithms seem less likely to findgood solutions when file size increases. This may be because neither SA2or GA3 scales their parameters by file size. This suggest that GA and SAdo not get enough iterations to converge. But, if GA were to run for moregenerations, it would become slower or population size would have to bedecreased, which may further impact the result, which would suggest thatSA scale better. Figures 4.2 and 4.4, however, suggest that population sizecan be dramatically decreased in favor of more generations and still findbetter better solutions. It would seem that GA and SA are comparable onlarger search spaces, when considering the parameterizations tried.

For SA2, GA1, GA2 and GA3 the same parameters were used for all filesizes. As mentioned above, all parameterizations of both algorithms seemless likely to find good solutions when file size increases. It may therefore bebetter to scale the parameters by file size, as in SA1 and SA3.

SA1 tries fewer solutions as file size increases. This makes the runningtime about the same for all file sizes, as shown in figure 4.3. As is to beexpected, this results in lower traffic flow in solutions when file size increases,as shown in figure 4.1. Besides being lower the traffic flow also varies morefor SA1, showing SA1 does not getting enough time to properly converge.

SA3 does the opposite, i.e. searches more solutions as file size increases.Note that that SA2 uses a parameterization corresponding to SA3 runningon file 12 (i.e. with 𝑛 = 1200), with a small change to 𝜆. Figure 4.1 showsthat SA2 generally find better solutions than SA3 on the first few files, butslightly worse on the last few files. The switch likely occurs on the file whereboth parameterizations try the same amount of solutions.

Another way of going about the tests could be to optimize the parametersper file, i.e. try many different parameters for the file, and use the best resultwhen comparing. This may, however, be unrealistic if the algorithms were torun in real time on a real problem. The time necessary to find the parametersmay not be available in such a situation.

5.2 Criticism of Simulation

As noted in chapter 3, the simulation is not entirely realistic and may there-fore not accurately reflect a real situation. However, it is believed that itcould still be used to approximate small intersections, where not enough carspass to show the inadequacies of the simulation.

As shown, the found traffic flows vary between files. This suggests thattraffic is very dynamic and that the simulation portraits this in the searchspace. Likely the search space vary considerably between files. It can also beargued that it is caused by unknown bugs and instabilities in the simulation.

25

CHAPTER 5. DISCUSSION 5.3. POSSIBLE PRACTICAL APPLICATIONS

On the subject of evaluation it can be argued that the definition andmeasurement used for traffic flow is too simplistic. The evaluation functionshould have been better grounded in theory. Originally multiple measureswere considered when the evaluation function was being defined, but due tomost of them being too closely related they were dismissed.

Furthermore, all time steps had the same size in ticks. A more realisticintersection should make use of configurations of varied-size time steps. Forexample, a solution could be redefined as a sequence of configuration-and-size pairs instead of a sequence of only configurations. It should also be notedthat the evaluation used was defined in terms of time steps used. By usingtime steps of varying size and defining evaluation in terms of ticks instead oftime steps, a larger variety (and likely more optimal) evaluations could havebeen produced.

Combined with varying-sized time steps, it should also be considered toallow non-maximal configurations. Non-maximal configurations were origi-nally not used, due to enlarging the search space to no clear benefit. Withvaried-size time steps, however, it might sometimes be optimal to let lanesgather some amount of cars before greenlighting them. All maximal config-urations greenlight exactly two lanes, meaning that to greenlight some laneanother must also be greenlit and this may prevent cars from gathering there.That is, allowing only maximal configurations could hamper the potential ofvaried-sized time steps.

5.3 Possible Practical Applications

A possible practical application of the method would be to plan intersectionsahead of time in small intervals. If it is possible to accurately predict whencars will arrive at the intersection, it would be possible to plan ahead, e.g.20 minutes at a time. This is, of course, heavily dependent on the predictionmechanism.

Some previous work (such as [2]) present systems and algorithms thatmake decisions based on the number of incoming cars, but does not considerthe spacing between those cars. With the speed of todays computers it isprobably possible to make decisions based on the exact cars that are approachthe (spacing, types of cars, etc.), not the just number of cars. This is similarto the approach other precious work (such as [4]).

It should be noted that computations were single-threaded and did notmake use of parallelization. In a real situation it may be necessary to do so,to make the solutions fast enough. The algorithms may, however, make useof the parallelization in different ways and one way may be more appropriate.This could be subject of future work.

26

Chapter 6

Conclusion

It is difficult to draw any hard conclusion without using statistics and thedifference is heavily dependent on parameterization and there likely existsbetter parameterizations for both SA and GA.

We would however like to conclude that: SA generally finds better solu-tions than GA in small search spaces and that SA and GA are comparableon larger search spaces.

27

Chapter 7

Bibliography

[1] Chaojun Dong, Shiqing Huang, and Xiankun Liu. Comparative studyof several intelligent optimization algorithms for traffic control appli-cations. In Electronics, Communications and Control (ICECC), 2011International Conference on, pages 4219–4223, Sept 2011.

[2] Michael C. Dunne and Renfrey B. Potts. Algorithm for traffic control.Operations Research, 12(6):870–881, 1964.

[3] Paolo Serafini and Walter Ukovich. A mathematical model for the fixed-time traffic control problem. European Journal of Operational Research,42(2):152 – 165, 1989.

[4] Cheng-You Cui, Ji-Sun Shin, Michio Miyazaki, and Hee-Hyol Lee. Real-time traffic signal control for optimization of traffic jam probability.Electronics and Communications in Japan, 96(1):1–13, 2013.

[5] Darrell Whitley. A genetic algorithm tutorial. Statistics and Computing,4(2):65–85, 1994.

[6] Mitchell Melanie. An introduction to genetic algorithms, volume 3. Cam-bridge, Massachusetts London, England, Fifth printing, 1999.

[7] Dimitris Bertsimas and John Tsitsiklis. Simulated annealing. Statist.Sci., 8(1):10–15, 02 1993.

[8] S. Kirkpatrick, C. D. Gelatt, and M. P. Vecchi. Optimization by simu-lated annealing. Science, 220(4598):pp. 671–680, 1983.

[9] LPPP Van Ginneken and RHJM Otten. An inner loop criterion forsimulated annealing. Physics letters A, 130(8):429–435, 1988.

[10] A. Stevanovic, J. Stevanovic, C. Kergaye, and P. Martin. Traffic con-trol optimization for multi-modal operations in a large-scale urban net-work. In Integrated and Sustainable Transportation System (FISTS),2011 IEEE Forum on, pages 146–151, June 2011.

28

CHAPTER 7. BIBLIOGRAPHY

[11] Gustaf Jansson. Traffic control with standard genetic algorithm - asimulated optimization control of a traffic intersection. Thesis work inIntelligent Systems Design, (2010:127), 2010.

[12] Weizhen Gu and Xingde Jia. On a traffic control problem. In Paral-lel Architectures,Algorithms and Networks, 2005. ISPAN 2005. Proceed-ings. 8th International Symposium on, pages 6 pp.–, Dec 2005.

[13] Lien-Wu Chen, Chia-Chen Chang, P. Sharma, Jen-Hsiang Cheng,Chien-Cheng Wu, and Yu-Chee Tseng. A lane-level dynamic trafficcontrol system for driving efficiency optimization based on vehicularnetworks. In Pervasive Computing and Communications Workshops(PERCOM Workshops), 2013 IEEE International Conference on, pages297–299, March 2013.

[14] Nicholas Metropolis, Arianna W Rosenbluth, Marshall N Rosenbluth,Augusta H Teller, and Edward Teller. Equation of state calculations byfast computing machines. The journal of chemical physics, 21(6):1087–1092, 1953.

[15] JGAP Team. Jgap, April 2015. http://jgap.sourceforge.net.

[16] AIMA Team. Aima 3e java, April 2015. https://github.com/

aima-java/aima-java.

29

www.kth.se