Intelligent Traffic Light Management - DTU Electronic Theses and

Intelligent Traffic LightManagement

Arterial Simulation & Optimization

Andreas Warberg, 030447

June 30, 2008

Supervisors:Rene Munk Jørgensen, DTU Transport &

Jesper Larsen, DTU Management

Technical University of Denmark

Abstract

The signal controllers of heavy-traffic arteries are subject to optimization to bestaccomodate the movement of the large traffic volumes. The DOGS system for arte-rial optimization works by adjusting the common cycle time according to detectedtraffic conditions and was tested in the Vissim microsimulator for a section of theDanish ringroad 3. Tests show that DOGS, while providing improved conditionsfor arterial traffic in most cases, can be further improved by selecting an offset foreach DOGS level, rather than remaining at the same offset regardless of the cur-rently selected cycle time. For finding such offsets for the comparison a simulatedannealing algorithm was implemented to solve the problem of coordinating signalcontrollers.

Keywords: traffic signal settings, traffic optimization, traffic artery

1

Contents

1 Introduction 1

1.1 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Software versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Signal Control Systems 5

2.1 Traditional signal control . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Adaptive signal control . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 The DOGS System for Arterial Optimization 8

3.1 Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Prediction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5 DOGS and offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Simulation & Vissim 15

5 Vehicle Actuated Programming in Vissim 19

5.1 Interstage definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 DOGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.1 Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.2 Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Bus priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Traffic Analysis 27

6.1 Detector data analysis . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 Traffic count analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7 Vissim Network Modelling 35

7.1 Modifications and additions to existing model . . . . . . . . . . . . 35

7.2 Link inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.3 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.4 Right-of-way . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.5 Signal plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.6 Signal controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

i

8 Optimization System 46

8.1 Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.2 Manipulating speed . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.3 Adjusting offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.4 Direction bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.5 Closely distanced intersections . . . . . . . . . . . . . . . . . . . . 51

8.6 Metaheuristic search . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.7 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.7.1 Delta-evaluation . . . . . . . . . . . . . . . . . . . . . . . . 56

8.7.2 Neighbor solutions . . . . . . . . . . . . . . . . . . . . . . . 56

8.7.3 Bookkeeping outline . . . . . . . . . . . . . . . . . . . . . . 58

8.7.4 Parameter tuning . . . . . . . . . . . . . . . . . . . . . . . . 58

9 Results 64

9.1 Test scenarios and setup . . . . . . . . . . . . . . . . . . . . . . . . 64

9.2 DOGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9.3 Cycle times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9.4 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9.5 Bus priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

10 Conclusion 75

10.1 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

10.2 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A Signal Plans 81

B VAP Codes 82

B.1 Example: DOGS master . . . . . . . . . . . . . . . . . . . . . . . . 82

B.2 Example: DOGS slave . . . . . . . . . . . . . . . . . . . . . . . . . 85

B.3 Example: bus priority . . . . . . . . . . . . . . . . . . . . . . . . . 87

C Source Code 88

C.1 Utilities and data management . . . . . . . . . . . . . . . . . . . . 88

C.2 Vissim codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

C.3 Optimizer codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

ii

1 Introduction

Road traffic has become an essential part of modern society and is putting anincreasing demand on road networks. Traffic network congestion causes delayswhich add substantial costs to society and businesses on a daily basis and alsoincrease emissions and the risk of accidents.

To alleviate congestion, public transport can be improved or the infrastructurecan be expanded. In urban areas, the latter is often impossible due to residentialareas adjacent to the existing roads. A more subtle way to improve the networkperformance is to make better use of the existing roads, which can be achieved inpart by proper setting of traffic signal parameters.

It is estimated that the proper use of intelligent traffic systems including intelli-gent traffic signals, could increase the capacity of the road network in the GreaterCopenhagen area by 5 to 10% and in the report [14] simulations reveal that op-timized coordinations for a circular artery in Copenhagen can reduce delays andstops in the morning rush hour by more than 25%, compared to current settings.

The ringroads sorrounding the city of Copenhagen are part of the collection ofarteries in Denmark and serve to route traffic around the city to offload the urbanroad networks and provide an alternative to going through the city. As such thesignal controller settings are frequently adjusted in an offline process (see eg. anoptimization using TRANSYT1 [13]) to best serve the demand from road users.Offline signal settings are made for some prespecified time interval eg. ”morning”or ”afternoon” and cannot compensate for the dynamic aspects of traffic, unlikeadaptive signal control systems.

The DOGS system by Technical Traffic Solution (TTS) is a system for intel-ligent traffic light management on an artery. DOGS was chosen by the countyof Copenhagen to adjust the capacity of ringroad 3 due to the rebuilding of thenearby motorring 3, which was expected to cause increased traffic.

DOGS increases capacity by simultaneously increasing cycle times in all signalcontrollers, when certain traffic conditions arise. These criteria are determinedstatically so as to alleviate the most heavily loaded intersection in the DOGSarea.

The purpose of this study is to simulate DOGS to discover the true effects ofthe system. In previous analyses by the Danish Road Directorate (DRD) certainanalytical observations have been made, which indicate that DOGS is capable ofdisrupting coordination on ringroad 3.

The simulation tool is chosen to be Vissim, which is the de-facto microsimulationtool in Denmark. Ringroad 3 consist of two DOGS areas, which are separated bythree intersections, and due to the combined size of the network a code libraryis developed for Vissim to perform tasks such as inserting link inputs and routechoices from traffic counts and running tests with data extraction.

1See section 4 for more details on simulation tools.

1

To test the issue of disrupted coordination during DOGS operation an offsetoptimization tool was developed to provide precalculated offsets for each signalcontroller for each cycle time. This tool also integrates closely with Vissim toextract information such as distances and signal controller plans.

The report is structured as follows. After introducing traffic signal optimizationsystems in section 2 I describe how DOGS work and what the intentions behindDOGS are in section 3. Section 4 introduces the Vissim microsimulator and Idescribe how Vissim structures its data and how I can take advantage of the plaintext property of the Vissim network file to automatically insert traffic data for linkinputs and route choice. In section 5 I describe the Vehicle Actuated Programminglanguage (VAP) of Vissim and how I use it to emulate DOGS in a master-slavescheme. For the purpose of adjusting the simulation I received detailed traffic datafrom both the DRD (traffic counts and signal layouts) and from TTS detectordata. These data are analysed in section 6 where I show the arterial nature ofringroad 3 and other properties such as direction bias. The Vissim network I usein this project was started by COWI2 and later inherited and improved by manystudents at the Technical University of Denmark. In the next section 7 I discusshow I expanded and modified the network using automatic procedures, whichwork directly on the data structures described in section 4. Section 8 is where Idiscuss optimization of coordination and how I designed my own system basedon simulated annealing. The last section 9 compares the performance of originalDOGS and DOGS with offsets from the optimizer to the basic program. Finallyin section 10 I bring my conclusions and suggestions for future works based on theresults of section 9.

1.1 Terms

When I first started studying the literature on traffic signal optimization [16] itbecame evident that there was a great deal of terminology specific to the field oftraffic signal settings and that most articles assumed the author to be familiarwith it.

It is my impression that the terms of traffic signal optimization are fairly stan-dardized and most articles will share terminology.

This section attempts to extract the most important terms and give solid de-scriptions, so that the field can be adopted by newcomers more quickly.

Artery A main-path, the major road, through a traffic network. It will generallyface higher demand than minor roads adjoining the artery.

Coordination Especially relevant to arteries, the quality of coordination betweensignal controllers determines how road users perceive a journey through anartery. With good coordination, the platoons of vehicles will experience agreen light whenever they approach the next intersection, this is also knownas the green wave.

2A Danish consulting firm in engineering, environmental science and economics.

2

Cycle time The turnaround time for all phases of a traffic signal to complete ie.the time it takes from the start of green time for a phase until it becomesgreen again. A common cycle time is especially relevant for the signal con-trollers in an artery in combination with proper offsets to establish goodcoordination.

Green Wave Road users experience green waves when they receive green everytime they reach the next intersection. A progression band is a graph intime and distance describing the progression of a platoon of vehicles. Incombination with the states of the signal controllers progression bands formroad-time diagrams that give an impression of the quality of such greenwaves.

Interphase green Also known as lost time, is a small amount of time insertedas a buffer between two phases. During the lost time the lights can be eitherred in all directions or, as in Denmark, amber lights can be used to introducea buffer. The purpose of the buffer is to allow vehicles, which entered duringthe last phase, to exit the intersection before it is flooded by vehicles fromthe next phase.

MOE An abbreviation for Measure Of Effectiveness and also referred to as theperformance index (PI) or fitness. MOE is some metric on which the perfor-mance of a traffic signal network is assessed . Most often used is the averagedelay, also common is the travel time through the network and number ofstops or some combination.

Offset Only relevant under cycle-time-based programs, the offset is the delay withwhich to start the execution of the signal program, relative to the mastercontroller. Offsets are chosen for each signal controller in a way such thatgood coordination is acheived. The cycle time must be common to all signalcontrollers otherwise the offset only provide the expected coordination in thefirst cycle and periodically in the later cycles.

Phase Sometimes referred to as stage, corresponds to a particular combination ofthe red and green lights of the signal heads in an intersection. For instancethere may be a phase of green in the north and south direction for a two-wayintersection (which implies red lights are shown in the east-west direction).

Platoon A group of vehicles travelling together. A platoon can be detected byobserving the time between a vehicle and the next and applying a thresholdin time units known as the critical headway. Platoons are formed both as aconsequence of car-following behaviour, which is used in simulation frame-works such as [15] and Vissim, but also due to the batch-like nature whichis imposed on the traffic by traffic signals. Platoons are dispersed ie. split upover time into multiple platoons due to the individual behaviourial elements(eg. desired speeds) of road users.

3

Queue spillback This phenomenon occurs when a queue reaches from a down-stream intersection to the preceding intersection, effectively preventing traf-fic from leaving the upstream intersection.

Signal Controller A means for controlling the right-of-way of conflicting trafficmotions in an intersection between two or more roads. Right-of-way is pe-riodically shifted between incompatible traffic flows by choosing one signalgroup after another.

Signal Group A collection of signal heads, which show identical colors at alltimes.

Signal Head A traffic light, which constitute a signal group itself or, more com-monly, is a part of a signal group.

Signal Program A description of the states of the signal groups in the course ofa cycle. The signal program is repeated after each cycle completion.

Time horizon The amount of time, which is taken into consideration while opti-mizing signal settings or making predictions. Since predictions of the futuretraffic becomes more and more fuzzy the deeper one looks a paradox arises:using a short time horizon the optimizations might prove to be flawed whenit fails to see a clever decision, but with longer time horizons the predictionsthemselves become flawed and may mislead the optimization.

Traffic assignment Also known as flow assignment, is the determination of ve-hicular flow along origin-destination (OD) paths and, consequently, alonglinks in a traffic network. Traffic assignment is in contrast to static assign-ment, when link inputs and routes are fixed before the simulation starts.

Traffic network A graph G(V,E) where V is a set of intersections controlledby a traffic signal and E is the set of roads connecting the intersections.A path is thus a route through the network crossing a least one signalizedintersection.

1.2 Software versions

The Vissim network was developed first under Vissim 4.00-16 and later in thenewly released Vissim 5.00 using the latest service packs as they were released.All tests were performed in Vissim version 5.00-08, however.

Libraries for Vissim manipulation, support and optimization were written inRuby, targeting version 1.8.6.

4

2 Signal Control Systems

The systems that mandate road use by signal controllers can roughly be dividedinto two major types: adaptive and non-adaptive. Within each type the systemsare specialized with respect to the number of signal controllers the system governsand the network layout, when more than one intersection is under signal control.

The general traffic light management system manage the settings of signal con-trollers in a grid of connected roads and the optimization problem must respectall traffic flows between each input and output. A special case is the artery wherea single one-way or bidirectional traffic flow dominates the total demand of thenetwork.

This section introduces briefly the major trends in these two systems to outlinethe setting in which DOGS is used.

2.1 Traditional signal control

The traditional systems, which are also the simplest, operate on the basis of signalplans, such as the ones seen in appendix A. For isolated intersections, there is achoice between pretimed and traffic actuated control strategies. Pretimed controlinvolves the use of static signal plans for phase sequences, cycle time and greentimes according to the time of day. Traffic actuated signals are usually flexibleversions of the static signal plans, allowing the green time of stages to be extended,up to some maximum when vehicles are detected.

When more than one signal controller is under system control the signal plansare based on a common cycle time and the signal controllers are adjusted relativeto each other by choosing an offset, for each signal controller, which providesgood coordination. Traffic actuated signals cannot cooperate with other signalcontrollers in an artery since they operate on a variable cycle time depending onthe amount of time each stage was extended.

Pretimed control is based on the assumption that demand is fairly stable withincertain divisions of time eg. morning, midday and evening or workday / weekend.For instance, in the morning (7.00 to 9.00) and afternoon (15.00 to 17.00) thetraffic is usually heavier than during the day or night due to commuter traffic.

Tools such as TRANSYT are used to generate static signal plans and offsetsgiven historical traffic data.

2.2 Adaptive signal control

Adaptive signal control strategies may be based on historical data as well, butdiffer from schemes using static signal plans by actively monitoring current trafficconditions and make adjustments accordingly.

The dynamic aspects of traffic become obvious when considering the things thataffect it:

5

• Events: football games, lane closures due to VIP transport etc. will cause afocusing of traffic in certain areas

• Weather: warm weather will cause more traffic going out of the city whilewinter and snow causes reduced speeds but potentially also fewer vehicleson the road

• Accidents: traffic is diverted onto alternative routes

It is near impossible to take into account such phenomenon when designingpretimed signal plans. In fact traffic engineers will attempt to capture the least”eventful” (neutral) dataset possible when designing such plans to accomodatethe most common traffic situation.

Adaptive signal control systems adjust signal controllers in an arterial or net-work to coordinate intersections so as to optimize some performance index eg.average delay or number of stops (or a combination) but also to reduce the needfor constant supervision and tuning of signal timing plans, which is necessary forpretimed control. That said, an adaptive system will also need supervision, butat least they are designed to be able to make adjustments autonomously, such asredistributing green time from one direction to another, when traffic changes.

To achieve optimum combined performance, adaptive systems dynamically ad-just parameters such as cycle times, phase sequences and green times according todetected as well as predicted traffic thereby reacting to those dynamic aspects oftraffic, which cannot be captured by the pretimed signal plans. Systems like thephase-by-phase system in the article [9], RHODES [10], OPAC [11] and SCOOT[3] even skip or work around the conventional periodic scheme based on a commoncycle time and make direct assignments of phases and allow phases to be skipped,as discussed later in section 8.1.

The key to adaptive signals is reliable detection and short term prediction oftraffic. Most of the adaptive systems I analysized in [16] use historical input andcurrent detector input to make short term predictions for what is going to happeneg. within the next minute, next 10 minutes and so forth.

While an isolated signal controller operated in a traffic actuated scheme canbe thought of as a primitive type of adaptive signal, the main attraction withadaptive signals is when they can be set to work together. A good system willnaturally cause green waves to appear and move the direction of the green wavesalong with changes in flow.

It is evident that the cycle time is crucial in optimization because, in case ofa congested network, increasing the cycle time will cause increased capacity and- hopefully - increased throughput as well. Long cycle times lead to long phasedurations, which allow a steady flow of vehicles to pass and minimizes lost andinterphase time per time unit, but will also allow queues to grow larger until theycan be emptied by the start of a green stage for the approach of the queue. Thusincreasing the cycle time increases the capacity of the intersection. The exceptionis for left-turning traffic, which does not have a priority stage, here long cycle

6

times will actually decrease capacity since only as many vehicles as will fit in theintersection may turn per cycle.

7

3 The DOGS System for Arterial Optimization

DOGS is a hybrid somewhere between adaptive and traditional pretimed systemsfor arterial signal control, making adjustments to cycle time and splitting the extragreen time in favor of the arterial traffic. DOGS has no prediction capabilities, butrelies on detector values, and is thus lacking a key component of other adaptivesystems.

This, however, gives DOGS a clear advantage in implementation since no heavycalculations of prediction are needed and the only decision to make is whether toremain at the current level (ie. common cycle time) or to change the level by oneie. increasing or decreasing the common cycle time. This decision does not requiremuch computational effort and this, along with the immediate adoption of thepreexisting signal timing plans, makes DOGS a simple and easily implemented -and understood - arterial optimization system.

DOGS has been implemented on several arteries in Denmark and relies on sitespecific knowledge for definition of criteria parameters, which must be gatheredin a manual process and reevaluated over time and thus does not liberate thesystem owners from continuous supervision and periodic parameter tuning. DOGSis different from other adaptive systems by the fact that it only operates undermedium to heavy traffic loads under which the problem of choosing signal settingsreduce to the proper setting of capacity on the major road and coordination byoffsets.

DOGS is an extension of the DOG system, which was developed for the im-portant intersection of Herlev Hovedgade and ringroad 3. The first 3 letters canbe directly translated from Danish to dynamic optimization of greens and the ap-pended S of the herein regarded system means coordination. Thus DOG is a trafficactuated optimizer for single intersections and DOGS add coordination betweenintersections.

DOGS is a criteria-based system which relies on a common cycle time for coor-dination. The intended area of application is traffic signals along arterials, whichsee a high fluctuation in demand.

Two of the sites where DOGS currently operate are the Glostrup and Herlevsites along the important ringroad 3. They see high increases in demand in themorning and afternoons with commuters. Traditionally such fluctuations has beenhandled well by a small number of timing plans, which are chosen among accordingto the time of day, but the area also see more unpredictable types of fluctuationswhen accidents occur on the nearby highway, M3, or when M3 lanes are closed dueto the current expansion program. For these reasons DRD decided to implementa system which could handle such situations.

The purpose of DOGS is to increase the capacity of the artery in the abovementioned cases and revert to offline-optimized, pretimed plans in low traffic sit-uations. The capacity increase comes by increasing the common cycle time andallocate the extra green time per cycle to the stages, which serve the artery. Thiswill cause decreased performance for the minor roads, but may prevent queues

8

from reaching the previous intersection - or even prevent queues in cases of lightcongestion - on ringroad 3. DOGS is also capable of providing priority to busesby extending the green time when buses are near an intersection. This feature iscurrently only used in Glostrup.

As mentioned the system must be tailored to the environment in which it oper-ates. For this reason the following sections will use the Herlev area as a referencearea in order to explain certain concepts. In Figure 1 is a layout of this network.

Figure 1: Layout of the partial ringroad 3 artery in Herlev, which is under DOGScontrol. The arrows and numbers indicate flow direction and examples of vehicleloads.

3.1 Detection

Detector loops are placed in the immediate downstream of intersections and con-nected to closest controller to reduce the wire length.

The criteria, which DOGS use, are based on the total inflow per cycle as well asoccupancy rates, which, in Herlev, is extracted from strategically placed detectorsin the ends of the arterial. In Figure 1 we see the detectors available in Herlevwhere these measurements are done.

In addition to vehicles per cycle and load degrees the detectors are capable ofmeasuring vehicle speeds, though this is not taken into consideration in any ofthe criteria. In the case of prediction such capabilities could be taken advantageoff eg. by fitting the predicted speeds to observations. Individual vehicle speedsmeasured at detectors are usually not taken into consideration when performingprediction since they represent the speed at a single point rather than some averagespeed. It is possible that the average speeds measured at detectors can be usedto estimate the level of congestion of the network as an alternative to travel timemeasurements by video.

3.2 Prediction

As mentioned DOGS is a purely traffic actuated system and no prediction is usedwhen the system is activated due to heavy traffic conditions.

In spite of the intended flexibility of the system this is a point which puts highdemand on the implementing traffic engineers since traffic through the arterial

9

must be assessed manually when the system is put into production as well asduring maintenance.

An alleviating point to the lack of prediction is the fact that the current arterialsunder DOGS control are relatively small and static predictions can be made by anexperienced traffic engineer. Furthermore, since DOGS only operate under highload conditions, predictions become less valuable - or superfluous, even - becauseall that can be said about the artery in this case is that it is heavily loaded withtraffic.

3.3 Optimization

Since DOGS only kicks in under congested or near-congested conditions (for theHerlev area when the load exceeds 60% of the capacity) it is simple to optimizethe throughput since any increase in green time will just allow more vehicles topass.

That DOGS only operate during high-congestion levels is an unusual trait for anadaptive system since they usually excel in optimization under normal ie. uncon-gested load conditions when the signal controllers can be adjusted to cater for thescarce vehicle platoons. DOGS will not be able to make good decisions on signalsettings for low-to-medium traffic volumes due to the lack of an explicitly definedobjective function and optimization routine. This explains why DOGS remain atthe pretimed signal programs during most of a normal day and adjustments areonly made for high loads.

The objective is to keep the load degree (load/capacity) for the most heavilyloaded intersection below 90%. To do this the common cycle time and green timesare set according to the load level. The adjustments are made with a few secondsper cycle to avoid sudden, major changes in cycle time.

Coordination is achieved in one direction by running the signals on a commoncycle time, but offsets are not adjusted when the common cycle time changes, al-tering coordination in the other direction. This issue receives further investigationin section 3.5.

Naming the inflow detectors in the north- and south ends DN and DS, respec-tively, the transition from pretimed control to adaptive control is decided by theconstraint:

Intensity(DN) > Ienable ∨ Intensity(DS) > Ienable

or

Occupancy(DN) > Oenable ∨ Occupancy(DS) > Oenable

It is important to measure occupancy rates (how much of the measuring periodthe detector was activated by vehicles) in addition to intensity levels (number ofvehicles) since the intensity levels will drop to zero due to queues, while occupancyrates go to 100% due to the same the queue.

10

For switching back to pretimed control this constraint must hold:

Intensity(DN) < Idisable ∧ Intensity(DS) < Idisable

and

Occupancy(DN) < Odisable ∧ Occupancy(DS) < Odisable

To avoid hysteresis ie. constant enabling and disabling of dynamic control:

Ienable − Idisable ≥ Iε (1)Oenable −Odisable ≥ Oε (2)

Iε, Oε > 0 (3)

DOGS exhibits a dynamic behaviour because the permitted cycle time exten-sions are divided into programs according to the intensity and occupancy levels inthe ends of the artery. These programs include constraints that take a form whichis similar to the enable- and disable constraints.

When deciding whether to remain in the current program, i− 1, or switch to aprogram for higher demand, i, the following relation must be satisfied:

Ienable,i+1 ≥ max(Intensity(DN), Intensity(DS)) > Ienable,i

∨Oenable,i+1 ≥ max(Occupancy(DN), Occupancy(DS)) > Oenable,i

The decision of switching from program i to the program for lower demand,i− 1, is determined by this relation:

Idisable,i−1 ≤ max(Intensity(DN), Intensity(DS)) < Idisable,i

∧Odisable,i−1 ≤ max(Occupancy(DN), Occupancy(DS)) < Odisable,i

DOGS level changes are implemented over 2 cycles during which the level cannotchange again. The current cycle time is increased or decreased by 5 seconds untilthe new level is implemented. All signal controllers thus increase or decrease thegreen time in the main direction by 4 seconds and minor direction by 1 second intwo consecutive stages until the new level is enabled.

In the DOGS controlled area in Herlev there are 8 different programs to choosefrom - although only a limited number of programs are allowed under normaloperation - and the enable and disable thresholds for programs respect the orderingimplicit in the above equations:

{I, O}enable,i+1 > {I, O}enable,i

{I, O}disable,i−1 < {I, O}disable,i

To avoid hysteresis between programs the same constraints (equations 1-3) asfor switching between pretimed and dynamic control applies.

11

3.4 Evaluation

Tests by DRD [8] have shown that the system is indeed capable of increasingthe throughput. When the Herlev-artery is at or above moderate load DOGS willincrease the capacity by 15-25% compared to the capacity if only the pretimedplans was in use. Apparently there has been no previous simulations of DOGS andas such it is difficult to generate reproducible data for analysis. This is where thisproject comes in.

3.5 DOGS and offsets

For a basic program DOGS makes use of static signal plans which are tailored tothe respective time of day eg. morning. In Herlev and Glostrup such plans havebeen generated using the well-renown optimization package TRANSYT. Such pro-grams include an offset for each signal controller in the system, which are optimizedfor a certain cycle time, however DOGS always use the same offsets. AlthoughDOGS has support for dynamically adjusting the coordination to prioritize forthe current direction bias it is not enabled in either the Glostrup or Herlev sitesat the moment and works by selecting the offsets from a program which was op-timized for a fixed cycle time.

This optimization of offsets include aligning green starts so that the road userstravelling through the artery at a certain speed will experience green lights as theyapproach the next intersection. The green time displacement ∆f is the time fromgreen start at the first intersection to green start at the next and should matchthe travel time, tt, between the intersections (see Figure 2).

If ∆f > tt road users from the upstream intersection must stop at the nextintersection and wait for green. If ∆f < tt there is a risk of wasted green timesince the downstream intersection starts its green time before vehicles from theupstream intersection has a chance to reach it. These concepts are visualized inFigure 3.

Note that it might be a good idea to expedite the green start a bit ie. accept∆f < tt when the downstream intersection has vehicles in queue. When the queueis long the distance to close by vehicles from the previous intersection - beforemaking a stop - is shorter, affecting the real travel time. These queues are generatedfrom traffic that turned in from minor roads and possibly vehicles that did notmake it across during the previous green time and will be of dynamic length.

When DOGS increase the cycle time the green time displacement in one direc-tion is maintained. By Figure 3 we can see that C = ∆f12 +∆f21 and so the greentime displacement in the other direction will increase by the cycle time increase,disrupting coordination in this direction.

These observations were made already in the DRD analysis of DOGS [8] andthis project attemps to answer the question of how much of an effect this has.The obvious approach to a remedy is to select new offsets for each cycle time,

12

Figure 2: Green time displacement concept. Arrows indicate travel times.

Figure 3: Green time displacement scenarios

13

which DOGS might choose and switch from the TRANSYT optimized offsets forthe lower cycle time to the set of offsets which match the current DOGS level.

This alternative is called Modified DOGS and will further explained in the latersections of the report.

14

4 Simulation & Vissim

Traffic simulation is the emulation of traffic on a computer and it is done to gaininsight in road user behaviour and observe various effects eg. what happens to theminor-road traffic when we increase the cycle time to 100 seconds.

A main issue of traffic signal optimization is that of how to evaluate solutions.Fitness determination of a set of signal parameters is a major issue, especiallyin metaheuristic search, which is prevalent in the litterature and in this project,that put ”blind faith” in the evaluation procedure. This is to be understood suchthat metaheuristic search routines do not necessarily search the solution space ina manner in which each step a better solution is obtained, but rather by trial-and-error. Furthermore the metaheuristic must evaluate a certain amount of solutionsbefore confidence in the final solution is established, thus each evaluation must befast if the search is a part of an adaptive system, rather than an offline optimizationthat has no strict deadline.

Simulation handles the complexity issues of modelling the bilevel system ofmutually responsive road user behaviour versus traffic signal settings and allowsthe optimization routine to rely on the simulation results as a black box for fitnessevaluation.

The primary use of simulators are for infrastructure expansions and testingvarious signal timing plans, of course. In traffic signal optimization they are almostalways used to establish confidence in performance for some signal optimizationprocedure. This confidence comes from observing the actions of the system duringthe simulation but also by comparing aggregated fitness values with those comingfrom some other, well-known approach. In this regard the TRANSYT offline trafficsignal optimization package is often used as a baseline.

This form of testing favors quality of the simulation over execution speed, unlikesearch routines, which must have results quickly. In Table 1 are the names of threemajor simulators, which are used by traffic engineers to produce realistic trafficsimulations. In Denmark the de-facto simulation tool for final testing of signalsettings and infrastructure changes has become Vissim by PTV. For obtainingsignal settings TRANSYT is highly regarded by DRD though the results willoften be adjusted and confirmed in Vissim.

There are three types of simulators, the main difference being the level of detailin the underlying model. They are micro-, meso- and macrosimulators. Microsim-ulators model the behaviour of each vehicle and driver, mesosimulators regard themovements of platoons of vehicles and macrosimulators search for equilibriumsbetween signal settings and road user response (route choice), considering origins(input links) and destinations (output links).

Independent on the detail level of the model a simulation must run until it isconverged before the fitness can be determined.

Previous studies (see [4]) have shown that the CORSIM microsimulator is su-perior to the mesoscopic simulator from the TRANSYT package when combined

15

with a genetic algorithm, since the flow equations do not capture the dynamicaspects of traffic. But microsimulation is also slower to converge and thus evalua-tion of a solution will take longer. In a comparison study [6] Holst estimates therequired relative simulation time in a large network, see Table 1.

Vissim Dynameq Time Slice Assistant(micro) (meso) (macro)

1000 100 1

Table 1: Estimate of of relative required simulation time for convergence. Conver-gence of a Vissim simulation takes approximately 1000 times longer then the samesimulation in TSA.

Microsimulation will not scale as well as meso- and macrosimulation since thenumber of vehicles in the network will grow in proportion with the total length ofthe roads. In mesosimulation the number of platoons need not grow as fast sincesome arteries traverse the entire network and a single platoon is regarded. Theheadway threshold for platoon definition could also be increased to compensatefor the extra cars. Macrosimulators will scale in proportion with the size of theOD-matrices, which is the minimal level of detail and complexity for realisticresults. Meso- and macro simulators, using deterministic principles, have anotheradvantage since they can execute heuristic procedures to skip past much of theinitial population of roads, which is mandatory in microsimulation when trafficbegins to flow into the empty network. Since most simulations will be stoppedwhenever convergence is reached this is a very useful attribute.

Aside from the commercial simulator packages, such as the ones listed in Table 1,there are several examples of researchers implementing their own simulation tools.Such tools are tightly coupled to the test network and the results are questionablethus it is important that the industry agrees upon a common simulation platform,but also that common standards are used within the agreed upon tool. Such aproject has recently been undertaken by DRD to improve the comparability ofresults from different consulting firms.

Vissim

Vissim provides a microscopic simulation of traffic in a network. In this contextmicroscopic entails that each vehicle is individually modelled and, in a sense,Vissim takes the view of the users of the network.

The main feat of Vissim is the visual representation of vehicle movements andinspection of signal controller states. Furthermore Vissim allows a multitude ofinformation to be extracted in addition to the ones listed below. This, and a the-oretically well foundedness, is presumably why Vissim has become so widespreadin Denmark. Some of the most important informations which is available from aVissim simulation run are:

16

1. Delay: the difference between the best-case travel time ie. no intersectionsand travel at free flow speeds (no other road users). The delay from pointA to B when there are no intermediate intersections is an indication of thecongestion

2. Travel time is measured as the raw time spent by road users getting fromA to B in a network. Travel time sections can be placed anywhere and, likedelay, can be filtered on vehicle type eg. car, truck and bus

3. Average queue lengths are correlated with delays especially when measuringdelays for vehicles crossing an intersection

Below I will briefly introduce the Vissim elements that have required the mostattention in this project. In section 7 I will go into the practical details of linkinputs and route choices.

Network Elements

Vissim is highly flexible with regards to network layout description and intersectionturning movements can be fine-tuned almost to perfection, given enough time. Thenetwork is designed using a GUI interface where links are joined using connectors.

Links are directed sections of road with one or more lanes. All lanes have thesame direction as the link - the opposite direction is modelled using a parallel link.

Connectors are mostly relevant in intersections where they connect exactly twolinks, however the lanes connected within the links can be chosen freely. Multipleconnectors may be inserted between links, allowing routing alternatives.

Traffic input

Vissim is capable of dynamic traffic assignment (DTA) as well as static input.DTA is a method in which the traffic flow adapts to the capacity of the networkdue to a stochastic user equilibrium (SUE) ie. the road user response of trafficconditions model their choice of route [17].

Vissim can perform this form of traffic input given zones, which are confinedand non-overlapping areas of the network, and a matrix describing the relativetraffic from each zone to each other zone.

In this project DTA was abandoned on recommendation from DTU Transportprofessor Otto Anker Nielsen due to the dynamic nature of the traffic signalssince, in his experience, odd phenomenon may occur such as random gridlocks,when adjacent links are fully saturated.

Instead static input was chosen. In static input traffic enters on specific linksand traverse the network until an exit link has been reached. Static input is usedin combination with routing decisions, which are usually placed on input link suchthat each vehicle entering will be routed through the network according to theavailable traffic data.

17

Routing decisions

Routing decisions are made by vehicles when they pass over a routing decisionpoint in the Vissim network. Selecting routes for vehicles can be done either byplacing a routing decision point on an input link and designate a number of exitlink options (end-to-end routes) or by placing routing decisions on each approachand route vehicles through eg. an intersection (local routes).

For the first option there exist many routes even for small networks when routesare symmetric (albeit using different input and exit links). The number of routeswill grow exponentially as the number of intersections (exit link options) increaseand the problem of mapping traffic count data onto end-to-end routes is not easyto solve. On the upside end-to-end routes are more correct to use since road userswill most likely know how they wish to traverse the network in advance and routesending in an exit link are certain to cause no vehicles to cycle about indefinatelyin the network.

The second option requires a route per traffic stream in each intersection. Herea traffic stream is a pair of orientational markers indicating from where the routeorigins and where it ends eg. north-to-south (a through-going traffic stream) ornorth-to-west (a left-turning stream). This option is easy to implement given trafficcount data since they immediately give the proportions of vehicles making eachturn (ie. taking each route) in an approach. A vehicle will pass a number of routingdecisions, obtaining new routes (making turning movements) until an exit link isreached.

It is possible to implement the first option by solving a linear program usingthe ordinary traffic counts as input data. The complexity of this solution causedme to adopt the second option instead and in section 7.3 I describe how I did this.Note that the problem of indefinite cycling the network cannot occur since I amregarding an artery only in this project and thus it is not possible to choose acyclic route (there are no u-turns).

18

5 Vehicle Actuated Programming in Vissim

VAP is an optional module for Vissim which enables direct programming of signalcontrollers. VAP is a simple, label-based (goto) language. The main feature isaccess to a library of functions, which manipulate the state of the signal controller.

With VAP there is a graphical program, VISVAP, that allows the user to designa flowchart description of the controller logic, rather than writing it in VAP, asVISVAP can compile the flowchart into VAP. Figure 4 shows an example of asimple logic to control the lights at the ring 3 / Herlev Sygehus intersection.

Figure 4: VISVAP flowchart description of simple fixed-time logic for the intersec-tion between Herlev Sygehus and ringroad 3

The VAP program is called once for every simulation second. The starting labelis START and the program proceeds as indicated by the arrows until the ENDlabel has been reached. Diamond boxes are logical tests where the right-goingarrow indicates TRUE and down-going indicates FALSE. Square boxes containexpressions, in this case we use Is(<stage_from>,<stage_to>) to switch betweenstages, when a certain portion of the current cycle time has passed. Below is theVAP code, which corresponds to the flowchart:

/* EXPRESSIONS */cycle_sec := T;cycle_sec_plus1 := cycle_sec + 1;

/* MAIN PROGRAM */

S00Z001: IF cycle_sec = 35 THENS01Z001: Is(1,2)

ELSES00Z002: IF cycle_sec = 50 THENS01Z002: Is(2,3)

ELSES00Z003: IF cycle_sec = 80 THENS01Z003: Is(3,1); SetT(1);

19

GOTO PROG_ENDEEND

ENDEND;

S02Z004: SetT(cycle_sec_plus1)PROG_ENDE: .

VAP is unsuited for complex controller logic, such as ones involving predictionsand optimization by iteration. This is due to the fact that VAP only has supportfor basic programming language constructs and the label-based nature of the lan-guage, which is detrimental to larger code bases see eg. the statement by Dijkstra[5]. As an example the above VAP code could be written in procedural languagewith better programming constructs as:

function UpdateController(cycle_second){switch(cycle_second){case 35: Interstage(1,2)case 50: Interstage(2,3)case 80: Interstage(3,1); Set_cycle_second(1); returncase else: /* do nothing */}Set_cycle_second(cycle_second + 1) /* update time */

}

VAP is suitable, however, for the implementation of DOGS due to its simpledecision system as described in section 3. In this section I will describe how theDOGS logic was implementated in VAP.

5.1 Interstage definitions

Before we move on to DOGS in VAP it is fundamental to explain the Interstage(abbr. Is) concept. Interstage definitions are mandatory in Vissim whenever aVAP program is to control a signal.

An interstage is basically the lighting scheme to be used during stage transition.Usually, when switching from stage A to B the lights of A switch to amber andthen red while B switch from red to red and amber and then green.

The amber light of A is a warning that a transition is in progress, the intersectionshould be cleared and no more vehicles should enter the intersection. To ensureright-of-way consistency during the transition, B will stay red until the momentA switches from amber to red. For all intersections discussed in this project, theamber period is 4 seconds.

The red and amber period of B indicates that attentive entry into the intersec-tion is permitted. The red and amber period is 2 seconds for all intersections.

20

Thus a total stage transition will last 6 seconds or more. Figure 5 is an exampleof the interstage lost times for various number of stages and cycle times. Somestages - eg. a through, left and rightgoing stage followed by a left-only stage -will be compatible ie. there is no pause during the transition thus the table ispessimistic. However it clearly shows that there is a tradeoff between lost timeand cycle time - especially in complex, multistaged intersections.

Figure 5: Interstage lost time in percent of cycle time for some combinations ofcycle time and number of incompatible stages

In the above flowchart and code examples we start an interstage whenever wewish to move to the next stage.

The interstages are defined in Vissim by .PUA files. Below is an example of sucha definition for Herlev Bygade. This intersection has two stages; stage A allowingtraffic in either direction of the arterial and stage B for turn-ins from the minorroad.

$SIGNAL_GROUPSA 1B 2

$STAGESStage_1 Ared BStage_2 Bred A

$STARTING_STAGEStage_1

$INTERSTAGE1Length [s] : 6From Stage : 1To Stage : 2$ redend grend

21

A -127 0B 4 127

$INTERSTAGE2Length [s] : 6From Stage : 2To Stage : 1$ redend grendB -127 0A 4 127$END

In section $STAGES it is defined that stage A should be green while B shouldis red and vice versa (they are not compatible). Here A and B refers to a space-separated list of signal groups from the $SIGNAL GROUPS section.

For the interstage definitions, in INTERSTAGE1, we have redend for A to be-127, which means that A is green before the interstage, and grend (green end) is0 meaning it should be red when the interstage has completed. For stage B, whichis red before the interstage is run due to the $STAGES definition, the redend(=green start) occurs 6 seconds into the interstage and grend set to 127 meansthat B should remain green after the interstage.

It is always up to the interstage designer to ensure that no right-of-way con-flicts are present in the stage definitions. PTV supplies a support tool, whichsolves this issue, called CROSSIG. CROSSIG is capable of generating .PUA files;in this project CROSSIG was not available, however, and they were generatedautomatically from the signal plans, which are listed in appendix A.

Interstage rules

The signal plans, for which interstage definitions are to be built, are formatted sothat each named signal group (head) has a row with C-cells, where C is the cycletime. Each cell can be amber, green, yellow or red. Thus a complete signal timingplan is visually represented as one or more such rows in a stack.

In order to generate the interstage definitions (.PUA files in Vissim) it is neces-sary with a definition of an interstage itself. A stage is said to run while the signalgroups of the stage is settled in the green state. We define that when a stage isrunning an interstage cannot run and vice versa. Thus every cycle second mustspecify the current stage or interstage.

An interstage runs whenever one or more signal groups receive new colors untilthe changes of color have settled. This could for instance be the green end forgroup A, which is the start of an interstage cycle second the group begins to showyellow, until the perpendicular group, B, has settled its green light, which couldinclude amber time. In the sample .PUA file above we see the implementationof this exact scenario: A ends its green time in interstage second 1 and B begins

22

its amber-green time 4 seconds later, while group A is showing yellow. Group Bshows amber for 2 seconds and thus the total length of the interstage is 6 seconds.

It is important to note that, while stages must have a temporal extend tomake sense, interstages may have zero length. Such interstages occur when lightswitch directly from red to green (respecting safety) and from green to red withoutthe ordinary amber and yellow time respectively. Amber and yellow times aredefined in the Vissim network file (.INP) and cannot be controller in the interstagedefinitions. Amber and yellow time is automatically appended by Vissim to thegreen- and red end times when the VAP controller runs an interstage.

A safety period, where all heads are red, is sometimes introduced in order toallow the intersection to be cleared. This can be modelled either as a stage with nogreen signal groups or included into the interstage definition by prolonging red endtimes and interstage length by the length of the safety period. The latter solutionis preferred since it is directly supported in the PUA format and also avoids theintroduction of an all-red stage and a number of extra interstages to and from theall-red stage.

5.2 DOGS

As VAP does not permit the writing of a program, which supervise all signalcontrollers at the same time, it was necessary to dedicate a signal controller asthe master controller. To fully separate the master/slave concept it was chosen toinstall a virtual signal controller for each DOGS area, whose only purpose is torun the DOGS program.

The master controller, which for the purpose of offset has a virtual location onHerlev Hovedgade and Roskildevej (for the Herlev and Glostrup areas resp.), runsthe DOGS program and determines the current level by inspecting the northern-and southern detectors according to the specification outlined in section 3. Inaddition this controller also runs the master clock and the current DOGS leveland master cycle second is sent to all slave controllers every cycle second.

The slave signal controller - even the one on Herlev Hovedgade - must listen forcommunication from the master controller and set the green time of the variousstages according to the current dogs level and cycle second as received from themaster.

Both master and slave VAP controllers are generated automatically using ascript, which takes parameters such as, for the master, the area-specific detectorsand activation / level-up / level-down bounds and, for the slave, offset value(s),signal program etc. In appendix B are examples of a master and a slave controllersin VAP.

5.2.1 Master

Relevant to master controllers we need to know the northern and southern detectornames as these are used to determine if DOGS is enabled or turned off. Once DOGS

23

is enabled another set of detectors (possibly overlapping) are measured upon todetermine the appropriate level of DOGS. Note that, depending on thresholdvalues for vehicle count and occupancy rates, DOGS may be enabled but notperform adjustments to the base-program - this is by TTS design.

The threshold values, which are parameters that must be fed into the generatorscript, were indicated by the DOGS reference material for each area, however dueto variations between the traffic, which TTS used to tune the threshold values,and the traffic which is observed in the simulation, it was decided to manuallyretune them. Along with the detector data described in section 6.1 TTS suppliedthe selected DOGS levels in the same period. By a manual, iterative process thelevels selected by DOGS in the simulator was fitted to the levels of the detectordata set during the morning period. The main fixpoints used was the maximumand the average levels chosen.

DOGS accumulate detections over a cycle - which is of variable length - andcompare them to the threshold values. Occupancy is the percentage of time ofwhich the detector was enabled ie. a vehicle passed over or was in queue overthe detector and thus the detection period can be chosen freely. The amount ofvehicles which passed over (the 2nd component for threshold matching) is in totalnumbers and consequently when the cycle time increase so does the number ofdetected vehicles. TTS informs me that no adjustment - except for the standardexponential smoothening - is performed when comparing detector vehicle countvalues with the thresholds. I decided to correct this in the VAP code by assumingthe counting thresholds matched a 80 seconds cycle and then scale the detectedcount to this level by using the actual cycle time (which is usually higher, whenDOGS is enabled).

Another observation, though not compensated for as for vehicle counts, is thatwhen DOGS is active the level is adjusted at most by one for each 2-cycle. Thuswhen the level is high it will take longer to change between levels and the mea-suring periods are longer. This results in more accurate measurements, but lessresponsiveness. I do not have a suggestion for an alternative to this approach, thatalso solves the problem of keeping the controllers synchronized.

The modified version of the master controller differ only from the unmodifiedversion in how long the cycle time must be allowed to run before changing to thenext - thus changing between the versions, for the master, is a matter of adjustinga single variable.

5.2.2 Slave

The purpose of slave controllers is to obey the cycle second and DOGS levelinstructions from the master controller.

The first step for a slave is to calculate the local cycle second, which due tocontroller offset will usually differ from the master cycle second. An exception isthe slave controller, which controls the intersection in which the master controlleris physically positioned - the distance between them is 0 and likewise the offset.

24

The modified DOGS version of the slave will also select its offset depending onthe requested DOGS level from the master.

Given the local time, current DOGS level (and offset) the slave will implementthe associated signal timing plan (see appendix A) by making interstage transi-tions.

An issue I discovered during implementation can be described accordingly: con-sider that stage A is active while the master controller lowers the DOGS level by1. In this case the end time is lowered if stage A receives priority from DOGS andit may happen that the end time for stage A is now lower then the current cyclesecond. Stage A will then have received more green time than it was supposed toand I solved this issue by causing the slave to immediately make the transitionfrom stage A to the next stage, B. In case B is not the stage which was supposedto be active (a rare case - stage B is short indeed) we allow stage A to carry overto the next cycle as we can only make stage transitions between subsequent stages- not in arbitrary order.

5.3 Bus priority

Three intersections in the Glostrup area - Fabriksparken, Gammel Landevej andKindebjergvej - operate with bus priority on the arterial direction. Bus priority iseffectuated solely by the corresponding slave controller as follows:

If a bus arrives from north or south during the stage which gives green to thebus, up to 10 seconds extra green time is distributed from the minor road stage tothis stage. The effect is that buses might just make it across before the next stageis started rather than being cut off. In the next cycle the main stage is shortenedby the same amount of time and the minor stage is lengthened accordingly.

This is implemented by associating detectors for north- and southgoing busesfor each of these intersections. The autogenerated VAP code will then check forbus detections in each cycle second and perform bus prioritization if:

1. The main stage is the currently active stage

2. The signal controller is not currently performing a bus prioritization

3. The signal controller is not currently compensating the minor road stage dueto prioritization in the previous cycle

When bus prioritization is activated under these conditions the stage end timeswill be adjusted as mentioned and the next cycle (compensation) will performlikewise adjustments albeit inversed.

In the case where a bus arrives and activates bus prioritization but make itacross the intersection before the green time for the stage has been extended, busprioritization is cancelled and no changes are made to the green time distribution.

25

Such iterations of borrowing and compensation will not affect coordination verymuch since only the green-end times are changed and the cycle time remains in syncwith the common cycle time set by DOGS. Hence the performance degradation fornon-bus traffic becomes a mere matter of capacity redistribution. This is changedif the aggresiveness of bus priority is increased and the next green stage for the busis expedited, however only the above described bus priority technique was tested.

26

6 Traffic Analysis

For the two areas of interest, Glostrup and Herlev, TTS supplied data from de-tectors for a period of a couple of weeks in november 2007.

This period is generally accepted as the beginning of the winter season and assuch the traffic is expected to be high.

The data from TTS is a supplement to the traffic counts, which were made avail-able by DRD. Since the detector data is anonymous with respect to vehicles types,for links in the ends of the arterial (Herlev Sygehus from north and Roskildevejfrom east, west and south) the data from the corresponding detectors was used inthe project to scale the input sizes of the traffic counts.

The format of the data from TTS is:

Date Time D1 ... DN13-11-2007 08:42:56 39 ... 3513-11-2007 08:44:26 38 ... 28

Table 2: Format of TTS supplied detector data

Thus each detector, named DN, has a column where the numbers are the de-tected vehicles since last detection. The detections are made once for every cyclethus there will be some variations in the time between measurements due to theadjustments to cycle time, which are made by DOGS.

It was agreed with DRD that the temporal resolution for link inputs and routedecisions was to be fixed at 15 minutes, which corresponds to the resolution of thetraffic counts. Accumulation was performed on the DOGS data by indexing timewithin the data period into 15 minute bins and summing detections from the last15 minutes.

Multiple data files - for different sets of detectors - were received for each area.Since the data period was not identical over the data files it was necessary toperform some cleanup in order to generate accumulated data in which all detectorswere represented.

Area From To DetectorsHerlev 13-11-2007 20:45 28-11-2007 09:45 D3-D8, D13-D15, D18

Glostrup 13-11-2007 08:45 26-11-2007 14:15 D1-D14

Table 3: Periods of aggregated and cleaned data sets

The cleaned data was exported to a single table of more than 30.000 rows inthe format:

Date Time Area Detector Name From Direction Vehicles

Table 4: Format of cleaned data set

27

In the next section I will use the cleaned data to make some analyses and com-parisons of the areas to discover facts on directional proportions and distributionof traffic on a daily basis.

Section 6.2 brings additional conclusions from the traffic count data set to fillout some details, which cannot be extracted from the analysis of detector dataalone.

6.1 Detector data analysis

The first four graphs (Figures 6) shows the overall fluctuation of traffic (mean-value) on workdays and in weekends split on mornings (7-9) and afternoons (15-17)for north- and southgoing traffic (N and S resp.).

(a) Herlev - morning (b) Herlev - afternoon

(c) Glostrup - morning (d) Glostrup - afternoon

Figure 6: Proportions of north- and south-going traffic in the morning and after-noon in Herlev and Glostrup

We can see that there is an overweight of northgoing traffic. This overweight ismore profound in the Glostrup area and increases in the afternoon for both areas.

From these graphs we can also see that, in the weekend, most traffic happensin the afternoon.

The next graph, see Figure 7a, shows the usual commuter- and lunch trafficpatterns. The data from all mondays to fridays in the dataset have almost identicaltemporal distributions and thus the graph shows summarized data from workdays.

28

(a) Workdays

(b) Weekends

Figure 7: Distribution of traffic in Herlev and Glostrup

29

By comparing the workday distribution to the detected traffic in the weekend,see Figure 7b - and at the same time looking at the directional proportions - it isclear that ringroad 3 is heavily used by commuters in both Herlev and Glostrup.Traffic is almost identically distributed on saturdays and sundays and the graphshows summarized data for the weekend.

The next graph (Figure 8) show how detections are aligned in the north andsouthgoing directions in both areas. (For both directions and areas these propor-tions do not vary in particular between workday and weekend).

Figure 8: Relative detections for north- and southgoing links in Herlev andGlostrup

One notable conclusion that can be drawn from these detector data is that thereis a slight overweight of north-going traffic in both areas, in the most extreme casearound 3:2, so the direction bias is not profound.

We can also conclude that ringroad 3 in Glostrup and Herlev face heavy com-muter traffic by the classical increases in traffic from 7-9 and 15-17 but also slightlyaround 12 due to lunch traffic. The background traffic (ie. traffic not directlycaused by commuters) through the workdays is heavy as well, starting around6 and leveling off around 18. Morning and afternoon traffic appears to be quitesimilar.

6.2 Traffic count analysis

Traffic counts are widely used in traffic planning to setup simulations. They areperformed manually by a suitable number of persons, so that each approach andturning motion of an intersection is counted simultaneously.

DRD provided traffic counts for every intersection except Ejby Torvevej (whichis a blinded minor road and of little importance according to DRD) which has madeit possible to model in detail the turning motions in the network. The countingperiod was 7.00-9.00 in the mornings and 15.00-17.00 in the afternoons in 15-minutes intervals. The counts involved, for each approach, the turning movementsof cars (including vans) and trucks.

30

In Table 5 we see a listing of the traffic counts and couting dates; most counts arefrom fall 2001 before the expansion of motorring 3 had begun. It is expected thatthe traffic has changed since then but the overall changes will probably fluctuateuntil motorring 3 is finished late 2008 (expected) due to differing conditions overtime on motorring 3 (lane closures etc).

For some of the most important intersections (Mileparken, Jyllingevej, Roskilde-vej) we have newer traffic counts. For Herlev Hovedgade I received a detector count(MASTRA) from 2007 in addition to the traffic count in 2001, however the reso-lution was 1 hour and there was no distinction between cars and trucks and so itwas disregarded.

# Intersection Date Counted1 Herlev Sygehus 30-10-20012 Hjortespringvej 09-10-20013 Herlev Bygade 04-10-20014 Herlev Hovedgade 02-10-20015 Mileparken 03-10-20056 Ejby Industrivej 27-02-20017 Ejby Torvevej -8 Jyllingevej 23-10-20079 Fabriksparken 04-10-200110 Gammel Landevej 03-10-200111 Kindebjergvej 18-09-200112 Roskildevej 28-08-2003

Table 5: Traffic count dates

The main feat of traffic counts is that the ratio of cars to trucks is available. InFigure 9 we see that - in total - there is about the same amount of traffic in eachdirection, however there are more trucks from south (ie. northgoing) supportingthe results on direction bias from the DOGS detector data. Furthermore we areconfirmed again on the clear arterial nature of the involved intersections due tothe relative volumes of north-south going traffic to traffic from east-west.

The columns E and W indicate the total load of trucks and vehicles comingfrom east and west respectively, in which we see that the traffic from west, whichis travelling towards the city of Copenhagen, is somewhat heavier than the trafficcoming from east, travelling away from the city.

In Figure 10 we see how the proportion of cars and trucks evolve over time andnote that the proportion remains the same in the sampling period.

In the next figure (11) we see the proportions of cars to trucks for each inter-section. The bars are the sum of cars and trucks in the morning period and alsogive an indication of the load each intersection faces. We can see that the mostheavily loaded intersections are Herlev Hovedgade, Jyllingevej and Roskildevej(disregarding that two latter two were counted later than the other intersections)and that Herlev Hovedgade is the junction which sees the most trucks per car

31

Figure 9: Combined ratio of cars to trucks from each direction in the morningperiod. There are more trucks coming from south than from north.

Figure 10: As Figure 9 but over time. The proportion of cars to trucks does notvary much.

32

while Jyllingevej serve considerably less trucks. It is interesting to see that theseheavily loaded intersections are the ones which were recounted after 2001, exceptfor Mileparken.

Figure 11: Cars to trucks proportions per intersection

The final two figures (12a-12b) show, for each DOGS controlled area, the de-mand faced from each direction split on trucks and cars.

In all cases the demand from cars by far outweighs truck demand; the inter-sections facing the most truck demand in Herlev are Herlev Hovedgade (from alldirections), Herlev Bygade (from north and south) and also Herlev Sygehus fromthe arterial directions.

In Glostrup we see that Fabriksparken has far more northgoing traffic and fairamounts of trucks and both arterial directions. Roskildevej has almost as muchtraffic from the sideroads as does Herlev Hovedgade, emphasizing the fact thatringroad 3 is not exclusively an artery in the north-south directions for severalintersections.

33

(a) Herlev

(b) Glostrup

Figure 12: Demand from direction per vehicle type in each area

34

7 Vissim Network Modelling

The Vissim network used throughout the project is derived from a network origi-nally introduced by COWI and later reworked by DTU Transport students.

COWI’s version included ringroad 3 from Jyllingevej to the intersection withhighway 3 and even further north. In addition M3, which runs almost parallel withringroad 3 in this area, was included as well as the minor roads in between.

The network which is modelled in this project is somewhat large. Vissim main-tains a .inp file, which contains the most relevant informations necessary to run asimulation including information on links, connectors and routes. This file is plaintext and can be modified using simple file input-output operations. To properlyinsert and manage the traffic data necessary to obtain a correct simulation, theinp file is manipulated by scripts - how I do this is explained below3.

7.1 Modifications and additions to existing model

As such the network was missing four intersections of ringroad 3 from Jyllingevejto Roskildevej. To establish this section satellite photos from Google Earth wascombined with intersection layouts, kindly provided by DRD.

The signal plans and naming conventions for the existing intersections in theCOWI model for ringroad 3 intersections were adopted when entering the fourmissing intersections into the network. As for the intersection layout, DRD pro-vided the missing signal plans for these intersections as well.

To prevent side-effects all links not connected to ringroad 3 from Herlev Sygehusto Jylligevej were removed as well as all parking lots (DTA zones).

A number of mistakes were corrected in the definition of the intersections. Thiswas done using layout plans for the intersections from DRD. Most mistakes wererelated to non-existent turning-lanes (and even turning possibilities) and the place-ment of bus-only lanes.

7.2 Link inputs

The original network generated traffic load and route choices from OD matrices.For my simulations I had decided to use static inputs and routes from the trafficcounts and detector data, analysed in section 6.

Link inputs are created on the basis of the detector data from TTS and the trafficcounts from DRD. First the traffic counts is used to establish the proportion of

3Note that many of the operations I perform by changing the raw Vissim network data file canbe done using the COM interface of Vissim. However when work on this project was commencedonly Vissim version 4 was available, which has major flaws in COM interaction. So I decided totake the herein described approach instead, accepting that changes in the Vissim data file formatcould break my tools. Vissim 5 works much better with COM and future project could involveporting the tools to use the COM interface.

35

Figure 13: The final Vissim network for ringroad 3 from Herlev Sygehus (north)to Roskildevej (south)

cars to trucks for all approaches, except Ejby Torvevej. Then, for the approaches,which were measured upon in the TTS data, I apply detector values rather thantraffic count values. This is done using detectors north of Herlev Sygehus in Herlevand from south for the east-, west- and southern approaches to Roskildevej.

The link inputs were scaled to represent hourly traffic input, as Vissim require,and inserted into the Vissim network file.

The format of a link input in the Vissim inp file is:

INPUT <input_number>NAME "<input_description>" LABEL 0.00 0.00LINK <link_number> Q <link_contrib> COMPOSITION <comp>TIME FROM <t_begin> UNTIL <t_end>

(Vehicles always arrive at the beginning of the link.)

Where the most important fields are the link number, defining on which link theinput occurs, the link contrib, which is the input quantity in vehicles per hour andfinally t begin and t end ie. the time period in which this traffic quantity must begenerated.

The comp variable defines the traffic composition used eg. cars, trucks, buses or acombination. According to the Vissim manual it is possible, but not recommended,

36

to define multiple inputs on the same link for the same period of time. Since thetraffic composition will remain fairly static it is more intuitive to define a singlelink input for a traffic composition, which defines relative proportions of eachpossible vehicle type.

7.3 Routes

Routes can be designed using the GUI tool provided with Vissim. However, in thespirit of the solution for automated link inputs routes are inserted automatically.

At every intersection it is possible to follow each adjacent link (ie. turn left,right or go straight through) and thus the total number of routes from an inputlink to an exit link in the network is tremendous.

To apply traffic count dataset by DRD in Vissim (section 6.2) it is possible touse Vissim turning decisions but the Vissim manual is clear that static routesshould be used instead, when modelling turning distributions. The main reasonis that congestion may cause a decision to turn to be overruled whereas a vehicleon a fixed route will wait for the congestion to clear. It appears that technicallimitations in Vissim (or perhaps backwards compatibility requirements) renderVissim unable to fixate a certain destination upon a vehicle by using turningdecisions alone, unlike when using a routing decision. But routing decisions hasan edge over turning decisions in that they can be made a long time before thevehicle arrives at the critical point at which to turn, allowing the vehicle to positionitself in the turning lane rather than making a last-minute lane change, when theturning decision is applied.

The simplest approach was to introduce a routing decision for each approach,which had traffic count data, and then add routes - respecting the counting data- which represented the turning motion. Such a route is internal as it does notnecessarily lead from an input to an exit link. Consequently this approach yieldsa network with the possibility of endless circulation of vehicles, however since weonly regard an artery in this project - and the fact that there are no U-turns inthe network - no vehicles will be able to circulate and will always find an exit link.

The routing decision must be placed at a decision point, however this does notexist in Vissim. Rather the decision point is scattered over 2 or more connec-tors attached to each link facing an intersection. In order to overcome this theseconnectors were grouped by a naming convention which identifies which decisionpoint they belong to and which turning motion they will cause a vehicle to take.The names are the concatenation of the direction from which traffic arrives (ie.north, south, east or west), the number of the intersection the decision belongsto (intersections are sequentially numbered from north to south) and finally theturning motion (ie. left, through or right), whichever is applicable.

As an example the decision point at Herlev Sygehus (the northern-most intersec-tion with the number 1), which faces traffic from north consist of three connectors,are called N1L, N1T and N1R.

37

To find the insertion point for the routing a backtracking search is made fromeach turning motion until a common link is found. This link is thus the decisionpoint and we can automatically generate our internal routes by using a discoveryroutine to find a valid route. This routine is presented later in this section.

In Figure 14 is an example of decision points (y) and the proportions of trafficfor each turning motion.

Figure 14: Flow distribution principle

In the Vissim network file a routing decisions and the corresponding choice sethas the format:

ROUTING_DECISION <number> NAME "<description>" LABEL 0.00 0.00LINK <origin_link> AT 50.000TIME FROM 0.0 UNTIL 99999.0NODE 0VEHICLE_CLASSES <composition>ROUTE 1 DESTINATION LINK <dest_link1> AT 5.000FRACTION <fraction1>OVER <connector> <link> ... <connector>ROUTE 2 DESTINATION LINK <dest_link2> AT 5.000FRACTION <fraction2>OVER <connector> <link> ... <connector>

38

The origin link denotes the position of the decision point. The line VEHI-CLE CLASS... impose a limit of the vehicles, which are required to select onof the routes of this routing decision. A composition may be a single vehicle type(eg. Car) or a combination (eg. Car, Truck). Next comes a number of lines withroute alternatives. The OVER... lines describe the path taken from origin link todest link. The first connector must be downstream of - and connected to - thedecision point link. Likewise the final connector must be upstream and connectedto the destination and the same applies to internal links.

The fractions define the relative distribution of vehicles of the given class orclasses, which should take each route. Route fractions are taken directly as thevalues of each turning motion of the DRD supplied traffic counts.

In order to enumerate the relevant routes defining a turning motion it is neces-sary to parse the .inp file and generate an internal representation of the networkas a graph. A route discovery routine was implemented:

def discover start, exits, path = [], &route_foundreturn if path.include?(start) # avoid loops# check if start is the road segment we search forroute_found[Route.new(path + [start])] if exits.include?(start)if start.is_a?(Connector)# you can only search on by going to the connected linkdiscover(start.to_link, exits, path + [start], &route_found)

else# start is a link and has zero or more outgoing connectorsstart.outgoing_connectors.each do |conn|discover(conn, exits, path + [start], &route_found)

endend

end

The discovery routine uses recursion to explore the network and find exit links,which are connected to link by a path of links and connectors.

In the initial call only the starting link is given along with an empty path anda callback-method, route_found, which is invoked by each call timed a new routeis found.

(The discover routine is a so-called generator of Ruby and the first invoca-tion might look like this: discover(start_link){|route| routes.add(route)}where the block is enclosed by {} and all routes found from start_link are simplystored for later in an array.)

A Vissim route is a sequence of connectors and links and must start and endwith the first connector, which is outgoing from the start link, and the connector,which is incoming to the exit link, resp.

In line 2 a check is made if the adjacent link, which is currently being explored,has already been visited in which case it should be skipped to avoid a loop. In

39

line 8 it is checked whether the adjacent link leads out of the network. If it doeswe have found a route from the start link otherwise we descend into the recursionand explore the adjacent links of this link.

The Route.new invocation, which is performed when an exit link is found, in-stantiates a new Route object, which enables additional options such as printingthe mentioned sequence of connectors links for Vissim, which is more cumbersomewith just the raw path.

7.4 Right-of-way

The purpose of a traffic signal is to fairly distribute the right-of-way for conflictingtraffic motions. In spite of this traffic signals cannot overcome all situations andrely on road users to enforce themselves some right-of-way rules. This especiallybecomes relevant when the capacity of the intersection is reached and vehiclesbecome trapped due to a stage change.

Vissim per default allows ”collisions” since overlapping links and connectorsmust be manually prioritized or marked as a conflict area. The existing networkwas built using previous versions of Vissim, which only supported priority rules(see Figure 15).

Figure 15: From the Vissim manual: illustration of priority rule concepts

In Vissim 5 conflict areas were added to perform a similar task and are recom-mended over priority rules (the latter remain in Vissim for compatibility) sincethey are easier to establish and will result in more intelligent driving behaviour.For instance vehicles will avoid entering a conflict area if they can see that itwill not be possible to leave it with a certain minimum speed, which will preventvehicles from clogging up intersections.

40

Conflict areas and priority rules both rely on threshold values (gap) which roadusers will use to assess whether it is possible to safely enter a conflict area. Thegap is an estimate of the minimum time before the next vehicle from a conflictinglink will enter the conflict area.

For the extensions made from Jyllingevej to Roskildevej relevant conflict areaswas added for each of the four intersections. The default values in Vissim servicepack 6 was used for all conflict areas.

During simulation it became apparent that the priority rules did not preventcollisions in the preexisting intersection so it was decided to replace them withconflict areas. The intersection which had collisions using only priority rules are:

• Herlev Syghus

• Hjortespringvej

• Herlev Hovedgade

• Mileparken

• Ejby Industrivej

• Ejby Torvevej

• Jyllingevej

The intersections with the most observed collisions were Herlev Hovedgade,Hjortespringvej and Herlev Sygehus. It appears that priority rules have difficultiesin coping with trapped traffic whereas conflict areas avoid all collisions. Thus theonly priority rules which are carried over from the original model are those for busstops.

Conflict areas basically make vehicles in conflicting traffic flows aware of eachother so that collisions can be avoided. It is also possible - but not mandatory - toassign a priority. Conflict areas for merging situations should preserve the orderof the vehicles and thus have no priority.

A number of additional situations arise for which the following rules were used:

1. Left-turning traffic must wait when traffic from the opposite direction - andin the same stage - is going through the intersection

2. When vehicles are trapped in the intersection, waiting for a left turn whilethe stage changes the vehicles from the next stage, which are in a conflictingmotion, must wait for the left-turners to clear even though they have a greenlight. This is to avoid having traffic stuck in the intersection waiting for theirnext stage

3. Buses leaving bus stops are always prioritized

41

7.5 Signal plans

Signal plans define the stage sequence, green duration and how changes betweenadjacent stages should happen with respect to colors in the from and to stages.For cycle-based signal plans the cycle time must be equal to the sum of green andinterstage time from the beginning of the first stage until it begins again.

A single stage defines the signal head colors of one or more signal group, which,in turn, is a group of signal heads operating synchronously.

The simplest signal controller consist of two stages. In Figure 16 the arrowsindicate the directions being served green.

Figure 16: A simple intersection

DOGS rely on existing signal plans and modify the duration of the stage orstages, which serve green in the direction of the arterial. Thus DOGS assume thatthe stage sequence and interstages are optimized so that the time lost in stagechanges is minimized and safe so that vehicles in eg. left-turning movements havetime to leave the intersection before the conflicting direction receives green.

For this project DRD has supplied a number of signal plans for each intersection,developed by TTS. Throughout the plans signal groups in one direction (usuallythe major one) are named A and B in the perpendicular direction. Names such asAt, Av, Atv indicates signal group for the throughgoing, leftgoing (v = venstre,Danish for left) and a combination for the final name variant. Lower case a’s andb’s indicate a signal group for pedestrians in the major and minor direction resp.Lower case v’s mean that for the controller(s) in this plan a left-turning light isattached to an ordinary red-yellow-green light in order to make it clear that left-turners now have the lane to themselves. If the V is in upper case the light isexclusively for left-turning traffic.

For some intersections a number of alternative plans were supplied. Consideringthe scope of this project only a single plan was chosen for each intersection andtime of day. Generally plans involving pedestrian or bicyclist actuated stages wereavoided so as to reduce the complexity of the simulation and maximize the po-tential for traffic signal optimization. Pedestrians can have devastating effects onvehicular traffic performance on issues of throughput and coordination eg. when

42

a button is pressed to activate a pedestrian signal stage or pedestrians linger toolong in a crosswalk. It was confirmed by TTS that pedestrian-actuated stages,which are taken in a stochastic manner ie. when a button is pressed, can be devas-tating to the coordination of traffic signals. Furthermore multiple through-goingbicyclists may hinder the flow of right-turning vehicles (in right-side driven trafficnetworks) and the handling of these issues is not in the scope of this project.

As a final simplifying step it was chosen not to provide signal heads for pedestri-ans and bicyclists as these types of road users are not being simulated. Pedestrianstages will mostly follow the parallel stages anyway and if this is not the casethen the stage, which is being denied in favor of the pedestrian stage, will simplyreceive red for the duration.

The final plans, which are used in the simulation, can be seen in appendix A.

The actual implementation if the signal plans is done in VAP by running theinterstages at the cycle second according to the signal plan, for more details referto section 5.

7.6 Signal controllers

The optimization system (see Section 8.6) needs some additional information onthe signal controllers, the distances between intersections and which stages arearterial. This is not immediately available in the Vissim network file but can bededuced.

Since Vissim does not offer the concept of an intersection - and this is needed toplace intersections relative to each other for signal coordination - this informationwas extracted as follows.

Arteries have the property that they have two major traffic streams4, whichtraverse the arterial from end to end. These streams can be called up and down orleft and right or even clockwise and counterclockwise. The point is that there arealways two. In this project the streams were called North and South indicatingthe direction from which they come. We can now find these streams by finding theroutes that traverse all decisions (see section 7.3), which are through-going and inone of the arterial directions.

For the arterial route from north, we look for a route which reaches the HerlevSygehus intersection from north and takes the throughgoing turning option N1T,the route must then pass through Hjortespringvej N2T and so forth until it takesthe final decision at Roskildevej N12T and exit the network.

Distances between intersections

One of the things we really need to assess the quality of coordinations is the dis-tances between the signal heads (stop-line) for adjacent intersections. The Vissimnetwork file contains information on which link or connector (denoted in common

4An exception is the one-way artery, which is trivial to coordinate, see section 8.1.

43

as road segment) each head is placed. By marking all road segments, which arepart of the arterial routes, we can deduce which signal heads give green light tovehicles travelling in the arterial direction.

The distance from signal controller 1 to 2 is then calculated by summing thelengths of road segments from the arterial signal heads at controller 1 to thearterial heads at controller 2 and so forth.

Arterial stages

This is also a good time to mention the notion of arterial stages. In optimizationof coordinations we need to know if a stage is meant for the arterial or for a minorroad. And if it is for the arterial, from which direction.

When we calculated distances between intersections on the arterial we learnedwhich signal heads provided for the artery. Since each head is a part of a signalgroup and a stage is a selection of groups, which are run simultaneously, we candeduce the arterial stages using these rules:

1. A stage is arterial ie. gives green light to the artery, if it contains an arterialgroup

2. A group is arterial if it contains an arterial signal head

3. And finally, as outlined previously, a signal head is arterial if is placed as ona link, which is marked as arterial

The reason I only require stages and groups to contain an arterial group andhead resp. is that a stage could contain purely arterial groups and then, maybe, agroup for left-turners but the stage is still arterial.

During group naming, when intersections are built, the designers usually prefixthe name of the main direction A and the side roads B. By extracting the definitionsof arterial groups as explained above we can see that not all road engineers hadthe same opinion:

Intersection Arterial Groups1 Herlev Sygehus A1, A22 Hjortespringvej A, At3 Herlev Bygade A, At4 Herlev Hovedgade B, Bt5 Mileparken A, At9 Fabriksparken A1, A210 Gammel Landevej A1, A211 Kindebjergvej A1, A212 Roskildevej B, Bt

Table 6: Groups for main traffic direction as perceived by traffic signal designer

44

As can be seen in Table 6 the perceived main directions for Herlev Hovedgadeand Roskildevej is to-and-fro the city of Copenhagen and western Sealand.

These descriptions conclude on the main issues I have solved in automatic datainsertion, manipulation and extraction for Vissim.

45

8 Optimization System

In this section I discuss optimization of coordination and describe the optimiza-tion method I later use to extend DOGS into address the coordination issues Iintroduced in section 3.

8.1 Coordination

Coordination along an arterial is fundamental in signal optimization. The ideal sit-uation for road users is the green wave, where upon arrival to the next intersectionthere will always be a green light.

Contemporary car engines consume less fuel in general when they are allowedto run at a constant RPM level so the travel experience as well as emmission levelsare improved under coordination.

There are also security aspects which indicate that coordination and green wavesare desirable since the human eye has difficulty in observing acceleration anddeceleration and coordination will cause less variation in speed.

In one-way coordination a signal controller emits a platoon of vehicles over aperiod of time, say from t1 to t2, where Tg = t2− t1 ie. the green time is indicativeof the number of vehicles that need to pass. To avoid stopping these vehicles at thenext signal the same amount of green time, Tg must be given to the approachingplatoon only offset in time by ∆f to represent the travel time of the platoon fromone signal to the next.

In fact, due to platoon dispersion, which depend mainly on the intersignal dis-tance and speeds, more than Tg green time must be allotted to the stage of thedownstream signal. It is also due to platoon dispersion that coordination is onlyrelevant for signals which are relatively close. In the experience of DRD the dis-tance should not exceed 800-900 m.

In perfect two-way coordination between two intersections the leading vehiclesin platoons of traffic in either direction must experience that the next signal switchto green before they reach the area in which they decide to brake for red.

In a common cycle-time based system [1] gives us:

tt = n · C2

Where tt is the travel time between the intersections, which is assumed to bethe same in both directions, C is the cycle time and n is an integer.

The travel time can be calculated as tt = L/v where L is the distance and v isthe speed by which road users travel between the intersections. By insertion weget:

C = 2 · L

n · v

46

This equation is quite constrained, however. For cycle time we require that itlies within a span of about 60 til 120 seconds based on recommendations fromDRD. If the cycle time is less, stage lengths become too short to reach past thequeue startup delay (about 4 vehicles), if more the minor roads experience longdelays and pedestrians and bicyclists may start to cross the road before the signalturns green.

In addition green waves usually span over more than two intersections whichmay have different distances and average speeds between them, all this makingit hard or impossible to find an integer n satisfying the constraints. Thus greenwaves are most easily established in one, main direction. It is possible to affectthe average speeds between intersections by changing the allowed speed-signs. Ifthis is not sufficient one might accept that the green wave is not perfect by, forinstance, prioritizing one direction over the other.

Priority can be given entirely to one direction or distributed by some weight,for instance based on the ratio of traffic in each direction. An obvious choice forthe first option would be for an artery with traffic between some suburbs and amajor city. In the morning full priority should be given in the direction towardsthe city when people go to work and opposite in the afternoon. A third alternativeis to provide a perfect progression band in one direction for a some ratio of time,corresponding to the ratios of traffic in either direction. For ringroad 3, which wassimulated in this project, there is no profound direction bias in the morning orafternoon traffic (see section 6) and a solution which weighs the green wave qualityaccording to direction ratio is preferred.

Why are we using common cycle schemes?

In this section I highlight the restrictions imposed when introducing two-way coor-dination between common cycle time signal controllers. Are there no alternatives,which are less strict and why aren’t they used in Denmark?

With a common cycle time comes fixed signal plans that give us full insight intothe operation of each signal controller. We can see exactly which signal groupsie. heads are green, red, yellow and amber at any given second. Furthermore, aspresented above, there exist expressions for the offset and cycle time which causescoordination.

Although traffic actuated green time extension schemes exist to make fine ad-justments, such as the ones used for bus priority, it is always necessary to takethe seconds from some other stage due to the common cycle time requirement.Likewise with stage skipping, you must always ”spend” C cycle seconds - and maynever spend more - before restarting the signal plan.

These restrictions makes it difficult for a computer system to obtain optimumperformance for the signal controllers and the observed / predicted traffic.

In addition, for large networks the enforcement of a common cycle time is in-appropriate. Consider a network which is so large that two disjoint arterials exist

47

(such as the case of ringroad 3 - Herlev and Glostrup). In this case it is unlikelythat a common cycle time will allow green waves to exist for both arterials eg.when the intersections of one arterial are more tightly spaced than in the other.Even though the arterials cannot be considered as a single arterial, they are notcompletely disjoint and will affect each other, if relatively close.

Stage based signals is an alternative to fixed signal plans where stages are queuedfor future execution along with a green time. There is no fixed order of the stagesand no fixed green time. This gives great flexibility for the computer system,however the problem is the plans cannot be written down in advance in terms ofC for human inspection and control. Instead they must be defined dynamicallyon the basis of a set of signal rules, which are implemented and respected by thecomputer system while adapting to the measured traffic conditions.

Here is a subset of rules such a system should implement:

Coordination Whenever the arterial stage for a signal is active from t1 to t2 thearterial stage of the downstream signal should be active from t1 +tt to t2 +ttwhere tt is the best estimate of travel time from signal 1 to signal 2.

Priority for the artery The green times for all stages in the direction of theartery must match the load on the arterial, respecting other rules.

Fairness to minor roads The queues for minor roads cannot exceed a prede-fined length nor must a vehicle wait more than a certain amount of time atany intersection to pass.

These rules - given proper parameters - are precise enough to be implementedin a computer program. The setting of parameters (for instance maximum queuelength for minor roads) is a difficult subject, which could require many train-ing hours for end-users. This was my impression about the Utopia/Spot systemwhich the municipality of Copenhagen (Vej & Park) had implemented for Cen-trum Forbindelsen - its was difficult for them to decide on which adjustsmentsshould be made, when the system acted up. However, many parameters can - andshould - be set automatically by repeated simulation with trial-and-error or theyare either easy enough to understand that rules of thumb and area specific insightis enough to make proper choices.

I believe that stage based signals and more centralized computer control ofarteries could be accepted and achieved if systems were more available and openas proposed above. The introduction of stage based signals would be a majorbreak with tradition in Denmark - and probably also in many other countries.Some systems exist, which use stage-based programs including RHODES [10] andUTOPIA/SPOT [12] mentioned previously.

Breaking tradition is always hard; this combined with the complexity of sucha system has compelled me to remain in the common cycle time world in thisproject. But as will be seen in the following sections, there are many ways toimprove the performance of signal controllers in spite of the the restrictions of C.

48

8.2 Manipulating speed

The first option, which is implemented in the search procedure (see section 8.7),is to improve coordination by affecting the speeds of road users. This is doneby adjusting speed signs since most motorists will obey these. The travel timebetween intersections, which largely determines the offset, could then be increasedor decreased by changing the speed signs.

In Figure 17 we can see how this works. In the before situation, platoons fromintersection i + 1 arrive too late and some experience red light. In the after situa-tion, the platoon is allowed to go faster and arrive entirely during the green timeof intersection i.

Figure 17: Changing speeds to obtain better coordination

Some considerations should be made in this respect. For instance we must ensurethat the speeds do not divert too much from the norm of the relevant type of road.In addition the number of speed changes, which a motorist travelling throughoutthe artery experience, must be minimized. And if speed changes do occur, it is agood idea to keep them small so that the speeds don’t go from 50 to 70 from onestretch of road to the next.

From a security perspective it might seem risky to not persist a common speedlevel through the artery. But considering that a change of speed might improvethe quality of the coordination, this problem is negated. This also applies to theadditional acceleration and deceleration since, if a green wave does not exist thevehicles must be stopped altogether at the red light causing even more acceleration.

49

The current infrastructure on ringroad 3 does not offer this fine-grained level ofadjustment but electronic speed signs are common practice nowadays and is, forinstance, used on the almost-parallel M3 to smoothen out queues.

8.3 Adjusting offsets

The individual signal offset is the traditional parameter for adjustment. The for-mulas presented earlier (section 8.1) can be used to establish one-way coordination,under the restrictions described, but two-way coordination is not solved so easily.

Traditional offline optimization systems such as TRANSYT often employs ablack-box simulator for fitness evaluation. However for offsets we can do withoutsuch overhead since we know exactly what we are looking for.

Basically the purpose of offsets is to properly align adjacent intersections intime such that a platoon emitted during the green time of intersection 1 is met bya green light at the adjacent intersection 2. A good estimate of the propagationtime of the platoon is the travel time tt1,2 = L/v where v is the average speedand L is the distance between the intersections and the green time displacement,∆fi,j , should match tt for all adjacent intersections i and j.

Figure 18: Changing offsets to obtain better coordination

50

We can change both the travel time, by changing speed signs, and also the greentime displacement by adjusting offsets. The consequences of changing an offsetscan be difficult to foresee, consider the example in Figure 18. From intersection jto i the platoon will arrive too early. We can increase the offset (delay the greenstart) of j but then we just reverse the situation. During all this, we must expectthat there are also signal controllers i− 1 and j + 1 to the left and right resp. of iand j, which must be in coordination with i and j.

8.4 Direction bias

In section 6 we looked at the detector data and traffic counts, which are usedto fit the simulation. We saw, among other things, that the northgoing traffic ishigher than southgoing. The optimization routine can be coherced into favoringone direction over the other - or be completely fair - by punishing deviations froma certain bias indicator.

To calculate the bias under current offsets we sum, in each direction of theartery, the deviations of the green time displacement to the expected travel time.The bias is thus the ratio of these sums and can be compared to the desired bias.The punishment for choosing settings, which result in deviation from the desiredbias, is a factor which grows exponentially with deviations in either direction.

By using such a weight the effect is that eg. perfect coordination in one direction- on the cost of coordination in the opposite direction - will be heavily punishedunder neutral bias (identity). This method can also be used to establish highlydirection specific coordinations when the bias approaches zero or infinity.

8.5 Closely distanced intersections

When the distance from an intersection to the upstream intersection is short (eg. ≤200m) coordination between the two intersections should receive special attentionfor two reasons:

• Since they are closely distanced queues cannot be very long before reachingback to the downstream intersection

• Travel time between the intersections is more predictable since the naturalvariations in speeds do not have much time to work in forming platoonsunlike for longer stretches of intermediate road, where the travel time spreadis higher

To favorize good coordination between closely distanced intersection I have cho-sen to use weights. I have opted to not statically classify what is close and whatis not but rather rank the distances of all coordinations between adjacent inter-sections and set the weight of imperfections accordingly. The effect is that flawsin coordinations between close intersections adds more to the total solution value

51

than for the same flaws at widely spaced intersections and thus the minimizationproblem solver is guided toward favorizing coordination between close intersec-tions.

8.6 Metaheuristic search

DRD has traditionally used TRANSYT to obtain coordination. TRANSYT em-ploys a genetic algorithm to finds its solutions but often it is necessary to manuallyadjust the offsets in order to obtain a good two-way coordination or to give pref-erence to some direction.

In this project the green wave concept has been formalized so that it is pos-sible to evaluate a proposal for offsets. This opens up for the application of ametaheuristic search procedure.

In this cycle-based approach the variable to be optimized is, of course, the offsetfor each signal controller. The signal controllers themselves operate under cyclicplans which are shifted in time according to the chosen offset. In addition all abovesuggestions for improved coordination are implemented.

Evaluation of solutions

For non-trivial arteries of size n ≥ 2 intersections there are n offsets to select andm = 2 · n− 2 coordinations5 and hence m speeds to choose, assuming speeds anddistances are not symmetric in the coordination from signal controller i to j andj to i. The selection of offsets and speeds is a minimization problem where thefitness value indicates the quality of a coordination:

min∑∀i,j

f(oi, oj , sij)

Where i and j are signal controllers, o is the offset vector, s contains speedsfor each coordination and f is the fitness function. The common cycle time isfundamental in the evaluation, but is not an optimization variable in this contextand is thus not shown here.

I previously hinted at various methods of evaluating the fitness of solutions tooffsets (and speeds). The most general approach is by using a simulator, howeverwe cannot use Vissim for this purpose, as mentioned in section 4, due to the factthat Vissim runs - at best - at 10-50 times realtime speed in the network used inthis project on contemporary machines. Using metaheuristics we need to evaluateseveral hundreds of solutions - and preferably more - per second and thus Vissimis far too slow for this purpose.

Since we only solve a subproblem of signal setting optimization, that is coordi-nation, we can exploit the nature of coordination and below are three suggestions,

5Since each signal controller has an outgoing coordination in each direction except at the ends,which have only one

52

listed in order of increasing complexity, I have found to evaluate solutions to co-ordination.

Green time displacement The simplest - but most constrained - evaluation cri-terion. As explained in Figure 3, section 3.5, the start of greens are aligned bychanging offsets so that the difference between travel time (given the averagetravel speed) and green time displacement is minimized for all coordinations:

|∆f − traveltime|

Green time displacement considering length of green times In the aboveevaluation method only green starts are considered. If the green durationsof the signal controllers being coordinated are not equally long it is possibleto introduce some flexibility, as can be seen in Figure 19.

Figure 19: Flexibility in green time displacement considering downstream greenduration

Since the duration of the downstream green time is longer, the green start(offset) of the first signal controller can be chosen more freely without sac-rificing coordination. This increases the size of the search space, since nowseveral solutions yield the same solution value due to the added flexibilityand allows the solver will be able to find better solutions.

Horizon evaluation The final suggestion is an extension of the previous scheme.It is suited for evaluating coordination for common cycle time, fixed signalplan controllers as well as stage based signal controllers.

For evaluation of a coordination from signal controller i to j in the contextof a time horizon H = hmin..hmax we examine each green band, which isemitted from i. Here a band is understood as an integer set of seconds in

53

the horizon from the green start to green end of a signal controller (see eg.Figure 19).

Given the distance and chosen speed in the coordination we can shift theband emitted from signal controller i, called b1, by the travel time, and,by comparing the resulting band to the equivalent band of the downstreamcontroller j, called b2, count how many seconds worth of green band, whichis not being ”let through”. Band b1 may be cut in several ways, if it is notfully compatible with b2 ie. the downstream controller does not provide agreen light for all traffic from the first controller:

• There is no overlap. This is the worst situation that happens when alltraffic from the first signal controller will be met by a red light at thedownstream controller. The fitness is the size of b1.

• When the beginning of the b1 lies before b2 the green start of the firstcontroller was too early or the downstream controller started its greentoo late. This will result in the stopping of the head vehicles from i andthe fitness is the size of b1 \ b2.

• Similar to the previous case but b1 extends beyond b2. Here the tail ofvehicles from i is cut off and the fitness is calculated same as before.

• When |b1| > |b2| there is a chance that both the head and tail of vehiclesfrom the first signal controller are cut since the downstream controllercannot offer enough green time to match that of the previous controller.In this case b1 \ b2 will result in two discontinued sequences of secondsin the horizon and the sum of the sizes of the sets constitute the fitnessvalue.

This evaluation method is generic since the only requirement is the greenbands in the horizon. This information can be extracted from all types ofsignal controllers, including stage-based controllers with memory of paststages. Pretimed signal controllers does not need memory of past stages tosupply information on green times and thus the overhead of this evaluationscheme is not necessary. I believe, however, that this option might be ofinterest in future works and have left it here for completeness.

In these evaluation methods no attempt is made to address preexisting queuesbefore the arrival of platoons from the downstream intersections. The dynamicnature (length) of these residual queues first mentioned in section 3.5 is not easilyhandled in a common cycle time signal setting scheme. It is possible to incorpo-rate a buffer for residual queue clearance by reducing the travel time used in thecalculations so that it is shorter than the actual travel time. However the problemof finding a sweet spot that does not waste green time while clearing queues wasbeyond the scope of this report.

During testing it was found that the simplest evaluation option, to regard onlygreen time displacements, gave the best results on average and this was chosen as

54

the primary evaluation mechanism in the offset optimization routine. I believe thatthe reduction in search space and complexity has increased the number of solutionstested per second to a level that the higher freedoms of the latter two solutionsdid not give an advantage over the simplest evaluation method. Unfortunately Idid not have time to properly test this hypothesis.

8.7 Simulated Annealing

In this section I describe the metaheuristic search routine, which was chosen:Simulated Annealing (SA). SA is a hill-climber with the ability to escape fromlocal optima ie. jump to another hill-top. It builds on ideas of the annealing fromthe metal industry where metals are heated and slowly cooled down to allow themolecules to arrange themselves so that the metal is as strong as possible.

This can be transferred to computer-aided optimization as taking a completelyrandom (ie. ”smeltered” solution) and slowly cool it (inspecting neighbor solu-tions) to find a good solution. Thus SA performs a randomized, converging searchin the entire search space (for offsets that is each combination of N mod C overthe intersections) looking for the possible best set of offsets without getting stuckwith the first-and-best solution it encounters.

The initial solution is chosen so that all offsets are zero6. SA then works itsway toward a better solution by examining neighbor solutions to the current one.A neighbor solution is found by incrementing or decrementing a single offset inthe current solution or changing the allowed speed between the intersections by5km/h.

The solutions to offsets are evaluated and compared in the context of the net-work and, if a neighbor is found to be better than the best solution found so far,it is adopted as the new encumbent. If the neighbor was not better it should bethrown away, but here SA avoids being caught in a local optima by with someprobability, related to the entropy difference of the current and neighbor solutions,keeping the neighbor solution regardless and work on from there. This characteris-tics of this probability function - which decreases as the search progress - is chosenmanually and so is subject to tuning.

Generally metaheuristics give no guarantee that an optimum solution will befound, but with proper tuning and fast data structures - so that at least a coupleof hundred solutions can be tested per second - it is my experience that theywill yield good solutions. The strengths of metaheuristics are that they can easilysupport any kind of constraint, take advantage of the structure of the problemand the running time is bounded only by the time available.

In this project I have developed data structures, which are fast enough to gen-erate the necessary iterations per second and can be used in various metaheuristicsearch schemes, not just simulated annealing.

6Alternatives are, for each controller, a random offset within the common cycle time (by somedistribution eg. uniform) or some pre-existing offsets eg. generated by TRANSYT

55

In my experience the keys to speed in metaheuristic search are delta-evaluationand to reduce the need for object instantiation.

8.7.1 Delta-evaluation

To evaluate a solution for offsets for sequentially adjacent signal controllers sc1

to scn we evaluate, in accordance to description in section 8.6, each coordination(sc1, sc2), (sc2, sc1)7 and so forth. This gives us a value for each coordination andwe then perform some kind of aggregation in order to obtain a single figure, thesolution value, which is augmented using the weighting methods described earlier.

Every time a neighbor solution is generated we normally immediately wantto evaluate it as well. This can be done by going through the routine describedabove, but we can also use delta-evaluation to speed up the evaluation, if we haveinformation on the structure of the problem.

A change in the offset of signal controller sci will affect the coordinations be-tween sci−1 and sci and also between sci and sci+1. Since we didn’t change theoffset sci−1 or sci+1 or any other offset, all coordinations but those mentioned willremain just as good - or bad - as before the offset change for sci. This is illustratedin Figure 20.

So, rather than evaluating every coordination again we may safely assume thatonly coordinations (sci−1, sci), (sci, sci−1) and (sci, sci+1), (sci+1, sci) need to bereevaluated.

We now need only to evaluate at most four coordinations8 to obtain the neighborsolution value. In total there are m = 2 · (n − 1) coordinations to evaluate andthus we exchange a linearly growing evaluation time (in the number of signalcontrollers) for a constant one and rough tests have shown that, even for smallnetworks, the savings in CPU time per iteration are in excess of a factor two, inspite of the extra overhead due to bookkeeping.

8.7.2 Neighbor solutions

In previous studies of metaheuristics, where the object oriented programmingmodel was completely adopted, it was found that the overhead of object instan-tiation, whenever a neighbor solution was generated, would result in tremendousconsumption of CPU time.

Instead I have minimized the need for copying information from a solution toits neighbor by introducing the dual methods change and undo_changes. Thepurpose of these methods is to allow a solution to temporarily take the form of itsneighbor and switch back to its former self, if requested. When the metaheuristic

7Coordinations between adjacent signal controllers need not be symmetrical. For instancethere might be a longer way in one direction that the other or, more likely, different speeds mightbe allowed

8Changing offsets for controllers in the ends of the arterial will only change the value of twocoordinations.

56

Figure 20: Local nature of coordinations. This illustrates the quality of coordina-tions between three signal controllers before and after changing the offset of themiddle controller. Notice that the coordinations between the outer controllers andsci−2 and sci+2 remain the same.

57

runs it will constantly ask for neighbor solutions but throw away most of them.This approach avoids much copying of solution attributes and at the same timethe details of the switching of identify are relayed to the solution object, ensuringproper encapsulation.

8.7.3 Bookkeeping outline

The change and undo_changes methods are closely integrated with delta-evaluation.The initial solution obviously cannot be delta-evaluated so, during full evaluation,the contribution from each coordination is noted.

When change is called a signal controller whose offset to change is chosen aswell as a new offset value. Next we find the affected coordinations and update thevalue of the solution by swapping the old contributions with the new ones, whenevaluated under the changed offset.

We must be ready to undo the changes we just made, so we track all thesechanges: which offset or speed we changed and by how much as well as the previouscontributions from the affected coordinations.

The extra time spent on bookkeeping is bounded by the number of affectedcoordinations, as explained previously and does increase the complexity of thecode by a great amount.

8.7.4 Parameter tuning

The performance of simulated annealing is highly dependent on the parameters,which are used. Parameter tuning involves finding the best possible set of param-eters.

The core parameters in the implemented simulated annealing are:

1. The starting temperature, which is an indication of the initial chance ofadopting solutions regardless of them being poor ie. the initial hill-jumpingcapability.

2. Alpha - or the cooling factor - is multiplied upon the current temperatureafter each iteration of simulated annealing. Alpha is in the range ]0; 1] sothat the temperature converges on zero (or remains at level, if alpha is 1)continuously reducing the probability of jumping away from (potential) localoptima.

Starting temperature and the cooldown factor work together to focus on thegood solutions without becoming too narrow sighted in the early iterations. Thereare no cut-in-stone definitions of good choices of starting temperature and alphavalues so they are chosen in parameter tuning.

Other parameters used in the optimization system are:

58

1. The proportion of change calls being diverted to changes in speeds andoffsets. When changing into a neighbor solution only one of these alternativesare chosen to respect the distinction between neighborhood and randomsolutions.

2. The threshold for the number of iterations before some action must be per-formed to escape from a dead end. The actions are themselves taken withsome probability and under certain conditions:

(a) Reheating causes the temperature to be increased to the starting tem-perature thus increasing future chances of adopting poor solutions andmake hill jumps. Reheating is only allowed if the temperature is belowthe starting temperature.

(b) Focus immediately returns to the encumbent solution and works itsway from there rather than continuing with the current solution, whichseems to be a dead end. Focus is only allowed if the value of the solu-tion, which is currently being explored, is not as good as that of theencumbent solution.

(c) Random restart is the most drastic jump-start alternative when thesolver has been stuck for a number of iterations. The offsets for everysignal controller are chosen randomly from within the common cycletime and - if speed changes are allowed - the speed for each coordi-nations is set to the default speed or default speed ±5km/h. Randomrestart is the only action which may actually land in a new encumbentsolution

In parameter tuning a large number of parameter combinations are tested andselected among according to the observed performance of simulated annealing. Ascan be seen above there are many parameter combinations to tune. I have selectedto tune only starting temperature, alpha and the jump-start action threshold. Thechoice among the possible jump-start actions is done with equal probability, re-specting the required conditions of reheating and focus, thus giving higher effectivechance of choosing random restart since it has no constraints unlike the other twooptions. The probability of changing an offset is set to 1.0 since speed changes wasnot relevant for the comparisons of section 9.

Tuning is usually done in the generic case where an array of ”problems” - inthis context arterials - are solved using all parameter combinations. Metrics suchas the average fitness and variance is compared and the parameters which gavethe best result are chosen. In our case there are only two arteries to test ie. Herlevand Glostrup. Furthermore we know that all critical runs will be done in theseareas and thus the parameter tuning is focused here.

In Figures (21a-21c) are the average fitness values of all 2-combinations of pa-rameters where lower is better. Each parameter combination was tested 10 timesand the fitness is the average of the final solution values.

59

(a) Jumpstart threshold values versus cooling fac-tors

(b) Starting temperatures versus jumpstartthreshold values

(c) Starting temperatures versus cooling factors

Figure 21: Effects of parameter variations

60

The running time of the solver was 0.1 seconds since convergence was quicklyachieved in the small networks available - Herlev and Glostrup. It was observedthat in at most 1 second simulated annealing with any parameter combinationwould have found almost identical solutions, indicating that an optimum solutionhas been found under the chosen evaluation scheme.

The parameter, which is most sensitive, seems to be alpha, which must not betoo high. In Figures 21c and 21a we see that alpha = 0.99 gives considerably worsefitness values and taking alpha down to 0.95 reduces the gap in fitness. The bestalpha value is 0.9 by a minor margin indicating that the best solutions are foundby - relatively quickly - decreasing the capability of accepting a worse-than-currentsolution.

The jumpstart threshold value is not very sensitive, which is seen in Figures 21aand 21b in that it is mainly the variation in the other parameter (cooling factorand starting temperature resp.) that causes changes of fitness. We can deduce fromthis that the jumpstart actions are not of high importance to simulated annealingin this problem.

The best starting temperature among the tested values is 100 again supportingthe claim that the solver desires to quickly zoom in on a specific region of thesearch space. Using this temperature and the best alpha value of 0.90, we see inFigure 22 the resulting cooling.

Figure 22: Cooling diagram for alpha 0.9 and starting temperature 100.

The final results of the parameter tuning, which was used in the final testing,can be seen in Table 7.

Effect of speed changes on fitness values

A neighbor solution is different by the speed in a coordination or by an offset andthus when creating the neighbor solution it must be decided which change to make.Maintaining the values of Table 7 except for speed and offset change probabilitiesI have performed another test to see the effect of making speed changes comparedto changing offsets.

61

Parameter ValueStarting temperature 100Cooling factor (alpha) 0.9Jumpstart threshold 75Reheat action probability 0.33Focus action probability 0.33Random restart action probability 0.33Offset change probability 1.0Speed change probability 0.0

Table 7: Parameters used for simulated annealing when generating offsets for thetests in section 9.

(a) All probabilities (b) All probabilities but zero

Figure 23: Probability of changing offsets and speeds

62

In Figure 23a we see the importance of offsets compared to the average speedsused between intersections. In Figure 23b we are zoomed in on the upper proba-bility levels for changing offsets and see that, although marginal, allowing speedchanges with probability 0.3 is preferable to not allowing speed changes at all.

63

9 Results

DRD and TTS has informed me that the DOGS system has not previously beentested in a simulation environment. The initial project proposal by Steen Lauritzenof DRD was to perform such a test in the Vissim simulation tool, described insections 4 and 7.

As part of this, tests were performed to discover the effect of bus priority and todiscover whether the uncontrolled green time displacements, which DOGS intro-duce during level change (see section 3.5), can be remedied by choosing cycle-timespecific offsets at level changes.

Only the morning period (7.00-9.00) was tested due time constraints and the factthat few differences in results were expected considering the similarities betweenmorning and afternoon (15.00-17.00) we saw in section 6.

The overall conclusion is that the combined performance of the network isreduced when DOGS is running. This means that the positive effect for traffictraversing the arterial does not outweigh the penalties for minor road traffic. Aperformance decrease for minor roads is acceptable since DOGS, for political rea-sons, was sanctioned to perform a capacity redistribution to favor traffic on theartery. However, tests show that this redistribution does not succeed in a convinc-ing way and even increases queue lengths and delays for arterial traffic in somecases.

In section 3.5 I discussed how DOGS inadvertently alters the coordination as itincreases the cycle time without compensating by implementing new offsets. Thetests involving Modified DOGS show that DOGS can be improved by choosingnew offsets when the cycle time is changed.

For bus priority, although it is only enabled for a few of the involved intersections- and that the implemented priority logic could be more aggressive - there is anoticable effect.

The rest of this section explains the test setup and test scenarios I used to arriveat these conclusions.

9.1 Test scenarios and setup

Below are the six scenarios, which were tested:

1. Basic program

2. Basic program with bus priority

3. DOGS

4. DOGS with bus priority

5. Modified DOGS

64

6. Modified DOGS with bus priority

In scenarios 1 and 2 DOGS is disabled effectively ignoring all detections (exceptfor buses in scenario 2) and thus the signals will remain in the basic, morningprogram (see appendix A). These scenarios represent the situation before DOGSwas introduced and as such constitute a comparison baseline.

In scenarios 3 and 4 DOGS is enabled and the capacity in the main directionis adjusted according to detector values as described in section 3. For Herlev bothscenarios are ”authentic” ie. they are being used today whereas for Glostrup onlyscenario 4 is authentic, since this area implements bus prioritization for 3 of 4intersections.

Finally scenarios 5 and 6 are DOGS with per-level offsets. These scenarios areincluded to show what happens when DOGS use incorrect offsets and to emphasizethat DOGS can be improved by using per-level offsets. The optimization routinedescribed in section 8 is used to precalculate cycle-time specific offsets for eachDOGS signal controller. Apart from the varying offsets, the only other differencebetween modified DOGS and original DOGS is that level changes cannot occurafter at least 3 cycles to allow the new offsets to come into effect. Original DOGSallows level change immediately after the previous level change is implementedand although, as the cycle time increase the longer the time between possiblelevel changes, levels may still change quite frequently, preventing any offsets fromcoming into effect.

As DOGS will naturally cause decreased performance for the minor roads itwas decided to split the dataset so that arterial and minor road traffic can bedistinguished.

Arterial traffic is defined as traffic which enters an intersection from north orsouth and makes a throughgoing motion rather than turning off the artery.

Minor road traffic consist of all traffic from east and west making left- and rightturns as well as crossing over the artery.

The results of the tests are measured by extracting average queue lengths andaverage delays for each intersection. These values are extracted using Vissim nodeevaluations, which are inserted for each of the twelve intersections.

All simulations were fitted to the traffic observed in the morning period from7.00 to 9.00 and run 10 times with different seeds. All graphs shown in this sectionare based on average values over the 10 runs.

9.2 DOGS

The first set of results compares DOGS to the basic program and DOGS withmodifications.

65

Average queue lengths

Average queue length indicates, in units of length (m), the number of vehicleswaiting to traverse an intersection ie. perform some turning motion, or go straightthrough, in the beginning of the green interval.

When queues become too long spillback occurs causing queues upstream. Inthe extreme event queues stretch back to the last upstream intersection blockingall entry into the intersection and effectively causes a gridlock. Another spillbacksituation, although less severe - but more common, is when vehicles waiting for aleft-turn fill up a dedicated left-turning lane and spill back into the main direction.

These situations are, of course, not desirable and thus the queue length is animportant factor to observe.

The way DOGS work we can make some speculations on how queues will form.The intention of DOGS is to improve capacity for the arterial traffic while sac-rificing some performance for the minor roads. So we expect queues to shortenfor the main direction and lengthen for the side roads. This is a slightly riskystrategy since the minor roads will usually have a short distance to the upstreamintersection.

(a) Arterial and crossing traffic (b) All traffic types

Figure 24: Average queue lengths. The graphs are the combined performance ofeach system in Herlev and Glostrup.

In Figures 24 we see the average queue lengths for all intersections with andwithout DOGS, in both cases with no bus priority (since bus priority may causeincreased queues and we want to save this aspect for later). The values behindthese graphs are the averages for all intersections.

In Figure 25 we see the total performance of each signal timing strategy perarea.

In Glostrup both DOGS variants outperform the basic program for arterialtraffic. Original DOGS delivers about 20% shorter queues on the artery thanmodified DOGS, which, in turn is about 10% better than the basic program. Forthe minor roads, again both DOGS variants increase the queue lengths for minorroads but modified DOGS has an edge over DOGS in this case.

66

Figure 25: Average queue lengths per area and traffic type

In Herlev DOGS actually increase the queue lengths for arterial traffic, com-pared to the baseline program, unlike modified DOGS, which bring a 25% advan-tage over the baseline. For the minor road traffic we again see that, on average, thistype of traffic experience longer queues however the difference is not as extremeas in Glostrup.

(Since intersections 6 to 9 are not controlled by DOGS the performance is almostidentical whether DOGS is enabled or not and are not shown for this reason.)

Figures 26a and 26b shows the average lengths of queues forming at arterial andminor road intersection approaches. We see that in the Herlev area only arterialtraffic at Herlev Hovedgade gains an advantage under DOGS. On the other handthe Herlev Sygehus intersection performs almost twice as bad as it did withoutDOGS.

Modified DOGS outperforms DOGS and the basic program in all cases butHjortespringvej, which deviates drastically from both DOGS and the basic pro-gram. In this case the optimization routine has chosen offsets, which yield goodaverage performance for the area, sacrificing Hjortespringvej.

DOGS performs better in all Glostrup intersections yielding from 10% at Kinde-bjergvej to almost 40% reduced queue length at Gammel Landevej compared to thebasic program. Here modified DOGS is outperformed by DOGS at Fabriksparkenand Gammel Landevej by a margin of almost 50%, and performs slightly worsethan the basic program. At Roskildevej DOGS and its modified sibling is at par,both outperforming the basic program. Modified DOGS excels, however, at Kinde-bjergvej.

Looking at the performance for minor road traffic, the promised ”sacrifices”are clearly visible. In Herlev there are slight increases of average queue lengthfor intersections Herlev Sygehus, Hjortespringvej and Mileparken. Herlev Bygade

67

(a) Arterial traffic

(b) Minor road traffic

Figure 26: Average queue length

68

suffer about 30% longer queues under DOGS control - but 20% less under modifiedDOGS control.

In Glostrup we see moderate performance variations for Fabriksparken andKindebjergvej. Roskildevej and Gammel Landevej are more affected, Roskilde-vej suffering more than 40% longer queues on average. In both cases modifiedDOGS is somewhat closer to the basic program, although still increasing queuelengths.

Average delays

We conclude the comparison of DOGS and modified DOGS to the basic programby looking at the average delays experienced in each area for each traffic type.

These are found in Figures 27 where we see the combined performance forintersections in the respective area versus time in seconds.

(a) Arterial traffic - Herlev (b) Arterial traffic - Glostrup

(c) Minor road traffic - Herlev (d) Minor road traffic - Glostrup

Figure 27: Average delays

In Vissim delays is the difference from the ideal travel time ie. no other vehicles(free flow speeds), no intersections to the actual travel time.

We expect that delays are correlated with the queue lengths observed previously.As such we are not surprised to see that modified DOGS is the best option in Herlevfor favoring arterial traffic. Original DOGS does seem to avoid the spike in averagedelays, which is seen in Herlev under the basic program around 8.00 (simulationsecond 3600) but otherwise is outperformed even by the basic program. For minor

69

road traffic the differences between each program are not profound, although it isclear, as expected, that the basic program is the best choice.

In Glostrup we see that both DOGS variants reduce delays for arterial trafficand that original DOGS, on average, outperforms the modified version. For minorroad traffic we see the same tendency as in Herlev, again the basic program favorsthis type of traffic the most whereas DOGS is hard on minor road traffic.

Improvements to DOGS

These analyses leave an impression of DOGS as a system which work as intended,at best and is detrimental to minor road traffic and - in some cases - even toarterial traffic as well.

The fact that minor road traffic suffers reduced performance is explained by theuneven distribution of the extra green-time, which comes as a result of increasedcycle times, in the ratio 4:1. What this means is that, when DOGS increase thecycle time by 10 seconds, the arterial phase will receive 8 extra seconds of green percycle but the minor road phase only receives 2 seconds. The case of performancefor arterial traffic is somewhat unexpected since DOGS increased capacity andrequires more study.

In the DRD report [8] Steen Lauritzen makes a note of the uncontrolled be-haviour of offsets when DOGS change level (section 5.8 in his report) and insection 3.5 I explained the problem.

During simulation it has been observed how the resulting poor coordinations areaffected by DOGS; more vehicles are stopped at the red light due to the increasedcapacity and queues become longer.

To test the theory that poor offsets are, in fact, the main cause of less-than-expected performance benefits - and even performance decreases for arterial aver-age delays and -queues I tested a modified version of DOGS with per-cycle-timeoffsets. The comparisons made in the section has shown us that improper offsetsare a likely cause of the performance difference and that DOGS can be improvedby adopting such per-level offset values. The offset values can be calculated byany offline optimization tool, such as the one I have developed, and I believe thechanges can easily be implemented in existing DOGS logic considering the easeby which I was able to change between original and modified DOGS in my VAPcodes (see appendix B).

In the Glostrup area we observe how modified DOGS is not able to matchthe performance of original DOGS, except for Kindebjergvej and Roskildevej.The optimization routine used to select the offsets for modified DOGS does notdistinguish between solutions where the coordination quality is focused in onesection of the artery and solutions where the coordination quality is fairly dividedover among all intersections. I did not have time to test this hypothesis either,but suspect the lack of this feature is what is causing the inferior performance ofmodified DOGS in Glostrup. My suggestion is that future work should focus onsuch an improvement.

70

9.3 Cycle times

In Figures 28 are the cycle times chosen between 7 and 9 in the simulation.

(a) DOGS Herlev (b) DOGS Glostrup

(c) Modified DOGS Herlev (d) Modified DOGS Glostrup

Figure 28: Cycle times.

We see that the modifications made to DOGS reduces the eagerness to changelevels. This is an effect of the mandatory rule for modified DOGS to remain atleast 3 cycles in each level, whereas DOGS is free to change the cycle time up ordown after each level has been implemented.

This explains why modified DOGS is generally kinder on the minor roads thanDOGS. Modified DOGS will remain longer at each level, allowing not only the newoffsets to take effect but also the increased traffic, which caused the level change,to traverse the artery, before changing to the next level. An attempt to implementthis form of level smoothening was thought into the DOGS system by the lower-and upper threshold values. However it appears that more drastic means shouldbe taken to ensure that this form of hysteria does not occur - an obvious approachis simply to require level burn-in times, such at the 3 cycles I chose for modifiedDOGS.

9.4 Throughput

DOGS attempts to increase throughput ie. the number of vehicles which traversea section of road in a time interval. The observed effect of a throughput increase is

71

a smoothening of traffic peaks when more vehicles are let through due to increasedcycle times. As we saw earlier, for instance in Figure 27a, the DOGS system iscapable of smoothening the average delays durings peaks of traffic (in the figure,around simulation second 3600 ie at 8-o’clock).

I have performed throughput measurements using Vissim link evaluations to seethat the capacity increase, which DOGS brings by theoretical fact, also makes animpression on the vehicles.

The final Figures 29 show the throughput of DOGS and modified DOGS for theroad segments connecting Herlev Hovedgade and Herlev Bygade. This area waschosen since Herlev Hovedgade is considered the major bottle-neck of the Herlevarea of the artery.

(a) Herlev Bygade to Herlev Hovedgade

(b) Herlev Hovedgade to Herlev Bygade

Figure 29: Throughput over time from Herlev Bygade to Herlev Hovedgade (top)and the reverse direction (bottom)

Comparing the throughput of both DOGS versions we see that DOGS is capableof increasing the throughput, as expected. It appears that there is no immediatecorrelation between the other measurements performed on queue lengths and de-lays.

72

9.5 Bus priority

The final analysis is for the bus priority for the three Glostrup intersections, Fab-riksparken, Gammel Landevej and Kindebjergvej.

Bus priority is a questionable feature for a crowded artery, such as ringroad 3.Unless there exist dedicated bus lanes, buses wait in queue to cross an intersectionalong with all other vehicles. For the three intersections with bus priority there isno such dedicated lane.

In Vissim it is possible to see delays per vehicle type, which in this analysis isused to filter out delays for buses. In Figures 30 we see how the various systemsaffects bus delays with and without bus priority.

(a) Basic program

(b) DOGS

(c) Modified DOGS

Figure 30: Delay for buses.

It is clear that the bus priority logic makes a considerable positive differencein bus delay reduction in spite of the heavy traffic, which ringroad 3 faces. In

73

addition, the logic could be more aggressive by detecting waiting buses shorteningthe non-bus stages so that the stage, which will serve the bus, can start earlier.

I have selected to compare each program variant with and without bus prioritysince this is the natural scenario, when any of the systems are chosen, and onemust decide whether to use bus priority or not.

Figure 31: Comparison of bus delay in the three systems with bus priority enabled.

In Figure 31 we see the different effects of bus priority in the three systems. AtFabriksparken the systems are almost identical using bus priority. Modified DOGSis the worst performer at Gammel Landevej and Kindebjergvej, in line with theobservations previously made for modified DOGS in Glostrup, since buses arevehicles sharing road segments with cars and trucks and bus delay will thus becorrelated to the delay of other vehicle types. The bus prioritized versions oforiginal DOGS and the basic program take turn in being best at reducing delaysfor Gammel Landevej and Kindebjergvej respectively.

The overall conclusion on bus priority is that it seems to have a positive effectin all systems and that modified DOGS - as it was tested - is the worst performer.The question whether to favor original DOGS over the modified version for thisreason on this account is left to politicians.

74

10 Conclusion

The DOGS system for arterial traffic optimization was implemented in the Herlevand Glostrup sections of ringroad 3 in response to the expansion of the nearby M3due to expected traffic increases as an effect of the work.

DOGS was developed by Danish Technical Traffic Solution (TTS) and basicallyuses threshold values to determine a proper common cycle time so that increasein load on the artery automatically causes the capacity to increase when the extragreen is primarily given to the stages accomodating arterial traffic.

However DOGS was never tested in a simulation environment, such as the (inDenmark de-facto) Vissim simulation tool - a microsimulator well-suited for testingcomplex situations and signal controller configurations. The Danish Road Direc-torate (DRD) suggested that DOGS be tested in Vissim to discover if the systemdelivers the necessary offload, when traffic is diverted onto ringroad 3.

In this report are the results of such a test performed for the morning period inthe two disjoint DOGS areas, Herlev and Glostrup, consisting of 5 and 4 intersec-tions, respectively.

Area Delay Queue lengthDOGS Herlev 100 109Modified DOGS Herlev 71 77DOGS Glostrup 77 73Modified DOGS Glostrup 88 91

Table 8: Indexed summary results for average delays and queue lengths experiencedfor arterial traffic. The performance of the basic program is at index 100. (Loweris better.)

The results show that DOGS, although capable of smoothening the peak trafficperiods and increase the througput, does not convicingly improve on arterial trafficconditions when compared to the preexisting, pretimed signal plans. We also seethat there is a major performance difference in Glostrup and Herlev.

The reason for the poor performance in Herlev, as previously speculated byDRD, is traced back to the uncontrolled change in green time displacements,when the cycle time is increased without choosing new offsets. This result is foundby comparing DOGS with a modified version, which does implement optimizedoffsets for each common cycle time.

Original DOGS, however, outperforms the modified version in Glostrup. Mod-ified DOGS performs well in Glostrup for Kindebjergvej and Roskildevej, but isoutperformed even by the pretimed signal program on Fabriksparken and Gam-mel Landevej, indicating that the offset optimizer may have chosen offsets thatfavors coordination between some controllers over others, undermining the overallperformance.

The optimization routine used to generate these offsets is based on the meta-heuristic optimization scheme simulated annealing, a hill climber with the ability

75

to escape local optima. The evaluation criterion is directly derived from the sameanalysis, which raised questions concerning the coordination properties of DOGSie. the green time displacement.

Accepting the de-facto status of Vissim the system extracts information from theactual Vissim network, wherever possible, reducing the need to redesign a networkin another tool eg. TRANSYT. Such information include signal controller stagesand signal timing plans and distances between intersections.

Features, which have been built into the optimization system, include prioritiz-ing coordination for a specific direction bias, achieving better coordination throughspeed adjustments for individual stretches between intersections and emphasis ongood coordination between close-by intersections. The system makes use of ran-dom restarts, focus and reheatings to effectively traverse as much of the searchspace as possible.

In addition to testing DOGS, the bus priority, which is present for the threenorthern-most intersections of Glostrup, was tested and found to give a consistentreduction in average delay for the buses using the arterial.

10.1 Future works

I strongly believe per-level offsets should be further considered in the next revisionof DOGS. In conjunction average speeds between intersections and hence traveltimes used in the optimization should be considered. It is safe to assume thatthe traffic conditions, which trigger each DOGS level, can be mapped upon acertain set of travel times. I expect the travel time to increase in some proportionto the proper DOGS level and this information can be used to further improvecoordination, as the results of this study assumed fixed travel times.

The selection of per-level offsets can be done by any optimization tool, includingTRANSYT. However should the simulated annealing approach of this project beselected, it is recommended that the issue of decreased performance in Glostrup(compared to original DOGS) be investigated and solved. I believe the issue couldpossibly be solved by introducing a punishment in the evaluation method so thatsolutions that have great coordination among some intersections, while sacrificingothers, cannot become the encumbent.

It is my hope that existing and future DOGS installations will incorporate someof the suggestions for improvement, which I have presented in this report. DOGS isa good mix of pretimed and adaptive signal control, allowing much infrastructureand signal design to remain unchanged while enabling an artery to respond tochanging traffic demands during medium to heavy loads.

The studies presented in this report tests a busy albeit normal morning situa-tion and does not include an investigation of the DOGS ”panic function” ie. thecapability of DOGS to adopt very high cycle times when eg. an accident occurson M3. It is expected that the benefit of DOGS will increase greatly, compared tothe basic morning program, when such situations occur.

76

The optimization routine was implemented in the interpreted language Ruby.Although the implemention will try more than 1000 combinations per second ona 2.0 GHz CPU, it is expected that an implementation in a compiled language,such as C# or Java will lead to even better solutions with regards to CPU time.

In the evaluation methods mentioned in section 8.6 no attempt is made toclear residual queues before the arrival of platoons from upstream intersections.Although I believe it is difficult to find a good solution to this issue under acommon cycle time signal scheme, future works should review the issue.

As mentioned the implemented system is capable of optimizing coordinationsby changing speeds as well as offsets. Dynamic speed signs are becoming more andmore widespread with the introduction of LED technology, for instance on M3,and simulation studies should be performed to test whether road users will be ableto respond to such speed signs indicating recommended speed for green wave.

During an interview with DRD and TTS it was explained that the traffic fromminor roads is neglected in the determination of the correct DOGS level. Interestwas expressed in seeing the effect of increasing the number of detectors used so thatthe system is not ”blind” to minor road traffic, as the downstream intersectionson the minor road approaches are usually close by and the approaches easily spillback.

10.2 Perspective

In this report I mostly discussed signal optimization for arterials. For a city suchas Copenhagen it makes sense to expand the area of optimization such that wholegrids were optimized for greens and coordination simultaneously.

A benefit of considering very large networks at the same time is the possibility oftraffic redirection. This is in part possible for small-scale arterial optimization bydenying progression at the upstream intersection until the downstream controllershave cleared their queues. In larger scale networks, if it is detected - or predicted -that an artery is, or will be, congested under current flow conditions it is sensibleto redirect some traffic onto alternative routes.

Redirecting traffic using traffic signals is a subtle technique which has not re-ceived much research yet, though it could pose more efficient than current traf-fic information systems, which inform road users of congestions and alternativeroutes, but allows them to ignore the advice.

When choosing an adaptive signal control system for a large area I believe itis important to choose among the preexisting systems (eg. SCOOT, Utopia/Spot,OPAC) rather than developing a new system, tailored for Danish road conditions.In this project I was given the opportunity to develop a system to find offsets forgood coordinations, though for non-educational purposes one should always preferwell-known tested off-the-shelf products. The reason is that such systems have seenmuch action in actual implementations abroad and there are no ”developmentcosts” that may run amok nor any incalculable time frame. The DRD should be

77

an information hub for municipalities and road committees and make analysesand recommendations on adaptive systems such that at most a handful intelligenttraffic light management systems are used in Denmark.

78

References

[1] Vejtrafik (in danish), chapter 5 Signalregulerede kryds by Steen M. Lauritzen.Polyteknisk Forlag, 1994. 8.1

[2] Search Methodologies. Springer, 2006.

[3] D. Bretherton, M. Bodger, and N. Baber. Scoot - the future [urban trafficcontrol]. Road Transport Information and Control, 2004. RTIC 2004. 12thIEE International Conference on, pages 301–306, 2004. 2.2

[4] Jerome Sacks Byungkyu “Brian” Park, Nagui M. Rouphail. Assessment ofa stochastic signal optimization method using microsimulation. TechnicalReport Number 110 at National Institute of Statistical Sciences, 2000. 4

[5] E. Dijkstra. Go to statement considered harmful. pages 27–33, 1979. 5

[6] Rune Andreas Harsløf Holst. Macro-,meso- and micro simulation - a com-parision of three dta softwares. Master’s Thesis at Centre for Traffic andTransport, Technical University of Denmark, 2007. 4

[7] J.L. Kim, J.-C.S. Liu, P.I. Swarnam, and T. Urbanik. The areawide real-timetraffic control (artc) system: a new traffic control concept. IEEE Transactionson Vehicular Technology, 42(2):212–224, 1993.

[8] Steen Merlach Lauritzen. Evaluation of dogs. Danish Road Directorate, 2004.[in Danish]. 3.4, 3.5, 9.2

[9] Randy Machemehl Michael Shenoda. Development of a phase-by-phase,arrival-based, delay-optimized adaptive traffic signal control methodologywith metaheuristic search. Research Report SWUTC, 2006. 2.2

[10] P. Mirchandani and L. Head. A real-time traffic signal control system: archi-tecture, algorithms, and analysis. Transportation Research Part C: EmergingTechnologies, 2001. 2.2, 8.1

[11] Farhad J. Pooran Nathan H. Gartner and Christina M. Andrews. Implemen-tation of the opac adaptive control strategy in a traffic signal network. IEEEintelligent Transportation Systems Conference Proceedings, 1995. 2.2

[12] Peter Christensen Peter Backer Hansen, Lars Bo Frederiksen. Signalreguler-ing pa centrumforbindelsen med utopia/spot (in danish). Dansk Vejtidsskrift,2004. 8.1

[13] COWI Traffic Planning. Samordning af signalanlæg pa ring 3 og pa roskildevej- transyt-beregninger. COWI, 2002. [in Danish]. 1, 19

[14] Cowi AS Steen Lauritzen, Vejdirektoratet; Lars Jørgensen. Samfundsbespar-elser ved bedre signalanlæg. Dansk Vejtidsskrift, 2008. [in Danish]. 1

79

[15] Martin Treiber, Ansgar Hennecke, and Dirk Helbing. Congested traffic statesin empirical observations and microscopic simulations. Physical Review E,62:1805, 2000. 1.1

[16] Andreas Warberg. Green wave traffic optimization. Technical report, Tech-nical University of Denmark, 2007. 1.1, 2.2

[17] J.G. Wardrop. Some theoretical aspects of road traffic research. ProceedingsInstitute of Civil Engineering, 1952. 4

80

A Signal Plans

Below are the signal plans used during simulation in all scenarios. The planscorrespond to non-traffic actuated morning plans supplied by DRD. The columnDOGS Priority is major when the group is part of an arterial stage, minor whenpart of the minor road stage and none if no DOGS should not adjust the greenextension of this group.

Group Red End Green End DOGS PriorityA1 78 42 MajorA2 78 42 Major

A1V 46 56 NoneA2V 46 56 NoneB1 60 72 MinorB2 60 72 Minor

Table 9: Herlev Sygehus

Group Red End Green End DOGS PriorityA 78 48 MajorAt 78 48 MajorB1 52 73 MinorB2 52 73 Minor

Table 10: Hjortespringvej

Group Red End Green End DOGS PriorityA 78 50 MajorB 54 72 Minor

Table 11: Herlev Bygade

81

Group Red End Green End DOGS PriorityA 78 20 MinorB 28 62 Major

BV 28 74 None

Table 12: Herlev Hovedgade

Group Red End Green End DOGS PriorityA 78 38 MajorAt 78 34 MajorB1 54 71 MinorB2 54 71 MinorAv 39 50 NoneAtv 39 50 NoneAth 44 50 NoneB1h 44 51 None

Table 13: Mileparken

Group Red End Green End DOGS PriorityA1 78 40 MajorA2 78 40 MajorB 47 71 Minor

A2h 49 78 None

Table 14: Fabriksparken

Group Red End Green End DOGS PriorityA1 78 48 MajorA2 78 26 MajorB 54 71 MinorBt 54 71 MinorBh 30 71 Minor

Table 15: Gammel Landevej

Group Red End Green End DOGS PriorityA1 78 50 MajorA2 78 38 MajorB 56 72 Minor

Table 16: Kindebjergvej

82

Group Red End Green End DOGS PriorityA 78 27 MinorAt 78 15 MinorAH 17 34 MinorB 34 60 MajorBt 34 60 MajorBv 34 74 Major

Table 17: Roskildevej

83

B VAP Codes

Below I have inserted examples of the master and slave VAP codes. As they areautomatically generated and hence very similar it is not very interesting - or rain-forest preserving - to reprint them all. The examples I display are from the Herlevarea ie. DOGS master in Herlev and for slave I selected Herlev Hovedgade.

The other slaves are generated using the signal plans I received from DRD(non-traffic actuated versions) as seen in appendix A.

B.1 Example: DOGS master

In Table 18 are the detector values used.

Area Detectors Type Bound ThresholdsHerlev 3 4 13 14 Counting Lower 17 28 39 50 61 72 83 94Herlev 3 4 13 14 Counting Upper 20 33 46 59 72 85 98 111Herlev 3 14 Occupancy Lower 8 17 35 51 65 74 86 94Herlev 3 14 Occupancy Upper 11 29 45 58 70 80 92 96Glostrup 1 2 5 8 9 10 11 12 13 14 Counting Lower 19 33 47 61 75 89 103 117Glostrup 1 2 5 8 9 10 11 12 13 14 Counting Upper 23 38 53 68 83 98 113 128Glostrup 1 2 5 8 9 10 11 12 13 14 Occupancy Lower 15 35 44 54 67 76 81 90Glostrup 1 2 5 8 9 10 11 12 13 14 Occupancy Upper 20 41 53 62 78 84 90 96

Table 18: DOGS detectors and threshold values.

Occupancy detector thresholds are in percent and counting thresholds in numberof vehicles (per cycle). The threshold values are listed for increasing DOGS levelsalthough (up to 8) although DOGS is level-capped at 5. The activation- anddeactivation bounds are coincident with the first upper- and lower bound valueresp. The detector id sequence is restarted in each area so although detectors 13and 14 appear in Glostrup as well as Herlev they are different detectors.

DOGS and modified DOGS are only different in the number of levels which mustbe maintained before switch to the next. This is enforced by testing a variableCYCLES_AT_LEVEL against the required value and thus only the original DOGSmaster is reprinted here.

1 /∗ This program was automat i ca l l y generated by v i s s im i n t e r a c t i o n . rb on 19−06−2008 ∗/2 PROGRAM DOGS MASTER ; /∗ ∗/34 CONST5 BASE CYCLE TIME = 80 ,6 DN = 3 ,7 DS = 14 ,8 SMOOTHING FACTOR = 0 .5 ,9 ENABLE CNT = 20 ,

10 DISABLE CNT = 17 ,11 ENABLE OCC = 11 ,12 DISABLE OCC = 8 ,13 DOGS FORCE DISABLE = 0 ;1415 /∗ Express ions ∗/16 c y c l e s e c := T;17 c y c l e s e c p l u s 1 := c y c l e s e c + 1 ;18 CURRENT CYCLE TIME := BASE CYCLE TIME + 10 ∗ DOGS LEVEL;19

84

20 S000 : IF NOT cy c l e s e c THEN /∗ Perform i n i t i a l i z a t i o n ∗/21 S001 : DN CNT := 0 ; DS CNT := 0 ; CYCLES AT LEVEL:= 0 ; /∗ Keeps Vissim from nagging ∗/22 S002 : SetT (1) ; /∗ Star t the c l ock ∗/23 GOTO PROG ENDE24 END;25 S003 : Marker put (1 ,DOGS LEVEL) ; Marker put (2 , c y c l e s e c ) ;26 S004 : IF c y c l e s e c < CURRENT CYCLE TIME THEN27 S005 : SetT ( c y c l e s e c p l u s 1 ) ;28 ELSE29 S006 : SetT (1) ;30 S007 : PREV CYCLES AT LEVEL := CYCLES AT LEVEL;31 S008 : CYCLES AT LEVEL := PREV CYCLES AT LEVEL + 1 ;32 END;33 S009 : IF T <> 1 THEN34 S010 : GOTO PROG ENDE;35 ELSE /∗ read and c l e a r d e t e c t o r s every cyc l e ∗/36 /∗ When DOGS LEVEL > 0 the count ing per iod i s extended along with the green time37 and the counts from the de t e c t i on s must be co r r e c t ed be f o r e comparing

to the cnt th re sho ld va lues ∗/38 S011 : DOGS CORRECTION FACTOR := BASE CYCLE TIME / CURRENT CYCLE TIME;39 S012 : DN CNT := DOGS CORRECTION FACTOR ∗ (DN CNT + SMOOTHING FACTOR ∗ ( Rear ends (DN)

− DN CNT) ) ;40 S013 : DS CNT := DOGS CORRECTION FACTOR ∗ (DS CNT + SMOOTHING FACTOR ∗ ( Rear ends (DS)

− DS CNT) ) ;41 S014 : DN OCC := Occup rate (DN) ∗ 100 ; /∗ Occupied ra t e percentage ∗/42 S015 : DS OCC := Occup rate (DS) ∗ 100 ;43 /∗ Measuring on detec to r s , which are used to determine cur rent dogs l e v e l ∗/44 S016 : D3 OCC := Occup rate (3) ∗ 100 ;45 S017 : D14 OCC := Occup rate (14) ∗ 100 ;46 S018 : D3 CNT := Rear ends (3) ;47 S019 : c re (3 ) ;48 S020 : D4 CNT := Rear ends (4) ;49 S021 : c re (4 ) ;50 S022 : D13 CNT := Rear ends (13) ;51 S023 : c re (13) ;52 S024 : D14 CNT := Rear ends (14) ;53 S025 : c re (14) ;54 S026 : IF (CYCLES AT LEVEL >= 2) THEN55 S027 : CYCLES AT LEVEL := 0 ; /∗ a l low f a l l through to dogs l e v e l change ∗/56 ELSE57 GOTO ADJUST LEVEL; /∗ make sure the new l e v e l i s f u l l y implemented ∗/58 END;59 END;60 /∗ Enable dogs i f north or south bounds are reached . I f dogs i s enabled but we are below

enable−bounds , keep dogs enabled until the lower thre sho ld i s reached ∗/61 S028 : DOGS ENABLED := ( (DN CNT >= ENABLE CNT) OR (DS CNT >= ENABLE CNT) AND (DN OCC >=

ENABLE OCC) OR (DS OCC >= ENABLE OCC) ) OR DOGS ENABLED AND ((DN CNT > DISABLE CNT)OR (DS CNT > DISABLE CNT) AND (DN OCC > DISABLE OCC) OR (DS OCC > DISABLE OCC) ) ;

62 S029 : IF DOGS FORCE DISABLE OR NOT DOGS ENABLED THEN63 S030 : DOGS LEVEL := 0 ;64 ELSE65 S031 : IF DOGS LEVEL = 0 THEN66 S032 : IF (D3 OCC > 11) OR (D14 OCC > 11) OR (D3 CNT > 20) OR (D4 CNT > 20) OR (

D13 CNT > 20) OR (D14 CNT > 20) THEN67 S033 : NEW DOGS LEVEL := 1 ;68 END;69 END;70 S034 : IF DOGS LEVEL = 1 THEN71 S035 : IF (D3 OCC > 29) OR (D14 OCC > 29) OR (D3 CNT > 33) OR (D4 CNT > 33) OR (

D13 CNT > 33) OR (D14 CNT > 33) THEN72 S036 : NEW DOGS LEVEL := 2 ;73 END;74 S037 : IF (D3 OCC < 17) AND (D14 OCC < 17) AND (D3 CNT < 28) AND (D4 CNT < 28) AND (

D13 CNT < 28) AND (D14 CNT < 28) THEN75 S038 : NEW DOGS LEVEL := 0 ;76 END;77 END;78 S039 : IF DOGS LEVEL = 2 THEN79 S040 : IF (D3 OCC > 45) OR (D14 OCC > 45) OR (D3 CNT > 46) OR (D4 CNT > 46) OR (

D13 CNT > 46) OR (D14 CNT > 46) THEN80 S041 : NEW DOGS LEVEL := 3 ;81 END;82 S042 : IF (D3 OCC < 35) AND (D14 OCC < 35) AND (D3 CNT < 39) AND (D4 CNT < 39) AND (

D13 CNT < 39) AND (D14 CNT < 39) THEN83 S043 : NEW DOGS LEVEL := 1 ;84 END;85 END;86 S044 : IF DOGS LEVEL = 3 THEN87 S045 : IF (D3 OCC > 58) OR (D14 OCC > 58) OR (D3 CNT > 59) OR (D4 CNT > 59) OR (

D13 CNT > 59) OR (D14 CNT > 59) THEN88 S046 : NEW DOGS LEVEL := 4 ;89 END;90 S047 : IF (D3 OCC < 51) AND (D14 OCC < 51) AND (D3 CNT < 50) AND (D4 CNT < 50) AND (

D13 CNT < 50) AND (D14 CNT < 50) THEN91 S048 : NEW DOGS LEVEL := 2 ;92 END;93 END;94 S049 : IF DOGS LEVEL = 4 THEN

85

95 S050 : IF (D3 OCC > 70) OR (D14 OCC > 70) OR (D3 CNT > 72) OR (D4 CNT > 72) OR (D13 CNT > 72) OR (D14 CNT > 72) THEN

96 S051 : NEW DOGS LEVEL := 5 ;97 END;98 S052 : IF (D3 OCC < 65) AND (D14 OCC < 65) AND (D3 CNT < 61) AND (D4 CNT < 61) AND (

D13 CNT < 61) AND (D14 CNT < 61) THEN99 S053 : NEW DOGS LEVEL := 3 ;

100 END;101 END;102 S054 : IF DOGS LEVEL = 5 THEN103 S055 : IF (D3 OCC > 80) OR (D14 OCC > 80) OR (D3 CNT > 85) OR (D4 CNT > 85) OR (

D13 CNT > 85) OR (D14 CNT > 85) THEN104 S056 : NEW DOGS LEVEL := 6 ;105 END;106 S057 : IF (D3 OCC < 74) AND (D14 OCC < 74) AND (D3 CNT < 72) AND (D4 CNT < 72) AND (

D13 CNT < 72) AND (D14 CNT < 72) THEN107 S058 : NEW DOGS LEVEL := 4 ;108 END;109 END;110 S059 : IF DOGS LEVEL = 6 THEN111 S060 : IF (D3 OCC > 92) OR (D14 OCC > 92) OR (D3 CNT > 98) OR (D4 CNT > 98) OR (

D13 CNT > 98) OR (D14 CNT > 98) THEN112 S061 : NEW DOGS LEVEL := 7 ;113 END;114 S062 : IF (D3 OCC < 86) AND (D14 OCC < 86) AND (D3 CNT < 83) AND (D4 CNT < 83) AND (

D13 CNT < 83) AND (D14 CNT < 83) THEN115 S063 : NEW DOGS LEVEL := 5 ;116 END;117 END;118 S064 : IF DOGS LEVEL = 7 THEN119 S065 : IF (D3 OCC > 96) OR (D14 OCC > 96) OR (D3 CNT > 111) OR (D4 CNT > 111) OR (

D13 CNT > 111) OR (D14 CNT > 111) THEN120 S066 : NEW DOGS LEVEL := 8 ;121 END;122 S067 : IF (D3 OCC < 94) AND (D14 OCC < 94) AND (D3 CNT < 94) AND (D4 CNT < 94) AND (

D13 CNT < 94) AND (D14 CNT < 94) THEN123 S068 : NEW DOGS LEVEL := 6 ;124 END;125 END;126 END;127 /∗|NEW DOGS LEVEL − DOGS LEVEL | = 0 or 1 ∗/128 ADJUST LEVEL: IF DOGS LEVEL <> NEW DOGS LEVEL THEN /∗ DOGS l e v e l changes are implemented

by increments o f +− 5 seconds per cy c l e ∗/129 S069 : IF DOGS LEVEL < NEW DOGS LEVEL THEN130 S070 : DOGS LEVEL STEP := DOGS LEVEL + 0 . 5 ;131 ELSE132 S071 : DOGS LEVEL STEP := DOGS LEVEL − 0 . 5 ;133 END;134 S072 : DOGS LEVEL := DOGS LEVEL STEP;135 END136 PROG ENDE: .

B.2 Example: DOGS slave

For the slaves again the only difference between original and modified DOGS isthat the offset is set per DOGS level in modified DOGS slaves. In Table 19 arethe offset values used in when simulating DOGS and 20 are the per-level offsetsused in simulation of modified DOGS.

86

Area # Intersection OffsetHerlev 1 Herlev Sygehus 74Herlev 2 Hjortespringvej 44Herlev 3 Herlev Bygade 72Herlev 4 Herlev Hovedgade 50Herlev 5 Mileparken 20Glostrup 9 Fabriksparken 12Glostrup 10 Gammel Landevej 52Glostrup 11 Kindebjergvej 65Glostrup 12 Roskildevej 60

Table 19: Morning program offset values from TRANSYT report [13]

Area # Intersection 1 2 3 4 5Herlev 1 Herlev Sygehus 45 55 38 48 58Herlev 2 Hjortespringvej 72 82 65 75 85Herlev 3 Herlev Bygade 0 0 83 93 103Herlev 4 Herlev Hovedgade 35 35 8 8 8Herlev 5 Mileparken 27 27 0 0 0Glostrup 9 Fabriksparken 30 0 0 60 0Glostrup 10 Gammel Landevej 0 60 60 0 60Glostrup 11 Kindebjergvej 72 42 42 102 42Glostrup 12 Roskildevej 67 37 37 97 37

Table 20: Precalculated offset values for morning program in each DOGS level

87

1 /∗ This program was automat i ca l l y generated by v i s s im i n t e r a c t i o n . rb on 19−06−2008 ∗/2 PROGRAM herlevhovedgade ; /∗ ∗/34 CONST5 STAGE1 TIME = 20 ,6 STAGE2 TIME = 32 ,7 STAGE3 TIME = 8 ,8 BASE CYCLE TIME = 80 ,9 OFFSET = 50 ;

1011 DOGS LEVEL := Marker get (1 ) ;12 TIME := Marker get (2 ) ;13 stage1 end := STAGE1 TIME + 2 ∗ DOGS LEVEL;14 stage2 end := STAGE2 TIME + 8 ∗ DOGS LEVEL + i s l (1 , 2 ) + stage1 end ;15 stage3 end := STAGE3 TIME + i s l (2 , 3 ) + stage2 end ;1617 S000 : IF NOT SYNC THEN18 S001 : IF (TIME − 1) = OFFSET THEN19 S002 : SYNC := 1 ;20 END;21 GOTO PROG ENDE22 END;23 S003 : C := BASE CYCLE TIME + 10 ∗ DOGS LEVEL;24 S004 : t l o c := (TIME − OFFSET) % C + 1 ;25 S005 : SetT ( t l o c ) ;26 S006 : IF stga (1) THEN27 S007 : IF T = stage1 end THEN28 IS1 2 : I s (1 , 2 ) ;29 END30 END;31 S008 : IF stga (2) THEN32 S009 : IF T = stage2 end THEN33 IS2 3 : I s (2 , 3 ) ;34 END35 END;36 S010 : IF stga (3) THEN37 S011 : IF T = stage3 end THEN38 IS3 1 : I s (3 , 1 ) ;39 END40 END;41 S012 : IF stga (1) AND (T > ( s tage1 end + i s l ( 1 , 2 ) ) ) AND ((T + 6) < s tage2 end ) THEN42 GOTO IS1 2 ;43 END;44 S013 : IF stga (2) AND (T > ( s tage2 end + i s l ( 2 , 3 ) ) ) AND ((T + 6) < s tage3 end ) THEN45 GOTO IS2 3 ;46 END47 PROG ENDE: .

B.3 Example: bus priority

Finally here is an example of the basic program for Fabriksparken with bus priority.1 /∗ This program was automat i ca l l y generated by v i s s im i n t e r a c t i o n . rb on 14−06−2008 ∗/2 PROGRAM fabr ik sparken ; /∗ ∗/34 CONST5 STAGE1 TIME = 40 ,6 STAGE2 TIME = 22 ,7 STAGE3 TIME = 3 ,8 BUSDETN = 101 ,9 BUSDETS = 102 ,

10 BUSDETN END = 201 ,11 BUSDETS END = 202 ,12 BASE CYCLE TIME = 80 ,13 OFFSET = 12 ;1415 DOGS LEVEL := Marker get (1 ) ;16 TIME := Marker get (2 ) ;17 stage1 end := STAGE1 TIME + 8 ∗ DOGS LEVEL + 10 ∗ BUS PRIORITY;18 stage2 end := STAGE2 TIME + 2 ∗ DOGS LEVEL + i s l (1 , 2 ) + stage1 end − 10 ∗ BUS PRIORITY;19 stage3 end := STAGE3 TIME + i s l (2 , 3 ) + stage2 end ;2021 S000 : IF NOT SYNC THEN22 S001 : IF (TIME − 1) = OFFSET THEN23 S002 : SYNC := 1 ;24 END;25 GOTO PROG ENDE26 END;27 S003 : C := BASE CYCLE TIME + 10 ∗ DOGS LEVEL;28 S004 : t l o c := (TIME − OFFSET) % C + 1 ;29 S005 : SetT ( t l o c ) ;30 S006 : IF Detect ion (BUSDETN) THEN31 S007 : BUS FROM NORTH := 1 ;

88

32 END;33 S008 : IF Detect ion (BUSDETS) THEN34 S009 : BUS FROM SOUTH := 1 ;35 END;36 S010 : IF Detect ion (BUSDETN END) THEN37 S011 : BUS FROM NORTH := 0 ;38 END;39 S012 : IF Detect ion (BUSDETS END) THEN40 S013 : BUS FROM SOUTH := 0 ;41 END;42 S014 : IF stga (1) THEN43 S015 : IF (BUS PRIORITY = 1) AND (NOT BUS FROM NORTH) AND (NOT BUS FROM SOUTH) AND (T

< ( s tage1 end − 10) ) THEN44 S016 : BUS PRIORITY := 0 ;45 END;46 S017 : IF (BUS FROM NORTH OR BUS FROM SOUTH) AND (BUS PRIORITY = 0) THEN47 S018 : BUS PRIORITY := 1 ;48 END;49 END;50 S019 : IF stga (1) THEN51 S020 : IF T = stage1 end THEN52 IS1 2 : I s (1 , 2 ) ;53 END54 END;55 S021 : IF stga (2) THEN56 S022 : IF T = stage2 end THEN57 IS2 3 : I s (2 , 3 ) ;58 S023 : IF BUS PRIORITY = −1 THEN59 S024 : BUS PRIORITY := 0 ; /∗ two cy c l e s o f bus p r i o r i t y has f i n i s h e d and the

donor r e c e i v ed i t s compensation ∗/60 END;61 END62 END;63 S025 : IF stga (3) THEN64 S026 : IF T = stage3 end THEN65 IS3 1 : I s (3 , 1 ) ;66 S027 : IF BUS PRIORITY = 1 THEN67 S028 : BUS PRIORITY := −1; /∗ subt rac t the extra bus time in next cy c l e ∗/68 END;69 END70 END;71 S029 : IF stga (1) AND (T > ( s tage1 end + i s l ( 1 , 2 ) ) ) AND ((T + 6) < s tage2 end ) THEN72 GOTO IS1 2 ;73 END;74 S030 : IF stga (2) AND (T > ( s tage2 end + i s l ( 2 , 3 ) ) ) AND ((T + 6) < s tage3 end ) THEN75 GOTO IS2 3 ;76 END77 PROG ENDE: .

C Source Code

Below are the codes I programmed for this project.

C.1 Utilities and data management

Listing 1: aggregation.rb1 # Sc r i p t s f o r c l e a n i n g d e t e c t o r data from t e c h n i c a l t r a f f i c s o l u t i o n23 r equ i r e ’ csv ’4 r e qu i r e ’ time ’5 r equ i r e ’ const ’67 # re t u rn s a Time o b j e c t g i v en8 # an t u p l e w i th t h e da t e ( eu fmt ) and t ime (24 h ) r e sp .9 def parse t ime eu date t ime tup l e

10 Time . parse eu date t ime tup l e . j o i n ( ’ ’ )11 end1213 def ge t dat e t ime obj14 t ime obj . s t r f t ime EU date fmt15 end1617 def get t ime t ime obj18 t ime obj . s t r f t ime Time fmt19 end20

89

21 def ge t da t e t ime t ime obj22 t ime obj . s t r f t ime ”#{EU date fmt} #{Time fmt}”23 end2425 ##26 # the c s v f i l e s ( t a e l l i n g ∗ . c s v ) c on t a i n s d e t e c t e d v e h i c l e coun t s27 # from the l a s t c oup l e o f minutes .28 # rows shou l d be read s e q u e n t i a l l y and d e t e c t i o n s a g g r e g a t e d u n t i l29 # Reso l u t i on seconds or more have pas sed30 def c r e a t e agg r c s v f i l e3132 reader = CSV. open ( c s v f i l e , ’ r ’ , ’ ; ’ )33 header = reader . s h i f t # sk i p pa s t t h e header3435 det names = header [ 2 . . −1 ]3637 # pre−l o op i n i t i a l i z a t i o n38 row = reader . s h i f t39 prev acc t ime = parse t ime ( row [ 0 . . 1 ] )40 f i r s t r ow t ime = prev acc t ime − ( prev acc t ime . sec + prev acc t ime . min∗

MINUTES PER HOUR)4142 row = reader . s h i f t43 num det = row . length−2 # number o f d e t e c t o r s44 acc = [ 0 ] ∗ num det # f i l l array w i th z e r o s4546 o f f s e t = Res47 until row . empty?4849 cu t o f f = f i r s t r ow t ime + o f f s e t ∗ 605051 while not row . empty? and parse t ime ( row [ 0 . . 1 ] ) <= cu t o f f52 # accumulate d e t e c t i o n s53 row [ 2 . . − 1 ] . each with index do |d , i |54 acc [ i ] += d . t o i55 end5657 row = reader . s h i f t58 end5960 # on ly r e t u rn the entry , i f someth ing was accumulated61 i f acc . any ?{|d | d > 0}62 # cr e a t e a mapping from d e t e c t o r names to d e t e c t e d count63 a c c d e t e c t s = {}64 ( 0 . . num det−1) . each {| i | a c c d e t e c t s [ det names [ i ] ] = acc [ i ]}65 yield cu to f f , a c c d e t e c t s66 end6768 # empty t h e accumula t ion b u f f e r69 acc = [ 0 ] ∗ num det70 o f f s e t += Res71 end7273 reader . c l o s e74 end7576 puts ”BEGIN”7778 In fo = {79 ’ Herlev ’ => { : d i r => Her l ev d i r , : southgoing => [ ’D3 ’ , ’D4 ’ , ’D6 ’ , ’D8 ’ , ’D15 ’ ]} ,80 ’ Glostrup ’ => { : d i r => Glost rup d i r , : southgoing => [ ’D02 ’ , ’D08 ’ , ’D010 ’ , ’D012 ’ , ’D014 ’

]}81 }8283 # The header row o f t h e e x c e l da ta s h e e t ; more rows are appended l a t e r84 rows = [ [ ’ Date ’ , ’Time ’ , ’DoW’ , ’ Detector ’ , ’ D i r e c t i on ’ , ’ Detected ’ , ’ Area ’ ] ]8586 for area , i n f o in In f o87 puts ” Proces s ing DOGS det e c to r data from #{area}”88 Dir . chd i r i n f o [ : d i r ]8990 time det map = Hash . new({})9192 for c s v f i l e in Dir [ ’ t a e l ∗ . csv ’ ]93 p r in t ” Proces s ing #{ c s v f i l e } : ”94 prev date = ni l95 c r e a t e agg r ( c s v f i l e ) do | time , d e t e c t i on s |96 # e x t r a c t t h e o l d hash and merge w i th t h e new s e t o f d e t e c t i o n s97 # assume t h e r e are no d e t e c t o r name c l a s h e s98 time det map [ time ] = time det map [ time ] . merge ( d e t e c t i on s )99 cur date = ge t dat e ( time )

100 i f cur date != prev date101 pr in t ”#{cur date } ”102 prev date = cur date103 end104105 #break i f c u r d a t e == ’14−11−2007 ’106 end

90

107 puts108 end109110 # f i n d the en t r y w i th t h e most d e t e c t o r names111 det names = time det map . va lues .max {| dets1 , dets2 | dets1 . l ength <=> dets2 . l ength } .

keys112113 for t in time det map . keys . s o r t114 #put s ”#{ g e t d a t e t im e ( t ) } : #{Time det map [ t ] . i n s p e c t }”115 map t = time det map [ t ]116117 # sk i p e n t r i e s , which do not have data f o r a l l d e t e c t o r s118 next i f map t . l ength < det names . l ength119 date , time , dow = get date ( t ) , ge t t ime ( t ) , t . s t r f t ime ( ’%a ’ )120 det names . each do | dn |121 rows << [ date , time , dow , dn , i n f o [ : southgoing ] . i n c lude ?(dn) ? ’S ’ : ’N ’ ,map t [ dn ] ,

area ]122 end123 end124 end125126 t o x l s ( rows , ’ data ’ , ”#{Data dir}aggr . x l s ” )127128 puts ”END”

Listing 2: const.rb1 # Generic and p r o j e c t s p e c i f i c c on s t an t s .2 # U t i l i t y methods .34 r equ i r e ’ rubygems ’5 r equ i r e ’ s eque l ’67 CSPREFIX = ”DBI :ADO: Provider=Microso f t . Jet .OLEDB. 4 . 0 ; Data Source=”89 r equ i r e ”#{ARGV. f i r s t | | ’ t h e s i s ’} s e t t i n g s ” # load p r o j e c t s p e c i f i c c on s t an t s

1011 Tempdir = ENV[ ’TEMP’ ] . gsub ( ”\\” , ’ / ’ )12 Default network = F i l e . j o i n ( Vis s im dir , Network name )1314 Time fmt = ’%H:%M:%S ’15 EU date fmt = ’%d−%m−%Y’16 Res = 15 # r e s o l u t i o n in minutes o f i n pu t s17 MINUTES PER HOUR = Seconds per minute = 601819 RED,YELLOW,GREEN,AMBER = ’R ’ , ’Y ’ , ’G’ , ’A ’2021 # re v e r s e t h e t ype map so t h a t compos i t i on numbers po i n t to t h e t e x t d e s c r i p t i o n22 # assume 1−to−1 mapping23 Type map rev = [ ]24 Type map . each {|k , v | Type map rev [ v ] = k}2526 # s t r i n g s and compos i t i on numbers f o r ca r s and t r u c k s ( bu s e s are hand led s e p a r a t e l y27 Car s and t ruck s s t r 1 = [ : cars , : t rucks ]28 Cars and trucks = Type map .map{|k , v | Car s and t ruck s s t r 1 . i n c lude ?( k ) ? v : ni l } − [ ni l ]2930 EPS = 0.0131 INPUT SCALING = 1.032 ANNUAL INCREASE = 1.005 # used in inpu t g en e r a t i on f o r s c a l i n g33 BASE CYCLE TIME = 80 # seconds34 DATAFILE = F i l e . j o i n ( Base dir , ’ data ’ , ”data . x l s ” ) # main data f i l e c on t a i n i n g counts , sgp

’ s , you name i t35 CS = ”#{CSPREFIX}#{DATAFILE} ; Extended Prope r t i e s=\”Excel 8 . 0 ;HDR=Yes ;IMEX=1\””36 ENABLE VAP TRACING = { : master => false , : s l av e => fa l se } # wr i t e t r a c e s t a t emen t s in vap

code ?3738 # the f o l l o w i n g i s used in inpu t and rou t e g en e r a t i on39 # deno t e s t h e ∗end∗ t imes o f data c o l l e c t i o n i n t e r v a l s eg 7 :00 to 7 :1540 #PERIOD START, PERIOD END = ’15 : 15 ’ , ’ 17 : 00 ’41 PERIOD START, PERIOD END = ’ 7 :15 ’ , ’ 9 :00 ’42 START TIME = Time . parse (PERIOD START) − 15 ∗ 60 # fo r coun t ing seconds43 END TIME = Time . parse (PERIOD END)4445 r equ i r e ’ dbi ’46 r equ i r e ’ f i l e u t i l s ’47 r equ i r e ’ win32ole ’4849 DB = Sequel . dbi CS50 LINKS = DB[ : ’ [ l i n k s $ ] ’ ]51 BUSES = DB[ : ’ [ buses$ ] ’ ]5253 def exec query sq l , conn s t r = CS54 DBI . connect ( conn s t r ) do | dbh |55 return dbh . s e l e c t a l l ( s q l )56 end57 end58 # In d i c a t e s from which d i r e c t i o n t r a f f i c comes from eg . North

91

59 def g e t f r om d i r e c t i o n ( fromsc , to s c )60 ( ( fromsc . number < to s c . number ) ? ARTERY[ : sc1 ] : ARTERY[ : sc2 ] ) [ : f r om d i r e c t i on ]61 end62 def t o t ex ( table , u s e r op t s = {})63 d e f au l t op t s = { : c ente r => true , : s e p c o l s => true , : c o l a l i g n => ’ l ’ , : row sep => ”\ r

”}64 opts = de f au l t op t s . merge ( u s e r op t s )65 l i n e s = [ ’\begin{ t ab l e } [ ht ] ’ ]66 l i n e s << ’\ c en t e r i ng ’ i f opts [ : c ente r ]67 headers = tab l e . f i r s t68 l i n e s << ”\\begin{ tabu lar}{#{headers .map{opts [ : c o l a l i g n ] } . j o i n ( opts [ : s e p c o l s ] ? ’ | ’

: ’ ’ ) }}”69 heade r s i n bo ld = headers .map{| header | ( header . ni l ? or header . t o s . empty ?) ? ’ ’ : ”\\

t ex tb f{#{header}}”}70 l i n e s << heade r s i n bo ld . j o i n ( ’ & ’ ) + ’ \\\\ \\ h l i n e ’71 tab l e [ 1 . . − 1 ] . each {| row | l i n e s << row . j o i n ( ’ & ’ ) + ’ \\\\ ’}72 l i n e s << ’\end{ tabu lar } ’73 l i n e s << ”\\ capt ion{#{opts [ : capt ion ]}} ” i f opts [ : capt ion ]74 l i n e s << ”\\ l a b e l{#{opts [ : l a b e l ]}} ” i f opts [ : l a b e l ]75 l i n e s << ’\end{ t ab l e } ’76 l i n e s . j o i n ( opts [ : row sep ] )77 end78 # cr e a t e an array o f l i n e a r l y spaced numbers79 def l i n s p a c e ( from , step , l im i t )80 a = [ ]81 from . step ( l im i t , s tep ) {| x | a << x}82 a83 end84 class Time85 def to hm86 s t r f t ime ”%H:%M”87 end88 end89 def numbers ( from , step , count )90 l i n s pa c e ( from , step , ( count − 1) ∗ s tep + from )91 end92 def maybe?93 rand < 0 .594 end95 def t o x l s rows , sheetname , x l s f i l e9697 begin98 exc e l = WIN32OLE : : new( ’ Excel . Appl i cat ion ’ )99 wb = exce l . Workbooks . Open( x l s f i l e )

100101 datash = wb. Sheets ( sheetname )102103 datash . c e l l s . c l e a r104105 # a l l−in−one i n s e r t i o n106 datash . range ( ”a1” ) . r e s i z e ( rows . s i z e , rows [ 0 ] . s i z e ) . Value = rows107108 datash . Range ( ”a1” ) . Au t o f i l t e r109 datash . Rows (1) . Font . Bold = true110 datash . Columns . Auto f i t111112 wb . Save113 rescue Exception => e114 r a i s e ( e , ” Fa i l ed to wr i t e #{rows . s i z e } rows and #{rows . f i r s t . s i z e } columns to sheet

’#{sheetname } ’ o f e x c e l f i l e ’#{ x l s f i l e } ’ ” )115 ensure116 exc e l . D i sp layAle r t s = fa l se # avo id e x c e l nag to save book117 exc e l . Quit118 end119 end120 class Array121 def sum ; i n j e c t {| a , x | x+a} ; end122 def mean ; sum . t o f / s i z e ; end123 def var iance124 mu = mean125 i n j e c t {| a , x | ( x − mu) ∗∗2 + a}126 end127 def dev i a t i on128 Math . sq r t ( var iance )129 end130 def sample n=1 ; ( 0 . . . n ) . c o l l e c t { s e l f [ Kernel : : rand ( s i z e ) ] } ; end131 def rand ; s e l f [ Kernel : : rand ( s i z e ) ] ; end132 def copy133 i n j e c t ( [ ] ) {| a , e l | a << ( e l . r e spond to ? ( : copy ) ? e l . copy : e l )}134 end135 end136137 class Point138 a t t r r e ad e r : x , : y , : z139 def i n i t i a l i z e x , y , z = 0 .0140 @x, @y, @z = x , y , z141 end142 def t o s

92

143 ”#{@x} #{@y}”144 end145 # c a l c u l a t e t h e d i s t a n c e between s e l f and po i n t146 def d i s tance point147 dx = @x − point . x148 dy = @y − point . y149 Math . sq r t (dx∗∗2 + dy∗∗2)150 end151 end152153 class Class154 def new ! (∗ args , &block )155 # make sure we have arguments156 i f args and args . s i z e > 0157 # i f i t ’ s not a Hash , perform a normal ”new”158 return new(∗ args , &block ) unless Hash === args . l a s t159160 i n i t = args . pop161162 # cr e a t e t h e o b j e c t and s e t i t s f i e l d s163 obj = new(∗ args , &block )164 i n i t . each {|k , v | obj . i n s t a n c e v a r i a b l e s e t ( ”@#{k}” , v )}165 else166 # no args , j u s t do a normal ”new” wi th any b l o c k pas sed167 obj = new(&block )168 end169 obj170 end171 end172173 class Hash174 def s e l f . new nested hash175 new{|h , k | h [ k ] = new(&h . d e f au l t p r o c ) }176 end177 def copy178 h = Hash . new( d e f au l t p r o c )179 each {|k , v | h [ k]=v}180 h181 end182 def +(h)183 copy . merge (h . copy )184 end185 def r e t a i n k ey s ! (∗ keys )186 d e l e t e i f {|k , | not keys . i n c lude ? k}187 end188 end189190 class Range191 def over lap ? other192 inc lude ?( other . f i r s t ) or other . i n c lude ?( f i r s t )193 end194 end195196 class I n t eg e r197 def f a c t198 return 1 i f s e l f <= 1199 ( 1 . . s e l f ) . i n j e c t { | i , j | i ∗ j }200 end201 end202203 i f FILE == $0204 puts Pro j ec t205 end

Listing 3: dtu tests.rb1 TESTQUEUE = [2 { : testname => ’DOGS with bus p r i o r i t y ’ , : dogs enabled => true ,3 : bu sp r i o r i t y => true } ,4 { : testname => ’DOGS’ , : dogs enabled => true } ,5 { : testname => ’ Bas ic program with bus p r i o r i t y ’ , : bu sp r i o r i t y => true } ,6 { : testname => ’ Bas ic program ’ } ,7 { : testname => ’ Modif ied DOGS with bus p r i o r i t y ’ , : dogs enabled => true ,8 : u s e c a l c u l a t e d o f f s e t s => true , : b u s p r i o r i t y => true } ,9 { : testname => ’ Modif ied DOGS’ , : dogs enabled => true ,

10 : u s e c a l c u l a t e d o f f s e t s => true}11 ]1213 c a l c u l a t e d o f f s e t s = {} # c o n t r o l l e r => dogs l e v e l => o f f s e t1415 # check i f any t e s t needs p r e c a l c u l a t e d o f f s e t s16 i f TESTQUEUE. any ?{| t e s t | t e s t [ : u s e c a l c u l a t e d o f f s e t s ]}17 r equ i r e ’ greenwave eval ’1819 o f f s e t d a t a = [ [ ’ Area ’ , ’ S i gna l Cont ro l l e r ’ , ’DOGS Level ’ , ’ O f f s e t ’ ] ]2021 [ [ : her lev , ( 1 . . 5 ) ] , [ : g los t rup , ( 9 . . 1 2 ) ] ] . each do | area , c o n t r o l l e r r a n g e |

93

22 c o n t r o l l e r s = v i s s imnet . c o n t r o l l e r s . f i n d a l l {| sc | c o n t r o l l e r r a n g e === sc . number}2324 c o n t r o l l e r s . each {| sc | c a l c u l a t e d o f f s e t s [ sc ] = {}}2526 coords = pa r s e c oo rd i na t i on s ( c o n t r o l l e r s , v i s s imnet )2728 # p r e c a l c u l a t e new o f f s e t s f o r each v a l i d dogs l e v e l29 ( 0 . .DOGS MAX LEVEL) . each do | dog s l e v e l |30 pr in t ” Ca l cu la t ing o f f s e t s in #{area} f o r DOGS l e v e l #{dog s l e v e l } : ”31 s o l u t i on c and i da t e s = [ ]32 cyc l e t ime = BASE CYCLE TIME + DOGS TIME ∗ dog s l e v e l33 SOLVER ITERATIONS. t imes do | i | # ge t a bunch o f s o l u t i o n s to choose from f o r each

c y c l e t ime34 pr in t ” #{SOLVER ITERATIONS − i }”3536 problem = CoordinationProblem . new( coords ,37 : cy c l e t ime => cyc l e t ime ,38 : d i r e c t i o n b i a s => nil ,39 : change p robab i l i t y => { : speed => 0 . 0 , : o f f s e t => 1 .0} )4041 r e s u l t = SimulatedAnneal ing . new( problem , SOLVER TIME,42 : s tar t temp => 100 .0 ,43 : alpha => 0 .90 ,44 : no improvement act ion thresho ld => 7545 ) . run4647 s o l u t i on c and i da t e s << r e s u l t [ : s o l u t i o n ]48 end4950 puts5152 b e s t s o l u t i o n = so l u t i on c and i da t e s . min53 b e s t s o l u t i o n . o f f s e t . each do | sc , o f f s e t |54 c a l c u l a t e d o f f s e t s [ sc ] [ d o g s l e v e l ] = o f f s e t55 o f f s e t d a t a << [ area . t o s . c a p i t a l i z e , sc . name , dog s l e v e l , o f f s e t ]56 end57 end58 end59 t o x l s ( o f f s e t d a t a , ’ o f f s e t s ’ ,RESULTS FILE)60 end6162 i f TESTQUEUE. any ?{| t e s t | t e s t [ : bu sp r i o r i t y ]}63 insert measurements # bus t r a v e l t im e measurements64 end

Listing 4: results.rb1 # c o l l e c t r e s u l t s from v i s s im r e s u l t s . mdb f i l e23 r equ i r e ’ const ’4 r e qu i r e ’ v i s s im ’5 r equ i r e ’ v i s s im rou t e s ’67 class NodeEvaluation8 a t t r r e ad e r : testname , : node , : r e s u l t s , : f roml ink , : t o l i nk , : t s t a r t , : tend9 def i n i t i a l i z e name , node , f roml ink , to l ink , t s t a r t , tend , r e s u l t s

10 @testname = name11 @node = node12 @fromlink , @tol ink = fromlink , t o l i n k13 @tstart , @tend = t s t a r t , tend14 @resu l t s = r e s u l t s # hash o f r e s u l t t y p e s to t h e i r v a l u e s15 end16 def <=>(othernodeeva l )17 (@node == othernodeeva l . node ) ? ( @testname <=> othernodeeva l . testname ) : (@node <=>

othernodeeva l . node )18 end19 end20 class NodeEvals < Array2122 # NodeEva luat ion r e q u i r e s a v i s s im network i n s t an c e to o b t a i n23 # the node e v a l u a t i o n and combine r e s u l t s w i th t h e d e c i s i on s , which are passed24 def i n i t i a l i z e v i s s im = Vissim . new25 @vissim = vis s im26 end2728 # columns o f t h e v i s s im r e s u l t s da t a ba s e to t h e29 # names ∗we∗ want to use ! Note t h i s i s a30 # array o f t u p l e s s i n c e we want to p r e s e r v e t h e order31 COLS TO HEADERS = [32 [ ’ avequeue ’ , ’ Average Queue ’ ] ,33 [ ’maxqueue ’ , ’Max Queue ’ ] ,34 [ ’ d e l a y a l l ’ , ’ Average Delay ’ ] ,35 [ ’ f u e l c on s ’ , ’ Fuel Consumption ’ ] ,36 # [” d e l a y 2 ” , ’Car & Truck Delay ’ ] ,37 # [” d e l a y 1 0 03 ” , ’Bus Delay ’ ]38 ]39

94

40 NODEEVALSQL = ”SELECT41 NODE,42 FROMLINK,43 TOLINK,44 TSTART,45 TEND,46 #{COLS TO HEADERS.map{|k , h | ”AVG(#{k }) As #{k }”} . j o i n ( ’ , ’ ) }47 FROM NODEEVALUATION48 WHERE MOVEMENT <> ’ A l l ’49 GROUP BY NODE, FROMLINK, TOLINK, TSTART, TEND”5051 # ca l l e d a f t e r each v i s s im t e s t has been repeated a number o f t imes52 de f e x t r a c t r e s u l t s testname , t e s t d i r5354 f o r row in exec query (NODEEVALSQL, ”#{CSPREFIX}#{F i l e . j o i n ( t e s t d i r , ’ r e s u l t s . mdb ’ )

} ; ” )5556 # f i n d the t r a v e l t im e en t r y in order to ga in a d d i t i o n a l i n s i g h t57 node = @vissim . nodes . f i nd {|n | n . number == row [ ’NODE’ ]}58 fromnum , tonum = row [ ’FROMLINK’ ] , row [ ’TOLINK ’ ]59 f roml ink = @vissim . l i n k ( fromnum)60 t o l i n k = @vissim . l i n k ( tonum)6162 r e s u l t s = {}63 COLS TO HEADERS. each {|k , h | r e s u l t s [ k ] = row [ k ]}6465 s e l f << NodeEvaluation . new( testname , node , froml ink , to l ink , row [ ’TSTART’ ] , row [ ’

TEND’ ] , r e s u l t s )66 end67 end68 def to a6970 i n s e c t i n f o = DB[ ”SELECT name , number FROM [ i n t e r s e c t i o n s $ ] ” ] . a l l7172 rows = [ [ ’Node ’ ,73 ’ Test Name ’ ,74 ’ I n t e r s e c t i o n ’ ,75 ’From ’ ,76 ’ Motion ’ ,77 ’ T r a f f i c Type ’ ,78 ’ Period Star t ’ ,79 ’ Period End ’ ,80 ∗COLS TO HEADERS.map{|k , h | h } ] ]8182 for nodeeval in s o r t {| ne1 , ne2 | ne1 . node <=> ne2 . node}83 f rom l ink , t o l i n k = nodeeval . f roml ink , nodeeval . t o l i n k84 begin85 route = @vissim . f i n d r ou t e ( f rom l ink , t o l i n k )8687 # e x t r a c t t h e d e c i s i o n s which are t r a v e r s e d f i r s t and l a s t on t h i s r ou t e88 d e c i s i o n = route . d e c i s i o n s . f i r s t | |89 r a i s e ( ”Expected a route from #{f r om l ink } to #{t o l i n k } t r a v e r s i n g a dec i s i on ,

found : #{route . t o v i s s im }” )9091 i n t e r s e c t i o n = i n s e c t i n f o . f i nd {| r | r [ : number ] == de c i s i o n . i n t e r s e c t i o n } [ : name ]9293 # ’ a r t e r i a l ’ t r a f f i c e x i t s in e i t h e r end o f t h e a r t e r i a l94 # ’ minor road ’ t r a f f i c comes from the minor roads and c r o s s or turn in on95 # the a r t e r y96 t r a f f i c t y p e = i f ARTERY DIRECTIONS. inc lude ?( d e c i s i o n . f r om d i r e c t i on ) and

de c i s i o n . turning mot ion == ’T ’97 ’ A r t e r i a l ’98 else99 ’Minor road ’

100 end101 rescue102 i n t e r s e c t i o n = de c i s i o n = t r a f f i c t y p e = ni l103 end104 node = nodeeval . node105106 rows << [ node . number ,107 nodeeval . testname ,108 i n t e r s e c t i o n ,109 d e c i s i o n ? d e c i s i o n . f r om d i r e c t i on : nil ,110 d e c i s i o n ? d e c i s i o n . turning mot ion : nil ,111 t r a f f i c t y p e ,112 nodeeval . t s t a r t ,113 nodeeval . tend ,114 ∗COLS TO HEADERS.map{|k , h | nodeeval . r e s u l t s [ k ] } ]115 end116117 rows118 end119 end120121 i f FILE == $0122 v i s s imnet = Vissim . new( Default network )123 r e s u l t s = NodeEvals . new( v i s s imnet )

95

124 r e s u l t s . e x t r a c t r e s u l t s ’ t e s t s imu la t ion ’ , ’C:\Documents and Se t t i ng s \anwg\LocalS e t t i ng s \Temp\ v i s s im scenar io1 morgen ’

125 for row in r e s u l t s . to a126 puts row . i n spe c t127 end128 end

Listing 5: thesis settings.rb1 Base d i r = ”#{Dir . pwd . s p l i t ( ’ / ’ ) [ 0 . . . − 1 ] . j o i n ( ”\\” ) }\\”2 Network name = ” t i l p a s s e t mode l . inp ”3 Vi s s im d i r = ”#{Base d i r }Vissim\\ o3 r o s k i l d e v e j−her l evsygehus \\”4 DOGSAGGRFILE = ”#{Base d i r }data\\ aggr . x l s ”5 DOGSAGGRCS = ”#{CSPREFIX}#{DOGSAGGRFILE} ; Extended Prope r t i e s=\”Excel 8 . 0 ;HDR=Yes ;IMEX

=1\””6 DOGSDB = Sequel . dbi DOGSAGGRCS78 PROGRAM = ’P1 ’9

10 USEDOGS = true1112 # d e f i n i t i o n o f extreme ends o f a r t e r y13 ARTERY = {14 : sc1 => { : f r om d i r e c t i on => ’N ’ , : scno => 1} ,15 : sc2 => { : f r om d i r e c t i on => ’ S ’ , : scno => 12}16 }1718 ARTERY DIRECTIONS = ARTERY.map{| sc , i n f o | i n f o [ : f r om d i r e c t i on ]}1920 # DOGS p r i o r i t y l e v e l s21 MINOR = ’Minor ’22 MAJOR = ’Major ’23 NONE = ’None ’24 DOGS LEVELS = 825 DOGS LEVEL GREEN = 10 # seconds green t ime a s s o c i a t e d w i th each dogs l e v e l change26 DOGS LEVELDOWN BUFFER = 0.1 # perc en t a g e o f t h r e s h o l d v a l u e f o r cu r r en t l e v e l27 DOGS TIME = 10 # number o f seconds by which c y c l e t ime i s i n c r e a s e d f o r each dogs l e v e l28 DOGS MAJOR FACTOR = 0.829 DOGS MINOR FACTOR = 1.0 − DOGS MAJOR FACTOR30 DOGS MAX LEVEL = 531 BUS TIME = 10 # number o f seconds to ex t end green t ime f o r bus s t a g e s32 DOGS CNT BOUNDS FACTOR = 0.8 # ad j u s t t h e a g g r e s i v e n e s s o f DOGS. Lower => more

a g g r e s s i v e to i n c r e a s e c y c l e t imes .33 DOGS OCC BOUNDS FACTOR = 0.834 # a s s o c i a t e d numbers w i th t h e s e v e h i c l e t y p e s35 Type map = { : c a r s => 1001 , : t rucks => 1002 , : buses => 1003}36 RESULTS FILE = ”#{Base d i r } r e s u l t s \\ r e s u l t s . x l s ”37 RESULTS FILE CS = ”#{CSPREFIX}#{RESULTS FILE} ; Extended Prope r t i e s=\”Excel 8 . 0 ;HDR=Yes ;

IMEX=1\””3839 Pro j ec t = ’ dtu ’4041 He r l e v d i r = F i l e . j o i n ( Base dir , ’ data ’ , ”DOGS Herlev 2007” )42 Glo s t rup d i r = F i l e . j o i n ( Base dir , ’ data ’ , ”DOGS Glostrup 2007” )43 MIN STAGE LENGTH = 6 # used when DOGS changes l e v e l and a s t a g e jump maybe be con s i d e r ed

C.2 Vissim codes

Listing 6: measurements.rb1 # i n s e r t i o n o f measurement p o i n t s ( queue l e n g t h d e t e c t o r s and t r a v e l t ime s e c t i o n s )2 # note ! o b s o l e t e d , use node e v a l u a t i o n s per i n t e r s e c t i o n i n s t e a d !3 # buse s are an e x c e p t i o n f o r t r a v e l t ime e v a l u a t i o n s45 r equ i r e ’ v i s s im output ’6 r e qu i r e ’ v i s s im e lem ’7 r equ i r e ’ v i s s im ’89 def insert measurements v i s s im = Vissim . new( Default network )

10 route s = vi s s im . g e t f u l l r o u t e s1112 #in s e r t q u e u e c o u n t e r s v i s s im , r ou t e s13 i n s e r t t r a v e l t im e s routes , : buses => true14 end15 class QueueCounter < VissimElem16 a t t r r e ad e r : l i n k17 def t o s ; ”#{super} at #{@link}” ; end18 end19 class TravelTime < VissimElem20 a t t r r e ad e r : from , : to , : v e h i c l e c l a s s e s21 def t o s ; ”#{super} from #{@from} to #{@to}” ; end22 def <=>(t t2 )23 (@from == tt2 . from ) ? (@to <=> t t2 . to ) : (@from <=> t t2 . from )

96

24 end25 end26 class Node < VissimElem ; end2728 class QueueCounters < Array29 inc lude VissimOutput30 def s e c t i on heade r ; /ˆ−− Queue Counters : −−/; end31 def t o v i s s im32 s t r = ’ ’33 each with index do | l ink , i |34 s t r += ”QUEUE COUNTER #{ i +1} LINK #{ l i n k . number} AT #{ l i n k . l ength − 5}\n”35 end36 s t r37 end38 end3940 def i n s e r t queue coun t e r s viss im , route s = g e t f u l l r o u t e s ( v i s s im )4142 d e c i s i o n s = route s . c o l l e c t {| r | r . d e c i s i o n s } . f l a t t e n . uniq4344 qc = QueueCounters . new45 # i n s e r t a queue l e n g t h d e t e c t o r b e f o r e each t u rn in g motion46 # a d e c i s i o n i s a connec tor . t h e from l i n k i s where to put t h e measuring d e v i c e47 d e c i s i o n s . s o r t . each {| dec | qc << dec . connector . from}4849 #put s qc . t o v i s s im50 qc . wr i t e51 end5253 class TravelTimes < Array54 inc lude VissimOutput55 def s e c t i on heade r ; /ˆ−− Travel Times : −−/; end56 def add name , input , ex i t , veh types = Cars and trucks , i nput a t = 20 .0 , e x i t a t =

50 .057 s e l f << { : name => name ,58 : input => input , : i nput a t => input at ,59 : e x i t => ex i t , : e x i t a t => ex i t a t ,60 : vehtyp => veh types }61 end62 VISSIM REAL FMT = ”%.03 f ”63 def t o v i s s im64 s t r = ”TRAVEL TIME AGGREGATION INTERVAL 99999 FROM 0 UNTIL 99999 RAW YES DATABASE

TABLE \”TRAVELTIMES\” AGGREGATE NO\n”65 each with index do | tt , i |6667 s t r += ”68 TRAVEL TIME #{ i +1} NAME \”#{ t t [ : name ]}\” DISPLAY LABEL 0.000 0 .000 0 .000 0 .000

EVALUATION YES69 FROM LINK #{t t [ : input ]} AT #{VISSIM REAL FMT % tt [ : i nput a t ]} TO LINK #{t t [ :

e x i t ]} AT #{VISSIM REAL FMT % tt [ : e x i t a t ]} SMOOTHING 0.25VEHICLE CLASSES #{t t [ : vehtyp ] . j o i n ( ’ ’ ) }”

7071 end72 s t r73 end74 end75 def i n s e r t t r a v e l t im e s routes , opts76 t t s = TravelTimes . new7778 i f opts [ : buses ]79 # In s e r t t r a v e l t ime measur ings f o r each bus l i n e80 for row in exec query ”SELECT BUS, [ Input Link ] , [ Exit Link ] FROM [ buses$ ] ”81 t t s . add ”Bus #{row [ 0 ] . t o i }” , row [ 1 ] . t o i , row [ 2 ] . t o i , [ Type map [ ’ Buses ’ ] ]82 end83 end8485 i f opts [ : p r i v a t e v e h i c l e s ]86 # In s e r t t r a v e l t ime measur ings f o r f u l l r o u t e s which have a c e r t a i n l e n g t h87 for route in route s . f i n d a l l {| r | r . l ength >= MIN ROUTE LENGTH} . s o r t88 t t s . add ”From #{route . s t a r t } to #{route . e x i t }” , route . s t a r t . number , route . e x i t .

number89 end90 end9192 #put s t t s . t o v i s s im93 t t s . wr i t e94 end9596 def g e t n e a r e s t l i n k ( head , s ea rch fo rward )97 p o s i t i o n l i n k = head . p o s i t i o n l i n k98 i f p o s i t i o n l i n k . i s a ?( Connector )99 return s ea rch fo rward ? p o s i t i o n l i n k . t o l i n k : p o s i t i o n l i n k . f rom l ink ,

100 search fo rward ? p o s i t i o n l i n k . a t t o l i n k : p o s i t i o n l i n k . a t f r om l i nk101 else102 i f s ea rch fo rward103 conn = po s i t i o n l i n k . outgo ing connec to r s . f i r s t104 else # f i n d a connec tor l e a d i n g to t h i s l i n k105 ObjectSpace . ea ch ob j e c t ( Connector ) do | c |

97

106 i f c . t o l i n k == po s i t i o n l i n k107 conn = c108 break109 end110 end111 end112 return conn . t o l i nk , conn . a t t o l i n k113 end114 end115116 i f FILE == $0117 t t s = TravelTimes . new118 v i s s im = Vissim . new119120 v i s s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 1 . . 5 ) === sc . number } . each cons (2) do | sc1 , sc2 |121 ARTERY DIRECTIONS [ 0 . . 0 ] . each do | f r om d i r e c t i on |122 head1 = sc1 . a r t e r i a l g r oup f r om ( f r om d i r e c t i on ) . heads . f i nd {|h | h . a r t e r i a l f r om ==

f rom d i r e c t i on }123 head2 = sc2 . a r t e r i a l g r oup f r om ( f r om d i r e c t i on ) . heads . f i nd {|h | h . a r t e r i a l f r om ==

f rom d i r e c t i on }124125 route = vi s s im . f i n d r ou t e ( head1 . p o s i t i o n l i n k , head2 . p o s i t i o n l i n k )126127 t o l i n k = route [−1]128 t t s . add ”From #{sc1 . name} to #{sc2 . name}” , Cars and trucks ,129 route [ 1 ] . number , t o l i n k . number ,130 5 . 0 , t o l i n k . l ength − 20 .0131 end132 end133134 puts t t s . t o v i s s im135 t t s . wr i t e136 end

Listing 7: network.rb1 # Cla s s e s which d e s c r i b e t h e p h y s i c a l v i s s im network23 r equ i r e ’ v i s s im e lem ’45 class RoadSegment < VissimElem6 a t t r r e ad e r : lanes , : c l o s ed to , : ove r po in t s ,7 : a r t e r i a l f r om # i f se t , i n d i c a t e s t h i s road i s pa r t o f t h e a r t e r y8 #d i r e c t i o n and from where9 def c l o s ed to any ?( veh types )

10 r a i s e ” Veh ic l e l ane s c l o s u r e was not de f ined f o r #{ s e l f } ! ” i f @closed to . ni l ?11 not ( @c losed to & veh types ) . empty?12 end13 def a l l ow s p r i v a t e v e h i c l e s ?14 not c l o s ed to any ?( Cars and trucks )15 end16 def l e n g th ov e r po i n t s17 return 0 .0 i f @over points . empty?18 ( 0 . . . @over points . s i z e −1) .map do | i |19 @over points [ i ] . d i s t ance ( @over points [ i +1])20 end . sum21 end22 end23 # Connectors e s t a b l i s h a one−way connec t i on from a l i n k to ano ther24 class Connector < RoadSegment25 a t t r r e ad e r : f rom l ink , : a t f r om l ink , : t o l i nk , : a t t o l i n k26 def l ength27 # TODO: hand l e case when connec tor i s not p l a c ed in t he ends o f f r om l i n k or t o l i n k28 l e ng th ov e r po i n t s29 end30 end31 # A de c i s i o n i s a connector , which , whenever taken , has a d e c i d i n g e f f e c t32 # on the f i n a l r ou t e o f t h e mo t o r i s t33 class Dec i s ion < Connector34 a t t r r e ad e r : f r om d i r e c t i on , : i n t e r s e c t i o n , : turning motion , : f r a c t i on s , : weight , :

d rop l ink ,35 : d e c i d e f r om d i r e c t i on , : d e c i d e a t i n t e r s e c t i o n36 def i n i t i a l i z e ( number )37 super ( number )38 # the numbered op t i on f o r t h i s t u rn in g motion , when a l t e r t i v e s f o r t h e39 # same tu rn in g motion e x i s t40 @f rac t i ons = [ ]41 end42 def t ime i n t e r v a l s ; @ f rac t i ons .map{| f | f . i n t e r v a l } ; end43 def add f r a c t i on ( i n t e r va l , vehtype , quant i ty )44 r a i s e ” Fract ions at #{t o s } f o r #{vehtype} from #{ i n t e r v a l } a l ready e x i s t ! ” i f

@frac t i ons . any ?{| f | f . i n t e r v a l == i n t e r v a l and f . veh type == vehtype}4546 @f rac t i ons << Fract ion . new ! ( : i n t e r v a l => i n t e r va l , : veh type => vehtype , : quant i ty

=> quant i ty )47 end48 def <=>(d2 )

98

49 @in t e r s e c t i on == d2 . i n t e r s e c t i o n ?50 ( @from direct ion == d2 . f r om d i r e c t i on ? @turning motion <=> d2 . turning mot ion :

@from direct ion <=> d2 . f r om d i r e c t i on ) :51 @ in t e r s e c t i on <=> d2 . i n t e r s e c t i o n52 end53 end54 class Link < RoadSegment55 a t t r r e ad e r : f rom point , : to po int ,56 : l i nk type , : lanes , : length ,57 : inte r sec t ion number , : f r om d i r e c t i on ,58 : outgo ing connec to r s59 a t t r a c c e s s o r : i s bu s i npu t60 def i n i t i a l i z e number61 super ( number )62 @outgoing connectors = [ ] # a l i s t o f ou t g o in g connec to r s from t h i s l i n k63 end6465 # i s t h i s l i n k an e x i t ( from the network ) l i n k ?66 def e x i t ? ; @outgo ing connectors . empty ? ; end67 # inpu t l i n k s can be d e t e c t e d bu t we need to be a b l e to f i l t e r68 # them out69 def input ? ; @l ink type == ’ IN ’ ; end70 # re t u rn s a l i s t o f d e c i s i o n s f o r which t h i s l i n k i s t h e drop−o f f l i n k71 def drop fo r72 return @drop for i f @drop for73 @drop for = i f @name =˜ /drop ( .+) /74 $1 . s p l i t ( ’ , ’ ) .map{| s | s . s t r i p }75 else ; [ ] ; end76 end77 def t o s78 s t r = super79 s t r << ”#{@direct ion }” i f @direct ion80 s t r81 end82 end8384 # A de c i s i o n po i n t i s p o i n t on a l i n k where a d e c i s i o n85 # must be made about which way to go from here i e . which86 # of t h e p o s s i b l e d e c i s i o n s to t a k e .87 class Dec i s ionPoint88 a t t r r e ad e r : f r om d i r e c t i on , : i n t e r s e c t i o n , : d e c i s i o n s89 def i n i t i a l i z e from , i n t e r s e c t i o n90 @from direct ion , @ in t e r s e c t i on = from , i n t e r s e c t i o n91 @dec i s ions = [ ]92 @link = ni l93 end9495 # r e t r i e v e a combined s e t o f t ime i n t e r v a l s96 # fo r t h e f l ow s d e f i n e d on a l l d e c i s i o n s in t h i s97 # de c i s i o n po i n t .98 # note t h a t t h e d e c i s i o n s might not have f l ow s in t h e same99 # time i n t e r v a l s

100 def t ime i n t e r v a l s ( program )101 i n t e r v a l s = @dec i s ions .map{|d | d . t ime i n t e r v a l s } . f l a t t e n . uniq . f i n d a l l {| i | program .

i n t e r v a l === i . t s t a r t }102 i f program . r e p e a t f i r s t i n t e r v a l103 i n t e r v a l s << i n t e r v a l s . min104 end105 i n t e r v a l s106 end107 # Loca te s t h e common o r i g i n l i n k f o r t h e d e c i s i o n s in t h i s d e c i s i o n po i n t .108 # Does t h i s by f i n d i n g a l i n k from which t h e r e i s a rou t e to a l l d e c i s i o n109 # de s t i n a t i o n l i n k s110 def l i n k v i s s im111 return @link i f @link # cache h i t112113 # check i f t h i s d e c i s i o n po i n t r ou t e s t r a f f i c d i r e c t l y from an inpu t l i n k114 # i f so , p l a c e t h e d e c i s i o n po i n t t h e r e to a s s i g n t h e d e c i s i o n115 # as e a r l y as p o s s i b l e116117 i npu t l i n k = vi s s im . l i n k s . f i nd do | l |118 l . i n t e r s ec t i on number == @int e r s e c t i on and l . f r om d i r e c t i on == @from direct ion119 end120121 return @link = inpu t l i n k i f i n pu t l i n k122123 # othe rw i s e , perform a backwards s ea rch f o r t h e b e s t common s t a r t i n g po i n t . . .124 r a i s e ” Dec i s ion point #{@from direct ion}#{@int e r s e c t i on } has no d e c i s i o n s ! ” i f

@dec i s ions . empty?125126 d rop l i nk s = @dec i s ions .map{| dec | dec . d rop l i nk }127128 # Looking f o r a l i n k which has r ou t e s end ing a t a l l o f t h e drop l i n k s129 l i n k r o u t e s = {}130 ( v i s s im . l i n k s − d rop l i nk s ) . each do | l i n k |131 l i n k r o u t e s [ l i n k ] = vi s s im . f i n d r ou t e s ( l ink , d r op l i nk s )132 end133

99

134 # remove any l i n k which i s not connec ted to a l l drop l i n k s135 l i n k r o u t e s . d e l e t e i f do | l ink , route s |136 not d rop l i nk s . a l l ?{| drop l i nk | route s . any ?{| route | route . e x i t == drop l i nk }}137 end138139 # remove any l i n k which has r ou t e s t h a t does not t r a v e r s e one o f t h e d e c i s i o n s140 l i n k r o u t e s . d e l e t e i f do | l ink , route s |141 not @dec i s ions . a l l ?{| dec | route s . any ?{| route | route . d e c i s i o n s . i n c lude ?( dec )}}142 end143144 # We now have a number o f c and i d a t e s . We want t h e one c l o s e s t145 # to the d e c i s i o n s . E x p l o i t t h a t we ∗know∗ t h e s e l i n k s have r ou t e s to146 # a l l drop l i n k s .147 s h o r t e s t r o u t e = l i n k r o u t e s . va lues . f l a t t e n . min148 @link = sho r t e s t r o u t e . s t a r t149150 @link | | r a i s e ( ”No l i n k found from which #{d rop l i nk s . j o i n ( ’ , ’ ) } can be reached ” )151 end152 def <=>(dp2 )153 @in t e r s e c t i on == dp2 . i n t e r s e c t i o n ? @from direct ion <=> dp2 . f r om d i r e c t i on :

@ in t e r s e c t i on <=> dp2 . i n t e r s e c t i o n154 end155 def t o s156 ” Dec i s ion Point #{@from direct ion}#{@int e r s e c t i on } : #{@dec i s ions . j o i n ( ’ , ’ ) }”157 end158 end

Listing 8: signal.rb1 ##2 # Cla s s e s to c omp l e t e l y d e s c r i b e a s i g n a l c o n t r o l l e r :3 # − i n t e r s t a g e c a l c u l a t i o n s4 # − group r e p r e s e n t a t i o n and s t a t e s56 r equ i r e ’ v i s s im e lem ’7 r equ i r e ’ v i s s im rou t e s ’89 class S i gna lCon t r o l l e r < VissimElem

10 a t t r r e ad e r : c on t r o l l e r t yp e , : cyc l e t ime , : o f f s e t , : groups , : program ,11 : bus detec tor n , : bu s de t e c to r s , # north and sou the rn d e t e c t o r s u f f i x e s12 : donor stage , : r e c i p i e n t s t a g e , # donor and r e c i p i e n t s t a g e s13 : member coordinations , # l i s t o f c oo rd ina t i on s , in which t h i s c o n t r o l l e r p a r t i c i p a t e s14 : p o s i t i o n # Gives an e s t ima t e o f t h e c o n t r o l l e r s p o s i t i o n in t he a r t e r y in meters1516 def i n i t i a l i z e number17 super ( number )18 @groups = [ ] ; @member coordinations = [ ]19 @ar t e r i a l g roups f r om = {} ; @ s e r v e d a r t e r i a l l i n k s = {} # cache s t o r e s20 end2122 # Methods used in bus p r i o r i t y23 def ha s bu s p r i o r i t y ? ; [ @bus detector n , @bus detector s , @donor stage , @r e c i p i en t s t ag e

] . a l l ?{| e | e } ; end24 def i s dono r ? s tage ; s tage . number == @donor stage ; end25 def i s r e c i p i e n t ? s tage ; s tage . number == @rec i p i en t s t a g e ; end2627 # check i f a l l g roups have a s i g n a l p lan p l u s28 # gen e r e l check s29 def has p lans ? ; not [ @program ] . any ?{| e | e . ni l ?} and @groups . a l l ?{| grp | grp . has p lan ?} ;

end30 def add group (number , opts ) ; @groups << SignalGroup . new ! ( number , opts ) ; end31 def group (number ) ; @groups . f i nd {| grp | grp . number == number } ; end32 def a r t e r i a l g r o u p s33 @ar t e r i a l g r oups | |= @groups . f i n d a l l {| grp | grp . s e r v e s a r t e r y ?}34 end35 def a r t e r i a l g r oup s f r om ( f r om d i r e c t i on )36 @ar t e r i a l g roups f r om [ f r om d i r e c t i on ] | |=37 a r t e r i a l g r o u p s . f i n d a l l {| grp | grp . a r t e r i a l f r om . inc lude ?( f r om d i r e c t i on )}38 end39 def a r t e r i a l g r oup f r om ( f r om d i r e c t i on )40 groups = a r t e r i a l g r oup s f r om ( f r om d i r e c t i on )41 r a i s e ”Expected exac t l y one group from #{ f r om d i r e c t i on }” i f groups . s i z e != 142 groups . f i r s t43 end44 def i n t e r s t a g e a c t i v e ?( c y c l e s e c , program name )45 # a l l−red phases are con s i d e r ed i n t e r s t a g e46 return true i f @groups . a l l ?{| grp | grp . c o l o r ( c y c l e s e c , program name ) == RED}4748 # check f o r o rd inary i n t e r s t a g e s49 @groups . any ?{| grp | [YELLOW,AMBER] . i n c lude ? grp . c o l o r ( c y c l e s e c , program name )}50 end51 def p r i o r i t y s tage52 return NONE unless s tage . i n s t a n c e o f ?( Stage ) # i n t e r s t a g e s are f i x e d l e n g t h5354 # a s t a g e has major p r i o r i t y i f i t c on t a i n s a l l g roups ( f o r t h i s SC)55 # which shou l d r e c e i v e major p r i o r i t y r a t h e r than j u s t some o f them56 i f (@groups . f i n d a l l {| grp | grp . p r i o r i t y == MAJOR} − s tage . groups ) . empty?

100

57 MAJOR58 else59 s tage . groups . any ?{| grp | grp . p r i o r i t y == MINOR} ? MINOR : NONE60 end61 end62 # Finds t h e green wave bands emi t t e d from the g i v en a r t e r i a l d i r e c t i o n63 # in the g i v en t ime hor i z on . The o f f s e t o f t h e s i g n a l c o n t r o l l e r i s taken64 # as a parameter and w i l l a f f e c t t h e s t a r t−and end t imes o f t h e bands .65 def greenwaves ( horizon , o f f s e t , f r om d i r e c t i on , cy c l e t ime = @cycle t ime )66 waves = [ ]67 a r t e r i a l g r oup s f r om ( f r om d i r e c t i on ) . each do | group |68 a c t i v e s e c ond s = group . a c t i v e s e c ond s # wi t h i n a c y c l e6970 g r e en t ime ex t = case group . p r i o r i t y71 when MAJOR then ( cy c l e t ime − @cycle t ime ) ∗ DOGS MAJOR FACTOR72 when MINOR then ( cy c l e t ime − @cycle t ime ) ∗ DOGS MINOR FACTOR73 else 074 end7576 # p r o j e c t a c t i v e seconds i n t o t h e ho r i z on77 t s t a r t b a s e = ac t i v e s e c ond s . min + o f f s e t78 tend base = ac t i v e s e c ond s .max + o f f s e t + green t ime ex t7980 # on ly show bands in t h e hor i z on ;81 n = ( hor izon . min / cyc l e t ime . t o f ) . f l o o r # f i r s t band i s found a f t e r n c y c l e s82 m = ( hor izon .max / cyc l e t ime . t o f ) . f l o o r # l a s t band i s found a f t e r m c y c l e s8384 (n . .m) . each do | cycle number |85 c y c l e o f f s e t = cyc l e t ime ∗ cycle number86 t s t a r t = ( t s t a r t b a s e + c y c l e o f f s e t ) . round87 tend = ( tend base + c y c l e o f f s e t ) . round88 # check i f ( t s t a r t . . t end ) o v e r l a p s w i th t h e hor i z on89 waves << Band . new( t s t a r t , tend ) i f ( t s t a r t . . tend ) . over lap ?( hor izon )90 end91 end92 waves93 end94 def s t age s program name95 return @stagear i f @stagear # cache h i t96 l a s t s t a g e = ni l97 l a s t i n t e r s t a g e = ni l98 @stagear = [ ]99 for t in ( 1 . . @program [ program name ] [ : c y c l e t ime ] )

100 i f i n t e r s t a g e a c t i v e ?( t , program name )101 i f l a s t i n t e r s t a g e102 l a s t i n t e r s t a g e = l a s t i n t e r s t a g e . succ unless @stagear . l a s t == l a s t i n t e r s t a g e103 else104 l a s t i n t e r s t a g e = ’ a ’105 end106 @stagear << l a s t i n t e r s t a g e107 else108 # check i f any c o l o r s have changed109 i f @groups . a l l ?{| grp | grp . c o l o r ( t , program name ) == grp . c o l o r ( t−1,program name )}110 @stagear << l a s t s t a g e111 else112 l a s t s t a g e = Stage . new ! ( ( l a s t s t a g e ? l a s t s t a g e . number+1 : 1) ,113 : groups => @groups . f i n d a l l {| grp | grp . a c t i v e s e c ond s ( program name ) === t })114 @stagear << l a s t s t a g e115 end116 end117 end118 @stagear119 end120 def s e r v e d a r t e r i a l l i n k s ( f r om d i r e c t i on )121 @ s e r v e d a r t e r i a l l i n k s [ f r om d i r e c t i on ] | |=122 a r t e r i a l g r oup s f r om ( f r om d i r e c t i on ) .map{| grp | grp . s e r v e d a r t e r i a l l i n k s } . f l a t t e n123 end124 # c a l c u l a t e s t h e approx imate d i s t a n c e ac ro s s t h e i n t e r s e c t i o n from stop− l i n e to s top−

l i n e125 def i n t e r n a l d i s t a n c e126 # a r t e r i a l h e a d s f r om = Hash . new {| h , k | h [ k ] = [ ] } # f r om d i r e c t i o n s => l i n k s127 # @groups .map{| grp | grp . a r t e r i a l h e a d s } . f l a t t e n . each do | head |128 # put s head129 # a r t e r i a l h e a d s f r om [ head . p o s i t i o n l i n k . f r om d i r e c t i o n ] << head130 # end131 # fo r f r om d i r e c t i o n in a r t e r i a l h e a d s f r om . key s . uniq − [ n i l ]132 # put s f r om d i r e c t i o n133 # end134135 42136 end137 class SignalGroup < VissimElem138 a t t r r e ad e r : red end , : green end , : tred amber , : tamber , : heads , : p r i o r i t y , : program139 def i n i t i a l i z e ( number )140 super ( number )141 @heads = [ ] # s i g n a l heads in t h i s group142 @color = {}143 end

101

144 def add head number , opts ; @heads << SignalHead . new ! ( number , opts ) ; end145 #de f ha s p l an ? ; not [ @red end , @green end , @tred amber , @tamber ] . any ?{| e | e . n i l ?} ; end146 def has p lan ? ; not [ @program ] . any ?{| e | e . ni l ?} ; end147 def c o l o r c y c l e s e c , program name148 red end = @program [ program name ] [ : red end ]149 green end = @program [ program name ] [ : green end ]150 case c y c l e s e c151 when a c t i v e s e c ond s ( program name )152 GREEN153 when ( red end +1. . red end+@tred amber )154 AMBER155 when ( green end . . green end+@tamber )156 YELLOW157 else158 RED159 end160 end161 # re t u rn s a range o f seconds in a c y c l e in v e h i c l e s are p e rm i t t e d162 # to c r o s s t h e s t op l i n e s o f t h e group163 def a c t i v e s e c ond s program name164 red end = @program [ program name ] [ : red end ]165 green end = @program [ program name ] [ : green end ]166 g r e e n s t a r t = red end + @tred amber + 1167 i f g r e e n s t a r t < green end168 ( g r e e n s t a r t . . green end )169 else170 # ( green end +1. . g r e e n s t a r t ) d e f i n e s t h e red t ime171 ( 1 . . green end ) # todo : hand l e t h e case o f green t ime which wraps around172 end173 end174 def s e r v e s a r t e r y ? ; @se rve s a r t e ry | |= @heads . any ?{|h | h . s e r v e s a r t e r y ?} ; end175 def s e r v e d a r t e r i a l l i n k s ; @ s e r v e d a r t e r i a l l i n k s | |= a r t e r i a l h e a d s .map{|h | h .

p o s i t i o n l i n k } . uniq ; end176 # Scan over t h e s i g n a l heads in t h i s group e x t r a c t i n g a l l177 # road segments , which are a r t e r i a l and the from d i r e c t i o n .178 # I f none such markings are found among the heads , t h i s group s e r v e s179 # on ly minor−road t r a f f i c . Otherwise a t l e a s t some heads180 # se r v e t h e a r t e r i a l ( major road ) and the d i r e c t i o n from which i s s e r v ed181 # becomes t h e answer182 def a r t e r i a l f r om ; @ar t e r i a l f r om | |= @heads .map{|h | h . a r t e r i a l f r om } . uniq − [ ni l ] ;

end183 def a r t e r i a l h e a d s ; @ar t e r i a l h ead s | |= @heads . f i n d a l l {|h | h . s e r v e s a r t e r y ?} ; end184 class SignalHead < VissimElem185 a t t r r e ad e r : p o s i t i o n l i n k , : lane , : at186 def s e r v e s a r t e r y ? ; not a r t e r i a l f r om . ni l ? ; end187 def a r t e r i a l f r om ; @po s i t i on l i nk . a r t e r i a l f r om ; end188 def t o s ; ”Head #{number} on #{@pos i t i on l i nk } at #{at}” ; end189 end190 end191 end192 # A s t a g e d e f i n e s a pe r i od o f t ime in which one or more s i g n a l groups are193 # a c t i v e i e . green s imu l t a n e ou s l y .194 class Stage < VissimElem195 a t t r r e ad e r : groups196 def t o s ; @number . t o s ; end197 def a r t e r i a l ? ; @groups . any ?{| grp | grp . s e r v e s a r t e r y ?} ;end198 end

Listing 9: turningprob.rb1 r equ i r e ’ network ’2 r e qu i r e ’ v i s s im ’3 r equ i r e ’ v i s s im rou t e s ’4 r e qu i r e ’ v i s s im output ’56 class Rout ingDec i s ions < Array7 inc lude VissimOutput8 def s e c t i on heade r ; /ˆ−− Routing Dec i s i ons : −−/; end9 def t o v i s s im

10 s t r = ’ ’11 each with index do | rd , i |12 s t r << ”#{rd . t o v i s s im ( i +1)}”13 end14 s t r15 end16 end17 class RoutingDecis ion18 a t t r r e ad e r : i nput l i nk , : veh type19 def i n i t i a l i z e20 @routes = [ ]21 end22 def add route route , f r a c t i o n s23 r a i s e ”Warning : s t a r t i n g l i n k (#{ route . s t a r t }) o f route was d i f f e r e n t24 from the input l i n k o f the rout ing d e c i s i o n (#{@input l ink }) ! ” unless route .

s t a r t == @input l ink25

102

26 r a i s e ”Wrong v eh i c l e types detected among f r a c t i on s , expect ing only #{@veh type}” i ff r a c t i o n s . any ?{| f | f . veh type != @veh type}

27 unless f r a c t i o n s . s i z e == @t ime in t e rva l s . s i z e28 r a i s e ”Wrong number o f f r a c t i on s , #{ f r a c t i o n s . s i z e } , ” +29 ” expected #{@t ime in t e rva l s . s i z e }\n#{ f r a c t i o n s . s o r t . j o i n ( ”\n” )}\n#{route }\n#{

@t ime in t e rva l s . j o i n ( ”\n” )}”30 end31 @routes << [ route , f r a c t i o n s ]32 end33 def tbeg in34 @t ime in t e rva l s . min . t s t a r t35 end36 def t o v i s s im i37 s t r = ”ROUTING DECISION #{ i } NAME \”#{@desc ? @desc : ( @veh type . t o s . c a p i t a l i z e )}

from #{@input l ink }\” LABEL 0.00 0.00\n”38 # AT must be AFTER the inpu t po i n t39 # p l a c e d e c i s i o n s as e a r l y as p o s s i b l y to g i v e v e h i c l e s t ime to changes l a n e s4041 s t r << ” LINK #{@input l ink . number} AT #{@input l ink . l ength ∗ 0 .1 + 10}\n”42 s t r << ” TIME #{@t ime in t e rva l s . s o r t .map{| i n t | i n t . t o v i s s im ( tbeg in ) } . j o i n ( ’ ’ ) }\

n”43 s t r << ” NODE 0\n”44 s t r << ” VEHICLE CLASSES #{Type map [ @veh type ]}\n”4546 j = 14748 for route , f r a c t i o n s in @routes49 e x i t l i n k = route . e x i t50 # dump v e h i c l e s l a t e on the rou t e e x i t l i n k to avo id p l a c i n g t h e d e s t i n a t i o n51 # upstream o f t h e l a s t connec tor52 s t r << ” ROUTE #{ j } DESTINATION LINK #{e x i t l i n k . number} AT #{

e x i t l i n k . l ength ∗ 0.1}\n”53 s t r << ” #{ f r a c t i o n s . s o r t .map{| f | f . t o v i s s im } . j o i n ( ’ ’ ) }\n”54 s t r << ” OVER #{route . t o v i s s im }\n”55 j += 156 end57 s t r58 end59 end6061 # SQL f o r e x t r a c t i n g t r a f f i c count in f o rma t i on f o r t u rn in g r a t i o s62 # note t h e r e are two p l a c e h o l d e r s : PERIOD START and PERIOD END, which63 # must be s u b s t i t u t e d by a time−of−day va l u e such as 7 :00 or 15 :0064 TURNING SQL = ”SELECT clng (INTSECT. number ) as inter sect ion number ,65 f r om d i r e c t i on , t o d i r e c t i o n ,66 [ Turning Motion ] As turn ,67 [ Period Star t ] As t s t a r t ,68 [ Period End ] As tend ,69 cars , t rucks70 FROM [ counts$ ] As COUNTS71 INNER JOIN [ i n t e r s e c t i o n s $ ] As INTSECT72 ON COUNTS. I n t e r s e c t i o n = INTSECT.Name73 WHERE [ Period End ] BETWEEN \#1899/12/30 PERIOD START:00\# AND

\#1899/12/30 PERIOD END:00\#74 AND NOT IsNu l l ( t o d i r e c t i o n ) ”7576 # he lpe r−c l a s s e s f o r Dec i s i on77 class I n t e r v a l78 a t t r r e ad e r : t s t a r t , : tend79 def i n i t i a l i z e t s t a r t , tend80 @tstart , @tend = t s t a r t , tend81 end82 def s h i f t ( seconds )83 @tstart += seconds84 @tend += seconds85 end86 def copy87 I n t e r v a l . new( @tstart , @tend )88 end89 def hash90 @tstart . hash + @tend . hash91 end92 def eq l ?( other )93 @tstart == other . t s t a r t and @tend == other . tend94 end95 def t o v i s s im ( tbeg in ) ; ”FROM #{@tstart − tbeg in } UNTIL #{@tend − tbeg in }” ; end96 def t o s ; ”#{@tstart . to hm} to #{@tend . to hm}” ; end97 def <=>(i 2 ) ; @tstart <=> i 2 . t s t a r t ; end98 end99 class Fract ion

100 a t t r r e ad e r : i n t e rva l , : veh type , : quant i ty101 def copy102 Fract ion . new ! ( : i n t e r v a l => @interva l . copy , : veh type => @veh type , : quant i ty =>

@quantity )103 end104 def <=>(f 2 ) ; @interva l <=> f 2 . i n t e r v a l ; end105 def t o s ; ” Fract ion from #{@interva l } = #{quant i ty} #{@veh type}” ; end106 def t o v i s s im ; ”FRACTION #{@quantity}” ; end

103

107 end108109 def g e t r o u t i n g d e c i s i o n s viss im , program110111 d e c i s i o n s = vi s s im . d e c i s i o n s . f i n d a l l do | dec |112 dec . f r a c t i o n s . any ?{| f r a c t i o n | program . i n t e r v a l === f r a c t i o n . i n t e r v a l . t s t a r t }113 end114115 r o u t i n g d e c i s i o n s = Rout ingDec i s ions . new116117 d e c i s i o n p o i n t s = [ ]118 d e c i s i o n s . each do | dec |119 dp = de c i s i o n p o i n t s . f i nd do | dp |120 dp . f r om d i r e c t i on == dec . d e c i d e f r om d i r e c t i o n and121 dp . i n t e r s e c t i o n == dec . d e c i d e a t i n t e r s e c t i o n122 end123124 # cr e a t e new dp , i f no o t h e r d e c i s i o n c r e a t e d i t b e f o r e125 i f dp . ni l ?126 dp = Dec i s ionPoint . new( dec . d e c i d e f r om d i r e c t i on , dec . d e c i d e a t i n t e r s e c t i o n )127 d e c i s i o n p o i n t s << dp128 end129 dp . d e c i s i o n s << dec130 end131132 # f i n d the l o c a l r o u t e s from the d e c i s i o n po i n t133 # to the po i n t where t h e v e h i c l e s are dropped o f f downstream o f i n t e r s e c t i o n134 d e c i s i o n p o i n t s . s o r t . each do | dp |135 d e c i s i o n l i n k = dp . l i n k ( v i s s im )136137 for veh type in [ : cars , : t rucks ]138 rd = RoutingDecis ion . new ! (139 : i npu t l i n k => d e c i s i o n l i n k ,140 : veh type => veh type ,141 : t ime i n t e r v a l s => dp . t ime i n t e r v a l s ( program ) )142143 # add rou t e s to t h e d e c i s i o n po i n t144 for dec in dp . d e c i s i o n s145 dest = dec . d rop l i nk146147 # f i n d the rou t e th rough the i n t e r s e c t i o n ( i e . t h e t u rn in g motion )148 l o c a l r o u t e s = vi s s im . f i n d r ou t e s ( d e c i s i o n l i n k , dest )149 l o c a l r o u t e = l o c a l r o u t e s . f i nd {| r | r . d e c i s i o n s . i n c lude ?( dec )}150 r a i s e ”No route s from #{d e c i s i o n l i n k } to #{dest } over #{dec} among these route s

:151 \n#{ l o c a l r o u t e s .map{| l r | l r . t o v i s s im } . j o i n ( ”\n” )}” i f l o c a l r o u t e . ni l ?152153 f r a c t i o n s = dec . f r a c t i o n s . f i n d a l l do | f r a c t i o n |154 f r a c t i o n . veh type == veh type and155 program . i n t e r v a l === f r a c t i o n . i n t e r v a l . t s t a r t156 end157 i f program . r e p e a t f i r s t i n t e r v a l158 f i r s t f r a c t i o n = dec . f r a c t i o n s . f i n d a l l {| f | f . veh type == veh type } . min by {| f | f

. i n t e r v a l }159160 r a i s e ” Fract ions at #{dec } :\n#{ f r a c t i o n s . j o i n ( ”\n” )}” unless f i r s t f r a c t i o n161162 n ew f i r s t f r a c t i o n = f i r s t f r a c t i o n . copy163 n ew f i r s t f r a c t i o n . i n t e r v a l . s h i f t (−program . r e s o l u t i o n ∗ 60)164165 f r a c t i o n s << n ew f i r s t f r a c t i o n166 end167 rd . add route ( l o c a l r ou t e , f r a c t i o n s )168 end169170 r o u t i n g d e c i s i o n s << rd171 end172173 end174175 r o u t i n g d e c i s i o n s176 end177178 i f FILE == $0179 puts ”BEGIN”180181 r equ i r e ’ c ow i t e s t s ’182183 v i s s im = Vissim . new184185 rds = g e t r o u t i n g d e c i s i o n s viss im ,MORNING186 puts rds . t o v i s s im187188 puts ”END”189 end

Listing 10: vap.rb

104

1 r equ i r e ’ v i s s im ’2 r equ i r e ’ dog s th r e sho ld ’34 class CodePrinter5 def i n i t i a l i z e6 @fmt num = ”S%03d : %s”7 @fmt nonum = ”#{’ ’∗6}%s”8 @line number = 09 @l ines = [ ]

10 end11 # add a l i n e ∗wi th ∗ a l i n e number12 def <<( l i n e )13 @l ines << format (@fmt num , @line number , l i n e )14 @line number += 115 end16 # add a l i n e w i t hou t a l i n e number17 def add l i n e ; @l ines << format (@fmt nonum , l i n e ) ; end18 # adds a l i n e verba t im19 def add verb l i n e ; @l ines << l i n e ; end20 def t o s ; @l ines . j o i n ( ”\n” ) ; end21 def wr i te f i l e p a t h ; F i l e . open ( f i l e p a th , ’w ’ ) { | f | f << t o s } ; end22 end23 def g e t g en e r a t e d i n f o24 ”/∗ This program was automat i ca l l y generated by #{$0 . s p l i t ( ”/” ) . l a s t } on #{Time . now .

s t r f t ime ( EU date fmt )} ∗/”25 end26 def gen master opts , c y c l e s t o r ema i n i n l e v e l , outputd i r2728 cp = CodePrinter . new2930 cp . add verb g e t g en e r a t e d i n f o3132 cp . add verb ”PROGRAM DOGS MASTER ; /∗ #{opts [ : area ]} ∗/”33 cp . add verb ’ ’3435 # Count ( i n t e n s i t y ) bounds are e s t ima t ed f o r a coun t ing pe r i od o f BASE CYCLE TIME

seconds36 # Occupied ra te− ( p e r c en t a g e s ) and count−bounds are taken from the DOGS ma t e r i a l37 # and are i d e n t i c a l f o r bo th areas on O338 cnt bounds = opts [ : cnt bounds ]39 occ bounds = opts [ : occ bounds ]4041 cp . add verb ”CONST42 BASE CYCLE TIME = #{BASE CYCLE TIME} ,43 DN = #{opts [ : dn ]} ,44 DS = #{opts [ : ds ]} ,45 SMOOTHING FACTOR = 0 .5 ,46 ENABLE CNT = #{cnt bounds [ : upper ] . min} ,47 DISABLE CNT = #{cnt bounds [ : lower ] . min} ,48 ENABLE OCC = #{occ bounds [ : upper ] . min} ,49 DISABLE OCC = #{occ bounds [ : lower ] . min} ,50 DOGS FORCE DISABLE = #{opts [ : dogs enabled ] ? 0 : 1} ;51 ”5253 cp . add verb ”/∗ Express ions ∗/54 c y c l e s e c := T;55 c y c l e s e c p l u s 1 := c y c l e s e c + 1 ;56 CURRENT CYCLE TIME := BASE CYCLE TIME + #{DOGS LEVEL GREEN} ∗ DOGS LEVEL;57 ”5859 cp << ”IF NOT cy c l e s e c THEN /∗ Perform i n i t i a l i z a t i o n ∗/”60 cp << ” DN CNT := 0 ; DS CNT := 0 ; CYCLES AT LEVEL:= 0 ; /∗ Keeps Vissim from nagging

∗/”61 cp << ” SetT (1) ; /∗ Star t the c l ock ∗/”62 cp << ” TRACE(ALL) ; /∗ Enable t r a c i ng ∗/” i f ENABLE VAP TRACING [ : master ]63 cp . add ” GOTO PROG ENDE”64 cp . add ”END; ”6566 cp << ”Marker put (1 ,DOGS LEVEL) ; Marker put (2 , c y c l e s e c ) ; ”67 cp << ”IF c y c l e s e c < CURRENT CYCLE TIME THEN”68 cp << ” SetT ( c y c l e s e c p l u s 1 ) ; ”69 cp . add ”ELSE”70 cp << ” SetT (1) ; ”71 cp << ” PREV CYCLES AT LEVEL := CYCLES AT LEVEL; ”72 cp << ” CYCLES AT LEVEL := PREV CYCLES AT LEVEL + 1 ; ”73 cp . add ”END; ”7475 cp << ”IF T <> 1 THEN”76 cp << ” GOTO PROG ENDE; ”77 cp . add ”ELSE /∗ read and c l e a r d e t e c t o r s every cy c l e ∗/”78 cp . add verb ”/∗ When DOGS LEVEL > 0 the count ing per iod i s extended along with the

green time79 and the counts from the de t e c t i on s must be co r r e c t ed be f o r e comparing

to the cnt th re sho ld va lues ∗/”80 cp << ” DOGS CORRECTION FACTOR := BASE CYCLE TIME / CURRENT CYCLE TIME; ”81 cp << ” DN CNT := DOGS CORRECTION FACTOR ∗ (DN CNT + SMOOTHING FACTOR ∗ ( Rear ends (

DN) − DN CNT) ) ; ”

105

82 cp << ” DS CNT := DOGS CORRECTION FACTOR ∗ (DS CNT + SMOOTHING FACTOR ∗ ( Rear ends (DS) − DS CNT) ) ; ”

83 cp << ” DN OCC := Occup rate (DN) ∗ 100 ; /∗ Occupied ra t e percentage ∗/”84 cp << ” DS OCC := Occup rate (DS) ∗ 100 ; ”85 cp . add verb ”/∗ Measuring on detec to r s , which are used to determine cur rent dogs l e v e l

∗/”86 for occ de t in opts [ : o c c de t s ]87 cp << ” D#{occ de t } OCC := Occup rate(#{occ de t }) ∗ 100 ; ”88 end89 # coun t ing d e t e c t o r s needs to be c l e a r e d90 for cnt de t in opts [ : cn t de t s ]91 cp << ” D#{cnt de t } CNT := Rear ends(#{ cnt de t }) ; ”92 cp << ” cre (#{ cnt de t }) ; ”93 end94 unless opts [ : cn t de t s ] . i n c lude ? opts [ : dn ]95 cp << ” cre (DN) ; ”96 end97 unless opts [ : cn t de t s ] . i n c lude ? opts [ : ds ]98 cp << ” cre (DS) ; ”99 end

100 cp << ” IF (CYCLES AT LEVEL >= #{c y c l e s t o r ema i n i n l e v e l }) THEN”101 cp << ” CYCLES AT LEVEL := 0 ; /∗ a l low f a l l through to dogs l e v e l change ∗/”102 cp . add ” ELSE”103 cp . add ” GOTO ADJUST LEVEL; /∗ make sure the new l e v e l i s f u l l y implemented ∗/”104 cp . add ” END; ”105 cp . add ”END; ”106107 cp . add verb ”/∗ Enable dogs i f north or south bounds are reached . I f dogs i s enabled

but we are below enable−bounds , keep dogs enabled un t i l the lower thre sho ld i sreached ∗/”

108 cp << ”DOGS ENABLED := ” +109 ” ( (DN CNT >= ENABLE CNT) OR (DS CNT >= ENABLE CNT) AND (DN OCC >= ENABLE OCC) OR (

DS OCC >= ENABLE OCC) ) ”+110 ”OR DOGS ENABLED AND ” +111 ” ( (DN CNT > DISABLE CNT) OR (DS CNT > DISABLE CNT) AND (DN OCC > DISABLE OCC) OR (

DS OCC > DISABLE OCC) ) ; ”112 cp << ”IF DOGS FORCE DISABLE OR NOT DOGS ENABLED THEN”113 cp << ” DOGS LEVEL := 0 ; ”114 cp . add ”ELSE”115 for l e v e l in ( 0 . . . DOGS LEVELS)116 cp << ” IF DOGS LEVEL = #{ l e v e l } THEN”117 cp << ” IF #{opts [ : o c c de t s ] . map{| det | ” (D#{ de t } OCC > #{occ bounds [ : upper ] [

l e v e l ]} ) ”} . j o i n ( ’ OR ’) } OR #{op t s [ : c n t d e t s ] . map{| de t | ”(D#{de t } CNT > #{cn t bounds [ : upper ] [ l e v e l ]} ) ”} . j o i n ( ’ OR ’) } THEN”

118 cp << ” NEW DOGS LEVEL := #{ l e v e l +1};”119 cp . add ” END; ”120 i f l e v e l > 0121 cp << ” IF #{opts [ : o c c de t s ] . map{| det | ” (D#{ de t } OCC < #{occ bounds [ : l ower ] [

l e v e l ]} ) ”} . j o i n ( ’ AND ’) } AND #{op t s [ : c n t d e t s ] . map{| de t | ”(D#{de t } CNT < #{cn t bounds [ : l ower ] [ l e v e l ]} ) ”} . j o i n ( ’ AND ’) } THEN”

122 cp << ” NEW DOGS LEVEL := #{ l e v e l −1};”123 cp . add ” END; ”124 end125 cp . add ” END; ”126 end127 cp . add ”END; ”128 cp . add verb ” /∗|NEW DOGS LEVEL − DOGS LEVEL | = 0 or 1 ∗/”129 cp . add verb ”ADJUST LEVEL: IF DOGS LEVEL <> NEW DOGS LEVEL THEN /∗ DOGS l e v e l changes

are implemented by increments o f +− 5 seconds per cy c l e ∗/”130 cp << ” IF DOGS LEVEL < NEW DOGS LEVEL THEN”131 cp << ” DOGS LEVEL STEP := DOGS LEVEL + 0 . 5 ; ”132 cp . add ” ELSE”133 cp << ” DOGS LEVEL STEP := DOGS LEVEL − 0 . 5 ; ”134 cp . add ” END; ”135 cp << ” DOGS LEVEL := DOGS LEVEL STEP; ”136 cp . add ”END”137 cp . add verb ’PROG ENDE: . ’138139 cp . wr i t e F i l e . j o i n ( outputdir , ”DOGS MASTER #{opts [ : name ] . upcase } . vap” )140 end141142 Replacement = {221 => ’ ae ’ , 248 => ’ oe ’ , 206 => ’ aa ’} # be sure to use c ha r a c t e r codes

f o r non−a s c i i char s143144 # Below i s code f o r g en e r a t i n g a DOGS SLAVE c o n t r o l l e r in VAP145 def gen vap sc , outputdir , program name , o f f s e t = ni l146 cp = CodePrinter . new147148 cp . add verb g e t g en e r a t e d i n f o149150 name = sc . name . downcase . gsub ( ’ ’ , ’ ’ )151 cp . add verb ”PROGRAM #{name . gsub ( / [ ˆ a−z ] / ) { |match | Replacement [ match . t o s [ 0 ] ] } } ; /∗

#{program name} ∗/”152 cp . add verb ’ ’153154 s tage s = sc . s t age s ( program name )155156 un iq s t ag e s = s tage s . uniq . f i n d a l l {| s | s . i n s t a n c e o f ? Stage}

106

157158 i f USEDOGS159 # prepare t h e s p l i t o f DOGS e x t r a t ime between major and minor s t a g e s160 minor s tages = un iq s t ag e s . f i n d a l l {| s | sc . p r i o r i t y ( s ) == MINOR}161162 # make sure t h a t e x a c t l y DOGS TIME w i l l be d i s t r i b u t e d to ex t ended s t a g e s163 minor fac t = minor s tages . l ength > 1 ? 1 : 2164 # a r t e r i a l o p t im i z a t i o n : t h e r e i s a lways e x a c t l y 1 major p r i o r i t y s t a g e165 majo r f ac t = DOGS TIME − minor fac t ∗ minor s tages . l ength166 end167168 cp . add verb ”CONST”169 # c a l c u l a t e s t a g e l e n g t h s170 for s tage in un iq s t ag e s171 cp . add verb ”\tSTAGE#{s tage } TIME = #{s t age s . f i n d a l l {| s | s == stage } . l ength } , ”172 end173 i f sc . h a s bu s p r i o r i t y ?174 cp . add verb ”\tBUSDETN = 1#{sc . bu s de t e c to r n } , ” # a r r i v a l d e t e c t o r175 cp . add verb ”\tBUSDETS = 1#{sc . bu s d e t e c t o r s } , ” # a r r i v a l d e t e c t o r176 cp . add verb ”\tBUSDETN END = 2#{sc . bu s de t e c to r n } , ” # depar t u r e d e t e c t o r177 cp . add verb ”\tBUSDETS END = 2#{sc . bu s d e t e c t o r s } , ” # depar t u r e d e t e c t o r178 end179 # un l e s s t h e r e are c y c l e t imes per dogs l e v e l , use t h e t r a n s y t c y c l e t imes , which are180 # s t o r e d in t h e s i g n a l c o n t r o l l e r181 cp . add verb ”\tBASE CYCLE TIME = #{sc . program [ program name ] [ : c y c l e t ime ]} ” +182 (Hash === o f f s e t ? ’ ’ : ” ,\n\tOFFSET = #{sc . program [ program name ] [ : o f f s e t ]} ” ) + ” ; ”183 cp . add verb ’ ’184185 i f USEDOGS186 cp . add verb ’DOGS LEVEL := Marker get (1 ) ; ’187 cp . add verb ’TIME := Marker get (2 ) ; ’188 end189190 # c a l c u l a t e s t a g e end t imes based on s t a g e l e n g t h s , r e s p e c t i n g dogs l e v e l and bus

p r i o r i t i e s191 for i in ( 0 . . . un i q s t ag e s . l ength )192 prev , cur = un iq s t ag e s [ i −1] , un i q s t ag e s [ i ]193 s tage end = ” stage#{cur} end := STAGE#{cur} TIME”194195 i f USEDOGS196 curpr i o = sc . p r i o r i t y cur197 # as s i g n p r i o r i t y to major and minor s t a g e s198 stage end += ” + #{curp r i o == MAJOR ? majo r f ac t : minor fac t } ∗ DOGS LEVEL” i f

curp r i o != NONE199 end200201 # account f o r t h e i n t e r s t a g e l e n g t h f o r a l l s t a g e ends bu t t h e f i r s t s t a g e202 stage end += ” + i s l (#{prev},#{ cur }) + stage#{prev} end” i f cur != un iq s t ag e s . f i r s t203204 # i n s e r t bus p r i o r i t y f o r t h e f i r s t s t a g e (=main d i r e c t i o n ) , i f t h e SC has i t205 i f sc . h a s bu s p r i o r i t y ?206 i f sc . i s r e c i p i e n t ? cur207 stage end += ” + #{BUS TIME} ∗ BUS PRIORITY”208 e l s i f sc . i s dono r ? cur209 # the bus green e x t e n s i o n i s s u b t r a c t e d from the su b s e quen t s t a g e210 # in the compensat ion cyc l e , t h e e x t e n s i o n i s g i v en to t h i s s t a g e211 stage end += ” − #{BUS TIME} ∗ BUS PRIORITY”212 end213 end214 cp . add verb stage end + ’ ; ’215 end216217 cp . add verb ’ ’218219 i f USEDOGS220 # dogs master sync and l o c a l t im ing c a l c u l a t i o n s221222 i f Hash === o f f s e t # map from dogs l e v e l t o cu r r en t o f f s e t223 o f f s e t . s o r t . each do | dog s l e v e l , o f f s e t |224 cp << ”IF DOGS LEVEL = #{dog s l e v e l } THEN”225 cp << ” OFFSET := #{o f f s e t } ; ”226 cp . add ’END; ’227 end228 end229 cp << ’ IF NOT SYNC THEN’230 cp << ’ IF (TIME − 1) = OFFSET THEN’231 cp << ’ SYNC := 1 ; ’232 cp << ’ TRACE(ALL) ; ’ i f ENABLE VAP TRACING [ : s l av e ]233 cp . add ’ END; ’234 cp . add ’ GOTO PROG ENDE’235 cp . add ’END; ’236 else237 # l o c a l t ime r e q u i r e d238 cp << ’TIME := OLDTIME + 1 ; ’239 cp << ’OLDTIME := TIME; ’240 end241242 cp << ”C := BASE CYCLE TIME + #{DOGS TIME} ∗ DOGS LEVEL; ” i f USEDOGS

107

243 cp << ” t l o c := (TIME − OFFSET) % #{USEDOGS ? ’C ’ : ’BASE CYCLE TIME ’} + 1; ”244 cp << ’ SetT ( t l o c ) ; ’245246 i f sc . h a s bu s p r i o r i t y ?247248 # a r r i v a l d e t e c t i o n249 cp << ”IF Detect ion (BUSDETN) THEN”250 cp << ” BUS FROM NORTH := 1 ; ”251 cp . add ”END; ”252 cp << ”IF Detect ion (BUSDETS) THEN”253 cp << ” BUS FROM SOUTH := 1 ; ”254 cp . add ”END; ”255256 # depar t u r e d e t e c t i o n257 cp << ”IF Detect ion (BUSDETN END) THEN”258 cp << ” BUS FROM NORTH := 0 ; ”259 cp . add ”END; ”260 cp << ”IF Detect ion (BUSDETS END) THEN”261 cp << ” BUS FROM SOUTH := 0 ; ”262 cp . add ”END; ”263264 # Rec i p i en t i s t h e s t a g e f o r t h e main d i r e c t i o n where bu se s come265 # To g i v e p r i o r i t y we r e q u i r e t h a t t h e bus a r r i v e s wh i l e in266 # s t a g e 1 and gran t t h e s t a g e e x t r a t ime so t h a t t h e bus may j u s t s qu e e z e a c ro s s .267 # Only s t a r t p r i o r i t y i f BUS PRIORITY = 0 i e . we are not a l r e a d y p r i o r i t i z i n g or

compensat ing .268269 # Any bus p r i o r i t i z a t i o n must be done w i t h i n t h e main ( a r t e r i a l ) s t a g e270 cp << ”IF stga (#{ sc . r e c i p i e n t s t a g e }) THEN”271 # check f o r d e a c t i v a t i o n o f bus p r i o r i t y because bu se s s i g n a l l e d t h ey no l on g e r need

i t272 cp << ” IF (BUS PRIORITY = 1) AND (NOT BUS FROM NORTH) AND (NOT BUS FROM SOUTH)

AND (T < ( s tage#{sc . r e c i p i e n t s t a g e } end − #{BUS TIME}) ) THEN”273 cp << ’ BUS PRIORITY := 0 ; ’274 cp . add ’ END; ’275276 # check i f bus p r i o r i t y s hou l d be enab l e d277 cp << ’ IF (BUS FROM NORTH OR BUS FROM SOUTH) AND (BUS PRIORITY = 0) THEN’278 cp << ’ BUS PRIORITY := 1 ; ’279 cp . add ’ END; ’280 cp . add ’END; ’281 end282283 # check s f o r i n t e r s t a g e runs284 for i in ( 0 . . . un i q s t ag e s . l ength )285 cur , nxt = un iq s t ag e s [ i ] , un i q s t ag e s [ ( i +1) % un iq s t ag e s . l ength ]286 # check t h a t from−s t a g e i s running − may not be due to dogs l e v e l change !287 cp << ”IF stga (#{cur }) THEN”288 cp << ” IF T = stage#{cur} end THEN”289 cp . add verb ” IS#{cur} #{nxt } : I s (#{cur},#{nxt }) ; ”290 i f sc . h a s bu s p r i o r i t y ?291 i f sc . i s dono r ? cur292 cp << ’ IF BUS PRIORITY = −1 THEN’293 cp << ’ BUS PRIORITY := 0 ; /∗ two cy c l e s o f bus p r i o r i t y has f i n i s h e d

and the donor r e c e i v ed i t s compensation ∗/ ’294 cp . add ’ END; ’295 end296 i f cur == un iq s t ag e s . l a s t297 cp << ’ IF BUS PRIORITY = 1 THEN’298 cp << ’ BUS PRIORITY := −1; /∗ subt rac t the extra bus time in next cy c l e

∗/ ’299 cp . add ’ END; ’300 end301 end302 cp . add ’ END’303 cp . add ”END” + (( Pro j ec t != ’ dtu ’ and i < un iq s t ag e s . length −1) ? ’ ; ’ : ’ ’ )304 end305306 i f Pro jec t == ’ dtu ’307 # check s f o r missed i n t e r s t a g e runs due to dogs l e v e l d own s h i f t s308 # note t h i s w i l l cause unexpec t ed s i g n a l changes ( red /amber −> red )309 # i f t h e s imu l a t i o n r e s o l u t i o n i s 1 s t e p per sim second or worse ( l e s s )310 for i in ( 1 . . . un i q s t ag e s . l ength )311 prev , cur = un iq s t ag e s [ i −1] , un i q s t ag e s [ i ]312 cp << ”#{ i == 1 ? ’ ; ’ : ’ ’} IF stga (#{prev }) AND (T > ( s tage#{prev} end + i s l (#{

prev},#{ cur }) ) ) AND ((T + #{MIN STAGE LENGTH}) < s tage#{cur} end ) THEN”313 cp . add ” GOTO IS#{prev} #{cur } ; ”314 cp . add ”END#{( i < un iq s t ag e s . length −1) ? ’ ; ’ : ’ ’} ”315 end316 end317 cp . add verb ’PROG ENDE: . ’318319 cp . wr i t e F i l e . j o i n ( outputdir , ”#{name} . vap” )320 end321322 def gen pua sc , outputdir , program name323 cp = CodePrinter . new324 cp . add verb ’$SIGNAL GROUPS ’

108

325 cp . add verb ’ $ ’326 for grp in sc . groups . s o r t {| g1 , g2 | g1 . number <=> g2 . number}327 cp . add verb ”#{grp . name}\ t#{grp . number}”328 end329330 cp . add verb ’ ’331 cp . add verb ’$STAGES ’332 cp . add verb ’ $ ’333334 s tage s = sc . s t age s program name335 un iq s t ag e s = s tage s . uniq . f i n d a l l {| s | s . i n s t a n c e o f ? Stage}336337 for s tage in un iq s t ag e s338 cp . add verb ” Stage #{s tage . number}\ t#{s tage . groups .map{| g | g . name} . j o i n ( ’ ’ ) }”339 cp . add verb ” red\ t#{( sc . groups − s tage . groups ) .map{| g | g . name} . j o i n ( ’ ’ ) }”340 end341342 cp . add verb ’ ’343 cp . add verb ’$STARTING STAGE ’344 cp . add verb ’ $ ’345 cp . add verb ’ Stage 1 ’346 cp . add verb ’ ’347348 isnum = 0349 for t in ( 2 . . sc . program [ program name ] [ : c y c l e t ime ] )350 next unless s t age s [ t−1] != s tage s [ t ] and s t age s [ t −1] . i n s t a n c e o f ?( Stage )351 isnum += 1352 cp . add verb ”$INTERSTAGE#{isnum}”353354 # f i n d the l e n g t h o f t h e i n t e r s t a g e355 i s l e n = 0356 fromstage = s tage s [ t−1]357 i f s t age s [ t ] . i n s t a n c e o f ?( Stage )358 # i n t e r s t a g e happens from one c y c l e second to t h e nex t359 to s tage = s tage s [ t ]360 else361 # t h i s i s an ex t ended i n t e r s t a g e362 i s l e n += 1 while s t age s [ t+i s l e n ] == stage s [ t ]363 to s tage = s tage s [ t+i s l e n +1]364 end365366 cp . add verb ”Length [ s ] : #{ i s l e n }”367 cp . add verb ”From Stage : #{f romstage}”368 cp . add verb ”To Stage : #{to s tage | | un iq s t ag e s . f i r s t }” # wrap around c y c l e369 cp . add verb ”$\ tredend\ tgrend ”370371 # cap tu r e a l l changes in t h i s i n t e r s t a g e372 for i t in ( 0 . . i s l e n )373 for grp in sc . groups374 # compare t h e c o l o r s o f t h e p r e v i o u s and cu r r en t heads375 tp = t + i t376 case [ grp . c o l o r ( tp , program name ) , grp . c o l o r ( tp+1,program name ) ]377 when [AMBER,AMBER]378 # t h i s i s t h e 2nd amber second , red ended 2 s e c s ago379 cp . add verb ”#{grp . name}\ t#{ i t − 1}\ t127 ”380 when [RED,GREEN]381 # d i r e c t change from red to green382 cp . add verb ”#{grp . name}\ t#{ i t }\ t127 ”383 when [GREEN,RED] , [GREEN,YELLOW]384 # change from green to y e l l ow or385 # t h i s l i g h t became red immed ia te l y386 cp . add verb ”#{grp . name}\ t−127\ t#{ i t }”387 end388 end389 end390391 cp . add verb ’ ’392 end393394 cp . add verb ’$END ’395396 cp . wr i t e F i l e . j o i n ( outputdir , ”#{sc . name . downcase . gsub ( ’ ’ , ’ ’ ) } . pua” )397 end398399 i f Pro jec t == ’ dtu ’400 # c r i t e r i a f o r when DOGS can be enab l e d and d i s a b l e d . measured a g a i n s t dn and ds401402 # in fo rma t i on on master c o n t r o l l e r s403 MasterInfo = [404 {405 : name => ’ Her lev ’ ,406 : dn => 3 , : ds => 14 ,407 : o c c de t s => [ 3 , 1 4 ] , : cn t de t s => [ 3 , 4 , 1 3 , 1 4 ] ,408 : cnt bounds => { : upper => numbers (20 ,13 ,DOGS LEVELS) , : lower => numbers (17 ,11 ,

DOGS LEVELS) } ,409 : occ bounds => { : upper => [ 1 1 , 29 , 45 , 58 , 70 , 80 , 92 , 96 ] , : lower =>

[ 8 , 17 , 35 , 51 , 65 , 74 , 86 , 94 ]}410 } , {

109

411 : name => ’ Glostrup ’ ,412 : dn => 14 , : ds => 1 ,413 : o c c de t s => [ 1 , 2 , 5 , 8 , 9 , 10 , 11 , 12 , 13 , 14 ] , : cn t de t s => [ 1 , 2 , 5 , 8 , 9 , 10 , 11 , 12 , 13 , 14 ] ,414 : cnt bounds => { : upper => numbers (23 ,15 ,DOGS LEVELS) , : lower => numbers (19 ,14 ,

DOGS LEVELS) } ,415 : occ bounds => { : upper => [ 2 0 , 41 , 53 , 62 , 78 , 84 , 90 , 96 ] , : lower =>

[ 15 , 35 , 44 , 54 ,67 ,76 ,81 ,90 ]}416 }417 ]418 end419420 def g e n e r a t e c o n t r o l l e r s viss im , u s e r op t s = {} , outputd i r = Vi s s im d i r421 d e f au l t op t s = { : verbose => true}422 opts = de f au l t op t s . merge ( u s e r op t s )423424 o f f s e t s p e r c y c l e t im e = Hash === opts [ : o f f s e t ]425426 i f Pro jec t == ’ dtu ’427 for master opts in MasterInfo428 # i f t h e r e are o f f s e t s per c y c l e t ime remain a t l e a s t 3 c y c l e s in each l e v e l429 # othe rw i s e , a l l ow l e v e l change a f t e r each c y c l e t ime has ended ( o r i g i n a l dogs )430 gen master opts . merge ( master opts ) , o f f s e t s p e r c y c l e t im e ? 4 : 2 , outputd i r431 end432 end433434 buspr io r = i f opts [ : bu sp r i o r i t y ]435 # f e t c h t h e bus d e t e c t o r s a t t a c h e d to t h i s i n t e r s e c t i o n , i f any436 DB[ ”SELECT CLNG(INSECTS . number ) AS [ number ] ,437 CSTR( [ Detector North Su f f i x ] ) AS bus detec tor n ,438 CSTR( [ Detector South Su f f i x ] ) AS bus de t e c to r s ,439 CLNG( [ Donor Stage ] ) as donor stage ,440 CLNG( [ Rec ip i ent Stage ] ) as r e c i p i e n t s t a g e441 FROM [ busp r i o r i t y$ ] AS BUSP442 INNER JOIN [ i n t e r s e c t i o n s $ ] As INSECTS ON INSECTS .Name = BUSP. I n t e r s e c t i o n ” ] .

a l l443 else ; [ ] ; end444445 for sc in v i s s im . c o n t r o l l e r s . f i n d a l l {| x | x . has p lans ?}446 buspriorow = buspr io r . f i nd {| r | r [ : number ] == sc . number}447 i f opts [ : bu sp r i o r i t y ] and buspriorow448 sc . update buspriorow . r e t a i n k ey s ! ( : bus detec tor n , : bu s de t e c to r s , : donor stage , :

r e c i p i e n t s t a g e )449 # put s ”#{ sc } : ”450 # put s ” donor : #{sc . d ono r s t a g e }”451 # put s ” r e c i p i e n t : #{sc . r e c i p i e n t s t a g e }”452 else453 sc . update : bu s de t e c to r n => nil , : b u s d e t e c t o r s => nil , : donor s tage => nil , :

r e c i p i e n t s t a g e => ni l454 end455 puts ”Generating VAP and PUA fo r #{sc}” i f opts [ : verbose ]456 gen vap sc , outputdir , o f f s e t s p e r c y c l e t im e ? opts [ : o f f s e t ] [ sc ] : sc . o f f s e t # map

from dogs l e v e l t o o f f s e t or n i l457 gen pua sc , outputd i r458 end459 end460461 i f FILE == $0462 rows = [ [ ’ Area ’ , ’ Detectors ’ , ’Type ’ , ’Bound ’ , ’ Thresholds ’ ] ]463 typename = { : cnt => ’ Counting ’ , : occ => ’ Occupancy ’}464 MasterInfo . each do |master |465 [ : cnt , : occ ] . each do | det type |466 [ : lower , : upper ] . each do | bound |467 rows << [468 master [ : name ] ,469 master [ ”#{det type } de t s ” . to sym ] . j o i n ( ’ ’ ) ,470 typename [ det type ] ,471 bound . t o s . c a p i t a l i z e ,472 master [ ”#{det type } bounds” . to sym ] [ bound ] . j o i n ( ’ ’ )473 ]474 end475 end476 end477478 puts t o t ex ( rows , : l a b e l => ’ tab : thva l s ’ , : capt ion => ’DOGS de t e c t o r s and thre sho ld

va lues . Occupancy de t e c to r th r e sho ld s are in percent and counting th r e sho ld s innumber o f v e h i c l e s ( per cy c l e ) . ’ )

479480 # v i s s im = Vissim . new481 # g e n e r a t e c o n t r o l l e r s ( v i s s im , : b u s p r i o r i t y => f a l s e , : d o g s ena b l e d => t r u e )482 end

Listing 11: vissim.rb1 r equ i r e ’ const ’2 r e qu i r e ’ network ’3 r e qu i r e ’ s i g n a l ’4 r e qu i r e ’ v i s s im e lem ’

110

5 r equ i r e ’ v i s s im d i s t an c e ’6 r e qu i r e ’ v i s s im rou t e s ’7 r e qu i r e ’ v i s s im input ’89 # v i s s im e lement names . match any th ing t h a t i s n ’ t t h e l a s t q u o t a t i o n mark

10 NAMEPATTERN = ’ \” ( [ ˆ\” ]∗ ) \” ’11 SECTIONPATTERN = /−− ( [ˆ− : ]+) : −−/ # s e c t i o n s t a r t12 COORDINATEPATTERN = ’ (\−?\d+.\d+) (\−?\d+.\d+) ’ # x , y1314 # se c t i o n s , which are parsed from the network f i l e15 # and symbo l s f o r t h e methods , which hand l e them16 SECTION PARSERS = {17 ’ Links ’ => : p a r s e l i n k s ,18 ’ Connectors ’ => : pa r se connector s ,19 ’ S i gna l Con t r o l l e r s (SC) ’ => : p a r s e c o n t r o l l e r s ,20 ’Nodes ’ => : parse nodes ,21 ’ Inputs ’ => : p a r s e i npu t s22 }2324 class Vissim25 a t t r r e ad e r : connectors , : d e c i s i on s , : c o n t r o l l e r s , : nodes , : inputs26 def i n i t i a l i z e i n p f i l e = Default network27 inp = IO . r e ad l i n e s ( i n p f i l e ) .map ! { | l i n k | l i n k . s t r i p } . d e l e t e i f {| l i n k | l i n k . empty?}2829 # f i n d r e l e v a n t s e c t i o n s o f t h e v i s s im f i l e30 s e c t i o n s t a r t = sect ion name = ni l31 inp . each with index do | l ink , i |32 next unless l i n k =˜ SECTIONPATTERN33 i f s e c t i o n s t a r t34 i f par se r = SECTION PARSERS[ sect ion name ]35 # found a pa r s e r i n t e r e s t e d in t h e s e c t i o n36 send parser , inp [ s e c t i o n s t a r t +2 . . . i ]37 end38 s e c t i o n s t a r t = i39 sect ion name = $140 else # f i r s t occurrence o f s e c t i o n s t a r t41 s e c t i o n s t a r t = i42 sect ion name = $143 end44 end4546 # remove non−i npu t l i n k s which cannot be reached47 @links map . d e l e t e i f do |n , l i n k |48 # a pr e d e c e s s o r e x i s t s i f t h e r e i s a connec tor to t h i s l i n k49 not ( l i n k . input ? or l i n k . i s bu s i npu t ) and not @connectors . any ?{| c | c . t o l i n k ==

l i nk }50 end5152 # remove a l l ou t g o in g connec t o r s which no l on g e r have a from l i n k53 @connectors . d e l e t e i f {| c | @links map [ c . f r om l ink . number ] . ni l ?}5455 # no t i f y t h e l i n k s o f t h e i r ou t go in g connec t o r s56 @connectors . each {| conn | conn . f r om l ink . outgo ing connec to r s << conn}5758 i f Pro jec t == ’ dtu ’59 # at tempt to mark l i n k s as a r t e r i a l60 # and note t h e d i r e c t i o n o f t h e l i n k ;61 # t h i s i s used by t h e s i g n a l o p t im i z a t i o n r o u t i n e s62 sc1 = ARTERY[ : sc1 ] [ : scno ]63 sc2 = ARTERY[ : sc2 ] [ : scno ]64 from1 = ARTERY[ : sc1 ] [ : f r om d i r e c t i on ] # primary from d i r e c t i o n65 from2 = ARTERY[ : sc2 ] [ : f r om d i r e c t i on ]6667 # a r t e r i a l end−to−end rou t e must t r a v e r s e t h e s e numbered i n t e r s e c t i o n s in order68 s c s t o p a s s = ( sc1 . . sc2 )6970 # f i n d the d e c i s i on s , which must be t r a v e r s e d in t h e a r t e r y rou t e71 # always through−go ing d e c i s i o n s .72 # in the end t h e r e shou l d be e x a c t l y two keys = d i r e c t i o n s73 # in the hash and the number o f d e c i s i o n s would norma l l y corre spond to t h e74 # number o f c o n t r o l l e r s in t h e a r t e r y .75 a r t e r y d e c i s i o n s = Hash . new{|h , k | h [ k ] = [ ] }76 @dec i s ions . each do | d |77 i f s c s t o p a s s === d . i n t e r s e c t i o n and d . turning mot ion == ’T ’ and [ from1 , from2 ] .

i n c lude ?(d . f r om d i r e c t i on )78 a r t e r y d e c i s i o n s [ d . f r om d i r e c t i on ] << d79 end80 end8182 # loo k f o r r ou t e s pa s s i n g t h e a r t e r y d e c i s i o n s83 route s = g e t f u l l r o u t e s8485 for f r om d i r e c t i on , d e c i s i o n s in a r t e r y d e c i s i o n s86 a r t e r y r ou t e s = route s . f i n d a l l {| r | d e c i s i o n s . a l l ?{|d | r . d e c i s i o n s . i n c lude ?(d)}}87 puts ”Warning : no a r t e ry route s were found ! ” i f a r t e r y r ou t e s . empty?88 puts ”Warning : #{a r t e r y r ou t e s . s i z e } route s were found from #{ f r om d i r e c t i on } ;

expected only one . ” i f a r t e r y r ou t e s . s i z e > 189 i f a r t e r y r ou t e s . s i z e == 1

111

90 route = a r t e r y r ou t e s . f i r s t9192 # mark l i n k s and connec t o r s in t h e a r t e r y rou t e so t h a t t h e s i g n a l c o n t r o l l e r s

may see which93 # d i r e c t i o n they g i v e green to .94 route . ma rk a r t e r i a l f r om d i r e c t i on95 end96 end9798 # c o n t r o l l e r p o s i t i o n s r e l a t i v e to f i r s t sc in primary d i r e c t i o n99 f i r s t s c = @con t r o l l e r s . f i nd {| sc | sc . number == sc1} | | r a i s e ( ”Could not f i nd f i r s t

c o n t r o l l e r with number #{sc1}” )100 c o n t r o l l e r s w i t h p l a n s . each do | sc |101 sc . update : p o s i t i o n => d i s tance ( f i r s t s c , sc )102 end103 end104 end105 def i n pu t l i n k s ; l i n k s . f i n d a l l {| l | l . input ?} ; end106 def e x i t l i n k s ; l i n k s . f i n d a l l {| l | l . e x i t ?} ; end107 def l i n k s ; @links map . va lues ; end108 def l i n k (number ) ; @links map [ number ] ; end109 def c o n t r o l l e r s w i t h p l a n s ; @con t r o l l e r s . f i n d a l l {| sc | sc . has p lans ?} ; end110 def parse nodes ( inp )111 r equ i r e ’ measurements ’112 @nodes = [ ]113 while l i n e = inp . s h i f t114 @nodes << Node . new ! ( $1 . t o i , : name => $2 ) i f l i n e =˜ /NODE\ s+(\d+)\ s+NAME\ s+#{

NAMEPATTERN}/115 end116 @nodes . s o r t117 end118 # parse s i g n a l c o n t r o l l e r s and t h e i r groups + heads119 def p a r s e c o n t r o l l e r s ( inp )120 plans = begin121 DB[ ”SELECT122 CLNG(INSECTS . Number) As isnum ,123 PLANS. program ,124 [ Group Name ] As grpname ,125 CLNG( [ Group Number ] ) As grpnum ,126 #{USEDOGS ? ’ p r i o r i t y , ’ : ’ ’}127 CLNG( [ Red End ] ) As red end ,128 CLNG( [ Green End ] ) As green end129 FROM [ plans$ ] As PLANS130 INNER JOIN [ i n t e r s e c t i o n s $ ] As INSECTS ON PLANS. I n t e r s e c t i o n = INSECTS .Name” ] . a l l131 rescue Exception => e ; puts e . message ; [ ] ; end # No s i g n a l p l an s found132133 s c i n f o = begin134 DB[ ”SELECT135 OFFSETS. program ,136 CLNG(INSECTS . Number) As isnum ,137 CLNG(PROGRAMS. [ Cycle Time ] ) As cyc l e t ime ,138 CLNG( o f f s e t ) as o f f s e t139 FROM ( ( [ o f f s e t s $ ] As OFFSETS140 INNER JOIN [ i n t e r s e c t i o n s $ ] As INSECTS ON INSECTS .Name = OFFSETS. I n t e r s e c t i o n )141 INNER JOIN [ programs$ ] AS PROGRAMS ON OFFSETS. Program = PROGRAMS.Name) ” ] . a l l142 rescue Exception => e ; puts e . message ; [ ] ; end # No s i g n a l c o n t r o l l e r s found143144 @con t r o l l e r s = [ ]145146 while s c l i n e = inp . s h i f t147 next unless s c l i n e =˜ /ˆSCJ (\d+)\ s+NAME #{NAMEPATTERN}/148149 sc = S i gna lCon t r o l l e r . new ! ( $1 . t o i , : name => $2 )150151 # parse s i g n a l groups and s i g n a l heads152 # u n t i l t h e nex t s i g n a l c o n t r o l l e r s t a t emen t i s found or we run out o f l i n e s153 while l i n e = inp . s h i f t154 i f l i n e =˜ /ˆSCJ/ # s t a r t o f new SC d e f i n i t i o n155 inp . i n s e r t (0 , l i n e ) # put l i n e back in f r o n t156 break157 end158159 # f i n d the s i g n a l groups160 i f l i n e =˜ /ˆSIGNAL GROUP\ s+(\d+)\ s+NAME\ s+#{NAMEPATTERN}\ s+SCJ\ s+#{sc . number}.+

TRED AMBER\ s +([\d \ . ]+) \ s+TAMBER\ s +([\d \ . ]+) /161162 sc . add group ( $1 . t o i ,163 : name => $2 ,164 : tred amber => $3 . t o i ,165 : tamber => $4 . t o i )166167 e l s i f l i n e =˜ /SIGNAL HEAD\ s+(\d+)\ s+NAME\ s+#{NAMEPATTERN}\ s+LABEL\ s +0.00\ s

+0.00\ s+SCJ\ s+#{sc . number}\ s+GROUP\ s+(\d+)/168 num = $1 . t o i169 opts = { : name => $2}170 grpnum = $3 . t o i171 grp = sc . group (grpnum) | |

112

172 r a i s e ( ” S igna l head ’#{opts [ : name ]} ’ i s miss ing i t s group #{grpnum} atc o n t r o l l e r ’#{ sc } ’ ” )

173174 l i n e =˜ /POSITION LINK\ s+(\d+)\ s+LANE\ s+(\d)\ s+AT\ s+(\d+\.\d+)/175176 pos l ink num = $1 . t o i # heads can be p l a c ed on bo th l i n k s and connec to r s (

RoadSegment )177 opts [ : p o s i t i o n l i n k ] = l i n k ( pos l ink num ) | |178 @connectors . f i nd {| c | c . number == pos l ink num} | |179 r a i s e ( ” Pos i t i on l i n k #{pos l ink num} f o r head #{num} at #{sc} could not be

found !\ nLine parsed : ’#{ l i n e } ’ ” )180181 opts [ : l ane ] = $2 . t o i182 opts [ : at ] = $3 . t o f183184 grp . add head (num, opts )185 end186 end187188 # enr i c h t h i s s i g n a l c o n t r o l l e r w i th s i g n a l p lans , i f any189 scrows = s c i n f o . f i n d a l l {| r | r [ : isnum ] == sc . number} # row f o r sc f o r each program

( c y c l e time , . . . )190 sc program = {}191 for program in scrows .map{| r | r [ : program ] } . uniq192 s e t t i n g s = scrows . f i nd {| r | r [ : program ] == program}193 sc program [ program ] = s e t t i n g s . r e t a i n k ey s ! ( : cyc l e t ime , : o f f s e t )194 end195196 sc . update : program => sc program unless sc program . empty?197198 for grp in sc . groups199 grp program = {} #200 for row in plans . f i n d a l l {| r | r [ : isnum ] == sc . number and r [ : grpnum ] == grp .

number}201 grp program [ row [ : program ] ] = row . r e t a i n k ey s ! ( : red end , : green end , : p r i o r i t y )202 end203 grp . update ( : program => grp program ) unless grp program . empty?204 end205206 @con t r o l l e r s << sc207 end208 @con t r o l l e r s . s o r t !209 end210 def par s e connec to r s ( inp )211 @connectors = [ ]212213 while conn l i n e = inp . s h i f t214 next unless conn l i n e =˜ /ˆCONNECTOR\ s+(\d+) NAME #{NAMEPATTERN}/215 number = $1 . t o i216 opts = { : name => $2}217218 inp . s h i f t =˜ /FROM LINK (\d+) LANES (\d )+AT (\d+\.\d+)/219 opts [ : f r om l ink ] = l i n k ( $1 . t o i )220 opts [ : f r om lanes ] = $2 . s p l i t ( ’ ’ ) .map{| s t r | s t r . t o i }221 opts [ : a t f r om l i nk ] = $3 . t o f222223 s e t o v e r p o i n t s ( opts , inp )224225 inp . s h i f t =˜ /TO LINK (\d+) LANES (\d )+AT (\d+\.\d+)/226 opts [ : t o l i n k ] = l i n k ( $1 . t o i )227 opts [ : t o l a n e s ] = $2 . s p l i t ( ’ ’ ) .map{| s t r | s t r . t o i }228 opts [ : a t t o l i n k ] = $3 . t o f229230 # loo k f o r any c l o s e d to d e c l a r a t i o n s ( t h ey are not mandatory )231232 s e t c l o s e d t o ( opts , inp )233234 # check i f t h i s connec tor i s a d e c i s i o n235 conn = i f opts [ : name ] =˜ / ( [NSEW] ) (\d+) ( [LTR] ) (\d+)?/236 dec id = ”#{$1}#{$2}#{$3}” # de c i s i o n i d e n t i f i e r237238 opts [ : f r om d i r e c t i on ] = $1239 opts [ : i n t e r s e c t i o n ] = $2 . t o i240 opts [ : turn ing mot ion ] = $3241 opts [ : weight ] = $4 ? $4 . t o i : ni l242243 # Ex t ra c t i n f o rma t i on on an op t i ona l , a l t e r n a t i v e244 # de c i s i o n po i n t which t h i s d e c i s i o n shou l d o r i g i n from245 opts [ : name ] =˜ /decide−at ( [NSEW] ) (\d+)/246 opts [ : d e c i d e f r om d i r e c t i o n ] = $1 | | opts [ : f r om d i r e c t i on ]247 opts [ : d e c i d e a t i n t e r s e c t i o n ] = $2 ? $2 . t o i : opts [ : i n t e r s e c t i o n ]248249 # The l i n k a t which t h i s d e c i s i o n shou l d end , i e . drop250 # the a f f e c t e d v e h i c l e s so t h ey may o b t a i n a new rou t e251 opts [ : d r op l i nk ] = l i n k s . f i nd {| l | l . d r op f o r . i n c lude ?( dec id )} | | opts [ : t o l i n k ]252253 Dec i s ion . new ! ( number , opts )254 else

113

255 Connector . new ! ( number , opts )256 end257258 # on ly l i n k s which can be reached are car s and t r u c k s are i n t e r e s t i n g259 @connectors << conn i f conn . a l l ow s p r i v a t e v e h i c l e s ?260 end261262 @dec i s ions = @connectors . f i n d a l l {| c | c . i n s t a n c e o f ?( Dec i s ion ) } . s o r t263264 DB[ ”SELECT clng (INTSECT. number ) as inte r sect ion number ,265 f rom d i r e c t i on , [ Turning Motion ] As turn ,266 [ Period Star t ] As t s t a r t , [ Period End ] As tend ,267 cars , t rucks268 FROM [ counts$ ] As COUNTS269 INNER JOIN [ i n t e r s e c t i o n s $ ] As INTSECT270 ON COUNTS. I n t e r s e c t i o n = INTSECT.Name271 WHERE NOT IsNu l l ( t o d i r e c t i o n ) ” ] . each do | row |272 from = row [ : f r om d i r e c t i on ] [ 0 . . 0 ]273 turn = row [ : turn ] [ 0 . . 0 ]274 i n t e r s e c t i o n = row [ : in t e r s ec t i on number ]275276 dec = @dec i s ions . f i nd do | d |277 d . f r om d i r e c t i on == from and278 d . turning mot ion == turn and279 d . i n t e r s e c t i o n == i n t e r s e c t i o n280 end | | next # Cannot f i n d d e c i s i o n − presumab ly i t s not d e f i n e d281282 i n t e r v a l = In t e r v a l . new(Time . parse ( row [ : t s t a r t ] [ −8 . . −1 ] ) ,Time . parse ( row [ : tend

] [ −8 . . −1 ] ) )283 [ : cars , : t rucks ] . each do | vehtype |284 dec . add f r a c t i on ( i n t e rva l , vehtype , row [ vehtype ] )285 end286 end287 end288289 # Ex t ra c t knot d e f i n i t i o n s f o r l i n k s and connec to r s290 def s e t o v e r p o i n t s opts , inp291 opts [ : o v e r po in t s ] = [ ]292 while l i n e = inp . s h i f t293 i f not l i n e =˜ /ˆOVER/294 inp . i n s e r t (0 , l i n e )295 break296 end297 for ove r par t in l i n e . s p l i t ( ’OVER’ )298 ove r par t . s t r i p !299 next i f ove r par t . empty?300 opts [ : ov e r po in t s ] << Point . new(∗ ove r par t . s p l i t ( ’ ’ ) .map{| s | s . t o f })301 end302 end303 end304 def s e t c l o s e d t o opts , inp305 begin306 l i n e = inp . s h i f t307 end until l i n e . ni l ? or l i n e =˜ /(CLOSED|LINK |CONNECTOR)/308309 opts [ : c l o s e d t o ] = i f $1 == ’CLOSED’310 inp . s h i f t =˜ /VEHICLE CLASSES\ s +([\d ]+)+/311 $1 . s p l i t ( ’ ’ ) .map{| s t r | s t r . t o i }312 else313 inp . i n s e r t (0 , l i n e )314 [ ]315 end316 end317 def pa r s e l i n k s ( inp )318319 # we do a l o t o f l o o kup s on l i n k numbers l a t e r on320 # t h i s map w i l l save t ime .321 @links map = {}322323 while l i n e = inp . s h i f t324 next unless l i n e =˜ /ˆLINK\ s+(\d+) NAME #{NAMEPATTERN}/325326 number = $1 . t o i327 opts = { : name => $2}328329 inp . s h i f t =˜ /LENGTH\ s+(\d+\.\d+)\ s+LANES\ s+(\d+)/330 opts [ : l ength ] = $1 . t o f331 opts [ : l ane s ] = $2 . t o i332333 # e x t r a c t from and to c o o r d i n a t e s334 inp . s h i f t =˜ /FROM\ s+#{COORDINATEPATTERN}/335 opts [ : f rom point ] = Point . new( $1 . t o f , $2 . t o f )336 s e t o v e r p o i n t s ( opts , inp )337338 inp . s h i f t =˜ /TO\ s+#{COORDINATEPATTERN}/339 opts [ : t o po in t ] = Point . new( $1 . t o f , $2 . t o f )340341 s e t c l o s e d t o ( opts , inp )

114

342343 @links map [ number ] = Link . new ! ( number , opts )344 end345346 l i n k i s s q l = ”SELECT CLNG(LINKS . number ) as [ number ] , f r om d i r e c t i on , l i nk type ,

CLNG(INSECTS .Number) AS inte r s ec t i on number347 FROM [ l i n k s $ ] AS LINKS348 INNER JOIN [ i n t e r s e c t i o n s $ ] AS INSECTS ON LINKS . Intersect ion Name =

INSECTS .Name”349350 # enr i c h t h e e x i s t i n g l i n k o b j e c t s w i th data from the da ta ba s e351 DB[ l i n k i s s q l ] . each do | row |352 l i n k = l i n k ( row [ : number ] )353 i f not l i n k354 puts ( ”Warning : l i n k number #{row [ : number ]} was marked as an input l ink , but

could not be found ! ” )355 next356 end357 l i n k . update ( row . r e t a i n k ey s ! ( : f r om d i r e c t i on , : in te r sect ion number , : l i n k t yp e ) )358 end359360 begin # note which l i n k s have bus i n pu t s ( mandatory )361 BUSES. each do | businputrow |362 l i n k ( businputrow [ : i n pu t l i n k ] . t o i ) . i s bu s i npu t = true363 end364 rescue ; end # sk i p bus inpu t l i n k s ; t a b l e was not d e f i n e d ( see BUSES)365 end366 def t o s367 s t r = ” Con t r o l l e r s : #{@cont r o l l e r s . s i z e }\n”368 s t r << ”Links : #{@links map . s i z e }\n”369 s t r << ” − inputs : #{ i n pu t l i n k s . s i z e }\n”370 s t r << ” − bus inputs : #{ l i n k s . f i n d a l l {| l | l . i s bu s i npu t } . s i z e }\n”371 s t r << ” − e x i t s : #{e x i t l i n k s . s i z e }\n”372 s t r << ”Connectors : #{@connectors . s i z e }\n”373 s t r << ” − d e c i s i o n s : #{d e c i s i o n s . s i z e }\n”374 s t r << ”Total l i n k s & connectors : #{@connectors . s i z e + @links map . s i z e }\n”375 s t r << ”Total knots ( over−po int s ) : #{(@connectors+l i n k s ) .map{| r s | r s . ov e r po in t s . s i z e

} . sum}”376 s t r377 end378 def pa r s e i npu t s inp379 @inputs = Inputs . new380 while l i n e = inp . s h i f t381 next unless l i n e =˜ /INPUT (\d+)/382 inp . s h i f t # sk i p NAME, LABEL l i n e383 inp . s h i f t =˜ /LINK (\d+) Q (\d+\.\d+) COMPOSITION (\d+)/384 linknum = $1 . t o i385 quant i ty = $2 . t o f386 comp = $3 . t o i387 inp . s h i f t =˜ /TIME FROM (\d+)\ . 0 UNTIL (\d+)\ .0/388 @inputs << Input . new( l i n k ( linknum ) , $1 . t o i , $2 . t o i , comp => quant i ty )389 end390 end391 end392393 i f FILE == $0394 v i s s im = Vissim . new395 # v i s s im . c o n t r o l l e r s w i t h p l a n s . each do | sc |396 # fo r grp in sc . groups397 # put s grp . program398 # end399 # end400 # rows = [ [ ’# ’ , ’Name ’ , ’ Date Counted ’ ] ]401 # DB[ ’SELECT name , CLNG( number ) as num, coun t da t e FROM [ i n t e r s e c t i o n s $ ] ORDER BY

number ’ ] . each do | row |402 # rows << [ row [ : num] , row [ : name ] , row [ : c oun t da t e ] ?403 # Time . par se ( row [ : c oun t da t e ] . s p l i t ( ’ ’ ) . f i r s t ) . s t r f t i m e (”%d−%m−%Y”) : ’− ’]404 # end405 # put s t o t e x ( rows , : row sep => ”\ r ” , : c ap t i on => ’ Groups f o r main t r a f f i c d i r e c t i o n

as p e r c e i v e d by t r a f f i c s i g n a l d e s i g n e r ’ , : l a b e l => ’ t a b : t r a f f i c c o u n t s ’ )406 end

Listing 12: vissim distance.rb1 class Vissim2 def speed ( fromsc , to s c )3 70 / 3 .6 # km/ t −> m/s4 end5 # Finds t h e d i s t a n c e from the a r t e r i a l s i g n a l head ( s ) in t h i s c o n t r o l l e r6 # to the downstream stop− l i n e o f o t h e r s c7 def d i s tance fromsc , to s c8 return 0 i f fromsc == tosc9

10 # determine which sc i s in t h e downstream11 f r om d i r e c t i on = ge t f r om d i r e c t i o n ( fromsc , to s c )1213 f r om l i nk s = fromsc . s e r v e d a r t e r i a l l i n k s ( f r om d i r e c t i on )

115

14 t o l i n k s = tosc . s e r v e d a r t e r i a l l i n k s ( f r om d i r e c t i on )1516 route s = f r om l i nk s .map{| f r om l ink | f i n d r o u t e s ( f rom l ink , t o l i n k s ) } . f l a t t e n17 r a i s e ”Found no route s from #{ f r om l i nk s } to #{ t o l i n k s } ! ” i f route s . empty?18 r a i s e ”Found mul t ip l e route s (#{ route s . s i z e }) from #{ f r om l i nk s } to #{ t o l i n k s } :\n#{

route s .map{| r | r . t o v i s s im } . j o i n ( ”\n” )}” i f route s . s i z e > 119 route = route s . f i r s t2021 # Find the s i g n a l heads we measure d i s t a n c e between so22 # tha t t h e at−p o s i t i o n can be s u b t r a c t e d from the p o s i t i o n l i n k l e n g t h s2324 f rom l ink , t o l i n k = route . s ta r t , route . e x i t25 heads = { f r om l ink => [ ] , t o l i n k => [ ] }2627 ObjectSpace . ea ch ob j e c t ( S i gna lCon t r o l l e r : : SignalGroup : : SignalHead ) do | head |28 # put s ”Examining #{head } . . ”29 heads [ head . p o s i t i o n l i n k ] << head i f heads . keys . i n c lude ?( head . p o s i t i o n l i n k )30 end3132 # put s ”Found heads : ”33 # fo r l i n k , h e a d l i s t in heads34 # put s l i n k35 # put s h e a d l i s t36 # end37 #38 # Now have a l l t h e heads a t t h e s t a r t and end o f t h e rou t e .39 # They shou l d be p r e t t y c l o s e to each other , bu t we t a k e t h e mean to40 # be f a i r .41 avg at f rom = heads [ f r om l ink ] . map{|h | h . at } .mean42 avg a t to = heads [ t o l i n k ] . map{|h | h . at } .mean4344 # put s ”Avg from #{a v g a t f r om }”45 # put s ”Avg to #{a v g a t t o }”46 # put s ”Route l e n g t h #{rou t e . l e n g t h }”4748 # Routes l e n g t h i n c l u d e s from and to l i n k s l e n g t h .49 # Correc t t h i s now .50 ( route . l ength − avg at f rom − t o l i n k . l ength + avg a t to ) . round51 end52 end

Listing 13: vissim elem.rb12 class VissimElem3 a t t r r e ad e r : number , : name4 def i n i t i a l i z e number ; @number = number ; end5 def type ; s e l f . class . t o s . s p l i t ( ’ : : ’ ) . l a s t ; end6 def t o s ; ”#{type} #{@number}#{@name and @name != ’ ’ ? ” ’#{@name} ’ ” : ’ ’} ” ; end7 def hash ; @number + type . hash ; end8 def eq l ?( other ) ; other . i n s t a n c e o f ?( s e l f . class ) and @number == other . number ; end9 def <=>(other ) ; @number <=> other . number ; end

10 def update opts ; opts . each {|k , v | i n s t a n c e v a r i a b l e s e t ( ”@#{k}” , v ) } ; end11 end

Listing 14: vissim input.rb1 r equ i r e ’ const ’2 r e qu i r e ’ v i s s im output ’3 r e qu i r e ’ v i s s im ’45 class Inputs < Array6 inc lude VissimOutput7 def s e c t i on heade r ; /ˆ−− Inputs : −−/; end8 def g e t by l i n k number9 f i n d a l l {| i | i . l i n k . number == number}

10 end11 def t o v i s s im12 s t r = ’ ’13 inputnum = 114 tbeg in = map{| i | i . t s t a r t } .min15 each do | input |16 l i n k = input . l i n k1718 for veh type , q in input . veh flow map19 s t r << ”INPUT #{inputnum}\n” +20 ” NAME \”#{veh type} from #{ l i n k . f r om d i r e c t i on}#{ l i n k . name . empty? ? ’ ’ :

” ON ” + l i nk . name}\” LABEL 0.00 0.00\n” +21 ” LINK #{ l i n k . number} Q #{q ∗ 0.8} COMPOSITION #{Type map [ veh type ]}\n” +22 ” TIME FROM #{input . t s t a r t − tbeg in } UNTIL #{input . tend − tbeg in }\n”2324 inputnum += 125 end26 end27 s t r

116

28 end29 def to a3031 end32 end3334 class Input35 a t t r r e ad e r : l ink , : t s t a r t , : tend , : veh flow map36 def i n i t i a l i z e l ink , t s t a r t , tend , veh flow map37 @link , @tstart , @tend , @veh flow map = l ink , t s t a r t , tend , veh flow map38 end39 def r a t i o veh type1 , veh type240 f l ow type1 = @veh flow map [ veh type1 ] | | 0 .041 f l ow type1 . t o f / ( f l ow type1 + ( @veh flow map [ veh type2 ] | | 0 . 0 ) )42 end43 def t o s44 ” Input on #{@link} from #{@tstart } to #{@tend } : #{@veh flow map . i n spe c t }”45 end46 def <=>(other )47 @tstart <=> other . t s t a r t48 end49 end5051 def ge t i npu t s viss im , program5253 l i n k s = vi s s im . i n pu t l i n k s5455 # Aggrega te a l l t u rn i n g motions in t h e same from−d i r e c t i o n56 i npu t s q l = ”SELECT COUNTS. i n t e r s e c t i o n As isname , LINKS . number , [ Period Star t ] As

t s t a r t , [ Period End ] As tend ,57 SUM( car s ) As cars , SUM( trucks ) As t rucks58 FROM [ counts$ ] As COUNTS59 INNER JOIN [ l i n k s $ ] As LINKS60 ON COUNTS. I n t e r s e c t i o n = LINKS . in t e r s e c t i on name AND61 COUNTS. f r om d i r e c t i on = LINKS . f r om d i r e c t i on62 WHERE LINKS . l i n k t yp e = ’ IN ’63 AND [ Period End ] BETWEEN \#1899/12/30 #{program . from . to hm}:00\# AND

\#1899/12/30 #{program . to . to hm}:00\#64 GROUP BY in t e r s e c t i o n , [ Period End ] , [ Period Star t ] , LINKS . number65 ORDER BY in t e r s e c t i o n , [ Period End ] ”6667 i n s e c t i n f o = DB[ ”SELECT name , count date FROM [ i n t e r s e c t i o n s $ ] ” ] . a l l6869 inputs = Inputs . new7071 # i t e r a t e over t h e d e t e c t e d data by p e r i od to g ene ra t e72 # inpu t which v a r i e s w i th t h e d e f i n e d r e s o l u t i o n73 for row in DB[ i npu t s q l ] . a l l7475 t s t a r t = Time . parse ( row [ : t s t a r t ] [ −8 . . −1 ] )76 tend = Time . parse ( row [ : tend ] [ −8 . . −1 ] )77 l ink number = row [ : number ] . t o i7879 i npu t l i n k = l i n k s . f i nd {| l | l . number == link number} # i n s e r t t r a f f i c here80 r a i s e ”Unable to l o c a t e l i n k with number #{l ink number}” unless i n pu t l i n k8182 # s c a l e t h e t r a f f i c from the coun t ing da t e to now83 isrow = i n s e c t i n f o . f i nd {| r | r [ : name ] == row [ : isname ]}84 r a i s e ”Unable to f i nd counting date f o r i n t e r s e c t i o n ’#{row [ : isname ]} ’ ” i f i s row . ni l

?8586 count date = Time . parse ( i s row [ : count date ] . t o s )8788 # number o f year s which has pas sed s i n c e t h e t r a f f i c count89 year s pas s ed = Time . now . year − count date . year9091 veh flow map = {}92 # produce an inpu t per v e h i c l e t ype93 for veh type in [ : cars , : t rucks ]94 f low = row [ veh type . to sym ]95 next i f f low < EPS9697 # l i n k i n pu t s in Vissim i s d e f i n e d in veh /h98 # a l s o s c a l e t h e i npu t acco rd ing to t h e t ime which has passed99 r e s o l u t i o n i n m inu t e s = ( tend−t s t a r t ) / 60

100 s c a l e d f l ow = f low ∗ INPUT SCALING ∗ (MINUTES PER HOUR/ r e s o l u t i o n i n m inu t e s ) ∗ (ANNUAL INCREASE ∗∗ year s pas s ed )

101 #put s ”#{ i n p u t l i n k } : #{ f l ow } −> #{ s c a l e d f l o w } #{ s c a l e d f l o w / f l ow } from #{ t s t a r t }t o #{t end }”

102 veh flow map [ veh type ] = s c a l e d f l ow103 end104105 inputs << Input . new( input l i nk , t s t a r t , tend , veh flow map )106 end107108 i f program . r e p e a t f i r s t i n t e r v a l109 # hea t i n g o f t h e s imu l a t o r110 t im e o f f s e t = program . r e s o l u t i o n ∗ 60

117

111 inputs . f i n d a l l {| i | i . t s t a r t == program . from } . each do | input |112 inputs << Input . new( input . l ink , input . t s t a r t − t ime o f f s e t , input . tend −

t ime o f f s e t , input . veh flow map )113 end114 end115116 # fo r nor thern end ( by h e r l e v sygehus ) and r o s k i l d e v e j117 # use the dogs d e t e c t o r data and t a k e t h e cars−to−t r u c k r a t i o s from the118 # t r a f f i c coun t s119120 i f Pro jec t == ’ dtu ’121 for det in [ ’D3 ’ , # nor thern inpu t from h e r l e v sygehus122 ’D01 ’ , ’D03 ’ , ’D06 ’ # r o s k i l d e v e j123 ]124125 # Fetch t h e l i n k inpu t number f o r t h i s d e t e c t o r126 number = exec query ( ”SELECT LINKS .Number127 FROM [ de t e c t o r s $ ] As DETS128 INNER JOIN [ l i n k s $ ] As LINKS129 ON DETS. I n t e r s e c t i o n = LINKS . Inte r s ec t i on name130 AND DETS.FROM = LINKS . From direct ion131 WHERE DETS.Name = ’#{det } ’ ” ) . f l a t t e n . f i r s t . t o i132133 # now change t h e inpu t f o r t h i s l i n k number to use134 # the data from t h i s d e t e c t o r , r e s p e c t i n g t h e v e h i c l e r a t i o135136 i n p u t s f o r l i n k = inputs . g e t by l i n k number137 r a i s e ”No inputs found f o r l i n k #{number}” i f i n p u t s f o r l i n k . empty?138139 #put s ” inpu t l i n k : #{number}”140141 s q l = ”SELECT142 HOUR(Time) As h ,143 MINUTE(Time) As m,144 AVG( Detected ) As detected145 FROM [ data$ ]146 WHERE NOT DoW IN ( ’ Sat ’ , ’ Sun ’ )147 AND Detector = ’#{det } ’148 AND [ Time ] BETWEEN \#1899/12/30 #{program . from . to hm}:00\# AND \#1899/12/30 #{

program . to . to hm}:00\#149 GROUP BY Detector , Time”150151 for row in DOGSDB[ s q l ] . a l l152 input = i n p u t s f o r l i n k . f i nd {| i | i . tend . hour == row [ : h ] and i . tend . min == row [ :m

]}153 r a i s e ” Input f o r l i n k #{number} at tend #{row [ : h ]}h#{row [ :m]}m not found” i f

input . ni l ?154 # Vissim e x p e c t s f l ow in v e c h i c l e s per hour . The dogs f l ow seems to have been

ad j u s t e d155 # a l r e ad y by i n s p e c t i n g o f b e f o r e and a f t e r f l ow data f o r each v e h i c l e t ype ( see

commented code be low )156 f low = row [ : detected ] . t o f ∗ 4157158 # Assume the DOGS d e t e c t o r data f o l l o w approx . t h e same v e h i c l e t ype159 # propo r t i on as t h e coun t ing data and reuse t h e p r opo r t i on .160 r = input . r a t i o ( ’ Cars ’ , ’ Trucks ’ )161 # b e f o r e c a r s = inpu t . v eh f l ow map [ ’ Cars ’ ]162 # b e f o r e t r u c k s = inpu t . veh f l ow map [ ’ Trucks ’ ]163 input . veh flow map [ ’ Cars ’ ] = f low ∗ r164 input . veh flow map [ ’ Trucks ’ ] = f low ∗ (1 − r )165166 # put s ”Cars d e l t a : #{b e f o r e c a r s − i npu t . v eh f l ow map [ ’ Cars ’ ]}”167 # put s ”Trucks d e l t a : #{ b e f o r e t r u c k s − i npu t . v eh f l ow map [ ’ Trucks ’ ]}”168 end169 end170 end171172 inputs173 end174175 i f FILE == $0176 puts ”BEGIN”177 v i s s im = Vissim . new178179 inputs = ge t i npu t s v i s s im180 inputs . wr i t e181 #put s i n pu t s . t o v i s s im182183 puts ”END”184 end

Listing 15: vissim interaction.rb12 r equ i r e ’ const ’3 r e qu i r e ’ vap ’4 r equ i r e ’ r e s u l t s ’

118

5 r equ i r e ’ measurements ’6 r e qu i r e ’ turningprob ’7 r equ i r e ’ v i s s im input ’89 puts ”#{Time . now} : BEGIN”

1011 thorough = fa l se # f a l s e => qu i c k t e s t t o see e v e r y t h i n g works1213 i f thorough14 SOLVER TIME = 2 # seconds15 SOLVER ITERATIONS = 10 # number o f t imes to rerun SA so l v e r , t r y i n g to g e t b e t t e r

s o l u t i o n s1617 RUNS = 10 # number o f s imu l a t i o n runs per t e s t18 RESOLUTION = 10 # s t e p s per s imu l a t i o n second19 else20 SOLVER TIME = 1 # seconds21 SOLVER ITERATIONS = 1 # number o f t imes to rerun SA so l v e r , t r y i n g to g e t b e t t e r

s o l u t i o n s2223 RUNS = 1 # number o f s imu l a t i o n runs per t e s t24 RESOLUTION = 10 # s t e p s per s imu l a t i o n second25 end2627 r equ i r e ”#{Pro jec t } t e s t s ” # f i l e must d e f i n e a TESTQUEUE cons t an t l i s t2829 seeds = numbers ( rand (100) + 1 , rand (100) + 1 , TESTQUEUE. s i z e ∗RUNS)3031 v i s s imnet = Vissim . new32 r e s u l t s = NodeEvals . new( v i s s imnet )3334 networks = [ [ ’ Path ’ , ’ Scenar io ’ , ’Time o f Day ’ ] ]3536 proces sed = 037 while t e s t = TESTQUEUE. s h i f t3839 proces sed += 14041 # fo r each time−of−day program in the t e s t42 t e s t [ : programs ] . each do | program |43 next i f program == DAY# or program == MORNING4445 workdir = F i l e . j o i n (Tempdir , ” v i s s im s c ena r i o#{proces sed } #{program . t o s . downcase}” )464748 begin49 Dir . mkdir workdir50 rescue51 # workd i r a l r e a d y e x i s t s , c l e a r i t52 F i l eU t i l s . rm Dir [ F i l e . j o i n ( workdir , ’∗ ’ ) ]53 end5455 # move i n t o t h e d e f a u l t v i s s im d i r e c t o r y f o r t h i s p r o j e c t56 # or the d i r e c t o r y o f t h e r e q u e s t e d v i s s im network in order to copy i t t o57 # a temporary l o c a t i o n58 v i s s im d i r = t e s t [ : network d i r ] ? F i l e . j o i n ( Base dir , t e s t [ : network d i r ] ) :

V i s s im d i r59 Dir . chd i r ( v i s s im d i r )6061 # copy a l l r e l e v a n t f i l e s to t h e i n s t an c e workd i r62 F i l eU t i l s . cp(%w{ inp pua knk mdb szp } .map{| ext | Dir [ ”∗.#{ ext}” ] } . f l a t t en , workdir )6364 inp f i l ename = Dir [ ’ ∗ . inp ’ ] . f i r s t # Vissim => p i c k y65 inppath = F i l e . j o i n ( workdir , inp f i l ename )66 networks << [ inppath , processed , program . name ]6768 i f Pro jec t == ’ dtu ’69 # c r e a t e s vap and pua f i l e s r e s p e c t i n g t h e s imu l a t i o n parameters70 g e n e r a t e c o n t r o l l e r s v i ss imnet , t e s t +71 { : o f f s e t => ( t e s t [ : u s e c a l c u l a t e d o f f s e t s ] ? c a l c u l a t e d o f f s e t s : ni l ) } ,72 workdir73 else74 s e t up t e s t t e s t [ : detector scheme ] , program , workdir75 end76 pr in t ”Vissim running #{RUNS} s imu la t ion#{RUNS != 1 ? ’ s ’ : ’ ’} o f ’#{simname } ’ . . . ”7778 RUNS. t imes do | i |79 pr in t ”#{ i +1} ”8081 # s e t t i n g and incremen t ing RunIndex cause s v i s s im to s t o r e82 # the r e s u l t s o f t h e c on s e c u t i v e runs in t h e same t a b l e83 sim . RunIndex = i84 sim . RandomSeed = seeds . pop85 sim . RunContinuous86 end8788 puts ”done”89

119

90 # the r e s u l t s from a l l runs in t h i s t e s t s c ena r i o can now be e x t r a c t e d91 r e s u l t s . e x t r a c t r e s u l t s ”#{simname} #{program . name}” , workdir9293 v i s s im . Exit9495 end # end f o r each t e s t program ( eg . morning , a f t e rnoon )96 end9798 t o x l s ( networks , ’ networks to t e s t ’ , F i l e . j o i n ( Base dir , ’ r e s u l t s ’ , ’ r e s u l t s . x l s ’ ) )99

100 puts ”PREPARING RESULTS − PLEASE WAIT! ”101102 t o x l s ( r e s u l t s . to a , ’ data ’ , RESULTS FILE)103104 # take c y c l e t imes and l i n k e v a l u a t i o n s from the l a s t run o f DOGS and mod DOGS105 r equ i r e ’ e x t r a c t c y c l e t ime s ’106 r equ i r e ’ e x t r a c t l i n k s e v a l s ’107108 puts ”#{Time . now} : END”

Listing 16: vissim output.rb1 # module i n c l u d e d by c l a s s e s t h a t need to w r i t e2 # t h e i r ou tpu t to a v i s s im network f i l e s3 # they must d e f i n e t o v i s s im and s e c t i o n h e a d e r4 module VissimOutput5 def wr i te i n p f i l e = Default network6 s e c t i o n c on t en t s = to v i s s im # make sure t h i s can be s u c c e s s f u l l y g ene ra t ed b e f o r e

opening t h e network f i l e !7 inp = IO . r e ad l i n e s ( i n p f i l e )8 s e c t i o n s t a r t = ( 0 . . . inp . l ength ) . to a . f i nd {| i | inp [ i ] =˜ s e c t i on heade r } + 19 se c t i on end = ( s e c t i o n s t a r t . . . inp . l ength ) . to a . f i nd {| i | inp [ i ] =˜ /−− .+ −−/ } − 1

10 F i l e . open ( i n p f i l e , ”w” ) do | f i l e |11 f i l e << inp [ 0 . . s e c t i o n s t a r t ]12 f i l e << ”\n#{s e c t i o n c on t en t s }\n”13 f i l e << inp [ s e c t i on end . . −1 ]14 end15 #put s ”Wrote#{r e s pond t o ? ( : l e n g t h ) ? ” #{ l e n g t h }” : ’ ’} #{ s e l f . c l a s s } t o ’#{ i n p f i l e

} ’”16 end17 end

Listing 17: vissim routes.rb1 # This f i l e can enumerate t h e p o s s i b l e r o u t e s between2 # a l i s t o f l i n k s and g ene ra t e Vissim ou tpu t34 # f a c t s :5 # − connec t o r s a lways connec t two l i n k s denoted t h e from− and to l i n k6 # − in a non− t r i v i a l network l i n k s are a lways connec ted to a t l e a s t 1 connec tor7 # − t h e r e e x i s t a rou t e from A to C i f t h e r e e x i s t a connec tor from A to B and8 # from B to C. This can be de termined by f o l l o w i n g t h e ou t go in g connec t o r s9 # from A and then B u n t i l a connector , which ends in C, i s found

1011 # a rou t e i s a l i s t o f l i n k s which are f o l l o w e d by us ing12 # the g i v en connec to r s13 class Vissim14 class Route15 a t t r r e ad e r : road segments , : d e c i s i o n s16 def i n i t i a l i z e ( road segments )17 r a i s e ”A route cannot s t a r t and end on the same road segment (#{ road segments .

f i r s t }) ” i f road segments . s i z e == 118 @road segments = road segments19 @dec i s ions = @road segments . f i n d a l l {| r s | r s . i n s t a n c e o f ?( Dec i s ion )}20 end21 def mark a r t e r i a l f r om d i r e c t i on22 @road segments . each {| r s | r s . update ( : a r t e r i a l f r om => f r om d i r e c t i on )}23 end24 def [ ] ( i )25 @road segments [ i ]26 end27 # Ca l c u l a t e s t h e l e n g t h from the b e g i nn in g o f t h e f i r s t road segment28 # to the end o f t h e l a s t road segment .29 def l ength ; @road segments .map{| r s | r s . l ength } . sum ; end30 def s t a r t ; @road segments . f i r s t ; end31 def e x i t ; @road segments . l a s t ; end32 # re t u rn s a space−s e pa ra t e d s t r i n g o f t h e connector−l i n k−connec tor . . . s equence33 # fo r use in t h e v i s s im OVER format in rou t e d e c i s i o n s34 def t o v i s s im ; @road segments [ 1 . . . − 1 ] .map{| r s | r s . number } . j o i n ( ’ ’ ) ; end35 def t o s ; ”#{s t a r t } > . . . (#{@road segments . s i z e −2}) > #{e x i t }” ; end36 def <=>(other ) ; @road segments . s i z e <=> other . road segments . s i z e ; end37 end3839 # rou t e f i n d i n g r ou t i n e work ing d i r e c t l y on v i s s im network o b j e c t s40 def d i s cove r s ta r t , ex i t s , path = [ ] , &on route found

120

41 return i f not s t a r t . a l l ow s p r i v a t e v e h i c l e s ?42 return i f path . inc lude ?( s t a r t ) # avo id l o o p s43 # check i f s t a r t i s t h e road segment we search f o r44 on route found [ Route . new( path + [ s t a r t ] ) ] i f e x i t s . i n c lude ?( s t a r t )45 i f s t a r t . i s a ?( Connector )46 # you can on ly s earch on by go ing to t h e connec ted l i n k47 d i s cove r ( s t a r t . t o l i nk , ex i t s , path + [ s t a r t ] , &on route found )48 else49 # s t a r t i s a l i n k and has z e ro or more ou t go in g connec to r s50 s t a r t . outgo ing connec to r s . each do | conn |51 d i s cove r ( conn , ex i t s , path + [ s t a r t ] , &on route found )52 end53 end54 end5556 # a r t e r i a l o p t im i z a t i o n : prune ” i d e n t i c a l ” r ou t e s i e same s t a r t and end57 # not needed c u r r e n t l y − bu t code may become v a l u a b l e l a t e r on58 def p run e i d en t i c a l route s59 e x i t i n g a t = {}60 route s .map{| r | r . e x i t } . uniq . each do | e x i t l i n k |61 e x i t i n g a t [ e x i t l i n k ] = route s . f i n d a l l {| r | r . e x i t == e x i t l i n k }62 end6364 routes to remove = [ ]65 for s t a r t l i n k in route s .map{| r | r . s t a r t } . uniq66 # El im ina t i n g rou t e d u p l i c a t e s s t a r t i n g a t s t a r t l i n k . . .67 for r1 in route s . f i n d a l l {| r | r . s t a r t == s t a r t l i n k }68 next i f route s to remove . in c lude ? r169 dup l i c a t e s = e x i t i n g a t [ r1 . e x i t ] . f i n d a l l {| r2 | r2 != r1 and r2 . s t a r t ==

s t a r t l i n k }70 route s to remove . concat ( dup l i c a t e s )71 end72 end7374 route s − route s to remove75 end7677 # he l p e r method f o r t h e d i s c o v e r y r ou t i n e to f i n d mu l t i p l e r ou t e s78 def f i n d r o u t e s s ta r t , dest79 route s = [ ]80 d i s cove r ( s ta r t , [ dest ] . f l a t t e n ) do | r |81 route s << r82 end83 route s84 end85 # f i n d s r ou t e s from s t a r t t o des t , e x p e c t i n g86 # a s i n g l e rou t e on l y . w i l l r a i s e an e r r o r i f no87 # rou t e s are found or t h e r e are mu l t i p l e r o u t e s88 def f i n d r ou t e s ta r t , dest89 route s = f i n d r ou t e s ( s ta r t , dest )90 r a i s e ”No route from #{s t a r t } to #{dest } ! ” i f route s . empty?91 r a i s e ” Mult ip le route s from #{s t a r t } to #{dest } ! ” i f route s . s i z e > 192 route s . f i r s t93 end9495 # f i n d s a l l f u l l i e . end−to−end r ou t e s in t h e v i s s im network96 def g e t f u l l r o u t e s97 route s = [ ]98 for s t a r t in i n pu t l i n k s99 d i s cove r ( s ta r t , e x i t l i n k s ) do | route |

100 route s << route101 end102 end103104 #p r u n e i d e n t i c a l r o u t e s105 route s106 end107 end108109 i f FILE == $0110 r equ i r e ’ v i s s im ’111 v i s s im = Vissim . new112 #re q u i r e ’ p r o f i l e ’113 route s = vi s s im . g e t f u l l r o u t e s114 puts ”Found #{route s . l ength } route s ”115 end

C.3 Optimizer codes

Listing 18: greenwave eval.rb1 # Cla s s e s and methods f o r e v a l u a t i o n o f and search f o r o f f s e t v a l u e s2 # fo r v i s s im s i g n a l c o n t r o l l e r s34 r equ i r e ’ v i s s im ’

121

5 r equ i r e ’ const ’67 # A band i s an i n t e g e r sequence o f seconds used to i n d i c a t e8 # A band i s an i n t e g e r sequence o f seconds used to i n d i c a t e9 # the tempora l e x t end o f eg . t h e green t ime o f a s t a g e

10 class Band11 a t t r r e ad e r : t s t a r t , : tend12 def i n i t i a l i z e t s t a r t , tend13 r a i s e ”A waveband must s t a r t be f o r e i t ends , r e c e i v ed t s t a r t = #{t s t a r t } and tend =

#{tend}” i f t s t a r t > tend14 r a i s e ”Only i n t e g e r va lues are accepted , r e c e i v ed t s t a r t = #{t s t a r t } and tend = #{

tend}” unless [ t s t a r t , tend ] . a l l ?{|n | I n t eg e r===n}15 @tstart , @tend = t s t a r t , tend16 end17 def over lap ?( other ) ; t o r . over lap ?( other . t o r ) ; end18 def width ; @tend − @tstart + 1 ; end19 # re t u rn s a l i s t o f bands , which are t h e r e s u l t o f s u b t r a c t i n g o t h e r from s e l f20 def subt rac t ( other )21 return [ copy ] unless over lap ?( other )22 case [ @tstart <=> other . t s t a r t , @tend <=> other . tend ]23 when [ 0 , 0 ] , [1 ,−1] , [0 ,−1] , [ 1 , 0 ] # s e l f i s c omp l e t e l y covered by o t h e r24 [ ]25 when [−1 ,1] # s t a r t b e f o r e o t h e r s t a r t and end i s a f t e r o t h e r end , mu l t i p l e bands26 [ Band . new( @tstart , other . t s t a r t − 1) ,Band . new( other . tend + 1 ,@tend ) ]27 when [−1 ,0] , [−1 ,−1] # s t a r t s b e f o r e o t h e r bu t ends a t same t ime28 [ Band . new( @tstart , other . t s t a r t − 1) ]29 when [ 0 , 1 ] , [ 1 , 1 ] # s t a r t s same t ime as o t h e r bu t ends a f t e r30 [ Band . new( other . tend + 1 ,@tend ) ]31 else32 r a i s e ”Should not get here . Attempted #{ s e l f } − #{other }”33 end34 end35 # o f f s e t s t h e band in t ime in p l a c e36 def s h i f t ! ( o f f s e t ) ; @tstart += o f f s e t ; @tend += o f f s e t ; @as range = ni l end37 def t o s ; ”(#{ t o r }) ” ; end38 def t o r ; @as range | |= ( @tstart . . @tend ) ; end39 def to a ; t o r . to a ; end40 def copy ; Band . new( @tstart , @tend ) ; end41 end4243 # A coo rd i n a t i on i s an a b s t r a c t i o n o f t h e road segment ( s ) be tween two ad j a c en t

i n t e r s e c t i o n s .44 # Contains v a r i o u s e v a l u a t i o n methods , which are used in op t im i z a t i on , which d i f f e r in

comp l e x i t y45 # Note t h a t a c oo r d i na t i on i s d i r e c t e d .46 class Coordinat ion47 a t t r r e ad e r : sc1 , : sc2 , : d i s tance , : f r om d i r e c t i on , : l e f t t o r i g h t , : d e f au l t sp e ed48 def i n i t i a l i z e sc1 , sc2 , speed , d i s t ance49 @sc1 , @sc2 = sc1 , sc2 # coo rd i na t i on from sc1 to sc250 @defau l t speed = speed # the speed by which v e h i c l e s may c l o s e t h e d i s t a n c e51 @from direct ion = ge t f r om d i r e c t i o n (@sc1 , @sc2 ) # t r a f f i c d i r e c t i o n52 @ l e f t t o r i g h t = sc1 . number < sc2 . number ? true : fa l se53 @tt = {} # cache f o r t r a v e l t imes , k ey s are speed s5455 # s im p l i f y t h i n g s and v i s u a l i z a t i o n by a lways t a k i n g t h e d i s t a n c e56 # in the primary d i r e c t i o n57 @distance = d i s tance . t o f58 # no t i f y c o n t r o l l e r s t h a t t h ey are now par t o f t h i s c o o r d i na t i on59 [ @sc1 , @sc2 ] . each {| sc | sc . member coordinat ions << s e l f }60 end61 ACCELERATION = 2.5 # m/s ˆ2 uniform a c c e l e r a t i o n62 # Ca l c u l a t e s t h e t r a v e l t ime from sc1 to sc263 # s : : t h e a l l owed t r a v e l speed64 def t r ave l t ime ( s )65 return @tt [ s ] i f @tt [ s ] # cache h i t6667 tacc = s / ACCELERATION # s68 d i s t f i n a l s p e e d r e a c h e d = 0.5 ∗ ACCELERATION ∗ ( tacc ∗∗ 2) # m ( assume i n i t i a l

speed = 0)6970 # cache and r e tu rn the r e s u l t o f t h i s c a l c u l a t i o n . w i l l be needed71 # mu l t i p l e t imes when used by t he o p t im i z a t i o n r ou t i n e72 @tt [ s ] = i f d i s t f i n a l s p e e d r e a c h e d > @distance73 # we a c c e l e r a t e d a l l t h e way to t h e nex t i n t e r s e c t i o n ( very c l o s e ! )74 Math . sq r t ( 0 . 5 ∗ ACCELERATION / @distance )75 else76 # reached d e s i r e d speed b e f o r e t h e nex t i n t e r s e c t i o n77 tacc + ( @distance − d i s t f i n a l s p e e d r e a c h e d ) / s78 end . round79 end8081 # re t u rn s t h e seconds where t h e r e i s a mismatch between sc1 and sc2 i e .82 # when t r a f f i c em i t t e d from sc1 i s not r e c e i v e d by green l i g h t a t sc283 # r e s p e c t i n g t h e cu r r en t o f f s e t s o f t h e s e c o n t r o l l e r s and the t r a v e l t im e84 # from stop− l i g h t t o s top− l i g h t85 def mismatches in hor i zon h , o1 , o2 , s , c1 = @sc1 . cyc l e t ime , c2 = @sc2 . cy c l e t ime86 t t = t rave l t ime ( s )87

122

88 for b1 in @sc1 . greenwaves (h , o1 , @from direct ion , c1 )89 b1 . s h i f t ! ( t t ) # p r o j e c t t h i s em i t t e d band forward in t ime90 uncovered bands = [ b1 ]91 bands2 = @sc2 . greenwaves ( b1 . to r , o2 , @from direct ion , c2 )92 # b1 s h i f t e d i s now a l l p o t e n t i a l mismatches ;93 # use the bands from sc2 to chop o f f p i e c e s94 while b2 = bands2 . s h i f t and not uncovered bands . empty?95 b1 = uncovered bands . pop96 remaining = b1 . subt rac t ( b2 )97 uncovered bands . concat remaining98 end99

100 uncovered bands . each {|b | yield b}101 end102 end103 # the p o s i t i o n where a green band ∗may∗ become he l d up by a red l i g h t104 def c o n f l i c t p o s i t i o n # c o n f l i c t a lways happen a t sc2105 @ l e f t t o r i g h t ? @sc2 . p o s i t i o n : (@sc2 . p o s i t i o n + @sc1 . i n t e r n a l d i s t a n c e )106 end107 def eva l speed s108 ( @defau l t speed − s ) ∗∗ 2 # quad r a t i c punishment o f d e v i a t i o n from d e f a u l t speed109 end ; p r i va t e : eva l speed110 # Finds t h e u t i l i t y i e . number o f mismatches in t h e g i v en hor i z on .111 # Mixing a pp l e s and bananas .112 def eva l h , o1 , o2 , s113 z = eva l speed ( s )114 mismatches in hor i zon (h , o1 , o2 , s ) {| band | z += band . width}115 z116 end117 # the green t ime d i s p l a c emen t from green s t a r t o f sc1 to118 # green s t a r t o f sc2 under t h e g i v en o f f s e t s and speed ( t r a v e l t ime ) .119 # de v i a t i o n s from d e f a u l t speed are pun i shed120 def e v a l f i x e d o1 , o2 , s , c121 red end = {}122 [ [ @sc1 , o1 ] , [ @sc2 , o2 ] ] . each do | sc , o |123 group = sc . a r t e r i a l g r oup f r om ( @from direct ion )124 red end [ sc ] = ( group . red end + o ) % c + 1125 end126127 green t ime d i sp lacement = case red end [ @sc1 ] <=> red end [ @sc2 ]128 when 1 # sc1 a r t e r i a l green s t a r t s b e f o r e sc2129 red end [ @sc1 ] − red end [ @sc2 ]130 when −1 # must wa i t an e n t i r e c y c l e b e f o r e green s t a r t o f sc2131 c − ( red end [ @sc2 ] − red end [ @sc1 ] )132 else133 c # green s t a r t s a t t h e same time , bo th must wa i t an e n t i r e c y c l e134 end135136 ( green t ime d i sp lacement − t r ave l t ime ( s ) ) . abs + eva l speed ( s )137 end138 def t o s139 ”Coordinat ion between #{@sc1 . number} #{@sc1 . name} and #{@sc2 . number} #{@sc2 . name}”140 end141 def <=>(other )142 i f @sc1 == other . sc1143 @sc2 <=> other . sc2144 else145 @sc1 <=> other . sc1146 end147 end148 end149150 # A s imu l a t e d annea l i n g a l g o r i t hm f o r o p t im i z i n g o f f s e t s ( and speeds , i f a l l owed )151 # fo r c o o r d i n a t i o n s152 class SimulatedAnneal ing153 def i n i t i a l i z e problem , t ime l im i t , params154 @problem = problem155 @t ime l imit = t ime l im i t156 @parameters = params157 end158 def run159 r e s u l t = Hash . new (0)160 r e s u l t [ : s u c c e s f u l chang e s ] = Hash . new (0)161 r e s u l t [ : a c t i on count ] = Hash . new (0) # number o f t imes each a c t i on has been taken162 r e s u l t [ : a c t i o n s u c c e s s ] = Hash . new (0) # no . t imes t h e a c t i on improved t h e encumbent163164 i te r s wi th no improvement = 0165166 s t a r t t ime = Time . now # s t a r t t h e c l o c k167168 @problem . c r e a t e i n i t i a l s o l u t i o n169170 temp = @parameters [ : s tar t temp ]171172 while Time . now − s t a r t t ime < @time l imit173 r e s u l t [ : i t e r a t i o n s ] += 1174 cu r r en tva l = @problem . cu r r en t va lu e175

123

176 # change ” cu r r en t ” d i r e c t l y to ” ne i gh bo r ” ( save t ime copy ing o b j e c t s )177 # ( @problem i s c apa b l e o f undoing t h e change )178 change type = @problem . change179180 ne ighborva l = @problem . cu r r en t va lu e181182 i f ne ighborva l < @problem . encumbent value183 # use the ne i gh bo r s o l u t i o n nex t i t e r a t i o n i f i t i s b e t t e r than the b e s t found

so f a r . . .184 @problem . store encumbent185 r e s u l t [ : encumbent found time ] = Time . now − s t a r t t ime186 r e s u l t [ : encumbent found i te rat ion ] = r e s u l t [ : i t e r a t i o n s ]187 r e s u l t [ : s u c c e s f u l chang e s ] [ change type ] += 1188 i te r s wi th no improvement = 0189190 yield neighborval , cur rentva l , ” change o f #{change type}” , @problem . s o l u t i on i f

b lock g iven ?191 else192 i te r s wi th no improvement += 1193 i f Math . exp(−( ne ighborva l − cu r r en tva l ) / temp) > rand194 # and maybe even i f i t s not !195 # re t a i n ne i gh bo r s o l u t i o n as cu r r en t work ing s o l u t i o n even though i t196 # i s not an o v e r a l l improvement197 r e s u l t [ : accepted ] += 1198 else # undo the change we made / r e t u rn to p r e v i o u s ” cu r r en t ” s o l u t i o n199 @problem . undo changes200 end201 end202203 # ad j u s t temperature ,204 # check i f some ac t i on must be taken due to b e in g s t u c k205 i f i t e r s wi th no improvement > @parameters [ : no improvement act ion thresho ld ]206 i f temp < @parameters [ : s tar t temp ] and maybe? # pure r e h e a t i n g207 temp = @parameters [ : s tar t temp ]208 ac t i on = : reheat209 e l s i f @problem . cu r r en t va lu e > @problem . encumbent value and maybe?210 @problem . focus211 ac t i on = : focus212 else213 ac t i on = : random restart214 @problem . random restart215216 i f @problem . cu r r en t va lu e < @problem . encumbent value217 # the random r e s t a r t a c t u a l l y gave t h e b e s t s o l u t i o n thu s f a r !218 yield @problem . cur rent va lue , @problem . encumbent value , act ion , @problem .

s o l u t i on i f b lock g iven ?219 @problem . store encumbent220 r e s u l t [ : a c t i o n s u c c e s s ] [ a c t i on ] += 1221 end222 end223224 r e s u l t [ : a c t i on count ] [ a c t i on ] += 1225 i te r s wi th no improvement = 0226 else227 temp ∗= @parameters [ : alpha ]228 end229 end230 time = Time . now − s t a r t t ime231 r e s u l t +232 { : encumbent value => @problem . encumbent value ,233 : time => time ,234 : s o l u t i o n => @problem . so lu t i on ,235 : i t e r p e r s e c => ( r e s u l t [ : i t e r a t i o n s ] / time . t o f ) . round} +236 @problem . s t a t i s t i c s237 end238 end239240 # A s e t o f c oo rd ina t i on s , which must be op t im i z ed f o r o f f s e t s and speed s ( p o s s i b l y )241 class CoordinationProblem242 a t t r r e ad e r : cur rent va lue , : encumbent value , : s t a t i s t i c s243 def i n i t i a l i z e coords , opts244 r a i s e ”Cannot proceed without coo rd ina t i on s ! ” i f coords . ni l ? or coords . empty?245 @coordinat ions = coords246 @maximum coord distance = coords .map{| c | c . d i s t ance } .max247248 @con t r o l l e r s = coords .map{| coord | [ coord . sc1 , coord . sc2 ] } . f l a t t e n . uniq249250 i f opts [ : hor i zon ]251 @scheme = : s tage based252 @horizon = opts [ : hor izon ]253 e l s i f opts [ : c y c l e t ime ]254 @scheme = : common cycle time255 @cur rent cyc l e t ime = opts [ : c y c l e t ime ] # seconds256 end257258 @change probabi l i ty = opts [ : change p robab i l i t y ]259260 @des i r ed b ia s = opts [ : d i r e c t i o n b i a s ] # i f n i l , do not c on s i d e r d i r e c t i o n b i a s

124

261262 @coord contr ibut ion = {} # i n d i v i d u a l c o n t r i b u t i o n from coo r d i n a t i o n s to cu r r en t

v a l u e263 @de l ta cont r ibut i on = {} # bookkeep ing o f changes goes here264265 @cu r r en t o f f s e t = {} ; @encumbent of fset = {}266 @current speed = {} ; @encumbent speed = {}267268 @ s t a t i s t i c s = Hash . new (0)269 end270 def c r e a t e i n i t i a l s o l u t i o n271 @con t r o l l e r s . each {| sc | @cur r en t o f f s e t [ sc ] = 0}272 @coordinat ions . each {| coord | @current speed [ coord ] = coord . d e f au l t sp e ed }273 f u l l e v a l u a t i o n # upda te s cu r r en t s o l u t i o n va l u e274 store encumbent275 end276 SPEED INCREMENT = 5 / 3 .6 # 5KM/H277 SPEED CHANGE OPTIONS = [−SPEED INCREMENT, SPEED INCREMENT]278 SPEED CHANGE OPTIONS WITH ZERO = SPEED CHANGE OPTIONS + [ 0 ]279280 # Random r e s t a r t : c o n t r o l l e r s are a s s i g n ed a random o f f s e t281 # in the cu r r en t c y c l e t ime and a l l owed speed s f o r c o o r d i n a t i o n s282 # are s e t t o t h e d e f a u l t speed pm 5283 def random restart284 @con t r o l l e r s . each {| sc | @cur r en t o f f s e t [ sc ] = rand ( @cur r ent cyc l e t ime | | sc .

c y c l e t ime )}285 i f @change probabi l i ty [ : speed ] . nonzero ?286 @coordinat ions . each do | coord |287 @current speed [ coord ] = coord . d e f au l t sp e ed + SPEED CHANGE OPTIONS WITH ZERO.

rand288 end289 end290 f u l l e v a l u a t i o n # a l l c o o r d i n a t i o n s change , must do f u l l r e e v a l u a t i o n291 end292 # re t u rn s f o cu s to encumbent s o l u t i o n293 def f o cus294 @cu r r en t o f f s e t = @encumbent of fset . copy295 @current speed = @encumbent speed . copy296 f u l l e v a l u a t i o n297 end298 # make a c l e an copy o f t h e cu r r en t s o l u t i o n f r e e from ba c k r e f e r e n c e s299 def store encumbent300 @ s t a t i s t i c s [ : encumbents ] += 1 i f @encumbent value # do not count t h e f i r s t ”

encumbent ” ( i n i t i a l s o l u t i o n )301 # Synchron i ze encumbent and cu r r en t s o l u t i o n302 #303 # For o f f s e t s , l ower a l l o f f s e t s by a con s t an t f a c t o r so u n t i l t h e f i r s t o f f s e t

becomes304 # zero . This has no e f f e c t on the s o l u t i o n bu t t r ims th e o f f s e t so t h a t305 # a ”master ” c o n t r o l l e r ( o f f s e t = ze ro ) appears .306 @encumbent of fset = {}307 m in o f f s e t = @cu r r en t o f f s e t .map{| sc , o f f s e t | o f f s e t } .min308 @cu r r en t o f f s e t . each {| sc , o f f s e t | @encumbent of fset [ sc ] = o f f s e t − min o f f s e t }309 @encumbent speed = @current speed . copy310 @encumbent value = @current va lue311 end312 # make a change in t h e cu r r en t s o l u t i o n313 # note t h e change so t h a t i t may be undone , i f r e q u e s t e d314 def change315 @last change = i f rand < @change probabi l i ty [ : speed ]316 change speed ; : speed317 else318 chang e o f f s e t ; : o f f s e t319 end320 end321 # Change t he speed o f one c oo r d i n a t i on between two c o n t r o l l e r s .322 def change speed323 @ s t a t i s t i c s [ : speed changes ] += 1324 # p i c k a c oo r d i n a t i on to change speed f o r325 @changed coord = @coordinat ions . rand326 @previous speed = @current speed [ @changed coord ]327 @current speed [ @changed coord ] = @previous speed + SPEED CHANGE OPTIONS. rand328 d e l t a e v a l ( @changed coord )329 end ; p r i va t e : change speed330 def chang e o f f s e t331 @ s t a t i s t i c s [ : o f f s e t c h ang e s ] += 1332 @changed sc = @con t r o l l e r s . rand333 @pr ev i ou s o f f s e t = @cu r r en t o f f s e t [ @changed sc ]334 @cu r r en t o f f s e t [ @changed sc ] =335 ( @pr ev i ou s o f f s e t + (maybe? ? −1 : 1) ) % ( @cur rent cyc l e t ime | | @changed sc .

cy c l e t ime )336337 # perform de l t a−e v a l u a t i o n338 d e l t a e v a l (∗@changed sc . member coordinat ions )339 end ; p r i va t e : c h ang e o f f s e t340 # update cu r r en t v a l u e by r e c a l c u l a t i n g on l y t h e g i v en coords341 def d e l t a e v a l (∗ coords )

125

342 @current va lue check = @current va lue # note p r e v i o u s v a l u e f o r d e l t a r e s t o r ei n t e g r i t y check

343 # r e f r e s h e v a l u a t i o n s f o r t h e c o o r d i n a t i o n s which i n v o l v e t h e changed s i g n a lc o n t r o l l e r

344 @de l ta cont r ibut i on . c l e a r # f o r g e t how to r e v e r t t o t h e p r e v i o u s s o l u t i o n345 for coord in coords346 # Make a note o f t h e p r e v i o u s c o n t r i b u t i o n o f t h i s347 # coo rd i na t i on and s u b t r a c t i t from the cu r r en t s o l u t i o n va l u e348 o ld va lu e = @coord contr ibut ion [ coord ]349 @de l ta cont r ibut i on [ coord ] = o ld va lu e350 @direct ion sum [ coord . l e f t t o r i g h t ] −= o ld va lue351352 # Reca l c u l a t e t h e c o n t r i b u t i o n o f t h e c oo r d i na t i on353 # under t h e new s e t t i n g s . . .354 new value = eva l coo rd ( coord )355 @coord contr ibut ion [ coord ] = new value356 @direct ion sum [ coord . l e f t t o r i g h t ] += new value357 end358 s t o r e c u r r e n t v a l u e359 end360 def s t o r e c u r r e n t v a l u e361 @current va lue = @direct ion sum . va lues . sum ∗ b i a s d ev i a t i on pun i shment f a c t o r362 end363 def eva l coo rd ( coord )364 o1 , o2 , s =365 @cu r r en t o f f s e t [ coord . sc1 ] ,366 @cu r r en t o f f s e t [ coord . sc2 ] ,367 @current speed [ coord ]368369 value = case @scheme370 when : common cycle time371 coord . e v a l f i x e d ( o1 , o2 , s , @cur rent cyc l e t ime )372 when : s tage based373 coord . eva l ( @horizon , o1 , o2 , s )374 else375 r a i s e ”Don ’ t know how to eva luate o f f s e t s and speeds in a ’#{@scheme} ’ scheme”376 end377378 # put a we i gh t o f t h e v a l u e o f t h e coord w i th cu r r en t s e t t i n g s379 # such t h a t h i gh v a l u e s (−> poor c o o r d i n a t i o n s ) are pun i shed380 # more s e v e r e l y when the i n t e r s e c t i o n s o f t h e c oo r d i na t i on are c l o s e by381 r a t i o = @maximum coord distance / coord . d i s t ance382 value ∗ Math . exp((1− r a t i o ) . abs )383 end ; p r i va t e : eva l coo rd384 # re tu rn a hash o f s i g n a l s mapping to t h e found o f f s e t s and speed s385 def s o l u t i on386 So lut i on . new @encumbent value , : o f f s e t => @encumbent offset , : speed =>

@encumbent speed387 end388 # undo a l l changes made dur ing l a s t c a l l t o change389 def undo changes390 @ s t a t i s t i c s [ : r e j e c t e d ] += 1391392 # r e s t o r e s t a t e o f p r e v i o u s s o l u t i o n393 case @last change394 when : o f f s e t395 @cu r r en t o f f s e t [ @changed sc ] = @pr ev i ou s o f f s e t396 when : speed397 @current speed [ @changed coord ] = @previous speed398 else399 r a i s e ”Don ’ t know how to undo a ’#{@last change } ’ change ! ”400 end401402 # de l t a−r e s t o r e t h e v a l u e o f t h e s o l u t i o n403 for coord , o l d va lu e in @de l ta cont r ibut i on404 cu r r en t va lu e = @coord contr ibut ion [ coord ]405 @direct ion sum [ coord . l e f t t o r i g h t ] −= cur r en t va lu e406 @coord contr ibut ion [ coord ] = o ld va lu e407 @direct ion sum [ coord . l e f t t o r i g h t ] += o ld va lu e408 end409410 s t o r e c u r r e n t v a l u e411412 r a i s e ” Restorat ion o f prev ious s o l u t i on f a i l e d a f t e r change in #{@last change } :\n” +413 ” expected value #{@current va lue check } got #{@current va lue }” i f (1 −

@current va lue check / @current va lue ) . abs > EPS414 end415 # punish d e v i a t i o n from d e s i r e d d i r e c t i o n b i a s416 def b i a s d ev i a t i on pun i shment f a c t o r417 return 1 i f @des i r ed b ia s . ni l ?418 b ia s = @direct ion sum [ true ] . t o f / @direct ion sum [ fa l se ] . t o f419 r a t i o = @des i r ed b ia s / b ia s # ra t i o w i l l be c l o s e to 1 when the d i r e c t i o n b i a s i s

good420 Math . exp((1− r a t i o ) . abs ) # exp (0) = 1 i e . no punishment421 end422 # ev a l u a t e t h e cu r r en t s o l u t i o n423 def f u l l e v a l u a t i o n

126

424 @direct ion sum = {true => 0 , fa l se => 0} # sum o f v a l u e c o n t r i b u t i o n s f o r eachd i r e c t i o n ( a r t e r y )

425 @coordinat ions . each do | coord |426 value = eva l coo rd ( coord )427 @coord contr ibut ion [ coord ] = value428 @direct ion sum [ coord . l e f t t o r i g h t ] += value429 end430431 s t o r e c u r r e n t v a l u e432 end433 end434435 H = ( 0 . . 1 0 0 ) # hor i z on in seconds436437 # parse a l l c o o r d i n a t i o n s between the g i v en s i g n a l c o n t r o l l e r s438 def pa r s e c oo rd i na t i on s scs , v i s s im439440 # ad j u s t t h e p o s i t i o n o f c o n t r o l l e r s such t h e l e f t −most one441 # i s a t p o s i t i o n ze ro442 minpos = sc s .map{| sc | sc . p o s i t i o n } .min443 s c s . each {| sc | sc . update : p o s i t i o n => ( sc . p o s i t i o n − minpos )}444445 coo rd ina t i on s = [ ]446 s c s . each cons (2) do | sc1 , sc2 |447 next unless ( sc2 . number − sc1 . number ) . abs == 1 # as s i g n ed numbers i n d i c a t e p ro x im i t y448 # se tup a coo r d i na t i on in each d i r e c t i o n449 [ [ sc1 , sc2 ] , [ sc2 , sc1 ] ] . each do | fromsc , to s c |450 coo rd ina t i on s << Coordinat ion . new( fromsc , tosc , v i s s im . speed ( fromsc , to s c ) , v i s s im .

d i s t ance ( fromsc , to s c ) )451 end452 end453454 coo rd ina t i on s455 end456 def g e t d o g s s c e n a r i o s scs , v iss im , dog s cyc l e t ime457 cyc l e t ime = {}458 s c s . each {| sc | cyc l e t ime [ sc ] = dog s cyc l e t ime }459460 return pa r s e c oo rd i na t i on s ( scs , v i s s im ) , [ : c y c l e t ime => cyc l e t ime ] , H461 end462463 def run s imu la t i on annea l i ng ( c o n t r o l l e r s , v iss im , opts = { : c y c l e t ime => 80 , : verbose =>

fa l se })464 coords = pa r s e c oo rd i na t i on s ( c o n t r o l l e r s , v i s s im )465 problem = CoordinationProblem . new( coords , opts +466 { : d i r e c t i o n b i a s => 1 . 0 , : change p robab i l i t y => { : speed => 0 . 0 , : o f f s e t => 0 .8}} )467468 siman = SimulatedAnneal ing . new( problem , 2 ,469 : s tar t temp => 100 .0 ,470 : alpha => 0 .95 ,471 : no improvement act ion thresho ld => 50472 )473474 s o l u t i o n s = [ ]475 r e s u l t = siman . run do | newval , prevval , change desc , s o l u t i o n |476 puts ”Found new encumbent #{newval} vs . #{prevva l } by #{change desc}” i f opts [ :

verbose ]477 s o l u t i o n s << s o l u t i on478 end479 i f opts [ : verbose ]480 p r i n t r e s u l t s ( r e s u l t )481 end482483 return coords , s o l u t i on s , H484 end485486 class So lut i on487 a t t r r e ad e r : o f f s e t , : speed , : va lue488 def i n i t i a l i z e ( value , s e t t i n g s )489 @value = value490 @o f f s e t = s e t t i n g s [ : o f f s e t ]491 @speed = s e t t i n g s [ : speed ]492 end493 def t o s494 s t r = ” So lut i on value : #{@value}\n”495 i f @of f s e t496 s t r << ” O f f s e t s :\n”497 @o f f s e t . s o r t . each do | sc , o f f s e t |498 s t r << ” #{sc . number} #{sc . name} : #{o f f s e t } s\n”499 end500 end501 i f @speed502 s t r << ”Speeds :\n”503 @speed . s o r t . each do | coord , speed |504 s t r << ” #{coord } : #{(speed ∗ 3 . 6 ) . round}km/h , t r a v e l time : #{coord . t r ave l t ime

( speed )} s\n”505 end506 end

127

507 s t r508 end509 def <=>(other )510 @value <=> other . va lue511 end512 end513514 def p r i n t r e s u l t s ( r e s u l t )515 puts ” So lve r f i n i s h e d in #{r e s u l t [ : time ]} seconds . ”516 puts ”Completed i t e r a t i o n s : #{r e s u l t [ : i t e r a t i o n s ]} ”517 puts ” I t e r a t i o n s per second : #{r e s u l t [ : i t e r p e r s e c ]} ”518 puts ”Actions taken on no improvement : ”519 r e s u l t [ : a c t i on count ] . each do | act ion , count |520 puts ” #{ac t i on } : #{count} o f which #{r e s u l t [ : a c t i o n s u c c e s s ] [ a c t i on ]} improved

encumbent”521 end522 puts ”Reheatings : #{r e s u l t [ : r ehea t s ]} ”523 puts ” Res tar t s : #{r e s u l t [ : r e s t a r t s ]} ”524 puts ”Accepted s o l u t i o n s ( jumps ) : #{r e s u l t [ : accepted ]} ”525 puts ”Rejected s o l u t i o n s : #{r e s u l t [ : r e j e c t e d ]} ”526 puts ”Encumbents found : #{r e s u l t [ : encumbents ]} ”527 puts ” Fina l s o l u t i o n value : #{r e s u l t [ : encumbent value ]} ”528 end529530 def g e t s o l u t i o n v i s s im531 coords , s o l u t i o n s = run s imu la t i on annea l i ng (532 v i s s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 1 . . 5 ) === sc . number} , v i s s im )533534 #put s s o l u t i o n s . j o i n (”\n”)535 puts s o l u t i o n s . l a s t536 end537538 i f FILE == $0539 v i s s im = Vissim . new540541 g e t s o l u t i o n v i s s im542 end

Listing 19: greenwave gui.rb1 # A GUI w r i t t e n to d i s p l a y green wave bands in a t ime hor i z on23 r equ i r e ’wx ’4 inc lude Wx56 class RoadTimeDiagram < Frame7 FATPENWIDTH = 38 def i n i t i a l i z e9 super ( nil , : s i z e => [ 8 0 0 , 6 0 0 ] )

10 v i s s im = Vissim . new1112 @con t r o l l e r s = vi s s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 1 . . 5 )===sc . number} # Her l ev13 #@con t r o l l e r s = v i s s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 9 . . 1 2 )===sc . number} # Glos t rup1415 @coordinat ions , @solut ions , @horizon =16 g e t d o g s s c e n a r i o s ( @cont ro l l e r s , v iss im , 80 )17 # run s imu l a t i o n ann e a l i n g (18 # v i s s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 1 . . 5 ) === sc . number } ,19 # viss im , : v e r b o s e => t rue , : c y c l e t im e => 80)2021 s e t t i t l e ”Road−Time Diagram (#{@cont r o l l e r s . s i z e } i n t e r s e c t i o n s ) ”2223 @tmax = ( @coordinat ions .map{| c | c . t r ave l t ime ( c . d e f au l t sp e ed ) } .max ∗ 2 + @horizon .

max) . t o f24 @distmax = @cont r o l l e r s .map{| sc | sc . p o s i t i o n } .max + 1002526 # a l l t ime / d i s t a n c e r e l a t e d pa i n t j o b s must t r a n s l a t e to match t h i s o r i g o (0 ,0 )27 @ox , @oy = 30 , 1202829 @fat pen = Pen . new(BLACK)30 @fat pen . s e t w idth FATPENWIDTH3132 @normal pen = Pen . new(BLACK)3334 @brush = {35 true => Brush . new( Colour . new(0 ,255 ,255 ,160) ) ,36 fa l se => Brush . new( Colour . new (0 ,0 ,255 ,160) )37 }3839 se t background co lour WHITE4041 # p i c k a green pen f o r each d i r e c t i o n42 @green pen = {43 true => Pen . new( Colour . new (0 ,255 ,0 ) ) ,44 fa l se => Pen . new( Colour . new (0 ,192 ,0 ) )45 } . each va lue {| pen | pen . s e t w idth (FATPENWIDTH ∗ 2)}46

128

47 @red pen = Pen . new( Colour . new (255 ,0 ,0 ) )48 @red pen . s e t w idth FATPENWIDTH ∗ 24950 f e t c h n e x t s o l u t i o n5152 Timer . every (500) { f e t c h n e x t s o l u t i o n ; on pa int }5354 ev t pa in t { on pa int }55 e v t s i z e { on pa int }5657 show58 end59 def f e t c h n e x t s o l u t i o n60 return i f @solut ions . empty?61 s o l u t i on = @so lut ions . s h i f t62 i f s o l u t i on [ : o f f s e t ]63 @o f f s e t = so l u t i on [ : o f f s e t ]64 else65 @o f f s e t = {}66 @con t r o l l e r s . each {| sc | @of f s e t [ sc ] = sc . o f f s e t }67 end68 i f s o l u t i on [ : speed ]69 @speed = so l u t i on [ : speed ]70 else71 @speed = {}72 @coordinat ions . each {| coord | @speed [ coord ] = coord . d e f au l t sp e ed }73 end74 i f s o l u t i on [ : c y c l e t ime ]75 @cycle t ime = so l u t i on [ : c y c l e t ime ]76 else77 @cycle t ime = {}78 @con t r o l l e r s . each {| sc | @cycle t ime [ sc ] = sc . cy c l e t ime }79 end80 #put s ”#{ s o l u t i o n }\n”81 end82 def on pa int83 pa i n t bu f f e r ed do | dc |84 dc . c l e a r8586 s i z = dc . s i z e87 h , w = s i z . height , s i z . width8889 # WORKAROUND p a i n t b u f f e r e d b l a c k background90 pen = Pen . new( get background co lour )91 brush = Brush . new( get background co lour )9293 dc . s e t pen ( pen )94 dc . s e t b ru sh ( brush )95 dc . draw rectang l e (0 ,0 ,w, h)96 # END WORKAROUND9798 gdc = GraphicsContext . c r ea t e ( dc )99

100 gdc . s e t pen @fat pen101102 ybase = h − @oy # base o f f s e t f o r v e r t i c a l drawing ops103104 gdc . s t r o k e l i n e (0 , ybase ,w, ybase ) # draw x−a x i s105 gdc . s t r o k e l i n e (@ox , h ,@ox , 0 ) # draw y−a x i s106107 dc . s e t pen @normal pen108109 # s c a l i n g f a c t o r o f t ime to p i x e l s on the y−a x i s110 y s ca l e = ybase / @tmax111112 # s c a l i n g f a c t o r o f d i s t a n c e to p i x e l s on the x−a x i s113 x s ca l e = (w − @ox) / @distmax . t o f114115 # draw d i s t a n c e h e l p e r l i n e s ( v e r t i c a l )116 500 . s tep (@distmax . round ,500 ) do | d |117 x = (d ∗ x s ca l e ) . round + @ox118 dc . d raw l ine (x , h , x , 0 )119 end120121 common cycle = @cycle t ime . va lues . f i r s t122 # draw time h e l p e r l i n e s ( h o r i z o n t a l )123 common cycle . s tep (@tmax . round , common cycle ) do | t |124 y = ybase − ( t ∗ y s ca l e ) . round125 dc . draw text ( ”#{t}” , 1 , y )126 dc . d raw l ine (0 , y ,w, y )127 end128129 # i n s e r t t h e names o f t h e i n t e r s e c t i o n s130 # and cu r r en t o f f s e t s131 for sc in @cont r o l l e r s132 x = ( sc . p o s i t i o n ∗ x s ca l e ) . round + @ox133 dc . draw text ( ”#{sc . p o s i t i o n }” , x + 1 , ybase )134 dc . draw text ( ”O=#{@of f s e t [ sc ]} ” , x − 1 , ybase + 12)

129

135 dc . d raw rota ted text ( sc . name , x , h − 5 , 90)136 end137138 # i n s e r t cu r r en t speed s o f c o o r d i n a t i o n s139 for coord in @coordinat ions140 x = ( x s ca l e ∗ [ coord . sc1 . po s i t i on , coord . sc2 . p o s i t i o n ] . mean) . round + @ox141 speed = ”#{(@speed [ coord ] ∗ 3 . 6 ) . round}km”142 speeds ign = coord . l e f t t o r i g h t ? ”#{speed} −>” : ”<− #{speed}”143 tw , th = dc . g e t t e x t e x t e n t ( speeds ign )144145 y = h − 1 − ( coord . l e f t t o r i g h t ? 2 : 1) ∗ th146 dc . draw text ( speeds ign , ( x − tw /2 . 0 ) . round , y )147 end148149 # true => l e f t t o r i g h t , f a l s e => r i g h t t o l e f t150 g r e e n l i g h t s = {true => [ ] , fa l se => [ ] }151152 # draw a band where t h e wid th cor r e sponds to t h e green t ime153 # in the a r t e r i a l d i r e c t i o n154 @coordinat ions . each do | coord |155 gdc . s e t b ru sh @brush [ coord . l e f t t o r i g h t ] # fo r f i l l i n g wave bands156157 sc1 , sc2 = coord . sc1 , coord . sc2158 i f coord . l e f t t o r i g h t159 l s t a r t = sc1 . p o s i t i o n160 lend = l s t a r t + coord . d i s t ance161 else162 l s t a r t = sc2 . p o s i t i o n + sc2 . i n t e r n a l d i s t a n c e + coord . d i s t ance163 lend = l s t a r t − coord . d i s t ance164 end165166 # TODO: draw wave bands f o r c o n t r o l l e r s in t h e ends o f t h e a r t e r i a l167 # ( the i n t e r n a l c o n t r o l l e r s w i l l be drawn because t h ey are sc1 in some

coo r d i na t i on )168 sc1 . greenwaves ( @horizon , @o f f s e t [ sc1 ] , coord . f r om d i r e c t i on , @cycle t ime [ sc1 ] ) .

each do | band |169 t1 = band . t s t a r t170 t2 = t1 + band . width171 t1 , t2 = t2 , t1 unless coord . l e f t t o r i g h t172173 x1 = ( l s t a r t ∗ x s ca l e ) . round + @ox174 x2 = ( lend ∗ x s ca l e ) . round + @ox175 y1 = ybase − ( t1 ∗ y s ca l e ) . round176 y2 = ybase − ( ( t1 + coord . t r ave l t ime (@speed [ coord ] ) ) ∗ y s ca l e ) . round177 yde l ta = ( ( t2 − t1 )∗ y s ca l e ) . round # wid th o f t h e band in p i x e l178179 # mark the path o f t h e green band180 path = gdc . c r ea t e pa th181182 path . move to point ( x1 , y1 )183 path . a dd l i n e t o p o i n t ( x2 , y2 )184 path . a dd l i n e t o p o i n t ( x2 , y2 − yde l ta )185 path . a dd l i n e t o p o i n t ( x1 , y1 − yde l ta )186 path . a dd l i n e t o p o i n t ( x1 , y1 )187188 gdc . s e t pen ( @fat pen ) # fo r drawing edge s o f t h e bands189190 # ou t l i n e t h e marked band us ing cu r r en t pen then f i l l u s ing green brush191 gdc . f i l l p a t h ( path )192193 g r e e n l i g h t s [ coord . l e f t t o r i g h t ] << [ x1 , y1 , x1 , y1 − yde l ta ]194 end195196 # pa in t a l l mismatches ( wave bands meet ing a red l i g h t )197 gdc . s e t pen @red pen198199 x = ( coord . c o n f l i c t p o s i t i o n ∗ x s ca l e ) . round + @ox200 coord . mismatches in hor i zon ( @horizon , @o f f s e t [ sc1 ] , @o f f s e t [ sc2 ] , @speed [ coord ] ,

@cycle t ime [ sc1 ] , @cycle t ime [ sc2 ] ) do | band |201 t1 = band . t s t a r t202 t2 = t1 + band . width # pa in t tend i n c l u s i v e203 gdc . s t r o k e l i n e (x , ybase − ( t2 ∗ y s ca l e ) . round , x , ybase − ( t1 ∗ y s ca l e ) . round

)204 end205 end206207 # draw a l i n e f o r t h e green s i g n a l du ra t i on208 for l 2 r i ndc , g r e e n l i g h t s f o r d i r e c t i o n in g r e e n l i g h t s209 for x1 , y1 , x2 , y2 in g r e e n l i g h t s f o r d i r e c t i o n210 gdc . s e t pen @green pen [ l 2 r i n d c ]211 gdc . s t r o k e l i n e ( x1 , y1 , x2 , y2 )212 end213 end214 end215 end216 end217218 i f FILE == $0

130

219 r equ i r e ’ greenwave eval ’220 App . run{RoadTimeDiagram . new}221 end

Listing 20: paramtuning.rb1 # s c r i p t s used in t h e parameter tun ing o f s imu l a t e d annea l i n g23 r equ i r e ’ const ’4 r e qu i r e ’ greenwave eval ’5 r e qu i r e ’ r u by t e s t s e r v e r ’67 TIME = [ 0 . 5 ] # seconds89 ALPHA = [ 0 . 9 ] #[ 0 . 8 , 0 . 8 5 , 0 . 9 , 0 . 9 5 , 0 . 9 8 ] # cooldown f a c t o r s

10 TEMP = [ 1 0 0 ]#,200 ,300 ,400 ,500 ] # s t a r t i n g t empera tu re s11 JUMPSTART THRESHOLD = [ 7 5 ] #[50 ,75 ,100 ,125 ,150 ]12 OFFSET SPLIT = [ 0 , 0 . 5 , 0 . 5 5 , 0 . 6 , 0 . 6 5 , 0 . 7 , 0 . 7 5 , 0 . 8 , 0 . 8 5 , 0 . 9 , 0 . 9 5 , 0 . 9 9 , 1 . 0 ]13 RUNS = 101415 v i s s im = Vissim . new1617 HERLEV CONTROLLERS = vis s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 1 . . 5 ) === sc . number}18 GLOSTRUP CONTROLLERS = vis s im . c o n t r o l l e r s . f i n d a l l {| sc | ( 9 . . 1 2 ) === sc . number}1920 PROBLEMAREA = [21 {22 : name => ’ Her lev ’ ,23 : c o n t r o l l e r s => HERLEV CONTROLLERS,24 : c oo rd ina t i on s => pa r s e c oo rd i na t i on s (HERLEV CONTROLLERS, v i s s im )25 } ,26 {27 : name => ’ Glostrup ’ ,28 : c o n t r o l l e r s => GLOSTRUP CONTROLLERS,29 : c oo rd ina t i on s => pa r s e c oo rd i na t i on s (GLOSTRUP CONTROLLERS, v i s s im )30 }31 ]3233 combinations = [ ]3435 ALPHA. each do | alpha |36 TEMP. each do | temp |37 JUMPSTART THRESHOLD. each do | th |38 combinations << { : s tar t temp => temp , : alpha => alpha , :

no improvement act ion thresho ld => th}39 end40 end41 end4243 r e s u l t s = [ ]4445 t e s t e r = Tester . new46 while saparms = combinations . pop47 puts ”Remaining t e s t s : #{combinations . s i z e }”48 OFFSET SPLIT . each do | o f f s e t s p l i t |49 PROBLEMAREA. each do | pa |50 TIME. each do | time |51 encumbent values = [ ]52 RUNS. t imes do53 r e s u l t = t e s t e r . r un s o l v e r ( saparms , time , 80 , pa [ : c oo rd ina t i on s ] , o f f s e t s p l i t )

+ saparms54 encumbent values << r e s u l t [ : encumbent value ]55 end56 mean = encumbent values . mean57 std = encumbent values . dev i a t i on58 r e s u l t s << saparms + { :mean => mean , : std => std , : area => pa [ : name ] , :

o f f s e t s p l i t => o f f s e t s p l i t }59 end60 end61 end62 end6364 so r t ed = r e s u l t s . s o r t {| r1 , r2 | r1 [ : mean ] == r2 [ : mean ] ? r1 [ : std ] <=> r1 [ : s td ] : r1 [ : mean ]

<=> r2 [ : mean ]}6566 data = [ [ ’ Area ’ , ’ Cool ing Factor ’ , ’ S ta r t i ng Temperature ’ , ’ Jumpstart Threshold ’ , ’ O f f s e t

Probab i l i t y ’ , ’Mean ’ , ’ Deviat ion ’ ] ]6768 PROBLEMAREA.map{| pa | pa [ : name ] } . each do | area |69 puts ”Top r e s u l t s in #{area } : ”70 so r t ed . f i n d a l l {| r | r [ : area ] == area } . each do | r e s |71 puts ” alpha = #{r e s [ : alpha ]} , s t a r t temp = #{r e s [ : s tar t temp ]} , th r e sho ld = #{r e s [ :

no improvement act ion thresho ld ]} => ” +72 ”#{r e s [ : mean ]} (#{ r e s [ : std ]} ) ”73 data << [ area , r e s [ : alpha ] , r e s [ : s tar t temp ] , r e s [ : no improvement act ion thresho ld ] , r e s

[ : o f f s e t s p l i t ] , r e s [ : mean ] , r e s [ : s td ] ]74 end

131

75 end7677 t o x l s ( data , ’ d a t a o f f s e t ’ , F i l e . j o i n ( ’d : ’ , ’ greenwaves ’ , ’ r e s u l t s ’ , ’ paramtuning . x l s ’ ) )

[]

132