Agent-Based Modelling of Traffic EvacuationStrategies

Jamal Rahman1416458

Supervisor: Dr. J. A. Bullinaria

MSci Computer Science

April 2019

School of Computer ScienceUniversity of BirminghamBirmingham, B15, 2TT

Abstract

Understanding complex traffic-based evacuation scenarios is a task which lends itself to

computational simulation via Agent-Based Modelling. This project develops a flexible,

highly parameterised simulation which is capable of modelling traffic-based evacuations

on arbitrary network topologies, and evaluating evacuation performance over a config-

urable range of scenarios. Agents utilise a continuous-space adaptation of the Nagel-

Schreckenberg algorithm to evacuate any network via their shortest path. The throttling

route-management strategy is implemented, altering the status of the road network in

real time, and agent behaviours are augmented with the inclusion of greedy traits. The

program is capable of launching a broad range of investigations into the problem space;

specific investigation is undertaken into the throttling route management strategy, and

into the nature of greedy evacuee decision making. Findings indicate that throttling can

improve evacuation times up to 35%, and that the impact of greedy decision making

can similarly improve regional evacuation times up to 38%, with a bias towards highly

inter-connected networks.

i

Acknowledgements

I would first like to express thanks to my project supervisor, Dr John Bullinaria, for his

guidance throughout the duration of the project.

I also want to extend my unbounded gratitude to both of my parents and to Amelia

Elgey. Without their incredible support I surely would not have been able to complete

this project.

ii

Contents

1 Introduction 1

1.1 Agent-Based Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3

2.1 Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.1 Existing Software and Frameworks . . . . . . . . . . . . . . . . . . 4

2.3.2 Environment Representation . . . . . . . . . . . . . . . . . . . . . . 5

2.3.3 Vehicle behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 ABM Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Agent Greed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.2 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.3 Flow management & Routing . . . . . . . . . . . . . . . . . . . . . 8

3 Project Specification 10

3.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 System Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Road Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2 Agent Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.3 Simulation Configuration . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Experiment Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Design 16

4.1 Mason . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Running Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Implementation 21

5.1 Network Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Traversing Network Space . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iii

5.3 Dynamic Routing - Greed & Throttling . . . . . . . . . . . . . . . . . . . . 23

6 Experimentation 25

6.1 Throttling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 Agent Greed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2.1 The Sioux Falls Network . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2.2 Visual Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2.3 An Alternative Network . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7 Conclusion 34

7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.3 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A Structure of Project Directory 38

A.1 Running the Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.2 Compiling the programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

B List of Configurable Parameters 40

C Configuration File Format 42

iv

List of Figures

3.1 A triangular road network encoded as a file and visualised . . . . . . . . . 12

3.2 An example experiment configuration file . . . . . . . . . . . . . . . . . . . 14

4.1 Project component relationship diagram . . . . . . . . . . . . . . . . . . . 17

4.2 Annotated images of the EvacVisual simulation visualisation components . 19

5.1 Network Space road traversal . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Diagram depicting neighbour recognition during agent rerouting . . . . . . 23

6.1 Madireddy et al. throttling test network. . . . . . . . . . . . . . . . . . . . 25

6.2 Heatmap portraying how the upper and lower thresholds of throttling affect

clearance time. Darker zones have a greater performance when compared

to the base case - no throttling at all . . . . . . . . . . . . . . . . . . . . . 26

6.3 Reference heatmap from the study by Madireddy et al on throttling thresh-

olds’ effects on clearance time [15]. . . . . . . . . . . . . . . . . . . . . . . 27

6.4 Sioux Falls road network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.5 Clearance time as a function of agent greed threshold on the Sioux Falls

network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.6 Evacuation of the Sioux Falls network at different times . . . . . . . . . . . 30

6.7 Greedy agents finding sub-optimal routes . . . . . . . . . . . . . . . . . . . 31

6.8 An artificial grid network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.9 Clearance time as a function of agent greed threshold on the artificial grid

network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

C.1 Control variable XML format . . . . . . . . . . . . . . . . . . . . . . . . . 42

C.2 Independent variable XML format . . . . . . . . . . . . . . . . . . . . . . . 42

C.3 Network from file XML format . . . . . . . . . . . . . . . . . . . . . . . . . 43

C.4 Procedurally generated grid XML format . . . . . . . . . . . . . . . . . . . 43

v

Chapter 1

Introduction

An emergency evacuation is the time-critical migration of people from a dangerous situa-

tion to a position of safety. Disasters such as fires, floods, hurricanes and nuclear hazards

can call for evacuations of potentially large regions, and studies have shown that an evac-

uation of greater than 1000 people occurs, on average, every two to three weeks in the

USA [1, 2]. As urban environments become increasingly densely populated, regional in-

frastructure is often found ill-equipped to handle the stress of an evacuation scenario [3],

and in recent decades eyes have increasingly turned towards the factors that play into

evacuation issues [4] such as households evacuating with more cars than necessary, and

the region evacuating too quickly leading to crippling congestion on the road network.

If we can understand the factors that are at play in an evacuation, authorities and local

governments will be able to design schemes for more efficient and successful egress. Prac-

tical evacuation drills on a regional scale are expensive, pose ethical issues and are often

simply impossible, for this reason researchers have turned to computational simulation.

1.1 Agent-Based Modelling

Computer simulation of evacuation scenarios historically used top-down modelling tech-

niques. A top-down technique aims to characterise the macroscopic outcome of a phe-

nomenon using general terms. For example, evacuation systems have previously been

modelled using fluid dynamics, drawing parallels between an individual in a crowd with a

molecule in a wave [5]. In contrast, a bottom-up model aims to characterise the individual

components of a system on a microscopic basis, modelling their actions and allowing their

interactions to naturally produce an emergent phenomenon.

Microsimulation is more computationally taxing than macrosimulation, demanding

processing time for each agent in the system; however, bottom-up approaches are able

to account for interactions between agents, a concept that top-down models are unable

to replicate. Modelling scenarios by defining the behaviour of the individual agents is

referred to as agent-based simulation or agent-based modelling (ABM). For our purposes

1

we shall use the term ABM to describe such a system.

Microscopic simulation of road networks started becoming computationally feasible in

the 1990s, beginning a surge of research that attempted, and succeed, to accurately model

road traffic [6]. As computing power increased further, ABM research accelerated rapidly

in the 21st century [7, 8].

1.2 Overview

This report describes the formulation, design and implementation of a multi-agent sim-

ulation program for traffic-based evacuation scenarios - and experimentally investigates

the impact different strategies and scenario effects can have on evacution time.

Chapter 2 will introduce the background behind the field of agent-based modelling,

initially from an abstract context and then within the realm of traffic simulation. We will

consider how similar evacuation models have been leveraged, to provide an understanding

of the problem space wherein this project lies.

The Project Specification section first gives a formal designation of the project aims

- thereafter specifying, in explicit terms, the high-level functional requirements of the

program, the program capabilities, and the description of fundamental aspects of the

simulation itself. Here, we shall have an understanding of what the system does and

broadly how it will attempt to do so.

System design is addressed in Chapter 4, giving an overview of how the system’s

components interact with each other.

The Implementation section explores the realisation of core system components. In

particular, we cover the framework for moving within road networks, and the associated

algorithms that dictate agent behaviours.

Chapter 6 uses the system to experimentally investigate the effects that two partic-

ular evacuation scenarios have on total evacuation time, and analyses how the emergent

behaviour drives the outcome.

2

Chapter 2

Background

A preeminent introduction to ABM is given by Macal and North (2005), which provides

a thorough discussion on what defines an agent. In brief, an agent is an entity which acts

independently within an environment:

2.1 Agents

Agents are governed by a set of rules which dictate how they react to their environment

and to other agents. Some agents have the ability to perceive and store memory of the

environment, as well as events within it, and may adapt their behaviour according to

their perceptions [9]. An agent need not be realised specifically as a human; a simulated

road network will model a vehicle as an agent, and some models may model collections of

jointly-acting people, such as families, as agents [10]. As long as the collective-agent acts

as an independent individual this is accepted.

Agent behaviour can be described at different levels of complexity; it is impracticable

to describe the full decision making process behind an agent’s actions, accounting for a

large set of memories and perceptions. Primitive agents may be modelled as finite state

machines [11], and in some cases a simple behavioural model is built from a statistical

estimation of the agent’s behaviour [12].

ABM’s benefits as a simulation technique are due to its natural ability to capture

emergence, its parallels to real-world systems, and its flexibility [7]. An emergent phe-

nomenon, by definition, cannot be reduced to the sum of its parts as it is the result of

interactions that are decided upon at execution time. The parallels between an agent-

based model and a real world system are intrinsic, agents are designed to directly mimic

real participants’ behaviour. Lastly such systems are flexible in scale; it’s easy to increase

the number of agents, change the environment or tweak the simulation parameters with-

out making any fundamental changes to the model. Because of this, ABM is notorious

for excelling at posing ‘what if’ questions and investigating hypothetical scenarios.

3

2.2 Environments

Careful consideration of the real world must be taken when designing the fundamental

architecture of an ABM - most importantly when choosing the agents’ environment. Some

applications require a minimal environment, such as in a supply chain model which sets

agents as factories, retailers, consumers, etc and allows them to communicate with each

other [13]. Here the environment need only be the collection of agents themselves. Al-

ternatively environments may take on a more literal representation, providing a spatial

description of a physical environment as is more commonly seen when studying ecological

and social behaviour [9].

When simulating physical, ecological, and sociological phenomena, environments typ-

ically fall into three categories: continuous, cellular automata (CA) and networked. Con-

tinuous representations use a continuous (x, y) coordinate system within which agents act.

CA is a discrete environment, chunking space into a grid. CA models make for a trade

off between model accuracy and computational ease; agents reside within a grid cell and

naturally have eight surrounding cells. This limitation allows for a simple model that is

computationally efficient while still approximate of real space. Lastly, many simulation

applications can be realised on a network, or graph. Across all environment representa-

tions, the timestep of simulation can be adjusted as a trade off between computational

load and model accuracy. It comes naturally to model a regional evacuation scenario

using a network environment.

2.3 Traffic Model

In order to perform research on road network evacuations, a robust agent-based model

must first be constructed. In ABM, there is no one accepted process for building simula-

tions and running experiments. Numerous approaches are taken to model road networks,

and to simulate evacuation scenarios on them.

2.3.1 Existing Software and Frameworks

In the field of ABM, regardless of application area, there is a distinct split between

commercial systems and programming frameworks. Typically, researchers use frameworks

to make new advancements in their respective problem areas, and development studios

implement new techniques into user friendly commercial systems, often with government

officials in mind as end users.

4

CORSIM, VISSIM and Paramics

CORSIM, VISSIM and Paramics are three commonly used commercial software packages

for traffic modelling.

The systems do not greatly differ in functionality, as all three of the systems specialise

in producing a highly representative simulation of the roads. Their focus is on such

microscopic matters as modelling the dynamics of different classes of vehicle and other

low level details that allow them to accurately model the flow of traffic through individual

complex intersections, and small networks [14]. CORSIM, VISSIM and Paramics all allow

for programming of the simulation parameters, and they provide comprehensive 2D and

3D visualisation features.

MASON

For researchers who need to build models from the ground up, none of CORSIM, VIS-

SIM or Paramics are suitable, as the three models are inflexible towards implementing

novel strategies. For such demands, frequently used ABM software frameworks include

NetLogo, MASON (Multi-Agent Simulator of Neighbourhoods/Networks) and the Repast

Suite. Netlogo uses a proprietary scripting language, whereas MASON and Repast pro-

vide libraries for working in Java. While both solutions provide a core simulation engine,

data structures for common environment representations, and visualisation tools, Repast

was deemed to be unsuitable for this project; rather than import a library of useful code

to use in a system, Repast simulations must be run from within the Repast Suite’s own

program, and Java files can be written to configure the nature of the simulation that is

ran from the Repast main suite. Conversely, MASON operates as a typical Java library

does, allowing importing of MASON packages to add features into our own programs. An

overview of how MASON works within the project is given in Chapter 4.

2.3.2 Environment Representation

A road network can be represented as a directed graph G(N,E), where N is the set of

nodes (junctions) on the network and E the set of edges (road connections) between all

junctions. Nodes n ∈ N have coordinates (x, y) and edges e ∈ E have corresponding

lengths l [15]. Edges and nodes may possess additional properties, such as speed limits.

Simulations are often tested on synthetic network topologies, generated to mimic com-

mon road patterns [10], alternatively researchers can test on a real world road network

extracted from GIS data [16].

5

2.3.3 Vehicle behaviour

A vehicle’s goal is to reach a ‘safe’ node, at which point it is deemed to have evacuated

successfully. One approach is to define a sub-region of the network to be evacuated, and

any node not in this subset is hence in the set of safe nodes. [17] Another more common

approach is to identify which roads act as exits to the region which is being modelled,

and record their corresponding nodes as safe evacuation nodes [15, 12].

Multiple algorithms exist for modelling driving behaviour. A tried and tested traffic

algorithm is the Nagel-Schrekenberg (N-S) cellular automata model [6, 18]. See Algorithm

1. N-S is a CA model, which divides the world space into grid cells of the approximate

size of a car. At every timestep, agents will accelerate up to the speed limit, unless there

is a car in the way, in which case the agent will slow down to not collide with the car in

front. All driving behaviours incorporate a random element, to account for the human

factor. The N-S model does this by supplying a probability p with which an agent may

overbreak and reduce their speed.

Algorithm 1: Nagel-Schreckenberg (N-S) driving model

Data: Cars = (V elocity, Location)while running do

for car ∈ Cars doif velocitycar < speed limit then

velocitycar ← velocitycar + 1;if DistanceToNextCar(car) < velocitycar then

velocitycar ← DistanceToNextCar(car)− 1;if with probability p then

velocitycar ← velocitycar − 1;locationcar ← locationcar + velocitycar;

PARAMICS bases its car-following mechanism on the Fritzsche model [19] which char-

acterises five driving modes that dictate the agent behaviour, however the resultant be-

haviour is largely the same as with the N-S algorithm.

Recent research has used continuous adaptations of the N-S algorithm, forgoing the

limitations applied by CA, or have opted to use very simple approximations of the algo-

rithm [20, 15].

2.4 ABM Experiments

With robust digital models able to accurately model the nuance of the physical world,

researchers can leverage the emergence of ABM to pose questions about a hypothetical

scenario and solve the problems that arise.

6

The most important metric in evacuation research is clearance time, which is the total

time elapsed between the first evacuee leaving their source to the last evacuee reaching

their destination [21, 15].

2.4.1 Agent Greed

Zhang, Ukkusuri and Chan (2009) present a model which models the population with

varying levels of greed. In this context, a greedy agent is one who diverts from their route

depending on their perception of their route’s level of congestion. The congestion level,

ρe, of an edge e is given by the following relation:

ρe =Number of cars on edge e

length of edge e × average car length(2.1)

Formally, when a greedy agent approaches a junction it makes a judgement on the

congestion level of it’s originally planned next road. If congestion on the original planned

route exceeds a given tolerance limit, the greedy agent will divert its route via the junc-

tion’s least congested outbound road, and will re-calculate a new route starting from this

new low-congestion diversion road [10].

It is likely that a chosen less-congested diversion route will have a greater length than

the agent’s original route to the evacuation goal, to account for this, greedy agents will

not choose a new less-congested route if the new route’s length exceeds a tolerance limit

above the original route. In addition, if the greedy agent has made enough route changes

to exceed a given limit, it will not choose any more route diversions.

Zhang et al. do not draw any conclusions as to whether greedy agents make for a

more accurate or inaccurate representation of human drivers, however other research has

made assumptions of greed in their models [15].

2.4.2 Scheduling

Chen and Zhan (2006) focus on whether clearance time can be reduced by scheduling

subsections of the network to evacuate separately in a staged evacuation, as opposed to

a simultaneous evacuation where all buildings evacuate simultaneously [17]. Strategies

were compared under different population loads and across different network topologies: a

uniform grid, a series of nested and interconnected uniform rings, and a real road network

within a city in the US. The experiment performed staged evacuations across four arbitrary

zones of roughly equal area - only testing the sequenced strategies in which one zone is

ordered to evacuate at a time, and the simultaneous strategy where all four zones evacuate

at once. The study reveals that there was no general purpose superlative strategy but

at high populations, as roads become congested, the staged evacuation strategy is more

7

effective than a simultaneous evacuation for both a grid network and a real road network.

[22].

2.4.3 Flow management & Routing

Staged evacuations require planning and prior informing of the population, however in

addition to scheduling, authorities are also able to manipulate the road network during

an ongoing evacuation to increase the effectiveness of evacuation. The contraflow strategy

reroutes the network by reversing the direction of lanes which are inbound to the evacu-

ation area, turning them into additional outbound routes. A solution to the contraflow

problem is a network configuration where each edge is directed such that the network’s

clearance time is a minimum. Contraflow has received a large amount of research from a

modelling standpoint [23, 24] as well as from a managerial and logistical perspective, be-

ing implemented during real emergency scenarios and it is considered a logistically viable

management solution [25].

Contraflow is a largely solved problem, established as a useful strategy by macro-

scopic models using heuristic approaches to reorganise an optimal configuration of the

network. [24] For our purposes we need not understand the algorithms that achieve solu-

tions to the contraflow problem. An additional motivation for microsimulation is given by

Madireddy, Medeiros, and Kumara (2011) who explain that officials from Florida imple-

mented contraflow to mitigate congestion during hurricane Floyd, which did not work in

this case. The authorities turned to the CORSIM platform which was used to organically

demonstrate the flow in the contraflow topology. [15] The success of contraflow inspired

Madireddy et al. to use ABM to develop and test new traffic management strategies;

their paper introduces throttling, a technique where authorities temporarily close roads

that become too congested, and reopening the road once the congestion has sufficiently

lowered.

Throttling is designed to fully utilise the road network - by throttling congested roads,

the flow of traffic is temporarily forced to follow underutilised routes. A traffic manage-

ment actor will close a road e at a time t if the congestion level, ρe, reaches an upper

blocking threshold, UT [15].

If ρe(t− 1) < UT, ρe(t) ≥ UT, close road e (2.2)

The traffic manager will unblock a throttled road if the congestion level falls to a lower

unblocking threshold, LT [15].

If ρe(t− 1) > LT, ρe(t) ≤ LT, reopen road e (2.3)

The experiment by Madireddy et al. tested a range of congestion coefficient thresholds

for closing and reopening roads, from 0 to 1, where UT ≥ LT . Throttling was found to

8

perform comparably with contraflow, but throttling may have an advantage by being

more easily implemented in reality, and that adaptation and response to changing traffic

conditions will be more logistically feasible for throttling than for contraflow.

9

Chapter 3

Project Specification

Simulation research is a two-step process: a simulation must first be designed from known

principles, so that it accurately reflects the real world; secondly, the accurate simulation

can hence be used to run virtual experiments and learn more about the real world. This

project is an exercise in both aspects of simulation science. At the inception of the

project, an initial focus was put towards experimentation; as the project continued this

focus became balanced more evenly between empirical investigation and the engineering

of the system itself. Here we will state the formal specification of the project, what it

aims to achieve and what features it must have to accomplish its task.

3.1 Problem Definition

Previous chapters discussed the problem space around which this project is exploring,

but in explicit terms: commercial evacuation software provides the means to model the

likely outcome of traffic on a road network, but is inflexible and ill-suited for evaluating

the impact of novel strategies and factors in an evacuation scenario.

This project aims to produce a highly configurable agent-based model of regional road

networks in order to investigate traffic-based evacuation strategies. The program is to

experimentally evaluate the throttling traffic management strategy and investigate the

impacts of agent greed on network clearance time.

3.2 System Specification

For a simulation package to form a basis for experimentation, the system must be flexible

enough to capture a range of realistic and targeted scenarios in the real-world problem

space. The system will model an input of some directed graph as a road network and, using

the principles of traffic modelling discussed in Chapter 2, will run through an evacuation

scenario to completion when all cars have evacuated the network.

In addition to constructing the underlying model, it is beneficial for understanding

10

the intricacies of a simulation to visualise it in progress. However the simulation should

not be functionally dependent on any UI - it may be ran in the background, or with a

visual wrapper. Demands of the UI are minimal as the target user of the software is a

researcher; the UI should be able to: start, stop and reset a simulation; advance through

the simulation one step at a time or continuously; and lastly the UI must provide a clear

depiction of the model behaviour.

3.2.1 Road Networks

Loading a network into the system is best achieved by encoding a topology into a file

on disk (given the .net file extension) which can be read, and parsed, by the system at

runtime - this strategy affords the researcher a quick and simple method of defining new

networks in which to simulate an evacuation.

A road network is defined by a collection of nodes in continuous space - each having a

pair of (x, y) coordinates, a flag to signify if the node is an evacuation point (an exit flag),

and a flag to signify if agents may load onto the network via the node (a source flag) -

and a collection of edges, each specifying the node they are coming from (from node)and

the node to which they are directed (to node), optionally specifying a flag to signify if

the road is allowed to be throttled. Road length shall be calculated as the linear distance

between an edge’s two nodes.

Appropriately, the proprietary .net file format is defined by the following rules:

• A line beginning with the ‘#’ character defines the line as a comment, and is ignored

by the parser.

• A line composing only of ‘<NODES>’ defines the following lines as representing nodes.

• A line composing only of ‘<EDGES>’ defines the following lines as representing edges.

• A node line follows the format: ‘X-COORDINATE Y-COORDINATE EXIT-FLAG

SOURCE-FLAG’ where each argument is whitespace-sparated, EXIT-FLAG and

SOURCE-FLAG take values of zero for false and one for true.

• An edge line follows the format: ‘FROM-NODE-INDEX TO-NODE-INDEX

(THROTTLEABLE-FLAG)’ where the node index is the nth node to have been specified

in the file. For example, the first node line found in a .net file is addressed with

a node index of ‘1’. The optional THROTTLEABLE-FLAG takes binary values as node

flags do, and it represents whether the throttling algorithm will target this edge or

ignore it.

• Edge definitions must reference nodes which are already themselves defined, an

edge cannot reference a node which is defined later in the .net file. It is therefore

recommended to specify all nodes before specifying edges in a network file.

11

<NODES>

#X Y exit source

0 0 0 1

100 0 0 1

50 100 1 0

<EDGES>

#from to (throttleable)

1 2

1 3

2 1

2 3

3 1

3 2

(a) Network file encoding (b) Corresponding simulation image

Figure 3.1: A triangular road network encoded as a file and visualised

Figure 3.1 gives an example of a three node complete digraph in the form of an

equilateral triangle - the example is given in both the encoding of a .net network file and

as the system interprets and visualises the network. Here, nodes are highlighted in black

to more clearly visualise loading from a file to a road network, but nodes are not given

a visualisation in the simulation proper. All network topologies are permitted within

the program, however the simulation performance is not designed with very large scale

simulations in mind. The simulation will be used to test evacuation strategies on small

test networks and regional networks such as subsections of a city or on simplifications of

major roads in a city. In addition to reading networks from disk, the system should be

able to procedurally generate very simple artificial networks - specifically, the system will

be capable of generating a uniform grid of n× n roads with each road segment having a

length l. The artificial grid road network is an elementary test case to evaluate driving

behaviours.

3.2.2 Agent Specification

The program has two agent archetypes: the Car and the Overseer. Cars are the primary

agent in the system and the subjects of the evacuation, they are modelled as a point in

space, but they have virtual dimensions according to a parameter. Overseer agents are

those agents which do not necessarily have a contextual counterpart in the simulation, as

their roles are to implement real-time features in the simulation. It is an Overseer which

will implement evacuation strategies and control the scenario of the simulation. Unless

stated otherwise, usages of the word agent will refer to cars

12

When a car is initialised, it is randomly distributed to a source node. On initialisation,

cars calculate their shortest path to the evacuation route using the A* search algorithm

[26]. In the age of smartphones and satnav this assumption is appropriate. Traffic be-

haviour is governed by the N-S algorithm, but the specific parameters that adjust driving

behaviour are configurable. The list of car driving parameters is:

• Speed Limit

• Acceleration

• Vehicle buffer - The space kept between cars (their effective lengths)

• Perception Radius - The distance within which a car can perceive its surroundings

Evacuation strategies - namely throttling and agent-greed - are to be implemented

according to their definitions in Chapter 2, and be toggle-able within the system. Each

strategy’s parameters are also highly configurable.

3.2.3 Simulation Configuration

A full list of configurable parameters, and their definitions, is given in Appendix B. With

such numerous variables, the project demands an easy method for researchers to set up

a new scenario, test it, and set up an experiment that runs a simulation multiple times,

evaluating the effect of one or more independent variables on clearance time. As with

the network topology, it is impractical to set up every new scenario within the system

code itself, therefore it is fitting to use an external configuration file. Hence, a simulation

requires two files to run, a configuration file and a network file.

An initial format proposed for the configuration file was as a Java properties file. A

Java properties file is a text file consisting of key/value pairs. A key refers, by name, to a

variable in the program, and the associated value is assigned to the key variable at runtime.

While simple to construct and easily readable, the properties file format lacks complexity,

and is unable to capture all necessary configurables: experiments may iterate over multiple

independent variables, hence a particular parameter may either be controlled to a fixed

value or given a range of values to iterate over. Whether a variable is dependent or

independent will change how it is configured. This is not easily accomplished with simple

key/value pairs, and if it were accomplished, any simplicity that the Java properties file

had is quickly lost.

In order to express experiments with levels of complexity, XML is a sensible option -

Figure 3.2 depicts an experiment configuration which varies over two independent vari-

ables. Any variable not specified in a configuration XML file takes a default value; default

parameter values are given alongside their parameter definitions in Appendix B. A com-

prehensive overview on how to construct a configuration file is given in Appendix C.

13

<?xml version = "1.0"?>

<experiment>

<network type="file">

<filepath>config/batch3/SiouxFalls_madireddySources.net</filepath>

</network>

<repeats>10</repeats>

<variable var="populationSize" type="int">2000</variable>

<variable var="upperThreshold" type="double" varType="independent">

<min>0.0</min>

<max>1</max>

<interval>0.1</interval>

</variable>

<variable var="lowerThreshold" type="double" varType="independent">

<min>0.0</min>

<max>1</max>

<interval>0.1</interval>

</variable>

<variable var="greedEnabled" type="boolean">false</variable>

<variable var="throttlingEnabled" type="boolean">true</variable>

</experiment>

Figure 3.2: An example experiment configuration file

As all parameters are arbitrary and configurable, the simulation is agnostic towards

which units are used for each variable as long as all variable units are consistent with

each other. For example, if the researcher wants to configure velocity in miles per hour,

distances must be given in miles to avoid unit errors - this is intuitive for any system that

does not explicitly design for conflicting units. Unless specified, all default parameters

are to be interpreted as SI units where applicable.

3.3 Experiment Specification

As stated in Chapter 2, the metric to consider for every simulation run is clearance time

- the total time elapsed between the first evacuee leaving their source to the last evacuee

reaching their destination.

Research in this area is naturally sequential. Hypotheses are built on the findings

of previous experiments, which motivate the formulation of the next scenario to put to

simulation. See the experiments section for a detailed analysis of the sequential experi-

mentation process.

Initially, experiments on the effectiveness of throttling by Madireddy et al. (2011) will

be replicated, and if necessary, the effect of throttling will be evaluated across different

networks and under different simulation configurations.

Regarding agent greed, Zhang et al. (2009) do not explore whether the greedy threshold

14

of an agent, the congestion level a road must reach for an agent to choose to divert its

route, shares any clear relationship with clearance time. This relationship is evaluated in

Chapter 6.

15

Chapter 4

Design

4.1 Mason

MASON (Multi-Agent Simulation of Neighbourhoods, or Networks) is a versatile Java li-

brary for providing the key architecture in agent-based applications. MASON provides a

range of environment representations, or fields in MASON nomenclature, and a GUI sys-

tem that intuitively visualises system components that interact in and with the MASON

fields.

This project did not tie itself heavily to MASON’s broad range of features. MASON

only provided a very lightweight framework to act as a foundation for the simulation

construction: MASON fundamentally revolves around a Schedule object, which is an

enhanced priority queue. For an agent to act in the system it must inherit the Steppable

interface, which guarantees the agent has a step() method. Agents are queued into the

Schedule for each time step, and the Schedule executes the agent’s step method when it

reaches the top of the queue. In compliment with this simple functionality, the Schedule

will step higher priority agents first and will step agents of equal priority in a uniformly

random order.

In addition to the Schedule, MASON’s other contribution to the project was providing

a GUI, and MASON’s GUI-compliant graph data structure functionality. A MASON

Network is a simple collection of arbitrary user-defined objects to use as nodes, and a

map between nodes and their associated edge objects. While MASON expects users to

provide a class to act as a node, it provides its own Edge class. Edge objects store a ‘from

node’, ‘to node’ and an arbitrary user-defined child object, which is expected to store

semantic data about what the edge represents in the context of the simulation. MASON

networks hence act as wrappers for user-defined node and edge objects - to that end,

Junction objects were defined as the Network’s node objects, and Road objects were

constructed to provide a semantic representation of roads in the simulation. The driving

reason for using a MASON Network rather than constructing a graph directly from the

Junction and Road objects is the ease of the MASON network integration with MASON’s

16

Figure 4.1: Project component relationship diagram

own GUI and visualisation tools. Using MASON’s effective UI framework allows more

focus to be directed towards the core system design, and the evaluation of evacuation

strategies.

4.2 System Overview

At the highest level, the project is composed of a simulation package, working in tandem

with MASON, and a collection of classes which leverage the simulation package. Figure

4.1 gives a simple class-relationship diagram of the system which articulates this high-

level package split as well as portraying a lower level system composition; the simulation

package consists of a set of agents, a collection of environment classes, a pair of classes

for implementing the A* algorithm, and most importantly, the CoreSimulation class. A

brief overview of each component is listed in Table 4.1.

CoreSimulation is the backbone of the program - it sets up the virtual environment,

constructs a population of agents and populates the system with them. CoreSimulation

17

Class Description Class Inheritance

CoreSimulationThe simulation properStores environment fields and agents

Extends SimState

Car Implementation of car agents. Their step func-tion evaluates their environment and attemptsto move towards their evacuation goal

Implements Steppable

Extends SimplePortrayal2D

Overseer Implementation of overseer agents. An Over-seer checks the network at every step and throt-tles roads according to the throttling rulesgiven in Chapter 2.

Implements Steppable

Junction Networks are defined by Junctions connectedby MASON Edge objects.

Extends SimplePortrayal2D

Road Mason Edge objects wrap a Road object. Roadshave lengths, a record of all traffic on themand a reference to their source and destinationJunctions.

AStarSearch A utility class which Cars use to find shortestevacuation paths

AStarNode This wrapper class is used to track heuris-tic data for each Junction, which is requiredby the A* algorithm, without cluttering theJunction class which has no direct need forowning such data.

Table 4.1: Simulation class component descriptions

extends MASON’s SimState class, which is the central class in the framework. SimState

provides the Schedule and a Java implementation of the Mersenne Twister random num-

ber generator by Matsumoto and Nishimura (1998), which performs far better than

java.util.Random [27, 28].

The SimplePortrayal2D class is a MASON GUI class. By extending

this class, MASON will intuitively be able to visualise an object in the UI.

SimplePortrayal2D.draw(...) can be overridden to customise the object’s visual ap-

pearance.

4.3 Running Simulations

ExperimentSequence and EvacVisual are two ways for a user to interact with the simu-

lation. ExperimentSequence is designed to be used in the context of research, it executes

a batch of experiments. EvacVisual runs a single simulation with visualisation.

ExperimentSequence is run with an input list of simulation configuration XML files,

18

(a) Simulation display window(b) Simulation console win-dow

Figure 4.2: Annotated images of the EvacVisual simulation visualisation components

each corresponding to an individual experiment. Each experiment is handled by a an

EvacExperiment object which manages iteration across the examined space of indepen-

dent variables, and takes repeat measurements. Configuration file parsing functionality

is performed by a Configuration object.

EvacVisual also uses a Configuration object, as it requires a simulation configuration

file to run, but it does not sequence multiple simulations or record any data. The program

opens two windows on launch, the console (Figure 4.2b) and the display window (Figure

4.2a.

Display

This window shows the simulation in progress.

Roads are drawn as thin grey lines, if a road is throttled it is drawn in red. Cars are

drawn as circles; typically red but coloured blue if they are greedy agents. Image zoom

can be adjusted by the buttons in the top-right (Figure 4.2: label 1 ) and when zoomed

in the scroll bars can direct the camera view.

Console

MASON’s console feature provides a collection of interfaces that interact with the visuali-

sation. Many of these interfaces have limited use, but some are crucial - most important of

which is the lower tray of buttons (Figure 4.2: label 2 ). The contents of the tray are, from

left to right: manual step button; pause/play button; stop-and-reset button; time/step

19

counter. The time/step counter can be changed using the bottom-right dropdown menu.

An additional console feature of high importance is the Delay scale (Figure 4.2: label 3 ).

Naturally the EvacVisual program will run as fast as the processor allows it, however

adding a time delay between each advancing step slows down the animation to become

comprehensible. By default, the time resolution of the system is 1 step/second, so a Delay

of 1 would run the simulation at ‘real-time’.

20

Chapter 5

Implementation

Cars are modelled as individual agents, the Car class inherits MASON’s Steppable in-

terface which allows Cars to be treated as agents by the simulation’s Scheduler and have

their step() method called at every timestep in the simulation. Here we will discuss the

step() method, what it does, and why. First though, we must understand how an agent

percieves the world around it.

Algorithm 2: Adapted N-S model

Data: Cars = (V elocity, Location)while running do

for car ∈ Cars doif velocitycar < speed limit then

velocitycar ← velocitycar + acceleration;if DistanceToNextCar(car) < velocitycar then

velocitycar ← DistanceToNextCar(car)− vehicleBuffer;if with probability p then

velocitycar ← velocitycar − 1;locationcar ← locationcar + velocitycar;

Modern processors no longer necessitate using CA environments in ABM, allowing

continuous systems to simulate emergent behaviour with a greater spatial fidelity. Agents

in this model exist in such a continuous 2D space, but this presents challenges. Most

trivially, the N-S algorithm must be adapted to work for continuous environments, however

this is easily overcome as the design of N-S does not strictly require a discrete coordinate

space to function. An adapted N-S algorithm is given in Algorithm 2. Adapting the N-S

algorithm simply requires an adjustment to cases where the agent must slow down due

to another car in front of it. Where discrete N-S slows an agent down so that it comes to

occupy the cell immediately behind the cell of the car in front of it, continuous N-S slows

the same agent down so that its position is some arbitrary stopping buffer behind the car

in front of it. In adapting N-S, the typical unit acceleration of 1 was also replaced with

an arbitrary acceleration parameter which brought the algorithm in line with common

21

modern implementations [15].

A more difficult problem brought about by the environment is implementing agents

that follow the roads, and designing how an agent will process nearby cars into its own

perception of the road ahead. The solution to this problem is found by giving agents

access to the real, 2D, global space as well as a second network space within which they

can process their surroundings.

5.1 Network Space

Network space is a one-dimensional coordinate system defined by an agent’s current road

segment and the current position along the length of the 1D vector of the road, we shall

call this current length along a road the index. Network space is best understood using

an example, with Figure 5.1 for reference:

Figure 5.1: Network Space road traversal

Let r be a road of length lr = 30 units, directed from a junction j1 towards a junction

j2. Suppose a car c1 is positioned 20 units along the road, then the index of c1 on r is

equal to 20. Suppose the next car ahead of c1, being c2, is 5 units in front, the index of c2

on r is equal to 25. By definition, if the index of a car on road r reaches lr then that car

must have traversed the length of the road and reached the road’s destination node, j2.

Here we have been able to reduce a car’s two dimensional road behaviour to one

dimension. In reality the network space is two dimensional, as the first dimension is

the index/position and the second dimension refers to the roads themselves, however in

practise the driving behaviour can focus on this first linear dimension. In compliment

with the network space, cars still exist in and move through the global 2D space - this

facilitates agents that are able to perceive and react not only to the roads but also any

other feature in their vicinity. None of the experiments in the scope of this project take

advantage of this capability, but potential applications of the feature include allowing cars

to interact with pedestrians in the 2D space, and programming cars to react to seeing fire

or some other hazard anywhere in the environment.

22

As cars move through network space, a transformation is needed to calculate their

location in global space. For a car, c at a network space index i on a road r of length lr

from junction v to junction w, the global space position of c, pc, is given by:

pc = v + i · v̂w = v + i(~vw

lr) (5.1)

The x and y coordinates of c are found by separating equation 5.1 into its x and y

components:

xc = vx + i(xw − xv

lr) (5.2)

yc = vy + i(yw − yvlr

) (5.3)

5.2 Traversing Network Space

Returning to our earlier example of network space: if c2, which is at index 25 on a road r

of length lr = 30, has a velocity in the current timestep of v = 5 + ε, ε > 0, hence v > 5,

then its next calculated index must exceed the length of the road and it must travel

through the junction j2 and onto the next road segment. c2 will travel a distance of ε onto

the new road, as residual movement which carries over the junction. This interaction is

shown in Figure 5.1.

5.3 Dynamic Routing - Greed & Throttling

Encountering a junction is not as simple as having to transfer which road the car is

tracking, and handle any residual movement over the transition; with the implementation

of dynamic routing strategies, an agent may change its route as it approaches a junction.

Figure 5.2: Diagram depicting neighbour recognition during agent rerouting

23

When an agent executes its step() function, it first calculates its step velocity accord-

ing to the road and traffic ahead. If, due to its velocity, an agent calculates it will reach

a junction in the current step it makes an evaluation of the upcoming junction’s different

roads to recognise congested and throttled routes, and change its route accordingly.

Before the agent can execute its move and traverse over the junction onto its next

road, the agent must re-calculate its current step velocity - this is because a change in

route means whichever car is immediately in front of the agent, the nearest neighbour,

will have changed as well. By definition, if an agent is able to travel through a junction

then there was no neighbour between itself and the junction - its nearest neighbour must

have been on the next road segment, or even further away. If the neighbour was on

a road segment which the agent dynamically reroutes to avoid, that neighbour can be

ignored as it no longer presents any relevance to the agent. The agent must instead find

its actual new neighbour on its new route, and calculate its velocity accordingly. Figure

5.2 illustrates an example of route switching and neighbour recalculation. In extreme

cases, where indexNewNeighbour ≤ vehicleBuffer then the agent will not actually be able

to traverse through the junction as there is no room at the beginning of the next road, its

velocity will be clipped according to the adapted N-S algorithm such that the car comes

to a halt at the junction and waits for space to open up on the road.

24

Chapter 6

Experimentation

This chapter details the sequential investigations made into the impact of throttling and

agent greed on evacuation clearance time. For each section, a brief simulation configura-

tion is explained, the results are stated, and motivations for the findings are analysed.

6.1 Throttling

In this section, we replicate an experiment by Madireddy, Mediros and Kumara (2011),

which investigates the relationship between throttling-thresholds and network clearance

time. We evaluate an evacuation of 1000 agents on a test network (Figure 6.1), the

simulation speed limit, acceleration, and vehicle buffer (vehicle size) are 20m/s, 1m/s2,

and 4m. The simulation is run for upper threshold (UT) and lower threshold (LT) values

in the ranges UT ∈ {0, 0.1, 0.2, ..., 1} and LT ∈ {0, 0.1, 0.2, ..., 1} where LT ≤ UT . Recall

that UT refers to the congestion level of a road required for the traffic management agent

to close the road and LT refers to the congestion level a road must fall to for it to be

re-opened. Each simulation is run 10 times.

Figure 6.1: Madireddy et al. throttling test network.

The network has 6 nodes. Nodes 1, 2 and 3 are source nodes, and node 7 is the evacua-

tion node. Every agent is 100% greedy with a greedy threshold of 1 - this means an agent

25

will make always make a greedy decision if its route reaches maximum capacity. Without

throttling, the routes {1,5,7} and {3,6,7} will be under utilised, hence the experiment

aims to throttle edges {1,2}, {2,4}, and {3,4}. It reasons to stand that there will be an

optimal (UT,LT) pair which best forces evacuation route utilisation.

Figure 6.2 shows a heatmap of the experiment’s results. Darker zones reflect a greater

improvement on clearance time compared to the base case of not using throttling at all.

The greatest improvement found was a clearance time improvement of 35% for UT =

0.4, LT = 0.4. Throttling loses its effectiveness as it is configured to extreme thresholds,

but otherwise shows a consistent improvement of 20% improved clearance time for the

network.

Interestingly, the graph seems to indicate that UT dominates LT in their impact on

clearance time. For a fixed UT value, the system performance does not vary much as the

values of LT are iterated through. Contrary to this, for any fixed LT value, the system

performance varies heavily over the range of UT values.

Figure 6.2: Heatmap portraying how the upper and lower thresholds of throttling affectclearance time. Darker zones have a greater performance when compared to the base case- no throttling at all

As a reference, Figure 6.3 gives the equivalent results by Madireddy et al, which agrees

that extreme threshold values have a minimal impact on clearance time, but their results

for the majority of threshold values present an overall different story. Their set of results

shows a peak of performance at UT = 0.1, LT = 0.1 which falls off extremely quickly for

other threshold values. Most unusually, the experiment by Madireddy et al. predicts a

non linear relationship. For example, for a set value of LT = 0.5, Madireddy et al predict

that clearance time decreases as UT increases, until LT = 0.5, UT = 0.8 where evacuation

performance temporarily climbs again. This inconsistent trend persists throughout the

26

Figure 6.3: Reference heatmap from the study by Madireddy et al on throttling thresholds’effects on clearance time [15].

heatmap given by Madireddy et al.

In contrast, this project finds that evacuation thresholds hold a much more consistent

linear relationship with clearance time. Our result set represents a far more intuitive

characterisation of the expected behaviour of the system:

A faster clearance time is ultimately achieved by minimising the trip time of cars.

A short route will be chosen in an agent’s pathfinding, and will hence become more

congested. Therefore with a low UT value, short routes will be closed frequently (e.g.

road {1,4} on Figure 6.1), and cars will be forced to take the longer route (e.g. path

{1,5,7}). Hence the average car’s journey will be longer than is optimal due to it taking a

longer path. With a high UT value, the cars will more frequently be able to take the short

route, however due to increased congestion on the route they will lose time in slow traffic

- and even exceed the journey time that would have been accomplished by taking the long

route. There is some intermediate UT value which optimises the average evacuation time

by splitting the cars optimally between shorter and longer routes.

Within the above problem of varying UT, there is the sub-problem of optimising the

unblocking threshold, LT. As explained, UT dictates how congested a road can get and

still allow cars in - this means UT has great control over whether cars will ultimately

waste time in congestion, and whether a car is likely to gain access to a short route.

This explains why UT dominates LT. LT only mitigates, or adjusts, the impact on

traffic flow which has been dictated by UT.

Another paradigm of framing the problem is by flow potential and road utilisation.

If a short route becomes detrimentally congested but not throttled, and a slightly longer

route hence goes unused, the system is under utilising the long route and losing potential

27

Figure 6.4: Sioux Falls road network

evacuation flow. The reverse is true for under utilising a short route which is kept closed

after traffic dies down - the potential high flow of traffic down this road is not taken

advantage of and is lost.

Our results find that throttling has a greatest impact on clearance time as the values

for UT and LT approach each other. This also makes intuitive sense. An optimal UT value

directs just enough cars into a short road so that they can evacuate quickly and avoid

the longer alternative route, but not enough cars that the congestion starts detracting

from their journey time. Having an LT value equal this threshold means that throttled

roads operate on a one-in-one-out policy - thus perpetually maintaining the optimum road

utilisation.

6.2 Agent Greed

Zhang, Ukkusuri, and Chan (2009) proposed the greedy agent framework that this project

and prior throttling models have implemented. A factor that has been overlooked by

prior work is that of an agent’s greedy threshold - i.e, the level of congestion required to

motivate a greedy agent to make a diversion. We shall experimentally investigate how a

population’s greedy threshold affects the clearance time of the scenario.

6.2.1 The Sioux Falls Network

Greed threshold was investigated on the Sioux Falls reference network (Figure 6.4). Nodes

1 and 2 are evacuation nodes, all other nodes are source nodes over which the population

of agents is randomly distributed. The system is configured with throttling disabled and

speed limit, acceleration, vehicle buffer, and population as: 20, 1m/s2, 4m, and 2000.

Parameters which defined greedy behaviour are controlled; population greed proportion,

28

Figure 6.5: Clearance time as a function of agent greed threshold on the Sioux Fallsnetwork

agent greed chance, max greedy length factor and max greedy changes are set to: 1 (Every

agent is greedy), 1 (greedy agents always act greedily if the situation allows), 2, and 15.

Each simulation was ran 10 times to obtain statistical significance. Clearance time was

tested for 0 ≤ greedThreshold ≤ 1, at intervals of 0.1, and the results were measured

against the base case of no greed in the system to find the percentage improvement that

greedy agents bring to the evacuation scenario. Figure 6.5 plots the average clearance

times, and standard deviations, across the range of tested greed thresholds.

Simulation results find that for all greed thresholds below 0.8, the evacuation clearance

time is reduced, and for thresholds above approximately 0.8 the system can be expected

to perform worse than the base case. The optimal greed threshold was 0.3, however this

only resulted in a system improvement of 10%.

To investigate further, and try to deduce why high greed thresholds caused the evacu-

ation time to worsen, it was best to turn to visual analysis of the simulation to understand

what behaviour was emerging in the system.

6.2.2 Visual Analysis

During the early stages of an evacuation, the roads are largely sparesely congested. As

the simulation progresses, all traffic tends to converge towards the evacuation points and

traffic builds up accordingly. In the Sioux Falls network, there are two evacuation points

on opposing sides of the city. As expected, traffic builds up behind each evacuation point,

29

forming two channels of congested traffic (Figure 6.6b).

At low thresholds, agents avoid congestion buildups and take greedy diversions earlier

in the simulation. At high thresholds, agents will only make greedy route changes as

traffic converges towards the final channels and local congestion levels rapidly rise.

(a) t = 100Early simulation

(b) t = 2460Distinct channel formation

(c) t = 3300Right side congestion

Figure 6.6: Evacuation of the Sioux Falls network at different times

In every simulation the ‘rightmost channel’ towards node 2 remains gridlocked far after

the ‘left channel’ has fully evacuated through node 1 (Figure 6.6c), a prime example of

under-utilisation and lost flow potential. A more optimal routing would balance the egress

of agents through nodes 1 and 2. Visual analysis reveals that when agents in the right

channel make a greedy diversion, they always end up back in the channel, providing no

benefit to the system and only increasing the agent’s total evacuation time as it reroutes

back into the gridlock.

Recall that the greedy algorithm by Zhang et al. programs agents to first navigate

down the least congested road segment to immediately avoid a congested road, thereafter

using regular path finding to navigate the remainder of the route to the evacuation point.

This behaviour is intended to find proximal pseudo-optimal alternative routes, but the

visualisation shows that agents are often either re-navigating down the road segment

they originally diverted to avoid, or effectively diverting around the first congested road

segment only to join the congested channel immediately after. For both situations, the

agent will attempt another greedy diversion when they reach the congested road again, and

will begin a back-and-forth behaviour until they finally exceed their max greedy changes

parameter, at which point the agent gives up attempting a greedy diversion and joins

the gridlock permanently. The annotated Figure 6.7 uses arrows to highlight three of the

aforementioned behaviours identified in simulation.

6.2.3 An Alternative Network

Visual analysis indicates that the greedy behaviour fails due to the Sioux Falls network

topology; traffic converges along two channels, and greedy path finding will never navi-

30

Figure 6.7: Greedy agents finding sub-optimal routes

Figure 6.8: An artificial grid network

gate an agent across the gap into the opposing channel. It is hypothesised that a more

highly inter-connected network will provide a greater number of pseudo-optimal alterna-

tive routes than the less well connected Sioux Falls network, and this will translate to a

faster clearance time.

To test this hypothesis, the Sioux Falls experiment simulation parameters will be

replicated on a new network topology - a city-like artificial uniform grid network. A

regular square of side length 10 junctions is formed with orthogonally adjacent junctions

connected by roads each of length 100 units (Figure 6.8). One random external node is

the designated evacuation node, seen in green, and all interior nodes are source nodes, in

red. Non-exit exterior nodes are not special. As the size of the network is smaller than

the Sioux Falls network, the population size is decreased to 1000, all other variables are

kept consistent with the Sioux Falls experiment.

Results from the grid network experiment portray a clear trend. At a greed threshold of

31

Figure 6.9: Clearance time as a function of agent greed threshold on the artificial gridnetwork

0.5, the evacuation simulation reports a 37.9% decrease in clearance time when compared

to the average no-greed base case. This increased performance holds for threshold values

of 0.4 through to 0.8, outside of which range the clearance time sharply rises as the

evacuation loses efficiency.

6.2.4 Evaluation

Findings of both the Sioux Falls and grid experiments agree that extreme values of agent

greed are detrimental to clearance time when compared to moderate greedy thresholds.

The greedy agent model requires agents have a maximum greedy changes parameter,

which is the maximum number of greed-motivated diversions that an agent will make, after

which an agent will always follow their planned routes; this assumption was implemented

into the model to temper the back-and-forth route switching as was evident in the Sioux

Falls experiment (Figure 6.7). Agents with a low greedy threshold will exhaust their

greedy-route-change allowance very early in the simulation, and hence as traffic begins

converging and forming congested choke points, the agents will not make any greedy

diversions, however this is the time where diversions are most imperative and effective.

An explanation for why high thresholds are ineffective is far more trivial; 100% congestion

on a road is not a frequent event throughout the duration of a simulation. As an agent’s

greed threshold increases towards 1, the extent to which the agent will make greedy

diversions minimises. If agents are not making many greedy routing choices then we

32

naturally can expect to see this lack of greedy behaviour reflected in the clearance time

trending towards the base case.

The artificial grid simulation results confirm the hypothesis that performance of the

Zhang et al. model of agent greed performs best on well connected networks, and is highly

dependent on network topology. In the highly connected grid network, greedy routing

allows agents to find the alternative paths and is hence less predisposed to re-route all

agents back into a single sequence of roads.

It is clear from the findings that the greedy agent model is flawed in two primary

ways - the rigidity of agents having a maximum number of route changes stifles greedy

phenomena as simulation runtime increases, and the propensity for the greedy algorithm

to repeatedly route an agent onto the same road fails to capture the intended behaviour

of a greedy route-changing individual.

33

Chapter 7

Conclusion

Here, a conclusion is given in three parts; first a summary of the project is given, then in

section 7.2 the author delivers a succinct appraisal of the entire process. Lastly, specula-

tion is given towards research which can extend the work done by this project.

7.1 Summary

A program was designed for simulating vehicle-based evacuations at a local and regional

scale. The system is configurable with a proprietary XML format, which provides the

researcher with a flexible and powerful tool for experimentation and manipulation of the

software - in addition, the software is able to operate on any arbitrary networks as per

the goals of the research.

The software is able to visualise emergent behaviour which has provided insight into

explaining experimental results.

Experimentation via simulation confirmed that the throttling strategy can improve

road network evacuation times, and provided insight into the relationship between block-

ing and unblocking thresholds and the evacuation behaviour of a network.

It was found that the effect of greedy agents is dependent on network topology, and

favours highly inter-connected networks. Agents were found to perform optimally with

a moderate threshold for greedy behaviour, and a greedy population can perform up to

38% more efficiently than a non-greedy population.

7.2 Evaluation

This project has achieved the goals it set out to accomplish within the evacuation simu-

lation space. The system is able to effectively model emergent details, and is capable of

evaluating programmable scenarios.

The system design is clean, and means that adding a new scenario or feature in the

simulation is a simple case of writing an appropriate method in Overseer or Car which

34

adjusts for the scenario. Unfortunately this functionality had not been planned from the

inception of the project, and if it were then the system design could fully accommodate

for it. It would be possible to implement some minor abstraction of functionality into

Overseer and Car superclasses, where each different subclass of Car or Overseer could

implement a different behaviour, thus maintaining full compatibility with the remaining

codebase.

In the experimental section, it is regrettable to have not gained much insight into the

discrepancy between this system’s results and the findings by Madireddy, Medeiros, and

Kumara (2011) - but it would be infeasible to reconcile the two sets of results without

viewing their system directly. As it stands, the experiments put forward in this report

behaved visually as expected, and the results are intuitive with a grounded analysis which

justifies their outcome.

A major setback in the project was in underestimating the required scope of the pro-

gram which would meet the chosen specifications. While the project is greatly strength-

ened by its flexibility and scalability towards a vast problem space, the amount of time

required to implement such a vast and powerful system detracted from the experimental

depth of the project - leaving the author with a simulation capable of evaluating multiple

avenues for further research which could not be completed in the project’s time frame.

7.3 Further Research

This project produced a simulation capable of investigating many topics further. Throt-

tling as proposed by Madireddy et al. is a dumb algorithm. It throttles any roads

that meet a simple criteria, or it requires the researcher to manually select which routes

are allowed to be throttled. An intelligent throttling algorithm would optimise throt-

tling thresholds on a per-road basis, an elementary example would be an implementation

of throttling which never blocks roads which are cut-edges, i.e - crucial edges which, if

blocked, disconnect a subgraph from the remainder of the network.

Analysis in Chapter 6 unveiled the flaws in the standard greedy agent model. A logical

next step would be to address the problems of repeatedly diverting back-and-forth along

a road, and of agent behaviour drastically changing once an agent reaches its max greedy

changes allowance. For example - agents could store a recent memory of congested roads

and avoid them when path finding in the future. To address the latter problem, research

could investigate having an agent’s allowance for greedy route changes be determined as

a function of the recency of previous greedy decisions, thus giving agents more motivation

to choose a greedy route if they have not done so in a given time period.

35

Bibliography

[1] Sandia National Laboratories. Identification and Analysis of Factors AffectingEmergency Evacuations. Tech. rep. 2005.

[2] Pamela Murray-Tuite and Brian Wolshon. “Evacuation transportation modeling:An overview of research, development, and practice”. In: Transportation ResearchPart C: Emerging Technologies 27 (Feb. 2013), pp. 25–45.

[3] Michael Pitt. The Pitt review: lessons learned from the 2007 floods. Tech. rep. 2008.

[4] Kirstin Dow and Susan L Cutter. “Emerging Hurricane Evacuation Issues: Hurri-cane Floyd and South Carolina”. In: (2002).

[5] Peter A. Thompson and Eric W. Marchant. “A computer model for the evacuationof large building populations”. In: Fire Safety Journal 24.2 (Jan. 1995), pp. 131–148.

[6] Kai Nagel and Michael Schreckenberg. “A cellular automaton model for freewaytraffic”. In: Journal de Physique I 2.12 (1992).

[7] Eric Bonabeau. “Agent-based modeling: methods and techniques for simulating hu-man systems.” In: Proceedings of the National Academy of Sciences of the UnitedStates of America 99 Suppl 3.suppl 3 (May 2002), pp. 7280–7.

[8] Dusan Teodorovic. “Transport modeling by multi-agent systems: a swarm intelli-gence approach”. In: Transportation Planning and Technology 26.4 (Aug. 2003),pp. 289–312.

[9] C.M. Macal and M.J. North. “Tutorial on agent-based modeling and simulation”.In: Proceedings of the Winter Simulation Conference, 2005. IEEE, 2005, pp. 2–15.

[10] Bo Zhang et al. Agent-based modeling for household level hurricane evacuation. 2009.

[11] Chuanjun Ren, Chenghui Yang, and Shiyao Jin. Agent-Based Modeling and Simu-lation on Emergency Evacuation. Tech. rep. 2009, pp. 1451–1461.

[12] Richard J Dawson, Roger Peppe, and Miao Wang. “An agent-based model for risk-based flood incident management”. In: (2011).

[13] Charles M. Macal and Michael J. North. “Tutorial on agent-based modeling andsimulation part 2: How to model with agents”. In: Proceedings - Winter SimulationConference. 2006.

[14] Fred Choa, Ronald T Milam, and David Stanek. “CORSIM, PARAMICS, and VIS-SIM: What the Manuals Never Told You”. In: (Mar. 2004).

[15] Manini Madireddy, D. J. Medeiros, and Soundar Kumara. An agent based model forevacuation traffic management. 2011.

36

[16] Xuwei Chen, John W. Meaker, and F. Benjamin Zhan. “Agent-Based Modeling andAnalysis of Hurricane Evacuation Procedures for the Florida Keys”. In: NaturalHazards 38.3 (July 2006), pp. 321–338.

[17] X Chen and F B Zhan. “Agent-based modelling and simulation of urban evacuation:relative effectiveness of simultaneous and staged evacuation strategies”. In: Journalof the Operational Research Society 59.1 (Jan. 2008), pp. 25–33.

[18] Kai Nagel et al. Two-lane traffic rules for cellular automata: A systematic approach.Tech. rep. 1998.

[19] H T Fritzsche. “A Model for Traffic Simulation”. In: Traffic Engineering & Control35.5 (1994).

[20] Matthew Durak et al. “Optimizing an agent-based traffic evacuation model usinggenetic algorithms”. In: 2015 Winter Simulation Conference (WSC). IEEE, Dec.2015, pp. 288–299.

[21] Ameya Shendarkar et al. “Crowd Simulation for Emergency Response using BDIAgent Based on Virtual Reality”. In: Proceedings of the 2006 Winter SimulationConference. IEEE, Dec. 2006, pp. 545–553.

[22] D R Bish et al. “Optimal evacuation planning using staging and routing”. In: Jour-nal of the Operational Research Society 65.1 (2014), pp. 124–140.

[23] Thomas J. Cova and Justin P. Johnson. “A network flow model for lane-basedevacuation routing”. In: Transportation Research Part A: Policy and Practice 37.7(Aug. 2003), pp. 579–604.

[24] Sangho Kim, S. Shekhar, and M. Min. “Contraflow Transportation Network Recon-figuration for Evacuation Route Planning”. In: IEEE Transactions on Knowledgeand Data Engineering 20.8 (Aug. 2008), pp. 1115–1129.

[25] Brian Wolshon. ““One-Way-Out”: Contraflow Freeway Operation for HurricaneEvacuation”. In: Natural Hazards Review 2.3 (Aug. 2001), pp. 105–112.

[26] Peter Hart, Nils Nilsson, and Bertram Raphael. “A Formal Basis for the HeuristicDetermination of Minimum Cost Paths”. In: IEEE Transactions on Systems Scienceand Cybernetics 4.2 (1968), pp. 100–107.

[27] Makoto Matsumoto and Takuji Nishimura. “Mersenne twister: a 623-dimensionallyequidistributed uniform pseudo-random number generator”. In: ACM Transactionson Modeling and Computer Simulation 8.1 (Jan. 1998), pp. 3–30.

[28] Tim Tyler. Sun redefines randomness. url: http://www.alife.co.uk/nonrandom/(visited on 04/24/2019).

37

Appendix A

Structure of Project Directory

The contents of the project directory are as follows:

• EvacVisual.jar - The method of running the visualisation of a simulation

• ExperimentSequence.jar - The way to run simulations in the background with datarecording

• config/ - All simulation configuration (.xml) files, and network (.net) files. Theauthor has created a range of example simulation configuration files for readers totry out, and use as references when making your own .xml config files

• config/experiments by author/ - The (mostly failed) experiments previously ran

• config/networks/ - A series of .net files which can be loaded by the software

• lib/ - All project dependencies, used to compile the project

• results/ - All results taken from experiments found under config/experiments by author

• src/ - All source code

• target/ - All compiled class files

• README.txt - Contains the information on this page, plus more

• gitlab address.txt - Contains the URL for this project’s GitLab repository

———————————————————————————–

A.1 Running the Programs

This project is ran from the command line.1) From the terminal, navigate to the root project directory (which contains EvacVi-

sual.jar and ExperimentSequence.jar)2.a) For visualisation, execute the command:

java -jar EvacVisual.jar <PATH TO CONFIGURATION FILE>

38

By default, the path to configuration file begins at the root project directory. I.e - thefollowing is a valid command you can execute, and is a good introduction to the system:

java -jar EvacVisual.jar config/example1.xml

Note that EvacVisual will not iterate through a series of independent variable values.If you visualise a config file which has independent variables it will only visualise the firstconfiguration (where the independent variables are at their minimums)

2.b) For experiments:

java -jar ExperimentSequence.jar -o <Output Location> -i <Input config xml file(s)>

Here, the output results .txt files will be placed in the folder specified by <OutputLocation>

<Input config xml file(s)>can take the following forms:A regular path to a configuration file:

config/example1.xml

A list of paths to config files, simply space-separated:

config/example1.xml config/example2.xml

A directory which contains config files:

config/exampleBatch/

The following is a valid command:

java -jar ExperimentSequence.jar -o output/ -i config/exampleBatch/

A.2 Compiling the programs

It is highly recommended to use a Java compatible IDE for compilation rather thancompile in the command line.

1) Load the project directory into an IDE of your choice2) Set up the IDE project to include all the contents of lib/ as dependencies3) Build the project normally

39

Appendix B

List of Configurable Parameters

The following parameters can be configured in a simulation configuration XML file. Thevar column gives the attribute string to use in a <variable var="..."> tag. Parametersof type int, double, and boolean can be set as independent variables, and a range givento experiment over. If a configuration file does not specify a parameter, it takes thedefault value listed here.

Parameter var Description Type Default Value

Greed Enabled greedEnabled Flag to enable agent greed boolean false

ThrottlingEnabled

throttlingEnabled Flag to enable throttling boolean false

Population Size populationSize Number of cars to evacuate int 1000

Time Factor timeFactor Temporal resolution of simulation(time units / step)

double 1

Population GreedProportion

greedProportion Proportion of the population to begreedy agents [0,1]

double 1

Upper Threshold(UT)

upperThreshold Congestion threshold required tothrottle a road [0,1]

double 0.5

Lower Threshold(LT)

lowerThreshold Congestion threshold required to re-open a throttled road [0,1]

double 0.5

Agent Acceleration agentAcceleration Acceleration of cars double 1

Speed Limit agentSpeedLimit Maximum speed of a car double 20

Vehicle Buffer agentBuffer The buffer left between two cars’ co-ordinate points. In effect the VehicleBuffer is a representation of car size

double 4

Agent PerceptionRadius

agentPerceptionRadius The distance around the car which itcan sense and react to

double 40

Agent GreedThreshold

agentGreedThreshold Congestion threshold of a road re-quired for a greedy agent to divertfrom its route [0,1]

double 0

Agent GreedChance

agentGreedChance Probability for a greedy agent tomake a greedy route diversion [0,1]

double 1

Max GreedyLength Factor

agentGreedMaxLengthFactor An agent will not divert if its newgreedy route exceeds the product ofthe agent’s current route length andthe max greedy length factor

double 2

40

Max GreedyChanges

agentGreedMaxChanges The maximum number of greedyroute changes an agent will make af-ter which the agent will stop act-ing greedily, to avoid excessive greedyrouting

int 10

In addition to the above simulation parameters, a configuration XML file may containspecial tags for the following experiment meta-parameters (See Appendix C).

Parameter Tag Description Default Value

Name <name> Name of the simulation, for ease of use and fornaming output files

Extracted from the XML filename

Network <network> Network topology to simulate false

Timeout Limit <timeout> Number of steps to execute before prematurelystopping the simulation

20000

Repeat Count <repeats> Number of times to repeat the simulation at everyconfiguration of the supplied independent variables

1

41

Appendix C

Configuration File Format

Contents of a configuration XML file are first wrapped by a root <experiment> tag:

<experiment>

.

.

.

</experiment>

Simulation parameters are configured using the following XML tag:

<variable var="PARAMETERNAME">VALUE</variable>

Figure C.1: Control variable XML format

Where PARAMETER NAME is the parameter name as stated in Appendix B, and VALUE is thevalue to assign to the parameter. To configure a parameter to be an independent vari-able, include the "varType="independent" and type="DATA TYPE" attributes in the tag,and include the following nested tags: <min>MIN VALUE</min>, <max>MAX VALUE</max>,and <interval>INTERVAL VALUE</interval> where DATA TYPE is the data type of theindependent variable (int, double and boolean supported), MIN VALUE, MAX VALUE, andINTERVAL VALUE are are the starting value over which to iterate the parameter, the max-imum value, and the interval over which to step the parameter. An independent variabletag takes the following form:

<variable var="populationSize" varType="independent" type="int">

<min> 1000 </min>

<max> 4000 </max>

<interval> 1000 </interval>

</variable>

Figure C.2: Independent variable XML format

In addition to the <varible> tag which defines simulation-specific parameters, there areadditional tags which define how the experiment is to run:

• <repeats>n</repeats> - Repeats each simulation (at each independent variablepermutation) n times.

42

• <timeout>n</timeout> - Kills a simulation run if the number of steps exceedsn.

• <name>$name</timeout> - Names the experiment $name for quick comprehen-sion. Output data files are given the name “$name.txt”. If no name is specified,output data files are given the same name as the XML’s filename.

• <network>...</network> - Provides a network file or specifies a proceduralnetwork to build..

The <network> tag takes two forms, read in a network from a .net file, and generate gridfrom parameters, the read-from-file tag is the simplest of the two:

<network type="path">

<filepath>\$path</filepath>

</network>

Figure C.3: Network from file XML format

Here, the $path can be specified as an absolute path or relative to where Java is executingthe program. Most likely Java is executing the program from the project root directory,in which case the following example path is valid:“config/networks/SiouxFalls allSources.net”.

To configure a procedural grid, the <network> tag takes the following form:

<network type="grid">

<size>n</size>

<roadLength>l</roadlength>

</network>

Figure C.4: Procedurally generated grid XML format

Which constructs a network of n× n Junctions, where each connecting road segment haslength l.

For examples of configuration files, see the config folder in the project root directory.

43