Citation

## Material Information

Title:
Dynamic scheduling of dererministic routes for objects moving in three dimensional space
Creator:
Godwin, Bret Allen
Place of Publication:
Denver, CO
Publisher:
Publication Date:
Language:
English
Physical Description:
x, 207 leaves : illustrations ; 29 cm

## Subjects

Subjects / Keywords:
Scheduling ( lcsh )
Route choice ( lcsh )
Computer algorithms ( lcsh )
Computer algorithms ( fast )
Route choice ( fast )
Scheduling ( fast )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

## Notes

Bibliography:
Includes bibliographical references (leaves 206-207).
Thesis:
Submitted in partial fulfillment of the requirements for the degree, Master of Science, Computer Science
General Note:
Department of Computer Science and Engineering
Statement of Responsibility:
by Bret Allen Godwin.

## Record Information

Source Institution:
Holding Location:
|Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
39719091 ( OCLC )
ocm39719091
Classification:
LD1190.E52 1997m .G64 ( lcc )

Full Text
DYNAMIC SCHEDULING OF DETERMINISTIC ROUTES FOR OBJECTS
MOVING IN THREE DIMENSIONAL SPACE
by
Bret Allen Godwin
B.S., University of Colorado at Denver, 1987
A thesis submitted to the
in partial fulfillment
of the requirements for the degree of
Master of Science
Computer Science

This thesis for the Master of Science
degree by
Bret A. Godwin
has been approved
by
Date

Godwin, Bret A. (MS, Computer Science, Engineering)
Dynamic Scheduling of Deterministic Routes for Objects Moving in Three
Dimensional Space
Thesis directed by Associate Professor William J. Wolfe
ABSTRACT
The purpose of this research is to evaluate whether deterministic dynamically
scheduled fixed routes in three dimensional space will support high traffic volumes
while providing adequate throughput to minimize delays and improve travel times in
congested areas. To accomplish this task, the author presents a scheduling algorithm
that will be used by an automated route scheduling and vehicle management system.
The algorithm includes a time dependent windowing scheme that optimizes
route management while reducing queuing delays. A software simulator is developed
to simulate vehicle traffic traveling in three-dimensional space. The results of
simulation scenarios indicate that the premise of deterministic routing for three-
dimensional traffic is possible with average queuing delays of less than 30 minutes.
This abstract accurately represents the content of the candidate's thesis. I
recommend its publication.
in

DEDICATION
For Diane, Jeffrey, and Mark. Thanks for being so patient and for all of the support. I
know it was a long arduous process, but in the end it was worth it. I also want to
thank Mom and Dad for all of their continued support throughout my years of
education. I love you all.

CONTENTS
CHAPTER 1 INTRODUCTION..................................................1
Problem Description...................................................5
Problem Formulation...................................................7
Strategy..............................................................8
Notation..............................................................9
Thesis Organization..................................................10
CHAPTER 2 A DETERMINISTIC APPROACH.....................................11
Concept..............................................................11
CHAPTER 3 THEORETICAL ANALYSIS.........................................15
Network Technology Similarities......................................15
Local Area Network Access Characteristics..........................15
Network Routing and Switching Queuing Analysis.....................18
Erlang Blocking Probability..........................................19
Queueing Theory......................................................21
CHAPTER 4 SOLUTION ANALYSIS............................................26
Non-windowed Routing.................................................26
The Scheduled Chronoscube............................................28
Non-Windowed Routing example:........................................31
Scheduled Chronoscube Routing example:...............................32
Pre-Scheduling.......................................................34
Automated Architecture...............................................35
v

Vehicle Requirements..................................................35
Control Requirements..................................................35
Three Dimensional Space.................................................38
Routes..................................................................39
CHAPTER 5 SIMULATION ARCHITECTURE..........................................40
Simulation Engine Object................................................40
RouteMasterComputer Object..............................................41
.Vehicle Object.........................................................43
Grid Object.............................................................47
Graphical User Interface Object.........................................48
Vehicle Movement Formulas...............................................49
Simulation Hardware.....................................................50
Simulator Constraints...................................................50
CHAPTER 6 SIMULATION RESULTS...............................................51
Simulation Scenarios....................................................53
High Volume Simulation Configuration....................................53
High Volume Simulation Results..........................................54
Heavy Congestion Simulation Configuration...............................56
Heavy Congestion Simulation Results.....................................57
Heavy Congestion with Small Time Window Simulation Configuration........59
Heavy Congestion with Small Time Window Simulation Results..............60
Medium Congestion Simulation Configuration..............................61
Medium Congestion Simulation Results....................................62
Light Traffic Simulation Configuration..................................63
Light Traffic Simulation Results........................................64
Pre-Schedule Simulation Configuration...................................66
vi

Pre-scheduling Simulation Results.........................67
Optimization Analysis.....................................69
CHAPTER 7 CONCLUSION........................................71
APPENDIX A SIMULATOR OPERATION GUIDE........................75
APPENDIX B CODE LISTINGS....................................82
APPENDIX C SIMULATION 3D GRAPHICAL OUTPUT..................201
REFERENCES.................................................205
vii

TABLES
Table
Table 3-1: Erlang blocking probabilities for arrival rate of
28 vehicles/sec and average holding time of 476
seconds....................................................................20
Table 3-2: Calculated Queuing Delay parameters.................................24
Table 6-1: Simulation Parameters for High Volume
Configuration..............................................................54
Table 6-2: High Volume Simulation Results......................................56
Table 6-3: Simulation Parameters for Heavy Congestion
Configuration..............................................................57
Table 6-4: Heavy Congestion Simulation Results..................................58
Table 6-5: Simulation Parameters for High Congestion with
Short Time Window Configuration............................................59
Table 6-6: Simulation Parameters for Medium Congestion..........................61
Table 6-7: Medium Congestion Results............................................63
Table 6-8: Simulation Parameters for Light Traffic..............................63
Table 6-9: Calculated vs. Simulated Queuing Values for
Light Traffic..............................................................64
Table 6-10 :Output Results for Light Load Simulation............................66
Table 6-11: Simulation Parameters for Pre-scheduling............................67
Table 6-12: Pre-Schedule Congestion Results.....................................67
viii

FIGURES
Figure
Figure 1-1: A pictoral view of the deterirninistic solution for
3D vehicle travel................................................................4
Figure 2-1: Dynamic routing diagram illustrating the routes
on each level of the 3D Grid....................................................13
Figure 3-1: Ethernet vs. Token Ring LAN delay
Figure 3-2: Queuing Theory Notation..................................................22
Figure 3-3: Basic Queuing Theory Equations for M/M/l
queues..........................................................................23
Figure 4-1: Illustration of a chronoscube............................................30
Figure 4-2: Initial Routing Approach example illustration............................31
Figure 4-3: Improved Routing Approach Example
Illustration....................................................................33
Figure 4-4: The architecture of the centralized computer
system..........................................................................37
Figure 4-5: Functional subdivision of the three dimensional
space by altitude...............................................................38
Figure 4-6: Vehicle Route Ilustration using Chronoscubes.............................39
Figure 5-1: Simulation Architecture illustrating the object
layout and object connections...................................................42
Figure 5-2: Flowchart illustrating the level determination
phase of the route allocation process...........................................44
Figure 5-3: Flowchart illustrating the route selection
IX

algorithm that assigns chronoscubes to routes...............................45
Figure 5-4: Flow charts illustrating the main simulation and
vehicle movement algorithms.................................................46
Figure 5-5: Illustration of the chronoscube sparse matrix
with the cell contents for a chronoscube.....................................48
Figure 6-1: Simulator Main Window depicting the Denver
Metropolitan area............................................................52
Figure 6-2: Queuing Graph for the High Volume
Configuration................................................................55
conditions...................................................................58
Figure 6-4: Queueing and Wait Times for Heavy
Congestion with Small Window Size..........................................60
Figure 6-5: Heavy Congestion Simulation with Short Time
Window Results...............................................................61
Figure 6-6: Graph Illustrating the Queuing Delay for the
model under medium congestion................................................62
Figure 6-7: Chart Illustrating Queuing and Wait Times for
Light Congestion.............................................................65
Figure 6-8: Chart Illustrating Queuing and Wait Times for
Pre-Scheduling...............................................................68
Figure 6-9 : Comparison of Simulation Configuration
Results......................................................................69
x

CHAPTER 1
INTRODUCTION
As traffic congestion continues to grow at an alarming pace in the late 20th
century, many transportation forecasts predict that by the early 21st century road
congestion will be so severe that travel will be very time consuming in most major
urban areas1.
To counteract these claims of impending gridlock, many scientists and
aeronautical engineers have started to evaluate alternatives to our present two-
dimensional method of travel. Many are pursuing new designs for transportation
technologies of the future. Some of these new alternatives take advantage of three-
dimensional space where terrain features and buildings no longer inhibit travel and
create congestion points.
A few forward thinking individuals are presently evaluating technologies that
are considered by many as too futuristic to be attainable in the near future. However,
some scientists and engineers believe that we are very close to having flying vehicles
that will enable three-dimensional travel. The primary difficulties today are technology
limitations that prohibit safe and economical vehicular flight. The following excerpt
from an interview with Steven Crow2, portrays the difficulties with flying vehicles
today:
"The reason most of us pilot vehicles that only leave the asphalt when jumping
potholes, is that small planes whether or not they convert into cars are too
1 Vehicle use and population density has increased by 50% and 15% respectively, from 1975 to
1990[5],
2 Steven Crow is an aeronautical engineer at the University of Arizona who is currently designing
future flying vehicles with students at the University[7].
1

expensive and too hard to fly. Plan on \$150,000 for your bare bones cramped
four-passenger plane. Add \$3,500 and 60 hours' worth of white-knuckled
tutoring to get your pilot's license. And don't forget to factor in thousands of
dollars worth of annual mechanical maintenance and other costs, and countless
hours to plot flight paths. Throw in a third dimension, aerodynamics,
rotations, gyroscopic phenomena and you've got a situation the human mind
just doesn't deal well with."
So, with this in mind, new technologies will be needed that overcome these obstacles
before mass transportation in three-dimensional space is a pragmatic endeavor.
As transportation has evolved, technology has enabled us to increase speeds
and safety in addition to comfort, and styleJ. These benefits have created more
demand for individual transportation and freedom of movement. This need for
independence has created an abundance of single driver vehicles for a two-dimensional
road network that is already unable to support peak utilization. As population
densities increase, there will be no choice but to eventually change to another form of
transportation. The two alternatives are: increased utilization of mass transit, or to
pursue three-dimensional travel.
One of the constraints associated with transportation today is the fact that most
transportation occurs in a 2-dimenstionaI domain. Although we have airplanes,
helicopters, and other air transportation technologies for 3-dimensional travel, these
vehicles are usually limited in use due to economic and technical constraints.
Airplanes today usually only transport people and freight to other locations across
long distances; while helicopters are only used in rare situations for short distances.
Neither of these technologies provides safe and cost effective travel for the masses.
In order to reap the benefits associated with 3-dimensional travel, new
vehicular technologies will need to be developed to provide all modes of
transportation from single person vehicles to large sized transports. Once these flying
J Scientific American, September 1997

vehicles are developed new rules and regulations will need to be created to support the
new "sky-ways" of the future.
Presently, air traffic control centers manage the sky-ways primarily for
commercial aircraft, but they only manage several hundred vehicles at a time. When
three-dimensional transportation for the masses becomes generally available,
sophisticated automated systems will be required to insure that travel is safe and
effective. These new automated systems will need to be fast, efficient, and require
significant system redundancy to manage the high volumes of traffic.
Three-dimensional travel will enable travel directly to a destination point
without having to steer around obstacles.. In an unrestricted space, vehicles will be
able to travel directly to their destination without having to travel along predefined
corridors (todays roads). This will enable an individual to travel from home directly
to the store or office without having to stop at stoplights or wait in traffic jams.
Vehicles will no longer be bound by the constraints imposed by two-dimensional
terrain. Transit speeds will likely increase by as much as 2 4 times over present day
ground transportation4. These direct routes and increased speeds should reduce traffic
congestion by reducing the amount of time a vehicle is in transit from origin to
destination.
Three-dimensional travel will create many new challenges. Millions of vehicles
moving unrestricted in an open space will increase the probability for collisions,
congestion, and visual pollution in proportion to the number of vehicles and the
amount of open space available. Therefore, traffic management in a 3-dimensional
world will be more critical than it is in our present 2-dimensional environment.
4 Helicopters and small planes presently travel at speeds 2-4 times faster than automobiles[7].
3

This thesis focuses on one possible solution to an automated traffic
management system. Figure 1-1 illustrates the basic premise that will be described.
Figure 1-1: A pictoral view of the deteriministic solution for 3D vehicle travel
4

and analyzed in the following chapters. The illustration portrays a vehicle requesting a
route and the activity that takes place during movement once a route is defined.
Problem Description
To address three-dimensional travel, new automated control systems and
algorithms will need to be developed to manage flying vehicles in congested areas.
These new traffic management systems may resemble present day air traffic control
systems or more sophisticated automated systems. The algorithms may be simple
routing based mechanisms that route traffic down 3-dimensional corridors, or more
sophisticated scheduling systems that guarantee routing based on destination,
congestion level, priority, and expected travel time.
Since there are many aspects to 3-dimensional travel, the focus is constrained
to the following issues:
Given a condensed 3-dimensional airspace, what type of algorithm would
enable 3-dimensional travel without collisions, reduce visual air pollution
(vehicles hovering in the air), provide travel flexibility, reduce time to
destination, and minimize congestion?
If altitude height is constrained, how does this impact travel times and
queuing delay?
How does traffic volume affect delay?
What is the most efficient method of travel from origin to destination?
5

Is it feasible to schedule vehicle traffic to a pre-determined path before the
vehicle leaves the ground and have that vehicle travel that path?
How can the number of vehicles in the air be minimized?
Using the above questions as guidelines, the following requirements further refine the
problem domain:
1. The problem domain is restricted to high-density metropolitan areas.
2. Air space is segmented into a three dimensional grid with vertical levels
starting above a minimum height that is restricted to local traffic.
3. Vehicle density is high during travel periods associated with this study.
4. Vehicles may not make mid-air changes in direction
5. Vehicles may travel in any direction horizontally and vertically.
6. Vehicles may travel up to 200 Miles Per Hour (MPH) horizontally, and 60
MPH vertically.
7. Vehicles have a constant acceleration of 88 feet/sec2.
8. Vehicles have a constant deceleration of 60 feet/sec2.
9. Vehicles contain a global positioning system and transponder that identifies
where they are at all times.
10. Vehicles may not cross paths if the projected vehicle movement will place
the vehicles in within 100 ft of each other within a 5-second interval.
11. Vehicles must wait for a route to be defined before they may move.
12. Vehicle routes are confined to a single level of altitude for horizontal
travel.
13. When a vehicle requests a route, queuing time must be minimized
14. Vehicles traveling shorter distances should travel at lower altitudes to
minimize travel time.
6

15. Congestion must be minimized so that large numbers of vehicles are not
grouped together during transit.
Problem Formulation
There are many potential solutions that will address the problem of managing
vehicular travel in three dimensions. Steve Crow from the University of Arizona has
the following perspective:
"Complete self piloting would be possible only if the national air traffic control
system switched from the current centralized, ground based approach to a
distributed one in which planes broadcast their locations to other planes, and
onboard computers figured out how to keep them away from each other."
Self piloting will only work in low congestion areas. The Federal Aviation
Administration (FAA) has adopted this approach in their new Free Flight rules
for aircraft separation. Unfortunately, this approach breaks down in highly
congested traffic areas because the number of real-time variables increases
exponentially with the number of vehicles and the air space density. The FAA
has also acknowledged this in their Free Flight rules which indicate that air
traffic controllers will direct traffic in high congestion areas[8].
To better understand the rationale of this approach, the following items should
be considered:
In three-dimensional space no physical barriers exist to restrict movement
in any direction, both horizontally and vertically.
Congestion will occur in areas where high concentrations of vehicles
originate or terminate.
In congested areas, if vehicles are moving at random, vehicles will be
required to wait (hover) until other vehicles move out of the way.
7

Congestion will increase the number of vehicles in the air which may lead
to complaints related to having too many floating vehicles in the air which
block peoples view. This phenomena could be referred to as "vehicle
clouds".
A significant amount of energy may be utilized by a vehicle waiting in 3D
space for a path to it's destination.
The above concerns, require a more rigid system that to manage congested
environments. To reduce congestion, deterministic methods must be used to manage
traffic. To accomplish a deterministic method for three-dimensional travel, one might
create a centralized manager that dictates how and when vehicles will move. This
central controller will assign predefined paths based upon the vehicles destination
coordinates at a prescribed instant in time. Another approach might be to create a
highly distributed system that manages sectors within a grid.
Strategy
In order answer the questions posed in the prior section, existing transportation
methodologies that had similar characteristics were evaluated. The primary systems in
use today are the two dimensional road system and the highly successful 3-dimensional
air traffic control system.
Since the existing road system gains much of it's inherent queuing and
inefficiencies from geographic boundary constraints and the random nature of
automobile traffic, this model was not adequate in many respects.
The air traffic control system on the other hand seemed to be much more
similar due to the automated systems already used today. The difficulty with the
existing air traffic control methodology is that it uses congestion corridors and in flight
queueing. This approach creates visual pollution (from the airplanes waiting and
8

circling) and is inherently inefficient. The other main difference with today's air traffic
control system is that it manages traffic that has characteristically long travel times and
due to the long travel distances can have random arrival times.
Other areas having similar queuing characteristics are telephone and data
networks that have similar route allocation and queuing issues. Telephone networking
equations for network trunking were analyzed along with algorithms for router based
networks. After reviewing numerous materials, it became obvious that existing
solutions were not adequate to describe a mathematical approach.
With this in mind, the next step was to develop a simulation of the proposed
algorithm to determine if the initial hypothesis could be supported. Since vehicles that
meet the requirements of the problem domain do not exist in 1997, a simulation of the
solution paradigm is required. A computer model was developed to provide this
simulation. The results were evaluated and compared against initial assumptions for
validation.
Notation
Conventions used throughout this document are as follows:
Vectors:
Matrices:
Scalars:
Bold lower case letters denote a vector (eg., x or y). A
subscript associated with a vector letter, in plain type,
represents an element of that vector (e.g., a/ is the ith element of
a).
Bold, uppercase letters represent matrices (e.g., G or P). A
pair of subscripts on a matrix name, in plain type, identifies an
element of that matrix (e.g., My is the element in the f' row, jth
column of M.
Upper and lowercase letters, in plain type, denote a scalar.
9

Variables: Upper and lowercase letters, in italic type, denote a constant.
Thesis Organization
The organization of this thesis is as follows. Chapter 2 defines a deterministic
approach for solving congestion of moving vehicles in three-dimesnional space.
Chapter 3 examines similarities to other technologies and some blocking and queuing
theory to assist with the definition of the model. Chapter 4 describes the routing
algorithm and describes how the central controller assigns and manages routes..
Chapter 5 then proceeds with a discussion of the simulation architecture and Chapter 6
presents the simulation results. Finally, Chapter 7 summarizes the thesis and identifies
additional research topics and other fields of study that may benefit from this solution.
10

CHAPTER 2
A DETERMINISTIC APPROACH
Many researchers believe that finding a deterministic approach to solving a
problem is the best way to manage the problem repeatedly with similar results3. This
methodology is not always the most efficient or the most cost effective, but it does
provide predictable results.
Predictability is the key to managing congestion. Managing traffic congestion
in a high-density area requires the development of an algorithm that is deterministic
and provides predictable behavior. Thus, using a fixed route algorithm that forces
vehicles to wait for a route (queuing) provides an effective deterministic model to
minimize traffic congestion in 3-dimensional space. Figure 2-1 provides an illustration
of how routes are allocated in space.
Concept
The problem domain defined by this thesis focuses on high traffic congestion in
relativley small geographic areas (50 square miles) with fixed flight paths and
predetermined arrival times. Congestion needs to be avoided and low delay is desired.
Any vehicle that wishes to move from an origin to a destination location in a 3-
dimensional grid must first request a route from an origin location to a destination.
Once the route has been defined, the vehicle may move unimpeded and at full speed
until the destination location has been reached.
The following isssues need to be considered when investigating route selection:
5 Warren Powell at Princeton University uses deterministic models extensively in Operations
Research for transportation optimization problems! 19],
11

A route may not intersect another route if two or more vehicles will
occupy the same space in time.
Routes should be direct to minimize travel time.
Shorter routes should be assigned to lower altitudes to reduce
travel time.
The number of vehicles in the air at any one time should be
minimized.
Routes assigned at higher levels will block route selection along the
vertical path as searches are made sequentially upward.
High density destinations will restrict the number of route
terminations for the vertical down path.
The amount of time a vehicle waits to have a route assigned should
be minimized.
12

Level n
Level n-1
Level 2
Level 1
Level 0
Figure 2-1: Dynamic routing diagram illustrating the routes on
each level of the 3D Grid.
Several additional issues should be considered:
What happens if a vehicle wants to change routes during flight? or,
How are routes allocated if a direct route is not available?
13

The solutions to these questions are not easy to solve because there are many
variables that need to be considered. For example, if a route is blocked, does the
vehicle wait, or does it try to find the shortest route around the obstacle. The problem
with finding the shortest route is that it might take longer to travel the shortest
available route than to sit and wait. This phenomena is experienced by many travelers
who leave freeways to detour around an accident, only to find that the detour takes
longer to traverse than staying in the original traffic jam.
The issue of course change during a movement has profound implications on
the master control computer and the algorithm that is used to implement the fixed
routing scheme. The difficulty in changing a vehicle's path during movement is that all
vehicles in transit who's route intersects with that particular vehicle must be considered
at the same time.
The reason for this is due to the nature of scheduled routes. If a route is
scheduled based on time, then a vehicle is expected to move through each grid
location during the scheduled time interval. All other vehicular traffic that is moving
across that vehicle's path are dependent on where it is at a specific instant in time.
Therefore, if a vehicle needs to change direction, then all related vehicles will
have to come to a stop and new routes will need to be generated for those vehicles
that are impacted. Depending on the number of vehicles that cross the path, this could
be a trivial or very complex endeavor. The real problem is when a cascading effect
takes place that effects all vehicles in the system.
The path change of one vehicle could cause significant blocking to occur for
vehicles in the air which will cause floating objects that will have to be given priority
during the scheduling process. The re-configuration effort of the system could
potentially create large delays in the system depending on the amount of congestion
14

CHAPTER 3
THEORETICAL ANALYSIS
Deterministic routing of objects in congested three-dimensional space is
somewhat unique at this point in time. There is no other known research that address
this material. Therefore, other areas of research that provide metaphorical solutions
were used as the basis for the theoretical research and foundation for the solution
derived.
Network Technology Similarities
Areas of research similar to this problem domain are voice and data
networking. The study of queuing and routing is prevalent in both areas. Both
telephony and data communications technologies encounter a different type of offered
traffic load and each uses a unique method to manage the traffic. After studying
solutions to traffic congestion in telephony and data networking, a hybrid system based
on both areas was used to deterministically route vehicles.
From telephony the concept of multiple channels was incorporated to improve
throughput by adding additional levels to increase the number of available routes[2].
Data communications provided the concept of time slots that are used by cell based
protocols such as Asynchronous Transport Mode (ATM) [15],
The theoretical aspects of these areas is used as the foundation for developing
the models for the assignment of the three-dimensional routes.
Local Area Network Access Characteristics
The approach used for managing deterministic routes has many similarities to
the study of access delay characteristics found in Local Area Networks and queuing
delays in network routers and packet switches. In networking, the physical medium
15

can be thought of as a shared medium for nodes to compete for access for data
the medium, or begin transmitting at any time.
Vehicles in the three-dimensional space problem face a similar situation. If we
map our present mode of two-dimensional transportation onto the three-dimensional
model, the vehicles would move immediately without concern for destination
congestion or route blocking. This non-deterministic method of travel is random in
nature and equivalent to the shared medium used with Ethernet network technology.
The benefits of random vehicle routing and LAN media access control
techniques are low access latency in an unloaded environment. This translates into a
fast response time from the users' perspective. Unfortunately, the opposite scenario
occurs in a loaded environment where very high access latency is encountered.
Two common network access control strategies in use today are Ethernet and
Token Ring. The Ethernet protocol assumes that the medium is available most of the
time and that statistically at any given time the probability that a collision will occur is
minimal. The access control mechanism used by Ethernet is called Carrier Sense
Multiple Access/Carrier Detection (CSMA/CD). This protocol dictates that a station
waits for an open channel and begins transmitting. If another node begins transmitting
at the same time the node is trying to send data, a collision occurs. In a collision
situation, both nodes stop transmitting and wait for a random period of time before
trying to send again[15].
In a lightly loaded network, this algorithm is very effective and most networks
in use today use this technology because it is inexpensive and highly effective.
the number of collisions on the medium begins to degrade performance. This
degradation in performance effectively increases the access time of nodes onto the
network[15].
16

The Token Ring (TR) protocol is a deterministic protocol that uses polling as a
means to mediate access control. The TR scheme identifies a controlling node that
manages all traffic on the network through the control of a token that is passed from
one network node to another. The token is a protocol identifier that allows a node to
request access to the physical medium to transmit data. The token traverses from one
node to another as it travels along the network. If the token is full, i.e. data is being
transmitted, then a station is required to wait until the token is released before it can
Token Ring is a highly deterministic protocol that utilizes bandwidth more
effectively than Ethernet under heavy loading. It is more efficient because collisions
are avoided and each network node shares the medium equally. The main advantage
to this scheme is the ability to manage the network congestion by controlling access to
the token. Prioritization schemes are employed to guarantee levels of service for high
priority media access control messages. If traffic congestion is too high, stations may
be requested to reduce their traffic, or wait until bandwidth is available.
An interesting phenomenon associated with both Ethernet and Token Ring
network protocols is access delay. This delay is the characteristic related to how long
a node has to wait to send data across the shared medium. Figure 3-1 illustrates the
access delay characteristics of Token Ring and Ethernet LANs.
This graph illustrates that a random approach to access is not as efficient as the
conditions, the non-deterministic algorithm is more efficient. This data was used as
the basis for using a deterministic algorithm for evaluating the three dimensional travel
problem with high vehicle densities.
17

Figure 3-1: Ethernet vs. Token Ring LAN delay characteristics relative to
Network Routing and Switching Queuing Analysis
In order to create fixed routes in space that do not overlap, some routes will
not be available when requested. Therefore, vehicles will be required to queue and
wait until a route is available. Queuing is an undesirable side effect of the proposed
deterministic routes, so the goal of the solution is to minimize it. One source of
queuing research is data networking routing and switching. These technologies
employ sophisticated algorithms to reduce packet and cell queuing.
Before examining a queuing model, the probability functions for availability are
needed, along with several definitions as follows:
C Is defined as the chronoscube; which is a 3-dimensional cubic area of
space that is reserved for a specified time interval t-e where e is a constant. A more precise definition is located in Chapter
4.
18

G Is a 3-dimensional matrix that contains vertices that represent a comer
of a chronoscube in 3-dimensional space.
k Constant identifying the number of levels (z axis increments) in the grid
G.
p A vector of chronoscube from 1 ... n that represent a path from an
origin vertices to a destination vertices in G
p probability that a path is blocked
q probability that a path is open; q = 1 p
p' probability that a chronoscube is unavailable
q' probability that a chronoscube is available; q'= 1-p'
n number of chronoscubes in a path
P Probability that k independent paths (one on each level of G) of
chronoscube p are blocked; P =pk
B Probability that one of the chronoscube in p will be blocked, which can
be represented as 1 minus the probability that all cubes in a path are
available; B = 1 q',
D Probability that a chronos-cube is busy.
Erlang Blocking Probability
In 1909, the Danish mathematician A. K. Erlang developed and published a
book called The Theory of Probabilities of Telephone Conversations[ 11], This and
follow on research characterized telephone systems as one of the following:
Poisson input, exponential service times, and multiple channels
Poisson input, constant holding times, and a single channel.
19

Through his research, Erlang developed several important formulas that are
used extensively by the telecommunications industry to engineer and manage
telecommunications networks throughout the world. Erlang's work enables engineers
to determine the average amount of traffic that can be present on a set of trunks before
blocking occurs, or to determine the amount of utilization of a channel given a
blocking probability. His formula for the blocking probability for a lost calls cleared
system with Poisson arrivals is known as the Erlang B formula and is presented below:
(3.1)
B =E,M) =
__A
( A>\
l\
Where N is the number of servers and A is the traffic intensity. A is defined as
the average arrival rate multiplied by the average holding time with units of erlang.
One erlang is equivalent to 3600 seconds.
After running several simulations, the average average holding time can be
observed and this formula can be used to calculate the blocking probability for several
Traffic Intensity Servers Blocking Probability B
3.7 erlangs 2 .59
3.7 erlangs 4 .28
3.7 erlangs 10 .004
3.7 erlangs 20 8.69 x 1 O'09
Table 3-1: Erlang blocking probabilities for arrival rate of 28 vehicles/sec and
average holding time of 476 seconds.
20

The calculated data in Table 3-1 implies that with an ingress rate of 28 vehicles
per second, over the period of an hour, a model with more than 10 levels will
experience a very low probability of blocking. However, what it does not indicate is
the amount of blocking a vehicle will experience at any given instant in time. This data
is misleading in that it doesn't take into account the fact that the blocking probability
for the routing model is not only dependent on the average time a vehicle is in transit,
but also is dependent on the number of other vehicles that are present in the system. It
is a good approximation though.
Queueing Theory
Queueing theory describes the process by which queuing systems are analyzed.
There are six basic characteristics of queuing processes that are listed below
Arrival pattern of customers
Service pattern of customers
Queue discipline
System capacity
Number of service channels
Number of service stages
In 1953 D.G. Kendal created a shorthand notation to describe these attributes.
This notation has been extended over the years and is now represented in Figure 3-2.
Using this notation, the following queuing definition approximates the route
scheduling queuing analysis[l 1].
21

M / M / 1 / FIFO / oo / oo
The arrival pattern defines the number of arrivals per unit of time. For the
route scheduling problem, this parameter was developed based on a busy hour traffic
density of 100,000 vehicles per hour, which translates to 28 requests per second6. The
arrival pattern is defined by the variable X. The service time p is characterized by how
quickly the central controller can allocate routes and how long it takes for a route to
become available. The arrival and service time can be characterized as Poisson
distributions.
a /b /s /w /p /c
Source Population
1,2,3 ... oo
Capacity
1.2,3 ...oo
Queue Type
(FTFO.LIFO, SIRO)
Parallel Servers
1,2,3...oo
Service Time
M = Poisson
D = Deterministic
Arrival Distribution
M = Poisson
D = DeterminicTir.
Figure 3-2: Queuing Theory Notation
6 The number 100,000 requests per hour was derived from travel forecast demand algorithms in [5]
using an average of the top 10 metropolitan population densities.
22

The number of servers is a function of the number of levels in the grid that are
available for routes. The input queue is FIFO and the capacity of the system is limited
by the number of routes that can be assigned at any given instance in time. The source
population is the maximum number of vehicles than will request a route at a given
instant in time.
Queuing theory only works well for very simple problems, many problems are
better solved using simulation. However, the theory can be used to determine if initial
assumptions are accurate. The following formulas are from [11 ] for a single server
queue with a single input line. The variables are identified as
Ls number of expected vehicles in the system
Lq number of expected vehicles in queue
Ws expected wait time in system (queue + servicing)
Wq expected wait time in queue.
p probability of n vehicles in the system
Figure 3-3: Basic Queuing Theory Equations for M/M/l queues.
23

Using an arrival rate of 28 vehicles per second and a service time of 30 per
second, Table 3-2 lists the values predicted.
Queue Attributes Values Calculated
P .933
Ls 1400
Lq 1300
Ws 50 sec
wq 46 sec
Table 3-2: Calculated Queuing Delay parameters
These are the expected results for the steady state condition. The difficulty
with these formulas is that they do not take into account the complexity associated
with route availability. For example, the master computer has a service rate of 30
requests per second. Therefore, it can service 30 vehicles every second. The queuing
algorithm used is First In First Out (FIFO).
As each vehicle is scanned in the queue, the master computer checks to see if a
route is available. If a route is available, the vehicle is removed from the queue and it
begins moving. If a route is not available, then the vehicle remains in queue on the
ground until a route opens up. The fact that the computer can process 30 requests per
second does not mean that it is actually servicing 30 requests. The computer has the
capability to process that many requests.
delays and queue sizes. However, when route congestion occurs, the formulas do not
represent the variation in service times. An equation that addresses variable service
times from [16] could be used if the average variable service times could be accurately
24

defined. The difficulty is that there are too many transient conditions at any instant in
time to accurately describe the average variable service time.
One of the main transient conditions is the assignment of routes to a vehicle in
queue. As indicated earlier, if a vehicle is not selected from the queue, then it remains
in queue until a route is available. The master computer will inspect each vehicle in
the queue up to the maximum service rate. Any vehicle for which a route is found will
be removed from the queue. This process may create a situation where the first
vehicle in queue never leaves because it is being blocked my new vehicles entering the
queue.
This situation is difficult to avoid because in order to avert it, only one vehicle
may be processed at a time. If this were the case, then all vehicles would be blocked
for a period equal to their position in the queue plus the amount of time needed to find
an available route. Instead, the master computer processes the first n vehicles in the
queue with n being equal to the service rate. If the service rate is equal to the arrival
rate, and all vehicles are blocked, then all other vehicles will have to wait until one of
the vehicles is assigned a route.
The outcome of this is to simulate the results which is what is recommended by
most queuing theory and operations research books[21].
25

CHAPTER 4
SOLUTION ANALYSIS
Non-windowed Routing
The main premise behind deterministic routing of vehicles in three dimensions
is that fixed routes are required. As discussed above, the rationale behind this premise
is based on similarities to other fields of study that indicate that random traffic will
eventually lead to congestion when high volume loads are offered. The deterministic
solution does not alleviate congestion, but merely manages it a uniform manner.
Instead of congestion in transit, the approach presented here pursues a queuing based
architecture that prevents vehicles from moving until a guaranteed path is available.
This approach is more reasonable in a three-dimensional environment
compared to today's road system is because of the unrestricted nature of three-
demensional space. In today's two-dimensional world, traffic intersections and
geographic obstacles represent a myriad of congestion points that would be difficult to
schedule available paths for. Thus the rationale for adding the third dimension.
The first approach to solving the routing problem was simplistic. A three-
dimensional grid of rectangular hexahedrons was contrived and each was assigned a
vertex (x, y, 8) in 3D space. The x and y coordinates represent the horizontal vertex
pair, and 8 represents the z coordinate or more specifically the vertical level. The
horizontal pairs are equidistant from the next coordinate pair and the distance is a
constant magnitude that forms the top and bottom of the hexahedron. The parameter
8 is also a fixed value that is equidistant from the next 8 vertex value. The horizontal
and vertical distances may be different in magnitude. The formal definition of the grid
and coordinates is as follows:
26

G is a grid of rectangular hexahedrons with coordinates x, y, and 5; where
x,y = a/; where a, = a,.i+c for z = 1 ...n
where a0 = 0,n< 1000, c < 1000.
5 =b ; where b, = b,./+d for i = 1 ...n
where b0 = 0, n <20, d < 500
H is a hexahedron in G. H is defined as follows:
H = 1 when it is reserved as part of a route path. H = 1 only during
the time it takes a vehicle to arrive at and traverse through it.
H = 0 when it is not part of a route path.
r is a vector of adjacent chronoscubes both vertically and horizontally in
G that represents a route that a vehicle will traverse in order to travel
from origin to destination.
r, represents a hexahedron in r where z = 1 ..n with n <= number of
hexahedrons between the origin vertex and destination vertex.
This first approach to routing was to generate fixed routes from an origin
vertex to a destination vertex in G that was relatively insensitive to time intervals in
each hexahedron. This route identified as r above, occupied a string of adjacent grid
hexahedrons for a time period equal to the time required for the vehicle to travel from
the origin vertex through each H in r. This timeframe is short for r/ close to the origin,
but increases as z approaches n where n is the length of r.
27

Under this approach, as a vehicle traverses a route when it moves from r, to
r,+] r, is released and made available for other routes. Since each route may exist
on a separate plane in G, the initial assumption was that the probability of intersections
of routes at any H in G would be small. After running many simulation exercises, this
assumption turned out to be true given a large enough G with random vehicle traffic
patterns. However, when traffic patterns were focused towards specific grid locations
or from specific locations outward, as is generally the case in many real world traffic
patterns, the algorithm became very inefficient (see the simulation results in Chapter
5).
The simulation showed that vehicles were waiting for routes that were blocked
at destination points in the vertical direction. Horizontal blocking was occurring
infrequently. The reason routes were blocked was because of the long holding times
of r,; i> n/2 towards destination locations due to travel times. The initial assumption
had been that vehicles traveling at 200 MPH with guaranteed flight paths would spend
so little time in the air that queuing delays would be minimal. However, as the number
of vehicles in the system increased, the number of blocked paths also increased, and
the queuing delay for vehicles increased to over an hour. This result was unexpected
and very disconcerting. Initial expected delays were in the magnitude of 10 15
minutes.
Alternatives were evaluated to reduce the size of H to reduce the amount of
congestion, but this turned out to reduce the time delays only marginally. After many
simulation runs and simulation parameter adjustments, it became obvious that a more
sophisticated algorithm was required.
The Scheduled Chronoscube
As described above, the initial routing algorithm was not adequate to meet the
original goals of the solution to minimize queuing wait time. Initial simulation runs
28

indicated that vehicles were waiting for routes to become available because
hexahedrons in G were allocated for excessive time periods. This phenomenon was
very similar to holding times associated with queuing delays in air traffic control when
airplane spacing is large and runway availability is minimal. This queuing situation
also has many similarities to the telephone network trunk holding delay problems.
In a telephone network with long holding times or heavy traffic, the primary
method used to reduce blocking is to increase the number of trunks, thereby adding
capacity. One of the original assumptions from the initial approach was to add more
levels (essentially adding more capacity). This seemed like a logical approach, but
only increased the delay. The delay increased because as routes increased in vertical
height, the distance a vehicle traveled increased, thus increasing the amount of time a
hexahedron was occupied.
With telephone networks, the only other method to reduce blocking is to
reduce the holding time. In telephone networks, disconnecting calls after a
predetermined or random time interval can reduce holding time. This probably would
not be considered friendly service to end users, but it would reduce congestion.
Similarly, for the routing problem, the holding time for each hexahedron in r, can be
reduced by restricting the time allocation to a predetermined time interval. If the
interval is small enough, the probability that the hexahedron is occupied is reduced
significantly.
With this new concept, the routing algorithm had to be modified significantly
to accommodate hexahedron time scheduling. A new definition for a hexahedron was
developed and it was now called a chronoscube to reflect the added dimension of time.
Figure 4-1 depicts a chronoscube and the new definition follows below:
29

H' is a hexahedron in G called a chronoscube. H is defined as follows:
H' = 1 when it is reserved as part of one or more route paths for a
given time interval x; where x is defined as the number of
seconds it takes for a vehicle to move through the
chronoscube space at a given velocity v.
H' = 0 when it is not part of any route path.
Chronoscube
X Dimension
Time reservation t
-------------------------------------------
Figure 4-1: Illustration of a chronoscube
30

With the definition of a chronoscube, the dimensionality of a route is increased
to accommodate a time window. A route now' occupies space and time intervals
within a chronoscube. To see how this impacts the routing algorithm, the following
comparison between the original and the new version is examined. The following
Non-Windowed Routing example:
Figure 4-2 is used to illustrate the following textual description. Vehicle Vi
requests a route r. The central controller starts examining each level in G to see if a
route is available. A route is found and the respective hexahedrons in r are set to 1.
Vehicle Vi begins to move along route r until time x where it resides in hexahedron r4
Vehicle v2
Figure 4-2: Initial Routing Approach example illustration
31

At time t+y, y > x, vehicle v2 requests a route that shares one of the same
hexahedrons in r, r3, which was assigned to vj. At time x+y r3 has been freed because
Vi has already moved through it. Vehicle v2 is assigned a route.
Another vehicle v3 requests a route during time interval t +z where z >x,
containing hexahedrons r6 and r7 within route r. Since vj hasn't move through those
two hexahedrons yet, vehicle v3 is blocked.
Each successive vehicle vthat needs a hexahedron in r, during the interval t+z
where z > x and />4 will experience a blocking condition. A route may be searched on
a different level, but eventually, enough hexahedrons will be blocked and vehicles will
begin to wait in queue for a route.
The main problem with this algorithm is the amount of time held by r* where i
> n/2 with n being the total number of hexahedrons in r. These hexahedrons are
reserved for an extended amount of time. The larger n is, the longer they are reserved,
which creates long delays for other vehicles that need to traverse through them.
Scheduled Chronoscube Routing example:
In the improved version of the algorithm, vehicle Vi requests a route r. The
central controller starts examining each level in G to see if a route is available. A
route is found and the respective chronoscubes in r are set to the time interval x;W.
zvi(,) represents the time interval when vehicle Vi will occupy a chronoscube at time t.
At time x+y, y > x, vehicle v2 requests a route that requires the r3 chronoscube
in r. At time x+y r3 has been released because Vi has already moved through it.
Vehicle v2 is assigned a route.
Another vehicle v3 requests a route during time interval t +10, containing
chronoscubes r6 and r7 within route r. Although Vi hasn't moved through these
chronoscubes yet, if e is small enough, and x3^. is not too close to x, then the
32

chronoscubes will be available. In this example, v3 is not allocated a route because the
time tV3(t it requires for r6 and r7 is within the time interval needed by Vi at xv/^.
When vehicle v4 needs a route at time t+18 through r it is able to get one
because it does not conflict with vj. This time windowing allows v4 to move to its
destination without being impeded by v/s route. Thus making the algorithm more
efficient than it's predecessor. Figure 4-3 illustrates this solution.
Each successive vehicle y, that needs a chronoscube in r( during the interval t+z
where z > x and i>4 will have a potential to utilize the chronoscubes reserved by vl as
long as the time intervals don't overlap.
Figure 4-3: Improved Routing Approach Example Illustration
All successive requests for chronoscubes in route r assigned to vehicle Vi will
experience similar results as vehicle v4 Essentially, the time interval assigned to a
chronoscube for each vehicle creates a time window that is much shorter than that
from the initial approach. This time window is much more dependent on the
33

movement characteristics of each vehicle and requires more calculation than the first
approach.
As illustrated from the preceding examples, the scheduled chronoscube offers
better utilization of chronoscubes and reduces the number of blocked routes at any
given instant in time. It maintains the deterministic nature of the model, and provides
additional control. For example, the time interval assigned to each chronoscube is
initially based on the amount of time a vehicle spends within the boundaries of the 3D
hexahedron. However, to increase safety margins, additional time may be added to the
chronoscube time interval to account for early or late ingress and egress. This
additional time constant e is referred to as a guard time and may be adjusted to insure
vehicle separation. If e is made very large, the model will approximate the non-
scheduled chronoscube model presented in the non-windowed problem approach.
Pre-Schedulinp
In addition to the scheduled chronoscube, another algorithmic improvement to
reduce vehicles trapped in queue is called pre-scheduling. The rationale for this
approach is based on the fact that some vehicles that are waiting for a route continue
to wait for an extended period of time in the queue. This situation occurs when a
vehicle is trying to establish a route that is blocked by other vehicles repeatedly over a
given interval. Blocking usually occurs when many vehicles are trying to travel to a
small geographic location within a small time interval.
To reduce the vehicle wait time in queue, pre-scheduling of the vehicle i.e.
looking ahead in time for a route is one method to reduce this blocking. Essentially,
pre-scheduling enables the routemaster computer to search for a route, many minutes
ahead of the present time, which, in general will allow it to find a route more quickly
for the requesting vehicle. The downside to this approach is that more resources are
34

needed by the routemaster computer to search all possible routes. Therefore, the
routemaster computer is not able to process as many requests. If too many vehicles
require pre-scheduling, the total amount of routes processed each second is reduced.
Automated Architecture
For vehicles to travel in three-dimensional space using a deterministic routing
algorithm, several important improvements will be required as listed below:
Vehicle Requirements
Vehicles must be able to travel in any direction, horizontally and vertically.
Vehicle systems must require redundancy such that a catastrophic failure is
extremely unlikely; system redundancy that is much higher than in existing
aircraft.
Each vehicle must use a positioning system to identify where it is in 3D
space at any given point in time.
Control Requirements
A centralized or distributed system that maintains a map of all routes
assigned to all vehicles.
A system that allocates all routes and updates the route maps as vehicles'
transit the domain.
A system that maintains a queue of route requests.
35

A system that manages priorities for route requests and transit time.

A system that manages congestion by limiting the amount of vehicles in
transit at a given time.
A system that distributes traffic evenly across the grid space.
There are several potential hardware and software architectures that could be
selected to meet the control requirements of the problem domain. Each potential
solution will have to take into consideration the following variables:
Control computer performance.
Reception and processing of transponder signals from vehicles.
Routing Assignment computing vs. vehicle movement computing.
Dynamic rerouting of routes if a vehicle fails to move along the prescribed
route in the appropriate timeframes.
System redundancy.
36

The architecture selected for modeling the simulation is based on a massive
single computer system that is responsible for assigning and managing all routes.
Figure 4-4: The architecture of the centralized computer system
The rationale for this approach is simplicity in simulation. A distributed
environment would work just as well, but simulating a distributed environment is more
complex. Figure 4-4 illustrates the architecture of the model used in the simulation.
37

Three Dimensional Space
The three-dimensional space represented by the grid defines the space in which
vehicles may travel. Since it is probably not feasible to create routes for all vehicle
travel, the space will probably need to be functionally subdivided for different types of
travel. As illustrated in Figure 4-5 the vertical airspace has been divided into 4
sections. Airspace below 500 feet is reserved for local vehicle traffic. Vehicles
traveling in this area will probably travel at slower speeds and may be restricted to the
length of travel.
Above the local traffic zone is the routed traffic airspace. This is the area that
is addressed by the simulation. One important note is that vehicles must traverse
through the local airspace to get into the routed traffic zone (zone 2). This is also true
for vehicles moving in zones 3 and 4. If a vehicle wishes to traverse from one zone to
another that would require it to pass through zone 2, the vehicle would be required to
schedule a route through zone 2.
Zone 4
Zone 3
Zone 2
Zone 1
10,500 ft < z < 15,000 ft
Unrouted cross country traffic
500 Routed Traffic
Z < 500 ft Local Traffic
Figure 4-5: Functional subdivision of the three dimensional space by altitude.
38

Zones 3 and 4 are used for vehicles that are traveling across country and do
not want to be impeded by traffic in the metro areas.
Routes
Routes in the three dimensional space are defined by sequential reservations of
chronoscubes. These routes occupy a chronoscube for a time interval equal to the
amount of time it takes for a vehicle to traverse the cube plus a guard time. Routes
are simplified to a rectangular shape to reduce the number of calculations involved in
allocating chronoscubes. This simplification does not necessarily reduce the accuracy
of the simulation because it is unknown at this time how vehicles will be able to travel
in the future.
Figure 4-6 illustrates a route projected in 3D space. Each chronoscube is
allocated a time slot that is determined by the vehicle's performance characteristics.
For purposes of this research, all vehicles are assumed to have similar movement
characteristics, therefore, movement is uniform across all vehicles in the system. Since
this may not be the case in a real world environment, vehicle parameters may be
configured individually. However, it is difficult to know exactly how different the
parameters might be since these vehicles have not been developed yet.
Figure 4-6: Vehicle Route Illustration using Chronoscubes
39

CHAPTER 5
SIMULATION ARCHITECTURE
To simulate the vehicle scheduling problem, a computer simulation was
developed using C++ and multi-threading under the Windows NT Operating System
(version 4.0). The simulation object model is architected as illustrated in figure 5-1.
The object model contains 5 objects:
Simulation Engine Object
Route Master Computer Object
Vehicle Object
Grid Object
Graphical User Interface (GUI) Object
Simulation Engine Object
The core object within the simulation is the Engine object. This object
provides the methods that drive the simulation. Its main purpose is to control the
simulation activity which includes
Simulation initialization.
Vehicle creation.
Vehicle queue management
Vehicle movement.
40

The routemaster computer route selection.
Statistics generation.
Simulation cleanup.
The flow chart in Figure 5-4 describes the process for each second of
simulation time.
RouteMasterComputer Object
The RouteMasterComputer object describes the functionality of the master
computer system that controls route allocation. Each vehicle generates a request to
the RouteMasterComputer object, which stores the request in a queue. When the
RouteMasterComputer processes the queued requests it checks each queued request
in FIFO order for the next available route. If a route is available for a request, it
returns the route to the vehicle that made the request and removes the request from
the queue.
If a route is not available, the request is retained in the queue. Figure 5-3
illustrates the process flows for finding a route.
The RouteMasterComputer object will only process k requests during each
simulation second. This limitation represents the real world processing restrictions for
the central computer system. The variable k is represented by a parameter in the
control panel of the simulation
41

Figure 5-1: Simulation Architecture illustrating the object layout and object
connections.
IsReservedQ
TestMoveVehicleQ

Vehicle Object
The vehicle object describes a physical vehicle object. Each vehicle is created,
waits, moves, and is destroyed during the course of simulation activity. A vehicle
object contains the following information:
Vehicle position
Speed
Direction traveling (vertical/horizotal)
Acceleration
Deceleration
Velocity
Origin and destination
Route Vector
43

(Process Routes
________I________
For each vehicle :
in queue (FIFO) *
X
-Opoon 1
\x Strategy
-Option 3
________I________
Assign level
based on
distance
traveled, shorter
is lower
Option 2
,_________I___________
i Same as option 1
with random i
bunching
Set level to 1
________I_________
Check level for
available route
No
Route available
-Yes-
Increment level
I by 1 until = max
levels
1 > naxlevcts
No
__________I_________
Asign level to I
vehicle and notify
it so that it can
begin moving
Yes
V
No route found for
vehicle, leave it in
queue, increase
wait seconds
Get next vehicle
in queue
Figure 5-2: Flowchart illustrating the level determination phase of the route
allocation process.
44

Find Route
_____I____
Seconds= 1
________Y________
Calculate vehicle
movement for
this second
________Y______
Calculate the
occupied
chronoscube
based on current
vehicle position
Y
Remove all
chronoscubes
from route vector
Route Not
Found
No
Assign time
window
s-e to chronoscube
_______Y________
to vehicle route
vector
Y
Vdsclc Landed'' )-----------------Yes-------- Route Found '
No
Increment
seconds by I
Figure 5-3: Flowchart illustrating the route selection algorithm that assigns
chronoscubes to routes.
45

Begin
Simulation
______
Initialize,
seconds = 0
T
Move Vehicle
_______y________
Check direction
moving
Vertical
Horizontal
Allocate n
vehicles

| in system queue
Calculate and
Move each vehicle
with a route
assigned
Acceleratiing
Yes
______I______
Accelerate
Vertical Rate
Accel dating
Yes
________T
Accelerate
Horiz Rale
No
JL
Yes
Calculate routes
for k vehicles
Decelerating /No^HNo-
Deceleratmg
T
Increment
seconds by 1
y..
Yes Yes
________ _________________I_
i Accelerate
! Vertical Rate j
Accelerate
Horiz Rate
/" Any vehicles in
queue or moving?'
JL

No
Terminate
Move Vehicle *-
J
/Vehicle moved N
<" out of current -----
xhronoscube?'
Yes
,________I_________,
Send Transponder ;
to Central Control;
i Free chronoscube i
Vehicle Landed? /-
Yes
Remove vehicle |
from system j
Terminate
Figure 5-4: Flow charts illustrating the main simulation and vehicle movement
algorithms
46

When a vehicle object is created, the vehicle sends a message to the master
computer requesting a route. If a route is found, the vehicle begins moving, if not, it
waits in queue until a route is allocated. Figure 5-4 illustrates the process for moving
a vehicle.
Once a route is assigned to a vehicle, the vehicle begins to move by
accelerating vertically until it reaches the maximum velocity. It travels at this rate until
it reaches a deceleration point whereby it begins decelerating until it reaches the
altitude at which it will begin traveling horizontally.
Horizontal travel begins with acceleration until horizontal maximum velocity is
reached. Travel continues until the deceleration point is reached and deceleration
begins until the vehicle position is equal to the point where the vertical descent begins.
Vertical descent is the same as the ascent portion of the route with acceleration
towards the ground. It is important to note that vehicle movement is asymmetrical in
the vertical and horizontal directions. This model was used to represent the fact that
vertical travel may be more expensive than horizontal travel with respect to power
requirements.
As each vehicle moves, it passes through chronoscubes in the three-
dimensional grid. When a vehicle passes from one chronoscube to the next, it uses a
transponder to send a message to the master computer indicating that it has moved out
of the current chronoscube. This allows the master computer to release the
chronoscube to be used by another route. When a vehicle lands, all chronoscubes
have been released and the vehicle is removed from the system list.
Grid Object
The grid object represents the three-dimensional space that routes are allocated
in and vehicles travel through. The grid is represented by a 3 x 3 sparse matrix to
minimize memory requirements. Each element in the matrix points to a cell that
47

contains information about the status of the cell. A cell contains a information on the
number of vehicles using the cell and a pointer to a list of time ranges that indicate
when the cell is reserved by a particular vehicle ID as depicted in Figure 5-5.
The grid object is responsible for manipulating all grid activity and is heavily
used by the master computer and the vehicle objects. The grid object is also
responsible for finding and allocating routes for the master computer. The grid object
was selected to perform this functionality because it has easy access to all grid data.
Figure 5-5: Illustration of the chronoscube sparse matrix with the cell contents
for a chronoscube.
Graphical User Interface Object
The GUI object provides the user interface to manipulate the simulation.
Appendix A contains a view of the main screen. The GUI configures the simulation
48

parameters and executes and stops the simulation. The GUI is also used to display
simulation activity graphically. The main screen contains two windows that are used
to display vehicle routing and movement.
The large window contains an overhead view of each grid level. This view
provides a planar window into the grid that allows the user to see how vehicle travel is
progressing at each level. Additionally, this view also enables the user to see vehicles
moving vertically by changing the color of the vehicles to depict the direction they are
moving. The color blue is a vertical climb, the color red is horizontal movement, and
the color green represents a vertical descent.
The smaller window contains a 3D box with a 3D view of the grid. Each route
and vehicle is plotted on this grid to illustrate how they look from different viewing
perspectives. At any time, the simulation can be stopped to examine the 3D view to
check traffic movement and congestion.
Vehicle Movement Formulas
Since each vehicle must be positioned at each second of simulation time, the
following formulas determine where the vehicle will be. Note that the variable seconds
in the equations refers to seconds relative to the time the vehicle started moving.
During the acceleration phase of movement the equation is:
(5.1)
x = (seconds2)
2v
At maximum velocity the equation is:
(5-2) x = velocity seconds + adistmce
49

During the deceleration phase of movement
(5.3)
x = abs( sec onds deceltime) -1 deceleration deceltime2 | + vdis tan ce
where deceltime is the time in seconds where deceleration begins and
vdistance is the distance traveled before deceleration begins
Constant acceleration and deceleration rates are used to simplify the model.
Another reason to use a simplified model is that future vehicle characteristics are
speculative at best.
Simulation Hardware
The simulation was executed on a Personal Computer running the Windows
NT Operating System. The CPU is a 133MHz Pentium Processor with 64 MB of
RAM. The system also included a 7 GB hard disk with virtual memory set to
390MB.
During high volume 5000 vehicle simulation the system utilized 124MB of
combined RAM and virtual memory.
Simulator Constraints
The simulator is designed to manage vehicles entering the system within the
boundaries of the grid area. Vehicles will need to be able to enter the system from
outside the grid area within the routed traffic zone (zone 2) altitude, and from altitudes
above and below it.
Another limitation of the model is the ability to route around obstacles. For
example, if a congested area blocks a direct path, an alternate route with multiple
segments might be used instead of waiting for the congestion to dissipate.
50

CHAPTER 6
SIMULATION RESULTS
There are many scenarios that can be addressed when simulating the effects of
route generation and vehicle movement. The main premise behind this research is to
identify parallels to existing traffic movement, thus a model is used that represents
travel in a major metropolitan area. Since the author resides in Denver, this city was
selected as the subject for the simulation runs
The simulation model for Denver consists of two focal areas for travel: the
center area represents downtown and the area to the southeast represents the Denver
Technology Center. Traffic moves towards each area based on random destination
points within the grid. Figure 6-1 illustrates how Denver is modeled in the simulator.
The picture shows vehicles moving towards the two concentration areas and several
routes that have random destinations.
The assignment of destination points is performed with the following rules:
1. Random traffic anywhere on the grid is 20%
2. Traffic moving towards downtown is 40%
3. Traffic moving towards the Technology Center is 40%
These rules were developed based on traffic patterns during peak travel times
in Denver between 6:00am and 9:am. Traffic patterns are different depending on the
time of day.7 These patterns do not include cross-town traffic, which is expected to
travel outside the route assignment level zone.
7 Colorado Department of Transportation traffic studies for 1992.
51

GRID VILW1 R
HBD
Data
\>4aM= 1
The simulation software is capable of supporting other models in addition to
the Denver scenario such as: multiple destination areas (up to 10), complete random
traffic to any destination, and traffic moving towards or away from a focal area. Each
configuration produces interesting results for analysis, but to create a comparison that
could be contrasted, the scenario chosen was of most interest to the author. The
following sections describe the results obtained from the research using the simulator.
52

Simulation Scenarios
The primary results of the simulation focus on the queue sizes and the wait
time associated with each vehicle. The following observations illustrate several
different output characteristics of the simulation. These graphs focus on the following:
High Volume Simulation
Heavy Congestion Simulation
Medium Congestion Simulation
Light Congestion Simulation
Heavy Congestion with Small Time Window Simulation
Each graph provides insight into how the algorithm operates under different
parameters.
High Volume Simulation Configuration
The high volume simulation results illustrate how well the model responds to a
large load. Due to the limited size of the computing resources available to simulate
this model, 5000 vehicles is the maximum input capacity of the simulator on the
hardware used. A sample of 200,000 vehicles would be preferred. However, to reach
this level of simulation, a system with 10 or more gigabytes of RAM is required, or a
sophisticated grid caching algorithm is needed. The parameters listed in Table 6-1
were used to generate the high volume simulation results.
53

Simulation Parameters Value
Vehicles Requesting Routes 5000
Routes Requested Per Second 28
Routes Processed Per Second 30
Chronoscube Guard Time 5 seconds
XY Grid Size 500 sq ft
Vertical Level Size 500 ft
Levels in the Grid 20
Vehicle Movement Denver Scenario plus random
Route Allocation Start at level 1; travel upward
Nodes in Grid to travel towards 2
Table 6-1: Simulation Parameters for High Volume Configuration
High Volume Simulation Results
For this simulation run, wait times are not excessive given that the simulation
was terminated early. The simulation was terminated early because of excessive
thrashing on the hard drive due to the use of virtual memory. The simulation was
running for almost 1 week and had not made significant progress in the latter days due
to the I/O bottleneck.
If the simulation had completed, the author believes the wait times would have
reached 500 900 seconds for vehicles which entered the system toward the end of the
ingress period. The premise for this statement is based on the simulation results
encountered in other simulation runs where high congestion was present.
Figure 6-2 presents the queuing data for the simulation. The queue size is 40%
of the number of vehicles requesting service. The wait times are within an acceptable
range and the queue size is beginning to decrease.
54

Queuing Analysis for 5000 Vehicle Simulation Run
120
100
80
60
40
20
0
0 60 100 160 200 260
Time (t)inieceidi
+ Vehicles in Grid
I Vehicles in Queue
3
*
Vehicle somber *s it enters
system
Vehicle Wtit Time
Figure 6-2: Queuing Graph for the High Volume Configuration
The graph above represents the results of the largest model size that would run
on the hardware used to execute the simulation. Although much larger data points
may be required to simulate real traffic patterns, the data provides insight into how the
Table 6-2 lists the statistical observations identified. The numbers related to
the maximum and average move seconds are not available because the simulation was
not completed.
55

Statistical Simulation Output Values
Maximum Vehicles on a Level (Level #) 576(1)
Average Vehicles on a Level 193.67
Maximum Vehicles in System 3821
Maximum Queue Size 1633
Average Queue Size 529
Maximum Wait Time 98 sec
Average Wait Time 23 sec
Maximum Vehicle Move Seconds N/A
Average Vehicle Move Seconds N/A
Table 6-2: High Volume Simulation Results
Heavy Congestion Simulation Configuration
To simulate the heavy congestion scenario with the limited system resources,
an approximation was used to create congestion. To get the desired results, only two
levels were used with an input of 2000 vehicles. The rationale for this approach is
based on the fact that when all levels are full, the chance of finding an open route is as
likely with 2 levels as that of 20. The reason for this is that the destination vertical
path is usually blocked and a large number of levels will not have a major impact on
route generation.
With only 2 levels in use, only 2000 vehicles are required to generate a
congestion situation. By using only 2000 vehicles, the simulation runs in memory with
reasonable performance. The simulation configuration parameters are listed in Table
6-3.
56

Simulation Parameters Value
Vehicles Requesting Routes 2000
Routes Requested Per Second 28
Routes Processed Per Second 30
Chronoscube Guard Time 5 seconds
XY Grid Size 500 sq ft
Vertical Level Size 500 ft
Levels in the Grid 2
Vehicle Movement Denver Scenario plus random
Route Allocation Start at level 1; travel upward
Nodes in Grid to travel towards 2
Table 6-3: Simulation Parameters for Heavy Congestion Configuration
Heavy Congestion Simulation Results
In a heavy congested environment, the queue size relative to the vehicles
requesting service is 75%. Wait times increase to 1400 seconds for vehicles that arrive
at the end of the ingress period. The graph in Figure 6-3 illustrates the relationship
between the service requests and the queue size. The wait time increases linearly with
each additional request. The specific output results are listed in table Table 6-4.
57

Heavy Congestion
2500
2000
1500
1000
500
0
10
/

A .igfjpaMfc x --
ii ii %
100
Tima (seconds)
1000
1400
1200 S'
1000 O
*00 Â§
too
400
200
0
10000
Wut Qurat Sn
Vehicles it System
. Vthick Airtrel Order
a QTrent Wut Seconds
This graph illustrates that the model does not prevent long queuing times when
heavy congestion exists. Average wait time for this simulation run is 500 seconds (8.3
minutes), which is probably an acceptable wait time for most individuals. The
maximum wait time was near 1400 seconds (23.3 minutes) which is within 30 minutes.
Statistical Simulation Output Values
Maximum Vehicles on a Level (Level #) 335 (1)
Average Vehicles on a Level 299
Maximum Vehicles in System 598
Maximum Queue Size 1619
Average Queue Size 597
Maximum Wait Time 1531 sec
Average Wait Time 530 sec
Maximum Vehicle Move Seconds 1003 sec
Average Vehicle Move Seconds 477 sec
Table 6-4: Heavy Congestion Simulation Results
58

Heavy Congestion with Small Time Window Simulation Configuration
To minimize queuing delay, one of the parameters that can easily be changed is
the guard time for each chronoscube. The guard time represents a safety margin that
is used to minimize the proximity of one vehicle to another. Under heavy loaded
conditions, reducing this parameter will have an effect on the number of routes that
can be processed. The eflFect this has on the model is to change the time window
available in each chronoscube. This effectively reduces the probability that a
chronoscube will be in use when it is needed as part of a route at any given instant in
time.
This simulation run examines this by changing the guard time from 5 seconds
to 1 second. The value was not changed to zero because this leaves no margin for
error. All other parameters are equal to the heavy congestion configuration.
Simulation Parameters Value
Vehicles Requesting Routes 2000
Routes Requested Per Second 28
Routes Processed Per Second 30
Chronoscube Guard Time 1 seconds
XY Grid Size 500 sq ft
Vertical Level Size 500 ft
Levels in the Grid 2
Vehicle Movement Denver Scenario plus random
Route Allocation Start at level 1; travel upward
Nodes in Grid to travel towards 2
Table 6-5: Simulation Parameters for High Congestion with Short Time Window
Configuration
59

Heavy Congestion with Small Time Window Simulation Results
The output results reflect a reduction in maximum queue size and wait time.
The maximum queue size is reduced by 23% and wait time is reduced by 30%.
Another significant reduction is the maximum wait time incurred by some of the
vehicles in the system. The maximum wait time was reduced by 30% as well.
These reductions in queuing delay indicate that the guard time has a significant
impact on the delay incurred while waiting for a route. While this is a significant
improvement, the safety margin is minimal and may lead to collisions, which are
undesirable. Figure 6-4 illustrates the improved queuing results graphically.
Heavy Congestion with Small Time Window
e
u
9
OS
I
I
Time (seconds)
Wait Queue Size
Vehicles in System
Wait Seconds
Figure 6-4: Queueing and Wait Times for Heavy Congestion with Small
Window Size
In the above graph, a smaller time window was used to compare the wait times
in a heavy congestion environment. A wait time window guard time of 1 second was
used instead of the normal 5 second guard time. Wait times dropped by 500 seconds
on average in this run.
60

Statistical Simulation Output Values
Maximum Vehicles on a Level (Level #) 743 (1)
Average Vehicles on a Level 649
Maximum Vehicles in System 1298
Maximum Queue Size 1172
Average Queue Size 281.6253
Maximum Wait Time 921 sec
Average Wait Time 116 sec
Maximum Vehicle Move Seconds 1000 sec
Average Vehicle Move Seconds 476 sec
Figure 6-5: Heavy Congestion Simulation with Short Time Window Results
Medium Congestion Simulation Configuration
The medium congestion simulation was executed to use as a comparison
against the heavy congestion scenario to see if halving the input rate reduced the
queue size and wait time. The only difference between the medium and heavy
simulation exercise was the arrival rate that was halved.
Simulation Parameters Value
Vehicles Requesting Routes 2000
Routes Requested Per Second 15
Routes Processed Per Second 30
Chronoscube Guard Time 5 seconds
XY Grid Size 500 sq ft
Vertical Level Size 500 ft
Levels in the Grid 2
Vehicle Movement Denver Scenario plus random
Route Allocation Start at level 1; travel upward
Nodes in Grid to travel towards 2
Table 6-6: Simulation Parameters for Medium Congestion
61

Medium Congestion Simulation Results
By reducing the arrival rate by 50%, the queue size and queue wait time
decreased. However, the decrease was only marginal, 4%. The reason for this is due
to the grid becoming saturated fast in both simulation exercises.
From these results, it is obvious that reducing the arrival rate is not a good
mechanism for improving queuing delays.
Medium Congestion
1 to 100 1000 10000
1

u
9
m
i
W ait Q ueue S ire
Vehicles in System
^ W ait S econds
Tine (seconds)
Figure 6-6: Graph Illustrating the Queuing Delay for the model under medium
congestion
The statistical results for the medium congestion scenario are listed in Table 6-7.
62

Statistical Simulation Output Values
Maximum Vehicles on a Level (Level #) 392(1)
Average Vehicles on a Level 349
Maximum Vehicles in System 698
Maximum Queue Size 1524
Average Queue Size 577
Maximum Wait Time 1576 sec
Average Wait Time 512 sec
Maximum Vehicle Move Seconds 1032 sec
Average Vehicle Move Seconds 480 sec
Table 6-7: Medium Congestion Results
Light Traffic Simulation Configuration
The light traffic simulation exercise tests the basic queuing theory stated in
Chapter 3. Using an arrival rate of 2 vehicles per second and 10 levels, the load for
routing is predicted to be non-existant. The simulation parameters are located in Table
6-8 below.
Simulation Parameters Value
Vehicles Requesting Routes 2000
Routes Requested Per Second 2
Routes Processed Per Second 30
Chronoscube Guard Time 5 seconds
XY Grid Size 500 sq ft
Vertical Level Size 500 ft
Levels in the Grid 10
Vehicle Movement Denver Scenario plus random
Route Allocation Start at level 1; travel upward
Nodes in Grid to travel towards 2
Table 6-8: Simulation Parameters for Light Traffic
63

Light Traffic Simulation Results
Using the equations presented in Chapter 3, the following theoretical values
were calculated in Table 6-9.
Queue Parameters Calculated Values Simulation Values
P 0.067 N/A
Ls 70 498
Lq 4 1.4
ws 3.5 sec 479 sec
Wa 2 sec 1.11 sec
Table 6-9: Calculated vs. Simulated Queuing Values for Light Traffic
The calculated values represent the steady state theoretical values over a
period of time equal to that of the simulation. Ls represents the number of vehicles in
the system. The reason for the difference is that the calculated values do not take into
consideration the time duration a vehicle is in flight. Lq represents the length of the
queue. The percentage difference is 35% which is good considering the simplicity of
the queuing calculations.
Ws is the total time a vehicle is in the system. The calculated results are
unusable here because they do not reflect the true service time that includes vehicle
movement. Wq is the average time a vehicle waits in queue. This value is off by 55%
compared to simulated results, but with an arrival size of 2000 vehicles, this margin is
relatively small.
Figure 6-7 illustrates the simulated data for queue size and wait times. Some
vehicles experience a high wait time due to route conflicts with other vehicles. These
vehicles must wait for a time period equal to or greater than the guard time of all
surrounding chronoscubes. With a 5 second guard time, this wait time can be as high
as 7 seconds. If a vehicle is blocked by more than one vehicle at different time
64

Light Traffic Simulation Results
Using the equations presented in Chapter 3, the following theoretical values
were calculated in Table 6-9.
Queue Parameters Calculated Values Simulation Values
P 0.067 N/A
Ls 70 498
Lq 4 1.4
Ws 3.5 sec 479 sec
WQ 2 sec 1.11 sec
Table 6-9: Calculated vs. Simulated Queuing Values for Light Traffic
The calculated values represent the steady state theoretical values over a
period of time equal to that of the simulation. Ls represents the number of vehicles in
the system. The reason for the difference is that the calculated values do not take into
consideration the time duration a vehicle is in flight. Lq represents the length of the
queue. The percentage difference is 35% which is good considering the simplicity of
the queuing calculations.
Ws is the total time a vehicle is in the system. The calculated results are
unusable here because they do not reflect the true service time that includes vehicle
movement. Wq is the average time a vehicle waits in queue. This value is off by 55%
compared to simulated results, but with an arrival size of2000 vehicles, this margin is
relatively small.
Figure 6-7 illustrates the simulated data for queue size and wait times. Some
vehicles experience a high wait time due to route conflicts with other vehicles. These
vehicles must wait for a time period equal to or greater than the guard time of all
surrounding chronoscubes. With a 5 second guard time, this wait time can be as high
as 7 seconds. If a vehicle is blocked by more than one vehicle at different time
65

intervals, the waiting time will increase as indicated by several occurrences illustrated
on the graph.
Light Congestion
900
800
< TO
too
Jj 500
a 430
3 300
jg 200
100
0
3
3
O'
Time (seconds)
Vehicles in System
Wait Queue Size
Wait Seconds
Figure 6-7: Chart Illustrating Queuing and Wait Times for Light Congestion
The above graph illustrates that with light congestion, queuing is not a factor
and wait times are insignificant. The arrival rate used for this simulation is 2 vehicles
per second.
66

Simulation Parameters Value
Vehicles Requesting Routes 2000
Routes Requested Per Second 2
Routes Processed Per Second 30
Chronoscube Guard Time 5 seconds
XY Grid Size 500 sq ft
Vertical Level Size 500 ft
Levels in the Grid 10
Pre-scheduling On
Vehicle Movement Denver Scenario plus random
Route Allocation Start at level 1; travel upward
Nodes in Grid to travel towards 2
Table 6-11: Simulation Parameters for Pre-scheduling
Pre-scheduling Simulation Results
The output results from the simulation using pre-scheduling are listed in Table
6-12.
Statistical Simulation Output Values
Maximum Vehicles on a Level (Level #) 392(1)
Average Vehicles on a Level 349
Maximum Vehicles in System 698
Maximum Queue Size 1480
Average Queue Size 577
Maximum Wait Time 1480 sec
Average Wait Time 220 sec
Maximum Vehicle Move Seconds 1032 sec
Average Vehicle Move Seconds 480 sec
Table 6-12: Pre-Schedule Congestion Results
67

Calculated values indicate that average wait time is 50% smaller than wait
times in a congested environment. This reflects the fact that pre-scheduling in time
finds more optimal routes for vehicles on average than waiting for a route to be
allocated in time. Unfortunately, pre-scheduling does not reduce the wait times for all
vehicles. Some vehicles still get trapped in the queue and must wait for inordinate
times before a route can be allocated. Figure 6-8 illustrates the simulated data for
queue size and wait times.
Heavy Congestion with Pre-scheduling
2500 r 1500

2000 - 4- c
1500 - - iooo S w Wait Queue Size
1000 - 500 I Vehicles in System
500 -
ii <8 Vehicle Arrival Older
0 i -o
1 10 100 1000 Queue Wait Seconds
Time (seconds)
Figure 6-8: Chart Illustrating Queuing and Wait Times for Pre-Scheduling
This graph shows that with pre-scheduling, wait times are reduced by 50% on
average, while maximum wait times are still equivalent to the normal congestion
scenario.
68

Optimization Analysis
After reviewing the results provided by the five simulation studies, it is obvious
that changing several parameters can have a dramatic impact on the queuing delay. To
identify any potential improvements.
Since the primary area of concern is the heavy congestion scenario, this is the
focus of.the optimization analysis. In addition to the two simulation configurations
presented in this section, two other configurations are of interest. The first addresses
increasing the service rate by 100% from 30 to 60 routes per second. The second
configuration reduces the size of a chronoscube side from 500 ft to 100 ft to measure
the impact of smaller chronoscubes in a route.
In the second configuration, the chronoscube guard time is reduced because a
vehicle spends only a fraction of time in a chronoscube when the size is reduced. The
graph in Figure 6-9 shows the average queuing delay, the average queue size, the
maximum queue size, and the maximum number maximum vehicles in the system.

3
tt
3
o
c
(0

o
a>
>
700
600
500
400
300
200
100
0
1800 _
1600 m
1400 "5
1200 o
1000 g
800
600
400
200
0

E
Avg Queue size
BAvg Queuing Delay
Max Wait Time
Figure 6-9 : Comparison of Simulation Configuration Results
69

From the results of the graph, it is evident that the biggest improvement to
reduce queuing delay is to change the grid size and to reduce the guard time for the
chronoscube. Pre-scheduling reduces average wait time, but does not impact the
queue size or maximum wait time.
There are an infinite number of possible combinations for the above scenarios
that can be used to optimize the queuing delay. Each parameter adds a cost factor to
the implementation of the system though. For example, when the size of a
chronoscube is reduced, the size of the grid increases proportionally. This increases
cost to compute and store routes. Another example is the cost of increasing the
service rate. If the service rate is increased, then additional computing power may be
required which will add hardware costs.
These examples illustrate the trade-offs associated with changing parameter
values. Much thought will be required to optimize these parameters and others that
have not been identified yet.
70

CHAPTER 7
CONCLUSION
Researching theoretical material to support the premise of the thesis was
difficult because very little data or information exists to support the hypothesis of
deterministic routing in three-dimensional space. Since this is a new idea, the author
pioneered a number of new concepts such as the chronoscube and the routing
algorithm. The initial hypothesis was to identify a potential model for traffic
movement in three-dimensional space that would minimize travel time and congestion.
The deterministic approach was developed based on similar models that reflected
advantages to more predictability in managing traffic.
A simulator was developed to test the original hypothesis; that this type of a
solution would be effective. Due to the simplicity of the first model, high volume
simulations could be executed without memory constraints. The original simulations
identified a major flaw in the original hypothesis because queuing wait times exceeded
an hour, an excessive wait period.
The alternative solution brought about the concept of the chronoscube and the
benefits it brings to solving the problem of queuing delay. The chronoscube added a
fourth dimension to the problem, which added complexity. This complexity added a
high cost to the simulation in terms of memory usage. With the added memory
requirements, the simulation size was reduced dramatically, which created a need to
simulate congestion in compressed space as a means of gauging the impacts on the
new algorithm. Although this was not an ideal environment, the results reflect that
with the addition of the chronoscube to the algorithm, the queuing delays are reduced
to what the author believes will be acceptable delays.
71

From the simulation results, it is apparent that when the offered traffic load is
light to medium, the simulation behaves as expected. Routes are allocated quickly and
queueing delays are minimal, less than 5 minutes. As the offered load is increased to
above 15 vehicles per second, the simulation reaches saturation and the queuing delay
begins to increase linearly for each vehicle that arrives after the point of saturation.
The difficulty with this behavior is that it implies that with large volumes of
traffic, in excess of 10,000 vehicles, queuing delays could become unacceptably high
(> 30 minutes). Due to the limitations of the hardware that is executing the
simulation, sample runs greater than 5000 are impractical. Therefore, approximations
are used to emulate congested environments. These approximations may exhibit
different characteristics as compared to a complete simulation run. Since congestion is
one area of major importance with respect to this problem domain, additional research
is needed to validate the supposition that the simulated congestion scenarios are
comparable to the behavior a high capacity sample.
Several important observations were made during the execution of the various
simulation scenarios as listed below:
The time to calculate a route consistently averaged from 300 to 1200
miliseconds depending on the length of the route. This implies that fast
hardware or multiple processors will be required to manage peak loads.
Route patterns oriented towards a focal point reached congestion faster
than pure random patterns. Vehicles moving away from a focal point
incurred an even higher delay than either of the aforementioned patterns.
When routes are allocated from lower levels upward, saturation occurs
faster compared to route level assignment based on level.
72

Queuing delay is reduced dramatically when the area of a chronoscube is
reduced in size. This is evident from the results identified in the
comparison graph in Chapter 6.
Because the queue service strategy used is a modified FIFO, some vehicles
may wait in queue long after new arrivals are dispatched. This creates
some disparity and may require a priority scheme to overcome. Since this
observation came to light during the writing of this paper, additional and
output statistics will be needed to study the impact of this circumstance.
When this endeavor was first started, the premise was that traffic congestion in
the air would be unacceptable. Thus the idea to keep vehicles on the ground while
waiting for a guaranteed route before moving. Once movement began, a vehicle
moves in the most optimal manner until it reaches the destination coordinates. As the
research progressed, it became obvious that with chronoscube routing, other problems
might be solved. The other areas of research might include the following:
Present day routing of vehicles in two-dimensions.
Air traffic control around congested airports.
A military application such as scheduling weapons delivery over a target.
Scheduling the delivery of data messages on local area networks.
73

With respect to follow on research related to the problem domain, there are
many areas of study that need to be pursued. The list below is a not comprehensive by
any means:
1. Vehicle movement in an arc instead of the rectangular movement.
2. Developing enhancements to the algorithm to account for vehicle
movement that does not coincide with a scheduled route. Dynamic
rescheduling in flight.
3. Add vehicles that enter the system in the air from outside the original grid
space.
4. Study the impacts weather will have on route creation.
5. Evaluate better methods for reducing queuing delay.
6. Execute simulations that approach theoretical real world sizes to gather
more accurate results.
7. Optimization in the creation of routes.
8. Optimization in the implementation of chronoscubes
9. Study the characteristics of distributed vs. centralized control.
The simulation data supports the hypothesis that deterministic fixed routes may
be generated for three-dimensional travel with reasonable queueing delays. It would
be nice to live long enough to see how future technology will be deployed and if
people are willing to use a system similar to the one proposed here.
74

APPENDIX A SIMULATOR OPERATION GUIDE
The 3D simulator provides users with the ability to configure various
parameters of the simulation through a graphical user interface. In addition to
modifying the simulation parameters, the simulation interface also provides a graphical
depiction of the vehicle routes and vehicles moving on the 3D grid.
To execute the simulation, press the start button, enter the configuration
values, and watch.
The main screen of the simulator is illustrated below:
Figure A-l: Simulator Main Window
75

The objects displayed on the main window perform the following functions:
GUI Objects Use Description
Start Button When this button is pushed, a dialog box is opened requesting the simulation parameters for the simulation run. Once the parameters have been modified and the OK button is pressed, the simulation starts. A successful start is indicated on the main window above the start button where the phrase simulation running is displayed.
Stop Button This button when pressed stops the simulation. All statistics files are closed and the simulation run is terminated. A new simulation must be started after the stop button is depressed.
Pause Button This button pauses the simulation until the continue button is pressed.
Continue Button This button continues the simulation after the pause button is pressed. The continue button will not work after the stop button is pressed.
Draw Button This button updates the graphics on the main window and the 3D graphics window.
Level Change Box The level change box contains the current level number of the grid that is displayed in the main window. This number can be changed by pressing on the up or down arrows. Typing a new number into the box will also change the level.
Configuration Menu The Configuration menu displays the simulation parameters dialog box which can be used to change system parameters during simulation execution.
The dialog box that contains the simulation parameters is portrayed in the next
figure.
76

Control Setup Parameters
BQ
- Engine Control Parameters-
Maximum No. at Vehicles
Computer Rate Update Interval fi
Vehicle Route RequestAec |28
Grid Drawing Every No. of secs 15
Logging------------------
r Normal Logging On
W Statistics Logging On
P Error Logging On
W Display Route Trace
W Preschedufrig On
OK
Cancel j
Hefr |
Route Computer Parameters DebugLevel |999 i Grid Configuation Parameters Grid Square Side See in Feet |500
Maxinun No. ol Vehicles in Queue |10000 i Grid Level Size in Fed 1500
Routes Processed per Second J50 I Tine Interval */ (secs) F
Pending Requests Queue See {10000 ; Levels Used {20
Pre-schedtJe Max Time Lookahead (60 | i Max Vehicles Per Level Nodes n Grid Layout 1100 |2
|
i
- Simtiation Contigaatior Parameters------
I Vehicle Movement Options {3
Vehicle Arrival DistAUbon pj
: Route Level Assignment Options J3
1=random,2 = Denver,3*2 + 1,4 = Taeach j
node in gid node layout j
1 = Go to Desrtation 2 Leave from
Destination
1 = Seq. 2 = Random. 3 (always start at 1 ]
___________________________________i
Figure A-2: Simulation Parameters Dialog Box
The fields on the dialog box are identified in as follows:
Field Value Field Description
Maximum number of vehicles This parameter identifies how many vehicles will be created during the simulation.
Computer Route Update Interval This value represents the number of seconds between route generation, i.e. the
77

Field Value Field Description
master computer will only process route requests every x seconds where x is the value specified in this field.
Vehicle Route Requests per Second The value in this field reflects the rate at which vehicles are created by the simulation. It represents the arrival rate of vehicles into the system.
Grid Drawing Every Number of Seconds This value is the interval between automatic grid updates on the user screen. The larger the number, the fewer screen updates. If this parameter is too low, the simulation will slow because it has to wait while the screen is updated. Screen updates can require significant time to update if there are a large number of vehicles present.
Normal Logging On If the checkbox is checked, then logging to a file is performed to validate simulation state changes.
Statistics Logging On When checked, this parameter indicates that statistics are logged for analysis.
Error Logging On When checked, system errors are logged and additional detail is generated.
Pre-scheduling On When checked, the simulation will perform pre-scheduling for vehicles requesting routes.
Debug Level This numerical data indicates the debug level. If Error Checking is checked then debug information is output to a log file. Debug levels 1 4 are available. Smaller numbers represent less log data. Data is output to a file called Engine.log
Maximum number of vehicles in queue This parameter represents the maximum
78

Field Value Field Description
number of vehicles that can be created by the system. If during the course of simulation this number is exceeded, vehicles will not be created until other vehicles have completed to their destination.
Routes Processed per second This parameter represents the number of route requests processed each second by the master computer. If this number is less than the vehicle arrival rate, then queuing will occur before route congestion occurs. For optimal execution of the simulation, it is recommended that this value is always equal to or greater than the arrival rate.
Pending Request Queue Size This is the size of the pending request queue. The pending request queue is where the master computer stores route requests from vehicles. It processes each request in the order it is received. If the number of requests exceeds this value the requests are denied.
Pre-scheduled max lookahead time This value represents the maximum amount of time the scheduler will look ahead into time to see if a route is available for a vehicle.
Grid Square Side in square feet This is the horizontal distance of a chronoscube in feet. The default value is 500 feet.
Grid Level Size in Feet This value represents the vertical component of the chronoscube in feet. The default value is 500 feet.
Time interval +/- seconds The time interval value is considered the fourth dimensional component of the chronoscube and represents the guard
79

Field Value Field Description
time of the cube. If a vehicle reserves a cube, the cube is unavailable for the period of time it takes a vehicle to travel through the cube, plus the guard time. The default guard time is 5 seconds.
Levels Used The value in this field is the maximum number of levels available to a vehicle when traversing the grid. The default is 20.
Max Vehicles per level To reduce congestion on a level, this parameter can be used to restrict the number of vehicles that can be allocated to a level at any given time.
Nodes in Grid Layout This value is the number of nodes in the grid that vehicles might traverse to or away from. This parameter is used to simulate city locations or potential congestion points. This number can be from 1 to 10.
Vehicle Movement Options This parameter describes how a vehicle will wish to travel on the grid The value 1 is for total random traffic. The value 2 is for traffic similar to Denver traffic during rush hour. The value 3 is for Denver traffic during rush hour with random traffic added. The value 4 is for traffic moving towards the nodes defined by the "Nodes in Grid Layout Parameter".
Vehicle Arrival Distribution This parameter defines how vehicles move. If the value is 1, vehicles move from origin to destination. If it is 2, vehicles move in the opposite direction.
80

Field Value Field Description
Route Level Assignment Option This option describes how the master computer assigns levels to a route. A value of 1 indicates sequential assignment after a base level is calculated based on distance to travel. A value of 2 indicates random assignment after a base level is calculated based on distance to travel. A value of 3 indicates that all vehicle routes are searched for from level 1 sequentially.
81

APPENDIX B CODE LISTINGS
The code listings are contained on the following pages.for the 3D vehicle
scheduling simulation. The table below identifies the listings and their purpose.
Program Name Purpose/F unction Reference
3DgridView.cpp This source file contains the 3D object drawing methods to display the simulation of vehicles moving in 3D-space. 84
Control Dialog.cpp This file contains the objects to draw and maintain the simulation control dialog box. 98
Control Dialog.hpp This file contains the object definitions for the simulation control dialog box. 101
Engine.cpp This file contains the simulation engine object methods that drive the 3D simulation. The engine is executed as a separate task. It creates the vehicles and calls the master computer to create routes. Once a route is created, it moves the vehicles. 103
Engine.hpp This file contains the object definitions for the simulation engine object for file Engine.cpp. 109
Globals.hpp This file contains global variables that are used to 112
82

Program Name Purpose/F unction Reference
configure all modules of the simulation.
Grid.cpp This file contains the objects related to the 3D grid that represents the 3D airspace where routes are created and vehicles move through. 114
Grid.hpp This file contains the grid object definitions for file Grid.cpp 150
Gridtest.cpp This file contains the objects for the graphical user interface and the event routines that are used to drive the simulation. 156
RouteMasterComputer.cpp This file contains the objects for the master computer that assigns routes and updates the grid when a vehicle moves through a chronoscube. 176
RouteMasterComputer.hpp This file contains the object definitions for the master computer and route request queues for file RouteMasterComputer.cpp 182
Vehicle.cpp This file contains the vehicle object methods that create, move and signal vehicle movement to the master computer. 185
Vehicle.hpp This file contains the vehicle object definitions for file vehicle.cpp. 198
83

//-------------------------------------------
// Project Vehicle Simulator
//
//
//
//
//
//
//
// OVERVIEW
// ..........
// OpenGL API calls to display the 3D routes and vehicle movement
//
SUBSYSTEM:
FILE:
AUTHOR:
DATE:
3D Route Viewer
3DgridView.cpp
Bret A. Godwin
November 1997
//
include
include "opengl testapp.h"
include "opengl testwindowview.h
include
include
include
include
include

"controldialog.h"
"vehicle.hpp"
"engine.hpp"
const GRIDRANGE = float((GRIDMAX+50)/2);
const LEVELRANGE = 200.Of;
const STEPSIZE = 0.5f ;
const STEPQTY = GRIDRANGE / STEPSIZE;
// Rotation amounts
static GLfloat xRot = 295.Of;
static GLfloat yRot = O.Of;
static GLfloat zRot = 310.Of;
static GLfloat xnew[10],ynew[10] ,
static GLfloat xShift, yShift;
znew[10], xnew2[10], ynew2[10];
static LOGFONT MainFontRec;
static TFont *sfontl;
static TFont *sfont2;
//extern ControlDialogXfer ControlDialogData;
// Forward declarations
void GLResize(GLsizei w, GLsizei h);
void GLRenderScene(void *pData);
void GLSetupRC(void *pData);
extern MyCriticalSection EngineLock;
//
// Build a response table for all messages/commands handled by the application.
//
if defined(ENGINERUN)
84

DEFINE_RESP0NSE_TABLE1(TOpenGL_TestWindowView, TWindow)
#else
DEFINE_RÂ£SP0NSE_TABLE1(TOpenGL_TestWindowView, TWindowView)
#endif
//{{TOpenGL_TestWindowViewRSP_TBL_BEGIN})
EV_WM_CREATE'
EV_WM_DESTROY,
EV_WM_ERASEBKGND,
EV_WM_PAINT,
Ey_WM_s IZ E,
EV_WM_QUERYNEWPALETTE,
EV_WM_PALETTECHANGED,
EV_WM_TIMER,
EV_WM_KEYDOWN,
EV_WM_RBUTTONUP,
EV_WM_LBUTTONUP,
EV_WM_ACTIVATE,
#if defined(ENGINERUN)
EV_MESSAGE(1033,EvRotate),
#endif
//{{TOpenGL_TestWindowViewRSP_TBL_END}}
END RESPONSE TABLE;
//{{TOpenGL_TestWindowView Implementation}}
//---------------------------------------------------------
// TOpenGL_TestWindowView
//...........
// Construction/Destruction handling.
//
#if defined(ENGINERUN)
TOpenGL_TestWindowView::TOpenGL_TestWindowView(TWindow parent,
: TWindow(parent, title)
#else
TOpenGL_TestWindowView::TOpenGL_TestWindowView(TDocumenti doc
: TWindowView(doc, parent)
#endif
Attr.Style 1= (WS_VISIBLE I CS_OWNDC);
Attr.W = 600;
Attr.H = 600;
Attr.X = 0;
Attr.Y = 0;
m_pPalette = NULL;
m hDC = NULL;
}
TOpenGL_TestWindowView::~TOpenGL_TestWindowView()
{
Destroy();
delete m_pPalette;
)
void TOpenGL_TestWindowView::EvClose()
{
#if defined(ENGINERUN)
TWindow::EvClose();
#else
TWindowView::EvClose() ;
#endif
char title)
TWindow* parent)
85

delete myDC;
}
int TOpenGL_TestWindowView::EvCreate(CREATESTRUCT fars createStruct)
{
int result;
#if defined(ENGINERUN)
result = TWindow::EvCreate(createStruct);
#else
createStruct.style |= (WS_CLIPCHILDREN I WS_CLIPSIBLINGS I CS_OWNDC);
result = TWindowView::EvCreate(createStruct);
#endif
// Select pixel format/rendering context
Static PIXELFORMATDESCRIPTOR pfd = {
sizeof(PIXELFORMATDESCRIPTOR) , // Size of this structure
1,
// Version of this structure
PFD_DRAW_TO_WINDOW I // Draw to Window
(not to bitmap)
PFD_SUPPORT_OPENGL | // Support OpenGL
calls in window
PFD_DOOBLEBUFFER, // Double
buffered mode
// PFD_SUPPORT_GDI, // Support for GDI mode
PFD_TYPE_RGBA, // RGBA
Color mode
16,
// Want 16 bit color
0,0,0,0,0,0, // Not used
to select mode
0,0,
// Not used to select mode
0,0,0,0,0, //
Not used to select mode
16,
// Size of depth buffer
0,
// Not used to select mode
0,
// Not used to select mode
PFD_MAIN_PLANE, // Draw in
main plane
0,
// Not used to select mode
0,0,0 };
II Not used to select mode
// Get the device context
m_hDC = ::GetDC(this->GetHandle());
myDC = new TDC(m_hDC);
// Choose a pixel format that best matches that described in pfd
int nPixelFormat = ChoosePixelFormat(m_hDC, &pfd);
// Set the pixel format for the device context
SetPixelFormat(m_hDC, nPixelFormat, spfd);
// Create a 3-3-2 palette
SetupPalette(m_hDC);
86

// Create the rendering context
m_hRC = wglCreateContext(m_hDC);
// Make the rendering context current and perform initializion.
wglMakeCurrent(m_hDC,m_hRC) ;
GLSetupRC(m_hDC);
/* randomized;
for (int i=0; i < 10; i++)
{
xnew[i] = random(400) GRIDRANGE;
ynew[i] = random(400) GRIDRANGE;
xnew2[i] = random(400) GRIDRANGE;
ynew2[i] = random(400) GRIDRANGE;
znewfi] = random(200);
yShift = O.Of;
xShift = O.Of;
MainFontRec.lfHeight = 6;
MainFontRec.lfWidth = 4;
MainFontRec.IfEscapement = 0;
MainFontRec.IfOrientation = 0;
MainFontRec.lfWeight = FW_BOLD;
MainFontRec.IfItalic = 0;
MainFontRec.lfUnderline = 0;
MainFontRec.IfStrikeout = 0;
MainFontRec.lfCharSet = ANSI_CHARSET;
MainFontRec.lfOutPrecision = ODT_DEFAULT_PRECIS;
MainFontRec.lfClipPrecision = CLIP_DEFAOLT_PRECIS;
MainFontRec.lfQuality = PROOF_QOALITY;
MainFontRec.IfPitchAndFamily = VARIABLE_PITCH I FF_ROMAN;
strcpy(MainFontRec.IfFaceName, "Times New Roman");
sfontl = new TFont(SMainFontRec);
MainFontRec.lfHeight = 12;
MainFontRec.lfWidth = 6;
sfont2 = new TFont(SMainFontRec);
V
return result;
)
void TOpenGL_TestWindowView::EvDestroy0
// Free the rendering context
wglMakeCurrent(NULL,NULL);
wglDeleteContext(m_hRC);
// Release the device context
::ReleaseDC(this->GetHandle(),m_hDC);
#if defined(ENGINERUN)
TWindow::EvDestroy();
#else
TWindowView: -.EvDestroy () ;
#endif
)
87

bool TOpenGL_TestWindowView::EvEraseBkgnd(HDC dc)
{
bool result;
return false;
}
void TOpenGL_TestWindowView::EvPaint()
{
// Make the rendering context current, and call OpenGL Rendering code
EngineLock.Lock();
wglMakeCurrent(m_hDC,m_hRC);
// myDC->SelectObject(*sfont2);
GLRenderScene(NULL);
wglMakeCurrent(NULL,m_hRC);
// Finally swap buffers since this rendering context is double buffered
SwapBuffers(m_hDC);
// Do NOT Validate the window
Validate();
EngineLock.Unlock();
)
void TOpenGL_TestWindowView::EvSize(uint sizeType, TSizeS size)
GLsizei w, h;
#if defined(ENGINERUN)
TWindow::EvSize(sizeType, size);
#else
TWindowView::EvSize(sizeType, size);
#endif
w = size.cx;
h = size.cy;
// Make the rendering context current, and call function
// to make adjustments to OpenGL viewport
wglMakeCurrent(m_hDC,m_hRC);
GLResize(w,h);
wglMakeCurrent(m_hDC,NULL);
}
bool TOpenGL_TestWindowView::EvQueryNewPalette()
(
bool result;
II Only if palette was created
if(m_pPalette != NULL)
<
int nRet;
// Select the palette into the current device context
if(SelectPalette(m_hDC, m_pPalette->GetHandle(),FALSE) == NULL)
::MessageBox(NULL,"Cannot select Palette","Error,MB_OK)
// Map entries from the currently selected palette to
// the system palette. The return value is the number
88

// of palette entries modified.
nRet = RealizePalette(m_hDC);
// Repaint, forces remap of palette in current window
Invalidate();
return nRet;
}
// Call default function
result = TWindow::EvQueryNewPalette();
return result;
void TOpenGL_TestWindowView::EvPaletteChanged(THandle hWndPalChg)
{
// Only if palette created, or not this window
if((m_pPalette != NOLL) && (hWndPalChg != this->HWindow))
{
// Select the palette into the device context
::SelectPalette(m_hDC,m_pPalette->GetHandle(),FALSE);
// Map entries to system palette
::RealizePalette(m_hDC);
// Remap the current colors to the newly realized palette
::UpdateColors(m_hDC);
return;
}
// Call default handler
TWindow::EvPaletteChanged(hWndPalChg);
}
void TOpenGL_TestWindowView::EvTimer(uint timerld)
{
#if defined(ENGINERUN)
TWindow::EvTimer(timerld);
#else
TWindowView::EvTimer(timerld);
#endif
)
// Create the palette if necessary
void TOpenGL_TestWindowView::SetupPalette(HDC hDC)
{
PIXELFORMATDESCRIPTOR pfd;
LOGPALETTE *pPal;
int nPixelFormat;
int nColors;
int i ;
// Pixel Format Descriptor
// Pointer to memory for logical palette
// Pixel format index
// Number of entries in palette
// Counting variable
BYTE RedRange,GreenRange,BlueRange; II Range for each color entrys
// (7,7,and 3)
II Get the pixel format index and retrieve the pixel format description
nPixelFormat = GetPixelFormat(hDC) ;
DescribePixelFormat(hDC, nPixelFormat,
sizeof(PIXELFORMATDESCRIPTOR), ipfd);
// Does this pixel format require a palette? If not, do not create a
// palette and just return
89

if(!(pfd.dwFlags & PFD_NEED_PALETTE))
return;
// Number of entries in palette. 8 bits yeilds 256 entries
nColors = 1 pfd.cColorBits;
// Allocate space for a logical palette structure plus all the
// palette entries
pPal = (LOGPALETTE*)malloc(sizeof(LOGPALETTE)
+nColors*sizeof(PALETTEENTRY));
pPal->palVersion = 0x300; // Windows 3.0
pPal->palNumEntries = nColors; // table size
// Build mask of all l's. This creates a number represented by having
// the low order x bits set, where x = pfd.cRedBits, pfd.cGreenBits, and
// pfd.cBlueBits. '
RedRange = (1 pfd.cRedBits) -1;
GreenRange = (1 pfd.cGreenBits) 1;
BlueRange = (1 pfd.cBlueBits) -1;
// Loop through all the palette entries
for(i =0; i < nColors; i++)
{
// Fill in the 8-bit equivalents for each component
pPal->palPalEntry[i].peRed = (i pfd.cRedShift) & RedRange;
pPal->palPalEntry[i].peRed = (unsigned char)(
(double) pPal->palPalEntry[i].peRed 255.0 / RedRange);
pPal->palPalEntry[i].peGreen = (i pfd.cGreenShift)
pPal->palPalEntry[i].peGreen = (unsigned char)(
(double)pPal->palPalEntry[i].peGreen 255.0 /
&
GreenRange
GreenRange);
pPal->palPalEntry[i].peBlue = (i pfd.cBlueShift) & BlueRange;
pPal->palPalEntry[i].peBlue = (unsigned char)(
(double)pPal->palPalEntry[i].peBlue 255.0 / BlueRange);
pPal->palPalEntry[i].peFlags = (unsigned char) NULL;
// Create the palette
m_pPalette = new TPalette(pPal);
// Go ahead and select and realize the palette for this device context
if(SelectPalette(hDC,m_pPalette->GetHandle(),FALSE) == NULL)
::MessageBox(NULL,"Cannot select Palette in Palette Creation",
"Error",MB OK);
if(RealizePalette(hDC) == NULL)
;:MessageBox(NULL,"Cannot realize Palette in Palette Creation",
"Error",MB OK);
// Free the memory used for the logical palette structure
free(pPal);
void GLSetupRC(void *pData)
{
GLfloat
GLfloat
GLfloat
GLfloat
GLfloat
ambientLight[] = {0.4f, 0.4f, 0.4f, l.Of };
diffuseLight[] = {0.7f, 0.7f, 0.7f, l.Of };
specular[] = { 0.9f, 0.9f, 0.9f, l.Of);
lightPos[] = { -50.Of, 200.Of, 200.Of, l.Of };
specref[] = { 0.6f, 0.6f, 0.6f, l.Of };
90

Full Text

PAGE 1

DYNAMIC SCHEDULING OF DETERMINISTIC ROUTES FOR OBJECTS MOVING IN THREE DIMENSIONAL SPACE by Bret Allen Godwin B.S., University of Colorado at Denver, 1987 A thesis submitted to the University of Colorado at Denver in partial fulfillment of the requirements for the degree of Master of Science Computer Science

PAGE 2

This thesis for the Master of Science degree by Bret A. Godwin has been approved by / Chris Smith Date 1/ /1]/91 r 1

PAGE 3

Godwin, Bret A. (MS, Computer Science, Engineering) Dynamic Scheduling ofDeterministic Routes for Objects Moving in Three Dimensional Space Thesis directed by Associate Professor William J. Wolfe ABSTRACT The purpose ofthis research is to evaluate whether deterministic dynamically scheduled fixed routes in three dimensional space will support high traffic volwnes while providing adequate throughput to minimize delays and improve travel times in congested areas. To accomplish this task, the author presents a scheduling algorithm that will be used by an automated route scheduling and vehicle management system. The algorithm includes a time dependent windowing scheme that optimizes route management while reducing queuing delays. A software simulator is developed to simulate vehicle traffic traveling in three-dimensional space. The results of simulation scenarios indicate that the premise of deterministic routing for three dimensional traffic is possible with average queuing delays of less than 30 minutes. This abstract accurately represents the content ofthe candidate's thesis. I recommend its publication. 111

PAGE 4

DEDICATION For Diane, Jeffrey, and Mark. Thanks for being so patient and for all of the support. I know it was a long arduous process, but in the end it was worth it. I also want to thank Mom and Dad for all of their continued support throughout my years of education. I love you all.

PAGE 5

CONTENTS CHAPTER 1 INTRODUCTION ............................................................................... 1 Problem Description ............................................................................................... 5 Problem Formulation .............................................................................................. 7 Strategy ................................................................................................................. 8 Notation ................................................................................................................ 9 Thesis Organization ............................................................................................. 1 0 CHAPTER 2 A DETERMINISTIC APPROACH .................................................... 11 Concept ............................................................................................................... 11 CHAPTER 3 THEORETICAL ANALYSIS ............................................................ 15 Network Technology Similarities ......................................................................... 15 Local Area Network Access Characteristics ..................................................... 15 Network Routing and Switching Queuing Analysis ........................................... 18 Erlang Blocking Probability .................................................................................. 19 Queueing Theory ................................................................................................. 21 CHAPTER 4 SOLUTION ANALYSIS ................................................................... 26 Non-windowed Routing ....................................................................................... 26 The Scheduled Chronoscube ................................................................................ 28 NonWindowed Routing example: ....................................................................... 31 Scheduled Chronoscube Routing example: ........................................................... 32 Advantages ofthe scheduled chronoscube ............................................................ 34 Pre-Scheduling ..................................................................................................... 34 Automated Architecture ....................................................................................... 3 5 v

PAGE 6

Vehicle Requirements ....................................................................................... 35 Control Requirements ....................................................................................... 35 Three Dimensional Space ..................................................................................... 3 8 Routes ................................................................................................................. 39 CHAPTER 5 SIMULATION ARCIDTECTURE .................................................... 40 Simulation Engine Object ..................................................................................... 40 RouteMasterComputer Object .............................................................................. 41 .Vehicle Object .................................................................................................... 43 Grid Object .......................................................................................................... 4 7 Graphical User Interface Object ........................................................................... 48 Vehicle Movement Formulas ................................................................................ 49 Simulation Hardware ........................................................................................... 50 Simulator Constraints ........................................................................................... 50 CHAPTER 6 SIMULATION RESULTS ................................................................. 51 Simulation Scenarios ............................................................................................ 53 High Volume Simulation Configuration ................................................................ 53 High Volume Simulation Results .......................................................................... 54 Heavy Congestion Simulation Configuration ........................................................ 56 Heavy Congestion Simulation Results .................................................................. 57 Heavy Congestion with Small Time Window Simulation Configuration ................ 59 Heavy Congestion with Small Time Window Simulation Results .......................... 60 Medium Congestion Simulation Configuration ..................................................... 61 Medium Congestion Simulation Results ............................................................... 62 Light Traffic Simulation Configuration ................................................................. 63 Light Traffic Simulation Results ........................................................................... 64 Pre-Schedule Simulation Configuration ................................................................ 66 VI

PAGE 7

Pre-scheduling Simulation Results ........................................................................ 67 Optimization Analysis .......................................................................................... 69 CHAPTER 7 CONCLUSION .................................................................................. 71 APPENDIX A SIMULATOR OPERATION GUIDE ............................................. 75 APPENDIX B CODE LISTINGS ............................................................................ 82 APPENDIX C SIMULATION 3D GRAPHICAL OUTPUT ................................. 201 REFERENCES ...................................................................................................... 205 Vll

PAGE 8

TABLES Table Table 3-1: Erlang blocking probabilities for arrival rate of 28 vehicles/sec and average holding time of 476 seconds ............................................................................................................ 20 Table 3-2: Calculated Queuing Delay parameters ..................................................... 24 Table 6-1: Simulation Parameters for High Volume Configuration ................................................................................................... 54 Table 6-2: High Volume Simulation Results ............................................................. 56 Table 6-3: Simulation Parameters for Heavy Congestion Configuration ................................................................................................... 57 Table 6-4: Heavy Congestion Simulation Results ..................................................... 58 Table 6-5: Simulation Parameters for High Congestion with Short Time Window Configuration ................................................................... 59 Table 6-6: Simulation Parameters for Medium Congestion ....................................... 61 Table 6-7: Medium Congestion Results .................................................................... 63 Table 6-8: Simulation Parameters for Light Traffic ................................................... 63 Table 6-9: Calculated vs. Simulated Queuing Values for Light T ra:ffic ..................................................................................................... 64 Table 6-1 0 :Output Results for Light Load Simulation ............................................. 66 Table 6-11: Simulation Parameters for Pre-scheduling .............................................. 67 Table 6-12: Pre-Schedule Congestion Results .......................................................... 67 Vlll

PAGE 9

FIGURES Figure Figure 1-1: A pictoral view ofthe deterirninistic solution for 3D vehicle travel ................................................................................................ 4 Figure 2-1: Dynamic routing diagram illustrating the routes on each level ofthe 3D Grid ............................................................................. 13 Figure 3-1: Ethernet vs. Token Ring LAN delay characteristics relative to loading capacity ........................................................ 18 Figure 3-2: Queuing Theory Notation ...................................................................... 22 Figure 3-3: Basic Queuing Theory Equations for MIM/1 queues .............................................................................................................. 23 Figure 4-1: Illustration of a chronoscube .................................................................. 30 Figure 4-2: Initial Routing Approach example illustration ......................................... 31 Figure 4-3: Improved Routing Approach Example Illustration ........................................................................................................ 33 Figure 4-4: The architecture ofthe centralized computer system .............................................................................................................. 37 Figure 4-5: Functional subdivision ofthe three dimensional space by altitude ............................................................................................... 38 Figure 4-6: Vehicle Route Ilustration using Chronoscubes ........................................ 39 Figure 5-l: Simulation Architecture illustrating the object layout and object connections ........................................................................... 42 Figure 5-2: Flowchart illustrating the level determination phase of the route allocation process ............................................................... .44 Figure 5-3: Flowchart illustrating the route selection IX

PAGE 10

algorithm that assigns chronoscubes to routes .................................................. .45 Figure 5-4: Flow charts illustrating the main simulation and vehicle movement algorithms ............................................................................ 46 Figure 5-5: Illustration ofthe chronoscube sparse matrix with the cell contents for a chronoscube ........................................................... 48 Figure 6-1 : Simulator Main Window depicting the Denver Metropolitan area ............................................................................................. 52 Figure 6-2: Queuing Graph for the High Volume Configuration ................................................................................................... 55 Figure 6-3: Queuing Analysis under heavy loading conditions ......................................................................................................... 58 Figure 6-4: Queueing and Wait Times for Heavy Congestion with Small Window Size ................................................................ 60 Figure 6-5: Heavy Congestion Simulation with Short Time Window Results ............................................................................................... 61 Figure 6-6: Graph Illustrating the Queuing Delay for the model under medium congestion ....................................................................... 62 Figure 6-7: Chart Illustrating Queuing and Wait Times for Light Congestion .............................................................................................. 65 Figure 6-8: Chart Illustrating Queuing and Wait Times for Pre-Scheduling ................................................................................................. 68 Figure 6-9 : Comparison of Simulation Configuration Results ............................................................................................................. 69 X

PAGE 11

CHAPTER 1 INTRODUCTION As traffic congestion continues to grow at an alanning pace in the late 20th century, many transportation forecasts predict that by the early 21st century road congestion will be so severe that travel will be very time consuming in most major urban areas 1 To counteract these claims of impending gridlock, many scientists and aeronautical engineers have started to evaluate alternatives to our present two dimensional method oftravel. Many are pursuing new designs for transportation technologies of the future. Some ofthese new alternatives take advantage ofthreedimensional space where terrain features and buildings no longer inhibit travel and create congestion points. A few forward thinking individuals are presently evaluating technologies that are considered by many as too futuristic to be attainable in the near future. However, some scientists and engineers believe that we are very close to having flying vehicles that will enable three-dimensional travel. The primary difficulties today are technology limitations that prohibit safe and economical vehicular flight. The following excerpt from an interview with Steven portrays the difficulties with flying vehicles today: "The reason most of us pilot vehicles that only leave the asphalt when jumping potholes, is that small planes-whether or not they convert into cars-are too 1 Vehicle use and population density has increased by 50% and 15% respectively, from 1975 to 1990[5]. 2 Steven Crow is an aeronautical engineer at the University of Arizona who is currently designing future flying vehicles with students at the University[?]. 1

PAGE 12

expensive and too hard to fly. Plan on \$150,000 for your bare bones cramped four-passenger plane. Add \$3,500 and 60 hours' worth of white-knuckled tutoring to get your pilot's license. And don't forget to factor in thousands of dollars worth of annual mechanical maintenance and other costs, and countless hours to plot flight paths. Throw in a third dimension, aerodynamics, rotations, gyroscopic phenomena and you've got a situation the human mind just doesn't deal well with." So, with this in mind, new technologies will be needed that overcome these obstacles before mass transportation in three-dimensional space is a pragmatic endeavor. As transportation has evolved, technology has enabled us to increase speeds and safety in addition to comfort, and style3 These benefits have created more demand for individual transportation and freedom of movement. This need for independence has created an abundance of single driver vehicles for a two-dimensional road network that is already unable to support peak utilization. As population densities increase, there will be no choice but to eventually change to another form of transportation. The two alternatives are: increased utilization of mass transit, or to pursue three-dimensional travel. One of the constraints associated with transportation today is the fact that most transportation occurs in a 2-dimenstional domain. Although we have airplanes, helicopters, and other air transportation technologies for 3-dimensional travel, these vehicles are usually limited in use due to economic and technical constraints. Airplanes today usually only transport people and freight to other locations across long distances; while helicopters are only used in rare situations for short distances. Neither of these technologies provides safe and cost effective travel for the masses. In order to reap the benefits associated with 3-dimensional travel, new vehicular technologies will need to be developed to provide all modes of transportation from single person vehicles to large sized transports. Once these flying 3 Scientific American, September 1997 2

PAGE 13

vehicles are developed new rules and regulations will need to be created to support the new "sky-ways" of the future. Presently, air traffic control centers manage the sky-ways primarily for commercial aircraft, but they only manage several hundred vehicles at a time. When three-dimensional transportation for the masses becomes generally available, sophisticated automated systems will be required to insure that travel is safe and effective. These new automated systems will need to be fast, efficient, and require significant system redundancy to manage the high volumes of traffic. Three-dimensional travel will enable travel directly to a destination point without having to steer around obstacles .. In an unrestricted space, vehicles will be able to travel directly to their destination without having to travel along predefined corridors (today's roads). This will enable an individual to travel from home directly to the store or office without having to stop at stoplights or wait in traffic jams. Vehicles will no longer be bound by the constraints imposed by two-dimensional terrain. Transit speeds will likely increase by as much as 2-4 times over present day ground transportation4 These direct routes and increased speeds should reduce traffic congestion by reducing the amount of time a vehicle is in transit from origin to destination. Three-dimensional travel will create many new challenges. Millions of vehicles moving unrestricted in an open space will increase the probability for collisions, congestion, and visual pollution in proportion to the number of vehicles and the amount of open space available. Therefore, traffic management in a 3-dimensional world will be more critical than it is in our present 2-dimensional environment. 4 Helicopters and small planes presently travel at speeds 2 -4 times faster than automobiles[?]. 3

PAGE 14

This thesis focuses on one possible solution to an automated traffic management system. Figure 1-1 illustrates the basic premise that will be described. Request is made for a route to a destination Vehicle begins moving while communicating with the Master Computer continuously Master Computer updates the route database to reflect Route Master Computer Request is queued and route is returned when is available Route Master Canputer Transponder sends vehicle position to the Master Computer 1 Figure 1-1: A pictoral view of tbe deteriministic solution for 3D vehicle travel 4

PAGE 15

and analyzed in the following chapters. The illustration portrays a vehicle requesting a route and the activity that takes place during movement once a route is defined. Problem Description To address three-dimensional travel, new automated control systems and algorithms will need to be developed to manage flying vehicles in congested areas. These new traffic management systems may resemble present day air traffic control systems or more sophisticated automated systems. The algorithms may be simple routing based mechanisms that route traffic down 3-dimensional corridors, or more sophisticated scheduling systems that guarantee routing based on destination, congestion level, priority, and expected travel time. Since there are many aspects to 3-dimensional travel, the focus is constrained to the following issues: Given a condensed 3-dimensional airspace, what type of algorithm would enable 3-dimensional travel without collisions, reduce visual air pollution (vehicles hovering in the air), provide travel flexibility, reduce time to destination, and minimize congestion? If altitude height is constrained, how does this impact travel times and queuing delay? How does traffic volume affect delay? What is the most efficient method oftravel from origin to destination? 5

PAGE 16

Is it feasible to schedule vehicle traffic to a pre-detennined path before the vehicle leaves the ground and have that vehicle travel that path? How can the number of vehicles in the air be minimized? Using the above questions as guidelines, the following requirements further refine the problem domain: 1. The' problem domain is restricted to high-density metropolitan areas. 2. Air space is segmented into a three dimensional grid with vertical levels starting above a minimum height that is restricted to local traffic. 3. Vehicle density is high during travel periods associated with this study. 4. Vehicles may not make mid-air changes in direction 5. Vehicles may travel in any direction horizontally and vertically. 6. Vehicles may travel up to 200 Miles Per Hour (MPH) horizontally, and 60 MPH vertically. 7. Vehicles have a constant acceleration of 88 feet/sec2 8. Vehicles have a constant deceleration of 60 feet/sec2 9. Vehicles contain a global positioning system and transponder that identifies where they are at all times. 10. Vehicles may not cross paths ifthe projected vehicle movement will place the vehicles in within 100 ft of each other within a 5-second interval. 11. Vehicles must wait for a route to be defined before they may move. 12. Vehicle routes are confined to a single level of altitude for horizontal travel. 13. When a vehicle requests a route, queuing time must be minimized 14. Vehicles traveling shorter distances should travel at lower altitudes to minimize travel time. 6

PAGE 17

15. Congestion must be minimized so that large numbers ofvehicles are not grouped together during transit. Problem Formulation There are many potential solutions that will address the problem of managing vehicular travel in three dimensions. Steve Crow from the University of Arizona has the following perspective: "Complete self piloting would be possible only ifthe national air traffic control system switched from the current centralized, ground based approach to a distributed one in which planes broadcast their locations to other planes, and onboard computers figured out how to keep them away from each other." Self piloting will only work in low congestion areas. The Federal Aviation Administration (FAA) has adopted this approach in their new Free Flight rules for aircraft separation. Unfortunately, this approach breaks down in highly congested traffic areas because the number of real-time variables increases exponentially with the number of vehicles and the air space density. The FAA has also acknowledged this in their Free Flight rules which indicate that air traffic controllers will direct traffic in high congestion areas[8]. To better understand the rationale ofthis approach, the following items should be considered: In three-dimensional space no physical barriers exist to restrict movement in any direction, both horizontally and vertically. Congestion will occur in areas where high concentrations of vehicles originate or terminate. In congested areas, if vehicles are moving at random, vehicles will be required to wait (hover) until other vehicles move out ofthe way. 7

PAGE 18

Congestion will increase the number of vehicles in the air which may lead to complaints related to having too many floating vehicles in the air which block peoples view. This phenomena could be referred to as "vehicle clouds". A significant amount of energy may be utilized by a vehicle waiting in 3D space for a path to it's destination. The above concerns, require a more rigid system that to manage congested environments. To reduce congestion, deterministic methods must be used to manage traffic. To accomplish a deterministic method for three-dimensional travel, one might create a centralized manager that dictates how and when vehicles will move. This central controller will assign predefined paths based upon the vehicles destination coordinates at a prescribed instant in time. Another approach might be to create a highly distributed system that manages sectors within a grid. Strategy In order answer the questions posed in the prior section, existing transportation methodologies that had similar characteristics were evaluated. The primary systems in use today are the two dimensional road system and the highly successful 3-dimensional air traffic control system. Since the existing road system gains much of it's inherent queuing and inefficiencies from geographic boundary constraints and the random nature of automobile traffic, this model was not adequate in many respects. The air traffic control system on the other hand seemed to be much more similar due to the automated systems already used today. The difficulty with the existing air traffic control methodology is that it uses congestion corridors and in flight queueing. This approach creates visual pollution (from the airplanes waiting and 8

PAGE 19

circling) and is inherently inefficient. The other main difference with today's air traffic control system is that it manages traffic that has characteristically long travel times and due to the long travel distances can have random arrival times. Other areas having similar queuing characteristics are telephone and data networks that have similar route allocation and queuing issues. Telephone networking equations for network trunking were analyzed along with algorithms for router based networks. After reviewing numerous materials, it became obvious that existing solutions were not adequate to describe a mathematical approach. With this in mind, the next step was to develop a simulation of the proposed algorithm to determine ifthe initial hypothesis could be supported. Since vehicles that meet the requirements ofthe problem domain do not exist in 1997, a simulation ofthe solution paradigm is required. A computer model was developed to provide this simulation. The results were evaluated and compared against initial assumptions for validation. Notation Conventions used throughout this document are as follows: Vectors: Matrices: Scalars: Bold lower case letters denote a vector ( eg., x or y). A subscript associated with a vector letter, in plain type, represents an element of that vector (e.g., ai is the ith element of a). Bold, uppercase letters represent matrices (e.g., G or P). A pair of subscripts on a matrix name, in plain type, identifies an element ofthat matrix (e.g., M,1 is the element in the ith row,fh column ofM. Upper and lowercase letters, in plain type, denote a scalar. 9

PAGE 20

Variables: Upper and lowercase letters, in italic type, denote a constant. Thesis Organization The organization of this thesis is as follows. Chapter 2 defines a deterministic approach for solving congestion of moving vehicles in three-dimesnional space. Chapter 3 examines similarities to other technologies and some blocking and queuing theory to assist with the definition of the model. Chapter 4 describes the routing algorithm and describes how the central controller assigns and manages routes .. Chapter 5 then proceeds with a discussion of the simulation architecture and Chapter 6 presents the simulation results. Finally, Chapter 7 summarizes the thesis and identifies additional research topics and other fields of study that may benefit from this solution. 10

PAGE 21

CHAPTER2 A DETERMINISTIC APPROACH Many researchers believe that finding a deterministic approach to solving a problem is the best way to manage the problem repeatedly with similar results5 This methodology is not always the most efficient or the most cost effective, but it does provide predictable results. Predictability is the key to managing congestion. Managing traffic congestion in a high-density area requires the development of an algorithm that is deterministic and provides predictable behavior. Thus, using a fixed route algorithm that forces vehicles to wait for a route (queuing) provides an effective deterministic model to minimize traffic congestion in 3-dimensional space. Figure 2-1 provides an illustration of how routes are allocated in space. Concept The problem domain defined by this thesis focuses on high traffic congestion in relativley small geographic areas (50 square miles) with fixed flight paths and predetermined arrival times. Congestion needs to be avoided and low delay is desired. Any vehicle that wishes to move from an origin to a destination location in a 3dimensional grid must first request a route from an origin location to a destination. Once the route has been defined, the vehicle may move unimpeded and at full speed until the destination location has been reached. The following isssues need to be considered when investigating route selection: 5 Warren Powell at Princeton University uses deterministic models extensively in Operations Research for transportation optimization problems[19]. 11

PAGE 22

A route may not intersect another route if two or more vehicles will occupy the same space in time. Routes should be direct to minimize travel time. Shorter routes should be assigned to lower altitudes to reduce travel time. The number of vehicles in the air at any one time should be minimized. Routes assigned at higher levels will block route selection along the vertical path as searches are made sequentially upward. High density destinations will restrict the number of route terminations for the vertical down path. The amount of time a vehicle waits to have a route assigned should be minimized. 12

PAGE 23

Leveln Level n-1 Level2 Levell LevelO Figure 2-1: Dynamic routing diagram illustrating the routes on each level of the 3D Grid. Several additional issues should be considered: What happens if a vehicle wants to change routes during flight? or, How are routes allocated if a direct route is not available? 13

PAGE 24

The solutions to these questions are not easy to solve because there are many variables that need to be considered. For example, if a route is blocked, does the vehicle wait, or does it try to find the shortest route around the obstacle. The problem with finding the shortest route is that it might take longer to travel the shortest available route than to sit and wait. This phenomena is experienced by many travelers who leave freeways to detour around an accident, only to find that the detour takes longer to traverse than staying in the original traffic jam. The issue of course change during a movement has profound implications on the master control computer and the algorithm that is used to implement the fixed routing scheme. The difficulty in changing a vehicle's path during movement is that all vehicles in transit who's route intersects with that particular vehicle must be considered at the same time. The reason for this is due to the nature of scheduled routes. If a route is scheduled based on time, then a vehicle is expected to move through each grid location during the scheduled time interval. All other vehicular traffic that is moving across that vehicle's path are dependent on where it is at a specific instant in time. Therefore, if a vehicle needs to change direction, then all related vehicles will have to come to a stop and new routes will need to be generated for those vehicles that are impacted. Depending on the number of vehicles that cross the path, this could be a trivial or very complex endeavor. The real problem is when a cascading effect takes place that effects all vehicles in the system. The path change of one vehicle could cause significant blocking to occur for vehicles in the air which will cause floating objects that will have to be given priority during the scheduling process. There-configuration effort of the system could potentially create large delays in the system depending on the amount of congestion and cascading effects. 14

PAGE 25

CHAPTER3 THEORETICAL ANALYSIS Deterministic routing of objects in congested three-dimensional space is somewhat unique at this point in time. There is no other known research that address this material. Therefore, other areas of research that provide metaphorical solutions were used as the basis for the theoretical research and foundation for the solution derived. Network Technology Similarities Areas of research similar to this problem domain are voice and data networking. The study of queuing and routing is prevalent in both areas. Both telephony and data communications technologies encounter a different type of offered traffic load and each uses a unique method to manage the traffic. After studying solutions to traffic congestion in telephony and data networking, a hybrid system based on both areas was used to deterministically route vehicles. From telephony the concept of multiple channels was incorporated to improve throughput by adding additional levels to increase the number of available routes[2]. Data communications provided the concept of time slots that are used by cell based protocols such as Asynchronous Transport Mode (ATM)[15]. The theoretical aspects ofthese areas is used as the foundation for developing the models for the assignment of the three-dimensional routes. Local Area Network Access Characteristics The approach used for managing deterministic routes has many similarities to the study of access delay characteristics found in Local Area Networks and queuing delays in network routers and packet switches. In networking, the physical medium 15

PAGE 26

PAGE 27

PAGE 28

10% 20% 30% 40% 50'% 60% 70"/o 80% 90% L011dillg Percentage Figure 3-1: Ethernet vs. Token Ring LAN delay characteristics relative to loading capacity. Network Routing and Switching Queuing Analysis In order to create fixed routes in space that do not overlap, some routes will not be available when requested. Therefore, vehicles will be required to queue and wait until a route is available. Queuing is an undesirable side effect ofthe proposed deterministic routes, so the goal of the solution is to minimize it. One source of queuing research is data networking routing and switching. These technologies employ sophisticated algorithms to reduce packet and cell queuing. Before examining a queuing model, the probability functions for availability are needed, along with several definitions as follows: C Is defined as the chronoscube; which is a 3-dimensional cubic area of space that is reserved for a specified time interval t -E s t s t + E; where E is a constant. A more precise definition is located in Chapter 4. 18

PAGE 29

G Is a 3-dimensional matrix that contains vertices that represent a comer of a chronoscube in 3-dimensional space. k Constant identifying the nwnber oflevels (z axis increments) in the grid G. p A vector of chronoscube from 1 ... n that represent a path from an origin vertices to a destination vertices in G p probability that a path is blocked q probability that a path is open; q = 1 p p' probability that a chronoscube is unavailable q' probability that a chronoscube is available; q' = 1-p' n nwnber of chronoscubes in a path P Probability that k independent paths (one on each level of G) of chronoscube p are blocked; P = l B Probability that one of the chronoscube in p will be blocked, which can be represented as 1 minus the probability that all cubes in a path are available; B = 1 -q'n, D Probability that a chronos-cube is busy. Erlang Blocking Probability In 1909, the Danish mathematician A. K. Erlang developed and published a book called The Theory of Probabilities ofTelephone Conversations[11]. This and follow on research characterized telephone systems as one of the following: Poisson input, exponential service times, and multiple channels Poisson input, constant holding times, and a single channel. 19

PAGE 30

Through his research, Erlang developed several important formulas that are used extensively by the telecommunications industry to engineer and manage telecommunications networks throughout the world. Erlang's work enables engineers to determine the average amount of traffic that can be present on a set of trunks before blocking occurs, or to determine the amount of utilization of a channel given a blocking probability. His formula for the blocking probability for a lost calls cleared system with Poisson arrivals is known as the Erlang B formula and is presented below: (3.1) Where N is the number of servers and A is the traffic intensity. A is defined as the average arrival rate multiplied by the average holding time with units of erlang. One erlang is equivalent to 3600 seconds. After running several simulations, the average average holding time can be observed and this formula can be used to calculate the blocking probability for several loading conditions as listed in Table 3-1. Traffic Intensity Senrers Blocking Probability B 3.7 erlangs 2 .59 3.7 erlangs 4 .28 3.7 erlangs 10 .004 3.7 erlangs 20 8.69 X 10"09 Table 3-1: Erlang blocking probabilities for arrival rate of 28 vehicles/sec and average holding time of 476 seconds. 20

PAGE 31

The calculated data in Table 3-1 implies that with an ingress rate of28 vehicles per second, over the period of an hour, a model with more than 10 levels will experience a very low probability of blocking. However, what it does not indicate is the amount ofblocking a vehicle will experience at any given instant in time. This data is misleading in that it doesn't take into account the fact that the blocking probability for the routing model is not only dependent on the average time a vehicle is in transit, but also is dependent on the number of other vehicles that are present in the system. It is a good approximation though. Queueing Theory Queueing theory describes the process by which queuing systems are analyzed. There are six basic characteristics of queuing processes that are listed below Arrival pattern of customers Service pattern of customers Queue discipline System capacity Number of service channels Number of service stages In 1953 D.G. Kendal created a shorthand notation to describe these attributes. This notation has been extended over the years and is now represented in Figure 3-2. Using this notation, the following queuing definition approximates the route scheduling queuing analysis[ I I]. 2I

PAGE 32

M I M I 1 I FIFO I oo I oo The arrival pattern defines the number of arrivals per unit of time. For the route scheduling problem, this parameter was developed based on a busy hour traffic density of I 00,000 vehicles per hour, which translates to 28 requests per second6 The arrival pattern is defined by the variable A.. The service time 1..1. is characterized by how quickly the central controller can allocate routes and how long it takes for a route to become available. The arrival and service time can be characterized as Poisson distributions. a lb Is lw /p /c Figure 3-2: Queuing Theory Notation Source Population 1,2,3 ... 00 Capacity 1.2.3 ... 00 Queue Type (FIFO.LIFO, SIRO) Parallel Servers 1,2,3 ... 00 Service Time M =Poisson D =Deterministic Arrival Distribution M =Poisson n = Tktf'rmini<:tir. 6 The number 100,000 requests per hour was derived from travel forecast demand algorithms in [5] using an average ofthe top 10 metropolitan population densities. 22

PAGE 33

The number of servers is a function of the number oflevels in the grid that are available for routes. The input queue is FIFO and the capacity of the system is limited by the number of routes that can be assigned at any given instance in time. The source population is the maximum number of vehicles than will request a route at a given instant in time. Queuing theory only works well for very simple problems, many problems are better solved using simulation. However, the theory can be used to determine if initial assumptions are accurate. The following formulas are from [II] for a single server queue with a single input line. The variables are identified as Ls -number of expected vehicles in the system Lq -number of expected vehicles in queue Ws-expected wait time in system (queue+ servicing) Wq-expected wait time in queue. Pn probability of n vehicles in the system p=% Pn =(I-P)Pn L =_p_ s I-p p2 L=q I-p 1 = .u{l-p) w-P q,u{lp) Figure 3-3: Basic Queuing Theory Equations for M/M/1 queues. 23

PAGE 34

Using an arrival rate of28 vehicles per second and a service time of30 per second, Table 3-2 lists the values predicted. Queue Attributes Values Calculated p .933 Ls 1400 Lq 1300 Ws 50 sec Wq 46sec Table 3-2: Calculated Queuing Delay parameters These are the expected results for the steady state condition. The difficulty with these formulas is that they do not take into account the complexity associated with route availability. For example, the master computer has a service rate of 30 requests per second. Therefore, it can service 30 vehicles every second. The queuing algorithm used is First In First Out (FIFO). As each vehicle is scanned in the queue, the master computer checks to see if a route is available. If a route is available, the vehicle is removed from the queue and it begins moving. If a route is not available, then the vehicle remains in queue on the ground until a route opens up. The fact that the computer can process 30 requests per second does not mean that it is actually servicing 30 requests. The computer has the capability to process that many requests. Under normal loading, the queuing formulas work well to predict average delays and queue sizes. However, when route congestion occurs, the formulas do not represent the variation in service times. An equation that addresses variable service times from [16] could be used ifthe average variable service times could be accurately 24

PAGE 35

defined. The difficulty is that there are too many transient conditions at any instant in time to accurately describe the average variable service time. One of the main transient conditions is the assignment of routes to a vehicle in queue. As indicated earlier, if a vehicle is not selected from the queue, then it remains in queue until a route is available. The master computer will inspect each vehicle in the queue up to the maximum service rate. Any vehicle for which a route is found will be removed from the queue. This process may create a situation where the first vehicle in queue never leaves because it is being blocked my new vehicles entering the queue. This situation is difficult to avoid because in order to avert it, only one vehicle may be processed at a time. Ifthis were the case, then all vehicles would be blocked for a period equal to their position in the queue plus the amount of time needed to find an available route. Instead, the master computer processes the first n vehicles in the queue with n being equal to the service rate. If the service rate is equal to the arrival rate, and all vehicles are blocked, then all other vehicles will have to wait until one of the vehicles is assigned a route. The outcome of this is to simulate the results which is what is recommended by most queuing theory and operations research books[21]. 25

PAGE 36

CHAPTER4 SOLUTION ANALYSIS Non-windowed Routing The main premise behind deterministic routing of vehicles in three dimensions is that fixed routes are required. As discussed above, the rationale behind this premise is based on similarities to other fields of study that indicate that random traffic will eventually lead to congestion when high volume loads are offered. The deterministic solution does not alleviate congestion, but merely manages it a uniform manner. Instead of congestion in transit, the approach presented here pursues a queuing based architecture that prevents vehicles from moving until a guaranteed path is available. This approach is more reasonable in a three-dimensional environment compared to today's road system is because of the unrestricted nature ofthreedemensional space. In today's two-dimensional world, traffic intersections and geographic obstacles represent a myriad of congestion points that would be difficult to schedule available paths for. Thus the rationale for adding the third dimension. The first approach to solving the routing problem was simplistic. A three dimensional grid of rectangular hexahedrons was contrived and each was assigned a vertex (x, y, 8) in 3D space. The x andy coordinates represent the horizontal vertex pair, and 8 represents the z coordinate or more specifically the vertical level. The horizontal pairs are equidistant from the next coordinate pair and the distance is a constant magnitude that forms the top and bottom of the hexahedron. The parameter 8 is also a fixed value that is equidistant from the next 8 vertex value. The horizontal and vertical distances may be different in magnitude. The formal definition of the grid and coordinates is as follows: 26

PAGE 37

G is a grid of rectangular hexahedrons with coordinates x, y, and 8; where x,y = ai; where ai = ai_,+c for i = l ... n where ao = O,n 1000, c 1000. 8 =b ; where bi = b,.,+d fori = I ... n where bo = 0, n 20, d 500 H is a hexahedron in G. H is defined as follows: H = I when it is reserved as part of a route path. H = I only during the time it takes a vehicle to arrive at and traverse through it. H = 0 when it is not part of a route path. r is a vector of adjacent chronoscubes both vertically and horizontally in G that represents a route that a vehicle will traverse in order to travel from origin to destination. ri represents a hexahedron in r where i = I .. n with n <= number of hexahedrons between the origin vertex and destination vertex. This first approach to routing was to generate fixed routes from an origin vertex to a destination vertex in G that was relatively insensitive to time intervals in each hexahedron. This route identified as r above, occupied a string of adjacent grid hexahedrons for a time period equal to the time required for the vehicle to travel from the origin vertex through each H in r. This timeframe is short for ri close to the origin, but increases as i approaches n where n is the length ofr. 27

PAGE 38

Under this approach, as a vehicle traverses a route-when it moves from r; to r;+ 1 -r, is released and made available for other routes. Since each route may exist on a separate plane in G, the initial assumption was that the probability of intersections of routes at any H in G would be small. After running many simulation exercises, this assumption turned out to be true given a large enough G with random vehicle traffic patterns. However, when traffic patterns were focused towards specific grid locations or from specific locations outward, as is generally the case in many real world traffic patterns, the algorithm became very inefficient (see the simulation results in Chapter 5). The simulation showed that vehicles were waiting for routes that were blocked at destination points in the vertical direction. Horizontal blocking was occurring infrequently. The reason routes were blocked was because of the long holding times of r;: i> n/2 towards destination locations due to travel times. The initial assumption had been that vehicles traveling at 200 MPH with guaranteed flight paths would spend so little time in the air that queuing delays would be minimal. However, as the number of vehicles in the system increased, the number ofblocked paths also increased, and the queuing delay for vehicles increased to over an hour. This result was unexpected and very disconcerting. Initial expected delays were in the magnitude of 10 -15 minutes. Alternatives were evaluated to reduce the size ofH to reduce the amount of congestion, but this turned out to reduce the time delays only marginally. After many simulation runs and simulation parameter adjustments, it became obvious that a more sophisticated algorithm was required. The Scheduled Chronoscube As described above, the initial routing algorithm was not adequate to meet the original goals of the solution to minimize queuing wait time. Initial simulation runs 28

PAGE 39

indicated that vehicles were waiting for routes to become available because hexahedrons in G were allocated for excessive time periods. This phenomenon was very similar to holding times associated with queuing delays in air traffic control when airplane spacing is large and runway availability is minimal. This queuing situation also has many similarities to the telephone network trunk holding delay problems. In a telephone network with long holding times or heavy traffic, the primary method used to reduce blocking is to increase the number of trunks, thereby adding capacity. One ofthe original assumptions from the initial approach was to add more levels (essentially adding more capacity). This seemed like a logical approach, but only increased the delay. The delay increased because as routes increased in vertical height, the distance a vehicle traveled increased, thus increasing the amount oftime a hexahedron was occupied. With telephone networks, the only other method to reduce blocking is to reduce the holding time. In telephone networks, disconnecting calls after a predetermined or random time interval can reduce holding time. This probably would not be considered friendly service to end users, but it would reduce congestion. Similarly, for the routing problem, the holding time for each hexahedron in r; can be reduced by restricting the time allocation to a predetermined time interval. If the interval is small enough, the probability that the hexahedron is occupied is reduced significantly. With this new concept, the routing algorithm had to be modified significantly to accommodate hexahedron time scheduling. A new definition for a hexahedron was developed and it was now called a chronoscube to reflect the added dimension of time. Figure 4-1 depicts a chronoscube and the new definition follows below: 29

PAGE 40

H' is a hexahedron in G called a chronoscube. His defined as follows: H' = 1 when it is reserved as part of one or more route paths for a given time interval t; where tis defined as the number of seconds it takes for a vehicle to move through the chronoscube space at a given velocity v. H' = 0 when it is not part of any route path. c:: 0 ;;; c:: Q) E i:5 N I 1./ / Chronoscube Levelx Vehicle v X Dimension Time reservation t Figure 4-1: Illustration of a chronoscube 30

PAGE 41

With the definition of a chronoscube, the dimensionality of a route is increased to accommodate a time window. A route now occupies space and time intervals within a chronoscube. To see how this impacts the routing algorithm, the following comparison between the original and the new version is examined. The following examples provide additional insight. NonWindowed Routing example: Figure 4-2 is used to illustrate the following textual description. Vehicle v1 requests a route r. The central controller starts examining each level in G to see if a route is available. A route is found and the respective hexahedrons in r are set to 1. Vehicle v1 begins to move along router until timex where it resides in hexahedron r4. Vehicle v2 Vehiclev1 Vehicle v1 Router lr Indicates a blocked route Ooen hexahedrons Reserved hexahedrons Figure 4-2: Initial Routing Approach example illustration 31

PAGE 42

At time t+y, y > x, vehicle v2 requests a route that shares one of the same hexahedrons in r, rJ, which was assigned to VI. At time t+y rJ has been freed because vi has already moved through it. Vehicle v2 is assigned a route. Another vehicle v3 requests a route during time interval t +z where z >x, containing hexahedrons r6 and r1 within router. Since VI hasn't move through those two hexahedrons yet, vehicle v3 is blocked. Each successive vehicle v1 that needs a hexahedron in r; during the interval t+z where z > x and will experience a blocking condition. A route may be searched on a different level, but eventually, enough hexahedrons will be blocked and vehicles will begin to wait in queue for a route. The main problem with this algorithm is the amount of time held by r; where i > n/2 with n being the total number of hexahedrons in r. These hexahedrons are reserved for an extended amount of time. The larger n is, the longer they are reserved, which creates long delays for other vehicles that need to traverse through them. Scheduled Chronoscube Routing example: In the improved version of the algorithm, vehicle vi requests a router. The central controller starts examining each levelinG to see if a route is available. A route is found and the respective chronoscubes in rare set to the time interval tvJ(tJ tvJ(rJ represents the time interval when vehicle VI will occupy a chronoscube at timet. At time t+y, y > x, vehicle v2 requests a route that requires the rJ chronoscube in r. At time t+y r3 has been released because VI has already moved through it. Vehicle v2 is assigned a route. Another vehicle V3 requests a route during time interval t + 10, containing chronoscubes r6 and r1 within route r. Although vi hasn't moved through these chronoscubes yet, if E is small enough, and tvJ(rJis not too close to x, then the 32

PAGE 43

chronoscubes will be available. In this example, v3 is not allocated a route because the time 'tv3(r it requires for r6 and r1 is within the time interval needed by vi at 'tvJ(tJ When vehicle V4 needs a route at time t+ 18 through r it is able to get one because it does not conflict with vi. This time windowing allows v4 to move to its destination without being impeded by vi's route. Thus making the algorithm more efficient than it's predecessor. Figure 4-3 illustrates this solution. Each successive vehicle v1 that needs a chronoscube in r; during the interval t+z where z > x and will have a potential to utilize the chronoscubes reserved by vi as long as the time intervals don't overlap. Vehiclev2 Vehicle v3 Vehiclev1 Indicates a blocke v, Open hexahedrons Reserved hexahedrons Figure 4-3: Improved Routing Approach Example Illustration All successive requests for chronoscubes in router assigned to vehicle vi will experience similar results as vehicle v4. Essentially, the time interval assigned to a chronoscube for each vehicle creates a time window that is much shorter than that from the initial approach. This time window is much more dependent on the 33

PAGE 44

movement characteristics of each vehicle and requires more calculation than the first approach. Advantages of the scheduled chronoscube As illustrated from the preceding examples, the scheduled chronoscube offers better utilization of chronoscubes and reduces the number of blocked routes at any given instant in time. It maintains the deterministic nature ofthe and provides additional control. For example, the time interval assigned to each chronoscube is initially based on the amount oftime a vehicle spends within the boundaries of the 3D hexahedron. However, to increase safety margins, additional time may be added to the chronoscube time interval to account for early or late ingress and egress. This additional time constant E is referred to as a guard time and may be adjusted to insure vehicle separation. If E is made very large, the model will approximate the non scheduled chronoscube model presented in the non-windowed problem approach. Pre-Scheduling In addition to the scheduled chronoscube, another algorithmic improvement to reduce vehicles trapped in queue is called pre-scheduling. The rationale for this approach is based on the fact that some vehicles that are waiting for a route continue to wait for an extended period oftime in the queue. This situation occurs when a vehicle is trying to establish a route that is blocked by other vehicles repeatedly over a given interval. Blocking usually occurs when many vehicles are trying to travel to a small geographic location within a small time interval. To reduce the vehicle wait time in queue, pre-scheduling of the vehicle-i.e. looking ahead in time for a route-is one method to reduce this blocking. Essentially, pre-scheduling enables the routemaster computer to search for a route, many minutes ahead of the present time, which, in general will allow it to find a route more quickly for the requesting vehicle. The downside to this approach is that more resources are 34

PAGE 45

needed by the routemaster computer to search all possible routes. Therefore, the routemaster computer is not able to process as many requests. If too many vehicles require pre-scheduling, the total amount of routes processed each second is reduced. Automated Architecture For vehicles to travel in three-dimensional space using a deterministic routing algorithm, several important improvements will be required as listed below: Vehicle Requirements Vehicles must be able to travel in any direction, horizontally and vertically. Vehicle systems must require redundancy such that a catastrophic failure is extremely unlikely; system redundancy that is much higher than in existing aircraft. Each vehicle must use a positioning system to identify where it is in 3D space at any given point in time. Control Requirements A centralized or distributed system that maintains a map of all routes assigned to all vehicles. A system that allocates all routes and updates the route maps as vehicles' transit the domain. A system that maintains a queue of route requests. 35

PAGE 46

A system that manages priorities for route requests and transit time. A system that manages congestion by limiting the amount of vehicles in transit at a given time. A system that distributes traffic evenly across the grid space. There are several potential hardware and software architectures that could be selected to meet the control requirements of the problem domain. Each potential solution will have to take into consideration the following variables: Control computer performance. Reception and processing oftransponder signals from vehicles. Routing Assignment computing vs. vehicle movement computing. Dynamic rerouting of routes if a vehicle fails to move along the prescribed route in the appropriate timeframes. System redundancy. 36

PAGE 47

The architecture selected for modeling the simulation is based on a massive single computer system that is responsible for assigning and managing all routes. Transponder Station Transponder Station Transponder Station Transponder Station Figure 4-4: The architecture of the centralized computer system The rationale for this approach is simplicity in simulation. A distributed environment would work just as well, but simulating a distributed environment is more complex. Figure 4-4 illustrates the architecture ofthe model used in the simulation. 37

PAGE 48

Three Dimensional Space The three-dimensional space represented by the grid defines the space in which vehicles may travel. Since it is probably not feasible to create routes for all vehicle travel, the space will probably need to be functionally subdivided for different types of travel. As illustrated in Figure 4-5 the vertical airspace has been divided into 4 sections. Airspace below 500 feet is reserved for local vehicle traffic. Vehicles traveling in this area will probably travel at slower speeds and may be restricted to the length of travel. Above the local traffic zone is the routed traffic airspace. This is the area that is addressed by the simulation. One important note is that vehicles must traverse through the local airspace to get into the routed traffic zone (zone 2). This is also true for vehicles moving in zones 3 and 4. If a vehicle wishes to traverse from one zone to another that would require it to pass through zone 2, the vehicle would be required to schedule a route through zone 2. Zone4 Zone 3 Zone 2 Zone 1 ,s.oo,..q:z
PAGE 49

Zones 3 and 4 are used for vehicles that are traveling across cmmtry and do not want to be impeded by traffic in the metro areas. Routes Routes in the three dimensional space are defined by sequential reservations of chronoscubes. These routes occupy a chronoscube for a time interval equal to the amount of time it takes for a vehicle to traverse the cube plus a guard time. Routes are simplified to a rectangular shape to reduce the number of calculations involved in allocating chronoscubes. This simplification does not necessarily reduce the accuracy of the simulation because it is unknown at this time how vehicles will be able to travel in the future. Figure 4-6 illustrates a route projected in 3D space. Each chronoscube is allocated a time slot that is determined by the vehicle's performance characteristics. For purposes ofthis research, all vehicles are assumed to have similar movement characteristics, therefore, movement is uniform across all vehicles in the system. Since this may not be the case in a real world environment, vehicle parameters may be configured individually. However, it is difficult to know exactly how different the parameters might be since these vehicles have not been developed yet. ---: Figure 4-6: Vehicle Route Illustration using Chronoscubes 39

PAGE 50

CHAPTERS SIMULATION ARCHITECTURE To simulate the vehicle scheduling problem, a computer simulation was developed using C++ and multi-threading under the Windows NT Operating System (version 4.0). The simulation object model is architected as illustrated in figure 5-1. The object model contains 5 objects: Simulation Engine Object Route Master Computer Object Vehicle Object Grid Object Graphical User Interface (GUI) Object Simulation Engine Object The core object within the simulation is the Engine object. This object provides the methods that drive the simulation. Its main purpose is to control the simulation activity which includes Simulation initialization. Vehicle creation. Vehicle queue management Vehicle movement. 40

PAGE 51

The routemaster computer route selection. Statistics generation. Simulation cleanup. The flow chart in Figure 5-4 describes the process for each second of simulation time. RouteMasterComputer Object The RouteMasterComputer object describes the functionality ofthe master computer system that controls route allocation. Each vehicle generates a request to the RouteMasterComputer object, which stores the request in a queue. When the RouteMasterComputer processes the queued requests it checks each queued request in FIFO order for the next available route. If a route is available for a request, it returns the route to the vehicle that made the request and removes the request from the queue. If a route is not available, the request is retained in the queue. Figure 5-3 illustrates the process flows for finding a route. The RouteMasterComputer object will only process k requests during each simulation second. This limitation represents the real world processing restrictions for the central computer system. The variable k is represented by a parameter in the control panel ofthe simulation 41

PAGE 52

f) Q CI(JQ Cl c: g e. ()'I Q I Cl .... rJl c: ;-.... cs Cl > ri I I GUI c:r ::t.' g .... c: = N C: ;! .... ; (JQ .... c:r Q 0" .... fD f) Q c: Cl Q. Q 0" .... g .... I sReserved() Start() Grid Simulation Engine geiVehicleLisl() gel Grid() wherei\re You() RcscrveSquares(); rouleRequesl() updaleYehicleRoule( Vehicle RouteMasterComputer TransponderSignal() TestMoveVehicle()

PAGE 53

.Vehicle Object The vehicle object describes a physical vehicle object. Each vehicle is created, waits, moves, and is destroyed during the course of simulation activity. A vehicle object contains the following information: Vehicle position Speed Direction traveling ( vertical!horizotal) Acceleration Deceleration Velocity Origin and destination Route Vector 43

PAGE 54

(, \ Process Routes For each vehicle . m queue (FIFO) //"!: I ___ //(c,el Allocalioo 3 -----, '-,, Strarcgy Assign level based on distance : traveled shorter is lower T 1 Same as option 1 with random i additions to deter I ____ Set level to I Check level for available route No ./ / ''-, Increment level 1 /./ '-.. / Rooe available by I until = max ,______../bel> IIIIIJ levels / No level to vehicle and noti1Y it so that it can begin Jmving Yes y No route found fur : vehicle, leave it in ----------queue. incn:ase -.it seconds Get next vehicle ____________ _. in queue Figure 5-2: Flowchart illustrating the level determination phase of the route allocation process. 44

PAGE 55

Find Route Seconds= I : Calculate vehicle movement for this second Calculate the occupied chronoscube 1 based on current vehicle position No Assign time window s-e
PAGE 56

. BegliiSimulation y Initialize, seconds =0 --_ ________y_ -------Allocate n vehicles y Add to vehicles 1 in system queue y 1 Calculate and Move each vehicle with a route assigned __y___ ___ Calculate routes for k vehicles Increment seconds by I // Yes //Any vehicles in' ', __ -queue or / No y Terminate No : Move Vehicle ----y __ J Check direction 1 movmg Vertical / / Yes y Accelerate vertical Rate Yes Accelerate vertical Rate y Horizontal Yes Accelerate Horiz Rale Yes Accelerate Horiz Rate Move Vehicle -'-------No /" / out of current -, Yes Send Transponder to Central Control ; Free chronoscube I // ,/' No Yes Remove vehicle from system _ ___y_____ i Terminate Figure 5-4: Flow charts illustrating the main simulation and vehicle movement algorithms 46

PAGE 57

When a vehicle object is created, the vehicle sends a message to the master computer requesting a route. If a route is found, the vehicle begins moving, if not, it waits in queue until a route is allocated. Figure 5-4 illustrates the process for moving a vehicle. Once a route is assigned to a vehicle, the vehicle begins to move by accelerating vertically until it reaches the maximwn velocity. It travels at this rate until it reaches a deceleration point whereby it begins decelerating until it reaches the altitude at which it will begin traveling horizontally. Horizontal travel begins with acceleration until horizontal maximwn velocity is reached. Travel continues until the deceleration point is reached and deceleration begins until the vehicle position is equal to the point where the vertical descent begins. Vertical descent is the same as the ascent portion ofthe route with acceleration towards the ground. It is important to note that vehicle movement is asymmetrical in the vertical and horizontal directions. This model was used to represent the fact that vertical travel may be more expensive than horizontal travel with respect to power requirements. As each vehicle moves, it passes through chronoscubes in the three dimensional grid. When a vehicle passes from one chronoscube to the next, it uses a transponder to send a message to the master computer indicating that it has moved out of the current chronoscube. This allows the master computer to release the chronoscube to be used by another route. When a vehicle lands, all chronoscubes have been released and the vehicle is removed from the system list. Grid Object The grid object represents the three-dimensional space that routes are allocated in and vehicles travel through. The grid is represented by a 3 x 3 sparse matrix to minimize memory requirements. Each element in the matrix points to a cell that 47

PAGE 58

contains information about the status ofthe cell. A cell contains a information on the number of vehicles using the cell and a pointer to a list oftime ranges that indicate when the cell is reserved by a particular vehicle ID as depicted in Figure 5-5. The grid object is responsible for manipulating all grid activity and is heavily used by the master computer and the vehicle objects. The grid object is also responsible for finding and allocating routes for the master computer. The grid object was selected to perform this functionality because it has easy access to all grid data. lDGridS.-nr V Matrix Figure 5-5: Illustration of the chronoscube sparse matrix with the cell contents for a chronoscube. Graphical User Interface Object The GUI object provides the user interface to manipulate the simulation. Appendix A contains a view ofthe main screen. The GUI configures the simulation 48

PAGE 59

parameters and executes and stops the simulation. The GUI is also used to display simulation activity graphically. The main screen contains two windows that are used to display vehicle routing and movement. The large window contains an overhead view of each grid level. This view provides a planar window into the grid that allows the user to see how vehicle travel is progressing at each level. Additionally, this view also enables the user to see vehicles moving vertically by changing the color of the vehicles to depict the direction they are moving. The color blue is a vertical climb, the color red is horizontal movement, and the color green represents a vertical descent. The smaller window contains a 30 box with a 30 view of the grid. Each route and vehicle is plotted on this grid to illustrate how they look from different viewing perspectives. At any time, the simulation can be stopped to examine the 30 view to check traffic movement and congestion. Vehicle Movement Formulas Since each vehicle must be positioned at each second of simulation time, the following formulas determine where the vehicle will be. Note that the variable seconds in the equations refers to seconds relative to the time the vehicle started moving. During the acceleration phase of movement the equation is: (5.1) At maximwn velocity the equation is: (5.2) x = velocity seconds+ adistance Where adistance is the distance already traveled. 49

PAGE 60

During the deceleration phase of movement (5.3) x = abs(seconds deceltime)deceltime2 ) + vdistance where deceltime is the time in seconds where deceleration begins and vdistance is the distance traveled before deceleration begins Constant acceleration and deceleration rates are used to simplify the model. Another reason to use a simplified model is that future vehicle characteristics are speculative at best. Simulation Hardware The simulation was executed on a Personal Computer running the Windows NT Operating System. The CPU is a 133MHz Pentium Processor with 64MB of RAM. The system also included a 7 GB hard disk with virtual memory set to 390MB. During high volume 5000 vehicle simulation the system utilized 124MB of combined RAM and virtual memory. Simulator Constraints The simulator is designed to manage vehicles entering the system within the boundaries ofthe grid area. Vehicles will need to be able to enter the system from outside the grid area within the routed traffic zone (zone 2) altitude, and from altitudes above and below it. Another limitation of the model is the ability to route around obstacles. For example, if a congested area blocks a direct path, an alternate route with multiple segments might be used instead of waiting for the congestion to dissipate. 50

PAGE 61

CHAPTER6 SIMULATION RESULTS There are many scenarios that can be addressed when simulating the effects of route generation and vehicle movement. The main premise behind this research is to identify parallels to existing traffic movement, thus a model is used that represents travel in a major metropolitan area. Since the author resides in Denver, this city was selected as the subject for the simulation runs The simulation model for Denver consists of two focal areas for travel: the center area represents downtown and the area to the southeast represents the Denver Technology Center. Traffic moves towards each area based on random destination points within the grid. Figure 6-1 illustrates how Denver is modeled in the simulator. The picture shows vehicles moving towards the two concentration areas and several routes that have random destinations. The assignment of destination points is performed with the following rules: 1. Random traffic anywhere on the grid is 20% 2. Traffic moving towards downtown is 40% 3. Traffic moving towards the Technology Center is 40% These rules were developed based on traffic patterns during peak travel times in Denver between 6:00am and 9:am. Traffic patterns are different depending on the time of day. 7 These patterns do not include cross-town traffic, which is expected to travel outside the route assignment level zone. 7 Colorado Department of Transportation traffic studies for 1992. 51

PAGE 62

GlliO Vll 'WI 11 j -----------u.-=1 VQ = 181, WQ= I -=-=0 --1.-.-)l I Start I I Stop I I ContiRue I I 0nrw I Figure 6-1: Simulator Main Window depicting the Denver Metropolitan area. The simulation software is capable of supporting other models in addition to the Denver scenario such as: multiple destination areas (up to I 0), complete random traffic to any destination, and traffic moving towards or away from a focal area. Each configuration produces interesting results for analysis, but to create a comparison that could be contrasted, the scenario chosen was of most interest to the author. The following sections describe the results obtained from the research using the simulator. 52

PAGE 63

Simulation Scenarios The primary results ofthe simulation focus on the queue sizes and the wait time associated with each vehicle. The following observations illustrate several different output characteristics ofthe simulation. These graphs focus on the following: High Volume Simulation Heavy Congestion Simulation Medium Congestion Simulation Light Congestion Simulation Heavy Congestion with Small Time Window Simulation Each graph provides insight into how the algorithm operates under different parameters. High Volume Simulation Configuration The high volume simulation results illustrate how well the model responds to a large load. Due to the limited size ofthe computing resources available to simulate this model, 5000 vehicles is the maximum input capacity of the simulator on the hardware used. A sample of200,000 vehicles would be preferred. However, to reach this level of simulation, a system with 10 or more gigabytes of RAM is required, or a sophisticated grid caching algorithm is needed. The parameters listed in Table 6-1 were used to generate the high volume simulation results. 53

PAGE 64

Simulation Parameters Value Vehicles Requesting Routes 5000 Routes Requested Per Second 28 Routes Processed Per Second 30 Chronoscube Guard Time 5seconds XY Grid Size 500 sq ft Vertical Level Size 500ft Levels in the Grid 20 Vehicle Movement Denver Scenario plus random Route Allocation Start at level I; travel upward Nodes in Grid to travel towards 2 Table 6-1: Simulation Parameters for High Volume Configuration High Volwne Simulation Results For this simulation run, wait times are not excessive given that the simulation was terminated early. The simulation was tenninated early because of excessive thrashing on the hard drive due to the use of virtual memory. The simulation was running for almost 1 week and had not made significant progress in the latter days due to the 110 bottleneck. If the simulation had completed, the author believes the wait times would have reached 500-900 seconds for vehicles which entered the system toward the end ofthe ingress period. The premise for this statement is based on the simulation results encountered in other simulation runs where high congestion was present. Figure 6-2 presents the queuing data for the simulation. The queue size is 40% ofthe number of vehicles requesting service. The wait times are within an acceptable range and the queue size is beginning to decrease. 54

PAGE 65

Queuing Analysis for 5000 Vehicle Simulation Run 6000 120 5000 I 4000 100 in Grid i 80 0 .. Vehic Its in Queue .s 3000 60 .s .!1 :a 2000 :;:. 1000 J Vehicle number as it enters 40 system. i 20 ;:: Vehi lt 'ill'& it Time 0 0 0 50 100 150 200 250 Time (t):ianco..a. Figure 6-2: Queuing Graph for the High Volume Configuration The graph above represents the results ofthe largest model size that would run on the hardware used to execute the simulation. Although much larger data points may be required to simulate real traffic patterns, the data provides insight into how the model behaves under loaded conditions Table 6-2 lists the statistical observations identified. The numbers related to the maximum and average move seconds are not available because the simulation was not completed. 55

PAGE 66

Statistical Simulation Output Values Maximum Vehicles on a Level (Level#) 576 (I) Average Vehicles on a Level 193.67 Maximum Vehicles in System 3821 Maximum Queue Size 1633 Average Queue Size 529 Maximum Wait Time 98 sec Average Wait Time 23 sec Maximum Vehicle Move Seconds N!A Average Vehicle Move Seconds N/A Table 6-2: High Volume Simulation Results Heavy Congestion Simulation Configuration To simulate the heavy congestion scenario with the limited system resources, an approximation was used to create congestion. To get the desired results, only two levels were used with an input of2000 vehicles. The rationale for this approach is based on the fact that when all levels are full, the chance of finding an open route is as likely with 2 levels as that of20. The reason for this is that the destination vertical path is usually blocked and a large number of levels will not have a major impact on route generation. With only 2 levels in use, only 2000 vehicles are required to generate a congestion situation. By using only 2000 vehicles, the simulation runs in memory with reasonable performance. The simulation configuration parameters are listed in Table 6-3. 56

PAGE 67

Simulation Parameters Value Vehicles Requesting Routes 2000 Routes Requested Per Second 28 Routes Processed Per Second 30 Chronoscube Guard Time 5 seconds XY Grid Size 500 sq ft Vertical Level Size 500ft Levels in the Grid 2 Vehicle Movement Denver Scenario plus random Route Allocation Start at level I; travel upward Nodes in Grid to travel towards 2 Table 6-3: Simulation Parameters for Heavy Congestion Configuration Heavy Congestion Simulation Results In a heavy congested environment, the queue size relative to the vehicles requesting service is 75%. Wait times increase to 1400 seconds for vehicles that arrive at the end of the ingress period. The graph in Figure 6-3 illustrates the relationship between the service requests and the queue size. The wait time increases linearly with each additional request. The specific output results are listed in table Table 6-4. 57

PAGE 68

Heavy Congestion Ill = :2000 II wu Qutut S:i:u = 0 1500 .E 1000 Ill V thio: los in Sy stea u :c 500 Ill Vthio:lt .Ainl'll Order > 0 + Q 1le1lt W Ut Ste ODds 10 100 1000 10000 Time (seconds) Figure 6-3: Queuing Analysis under heavy loading conditions This graph illustrates that the model does not prevent long queuing times when heavy congestion exists. Average wait time for this simulation run is 500 seconds (8.3 minutes), which is probably an acceptable wait time for most individuals. The maximum wait time was near 1400 seconds (23.3 minutes) which is within 30 minutes. Statistical Simulation Output Values Maximum Vehicles on a Level (Level #) 335 (I) Average Vehicles on a Level 299 Maximum Vehicles in System 598 Maximum Queue Size 1619 Average Queue Size 597 Maximum Wait Time 1531 sec Average Wait Time 530 sec Maximum Vehicle Move Seconds 1003 sec Average Vehicle Move Seconds 477sec Table 6-4: Heavy Congestion Simulation Results 58

PAGE 69

Heayy Congestion with Small Time Window Simulation Configuration To minimize queuing delay, one of the parameters that can easily be changed is the guard time for each chronoscube. The guard time represents a safety margin that is used to minimize the proximity of one vehicle to another. Under heavy loaded conditions, reducing this parameter will have an effect on the number of routes that can be processed. The effect this has on the model is to change the time window available in each chronoscube. This effectively reduces the probability that a chronoscube will be in use when it is needed as part of a route at any given instant in time. This simulation run examines this by changing the guard time from 5 seconds to 1 second. The value was not changed to zero because this leaves no margin for error. All other parameters are equal to the heavy congestion configuration. Simulation Parameters Value Vehicles Requesting Routes 2000 Routes Requested Per Second 28 Routes Processed Per Second 30 Chronoscube Guard Time I seconds XY Grid Size 500 sq ft Vertical Level Size 500ft Levels in the Grid 2 Vehicle Movement Denver Scenario plus random Route Allocation Start at level I; travel upward Nodes in Grid to travel towards 2 Table 6-5: Simulation Parameters for High Congestion with Short Time Window Configuration 59

PAGE 70

Heary Congestion with Small Time Window Simulation Results The output results reflect a reduction in maximum queue size and wait time. The maximum queue size is reduced by 23% and wait time is reduced by 30%. Another significant reduction is the maximum wait time incurred by some ofthe vehicles in the system. The maximum wait time was reduced by 30% as well. These reductions in queuing delay indicate that the guard time has a significant impact on the delay incurred while waiting for a route. While this is a significant improvement, the safety margin is minimal and may lead to collisions, which are undesirable. Figure 6-4 illustrates the improved queuing results graphically. Heavy Congestion With Small Time Wmdow 2500 1000 e 900 Cl) 2000 800 Wait Queue Size .. 1 !It 100 1500 600 0 Vehicles in System .. II 500 fl!l Wait Seconds !It Cl) 1000 4JO 300 :a Cl) 500 200 i> 100 0 ... 0 1 10 100 1000 Time (seconds) Figure 6-4: Queueing and Wait Times for Heavy Congestion with Small Window Size In the above graph, a smaller time window was used to compare the wait times in a heavy congestion environment. A wait time window guard time of 1 second was used instead ofthe nonna15 second guard time. Wait times dropped by 500 seconds on average in this run. 60

PAGE 71

Statistical Simulation Output Values Maximum Vehicles on a Level (Level #) 743 (I) Average Vehicles on a Level 649 Maximum Vehicles in System 1298 Maximum Queue Size 1172 Average Queue Size 281.6253 Maximum Wait Time 921 sec Average Wait Time 116 sec Maximum Vehicle Move Seconds 1000 sec Average Vehicle Move Seconds 476 sec Figure 6-5: Heavy Congestion Simulation with Short Time Window Results Mediwn Congestion Simulation Configuration The mediwn congestion simulation was executed to use as a comparison against the heavy congestion scenario to see if halving the input rate reduced the queue size and wait time. The only difference between the mediwn and heavy simulation exercise was the arrival rate that was halved. Simulation Parameters Value Vehicles Requesting Routes 2000 Routes Requested Per Second 15 Routes Processed Per Second 30 Chronoscube Guard Time 5 seconds XY Grid Size 500 sq ft Vertical Level Size 500ft Levels in the Grid 2 Vehicle Movement Denver Scenario plus random Route Allocation Start at level 1; travel upward Nodes in Grid to travel towards 2 Table 6-6: Simulation Parameters for Medium Congestion 61

PAGE 72

Medium Congestion Simulation Results By reducing the arrival rate by 50%, the queue size and queue wait time decreased. However, the decrease was only marginal, 4%. The reason for this is due to the grid becoming saturated fast in both simulation exercises. From these results, it is obvious that reducing the arrival rate is not a good mechanism for improving queuing delays. Medium Congestion 2500 1800 e 1600 Q) 2000 ... "' >a "' 1500 .5i 1400 i 1:.100 Wait a ueue Size 0 1000 .. Vehicles in System "' 1000 Q) 800 j +WaitS econds 1500 ... :a 500 Q) > 400 ... :tOO 0 0 10 100 1000 10000 Tm.e (secolls) Figure 6-6: Graph Illustrating the Queuing Delay for the model under medium congestion The statistical results for the medium congestion scenario are listed in Table 6-7. 62

PAGE 73

Statistical Simulation Output Values Maximum Vehicles on a Level (Level #) 392 (I) Average Vehicles on a Level 349 Maximum Vehicles in System 698 Maximum Queue Size 1524 Average Queue Size 577 Maximum Wait Time 1576 sec Average Wait Time 512 sec Maximum Vehicle Move Seconds 1032 sec Average Vehicle Move Seconds 480 sec Table 6-7: Medium Congestion Results Light Traffic Simulation Configuration The light traffic simulation exercise tests the basic queuing theory stated in Chapter 3. Using an arrival rate of2 vehicles per second and 10 levels, the load for routing is predicted to be non-existant. The simulation parameters are located in Table 6-8 below. Simulation Parameters Value Vehicles Requesting Routes 2000 Routes Requested Per Second 2 Routes Processed Per Second 30 Chronoscube Guard Time 5 seconds XY Grid Size 500 sq ft Vertical Level Size 500ft Levels in the Grid 10 Vehicle Movement Denver Scenario plus random Route Allocation Start at level I; travel upward Nodes in Grid to travel towards 2 Table 6-8: Simulation Parameters for Light Traffic 63

PAGE 74

Light Traffic Simulation Results Using the equations presented in Chapter 3, the following theoretical values were calculated in Table 6-9. Queue Parameters Calculated V aloes Simulation Values p 0.067 NIA L, 70 498 LQ 4 1.4 w, 3.5 sec 479 sec Wq 2sec 1.11 sec Table 6-9: Calculated vs. Simulated Queuing Values for Light Traffic The calculated values represent the steady state theoretical values over a period oftime equal to that of the simulation. L, represents the nwnber of vehicles in the system. The reason for the difference is that the calculated values do not take into consideration the time duration a vehicle is in flight. Lq represents the length of the queue. The percentage difference is 35% which is good considering the simplicity of the queuing calculations. W, is the total time a vehicle is in the system. The calculated results are unusable here because they do not reflect the true service time that includes vehicle movement. Wq is the average time a vehicle waits in queue. This value is offby 55% compared to simulated results, but with an arrival size of 2000 vehicles, this margin is relatively small. Figure 6-7 illustrates the simulated data for queue size and wait times. Some vehicles experience a high wait time due to route conflicts with other vehicles. These vehicles must wait for a time period equal to or greater than the guard time of all surrounding chronoscubes. With a 5 second guard time, this wait time can be as high as 7 seconds. If a vehicle is blocked by more than one vehicle at different time 64

PAGE 75

Light Traffic Simulation Results Using the equations presented in Chapter 3, the following theoretical values were calculated in Table 6-9. Queue Parameters Calculated Values Simulation Values p 0.067 N/A Ls 70 498 Lq 4 1.4 Ws 3.5 sec 479 sec Wq 2sec 1.11 sec Table 6-9: Calculated vs. Simulated Queuing Values for Light Traffic The calculated values represent the steady state theoretical values over a period oftime equal to that ofthe simulation. Ls represents the number of vehicles in the system. The reason for the difference is that the calculated values do not take into consideration the time duration a vehicle is in flight. Lq represents the length of the queue. The percentage difference is 35% which is good considering the simplicity of the queuing calculations. Ws is the total time a vehicle is in the system. The calculated results are unusable here because they do not reflect the true service time that includes vehicle movement. Wq is the average time a vehicle waits in queue. This value is offby 55% compared to simulated results, but with an arrival size of2000 vehicles, this margin is relatively small. Figure 6-7 illustrates the simulated data for queue size and wait times. Some vehicles experience a high wait time due to route conflicts with other vehicles. These vehicles must wait for a time period equal to or greater than the guard time of all surrounding chronoscubes. With a 5 second guard time, this wait time can be as high as 7 seconds. If a vehicle is blocked by more than one vehicle at different time 65

PAGE 76

intervals, the waiting time will increase as indicated by several occurrences illustrated on the graph. Light Congestion Vehicles in System Wait Queue Size Wait Seconds 0 500 l!Dl 1500 Figure 6-7: Chart Illustrating Queuing and Wait Times for Light Congestion The above graph illustrates that with light congestion, queuing is not a factor and wait times are insignificant. The arrival rate used for this simulation is 2 vehicles per second. 66

PAGE 77

Simulation Parameters Value Vehicles Requesting Routes 2000 Routes Requested Per Second 2 Routes Processed Per Second 30 Chronoscube Guard Time 5 seconds XY Grid Size 500 sq ft Vertical Level Size 500ft Levels in the Grid 10 Pre-scheduling On Pre-schedule lookahead window 500 seconds Vehicle Movement Denver Scenario plus random Route Allocation Start at level I ; travel upward Nodes in Grid to travel towards 2 Table 6-11: Simulation Parameters for Pre-scheduling Pre-scheduling Simulation Results The output results from the simulation using pre-scheduling are listed in Table 6-12. Statistical Simulation Output Values Maximum Vehicles on a Level (Level#) 392(1) Average Vehicles on a Level 349 Maximum Vehicles in System 698 Maximum Queue Size 1480 Average Queue Size 577 Maximum Wait Time 1480 sec Average Wait Time 220 sec Maximum Vehicle Move Seconds 1032 sec Average Vehicle Move Seconds 480 sec Table 6-12: Pre-Schedule Congestion Results 67

PAGE 78

Calculated values indicate that average wait time is 50% smaller than wait times in a congested environment. This reflects the fact that pre-scheduling in time finds more optimal routes for vehicles on average than waiting for a route to be allocated in time. Unfortunately, pre-scheduling does not reduce the wait times for all vehicles. Some vehicles still get trapped in the queue and must wait for inordinate times before a route can be allocated. Figure 6-8 illustrates the simulated data for queue size and wait times. Heavy Congestion with Pre-scheduling G) 2500 1500 il :1 'U G 2000 1: :1 0 a 1000 Wait Queue Size t: 1500 .. fiJ 1000 Velric1es in System G 500 E i= J: 500 ... Velricle An:iY8l Order G) -; > 0 0 5: 1 10 100 1000 Qaeue Wait Seconds Time (seconds) Figure 6-8: Chart Illustrating Queuing and Wait Times for Pre-Scheduling This graph shows that with pre-scheduling, wait times are reduced by 50% on average, while maximum wait times are still equivalent to the normal congestion scenano. 68

PAGE 79

Optimization Analysis After reviewing the results provided by the five simulation studies, it is obvious that changing several parameters can have a dramatic impact on the queuing delay. To address this in more detail, additional simulation configurations were executed to identify any potential improvements. Since the primary area of concern is the heavy congestion scenario, this is the focus ofthe optimization analysis. In addition to the two simulation configurations presented in this section, two other configurations are of interest. The first addresses increasing the service rate by 100% from 30 to 60 routes per second. The second configuration reduces the size of a chronoscube side from 500 ft to 1 00 ft to measure the impact of smaller chronoscubes in a route. In the second configuration, the chronoscube guard time is reduced because a vehicle spends only a fraction of time in a chronoscube when the size is reduced. The graph in Figure 6-9 shows the average queuing delay, the average queue size, the maximum queue size, and the maximum number maximum vehicles in the system. CD 700 600 d 500 s::: 400 en 300 200 -.c 100 0 ---f-f--f--I f--f--rt= ..; r-f-1800 1600 c;;1400 "C 1200 s 1000 u 800 = 600 -4oo e 200 i= 0 Avg Queue size Avg Queuing Delay D Max Wait Time Figure 6-9: Comparison of Simulation Configuration Results 69

PAGE 80

From the results ofthe graph, it is evident that the biggest improvement to reduce queuing delay is to change the grid size and to reduce the guard time for the chronoscube. Pre-scheduling reduces average wait time, but does not impact the queue size or maximum wait time. There are an infinite number of possible combinations for the above scenarios that can be used to optimize the queuing delay. Each parameter adds a cost factor to the implementation of the system though. For example, when the size of a chronoscube is reduced, the size ofthe grid increases proportionally. This increases cost to compute and store routes. Another example is the cost of increasing the service rate. If the service rate is increased, then additional computing power may be required which will add hardware costs. These examples illustrate the trade-offs associated with changing parameter values. Much thought will be required to optimize these parameters and others that have not been identified yet. 70

PAGE 81

CHAPTER 7 CONCLUSION Researching theoretical material to support the premise of the thesis was difficult because very little data or information exists to support the hypothesis of deterministic routing in three-dimensional space. Since this is a new idea, the author pioneered a number of new concepts such as the chronoscube and the routing algorithm. The initial hypothesis was to identify a potential model for traffic movement in three-dimensional space that would minimize travel time and congestion. The deterministic approach was developed based on similar models that reflected advantages to more predictability in managing traffic. A simulator was developed to test the original hypothesis; that this type of a solution would be effective. Due to the simplicity ofthe first model, high volume simulations could be executed without memory constraints. The original simulations identified a major flaw in the original hypothesis because queuing wait times exceeded an hour, an excessive wait period. The alternative solution brought about the concept of the chronoscube and the benefits it brings to solving the problem of queuing delay. The chronoscube added a fourth dimension to the problem, which added complexity. This complexity added a high cost to the simulation in terms of memory usage. With the added memory requirements, the simulation size was reduced dramatically, which created a need to simulate congestion in compressed space as a means of gauging the impacts on the new algorithm. Although this was not an ideal environment, the results reflect that with the addition of the chronoscube to the algorithm, the queuing delays are reduced to what the author believes will be acceptable delays. 71

PAGE 82

From the simulation results, it is apparent that when the offered traffic load is light to medium, the simulation behaves as expected. Routes are allocated quickly and queueing delays are minimal, less than 5 minutes. As the offered load is increased to above 15 vehicles per second, the simulation reaches saturation and the queuing delay begins to increase linearly for each vehicle that arrives after the point of saturation. The difficulty with this behavior is that it implies that with large volumes of traffic, in excess of I 0,000 vehicles, queuing delays could become unacceptably high (> 30 minutes). Due to the limitations ofthe hardware that is executing the simulation, sample runs greater than 5000 are impractical. Therefore, approximations are used to emulate congested environments. These approximations may exhibit different characteristics as compared to a complete simulation run. Since congestion is one area of major importance with respect to this problem domain, additional research is needed to validate the supposition that the simulated congestion scenarios are comparable to the behavior a high capacity sample. Several important observations were made during the execution of the various simulation scenarios as listed below: The time to calculate a route consistently averaged from 300 to 1200 miliseconds depending on the length ofthe route. This implies that fast hardware or multiple processors will be required to manage peak loads. Route patterns oriented towards a focal point reached congestion faster than pure random patterns. Vehicles moving away from a focal point incurred an even higher delay than either of the aforementioned patterns. When routes are allocated from lower levels upward, saturation occurs faster compared to route level assignment based on level. 72

PAGE 83

Queuing delay is reduced dramatically when the area of a chronoscube is reduced in size. This is evident from the results identified in the comparison graph in Chapter 6. Because the queue service strategy used is a modified FIFO, some vehicles may wait in queue long after new arrivals are dispatched. This creates some disparity and may require a priority scheme to overcome. Since this observation came to light during the writing ofthis paper, additional and output statistics will be needed to study the impact ofthis circumstance. When this endeavor was first started, the premise was that traffic congestion in the air would be unacceptable. Thus the idea to keep vehicles on the ground while waiting for a guaranteed route before moving. Once movement began, a vehicle moves in the most optimal manner until it reaches the destination coordinates. As the research progressed, it became obvious that with chronoscube routing, other problems might be solved. The other areas of research might include the following: Present day routing of vehicles in two-dimensions. Air traffic control around congested airports. A military application such as scheduling weapons delivery over a target. Scheduling the delivery of data messages on local area networks. 73

PAGE 84

With respect to follow on research related to the problem domain, there are many areas of study that need to be pursued. The list below is a not comprehensive by any means: 1. Vehicle movement in an arc instead of the rectangular movement. 2. Developing enhancements to the algorithm to account for vehicle movement that does not coincide with a scheduled route. Dynamic rescheduling in flight. 3. Add vehicles that enter the system in the air from outside the original grid space. 4. Study the impacts weather will have on route creation. 5. Evaluate better methods for reducing queuing delay. 6. Execute simulations that approach theoretical real world sizes to gather more accurate results. 7. Optimization in the creation of routes. 8. Optimization in the implementation of chronoscubes 9. Study the characteristics of distributed vs. centralized control. The simulation data supports the hypothesis that deterministic fixed routes may be generated for three-dimensional travel with reasonable queueing delays. It would be nice to live long enough to see how future technology will be deployed and if people are willing to use a system similar to the one proposed here. 74

PAGE 85

APPENDIX A SIMULATOR OPERATION GUIDE The 3D simulator provides users with the ability to configure various parameters of the simulation through a graphical user interface. In addition to modifying the simulation parameters, the simulation interface also provides a graphical depiction ofthe vehicle routes and vehicles moving on the 3D grid. To execute the simulation, press the start button, enter the configuration values, and watch. The main screen ofthe simulator is illustrated below: ......... =1 -..-rr 38000 = 'VBIIt. 0 BBDt-0 -s--s...._ SeMs 0( 0.00 01) 1 -: Start :: I smp I : I Paase J .s : I Contillue J : 1i Draw I .. Gdd l..eYel Vehicle Level CoURt 1'1).""j0 j 0 _j 0 iO 1-5 I /. r---1 . -;-. : 0 0 i 11 i 0 i 0 6-10 1'11ro:-r o T IITII 11-15 ---l---' -1 0 0 \ 0 [ 0 : 0 16-20 I I I 1[3 :: Vehicles 1 0 :: Vebldes tit OuCue ,.------::-0--, . . ... . .. ... MO .. .. .. .. ... Figure A-1: Simulator Main Window 75

PAGE 86

The objects displayed on the main window perform the following functions: GUI Objects Use Description Start Button When this button is pushed, a dialog box is opened requesting the simulation parameters for the simulation run. Once the parameters have been modified and the OK button is pressed, the simulation starts. A successful start is indicated on the main window above the start button where the phrase simulation running is displayed. Stop Button This button when pressed stops the simulation. All statistics files are closed and the simulation run is terminated. A new simulation must be started after the stop button is depressed. Pause Button This button pauses the simulation until the continue button is pressed. Continue Button This button continues the simulation after the pause button is pressed. The continue button will not work after the stop button is pressed. Draw Button This button updates the graphics on the main window and the 3D graphics window. Level Change Box The level change box contains the current level number of the grid that is displayed in the main window. This number can be changed by pressing on the up or down arrows. Typing a new number into the box will also change the level. Configuration Menu The Configuration menu displays the simulation parameters dialog box which can be used to change system parameters during simulation execution. The dialog box that contains the simulation parameters is portrayed in the next figure. 76

PAGE 87

Control Setup Parameters (I l -EngineCcri'oiPar.neters logging Mamun No. ci Veticles .r OK Compt1er ROtie Update lrterval r li7 Statistics Logging On Cancel Vencle Raue Re(J.IeSt}!ec f28 r Error Loggi'lg On P Raue Trace Grid DraM.g No. of sees r -Rote. CaJ1MterParameters !Grid Parameters DebuJLevel Grid S(Jae Side Size in Feet lsoo Maxilun No. ol Vehcles: in Queue 110000 Grid Level Size in Feet 1500 Routes Proc:es:sed per Second Tine l!iertral +I [sees) r Penci'lg Queue Size J10000 Level! Used po-Pre-schedtJe Max Tine Lookahead J60 MaxVetlc:le! Per Level J100 Nodes in Grid layoot V.-1.!-L.. u _. 1= random. 2 c: Oerwer. 3,. 2 + 1. 4 =To each CI'LIC I'IUYCOI ... Il .... ..-.... ... I.;) node in gid node layoU: VencleArrival Disbidion 1 .. Go to Desmtion. 2 Leave from I' Destination R.:Ue leYel Options p 1 =5eq.2=Random,3(alway\$Uatat1) Figure A-2: Simulation Parameters Dialog Box The fields on the dialog oox are identified in as follows: Field Value Field Description Maximum number of vehicles This parameter identifies how many vehicles will be created during the simulation. Computer Route Update Interval This value represents the number of seconds between route generation, i.e. the 77

PAGE 88

Field Value Field Description master computer will only process route requests every x seconds where x is the value specified in this field. Vehicle Route Requests per Second The value in this field reflects the rate at which vehicles are created by the simulation. It represents the arrival rate of vehicles into the system. Grid Drawing Every Nwnber of Seconds This value is the interval between automatic grid updates on the user screen. The larger the nwnber, the fewer screen updates. If this parameter is too low, the simulation will slow because it has to wait while the screen is updated. Screen updates can require significant time to update ifthere are a large nwnber of vehicles present. Normal Logging On If the checkbox is checked, then logging to a file is performed to validate simulation state changes. Statistics Logging On When checked, this parameter indicates that statistics are logged for analysis. Error Logging On When checked, system errors are logged and additional detail is generated. Pre-scheduling On When checked, the simulation will perform pre-scheduling for vehicles requesting routes. Debug Level This nwnerical data indicates the debug level. lfError Checking is checked then debug information is output to a log file. Debug levels 1 4 are available. Smaller nwnbers represent less log data Data is output to a file called Engine.log Maximwn nwnber of vehicles in queue This parameter rep_resents the maximwn 78

PAGE 89

Field Value Routes Processed per second Pending Request Queue Size Pre-scheduled max lookahead time Grid Square Side in square feet Grid Level Size in Feet Time interval+/seconds 79 Field Description number of vehicles that can be created by the system. If during the course of simulation this number is exceeded, vehicles will not be created until other vehicles have completed to their destination. This parameter represents the number of route requests processed each second by the master computer. Ifthis number is less than the vehicle arrival rate, then queuing will occur before route congestion occurs. For optimal execution ofthe simulation, it is recommended that this value is always equal to or greater than the arrival rate. This is the size ofthe pending request queue. The pending request queue is where the master computer stores route requests from vehicles. It processes each request in the order it is received. If the number of requests exceeds this value the requests are denied. This value represents the maximum amount oftime the scheduler will look ahead into time to see if a route is available for a vehicle. This is the horizontal distance of a chronoscube in feet. The default value is 500 feet. This value represents the vertical component ofthe chronoscube in feet. The default value is 500 feet. The time interval value is considered the fourth dimensional component of the chronoscube and represents the guard

PAGE 90

Field Value Levels Used Max Vehicles per level Nodes in Grid Layout Vehicle Movement Options Vehicle Arrival Distribution 80 Field Description time of the cube. If a vehicle reserves a cube, the cube is unavailable for the period of time it takes a vehicle to travel through the cube, plus the guard time. The default guard time is 5 seconds. The value in this field is the maximum number of levels available to a vehicle when traversing the grid. The default is 20. To reduce congestion on a level, this parameter can be used to restrict the number ofvehicles that can be allocated to a level at any given time. This value is the number of nodes in the grid that vehicles might traverse to or away from. This parameter is used to simulate city locations or potential congestion points. This number can be from 1 to 10. This parameter describes how a vehicle will wish to travel on the grid The value 1 is for total random traffic. The value 2 is for traffic similar to Denver traffic during rush hour. The value 3 is for Denver traffic during rush hour with random traffic added. The value 4 is for traffic moving towards the nodes defined by the "Nodes in Grid Layout Parameter". This parameter defines how vehicles move. If the value is 1, vehicles move from origin to destination. If it is 2, vehicles move in the opposite direction.

PAGE 91

Field Value Field Description Route Level Assignment Option This option describes how the master computer assigns levels to a route. A value of 1 indicates sequential assignment after a base level is calculated based on distance to travel. A value of 2 indicates random assignment after a base level is calculated based on distance to travel. A value of 3 indicates that all vehicle routes are searched for from level 1 sequentially. 81

PAGE 92

APPENDIX B CODE LISTINGS The code listings are contained on the following pages.for the 3D vehicle scheduling simulation. The table below identifies the listings and their purpose. Program Name Purpose/Function Reference 3DgridView.cpp This source file contains the 3D 84 object drawing methods to display the simulation of vehicles moving in 3D-space. Control Dialog.cpp This file contains the objects to 98 draw and maintain the simulation control dialog box. Control Dialog.hpp This file contains the object 101 definitions for the simulation control dialog box. Engine.cpp This file contains the simulation 103 engine object methods that drive the 3D simulation. The engine is executed as a separate task. It creates the vehicles and calls the master computer to create routes. Once a route is created, it moves the vehicles. Engine.hpp This file contains the object 109 definitions for the simulation engine object for file Engine.cpp. Globals.hpp This file contains global 112 variables that are used to 82

PAGE 93

Pr02ram Name Purpose/Function Reference configure all modules ofthe simulation. Grid.cpp This file contains the objects 114 related to the 3D grid that represents the 3D airspace where routes are created and vehicles move through. Grid.hpp This file contains the grid object 150 definitions for file Grid.cpp Gridtest.cpp This file contains the objects for 156 the graphical user interface and the event routines that are used to drive the simulation. RouteMasterComputer.cpp This file contains the objects for 176 the master computer that assigns routes and updates the grid when a vehicle moves through a chronoscube. RouteMasterComputer.hpp This file contains the object 182 definitions for the master computer and route request queues for file RouteMasterComputer.cpp V ehicle.cpp This file contains the vehicle 185 object methods that create, move and signal vehicle movement to the master computer. Vehicle.hpp This file contains the vehicle 198 object definitions for file vehicle.cpp. 83

PAGE 94

11---------------------------------------------------------------------------I I Project Vehicle Simulator I I I I Copyright 1997. All Rights Reserved. II II SUBSYSTEM: 3D Route Viewer II FILE: 3DgridView.cpp II AUTHOR: Bret A. Godwin II DATE: November 1997 II II OVERVIEW II -------II OpenGL API calls to display the 3D routes and vehicle movement II //-------------------------------------------------------------------------iinclude iinclude "opengl testapp.h" iinclude "opengl testwindowview.h" iinclude iinclude iinclude "controldialog.h" iinclude "vehicle.hpp" iinclude "engine.hpp" const GRIDRANGE = float((GRIDMAX+50)/2); const LEVELRANGE = 200.0f; const STEPSIZE = O.Sf ; const STEPQTY = GRIDRANGE I STEPSIZE; II Rotation amounts static GLfloat xRot 295.0f; static GLfloat yRot c O .Of; static GLfloat zRot 310 .0f; static GLfloat xnew[10),ynew[10), znew[10), xnew2[10), ynew2[10); static GLfloat xShift, yShift; static LOGFONT MainFontRec; static TFont *sfont1; static TFont *sfont2; //extern ControlDialogXfer ControlDialogData; II Forward declarations void GLResize(GLsizei w, GLsizei h); void GLRenderScene(void *pData); void GLSetupRC(void *pData); extern MyCriticalSection EngineLock; II II Build a response table for all messages/commands handled by the application. II iif defined(ENGINERUN) 84

PAGE 95

DEFINE RESPONSE TABLEl(TOpenGL TestWindowView, TWindow) telse --DEFINE RESPONSE TABLEl(TOpenGL TestWindowView, TWindowView) tendifII!{TOpenGL TestWindowViewRSP TBL BEGIN}) EV_WM_CREATE, -EV_WM_DESTROY, EV_WM_ERASEBKGND, EV_WM_PAINT, EV_WM_SIZE, EV_WM_QUERYNEWPALETTE, EV_WM_PALETTECHANGED, EV_WM_TIMER, EV_WM_KEYDOWN, EV_WM_RBUTTONUP, EV_WM_LBUTTONUP, EV WM ACTIVATE, tif defined(ENGINERUN) EV MESSAGE(l033,EvRotate), tendif II{{TOpenGL TestWindowViewRSP TBL END)) END_RESPONSE_TABLE; -//{{TOpenGL_TestWindowView Implementation}} 11-------------------------------------------------------ll TOpenGL_TestWindowView II ---------11 Construction/Destruction handling. II tif defined(ENGINERUN) TOpenGL TestWindowView::TOpenGL TestWindowView(TWindow *parent, char *title) : TWindow(parent,titlel telse TOpenGL TestWindowView::TOpenGL TestWindowView(TDocument& doc, TWindow* parent) : TWindowView(doc, parent) tendif { Attr.Style I= (WS_VISIBLE Attr.W 600; Attr.H 600; Attr.X 0; Attr.Y 0; m_pPalette = NULL; m_hDC = NULL; CS_OWNDC); TOpenGL TestWindowView::-TOpenGL TestWindowView() { --Destroy (); delete m_pPalette; void TOpenGL_TestWindowView::EVClose() { tif defined(ENGINERUN) TWindow::EvClose(); telse TWindowView::EVClose(); tendif 85

PAGE 96

delete myDC; II INSERT>> Your code here. int TOpenGL TestWindowView::EvCreate(CREATESTRUCT far& createStruct) { -int result; *if defined(ENGINERUN) result= TWindow::EvCreate(createStruct); *else createStruct.style 1= (WS CLIPCHILDREN I WS CLIPSIBLINGS result= TWindowView::EvCreate(createStruct); *endif II Select pixel format/rendering context CS_OWNDC); static PIXELFORMATDESCRIPTOR pfd = { sizeof(PIXELFORMATDESCRIPTOR), 1, II Size of this structure II Version of this structure PFD DRAW TO WINDOW I (not to bitmap) --PFD SUPPORT OPENGL calls in window PFD_DOUBLEBUFFER, buffered mode !/ PFD_SUPPORT_GDI, PFD_TYPE_RGBA, Color mode 16, II Want 16 bit color 0,0,0,0,0,0, to select mode 0,0, II Not used to select mode 0,0,0,0,0, Not used to select mode 16, II Size of depth buffer 0, main plane II Not used to select mode 0, II Not used to select mode PFD_MAIN_PLANE, 0, II Not used to select mode 0, 0, 0 ) ; II Not used to select mode II Get the device context II Support for GDI mode m_hDC = ::GetDC(this->GetHandle()); myDC =new TDC(m_hDC); II Draw to Window II Support OpenGL II Double II RGBA II Not used II II Draw in II Choose a pixel format that best matches that described in pfd int nPixelFormat = ChoosePixelFormat(m_hDC, &pfd); II Set the pixel format for the device context SetPixelFormat(m_hDC, nPixelFormat, &pfd); II Create a 3-3-2 palette SetupPalette(m_hDC); 86

PAGE 97

II Create the rendering context m_hRC = wglCreateContext(m_hDC); II Make the rendering context current and perform initializion. wglMakeCurrent(m hDC,m hRC); GLSetupRC(m_hDC); randomize(); for (int i=O; i < 10; i++) { xnew[i] = random(400) -GRIDRANGE; ynew[i] = random(400) -GRIDRANGE; xnew2[i] = random(400) -GRIDRANGE; ynew2[i] random(400) -GRIDRANGE; znew[i] = random(200); yShift xShift O.Of; O.Of; MainFontRec.lfHeight = 6; MainFontRec.lfWidth = 4; MainFontRec.lfEscapement = 0; MainFontRec.lfOrientation = 0; MainFontRec.lfWeight = FW BOLD; MainFontRec.lfitalic = 0; MainFontRec.lfUnderline = 0; MainFontRec.lfStrikeOut = 0; MainFontRec.lfCharSet = ANSI CHARSET; MainFontRec.lfOutPrecision =-OUT DEFAULT PRECIS; MainFontRec.lfClipPrecision = CLIP DEFAULT PRECIS; MainFontRec.lfQuality = PROOF QUALITY; -MainFontRec.lfPitchAndFamily VARIABLE PITCH I FF ROMAN; strcpy(MainFontRec.lfFaceName, ftTimes New Romanft);-*I sfontl =new TFont(&MainFontRec); MainFontRec.lfHeight = 12; MainFontRec.lfWidth = 6; sfont2 =new TFont(&MainFontRec); return result; void TOpenGL_TestWindowView::EvDestroy() { II Free the rendering context wglMakeCurrent(NULL,NULL); wglDeleteContext(m_hRC); II Release the device context ::ReleaseDC(this->GetHandle(),m_hDC); #if defined(ENGINERUN) TWindow::EvDestroy(); *else TWindowView::EvDestroy(); #endif ) 87

PAGE 98

bool TOpenGL_TestWindowView::EvEraseBkgnd(HDC de) { bool result; return false; void TOpenGL_TestWindowView::EvPaint() { II Make the rendering context current, and call OpenGL Rendering code EngineLock.Lock(); wglMakeCurrent(m hDC,m hRC); II myDC->SelectObj ect (*sfont2 J ; GLRenderScene(NULL); wglMakeCurrent(NULL,m_hRC); II Finally swap buffers since this rendering context is double buffered SwapBuffers(m_hDCJ; II Do NOT Validate the window Validate(); EngineLock.Unlock(); void TOpenGL_TestWindowView::EvSize(uint sizeType, TSize& size) { GLsizei w, h; lif defined(ENGINERUN) TWindow::EvSize(sizeType, size); lelse TWindowView::EvSize(sizeType, size); llendif w size.cx; h size.cy; II Make the rendering context current, and call function II to make adjustments to OpenGL viewport wglMakeCurrent(m hDC,m hRC); GLResize(w,h); -wglMakeCurrent(m_hDC,NULL); bool TOpenGL_TestWindowView::EvQueryNewPalette() { bool result; II Only if palette was created if(m_pPalette !=NULL) { int nRet; II Select the palette into the current device context if(SelectPalette(m hOC, m pPalette->GetHandle(J,FALSEJ ==NULL) ::MessageBo-x(NULL,"cannot select Palette","Error",MB_OK); II Map entries from the currently selected palette to II the system palette. The return value is the number 88

PAGE 99

II of palette entries modified. nRet = RealizePalette(m_hDC); II Repaint, forces remap of palette in current window Invalidate(); return nRet; } II Call default function result= TWindow::EvQueryNewPalette(); return result; void TOpenGL_TestWindowView::EvPaletteChanged(THandle hWndPalChg) { II Only if palette created, or not this window if((m_pPalette !=NULL) && (hWndPalChg != this->HWindow)) { II Select the palette into the device context ::SelectPalette(m_hDC,m_pPalette->GetHandle(),FALSE); II Map entries to system palette ::RealizePalette(m_hDC); II Remap the current colors to the newly realized palette ::UpdateColors(m_hDC); return; } II Call default handler TWindow::EvPaletteChanged(hWndPalChg); void TOpenGL TestWindowView::EvTimer(uint timerid) { tif defined(ENGINERUN) TWindow::EvTimer(timerid); telse TWindowView::EvTimer(timerid); tendif II INSERT>> Your code here. II Create the palette if necessary void TOpenGL TestWindowView::SetupPalette(HDC hOC) { PIXELFORMATDESCRIPTOR pfd; II Pixel Format Descriptor LOGPALETTE *pPal; II Pointer to memory for logical int nPixelFormat; II Pixel format index int nColors; II Number of entries in palette int i; II Counting variable BYTE RedRange,GreenRange,BlueRange; II Range for each color entrys palette II ( 7 7 and 3 ) II Get the pixel format index and retrieve the pixel format description nPixelFormat = GetPixelFormat(hDC); DescribePixelFormat(hDC, nPixelFormat, sizeof(PIXELFORMATDESCRIPTOR), &pfd); II Does this pixel format require a palette? If not, do not create a II palette and just return 89

PAGE 100

if(! (pfd.dwFlags & PFD_NEED_PALETTE)l return; II Number of entries in palette. 8 bits yeilds 256 entries nColors = 1 << pfd.cColorBits; II Allocate space for a logical palette structure plus all the II palette entries pPal = (LOGPALETTE*)malloc(sizeof(LOGPALETTE) +nColors*sizeof(PALETTEENTRY)); II Fill in palette header pPal->palVersion = Ox300; pPal->palNumEntries = nColors; II Windows 3.0 II table size II Build mask of all 1's. This creates a number represented by having II the low order x set, where x = pfd.cRedBits, pfd.cGreenBits, and II pfd.cBlueBits. RedRange = (1 << pfd.cRedBits) -1; GreenRange = (1 << pfd.cGreenBits) -1; BlueRange = (1 << pfd.cBlueBits) -1; II Loop through all the palette entries for(i = 0; i < nColors; i++) { II Fill in the 8-bit equivalents for each component pPal->palPalEntry[i] .peRed = (i >> pfd.cRedShift) & RedRange; pPal->palPalEntry[i] .peRed = (unsigned char) ( (double) pPal->palPalEntry[i] .peRed 255.0 I RedRange); pPal->palPalEntry[i].peGreen = (i >> pfd.cGreenShift) & GreenRange; pPal->palPalEntry[i].peGreen = (unsigned char) ( (double)pPal->palPalEntry[i] .peGreen 255.0 I GreenRange); pPal->palPalEntry[i].peBlue = (i >> pfd.cBlueShift) & BlueRange; pPal->palPalEntry[i].peBlue = (unsigned char) ( (double)pPal->palPalEntry[i].peBlue 255.0 I BlueRange); pPal->palPalEntry[i].peFlags = (unsigned char) NULL; } II Create the palette m_pPalette =new TPalette(pPal); II Go ahead and select and realize the palette for this device context if(SelectPalette(hDC,m pPalette->GetHandle(),FALSEl ==NULL) ::MessageBox(NULL,"Cannot select Palette in Palette Creation", "Error",MB_OK); if(RealizePalette(hDC) ==NULL) ::MessageBox(NULL,"Cannot realize Palette in Palette Creation", "Error" ,MB_OK); II Free the memory used for the logical palette structure free(pPal); void GLSetupRC(void *pData) ( GLfloat GLfloat GLfloat GLfloat GLfloat ambientLight[] = {0.4f, 0.4f, 0.4f, l.Of }; diffuseLight[] = {0.7f, 0.7f, 0.7f, l.Of }; specular[] = { 0.9f, 0.9f, 0.9f, l.Of}; lightPos[] { -50.0f, 200.0f, 200.0f, l.Of }; specref[] = I 0.6f, 0.6f, 0.6f, l.Of }; 90

PAGE 101

II object glEnable(GL DEPTH TEST); glEnable(GL=CULL_FACE); II Enable lighting glEnable(GL_LIGHTING); II Setup light 0 II Hidden surface removal II Do not calculate inside of solid glLightModelfv(GL LIGHT MODEL AMBIENT,ambientLight); glLightfv(GL LIGHTO,GL AMBIENT,ambientLight); glLightfv(GL-LIGHTO,GL-DIFFUSE,diffuseLight); glLightfv(GL=LIGHTO,GL=SPECULAR,specular); II Position and turn on the light glLightfv(GL LIGHTO,GL POSITION,lightPos); glEnable(GL_LIGHTO); II Enable color tracking glEnable(GL_COLOR_MATERIAL); II Set Material properties to follow glColor values glColorMaterial(GL_FRONT, GL_AMBIENT_AND_DIFFUSE); II All materials hereafter have full specular reflectivity II with a moderate shine glMaterialfv(GL FRONT, GL SPECULAR,specref); g1Materiali(GL_FRONT,GL_SHININESS,64); II Black background glClearColor(O.lf, O.lf, O.lf, l.Of ); void TOpenGL TestWindowView::GLRenderScene(void *pData) { -RECT rect; GLfloat xmid, yrnid, facing; TPoint p; GLfloat xnew2, xnew, ynew2, ynew, znew, znew2, gridoffset; glClear(GL_COLOR_BUFFER_BIT I I glEnable (GL_CULL_FACEl; II glEnable(GL_DEPTH_TEST); II Set drawing color to green g1Color3f(0.5f, O.Sf, O.Sf); GL_DEPTH_BUFFER_BIT); II Save matrix state and do the rotation glPushMatrix ( l; glTranslatef(O.Of,yShift,O.Of); glRotatef(xRot, l.Of, O.Of, O.Of); glRotatef(yRot, O.Of, l.Of, O.Ofl; glRotatef (zRot, O.Of, O.Of, l.Ofl; II X-axis grid for(int i=O; i <= 1; i++) { glPushMatrix (); 91

PAGE 102

glTranslatef(-GRIDRANGE+(i 500.0f),O.Of,O.Of); glBegin(GL LINE STRIP); g1Yertex-3d( O.Of, GRIDRANGE, O.Of); g1Vertex3d( O.Of, GRIDRANGE, LEVELRANGE); g1Vertex3d( O.Of, -GRIDRANGE, LEVELRANGE); g1Vertex3d( O.Of, -GRIDRANGE, O.Of); g1Vertex3d( O.Of, GRIDRANGE, O.Of); glEnd(); glPopMatrix(); II y-axis grid for(int i=O; i <= 1; i++) { I glPushMatrix(); glTranslatef (0. Of, 0. Of, (i LEVELRANGE)); g1Rotatef(90.0f, O.Of,l.Of,O.Of); glBegin(GL LINE STRIP); g1Vertex-3d( O.Of, GRIDRANGE, -GRIDRANGE); g1Vertex3d( O.Of, GRIDRANGE, GRIDRANGE); g1Vertex3d( O.Of, -GRIDRANGE, GRIDRANGE); g1Vertex3d( O.Of, -GRIDRANGE, -GRIDRANGE); g1Vertex3d( O.Of, GRIDRANGE, -GRIDRANGE); glEnd(); glPopMatrix(); glPushMatrix(); llg1Rotatef(90.0f, O.Of,1.0f,O.Of); glRectf(-GRIDRANGE,-GRIDRANGE,GRIDRANGE,GRIDRANGE); glPopMatrix(); II z-axis grid for(int i=O; i <= 1; i++) { glPushMatrix(); glTranslatef(O.Of,-GRIDRANGE+(i 500.0f),0.0f); g1Rotatef(90.0f, O.Of,O.Of,1.0f); glBegin(GL LINE STRIP); glVerteX:3d( O.Of, GRIDRANGE, O.Of); g1Vertex3d( O.Of, GRIDRANGE, LEVELRANGE); g1Vertex3d( O.Of, -GRIDRANGE, LEVELRANGE); g1Vertex3d( O.Of, -GRIDRANGE, O.Of); g1Vertex3d( O.Of, GRIDRANGE, O.Of); glEnd (); glPopMatrix(); ) vehiclePointer v; int id; list::iterator vlp = ((Engine *)SimulationPtr) >getVehicleList() .begin(); list::iterator vlpend = ((Engine *)SimulationPtr) >getVehicleList().end(); if(! ((Engine *)SimulationPtr)->getVehicleList() .empty()) do { v = *vlp++; 92

PAGE 103

id = v->getiD(); gridoffset = GRIDMAX I 2; xnew = v->getVehiclePosition().getintegerX() -gridoffset; xnew2 = v->getDestination() .getintegerX() -gridoffset; ynew = v->getVehiclePosition() .getintegerY() -gridoffset; ynew2 = v->getDestination() .getintegerY() -gridoffset; znew = v->getVehiclePosition() .getintegerZ() I LEVELSIZE 10; znew2 = v->getLevel() 10; if (!v->waitingForARoute() && routeDisplayFlag) ( if (v->getDirectionMovingin() <= 1) { g1Color3f(O.Of,O.Of,1.0f); II blue going up glBegin(GL LINES); g1Vertex3f(xnew,ynew,znew); g1Vertex3f(xnew,ynew,znew2); glEnd(); if (v->getDirectionMovingin() <= 2) { g1Color3f(1.0f,O.Of,O.Of); II red going across glBegin(GL LINES); g1Vertex3f(xnew,ynew,znew2); g1Vertex3f(xnew2,ynew2,znew2); glEnd (); if (v->getDirectionMovingin() < 3) znew = znew2; if (v->getDirectionMovingin() <= 3) { } } g1Color3f(O.Of,1.0f,O.Of); II green coming down glBegin(GL LINES); g1Vertex3f(xnew2,ynew2,znew); g1Vertex3f(xnew2,ynew2,0.0f); glEnd(); glPushMatrix(); xnew = v->getVehiclePosition().getintegerX() -gridoffset; ynew = v->getVehiclePosition() .getintegerY() -gridoffset; znew = v->getVehiclePosition() .getintegerZ() I LEVELSIZE 10; glTranslatef(xnew,ynew,znew); g1Color3f(1.0f,1.0f,1.0f); if (v->getDirectionMovingln () 1) { g1Color3f(O.Of,1.0f,1.0f); else if (v->getDirectionMovingln () 3) { g1Color3f(l.Of,O.Of,l.Of); glRotatef(lBO.Of,l.Of,O.Of,O.Of); else if (v->getDirectionMovingln() 2) { g1Color3f(l.Of,1.0f,O.Of); if (xnew2 == xnew) { if (ynew2 < ynew) 93

PAGE 104

facing else facing else ( -90.0f; 90.0f; facing= atan((ynew2-ynew)l(xnew2-xnew)); facing *= 180.0fl3.1415f; if ( (xnew2 < xnew)) facing= (facing); glRotatef(facing,O.Of,O.Of,l.Of); if ( (xnew2 < xnew)) g1Rotatef(-90.0f,O.Of,l.Of,O.Of); else g1Rotatef(90.0f,O.Of,l.Of,O.Of); auxSolidCone(5.0f,8.0f); II Restore transformations glPopMatrix(); l while (vlp != vlpend); II myDC->GetCurrentPosition(p); II myDC->TextOut(p,"Object ID",9); II x-axis glPushMatrix(); g1Color3f(l.Of,O.Of,O.Of); glTranslatef(GRIDRANGE,O.Of,O.Of); auxSolidSphere(5.0f); glPopMatrix(); II y -axis glPushMatrix(); g1Color3f(O.Of,O.Of,l.Of); glTranslatef(O.Of,GRIDRANGE,O.Of); auxSolidSphere(5.0f); glPopMatrix(); II z -axis glPushMatrix(); g1Color3f(O.Of,l.Of,O.Of); glTranslatef(O.Of,O.Of,LEVELRANGE); auxSolidSphere(5.0f); glPopMatrix(); glPopMatrix(); II Flush drawing commands glFlush (); void GLResize(GLsizei w, GLsizei h) { GLfloat nRange = GRIDRANGE; 94

PAGE 105

II Prevent a divide by zero if(h == 0) if(w == 0) w = 1; h = 1; II Set Viewport to window dimensions glViewport(O, 0, w, h); II Reset coordinate system glMatrixMode(GL PROJECTION); glLoadidentity(J; II Establish clipping volume (left, right, bottom, top, near, far) if (W <= h) glOrtho (-nRange*l.S, nRange*1.5, -nRange*hlw*1.5, nRange*hlw*1.5, -nRange*2.0, nRange*2.0); else glOrtho (-nRange*wlh*1.5, nRange*wlh*1.5, -nRange*1.5, nRange*1.5, -nRange*2.0, nRange*2.0); glMatrixMode(GL MODELVIEW); glLoadidentity(J; I void TOpenGL_TestWindowView::EvKeyDown(uint nChar, uint repeatCount, uint flags) { II TWindowView::EvKeyDown(nChar, repeatCount, flags); if(nChar == VK UP) xRot-= -5.0f; if(nChar == VK DOWN) xRot +,: S.Of; if(nChar == VK LEFT) yRot -=-S.Of; if(nChar == VK RIGHT) yRot +=-S.Of; if(nChar == VK PRIOR) zRot _,: S.Of; if(nChar == VK HOME) zRot +=-S.Of; if(nChar == VK INSERT) yShift -+= GRIDRANGEI2.0f; if(nChar == VK DELETE) yShift --= GRIDRANGEI2. Of; if(xRot > 356.0fl xRot = O.Of; if(xRot < -l.Ofl xRot = 355.0f; if(yRot > 356.0fl yRot = O.Of; 95

PAGE 106

if(yRot < -l.Of) yRot = 355.0f; if(zRot > 356.0f) zRot = O.Of; if(zRot < -l.Of) zRot = 355.0f; Invalidate(FALSE); void TOpenGL_TestWindowView::EvRButtonUp(uint modKeys, TPoint& point) { II TWindowView::EvRButtonUp(modKeys, point); II int test; II ControlDialog myTest(this,IDD_CONTROL); II myTest.Execute(); II test= atoi(ControlDialogData.el); I* zRot+= 5.0f; *I ) if(zRot > 356.0f) zRot = O.Of; if(zRot < -l.Of) zRot = 355.0f; Invalidate(FALSE); void TOpenGL_TestWindowView::EvLButtonUp(uint modKeys, TPoint& point) { II TWindowView::EvLButtonUp(modKeys, point); II zRot-= 5.0f; if(zRot > 356.0f) zRot = O.Of; if(zRot < -l.Of) zRot = 355.0f; Invalidate(FALSE); void TOpenGL_TestWindowView::EvActivate(uint active, bool minimized, THandle hWndOther ) { II TWindowView::EvActivate(active, minimized, hWndOther ); SetFocus(); 96

PAGE 107

#if defined(ENGINERUN) LRESULT TOpenGL TestWindowView::EvRotate(WPARAM,LPARAM) { -//zRot += 30.0f; Invalidate(FALSE); ) #endif 97

PAGE 108

//---------------------------------------------------------------------------II Project Vehicle Simulator II Copyright 1997. All Rights Reserved. II II II II II II SUBSYSTEM: FILE: Simulation Control Dialog Box object Control Dialog.cpp AUTHOR: Bret A. Godwin DATE: November 1997 II II OVERVIEW II -------II Provides the object controls for the simulation parameters. II /1----------------------------------------------------------------------------#include #include .. \source\controldialog.h" #include "globals.hpp" //{{ControlDialog Implementation}} ControlDialogXfer ControlDialogData; ControlDialog::ControlDialog(TWindow* parent, TResid resid, TModule* module) TDialog(parent, resid, module) { //{{ControlDialogXFER USE}} el new IDC EDITl, 255); e2 new TEdit(this, IDC-EDIT2, 255); e3 new TEdit{this, IDC-EDIT3, 255); e4 new TEdit(this, IDC-EDIT4, 255); Logging= new TCheckBox(this, IDC CHECKBOX!, 0); statLogging =new TCheckBox(this,-IDC CHECKBOX2, 0); errorLogging =new TCheckBox(this, IDC CHECKBOX3, 0); routeDisplayBox = new TCheckBox(this,-IDC CHECKBOX4, 0); e5 new TEdit(this, IDC EDITS, 255); -e6 =new TEdit(this, IDC-EDIT6, 255); e7 =new TEdit(this, IDC-EDIT7, 255); ell= new TEdit(this, IDC EDITll, 255); e8 =new TEdit(this, IDC EDITS, 255); e9 =new TEdit(this, IDC-EDIT9, 255); elO new TEdit(this, IDC EDITlO, 255); el2 new TEdit(this, IDC-EDIT12, 255); el3 new TEdit(this, IDC-EDIT13, 255); el4 new TEdit(this, IDC-EDIT14, 255); el5 new TEdit(this, IDC-EDIT15, 255); el6 new TEdit(this, IDC-EDIT16, 255); el7 new TEdit(this, IDC=EDIT17, 255); strcpy(ControlDialogData.el,"lOOO"); strcpy(ControlDialogData.e2,"1"); strcpy(ControlDialogData.e3,"28"); strcpy(ControlDialogData.e4,"5"); ControlDialogData.Logging = 0; 98 //Total Vehicles requesting //Route compute update intv //Vehicle requests/sec //Draw update cycle.

PAGE 109

ControlDialogData.statLogging = 1; ControlDialogData.errorLogging = 0; ControlDialogData.routeDisplayFlag = 1; strcpy(ControlDialogData.e5,"999"); strcpy(ControlDialogData.e6,"10000"); strcpy(ControlDialogData.e7,"50"); strcpy(ControlDialogData.e8,"500"); strcpy(ControlDialogData.e9,"500"); strcpy(ControlDialogData.el0,"5"); strcpy(ControlDialogData.ell,"lOOOO"); strcpy(ControlDialogData.el2,"20"); strcpy(ControlDialogData.el3,"100"); strcpy(ControlDialogData.el4,"3"); strcpy(ControlDialogData.el5,"3"); strcpy(ControlDialogData.el6,"1"); strcpy(ControlDialogData.el7,"3"); SetTransferBuffer(&ControlDialogData); //{{ControlDialogXFER_USE_END)) II INSERT>> Your constructor code here. ControlDialog::-ControlDialog() { Destroy(IDCANCEL); II INSERT>> Your destructor code here. void ControlDialog::SetupWindow() { TDialog::SetupWindow(); II INSERT>> Your code here. boo! ControlDialog::CanClose() { boo! result; return true; void ControlDialog::CloseWindow(int retValue) { TDialog::CloseWindow(retValue); //debug level TOTVEHREQ = atoi(ControlDialogData.el); ROUTCOMPUPDATINTV = atoi(ControlDialogData.e2); VEHREQPERSEC = atoi(ControlDialogData.e3); DRAWUPDATINTVSEC = atoi(ControlDialogData.e4); debugLevel = atoi(ControlDialogData.e5); 99

PAGE 110

NUMOBJ = OBJQSIZE = atoi(ControlDialogData.e6); PROCREQPERSEC = atoi(ControlDialogData.e7); SQUAREFEET = atoi(ControlDialogData.e8); LEVELSIZE = atoi(ControlDialogData.e9); ETASECSWINDOW = atoi(ControlDialogData.elO); PENDQSIZE = atoi(ControlDialogData.ell); loggingon =ControlDialogData.Logging; statsloggingOn = ControlDialogData.statLogging; errorLoggingOn = ControlDialogData.errorLogging; routeDisplayFlag = ControlDialogData.routeDisplayFlag; LevelsUsed = atoi(ControlDialogData.el2); maxLevelDistribution = atoi(ControlDialogData.el3); gridLayoutType = atoi(ControlDialogData.el4); vMovmentOptions = atoi(ControlDialogData.el5); vArrivalOptions = atoi(ControlDialogData.el6); routeLevelOptions = atoi(ControlDialogData.el7); 100

PAGE 111

11---------------------------------------------------------------------------II Project Vehicle Simulator II II Copyright 1997. All Rights Reserved. II II SUBSYSTEM: Control Dialog II FILE: Control Dialog.hpp II AUTHOR: Bret A. Godwin II DATE: November 1997 II II OVERVIEW II -------II Control Dialog header file II 11---------------------------------------------------------------------------lif !defined(controldialog h) already included. ldefine controldialog_h linclude linclude .. IProjectslnewdlg.rh" linclude linclude II{{TDialog = ControlDialog)) struct ControlDialogXfer { II{{ControlDialogXFER_DATA)) char e1[ 255 l ; char e2[ 255 l ; char e3[ 255 l ; char e4[ 255 l ; ushort Logging; ushort statLogging; ushort errorLogging; ushort routeDisplayFlag; char e5 [ 255 l; char e6 [ 255 l; char e7[ 255 l; char ell[ 255 l; char e8[ 255 l; char e9[ 255 l; char elO[ 255 l; char e12[ 255 l ; char el3 [ 255 l; char e14 [ 255 l ; char e15[ 255 l; char e16 [ 255 l; char e17[ 255 l; II{{ControlDialogXFER_DATA_END)) II Sentry, use file only if it's not II Definition of all resources. 101

PAGE 112

}; class ControlDialog : public TDialog { public: ControlDialog(TWindow* parent, TResid resid virtual -controlDialog(}; II{{ControlDialogVIRTUAL BEGIN}} public: -virtual void SetupWindow(); virtual bool CanClose(); void CloseWindow(int retValue II{{ControlDialogVIRTUAL_END}} II{{ControlDialogXFER DEF}} protected: TCheckBox* Logging; TCheckBox* TCheckBox* TCheckBox* TEdit* el; TEdit* elO; TEdit* ell; TEdit* e12; TEdit* e13; TEdit* e14; TEdit* e15; TEdit* e16; TEdit* e17; TEdit* e2; TEdit* e3; TEdit* e4; TEdit* e5; TEdit* e6; TEdit* e7; TEdit* e8; TEdit* e9; statLogging; errorLogging; routeDisplayBox; II{{ControlDialogXFER DEFEND}} l; 11 { {ControlDialog} l*endif II controldialog_h sentry. IDCANCEL); 102 IDD_CONTROL, TModule* module 0);

PAGE 113

11---------------------------------------------------------------------------II Project Vehicle Simulator II II Copyright 1997. All Rights Reserved. II II SUBSYSTEM: Simulation Engine II FILE: engine.cpp II AUTHOR: Bret A. Godwin II DATE: November 1997 II II OVERVIEW II -------II This file contains the simulation engine object methods that drive the 3D II simulation. The engine is executed as a separate task. It creates the vehicles II and calls the master computer to create routes. Once a route is created, it moves II the vehicles II 11---------------------------------------------------------------------------II This is the implementation file for the engine class of the 3d II routing simulation #include "engine.hpp" !!include extern "C" I !!include .. lssslsss.h" ) extern MyCriticalSection EngineLock; Engine::Enginel) I running = false; engineTerminate = false; void Engine::initEngine(TWindow* w) I it (running) return; driver = w; initialize(); void Engine::initialize() I grid.initGrid(LevelsUsed,GRIDSIZE,LEVELSIZE,SQUAREFEET,NUMOBJ); ControlCentral.initRouteMasterComputer(NUMOBJ,GRIDSIZE, PROCREQPERSEC,OBJQSIZE, 103

PAGE 114

PENDQSIZE,&grid); secondCounter = 0; nurnberOfRequestsPerSecond VEHREQPERSEC; vehicleRequestCounter 0; maxwaitseconds = 0; avgwaitseconds 0; avgmoveseconds 0; maxmoveseconds = 0; statcount = 0; running = false; engineTerrninate = false; II loggingon = false; II statsloggingOn = true; II errorLoggingOn = false; II debugLevel = 999; IIGRIDDEBUG; systemTime = 0; void Engine::cleanUp() { initialize(); EngineLock.Lock(); while (!vehicleList.empty()) vehicleList.pop front(); controlCentral.cleanUp(); EngineLock.Unlock(); void Engine::StartEngine() { II EngineGo = true; if (running) return; running = true; engineTerrninate z false; Start(); void Engine::RunEngine() { secondCounter++; systemTime++; generateuserRequests(); moveVehicles(); vqueueSize = getVehicleQueueSize(); if ((secondCounter% ROUTCOMPUPDATINTV) 0) { ControlCentral.processRequests(); if (statsloggingOn) if (getWaitQueueSize() > 0) qstatFile << "qe," << systemTime << "," << getVehicleQueueSize() << "," << getWaitQueueSize() << "," << end!; 104

PAGE 115

void Engine::StopEngine() { if ((GetStatus() ==Running) I I (GetStatus() engineTerminate = true; ControlCentral.stopMasterComputer(); WaitForExit(O); void Engine::Pause() { ControlCentral.pause(); if ((GetStatus() ==Running) I I (GetStatus() Suspend(); void Engine::Continue() ControlCentral.resume(); if (GetStatus() ==Suspended) Resume(); int Engine::Run() { int i = 0; randomize () ; if (loggingOn 1 1 statsloggingOn) { outFile.open("Engine.log"); if ( !outFile) loggingOn = false; statFile.open("statfile.csv"); if (! statFile) statsloggingOn = false; else { statFile << "qd," << "viD," << "vLevel," << "vXYdistance," << "waitseconds," << "wqueuesize," << "vqueueSize," << "systemtime," << "totalmoveseconds," << "maxwaitseconds," << "avgwaitseconds," << "maxmoveseconds," << "avgmoveseconds," << "statcount" << endl; statFile << "qa," << "viD," << "vLevel," << "vXYdistance," << "waitseconds," << "wqueuesize," << "vqueueSize ," << "systemtime" << endl; ) qstatFile.open("qstatfile.csv"); if ( qstatFile) 105 Suspended)) { Suspended))

PAGE 116

statsloggingon else { false; qstatFile << "rc,calcXYdistance" << "cntr," << "assignedLevel," << "ltf," << "viD" << end!; qstatFile << "qe,systemTime," << "routesreq," << "qsize," << end!; driver->PostMessage{l025,0,0); while(!engineTerminate) { if ((i% DRAWUPDATINTVSEC) == 0) { driver->PostMessage(l027,0,0); Sleep ( 1500); RunEngine(); if (vehicleList.empty()) engineTerminate = true; i++; if (loggingOn I I statsloggingOn) { //Update window with running II Update window outFile << "Normal File Close" << end!; outFile.close(); driver->PostMessage(1027,0,0); driver->PostMessage(1026,0,0); cleanUp(); return 0; void Engine::generateUserRequests() { int i; II Update window II Update window with stopped int vacc, vdecc, haec, hdecc, hvelmax, vvelmax; int id; char s[20]; hvelmax = 293; vvelmax = 88; II hvelmax = 600; II vvelmax = 172; vacc = vvelmax I 10; vdecc = vacc .75; haec = hvelmax I 20; hdecc = haec; vehicle *v; numberOfRequestsPerSecond = EX(VEHREQPERSEC); for(i=1; i<=numberOfRequestsPerSecond; i++) { vehicleRequestCounter++; if (vehicleRequestCounter > TOTVEHREQ) return; id = vehicleRequestCounter; 106

PAGE 117

v =new vehicle(vacc, vdecc, haec, hdecc, if (v) vehicleList.push_back(v); if (!v && errorLoggingOn) vvelmax, hvelmax, id, &ControlCentral); outFile << "Out of memory when allocating vehicles" << end!; II if (loggingOn) II outFile << *v << end!; I* while (!vehicleList.empty()) ( v = vehicleList.front(); id = v.getiD(); vehicleList.pop(); *I void Engine::moveVehicles() int id; vehiclePointer v; vehicleStats vs; objectCoord o, d; list ::iterator vehicleListPtr = vehicleList.begin(); list ::iterator vehicleListOldPtr = vehicleList.begin(); if (!vehicleList.empty()) do { v = *vehicleListPtr; vehicleListOldPtr = vehicleListPtr++; id = v->get!D(); v->moveVehicle(); if (v->atDestination()) { EngineLock.Lock(); vs = v->getVehicleStats(); maxwaitseconds max(int(maxwaitseconds),vs.waitseconds); avgwaitseconds (avgwaitseconds + vs.waitseconds); avgmoveseconds (avgmoveseconds + vs.totalmoveseconds); maxmoveseconds max(int(maxmoveseconds),vs.totalmoveseconds); statcount++; if (statsloggingOn) { outFile << *v << end!; outFile << "MaxWaitSec << maxwaitseconds << end! << "AvgWaitSec << avgwaitsecondslstatcount << end! << "MaxMoveSec << maxmoveseconds << end! << "AvgMoveSec << avgmovesecondslstatcount << end! << "statcount << statcount << end!; o = v->getOrigin(); d = v->getDestination(); statFile << "qd," << v->getiD() << "," << v->getLevel() << "," << v->calcXYdistance(o,d) << "," << vs.waitseconds << "," << getWaitQueueSize() << "," << vqueueSize << "," << systemTime << "," << 107

PAGE 118

vs.totalmoveseconds << "," << maxwaitseconds << "," << avgwaitseconds/statcount << " << maxmoveseconds << "," << avgmoveseconds/statcount << "," << statcount << endl; delete v; vehicleList.erase(vehicleListOldPtr); EngineLock.Unlock(); ) while (vehicleListPtr != vehicleList.end()); list &Engine::getVehicleList() { return vehicleList; gridobject *Engine::getGrid() { return &grid; bool Engine::isRunning() { return running; int Engine::getWaitQueueSize() { return ControlCentral.getWaitQueueSize(); ) int Engine::getVehicleQueueSize() { return vehicleList.size(); 108

PAGE 119

11---------------------------------------------------------------------------II Project Vehicle Simulator II II Copyright 1997. All Rights Reserved. II II SUBSYSTEM: Simulation Engine II FILE: engine.hpp II AUTHOR: Bret A. Godwin II DATE: November 1997 II II OVERVIEW II -------II This is the C++ header file for the engine that drives the II 3d routing simulation II 11---------------------------------------------------------------------------II this define sets the global parameters to be initialized by this source file #define globalset #include #include #include #include "vehicle.hpp" #include "RouteMasterComputer.hpp" #define RUNMSG WM USER+l using namespace std; class Engine : public TThread { public: int secondCounter; Engine (); void initEngine(TWindow* w); void StartEngine(); void RunEngine(); void StopEngine(); int Run(); void Pause () ; void Continue(); void generateUserRequests(); void moveVehicles(); list &getVehicleList(); gridobject *getGrid(); boo! isRunning(); void cleanUp(); int getWaitQueueSize(); int getVehicleQueueSize(); private: 109

PAGE 120

void initialize(); int timeinterval; int updateDisplayinterval; int activeVehicleQueueSize; TWindow *driver; boo! running; boo! engineTerminate; float maxwaitseconds; float avgwaitseconds; float avgmoveseconds; float maxmoveseconds; int statcount; II Engine configuration parameters int numberOfRequestsPerSecond; long vehicleRequestCounter; RouteMasterComputer ControlCentral; list vehicleList; gridobject grid; II list ::Inputiterator vehicleListPtr; }; class MyCriticalSection { }; public: MyCriticalSection(); -MyCriticalSection(); void Lock(); void Unlock(); private: CRITICAL SECTION CritSec; inline MyCriticalSection::MyCriticalSection() { ::InitializeCriticalSection(CONST_CAST(CRITICAL_SECTION*,&CritSec)); II II Use system call to destroy the CRITICAL_SECTION object. II inline MyCriticalSection::-MyCriticalSection() { ::DeleteCriticalSection(CONST_CAST(CRITICAL_SECTION*,&CritSec)); II II Use system call to lock the CRITICAL_SECTION object. II inline void MyCriticalSection::Lock() { ::EnterCriticalSection(CONST CAST(CRITICAL_SECTION*,&CritSec)); II II Use system call to unlock the CRITICAL SECTION object. 110

PAGE 121

II inline void MyCriticalSection::Unlock() { ::LeaveCriticalSection(CONST_CAST(CRITICAL_SECTION*,&CritSec)); Ill

PAGE 122

//---------------------------------------------------------------------------II Project Vehicle Simulator II II Copyright 1997. All Rights Reserved. II II SUBSYSTEM: System Globals II FILE: globals.hpp II AUTHOR: Bret A. Godwin II DATE: November 1997 II II OVERVIEW II --------//This file contains the system configuration globals and other //system flags that are used by all modules and classes in the system II !1----------------------------------------------------------------------------#ifndef engineglobals #define engineglobals #ifdef globalset #define GEXTERN #else #define GEXTERN extern #endif //general global variables GEXTERN of stream outFile; GEXTERN ofstream statFile; GEXTERN ofstream qstatFile; GEXTERN bool loggingOn; GEXTERN bool statsloggingOn; GEXTERN bool errorLoggingOn; GEXTERN bool routeDisplayFlag; GEXTERN int systemTime; GEXTERN short debugLevel; GEXTERN int vqueueSize; GEXTERN int NUMOBJ; GEXTERN int PROCREQPERSEC; GEXTERN int OBJQSIZE; GEXTERN int PENDQSIZE; GEXTERN void *SimulationPtr; II Grid configuration values //#define GRIDMAX 2375 #define GRIDMAX 475 #define LEVELMAX 20 //#define GRIDSIZE 5 #define GRIDSIZE 1 GEXTERN int LEVELSIZE; GEXTERN int SQUAREFEET; GEXTERN int ETASECSWINDOW; GEXTERN int LevelsUsed; GEXTERN int maxLevelDistribution; GEXTERN int gridLayoutType; II Engine configuration values 112

PAGE 123

GEXTERN int TOTVEHREQ; GEXTERN int ROUTCOMPUPDATINTV; GEXTERN int DRAWUPDATINTVSEC; GEXTERN int VEHREQPERSEC; II Simulation Configuration values GEXTERN int vMovmentOptions; GEXTERN int vArrivalOptions; GEXTERN int routeLevelOptions; II DEBUGLEVELS idefine GRIDDEBUG 5 idefine GRIDDUMP 99 113

PAGE 124

11----------------------------------------------------------------------------II II II II II II II II Project Vehicle Simulator Copyright 1997. All Rights Reserved. SUBSYSTEM: FILE: AUTHOR: DATE: II II OVERVIEW II --------30 Grid objects grid.cpp Bret A. Godwin November 1997 II This is the method implementation code for the grid class for II the 3 dimensional routing simulation II 11----------------------------------------------------------------------------II hnclude "grid.hpp" tinclude "vehicle.hpp" tinclude extern rc; Gridinfo gridData; II Globals int verticalBlocked; int horizontalBlocked; int hBlockedByVertical; int verticalOverflow; int gridMemoryUsed; XYPairs xyloc[10] {{216,216}, {287,450}, {25,425}, {25, 50}, {25,216}, {425,216}, {216,425}, {450,450}, {450,1}}; {287, 1}, void getVehicleDestination{float &x, float &y) { int r; r = random{gridLayoutType); x =random {21)/float{GRIDSIZE) + xyloc[r] .x; y random {21Jifloat{GRIDSIZEJ + xyloc[r] .y; } gridCoord::gridCoord{bool randompick) { 114

PAGE 125

x =random (GRIDMAX); y random (GRIDMAX); z = 0; gridCoord::-gridCoord() { I boo! gridCoord::operator== (const gridCoord& arg) const { if ((x == arg.x) && (y == arg.y) && (z == arg.z)) return true; else return false; boo! gridCoord::operator< (const gridCoord& arg) const { if (x < arg.x) return true; if ((arg.x-x) 0) if (y < arg.y) return true; if (z < arg.z) return true; return false; ostream& operator<<(ostream& os, gridCoord& gel { I os << "<" << gc.x << return os; n n << gc.y << n n << gc.z << ">"; objectCoord::objectCoord(bool randompick, int type) { int r; if (type == 1) { II anywhere on the grid, starting location I x =random (GRIDMAX); y random (GRIDMAX); z = 0; if (type == 2) { if (random(10) > 5) { x = random (21) + 216; y random (21) + 216; z = 0; else { 115

PAGE 126

) x = random (21) + 287; y random (21) + 1; z = 0; if (type == 3) ( r = random(lO); if (r > 8) ( x =random (GRIDMAX); y random (GRIDMAX); z = 0; else if (r > 4) ( X= random (2l*GRIDSIZE)+ 216*GRIDSIZE; y random (2l*GRIDSIZE)+ 216*GRIDSIZE; z = 0; else ( x = random (2l*GRIDSIZE)+ 287*GRIDSIZE; y random (2l*GRIDSIZE)+ l*GRIDSIZE; z = 0; if (type == 4) ( if if getVehicleDestination(x, y); z = 0; (X 0) K = 1; (y 0) y = 1; long objectCoord::getintegerX() ( return long(x ); long objectCoord::getintegerY() ( return long (y ) ; long objectCoord::getintegerZ() ( return long(z LEVELSIZE); objectCoord::-objectCoord() ( } bool objectCoord::operator== (const objectCoord& arg) const ( if ((x == arg.x) && (y == arg.y) && (z == arg.z)) return true; else return false; bool objectCoord::operator< (const objectCoord& arg) const 116

PAGE 127

if (x < arg.x) return true; if ((arg.x-x) == 0) if (y < arg.y) return true; if (z < arg.z) return true; return false; ostream& operator<<(ostream& os, objectCoord& oc) ( I OS << "<" << OC.X << return os; n n << oc.y << gridSquareData::gridSquareData() { vertical used verticalreserved horizontal used horizontalreserved vcounter squareETAPtr false; false; false; false; 0; NULL; gridSquareData::-gridSquareData() void gridSquareData::cleanUp() EtaData *ptr, *nxt; Lock(this); ptr = squareETAPtr; if (ptr) { n n << oc.z << 117 ">";

PAGE 128

nxt = squareETAPtr->next; delete ptr; gridMemoryUsed -= sizeof(EtaData); while(nxt) { ptr = nxt; nxt = ptr->next; delete ptr; gridMemoryUsed sizeof(EtaData); ostream& operator<<(ostream& os, gridSquareData& oc) { EtaData *ptr, *nxt; ptr = oc.squareETAPtr; if (ptr) { nxt = oc.squareETAPtr->next; os << "VID : << ptr->vehicleiD << STime << ptr->startTime << ETime : << ptr->endTime << endl; while(nxt) { ptr = nxt; nxt = ptr->next; os << "VID : << ptr->vehicleiD << STime << ptr->startTime << ETime : << ptr->endTime << endl; return os; I SparseGrid::SparseGrid() { int i,j; Lock L(this); for (i=O; i < GRIDMAX; i++) for (j=O; j < LevelsUsed j++) grid[i] [j] = NULL; lastElement = NULL; memsize = sizeof(grid); gridMemoryUsed = memsize; SparseGrid::-SparseGrid() { int i,j; Lock L(this); for (i=O; i < GRIDMAX; i++) for (j=O; j < LevelsUsed j++) deleteRow(i,j); gridSquareData SparseGrid::getVal(int r, int c, int 1) { gridSquareData eta; GridElement *g; Lock L(this); 118

PAGE 129

if (ChecklndexRange(r,c,l)) return eta; r--; 1--; II arrays in C++ are indexed 0 .. n-1 if (grid[r] [1]) { if (g = findElement(r,c,l)) return g->eta; else return eta; else return eta; void SparseGrid::setVal(int r, int c, int 1, gridSquareData& eta) { GridElement *Element; Lock L(this); if (ChecklndexRange(r,c,l)) return; r--; 1--; II arrays in C++ are indexed 0 .. n-1 if (grid[r] [1]) if (Element= findElement(r,c,l)) Element->eta = eta; else addElement(r,c,l,eta); else { II row already has elements II elment already present, change values II no element, add it with the values grid[r] [1] makeNode(c,eta,NULL); II no elements in row void SparseGrid::clearGrid() { Lock L(this); for(int i=O;i tempPtr->col) { II col is not less than first II element of row while((c > tempPtr->col) && (tempPtr->next)) { tempPtr = tempPtr->next; tempPtr->next makeNode(c,eta,tempPtr->next); else II col is less than first in row 119

PAGE 130

grid[r] [1] makeNode(c,eta,tempPtr); void SparseGrid::deleteElement(int r, int c, int 1) { GridElement *tempPtr, *pptr = NULL; Lock L(this); ternpPtr = findElernent(r,c,l,pptr); if(ternpPtr == grid[r] [1]) grid[r] [1] = tempPtr->next; else if (tempPtr) pptr->next = ternpPtr->next; tempPtr->eta.cleanUp(); delete ternpPtr; rnemsize -= sizeof(gridSquareData); gridMernoryUsed -= sizeof(gridSquareData); void SparseGrid::deleteRow(int r, int 1) { GridElernent *tempPtr, *next; Lock L(this); tempPtr = grid[r] (1]; if (ternpPtr) ( next = tempPtr->next; ternpPtr->eta.cleanUp(); delete tempPtr; rnernsize -= sizeof(gridSquareData); gridMemoryUsed -= sizeof(gridSquareData); while(next) ( ternpPtr = next; next = next->next; tempPtr->eta.cleanUp(); delete ternpPtr; rnemsize -= sizeof(gridSquareData); gridMemoryUsed -= sizeof(gridSquareData); } grid[r] [1] = NULL; GridElement *SparseGrid::findElement(int r,int c,int 1) { GridElement *tempPtr; Lock L(this); if (grid[r] [1] == NULL) return NULL; tempPtr = grid[r) [1]; if ( tempPtr l return NULL; while((c != ternpPtr->col) && (tempPtr->next)) tempPtr = tempPtr->next; if (c == tempPtr->col) return ternpPtr; else return NULL; 120

PAGE 131

GridElement *SparseGrid::findElement(int r,int c,int l,GridElement* &prior) { GridElement *tempPtr; Lock L(this); tempPtr = grid[r] [1]; if ( tempPtr) return NULL; prior = tempPtr; while((c != tempPtr->col) && (tempPtr->next)) { prior = tempPtr; tempPtr = tempPtr->next; ) if (c == tempPtr->col) return tempPtr; else return NULL; GridElement *SparseGrid::makeNode(int c, gridSquareData& eta, GridElement *next) { GridElement *temp; Lock L(this); temp = new GridElement; temp->eta = eta; temp->col = c; temp->next = next; memsize += sizeof(gridSquareData); gridMemoryUsed += sizeof(gridSquareData); return temp; void SparseGrid::clearVal(int r, int c, int 1) { Lock L(this); if (CheckindexRange(r,c,l)) return; r--; 1--; II arrays in C++ are indexed 0 .. n-1 if (grid[r] [1]) deleteElement(r,c,l); int SparseGrid::getMemSize() { return memsize; bool SparseGrid::ChecklndexRange(int r, int c, int 1) { if (((r>O) && (r <= GRIDMAX)) && ((c>O) && (c <= GRIDMAX)) && ((1>0) && (1 <= LevelsUsed))) return false; return true; bool SparseGrid::isEmpty(int r, int c, int 1) 121

PAGE 132

GridElement *g; Lock L(this); r--; 1--; II arrays in C++ are indexed 0 .. n-1 if (grid[r] [1] == NULL) return true; else { if (g = findElement(r,c,l)) if (g->eta.squareETAPtr NULL) return true; else return false; else return true; gridobject::gridobject() { ) void gridobject::initGrid(int levUsed, int sqsize, int levsize, int sqfeet, int maxvcounter) int i; if (levUsed > LevelsUsed) levelsUsed LevelsUsed; else levelsUsed levUsed; squaresize = sqsize; squarefeet = sqfeet; levelsize = levsize; maxVCounter = maxvcounter; initializeArray(); for(i=O;i
PAGE 133

int gridobject::getMaxLevels() { return levelsUsed; void gridobject::clearGrid() ( Lock(this); verticalBlocked = 0; horizontalBlocked = 0; hBlockedByVertical = 0; vertica!Overflow = 0; gridarray.clearGrid(); void gridobject::clearSquare(gridCoord const &gc, int viD) { gridSquareData gd; Lock(this); if ((gc.x > GRIDMAX) I I (gc.y > GRIDMAX) I I (gc.z > levelsUsed) I I ( gc. x < 1) I I ( gc. y < 1) I I ( gc. z < 1) ) return; gd = gridarray.getVal(gc.x,gc.y,gc.z); if !gd.squareETAPtr == NULL) return; gd.horizontalused = false; gd.verticalreserved = false; gd.horizontalreserved = false; if (gd.vcounter > 0) gd.vcounter--; if (gd.vcounter == 0) gd.verticalused = false; gridarray.setVal(gc.x,gc.y,gc.z,gd); delEtaPtr(viD, gc); boo! gridobject::setsquare(int x, int y, int z) { gridSquareData gd; Lock(this); if ( (x > GRIDMAX) II (y > GRIDMAX) II (z > levelsUsed) II (x < 1) II (y < 1) II (z < 1)) return true; gd = gridarray.getVal(x,y,z); if (gd.verticalreserved) { if (gd.vcounter >= maxVCounter) { gridarray.setVal(x,y,z,gd); return true; gd.verticalused = true; gd.verticalreserved = false; 123

PAGE 134

else { gd.horizontalused = true; gd.horizontalreserved = false; gridarray.setVal(x,y,z,gd); return false; bool gridobject::setsquare{gridCoord const &gc) { int x, y, z; Lock(this); x= gc.getx(); y= gc.gety(); z= gc.getz(); return setsquare(x,y,z); bool gridobject::reserveSquare(int loc, int x, int y, int z, int directiontype) { II I* gridCoord gc; gridSquareData gd; Lock(this); llfprintf(fp, "called from line %d\n",loc); if ( (x > GRIDMAXl I I (y > GRIDMAX) I I (z > levelsUsed) II (x < 1) II (y < 1) ) { return true; gd = gridarray.getVal(x,y,z); if ((isSquareUsed(x,y,z,directiontype))) Ill I isSquareReserved(x,y,z))) rc++; if (errorLoggingOnl outFile << "route blocked z << endl; return true; << lOC << " << X << " << y << '' << if (Z > 0) { if (directiontype = moveVertica1) gd.verticalreserved = true; if (gd.vcounter >= maxVCounter) { rc++; gridarray.setVal(x,y,z,gd); return true; gd.vcounter++; else { gd.horizontalreserved true; *I gc.setxyz(x,y,z); gridList->push back(gc); II gridarray.setVal(x,y,z,gd); return false; 124

PAGE 135

bool gridobject::reserveSquare(gridCoord const &gc,int directiontype) { Lock(this); return reserveSquare(99,gc.x, gc.y, gc.z,directiontype); bool gridobject::unreserveSquare(int viD) { gridCoord gc; int x, y, z; Lock(this); if (!gridList->empty()) { gc = gridList->front(); gridList->pop_front(); x= gc. getx ( ) ; y= gc.gety(); z= gc.getz(); if ( (x > GRIDMAX) I I (y > GRIDMAX) II (Z > levelsUsed) II (X < 1) II (y < 1) II (Z < 1)) return false; clearSquare(gc,viD); return true; bool gridobject::isSquareTimeSlotOpen(ETAPtr ptr) { ETAPtr nxt; if (ptr == NULL) return true; nxt = ptr; while (nxt) { return false; bool gridobject::isSquareUsed(int x, int y, int z, int directiontype) { gridSquareData gd; Lock(this); if ( (x > GRIDMAX) II (y > GRIDMAX) II (z > levelsUsed) II (X < 1) II (y < 1) II (Z < 1)) return false; gd = gridarray.getVal(x,y,z); /* if (gd.horizontalused) //horizontal always blocks { if (isSquareTimeSlotOpen(gd.squareETAPtr)) 125

PAGE 136

*I return false; horizontalBlocked++; return true; if ((gd.vcounter >= maxVCounter) && (directiontype == moveVertical)) vertical Blocked; return true; if (gd.verticalused && (directiontype == moveHorizontal)) { if (isSquareTimeSlotOpen(gd.squareETAPtr)) return false; hBlockedByVertical++; return true; if (gd.squareETAPtr return false; else return true; NULL) bool gridobject::isSquareUsed(int x, int y, int z) { gridSquareData gd; Lock (this l ; if ( (x > GRIDMAX) II (y > GRIDMAX) II (z > levelsUsed) I I (X < 1) II (y < 1) II (Z < 1)) return false; gd = gridarray.getVal(x,y,z); if (gd.squareETAPtr == NULL) return false; else return true; bool gridobject::isSquareUsed(gridCoord const &gc, int directiontypel { Lock(this); return isSquareUsed(gc.x,gc.y,gc.z,directiontype); I bool gridobject::isSquareReserved(int x, int y, int z, int directiontype) { gridSquareData gd; Lock(this); if ( (x > GRIDMAX) I I (y > GRIDMAX) I I (Z > levelsUsed) II (X < 1) II (y < 1) II (Z < 1)) return true; gd = gridarray.getVal(x,y,z); if ((gd.vcounter >= maxVCounter) && (directiontype == moveVerticalll 126

PAGE 137

return true; if ((gd.horizontalreserved I I gd.verticalreserved) && (directiontype return true; return false; moveHorizontal)) boo! gridobject::checkVerticalRoute(objectCoord &p, int level) { int i; Lock(this); for(i=l; i <= level; i++) { if (isSquareUsed(find square(p),moveVertical)) return false; -return true; gridCoord gridobject::find_square(objectCoord const &p) { I* gridCoord np; Lock(this); if (p.x == 0.0) np.x 1.0; else np.x ceil(p.x); if (p.y == 0.0) np.y 1. 0; else np.y ceil(p.y); np.z = p.z; return np; int gridobject::FillSquares(objectCoord &p, objectCoord &q, int level, Route3D *Route3DPtr, vehiclePointer vPtr) gridCoord sl,s2; objectCoord c; double m,ox,oy,deltax,deltay; int i; gridCoord gc; objectCoord newp = p; objectCoord newq = q; II list *gridList; list ::iterator tail; list ::iterator head; gridList = new list ; currentVehiclePtr = vPtr; II create a global reference to vehicle II while in the grid class 127

PAGE 138

if ( !gridList) { if (errorLoggingOn) outFile << "Out of memory when allocating gridList" << endl; return 0; II Check vertical route for p and q. if either is blocked then II abort if (!checkVerticalRoute(p,level)) { Route3DPtr->setVerticalBlocked(); goto error; if (!checkVerticalRoute(q,level)) { Route3DPtr->setVerticalBlocked(); goto error; II Route is available, set grid squares to be used to II create a route 3d object that will be used by the vehicle II to traverse the route for (i=O;i<=(level-l);i++) ( newp.z = i; reserveSquare(find_square(newp), moveVertical); sl find_square(p); s2 find_square(q); II if (reserveSquare(l,int(sl.x), int(sl.y),level,moveHorizontal)) goto error; if ( (q.x -p.x) 0.0) m = 0.0; else m = float (q.y-p.y) I float(q.x -p.x) del tax deltay q.x -p.x; q.y -p.y; if ((deltax >= 0) && (deltay >= 0) && (deltay < deltax)) { II 0 <= theta < 45 oy=p.y; for(i=sl.x; i <= s2.x; i++) { c.x = i; c.y = m (c.x-p.x) + p.y; if (floor(c.y) != c.y) { if Coy< floor(c.y)) ( if (reserveSquare(3,int(c.x),int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y)); ) llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+l); if (reserveSquare(4,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; 128

PAGE 139

else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y)); //fprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l); II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)); II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)); II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(5,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(6,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(7,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(S,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; oy= c. y; else if ((deltax > 0) && (deltay >= 0) && (deltay >= deltax)) II 45 <= theta < 90 ox=p.x; for(i=sl.y; i <= s2.y; i++) { c.y = i; c.x = (c.y-p.yllm + p.x; if (floor(c.x) != c.x) { if (ox< floor(c.x)) { llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y)); if (reserveSquare(9,int(c.x),int(c.y),level,moveHorizontal)) goto error; ) llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(lO,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l); II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(ll,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(l2,int(c.x)+l,int(c.y)+l,level,moveHorizontal)J goto error; if (reserveSquare(13,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(14,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ox= c.x; else if ((deltax <= 0) && (deltay >= 0) && (deltay > -deltax)) II 90 <= theta< 135 ox=p.x; c.x = p.x; for(i=sl.y; i <= s2.y; i++) { c.y = i; if (m != 0.0) 129

PAGE 140

error; error; error; c.x = (c.y-p.y)lm + p.x; if (m == 0.0) { llfprintf(fp,"square %d, %d\n", int(sl.x),int(c.y)+l); if (reserveSquare(l5,int(sl.x),int(c.y)+l,level,moveHorizontal)) goto else if (floor(c.x) != c.x) { if (c.x < floor(ox)) { llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)); if (reserveSquare(l6,int(c.x)+l,int(c.y),level,moveHorizontal)) goto llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y)+l); if (reserveSquare(l7,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto else llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l); II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(lB,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(l9,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(20,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(2l,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ) ) ox= c.x; else if ((deltax <= 0) && (deltay > 0) && (deltay <= -deltax)) II 135 <= theta < 180 oy=p.y; for(i=sl.x; i >= (s2.x); i--) { c.x = i; c.y = m (c.x-p.x) + p.y; if (floor(c.y) != c.y) { if (oy < floor(c.y)) { llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); if (reserveSquare(22,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II II if (reserveSquare(23,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+l); else { 130

PAGE 141

llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+1, int(c.y)+1,level,moveHorizontal)) goto error; II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+1, int(c.y),1evel,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+1,level,moveHorizontal)) goto error; II diagonal right if (reserveSquare(24,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(25,int(c.x)+1,int(c.y)+1,level,moveHorizontal)) goto error; if (reserveSquare(26,int(c.x)+1,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(27,int(c.x),int(c.y)+1,level,moveHorizontal)) goto error; oy= c.y; else if ((deltax <= 0) && (deltay <= 0) && (deltay > deltax)) II 180 <= theta < 225 error; oy=p.y; for(i=s1.x-1; i >= (s2.x); i--) ( c.x = i; c.y = m (c.x-p.x) + p.y; if (floor(c.y) != c.y) ( if (c.y < floor(oy)) { llfprintf(fp,"square %d, %d\n", int(c.x)+1,int(c.y)+1); if (reserveSquare(28,int(c.x)+1,int(c.y)+1,level,moveHorizontal)) goto ) llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+1,level,moveHorizontal)) goto error; if (reserveSquare(29,int(c.x),int(c.y)+1,level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+1,int(c.y)+1,level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+1,level,moveHorizontal)) goto error; ) else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+1, int(c.y)+1,level,moveHorizontal)) goto error; II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+1, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+1,level,moveHorizontal)) goto error; II diagonal right goto error; error; error; if (reserveSquare(30,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(31,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) if (reserveSquare(32,int(c.x)+l,int(c.y),level,moveHorizontal)) goto if (reserveSquare(33,int(c.x),int(c.y)+l,level,moveHorizontal)) goto 131

PAGE 142

oy= c.y; else if ((deltax < 0) && (deltay <= 0) && (deltay <= deltax)) II 225 <= theta < 270 error; ox=p.x; for(i=sl.y; i >= s2.y; i--) { c.y = i; c.x = (c.y-p.yllm + p.x; if (floor(c.x) != c.x) { if (c.x < floor(ox)) { llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); if goto ) llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)l goto error; if (reserveSquare(35,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontalll goto error; ) else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)l goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(36,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(37,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(38,int(c.x)+l,int(c.y),level,moveHorizontal)l goto error; if (reserveSquare(39,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ox= c.x; else if ((deltax >= 0) && (deltay <= 0) && (-deltay > deltax)) II 270 <= theta < 315 error; ox=p.x; for(i=sl.y; i >= s2.y-l; i--) { c.y = if (m != 0.0) c.x = (c.y-p.y)lm + p.x; if (m == 0.0) { llfprintf(fp,"square %d, %d\n", int(sl.x),int(c.y)+l); if (reserveSquare(40,int(sl.x),int(c.y)+l,level,moveHorizontal)) goto else if (floor(c.x) != c.x) { 132

PAGE 143

if (ox < floor(c.x)) { llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(4l,int(c.x),int(c.y)+l,level,moveHorizontalll goto error; llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(42,int(c.x)+l,int(c.y)+l,level,moveHorizontal)l goto error; II llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y),level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; ) else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(43,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(44,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(45,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(46,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ox= c.x; else if ((deltax >= 0) && (deltay < 0) && (-deltay <= deltax)) II 315 <= theta < 360 oy=p.y; for(i=sl.x; i <= s2.x; i++) { c.x = i; c.y = m (c.x-p.xl + p.y; if (floor(c.y) != c.y) { if (c.y < floor(oy)) { llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(47,int(c.x),int(c.y)+2,level,moveHorizontal)) goto error; ) llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y),level,moveHorizontal)l go to II II go to error; if error; else (reserveSquare(48,int(c.x),int(c.y)+l,level,moveHorizontalll goto error; llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y)+l); llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y),level,moveHorizontal)) llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; 133

PAGE 144

llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above llfprintflfp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l,level,moveHorizontal)) goto error; II diagonal right if (reserveSquare(49,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(50,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(5l,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(52,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; oy= c.y; else If II P = Q II Route is available, set grid squares to used II create a route 3d object that will be used by the vehicle II to traverse the route II if (reserveSquare(2,int(s2.x), int(s2.y),level,moveHorizontal)) goto error; for (i=(level-l);i>=O;i--) { newq.z = i; reserveSquare(find_square(newq),moveVertical); head= gridList->begin(); tail= gridList->end(); while(head != tail) { gc = *head++; setsquare(gc); }II while Route3DPtr->addToRoute(p,level); Route3DPtr->addToRoute(q,level); Route3DPtr->addToRoute(q,0); Route3DPtr->clearverticalBlocked(); Route3DPtr->setRouteFound(); Route3DPtr->setRoute(gridList); return level; error: while(!gridList->empty()) unreserveSquare(); delete gridList; return 0; } II fillsquares *I Gridinfo gridobject::getGridinfo() 134

PAGE 145

Gridinfo temp; temp.levelsUsed temp.squaresize temp.squarefeet temp.levelsize return temp; Route3D::Route3D() levelsUsed; squaresize; square feet; levelsize; VerticalBlocked = false; RouteFound = false; routeGridSquareListPtr Route3D::-Route3D() { NULL; if (routeGridSquareListPtrl delete routeGridSquareListPtr; boo! Route3D::operator== (const Route3D& arg) const {) boo! Route3D::operator< (const Route3D& arg) const {) void Route3D::addToRoute(objectCoord oc, int level) { II II II if (level != 0) oc.z = level + 0.5; else oc.z = level; routeList.push_back(oc); list *Route3D::getroute() { return &routeList; void Route3D::setVerticalBlocked() { Vertica!Blocked = true; void Route3D::clearVerticalBlocked() { Vertica!Blocked = false; boo! Route3D::getVerticalBlocked() 135

PAGE 146

return VerticalBlocked; void Route3D::setRouteFound() { RouteFound = true; bool Route3D::getRouteFound() { return RouteFound; void Route3D::setRoute(list *ptr) { routeGridSquareListPtr = ptr; ) list *Route3D::getRouteGridSquareListPtr() { return routeGridSquareListPtr; ostream& operator<<(ostream& os, Route3D& r) { int i; if (!r.RouteFound) { os << "Route not found yet" << endl; II return os; list::iterator rStart = r.routeList.begin(); list::iterator rEnd= r.routeList.end(); list::iterator rGridStart = r.routeGridSquareListPtr->begin(); list::iterator rGridEnd = r.routeGridSquareListPtr->end(); i = 1; if (!r.routeList.empty()) { while(rStart != rEnd) { os << *rStart++ << "; if ( ( i% 5 ) == 0 ) os << endl; i++; os << endl; ) i = 1; if (!r.routeGridSquareListPtr->empty()) { while(rGridStart != rGridEnd) { OS << *rGridStart++ << "; if ( (i%5) == 0) os << endl; i++; os << endl; 136

PAGE 147

return os; int gridobject::SetRoute(objectCoord &p, objectCoord &q, int level, Route3D *Route3DPtr, vehiclePointer vPtr) gridCoord sl,s2; objectCoord c; double m,ox,oy,deltax,deltay; int i; gridCoord gc; objectCoord newp = p; objectCoord newq = q; II list *gridList; list ::iterator tail; list ::iterator head; gridList = new list ; vehicle vtemp = *vPtr; currentVehiclePtr = vPtr; II create a global reference to vehicle II while in the grid class if ( !gridList) { if (errorLoggingOn) outFile << "Out of memory when allocating gridList" << endl; return 0; II only so many vehicles allowed on a level at a given time if (isLevelFull(level)) goto error; II Check vertical route for p and q. if either is blocked then II abort for (i=O;i<=(level-l);i++) { newp.z = i; reserveSquare(find_square(newp), moveVertical); sl find_square(p); s2 find_square(q); II if (reserveSquare(l,int(sl.x), int(sl.y),level,moveHorizontal)) goto error; if ( (q.x -p.x) 0.0) m = 0.0; else m = float (q.y -p.y) I float(q.x -p.x) del tax deltay q.x -p.x; q.y -p.y; if ((deltax >= 0) && (deltay >= 0) && (deltay < deltax)) { I* 0 <= theta < 45 *I 137

PAGE 148

oy=p.y; for(i=sl.x; i <= s2.x; i++) { c.x = i; c.y = m (c.x-p.xl + p.y; if (floor(c.y) != c.y) { I if (oy < floor(c.y)) { ) if (reserveSquare(3,int(c.x),int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y)); llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+l); if (reserveSquare(4,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y)); llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l); II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)); II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)); II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(5,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(6,int(c.x)+l,int(c.y)+l,level,moveHorizontal)l goto error; if (reserveSquare(7,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(8,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; oy= c.y; else if ((deltax > 0) && (deltay >= 0) && (deltay >= deltax)) I* 45 <= theta < 90 *I ox=p.x; for(i=sl.y; i <= s2.y; i++) { c.y = i; c.x = (c.y-p.y)lm + p.x; if (floor(c.x) != c.x) { if (ox< floor(c.x)) { llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y)); if (reserveSquare(9,int(c.x),int(c.y),level,moveHorizontal)) goto error; I llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) got:o error; if (reserveSquare(lO,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; else llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l); II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level)) goto error; II diagonal right goto error; error; llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(ll,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(12,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) if (reserveSquare(13,int(c.x)+l,int(c.y),level,moveHorizontal)) goto 138

PAGE 149

if (reserveSquare(l4,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ox= c.x; else if ((deltax <= 0) && (deltay >= 0) && (deltay > -deltax)) I* 90 <= theta < 135 *I error; error; error; ox=p.x; c.x = p.x; for(i=sl.y; i <= s2.y; i++) { c.y = i; if (m != 0.0) c.x = (c.y-p.y)lm + p.x; if (m == 0.0) { llfprintf(fp,"square %d, %d\n", int(sl.x),int(c.y)+l); if (reserveSquare(l5,int(sl.x),int(c.y)+l,level,moveHorizontal)) goto else if (floor(c.x) != c.x) { if (c.x < floor(ox)) { llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y) ); if (reserveSquare(16,int(c.x)+l,int(c.y),level,moveHorizontal)) goto ) llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y)+l); if (reserveSquare(17,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto else llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l); II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(18,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(l9,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(20,int(c.x)+l,int(c.yl,level,moveHorizontalll goto error; if (reserveSquare(21,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ox= c.x; ) ) else if ((deltax <= 0) && (deltay > 0) && (deltay <= -deltax)) /* 135 <= theta < 180 */ oy=p.y; for(i=sl.x; i >= (s2.x); i--) { c.x = i; c.y = m (c.x-p.x) + p.y; if (floor(c.y) != c.y) { if (oy < floor(c.y)) { 139

PAGE 150

llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); if (reserveSquare(22,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; } llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II II if (reserveSquare(23,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+l); else ( llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l,level,moveHorizontal)) goto error; II diagonal right if (reserveSquare(24,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(25,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(26,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(27,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; oy= c.y; else if ((deltax <= 0) && (deltay <= 0) && (deltay > deltax)) I* 180 <= theta < 225 *I error; oy=p. y; for(i=sl.x-1; i >= (s2.x); i--) { c.x = i; c.y = m (c.x-p.x) + p.y; if (floor(c.y) != c.y) { if (c.y < floor(oy)) { llfprintflfp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); if (reserveSquare(2B,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto } llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(29,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; II llfprintflfp,"square %d, %d\n", int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x), int(c.y)+l,level,moveHorizontal)) goto error; } else { llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above 140

PAGE 151

llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l,level,moveHorizontal)) goto error; II diagonal right if (reserveSquare(30,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(31,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(32,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(33,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; oy= c.y; else if ((deltax < 0) && (deltay <= 0) && (deltay <= deltax)) I* 225 <= theta < 270 *I error; ox=p.x; for(i=sl.y; i >= s2.y; i--l { c.y = i; c.x = (c.y-p.yllm + p.x; if (floor(c.x) != c.x) { if (c.x < floor(ox)) { llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l); if (reserveSquare(34,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto ) llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(35,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; ) else I llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right goto error; error; error; llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(36,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(37,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) if (reserveSquare(3B,int(c.x)+l,int(c.y),level,moveHorizontal)) goto if (reserveSquare(39,int(c.x),int(c.y)+l,level,moveHorizontal)) goto ox= c.x; else if ((deltax >= 0) && (deltay <= 0) && (-deltay > deltax)) I* 270 <= theta < 315 *I 141

PAGE 152

error; ox=p.x; for(i=sl.y; i >= s2.y-1; i--) { c.y = i; if (m != 0.0) c.x = (c.y-p.y)lm + p.x; if (m == 0.0) 1 llfprintf(fp,"square %d, %d\n", int(sl.x),int(c.y)+l); if (reserveSquare(40,int(sl.x),int(c.y)+l,level,moveHorizontal)) goto else if (floor(c.x) != c.x) { if (ox< floor(c.x)) { llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(41,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; I llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(42,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y),level,moveHorizontal)) goto error; II llfprintf(fp,"square %d, %d\n", int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; I else I llfprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above /lfprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; II diagonal below llfprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right llfprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l); II diagonal right if (reserveSquare(43,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(44,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(45,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(46,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; ox= c.x; else if ((deltax >= 0) && (deltay < 0) && (-deltay <= deltax)) I* 315 <= theta < 360 *I oy=p.y; for(i=sl.x; i <= s2.x; i++) { c.x = i; c.y = m (c.x-p.x) + p.y; if (floor (c.y) != c.y) { if (c.y < floor(oy)) { llfprintf(fp,"square %d, %d\n", int(c.x),int(c.y),level,moveHorizontal)) goto error; 142

PAGE 153

if (reserveSquare(47,int(c.x),int(c.y)+2,level,moveHorizontal)) goto error; } //fprintf(fp,"square %d, %d\n", int(c.x), int(c.y),level,moveHorizontal)) goto error; II II if (reserveSquare(48,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; //fprintf(fp,"square %d, %d\n", int(c.x),int(c.y)+l); //fprintf(fp,"square %d, %d\n", int(c.x), int(c.y),level,moveHorizontal)) goto error; i else ( //fprintf(fp,"vertex %d, %d\n",int(c.x), int(c.y),level,moveHorizontal)) goto error; //fprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y)+l,level,moveHorizontal)) goto error; II diagonal above //fprintf(fp,"square %d, %d\n",int(c.x), int(c.y),level,moveHorizontalll goto error; II diagonal below //fprintf(fp,"square %d, %d\n",int(c.x)+l, int(c.y),level,moveHorizontal)) goto error; II diagonal right //fprintf(fp,"square %d, %d\n",int(c.x), int(c.y)+l,level,moveHorizontal)) goto error; II diagonal right if (reserveSquare(49,int(c.x),int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(50,int(c.x)+l,int(c.y)+l,level,moveHorizontal)) goto error; if (reserveSquare(5l,int(c.x)+l,int(c.y),level,moveHorizontal)) goto error; if (reserveSquare(52,int(c.x),int(c.y)+l,level,moveHorizontal)) goto error; else { } oy= c.y; /* p = Q */ II Route is available, set grid squares to used II create a route 3d object that will be used by the vehicle II to traverse the route II if (reserveSquare(2,int(s2.x), int(s2.y),level,moveHorizontal)) goto error; for (i=(level);i>=O;i--) { newq.z = i; reserveSquare(find_square(newq),moveVertical); head tail gridList->begin(); gridList->end(); Route3DPtr->addToRoute(p,level); Route3DPtr->addToRoute(q,level); Route3DPtr->addToRoute(q,0); Route3DPtr->setRoute(gridList); Route3DPtr->clearVerticalBlocked(); if (!CheckETA(&vtemp,Route3DPtr)) open { goto error; Route3DPtr->setRouteFound(); /* while(head !=tail) //Check the ETA to make sure that the route is //from a time perspective 143

PAGE 154

gc = *head++; setsquare(gc); ) */ vtemp.setRouteNull(); addToLevel(level); return level; II patch to fix destructor problem with copy to vtemp error: while(!gridList->empty()) { unreserveSquare(vtemp.getiD()); while(! (Route3DPtr->getroute()->empty())) { Route3DPtr->getroute()->pop_front(); delete gridList; vtemp.setRouteNull(); return 0; II patch to fix destructor problem with copy bool gridobject::CheckETA(vehicle *vptr, Route3D *routePtr) int seconds; gridCoord squareloc; list ::iterator routepos vptr->getVehicleRoutePtr()>getroute()->begin(); list ::iterator routeendpos vptr->getVehicleRoutePtr()>getroute()->end(); list *vGridListPtr = vptr->getVehicleRoutePtr()->getRouteGridSquareListPtr(); list ::iterator gridpos = vGridListPtr->begin(); EtaData etaPtr; int viD = vptr->getiD(); if (debugLevel <= GRIDDEBUG) outFile << *routePtr << endl; //etaPtr =new EtaData; //gridMemoryUsed += sizeof(EtaData); //if (debugLevel <= GRIDDEBUG) II outFile << "CheckETA:: adding EtaData primary, grid memory now at->"<< II gridMemoryUsed << vehicle ID = << viD << endl; while(routepos != routeendpos) { //calcTempMove updates the routepos pointer when the vehicle has //changed direction vertically to horizontal or vice versa if (vptr->calculateTempMove(*routepos,routepos,&etaPtr))

PAGE 155

PAGE 156

PAGE 157

gc << endl; return; ptr = gd.squareETAPtr; if ((etaPtr->vehicleiD == ptr->vehicleiD) && (etaPtr->startTime == ptr->startTime) && (etaPtr->endTime == ptr->endTime)) return; while(ptr->next) { if ((etaPtr->vehicleiD == ptr->vehicleiD) && (etaPtr->startTime == ptr->startTime) && (etaPtr->endTime == ptr->endTime)) return; ptr = ptr->next; } if (ptr != etaPtr) { newEtaPtr = new EtaData; //create new etadata *newEtaPtr = *etaPtr; //copy data ptr->next = newEtaPtr; //add new pointer to the list gridMemoryUsed += sizeof(EtaData); if (debugLevel <= GRIDDEBUG) outFile << "AddEtaPtr:: Adding EtaData last, grid memory now at->"<< gridMemoryUsed << vehicle ID = << etaPtr->vehicleiD << endl << gc << endl; void gridobject::delEtaPtr(int viD, gridCoord &gc) { EtaData *ptr, *temp; gridSquareData gd; Lock(this); gd = gridarray.getVal(gc.x,gc.y,gc.z); if (gd.squareETAPtr == NULL} return; if (gd.squareETAPtr->vehicleiD vi D) temp = gd.squareETAPtr; gd.squareETAPtr = gd.squareETAPtr->next; if (gd.squareETAPtr == NULL) { gridarray.clearVal(gc.x,gc.y,gc.z); else { gridarray.setVal(gc.x,gc.y,gc.z,gd); delete temp; gridMemoryUsed -= sizeof(EtaData); if (debugLevel <= GRIDDEBUG) II empty list; do nothing II remove first element in list II no eta values free sparse grid cell II update sparse grid cell outFile << "delEtaPtr:: deleting EtaData memory, grid memory now at->"<< gridMemoryUsed << vehicle ID = << viD << endl << gc << endl; 147

PAGE 158

return; ptr = gd.squareETAPtr; while(ptr->next && (ptr->next->vehicleiD != viD)) II find element in list { = ptr->next; if (ptr->next) { II remove element from the list temp = ptr->next; ptr->next = ptr->next->next; delete temp; gridMemoryUsed -= sizeof(EtaData); if (debugLevel <= GRIDDEBUG) outFile << "delEtaPtr:: deleting EtaData memory, grid memory now at->"<< gridMemoryUsed << vehicle ID = << viD << end! << gc << end!; void gridobject::dumpGrid() { int r,c,l; char s[80); gridSquareData g; if (debugLevel != GRIDDUMP) return; for(l=1;l<=LevelsUsed;l++) for(r=l;r<=GRIDMAX;r++) for(c=1;c<=GRIDMAX;c++) if (!gridarray.isEmpty(r,c,l)) { sprintf(s,"gridarray[%d,%d,%d) has entries",r,c,l); outFile << s << end!; } g = gridarray.getVal(r,c,l); outFile << g << end!; outFile << "End-of-Entries" << end!; boo! gridobject::isLevelFull(int level} ( if (leveldistribution[level-1) < maxLevelDistribution) return false; else return true; void gridobject::addToLevel(int level) ( if (leveldistribution[level-1) < maxLevelDistribution) leveldistribution[level-1)++; void gridobject::removeFromLevel(int level) ( leveldistribution[level-1)--; if (leveldistribution[level-1) < 0) leveldistribution[level-11 = 0; 148

PAGE 159

int gridobject::getLevelCount(int level) { return leveldistribution[level-1]; 149

PAGE 160

/l---------------------------------------------------------------------------11 Project Vehicle Simulator II II II Copyright 1997. All Rights Reserved. II SUBSYSTEM: II FILE: II AUTHOR: II DATE: II II OVERVIEW II -------3D Grid objects grid.hpp Bret A. Godwin November 1997 11 This header file contains the grid object definitions related to the II 3 dimensional vehicle routing simulation. II 11---------------------------------------------------------------------------II CLASS gridCoord II Class defintion that describes the grid coordinates for locating a II vehicle or a square in a grid. *include *include *include *include *include *include *include "graphicsgems.h" *include "globals.hpp" hfndef gridhpp *define gridhpp using namespace std; //*define GRIDMAX 475 150

PAGE 161

const moveVertical = 1; const moveHorizontal = 2; class vehicle; typedef struct int x; int y; ) XYPairs; typedef vehicle *vehiclePointer; class Route3D; class systemError public: systemError(const char *s) {strcpy(msg,s);) char *getmsg() {return msg; ); private: char msg[80]; ); class gridCoord public: gridCoord(): x(O),y(O),z(O) {) gridCoord(bool randompick); -gridCoord (); bool operator== (const gridCoord& arg) const; bool operator< (const gridCoord& arg) const; friend ostream& operator<<(ostream& os, gridCoord& gc); void setxyz(long xnew, long ynew, long znew) {x=xnew;y=ynew;z=znew;) long const getx () {return x;) long const gety() {return y;) long const getz() {return z;) II grid coordinates long x, y, z; ); class objectCoord { public: objectCoord(): x(O),y(O),z(O) {) objectCoord(bool randompick,int type); -objectCoord (); bool operator== (const objectCoord& arg) const; bool operator< (const objectCoord& arg) const; friend ostream& operator<<(ostream& os, objectCoord& oc); 151

PAGE 162

void setxyz(float xnew, float ynew, float znew) {x=xnew;y=ynew;z=znew;} float getx(l {return x;} float gety() {return y;} float getz () {return z; l long getintegerX(l long getintegerY() long getintegerZ() II grid coordinates float x, y, z; ); typedef struct { ini levelsUsed; int squaresize; int squarefeet; int levelsize; } Gridinfo; class gridError { ) ; class EtaData public: EtaData(): startTime(O), endTime(O),vehicleiD(O), next(NULL) {); unsigned short startTime; unsigned short endTime; int vehicleiD; EtaData *next; } ; typedef EtaData *ETAPtr; class gridSquareData : private TSync ( public: gridSquareData(); -gridSquareData(); void cleanUp(); boo! verticalused boo! verticalreserved boo! horizontalused boo! horizontalreserved unsigned vcounter 1; 1; 1; 1; 12; II II EtaData *squareETAPtr; boo! used : 1; boo! reserved : 1; II grid cube is in use II grid cube is reserved }; typedef struct gridelem gridSquareData eta; int col; gride1em *next; GridElement; class SparseGrid private TSync { 152

PAGE 163

public: SparseGrid(); -SparseGrid(); gridSquareData getVal(int r, int c, int 1); void setVal(int r, int c, int 1, gridSquareData& eta); void clearVal(int r, int c, int 1); int getMemSize(); void clearGrid(); bool isEmpty(int r, int c, int 1); void deleteElement(int r, int c, int 1); private: GridElement *grid[GRIDMAX] [LEVELMAX]; GridElement *lastElement; long memsize; void addElement(int r, int c, int 1, gridSquareData& eta); void deleteRow(int r, int 1); GridElement *findElement(int r,int c,int ll; GridElement *findElement(int r,int c,int 1, GridElement* &prior); GridElement *makeNode(int c, gridSquareData& eta, GridElement *next); bool CheckindexRange(int r, int c, int 1); }; II CLASS gridobject II Class definition that describes an multi-dimensional grid that is used II by the 3 dimensional routing simulator class gridobject : private TSync { public: gridobject(}; void initGrid(int levUsed, int sqsize, int levsize, int sqfeet, void initializeArray(); int getMaxLevels(); void clearGrid(); 153 int maxvcounter);

PAGE 164

void clearSquare(gridCoord const &gc, int viD); boo! reserveSquare(int loc, int x, int y, int z, int directiontype); boo! reserveSquare(gridCoord const &gc, int directiontypel; boo! unreserveSquare(int viD); boo! setsquare(int x, int y, int z); boo! setsquare(gridCoord const &gc); boo! isSquareUsed(int x, int y, int z); boo! isSquareUsed(int x, int y, int z, int directiontype); boo! isSquareUsed(gridCoord const &gc, int directiontype); boo! isSquareReserved(int x, int y, int z, int directiontype); gridCoord find square(objectCoord const &p); int FillSquares(objectCoord &p, objectCoord &q, int level, Route3D *route3DPtr, vehiclePointer vPtr); Gridinfo getGridinfo(); boo! checkVerticalRoute(objectCoord &p, int level); boo! isSquareTimeSlotOpen(ETAPtr ptr); int SetRoute(objectCoord &p, objectCoord &q, int level, Route3D *Route3DPtr, vehiclePointer vPtr); boo! CheckETA(vehicle *vptr, Route3D *routePtr); boo! setETAValues(vehicle *vptr, list ::iterator &head, EtaData *etaPtr); boo! checkTimeRange(EtaData *etaPtr, gridCoord &gc); void addEtaPtr(EtaData *etaPtr, gridCoord &gc); void delEtaPtr(int viD, gridCoord &gc); void dumpGrid(); boo! isLevelFull(int level); void addToLevel(int level); void removeFromLevel(int level); int getLevelCount(int level); private: ) ; list *gridList; SparseGrid gridarray; int levelsUsed; int squaresize; int squarefeet; int levelsize; int maxVCounter; vehiclePointer currentVehiclePtr; short leveldistribution[LEVELMAX]; class Route3D { public: Route3D(); -Route3D(); boo! operator== (const Route3D& arg) const; boo! operator< (const Route3D& arg) const; void addToRoute(objectCoord gc, int level); list *getroute(); 154

PAGE 165

void setVerticalBlocked(); void clearVerticalBlocked(); bool getVerticalBlocked(); void setRouteFound(); boo! getRouteFound(); void setRoute(list *ptr); list *getRouteGridSquareListPtr(); friend ostream& operator<<(ostream& os, Route3D& r); private: ); short VerticalBlocked; bool RouteFound; list routeList; list *routeGridSquareListPtr; fendif 155

PAGE 166

//---------------------------------------------------------------------------11 Project Vehicle Simulator II II II Copyright 1997. All Rights Reserved. /1 SUBSYSTEM: II FILE: II AUTHOR: II DATE: II II OVERVIEW II -------main gui driver gridtest.hpp Bret A. Godwin November 1997 11 II This file contains the objects for the graphical user interface and the event routines that are used to drive the simulation. II //----------------------------------------------------------------------------#include .. /source/ControlDialog.h" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "mydialog.h" #include "vehicle.hpp" #include "engine.hpp" #include .. \opengl test\opengl testwindowview.h" #define IDC SOLIDGAUGEl 901 #define IDC-SOLIDGAUGE2 902 #define IDC-SOLIDGAUGE3 903 //set the define engine_run in the compiler options define section extern XYPairs xyloc[lO]; MyCriticalSection EngineLock; using namespace std; static int ucolor = 1; class TMyFrameWindow : public TFrameWindow public: TMyFrameWindow(TWindow* parent, const char far* title = 0, TWindow* clientWnd = 0, 156

PAGE 167

boo! shrinkToClient int h 570, int w 700, TModule* module 0); -TMyFrameWindow(); I; TMyFrameWindow *newWin; TMyFrameWindow::TMyFrameWindow(TWindow* parent, const char far* title TWindow* boo! int h, int w, clientWnd shrinkToClient, TModule* module) : false, TFrameWindow(parent,title,clientWnd,shrinkToClient,module) Attr.X 0; Attr.Y 0; Attr.H h; Attr.W w; TMyFrameWindow::-TMyFrameWindow() { Destroy(); FILE *fp; int rc; extern int verticalBlocked, horizontalBlocked, hBlockedByVertical; extern int gridMemoryUsed; extern ControlDialogXfer ControlDialogData; class TDrawWindow public: public TWindow { TDrawWindow(TWindow* parent 0); -TDrawWindow () delete sfontl; delete sfont2; delete []editStr; delete GD; 157

PAGE 168

Engine Simulation; protected: TDC* DragDC; LOG FONT MainFontRec; II Override member function of TWindow bool CanClose(); II Message response functions void SetupWindow(); void EvLButtonDown(uint, TPoint&); void EvRButtonDown(uint, TPoint&); void EvMouseMove(uint, TPoint&); void EvLButtonUp(uint, TPoint&); void EvClose(); void EvPaint () ; void EvBtn () ; void EvEdit(); void EvCreate(); bool EvUpdown(TNmUpDown& not); void EvRunBtn(); void EvStopBtn(); void EvContBtn(); LRESULT EvRunMsg(WPARAM,LPARAM); LRESULT EvStopMsg(WPARAM,LPARAM); LRESULT EvCntMsg(WPARAM,LPARAM); void EvRunMsgBtn(}; void CmDlg () ; void plotsquare(int i, int j); void plotvehicle(objectCoord gc, int vcolor); void drawgrid(int level); 158

PAGE 169

); DECLARE_RESPONSE_TABLE(TDrawWindow); private: objectCoord p, q; char str[80]; Contro!Dialog *GD; int yoffset; TFont *sfontl; TFont *sfont2; TButton *mybutton; int btncounter; int level; char *editStr; TEdit *mytext; TUpDown *myupdown; TGauge *inServiceGauge, *inQueueGauge; TGauge *leve1Gauge[20]; bool editflag; bool runmsgflag; boo! setupOK; int simcount; TRect updateRect,updateRect2; LPMEMORYSTATUS memoryStatus; DEFINE_RESPONSE_TABLEl(TDrawWindow, TWindow) EV_WM_LBUTTONDOWN, EV_WM_RBUTTONDOWN, EV_WM_MOUSEMOVE, 159

PAGE 170

EV WM LBUTTONUP, EV_WM_CLOSE, EV_COMMAND(lOl,CmDlg), EV_COMMAND(85l,EvRunBtn), EV_COMMAND(852,EvStopBtn), EV_COMMAND(853,EvContBtn), II EV_COMMAND(854,EvRunMsg), EV_COMMAND(855,EvRunMsgBtn), EV_COMMAND(876,EvBtn), EV_MESSAGE(1025,EvRunMsg), EV_MESSAGE(1026,EvStopMsg), EV_MESSAGE(1027,EvCntMsg), EV_UDN_DELTAPOS(878, EvUpdown), EV_EN_SETFOCUS(877,EVCreate), EV_EN_CHANGE(877,EvEdit), EV_WM_PAINT, END_RESPONSE_TABLE; TDrawWindow::TDrawWindow(TWindow* parent) TWindow(O, 0, 0) TPoint point; Dragee = O; editflag = false; setupOK = false; level = 1; btncounter = 0; II Invalidate(); point.x=lO; point.y=lO; MainFontRec.lfHeight 6; 160

PAGE 171

MainFontRec.lfWidth = 4; MainFontRec.lfEscapement = 0; MainFontRec.lfOrientation = 0; MainFontRec.lfWeight FW_BOLD; MainFontRec.lfitalic 0; MainFontRec.lfUnderline 0; MainFontRec.lfStrikeOut 0; MainFontRec.lfCharSet = ANSI_CHARSET; MainFontRec.lfOutPrecision = OUT_DEFAULT_PRECIS; MainFontRec.lfClipPrecision = CLIP_DEFAULT_PRECIS; MainFontRec.lfQuality = PROOF_QUALITY; MainFontRec.lfPitchAndFamily = VARIABLE PITCH I FF_ROMAN; strcpy(MainFontRec.lfFaceName, "Times New Roman"); sfont1 =new TFont(&MainFontRec); MainFontRec.lfHeight = 12; MainFontRec.lfWidth = 6; sfont2 =new TFont(&MainFontRec); mybutton =new TButton(this, 876, "Draw", GRIDMAX/GRIDSIZE+30, 240, 75,25, true); new TButton(this, 851, "Start", GRIDMAX/GRIDSIZE+30,120, 75, 25, true); new TButton(this, 852, "Stop", GRIDMAX/GRIDSIZE+30, 150, 75, 25, true); new TButton(this, 853, "Pause",GRIDMAX/GRIDSIZE+30,180, 75, 25, true); new TButton(this, 855, "Continue",GRIDMAX/GRIDSIZE+30,210, 75, 25, true); new TStatic(this,-1, "Vehicle Level Count", GRIDMAX/GRIDSIZE+120, 120, 150, 20); new TStatic(this,-1, "1-5", GRIDMAX/GRIDSIZE+275, 145, 35, 20); new TStatic(this,-1, "6-10", GRIDMAX/GRIDSIZE+275, 176, 35, 20); new TStatic(this,-1, "11-15", GRIDMAX/GRIDSIZE+275, 207, 35, 20); new TStatic(this,-1, "16-20", GRIDMAX/GRIDSIZE+275, 238, 35, 20); new TStatic(this,-1, "Grid Level", GRIDMAX/GRIDSIZE+30, 300, 130, 20); new TStatic(this,-1, "Vehicles in System", GRIDMAX/GRIDSIZE+30, 330, 130, 20); new TStatic(this,-1, "Vehicles in Queue", GRIDMAX/GRIDSIZE+30, 355, 130, 20); 161

PAGE 172

mytext =new TEdit(this, 877, "1", GRIDMAX/GRIDSIZE+170,300,50,20); myupdown =new TUpDown(this, 878, GRIDMAX/GRIDSIZE+221,300,50,26, mytext); myupdown->Attr.Style I= UDS_SETBUDDYINT I UDS_ALIGNRIGHT; inServiceGauge =new TGauge(this, "%d", IDC_SOLIDGAUGE1, GRIDMAX/GRIDSIZE+170,330, 100, 20, true); inQueueGauge new TGauge(this, "%d", IDC_SOLIDGAUGE2, GRIDMAX/GRIDSIZE+170,355, 100, 20, true); inServiceGauge->SetRange(0,100); inServiceGauge->SetValue(O); inServiceGauge->SetNativeUse(nuNever); inQueueGauge->SetRange(0,100); inQueueGauge->SetValue(O); inQueueGauge->SetNativeUse(nuNever); int i=O; for (int j=O;j<4;j++) for (int k=O;kSetRange(0,100); levelGauge(i]->SetValue(O); levelGauge[i]->SetNativeUse(nuNever); i++; Attr.X 0; Attr.Y 0; Attr.H 520; Attr.W 800; 162

PAGE 173

editStr =new char[lO]; SimulationPtr = (void *)&Simulation; void TDrawWindow::SetupWindow() TWindow::SetupWindow(); //Lets TWindow create any child controls GD =new ControlDialog(this,IDD_CONTROL); II mybutton->Create(); editStr[O] '1'; editStr[l) '\0'; II mytext->Create(); level = 1; editflag = true; myupdown->SetRange(l,LEVELMAX); myupdown->SetPos(l); runmsgflag = false; simcount = 0; II setup dialog box memoryStatus = new MEMORYSTATUS; memoryStatus->dwLength = sizeof(MEMORYSTATUS); newWin->Create(); newWin->Show(true); 163

PAGE 174

void TDrawWindow::plotsquare(int i, int j) DragDC->SelectStockObject(GRAY_BRUSH); DragDC->Rectangle(i*l-GRIDSIZE,yoffset-(j*GRIDSIZE), i*GRIDSIZE+l,yoffset-(j*GRIDSIZE-GRIDSIZE)+l); DragDC->RestoreBrush(); void TDrawWindow::plotvehicle(objectCoord gc,int vcolor) { int x, y; TColor r(255,0,0); TColor g(0,255,0); TColor b(0,0,255); TBrush br(TColor(255,0,0)); x = gc.getintegerX()IGRIDSIZE; y = gc.getintegerY()IGRIDSIZE; switch(vcolor) { case 1 case 2 case 3 DragDC->SelectObject(TBrush(b)) break DragDC->SelectObject(TBrush(r)) break DragDC->SelectObject(TBrush(g)) break DragDC->Rectangle(x-2,yoffset-(y-2), x+2,yoffset-(y+2)); DragDC->RestoreBrush(); void TDrawWindow::drawgrid(int level) { int i,j,top,right,tleft; TRect wrect; gridobject *grid= Simulation.getGrid(); int vcolor; II color of car blue up, green down, red sideways MSG Msg; TColor r(255,0,0); TColor g(0,255,0); TColor b(0,0,255); TColor bl(O,O,O); II get global memeory status GlobalMemoryStatus(memoryStatus); top = GRIDMAXIGRIDSIZE;

PAGE 175

right = GRIDMAXIGRIDSIZE; this->GetClientRect(wrect); II point.x = wrect.Left(); yoffset = wrect.Bottom(); tleft = GRIDMAXIGRIDSIZE + 20; II output the point values DragDC->Select0bject(*sfont2); switch(ucolor) { case 1 case 2 case 3 DragDC->SelectObject(TPen(b)); break; DragDC->SelectObject(TPen(r) ); break; DragDC->SelectObject(TPen(g)); break; I* sprintf(str,"P.x = "); DragDC->TextOut(tleft,lO,str,strlen(str)); sprintf(str,"%4.2f",p.x); DragDC->TextOut(SO,lO,str,strlen(str)); sprintf(str,"P.y = "); DragDC->TextOut(5,25,str,strlen(str)); sprintf(str,"%4.2f",p.y); DragDC->TextOut(50,25,str,strlen(str)); sprintf(str,"Q.x = "); DragDC->TextOut(5,40,str,strlen(str)); sprintf(str,"%4.2f",q.x); DragDC->TextOut(50,40,str,strlen(str)); sprintf(str,"Q.y = "); DragDC->TextOut(S,SS,str,strlen(str)); sprintf(str,"%4.2f",q.y); DragDC->TextOut(SO,SS,str,strlen(str)); sprintf(str,"button press %d",btncounter); DragDC->TextOut(5,70,str,strlen(str)); *I sprintf(str,"Updated = %d",ucolor); DragDC->TextOut(tleft,25,str,strlen(str)); sprintf(str,"VQ = %d, WQ = %d",Simulation.getVehicleQueueSize(), 165

PAGE 176

Simulation.getWaitQueueSize()); DragDC->TextOut(tleft,40,str,strlen(str) ); sprintf(str,"memory = %d",gridMemoryUsed); DragDC->TextOut(tleft,55,str,strlen(str) ); II sprintf(str,"rc %d",rc); sprintf(str,"VBlk %d HBlk = %d",vertica1Blocked,horizonta1Blocked); DragDC->TextOut(tleft,70,str,strlen(str)); if (runmsgflag) { sprintf(str,"Simulation Running"); DragDC->TextOut(tleft,85,str,strlen(str)); else sprintf(str,"Simulation Stoped ") ; DragDC->TextOut(tleft,85,str,strlen(str)); sprintf(str,"Seconds %d(%5.2f m) %d ",Simulation.secondCounter,Simulation.secondCounterl60.0,ucolor); DragDC->TextOut(tleft,lOO,str,strlen(str)); DragDC->SelectObject(*sfontl); DragDC->SelectObject(TBrush(bl)); DragDC->SelectObject(TPen(bl)); II Plot the grid for(i=O; i <=GRIDMAXIGRIDSIZE; i+=lO) { DragDC->MoveTo(O,yoffset-i); DragDC->LineTo(right,yoffset-i); DragDC->MoveTo(i,yoffset-0); DragDC->LineTo(i,yoffset-top); itoa(i,str,lO); if (!str(2]) str[3]=' '; str[4]= '\0'; DragDC->TextOUt(i-2,yoffset-top-lO,str,3); DragDC->TextOut(right+3,yoffset-i-2,str,3); } DragDC->SelectStockObject(NULL BRUSH); for (i=O; i < gridLayoutType; i++) 166

PAGE 177

DragDC->Ellipse(xyloc[i) .x,yoffset-xyloc[i) .y, xyloc[i) .x+2l,yoffset-xyloc[i) .y-21); vehiclePointer v; int id; list::iterator vlp = Simulation.getVehicleList().begin(); list::iterator vlpend = Simulation.getVehicleList().end(); if(!Simulation.getVehicleList() .empty()) do v = *vlp++; id = v->getiD(); if ((v->whereAreYou() .z > (level-1)) && (v->whereAreYou() .z < (level+ 1))) vcolor = v->getDirectionMovingin(); plotvehicle(v->whereAreYou(),vcolor); II Draw the line the vehicle is traversing if ((v->getLevel() level) && (routeDisplayFlag)) DragDC->MoveTo(v->getVehiclePosition().getintegerX()IGRIDSIZE, yoffset-v->getVehiclePosition() .getintegerY()IGRIDSIZE); DragDC->LineTo(v->getDestination() .getintegerX()IGRIDSIZE, yoffset-v->getDestination() .getintegerY()IGRIDSIZE); while (vlp != vlpend); DragDC->RestoreObjects(); void TDrawWindow::EvPaint() EngineLock.Lock(); 167

PAGE 178

DragDC new TPaintDC(HWindow); drawgrid(level); delete DragDC; DragDC=O; EngineLock.Unlock(); II Validate(); void TDrawWindow::EVClose() void TDrawWindow::EvCreate() void TDrawWindow::EvEdit() if (!editflagl return; int i level mytext->GetText(editStr,4); atoi(editStr); llgrid->clearGrid(level); p.x 0.0; p.y 0.0; q.x 0.0; q.y 0.0; InvalidateRect(updateRect); InvalidateRect(updateRect2); II Invalidate(false); 168

PAGE 179

void TDrawWindow::CmDlg() int x; if ((x =GD->Execute()) IDOK) Simulation.initEngine(this); myupdown->SetRange(l,LevelsUsed); inServiceGauge->SetRange(O,TOTVEHREQ); inQueueGauge->SetRange(O,TOTVEHREQ); for (int i=O;iSetRange(O,maxLevelDistribution); inServiceGauge->SetValue(O); inQueueGauge->SetValue(O); for (int i=O;iSetValue(O); setupOK = true; bool TDrawWindow::CanClose() Simulation.StopEngine(); II return MessageBox("Do you want to save?", "Drawing has changed", II MB YESNO MB_ICONQUESTION) == IDNO; return true; 169

PAGE 180

void TDrawWindow::EvLButtonDown(uint, TPoint& point) void TDrawWindow::EvRButtonDown(uint, TPoint& point) int i,j; objectCoord sl; float rp; int err; gridobject *grid Simulation.getGrid(); I* randomize(); II GD->Execute(); p.K GD->Px; p.y GD->Py; q.K GD->Qx; q.y GD->Qy; II grid->clearGrid(level); II grid->FillSquares(p,q,level); *I if (ucolor 3) ucolor = 0; ucolor++; inServiceGauge->SetValue(Simulation.getVehicleQueueSize()); inQueueGauge->SetValue(Simulation.getWaitQueueSize()); for (int i=O;iSetValue(grid->getLevelCount(i+l)); 170

PAGE 181

InvalidateRect(updateRect2); II Invalidate(false); //err= TDialog(this, l).Execute(); void TDrawWindow::EvMouseMove(uint, TPoint& point) I I if (DragDC) II DragDC->LineTo(point); void TDrawWindow::EvLButtonUp(uint, TPoint& point) void TDrawWindow::EvBtn() II II II II II II /'* gridobject '*grid Simulation.getGrid(); int i,j; objectCoord sl; float rp; gridobject '*grid Simulation.getGrid(); Route 3D *r; btncounter++; grid->clearGrid(level); 171

PAGE 182

II *I p.K random (200)110.0; p.y random (200)/10.0; q.x random (200)110.0; q.y random (200) 110.0; r = grid->FillSquares(p,q,level); inServiceGauge->SetValue(Simulation.getVehicleQueueSize()); inQueueGauge->SetValue(Simulation.getWaitQueueSize()); InvalidateRect(updateRect); Inva1idateRect(updateRect2); II Invalidate(false); newWin->GetClientWindow()->PostMessage(1033); II newWin->SetActiveWindow(); newWin->Invalidate(); II grid->dumpGrid(); bool TDrawWindow::EvUpdown(TNmUpDown& not) level= myupdown->GetPos(); return false; void TDrawWindow::EvRunBtn() if (Simulation.isRunning()) return; this->GetClientRect(updateRect); updateRect2.Set(updateRect.Left()+GRIDMAXIGRIDSIZE, updateRect.Top(), updateRect.Right(), updateRect.Top()+120); updateRect.Set(updateRect.Left(),updateRect.Top(), 172

PAGE 183

updateRect.Left()+GRIDMAX/GRIDSIZE,updateRect.Bottom()); if (! setupOK) CmDlg(); simcount = 0; randomize () ; Simulation.StartEngine(); void TDrawWindow::EvStopBtn() Simulation.StopEngine(); void TDrawWindow::EvContBtn() Simulation.Pause(); void TDrawWindow::EvRunMsgBtn() /* bool ok; long error; *I ok = PostMessage(l025,0,0); error= GetLastError(); Simulation.Continue(); LRESULT TDrawWindow::EvRunMsg(WPARAM a, LPARAM b) runmsgflag true; 173

PAGE 184

inServiceGauge->SetValue(Simulation.getVehicleQueueSize()); inQueueGauge->SetValue(Simulation.getWaitQueueSize()); InvalidateRect(updateRect); InvalidateRect(updateRect2); return 0; LRESULT TDrawWindow::EvStopMsg(WPARAM a, LPARAM b) runmsgflag = false; setupOK = false; inServiceGauge->SetValue(O); inQueueGauge->SetValue(O); InvalidateRect(updateRect); InvalidateRect(updateRect2); return 0; LRESULT TDrawWindow::EVCntMsg(WPARAM a, LPARAM b) simcount++; II InvalidateRect(updateRect); II InvalidateRect(updateRect2); EvBtn(); return 0; class TDrawApp public TApplication { 174

PAGE 185

) ; public: TDrawApp() : TApplication() {) void InitMainWindow(); void TDrawApp::InitMainWindow() boo! test,t,z; SetMainWindow(new TMyFrameWindow(O, "GRID VIEWER", new TDrawWindow, true)); test= GetMainWindow()->AssignMenu(l); newWin =new TMyFrameWindow(GetMainWindow(), "3D-Graphics", new TOpenGL_TestWindowView,false,200,300); //newWin->Attr.Style &= -(WS_SYSMENU); newWin->Attr.Style I= (WS_CLIPSIBLINGS); int OwlMain(int /*argc*/, char* /*argv*/ []) try{ rc 0; fp fopen("grid.out", "w+"); TDrawApp() .Run(); fclose(fp); catch ( ... ) { MessageBox(O,"Unassigned exception","System Error", MB YESNO MB_ICONQUESTION) == IDNO; return 0; 175

PAGE 186

11---------------------------------------------------------------------------II Project Vehicle Simulator II II II II II II II Copyright 1997. All Rights Reserved. SUBSYSTEM: FILE: AUTHOR: Route Master Computer RouteMastercomputer.cpp Bret A. Godwin DATE: November 1997 II II OVERVIEW II -------II This is the implementation file for the RouteMasterComputer class II that is part of the 3d route simulation II 11---------------------------------------------------------------------------finclude "RouteMasterComputer.hpp" finclude "globals.hpp" RouteRequest::RouteRequest() { ) RouteRequest::RouteRequest(Route3D r3D,vehiclePointer v, objectCoord& b, objectCoord& e) Route3DPtr = r3D; vehiclePtr = v; requestOrigin = b; requestDestination e; RouteRequest::-RouteRequest() { ) bool RouteRequest::operator== (const RouteRequest& arg) const { return false; bool RouteRequest::operator< (const RouteRequest& arg) const { return false; Route3D *RouteRequest::getRoute3DPtr() 176

PAGE 187

return Route3DPtr; vehicle *RouteRequest::getVehiclePtr() { return vehiclePtr; objectCoord &RouteRequest::getOrigin() { return requestOrigin; objectCoord &RouteRequest::getDestination() { return requestDestination; RouteMasterComputer::RouteMasterComputer() { ) void RouteMasterComputer::initRouteMasterComputer(int numobj, int gs, int pr, int oQS, int pQS, numberOfObjects : numobj; gridSize : gs; processRequestsPerSecond : pr; objectQueueSize : oQS; pendingQueueSize : pQS; gridPtr : gptr; Terminate = false; PauseComputer = false; gridobject *gptr) void RouteMasterComputer::cleanUp() { while(!RequestQueue.empty()) RequestQueue.pop front(); gridPtr->clearGrid(); Route3D *RouteMasterComputer::routeRequest(vehiclePointer v, objectCoord &x, objectCoord &y) { Route3D *r3D; RouteRequest r; if (RequestQueue.size() <: pendingQueueSize) { r3D : new Route3D; if (r3D) { ) r: RouteRequest(r3D,v,x,y); RequestQueue.push back(r); return r3D; -if (!r3D && errorLoggingOn) outFile << "Out of memory allocating new route" << endl; 177

PAGE 188

return NULL; void RouteMastercomputer::returnRouteRequest(RouteRequest &r,int level) { vehicle *v; objectCoord o,d; vehicleStats vs; v = r.getVehiclePtr(); vs = v->getVehicleStats(); v->OpdateVehicleRoute(level); if (statsloggingOnJ { o = v->getOrigin(); d v->getDestination(); statFile << "qa," << v->getiD() << "," << v->getLevel() << "," << v->calcXYdistance(o,d) << "," << vs.waitseconds << "," << getWaitQueueSize() << "," << vqueueSize << "," < < systemTime << endl; void RouteMasterComputer::processRequests(J { int i; RouteRequest r; int levelFound; int requests; i = 1; requests= RequestQueue.size(); if (requests >= processRequestsPerSecond) requests -processRequestsPerSecond; list ::iterator RqListPtr RequestQueue.begin(); list ::iterator RqListOldPtr = RequestQueue.begin(); while requests) && !RequestQueue.empty() && !Terminate && !PauseComputer) { r *RqListPtr; RqListOldPtr = RqListPtr++; II r RequestQueue.front(); II RequestQueue.pop(); II if (! (levelFound = FindRoute(r)J) II RequestQueue.push(rJ; II else II returnRouteRequest(r,levelFound); II if ((levelFound c FindRoute(r)J) { RequestQueue.erase(RqListOldPtr); returnRouteRequest(r,levelFound); requests i++; RequestQueue.size(); void RouteMasterComputer::receiveTransponder(vehicle *vptr, gridCoord &gc) 178

PAGE 189

list *vGridListPtr = vptr->getVehicleRoutePtr()->getRouteGridSquareListPtr(); list ::iterator head= vGridListPtr->begin(); list ::iterator tail; if ((tail= find(vGridListPtr->begin(), vGridListPtr->end(), gc)) vGridListPtr->end()) return; while(! (*head== *tail)) { gridPtr->clearSquare(*head,vptr->getiD()); if (*head == gc) { vGridListPtr->pop_front(); return; head++; vGridListPtr->pop_front(); int RouteMasterComputer::FindRoute(RouteRequest &request) { int i, levels,cntr; int assignedLevel; int distance; int viD; vehicle *v; objectCoord o,d; SYSTEMTIME t1, t2; int lt1, lt2,ltf; GetSystemTime(&t1); WORD wHour; WORD wMinute; WORD wSecond; WORD wMilliseconds; lt1 = t1.wHour 3600*1000 + t1.wMinute 60*1000 + t1.wSecond*1000 + t1.wMilliseconds; Route3D *routePtr = request.getRoute3DPtr(); distance= request.getVehiclePtr()->calcXYdistance(); v = request.getVehiclePtr(); viD = v->getiD(); o v->getOrigin(); d = v->getDestination(); II Allocate based on distance first if (distance> (GRIDMAX *.75)) { i = .75 gridPtr->getMaxLevels(); levels= gridPtr->getMaxLevels(); if (routeLevelOptions == 2) II 314 of grid or longer i += random(gridPtr->getMaxLevels() .25); else if (distance> (GRIDMAX *.5)) { II 112 of grid or longer 179

PAGE 190

i = .5 gridPtr->getMaxLevels(); levels= gridPtr->getMaxLevels(); if (routeLevelOptions == 2) i += random(gridPtr->getMaxLevels() .25); } else if (distance> (GRIDMAX *.25)) { i = .25 gridPtr->getMaxLevels(); levels= gridPtr->getMaxLevels(); if (routeLevelOptions == 2) II 1/4 of grid or longer i += random(gridPtr->getMaxLevels() .25); else { i = 1; levels= gridPtr->getMaxLevels(); if (routeLevelOptions == 2) II short distances i += random(gridPtr->getMaxLevels() .25); assignedLevel = 0; II priority lowers the start level i = i-(gridPtr->getMaxLevels() request.getVehiclePtr()->getPriority() .25); if (routeLevelOptions == 3) i = 1; if (i < 1) i = 1; if (i > gridPtr->getMaxLevels()) i = gridPtr->getMaxLevels(); if (routePtr->getVerticalBlocked()) routePtr->clearVerticalBlocked(); cntr = 0; //Terminate is a global flag that indicates a request has been //made to shut down the simulation while ((i <=levels) && !routePtr->getVerticalBlocked() && !routePtr->getRouteFound() && !Terminate) assignedLevel gridPtr->SetRoute(request.getOrigin(), request.getDestination(), abs(i),routePtr,request.getVehiclePtr() ); i++; cntr++; GetSystemTime(&t2); lt2 = t2.wHour 3600*1000 + t2.wMinute 60*1000 + t2.wSecond*1000 + t2.wMilliseconds; ltf = lt2 -lt1; if (statsloggingOn) { if (!routePtr->getRouteFound()) assignedLevel = 0; qstatFile << "rc," << v->calcXYdistance(o,d) << "," << cntr << "," << assignedLevel << "," << ltf << "," << viD << endl; 180

PAGE 191

return assignedLevel; gridobject *RouteMasterComputer::getGridPtr() { return gridPtr; int RouteMasterComputer::getWaitQueueSize() { return RequestQueue.size(); void RouteMasterComputer::stopMasterComputer() { Terminate = true; void RouteMasterComputer::pause() { PauseComputer = true; void RouteMasterComputer::resume() { PauseComputer = false; 181

PAGE 192

ll---------------------------------------------------------------------------11 Project Vehicle Simulator II II II II II II II Copyright 1997. All Rights Reserved. SUBSYSTEM: FILE: AUTHOR: Route Master Computer RouteMasterComputer.hpp Bret A. Godwin DATE: November 1997 II II OVERVIEW II -------11 This class header file defines the route master computer class II which manages the routes associated with requests from a source II to a destination in the simulation II 11----------------------------------------------------------------------------iifndef routemastercomputerhpp idefine routemastercomputerhpp iinclude iinclude finclude "grid.hpp" iinclude "vehicle.hpp" using namespace std; class RouteRequest { public: RouteRequest(); RouteRequest(Route3D *r3D, vehiclePointer v, objectCoord &b, objectCoord &e); -RouteRequest(); bool operator== (const RouteRequest& arg) const; boo! operator< (const RouteRequest& arg) const; Route3D *getRoute3DPtr() vehicle *getVehiclePtr() objectCoord &getOrigin() 182

PAGE 193

objectCoord &getDestination(); private: ); Route3D *Route3DPtr; vehiclePointer vehiclePtr; objectCoord requestOrigin; objectCoord requestDestination; class RouteMasterComputer { public: RouteMasterComputer(); void initRouteMasterComputer(int numobj, int gs, int oQS, int pQS, gridobject *gptr); Route3D *routeRequest(vehiclePointer v, objectCoord &x, objectCoord &y); void cleanUp(); void processRequests(); void receiveTransponder(vehicle *vptr, gridCoord &gc); int FindRoute(RouteRequest &request); gridobject *getGridPtr(); int getWaitQueueSize(); void stopMasterComputer(); void pause(); void resume(); private: void returnRouteRequest(RouteRequest &r, int level); int numberOfObjects; 183 int pr,

PAGE 194

int gridSize; int processRequestsPerSecond; int objectQueueSize; int pendingQueueSize; boo! Terminate; boo! PauseComputer; gridobject *gridPtr; list RequestQueue; ) ; tendif 184

PAGE 195

11---------------------------------------------------------------------------II Project Vehicle Simulator I I II 1997. All Rights Reserved. II II SUBSYSTEM: I I FILE: II AUTHOR: I I DATE: II II OVERVIEW II -------Route Master Computer vehicle.cpp Bret A. Godwin November 1997 II This is the method implementation code for the vehicle class for II the 3 dimensional routing simulation II 11---------------------------------------------------------------------------linclude "vehicle.hpp" linclude "RouteMasterComputer.hpp" linclude $extern Gridinfo gridData; vehic1e::vehicle\left(int vacc, int vdecc, int haec, int hdecc, int vvelmax, int hvelmax, int id, RouteMasterComputer *cc\right) int r; objectCoord temp; origin= objectCoord\left(true,1\right); position = origin; destination= objectCoord\left(true,vMovmentOptions\right); if \left(vArrivalOptions == 2\right) \left\{ temp = origin; origin = destination; destination c temp; position z origin; haccelleration haec; hdecelleration c hdecc; vaccelleration vacc; vdecelleration vdecc; velocity = 0; vvelocitymax = vvelmax; hve1ocitymax = hve1max; vehicleiD = id; controlCentral c cc; 185$

PAGE 196

WaitingForRoute = true; ArrivedOK = false; distCalc = false; vehicleDirection 0; routeLevel = 0; moveseconds = 0; totalmoveseconds 0; waitseconds = 0; r = random(10); if (r == ll priority = 2; else if ( (r==2) 1 1 (r ==3)) priority 1; else priority 0; vehicleRoutePtr = requestRoute(); //after controlCentral is vehicle::vehicle() ( controlCentral = NULL; vehicleRoutePtr = NULL; vehicle::-vehicle() ( if (vehicleRoutePtr) delete vehicleRoutePtr; II priority is 2 10% of the time. II priority is a 1 20% II otherwise, priority is zero //this needs to be called //assigned a valid pointer bool vehicle::operator== (const vehicle& arg) const ( if (this->vehicleiD return true; return false; arg.vehicleiD) bool vehicle::operator< (const vehicle& arg) const ( if(this->vehicleiD < arg.vehicleiD) return true; return false; objectCoord vehicle::whereAreYou() return position; objectCoord vehicle::getOrigin() return origin; ) objectCoord vehicle::getDestination() return destination; void vehicle::setAccelleration(int a) ( haccelleration = a; 186

PAGE 197

void vehicle::setDecelleration(int d) { hdecelleration = d; void vehicle::setVelocityMax(int vm) { hvelocitymax = vm; int vehicle::getQuadrant(float deltax, float deltay) { if ({deltax >= 0) && (deltay >= 0) && (deltay < deltax)) { I 0 <= theta < 4 5 I return 1; ) else if ((deltax > 0) && (deltay >= 0) && (deltay >= deltax)) I* 45 <= theta < 90 *I return 2; ) else if ((deltax <=OJ && (deltay >= 0) && (deltay > -deltax)l I* 90 <= theta < 135 *I return 3; ) else if ((deltax <= 0) && (deltay > 0) && (deltay <= -deltax)) I* 135 <= theta < 180 *I return 4; ) else if ( (deltax <= 0) && (deltay <= 0) && (deltay > deltaxll I* 180 <= theta < 225 *I return 5; ) else if ((del tax < 0) && (deltay <= OJ && (deltay <= del tax)) I* 225 <= theta < 270 *I return 6; } else if ((del tax >= 0) && (deltay <= 0) && (-deltay > deltax)l I* 270 <= theta < 315 *I return 7; } else if ((del tax >= 0) && (deltay < 0) && (-deltay <= deltax)) I* 315 <= theta < 360 *I return 8; else return 0; void vehicle::resetMoveSeconds() 187

PAGE 198

rnoveseconds 0; void vehicle::calcXYvelocity(objectCoord &x2) float dist calcXYdistance(position,x2) gridData.squarefeet; float vfactor, accelDistance; for (int i=4;i>O; i--) { vfactor = il4.0; accelTirne = (hvelocityrnax vfactor)l(haccelleration vfactor); accelDistance (.5 haccelleration vfactor accelTirne accelTirne); decelDistance (pow(hvelocitymax vfactor,2)1(2 hdecelleration*vfactor)); if ((accelDistance + decelDistance) < dist) { decelTime = ((dist-(decelDistance + accelDistance)) I (hvelocityrnax vfactor)) + accelTime + l; hvelocityrnax *= vfactor; hdecelleration *= vfactor; haccelleration *= vfactor; if (loggingOn) outFile << "at << accelTime << endl << return; return; "ad << accelDistance << endl << "dt << decelTime << endl << "dd << decelDistance << endl << "dist n << dist << endl; float vehicle::calcXYdistance(objectCoord &xl, objectCoord &x2) { return sqrt(pow(x2.xxl.x,2) + pow(x2.y-xl.y,2)); int vehicle::calcXYdistance() { return int(calcXYdistance(origin,destination)); float vehicle::calcV(objectCoord &x2) { double x, adistance, vdistance; int velocityTime, decTirne; adistance vdistance .5 haccelleration accelTime accelTime; hvelocitymax (decelTime -accelTime) + adistance; II for accelleration x = ll2atA2 for 0 < t < accelTime if (moveseconds <= accelTirne) 188

PAGE 199

) x = (.5 haccelleration moveseconds moveseconds); velocity = haccelleration moveseconds; II for normal velocity after accelleration II x = vt; where vis constant velocity after accelleration II for t > accelTime and less than decelTime else if ((moveseconds > accelTime) && (moveseconds <= decelTime)) { ) velocityTime = moveseconds -accelTime; x = hvelocitymax velocityTime + adistance; if (loggingOn) outFile << "vTime << velocityTime << endl << "x << x << endl; II for decelleration, x = vt ll2atA2; II II II v = moving velocity decelTime < t < t when v = 0 a = decelleration constant else { decTime = moveseconds -decelTime; x = fabs(hvelocitymax decTime-.5 hdecelleration decTime decTime) + vdistance; return x; void vehicle::calcZvelocity(objectCoord &x2) { float dist = calcZdistance(x2) gridData.levelsize; float vfactor, accelDistance; for (int i=4;i>O; i--) { vfactor = il4.0; accelTime = (vvelocitymax vfactor)l(vaccelleration vfactor); accelDistance (.5 vaccelleration vfactor accelTime accelTime); decelDistance (pow(vvelocitymax vfactor,2)1(2 vdecelleration*vfactor)); if ((accelDistance + decelDistance) < dist) { decelTime = ((dist-(decelDistance + accelDistance)) I (vvelocitymax vfactor)) + accelTime + 1; vvelocitymax *= vfactor; vdecelleration *= vfactor; vaccelleration *= vfactor; return; return; float vehicle::calcZdistance(objectCoord &x2) { return x2.z -position.z; float vehicle::calcZ(objectCoord &x2) 189

PAGE 200

float x, adistance, vdistance; int velocityTime, decTime; adistance vdistance .5 vaccelleration accelTime accelTime; vvelocitymax (decelTime -accelTime) + adistance; II for accelleration x = ll2atA2 for 0 < t < accelTime if (moveseconds <= accelTime) { x = (.5 vaccelleration moveseconds moveseconds); velocity = vaccelleration moveseconds; } II for normal velocity after accelleration II x = vt; where vis constant velocity after accelleration II for t > accelTime and less than decelTime else if ((moveseconds > accelTime) && (moveseconds <= decelTime)) { velocityTime = moveseconds -accelTime; x = vvelocitymax velocityTime + adistance; ) II for decelleration, x II vt -ll2atA2; v = moving velocity decelTime < t < t when v = 0 a = decelleration constant II II else { decTime = moveseconds -decelTime; x = fabs(vvelocitymax (decTime) -.5 vdecelleration decTime decTime) + vdistance; return x; objectCoord vehicle::calculateMove(objectCoord &p2) { int verticalVelocity = BB; int horizontalVelocity = 323; double xdelta, ydelta, zdelta, angle; objectCoord newposition; gridCoord currentSquare, newSquare; bool vehicleLanded, routeSegmentComplete; int quadrant, directionx, directiony, directionz; currentSquare getCurrentGridSquare(position); if (moveseconds 0) { moveseconds = 1; oldposition = position; xdelta p2.x -oldposition.x; ydelta = p2.y -oldposition.y; zdelta = p2.z -oldposition.z; velocity = 0; if (zdelta != 0) calcZvelocity(p2); else 190

PAGE 201

calcXYvelocity(p2); xdelta ydelta zdelta p2.x -oldposition.x; p2.y -oldposition.y; p2.z -oldposition.z; angle= atan(fabs(ydeltallfabs(xdelta)); quadrant= getQuadrant(xdelta, ydelta); newposition = position; switch(quadrant) { case 1 directionx case 2 directionx case 3 directionx case 4 directionx case 5 directionx case 6 directionx case 7 directionx case 8 directionx default: directionx 1; directiony 1; directiony -1; directiony -1; directiony -1; directiony -1; directiony 1; directiony 1; directiony 0; directiony = 1; break;} = 1; break;} 1; break;} 1; break;} -1; break;} -1; break;} -1; break;) -1; break;) 0; } II set vehicle direction for color output display if (zdelta < 0) { directionz = -1; vehicleDirection 3; else if (zdelta > 0) { directionz = 1; vehicleDirection 1; else vehicleDirection 2; if (xdelta != 0) newposition.x = directionx (calcV(p2)1gridData.squarefeet} coscangle) + oldposition.x; if (ydelta != 0) { newposition.y = directiony (calcV(p2)1gridData.squarefeet) sin(angle) + oldposition.y; if (zdelta != 0) { newposition.z = directionz (ca1cZ(p2ll gridData.levelsize) + oldposition.z; moveseconds++; routeSegmentComplete false; vehicleLanded = false; if (xdelta > 0) { if (p2 < newposition) { routeSegmentComplete true; 191

PAGE 202

else if (xdelta < 0) { if (newposition < p2) { routeSegmentComplete true; else if ((xdelta == 0) && {ydelta != 0)) { if ((ydelta < 0) && (newposition < p2)) routeSegmentComplete = true; else if ((ydelta > 0) && (p2 < newposition)l routeSegmentComplete = true; else if ((xdelta == 0) && (ydelta { 0) && (zdelta != 0)) if ((zdelta < 0) && (newposition < p2)) routeSegmentComplete = true; vehicleLanded = true; else if ((zdelta > 0) && (p2 < newposition)) routeSegmentComplete = true; else if ((xdelta == 0) && (ydelta { routeSegmentComplete = true; if (routeSegmentComplete) { 0) && (zdelta newposition = vehicleRoutePtr->getroute()->front(); vehicleRoutePtr->getroute()->pop front(); totalmoveseconds += moveseconds;-moveseconds = 0; 0)) if (vehicleDirection == 2) II were no longer on that level controlCentral->getGridPtr()->removeFromLevel(routeLevel); newS quare getCurrentGridSquare(newposition); if (loggingOn) outFile << vehicleiD << " << "Current vs. Old square << currentSquare << " << newSquare << endl; if ((! (newSquare == currentSquare)) I 1 vehicleLanded) sendTransponder(newSquare); return newposition; 192

PAGE 203

objectCoord vehicle::moveVehicle() { if (vehicleRoutePtr { NULL) //computer didn't respond to request waitseconds++; vehicleRoutePtr = requestRoute(); else if (!vehicleRoutePtr->getRouteFound()) //no route available yet waitseconds++; else if(!WaitingForRoute && vehicleRoutePtr->getRouteFound() && !ArrivedOK) { if ('vehicleRoutePtr->getroute()->empty()) { position= calculateMove(vehicleRoutePtr->getroute()->front()); else ArrivedOK return position; true; void vehicle::sendTransponder(gridCoord &gc) { if (loggingOn && (routeLevel == 1)) { outFile << *this; controlCentral->receiveTransponder(this, gc); if (loggingOn &&(routeLevel == 1)) { outFile << "Sent Transponder update to Contro!Central" << gc << end!; outFile << *this; void vehicle::setVehicleiD(int t) ( vehicleiD = t; int vehicle::getiD() { return vehicleiD; Route3D *vehicle::requestRoute() { return controlCentral->routeRequest(this, position, destination); void vehicle::UpdateVehicleRoute(int level) { WaitingForRoute = false; setLevel(level); boo! vehicle::atDestination() { return ArrivedOK; 193

PAGE 204

gridCoord vehicle::getCurrentGridSquare(objectCoord &oc) { return controlCentral->getGridPtr()->find_square(oc); } Gridlnfo vehicle::getGridinfo() { return controlCentral->getGridPtr()->getGridinfo(); } Route3D *vehicle::getVehicleRoutePtr() { return vehicleRoutePtr; int vehicle:: getDirectionMovingin() { return vehicleDirection; int vehicle::getLevel() { return routeLevel; void vehicle::setLevel(int level) { routeLevel = level; ostream& operator<<(ostream& os, vehicle& v) { os << "vehicle= << v.vehicleiD << ", priority= << int(v.priority) << end! << "Start, Pos, End : << v.origin << v.position << v.destination << end! << "waitforroute << v.WaitingForRoute << ",arrivedOK << v.ArrivedOK << ",direction << int(v.vehicleDirection} << ,routelevel << int(v.routeLevel) << end! << "velocity n << v.velocity << ,movesec n << v.moveseconds << ",waitsec << v.waitseconds << ", n << end! << "Route3DList << *v.vehicleRoutePtr << end!; return os; vehicleStats vehicle::getVehicleStats() { vehicleStats vs; vs.waitseconds = waitseconds; vs.totalmoveseconds = totalmoveseconds; vs.distance = calcXYdistance(origin,destination); vs.routeLevel = routeLevel; return vs; boo! vehicle::calculateTempMove(objectCoord &p2, int vertica!Velocity = 88; int horizonta!Velocity = 323; list ::iterator &routepos, EtaData *eta) double xdelta, ydelta, zdelta, angle; objectCoord newposition; 194

PAGE 205

gridCoord vehicle::getCurrentGridSquare(objectCoord &oc) { return controlCentral->getGridPtr()->find_square(oc); } Gridinfo vehicle::getGridinfo() { return controlCentral->getGridPtr()->getGridinfo(}; } Route3D *vehicle::getVehicleRoutePtr() { return vehicleRoutePtr; } int vehicle:: { return vehicleDirection; int vehicle::getLevel() { return routeLevel; void vehicle::setLevel(int level) { routeLevel = level; ostream& operator<<(ostream& os, vehicle& v) { OS << "vehicle= << v.vehicleiD << ", priority= << int(v.priority) << end! << "Start, Pos, End : << v.origin << v.position << v.destination << endl << "waitforroute << v.WaitingForRoute << ",arrivedOK << v.ArrivedOK << ",direction << int(v.vehicleDirection) << ,routelevel << int(v.routeLevel) << endl << "velocity n << v.velocity << n ,movesec n << v.moveseconds << ",waitsec << v.waitseconds << ", n << endl << "Route3DList << *v.vehicleRoutePtr << end!; return os; vehicleStats vehicle::getVehicleStats() { vehicleStats vs; vs.waitseconds = waitseconds; vs.totalmoveseconds = totalmoveseconds; vs.distance = calcXYdistance(origin,destination); vs.routeLevel = routeLevel; return vs; boo! vehicle::calculateTempMove(objectCoord &p2, int verticalVelocity = 88; int horizontalVelocity = 323; list ::iterator &routepos, EtaData *eta) double xdelta, ydelta, zdelta, angle; objectCoord newposition; 195

PAGE 206

gridCoord currentSquare, newSquare; boo! vehicleLanded, routesegmentComplete; int quadrant, directionx, directiony, directionz; static boo! changesquareflag; current Square getCurrentGridSquare(position); if (moveseconds == 0) { changesquareflag = true; moveseconds = 1; oldposition = position; xdelta p2.x -oldposition.x; ydelta = p2.y-oldposition.y; zdelta = p2.z -oldposition.z; velocity = 0; if (zdelta != 0) calcZvelocity(p2); else calcXYvelocity(p2); xdelta ydelta zdelta p2.x -oldposition.x; p2.y -oldposition.y; p2.z -oldposition.z; angle= atan(fabs(ydelta)lfabs(xdelta)); quadrant= getQuadrant(xdelta, ydelta); newposition = position; switch(quadrant) { case 1 directionx case 2 directionx case 3 directionx case 4 directionx case 5 directionx case 6 directionx case 7 directionx case 8 directionx default: directionx 1; directiony = 1; directiony = -1; directiony -1; directiony -1; directiony -1; directiony 1; directiony 1; directiony 0; directiony 1; break;} 1; break;} 1; break;} 1; break; I -1; break; I -1; break; I -1; break;) -1; break;} 0; ) II set vehicle direction for color output display if (zdelta < 0) { directionz = -1; vehicleDirection 3; } else if (zde1ta > OJ { directionz 1; vehicleDirection 1; else vehicleDirection 2; if {xdelta != OJ newposition.x = directionx (calcV(p2JigridData.squarefeet) 196

PAGE 207

if (ydelta != 0) { cos(angle) + oldposition.x; newposition.y = directiony (calcV(p2J/gridData.squarefeetl sin(angle) + oldposition.y; ) if (zdelta != 0) { newposition.z = directionz (calcZ(p2)/ gridData.levelsizel + oldposition.z; moveseconds++; totalmoveseconds++; routeSegmentComplete false; vehicleLanded = false; if (xdelta > 0) { if (p2 < newpositionl { routeSegmentComplete else if (xdelta < 0) { if (newposition < p2) { routeSegmentComplete true; true; else if ((xdelta == 0) && (ydelta != 0)) { if ((ydelta OJ && (p2 < newposition)) routeSegmentComplete = true; else if ((xdelta == 0) && (ydelta { 0) && (zdelta != 0)) if ((zdelta 0) && (p2 < newposition)) routeSegmentComplete = true; else if ((xdelta == 0) && (ydelta { routeSegmentComplete = true; if (routeSegmentComplete) { 0) && (zdelta 197 0))

PAGE 208

newposition routepos++; move seconds *routepos; 0; newSquare getCurrentGridSquare(newposition); if (loggingOn) outFile << vehicleiD << " << "Current vs. Old square << currentSquare << " << newSquare << endl; position = newposition; eta->vehicleiD = vehicleiD; if (changesquareflag) eta->startTime = totalmoveseconds+systemTime; if ((! (newSquare == currentSquare)) 11 vehicleLanded) { eta->endTime = totalmoveseconds+systemTime; changesquareflag = true; return true; changesquareflag false; return false; int vehicle::getMoveSeconds() { return moveseconds; } gridCoord vehicle::getPosition() { return getCurrentGridSquare(position); void vehicle::setRouteNull() { vehicleRoutePtr = NULL; objectCoord vehicle::getVehiclePosition() { return position; int vehicle::getPriority() { return priority; bool vehicle::waitingForARoute() { return WaitingForRoute; } 198

PAGE 209

11---------------------------------------------------------------------------II Project Vehicle Simulator II II Copyright 1997. All Rights Reserved. II II SUBSYSTEM: II FILE: II AUTHOR: II DATE: II II OVERVIEW II -------Route Master Computer vehicle.hpp Bret A. Godwin November 1997 II This class describes the vehicle object that will move in the three II dimensional environment II 11---------------------------------------------------------------------------linclude linclude linclude linc.ude "grid.hpp" lifndef vehiclehpp ldefine vehiclehpp class RouteMasterComputer; using namespace std; typedef struct { class vehicle { public: int waitseconds; int totalmoveseconds; float distance; byte routeLevel; vehicleStats; vehicle(int vacc, int vdecc, int haec, int hdecc, int vvelmax, int hvelmax, int id, RouteMasterComputer *cc); vehicle (); -vehicle(); boo! operator== (const vehicle& arg) const; boo! operator< (const vehicle& arg) const; objectCoord whereAreYou(); objectCoord getOrigin(); objectCoord getDestination(); void setAccelleration(int a); void setDecelleration(int d); 199

PAGE 210

void setVelocityMax(int vm); objectCoord moveVehicle(); Route3D requestRoute(); void sendTransponder(gridCoord &gc); void setVehicleiD(int t); void resetMoveSeconds(); int getiD(); void UpdateVehicleRoute(int level); objectCoord calculateMove(objectCoord &p2); bool atDestination(); gridCoord getcurrentGridSquare(objectCoord &oc); Gridinfo getGridinfo(); Route3D *getVehicleRoutePtr(); int getQuadrant(float deltax, float deltayl; int getDirectionMovingin(); int getLevel(); int getMoveSeconds(); gridCoord getPosition(); void setLevel(int level); friend ostream& operator<<(ostream& os, vehicle& v); float calcV(objectCoord &x2); float calcZ(objectCoord &x2); void calcXYvelocity(objectCoord &x2); float calcXYdistance(objectCoord &xl, objectCoord &x2); int calcXYdistance(); void calcZvelocity(objectCoord &x2); float calcZdistance(objectCoord &x2); vehicleStats getVehicleStats(); bool calculateTempMove(objectCoord &p2, void setRouteNull(); list ::iterator &routepos, EtaData eta); objectCoord getVehiclePosition(); int getPriority(); bool waitingForARoute(); private: ); objectCoord origin; objectCoord position; objectCoord destination; objectCoord oldposition; byte haccelleration; byte hdecelleration; byte vaccelleration; byte vdecelleration; short velocity; short hvelocitymax; short vvelocitymax; int vehicleiO; Route3D vehicleRoutePtr; RouteMasterComputer controlCentral; bool WaitingForRoute; bool ArrivedOK; bool distCalc; byte vehicleDirection; byte routeLevel; short moveseconds; short totalmoveseconds; short waitseconds; short accelTime; float decelDistance; short decelTime; byte priority; 200

PAGE 211

typedef vehicle vehiclePointer; #endif 201

PAGE 212

APPENDIX C SIMULATION 3D GRAPHICAL OUTPUT Appendix C contains several screen captures of the 3D output window of the simulator. Each screen capture portrays a unique view of the simulation during execution of a 1 00 vehicle simulation in a metro area similar to the Denver metro area. Light blue objects are vehicles moving upwards, yellow objects are vehicles moving horizontally, and magenta colored objects represent vehicles moving downward. The colored lines represent the route paths a vehicle will move along towards it's destination. The blue line is the upward path, red the horizontal path, and green the downward path . 3D-Graphics fl'lif 13 Figure C-1: Vehicles taking off and moving towards central locations similar to 202

PAGE 213

downtown Denver. Figure C-2: Vehicles in flight moving towards two locations in the Denver metro area simulation. 203

PAGE 214

Figure C-3: Vehicles ending their flight in the Denver metro area simulation. 204

PAGE 215

Figure C-4: Vehicles taking otT and in transit for the Denver Metro Area Simulation. 205

PAGE 216

REFERENCES [ 1] Ackoff, Russell L. and Sasieni, Maurice W, Fundamentals of Operation Research, New York, John Wiley & Sons, Inc., 1968. [2] Bellamy, John, Digital Telephony, 2"d Edition, New York: Wiley-Interscience, 1991. [3] Bertsirnas D. J. and van Ryzin, G., A stochastic and dynamic vehicle routing problem in the euclidean plane: the multiple-server, capacitated vehicle case. Operations Research, 1993, 41:60-76. [4] Connen, Thomas H., Leiserson, Charles E., and Rivest, Ronald L., Introduction to Algorithims, Yew York, McGraw-Hill Book Company, 1990. [5] Do\WS, Anthony, Stuck in TrafficCoping with peak-hour traffic congestion, The Brookings Institution, Washington D.C., 1992. [6] Dror, M, G. Laporte, and P. Trudeau, Vehicle routing with stochastic demands: Properties and solution frameworks, Transportation Science, 1993, 23:166-176. [7] Freedman, David H., Chasing the Jetsons, Discover, September 1997, pp 4855. [8] FAA, Free Flight: An Introduction, FAA Publications, December 1990. [9] Garber, Nicholas J. and Hoel, Lester A., Traffic and Highway Engineering, second edition, Boston, PWS Publishing Co, 1997. [10] Glassner, AndrewS., Graphics Gems, Boston, AP 1990. [11] Gross, Donald and Harris, Carl M., Fundamentals of Queuing Theory, New York, John Wiley & Sons, Inc, 1974. [12] Hall, Thomas A., Engineering 2151 Century Highways, American Society of Engineers, New York, 1989, pp105118. 206

PAGE 217

[13] Lucas A., Ljungberg M.,. Evertsz R., Tidhar G., Goldie R., and Maisano P., New techniques for air traffic management for single and multiple airports,_ Tech. Rep. 51, Australian Artificial Intelligence Institute, Melbourne, Australia, April 1984. [14] Laporte, G. and Louveaux, F., "The vehicle routing problem with stocastic travel times", Transportation Science, 1992, 26(3):161-170. [ 15] Martin, James, Local Area Networks, Architectures and Implemenations. Englewood Cliffs: Prentice Hall, Inc, 1989. [16] Panico, Joeseph A, Queuing Theory: A Study of Waiting Lines for Business, Economics, and Science, Englewood Cliffs, NJ, Prentice Hall, 1969. [17] Pollatschek, Moshe A. Programming Discrete Simulations, Lawerence Kansas, R&D Books, 1995. [18] Powell, W., "A stochastic model ofthe dynamic vehicle allocation problem", Transportation Science, 1986,20:117-129. [19] Powell, W., "A Stochastic Formulation ofthe Dynamic Assigrunent Problem, with an Application to Truckload Motor Carriers. Statistics and Operations Research", Technical Report SOR-94-03, Princeton University, 1995. [20] Spohn, Darren L., Data Network Design, second edition:LNew York, McGraw Hill, 1997. [21] Taha, Hamdy A., Operations Research and Introduction, third edition, New York, Macmillan Publishing Co., Inc, 1982. [22] Zueben, Monte and Fox, MarkS., Intelligent Scheduling, San Francisco, Morgan Kaufmann Publishers, 1994. 207