agent-based modelling of tra c evacuation strategies · urable range of scenarios. agents utilise a...
TRANSCRIPT
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