Development of Optimization and Simulation Models

for the Analysis of Airfield Operations

by
Hojong Baik

Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University
in partial fulfillment of the requirements for the degree of
Doctor of Philosophy
in
Civil Engineering

Antonio A. Trani, Co-Chair

Hanif D. Sherali, Co-Chair

Dusan Teodorovic
Hesham Rakha
Julio C. Matinez

May 2000
Blacksburg, Virginia

Keyword: Integer Programming, Microscopic Simulation Model, Airport Terminal Area

Copyrritght 2000, Hojong Baik

Development of Optimization and Simulation Models

for the Analysis of Airfield Operations
by
Hojong Baik
Co-Chairmen: Professor Antonio A. Trani, and Professor Hanif D. Sherali.
(ABSTRACT)
This research is concerned with the modeling and development of algorithmic approaches for
solving airport operational problems that arise in Air Traffic Control (ATC) systems within the
terminal area at hub airports. Specifically, the problems addressed include the Aircraft
Sequencing Problem (ASP) for runway operations, the Network Assignment Problem (NAP) for
taxiway operations, and a simulation model for the evaluation of current or proposed ATC system
in detail.
For the ASP, we develop a mathematical model and apply the Reformulation-LinearizationTechnique (RLT) of Sherali and Adams to construct an enhanced tightened version of the
proposed model. Since ASP is NP-Hard and in fact, it is a variation of the well-known Traveling
Salesman Problem with time-windows, sub-optimal solutions are usually derived to
accommodate the real-time constraints of ATC systems. Nevertheless, we exhibit a significant
advancement in this challenging class of problem. Also for the purpose of solving relatively large
sized problems in practice, we develop and test suitable heuristic procedures.
For the NAP, we propose a quasi-dynamic assignment scheme which is based on the incremental
assignment technique. This quasi-dynamic assignment method assumes that the current aircraft
route is influenced only by the previous aircraft assigned to the network. This simplified
assumption obviates the need for iterative rerouting procedures to reach a pure equilibrium state
which might not be achievable in practical taxiway operations. To evaluate the overall system, we
develop a microscopic simulation model. The simulation model is designed to have the capability
for reproducing not only the dynamic behavior of aircraft, but also incorporates communication
activities between controllers and pilots. These activities are critical in ATC operations, and in
some instances, might limit the capacity of the facility.
Finally, using the developed simulation model named Virginia Tech Airport Simulation Model
(VTASM) in concert with ASP and NAP, we compare the overall efficiencies of several control
strategies, including that of the existing control system as well as of the proposed advanced
control system.

ii

This dissertation is dedicated to the memory of

my mother Gyu-young Ahn

iii

Acknowledgements

I would first like to thank my advisors, Dr. Antonio A. Trani and Hanif D. Sherali, for their
invaluable guidance, patience and inspiration during my entire studying at Virginia Tech. Without
their supports, this dissertation would not have been completed. I also indebted to them for
providing financial support through the National Center of Excellence for Aviation Operations
Research (NEXSTOR) and for numerous opportunities they have presented me with.
I have also been honored to have Dr. Dusan Teodorovic, Dr. Hesham Rakha, and Dr. Julio
Matinez as members of my committee. Special thanks go to my previous teacher, Dr. Kangwon
Lim, at Seoul National University for his encouragement.
I would like to thank my friends including Dr. Youn-soo Kang, Myung-hyun Lee, Dr. Jeong-gyu
Kang, Dr. Gyuhae Park, Heunggweon Sin, Sungpil Hahm, and Kyungho Ahn for their support
and warmhearted friendship.
I could not thank enough my parents, Chang-ki Baik and Gyu-young Ahn, and parents-in-law,
Won-woo Park and Eun-ja Kim, for their unconditional love and faith in me. Thanks also go to
my sister's, brother's and sisters-in-law's families. My special thanks go to my wife's aunt M.D.
Soo J. Kim for her constant encouragement and assistance to my family.
I would like to express my deepest gratitude to my beloved wife, Sunghye Park, and my daughter,
Julia Inhye Baik, for their support, patience, understanding, and endless love throughout my
graduate studies in Blacksburg.

iii

Contents

Chapter 1. Introduction
1.1 Motivation and Purpose................................................................................................1
1.2 Problem Description.....................................................................................................2
1.3. Organization of this Document ......................................................................................5

Chapter 2. Literature Review

2.1 Literature Review on Aircraft Sequencing Problems (ASP).............................................9
2.1.1Previous Studies on ASP.......................................................................................9
2.1.2Dynamic Programming Approach........................................................................12
2.1.3Reformulation-Linearization Technique (RLT).....................................................14
2.1.4Heuristic Approaches for the Traveling Salesman Problem (TSP)..........................16
2.2 Literature Review on Network Assignment Problem (NAP)..........................................42
2.2.1Literature Review on Network Assignment Algorithms .........................................43
2.2.2Shortest Path (SP) Algorithms .............................................................................50
2.3 Literature Review on Simulation Model......................................................................64
2.3.1Types of Simulation Models ................................................................................64
2.3.2Previous Air Traffic Simulation Models ...............................................................65
2.3.3Aircraft-Following Models ..................................................................................67
2.3.4Data Structures for Network Representation .........................................................68

Chapter 3. Model Development for ASP

3.1 Assumptions for Ready-times .....................................................................................72
3.2 First-come-first-serve (FCFS) Approaches...................................................................74
3.3 Integer Programming Approaches ...............................................................................78
3.3.1Formulation .......................................................................................................78
3.3.2Valid Inequalities ...............................................................................................79
3.3.3Enhanced Model Representation via an Application of RLT..................................81
iv

3.3.4Modifying the Formulation .................................................................................89

3.3.5Computatio nal Results ...................................................................................... 108
3.4 Heuristics for the Aircraft Sequencing Problem (ASP)................................................ 113
3.4.1Tour Building Process....................................................................................... 113
3.4.2Improvement Heuristic ..................................................................................... 117
3.4.3Computational Results ...................................................................................... 122

Chapter 4. Network Assignment Problem

4.1 Network Assignment Strategies ................................................................................ 124
4.1.1Network Assignment Algorithm ........................................................................ 124
4.1.2Shortest Path Algorithms................................................................................... 127
4.2 Computational Results.............................................................................................. 128

Chapter 5. Virginia Tech Airport Simulation Model

5.1 Framework of the Proposed Simulation Model........................................................... 131
5.2 Object-oriented Analysis (OOA) of the Simulation Model.......................................... 134
5.2.1Object Model ................................................................................................... 134
5.2.2Dynamic Model................................................................................................ 135
5.2.3Functional Model............................................................................................. 145
5.3 Object-oriented Design (OOD) of Simulation Model.................................................. 148
5.3.1System Design.................................................................................................. 148
5.3.2Object Design................................................................................................... 148
5.4 Object-oriented Programming (OOP)........................................................................ 197
5.5 Primary Validation of the Simulation Model.............................................................. 198

Chapter 6. Case Study

6.1 Definition of Delays ................................................................................................. 206
6.2 Sample Airport ........................................................................................................ 207
6.3 Scenarios ................................................................................................................. 210
6.4 Computational Process............................................................................................. 211
v

6.4.1Data Generation ............................................................................................... 211

6.4.2Sequencing....................................................................................................... 211
6.4.3Simulation........................................................................................................ 214
6.5 Computational Results............................................................................................. 220
6.5.1Total Taxiing Time as Related to Various Network Assignment Strategies........... 220
6.5.2Average Runway Delay for Analysis of Aircraft Sequencing Strategies............... 221
6.5.3Total Operation Time ........................................................................................ 224

Chapter 7. Summary, Conclusions and Future Research

7.1 Summary and Conclusions ........................................................................................ 226
7.2 Recommendations for Future Research...................................................................... 228

Bibliography ............................................................................................................. 231

Appendix..................................................................................................................... 243
Vita

........................................................................................................................ 270

vi

List of Figures

Figure 1.1 Configuration of Airport Terminal Area ............................................................3

Figure 1.2 Problem Structure and Data Flow for the ASP and NAP Problem Framework. .....7
Figure 1.3 Data Flow in the ASP/NAP Framework for Sample Problem. .............................8
Figure 2.1 Example of 2-exchange. .................................................................................20
Figure 2.2 Example of 3-exchange. .................................................................................20
Figure 2.3 Example of an Or-exchange (s = 2). ................................................................21
Figure 2.4 A local exchange [Psaraftis, 1983a].................................................................24
Figure 2.5 An example of 2-exchange..............................................................................26
Figure 2.6 Two-addition procedures in a savings heuristic. ...............................................29
Figure 2.7 Lexicographic search strategies.......................................................................35
Figure 2.8 Definition of primary changes.........................................................................37
Figure 2.9 Construction of primary changes.....................................................................38
Figure 2.10 Algorithmic Framework for Time-Dependent System Optimal Assignment
Problem [Peeta and Mahamassani, 1995]. ........................................................49
Figure 2.11 Bellman's Principle of Optimality. ...................................................................52
Figure 2.12 Time-dependent SP Algorithm [Cook and Halsey, 1985]. .................................55
Figure 2.13 Time-dependent SP Algorithm [Dreyfus, 1969]................................................55
Figure 2.14 Example of TDSP (1).....................................................................................56
Figure 2.15 Example of TDSP (2).....................................................................................56
Figure 2.16 Total Link Travel Time for the UW Problem....................................................58
Figure 2.17 Types of Queues for Node Selection Schemes [reproduced from Tarjan, 1983]. .60
Figure 2.18 Pseudo Code for a Time-dependent SP Algorithm............................................62
Figure 2.19 An Example Graph with 5 Nodes and 9 Arcs (i.e., n=5, m=9)............................69
Figure 2.20 Node-Arc Incident Matrix for the Example Network. .......................................69
Figure 2.21 Node-Node Adjacency Matrix for the Example Network. .................................70
Figure 2.22 Adjacency List Representations for the Example Network. ...............................70
Figure 2.23 Forward Star Representation for the Example Network.....................................71
Figure 3.1 Time Relationships for the Departing Aircraft..................................................73
Figure 3.2 Checking Minimum Separation Constraints. ....................................................89
Figure 3.3 Triangular Inequality. .....................................................................................91
Figure 3.4 Relationships among the Constraint Sets........................................................ 104

vii

Figure 3.5

Prefixing Variables....................................................................................... 107

Figure 3.6 Illustrative Example. .................................................................................... 110

Figure 3.7 LP-based tour building procedure for ASP..................................................... 116
Figure 3.8 Pseudo-code for the ASP heuristic................................................................. 118
Figure 3.9 Flowchart of Improvement Procedure for ASP. .............................................. 121
Figure 4.1 Quasi-dynamic Assignment Algorithm (1). .................................................... 126
Figure 4.2 Quasi-dynamic Assignment Algorithm (2). .................................................... 126
Figure 4.3 Pseudo Code for Suggested Time-dependent SP Algorithm. ............................ 128
Figure 4.4 Static vs. Time-dependent Path (1)................................................................ 129
Figure 4.5 Static vs. Time-dependent Path (2)................................................................ 130
Figure 5.1 Processes of OMT [reproduced from Weijers et. al, (1995) and Derr (1995)]. .. 133
Figure 5.2 Object Diagram............................................................................................ 136
Figure 5.3 State Diagram for an Arriving Flight. ............................................................ 138
Figure 5.4 State Diagram for Communication (Voice Channel). ...................................... 140
Figure 5.5 State Diagram for Communication (Data Link). ............................................ 140
Figure 5.6 State Diagram for a Departing Flight. ............................................................ 142
Figure 5.7 Flight Progress Strip. .................................................................................... 143
Figure 5.8 State Diagram for a Controller. ..................................................................... 144
Figure 5.9 Communication Process Initiated by the Controllers....................................... 145
Figure 5.10 Input and Output Values for the Simulation Model. ........................................ 146
Figure 5.11 Top-Level of Data Flow Diagram (DFD) for VTASM. ................................... 147
Figure 5.12 Speed-Acceleration Relationship. .................................................................. 151
Figure 5.13 Comparison of Aircraft-following Models. .................................................... 154
Figure 5.14 Flowchart of Aircraft Following Module........................................................ 155
Figure 5.15 Cases of Potential Ground Conflicts. ............................................................. 156
Figure 5.16 Concept of Conflict Detection. ...................................................................... 157
Figure 5.17 Calculation of the Lower-priority Flights Deceleration Rate........................... 159
Figure 5.18 Flowchart for the Conflict Detection and Resolution Module .......................... 161
Figure 5.19 Takeoff Procedure........................................................................................ 162
Figure 5.20 Steps for the Takeoff Roll Analysis. .............................................................. 163
Figure 5.21 Non-Uniform Acceleration Model [Drew, 1968]. ........................................... 171
Figure 5.22 Four Phases in the Landing Procedure. .......................................................... 174
Figure 5.23 Speed-Distance Relationship for the Landing Procedure................................. 174
Figure 5.24 Array-based List for Node Data..................................................................... 182

viii

Figure 5.25 Array-based List for Aircraft Model Data. ..................................................... 182
Figure 5.26 Singly-Linked List for Edge Data.................................................................. 182
Figure 5.27 Singly-Linked List for Taxiing Path Data....................................................... 183
Figure 5.28 Sample Network and Array of Singly-Linked List for the Sample Network..... 183
Figure 5.29 Flowchart for the Overall Simulation Model Process...................................... 187
Figure 5.30 Flowchart for the Initialization Step............................................................... 188
Figure 5.31 Flowchart for Performing Communication Checks. ........................................ 189
Figure 5.32 Flowchart for the Communication Logic........................................................ 190
Figure 5.33 Flowchart for the Communication Module from the Flights Point of View...... 191
Figure 5.34 Flowchart for the Communication Logic from the Controllers Point of View. . 192
Figure 5.35 Flowchart for the Movement Logic. .............................................................. 193
Figure 5.36 Flowchart for the Computation of the Next Acceleration for Taxiing. .............. 194
Figure 5.37 Flowchart for Updating Flights Dynamic States............................................ 195
Figure 5.38 Preliminary Results (1): Sample Output. ........................................................ 200
Figure 5.39 Validation of the Simulation Model (Time-Space Diagram for Departures, B727100). ........................................................................................................... 201
Figure 5.40 Validation of the Simulation Model (Takeoff Profile, B727-100). ................... 202
Figure 5.41 Validation of the Simulation Model (Time-Space diagram For Arrivals, B727100). ........................................................................................................... 203
Figure 5.42 Validation of the Simulation Model (Touchdown Profile, B727-100)............... 204
Figure 5.43 Validation of Simulation Model (Headway-Speed Profile, B727-100). ............ 205
Figure 6.1 Delays Associated with a Departing Flight..................................................... 208
Figure 6.2 Delays Associated with an Arriving Flight. .................................................... 208
Figure 6.3 Configuration of the Washington National Airport (DCA). ............................. 209
Figure 6.4 Flowchart of the Computational Process Employed in the Case Study. ............ 213
Figure 6.5 Sample of Schedule Data. ............................................................................. 215
Figure 6.6 A Sample of the Log.out File. ....................................................................... 217
Figure 6.7 A Sample of the flightState.out File. .............................................................. 218
Figure 6.8 A Sample of TaxiPath.out File. ..................................................................... 219
Figure 6.9 Average Runway Delay by Sequencing Methods (Communication: Voice
Channel)...................................................................................................... 223
Figure 6.10 Average Runway Delay by Sequencing Methods (Communication: Data Link).
................................................................................................................... 223
Figure 6.11 Total System Costs by Sequencing Methods (from the Simulation Run). ......... 225

ix

Figure 6.12 Total System Costs by Sequencing Methods (from the Simulation Run). ......... 225
Figure 7.1 Definition of Problem and Data Horizons. ..................................................... 229
Figure 7.2 Problem Structure and Data-Flow for the ASP and NAP Model Framework
(Multi-Data Horizon).................................................................................... 230

List of Tables
Table 2.1

Definitions of Various Types of TSP Problems. ...............................................17

Table 2.2

Computation of Waiting Time on a Concatenated Path. ....................................34

Table 2.3

Various Definitions of SP Problems. ...............................................................51

Table 2.4

Comparison of LS and LC Algorithm (1).........................................................53

Table 2.5

Comparison of LS and LC Algorithm (2).........................................................54

Table 2.6

Three Types of Time-dependent SP Algorithms. ..............................................57

Table 2.7

Operations for Various Queue Types. ..............................................................60

Table 2.8

Comparison of Data Structures for LC Algorithms. ..........................................63

Table 2.9

Macroscopic Models from Vehicle -following Models (Gerlough and Huber,

1975).............................................................................................................68

Table 3.1

Minimum Separation (seconds).......................................................................74

Table 3.2

Runway Occupancy Times (seconds)...............................................................75

Table 3.3

Aircraft Schedule (Randomly Generated)........................................................75

Table 3.4

First-come-first-serve Sequence for Landing Aircraft. ......................................76

Table 3.5

First-come-first-serve 1) Sequence (with Landing Priority). ................................77

Table 3.6

Original and SSRLT Constraint Sets.............................................................. 101

Table 3.7

Computational Results (without using Prefixing Constraints). ......................... 111

Table 3.8

Computational Results (using Prefixing Constraints). ..................................... 112

Table 3.9

An Example of Heuristic Method for ASP. .................................................... 115

Table 3.10 Computational Results (2-exchange improvement procedure). ........................ 122

Table 3.11 Comparison of Computational Efforts. .......................................................... 123
Table 3.12 Computational Results (2-swap improvement procedure, n=10). .................... 123
Table 4.1

Hypothetical Flight Schedule. ....................................................................... 128

Table 5.1

Equations for the Non-Uniform Acceleration Model. ...................................... 153

Table 5.2

Conversion Factors and Properties of International Standard Atmosphere. ....... 165

Table 5.3

Equations describing the Aircraft Landing Phases. ......................................... 178

Table 5.4

Landing-roll Statistics [Kim et al., 1996]. ...................................................... 180

Table 5.5

Comparison of List Implementations. ............................................................ 181

Table 5.6

Summary of Data Structures Used in the Simulation Model. ........................... 184

Table 5.7

The Initial States of the Simulation Model Variables. ..................................... 185

Table 5.8

Hypothetical Flight Schedule. ....................................................................... 199

Table 6.1

Scenarios for Case Study. ............................................................................. 210

Table 6.2

A Sample Output from the Sequencing Model................................................ 212

xi

Table 6.3

Constant Values used in the VTASM Simulation Model. ................................ 214

Table 6.4

Total Taxiing Times. .................................................................................... 220

Table 6.5

Average Runway Delays resulting from the Simulation. ................................. 221

Table 6.6

Average Runway Delays resulting from Sequencing Step. .............................. 222

Table 6.7

Total Operation Time 1). ................................................................................ 224

xii

Chapter 1. Introduction
1.1 Motivation and Purpose
According to Federal Aviation Administration (FAA) statistics, there were 27 airports in U.S.
having more than 20,000 hours of total annual delay in 1997. These delays represent a cost
exceeding 2.4 billion dollars. By the year 2003, the number of airports having annual delays
exceeding 20,000 hours could be 31, unless capacity improvements are made [FAA, 1998].
Efforts to augment current capacity by building new airports, or expanding existing ones- are
expensive, time consuming, and environmentally controversial. On the other hand, proposals to
change the demand for the Air Traffic Control (ATC) operations by, for example, imposing
higher landing fees can lead to legal proceedings. Hence there is great interest in using existing
capacity more efficiently by improving air traffic control procedures.
The critical bottleneck in an ATC system is the capacity inside a radius of about 50 nautical miles
(nm) around an airport (i.e., airport terminal area). There are three types of air traffic control
activities in this terminal area: aircraft sequencing operations which control the traffic inside the
airport terminal area, runway operations which control aircraft landings and departures, and
taxiway operations which guide aircraft from the gate to the runway for departures or vice versa
for arrivals. For these activities, three types of air traffic controllers are involved: Final approach
controllers who are responsible for the aircraft sequencing operations, local controllers who are
responsible for runway operations, and ground controllers who are responsible for taxiway
operations.
To achieve more efficient operations, it is desirable that those three operational components be
coordinated as one task, rather than be considered as three separate ones. The purpose of this
research project is to design an efficient method to model aircraft operations around the airport
terminal area using an open system architecture. It is believed that this operational scheme could
help alleviate the congestion around the airport terminal area, that is frequently observed at major
airports in the United States and abroad. The underlying philosophy of this research project is
reflected by Dears remark [Dear, 1976]:
By utilizing todays computer power and instrument sophistication, the controller
workload can be reduced and system performance improved through the use of computerassisted decision-making, without affecting the controllers autonomy.

1.2 Problem Description

This dissertation focuses on the operation of aircraft inside the airport terminal area (or airfield)
which is a 3-dimensional air space usually having 50 nautical miles of radius around airport
runways. Once an arriving aircraft passes an entry point of airport terminal area, it approaches
towards a runway. For the convenience of air traffic control, all arriving aircraft are required to
pass the final approach fix (FAF) just before it touch down. The airspace between the FAF and
runway is called final approach path (FAP) or final. In the FAP, aircraft are controlled to be
spaced in certain amount of distance based on the minimum separation rules enforced by FAA.
The minimum separation between arriving aircraft depends on the aircraft types involved. This
separation rule is designed to minimize the leading aircraft's vortex effect to the following
aircraft. Generally speaking, the separation is bigger when an aircraft follows a larger one than
when it follows a smaller one. Once the arriving aircraft touchdowns and exits from the runway,
it start to taxi to the gate.
On the ground, aircraft parking at gates load and unload either passengers or freight. After
completing the loading and unloading processes, the aircraft begins to taxi to the runway along
the designated taxiing path. Once the aircraft arrives at the end of runway, it starts to roll for
takeoff. Figure 1.1 illustrates the configuration of airport terminal area.
Fundamentally speaking, the delays in any transportation facility occur when the demand for
services exceeds its capacity. This basic rule can be applied to facilities around the airport
terminal area, such as runways, taxiways and gates. For example, when there are more aircraft
moving on a taxiway network than its capacity, some of taxiing aircraft would experience certain
amounts of delay due to network congestion.
In this dissertation, we consider an airport terminal area as a combination of various resources
having limited capacities. In our analysis, runway, taxiway and communication channels are
considered and accordingly this research focuses mainly on the analysis of air traffic operations
on the airfield facilitie s. (Aspects related to the gate facilities are not included in research, but
could be the subject of future studies.)
In short, this dissertation deals with the following three sub-problems: the Aircraft Sequencing
Problem (ASP) to model runway operations, the Network Assignment Problem (NAP) to model
taxiway operations, and the Simulation Model (SM) for addressing communication activities.

Terminal Building

Taxiway

Runway

Final Approach Fix

Entry Points
Boundary of Airport Terminal Area

Figure 1.1

Configuration of Airport Terminal Area

The Aircraft Sequencing Problem (ASP) handles the runway operations and is developed under
the guiding principle that if the arrivals and departures are sequenced intelligently, then an
enhanced system efficiency will accrue. The ASP problem considers minimum separation rules
enforced by FAA to protect consecutive aircraft from the dangers of wake-vortex effects.
To illustrate this point, note that during the final approach, air traffic controllers try to maintain a
minimum of 5 nm when a heavy aircraft leads a small one. This distance is equivalent to about
196 seconds in time. If this sequence is switched so that the small aircraft leads the heavy one, the
required distance between the two aircraft reduces to 3 nm, or about 75 seconds. Thus a saving of
more than 100 seconds could occur by switching the sequence, assuming that this process is
feasible to the individual aircraft time-window restrictions, and does not appreciably affect
delays.
Previous studies conducted on this topic have mainly focused on the sequencing problem for
arriving aircraft. Since many airports in the U.S. have dependent arrival and departure stream
operations, consideration is given here to both these operations simultaneously. This makes the
3

problem more realistic, yet at the same time, more challenging. In order to manage aircraft traffic
in congested airport terminal areas, an aircraft sequencing procedure can be used in conjunction
with advanced Air Traffic Control (ATC) automation tools. Problem ASP can be stated more
succinctly as follows:
Given a set of aircraft data involving both arrivals and departures, including aircraft type,
original (nominal or desired) schedule, a maximum delay time to be absorbed by each
aircraft, minimum separation rules among aircraft, and the runway occupancy time (ROT)
for each aircraft type.
Find an optimal sequence of aircraft which minimizes the total operation time/cost to finish all
operations while satisfying both the minimum separation rule and the maximum delay
constraints.
Given the time recommendations prescribed by ASP, which include the exit times from the
runway and the takeoff times at the runway, the next step is to solve Network Assignment
Problem (NAP) to decide the taxiing route for all aircraft so as to minimize the congestion on the
taxiway network. The NAP which deals with taxiing operations is defined as follows.
Given a network configuration (a directed graph G(N,A)) of runways and taxiways, including a
set of origin nodes, O; and a set of destination nodes, D; and time-dependent taxiing
demands from each origin to each destination for a certain period. Also, given are
prescribed landing and takeoff times at the runway for the aircraft, as obtained from model
ASP.
Find a set of optimal routes for the departing aircraft to lead them from the gate to the departure
queue, and for the arriving aircraft to lead them from the runway exit to the gate, in order to
minimize total travel or fuel costs.
In this analysis, we adopt the results of ASP as initial conditions for solving the NAP problem. In
regular airport operations, landing aircraft have higher priority over departing and taxiing aircraft.
This is because arrivals are both costly and safety-critical from a fuel consumption and
operational point of view. For the same reason, the runway operation has a priority over ground
taxiing. Hence, in the case where a conflict arises between an aircraft crossing a runway during
Taxiing and an aircraft departing or landing on the runway, the latter has a priority. Based on
view, we solve the ASP first and obtain the optimal runway operational sequence. We then solve

the NAP using the ASP optimal sequence. Figures 1.1 and 1.2 illustrate the relationship between
the ASP and NAP problems for a single data horizon, including the required data and information
flows.
At many busy airports, it is frequently observed that flights are delayed by communication
congestion (due to controller workload). For instance, even after a departing flight is ready to
taxi, the flight would be delayed at the gate until it obtains a taxiing clearance from the ground
controller. In previous analyses for ASP and NAP problems, no consideration has been given to
the communication process between controllers and pilots, although this is an important source of
delay. Indeed, there is a distinct possibility that due to the communication delays, the prescribed
ASP sequence and the suggested taxiing route obtained from NAP might not be achievable for
some flights.
In order to portray the pilot-controller communication process, a Simulation Model (SM) is
developed in this research. A continuous, microscopic simulation model provides very detailed
information about the dynamic status of all relevant entities, i.e., flights, local controllers, and
ground controllers. The dynamic status includes not only controllers' communication status but
also aircraft dynamic behaviors such as speed, acceleration, position, etc., at every time interval
of simulation. These microscopic features are embedded in the Virginia Tech Airport
Simulation Model (VTASM), and distinguish separate this model from existing air traffic
simulation models such as SIMMOD, TAMMS, etc., which employ disctere-event simulation
instead. VTASM includes airport facilities such as runways, taxiways, and gates. (Runway
thresholds play the role of a souce node for arriving flights and a sink node for departing flights.)
The main tasks in the development of VTASM can be described as follows:
Given a network configuration (a directed graph G(N,A)) of runways and taxiways, prescribed
landing and takeoff times at the runway for the aircraft, as obtained from model ASP, and a
set of optimal routes for both the departing and arriving aircraft from NAP.
Find, considering communication activities and aircraft dynamic movements, the aircraft status
such as speed, acceleration, position, etc., and delays on the network.

1.3. Organization of this Document

This dissertation is organized into six chapters. Chapter 2 is devoted to review previous studies
pertinent to ASP problem. The proposed ASP is a version of the asymmetric traveling salesman
5

problem with time-windows (ASP-TW), and is NP-complete in terms of computational

complexity. Because of this complexity, we develop two approaches for this problem,
respectively geared toward finding an exact solution and an approximate solution via a heuristic
method. In Chapter 3, the formulation of Problem ASP and the development of an effective
approach to solve this problem are presented along with some computational results for both the
exact and heuristic approach.
The NAP problem on the taxiway network is discussed in Chapter 4. We focus on proposing a
network assignment strategy which is appropriate for our case. Even though the taxiway network
is somewhat different from urban transportation networks, it is still helpful to review the state-ofart of both static and dynamic network assignment methods applied to urban transportation
planning processes. Various types of shortest path algorithms which play an important role in
NAP are also discussed along with their associated data structures. Two types of network
assignment strategies are considered in this research.
In Chapter 5, we present procedures relevant to the development of a continuous, microscopic
simulation model. The details of each component of the simulation model are provided in the
context of an Object-Oriented Design (OOD) and an Object-Oriented Programming (OOP)
approach. Computational results and a verification of the simulation model are also presented in
this chapter.
Chapter 6 provides results for a case study using hypothetical flight schedules at the Reagan
National Airport (DCA). A total of 12 scenarios are studied for several sequencing, network
assignment and pilot-controller communication methods. Each scenario is tested using 90 flight
schedule replications representing various demand levels.
Chapter 7 presents a summary of this research and conclueds with a discussuion on some possible
research extentions.

Nominal Schedule
for Arrivals

Separation
Rule

Nominal Schedule
for Departures

Aircraft Sequencing Problem

(ASP)

Optimal sequence and schedule

Time-dependent O-D
(between gates and runways)

Taxiing Network
Configuration

Network Assignment Problem

(NAP)

Simulation
(VTASM)

Optimal taxiing routes

for arrivals and departures

Figure 1.2

Problem Structure and Data Flow for the ASP and NAP Problem Framework (Single
Data Horizon).

<Original Schedule from data link>

Aircraft
Desired
Flight No.
type
touchdown Time
US322
B727
12:39
US321
B737
12:41
.
.
.

< Original schedule from flight-plan>

Aircraft
type
B747
B757
.

Flight No.
NW122
NW123
..

Desired
pushback Time
12:37
12:43
.
Ready-time to takeoff =
desired pushback time + taxiing time (T1 )
< Original Sequence>

max. delay =10 min.

Departures
Ready-time
Aircraft type
to takeoff
B747
12:47
B757
12:53
.
.

Flight no.
NW122
NW123
.

Due-time
to takeoff
12:57
13:03
.

Min. Separation Rule

Arrivals
Ready-time
Aircraft type
to touchdown
B727
12:39
B737
12:41
.
.

Flight No.
US322
US321
.

Due-time
to touchdown
12:49
12:51
.

Minimize the completion time

for all aircraft to be operated

ASP

<Optimal Sequence>
Flight No.
NW123
NW122
.

Departure
Opt. Time
Aircraft type
to takeoff
B757
12:53
B747
12:55
.
.

Arrival
Delay

Flight No.

Aircraft type

US321
US321
.

B737
B727
.

Opt. time
to touchdown
12:41
12:46
.

Delay

Recommended push-back time from the gate =

Optimal takeoff time Taxiing time Buffer time
Expected time to exit from the runway =
Optimal touchdown time + Runway Occ. Time (ROT)
<Time-dependent taxiing demand>
Flight No.

Aircraft type

NW123
NW122

B757
B747

Departures
Rec. time to
pushback
12:49
12:45

Origin
gate
Gate # 3
Gate # 5

Destination
runway
22R
22L

Flight No.

Aircraft type

US321
US321

B737
B727

Arrivals
Exp. time to exit
from runway
12:41
12:46

Origin runway
exit
Exit 2 on 22R
Exit 3 on 22L

Destination
gate
Gate # 9
Gate # 6

Assumption: Aircraft start taxiing at the recommended

pushback times/expected exit times

NAP
<Time-dependent taxiing demand>
Departures

Arrivals

Flight No.

Origin gate

Routes (links)

NW123
NW122

Gate # 3
Gate # 5

B12-> B23-> .->

C1-> B4-> .->

Destination
runway
22R
22L

Figure 1.3

US321
US321

Origin runwayexit
Exit 2 on 22R
Exit 3 on 22L

E1->E3-> .->
F5->E3-> .->

Destination
gate
Gate # 9
Gate # 6

Flight No.

Routes (links)

Data Flow in the ASP/NAP Framework for Sample Problem

(Single Data Horizon).

Chapter 2. Literature Reviews

2.1 Literature Review on Aircraft Sequencing Problems (ASP)
The Aircraft Sequencing Problem (ASP) is a combinatorial problem for which no efficient
algorithm (i.e., with computational time bounded by a polynomial in the size of the problem) is
known. When faced with such a computationally hard (formally classified as NP-hardsee Garey
and Johnson, 1979) problems, two approaches are possible:

1) Branch-and-bound methods applied with efficient procedures to evaluate lower/upper bound

at every nodes, which reduce the effort from that of exhaustive enumeration. These methods
are certain to produce an optimal solution, but in the worst-case scenario, they may require an
exponential number of calculations.
2) Heuristic methods which provide an approximate solution in fast (polynomial) time. These
methods may not produce an optimal solution, but generate sub-optimal solutions that are
close to an optimum for most cases.
In this review, we survey 1) the previous studies on Aircraft Sequencing Models (ASP), 2) a
dynamic programming method along with branch-and-bound scheme, and 3) various types of
heuristic methods for solving traveling salesman problems (TSP).

2.1.1

Previous Studies on ASP

The most straightforward sequencing strategy for arrivals is to assign the flights on a first-comefist-serve (FCFS) basis, which is largely applied in air traffic control these days. In this method,
the aircraft are scheduled in the order of preferred landing/departure times (or sometimes termed
nominal landing/departure times). The second sequencing method is the so-called time advance
(TA) technique which is used to minimize the average delay (or maximize throughput) without
changing the order of the aircraft. In this method, the runway utilization is improved by speeding
up aircraft during periods of heavy traffic so as to reduce the gaps that occur otherwise [Neuman
and Erzberger, 1990]. The FCFS sequencing procedure is most effective in the sense of
implementation, but it is subject to the randomness of the arrival process, and consequently, may
create undesirable delays which can be reduced by an optimized sequence.
9

ASP problems are combinatorial problems where n aircraft have to be sequenced optimally. To
enumerate all possible cases involves evaluating n! solutions. Since the computations for a total
enumeration increases drastically as n increases, we need to consider more constructive
enumeration methods. Due to the nature of the problem, previous research efforts have focused
on methods to reduce the computational complexity without losing the capability to obtain an
optimal solution.
Attempts to optimize ASP-type problems date back to the late 60s. A first investigation of the
ASP problem is made by Dear (1976). The main scope of his study is to determine the landing
order of arriving aircraft considering all the aircraft currently in the system. As this number can
be large (20 or even more simultaneous aircraft), Dear realizes the difficulty in attaining an
optimal solution in real-time. To solve this problem, a Constrained Position Shifting (CPS)
strategy is used instead of a FCFS strategy. That is, no aircraft may be sequenced forward or
backward more than a pre-specified number of positions (Maximum Position Shifting) from its
FCFS position. The method examines a window of (2 the maximum position shift 1)
positions, optimizes it (exhaustively) for a single position shift, moves the window down one
position, and repeats the process.
Considering Dears CPS management concept, Psaraftis (1980) develops a dynamic
programming approach for sequencing a given set of jobs on a single machine to minimize the
total processing cost. In this paper, Psaraftis assumes that there are n distinct groups of jobs,
where the jobs within each group are identical. Taking advantage of this grouping assumption, he
suggests a more practical algorithm which can save some computational effort as compared to the
classical dynamic programming approach for the job sequencing problem. He illustrates this
method by optimally sequencing aircraft arrivals at an airport.
Using an integer programming approach, Bianco et al. (1987, 1997) determine an optimal
sequence for arriving aircraft inside the Terminal Management Area (TMA). The authors point
out the static nature of Psaraftis study where all aircraft are supposed to wait to land at a given
time. Based on this concept, this paper presents a formulation which takes into account the
dynamic nature of the problem in which every aircraft entering the TMA has a Nominal Landing
Time (NLT) depending on the characteristics of the TMA, the aircraft speed, and so on. The
formulation developed by Bianco et al. (1987) is as follows.

Minimize s +

p x

ij ij

iJ 0 jJ 0

subject to

10

ti +

p x p

x s 0

i J0

(1)

ri ti 0

i J0

(2)

( p ij + Tij ) xij + ti t j Tij 0

i J 0 , j J, j i

(3)

=1

i J0

(4)

=1

j J0

(5)

ij ij

jJ 0

ij

kj kj

k J 0 jJ 0

j J 0

ij

i J0

s0

(6)

t0 = 0

(7)

xij {0 ,1} i J 0 , j J 0 , j i

(8)

ti 0, i J 0

where,
J = {1,...,n} : a set of n jobs to be processed on a single runway
ri : ready-time for job i
p ij : processing time of job i if job j is the successor of i in sequence,
i, jJ0 , J0 =J{0}
p 0i : setup time of the machine when the sequence starts with job i
xij = 1 if job i directly precedes job j, and otherwise 0
ti = start time of job i
s = machine idle time
Tij = sufficiently large value to make constraints (4) redundant whenever xij =0.
This problem is NP-Hard and in the case of zero ready-times it reduces to the Asymmetric
Traveling Salesman Problem (ATSP). Here, Constraint (3) secures the minimum separation
between two consecutive flights and also prevents subtours. The authors suggest a branching
strategy based on the characteristics of the subsequences obtained in the solution process, and a
Lagrangean lower bounding strategy. Heuristic upper bounds are also computed. Using their
branch-and-bound approach, they find an exact optimal solution for the problems having up to 44
aircraft in 1,956 seconds, and show that an optimal solution could save up to 20 % on the runway
utilization. Perhaps the major weaknesses in this formulation is the lack of due-time constraints
for each flight, resulting in potentially unacceptable air delays, and the neglecting of nonconsecutive separation restrictions.

11

One thing which should be noted here is that previous studies have mainly focused on the arrival
operations. In Dears study, an extension to mixed operations (i.e., departures and arrivals) is
given, with one critical assumption. For simplicity of computation, Dear assumes a slightly
relaxed separation in order not to create difficulties when the resulting sequence has two different
types of consecutive operations, which may otherwise violate the separation rules. (More details
of this issue will be discussed later.)

2.1.2

Dynamic Programming Approach

Sequencing and scheduling problems arise in a wide range of economic activities. The field of
sequencing and scheduling theory has originated from the endeavor to solve mainly job-machine
problems which involve accomplishing a number of tasks (jobs) that need to be processed by
various resources (machines) according to certain specified rules over a period of time. If we
view aircraft operations as jobs and a runway as a machine, we can apply job scheduling theory to
our problem, which is to minimize the total delay time or completion time of all aircraft. In this
problem, each aircraft has a ready-time, namely, the preferred time to land or depart.
Among the first analytical methods applied to solve sequencing problems was Dynamic
Programming, which originated from the work of Richard Bellman in the fifties. Held and Karp
(1962) applied Dynamic Programming to solve sequencing problems. Their approach is based on
Bellmans Principle of Optimality. Roughly, this says that in an optimal sequence, the first k
aircraft (for any k = 1,..., n) must form an optimal sequence for the reduced problem based on
these k aircraft alone. Dynamic Programming solves the problem in stages via a sequence of
recursive computations in a manner that yields an optimal solution to the entire problem which is
represented by the final stage.
To apply dynamic programming, we can divide our ASP into two sub-problems. First, for a single
aircraft problem, it is necessary to consider simply the preferred landing/departing time
(PLT/PDT) and the runway occupancy time. Second, for more than one aircraft, we need to
consider a recursive equation. If we have n aircraft to be sequenced, {j 1 , j 2 , , j k , j n }, the
equations for Dynamic Programming to minimize the completion time are as follows:
Let
J
: the subset of n aircraft
j(J) : last aircraft in sequence of subset J
j*(J) : optimal last aircraft in sequence of subset J
j** : optimal second-to-last aircraft in subset J, given that aircraft j is last
12

( = j*(J-{j}) )
ROTi : the runway occupancy time of aircraft i
p ij : minimum separation time between aircraft i and j when aircraft j immediately follows i
C(J, j) : optimal completion time for subset J, given that the last aircraft is j
C(J) : optimal completion time for subset J
f j (Cj ) : cost such as delay time for aircraft j, given its completion time (Cj )
G(J) : optimal cost such as total delay time for subset J.
If J contains a single aircraft, i.e. J = { j k }
C(J, j) = G(j k)
= PLT (or PDT) + ROTk,
G(J) = C(J, j k)
= G(j k),
j(J) = j k,
j*(J) = j k.
else if J contains more than one aircraft (recursive equations)
C(J, j) = C(J-{j}) + p j**j + ROTj ,
G(J) = min j in J [G(J-{j}) + f j (C(J, j))]
= [G(J-{j*}) + f j* (C(J, j*))],
C(J) = C(J, j*(J)).
The branch-and-bound approach is a preferred solution technique over Dynamic Programming.
As its name implies, the method consists of two fundamental features: 1) branching: this is the
process of partitioning a large problem into two or more subproblems, and 2) bounding: this is the
process of calculating a lower bound on the optimal solution value of a given subproblem.
As an example of a branching procedure, let P denote our ASP containing n jobs. The problem P
can be solved by solving n related subproblems, P1 , P2 ,, Pn (subproblem Pj means job j has
been constrained to come first, but all other aircraft are open for future assignments). The set of
subproblems Pj is a mutually exclusive and exhaustive partition of P in the sense that if each Pj is
solved, the best of these n solutions will represent an optimal solution to P.
Next, each of the subproblems can be partitioned, for instance, P1 can be partitioned into P12 , P13 ,
, P1n . (In P12 , jobs 1 and 2 occupy the first two positions in the sequence). Therefore the
second-level partition P1j bears the same relation to P1 as the first-level partition Pj bears to P. At
level k, each subproblem contains k fixed positions and can be further partitioned into (n-k)
subproblems. If this branching were to be carried out completely, there would be n! subproblems
at level n. Clearly, evaluating all n! cases is not practical, and so, a fathoming or curtailing of this
enumeration tree needs to be devised.

13

Suppose that at some intermediate stage, a complete solution has been obtained that has an
associated performance measure (called incumbent solution) Z. Also, suppose that a subproblem
encountered in the branching process has an associated lower bound lb > Z. Then that subproblem
need not be considered any further. To find a lower bound at a certain node A at level k (i.e., for
the subproblem P12...k), we can use the following equation:
lb(A) = ROT1 + P12 + + P(k-1)k + (n-k)Pmin (A)
where,
ROT1 : the runway occupancy time of aircraft 1 if this is the first in the processing
sequence
Pij : the processing time (minimum separation) of aircraft j if it immediately follows
aircraft i
Pmin (A) = min (i,j ){(1,2),,(k-1,k)}{Pij }.
Generally, the efficiency of the Branch-and-Bound method is strongly dependent on the trial
solution and the tightness of the lower bound computed at each node. Unfortunately using Pmin (A)
makes it difficult to obtain a sharp lower bound at earlier nodes in the tree, implying that the
method might require considerable computational time.
The Dynamic Programming method reduces the number of computations required to find an
optimal sequence when compared to exhaustive enumeration. It is also true that the larger the
problem, the more dramatic is the gain in speed. However, because Dynamic Programming must
keep all the information at each and every stage and none of this information is redundant until
the final identification of an optimal sequence, the storage requirements grow rapidly with the
number of jobs. Considering the real-time requirements of our ASP problem, we need to devise
more efficient solution methods. For this reason, this research suggests an Integer Programming
approach as well as a heuristic approach to solve the aircraft scheduling and sequencing problem.

2.1.3

Reformulation-Linearization Technique (RLT)

RLT was developed by Sherali and Adams (1989, 1990, 1994), and is an automatic reformulation
technique that can be used to derive tight LP representations as well as strong valid inequalities
[Sherali and Adams, 1999]. Consider a mixed-integer zero-one programming problem whose
feasible region X is defined as follow:
X = {( x,y) R n R m : Ax + Dy b, 0 x en , x binary, y 0} ,
where en is a vector of ones in Rn .

14

Here, x = (x1 ,, xn ) is a set of binary variables and y = (y1 ,, ym ) is a set of continuous variables.
RLT consists of essentially two steps: 1) a reformulation step in which additional non-linear valid
inequalities are automatically generated, and 2) a linearization step in which each product term is
replaced by a single continuous variable.
In the reformulation step, given d {1,...,n} , the RLT procedure constructs so-called boundfactors (Fd ) of degree d comprised of the product of some d binary variables or their
complements. These factors are then used to multiply each of the constraints defining X
(including the variable bounding restrictions) to create a nonlinear polynomial mixed-integer
zero-one programming problem. The bound-factors are defined as follow:

Fd ( J1 ,J2 ) =
xj
(1 x j ) ,
j J j J

J1 ,J2 N {1,..., n}, J1 J2 = , J1 J 2 = d .

2
In the linearization step, using the relationship x j = x j for each binary variable xj , j = 1,,n,

substituting a variable wJ and vJk, respectively, in the place of each nonlinear term of the type

J N and yk

jJ

J N, k , and relaxing integrality, the nonlinear polynomial

jJ

problem is re-linearized into a higher dimensional polynomial set Xd defined in terms of the
original variables (x, y) and the new variables (w, v). Sherali and Adams show that the projection
of Xd onto the space of the original variables (x, y), XPd , yields the hierarchy of relaxations.
X P 0 X 0 X P 1 X P 2 ....... X Pn = conv(X)

where, X P 0 X 0 (for d=0) is the ordinary LP relaxation, and

conv(X) is the convex hull of X.
The hierarchy of higher-dimensional representations produced in this manner markedly
strengthen the usual relaxations, as is evidenced by the fact that the convex hull representation is
obtained at the highest level. In fact, in computational studies on many classes of problems, even
the first-level representation helps design algorithms that significantly dominate existing
procedures.
Applications of RLT to specific problems include zero-one quadratic problems; zero-one
quadratic assignment problems (Adams and Sherali, 1986); continuous and discrete bilinear
15

programming problems (Adams and Sherali, 1993, Sherali and Alameddine, 1992); continuous
and

discrete

location-allocation

problems

(Sherali

and

Tuncbilek,

1995);

polynomial

programming problems (Sherali and Tuncbilek, 1995, 1997a, 1997b); factorable nonlinear
problems (Sherali and Wang, 1999): 0-1 mixed integer problems with application to some
specially structured problems (Sherali, et al., 1998): Miller-Tucker-Zemlin formulations for
asymmetric traveling salesman problems (Sherali and Driscoll, 1999), among many others.

2.1.4

Heuristic Approaches for the Traveling Salesman Problem (TSP)

The ASP problem can be seen as a variation of Traveling Salesman Problem (TSP) for which no
efficient algorithm (i.e., with computational time bounded by a polynomial in the size of the
problem) is known. In this section, we present several heuristic methods to solve the TSP. Over
past two decades, there have been several heuristic techniques developed that bear importance to
our original problem.

2.1.4.1

Definitions of Various Types of Traveling Salesman Problems

Depending on the characteristics of the edge weight, wij (or tij ), and time constraints on customer
service times, traveling salesman problems are classified as Symmetric (henceforth abbreviated
TSP), Asymmetric (ATSP), Symmetric with time-windows (TSP-TW), and Asymmetric with
time-windows (ATSP-TW) traveling salesman problem. The definitions of various types of TSP
problems are summarized in Table 2.1

2.1.4.2

Heuristic Approaches for the Traveling Salesman Problem (TSP)

Heuristic methods for TSP can be conveniently divided into two procedures: 1) tour construction
procedures which construct a initial feasible solution, and 2) Tour improvement procedures
which try to improve a given initial solution in a systematical way [Lawler, 1985].

2.1.4.2.1 Tour Construction Procedures for TSP

Reinelt (1994) classifies various types of construction heuristics suggested for TSP into four
groups: nearest neighbor heuristics, insertion heuristics, heuristics using spanning trees, and

16

saving heuristics. Among the construction heuristics, the insertion method is known as one of the
most efficient approximate algorithms for the initial tour construction [Syslo, 1983]. In general,

Table 2.1

Definitions of Various Types of TSP Problems.

Problem
TSP

Definition

1)

Given a complete weighted digraph G=(V, E) and symmetric weights wij (or
tij ) for all directed edges (i, j) V V in E.
Find a minimal Hamiltonian tour (or circuit) of G, i.e., a cycle which visits
each vertex exactly once, having minimum total weight.
(Most TSPs assume that a given vertex, say vertex 0, will serve as the first
and last vertex of any route and that the weight matrix (wij ) satisfies the
triangle inequality.)

ATSP

2)

Same as TSP except that G=(V, E) is defined having asymmetric weights wij
and wji for the directed edges (i, j) and (j, i) respectively. (i.e., wij is not
necessarily equal to wji .)

TSP -T W 3)

Given a complete weighted digraph G=(V, E) with symmetric weights wij for
all directed edges (i, j) V V in E, and a time-window on the departure
time for each vertex i denoted by [ei , li ] where ei specifies the earliest service
time and li the latest service time.
Find a minimal Hamiltonian tour of G satisfying the time-window
restrictions.

ATSP -T W

2)

Same as TSP-TW except that G=(V, E) has asymmetric weights wij and wji
for the directed edges (i, j) and (j, i) respectively.

1) Kanellakis (1980), Savelsberg (1990)

2) Acheuer (1999)
3) Savelsberg (1992)

an insertion method starts with a subtour comprising of one or two nodes, and extends the tour by
selecting a node from currently unvisited nodes and then inserting the selected node to the current
subtour in such a way that the incremental tour cost is as small as possible.
Let V be the entire node set where |V| = N and VT be the set of nodes included in the current
subtour. The k th iteration (1 k N-1) of an insertion algorithm enlarges the tour of size k to one
of size k+1 by applying the following two steps:

17

Selection step: In the set V-VT of the unvisited nodes, determine which node is to be
added to the cycle next.
Insertion step: Determine where the newly selected node is to be inserted to enlarge the
current subtour.
For the selection step, a number of heuristics have been suggested and investigated. Some of
these are:
arbitrary insertion: pick any unvisited node at random,
nearest insertion: pick the unvisited node that is nearest to the current subtour,
cheapest insertion: compare the cost of insertions of all unvisited nodes (in all insertion
positions) and pick the one having the smallest cost,
farthest insertion: pick the unvisited node that is farthest from the current subtour.
In addition to the above methods, the convex hull insertion method, and the greatest insertion
procedure can be applied, especially in an Euclidean space. (For more details, see Bodin (1983),
Golden and Stewart (1985), and Laporte (1992a).)
Of the insertion heuristics mentioned above, the farthest insertion appears to be the best overall
strategy (Golden et al., 1980). The underlying intuition behind the farthest insertion method is
that if a rough outline of the tour can be constructed through the widely-spread nodes, then the
finer details of the tour resulting from the incursion of the nearest nodes can be filled in without
greatly increasing the total length of the tour.
The farthest insertion algorithms are described as follows [Syslo et al., 1983]: in order to find the
farthest unvisited node, the array dist() of size N is maintained such that, for all unvisited nodes
v, dist(v) is the distance from the node v to the node in the current tour which is closest. The node
f denotes the farthest node from the current tour. Each time a new node is inserted into the cycle,
the dist array is updated. To find the best insertion position which is the closest edge from the
node f, the insertion cost of node f between node i and j (ICij ) is examined for all edges in the
current subtour. The insertion cost is expressed as
ICij = wif + wfj - wij .
Once the closest edge is obtained, state variables such as the total cost, the array dist() and the
node/edge sets corresponding to the current tour are updated. Below is the pseudo-code for the

18

farthest insertion algorithm. Here, s denotes an arbitrary node for an initial tour, and ET is the
edge set for the current subtour.

Initialization: VT = {s}; ET = {(s,s)}; wss 0; totalCost 0;

for all uV-VT, dist(u) wsu ;
Iteration:
while |VT | < n
(Selection):
f node in V-VT with largest value of dist(f);
(Insertion):
for every edge (i, j)ET, ICij wif + wfj - wij ; // examine insertion costs
(i* , j * ) edge in ET with smallest values of cij ; // find the closest edge
(update):
ET ET {(i* , f), (f, j * )}-{(i* , j * )}; // update the visited edge list
VT VT {f}; // update the visited vertex list
totalCost totalCost + ci*j* ; // update the total tour cost
for all xV-VT, dist(x) min{dist(x), wfx} //update the array dist
end

2.1.4.2.2 Improvement Procedures for TSP

There is a wealth of previous studies on heuristic approaches to improve solutions to the traveling
salesman problem. The best-known improvement heuristic procedures are edge-exchange (or
sometimes called edge-interchange) methods. Lin (1965) proposed the r-opt algorithm in which r
edges in a feasible tour are exchanged for other r edges in that tour as long as the result remains a
feasible tour and the length of the exchanged tour is less than the length of the previous tour.
Here, r is the number of edges exchanged at each iteration. The r-opt procedure is said to be roptimal if there is no feasible exchange that improves the current solution. The larger the value of
r, the more likely it is that the final solution is optimal. However, the computational requirements
increase rapidly as the value of r increases. As a result, r = 2 or r = 3 are the ones most commonly
used [Golden and Stewart (1985)].
A 2-exchange shown in Figure 2.1 involves the substitution of two edges, (i, i+1) and (j, j+1) with
two other edges (i, j) and (i+1, j+1). Such an exchange results in a local improvement if and only
if
wi,j + wi+1,j+1 < wi,i+1 + wj,j+1 .

19

Testing this improvement involves only local information and can be done in a constant time. The
total number of possible 2-exchanges is equal to NC2 , which implies a time complexity of O(N2 )
for the verification of 2-optimality.

i+1

j+1

j+1

Figure 2.1

i+1

Example of 2-exchange.

It should be noted that the orientation of the path (i+1,, j) is reversed in the proposed 2exchange tour. In a TSP having side-constraints such as time-windows, it is of importance to be
able to efficiently check the feasibility of the nodes in the reversed path. (This will be discussed
later.)
In a 3-exchange, where three edges are removed, there are several ways to construct a new route.
Two 3-exchanges shown in Figures 2.2(b) and (c) make an important difference: In Figure 2.2(c)
the orientation of the original tour is preserved whereas in Figure 2.2(b) this orientation is
reversed. The time to verification of 3-optimality is O(N3 ).

i+1

k+1

i+1

i+1

j+1

j+1

j+1

k+1

(a)

(b)

Figure 2.2

Example of 3-exchange.

20

k+1

(c)

Lin and Kernighan (1973) propose a variable r-opt algorithm which decides at each iteration how
many edges to exchange. The variable r-opt requires considerably more effort in coding than the
standard r-opt procedure. But the variable r-opt procedure outperforms the standard 2-opt or 3opt approach in finding near-optimal solutions. Because of this advantage, variable r-opt
procedure is frequently used to produce tighter upper bounds for the TSP.
With an intention to reduce the computational burden to verify r-optimality, proposals have been
made to take only a subset of all possible r-exchanges into account. Or (1976) proposes a method
that considers only those r-exchanges that would result in a string of s (= 2, 3..) consecutive
nodes being inserted between two other nodes. This reduces the time complexity required for the
verification of Or-optimality to O(N2 ). Figure 2.3 shows an example of Or-exchange (s=2) where
a string of (i1 , i2 ) is removed from its position and inserted between j and j+1.

i 1-1

i1

i 2 +1

i1

i2

j+1

j+1

Figure 2.3

2.1.4.3

i 1-1

i2 +1

i2

Example of an Or-exchange (s = 2).

Heuristic Approaches for the Traveling Salesman Problem with Time-windows (TSPTW)

Due to time-window restrictions at each node (or customer location), an arrival earlier than the
earliest service time ei introduces a waiting time at node i. On the other hand, the tour is
infeasible if the arrival time at node i is later than the latest service time li . Taking the timewindow into consideration, there are two types of objectives for TSP-TW [Savelsbergh, 1985]:
n

Minimizing the total travel time,

tk ,k +1 , which does not consider any possible waiting times at

k =0

the nodes.

21

Minimizing the route duration, An+1 -D0 , i.e., the time difference between the arrival time at the
depot (An+1 ) and the departure time at the depot (D0 ).
If the departure time at the initial node (node zero) is assumed to be set at its earliest time (i.e.,
D0 =e0 ), the objective of minimizing the route duration becomes that of minimizing the
completion time of the tour. This is suitable for our ASP problem which minimizes the total
completion time of runway operations for a given set of flights. In this review, we focus on the
procedures for the objective of minimizing the total route duration.
Most procedures for TSP can be successfully extended to TSP-TW. However, one difficulty in
applying heuristics designed for TSP to TSP-TW is testing the feasibility of a candidate tour
produced by any exchange scheme. For example, testing the feasibility of a k-exchange tour in
TSP with time-windows (or other side-constraints) requires O(N) time which results in a time
complexity of O(Nk+1 ) for the verification of k-optimality. Various types of researchers have
focused on devising more efficient techniques to test this feasibility.
By adopting the GENIUS (Generalized Insertion and Unstring and String) method for TSPs,
Gendreu et al. (1998) proposed a generalized insertion heuristics for TSP-TW in which the
objective is the minimization of travel time. The tour building algorithm produces a feasible route
by inserting a vertex in its neighborhood on the current route, and performing a local
optimization. Then, the feasible tour is post-optimized based on the successive removal and
reinsertion of all vertices.
Since the early eighties, TSP-TW has drawn additional attention due to the fact that procedures
for TSP-TW provide basic methods to solve vehicle routing problem with time-windows (VRPTW). These are very important and practical problems faced by the industries. The vehicle
routing problem (VRP) is a problem to design a set of minimum cost vehicle routes for a fleet of
vehicles of known capacity which service a set of customers with known demands [Solomon et
al., 1988]. All routes must originate and terminate at a common depot. Each customer is served
exactly once. In addition, all N customers must be assigned to vehicles such that the total demand
on any route does not exceed the capacity of the vehicle assigned to that route. The vehicle
routing problem with time-windows (VRP-TW) is a generalization of the VRP. In the VRP-TW, a
number of customers have one or more time-windows during which service must be scheduled.
Most VRP-TWs assume that the number of vehicles used is unlimited, i.e., the fleet size is
determined simultaneously.
Similar to TSP-TW, of primary importance to the effectiveness and efficiency of heuristics for
VRP-TW is the way in which the time-window constraints are incorporated in the solution

22

process [Solomon, 1987]. (In VRP, it is true that we should consider the vehicle capacity
constraint as well as time-windows. But, here we will skip discussions about the capacity
constraints. For more details about capacity constraint, see Savelsbergh, 1990a).
If we have a single vehicle to be scheduled (i.e. single VRP-TW), the problem then becomes the
same as TSP-TW. For this reason, it is worth reviewing previous studies on VRP-TW. These
studies include Psaraftis (1983a, 1983b), Savelsbergh (1985, 1990a, 1990b, 1992), Solomon
(1986, 1987) Solomon et al. (1988), Sexton and Bodin (1985), Baker and Schaffer (1986),
Desrosiers et al. (1986), Dumas et al. (1991, 1995), Desrochers et al. (1992), and Laporte
(1992b). Several of these procedures are reviewed below.

2.1.4.3.1 Psaraftis 's Procedure

A.

Tour Building Procedures

Psaraftis (1983a) suggests an O(N2 ) heuristic for the dial-a-ride problem (DARP) which is a
special type of TSP with precedence constraints. In the DARP, a vehicle is located at a point A,
and is called to service N customers, each of whom wishes to travel from a distinct origin to
distinct destination, and then returns to A so that total length of the route is minimized. Here, the
precedence among nodes should be considered because no destination can be visited before the
corresponding customer has been picked up. The problem is static in the sense that all N
customers requests are given and no new customer requests are considered until all of these N
customers are serviced.
Due to the complexity of the DARP, it is extremely hard to find an exact solution in reasonable
time for practical size problems (usually having more than 100 customers for a vehicle). For
instance, using Dynamic Programming to solve the DARP requires O(N2 3N) time, and this
approach limits the tractable problem size to no more than 8-10 customers [Psaraftis, 1980].
The tour building procedure proposed by Psaraftis is based on the minimum spanning tree (MST)
approach that is defined for N origins and N destinations. First, an initial TSP tour T0 through the
2N nodes is constructed. Then subsequent steps produce a feasible tour by traversing T0 in such a
way that precedence constraints are satisfied. The heuristic proceeds as follows.
Step 1 (Generate a TSP tour, T0 ): Without distinguishing origins and destinations, construct a
TSP tour T0 through 2N points based on their MST.

23

Step 2 (Generate a dial-a-ride tour, T1 ): Choose any customers origin on T0 as a first pick-up
point P1 around the starting point A. Construct a dial-a-ride tour T1 , by traversing T0
clockwise from P1 until all points are visited and then return to A. While doing this, do not
visit any point that has been previously visited or any destination whose origin has not
been visited yet.
Step 3 (Improve T1 : optional): Improve T1 by a sequence of a local exchanges.
Step 4 (Generate a dial-a-ride tour T2 : optional): Generate another tour by repeating Step 2 and
Step 3 but moving counterclockwise. Pick the shortest tour in T1 and T2 .
Step 5 (Optional): Repeat Step 2 (optionally 3 and 4) N times, each time choosing a different
customer origin as P1 . Pick the tour that has the minimum length.
For Step 3, Psaraftis proposes a local improvement scheme in the sense that the exchange
involves four adjacent nodes such as i, j, k, and m shown in Figure 2.4. Assuming that the edge
weights, wij , are symmetric and that the tria ngle inequality holds, the conditions for feasibility and
profitability of the exchange shown in Figure 2.4 are as follow:
wij + wkm < wik + wjm (condition for profitability),
where, k is not the destination of the customer whose origin is j (condition for feasibility).

Figure 2.4

A local exchange [Psaraftis, 1983a].

The computational complexity of the heuristic is O(N2 ) since finding MST, along with Step 3 and
5 each require O(N2 ) time. (Even though the MST in Euclidean plane can be found in O(NlogN)
time, still the heuristic is O(N2 ).)

B.

Improvement Procedures

24

In the context of DARP, Psaraftis (1983b) develops k-exchange procedures to perform local
search in a precedence-constrained vehicle routing problem. Similar to the k-opt procedure of Lin
(1965), and Lin and Kernighan (1973), a DARP tour is said to be k-optimal if it is impossible to
obtain another DARP tour of shorter length by replacing any k of its links by any other set of k
links.
Figure 2.5 depicts a 2-exchange. Such an exchange is profitable in a local tour improvement if
and only if wi,i+1 +wj,j+1 > wi,j +wi+1,i+1 under the assumption that the triangle inequality holds. In
contrast with the TSP where each individual exchange takes O(1) time, checking whether each
DARP exchange satisfies the origin-destination precedence constraints requires O(N2 ) time. (This
is so, because checking for precedences needs an examination of all pairs of nodes in the section
(i+1, j) and to ascertain if there is any customer who has the corresponding origin and destination
in the segment.) If the feasibility check is executed at every 2-inerchange, the procedure to find a
2-opt DRAP tour from a feasible DRAP tour will take O(N4 ) time.
Psaraftis proposes a method which finds the best 2-iterchange DARP tour out of a given feasible
tour in O(N2 ) time, which is the same as in the TSP where no feasibility checks are needed.
Suppose that we have an initial feasible DARP tour having N customers (labeled n=1,,N). A
DARP tour can be represented in one of following two ways.
Either using an array for a sequence counter S(i), i=0,,2N+1, representing the ith stop of the tour
given by following definition:
0
S(i) =

if i =0 and 2N+1 (i.e., the starting and ending point of the tour),

+n if the vehicle picks up customer n at stop i,

-n if the vehicle delivers customer n at stop i.

Or using a matrix [m(n,i)] in which m(n,i) represents the status of customer n at the end of the ith
stop of the tour:
3 if customer n has not been picked up so far,
m(n,i) =

2 if customer n is on board the vehicle,

1 if customer n has been delivered.

Let us consider a 2-exchange of (i, i+1) and (j, j+1) as shown in Figure 2.5. Checking the
precedence feasibility of the 2-exchange can be done by simply examining if there is any
customer n for whom m(n, i+1) = 3 and m(n, j) = 1. If there exists such a customer, the proposed

25

2-exchange will violate the precedence constraint. The matrix [m(n, i)] can be constructed from
array S(i) in O(N2 ) time. Having this matrix, we can check the precedence feasibility of a
proposed 2-exchange in O(N) time. Hence, the best 2-exchange DARP tour from a given initial
tour can be obtained in O(N3 ) time.

i+1

j+1

i+1

j+1

Figure 2.5

An example of 2-exchange.

In order to reduce the computational complexity further, Psaraftis introduces a screening

procedure to determine the feasibility of every possible 2-intercange. This screening process is
performed at the beginning of the algorithm, and the information is stored in a matrix to be used
in the tour improvement procedure.
Given a DARP tour and a stop i (0 i 2N-2), let FIRSTDEL(i) denote the position (or stop) of
the first delivery remaining beyond i+1, for which the corresponding customer has not been
picked up until stop i. The FIRSTDEL(i) is expressed as follows:
x
FIRSTDEL(i) =

if x is the smallest position above i+1 for which there exists a

customer n so that m(n, i) =3 and m(n, x) =1,

2N+1, otherwise.
Then, the precedence feasibility of a 2-exchange can be checked by applying the following
theorem.
Theorem (Psaraftis (1983b)): The substitution of links (i, i+1) and (j, j+1) with (i, j) and (i+1,
j+1) is feasible if and only if j < FIRSTDEL(i).

26

Using the array of FIRSTDEL() and the Theorem, the feasibilities of all possible 2-exchanges are
stored in the matrix [FE(i, j)] with values of true or false. The pseudo-code for the screening
process is presented below:
Step 1(Calculate the values of FIRSTDEL(i)): Using array S(i) and the matrix [m(n, i)], calculate
the values of FIRSTDEL(i) for all i, 0 i 2N-2.
Do i = 0 to 2N-2
Do x = i+2 to 2N+1
If (S(x) < 0)
// check if x is delivery
If m(-S(x), i) = 3) // check if x has already been picked up util the end of stop i
FIRSTDEL(i) = x;
End if
End if
If (x = 2N+1) then FIRSTDEL(i) = x;
End do i
End do x
Step 2 (Create a feasibility matrix [FE(i, j)] for all possible 2-exchanges):
Do i = 0 to 2N-2
Do j = i+2 to 2N
FE(i, j) = false;
If j < FIRSTDEL(i), then FE(i, j) = true;
End do i
End do j
The above screening process can be executed in O(N2 ) time. As a result, the best 2-exchange tour
out of a given DARP tour can be found in O(N2 ) time since checking feasibility of any proposed
2-exchange can be performed in O(1) time. It should be emphasized that what we have found so
far is not the find 2-opt tour but the best 2-interchange tour of a given DARP tour. To search for a
2-opt tour, the procedure should be applied a number of times. To facilitate this process, Psaraftis
introduces two search algorithms: Breath-first and depth-first search (see Psaraftis (1983b) for a
complete discussion of this).

2.1.4.3.2 Solomon's Procedures

A.

Tour Building Procedures

27

By extending the known VRP heuristics, Solomon (1987) proposes several tour-building
algorithms for VRP-TW. The novelty of the proposed approach is the incorporation of distance
and time dimensions in the heuristic process. The cost (for the objective function) of direct travel
from customer i to j is assumed to be given by ci j = 1 wij + 2 (b j - b i ), where 1 0, 2 0 and wij
is the direct travel time between i and j, and b j is the time to begin service for customer j. If 1 =
0, then the problem is to minimize the total travel time.
Solomon proposes necessary and sufficient conditions for time feasibility when inserting a
customer, u, between the customers ip-1 and ip , 1 p m, on a partially constructed feasible
route, (i0 , i1 , i2 ,, im ), i0 = im = 0 for which the times to begin service, bi r for 1 r m, are known.
Initially, the vehicle is assumed to leave the depot at the earliest possible time, e0 . (Later, the
depot departure time is adjusted to eliminate any unnecessary waiting time after the complete
vehicle schedule has been created.) The necessary and sufficient condition for feasibility of the
insertion is as follows:
b u lu and bi r + PFir lir , p r m,
new
where, PFir : the push-forward for customer ir is defined as bi p - bi p 0, if r =

p, and max{0, PFir Wir +1 } , if p r m 1,

and where, Wir +1 is the waiting time at ir+1 .

It should be noticed that if PFi p > 0, some of the customers ir , p r m, could become infeasible.
Hence, we need to examine these customers sequentially for time feasibility until we find a
customer, ir , for which PFi0 = 0, or ir is time infeasible.
It should also be noticed that, the aforementioned condition assumes that the triangle inequality
holds for travel distance and times. If non-Euclidean travel distances and times are used, then it is
possible that PFi p < 0, which leaves all the customers time feasible . Solomon proposes several
types of heuristic methods for the tour building methods.

Saving heuristics:
This approach is an extension of the savings heuristic originally proposed by Clarke and Wright
(1964). The procedure begins with n distinct routes in which each customer is served by a
dedicated vehicle. The tour-building heuristic is performed by the addition of a link of distinct
partially formed routes between two end customers, i and j, guided by a measure of cost savings
given by S ij = d i0 + d 0j - d ij , 0. In the VRP-TW, the route orientation must be considered
28

when two partial routes (see Figure 2.6) with end customers, l(ast) and f(irst), respectively, are
combined according to the savings value. Here, testing for time feasibility can be accelerated by
using the push-forward generated at f.

f
l

a) Before the addition

Figure 2.6

b) Addition 1

c) Addition 2

Two-addition procedures in a savings heuristic.

A time -oriented, nearest-neighbor heuristic:

This procedure initializes every route by finding the unrouted customer closest to the depot. The
heuristic searches for the customer closest to the last customer added to the route. Let the last
customer on the current partial route be customer i, and let j denote any unrouted customer. The
closeness of any two customers, i and j, denoted by cij , is the combination of the distance between
two customers d ij , the time difference between the completion of service at i and the beginning of
service at j, Tij , and the urgency of delivery to customer j, vij , given by the following equations:
Tij = Aj - (Ai + si ),
vij = lj - (Ai + si + wij ) and
cij = 1 wij + 2 Tij +3 vij , where 1 + 2 + 3 = 1, 1 , 2 , 3 0,
where, Ai : arrival time at customer i,
sj : service time for customer i,

B.

Improvement Procedures

29

Suppose that we have a 2-exchage tour as shown in Figure 2.5. Similar to Psarsftiss procedure,
Solomon (1988) considers two conditions to be satisfied for a substitution of (i, j) and (i+1, j+1)
with (i, i+1) and (j, j+1) to be favorable:
local improvement condition: wij +wi+1, j+1 < wi, j+1 + wi+1, j ,
feasibility condition: The time-window constraints of the customers affected by the exchange
need to be satisfied.
To check the feasibility of the 2-exchange, time-windows for all customers from i+1 to the end of
the route should be examined. Since this additional checking procedure requires O(N) time, the
total computational effort for 2-opt would result in a O(N3 ) time process.
By adopting the work of Psaraftis (1983b), Solomon et al. (1988) develop an acceleration method
for improvement heuristics for VRP-TW. This method is used as a preprocessor, which makes it
possible to handle the time-window constraints without an increase in running time of the
algorithm. Checking the feasibility of a 2-exchnage can be accelerated by examining the
precedence relationship between all pairs of customers. If Ai +si +wij (=Di +wij ) > lj , then customer i
should precede customer j in the tour. The precedence information between all pairs of customers
are stored in a matrix VP(i, j) in the following way:

VP(i, j) =

+1 if customer i must precede customer j,

0 if no precedence relationship exists,
-1 if customer j must precede customer i.

Similar to Psaraftis' method, it is possible to define a node precedence value, NP(i), for all
customers on the route which reflects the precedence dependence at that point with regard to
customers to be visited later in the route.
NP(i) = the smallest number k, k > i+1, such that VP(j, k) = +1, j i+1. If no such k
exists, then NP(i) = N+1,
where, N is the number of customers.
Given NP(i) for all i, a necessary condition for the time feasibility of a 2-exchange is stated as
follows:
A necessary condition for the feasibility of the 2-exchange of arcs (i, i+1) and (j, j+1)
with (i, j) and (i+1 and j+1) is that j < NP(i).

30

It is noted that VP(i, j) may be examined in O(N2 ) time, and NP(i) may be obtained from the
VP(i,j) in O(N2 ) time. It should also be noted that, unlike Psaraftiss procedure (1983b) for dial-a
ride problem, the aforementioned condition is not a sufficient condition but only a necessary
condition for feasibility of time-windows. Although the use of the NP(i) array does not eliminate
the need for further checking of the feasibility of a 2-exchage, Solomon et al. suggest that it may
be used as an effective filter to reduce the number of complete feasibility checks to obtain 2optimal solution for the VRP-TW. (For 3-exchanges and some examples, see Solomon et al.
(1988).)

2.1.4.3.3 Savelsbergh's Procedure

A. Tour Building Procedure
Savelsbergh (1990) introduce the forward-time slack at node i, Fi , to indicate how far the
departure time of the node can be shifted in time without causing the route to become infeasible
along the current path. The goal of the procedure is to check feasibility of the insertion of an
unrouted customer u between two routed customers i and i+1. Taking the departure time at the
initial node as the earliest service time (i.e., D0 = e0 ), Fi is defined as follows:

Fi = min lk Di + w p , p +1 .

i k n
p= i

Then, the feasibility of the insertion u will be secured if

max{Di +wi,u , eu } + wu,i+1 - Di+1 Fi .
Using the following backward recursion, Fk for all customers k can be computed in O(n).
Fn +1 = ln +1 Di ,
Fk = min{ Fk +1 + Wk +1, lk Dk } for k = n,1,

where, Wi : waiting time at node i defined as max{0, ei -Ai }.

31

For the profitability of the insertion, Savelsbergh uses the measure of savings given by the
following equation:
sav = 2w0,u + wi,i+1 wi,u - wu,i+1 .

B. Tour Improvement Procedures

The basic idea of Savelsbergh's tour improvement procedure (1990b) is to use a specific search
strategy in combination with a set of global variables such that testing the feasibility of a single
exchange and maintaining the set of global variables requires no more than a constant time, O(1).
The set of global variables is defined such that: 1) this set of variables makes it possible to test the
feasibility of a proposed exchange in constant time, and 2) the lexicographic search strategy
makes it possible to update the values of these variables in constant time. Savelsbergh suggests
three types of lexicographical search strategies for VRP-TW as shown in Figure 2.7.
Lexicographic search for 2-change: In the outer loop, choose the edge (i, i+1) in the order in
which they appear in the current tour starting at (0,1). For the inner loop, choose the edge (j,
j+1) to be (i+2, i+3), (i+3, i+4), , (n-1, n) (see Figure 2.7(a)).
Lexicographic search for backward Or-exchange: Choose the path (i1 ,,i2 ) in the order of the
current route starting with i1 equal to 2. Choose the edge (j, j+1) to be (i1 -2, i1 -1), (i1 -3, i1 -2),
, (0, 1) (see Figure 2.7(b)).
Lexicographic search for forward Or-exchange: Choose the path (i1 ,,i2 ) in the order of the
current route starting with i1 equal to 1. Choose the edge (j, j+1) to be (i2 +1, i2 +2), (i2 +2,
i2 +3), , (n-1, n) (see Figure 2.7(c)).
A general framework for the 2-exchange procedure is roughly described by the following pseudocode:
{ input: a route given as (0,1,2,,n)}
{ output: a route that is 2-optimal}
Start:
for i=0 to n{
initGlobal(i,G);
for j=i+2,n{
if(wi,j + wi+1,j+1 < wi,i+1 + wj,j+1 and FeasibleExchange(i,j,G))
{
PerformExchange(i,j);

32

Goto Start;
}
UpdateGlobal(i,j,G);
}// end for j
}// end for i

Comparing this procedure with the straightforward implementation, the suggested idea guarantees
that only constant time is spent on a single exchange, which implies an O(n 2 ) method for
verifying 2-optimality. On the other hand, in the straightforward implementation, the time spent
on a single exchange depends on the effort needed to establish either its feasibility or its
infeasibility, which implies an O(n 3 ) method for verifying 2-optimality.
Generally, the forward-time slack at node i related to the path (i,, j) and to the departure times
Di ,, Dj is expressed as:

Fi (i,..., j ) = min l k Di +

ik j

p =i

t p, p +1 .

Savelsbergh (1992) proves that if two feasible path (i1 ,, j 1 ) and (i2 ,, j 2 ), with associated
( i ,..., j )
(i ,..., j )
forward time slacks Fi1 1 1 and Fi 2 2 2 for the initial nodes are concatenated, the forward-

time slack for the first node of the resulting path is given by:

Fi1(i 1 ,..., j 1 , i 2 ,..., j 2 ) = min Fi1(i 1 ,..., j 1 ) , Fi1(i 2 ,...,

j2 )

i 1 < k j1

Wk + Di 2 (D j 1 + w j1 j 2 ) .

( 0,...,n )
Using the above equation, we can compute the forward-time slack at the depot, F0
, using

one of the following two ways:

( 0,...,i,i +1)
= min{ F0(0 ,...,i ) , li +1 Di +1 + 0< p i W p + Wi +1} .
forward recursion: F0
( i,i +1,...,n )
= min{li Di , Fi(+i1+1,...,n ) + Wi +1} .
backward recursion: F0

Another issue in improvement procedures is how efficiently the objective function associated
with a given exchange can be evaluated. Since our objective is to minimize the route duration,
Dn+1 -D0 , the efficiency of evaluation actually depends on the efficiency of the computation of

33

Dn+1 . Given a path (i,, j), a departure time Di and D0 =e0 , the departure time Dj can be computed
as
D j = Di + i k < j wk ,k +1 + i < k j Wk .

As such, the computation of waiting times, Wk, in a constant time is the real issue in checking for
profitability. Savelsbergh (1992) suggests an approach to compute the waiting time on the
concatenation of paths (i1 ,, j 1 ) and (i2 ,, j 2 ) by distinguishing four different cases on which
denotes D j1 + w j1 , j2 Di2 , and W2 which is the sum of the waiting time on the path (i2 ,, j 2 ).
Table 2.2 summarizes the results. Here B2 , which is the backward-time slack at node i relative to
the path (i,, j) indicates how far the departure time of the node can be shifted backward in time
without introducing any waiting time, and is computed as follows:
Bi(i ,..., j ) = min i k j {Dk ek }.

Table 2.2

Computation of Waiting Time on a Concatenated Path.

0

< 0

W2 = 0

W1

W1 +max{0, - -B2 }

W2 > 0

W1 +max{0, W2 -}

W1 + W1 +

Savelsbergh shows that on the concatenated path, both the forward-time slack at each node that is
used for the checking feasibility, and the sum of the waiting times used for checking the
profitability can be computed in constant time. Hence, it is possible to implement the testing of
feasibility and profitability in O(1) time.

34

i1

i1

0
i2

j+1

i2

j+1

i1

i1

0
i2

i2

j+1

j+1

j+1

i1

i1

0
i2

i2

j+1

j+1

j+1

i1

i1

0
i2

i2

j+1

(a) 2-changes

(b) Forward Or-exchanges

Figure 2.7

Lexicographic search strategies.

35

(c) Backward Or-exchange

2.1.4.4

Heuristic Approaches to the Asymmetric Traveling Salesman Problems (ATSP)

In principle, if an asymmetric TSP is translated into a symmetric TSP, we can now apply any
heuristic devised for symmetric TSP to solve ATSP. As pointed out by Kanellakis and
Papadimitriou (1980), this approach increases the problem size considerably. For example, a 100city ATSP is transformed into a 300-city symmetric TSP. They also remarked that not all
approaches to the symmetric TSP can be adopted to solve the ATSP (for example, the class of
techniques based on spanning trees). The power of Lin-Kernighans (1973) heuristic is the fact
that all primary changes are potentially searched. Kanellakis and Papadimitriou (1980) present an
extension of Lin-Kernighans local search algorithm for the solution of ATSP: the sequential
primary change in which the creation of a new cycle (by primary change as described below) is
immediately followed by a breaking of the cycle. They also suggest that the so-called quad
change which is nonprimary can substantially enrich the neighborhood structure. A quad change
is illustrated in Figure 2.8(d).
It is pointed out that Lin-Kernighans heuristic which uses a definite favorable -change (see the
definition given below) requires excessive computation for ATSPs. Without having any definite
favorable -change, the algorithm is designed to be able to stop if there is no favorable change at
every pair of steps. The computational results show that 90-city ATSPs can be solved in 4.43
minutes on a PRIME 400 minicomputer.
Below, we present the definitions of the -change and the primary change for a given tour ,
which are related to the sequential primary change.
Definition (-change of a tour ):
Let and be ATSP tours, X and Y be disjoint sets of edges such that =(-X)Y. If
|X|=|Y|=, we say that is a -change of . A graph G(,) is defined in such a way that,
given the nodes of G(,) corresponding to edges in X, if xi =(k, l) and xj =(p, q), xi , xj X,
then there is an arc (xi , xj ) in G(,) iff (k, q)Y. For example, a tour in Figure 2.8(b) is
a 5-change of the tour of Figure 9(a), and Figure 9(c) displays the graph G(,).
Definition (Primary change):
A tour is a primary change if G(,) consists of a single cycle. Figure 2.8(b), for
instance, shows a primary change for the tour of Figure 2.8(a), but Figure 2.8(d) displays
a non-primary change.

36

x5
y2

x4

y1
y3

x1
y5
y4
x2

x3

(a)

(b)

x5

x3
y4

x1

x4

y1
x1

x2
y2

y3

x2

x4

x3

(d)

(c)

Figure 2.8

Definition of primary changes.

There are two ways to gradually construct a primary change :

Decide x1 to be removed (see Figure 2.9(a)).
The choice of y1 (or generally y2i+1 ) uniquely determines an x2i+2 and a closed cycle C1 (Figure
2.9(b)).
Here we have two alternatives.
3-1) Choose y2 to break the cycle C1 and end up where the tour started (Figure 2.9(c)).
3-2) Choose y2 to generate a new cycle C2 (Figure 2.9(d)) and later break both cycles C1 and
C2 (Figure 2.9(e)).

37

Accordingly, we can define the sequential primary change as follows:

Definition (Sequential primary change):
If a primary change can be applied in a sequence, each immediately followed by the
breaking of a cycle, it is called a sequential primary change (see Figure 2.9(c)).

x1

(a)
x3

C1
y2

x1

y1

x2

x1

(b)

y1

x2

(c)
x4

C1

x1

y1

x2

x2

x1

y2
C2
x5
x3

x3

(d)

Figure 2.9

(e)

Construction of primary changes.

The heuristic for ATSP starts with an initial feasible tour . It picks an edge x1 of , and tries to
find a sequential primary change. If it fails, it backtracks with respect to the same x1 , and
considers all possible y1 s in increasing order and y2 s. (Here, all y2 s that break the cycle created
by y1 are searched and the one that produces the most favorable 3-change is selected.) If it fails
again, it backtracks with respect to all possible x1 s which it examines in decreasing order. This
part of the procedure is detailed as follows:
38

Step 1 (Initialization): Set G0 =0, G* =0, i* =0, and i=1. Pick x1 =(k, l) as the largest cost edge.
Step 2 (Pair of sub-steps):
Sub-step 1 (pick yi and create a new cycle Ci ):
Let xi =(k, l). Pick yi =(k, q) subject to F and Gi . This determines xi+1 and
generate a cycle Ci . If no such choice, stop.
Sub-step 2 (pick yi+1 and break the cycle Ci ):
Let xi =(p, q). Pick yi+1 =(p, r) subject to F and Gi+1 . This determines xi+2 and
a y* closing the tour, and it breaks Ci . If no such choice, stop.
Step 3 (Update): SP = G* . If G * > G* then, G* =G * , delete xi*+1 , , xi+1 from current tour , and
add yi*+1 , , yi+1 to the tour and set i* =i+1.
Step 4 (Stopping Criteria): If SP<Gi+1 , then set i=i+1, start a new pair of steps, else stop.
Where, F (Feasibility): The xs have not been ys in previous steps of the current search, and yi+1
breaks Ci .
Gi (working gain) = Gi-1 + c(xi ) - c(yi ).
Gi+1 = Gi + c(xi+1 ) - c(yi+1 ).
G * =

i+2

i +1

j =1

j =1

c( x j ) c( y j ) c( y*) >0.

G (the best definite gain achieved so far at the step i* ).

2.1.4.5

Heuristic Approaches to the Asymmetric Traveling Salesman Problem with Timewindows (ATSP-TW)

As part of a branch-and-cut algorithm to solve ATSP-TW, Ascheuer et al. (1999) apply a series of
heuristics. A sorting heuristic, a nearest-feasible -neighbor heuristic, and an insertion heuristic are
applied for constructing an initial feasible tour. A swap heuristic, a two-node-exchange heuristic,
a node-reinsertion heuristic, an arc-reinsertion heuristic, an arc-reversal heuristic, and the Orexchange heuristic are applied for improving a current tour. For the convenience of
implementation, an additional dummy node n+1 which denotes the depot is created such that
i p n+1 iV. (Here, p denotes the precedence relationship. For example, i p j means that i
has to precede j.) Ascheuer et al. also suggest an efficient order to implement these heuristics as
follows:
Do{ construction heuristics with following order:
Sorting heuristic
Nearest-feasible -neighbor heuristic
Insertion heuristic 1
Insertion heuristic 2
}
If no feasible sequence found Stop.
Do{ improvement heuristics with following order:
Or-exchange heuristic
39

Arc-reversal heuristic
Swap heuristic
Arc-reinsertion heuristic
Node-reinsertion heuristic
Two-node exchange heuristic
} until no further improvement is achieved.

A. Tour Building Procedures

The various types of heuristics used for tour building are as follows:
1) Sorting heuristic:
Check if the trivial sequence (0, 1,, n-1, n, n+1) is feasible.
Sort the nodes according to increasing ri and check whether this sequence is feasible.
Sort the nodes according to increasing d j and check whether this sequence is feasible.
Sort the nodes according to the midpoints of the time-windows mj = ej +(ej +lj )/2 and check
whether this sequence is feasible.
2) Nearest-feasible -neighbor heuristic:
For each feasible arc (0, i)A,
Enlarge the current subtour (0, v1 , v2 ,,vk) by an arc (vk , vl ) resulting in the smallest increase in
the objective value and guaranteeing feasibility.
3) Insertion heuristic:
Construct the initial subtour P=(0, v1 ,, vk, n+1) by finding the shortest path from 0 to n+1.
Enlarge the current subtour P by choosing a node j satisfying one of following criteria.
b1) Among all unsequenced nodes V=V\{v1 ,, vk}, choose the node j V that yields the
lowest increase in the path length, i.e., d min (j)=min{d min (i)|i V}, where d min (i) = min
{ wvl i + wivl +1 wvl vl +1 | i V, vl P and subtour (0, v1 ,, vl , i, vl+1 ,, vk, n+1) is
feasible}.
b2) Among all unsequenced nodes V=V\{v1 ,, vk}, choose the node jW that has the lowest
number of feasible insertion positions and insert this nodes at the cheapest of these
positions.

40

B. Improvement Heuristics
The details of the improvement heuristics are as follows:
1) Swap heuristic:
Given a feasible tour T=(v0 , v1 ,, vn+1 ), construct a new tour T by scanning through the current
tour and checking whether swapping two subsequent nodes vi and vi+1 , i =1,..,n-1, results in a
feasible solution with a better objective value. If a better solution is found, this new tour is
accepted. The procedure is repeated until no further improvement is achieved.

2) Two-node-exchange heuristic:
Given a feasible tour T=(v0 , v1 ,, vn+1 ), construct a new tour T by exchanging any two nodes (not
only subsequent nodes) in the current tour. If a better solution is found, this new tour is accepted.
This procedure is repeated until no further improvement is achieved.
3) Node-reinsertion heuristic:
Given a feasible tour T=(v0 , v1 ,, vi , vj , vk,, vn+1 ), construct a subtour T =(v0 , v1 ,, vi , vk,,
vn+1 ) by eliminating an inner node vj . Try to reinsert vj in the best position in T such that the new
tour T is feasible. If a better solution is found, this new tour is accepted. This procedure is
repeated until no further improvement is achieved.
4) Arc-reinsertion heuristic:
Given a feasible tour T=(v0 , v1 ,, vi , vj , vk, vl ,, vn+1 ), construct a subtour T =(v0 , v1 ,, vi , vl ,,
vn+1 ) by eliminating two consecutive nodes vj and vk. Try to reinsert the arc (vj , vk) at any position
in T such that the new tour T is feasible. If a better solution is found, this new tour is accepted.
This procedure is repeated until no further improvement is achieved.
5) Arc-reversal heuristic:
Given a feasible tour T=(v0 ,, vj , vk,,vl , vm ,, vn+1 ), construct a tour T=(v0 ,, vj , vl ,,vk,
vm ,, vn+1 ) by reversing the subpath (vk,,vl ) such that the new tour T is feasible. If a better
solution is found, this new tour is accepted. This procedure is repeated until no further
improvement is achieved.
6) Or-exchange heuristic:
41

Given a feasible tour T=(v0 , v1 ,, vi ,,, vj ,, vn+1 ), remove the subpath (vi ,,vj ) from the
current tour T, and try to reinsert it between any two subsequent nodes vl and vl+1 such that the
new tour T is feasible. If a better solution is found, this new tour is accepted. This procedure is
repeated until no further improvement is achieved.

2.2 Literature Review on Network Assignment Problem (NAP)

The NAP problem on the taxiway has many similarities with urban transportation network
problems. In urban networks, NAP solutions provide the best routes for drivers traveling to their
own destinations so that the system (or drivers) can reach an optimal (or equilibrium) state. In
solving urban transportation network problems, three types of sub-components are generally
involved:
Network assignment algorithm which, using the shortest path information, allocates traffic
demand, i.e., vehicle s, on the routes,
Shortest path algorithm which, using the link travel times, provides the shortest paths for a
given O-D pairs on the network, and
Link performance function(s) which represent the relationship between the traffic volume on
a link and the travel time along the link.
Finding an adequate link performance function is considered as a difficult task, and is still a
controversial issue. The difficulty arises from the dynamic feature of traffic conditions. Some
research groups [Leonard et al. 1978, Van Aerde 1985, 1999] use a simplified version of link
performance function having two components: free running times along the link and delays at
junction [Rakha, 1990]. Other groups [Peeta and Mahmassani 1995, Mahmassani, 1998] use
simulation models as a tool for measuring link travel time rather than using a closed-formed link
performance function. Some researches [Ran et al. 1997] suggest more sophisticated functions
which are capable of capturing the dynamic characteristic of vehicle behaviors. In this research,
we assume that the link travel time is a function of only delays at a junction. It is further assumed
that the delays at taxiway junctions are proportional to the number of conflicting vehicles.
Among those three sub-components, we revie w the previous studies on the network assignment
algorithm and the shortest path algorithm which have been well defined and successfully studied.

42

2.2.1

Literature Review on Network Assignment Algorithms

Depending on the time-dependency, network assignment algorithms can be classified into two
types: 1) static network assignment algorithm, and 2) dynamic network assignment algorithms.

2.2.1.1

Static Assignment Algorithm

In 1952, Wardrop established two mutually independent network assignment principles for the
static assignment problem. According to the first principle, users on the network choose a route
that minimizes their own travel time. In the second principle, users distribute themselves on the
network in such a way that the average (or marginal) travel time for all users for each route from
origin to destination is equal so that the aggregate vehicle -hours spent in traveling is minimized.
These two assignment principles are also-called User Equilibrium (UE) and System optimal
(SO) respectively. Two critic al conditions arise from two static network assignment principles
[Papacostas and Prevedouros, 1993]:

1) User equilibrium (UE) is the state where no traveler can improve his/her travel time by
unilaterally changing routes. (In other words, for each O-D pair, the travel time on all used
paths is equal, and also less than or equal to the travel time that would be experienced by a
single vehicle on any unused path.)
2) System optimal (SO) is the state where the travelers cannot improve the total system travel
time by jointly changing routes in any fashion. (In other words, for each O-D pair, the
marginal travel time on all used paths is equal, and also less than or equal to the marginal
travel time that would be experienced by a single vehicle on any unused path.)
Finding UE (or SO) solutions is a well-researched problem and various techniques are commonly
used in urban transportation studies [Sheffi, 1985]. The basic notation adopted in this research
project is shown below:
xa n : flow on link a at n th iteration,
ta : travel time on link a at n th iteration,
q rs : trip rate between origin r and destination s,
ta (): link travel time function for link a.

43

A) All-or-nothing assignment
The all-or-nothing assignment method is one in which the entire flow for any given O-D pair r-s,
q rs , is assigned to the minimum-travel-time path connecting this pair. The usual steps for the allor-nothing assignment are:
Step 0: initialization. Perform all or nothing assignment based on the shortest paths for all
trips obtained by using ta 0 = ta (0) for all the links. Obtain link flows {xa 0 } for all the
links. Set n = 1.
Step 1: update the link travel times. Set ta n = ta (xa n-1 ).
Step 2: network loading. Assign all the trips to their shortest paths on the network using the
all-or-nothing strategy based on the travel times {ta n }. Obtain the link flows {xa n }
for all the links.
Step 3: convergence test. If maxa {| xa n - xa n-1 |} k, then stop. Otherwise, set n n + 1 and
go to Step 1.

Considering how all-or-nothing assigns all of q rs to the shortest path, the algorithm is not
successful at converging to the state of user equilibrium. To overcome this problem, the following
algorithms have been devised by the Federal Highway Administration (FHWA).
Step 0: initialization. Perform all-or-nothing assignment based on the shortest paths for all
trips obtained by using ta 0 = ta (0) for all the links. Obtain the link flows {xa 0 } for all
the links. Set n = 1.
Step 1: update and smooth the link travel times. Set a n = ta (xa n-1 ) and ta n = 0.75 ta n-1 +
0.25a n for all the links.
Step 2: network loading. Perform an all-or-nothing assignment based on the travel times
{ta n }. Obtain the link flows {xa n } for all the links.
Step 3: stopping rule. If n = N, go to Step 4. Otherwise, set n n + 1 and go to Step 1.
*
Step 4: averaging. Set xa =

1
4

3
i =0

xan i , find the link travel times, ta * = ta (xa * ) for all the

links and stop. (Here, { xa * } approximate the link flows at equilibrium.)

44

There are two modifications used above. First, the link travel times are updated by smoothing the
link travel times from both the current and the previous iterations using certain weighting factors.
Second, the final link flows are obtained by averaging link flows from the last four iterations.
These modifications have proven to be somewhat helpful in obtaining solutions that are closer to
a true equilibrium state.
B) Incremental Assignment
In the incremental assignment method, the flows for a given O-D pair are assigned as a packet
which represents a portion of the origin-destination matrix at each iteration. The travel times are
updated based on the total traffic flows assigned to the links. The stepwise procedure for this
approach is outlined below.
Step 0: initialization. Divide each origin-destination demand into N equal portions (i.e. set
q rs n = q rs /N). Perform an all-or-nothing assignment based on ta 0 = ta (0). Obtain a set
of link flows {xa 0 }. Set n = 1 and xa 0 =0.
Step 1: update link travel times. Set ta n = ta (xa n-1 ).
Step 2: incremental network loading. Assign q rs n to the network based on the travel times
{ta n } for all origin-destination (i.e. rs) pairs. Obtain a set of link flows {wa n } from
this assignment, where wa n is the flow on link a resulting from the assignment of the
nth increment of O-D matrix on to the network.
Step 3: flow summation. Set xa n = xa n-1 + wa n for all the links.
Step 4: stopping rule. If n = N, stop with the current link flows as the prescribed solution.
Otherwise, set n n + 1 and go to Step 1.
One important fact in the incremental assignment procedure is that as the number of increments,
N, grows, the condition for UE can be achieved more closely. This point provides us with the
rationale for using an incremental assignment strategy in microscopic simulation models. In
microscopic simulation models, the vehicles are treated as individual objects, which means that
each vehicle is assigned one by one rather than as a packet of size q rs /N on the network. In this
case, the number of increments (N) is the same as the total number of vehicles, and this might
tend to produce the UE state.

45

C) Method of Successive Averages (MSA)

The MSA uses the following basic algorithm step of most minimization procedures.
x

n+1

= x n + n d

where, x n is the link flows at nth iteration,

n is a step size and
d n is a descent direction vector computed at x n .
In MSA, the step size n (n=1,2,) is not determined on basis of some characteristics of the
current solution but determined a priori. For this method to converge, some conditions of the
objective function and n have to be satisfied. These conditions include twice differentiability of

the objective function,

n = and

n =1

2
n

= (see Sheffi (1985) for a complete discussion).

n =1

The method is outlined below.

Step 0: initialization. Perform an all-or-nothing assignment based on ta 0 = ta (0). Obtain a set
of link flows {xa 1 }. Set n = 1.
step 1: update. Set ta n = ta (xa n ).
Step 2: direction finding. Assign all the trips to the network based on the travel times {ta n }.
Obtain a set of auxiliary link flows {ya n } from this assignment.
Step 3: move. Find the new flow pattern for all the links by setting xa n+1 = xa n + (1/n)(ya n xa n ).
Step 4: convergence test. If a convergence criterion is met, stop with the current solution,
{xa n+1 }, as the set of prescribed (near equilibrium) link flows. Otherwise, set n n
+ 1 and go to Step 1.
D) Convex Combination Method
Without using a predefined step size n , the convex combination method finds n at each iteration
by solving a Non-linear Programming (NLP) problem which is subject to linear constraints. The
resulting NLP problem can be replaced by a much simpler linear approximation, and solved using
the Frank-Wolfe (1956) algorithm. The method is outlined below.

46

Step 0: initialization. Perform an all-or-nothing assignment based on ta = ta (0). Obtain a set

of link flows {xa 1 }. Set n = 1.
Step 1: update link travel times. Set ta n = ta (xa n ).
Step 2: direction finding. Assign all the trips to the network based on the travel times {ta n }.
Obtain a set of auxiliary link flows {ya n } from this assignment.
Step 3: line search. Find n by solving 0min
1

x na + ( y na x na )
0

t a () d .

Step 4: move. Set xa n+1 = xa n + n (ya n - xa n ) for all the links.

Step 5: convergence test. If a convergence criterion is met, stop with the current solution,
{xa n+1 } as the set of prescribed (near equilibrium) link flows. Otherwise, n n + 1
and go to Step 1.
Methods A) and B) are called heuristic (or sometimes called non-equilibrium) assignment
methods in the sense that these may not converge to the equilibrium solution. On the other hand,
method D) is formulated as a mathematical programming technique to achieve either UE and SO.
It can be shown that solutions of mathematical formulations are consistent with to the conditions
of UE and SO defined by Wardrop.

2.2.1.2

Dynamic Assignment Algorithm

Similar to the static assignment problem, there are two types of dynamic assignment problems: 1)
dynamic system optimal assignment problem (DSO) which seeks to minimize the total system
travel time over the planning horizon, and 2) dynamic user equilibrium assignment problem
(DUE) which seeks time-dependent user path assignments that satisfy the temporal extension of
Wardrops UE condition [Peeta and Mahmassani, 1995].
Janson and Robles (1995) define the DUE as follows: Given a set of zone-to-zone trip tables
containing the number of vehicle trips from each origin zone in successive time intervals of 1 to
10 minutes each, determine the volumes of vehicles on each link in each time interval such that,
for each O-D pair of zones, no path has a lower travel time than any used path for trips departing
within a given time interval. Janson (1991) proves that the DUE condition for fixed departure
times is a temporal generalization of Wardrops condition for a static user equilibrium.
Using optimal control theory, Friesz et al. (1989) and Wie (1989) present formulations for
dynamic traffic assignment in continuous time, in which the equilibrium condition is stated that
47

no used path between any two nodes must have a higher travel time than any other path at any
instant. Ran et al. (1993) refine and extend optimal control models to include elastic demand and
departure time choice in user equilibrium or system optimal forms. Friesz et al. (1993) formulate
the simultaneous route choice and departure time problem in continuous time as a variational
inequality problem. Ran et al. (1997) propose the time-dependent travel time functions for
dynamic assignment on signalized network links which can be used to solve discrete-time
dynamic assignment problems.
Peeta and Mahmassani (1995) point out that virtually all of previous DUE models have link flows
as the decision variables, and that path flows obtained from link-based formulations are not
always unique. They suggest a formulation for the path-based assignment problem which
involves a non-explicit function of path travel times.

Instead of defining the extremely

complicated path travel time function, a simulator called DYNASMART is developed and used
to evaluate experienced path travel times. By applying Lagrangian multipliers, Peeta and
Mahmassani derive the conditions for a Dynamic System Optimal (DSO) state. At a DSO state,
the time-dependent marginal travel times for all used paths connecting a given O-D pair are
equal, and less than or equal to the time-dependent marginal travel times on any unused routes. In
order to find marginal link travel times, a curve fitting method is suggested. As a solution
algorithm, the method of successive averages (MSA) is used to determine the new path flows for
the next iteration. Using time-dependent experienced link travel times measured by the simulator,
the time-dependent shortest paths for all O-D pairs are computed. The complete algorithm is
depicted in Figure 2.10.
In the context of the simulation model named INTEGRATION, Van Aerde (1985) suggests that a
minimum path tree table indirectly constitutes a traffic assignment function, and forms the basis
upon which vehicles make route selection decisions. Specifically, the minimum path tree table
provides a list of the turning movements which correspond to the minimum paths for each
destination. These minimum path turning movements identify all downstream links
corresponding to a vehicles minimum cost path, given the current location of the vehicle and its
eventual destination. As drivers re-check these minimum path trees at each node, they
automatically reselect new paths if previous paths become congested and/or competing
alternative paths become faster. This path selection (and re-selection) process is based on realtime information and attempts to reproduce a continuous dynamic equilibrium.

48

 ,0
rijk

Network Simulator
(continuous/micro simulation)

x ta, i , T ta , i
Computation of the timedependent marginal link travel times
Legend:

Tta : travel time on link a during time interval t

xta : number of vehicles on link a during time interval t

t ta , i

tta : marginal travel time on link a during time interval t

rijk
: number of vehicles departing from i to j in period that are

Time-dependent
least marginal time path

assigned to path k
yijk * : auxiliary number of vehicles on paths departing from i to j

All-or-nothing
assignment

in period that are assigned to path k

ii+1

i: iteration counter.
,i
yijk
*

Path

Method of Successive Averages (MSA)

rijk , i +1 =

1
1
[ yijk,i ] + (1
)[rijk , i ]
+
+
(i 1)
(i 1)
rijk ,i+1 rijk ,i , i,j,k,

no

STOP

yes

Figure 2.10 Algorithmic Framework for Time-Dependent System Optimal Assignment Problem
[Peeta and Mahamassani, 1995].

49

2.2.2

2.2.2.1

Shortest Path (SP) Algorithms

Importance of SP Algorithm in Transportation Studies

Finding shortest paths is a classical problem in the field of Operations Research. Recently, with
the development of Integrated Transportation System (ITS), the time-dependent assignment
problem for real-time traveler information system has captured some renewed attention. It is
widely accepted that the successful implementation of real-time traffic network control system
depends on the efficiency of SP algorithms. The following comments show the importance of the
SP problem [Gallo, 1985].
If there is one routine that is never absent from any computer code used in transportation
analysis, it is certainly the SP routine. About 80 percent of computation time in traffic
assignment is consumed in finding shortest paths.

2.2.2.2

Definitions of SP Problems

Depending on the time-dependency of link travel times and number of shortest paths to be found,
SP problems are categorized into static SP, static k-SP, time-dependent SP, and time-dependent kSP problems. In the static SP problem, the link costs (or travel times) are assumed to be
independent of time. In the time-dependent SP problem, on the contrary, the link costs change
over time. Instead of finding a single path for a given origin-destination (O-D) pair, the k-SP
problem deals with multiple shortest paths. The k-SP problems are also classified as being either
static or time-dependent. The definition of various SP problems are summarized in Table 2.3
[Subramanian, 1997]. The basic notation used in this section is shown below:
N: node set of a given graph G(A, N),
A: arc set of a given graph G(A, N).
AT: arc set of a directed spanning tree T.
FS(i): forward star of node i,
RS(i): reverse star of node i,
cij : the travel cost (or travel time) of link (i, j)A,
cij (t): the travel cost (or travel time) of link (i, j)A departing node i at time t,
s: source node,
tn: terminal node,
i, j: intermediate node.

50

Table 2.3

Various Definitions of SP Problems.

Problem

Given

A graph G(N, A) having |N| nodes and The shortest path from s to t.
|A| arcs, and a distinguished source
node s and a destination node t, and a
set of link costs, cij , associated with
each arc (i, j).
Same as static SP problem.
The first, second,, k th shortest
paths from s to t, for any userspecified k1,2,...
A graph G(N, A) having |N| nodes and The shortest path from s to t,
|A| arcs, and a distinguished source starting from s at time t=t0 .
node s and a destination node t, and a
set of time-dependent link delays,
cij (t), associated with each arc (i, j).
Same as time-dependent SP problem.
The first, second,, k th shortest
paths from s to t, starting from s at
time t=t0 , for any user-specified
k1,2,...

Static SP

Static k-SP

Time-dependent
SP

Time-dependent
k-SP

2.2.2.3

Find

Static SP Algorithm

2.2.2.3.1 Network Flow Programming Approach

The static SP problem can be formulated as a minimum-cost network flow problem (Bazaraa et
al., 1990).

Minimize
x

subject to :

cij xij

( i, j )A

xij

j FS (i )

ji

= si

i N

j RS ( i )

xij 0

(i, j) A

where s s = 1 , stn = 1 , s i = 0 i ( s , tn)

and where, ss , stn , si : supply of node s, tn, i, respectively.
Due to the unimodularity property of this network structure, optimal extreme point solutions take
only integral values.

51

2.2.2.3.2 Bellman's Principle of Optimality

Bellman introduced the well-known "Principle of Optimality" which provides the basic
foundation for recursive algorithms including Dynamic Programming. Using the "Principle of
Optimality", Bellman (1966) developed the following equation. Let us denote
the (finite) length of arc (k , j ), if there is such an arc.
ckj =
+ , otherwise.
f j = the length of a shortest path from the origin to node j.

If there are no directed cycles with negative length, it is clear that f s = 0, where the node s is the
origin node. For each node j, j s, there must be some final arc (k, j) in a shortest path from node
s to j. Whatever the identity of k, it is certain that f j = f k + ckj . This follows from the fact that
the part of the path which extends to node k must be a shortest path from 1 to k. If this is not true,
the overall path to j would not be as short as possible (this is the Principle of Optimality). The
relationship between nodes s, k and j is shown in Figure 2.11.

f s= 0
s

fk

fj

c kj

Figure 2.11 Bellman's Principle of Optimality.

The shortest path length must satisfy the following system of equations (called Bellmans
equations):
fs = 0 ,

f j = min { f k + ckj }, j = 1,.., n .

k j

52

2.2.2.3.3 Labeling Algorithm

Labeling algorithms are known as the most popular and efficient methods to solve the shortest
path problem. The label in the algorithm represents the tentative shortest path length from the
source node to that node. There are two types of labeling algorithms: label setting (LS) and label
correcting (LC).
The LS algorithm sets the label of one node permanently at each iteration, thus increasing the
shortest path vector by one component at each iteration. The LC algorithm does not set any label
permanently. Instead, all the components of the shortest path vector are obtained simultaneously
after the algorithm terminates. Some features of these two SP algorithms are summarized in Table
2.4.
Table 2.4

Comparison of LS and LC Algorithm (1).

Label correcting (LC) algorithm

Label setting (LS) algorithm

Designate one label as permanent at each All labels are temporary until the final step
iteration
when all become permanent
Applicable only to Acyclic networks and Non- Applicable to all classes of problems
negative arc lengths problem
Both are iterative
Assign tentative labels to nodes at each step
(Label = the upper bound on the shortest path cost)
LS Algorithm LC Algorithm
The LC method always exchanges (augments, or updates) arcs in AT in a manner that replaces or
shortens the unique path from the source node s to v in T, where T is the directed spanning tree
and AT is the in T. However the LC method does not guarantee that the new path is a shortest path
until termination occurs.
The LS algorithm has become known as Dijkstras algorithm since Dijkstra was one of the first to
discover it independently. This algorithm finds the shortest paths from the source node s to all
other nodes in a network with nonnegative arc lengths. Table 2.5 shows generic pseudocodes for
the LS and LC algorithms.
Let, f i : travel distance (or travel time or label) to node i from source node s (which is an upper
bound on the shortest length to node i),
cij : the (finite) length of arc (i,j),
S : permanent label set,
S : temporary label set.

53

Table 2.5

Comparison of LS and LC Algorithm (2).

LS Algorithm (Dijkstras Algorithm)

Node-based selection.
Using permanent and temporary label.
S={}, S =N;
f s = 0 and predecessor(s) = 0;
f i = for each node i N;
while S n where n=|N| do
select node i S which f i = min{f j : j S };
S = S {i} ;

LC Algorithm
Arc-based selection
f s = 0, predecessor(s)=0;
f i = for each i N-{s};
while some arc(i,j) satisfies f j > f i + cij
do
f j = f i + cij ;
predecessor(j) = i;
end

S = S {i} ;
for each (i, j), jFS(i) do
if f j > fi + cij then
f j = f i + cij ;
predecessor(j) = i;
end
end
end

2.2.2.4

Time-dependent SP Algorithm

Assuming that the time-dependent link costs for all links, cij (t), are positive integer values, Cook
and Halsey (1966) have extended Bellmans Principle of Optimality to solve a time-dependent SP
algorithm. According to Cook and Halsey, the minimum time of travel to node tn starting from
node i at time t, f i (t), is defined by the following functional equation and shown in Figure 2.12:

min {cij (t ) + f j [t + cij (t )]} for i tn; t S

j i
f i (t ) =
for i = tn; t S
0
where, S: the discrete time set; S={t0 , t0 +1, t0 +2,, t0 +T},
T: the fixed upper-bound of travel time from node i to tn.

54

cji(t)

fi(t+c ji(t))
fj(t)

Figure 2.12 Time-dependent SP Algorithm [Cook and Halsey, 1985].

Dreyfus (1969) has suggested the use of Dijkstras algorithm to determine time-dependent
shortest paths where the link costs are any real-valued times. The minimum time of travel to node
j starting from node s at time 0, f j , is defined as follow:

min { fi + cij ( f i )} for i tn,

i j
fj =
for i = tn
0
f s= 0
s

fk

fj

c kj

Figure 2.13 Time-dependent SP Algorithm [Dreyfus, 1969].

While Cook and Halsey's method applies the Principle of Optimality in forward form, Dreyfuss
algorithm is implemented in backward fashion. Dreyfuss main algorithm is exactly the same as
that of the LS algorithm except that time-dependent link costs are used in the optimality
constraint. The following procedure finds the minimum path tree from node s to all nodes starting
at 0.
S={}, S =N; f i = for each node i N; f s = 0 and predecessor(s) = 0;
while S n do
select i S which f i = min{f j : j S };
S = S {i} ;
S = S {i} ;
for each (i, j), jFS(i) do
if f j > f i + cij ( f i ) then

55

f j = f i + cij ;
predecessor(j) = i;
end
end
end
Harpern (1977) first noted the limitation of Dreyfus approach and showed that if there exists a
y>0 such that y + cij (t + y ) < c ij ( t ) , then the departure from node i must be delayed, or the
optimal path might include cycles. Kaufman and Smith (1993) studied the assumptions under
which the existing TDSP algorithms would work. To illustrate the point, consider the simple
network shown in Figure 2.14. The resulting SP from 1 to 4 starting at time 0 is 1-3-4, with the
total path cost f 4 = 15.

2
C12 (0) = 10

C23 (10) = 10

C13 (0) = 10

C34 (20) = 5
C34 (10) = 5

Figure 2.14 Example of TDSP (1).

Now, let us assume that as shown in Figure 2.15, the travel time for link (3,4) at time 10 increases
to 20. Then the shortest path for the trip from 1 to 4 starting at time 0 is 1-2-3-4 with a travel cost
of 25. Here, it should be noticed that the driver who enters link (3,4) at time 20 can finish the trip
at 25 but another one who enters the same link at time 10 cannot finish the trip until 30. This
result is unreasonable in general transportation networks because the first-in-first-out (FIFO)
condition is violated.

2
C12(0) = 10

C23(10) = 10

3
C13 (0) = 10

C34(20) = 5
C34(10) = 20

Figure 2.15 Example of TDSP (2).

56

Kaufman and Smith make a consistency assumption preventing the time-dependent link cost to
indicate passing as follow.
For any arc (i,j)A, t1 +cij (t1 ) t2 +cij (t2 ) for all t1 , t2 T such that t1 t2 .
i.e.,

cij (t1 ) cij (t 2 )

1 for t1 t2 .
t 2 t1

They also show that under the assumption that the link-delay function follows the first-in-first-out
(FIFO) rule or consistency assumption, any static LS or LC algorithm can be extended to the
time-dependent case (using the time-space network formulation).
Orda and Rom (1990) studied various types of waiting-at-nodes scenarios and proposed
algorithms for these different cases. They showed that if waiting is allowed at nodes (UW), then
the consistency assumption is not required. They prescribed an algorithm for identifying optimal
waiting times at the source node if waiting is not allowed elsewhere in the network. Furthermore,
they demonstrated that for the forbidden waiting case, the paths obtained without the consistency
assumption may not be simple, and showed that the continuous-time version of the problem is
NP-Hard. Table 2.6 shows the three cases of time-dependent SP algorithms studied by Orda and
Rom. Sherali, Ozbay, and Subramanian (1998) prove NP-Hardness of various versions of timedependent shortest path problems, and develop efficient solution algorithms.

Table 2.6

Three Types of Time-dependent SP Algorithms.

UW (Unrestricted Waiting)

Vehicles may wait an unlimited duration at any nodes

SW (Source Waiting)

Vehicles may wait an unlimited duration only at source nodes

FW (Forbidden Waiting)

Vehicles are not permitted to wait at any nodes

For the UW case, the suggested solution algorithm matches that of Dreyfus, except that Dij (t) is
defined as follows.
Dij (t) = w + cij (w+t)
where, Dij (t) : total link travel time from i to j
w : waiting time at node i
cij (w+t): travel cost from node i to j starting at (w+t)

57

Figure 2.16 illustrates the graphical derivation of Dij (t).

cij(t)
cij(t)
Dij(t)
Dij(t)

t1

t2
Waiting
time(w)

45 o
time
t2 +cij(t2 ) t1 +cij(t1 )
cij(t1 +w)

Dij(t1 ) = w + cij(t1 +w)

Figure 2.16 Total Link Travel Time for the UW Problem.

2.2.2.5

Implementation Issues

Gallo and Pallottino (1985) point out that the traditional classification of shortest path algorithms
into LC and LS is somewhat unsatisfactory because of its dependence on the behavior of the
algorithm rather than on their data structure. Dijkstras algorithm is a type of LS algorithm where
the arc lengths are non-negative, while it becomes a LC algorithm if there are some negative arc
lengths in the graph. Gallo and Pallottino suggest that it is more desirable to classify the SP
algorithms based on the data structure which is the way to keep so-called candidate nodes for
next iteration. Let T be a directed spanning tree of G rooted at node s, and d v be the length of the
unique path in T from s to v, vG. Then T is a shortest path tree with origin s (T = T(s)) if and
only if the following condition holds:
f i + cij f j 0

for all (i, j)A

(2.1)

Then all the arc-based shortest path algorithms (i.e., LC SP algorithms) can be stated as having
the following procedures:
Step 1: Initiate a directed tree T rooted at r and for each vN, let f v be the length of the path
from s to v in T.
58

Step 2: Let (i, j)A be an arc for which condition (2.1) is not satisfied, then adjust the vector
f by setting f j = f i + cij , and update the tree T replacing the current arc incident into node j
by the new arc (i,j).
Step 3: Repeat Step 2 until condition (3.1) is satisfied for all (i, j)A.

The important point in the implementation of this procedure is how to select an arc at Step 2 in
order to check whether condition (2.1) is satisfied. Since n < m (n = |N|, and m = |A|), it seems
reasonable to sele ct nodes rather than arcs. Once a node i is selected, condition (3.1) is checked
on one or more (possibly all) arcs of forward stars of i, FS(i). (In the majority of the algorithms,
all the arcs corresponding to the selected nodes forward stars are checked once.) A general
implementation of procedure for node-based LC SP algorithms is as follows:
Step 1: (Initialize) f s = 0, predecessor(s)=0; f i = for each i N-{s}; Q = {s};
Step 2: (Select and update)
Select i Q; Q = Q - {i};
For each (i,j), j FS(i) such that f j >f i + cij , do
f j = f i + cij ;
predecessor(j) = i;
Q = Q + {j};
Step 3: (Iteration) if Q then go to Step 2, else stop.
where, Q: a set of candidates nodes (or a list of scan eligible (SE)).
The initial tree at Step 1 is a star-shaped tree, with one dummy arc (s,i) for each iN-{s}. These
dummy arcs are assigned a length equal to . It is very important how to select the node i from
the set of candidate nodes Q. In fact, almost all the practical shortest path algorithms are derived
by properly defining the rule of selection and the particular data structure which is used to
implement the set Q. Theoretically speaking, the time for node selection is bounded by O(n 2 ) and
the time for distance updates is bounded by O(m). If the network is sparse (i.e., n 2 >> m), then the
former time dominates the later. So, we need to reduce the node selection time without
substantially increasing the time for updating the distances.
Figure 2.17 shows several types of data structures relevant to the selection schemes. Internal
operations for each type of Queue is summarized in Table 2.7. A sorted queue is used for the LS
SP algorithm in which a sorting method is imbedded so that the node having the least label can be
selected from the set of candidate nodes. However, it should be noted that if the problem size is
large, the sorting algorithm is not inexpensive in terms of computational cost.

59

a) Stack

[x 1, x2 , ...., x n]
sorted cotents

b) Sorted queue
(Dijkstra algorithm)

[x 1, x2 , ...., x n]

[x1 , x2, ...., x n]

c) FIFO queue

[x 1, x2, ...., x n]

d) Output-restricted
double-ended queue

e) Double-ended queue

[x 1, x2, ...., x n]

Figure 2.17 Types of Queues for Node Selection Schemes [reproduced from Tarjan, 1983].
To revise this drawback, the so called double-ended queue (DEQueue, see Figure 2.17 (d)) has
been developed, which combines the properties of both the queue and the stack. In the DEQueue
structure, the first time a node is to be inserted into the tail of the queue. When, later on, the same
node again becomes a candidate node after being removed from the queue, it is inserted at the
head of the queue.

Table 2.7

enqueueFirst (=push)

Operations for Various Queue Types.

Sorted
Queue

FIFO
Queue

Output-restricted
double-ended Queue

Double-ended
Queue

enqueueLast (=inject)
dequeueFirst (=pop)
dequeueLast (=eject)
SortContents

60

On the other hand, the candidate nodes are always removed from the head of the queue. The
rationale for using the DEQueue is that every time f j is updated, except the first time, it is worth
trying to decrease the labels of the successors of j in current tree. Table 2.8 summarizes the
details of LC algorithms according to the data structures employed. Maintaining the DEQueue to
handle the candidate nodes, Ziliakopoulos and Mahmassani (1993) devise the time-dependent
shortest path algorithm. Figure 2.18 presents the pseudo code for this algorithm.

61

Call CREATE;
Call INSERT(N);
Current_Node = N; // to-node i
Do 1, While (SE list is not empty)
Call DELETE(Current_Node);
Do 2, for (All nodes J that can be directly reach Current_Node)
// J is the reverse star of node i
Next_Node = J;
In_SE_List? = No;
Do 3, for(t=1,M)
//Travel Time (j,i) starting at t
Current_Travel_Time = TRAVEL_TIME(Next_Node, Current_Node, t);
// TT(j,N) at t = TT(i,N) at (t+TT (j,i)) + TT(i,N) at t
New_Label = Label(Current_Node, t+Current_Travel_Time)
+ Current_Travel_Time;
If( Label(Next_Node,t) New_Label ) then
Label(Next_Node, t) = New_Label;
In_SE_List? = Yes;
Path_Pointer(Next_Node, t, 1) = Current_Node;
Path_Pointer(Next_Node, t , 2) = t + Current_travel_Time;
Endif
3

Continue

If (In_SE_List? = Yes) Call INSERT(Next_Node);

2
Continue
1 Continue
Procedure CREATE
Do, for(Node=1,N-1), Deque(Node) = 0;
Deque(N) = 999999;
First = N;
Last = N;
Procedure INSERT(Node)
If(Deque(Node) = 0) then
Deque(Last) = Node;
Last = Node;
Deque(Node) = 999999;
Else if (Deque(Node) = -1) then
Deque(Node) = First;
First = Node;
Endif
Procedure DELETE(Current_Node)
Current_Node = First;
First = Deque(Current_Node);
Deque(Current_Node) ;

Figure 2.18 Pseudo Code for a Time-dependent SP Algorithm

[Adapted from Ziliakopoulos and Mahmassani, 1993].

62

Table 2.8

Generic LC Algorithm
(Arc-based Selection)

Comparison of Data Structures for LC Algorithms.

Modified LC Algorithm
(Node-based Selection)
Using FIFO Queue

Rationale: number of nodes << number of arcs.

f s = 0, pred(s)=0;
f j = for each j N-{s};

f s = 0, pred(s)=0;
f j = for each j N-{s};
FIFOQueue={s}

Using Double Ended Queue

Rationale: Every time f j is updated, except the first
time, it is worth trying to decrease the labels of the
successors of j in current tree.
f s = 0, pred(s)=0;
f j = for each j N-{s};
DEQueue={s}

while some arc(i,j) satisfies f j > f i + cij do

f j = f i + cij ;
While FIFOQueue {} do
While DEQueue {} do
pred(j) = i;
Remove i from the head of FIFOQueue;
Remove i from the head of DEQueue;
end
For any (i,j), j FS(i) do
For any (i,j), j FS(i) do
If f j > f i + cij then{
If f j > f i + cij then{
f j = f i + cij ;
if jFIFOQueue{
pred(j) = i;
if f j = then
if jFIFOQueue
insert j into the tail of DEQueue;
then add node i to the tail of FIFOQueue;
else insert j into the head of DEQueue;
}
}
end
f j = f i + cij ;
end
pred(j) = i;
}
end
end

63

2.3 Literature Review on Simulation Model

2.3.1

Types of Simulation Models

Simulation models can be classified according to the following general categories [Lieberman
and Rathi, 1992]:
Discrete and continuous simulation models,
Microscopic, mesoscopic, and macroscopic simulation models, and
Deterministic and stochastic simulation models.
Discrete simulation models represent a system by asserting that the states of the system elements
change abruptly at points in time. In contrast, continuous simulation models represent the system
by changing state variables continuously over time [Law and Kelton, 1991]. Typically,
continuous simulation models involve differential equations giving relationships for the rates of
change of the state variables with time. If the differential equation is simple enough to be solved
analytically, the solution provides the values of the state variables at any given time as a function
of the values of the state variables at time zero. Because continuous models frequently are not
tractable using an analytical approach, numerical analysis techniques, e.g., Runge-Kutta
integration, are used to integrate the differential equations. For this reason, regardless of the
nature of the real system which might be either discrete or continuous, two types of discrete
simulation models are applied in practice: 1) discrete time simulation and 2) discrete event
simulation models. For systems of limited size entities whose states change infrequently, discrete
event simulation models are more appropriate in the sense of computational execution time.
However, for systems where most entities experience a continuous change in state and where the
model objectives require very detailed descriptions, discrete time models are likely to be the
better choice [Lieberman and Rathi, 1992].
Traffic simulation models may be classified according to the level of detail with which they
represent the system to be studied: 1) Microscopic, 2) Mesoscopic and 3) Macroscopic. A
microscopic model deals with both system entities and their interactions at a high level of detail.
A mesoscopic model generally represents entities at a higher level of detail but describes their
activities and interactions at a much lower level of detail. On the other hand, a macroscopic
model describes entities and their activities at a low level of detail. In a mesoscopic model, for
example, the lane-changing maneuver could be represented for individual vehicles as an
64

instantaneous event with the decision based on the relative lane densities, rather than on detailed
vehicle interactions. In macroscopic models, however, the traffic stream may be represented in
some aggregate manner such as speed, flow, and density, and lane change maneuvers would
probably not be represented.
In deterministic models, there are no random variables. In other words, all interactions between
entities are fixed in the sense that relationships are defined by mathematical, statistical or logical
equations. Stochastic models involve processes which include probability functions. The carfollowing model, for instance, may be modeled either as a deterministic or a stochastic problem
by defining the drivers reaction time as a constant estimated value or as a random variable,
respectively.

2.3.2

Previous Air Traffic Simulation Models

Since the early seventies, the FAA has developed computer simulation models to analyze airport
operations. Contrasting with the analytic models which consist of a series of equations using
fixed input parameters, most aviation and airport simulation models are discrete event, stochastic
models which emulate the movements of aircraft on the airfield as well as in the airspace. In
general, the simulation models produce the following statistics:

Hourly runway, taxiway, and gate capacity

Hourly and daily delays, travel times, flow rates, and queueing data etc.

Annual delay and annual delay costs

Annual delay savings computed from annual delay costs

ADSIM (Airfield Delay Simulation Model, 1976)

ADSIM is a microscopic, discrete event, stochastic simulation model, and known as one of the
most detailed models to evaluate the operations and sources of delay on the airport's surface
http://www.tc.faa.gov/act500/capacity/modelsq.htm]. ADSIM simulates the movement of aircraft
on the airport surface and in the immediate airspace. An airport is composed of a common
approach and departure corridors. The principal inputs to the model include aircraft routings,
runway and taxiway usage, runway occupancy times and exit probabilities, aircraft approach and
taxiing velocities, aircraft separations, gate service times, aircraft demand and mix, and ATC
rules and procedures. Outputs of the model are hourly arrival and departure flow rates, travel
times, and arrival and departure delays for each runway. Also provided are total delays for each
65

link on the airfield, departure queue lengths, and individual aircraft delays. ADSIM has a
capability to represent the movements in animation mode.
RDSIM (Runway Delay Simulation Model)
Developed mainly for runway capacity and delay analyses, RDSIM simulates operations on
runways and generates information on both capacities and delays [http://www.tc.faa.gov/
act500/capacity/modelsq.htm]. This model is a discrete event, stochastic simulation model.
During the simulation, it is assumed that arrival and departure demands are uniformly distributed.
The model simulates runway operations with arrival-priority, departure-priority, or balanced
arrivals and departures. This model can be used to compute runway capacity at an acceptable
level of delay and maximum runway throughput. Compared with ADSIM, RDSIM requires less
detailed inputs and less computational effort. The inputs consist of runway usage, runway
occupancy times, exit probabilities, aircraft demand and mix, aircraft approach velocities, aircraft
separations, and ATC rules and procedures. The outputs include delay statistics with graphics
showing delay versus demand along with other operational details.
SIMMOD (The airspace and airfield model)
SIMMOD is the first model to analyze the complex airspace interactions between airports.
SIMMOD satisfies the need to analyze delays, capacity and fuel consumption resulting from
changes in airspace utilization and operational procedures beyond an airport's immediate airspace
[SIMMOD3 Simulation Module, 1993]. In SIMMOD, each aircraft's movement is traced
individually and ATC required the actions for aircraft operations are also simulated. Inputs for
SIMMOD are traffic demand and fleet mix, route structures (both in the airspace and on the
airport surface), runway use configurations, separation rules and control procedures, aircraft
performance characteristics in airspace and airfield links, airspace sectorization, interactions
among multiple airports, and weather conditions. SIMMOD uses a link-node structure to
represent the gate/taxiway and runway/airspace route system. Input parameters depending on
aircraft type include the permissible airborne speed ranges for use by ATC, runway occupancy
times, safety separations, landing roll and takeoff characteristics, taxi speeds, and runway/taxiway
utilization. Gate utilization depends on aircraft type and airline. The output from SIMMOD
reports statistics about individual aircraft delay, travel time, and fuel consumption as well. A
simulation log containing information on various simulated events are also generated at the users
request.

66

2.3.3

Aircraft-Following Models

If there is more than one aircraft moving on the same taxiing path and the vehicles are close
enough to interact with each other, the leading aircraft behavior affects the following aircraft. To
represent this situation, aircraft-following models are introduced. The main concepts governing
aircraft-following models are borrowed from well-researched issues in transportation studies
concerning car-following models. There are several types of car-following models readily
applicable to simulation practices. It should be noticed that there is an m
i portant assumption
about the speed-acceleration relation applied to all types of vehicle -following models. In this
analysis, the vehicles ability to accelerate is assumed to decreases linearly as a function of speed.
Distance-controlled vehicle -following model: The distance-controlled logic for vehicle following models is based on the assumption that the acceleration of the following vehicle at time
t+t is decided by the distance between the leading and the following vehicle. The acceleration
for the following vehicle is decided by the equation given below (Starfield, 1990).

&x&nt ++1 t = k [( x tn x nt +1 ) D] ,
t + t
t + t
t + t
t + t
if x&&n +1 > &x&max then x&&n +1 = &x&max , and if x&&n +1 < &x&min then x&&n +1 = &x&min ,
t +t
where, x&&n +1 : acceleration for aircraft n+1 at time t+t,

( x tn x tn +1 ) : distance between aircraft n and n+1 at time t,

k = design parameter,
D = safety distance.
Speed-controlled vehicle -following model: In the speed-controlled logic, the acceleration of the
following vehicle at time t+t is modeled by the speed difference between the leading and the
following vehicle. Mathematically this can be expressed as,
x&&tn++1 t = k ( x& tn x&tn +1 ) ,
t + t
t + t
t + t
t + t
if x&&n +1 > &x&max then x&&n +1 = &x&max , and if x&&n +1 < &x&min then x&&n +1 = &x&min ,
t + t
where, x&&n +1 : acceleration for aircraft n+1 at time t+t,

( x tn x tn +1 ) : speed difference aircraft vehicle n and n+1 at time t,

k = design parameter.

67

Generalized vehicle -following model: The generalized car-following model proposed by Gazis
et al. (1961) assumes that the acceleration of the following vehicle at time t+t is influenced by
three dependent variables: the differences in both distance and the speed between the leading and
the following vehicles, and following vehicles speed. The generalized car-following model can
be expressed as follows:
&x&tn++1 t =

( x&tn++1 t ) m
( x&tn x&nt +1 ) ,
t
t
l
( xn xn +1 )

(2.2)

t + t
t + t
t + t
t + t
if x&&n +1 > &x&max then x&&n +1 = &x&max , and if x&&n +1 < &x&min then x&&n +1 = &x&min ,

where, , m, l: design parameters.

It should be noted that by integrating the equation (2.2) and applying the boundary conditions at
the steady state, the generalized vehicle -following model can be related to the traffic stream
model. Also, the resulting macroscopic models are diverse depending on the values of l and m.
For example, in the case that l =0, m =0, which is the speed-controlled car-following model, the
resulting macroscopic model is q = (1 - k/k j ), = qm , where q = flow, k = density, k j = jam
density and q m = maximum flow. The various macroscopic models are shown in Table 2.9.

2.3.4

Data Structures for Network Representation

The performance of a network algorithm depends not only on the algorithm itself, but also on the
manner used to represent the network within a computer. By representing a network more
cleverly and by using improved data and list structures, we can often improve the running time of
an algorithm [Ahuja et al., 1993].
Table 2.9

Macroscopic Models from Vehicle -following Models (Gerlough and Huber, 1975).
m=0

l=0

q = (1 - k/k j )

q = k ln(k j /k )

*iii)

3/2

q = (1 (k/k j )

1/2

q = k (1 - k/k j ) *vi)

*i)

*v)

m=1
= qm

*ii)

= um

*iv)

= uf
= uf
-

*i)

q = k e (k/k0) *vii)

= u f, k 0= k m

q = k e (k/k0) ( k/k 0 ) *viii)

= qm

Chandler, Herman, and Montroll (1958), *ii) Pipes (1953), *iii) Greenberg (1959)
*iv)
Gazis (1961), *v) Drew (1965), *vi) Greenshiled (1934), *vii) Edie (1961)
*viii)
Drake, Schoefer, and May (1961)

68

In representing a network, we need to store two types of information: (1) the network topology;
that is, the networks node and arc structures, and (2) attribute data such as costs (Cij ) and
capacities associated with arcs. There are several ways to represent a weighted graph G=(N,A),
|N|=n, |A|=m. Various graph representation methods including their advantages and disadvantages
are reviewed with a simple network shown in Figure 2.19.

4
1

2
3
3

C ij

2
1
4

5
2

Figure 2.19 An Example Graph with 5 Nodes and 9 Arcs (i.e., n=5, m=9).
(Node -Arc) Incident matrix: Construct an nm matrix which contains one row for each node
and one column for each arc. The column corresponding to each arc (i,j) has only two non-zero
elements: It has a +1 in the row corresponding to node i and a -1 in the row corresponding to
node j (see the Figure 2.20). Separate nm matrices should be generated for data storage.
Advantages: An incident matrix can be used as a constraint matrix of the minimum cost flow
problem. This matrix possesses several important theoretical properties such as total
unimodularity, etc. (see Bazaraa et al. (1990) for details).
Disadvantages: The incident matrix which has (nm-2m) zeros is inefficient in storage space.

node \ arc (1,2) (1,3) ( 2,1) (2,3) (4,1) (4,5) (5,2) (5,3) (5,4)
1
2
3
4
5

1
-1

0
0

1
0
1
0
0

1
1
0
0
0

0
1
-1
0
0

-1
0
0
1
0

0
0
0
1
-1

0
-1
0
0
1

0
0
-1
0
1

Figure 2.20 Node-Arc Incident Matrix for the Example Network.

69

0
0
0
-1
1

Node -node adjacency matrix: Construct an nn matrix which has a row and column
corresponding to every node. The ij th entry of the matrix equals 1 if arc (i,j)A and equals 0
otherwise.
Advantages: This matrix is space efficient if the network is sufficiently dense and the simplicity
of the matrix allows us to implement the network algorithm easily.
Disadvantages: Needs another nn matrix for data representation. An identification of
outgoing/emanating arcs of a node is in time proportional to n. In sparse networks this may
be a bottleneck operation for an algorithm.

from node \ to node 1 2 3 4 5

0

1
0

1
0

1
2
3
4
5

1
0
0
0
1

1
1
0
0
1

0
0
0
0
1

0
0
0

1
0

Figure 2.21 Node-Node Adjacency Matrix for the Example Network.

Adjacency lists: The arc adjacency list A(i) of a node i is defined as the set of arcs emanating
from that node, that is, the set of arcs (i,j) A obtained as j ranges over the nodes of the network.
Similarly, the node adjacency list of node i is defined as the set of nodes j for which (i,j) A. The
adjacency list representation stores the node adjacency list of each node as a singly linked list. To
implement this list, n linked lists, one for each node, should be generated. Array pointers that
point to the first cell of each linked list, pt(i), are also constructed.
Advantages : Adjacency list representations are relatively efficient in storage. Deletion and
addition of nodes can be done in constant time.
pt(i)

cij

pt

NULL

NULL

NULL

NULL

5(=n)

Figure 2.22 Adjacency List Representations for the Example Network.

70

NULL

Forward/reverse star representation: The forward star representation of a network is similar to

the adjacency list representation in the sense that it also stores the node adjacency list for each
node. However, instead of maintaining these lists as linked lists, it stores them in several arrays:
tail(.), head(.), and cost(.). Pointers pointing to the first element of the corresponding arc list are
stored in the pointer array pt(.). By convention: a) if the forward star of a node i is empty pt(i) =
pt(i+1); b) pt(n+1) = m+1. Thus, information related to the emanating arcs (i.e., forward star) of a
node i is stored in tail(.), head(.) and cost(.) from position pt(i) to pt(i+1)-1.
Advantages: This representation is more space efficient than the adjacency list representations
and can be applied in general computer languages like FORTRAN.
Disadvantages: Addition/deletion of a node requires time proportional to m which can be time
consuming.
i 1)
1
2
3
4
5
6

1)

Pt(i)
1
3
5
5
7
10

2)

corr. arcs
tail
head
Cost
1
1
2
3
2
1
3
4
3
2
1
3
4
2
3
6
5
4
1
5
6
4
5
1
7
5
2
7
8
5
3
2
9
5
4
2
i is the from nodes, the pointer array contains pointers to the first elements of the corresponding arc lists.

Figure 2.23 Forward Star Representation for the Example Network.

71

Chapter 3. Model Development for ASP

3.1 Assumptions for Ready-times
In order to obtain a sequence from ASP, we need to make some assumptions regarding the
departing aircraft ready-times. In fact, there are two types of ready-times: the ready-time to
pushback from a gate, and the ready-time for takeoff on the runway. The first one is the time
when the aircraft completes its boarding process, and waits for taxiing-out instructions from a
ground (or a ramp) controller. Initially, this time can be obtained from the flight schedule.
However, as airport operations progress over time, flight delays appear and new ready-times can
be obtained from the airline operations center.
The second ready-time is the instance at which the aircraft can begin the takeoff roll on the
runway. The earliest ready-time for takeoff (or so called "nominal takeoff time") is estimated as
the ready-time to pushback from the gate plus the taxiing time from the gate to the runway
departure queue. In our formulation, the ready-times to takeoff, ri , are used as one set of the input
data to solve the ASP problem.
One interesting aspect of the problem is that once we have the takeoff times as prescribed by
ASP, we can suggest pushback times from the gates in a manner that reduces congestion both on
the taxiway network and around departure queues. The recommended push-back times can be
computed as depicted in Figure 3.1. Mathematically, the relationship between ready-time
instances for a departing aircraft within the time horizon is given by,
Recommended pushback time from the gate
= Optimal takeoff time (Taxiing time + Buffer time).
(Here, buffer time includes expected communication time and estimated waiting time in
the departure queue.)
As seen in Figure 3.1, we can make different uses of the taxiing time (T), depending on the type
of computation being performed. T1 is the taxiing time interval that estimates the earliest takeoff
ready-time (ri ) required for ASP. Initially, this time can be obtained from historical data. (This
data can be found in the Consolidated Operations and Delay Analysis System (CODAS) database
which includes estimated taxiing times on ground networks at busy airports.) On the other hand,
T2 is the actual taxiing time to reach the takeoff ready-time from the recommended pushback time
72

(rpbi ). This time can be obtained from a Network Assignment Problem (NAP) which computes
the optimal route and taxiing time for each aircraft after model ASP prescribes the optimal
takeoff times (ti ).

WTAGi
Time

ROTd
T1

T2

rgi

ri

rpbi

B
ti

tofi

Where,

rgi : ready-time at gate

ri : earliest ready-time to takeoff
rpbi : recommended ready-time to push-back
ti : optimal time for takeoff
tofi : finishing time for takeoff
T1 : regular taxiing time from the gate to the departure queue
T2 : taxiing time to obtain the recommend push-back time
B : buffer time (i.e., waiting time in departure queue)
ROTd : runway occupancy time
WTAGi : waiting time at gate.

Figure 3.1

Time Relationships for the Departing Aircraft.

73

3.2 First-come-first-serve (FCFS) Approaches

When air traffic controllers in the control tower direct landing and departing aircraft, they
generally use a first-come-first-serve (FCFS) strategy, giving priority to landing aircraft. This
strategy provides a sequencing of the aircraft along with completion times, total delays, and so
on. This solution can be used to compare the performance of manual (FCFS) and optimal
sequencing methods.
To consider both arrival and departure operations simultaneously, minimum separation rules
should be defined for all possible aircraft group combinations. Table 3.1 shows the minimum
separation rules for all the cases considered in our analysis.

Table 3.1

Minimum Separation (seconds).

departure departure case.

Leading \ Following
Heavy
Large
Small

Heavy
60
60
60

Large
90
60
60

Small
120
90
60

Large
53
53
53

Small
65
65
65

departure arrival case.

Leading \ Following
Heavy
Large
Small

Heavy
50
50
50

arrival departure case.

Leading \ Following
Heavy
Large
Small

Heavy
40
35
30

Large
40
35
30

Small
40
35
30

arrival arrival case.

Leading \ Following
Heavy
Large
Small

Heavy
99
74
74

Large
133
107
80

Small
196
131
98

The runway occupancy time (ROT) is computed for every operation in order to assess the
processing times. ROT is defined as the time between the instance when an aircraft crosses the

74

runway threshold and the instance when the same aircraft clears the imaginary plane of the
runway at a turnoff. These times are specified in Table 3.2.

Table 3.2

Runway Occupancy Times (seconds).

Operation \ Aircraft Type

Arriving
Departing

Heavy
40
50

Large
35
40

Small
30
30

Using the foregoing data set, the FCFS sequence delays can be calculated for all aircraft
operations. An illustrative example using a randomly generated flight schedule is shown in Table
3.3. In this example, a due-time is obtained by adding a maximum delay of 600 seconds to all
ready-times.
Table 3.3

Aircraft Schedule (Randomly Generated).

Max Delay: 600 (seconds)
Arrival

Order

Flight
ID

Aircraft
Type

1
2
3
4
5
6
7
8
9
10

A1
A2
A3
A4
A5
A6
A7
A8
A9
A10

S
L
L
L
H
H
L
L
L
L

Departure

Nominal
Touchdown Time
Ready
98
164
205
268
494
550
643
834
962
973

Due
698
764
805
868
1094
1150
1243
1434
1562
1573

Flight
ID

Aircraft
Type

D1
D2
D3
D4
D5
D6
D7
D8
D9
D10

H
H
L
H
S
S
L
L
S
H

Nominal
Takeoff Roll
Time
Ready
Due
32
632
364
964
409
1009
542
1142
571
1171
643
1243
744
1344
881
1481
955
1555
996
1596

In FCFS with a full landing priority strategy, arriving aircraft should not be delayed by departing
flights. In other words, the arriving aircraft can be delayed only to resolve arrival conflicts. The
first step for FCFS sequencing is to obtain the arrival times by checking if there is any conflicting
arrival. The following steps show how to calculate the times for arrivals to cross runway
threshold, considering the minimum separation rules between two consecutive landing aircraft in
the FCFS sequence.
fcfs touchdown time for 1st landing aircraft = nominal ready-time for 1st landing aircraft
75

for i = 2 to (total number of arriving aircraft)

if [ (fcfs touchdown time for (i-1)th aircraft + minimum separation time between the
(i-1)th and ith aircraft ) > nominal ready-time of ith aircraft ]
fcfs touchdown time for ith aircraft =
fcfs touchdown time for (i-1)th aircraft
+ min. separation time between the (i-1)th and ith aircraft
else
fcfs touchdown time for ith aircraft =
nominal ready-time for ith aircraft
end
The resulting schedule for arrivals is shown in Table 3.4.
Table 3.4

First-come-first-serve Sequence for Landing Aircraft.

Order

Flight
Number

Aircraft
Type

1
2
3
4
5
6
7
8
9
10

A1
A2
A3
A4
A5
A6
A7
A8
A9
A10

S
L
L
L
H
H
L
L
L
L

Arrival
Nominal
Touchdown
Time
Ready
Due
98
698
164
764
205
805
268
868
494
1094
550
1150
643
1243
834
1434
962
1562
973
1573

FCFS
Touchdown
Time
98
178
285
392
523
621
701
834
962
1069

If the inter-arrival time between two consecutive aircraft is sufficient for one or more departures,
these are scheduled. Otherwise, departing aircraft are delayed until a slot having a sufficient time
to allow a departure is found. Table 3.5 presents the final result of the FCFS sequence with
landing priority.

76

Table 3.5

First-come-first-serve 1) Sequence (with Landing Priority).

(Seconds)
Arrival

Seq

FLT
No.

Acft
Type

Departure
Seq

FLT
No.

Acft
Type

S_T

ROT

C_T

D1

32

40

72

D2

432

40

472

68

10

D3

736

35

771

327

12

D4

874

40

914

332

14

D5

992

30

1022

421

16
D6
S
1109
17
D7
L
1164
18
D8
L
1224
19
D9
S
1319
20 D10
H
1369
Total Delay: 3586 (sec), Completion Time: 1408 (Sec.)

30
35
35
30
40

1139
1199
1259
1349
1409

466
420
343
364
373

S_T 2)

ROT 3)

C_T

4)

Delay 5)

2
3
4
5

A1
A2
A3
A4

S
L
L
L

98
178
285
392

30
40
40
40

128
218
325
432

0
14
80
124

7
8
9

A5
A6
A7

H
H
L

523
621
701

30
30
40

553
651
741

29
71
58

11

A8

834

40

874

13

A9

962

40

1002

15

A10

1069

40

1109

96

1)

Delay

In FCFS with landing priority, the landing aircraft should not be delayed later than its FCFS readytime.
2)
S_T: Starting time
3)
ROT: Runway Occupancy Time
4)
C_T: Completion Time
5)
Delay = FCFS operation time Nominal Ready-time.

77

3.3 Integer Programming Approaches

3.3.1

Formulation

Starting with known preliminary information about the aircraft such as aircraft types, nominal
arrival/departure times, maximum delay times, minimum separation rules, etc., the problem can
be formulated as a combinatorial optimization problem. The following is a mixed-integer
programming model for a single runway or closely spaced runways where arrivals and departures
are dependent.
Minimize z
subject to
ti +

p x

i J

(3.1)

ri ti 0

i J

(3.2)

ti d i 0

i J

(3.3)

t j ti + pij -(1-xij )(d i -r j + p ij )

i J 0 , j J 0, j i

(3.4)

ij ij

j i
jJ 0

ij

=1

i J0

(3.5)

ij

=1

j J0

(3.6)

i J 0 , j J 0, j i

(3.7)

j i
jJ 0

i j
iJ 0

xij + x ji 1
t0 = 0 , ti 0

iJ

(3.8)

xij {0,1}

i J 0 , j J 0, j i

(3.9)

where,
J ={1,,n}

: A set of n aircraft operating (i.e., landing or departing) on a single runway

J 0 = J {0} : Aircraft 0 is an imaginary aircraft which has 0 ready-time (i.e., r0 =0)

and 0 due-time (i.e., d 0 =0)

xij
x 0i
xi 0
ti

: 1 if aircraft i directly precedes aircraft j, and 0 otherwise

: 1, if aircraft i is the first in the sequence, and 0 otherwise
: 1, if aircraft i is the last in the sequence, and 0 otherwise
: the start time of aircraft i (i.e., time for touchdown or takeoff)
78

di
ri

pij

: the due-time for aircraft i

: the ready-time for aircraft i,
: p i0 = runway occupancy time of aircraft i (i.e., ROTi ) for i J .
p 0j = setup time for the first aircraft j.
else if ij, i0, j0, then p ij = minimum separation time between the
leading aircraft i and the following aircraft j.
if i=j, pij =0.

Constraint (3.1) states that the objective function value is no less than the last aircraft's
completion time. Ready and due-times constraints are considered in constraints (3.2) and (3.3).
The minimum separation rules are enforced by constraint (3.4). Two types of assignment
constraints are represented by (3.5) and (3.6). Constraint (3.7) is a (two-city) sub-tour elimination
constraint which prevents the resulting sequence from having any sub-tour consisting of two
cities. (Constraints (3.4) serve as the full set of Miller-Tucker-Zemlin subtour elimination
constraints.) Constraint (3.8) represents the non-negativity requirement for each aircraft's start
time for each aircraft. Constraint (3.9) restricts the sequencing variables to take the value of 0 or
1.
As imbedded component of the ASP model is a Traveling Salesman Problem with time-windows
which renders the problem NP-Hard. A tighter formulation that yields improved lower bounds is
designed in the sequel using the Reformulation-Linearization Technique (RLT) of Sherali and
Adams (1990, 1994) and Sherali et al. (1998).

3.3.2

Valid Inequalities

As a preliminary, we first develop a tighter lower bound LB(j) on the conditional start time of
aircraft js operation, given that it is last in the sequence.
Proposition 1. The maximum of the following three components can be used as a lower bound
on the start time of aircraft js operation, given that it is last in the sequence.
LB( j ) =
max{r j , max[ri + min pik ],
iJ
kJ
i j
k i
min [r + p + min p + min p + sum of (n-3) smallest from thearray min p for m J, m i,j ]}
0i k J ik t J tj
mn
i J i
nJ
i j
k i,j
t i,j
n i,j, m

79

Proof. The first term in LB(j), merely states that the start time of aircraft j should be greater than
its ready-time (rj ). For the second term, since

ri + min pik
kJ

represents the earliest completion time

of aircraft i regardless of the next aircraft, this term asserts that the last aircraft j should begin
later than any other aircrafts earliest completion time. For the third term, if we assume that any
particular aircraft ij is the first in the sequence, then the earliest start time of the la st aircraft j is
greater than or equal to the minimum of the total sum of processing times for all aircraft
following i. This lower bound is given by the sum of the following events:

(i) the start time of the first aircraft i,

ri + p 0 i

(ii) the minimum separation time between the first two aircraft, min

k J
k i,j

(iii) the minimum separation time between the last two aircraft, min

t J
t i,j

pik

ptj

(iv) the minimum of the remaining (n-3) separation times from the array of min

n J
n i,j ,m

p mn

for

mJ, mi,j.

Taking the smallest of this sum (i)-(iv) over iJ, ij yields a valid value for LB(j). This completes
the proof.
A set of valid inequalities to replace constraints (3.4) can be generated as in (3.4.1) and (3.4.2) of
Proposition 2 and 3 below, in order to achieve tighter lower bounds on the problem.
Proposition 2 (Valid Inequality I for Constraint (3.4)). For i = 0 , j J , the following
inequality is valid and tighter than the corresponding constraint (3.4).
t j max{rj , p0 j } - (1-x0 j ) max{0 , p0 j -rj } + x j 0 [ LB ( j )-rj ]

j J

(3.4.1)

where, LB(j) rj is a lower bound on the start time for the aircraft j, given that it is the last aircraft
in the sequence (see Proposition 1).
Proof. When x0 j = 1 , we have x j 0 = 0 and then t j max{r j , p0 j } is valid. When x0 j = 0 and
x j 0 = 0 , regardless of the values of p0 j and rj , t j max{r j , p0 j } max{0 , p0 j -rj } is valid,
since the resulting inequality is always t j rj . When x0 j = 0 and x j0 = 1 , aircraft j is last in the
sequence. From above, the inequality (3.4.1) reduces to tj rj + [LB(j) rj ] which imposes the
80

valid inequality tj LB(j). Moreover, noting that for i = 0, (3.4) is tj p 0j (1- x0j )(p 0j - rj ) = rj +
x0j (p 0j - rj ) while (3.4.1) implies via its first two terms that tj rj + x0j max{0, p 0j - rj }, we have that
(3.4.1) dominates (3.4) in the continuous sense. This completes the proof.
Proposition 3 ( Valid Inequality II for Constraint (3.4) ) For i,j J,i j , the following
inequality is valid and tighter than the corresponding constraint (3.4).
t j ti + p ij -(1-xij )(d i -rj + pij ) + x ji

i,j J,i j

(3.4.2)

where, = max[ 0,di rj max{ p ji ,ri rj }] .

Proof. When xij = 1 , we have x ji = 0 and then t j ti + pij is valid. When xij = 0 and x ji = 0 ,
then (3.4.2) is again valid since (tj -rj ) 0 (ti -d i ). Finally to make (3.4.2) valid whenever xij = 0
and x ji = 1 , 0 should be chosen so that ti t j d i rj is true under this condition. Note
that

when

x ji = 1 ,

we

have

t i = max{t j + p ji ,ri }

and

therefore

(ti t j ) = max{ p ji ,ri t j } max{ p ji ,ri r j } . Hence, for (3.4.2) to be valid, we can set
d i r j = max{ p ji ,ri r j }

and

since

0,

we

can

compute

= max[ 0,di rj max{ p ji ,ri rj }] . Moreover, because of the additional nonnegative term xji ,
(3.4.2) is tighter than (3.4) in the continuous sense. This completes the proof.

3.3.3

Enhanced Model Representation via an Application of RLT

1) Reformulation Phase
Using xij 2 =xij , xij xik=0 jk, xij xkj=0 ik, and xij xji = 0 i J 0 , j J 0 , k J 0 , we can construct
additional sets of constraints via (R1)-(R5) stated below.
(R1) Multiply the assignment constraint (3.5) for each i J by its corresponding ti . Similarly,
multiply the assignment constraint (3.6) for each j J by its corresponding tj . Note that
constraints resulting from multiplying (3.2) and (3.3) by these assignment constraints (3.5)
and (3.6) are then redundant.

ti xij
jJ 0 ,j i

= ti

iJ

81

(R1.1)

t j xij
iJ 0 ,i j

=t j

j J

(R1.2)

(R2) Multiply the inequality constraints (3.2) and (3.3) by the bound-factors xij 0 and x ji 0
for

i,j J

Multiplication by xij 0 :
(t j r j ) xij 0

i J, j J, i j

(R2.1)

(d j t j ) xij 0

i J, j J, i j .

(R2.2)

(t j r j ) x ji 0

i J, j J, i j

(R2.3)

(d j t j ) x ji 0

i J, j J, i j .

(R2.4)

Multiplication by x ji 0 :

Note that we can tighten the constraints (R2.1) and (R2.4), by using conditional logic as
follows, noting that the factors multiplied by the variable s xij and xji , respectively, are
relevant only when these variables take on a value of 1.
[t j max{ r j ,ri + p ij }] xij 0

i J, j J, i j

(R2.1)

[min{d j ,d i p ji } t j ] x ji 0

i J, j J, i j .

(R2.4)

If we consider similar products with x0j and xj0 , we can tighten these constraints further.
(t j rj ) x0 j = 0

j J

(R2.5)

(t j LB( j)) x j 0 0

j J

(R2.6)

( d j t j ) x j0 0

j J

(R2.7)

Remark 1: In (R2.6), rj has been validly replaced by any lower bound LB(j) on the start
time for aircraft js operation, given that j is the last aircraft. For this lower bound, we can
82

use any reasonable conditional completion time which can be computed with relative ease.
Also, note that (R2.5) is written as an equality since either x0j = 0, or if x0j = 1, then we can
begin the first aircraft js operation at tj = rj . Furthermore, because of this, the constraint (d j tj ) x0j 0 is redundant and has hence been omitted.
(R3) Multiply constraints (3.2), (3.3) by two-aircraft subtour elimination constraint,
(1 xij x ji ) 0 .

(t j r j )(1 xij x ji ) 0

i J, j J, i j

(R3.1)

(d j t j )(1 xij x ji ) 0

i J, j J, i j .

(R3.2)

Also, we can write similar constraints for the 0-index, while tightening these further using
logical tests. Noting that the following are relevant only under the condition x0j = xj0 = 0 (else
the left-hand-side is zero below), we can tighten the bounds rj and d j on tj to derive the
following valid product constraints.
(1-x 0 j -x j 0 )[t j max{ rj ,min ( ri + pij )}] 0

j J

(R3.1)

(1-x 0 j -x j 0 )[min {d j , max(d i p ji )} t j ] 0

j J .

(R3.2)

iJ
i j

i J
i j

(R4) Multiply (3.4.1) by the bound factors x0 j 0 , x j0 0 and the two-aircraft subtour
elimination constraint (1 x0 j x j 0 ) 0 j J .
Multiplication by x0 j 0 :
t j x0 j x0 j max{rj ,p0 j } 0

j J .

(R4.1)

Multiplication by x j 0 0 :
t j x j 0 x j 0 max{rj ,p0 j } + x j 0 max{0, p0 j r j } x j 0 [ LB ( j) rj ] 0 j J
i.e. t j x j 0 x j 0 LB( j ) 0

j J .

(R4.2)

j J .

(R4.3)

Multiplication by (1-x0 j x j 0 ) 0 :
t j (1-x0 j -x j0 ) r j (1 x0 j -x j 0 ) 0

83

(R5) Multiply (3.4.2) by the bound factors xij 0 , x ji 0 and the two-aircraft subtour
elimination constraint (1 xij x ji ) 0 for i,j J,i j .
Multiplication by xij 0 :
t j xij ti xij pij xij 0

i,j J,i j .

(R5.1)

i,j J,i j .

(R5.2)

Multiplication by x ji 0 :
t j x ji ti x ji + (d i rj ) x ji 0
where, = max[ 0,di rj max{ p ji ,ri rj }]
Multiplication by the two-aircraft subtour elimination constraint (1 xij x ji ) 0 :
t j (1 xij x ji ) ti (1 xij x ji ) (rj di )(1 xij x ji )

i,j J,i j .

(R5.3)

(R6) For computational convenience, we can rewrite the objective function and constraint (3.1) as
(3.1') and (3.1) given below.

Minimize z
subject to
ti +

p x

ij ij

i J0

(3.1)

j i
jJ 0

z=

(t + p
i

i0

) xi 0

(3.1)

i J

Let us now multiply (3.1) by xik 0 and (1 xik ) 0 , k J 0 , k i . This gives the
following.
zx ik ti x ik + pik xik

z (ti +

p x ) + ( zx
ij ij

ik

ti xik p ik xik )

i J 0, k J 0 , i k

(R6.1)

i J 0, k J 0 , i k

(R6.2)

j i
jJ 0

Similarly, the multiplication of (3.1) by x k 0 0 , k J , yields

zx k 0 = (t k + p k 0 ) x k 0

kJ .

84

(R6.3)

In the RLT context, when zxik is substituted by a single (independent) variable, (R6.1) will
likely hold as an equality and hence return (R6.2) to (3.1). To make (R6.1)-(R6.3) more
useful, we can also multiply the assignment constraints (3.5) and (3.6) by z.
Multiplication of z by the assignment factor (3.5) yields, using (R6.3),
z = (ti + p i 0 ) xi 0 +

zx

i J0 .

ij

(R6.4)

j i
jJ

Multiplication of z by (3.6) gives the following, using (R6.3).

z=

(t + p
i

i0

) xi 0

for j = 0, and

(R6.5)

jJ .

(R6.6)

i J

z=

zx

ij

i j
iJ 0

Note that constraint (R6.5) is the same constraint as (3.1) and can therefore be deleted.
However, (R6.6) can be retained. The resulting reformulation is stated below.
Minimize z
subject to
zx ik ti x ik + pik xik

z (ti +

p x ) + ( zx
ij ij

ik

ti xik p ik xik )

j i
jJ 0

zx k 0 = (t k + p k 0 ) x k 0

z = (ti + p i 0 ) xi 0 +

(t + p
z = zx
z=

i0

zx

ij

i J 0 , k J 0 , i k

(R6.1)

i J 0 , k J 0 , i k

(R6.2)

kJ

(R6.3)

i J

(R6.4)

j i
jJ

) xi 0

(R6.5)

i J

jJ

ij

(R6.6)

i j
iJ 0

(t j rj ) x0 j = 0

j J

[t j max ( r j ,ri + pij )] xij 0

(t j r j ) x ji 0

i J, j J, i j

(t j LB( j)) x j 0 0

j J

(t j r j )(1 xij x ji ) 0

i J, j J, i j

(R2.5)
(R2.1)

i J, j J, i j

j J

(1-x 0 j -x j 0 )[t j max ( r j ,min ( ri + p ij ))] 0

iJ
i j

85

(R2.3)
(R2.6)
(R3.1)
(R3.1)

(d j t j ) xij 0

i J, j J, i j

(d j t j )x j 0 0

j J

[min (d j ,d i p ji ) t j ] x ji 0
(d j t j )(1 xij x ji ) 0

i J, j J, i j

(1-x 0 j -x j 0 )[min ( d j ,max( d i p ji )) t j ] 0

j J

(R2.2)
(R2.7)
(R2.4)
(R3.2)
(R3.2)

t j x0 j x0 j max{rj ,p0 j } 0 ,

j J

(R4.1)

t j x j 0 x j 0 LB ( j ) 0 ,

j J

(R4.2)

t j (1 x0 j -x j 0 ) r j (1 x0 j x j0 ) 0 ,

j J

(R4.3)

t j x ji ti x ji + x ji (d i rj ) 0

i,j J,i j

(R5.2)

i J, j J, i j

i J
i j

t j (1 xij x ji ) ti (1 xij x ji ) + (r j d i )(xij + x ji ) (rj di )

i,j J,i j

(R5.3)

iJ

(R1.1)

j J

(R1.2)

xij = 1

j i

i J0

(3.5)

xij = 1

i j

j J0

(3.6)

xij + x ji 1

i J 0, j J 0, j i

(3.7)

ti xij = ti

j i

t j xij = t j

i j
jJ 0

iJ 0

t0 = 0 , ti 0

j J

xij {0 ,1}

i J 0, j J 0, j i

(3.8)
(3.9)

where, LB(j) is given by Preposition 1, and where = max[ 0,di rj max{ p ji ,ri rj }] (see
Proposition 3).

86

2) Linearization Phase
Let ti xij = u ij, tj xij = vij, zxij = zij . The linearization of the reformulated constraints can be represented
as follows (we state the identity of the corresponding constraint from the reformulation phase on
the left of each of the following linearized restrictions.)

Minimize z
subject to
(R6.1) : z ik uik + pik x ik
(R6.2) : z (t i +

p x ) + (z
ij ij

ik

u ik pik xik )

j i
jJ 0

(R6.3) : z k 0 = u k 0 + pk 0 xk 0
(R6.4) : z = ui 0 + pi 0 xi 0 +

(u
(R6.6) : z = z
(R6.5) : z =

i0

ij

i J, k J, i k

(L6.1)

i J, k J, i k

(L6.2)

kJ

(L6.3)

i J

(L6.4)

j i
jJ

+ pi 0 xi 0 )

(L6.5)

i J

jJ

ij

(L6.6)

i j
i J 0

(R2.5) : v0 j r j x0 j = 0
(R2.1) vij max ( r j ,ri + p ij ) xij 0
(R2.3) : u ji rj x ji 0
(R2.6) : u j 0 LB( j) x j 0 0
(R3.1) : t j vij u ji r j (1 xij x ji ) 0
(R3.1) : t j v0 j u j 0 max {r j , min ( ri + pij )}(1 x0 j x j 0 ) 0

j J

(R2.2) : d j xij vij 0

(R2.7) : d j x j 0 u j 0 0
(R2.4) : min ( d j ,d i p ji ) x ji u ji 0
(R3.2) : d j (1 xij x ji ) t j + vij + u ji 0
(R3.2) : min {d j , max (d i p ji )}(1 x0 j x j0 ) t j + v0 j + u j0 0

i J, j J, i j
j J
i J, j J, i j
j J

(L2.2)
(L2.7)
(L2.4)
(L3.2)
(L3.2)

(R4.1): v0 j x0 j max{rj ,p0 j } 0

j J

(L4.1)

(R4.2): t j v0 j u j 0 + rj x0 j + r j x j 0 rj

j J

(L4.2)

(R4.3): u j 0 x j 0 LB( j ) 0

j J

(L4.3)

iJ
i j

iJ
i j

i J, j J, i j
i J, j J, i j
j J
i J, j J, i j
j J

i J, j J, i j

i J, j J, i
(R5.2) : u ji v ji (d i rj ) x ji 0
t

t
+
u
+
v
+
(
r

d
)
x
+
(
r

d
)
x

(
r
(R5.3) : j ij
ji
i
ij
ji
j
i ij
j
i ji
j di )

87

(L2.5)
(L2.1)
(L2.3)
(L2.6)
(L3.1)
(L3.1)

(L5.2)
(L5.3)

 i J 0 , j J, i j

u
v

= ti

iJ

(L1.1)

= tj

j J

(L1.2)

xij = 1

j i

i J0

(3.5)

xij = 1

i j

j J0

(3.6)

xij + x ji 1

i J 0, j J 0, j i

(3.7)

t0 = 0 , ti 0

j J

xij {0 ,1}
zij 0 , uij 0 , vij 0

i J 0, j J 0, j i

(R1.1) :

ij
j J 0 ,j i

(R1.2) :

ij
i J 0 ,i j

jJ 0

iJ 0

(3.8)
(3.9)

i J, j J, i j

where, LB(j) is given by Preposition 1, and where = max[ 0,di rj max{ p ji ,ri rj }] (see
Proposition 3).

88

3.3.4

3.3.4.1

Modifying the Formulation

Consideration of More Than Two Consecutive Aircraft

Up to now, our minimum separation constraint assumes that we only need to maintain an
adequate separation between two consecutive aircraft. However, even though this constraint is
satisfied, the resulting solution can violate the minimum separation rule between certain
operations belonging to a common class in the context of mixed operations. Figure 3.2 illustrates
this difficulty. In this case, the minimum separation between consecutive operations (i.e., arrival i
and departure k, departure k and arrival j) are satisfied, but the required separation between the
two arriving aircraft (i.e., arrival i and arrival j) may be violated.
tk
time

ti

tj - tk p kj

tk ti p ik

tj

tj - ti < pij

Figure 3.2

Checking Minimum Separation Constraints.

To protect against this event, we need another constraint set to enforce the minimum separation
between the same types of operations as follows:
)
)
)
)
p ij xij m ji (1 xij ) t j t i mij xij p ji (1 xij ) ,

i < j, (i,j ) same class

(3.10)

where,
)
)
xij = 1 if t j > ti , and xij = 0 if ti > t j
mij , m ji : upper bounds on the separations between i j and j i , respectively,

i < j, (i,j ) same class. We can define mij = ( d j - ri ), and m ji = ( d i -rj ).

89

When ri + pij > d j , then it is clear that xij = 0 . (Note that in this case, we have pij > mij and (3.10)
)

leads to a contradiction when x ij = 1 , hence also implying that xij = 0 .). In this case, we need to
include the constraint t i t j + p ji . Similarly, if r j + p ji > d i (i.e., p ji > m ji ), then we can fix
)
x ij = 1 in (3.10) and include the relevant constraint t j t i + pij . Additionally, in order to tighten
)
the representation of this modified model, we can further relate the binary variable xij to the

original models variables xij , x ji , xik , xkj via the valid inequalities given in Proposition 4 below.

Proposition 4. The following constraints are valid inequalities.

)
xij xij 1 x ji ,
i < j with (i , j ) same class

(3.11)

)
2 xij + xik + xkj 1 xij 2 x jk xki 2 x ji , i < j with (i, j) same class, k i, j (3.12.1)
)
x j 0 xij (1 xi 0 )
i < j with (i, j) same class
(3.12.2)
)
x0 i xij (1 x0 j )
i < j with (i, j) same class.
(3.12.3)
)
Proof. If xij = 1, which means xik = xkj = x ji = 0 , and (xki+xjk) 1, (3.11) becomes 1 xij 1 , and
)
(3.12.1) becomes 1 xij 2 ( xki + x jk ) . Hence, both (3.11) and (3.12.1) are valid in this case. If
xij = 0, then equation (3.11) is clearly valid in both cases when x ji = 0 (whence we get
)
)
0 xij 1 ), and x ji = 1 (whence we get xij 0 ). Furthermore, in this case (xij =0), (3.12.1)
becomes
)
xik + xkj 1 xij , and

(3.12.1.1)

)
xij 2 x jk xki 2 x ji .

(3.12.1.2)
)
Consider (3.12.1.1). If xik = xkj = 1 , then since xij must be 1, this is valid. Else, xik + xkj 1 0
)
and so (3.12.1.1) is implied by xij 0. Next, consider the inequality (3.12.1.2). If x ji = 1, then
)
x jk = xki = 0 and since we must have xij =0, (3.12.1.2) is valid. On the other hand, suppose that
)
x ji =0. Then, if x jk = xki = 1 , we must have xij =0, and therefore (3.12.1.2) is valid. Otherwise,
)
we must have 2 x jk xki 1 and so (3.12.1.2) is implied by xij 1. This validates (3.12.1).
For (3.12.2), note that x i 0 =1 and x j 0 =1, is impossible and so, the possible values of ( x i 0 , x j 0 )
are (0,0), (1,0) and (0,1). It is readily verified that each of these cases implies a valid set of
)
bounds on xij . Hence, (3.12.2) is valid. With the same argument, (3.12.3) is also valid for all
possible cases. This completes the proof.
90

Note that if the triangular inequality for the separation among aircraft triplets holds true, i.e., if
p ik + p kj p ij i < j with (i, j) same class, k i, j , then we do not need to apply (3.10). As
shown below, by successive applications of these triangular inequalities, if the separation between
consecutive aircraft is enforced, then it holds between non-consecutive aircraft in the same class
as well.

Proposition 5. If the triangular inequality is satisfied for all triplets of aircraft in J involving i in
which i is first or last, or for all such triplets involving j, for any i and jsame class, then for any
solution that satisfies the separation constraints for consecutive aircraft, we will also have that i
and j satisfy their particular separation constraint.
t2 ( = tk 2 t k1 ) p k1 ,k 2

t1 ( = tk 1 ti ) pi ,k 1

( tk 2 ti ) ( pi ,k1 + p k1 ,k 2 ) pi, k 2
time
0

t kt0 k(1= ti ) tk 1
t
t

tk 2

tk 3

Figure 3.3

tk n 1

tk n

t k n+1 ( = t j )

Triangular Inequality.

Proof. Without loss of generality, let ti < tj (the case of tj < ti is similar) and suppose that aircraft i
and j are separated by some n 1 aircraft k 1 , , k n . Then, we have by the feasibility of
consecutive separation constraints that
(t j t i ) =
where tk ti and tk
0

n +1

n +1

r =1

(t k r t kr 1 )

n +1

pk
r =1

r 1 , kr

(P5.1)

t j . Now, suppose that all triangular inequalities involving i are satisfied

as stated in the Proposition (the case of j is similar). Then from (P5.1), we get
(t j ti ) pi ,k1 + pk1 ,k2 + pk 2 ,k3 + ....+ p kn 1 , kn + pk n , j
pi ,k 2 + p k2 , k3 + .... + pkn 1 ,k n + p kn , j
pi ,k 3 + .... + p kn 1 ,k n + p kn , j .. p i , j .
This completes the proof.

91

To enforce separation between all pairs of aircraft in the same class, we need to impose the
following constraints. Let V={i: some triangular inequalities are violated for a triplet involving i
in which i is last or first}. The following is a summary of the constraint set generated to enforce
aircraft separations.
ti t j + p ji

i < j, (i,j ) same class in V and ri + p ij > d j

t j t i + pij

i < j, (i,j ) same class in V and r j + p ji > d i .

Also,
for all i < j, (i,j ) same class in V and ri + p ij d j , r j + p ji d i ,

(P5.2)

impose the following set of constraints, where, mij = ( d j -ri ), m ji =( d i -rj )

)
)
)
)
p ij xij m ji (1 xij ) t j t i mij xij p ji (1 xij )
)
xij xij 1 x ji
)
2 xij + xik + xkj 1 xij 2 x jk xki 2 x ji

kJ, ki,j

)
x j 0 xij (1 xi 0 )
)
x0 i xij (1 x0 j ) .

3.3.4.2

Applying RLT

Reformulation:
(R7) Multiply (3.10) by the bound factors x ij 0 , x ji 0

i,j J,i j .
Multiplication by x ij 0 :
)
( p ij + m ji ) xij xij m ji xij + t i xij t j xij 0
)
t j xij t i xij ( p ji + mij ) xij xij + p ji xij 0 .
Multiplication by x ji 0 :
)
( p ij + m ji ) x ji xij m ji x ji t j x ji + t i x ji 0
)
t j x ji t i x ji ( p ji + mij ) x ji xij + p ji x ji 0 .
92

and (1 x ij x ji ) 0

for

Multiplication by (1 x ij x ji ) 0 :
)
)
( p ij + m ji ) xij + t i t j [( p ij + m ji ) xij xij m ji xij + t i xij t j xij ]
)
[( pij + m ji ) x ji xij m ji x ji t j x ji + t i x ji ] m ji
)
)
t j t i ( p ji + mij ) xij [t j xij t i xij ( p ji + mij ) xij xij + p ji xij ]
)
.
[t j x ji t i x ji ( p ji + mij ) x ji xij + p ji x ji ] p ji

Linearization:
)
)
Let t i xij = u ij and t j xij = vij i, j . Also note that xij xij xij and x ji xij = 0 .
p ij xij vij u ij mij xij

(3.10.1)

m ji x ji u ji v ji p ji x ji
)
)
pij ( xij xij ) m ji (1 xij x ji ) (t j ti ) (vij u ij ) (u ji v ji )
)
)
mij ( xij xij ) p ji (1 xij x ji ) .

(3.10.2)

(3.10.3)

)
)
)
Proposition 6. Conv{(ti , t j , xij ) : (3.10) holds, xij binary} {(3 .10 )} {0 xij 1} for each (i,j)
same class, i<j such that p ij mij and p ji m ji (i.e., for each (i, j) such that (P5.2) holds true).
Proof. Given any (i,j ) same class, i < j , consider the following linear program for any
ci , c j , cij .
)
LP : tmax
) (ci t i + c j t j + cij xij )
,t , x
i

(3.13.1)

ij

subject to
)
)
)
)
pij xij m ji (1 xij ) t j ti mij xij p ji (1 xij )
)
0 xij 1 .

(3.13.2)
(3.13.3)

It is sufficient to show that if LP defined by (3.13) has an optimal solution then it has an optimum
)
at which xij =0 or 1. Denoting nonnegative slacks s1 and s2 in the two inequalities in (3.13.2),
respectively, and eliminating tj by substitution using the first equality, say, yields the following
equivalent linear program
)
max{(ci + cj ) ti + (cij + cj p ij + cj mji ) xij + cj s1 - cj mji :
)
)
xij (p ij + mji - p ji - mij ) + s1 + s2 = (mji - p ji ), s1 0, s2 0, 0 xij 1}.

93

)
Note that for an optimum to exist, we must have (ci + cj ) = 0. Also, we then have that either xij is
nonbasic at 0 or 1 at an optimal vertex, or if it is basic, then it must equal
( m ji p ji )
1.
(m ji p ji ) (mij pij )
)
Hence, in this case, we must have (mij -p ij )=0 and xij =1 by feasibility. This completes the proof.
Remark 2. Note that if we include the constraints ri t i d i and r j t j d j with (3.10), then
the continuous relaxation can indeed have fractional extreme points. For example, we could have
a vertex determined by the right-hand inequality in (3.13.2) binding along with t i = d i and
t j = d j as three linearly independent constraints yielding the solution (where we have used
mij = d j ri )

t i = d i , t j = d j , xij =

d j d i + p ji
d j ri + p ji

(3.14)

)
If ri < d i < d j , this yields 0 < xij < 1 . Also, this solution (3.14) is feasible to the left-hand
inequality in (3.13.2) since this inequality is redundant whenever the right-hand inequality holds
as an equality because of the hypothesis p ij mij and p ji mji . Hence, this yields (3.14) as a
fractional vertex.
Motivated by Remark 2, we now present a tightened representation of (3.10). Consider the
representation of (3.10) given by the following polynomial set of constraints

)
)
(t j ti ) xij pij xij

(3.15.1)

)
)
(ti t j )(1 xij ) p ji (1 xij )

(3.15.2)

ri t i d i

(3.15.3)

rj t j d j

(3.15.4)

)
xij binary.

(3.15.5)

94

By Sherali and Adams (1994), a polyhedral convex hull representation can be given by
)
)
)2 )
multiplying the inequalities in (3.15.1) - (3.15.4) by xij , and (1 xij ) , and substituting xij = xij ,
)
)
t i xij = rij and t j xij = sij . This gives (3.16) below as the convex hull of (3.15).
)
( sij rij ) p ij xij

(3.16.1)

)
(ti t j ) ( rij sij ) p ji (1 xij )

(3.16.2)

)
)
)
)
ri xij rij d i xij , ri (1 xij ) (t i rij ) d i (1 xij )

(3.16.3)

)
)
)
)
r j xij sij d j xij , r j (1 xij ) (t j sij ) d j (1 xij )

(3.16.4)

)
0 xij 1 .

(3.16.5)

Now, suppose that we further include within (3.15) the restrictions

)
xij xij 1 x ji , xij , x ji binary.

(3.11)

Note that by Sherali et al. (1996), the Special Structured RLT (SSRLT) factors are given by
)
)
S1 = { xij 0, x ji 0 , xij xij 0 ,1 - x ji xij 0}

(3.17)

which collectively imply bounds of 0 and 1 on all the three binary variables as well as imply the
2-city DFJ subtour elimination constraint xij + x ji 1 (via the sum of the last two factors in S 1 .)
Using the fact that
)
)
xij xij = xij , x ji xij = 0 , and xij x ji = 0 ,

(3.18)

the second-order factors obtained by pairwise (including self) products in (3.17) are given by S 1
itself, and hence, so are the third-order product factors. This means that we can generate
conv{(3.15), (3.11)} by multiplying each of (3.15.1), (3.15.2), (3.15.3) and (3.15.4) by each
factor defining S 1 in (3.17), including these factors (3.17) within the resulting constraint set, and
substituting (3.18) along with

95

)
) )
)
u ij = t i xij , vij = t j xij , rij = t i xij , sij = t j xij , xij2 = xij , xij2 = xij , x 2ji = x ji .

(3.19)

The resulting constraint sets are,

conv{(3.15), S 1 }:
(3.15.1) xij : vij u ij pij xij 0

(3.15.1.11)

(3.15.1) x ji : redundant.
)
)
(3.15.1) ( xij xij ) : ( sij rij ) (vij u ij ) pij ( xij xij )
)
(3.15.1) (1 x ji xij ) : redundant.

(3.15.1.12)

(3.15.2) xij : redundant.

(3.15.2) x ji : v ji u ji p ji x ji 0 .
)
(3.15.2) ( xij xij ) : redundant.
)
)
(3.15.2) (1 x ji xij ) : (t i v ji rij ) (t j u ji sij ) p ji (1 x ji xij ) .
(3.15.3) xij : ri xij uij d i xij .

(3.15.2.11)

(3.15.2.12)

(3.15.3.11)

(3.15.3) x ji : ri x ji v ji d i x ji .
)
)
)
(3.15.3) ( xij xij ) : ri ( xij xij ) rij u ij d i ( xij xij ) .
)
)
)
(3.15.3) (1 x ji xij ) : ri (1 x ji xij ) t i v ji rij d i (1 x ji xij ) .
(3.15.4) xij : r j xij vij d j xij .

(3.15.3.12)
(3.15.3.13)
(3.15.3.14)

(3.15.4.11)

(3.15.4) x ji : r j x ji u ji d j x ji .
)
)
)
(3.15.4) ( xij xij ) : r j ( xij xij ) sij vij d j ( xij xij ) .
)
)
)
(3.15.4) (1 x ji xij ) : r j (1 x ji xij ) t j u ji sij d j (1 x ji xij ) .

(3.15.4.12)
(3.15.4.13)
(3.15.4.14)

For all i < j, (i,j ) same class and i V, j V, ri + p ij d j , r j + p ji d i , the above constraint
set will be imposed.
We can also consider the convex hull representation for {(3.15), (3.12.2)}, {(3.15), (3.12.3)}
using the special structured factors for (3.12.2) and (3.12.3) as follows:
96

)
)
S 2 = {xi 0 0, x j 0 0, xij x j 0 0, 1 - xi 0 xij 0} ,

(3.20)

)
)
S3 = { x0 i 0 , x0 j 0, xij x0 i 0, 1 - x0 j xij 0} .

(3.21)

Reformulation
)
)
)
)
Using x j 0 xij = x j 0 , xi 0 xij = 0 , x0i xij = x0 i , and x0 j xij = 0 , the reformulated constraint sets are,
conv{(3.15), S 2 }:
(3.15.1) x j 0

: (t j t i ) x j 0 p ij x j 0

(3.15.1) xi 0
)
(3.15.1) ( xij x j 0 )

: redundant.
)
)
: (t j t i )( xij x j 0 ) p ij ( xij x j 0 )

)
(3.15.1) (1 xi 0 xij )
(3.15.2) x j 0
(3.15.2) xi 0
)
(3.15.2) ( xij x j 0 )

: redundant.
: redundant
: (ti t j ) xi 0 p ji xi 0 .

)
(3.15.2) (1 xi 0 xij )

: redundant
)
)
: (t i t j )(1 xi0 xij ) p ji (1 xi 0 xij ) .

(3.15.3) x j 0

: ri x j 0 ti x j 0 d i x j 0 .

(3.15.3) xi 0
)
(3.15.3) ( xij x j 0 )
)
(3.15.3) (1 xi 0 xij )

: ri xi 0 t i xi 0 d i xi 0 .
)
)
)
: ri ( xij x j0 ) ti xij t i x j0 d i ( xij x j 0 ) .
)
)
)
: ri (1 xi 0 xij ) t i ti xi0 t i xij d i (1 xi 0 xij ) .

(3.15.4) x j 0

: r j x j0 t j x j0 d j x j0 .
: r j xi 0 t j xi 0 d j xi0 .
)
)
)
: r j ( xij x j 0 ) t j xij t j x j 0 d j ( xij x j 0 ) .
)
)
)
: r j (1 xi 0 xij ) t j t j xi 0 t j xij d j (1 xi 0 xij ) .

(3.15.4) xi 0
)
(3.15.4) ( xij x j 0 )

)
(3.15.4) (1 xi 0 xij )
conv{(3.15), S 3 }:
(3.15.1) x 0 i
(3.15.1) x0 j
)
(3.15.1) ( xij x0i )

: (t j ti ) x0 i pij x0 i

(3.15.2) x 0 i
(3.15.2) x0 j
)
(3.15.2) ( xij x0i )

: redundant.
: (ti t j ) x0 j p ji x0 j .

: redundant.
)
)
: (t j t i )( xij x0i ) pij ( xij x0 i )

)
(3.15.1) (1 x0 j xij ) : redundant.

: redundant.
)
)
)
(3.15.2) (1 x0 j xij ) : (t i t j )(1 x0 j xij ) p ji (1 x0 j xij ) .
97

: ri x 0i t i x 0i d i x 0i .
: ri x0 j t i x0 j d i x0 j .
)
)
)
: ri ( xij x0 i ) t i xij t i x0i d i ( xij x0i ) .
)
)
)
)
(3.15.3) (1 x0 j xij ) : ri (1 x0 j xij ) t i t i x0 j t i xij d i (1 x0 j xij ) .
(3.15.3) x 0 i
(3.15.3) x0 j
)
(3.15.3) ( xij x0i )

: r j x0 i t j x0 i d j x0 i .
(3.15.4) x0 j
: r j x0 j t j x0 j d j x0 j .
)
)
)
)
(3.15.4) ( xij x0i )
: r j ( xij x0i ) t j xij t j x0i d j ( xij x0i ) .
)
)
)
)
(3.15.4) (1 x0 j xij ) : r j (1 x0 j xij ) t j t j x0 j t j xij d j (1 x0 j xij ) .
(3.15.4)

x0 i

Linearization
)
)
Using rij = t i xij , sij = t j xij , u ij = t i xij , vij = t j xij ,

f ij = t i x0 j , l ij = t i x j 0 , the linearized

constraint sets are as follows:

conv{(3.15), S 2 }:
(3.15.1) x j 0

: u j 0 lij p ij x j 0

(3.15.1.21)

(3.15.1) x i 0
)
(3.15.1) ( xij x j 0 )

: redundant.
)
: ( sij rij ) (u j 0 l ij ) p ij ( xij x j 0 )

(3.15.1.22)

: redundant
: (u i 0 l ji ) p ji xi 0 .

(3.15.2.21)

(3.15.1) (1 xi 0

)
xij ) : redundant.

(3.15.2) x j 0
(3.15.2) x i 0
)
(3.15.2) ( xij x j 0 )
(3.15.2) (1 xi 0
(3.15.3) x j 0

: redundant
)
)
xij ) : (t i u i 0 rij ) (t j l ji sij ) p ji (1 xi 0 xij ) . (3.15.2.22)
: ri x j0 lij d i x j 0 .

(3.15.3) x i 0
: ri x i0 u i0 d i x i0 .
)
)
)
(3.15.3) ( xij x j 0 )
: ri ( xij x j0 ) rij lij d i ( xij x j 0 ) .
)
)
)
(3.15.3) (1 xi 0 xij ) : ri (1 xi 0 xij ) t i u i 0 rij d i (1 xi 0 xij ) .
: r j x j 0 u j 0 d j x j0 .
(3.15.4) x i 0
: r j xi 0 l ji d j xi0 .
)
)
)
(3.15.4) ( xij x j 0 )
: r j (xij x j 0 ) sij u j 0 d j ( xij x j 0 ) .
)
)
)
(3.15.4) (1 xi 0 xij ) : r j (1 xi 0 xij ) t j l ji sij d j (1 xi 0 xij ) .
(3.15.4) x j 0

conv{(3.15), S 3 }:

98

(3.15.3.21)
(3.15.3.22)
(3.15.3.23)
(3.15.3.24)
(3.15.4.21)
(3.15.4.22)
(3.15.4.23)
(3.15.4.24)

(3.15.1) x 0 i
: f ji v0 i p ij x0i
(3.15.1) x0 j
: redundant.
)
)
(3.15.1) ( xij x0i )
: ( sij f ji ) (rij v0i ) p ij ( xij x0i )
)
(3.15.1) (1 x0 j xij ) : redundant.
(3.15.2) x 0 i
(3.15.2) x0 j
)
(3.15.2) ( xij x0i )
(3.15.2) (1 x0 j

: redundant.
: f ij v0 j p ji x0 j .

(3.15.1.31)
(3.15.1.32)

(3.15.2.31)

: redundant.
)
)
xij ) : (t i f ij rij ) (t j v0 j s ij ) p ji (1 x0 j xij ) . (3.15.2.32)

: ri x 0 i v 0i d i x 0i .
: ri x0 j f ij d i x0 j .
)
)
: ri ( xij x0 i ) rij v0 i d i ( xij x0 i ) . (15.3-33)
)
)
)
(3.15.3) (1 x0 j xij ) : ri (1 x0 j xij ) ti f ij rij d i (1 x0 j xij ) .
(3.15.3) x 0 i
(3.15.3) x0 j
)
(3.15.3) ( xij x0i )

(3.15.3.31)
(3.15.3.32)
(3.15.3.34)

: r j x0 i f ji d j x0i .
(3.15.4.31)
(3.15.4) x0 j
: r j x 0 j v0 j d j x0 j .
(3.15.4.32)
)
)
)
(3.15.4) ( xij x0i )
: r j ( xij x0i ) s ij f ji d j ( xij x0 i ) .
(3.15.4.33)
)
)
)
(3.15.4) (1 x0 j xij ) : r j (1 x0 j xij ) t j v0 j sij d j (1 x0 j xij ) .(3.15.4.34)
(3.15.4)

x0 i

99

3.3.4.3

Comparison of Constraints Sets

)
Let us defined constraint Set I as [(3.10), (3.11), (3.15.3), (3.15.4)]. Again, using xij xij = xij ,
)
x ji xij = 0 , and xij x ji = 0 , the application of SSRLT factor S 1 to constraint set I, SSRLT(I), yield
the following.

SSRLT(I):
(3.10)S 1 :
(3.10) xij : p ij xij vij u ij mij xij
(3.10) x ji : m ji x ji u ji v ji p ji x ji
)
)
)
(3.10) ( xij xij ) : p ij ( xij xij ) (s ij vij ) (r ji u ji ) mij ( xij xij )
)
)
(3.10) (1 x ji xij ) : m ji (1 xij x ji ) (t j t i ) (s ij rij ) (u ji v ji )
)
p ji (1 xij x ji )

(3.10.4)
(3.10.5)
(3.10.6)
(3.10.7)

(3.11)S 1 : same to (3.11).

(3.11) xij : redundant.
(3.11) x ji : redundant.
)
)
(3.11) ( xij xij ) : xij xij
)
)
(3.11) (1 x ji xij ) : xij 1 x ji
(3.15.3) S 1 : same to (3.15.3.1), (3.15.3.2), (3.15.3.3), (3.15.3.4).
(3.15.3) xij : ri xij uij d i xij .
(3.15.3) x ji : ri x ji v ji d i x ji .
)
)
)
(3.15.3) ( xij xij ) : ri ( xij xij ) rij u ij d i ( xij xij ) .
)
)
)
(3.15.3) (1 x ji xij ) : ri (1 x ji xij ) t i v ji rij d i (1 x ji xij ) .

(3.15.3.1)
(3.15.3.2)
(3.15.3.3)
(3.15.3.4)

(3.15.4) S 1 : same to (3.15.4.1), (3.15.4.2), (3.15.4.3), (3.15.4.4).

(3.15.4) xij : r j xij vij d j xij .
(3.15.4) x ji : r j x ji u ji d j x ji .
)
)
)
(3.15.4) ( xij xij ) : r j ( xij xij ) sij vij d j ( xij xij ) .
)
)
)
(3.15.4) (1 x ji xij ) : r j (1 x ji xij ) t j u ji sij d j (1 x ji xij ) .

100

(3.15.4.1)
(3.15.4.2)
(3.15.4.3)
(3.15.4.4)

Similarly, let us define Constraint Set II[(3.15.1), (3.15.2), (3.11), (3.15.3), (3.15.4)] and let us
denote the application of SSRLT factor S 1 to this constraint as SSRLT(II).
Up to now, we have formulated two sets of constraints (i.e., Constraint Sets I and II) to enforce
the separation rules for the same class operations. By applying RLT to Set I, and SSRLT to both
Sets I and II, we have derived three sets of tightened constraints, RLT(I), SSRLT(I) and
SSRLT(II) (see Table 3.6).

Original Constraints

Table 3.6

Original and SSRLT Constraint Sets.

Constraint Set (I): (3.10), (3.11), (3.15.3), (3.15.4)

)
)
)
)
p ij xij m ji (1 xij ) t j ti mij xij p ji (1 xij ) (3.10)
plus the following constraints:
)
xij xij 1 x ji

(3.11)

ri t i d i

(3.15.3)

rj t j d j
SSRLT(I)
p ij xij vij u ij mij xij

SSRLT Constraints by applying S1

Constraint Set (II):

(3.15.1), (3.15.2), (3.11), (3.15.3), (3.15.4)
)
)
(t j ti ) xij pij xij
(3.15.1)
)
)
(ti t j )(1 xij ) p ji (1 xij )
(3.15.2)
plus the following constraints:

(3.15.4)

(3.10.4)

m ji x ji u ji v ji p ji x ji
(3.10.5)
)
)
p ij ( xij xij ) (s ij vij ) (r ji u ji ) mij ( xij xij )
(3.10.6)
)
m ji (1 xij x ji ) (t j t i ) (vij u ij ) (u ji v ji )
)
p ji (1 xij x ji )
(3.10.7)
plus the following constraints:
)
xij xij 1 x ji

SSRLT(II)
p ij xij vij u ij
(3.15.1.11)
)
p ij ( xij xij ) (s ij rij ) (vij u ij )
(3.15.1.12)
u ji v ji p ji x ji

(3.15.2.11)
(t j t i ) ( sij rij ) (u ji v ji )
)
p ji (1 x ji xij ) (3.15.2.12)
plus the following constraints:
(3.11)

ri xij uij d i xij

(3.15.3.11)

ri x ji v ji d i x ji
)
)
ri ( xij xij ) rij u ij d i ( xij xij )
)
)
ri (1 x ji xij ) t i v ji rij d i (1 x ji xij )
r j xij vij d j xij

(3.15.3.12)
(3.15.3.13)
(3.15.3.14)
(3.15.4.11)

r j x ji u ji d j x ji
)
)
r j ( xij xij ) sij vij d j ( xij xij )
)
)
r j (1 x ji xij ) t j u ji sij d j (1 x ji xij )

101

(3.15.4.12)
(3.15.4.13)
(3.15.4.14)

Let us now investigate the various implications among these constraint sets. As mentioned earlier,
)
the RLT factor 1 xij x ji 0 is implied by summing the last two factors xij xij 0 and
)
1 - x ji xij 0 defining S 1 in (3.18). Hence, since the other RLT factors xij 0 and xji 0 are also
implied by S 1 , we have that RLT(I) is implied by SSRLT(I).
For SSRLT(I) and SSRLT(II), the right-hand side (RHS) of (3.10.4) and (3.10.6) and the lefthand side (LHS) of (3.10.5) and (3.10.7) can be represented by (3.15.3.11)-(3.15.3.14) and
(3.15.4.11)-(3.15.4.14) in the following way, noting that mij = ( d j -ri ) and m ji =( d i -rj ).
(3.15.4.11) (3.15.3.11) = RHS of (3.10.4)
(3.15.4.12) (3.15.3.12) = LHS of (3.10.5)
(3.15.4.13) (3.15.3.13) = RHS of (3.10.6)
(3.15.4.14) (3.15.3.14) = LHS of (3.10.7).
Consequently, all the inequalities having mij or mji in (3.10.4)-(3.10.7) can be eliminated. This
reduces SSRLT(I) to SSRLT(II), thereby establishing their equivalence. Figure 3.4 presents the
relationships among these various constraint sets. In practical terms, the aforementioned
constraints can be generated by the following procedure.
For iV
For j>i, jV, (i,j)same class
If ( ri + p ij > d j ), then ti t j + p ji
Else if ( rj + p ji > d i ), then t j t i + pij
Else if ( ri + p ij d j and rj + p ji d i ), then
)
2 xij + xik + xkj 1 xij 2 x jk xki 2 x ji

kJ, k i,j

(3.15.1.11), (3.15.1.12), (3.15.2.11), (3.15.2.12),

(3.15.3.11), (3.15.3.12), (3.15.3.13), (3.15.3.14),
(3.15.4.11), (3.15.4.12), (3.15.4.13), (3.15.4.14).
(3.15.1.21), (3.15.1.22), (3.15.2.21), (3.15.2.22),
(3.15.3.21), (3.15.3.22), (3.15.3.23), (3.15.3.24),
(3.15.4.21), (3.15.4.22), (3.15.4.23), (3.15.4.24).

102

(3.15.1.31), (3.15.1.32), (3.15.2.31), (3.15.2.32),

(3.15.3.31), (3.15.3.32), (3.15.3.33), (3.15.3.34),
(3.15.4.31), (3.15.4.32), (3.15.4.33), (3.15.4.34).
Endif
End for j
End for i

103

Constraint Set (I):

(3.10), (3.11), (3.15.3), (3.15.4).

Constraint Set (II):

(3.15.1), (3.15.2), (3.11), (3.15.3), (3.15.4).

RLT Factors:
xij 0 , x ji 0 , 1 xij x ji 0 .

RLT I

SSRLT Factors:
)
)
S1 = { xij 0, x ji 0 , xij xij 0 ,1 - x ji xij 0} .

SSRLT(II)

SSRLT(I)
(3.10.4), (3.10.5),(3.10.6), (3.10.7),
(3.11),
(3.15.3.11), (3.15.3.12), (3.15.3.13), (3.15.3.14),
(3.15.4.11), (3.15.4.12), (3.15.4.13), (3.15..4.14)
Imply

(3.15.1.11), (3.15.1.12),
(3.15.2.11), (3.15.2.12),
(3.15.3.11), (3.15.3.12), (3.15.3.13), (3.15.3.14),
(3.15.4.11), (3.15.4.12), (3.15.4.13), (3.15.4.14).

Imply (Equivalent)

Figure 3.4

Relationships among the Constraint Sets.

104

3.3.4.4

Prefix and Probe Tests

Proposition 7. Let I={1,,t} be a collection of identical aircraft from the same class such that
)
r1 r2 rt and d 1 d 2 d t . Then we may fix xij =1 i, jI, i<j, and yet preserve optimality
in ASP.
Proof. Consider any optimal solution to ASP and examine the sequence positions of aircraft from
the set I. If these appear in the same order as in I, we are done. Otherwise, processing from the
left in I, let the first out-of-sequence aircraft be in position p (possibly, p=1)and let the aircraft in
this position be q. Note that q>p, and so, rp rq and d p d q . Since rp rq tq <tp d p d q by scheduling
aircraft q at time tp and aircraft p at time tq , we would obtain a feasible solution having the same
objective value. Continuing in this fashion, we would obtain an optimum with the aircraft in I
sequenced in order 1,,t. This completes the proof.
)
Remark 3. Whenever we fix xij =1,we automatically also have xji 0.

We can also perform probing tests on the xij variables based on the following concept. Suppose
that we tentatively fix xij =1. If this results in an infeasible problem ASP, then we can permanently
fix xij =0. Similarly, if fixing xij =0 renders the problem infeasible, then we can assert that we must
have xij =1. To simplify the notation in this development, for each aircraft r, let
r = minimum { prs }
s

p rs if s is in the same class as r

and let p rs =
r otherwise

aircraft s .

Proposition 8 (Probing on xij =1). Consider the pair of aircraft i and j associated with the (defined
and not as yet fixed) variable xij . If either (a) ri +p ij >d j , or (b) there exists an aircraft k for which
the following two conditions hold:

105

rk+ p ki >d i , or rk + p ki +p ij > d j ,

max{ri +p ij , rj }+ p jk >d k,
then we can optimally fix xij =0, assuming that an optimum exists.
Proof. Suppose that we consider any feasible solution in which xij =1. Clearly, if (a) holds true
then we have a contradiction, and so we must have xij =0. Hence, suppose that (b) holds true. If the
first part of condition (i) holds true, then k cannot precede i or else aircraft i cannot be feasibly
scheduled, and similarly, if the second part of condition (i) holds true then again k cannot precede
i or else aircraft j cannot be feasibly scheduled (given xij =1). On the other hand, condition (ii)
asserts that aircraft k cannot be feasibly scheduled after i and j are consecutively scheduled.
Together, these conditions imply that if xij =1, then there exists an aircraft k which cannot be
feasibly scheduled, and so, we may fix xij =0. This completes the proof.

Proposition 9 (Probing on xij =0). Consider the pair of aircraft i and j associated with the (defined
and not as yet fixed) variable xij . If
rj + p ji >d i , and
min [max{ri + p ik , rk } + p kj ] > d j ,

k i , j
ri + p ik d k

then we may optimally fix xij =1, assuming that an optimum exists.
Proof. Suppose that we consider any feasible solution in which xij =0. Condition (i) asserts that j
cannot precede i, and condition (ii) asserts that for any possible aircraft ki,j that immediately
follows i, it would not be feasible to subsequently schedule aircraft j. Hence, aircraft j would
remain unscheduled unless it immediately succeeds aircraft i, i.e., xij =1. This completes the proof.
Remark 4. Naturally, if i and j belong to the same class and we fix xij =1 then we can also fix
)
xij =1.

106

)
Figure 3.5 presents the scheme to prefix certain xij variables based on symmetry using the
Proposition 7, 8 and 9.

Let I be a set of identical aircraft in the same

class, where |I| 2. Arrange the aircraft indices
in I in nondecreasing lexicographic order of
(ri , d j ).

Denote r(I) as the rth ranked index in I, for r=1,,|I|.

For each r = 1,, |I|, compute the violation function.
VIOLr = [# of indices q(I), q<r for which d q(I) > d r(I)]
+ [# of indices q(I), q>r for which d q(I) < d r(I)].
Note that VIOLr counts how many aircraft pairs (q(I), r(I)),
qr, violate the nondecreasing ordering in I w.r.t. d values.
Find Rargmaxr {VIOLr }

Remove r(I) from I

no
VIOLR = 0
yes

Order the aircraft as they appear in I by setting

)
x( p ( I ), q ( I )) = 1, p, q= 1,.., |I|, p < q
)
xij if i < j
)
where x(i, j ) )
x ji if j < i

Figure 3.5

Prefixing Variables.
107

3.3.5

Computational Results

Figure 3.6 illustrates computational result of a simple case having 10 flights. As seen in the
figure, the completion time of the first-come-first-served (FCFS) sequence and the optimal
sequence are 624 seconds and 518 seconds, respectively. Hence by changing the traditional FCFS
sequence intelligently, about 17% of the overall operational time can be saved.
We consider 12 problem instances having specified hypothetical flight schedules. The results
given in Tables 3.7 and 3.8 indicate that the linear programming relaxation of the original
traditional model seems to yield a significant gap from optimality that needs to be resolved. On
the other hand, the proposed reformulated ASP problems yield tighter representations, producing
significantly improved lower bounds. As a result, several previously unsolvable instances are now
computationally tractable within the set limits. Nevertheless for real-time implementation, the
CPU times (seconds) measured on an HP workstation indicate that we need to devise suitable
heuristics as an alternative for deriving good quality solutions.
Various types of problems are defined as below according to the application of RLT and SSRLT.
Problem O is an original problem without applying RLT. RLT1 is a problem resulted from
applying RLT to problem O. Problem RLT2 involves additional constraints set generated by
applying SSRLT factor S 1 to constraints set (3.15). In problem RLT3, SSRLT factor S 1 , S 2 and S 3
are applied to constraints set (3.15). Among the problems, O, RLT1 and RLT2 are implemented
in this research.
O: Minimize z
subject to
(3.1), (3.2), (3.3), (3.4), (3.5), (3.6), (3.7), (3.8), (3.9), (3.10), (3.11), (3.12),
ti t j + p ji

i < j, (i,j ) same class in V and ri + p ij > d j

t j t i + pij

i < j, (i,j ) same class in V and r j + p ji > d i

)
xij binary.

RLT1: Minimize z
subject to
(L2.5), (L2.1), (L2.3), (L2.6), (L3.1), (L3.1), (L2.2), (L2.7), (L2.4), (L3.2), (L3.2),
(L4.1), (L4.2), (L4.3), (L5.2), (L5.3), (L1.1), (L1.2), (3.5), (3.6), (3.7), (3.8), (3.9),
(3.10), (3.11), (3.12),

108

ti t j + p ji

i < j, (i,j ) same class in V and ri + p ij > d j

t j t i + pij

i < j, (i,j ) same class in V and r j + p ji > d i

uij 0 , vij 0
)
xij binary.

i J, j J, i j

RLT2: Minimize z
subject to
(L2.5), (L2.1), (L2.3), (L2.6), (L3.1), (L3.1), (L2.2), (L2.7), (L2.4), (L3.2), (L3.2),
(L4.1), (L4.2), (L4.3), (L5.2), (L5.3), (L1.1), (L1.2), (3.5), (3.6), (3.7), (3.8), (3.9),
(3.10), (3.11), (3.10), (3.11), (3.12),
SSRLT[conv{(3.15), S1 }],
ti t j + p ji

i < j, (i,j ) same class in V and ri + p ij > d j

t j t i + pij

i < j, (i,j) same class in V and r j + p ji > d i

uij 0 , vij 0

i J, j J, i j

rij 0 , sij 0 i < j, (i,j) same class, i V, j V and ri + p ij d j , r j + p ji d i

)
xij binary.
RLT3: Minimize z
subject to
(L2.5), (L2.1), (L2.3), (L2.6), (L3.1), (L3.1), (L2.2), (L2.7), (L2.4), (L3.2), (L3.2),
(L4.1), (L4.2), (L4.3), (L5.2), (L5.3), (L1.1), (L1.2), (3.5), (3.6), (3.7), (3.8), (3.9),
(3.10), (3.11), (3.10), (3.11), (3.12),
SSRLT[conv{(3.15), S1 }],
SSRLT[conv{(3.15), S2 }],
SSRLT[conv{(3.15), S3 }],
ti t j + p ji

i < j, (i,j ) same class in V and ri + p ij > d j

t j t i + pij

i < j, (i,j ) same class in V and r j + p ji > d i

uij 0 , vij 0
i J, j J, i j
rij 0 , sij 0, f ij 0 , lij 0 , f ji 0 , l ji 0
i < j, (i,j ) same class, i V, j V and ri + p ij d j ,
r j + p ji d i
)
xij binary.

109

Legend

Nominal Schedule
(1) (2)
25 32
L L

(3)
82
L

(4)
102
H

(5)
154
H

(Original Sequence)
Scheduled time (seconds)
Aircraft type

100

(6)
4
H

(7)
73
S

200

(8) (9)
122 136
H
S

300

400

500

600

(10)
184
H

FCFS Schedule
Completion Time= 634 Seconds
(1)
54
L

(2)
114
L

(3)
324
L

100

200

(6)
4
H

(4)
384
H

300

(7)
200
S

(5)
594
H

400

500

(8)
274
H

(9)
470
S

600
(10)
544
H

Optimal Schedule (Before adding constraint set (2.10))

Completion Time= 484 Seconds
(1)
54
L

(3)
149
L

(4)
249
H

100

(6)
4
H

200
(7)
119
S

Violation

(5)
349
H

(2)
444
L

300

(8)
199
H

(10)
299
H

400

500

600

(9)
414
S

Violation

Optimal Schedule (After adding constraint set (2.10))

Completion Time= 508 Seconds
(1)
25
L

(2)
120
L

(3)
218
L

100
(7)
90
S

(4)
318
H

200
(9)
188
S

Figure 3.6

(5)
418
H

300
(6)
268
H

400
(8)
368
H

Illustrative Example.

110

500
(10)
468
H

600

Table 3.7
Data
Intrvl
(sec)

MIP
value

RLT1

Prob.
Id

# acft

5_0
5_1
5_2
5_3
5_4
5_5

5
5
5
5
5
5

2000
100
100
100
100
100

1558
288
263
266
260
380

1558
256
234
266
260
263

1558.0
85.0
79.0
92.1
84.9
84.0

0.01
0.01
0.02
0.02
0.01
0.01

7
98
223
245
199
72

.02
.11
.31
.31
.26
.09

1558
230
231
238
232
262

.12
.09
.12
.14
.11
.13

0
26
34
36
59
32

.01
.23
.26
.40
.57
.35

10_0
10_3
10_4
10_5
10_6

10
10
10
10
10

2000
600
600
300
200

1883
750
626
634
715

1883
686
492
518
524

1871.0
500.0
305.0
243.0
185.0

0.03
0.06
0.03
0.03
0.03

46932
27152
300,000
300,000
300,000

127.00
143.72
1250.36
1275.90
*1283.90

1873
531
464
479
489

3.30
2.90
1.43
2.42
1.12

47
7806
22147
22615
45320

32.14
784.51
2006.78
3646.54
3612.37

15_0
15_1
15_3

15
15
15

2000
500
500

2095
948
967

2095

2046.0

0.04

300,000

1286.99

2077

19.67

1657

299.57

Prob.
id

# acft

5_0
5_1
5_2
5_3
5_4
5_5

5
5
5
5
5
5

2000
100
100
100
100
100

1558
288
263
266
260
380

1558
256
234
266
260
263

1558
230
231
238
232
262

.11
.12
.14
.15
.16
.21

0
32
21
42
65
24

.01
.33
.18
.50
.66
.35

10_0
10_3
10_4
10_5
10_6

10
10
10
10
10

2000
600
600
300
200

1883
750
626
634
715

1883
686
492
518
524

1883
531
464
479
489

3.39
5.49
2.21
2.73
2.15

0
2878
20542
17413
48953

.02
573.50
2878.87
2774.44
4791.63

15_0
15_1
15_3

15
15
15

2000
500
500

2095
948
967

2095

2077

11.53

60

218.30

Data
Intrvl
(sec)

FCFS
sol.

Computational Results (without using Prefixing Constraints).

LP
Value

MIP
time

nodes

LP
Time

RLT2
FCFS
sol.

MIP
value

LP
Value

MIP
Time

not optimal (due to the maximum nodes limit).

111

nodes

Time

Value

MIP
Time

nodes

time

Table 3.8

Prob.
Id

# acft

Data
Intrvl
(sec)

FCFS
sol.

Computational Results (using Prefixing Constraints).

O

MIP
value

LP
Value

5_0
5_1
5_2
5_3
5_4
5_5

5
5
5
5
5
5

2000
100
100
100
100
100

1558
288
263
266
260
380

1558
256
234
266
260
263

10_0
10_3
10_4
10_5
10_6

10
10
10
10
10

2000
600
600
300
200

1883
750
626
634
715

1883
686
492
518
524

15_0
15_1
15_3

15
15
15

2000
500
500

2095
948
967

Prob.
id

# acft

5_0
5_1
5_2
5_3
5_4
5_5

5
5
5
5
5
5

2000
100
100
100
100
100

1558
288
263
266
260
380

1558
256
234
266
260
263

10_0
10_3
10_4
10_5
10_6

10
10
10
10
10

2000
600
600
300
200

1883
750
626
634
715

1883
686
492
518
524

15_0
15_1
15_3

15
15
15

2000
500
500

2095
948
967

Data
Intrvl
(sec)

FCFS
sol.

MIP
value

RLT1
MIP

time

1871.6
551.0
305.0
271.0
264.0

0.02
0.04
0.02
0.03
0.03

nodes

LP
Time

3792
6721
120518
33793
173046

9.80
31.50
442.98
127.77
660.00

RLT2
LP
Value

1883
551
464
479
489

MIP
Time

1.90
2.42
1.48
1.40
1.38

112

nodes

14
9358
3097
3774
9835

Time

18.22
3258.65
401.98
439.92
1263.82

Value

1873
551
464
479
489

MIP
Time

2.51
1.87
1.22
1.23
1.22

nodes

50
5299
2973
4113
8277

time

29.57
1183.42
262.96
379.53
758.40

3.4 Heuristics for the Aircraft Sequencing Problem (ASP)

Note that the aircraft sequencing decisions need to be made in real-time within a rolling horizon
framework. As such, the computational time required to solve reasonably sized instances of ASP
is of paramount importance. In such a context, both dynamic and integer programming
approaches are not likely to be appropriate for implementation, especially when the problem size
is relatively large. Hence, we propose the use of heuristic methods which provide solutions in a
reasonable time. Although these solutions might be sub-optimal, they are motivated by partial or
relaxed optimality considerations and are likely to be near-optimal.

3.4.1

3.4.1.1

Tour Building Process

FCFS Sequence

For the tour building procedure, instead of devising a new tour building procedure, the FCFS
sequence (with landing priority) can be used as an initial tour. The motivation of this is that the
FCFS sequence is the strategy currently applied in air traffic control, and we are seeking to
improve the solution provided by it.

3.4.1.2

LP-based Heuristic

Having determined an LP-RLT solution x for an ASP, we can use this solution to construct an
initial tour via a rounding process. (Among various types of RLT formulations shown in section
3.3.6, the RLT1 can be used for this purpose. This is because comparing with other RLTs, the
computation time for LP of RLT1 is relatively small without losing the tightness of LP solution.
See Table 3.7.) To do this, we develop two sequential rounding heuristics for the obtained LP
solution.
Method 1: Round x based on FCFS or cost/delay considerations.
Method 2: Suppose that x is fractional. Solve min i j xij xij , subject to assignment constraints,
and hence obtain the solution x . If x is a tour, then use this as the rounded tour. If x has
subtours, construct a complete tour by using a FCFS-based strategy.

113

For Method 1, the following steps are performed:

Step 0 (Selection of variables from the solution): From the LP solution x , for each i, find
j(i)argmaxj { xij }. Initialize the set of subtours as null.
Step 1 (Sort and store the selected variables): Sort the selected values xi , j (i ) i in nonincreasing
order, and store the corresponding ordered list of variables in an array X() of size N.
Step 2 (Insert nodes in the current set of subtours): Remove the first element xi,j (i) from X(), and
reduce the size of X() by one. Insert the nodes i and j(i) in a current subtour by applying
one of following rules.
Rule 1: If both i and j(i) are currently included in the current set of subtours, go to Step 3.
Rule 2: If both i and j(i) are not included in any current subtour, generate a new subtour
by connecting nodes 0 i j(i) 0.
Rule 3: If only i is included in some current subtour, i0, insert j(i) between node i and
the node following i in this subtour.
Rule 4: If only j(i) is included in some current subtour, j(i)0, insert i between node j(i)
and its predecessor node in this subtour.
Rule 5: In case the selected variable is of the type x0j (i.e., i = 0 with jj(0) not included
in any subtour), calculate the savings obtained by connecting j to node 0 in each
of the current subtours. The savings are given by the following expression:
saving jf m = p0 f m + p j 0 p jf m ,
where, f m is the first node after node 0 in the mth subtour.
Connect j as the immediate successor to node 0 in the subtour which yields the
largest savings.
Rule 6: In case the selected variable is of the type xi0 (i.e., j(i)=0), with i not included in
any subtour, calculate the savings obtained by connecting i to node 0 in each of
the current subtours. The savings are given by the following expression:
saving l mi = pl m 0 + p 0 i pl m i ,
where, lm is the last node before node 0 in the mth subtour.
Connect i as the immediate predecessor of node 0 in the subtour which yields the
largest savings.
Step 3 (Repeat): If the array X() is not empty, go to Step 2. Else, go to Step 4.

114

Step 4 (Connect subtours): If the current solution is a complete tour, stop. Else (i.e., the current
solution has more than one subtour), compute all savings by connecting the last node in a
subtour to the first node in another for all pairs of subtours. The savings for connecting
the last node lm in the mth subtour and the first node f n in the n th subtour is given by the
following expression.
savingmn = pl m 0 + p0 f n pl m f n ,

m, n{the index set for subtours}, mn.

Join the pair of subtours that yields the highest savings into a single subtour according to
the corresponding connection. Repeat Step 4 until a complete tour is obtained.
Table 3.9 shows an example of this initial tour building procedure for the case having 10 aircraft.
The first two columns in the table present the sorted LP-solution values, and the rules applied to
insert the nodes are shown in the third column.

Table 3.9

An Example of Heuristic Method for ASP.

Variable

LP-solution

Rule for insertion

x3,10

0.93

rule 2

x7,3

0.91

rule 4

x4,9

0.84

rule 2

x9,5

0.81

rule 3

x8,4

0.78

rule 4

x0,6

0.70

rule 5

x1,0

0.66

rule 6

x5,8

0.57

rule 1

x6,2

0.54

rule 3

x10,2

0.45

rule 1

Figure 3.7 depicts the stepwise process for this example. For instance, Figure 3.7(6) illustrates
two choices of connecting flight 6 to node 0, and the best resulting sequence after applying Rule
4 is shown in Figure 3.7(7). Figures 3.7(11) and 3.7(12) illustrate two possible ways to connect
the current pair of subtours, and Figure 3.7(13) depicts the final selected sequence after joining
these subtours.

115

10

10

10

10

(1)

(2)

(3)
10

(4)

10

10

7
6

(5)

10

(7)

(6)

10

10
1

7
7
6

5
5

(8)

(10)

10
3

7
6

10

8
4

(9)

10
3

(11)

(12)

Figure 3.7

LP-based tour building procedure for ASP.

116

8
4

(13)

3.4.2

3.4.2.1

Improvement Heuristic

2-exchange Heuristic

The 2-exchange scheme developed by Lin (1965) can be applied as an improvement routine for
ASP. Associated with a proposed exchange, the new schedule can be tested against the minimum
separation rules by considering each affected flight and its three previous flights. This is
necessary because the triangle inequality does not necessarily hold for the given edge weights.
The data for the minimum separation rule has a largest separation of 196 seconds, which is
required when a small aircraft follows a heavy one in an arrival sequence. In this case, two
departing operations can successively intervene between these two arrivals without delaying (or
pushing forward) the small aircraft schedule. Even though the separations between the small
aircraft arrival and the two departures are adequate, there is still a chance that the separation rule
between the heavy aircraft arrival and the small aircraft arrival is violated. Hence the foregoing
three-previous-flight rule.
Given that a 2-exchange involves the substitution of two edges, (i, i+1) and (j, j+1) with two other
edges (i, j) and (i+1, j+1) as shown previously in Figure 2.5, the profitability of a proposed
sequence is checked at the (j+1)th aircraft using the following condition:
If the start time of the (j+1)st aircraft's operation in the suggested 2-exchange
sequence is earlier than that in the current sequence, the new sequence is profitable.
In fact, this condition is not sufficient but is only a necessary condition for the improvement of
the current sequence. The reason for this is that there still exists a possibility for some flight
following the (j+1)st flight to be further delayed because of the separation constraints with respect
to the revised two predecessors of the (j+1)st flight. This relaxed condition sometimes results in a
non-monotone decreasing sequence of completion times. However, from computational
experience, it is observed that in some cases, this relaxed condition is very helpful to attain
improved solutions. The entire improvement process is repeated from the beginning whenever a
profitable sequence is obtained, and is continued until no feasible and profitable sequence is
found. The pseudo-code for this heuristic is shown in Figure 3.8.

117

iter = 0;
heurSeq = initial sequence from tour building;
prepareVP();
reduceTimeWindow();
do{
findBetterTwoExchange = false;
findBetterTwoExchange = heuristicASP ();
iter++;
}while(findBetterTwoExchange is not found);
heuristicASP()
{
int i, j, k;
findBetterTwoExchange = false;
for(i = 0 to totFlights 1){
for(j = i+2 to totFlights){
initialize tempSeq;
for (k = 0 to tot + 1){
if(k <= i) tempSeq[k] = heurSeq[k];
else if (k > i and k <= j){ // reversed sequence
tempSeq[k] = heurSeq[j - (k - i) + 1];
update tempSeq;
if(tempSeq is infeasible){
initialize tempSeq;
break;
}
}
else if (k == j + 1){ // check feasibility and profitability
tempSeq[k] = heurSeq[k];
update tempSeq;
if(tempSeq is infeasible or not profitable){
initialize tempSeq;
break;
}
}
else if(k < totFlights + 1){
tempSeq[k] = heurSeq[k];
update tempSeq;
if(tempSeq is infeasible){
initialize tempSeq;
break;
}
}
else{ // i.e., k = tot + 1;
tempSeq[k] = heurSeq[k];
update tempSeq;
if(tempSeq is infeasible){
initialize tempSeq;
break;
}
else{// i.e., tempSeq is feasible
for (m = 0 to tot + 1) heurSeq[m] = tempSeq[m]; // update heurSeq
return findBetterTwoExchange = true;
}
}//end if
}//for k
}//for j
}//for i
return findBetterTwoExchange = false;
}
update tempSeq{
// decide and update the current flight's start time considering the minimum separation rules between
// this flight and three previous flights.
}
checkFeasiblity of tempSeq(){
// if the tempSeqs start time is later than due-time then the tempSeq is not feasible.
}
checkProfitablity of tempSeq(curr, tSeq, hSeq){
// if the tempSeqs start time is less than the heurSeqs start time, then the tempSeq is profiable.
}

Figure 3.8

Pseudo-code for the ASP heuristic.

118

3.4.2.2

2-swap Heuristic

Besides the 2-exchange procedure, we can apply the 2-node swapping method which swaps a
node with one of its local neighbors that reside within some n nodes adjacent to the current node.
Let us consider swapping an ith with a j th flight for j>i. The 2-swap heuristic would check
feasibility for all the flights after the j th flight, and would also check the profitability of this
exchange at the i+1st flight. If the new starting time for the i+1st flight is earlier than the previous
starting time, this swapped sequence is considered as profitable.

3.4.2.3

Enhancing Improvement Heuristics

For expediting the improvement procedure, two additional methods may be applied: 1) Exploiting
a precedence relationship, and 2) reduction of time-windows.
Method 1 (Exploiting precedence relationship): In ASP, the precedence relations among the
flights can be found by applying the following rules:
Rule 1: The sequence is symmetrically identical by feasibly interchanging the same types
of operations involving the same aircraft type. As such, the FCFS rule could be
applied to such flights. In other words, restrict flighti p flightj , if operationi =
operationj , (aircraft type)i = (aircraft type)j , and ei ej .
Rule 2: Let [ei , li ] and [ej , lj ] denote time-windows for flights i and j, respectively. If li
ej , then flight i should precede flight j in the final sequence.
Adopting Solomons (1988) approach, the precedence information among the flights are stored in
a matrix VP(i, j), where VP(i, j) is defined as follows.
+1 if flight i must precede flight j,
0 if no precedence relationship exists,
-1 if flight j must precede flight i,
where, i and j are indices for flight identification.

VP(i, j) =

Once VP(i, j) is available, a node precedence value, NP(i), for the ith flight in the current
sequence, is defined as follows:

119

NP(i) = the smallest number k, k > i+1, such that VP(j, k) = +1, for some j i+1. If no
such k exists, then NP(i) = N+1,
where, i is a position for the ith flight in the current sequence, and N is the number of
flights.
The NP(i) array can be obtained from VP(i, j) in O(N2 ) time by applying the following procedure,
where N is the number of flights in the current sequence.
current_i = 1;
for(k = 2 to k < N + 1){
for(j = current_i to j < k){
NP(j 1) = k;
j_id = id of currSeq(j);
k_id = id of currSeq(k);
if(VP(j_id - 1, k_id - 1) = 1){
current_i = j + 1;
break;
}

}//end for
}//end for
NP(N) = N+1;
NP(N+1) = N+1;

Henceforth, the improvement procedure can be expedited by adopting the following necessary
condition for the feasibility of a 2-exchange as suggested by Psaraftis (1983b):
A necessary condition for the feasibility of a 2-exchange of arcs (i, i+1) and (j, j+1) with (i,
j) and (i+1, j+1) is that j < NP(i).
Let us consider an example case having 10 flights with the following current sequence.

Sequence

10

11

Flight Id.

f0

f6

f7

f8

F1

f2

f9

f10

f3

f4

f5

f0

Assuming that the precedence relations among the flights are f1 p f4 , f1 p f5 , f2 p f3 , f4 p f5 , f6 p f7 ,

f6 p f8 , and f7 p f8 , the resulting NP(i) values for the current sequence are given as follows:

120

i
0
1
2
3
4
5
6
7
8
9
10

NP(i)
2
2
3
8
8
10
10
10
10
11
11

Method 2 (Reduction of time-windows): Exploiting the precedence rela tions imposed in the
previous step, certain time-windows can be reduced as follows: Let [ei , li ] and [ej , lj ] be
time-windows for flights i and j, respectively. If flight i precedes flight j, then their timewindows can be reduced by letting li = min{li , lj -tij } and ej = max{ej , ei +tij }.
The overall steps included in Methods 1 and 2 are depicted in Figure 3.9.

Generate VP(i,j)

Reduce time-windows

Read the initial sequence

Generate NP(i) for all flights

Perform admissible
2-exchanges

Better sequence found?

No

Stop

Yes

Figure 3.9

Flowchart of Improvement Procedure for ASP.

121

3.4.3

Computational Results

To test suggested heuristic methods, we performed computations using a set of randomly

generated problems. For the tour building process, the FCFS sequences are used. The results
obtained from 2-exchange improvement procedure are summarized in Table 3.10. In the problems
15_0 and 50_7, the time-windows for flights appearing later in the schedule dominate the overall
completion time. Results show that 2-exchage heuristic method provides sequences very close to
exact solutions in a reasonable time.

Table 3.10

Computational Results (2-exchange improvement procedure).

Problem #

Number
of aircraft

10_0
10_3
10_4
10_5
10_6
15_0
15_1
15_2
50_2
50_7

10
10
10
10
10
15
15
15
50
50

FCFS
Completion
Time (sec.)
1883 (100)
750 (100)
626 (100)
644 (100)
715 (100)
2095 (100)
1006 (100)
948 (100)
4670 (100)
3086 (100)

Optimal
Completion
Time (sec.)
1883 (100.0) **
686 (91.5)
492 (78.6)
518 (80.4)
524 (73.3)
2095 (100.0)
n.a.
n.a.
n.a.
n.a.

2-exchange Sequence
Completion
Computation
Time (sec.)
Time (sec.)*
1883 (100.0)
0.010
691 (92.1)
0.050
492 (78.6)
0.060
541 (84.0)
0.050
545 (76.2)
0.060
2095 (100.0)
0.030
956 (95.0)
0.080
848 (89.5)
0.110
4602 (98.5)
0.030
3086 (100.0)
6.519

Computation times do not include times for tour building process. The reported times are CPU seconds on
a PC having Pentium Pro 166Mhz CPU and a 64Mega-byte RAM.
**
The numbers in parentheses denote the percentage of completion time comparing with FCFS sequence.

From computational experience, it turns out that Rule 1 in Method 1 for enhancement of
improvement heuristic does not always provide favorable results. The reason for this is likely that
restricting the chances of flipping a segment of the current sequence because of this rule might
reduce the possibility for generating a better solution. In fact, the precedence imposed on flights
having the same operation type and involving the same aircraft type is not a hard constraint but
a soft constraint in the sense that these precedences may be violated without losing feasibility.
While it is advantageous to add these relations to combat symmetry in a mathematical
optimization model, in the present context, it is preferable to drop this restriction.
In contrast, the reduction of time-windows is evidently effective in saving computational effort.
The computational performance before and after applying the time-window reduction to the same

122

data set used for Table 3.10 are compared in Table 3.11. In some cases, the computational time
increases slightly after applying this reduction. This increase is mainly due to the additional effort
for performing this reduction, and appears to be negligible. On the other hand, the number of
iterations is reduced significantly in some cases.

Table 3.11
Problem #
10_0
10_3
10_4
10_5
10_6
15_0
15_1
15_2
50_2
50_7
*

Comparison of Computational Efforts.

Before reduction of TW
1 (0.010) *
3 (0.050)
6 (0.060)
10 (0.050)
7 (0.060)
1 (0.030)
5 (0.080)
4 (0.110)
19 (6.519)
1 (0.030)

After reduction of TW
1 (0.020)
3 (0.050)
7 (0.080)
7 (0.060)
4 (0.040)
1 (0.040)
5 (0.110)
4 (0.130)
17 (6.018)
1 (0.040)

iterations (CPU time, seconds).

For the purpose of comparison, we also tested the 2-swap heuristic using the same data set that
was used for the 2-exchange heuristic. Computational results obtained are summarized in Table
3.12. Compared with the 2-exchange heuristic results (see Table 3.10), the 2-swap heuristic
requires much less computation time. It, however, shows that in some cases, the resulting
solutions are relatively further from optimality.
Table 3.12

Computational Results (2-swap improvement procedure, n=10).

Problem #

Number
of aircraft

10_0
10_3
10_4
10_5
10_6
15_0
15_1
15_2
50_2
50_7

10
10
10
10
10
15
15
15
50
50

FCFS
Completion
Time (sec.)
1883
750
626
644
715
2095
1006
948
4670
3086

Optimal
Completion
Time (sec.)
1883 (100.0) **
686 (91.5)
492 (78.6)
518 (80.4)
524 (73.3)
2095 (100.0)
n.a.
n.a.
n.a.
n.a.

2-swap Sequence
Completion
Computation
Time (sec.)
Time (sec.)*
1883 (100.0)
0.020
691 (92.1)
0.090
568 (90.7)
0.040
562 (87.3)
0.050
604 (84.5)
0.040
2095 (100.0)
0.020
995 (98.9)
0.040
905 (95.5)
0.100
4602 (98.5)
0.220
3086 (100.0)
0.971

Computation times do not include times for tour building process. The reported times are CPU seconds on
a PC having Pentium Pro 166Mhz CPU and a 64Mega-byte RAM.
**
The numbers in parentheses denote the percentage of completion time comparing with FCFS sequence.

123

Chapter 4. Network Assignment Problem

The main purpose of the Network Assignment Problem (NAP) is to provide air traffic controllers
with efficient taxiing plans that can reduce taxiing delays at the airport under consideration. The
plans involve taxiing routes from a gate to a runway (or more precisely, to the departure queue)
for departing aircraft, or from the runway exit to a gate for arriving aircraft. At large airports
having complex taxiway configurations, taxiing routing is an important task for ground
controllers. Even for small airports, this might be important if automated conflict resolution is
desired. The simplest way to assign taxiing paths is to establish routes based on shortest paths.
Shortest paths are usually static in the sense that the paths are independent of any changes in
traffic conditions on the taxiway structure. This approach is relatively easy to implement but is
likely to produce more delays. Another option is to apply a time-dependent network assignment
strategy which considers changes in traffic conditions over time. In this chapter, network
assignment and shortest path algorithms for solving NAP are presented along with computational
results.

4.1 Network Assignment Strategies

4.1.1

Network Assignment Algorithm

There are several drawbacks in adopting static assignment techniques as a solver for NAP
problems. This mainly because there are differences between urban transportation networks and
airfields with respect to the network operations. Most urban transportation links are directed in
that they are used in one direction for all days. In contrast, almost all links in airfields are bidirectional in that each links operational direction can change over time. Whereas urban
transportation networks are directed graphs, airfield networks are undirected graphs in their
network representation. In order to consider time-dependent characteristics of airfield links,
dynamic (or time-dependent) network assignment strategies which have a look-ahead function for
each links operational direction should be introduced.
In a time-dependent network assignment strategy, all aircraft interact as long as they overlap
within the time horizon. By rerouting all vehicles iteratively, a dynamic user equilibrium (UE) (or
system optimal (SO)) state can be achieved. The general condition describing a dynamic UE can
be expressed as follows [Ghali, 1995]:
124

If, at each instant in time, for each origin-destination pair, the unit costs of flow on
utilized paths are identical and equal to the minimum instantaneous unit path cost, the
corresponding flow pattern is said to be user optimized.
In this research, the tentatively named quasi-dynamic network assignment strategy is proposed. In
a quasi-dynamic network assignment strategy, it is assumed that the current aircraft route is
influenced only by the previous aircraft assigned to the network. This simplified assumption rules
out the necessity of iterative rerouting procedures, thereby reducing the number of computations.
Besides the computational aspect, there is another theoretical rationale behind using the quasidynamic network assignment strategy. In the UE (or SO) framework, it is assumed that vehicle
drivers select their best paths in such a way that their own travel times (or marginal travel time)
are minimized. It is also assumed that all drivers have equal priorities in the sense that the rule of
first-come-first-served is maintained during travel. At an airport, however, ground controllers
often provide higher priorities to certain taxiing aircraft over others to facilitate traffic flows. This
is a non-systematic situation where it might be impossible to achieve a pure dynamic UE (or SO)
state.
Figure 4.1 depicts the flowchart for a quasi-dynamic network assignment method. The method is
based on the incremental assignment technique which decides the aircraft path in a one by one
fashion. After an aircraft is routed, the links on the taxiing path are loaded by that aircraft over
time slices (see Figure 4.2). As mentioned earlier, once any aircraft is assigned to taxi on a link in
one direction, the opposite direction of the link should be blocked during the time slice occupied
by the aircraft to prevent any conflict on the taxiway. This can be done by increasing the travel
time of the conflicting ilnk to an artificially large number to avoid being selected as a timedependent shortest path for any other flight. In practice, all the information about the loaded
aircraft is maintained in an fixed size array, called a time-dependent aircraft flow table. Figure 4.2
shows the resulting time-dependent link flows and the time-dependent link travel times for the
case that a flow v1 traverses from O to D along the path O12D.
The time-dependent travel times for all links can be computed by applying any known link
performance function link traffic volumes. Once the time-dependent link travel times are updated,
the time-dependent shortest paths between all nodes are recomputed for next flight to be assigned
using a time-dependent shortest path algorithm.

125

n=1

Find TDSP
for the nth aircraft
(by using
TDSP algorithm)

Assign the nth

aircraft on the
links involved in
the TDSP over
time intervals

Update
link travel times

n = last vehicle?

n = n+1

No

Yes

End

Figure 4.1

Quasi-dynamic Assignment Algorithm (1).

V1

v1

v1

D
3

Time-dependent vehicle flow

Links
Time slices

1
2
3

LO1
v1
-

L1O
-

LO3
-

L3O
-

L12
v1
-

L21
-

L34
-

L43
-

L24
-

L42
-

L2D
v1

LD2
-

L4D
-

LD4
-

L42
-

L2D
t2D 3

LD2

L4D
-

LD4
-

Time-dependent link travel times

Links
Time slices

1
2
3

LO1
tO1 1
-

L1O

LO3
-

Figure 4.2

L3O
-

L12
t12 2
-

L21

L34
-

L43
-

L24
-

Quasi-dynamic Assignment Algorithm (2).

126

4.1.2

Shortest Path Algorithms

The time-dependent shortest path algorithm suggested by Ziliakopoulos and Mahmassani is

designed to provide time-dependent shortest paths for all O-D pairs every time slices. In terms of
problem size, the NAP on taxiway system is much smaller than the NAP on the urban
transportation network. For example, the number of nodes and links on taxiway system at a large
airport is much less than that on a typical urban network. Also the number of aircraft considered
in the airport is smaller than the number of cars in the urban network. Motivated by this point, we
employ a TDSP algorithm based on the Dijkstras algorithm having the following characteristics:
1)
The TDSP provides a time-dependent shortest paths from a single root node to all other nodes
starting at time t.
The TDSP algorithm uses the sorted-queue as a data structure for candidate nodes, which makes
the algorithm as LS algorithm rather than LC algorithm. (Even though the size of candidate
nodes set (i.e., SE list) is small, size are big, fast sorting algorithm such as "quick sort" can be
applied for the facilitating the sorting procedure.)
Figure 4.3 shows the suggested TDSP algorithm for time-dependent paths from a node, r, to all
other nodes starting at time t.

Compute CurrentTimeSlice.
Call Initialize
while(SE list is not empty)
u = deQueueMin(r);
for(v = all forward star of u){
d_u = shortTime(r, u);
// travel time from r to u.
d_v = shortTime(r, v);
// travel time from r to v.
Compute timeSliceFor_l_uv;//compute the time slice for travel time from u to v.
l_uv = Find travelTime(u, v, timeSliceFor_l_uv)
// find the travel time from u to v for timeSliceFor_l_uv
if(d_v > d_u + l_uv){
shortTime(r, v) = d_u + l_uv; // update the short time from r to v
enQueue(v);
}
} //end for
}// end while
Procedure Initialize:
for (i = all nodes){
predecessor(i) = 0;

127

for (j = all node){

if(i j) Label(i, j) = inf.;
else Label(i, j) = 0;
}
}
predecessor(r) = r;
Procedure deQueueMin(): // find the closet node from the SE list.
Procedure enQueueMin(x): // insert node x into the SE list.

Figure 4.3

Pseudo Code for Suggested Time-dependent SP Algorithm.

4.2 Computational Results

To compare static and time-dependent assignment strategies, let us consider a hypothetical flight
schedule for DCA airport. (For the airport configuration, see Figure 5.3. The details of this airport
are described in Chapter 5.) As shown in Table 4.1, the schedule has only two flights but it is
designed to have a conflict during taxiing to their own destinations.

Table 4.1
Flight #
DEP_1
DEP_2

Aircraft
Type
B727-100
B727-100

Operation
Type
Departure
Departure

Hypothetical Flight Schedule.

Hour
0
0

Schedule Time
Minute
Second
0
27
0
44

Gate

Runway

1
11

36
16

Figure 4.4 shows the paths resulting from two different assignment strategies. Since no flight is
on the taxiway when the flight "DEP_1" is assigned, it can taxi to its destination at unimpeded (or
free-flow) speed. Therefore there is no difference in static and time-dependent shortest paths for
flight "DEP_1".
In the static assignment strategy, "DEP_2" taxis and approaches "DEP_1" on the link (1020,
1024). On the other hand, for the time-dependent assignment case, "DEP_2" is assigned to make
a detour so as to avoid the conflict with "DEP_1". This is obvious because, when "DEP_2" is
assigned on the network, link (1024, 1020) has been blocked by "DEP_1", and the timedependent SP algorithm detects this blockage. The difference of two paths for "DEP_2" are
clearly illustrated in Figure 4.5.

128

Paths from Static Network Assignment

Flight "DEP_1": 1 (27') - 1009 (44') - 1011 (49') - 1014 (54') - 1016 (65') - 1017 (77') 1019 (83') - 1020 (90') - 1024 (117') - 1027 (126') - 1031 (143') - 2018 (171') 2021(202').
Flight "DEP_2": 11 (44') - 1029 (52') - 1030 (61') - 1026 (70') - 1024 (78') - 1020 (105') 1021 (111') - 1018 (122') - 1015 (140') - 1012 (149') - 1010 (157') - 1008 (182') 1005 (196') - 1002 (235') - 1001 (250') - 2001(261').

Paths from Time -dependent Network Assignment

Flight "DEP_1": Same as Static Path.
Flight "DEP_2": 11 (4') - 1029 (52') - 1030 (61') - 1026 (70') - 1024 (78') - 1027 (87') 1025 (94') - 1022 (105') - 1021 (119') - 1018 (130') - 1015 (148') - 1012 (157') 1010 (165') - 1008 (190') - 1005 (204') - 1002 (244') - 1001 (258') - 2001(269').
Legend: Node (Seconds).

Figure 4.4

Static vs. Time-dependent Path (1).

129

15

15

2001

19

1001

19

2001

1001

2002

2002

1003

1003

1002

1002

1004

1004

2003
1005

2003

2004

1005

1006

2004

1006

2006

1010

1013

1011

21

1009
1

1012

1009

2008

1012

2007

1017

2011

1017

2010

1020

8
12

1024

1028

1021

2015
1023
2013

2014

9
1026

1029

1024
2016

11
1028

1026

1029

1025
1027

2016

1030
2017

1032

2018

2020

33

1031
2017

2014

10

1031

1033

2015
1023

1025
1027

2012

1021

2013

12

1030

1032

1020

33

10

11

1019

6
2012

1022

2010
1018

1019

2007

1015
1016

4
2011
1018

2008

1014
1015

1013
2009

1016

2006

1010
1011

1014
3

2005

2009

1008

1007

2005

21

1008

1007

2019

2018

1033

2020

2021

01

(a) Statically assigned path.

Figure 4.5

2019

2021

01

(b) Time-dependently assigned path.

Static vs. Time-dependent Path (2).

130

Chapter 5. Virginia Tech Airport Simulation Model

In this research, the simulation model plays an important role as a supplement to the analytical
models developed for ASP and NAP. This is because the simulation model makes it possible to
portray the dynamic behavior of entities that are difficult to examine by analytical models. In this
Chapter, methodologies pertinent for developing our simulation model are reviewed along with
previous simulation models. We also present detailed procedures to develop a simulation model
named Virginia Tech Airport Simulation Model (VTASM).

5.1 Framework of the Proposed Simulation Model

The primary purpose of a simulation model in the NAP is to evaluate the current state of aircraft
in the taxiway and runway systems. Several measures of network performance can also be
estimated using the simulation model. These include the estimation of delays and a general
assessment of the network congestion.
Since the number of entities (aircraft and air traffic controllers) considered in airport simulation
models is relatively small, a discrete time, microscopic and deterministic simulation model is
considered appropriate for this research problem. Even though the current prototype model is
developed as a deterministic model, the model design permits the inclusion of random variables
to reflect the stochastic behavior observed at airport networks.
The development of the simulation model is based on standard object-oriented methods
commonly used in software engineering. The most prominent qualities of an object-oriented
model are: 1) an easier understanding of the system, and 2) modifications to the model tend to be
local as they often result from an individual item, which is represented by a single object
[Jacobson, 1992].
Object-oriented methods have been improved in the past decade with the development of many
new object-oriented programming languages. The number of object-oriented methods increased
from less than 10 to more than 50 during the period between 1989 and 1994. Among the methods,
the most notable include Booch and Jacobsons OOSE (object-oriented software engineering),
Rumbaughs OMT (object model technique), Shaer-Mellors method, and the Coad-Yourdans
method. Recently the Unified Modelling Language (UML) has been developed by Booch,
Jacobson and Rumbaugh to unify various object-oriented methods [Booch et al., 1998].

131

The simulation model devised in this research project has been developed by following an
extension of the OMT originally applied to the design of SIMMOD 3 [ATAC, 1993]. In general,
the object-oriented modeling process is decomposed into three phases: 1) Object-oriented
Analysis (OOA), 2) Object-oriented Design (OOD) and 3) Object-oriented Programming (OOP).
Figure 5.1 describes the general procedures of the OMT methodology [Weijers, et. al, 1995 and
Derr, 1995].

132

System Requrement
(Problem Statement)

OMT

Object Model

Object Model

Object Model

OOA
Object Diagram

State Diagram

Data Flow Diagram

Combining models,
perfoaming a consistency check

N.G.

System Design
O.K.

N.G.

OOD

Object Design
O.K.

N.G.

Coding
O.K.

N.G.

Test
O.K.

End

Figure 5.1

Processes of OMT [reproduced from Weijers et. al, (1995) and Derr (1995)].

133

OOP

5.2 Object-oriented Analysis (OOA) of the Simulation Model

OOA can be defined as a method of analysis that examines requirements from the perspective of
the classes and objects found in the vocabulary of the problem domain [Booch, 1994]. OOA
begins with the verbal description of a problem statement. Then three types of models are
constructed: an object model, a dynamic model, and a functional model.
The object model describes the static, structural, and data-aspects of objects in the system, along
with their inter-relationships. The object model is represented by object diagrams. An object
diagram is a graph whose nodes are object classes and whose arcs reflect the relationships among
classes. The dynamic model describes the interactions among objects in the system in terms of
state diagrams. These represent the temporal, behavioral, and control-aspects of the system
changing over time. In a state diagram, nodes represent states, and arcs represent transitions
between states.
The data value transformation within a system is described in the functional model. Functional
models include data-flow diagrams where nodes represent processes and arcs represent data flows
[Weijers, et. al, 1995]. In the end, the three models come together during implementation, which
involve data (object model), sequencing (dynamic model), and operational (functional model)
manipulations [Bakker et. al, 1995].

5.2.1

Object Model

The main focus of the object model is to construct an object diagram that describes the dataoriented static structures of the problem domain. The following steps are used in the object model
analysis according to the OMT method [Rumbaugh et al., 1991, and Derr, 1995]:
Step 1. Develop a problem statement.
Step 2: Identify the object classes which represent all the physical and conceptual objects
from the problem statement.
Step 3. Prepare a data dictionary giving a short description of various entities in the model.
Step 4. Identify associations (including aggregations) between object classes.
Step 5. Identify attributes of the object classes.
Step 6. Use inheritance to share common structures.
Step 7. Traverse access paths using scenarios to identify deficiencies.

134

The candidates of objects or classes may be found by identifying noun or noun phrases from the
problem description. Association is a relationship and represents dependencies between classes,
being usually denoted by verb or verb phrases in the problem statement. Attributes are the data
values that are held by the objects, and are usually imbedded in a noun followed by possessive
phrases [Derr, 1995].
The arrow in the object diagram shows an aggregation/association relationship. An object at the
tail of arrow has an object at the head of arrow. The airport network, for instance, has n nodes and
m links and each link consists of two nodes defined as the from-node and the to-node. A gate is
represented by a node, and each node can hold one aircraft (or n aircraft in the case of an
aggregate gate). A link can have at most n taxiing flights at the same time.
Each flight has a taxiing path which consists of a series of links from the gate to the runway for
departing flights (or vice versa for arriving ones). Aircraft can have n flight schedules.
Controlling flights at an airport is carried cooperatively by two types of air traffic controllers: 1) a
ground controller, and 2) a local controller. Air traffic controllers evaluate various flight requests
to pushback, taxi, takeoff, or land, and try to maintain a smooth flow on the taxiway and runway
infrastructure while minimizing delays. Even though the final decisions for the ground and local
controllers are different, they share common attributes and behavioral characteristics. For
example, both controllers have the same information on flights, airport configuration, and use the
same communication procedures etc. For this reason, the ground and the local controllers are
inherited from the common class called controller.
Clock object is of importance in the simulation model as it is used in scheduling the next event for
such entities as controllers and flights. The object diagram is illustrated in Figure 5.2. The various
class definitions are described in Appendix C.

5.2.2

Dynamic Model

The time-dependent aspect of each entity is represented in the so called state diagram (or state
transition diagram) which consists of states and events. A change of state caused by an event is
called a transition. Whereas an object model describes the possible patterns of objects, attributes,
and links in a system, a dynamic model represented by the state diagram highlights the timedependent behavior of a system [Weijers, et. al, 1995]. According to Rambaugh (1991), the
general steps for constructing state diagrams are as follows:

135

AprtNtwk_Class

Node_Class

Link_Class
Controller_Class :
Ponit_Class

Position Class

Local/Ground
Controller_Class :

Flight_Class

Clock_Class
Aircraft_Class

ShortestPath_Class :

Figure 5.2

Queue_Class :

Object Diagram.

Step 1: Prepare scenarios for typical interaction sequences.

Step 2: Identify events between objects and prepare an event diagram for each scenario.
Step 3: Build a state diagram.
Step 4: Match events between objects to verify consistency and completeness of events shared
among the state diagrams.

5.2.2.1

Arriving Flights

Arriving aircraft are introduced to the simulation at discrete times prescribed by the original flight
schedule. If a flight scheduled landing time violates the minimum separation headway criteria, the
flight is delayed at the entry node (the runway interface). This procedure models implictly the
fina; airspace corridor leading to the active runway.

136

A. State Diagram for Ground Movement

Once an arriving flight obtains landing clearance from the local controller, it begins its landing
roll procedure which is composed of four phases: flaring out, free rolling, braking, and coasting
[Trani et. al, 1993]. After the completion of these four phases, the pilot decides which exit to use
by considering both the current speed and the location of neighboring exits. (A more detailed
landing procedure will be discussed later). Once a flight starts to exit from the runway, it will
contact the ground controller for taxiing clearance instructions.
The aircraft movement on the taxiway system is modeled regulating the vehicle acceleration to
accomplish a smooth and safe movement to the gate. This procedure is executed in an
autonomous fashion as the aircraft moves along the given path, keeping a safe spacing with other
taxiing flights. For example, the leading aircraft movements are modeled by a second-order
feedback control system to be discussed later in this chapter. The state transition diagram for an
arriving flight is depicted in Figure 5.3.
B. State Diagram for Communication
A unique aspect of VTASM is that air traffic controllers are modeled as explicit resources. If the
corresponding controller is busy communicating with another flight when the current flight tries
to contact the controller, the current flight waits for a certain period of time until the controller
state turns to standby.
Here, the waiting process varies depending on the communication system. In this research model,
two types of communication systems are considered: 1) a voice channel system which has been
widely used in aviation for seventy years, and 2) a data link system which is an advanced system
using electronic data transmission so the time required for either sending requests or receiving
command is considered to be negligible.
Regardless of communication system type, the flights communication state is initially set to
readyToCommunication. Once the flight finds the need to communicate with a controller, then
it tries to send a request, which will be accepted by the controller unless the controller is busy.
If the controller is busy, it happens under the voice channel system that the flights state is set to
waitNextCommunication and the flight is required to wait for the next contact for a certain
amount of time. The operation of the data link system follows smilar principles. The flights state
changes to "waitContactFromController" and the flight waits controller's contact.

137

On Final

Recieved Landing
Clearance

Communication

Flare

Free
Rolling

Braking

Coasting

Exiting
R/W

No

Parked
(at gate)

Recieved Taxiing
Clearance

Taxiing

Communication

No

Area
Holding

Waiting
in Line
(Gate Arrival Queue)

Waiting to
Taxi

Figure 5.3

State Diagram for an Arriving Flight.

138

If the controller is in a state of "standby" when the flight attempts a contact, the controllers state
is set to busy. Once a flight succeeds in contacting the controller, it communicates exclusively
with the controller until the entire communication phase is completed. After the flight confirms
the command, the flights and controllers state are set to readyToComm and standby,
respectively.
Depending on the traffic congestion levels on the taxiway system, it is possible for the flight to be
delayed even after communicating with a controller. In this case, the flight communication state is
set to "wait for controller's contact". The state transition diagrams for both communication
systems are depicted graphically in Figures 5.9 and 5.10.

5.2.2.2

Departing Flight

A. State Diagram for Movement

A departing flight stays in the parked state until the scheduled departure time arrives. During
the last one or more hours of this state, a departing flight files a flight-plan with the FAA flight
service station (FSS) and loads passengers or freight. Having finished all required routines, the
flight contacts the ground controller for the pushback clearance. The pushback clearance is
frequently given to the flight along with a taxiing clearance by a local controller. However, in
some large-sized and busy airports, the pushback process is controlled by the gate manager. The
pushback is the initial process of departure in which the flight trespasses the apron area from the
gate to the taxiway.
Once the aircraft arrives at the taxiway from the gate with a taxiing clearance, a flight starts
taxiing to the designated runway. (The flight needs to contact the ground controller if it has not
acquired a taxiing clearance.) The taxiing procedure is almost the same, but in reverse, to the
taxiing process for an arrival. The flight autonomously traverses the taxiing path given by a
ground controller. Usually, the (ground) controller does not interrupt a flight taxiing schedule,
unless there is some new expected congestion or conflict. If a controller anticipates congestion, he
or she can give the flight a command to slow, stop, or change the taxiing path. The goal of this
interruption is to reduce the congestion on the taxiway network and, at the same time, maximize
the utilization of the runway.

139

Start Communication

Put this flight strip to

progressing box.

Is controller busy?

Sending
Request
(t1)

No

Waiting
Command
(t2)

Receiving
Command
(t3)

Sending
Confirm.
(t4)

Yes
WaitNext
Comm.
(t0)

Ready to
comm.

End Communication

Sending
Confirm.
(t4)

Wait
Contact
Received clearance?
from
No
Controller (i.e., Delayed)

Receiving
Command
(t3)

Yes

Figure 5.4

State Diagram for Communication (Voice Channel).

Start Communication

Put this flight strip to

progressing box.

Sending
Request
(t1)

Is controller busy?

No

Waiting
Command
(t2)

Receiving
Command
(t3)

Sending
Confirm.
(t4)

Yes

End Communication

Ready to
comm.

Sending
Confirm.
(t4)

Receiving
Command
(t3)

Wait
Contact
from
Controller

Received Clearance?
No
(i.e., Delayed)
Yes

Figure 5.5

State Diagram for Communication (Data Link).

140

When the flight approaches the active runway, it is required to reduce its speed and contact the
local controller to obtain takeoff clearance. Note that the previous taxiing clearance is not a
clearance to enter onto the runway. If there is a queue of flights waiting for takeoff, the local
controller gives the takeoff clearance based on a first-come-first-served policy, ensuring a
particular airborne separation by spreading out the aircraft departure intervals [Luffsey, 1990].
The takeoff process is composed of two processes: 1) rolling process in which the flight gains the
speed required for lift-off, and 2) the lift-off process in which the aircraft starts to climb and
clears the far end runway threshold. In the simulation model, the departing flight is traced until it
reaches the runway threshold. The state diagram for a departing flight is illustrated in Figure 5.6.

B. State Diagram for Communication

Basically, the departing flight state diagram for communication is same as that of an arriving
flight.

141

yes

Parked
(at gate)

Call for
Pushback
Clearance

Call for
Taxi
Waiting to Clearance
Taxi

Pushingback

Received
Taxiing
Cleance
Communication

Recievd
Communication Pushback
Cleance?

Taxiing

Waiting in
Line
(R/W dep.
Queue)

No

No

Waiting to
Taxi

Gate Hold

Area
Holding
(Holding
Area)

Waiting
on
Runway

LiftOff

Rolling

(until initial climb rate (with const. accel.

and speed)
until flying speed)

Figure 5.6

Received
Take-off
Clearance

State Diagram for a Departing Flight.

142

Communication

no
clearance

Call for
Take-off
clearance

5.2.2.3

Controller

Depending on who initiates the communication, air traffic controlling processes can be divided
into two classes: 1) passive control in which the controller renders control messages to various
flight requests, and 2) active control in which the controller makes decisions mainly for
controlling the overall traffic flow. In the process of air traffic controlling, flight progress strips
(or flight strips for short) are used to store critical flight information such as flight number,
aircraft type, origin, destination or arriving route, etc. This information is printed in a rectangular
piece of paper, and stored in a plastic holder while the flight is under supervision of an air traffic
controller. In the simulation model, three type of flight strips are modeled: pending, processing
and completed flight strips (See Figure 5.7).

Completed
Flight Strips

Completed
Flight Strips

Processing
Flight Strips

Processing
Flight Strips

Pending
Flight Strips

Pending
Flight Strips

Ground controller's
flight strip organization

Figure 5.7

Local controller's
flight strip organization

Flight Progress Strip.

Initially, the controllers state starts with standby and all flight strips are in the pending box.
Receiving a request from a flight in the passive control mode, the controller places the
corresponding flight strip in the processing state and begins to judge the situation. The
controllers judgement depends on the flights current state. For example, if a flight is at the final
stage in the arrival process and it requests landing clearance, the controller needs to check the
flights relative position around other flights, and then make a decision on whether or not to allow

143

this flight to proceed (checking for minimum separation rules between flights). The controller
sends control messages to the flight and waits for confirmation. Once a confirmation is received
from the flight, the controller returns to the "standby" state and waits for another request. The
state transition diagram for the controller is depicted in Figure 5.8.

sive
Pas trol
n
Co

Standby

Receiving
Request

Activ
Con e
trol

Judging

Sending
Control
Message

Waiting
for
Confirm

Standby

Contacting
Flight

Figure 5.8

State Diagram for a Controller.

When the flight finishes its operation completely, the controller moves the flight strip from the
processing to the completed state. If a flight is still performing some activity but passes the limits
of a controller's custody (control boundary), then the current controller hands the fight strip over
another controller's processing state bin. For instance, if a flight exits the runway taxiing after
completion of the runway landing roll and starts taxiing to gate, then the flight strip moves from
the local controlle r's processing bin to the ground controller's processing bin.
If any traffic congestion or conflict is expected, controllers can intervene during aircraft taxiing,
issuing control messages to slow-down, speed-up, or even to stop aircraft at the current position.
This active control decision making process is largely based on the controllers experience,
subject to ATC rules enforced by the FAA. It is difficult to devise a single comprehensive traffic
management rule that is applicable to all ground control cases. For the simulation purpose, it
might be more practical to develop a rule -based decision making process for the active control
process.
A controller also initiates an active control process when the controller is in "standby" and there
is some flight in the state of "wait for controller's contact". In fact a controller realizes the
existence of flights awaiting controller's contact by checking the strips in the processing bin. The
communication process initiated by controller is shown in Figure 5.9.

144

Check need for

communication

Is this controller standby?

No

Yes
Any flight waiting
controller's contact in
progressing strips?

No

Yes
Select the flight
having earliest schedule
for controller to contact

Is it
appropriate time to contact
the selected flight?

No

Stop
Yes

Needs Communication

Start Communication

Judging
Request
(t2)

Sending
Command
(t3)

Receiving
Confirm.
(t4)

standby

End Communication

Figure 5.9

5.2.3

Communication Process Initiated by the Controllers.

Functional Model

The functional model consists of Data Flow Diagrams (DFDs) and defines processes within a
system, describing how output values of the program are derived from the input values. Later,
DFD is used to determine which objects send messages to other objects. DFD is composed of
three components: process, data flows actors, and data stores which are represented in the OMT
methodologies by ellipsess, rectangles and pairs of parallel lines, respectively. The OMT
specifies the following steps for constructing a functional model [Rumbaugh et al., 1991].
Step 1: Identify input and output values.
Step 2: Build data flow diagrams for each input to output transformation.
Step 3: Develop descriptions for each process in the DFDs.
Step 4: Identify constraints between objects.

145

Step5: Specify any optimization criteria, e.g., values to be maximized or minimized.

Figure 5.10 illustrates the input and output values of the simulation model at the highest level of
abtraction. Here, the user interface which is devised for users to control the program progress is
not included. This is consistent with the research nature of this model. The main goal of this
research poject is to develop a comuptational engine that drives the simulation model. There are
two kinds of inputs for the simulation model: 1) scenario data including the flights schedule,
aircraft types, gate information, etc., and 2) static data including the airport configuration, an
aircraft model data with aircraft dimensions, performance, etc. All these parameters remain
unchanged throughout the simulation.

Scenario data
(Flight schedule)

User
Statistics on
ground operation
(Delays, Work load,..)

DataBase

Ground
Simulation
Model

Airport Configuration Data,

Aircraft data
(Dimenstions,
performance,..)

Figure 5.10 Input and Output Values for the Simulation Model.
The top-level DFD for the simulation model is shown in Figure 5.11. The flight schedule
information provided by the user serves as the input data for generating the flight objects along
with the aircraft model data. The link and node data pertinent to the airport configuration is used
to generate the airport network graph, which in turn is used to define the flight taxi path
information. The controller objects are created internally, which means that no explicit input data
is involved in generating the controller object. Instead, the objects belonging to the airport graph
class and the flight class are imbeded in the controller objects.
The DFDs are typically shown as layered sets of diagrams because they are generally too large to
be shown on a single piece of paper. The decomposition of DFD continues until the processes
cannot be partitioned any further. Because of their complexity, lower-layered DFDs are omitted
here.

146

User

Scenario data

Read
Flight Schedule
Detailed
Flight Data

Object data
Generate
Flight Objects

Read
Aircraft Model
Data

Object data
Objects in
Memory
Generate
Controller Objects Object data

DataBase

Static data

Object data
Read
Network Data

Node, Link Dtata

Generate
Network Graph
Object

Object data

Figure 5.11 Top-Level of Data Flow Diagram (DFD) for VTASM.

147

Obje ct
data

Run Simulation

Statictics

5.3 Object-oriented Design (OOD) of Simulation Model

5.3.1

System Design

In system design, the strategic decisions are made at a high level about how the problem will be
solved. The system design includes finding answers to the following questions: 1) what
components libraries, database, networking mechanisms, windowing systems will be used, and
how should they be used; 2) how will tasks communicate; 3) how will tasks be allocated to
processors; 4) what is the target environment for the application; 5) will the application need to
run on multiple platforms, and 6) what programming language will be used to implement the
design [see Derr, 1995].
The main objective of this research is to develop the backbone of a simulation model that
considers decisions in response to questions 1, 2, and 3 which are directly related to the software
implementation. For code portability, the American National Standards Institute (ANSI) C++ is
used to address truly muti-platform compatibility. From the same reason, wxWindows is
preferable windowing libraries to any commercial ones such as MFC (Microsoft Foundation
Classes).

5.3.2

Object Design

Object design is concerned with a full specification of the classes, associations, attributes, and
methods necessary for implementing a solution to the problem. Algorithms and data structures are
also fully defined along with any internal objects needed for the implementation. The following
steps are typical in an object design phase [Rumbaugh et al., 1991 and Derr, 1995].
Step 1: Identify methods for each class which define all the required types of functions.
Step 2: Design algorithms to implement methods by choosing efficient ways of coding
algorithms, selecting appropriate data structures, and defining new internal classes and methods.
Step 3: Optimize access paths to data by adding association classes to minimize access time,
rearranging the processing order of algorithms for efficiency, and saving calculated data to avoid
re-calculations.
Step 4: Design a method for dynamic control by refining the methods for implementing the flow
of events in the dynamic model.

148

Step 5: Adjust class structures to increase inheritance.

Step 6: Design object associations.
Step 7: Represent object data.
Step 8: Hide data and package classes into modules.
For Step 2, standard flow charts are adopted to present the relevant algorithms. Traditionally,
three types of diagrams are used in some applications of OMT. These are the message hierarchy,
events trace, and object interaction diagrams (Derr, 1995) which are not considered in this
research. During the implementation, the design is translated into code using an object-oriented
programming language such as C++.

5.3.2.1

Algorithms

5.3.2.1.1 An Algorithm for Aircraft-following Behavior

As previously reviewed, the generalized vehicle -following model presented in Equation (2.2) can
be used to predict the acceleration (or deceleration) at time t for a following vehicle that considers
the kinematic state of a leading vehicle. The application of vehicle -following equations yields
various types of macroscopic traffic flow models (see Table 2.9).
A well-known car-following model used in transportation studies is described in Equation (5.1),
where the coefficient m and l are 0 and 2, respectively. The macroscopic version of this model is
known as the Greenshields model, and is one of the most frequently used models in traffic
engineering studies. Greenshields model has significant advantages, namely, that it is simple to
use and has shown good correlation between the model and field data.

a tn++ 1 t =

(vtn vnt +1 )
( xnt xtn +1 ) 2

(5.1)

t + t
where a n +1 : n+1th vehicles acceleration at t+t
vtn : n th vehicles speed at t+t

xnt : n th vehicles position at t+t

= u f , (u f = free flow speed).
Greenshields model results in the following equations, establishing relationships among three
fundamental traffic parameters: speed, density and traffic flow.

149

u = u f (1- k / k j )
q = u f k (1- k / k j )
k = k j (1- u / u f ),
where,

u: speed (km/hour)
u f : free flow speed
k: density (vehicles/km)
k j : jam density
q: flow (vehicle/hour).

It should be remarked that the models appropriateness in traffic studies does not necessarily
guarantee its goodness in representing aircraft behavior on the airfield. In fact, the parameters in
generalized vehicle -following model should be calibrated with field data to warrant its use in
airport studies. This is an open area of research for now.
If we assume that the Greenshield's model adequately represents the aircraft-following logic, then
another approach for aircraft-following model can be devised. [Van Aerde, 1998] Using the
Greenshields basic speed-headway relationship, the method first determines the so called
desired speed of the following aircraft at time t which is the desired to be reached at time t+t.
Then the acceleration (or deceleration) is determined considering the current speed and other
exogenous constraints related to the maximum permissible acceleration (or deceleration). The
procedure is outlined below.
Step 1: Determine the following aircraft desired speed to be reached at time t+t using
Greenshields basic speed-headway relationship.

vtd+ t = v f (1

Hj
Ht

),

(5.2)

d
where vt + t : following aircrafts desired speed at (t+t)
vf : free flow speed
Hj : headway at jam density
Ht : headway between the le ading vehicle and the following vehicle at
time t.

Step 2: Obtain the following aircraft acceleration for the time interval from t to t+t using the
simple kinematic equation.
a tn++1 t = (vtd+ t vt ) / t ; if a tn++1 t > amax then a tn++1 t = amax ,
t + t
t + t
if a n + 1 < d max then a n + 1 = d max .

150

(5.3)

t + t
Here, a n +1 : following aircraft acceleration during the period from t to t+t

vtd+ t : following aircraft desired speed at (t+t)

vt : following aircrafts current speed at time t

t: the predefined time interval
a max/d max: maximum acceleration/deceleration.
In order to limit the kinematic behavior of the aircraft within a reasonable range, a non-uniform
acceleration model is employed. This model assumes that the vehicles maximum ability to
accelerate (a max) decreases linearly as a function of speed (see Figure 5.12). Another
consideration for maximum deceleration (d max) is based on passenger comfort.

Maximum
Acceleration
(a)

k1=amax

a curr max= amax - amax / vmax* vcurr

a curr max

Speed (v)
vmax

v curr

Figure 5.12 Speed-Acceleration Relationship.

The non-uniform acceleration model is considered to be reasonable because it adopts a thrust

lapse rate with respect to aircraft speed. The same behavior has been adopted to describe the
aircraft kinematic behavior on taxiways and taxilanes except that the values of a max and vmax are
adjusted accordingly to reflect lower speeds on these links. The equation for the non-uniform
acceleration model is expressed as follows.

151

 dv
a = = k1 k 2 v
dt

(5.4)

where, k 1 , k 2 : constants
v: speed
a: acceleration.
The equations for the speed-time relation can be deduced by separation of variables and
integration of Equation (5.4).

v0

dv
=
( k1 k2 v)

v=

dt .
t

dx k1
= (1 ek t ) + v0e k t .
dt k2
2

(5.5)

The equation for the distance-time relationship is obtained in analogous way,

dv =
v

v0

x=

k1

(1 e k t ) + v0 e k t dt .
k2

k1
k
k
t 12 (1 e k t ) + 1 (1 e k t ) .
k2
k2
k2
2

(5.6)

By substituting (5.5) into (5.6), we obtain the acceleration-time relationship.

a=

dv
k t
= (k1 k2 v0 )e 2 .
dt

(5.7)

The resulting equations are summarized in Table 5.1. (In the case that a max and vmax are given,
Equation (5.5) is of the form a = a max kv , where, k = a max / vmax.) It should be remarked that the
analytical solutions presented are only applicable to the leading vehicle. This is because these
analytical solutions explain the behavior of a vehicle starting from an initial speed and
accelerating as rapidly as possible in uninterrupted traffic flow. In fact, it is difficult to derive a
closed-form solution to explain the following vehicle behavior. To overcome this shortcoming,
the vehicle -following equations are implemented as a continuous simulation model using
standard numerical integration techniques.

152

Table 5.1
Numerical
Solution
at =

a max kvt 1

Vt =

vt 1 + at 1 t

xt =

xt 1 +

*1)

vt + vt 1
t
2

Equations for the Non-Uniform Acceleration Model.

not given a max and vmax
( k k v )e k2t
1

2 0

k1
(1 e k t ) + v0e k t
k2
2

k (v max v 0 ) exp( kt ) *1)

v 0 + (vmax v0 )(1 exp( kt))

k1
k
k
t 12 (1 e k t ) + 1 (1 e k t )
k2
k2
k2
2

Analytical Solution
given a max and vmax

x0 + v 0 t + (vmax v0 )(t exp( kt) / k )

(v max v0 ) / k

k = a max / vmax

In order to compare the models resulting from Equations (5.1) and (5.3), consider the following
simple example. At a taxiway-runway intersection, four aircraft are waiting for advisories from a
local controller. Using the aircraft performance values shown below, we construct the resulting
time-space diagrams according to the vehicle -following models described by Equations (5.1) and
(5.3).
vf = 60 kph
vmax = 120 kph
a max = 2 m/s2
a emergency = -.6g -6 m/s2
Hj = 5 m.
The time-space diagram for the vehicle -following model described by Equation (5.1) is displayed
in Figure 5.13 (a). This plot corresponds to a classical Greenshields model (i.e., m=0 and l=2).
Figure 5.13 (b) illustrates the vehicle -following behavior using Van Aerdes model. As seen in
the graphs, there si a substantial difference in vehicle behavior. The two methods exhibit a
disagreement in the headway parameter. The second vehicle in the generalized car-following
model, in fact, does not seem to follow the first one. (The same outcome results even if dt is
changed to as small a number as 0.02 sec.) The behavioral patterns observed persist even for
small step sizes (dt = 0.02). Consequently, the modeling approach adopted in this research
follows Equation (5.2) and (5.3). Figure 5.14 illustrates a flowchart showing the necessary steps
to implement the aircraft-following models adopted in VTASM.

153

From Generalized Vehicle-following Model (m =0, l =2)

(dt = 0.2 sec.)

700.00

1st vehicle

Distance (m)

600.00
500.00

2nd vehicle
3rd vehicle

400.00

4th vehicle

300.00
200.00
100.00
0.00
0

10

20

30

40

50

60

70

50

60

70

-100.00

Time (seconds)

From Van Aerde's Model (1998)

(dt = 0.2 sec.)

700.00

1st vehicle
600.00

2nd vehicle
3rd vehicle

500.00

Distance (m)

4th vehicle
400.00
300.00
200.00
100.00
0.00
0

10

20

30

40

-100.00

Time (seconds)

Figure 5.13 Comparison of Aircraft-following Models.

154

Aircraft-Following Module

diffDist (H) = LeadingFlight->traveledDistInLink ThisFlight->traveledDistInLink

diffSpeed = LeadingFlight->currSpeed ThisFlight->currSpeed

which control algorithm?

Control algorithm
based on headway

Control algorithm
based on speed

currAccel = k*(diffDist - SD)

SD: Safety distance

currAccel = k*diffSpeed

Control algorithm
based on headway-speed
(GM model)

currAccel
= k (diffSpeed / diffDist)
if m = 1 then
currSpeed
= prevSpeed/ (1-k (diffSpeed /
diffDist))
k = alpha*dt

currAccel > a_max

yes
currAccel = a_max

no

currAccel < a_min

yes
no
currAccel = a_min

Next

Figure 5.14 Flowchart of Aircraft Following Module.

155

Control algorithm
based on headway-speed
(Van Aerde's Model)

des'dSpeed
= max(0, Sf (1 - Hj / diffDist))
currAccel
= (currSpeed - des'dSpeed )/dt

5.3.2.1.2 An Algorithm for Conflict Detection and Resolution

A. Algorithm for Conflict Detection.
In the simulation model developed, explicit checks for potential ground collisions are
implemented only for the first aircraft on a taxiway link crossing a check-point upstream of an
intersection. All other following aircraft on the same link are not directly affected by any
potential conflicts since they just follow the leading aircraft according to the aircraft-following
logic explained in the previous section. For the first aircraft, the conflict detection method
examines if there are any opposing aircraft on the adjacent links. One of following three
circumstances could potentially result in a conflict between two aircraft. (See Figure 5.15.)
Case 1) The next taxiway link for aircraft 1 (current aircraft) is open and the next taxiway
link for aircraft 2 (conflicting aircraft) is also open.
Case 2) The next taxiway link for aircraft 1 is blocked by aircraft 2 and the next taxiway link
for aircraft 2 is open.
Case 3) The next taxiway links for both aircraft 1 and 2 are blocked by another aircraft.

case 1)

case 2)

aircraft 1

aircraft 2

aircraft 1

aircraft 2

aircraft 2

case 3)

aircraft 1

Figure 5.15 Cases of Potential Ground Conflicts.

156

For Case 2, there is no alternative for aircraft 1 except to wait until aircraft 2 crosses the
intersection. In this case, the current aircraft needs to reduce its speed (or stop if necessary)
allowing the other aircraft to pass the intersection without a substantial speed reduction. If Case 3
is triggered, there is no outlet for both aircraft (grid lock case). If Case 1 is invoked, the arrival
times for two conflicting aircraft (aircraft 1 and 2, here) are estimated. If the expected arrival
times of two aircraft are too close to secure a predefined minimum gap, the resolution routines are
automatically invoked.
Consider the example shown in Figure 5.16. Assume that the current aircraft considered is F
and that the minimum gap for safe separation at the intersection is set to 15 seconds. Given that
F1s current speed is 20 mi/hr (about 30 ft/sec) and the normal deceleration to stop is 3 ft/sec2 , F1
needs 10 seconds and 150 ft. to stop normally. Let us assume that F1 checks the collision risk at
the point of 150 ft (i.e., 10 seconds in time) upstream from the intersection and that other aircraft,
F2 and F3, are expected to enter the intersection at times, 30 and 15 seconds, respectively. In this
hypothetical situation, unless a speed control adjustment is applied to some aircraft, the current
aircraft, F1, will violate the required minimum separation gap with respect to aircraft F3. In this
instance, a potential collision is detected and the ground conflict resolution logic is initiated at the
same time.

Second or later flights on this link

(These follow the leading flight
by vehicle-following logic)

First flight on this link

(Need to check
for potential collisions)

Conflicting flights coming

toward the common
intersection

10(sec)

15(sec)

F1

Current position
of flight

Start point
of Intersection

F3

Legend :

30(sec)

F2

the current operation direction

Figure 5.16 Concept of Conflict Detection.

157

Expected arrival time to

the common intersction
(ET i)

B. Algorithm for Conflict Resolution

In the ground collision resolution logic, two issues are involved: 1) the flight priority and 2) the
speed control logic. The controller can give a higher priority to certain flights over others with the
intent of improving the overall efficiency of the taxiway (or runway) operations. The higherpriority flight has a right-of-way whenever it conflicts with another flight having a lower-priority.
In other words, lower-priority flights should slow down or completely stop in order to secure a
minimum gap at the intersection. In this case, the deceleration rate for the lower-priority flight
can be estimated by using the speed-control logic. The following equations are involved in this
speed control logic procedure.
new
old
old
EATlow
= EATlow
+ max[minimu m gap - (EATlow
EAThigh ), 0] .

2 dist
v

current
low

on
v intersecti
low

new
= EATlow
.

on
vintersecti
= vcurrent

low
low

Hence, decellow =
Here

2 dist
new .
EATlow

on
v intersecti
v current
2 dist
low
low
=
.
new
new 2
EATlow
EATlow

(5.8)

new
old
EATlow
( EATlow ): the low priority flight's new (old) expected arrival time
at the intersection,
EAThigh : the high priority flights expected arrival time at the intersection,

v current
high : the low priority flight's present speed,
on
vintersecti
high
: the low priority flights speed at the intersection,

dist : distance from the current position to the intersection,

decelhigh : the low priority flights deceleration rate.

Figure 5.17 illustrates the basic speed relationships related to the conflict resolution logic. Here,
two areas encompassed by a dotted line and a solid line produce the distance from the current
position to the intersection. In the foregoing example shown in Figure 5.15, if two conflicting
aircraft (F1and F3) have the same priority, the current flight (F1) will have a right-of-way based
on the first-in-first-out (FIFO) rule. The deceleration rate for flight F3 will be determined by
Equation (5.8). The complete logical procedures for collision detection and resolution that are
implemented in the simulation model are Figure 5.18.

158

speed

v current
low
deceleration rate
(decel)

on
vintersecti
low

EAThigh

old
EATlow

new
EATlow

time

Min. Gap

Figure 5.17 Calculation of the Lower-priority Flights Decele ration Rate.

159

Start

No
any conflicting flight?

*update confFlight's states

CurrMoveState = delayAtCross
depTimeAtCross = sysTime + ET_this + min Gap

Yes

**update thisfFlight's states

currMoveState = delayAtCross
depTimeAtCross = sysTime + ET_conf + min Gap

No
|ETthis - ETconf | < min. gap

where,
ET: Expected arrival time to the cross

Yes
compare
thisFlightNextEdge (1) vs. confFlightCurrEdge
(2)
thisFlightCurrEdge (3) vs. confFlightNextEdge (4)

case 1:
(1) != (2) and (3) != (4)

>

thisPriority >=< confPriority

case 2-1:
(1) == (2) and (3) != (4)

case 2-2:
(1) != (2) and (3) == (4)

case 3:
(1) == (2) and (3) == (4)

update
thisfFlight's states**

update
confFlight's states*

No Outlet

<

=
(FIFO)
ETthis <= ETconf
Yes
update
confFlight's states*

No
update
thisfFlight's states**

Next

Figure 5.18 Flowchart for the Conflict Detection and Resolution Module

161

5.3.2.1.3 Algorithms for the Takeoff and Landing Procedures

A. Algorithms for the Takeoff Procedure
Once a departing flight reaches the runway and obtains takeoff clearance from the (local)
controller, it initiates the takeoff procedure using its maximum acceleration potential. The takeoff
procedure can be divided into two phases: the takeoff rolling phase and the lift-off phase [Trani,
et al., 1993]. As the aircraft speed reaches lift-off speed, the aircraft becomes airborne and wheels
off from the ground. These two phases of the takeoff procedure are depicted in Figure 5.19. To
simplify its implementation, the lift-off phase is assumed to be characterized by a constant speed
after lift-off. The simulation model keeps track of the departing flight until it crosses the runway
threshold. In general, the time from the lift-off point to the runway threshold is relatively small as
the aircraft travels at a high speed.
There are two important parameters related to the takeoff rolling analysis: the takeoff rolling
distance and the takeoff rolling time. These values are estimated in the simulation model using a
aircraft equation of motion that is integrated forward in time.

Lift-off point

Air Speed
Altitude

Disatance

Lift-o

ff

Exit

g
Rollin

Figure 5.19 Takeoff Procedure.

162

Runway
Taxiway

The steps for the takeoff roll analysis are illustrated in Figure 5.20. Following traditional
aerodynamic performance estimation calculations, the first step is to convert all atmospheric
conditions to an equivalent international atmospheric status. This is because the performance of
an aircraft engine is affected by the atmosphere around airport. Once the corrected engine thrust
has been estimated in Step 2, the takeoff roll distance is computed.
The takeoff rolling time estimation requires some knowledge of two aircraft aerodynamic
parameters: the drag coefficient (Cd ) and the lift coefficient (Cl ). Usually, these parameters are not
made public by aircraft manufacturers. Consequently, approximations are needed to estimate
takeoff rolling times via alternative methods. A simple alternative method adopted in this model
is an adaptation of takeoff roll algorithms used in the FAA Integrated Noise Model (INM 6.0).

Step 1: Find density altitude

and temperature altitude
for airport

Step 2: Find engine thrust

Step 3: Find takeoff roll

distance

Step 4-1: Find takeoff roll time

using C d, Cl

Step 4-2. Find takeoff roll time

using takeoff roll distance

Figure 5.20 Steps for the Takeoff Roll Analysis.

Step 1: Find density altitude and temperature altitude. Using ISA (the International Standard
Atmosphere) properties as shown in Table 5.2, the temperature at a given altitude can be
calculated using the standard temperature lapse rate [Lan, 1981]:
T = T0 + (h - h 0 ),
where T: temperature at altitude h (F),
T0 : temperature (F) and altitude at mean sea level (h 0 =0 ft),

163

h: airport elevation (ft),

h 0 : elevation of mean sea level (h 0 =0 ft),
: atmospheric temperature lapse rate (F/ft).
The pressure and density variations with altitude can be calculated using the following standard
thermodynamic equations:

= 1 + h = 1 6 .875 10 6 h ,
T0
T0

P T
=
=
P0 T0

1
R

= 1 +
T0

P T T
=
= 0 = =
0 P0 T T0
where,

1
R

= 5.2561,

1
1
R

= 4 .2561 ,

: temperature ratio at airports current altitude (which is the airport elevation here),
h: airport elevation (ft),
: pressure ratio at current aircraft altitude,
P: atmospheric pressure at altitude h (in lbs/ft2 or N/m2 ),
P0 : atmospheric pressure at sea level (in lbs/ft2 or N/m2 ),
: atmospheric temperature lapse rate (in F/ft or C/m),
R: thermal gas constant (in ft/R or m/K),
T0 : standard sea level temperature, absolute value (in R or K),
: atmospheric temperature lapse rate (inF/ft or C/m),
: air density ratio at aircrafts current altitude (by employing the ratio version of the
ideal gas law),
: air density at altitude h,
0 : air density at sea level standard condition.

To illustrate the use of the equations, suppose that a standard altimeter indicates an altitude of an
altitude of 15,000 ft when the ambient air temperature is 35 F. Let us accordingly calculate the
density altitude and the temperature altitude.
1) Density altitude:
At h = 15,000 ft, the standard temperature is 5.5 F (=59-0.00356616(15000)). Hence, the
atmosphere is not standard. Since the altimeter is a pressure gauge, it will read the correct
pressure. The correct pressure at that altitude would be 1194 psf (= 2116.2 (temperature ratio) ^
5.2561 = 2116.2 ( (5.5+459.7) / 518.7) ^ 5.2561) ).

164

Table 5.2

ISA

etc.

Conversion Factors and Properties of International Standard Atmosphere.

Gravity constant (g 0 )
Pressure (p 0 )
Temperature (T0 )
Air density (0 )
Absolute temperature (T)
Atmospheric
temperature
lapse rate ()
Thermal gas constant
Force
Weight
Length
Speed

SI unit
9.806 m/sec2
1.013105 N/m2
15 C
1.225kg/m3
K = C + 273.15

UK unit
32.17 ft/sec2
2116.2 lb/ft 2
59 F
0.002377 slug/ft 3
R = F + 459.7
-0.00356616 F/ft

29.26 m/K
Newton (kgm/sec2 )
kg
m
1 knot = 0.514 m/sec

53.35 ft/R
lb-force
pound
ft

Conversion Factor
1 lb/ft 2 = 47.880 N/m2 (=Pa)
F = 9/5(C+32)
1 slug = 14.59kg

1 lb-force = 4.448 Newton

1 pound = 0.453 kg
1 ft = 0.3048 m

(Source: Lan and Roskman (1981) at http://www.ex.ac.uk/cimt/dictunit/dictunit.htm#length).

p
1194
=
= 0.001406 (slug/ft 3 ) .
gRT 32 .17 (53 .35 )(35 + 459 .7)
0.001406
=
=
= 0 .5915 .
0 0.002377
=

= 1 6. 875 10 6 hd = 1 / 4.2561 = 0. 88393 .

1 0 .88393 = 16,883
Therefore, hd =
(ft).
6.875 10 6
2) Temperature altitude:
=

T 35 + 459 .7
=
= 0.95373 = 1 6.875 10 6 ht .
T0
518 .7

1 0.95373 = 6,730
Therefore, h t =
(ft).
6 .875 10 6

Density altitude

T
= = 1 6.875 10 6 h =
T0
0

4.2561

= 4.2561

Temperature altitude

165

Step 2: Compute the net thrust per engine for jets. The non-standard atmosphere net thrust per
engine for jets, Fn , is a function of calibrated airspeed v, and density altitude h d , is calculated
using the SAE-AIR-1845 thrust equation developed by Society of Automotive Engineers. The
non-ISA thrust equation accounts for thrust-reducing effects of hot temperatures at high altitudes
[INM Users Guide, 1996].
F jetn (v,hd ) = (h d )[Ep + Fp v + G1p h d + G2p h d 2 + Hp Ts (h d )],
where, F jetn : non-ISA thrust per engine for jets (lb),
(h d ): ISA pressure ratio at aircrafts density altitude h d ,
v: calibrated airspeed (kt),
h d : the aircrafts density altitude which is the elevation of the airfield in our
problem (ft),
Ts : ISA temperature at the aircrafts density altitude (C),
Ts = (5/9) (59 - 0.003566h d - 32),
Ep ,Fp ,G1p ,G2p ,Hp : the engine dependent regression constants which depend on the
jets power setting state (max-takeoff or max-climb) from INM database.
F jetcorrected = F jetn /.
The corrected net thrust per engine for props, Fprop corrected, is given by
F prop net-standrad = 325.87 p Pp / Vt ,
where, Fnet-standard : the standard atmosphere net thrust per engine for props,
p : propeller efficiency, which depends on the power-setting state,
Pp : net power engine (hp) for sea-level standard day,
Vt : true airspeed (kt) = Vc -1/2 .
F prop corrected = F prop net-standrad /.

Step 3: Find takeoff roll distance. For the analysis of takeoff rolling distance, the initial and final
values of aircraft altitude are given as the airport elevation. The horizontal distance traveled on
the ground is calculated after initial and final values of speed and thrust are calculated. The
procedure follows SAE-AIR-1845.
The takeoff rolling distance (S g ) is given by,

166

S g = B f

(mg / ) 2
N Fnet corrected

where , S g : takeoff roll distance (ft),

B f : an airplane specific coefficient for a given flap deflection combination,
m: aircraft mass (lb),
g: gravity acceleration (= 32.2 ft/sec2 ),
: temperature ratio at aircraft altitude,
: pressure ratio at aircraft altitude,
N: the number of engines per aircraft,
Fnet-corrected: corrected net thrust per engine (lb) at takeoff rotation.
Typical velocities for the calculation of thrust are,
v1 = 16 knots,
v2 = Cf (mg)1/2 ,
v2 = v2 /()1/2 ,
where, v1 : calibrated speed at the beginning of the takeoff roll maneuver (i.e., at the break
release point) predefined as 8.2 m/sec or 16 knots,
v2 : calibrated speed at the end of the takeoff roll maneuver (i.e., at lift-off point),
Cf : coefficient which depends on the flap setting (from the INM database),
v2 : true air speed at the end of the takeoff roll maneuver,
: air density ratio at aircraft altitude.
Step 4-1: Find takeoff roll time using Cl and Cd . Forces related to the takeoff roll distance are
[Trani, et al., 1993],
1
L = v 2 SCl ,
2
D=

1 2
v SCd ,
2

TE = f (v, ) ,

Ff =( mg cos L ) f roll ,
where, L = lifting force (lb),
D = drag force (lb),
TE: corrected net tractive effort (lb),
Ff : friction force (lb),
: air density (slugs/ft3 ),
S: the aircraft reference area (ft2 ),
Cl : lift coefficient which is dependent on the flap setting (non-dim),
Cd : drag coefficient which is dependent on the flap setting (non-dim),
f roll : rolling friction coefficient (non-dim) normally 0.02~0.03,

167

 : the runway inclination angle with respect to the horizontal (degree).

The forces in the x (horizontal direction) produce
ma x = TE (v , ) D (mg cos L ) f roll mg sin .

Hence,
ax =

1
(TE (v, ) D ( mg cos L ) froll mg sin ) .
m

Assuming a linear tractive effort lapse rate function of speed, the following expression can be
derived,
T T
TE (v) = T1 1 2 v ,
v2
where, TE: tractive force at speed v,
T1 , T2 : tractive force at brake release point, and lift-off point,
v2 : aircraft speed lift-off point.
Note that runways are near flat by regulation (i.e., less than 2% effective gradients () for general
aviation (GA) runways and 1.5% for transport runways) and thus for the takeoff analysis, the
angle can be neglected in most practical applications. Neglecting the effect of grade on the
acceleration of the vehicle, we can estimate the following accelerations for two reference
conditions: 1) at brake release (a x|br ), and 2) at the lift-off point (a x|lo ).

ax =

T1 T2 1 2
1

v v S (Cd Cl f roll ) mgfroll ,

T

m
v2 2

a x|br =

1
(T1 mgfroll ) ,
m

a x |lo =

1
1 2

T2 v2 S (Cd Cl f roll ) mgfroll .

m
2

If we further assume that the acceleration varies inversely with the speed range from the brake
release point to the lift-off point, the simplified acceleration at speed v can be evaluated as
follows:

168

 dv
a x = = a x|br
dt

ax| br a x|lo

v2

1
1 1

(T1 T2 ) + v22 S (CD Cl f roll ) mgfroll

1
m
m 2
v
= (T1 mgfroll )

m
v2

= k1 k 2 v ,

where, k1 =

1
(T1 mgfroll ) ,
m

1
1 1

(T1 T2 ) + v22 S (Cd Cl f roll ) mgfroll

m
m
2

k1 =

.
v2

By integrating once from the brake release speed (v1 ) to the lift-off speed (v2 ), the takeoff roll
time, troll , is estimated as

troll =

1 k1 k2 v2

.
k2 k1 k2 v1

Step 4-2: Find takeoff roll time without using Cl and Cd . Here, we introduce an alternative
method to approximate takeoff roll distances without any information on Cl and Cd . The
estimation is based on the assumption of a non-uniform acceleration model discussed earlier in
this section. The resulting equations for the acceleration, speed and distance-time relationships
are summarized in Table 2.9, and are depicted graphically in Figure 5.21. Here, Equations (5.9)(5.11) are used again.

a=

dv
= k1 k2v
dt

v=

dx k1
= (1 ek t ) + v0e k t .
dt k2

x=

k1
k
v
t 12 (1 e k t ) + 1 (1 e k t ) .
k2
k2
k2

(5.9)
2

(5.10)
2

(5.11)

169

By substitution of (5.10) into (5.11), we obtain

a=

dv
k t
= (k1 k2 v0 )e 2 .
dt

(5.12)

The next step is to find parameters k 1 and k 2 which characterize the Equations (5.10), (5.11) and
(5.12). Using the SAE-AIR-1845 model, assuming the speed at the beginning of the takeoff roll,
v1 (= vbr), to be 8.2 m/sec or 16 knots, and letting
v2 (= vlo ) : speed at the point of lift-off,
a 1 (= a br) : the acceleration at the beginning of takeoff roll,
a 2 : the acceleration at the beginning of lift-off,
the equation for the time to reach a certain speed v2 is derived from (5.10) as

t2 =

1 k1 k2 v2
.
ln
k2 k1 k2 v1

(5.13)

By substitution of (5.13) into (5.11), we obtain

x=

k1 1 k1 k2 v2
ln
k2 k2 k1 k 2v1

k1
2
k2

k k v
ln

1 e k k v + v12

2
1

2 2

2 1

k k v
ln

1 e k k v

2 2

2 1

(5.14)

Since the conditions at the beginning of takeoff roll are known, v = v1 , a = a 1 = a br, from (5.9), k 1
can be expressed as k 2 according to
k 1 = a1 + k 2 v1 .

(5.15)

Substituting (5.15) into (5.11), the equation for the distance as a function of k 2 can be obtained as

x=

a1 + k2 v1 1 ( a1 + k2 v1 ) k2 v2
ln
k2 k2 (a1 + k2 v1 ) k2 v1

( a +k v ) k v
ln
a1 + k2 v1

1 e ( a +k v )k v
2

k2
1

2 1

2 2

2 1

2 1

( a +k v ) k v
ln
v1
+ 2 1 e ( a +k v )k v
k
2

170

2 1

2 2

2 1

2 1

(5.16)

k1
k
v
t 12 (1 e k t ) + 1 (1 e k t )
k2
k2
k2
2

Distance ( x)

x=

v0
1

x2
t2

Time ( t)

Speed ( v)

k1 / k2

v=

dx k1
= (1 e k t ) + v1 ek t
dt k2
2

v2
v1

t2

Time ( t)

k1
a1

a1

a2

a=

t2

dv
= (k1 k2 v1 )e k t
dt
2

Acceleration ( a)

Acceleration ( a=dv/dt
)

k1-k2v1

a=
a2

v1

Time ( t)

v2
Speed ( v)

Figure 5.21 Non-Uniform Acceleration Model [Drew, 1968].

171

dv
= k1 k2 v
dt

k1/k2

Given v1 , v2 , a 1 and the takeoff roll distance, x (=S g ), there is only one unknown variable, k 2 in
Equation (5.16). Because k 2 cannot be readily represented in a closed-form, numerical methods
can be used to obtain k 2 . Once k 2 is available, k 1 is calculated using (5.16).
One important factor that should not be overlooked in the takeoff roll analysis is that two
variables, takeoff roll distance and time, are rather stochastic than deterministic. In other words,
these variables may also be explained with certain types of statistical distribution models
extracted from observed data.
In general, the stochastic behavior observed during the takeoff roll has been addressed by federal
regulation authorities by imposing a correction factor to distance calculated via analytical
methods. This correction factor increases the runway length by 15% to account for pilot
deviations in the takeoff roll. This criteria does not apply in this model since VTASM assumes
the runway length to be sufficient for landing and departing operations.
B. Algorithms for the Landing Procedure
The landing procedure can be divided into four phases: flare, free-rolling, braking, and coasting
phases. (See Figure 5.22). The flare segment begins at the moment when the aircraft crosses the
runway threshold and ends when the main landing gear touches down on the runway. Pilots tend
to maintain a conservative margin over the stalling speed (vstall ), which can be calculated by the
following equation. The initial speed of this phase, vfl , is empirically known to be about 1.25
times vstall .
Stall speed (vstall ) =

2mg
,
Cl max Aw

(5.17)

where m: the aircraft mass (kg)

g: gravity acceleration
: standard atmosphere air density (kg/m3 )
Cl max: maximum landing lift coefficient
Aw: the aircraft wing area (m2 ).
The flare distance (sair ) is measured from the runway threshold to the touchdown point and is
expressed mathematically as [Trani et al., 1993],
sair = dl + d c + RL
dl =

(5.18)

h th

(5.19)

172

v fl 2
dc =
2 g ( n fl 1)

(5.20)

RL =LRL,

(5.21)

where, sair : flare distance

d l : linear descending distance from the runway threshold to the touchdown
aiming point
d c: circular-arc flare maneuver distance for transiting to a touchdown attitude
with a minimum sink rate and
RL: the correction distance that is influenced by the runway le ngth.
Also,
vfl : threshold crossing airspeed (m/sec or ft/sec)
vtd : touchdown speed (m/sec or ft/sec)
sair : touchdown distance (m or ft)
h th : threshold crossing height (m or ft)
: tangent value of the descent flight path angle (degree),
g: acceleration of gravity (m/sec2 or ft/sec2 )
n fl : the flare load factor
L: correction distance factor (meter for every 100 m (328 ft) of runway length,
valid for 2100m < RL < 2800m)
RL: runway length
tair : duration time in flare (m or ft)
2 mg
CLmax Aw
m: the aircraft mass
g: gravity acceleration
: the standard atmosphere air density
CLmax: maximum landing lift coefficient
Aw: the aircraft wing area.
vstall =

The free-rolling phase starts at the point where the main gear touches down and ends when thrustreverse and/or braking are applied. It has been observed that the duration of the free-rolling phase
is about 1-3 seconds with an average deceleration rate of 0.70 m/sec2 [Trani et al., 1993].
The braking phase is initiated from the ending point of the free-rolling phase and completes at the
moment when the aircraft decelerates to the so-called decision speed (about 35 m/s for heavy
aircraft), when the pilots decide which exit will be used. According to the aircraft type, different
deceleration rates are applied in the braking phase.
Once the aircraft passes the decision point, it begins to coast to the runway exit. During the
coasting phase, the pilot controls the speed based on the current speed and distance between the
current point and the selected exit. To capture this dynamic behavior, a second-order feedback
control system is used in the model implementation.
The speed-distance profile among landing phases is sketched in Figure 5.23. The equations for
each phase are summarized in Table 5.3 along with some statistical parameters which are

173

observed to fit a normal distribution model quite well. Table 5.4 shows the landing the roll
statistics for various aircraft types observed at various airports [Kim et al., 1996].

Exit point

Touchdown Point

Air Speed
Altitude

Disatance
Runway

CO

Taxiway

Exit

BR
FR

FL
FL : Flare
FR: Free-rolling
BR: Braking
CO: Coasting

Figure 5.22 Four Phases in the Landing Procedure.

Speed

Crossing
Threshold
(Speed: v fl )

Initial Brake
(Speed: v br )

Decision Point
(Speed: v co
27 mps for Wt<41,000 lb
35 mps for Wt>41,000 lb)
Touchdown
Speed: v td
Exiting
(Speed: v

s air

sfr1

sbr

s co

(Flare)

(Free RollFast)

(Braking)

(Coasting)

= f(exit type))

ex

Distance

Figure 5.23 Speed-Distance Relationship for the Landing Procedure.

174

Table 5.3
Phase

Initial Speed

Equations describing the Aircraft Landing Phases.

Ending Speed

Distance
s fl =

Flare 1)

vfl

vtd

Duration

hth

t fl =

v fl
2 g (n fl 1)

s fl
(v fl + vtd ) / 2

Acceleration

a fl =

(vtd v fl )
t fl

Braking 3)

vtd

vbr

vbr = vtd a frtfr

vco= vbr a brtbr

s fr = vtd t fr

s br = vbr tbr

a fr t 2fr

tfr

af

tbr

a br

a br tbr2
2

sco
tco
(by 2nd -order feedback(by 2nd -order feedback
control)
control)
1) vfl : threshold crossing airspeed (m/s or ft/s)
vtd : touchdown speed (m/s or ft/s)
sair : touchdown distance (m or ft)
h th : threshold crossing height (m or ft)
: tangent value of the descent flight path angle (degree)
g: acceleration of gravity (m/s2 or ft/s2 )
n fl : the flare load factor (DIM)

Coasting 4)

vco

(or ~ N(v fl , 0.06 v fl ) )

vtd 0.95 vfl (or vfl 3.2)
tfr = 2~3 seconds
a fr 0.7 m/sec2
tbr = time to decelerate to the speed of
27mps for wt < 41000 lb
35mps for wt > 41000 lb
a br = f(aircraft type)5)
B727~N(2.19, 0.4162 )
B737~N(2.25, 0.4712 )
B757~N(2.01, 0.4782 )
DC-9~N(2.03, 0.4142 )
MD-80~N(2.05, 0.3872 )
vex = f(exit type)
2

+ L RL

Free Rolling 2)

Empirical values
2.5~3 degree (or ~N(2.75, 0.082 ))
h th 15.2 m (= 50ft) (or ~N(15.2, 32 ))
n fl = 1.1~1.3
L +25m (=82 ft)/100m runway length
vfl 0.95 vap 1.25 vstall

vex

178

a co

(RL): correction distance (meter for every 100 m (328 ft) of runway length, valid for 2100m < RL < 2800m).
tair : Duration time in flaring out (m or ft)
2 mg
CLmax Aw
m: the aircraft mass
g: gravity acceleration
: air density
CLmax: maximum landing lift coefficient
Aw: the aircraft wing area
2) vbr : Initial braking speed (m/s or ft/s)
a fr : Average free-rolling deceleration (m/s2 or ft/s2 )
tfr : Free-rolling time (seconds)
3) vco: Initial coasting speed (m/s or ft/s)
a br : Average braking deceleration (m/sec2 or ft/s2 )
tbr : Braking time (seconds)
4) vex: Exit speed (m/sec or ft/s)
5) Kim, et al., 1996.
vstall =

179

Table 5.4
Airport
(Runway)

1)

Runway
Length

Grade 1)
(%)

DCA
(R36)

2094 m
(6869 ft)

CLT
(R23)

2286 m
(7500 ft)

-0.5

ATL
(R8L)

2742 m
(9000 ft)

-0.3

Landing-roll Statistics [Kim et al., 1996].

Aircraft
Type

No. of
Obs.

B-727
B-737
B-757
DC-9
MD-80
B-727
B-737
B-757
DC-9
MD-80
B-727
B-737
B-757
DC-9
MD-80

72
36
26
36
51
13
34
4
8
7
13
12
10
13
28

Flaring speed
(m/s)
Mean
S.D.
66.62
3.03
65.77
3.99
65.30
5.78
65.02
3.54
68.29
4.51
68.18
3.16
66.08
3.57
61.55
2.11
67.34
3.46
66.60
2.55
70.87
3.87
68.74
4.34
65.28
5.29
68.85
3.9
68.57
4.97

Touchdown distance
(m)
Mean
S.D.
455.0
132.1
399.2
80.0
424.9
97.7
434.9
105.8
434.3
94.1
546.9
169.8
400.0
77.4
489.6
139.7
425.2
79.6
550.6
188.3
621.7
164.2
603.3
75.9
699.9
115.4
594.0
137.9
569.7
124.6

Deceleration rate decreases by 0.01 m/sec2 (0.033 ft/sec2 ) per 0.1% of grade change on runway.

180

Braking deceleration
(m/s2 )
Mean
S.D.
2.26
0.382
2.30
0.422
2.14
0.675
2.08
0.397
2.14
0.428
1.83
0.511
2.21
0.573
1.62
0.231
2.08
0.56
1.81
0.381
2.11
0.423
2.08
0.497
1.79
0.337
1.83
0.341
1.90
0.302

5.3.2.2

Data Structures

Data structures play an important role in designing an efficient computer code because they
govern the organization of the model information, and thereby constitute the basis for good
algorithms. Two types of data structures are mainly used in implementing our simulation model:
lists and queues.
A list is a finite, ordered sequence of data items known as elements (ordered in the definition
means that each ele ment has a position in the list). There are two implementations of a list: a
static array-based list, and a dynamic linked list using pointers. In an array-based list, the size of
the array should be fixed before the array is created. On the other hand, the linked list is dynamic
in the sense that it allocates memory for new list elements as needed. There are advantages in the
dynamic linked list such as added flexibility in programming. However, the linked list needs extra
space to keep a pointer that indicates the next element of the list (in singly-linked list case). In
terms of computational cost, the array-based list is faster in accessing the ith element and
appending an element to the tail of the array. Operations to remove and insert an element are
relatively expensive. As a rule of thumb, linked lists are a better choice when working with
vectors whose sizes are unknown or which vary widely. Array-based lists are generally more
space efficient when the user knows in advance the size of the list [Shaffer, 1997]. Computational
efficiencies of the two lists are compared in Table 5.5.

Table 5.5
advantage
access ith element

Comparison of List Implementations.

Array-based list
no wasted space for an
individual element
(1) a)

Linked list
Need space for the objects
actually on the list
(i)

append an element
(1)
(1)
insert ith element
(i)
(1)
remove ith element
(i)
(1)
(big-theta) indicates that the upper-bound, O(big-oh), and the lower bound, (big-omega),
are the same.

cost
a)

The array-based list is used in the simulation model to store information about nodes and links.
This is efficient because the numbers of nodes and links at an airport are known in advance and
can be assumed to remain unchanged during the period of simulation. This is similar to the
database for the aircraft characteristics because the number of aircraft types is also limited and

181

fixed. Figures 5.29 and 5.30 illustrate the applications of array-based lists to the node data and
aircraft data, respectively.

Node Object

Index
0
1
2

Number of
Nodes

int Id

Point Pt (x,y)

9981

(34.12,67.212)

Flight*
FlightInNode_p

Figure 5.24 Array-based List for Node Data.

Acft_Model Object

Index
0
1
2

Number of
Acft_Model

Char* Id_str

Float WingSpan_ft

B747-100

110.45

Float
MaxAccel_m
0.5

Figure 5.25 Array-based List for Aircraft Model Data.

In contrast, the number of flights on the flight schedule dynamically changes according to the
day, or time of day. The taxiing path between the gate and the runway for a flight is also flexible
in the sense that the number of links defining taxiing paths is not fixed. In these cases, a linked
list, particularly a singly-linked list, is adopted to maintain the information regarding the flight
schedules and taxiing paths. Figures 5.31 and 5.32 show describe the implementation of linked
lists for these two variable size vectors.

char* Id_str

Flight* NextFlightInList_p
Flight*
LeadingFlight_p
Flight* FollowingFlight_p
Edge* Taxipath

AA352

US987

NW312

Figure 5.26 Singly-Linked List for Edge Data.

182

UA490

UA093

TaxiEdge Obj.

Edge*
EdgeEle

TaxiEdge Obj.

TaxiEdge Obj.

TaxiEdge*
NextTaxiEdge_p

Edge*
EdgeEle

TaxiEdge*
NextTaxiEdge_p

Edge*
EdgeEle

TaxiEdge*
NextTaxiEdge_p
NULL

Figure 5.27 Singly-Linked List for Taxiing Path Data.

The adjacency list, which is commonly applied in graph theory, is used for representing the
networks within the simulation model. (For more details, see Figure 2.22.) In practice, an array of
a singly-linked list having n| | items is applied to the adjacency list, where |n | is the number of
nodes. A sample network and an array for a linked list are shown in Figure 5.28.

1
4

5
2

Edge

Edge

Node

0
1
2
3
4
5

fNode

Tnode

0
1
2
3
4

1
2
5
4
5

Next
E_p

fNode

tNode

0
1

2
4

Edge

Next
E_p

fNode

tNode

Next
E_p

Figure 5.28 Sample Network and Array of Singly-Linked List for the Sample Network.

183

A FIFO queue (See Figure 3. 8) is a form of a restricted list, in which an element may only be
entered at the back and removed from the front of the list. The service line at a bank is a typical
example of a queuing system. The aircraft in a link can be also described by a queuing system.
An aircraft entering into a new taxiway link is stored at the end of the queue.
As reviewed in the previous chapter (see Table 3.6), the sorted queue and the (output-restricted)
double-ended queue are used in the implementation of the static shortest path algorithm and the
time-dependent shortest path algorithm respectively. Table 5.6 summarizes the resulting data
structures used in the implementation of the simulation model.

Table 5.6

Summary of Data Structures Used in the Simulation Model.

Data structure type

Data
Node,
Link
Flight schedule,
Taxiing path
Airport Network
Dijkstra algorithm
Aircraft on the link
Time-dependent
shortest path algorithm

array-based list
List
linked list
Array of linked list
sorted queue
FIFO queue
Queue
output-restricted
double-ended queue

5.3.2.3

Flowcharts

The last step in the object model in OMT is to write pseudo-codes for algorithms or other related
methods. Instead of pseudo codes, our approach is to use flowcharts showing the details of the
coding process graphically. Figure 5.29 depicts the procedural flows for the complete simulation
model.
The initialization procedure is illustrated in Figure 5.30. Basic objects such as the network graph,
flights and controllers are generated and initialized after all related data is read from the input file.
(See Appendix A for the list of input data.) A controller object calculates the shortest path
between all nodes defining the airport network. The allocation of flights to each controller is also
done during the initialization procedure. Some of the important variables associated with flights
and air traffic controllers and their initial states are summarized in Table 5.7. Communication and
movements are two types of activities involved in the aircraft flight behavior. The efficient
organization of these activities centers around two event times named nextCommEventTime

184

and nextMoveEventTime which are created inside the flight objects (more detailed member
variables and functions are included in Appendix C).
The main part of the simulation model is executed in such a way that the states of all entities i.e.,
flights, ground controller(s), local controller(s), in the system are updated every time interval until
the simulation time ends. Two types of loops are involved in this process: an outer loop where the
system clock proceeds by a time increment (t) until the simulation ends, and an inner loop
where the states of all flights in the system are checked and updated successively.
Table 5.7

The Initial States of the Simulation Model Variables.

object

variable
currState
controller
nextEventTime
currCommState
nextCommEventTime
currMoveState
nextMoveEventTime
position
flight
speed
acceleration
needToComm
collisionChecked
permission
State for arrival/departure.

initial state
standby
simulationDuration
readyToCommunicate
simulationDuration
parking/onFinal*
scheduled time
gate/runway threshold
0.0/final approach speed
0.0
false
false
undecided

Inside the inner loop, a check is made for each flights time clock to determine the movement.
ock is initially set to the time given in the flight schedule. When the system
clock advances and passes the flights scheduled time, the flight executes the two major activities
related to communication and movement within the outer loop. Otherwise, all the processes
inside the outer loop are just skipped.
Unlike the flight movement which is checked continuously, the communication activities are
treated as discrete events. This is because a communication event is scheduled only when it is
necessary. Communication states in both controller and flight objects change in a discrete
fashion. The module named checkNeedToComm and illustrated in Figure 5.31 checks if a
flight requires communication with either the local or the ground controller. If a flight attempts to
communicate, two state variables, needToComm and nextCommEventTime are set to true
and the current system time, respectively. The communication module (shown in Figure 5.3)
initiates the communication events and changes the flight movement state if it is permitted to
move.

185

In Figure 5.33, a communication process is depicted from the flights point of view. Here, the
state variable called nextCommEventTime is updated according to the time duration required
for the current communication activity. On the other hand, the controllers communication states
change according to the corresponding flights current communication state as shown in Figure
5.34.
It should be noticed that a function called judge mimics the controllers decision process on
whether a flight request is accepted. This function changes the controllers state via
judgingCommand. If the controller decision is to accept a flight to move and end
communication, the flights nextCommEventTime is set to the simulation duration so that the
flight can jump the communication procedure until it needs to communicate again. Usually, the
taxiing clearances from the local controller are provided with the taxiing route from the runway
exit to the gate.
The states of flight movement such as speed, acceleration, position, etc., are continuously
evaluated after a flight enters the system. The main concern in the movement logic is to decide
how much the flight would accelerate (or decelerate) in the next time interval. Unless a flight is
either stopped, parked at a gate, or waiting on a runway, the flights dynamic behavior is decided
by its own control logic depending on its current movement state. For example, if an arriving
flight is in the coasting phase on the runway, its acceleration for the next time interval is
determined by the second-order feedback control system discussed in the previous section.
Acceleration (or deceleration) during taxiing is a little more complicated because it might depend
on a leading aircraft, if any, on potential collisions, and on the remaining distance to the
destination for taxiing, etc. The detailed processes to decide the acceleration for a taxiing flight
are summarized in Figure 5.36, and the flowchart for the conflict detection and resolution
algorithm is previously shown in Figure 5.18.
The last procedure inside the inner loop is to update the flight kinematic states to reflect the
current changes according to the new acceleration value selected. This is done by the update
module shown in Figure 5.37. In the case that a flight enters a new link, the flight information on
its leading and following flight as well as the link information are updated by enqueue and
Once the complete procedure for a flight has been executed, a check is made to decide if this
flight is the last one on the list. If it is the last one, the inner loop is completed, and both ground
and local controllers start to check if there is any flight awaiting controller's contact by looking at
their flight progress strips. If there is any flight and the controller are both in standby states,
contact is made by the controller. (See Figure 5.9 for details.) Once all controllers finish an

186

appropriate action, the simulation time advances by a time increment to commence another
iteration of the outer loop (see Figure 5.29).

Initialization
// read data
//generate network grap, controller, flights

sysTime = 0

Flight = 1st Flight in List

No

sysTime == nextMoveEventTime ?
Yes
call checkNeedToCommunicate

needToComm == True &&

sysTime == nextCommEventTime ?

No
Inner Loop

Yes
Communication

Outer Loop
8

Movement
10
Last Flight
in the flight list?

No

Flight = nextFlight

Yes

Contact the Flight

Yes

Contact the Flight

No

sysTime = sysTime + dt

Yes
Does GC need to
contact any flight?
No
Does LC need to
contact any flight?
No
sysTime == simDuration?
Yes
End

Figure 5.29 Flowchart for the Overall Simulation Model Process.

187

read Node Data

read Link Data

generate
Network Graph

read Flight Plan Data

generate and initialize

Controllers
(local/ground)

calculate
- Initial travel times
- Initial minimum path
allocate
- the control area to each controller
allocate
- flights to controllers by the current
poistion

Next

Figure 5.30 Flowchart for the Initialization Step.

188

read Aircraft Model Data

generate and initialize

Flights

Parking
Departure
Start

permission != clearToTaxi
&& nextCommEvevtTime ==
simulationDuration ?

waitingToTaxi

Yes

currMoveState
needToComm = False
areaHolding

No

permission != clearToTakeoff
&& nextCommEvevtTime ==
simulationDuration ?

Wating on R/W

Yes

Operation Type?
No

needToComm = True
nextCommEventTime
= sysTime
Arrival

permission != clearToLand
&& nextCommEvevtTime ==
simulationDuration ?

onFinal

currMoveType

No

Yes

Exting R/W
permission != clearToTaxi
&& nextCommEvevtTime ==
simulationDuration ?

waitingToTaxi

No

Figure 5.31 Flowchart for Performing Communication Checks.

189

Yes

next

Parking

call
communicateGroundController
*
permission == clearToTaxi?

Yes

call makeTaxiEgdeList
currMoveState = TaxingToDepartureQueue
update currtaxiEgde_p
enQueue(currtaxiEgde_p)

Departure
No

waitingToTaxi

call
communicateGroundController
*

currMoveState
areaHolding

permission == clearToTaxi?

Start

Yes

currMoveState = TaxingToDepartureQueue
8

No

Operation Type?

Wating on R/W

call
communicateLocalController
*
permission == clearToTakeoff?

Yes

No
onFinal

call
communicateLocalController
*
permission == clearToLand?

Yes

Arrival
No
currMoveType

Exting R/W

Yes

No
waitingToTaxi

currMoveState = flaringOut
update currRunwayEgde_p
enQueue(currRunwayEgde_p)

call
communicateGroundController
*

permission == clearToTaxi?
*Parameters
- currMoveState,
- currCommState,
- currPosition
- finalDestination(Dep. Queue)

currMoveState = rolling
update currRunwayEgde_p //taxingPath
enQueue(currRunwayEgde_p)

call makeTaxiEgdeList
currMoveState = TaxingToGate
update currtaxiEgde_p //taxing Path
enQueue(currtaxiEgde_p)
8

call
communicateGroundController
*
permission == clearToTaxi?

Yes
No

Figure 5.32 Flowchart for the Communication Logic .

190

currMoveState = TaxingToGate
8

next

Communicate Module for Flight

this->currCommState

readyToCommunicate

No

waitingCommand

sendingRequest

receivingCommand

sendingComfirmation

currControllerCommState
== standby ?

Yes
currFlightCommState =
needToCommunicate

currFlightCommState =
sendingRequest

nextCommEventTime=
nextCommEventTime=
sysTime +
sysTime +
sendingRequestTime
waitingToContactTime

currFlightCommState =
waitingCommand

currFlightCommState =
receivingCommand

currFlightCommState =
sendingConfirmation

nextCommEventTime=
sysTime +
sendingCommandTime

nextCommEventTime=
sysTime +
sendingCommandTime

nextCommEventTime=
sysTime +
sendingConfirmTime

call communicate
for controller

Figure 5.33 Flowchart for the Communication Module from the Flights Point of View.

191

currFlightCommState =
readyToCommunicate
nextCommtEventTime =
simulationDuration

Communicate Module for Controller

currFlightCommState

sendingRequest

waitingCommand

currState =
receivingRequest

currState =
judgingCommand

assign currFlightComm_p

decision = call judge

nextEventTime=
sysTime +
receivingRequestTime

nextEventTime=
sysTime +
judgingCommandTime

receivingCommand

sendingComfirmation

readyToCommunicate

currCommState =
sendingCommand

currCommState =
receivingConfirmation

nextEventTime=
sysTime +
sendingCommandTime

nextEventTime=
sysTime +
receivingConfirmTime

currCommState =
stanby
nextEventTime =
simulationDuration

Yes

No
decision == clearToTaxi*

currFlight's permission =
clearTotaxi*
nextCommtEventTime =
SimulationDuration

* For the local controller,

clearTotakeoff or clearToLand

nextCommtEventTime =
sysTime +
waitingToContactTime

call communicate
for controller

Figure 5.34 Flowchart for the Communication Logic from the Controllers Point of View.

192

taxingToDQ

currentPosition == destination?

Yes
No

Departure

delayedAtCross

sysTime > depTimeAtCross ?

Rolling

Yes

Yes
No

currentPosition == runway end?

others

10

flaringOut

10

Yes

No
duration >= flaringOut time?

currMoveState = liftingOff

10

call roll //calc. acceleration

Start

Operation Type?

currMoveState = taxingToDQ
call taxiToDest //calc. acceleration

currentSpeed == liftoffSpeed?

liftingOff

10

call taxiToDest //calc. acceleration

No
currMoveState

currMoveState = waitingOnRunway

currMoveState = endOfDeparture
call statistics
call delete(thisFlight)

10

call roll //calc. acceleration

Yes

No

currMoveState = freeRolling

10

call move
//update dynamic states

call flaringOutt //calc. acceleration

10

freeRolling

duration >= freeRolling time?

Arrival

currMoveType

Yes
No

braking

currentSpeed == decisionSpeed?

Yes

distToExit == 0.0 ?

Yes

currentPosition ==
end of runwy exit?

Yes

currentPosition == runway end?

Yes

others

sysTime > depTimeAtCross ?

10

currMoveState = taxingToGate
orgNode = end of runwy exit
desNode = gate

currMoveState = parking
call statistics

currMoveState = taxingToGate
call taxiToDest //calc. acceleration

Figure 5.35 Flowchart for the Movement Logic.

193

10

10

10

call taxiToDest //calc. acceleration

Yes

No

currMoveState = exitingRunway
orgNode = begin of runwy exit
desNode = end of runwy exit

call taxiToDest //calc. acceleration

No
delayedAtCross

10

call findDistToExit
call coast(distToExit) //calc. accel.

No
taxingToGate

currMoveState = coasting
call brake //calc. acceleration

No

exitingRunway

10

call freeRoll //calc. acceleration

No

coasting

currMoveState = braking

10

next

taxiToDest

computeNextTaxiAccel

No

this == leadingFlightInEdge ?

Yes

Yes

restTimeTotaxiDestination <
normStopDist

No

(i.e., This link is the last

one before the taxiing
destination)

restTimeToCross < 1.5* normStopDist

Yes
No
collisionChecked == notYet

Yes

call collisionDetectResolve

currentMoveState == delayedAtCross

call
Car-following Module

call nextAccel_1

call nextAccel_2
a=

spd 22 spd12

a=

2 restDistTo Stop

normSpd currSpd
dt

call nextAccel_3
a=

2 restDistTo Stop
currSpeed

Move

Figure 5.36 Flowchart for the Computation of the Next Acceleration for Taxiing.

194

Update Flight's dynamic state

prevSpeed = currSpeed
currSpeed = currSpeed + currAccel * dt
traveledDistInLink +=
(prevSpeed + currSpeed)/2 *dt
traveledDistTotal += traveledDist
update
currPosition_p-> traveledDistInLink,
currPosition_p-> pt.x,
currPosition_p-> pt.y.

No

traveledDistInLink >= currEdge_p.distance

Yes
(Enter the new link )

traveledDistInLink - = currEdge_p.distance
update
currPosition_p-> traveledDistInLink,
currPosition_p-> pt.x,
currPosition_p-> pt.y.
currNodeIndex,
currTaxiEdge_p.
this->deQueue(currTaxiEdge_p)
this->enQueue(nextTaxiEdge_p)

Next

Figure 5.37 Flowchart for Updating Flights Dynamic States.

195

5.3.2.4

Detailed Object Design Model

Once the algorithmic steps have been implemented using appropriate data structures, the model
development cycle continues with a refinement of classes according to the following guidelines.

Adjust class structures to increase inheritance: In order to increase inheritance, it is necessary

to abstract out any behavior that is common to a group of classes. In our case, such behaviors
as finding shortest path and making taxiing path are common to both the ground
controller and the local controller classes. These methods are placed in the super class,
controller. While the inheritance happens to be an is-a relationship, the aggregation is said
-a rela tionship in the representation of classes. In the simulation model, many
aggregation relationships are found. For example, a node class has a point class which
contains information on the coordinates of a point, and an edge class which represents a
taxiway link has two node classes corresponding to the from node and the to node. A graph
class which contains the airport network information has an edge list consisting of a special
number of edges.

Design associations: Unlike inheritance or aggregation, the association between classes is

often referred to as a use-a relationship. For example, the controller class uses (one or
more) queue classes when a controller generates the shortest paths for all O-D pairs.

The attributes and member functions for all defined classes in the simulation model are
summarized in Appendix C.

196

5.4

Object-oriented Programming (OOP)

The computer language selected for the simulation model is C++ which is one of the most
popular object-oriented programming computer languages. In order to enhance the portability of
the simulation model, all libraries used in the model are based on the ANSI C++ rather than
using commercialized versions of the C++ libraries. In this research project, no graphic
representation or GUI (Graphic User Interface) is considered. For the future development of a
windowing GUI system, it is recommended to use the wxWindow library which provides a
better multi-platform portability when compared to other commercial libraries such as the
Microsoft Foundation Cla sses (MFC).
Once the simulation model is coded, the last step is the debugging and validation phase to check
if the code is performing as expected. Several tips are recommended for debugging [May, 1990].

Debug each member function separately.

Use known deterministic data rather than stochastic data.

Perform manual calculations to check.

197

5.5 Primary Validation of the Simulation Model

The validation step is the process whereby the simulation model is evaluated to determine
whether it satisfactorily duplicates the real system behavior [Drew, 1966]. In order to match the
simulation model output with real-life observations, a calibration process should be performed
using collected input data and measures of effectiveness (MOE). In this research, the calibration
process considers accepted models of behavior and compares them with the output from the
simulation model. VTASM is a proof-of-concept research model and further validation is needed
for commercial use.
Table 5.8 shows a hypothetical flight schedule consisting of 20 flights scheduled in about 5
minutes. Here, the relatively tight flight schedule is intentional to produce conflicts on the
taxiway system. It is assumed that all flights use one runway 01, and all aircraft represent
transport type operations. The aircraft mix is set to be 70/30 (large/small).
Important simulation outputs include information on the flight states at every simulation interval,
such as movement state, current communication state, speed, acceleration, current position,
traveled distances etc. Figure 5.38 shows a sample output of the simulation results. The timespace diagram shown in Figure 5.39 depicts the behavior of four departing aircraft starting from
one common gate to the same runway.
A close examination of this figure confirms that headways between the aircraft are kept during
the taxiing phase, and the minimum separation rules for the takeoff aircraft are maintained. A
more detailed takeoff profile is illustrated in Figure 5.40. Figure 5.41 also ratifies the minimal
separations between successive landing aircraft. It is shown in Figure 5.42 that landing distances
and runway occupancy times presented in Table 5.3 are reproduced with good accuracy.
For the aircraft-following model defined in Equation (5.2), Hj and vf are set to 83 ft/aircraft, 41
ft/s respectively. Figure 5.43 shows that headway between two leading and following aircraft
correlates well with the speed and vehicle -following control laws stated in the Equation (5.2). In
this Figure, some discrete speeding phenomena is observed following the aircraft transition
through various taxiway links. This behavior is explained when the following aircraft returns to a
normal taxiing speed, once it becomes the leading aircraft on a link.

198

Table 5.8

Flight #
AA001
AA002
AA003
AA004
AA005
AA006
AA007
AA008
AA009
AA010
AA101
AA102
AA103
AA104
AA105
AA106
AA107
AA108
AA109
AA110

Aircraft
Type
B727-100
B727-100
SF340
B727-100
B727-100
B727-100
SF340
B727-100
B727-100
SF340
B727-100
B727-100
B727-100
SF340
B727-100
B727-100
SF340
SF340
B727-100
B727-100

Operation
Type
D
D
D
D
D
D
D
D
D
D
A
A
A
A
A
A
A
A
A
A

Hypothetical Flight Schedule.

Hour
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7

Schedule Time
Minute
Second
0
0
0
4
0
20
0
40
0
50
0
30
0
10
0
45
0
25
0
30
1
0
3
1
3
2
3
3
1
12
1
45
1
20
5
3
3
0
2
1

199

Gate

Runway

1
1
2
2
3
3
4
4
4
4
11
11
12
12
10
10
10
9
9
9

36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36

Time FLT #

(x, y)

currCommState

currMoveState

speed

accel

currLink linkLength distInLink

totDist

60.5 AA378 (3.55881,6.15414) readyToCommunicate taxiingToDepQue

AA789 (3.55850,6.15410) readyToCommunic ate parking
AA790 (3.55850,6.15410) readyToCommunicate parking
AA791 (3.55850,6.15410) readyToCommunicate parking

3.20622 15.6622
0.00000 0.0000
0.00000 0.0000
0.00000 0.0000

4 -> 1016 157.659 0.324311 0.324311

0 -> 0
0
0.000000 0.000000
0 -> 0
0
0.000000 0.000000
0 -> 0
0
0.000000 0.000000

60.6 AA378 (3.55918,6.15418) readyToCommunicate taxiingToDepQue

AA789 (3.55850,6.15410) readyToCommunicate parking
AA790 (3.55850,6.15410) readyToCommunicate parking
AA791 (3.55850,6.15410) readyToCommunicate parking

4.70198 14.9576
0.00000 0.0000
0.00000 0.0000
0.00000 0.0000

4 -> 1016 157.659

0 -> 0
0
0 -> 0
0
0 -> 0
0

Figure 5.38 Preliminary Results (1): Sample Output.

200

0.719721 0.719721
0.000000 0.000000
0.000000 0.000000
0.000000 0.000000

12000
ROT
10000

Distance (ft)

8000

Takeoff Distance
6000

4000

Taxiing Distance

Separation

2000

0
0

50

100

150

200

250

300

350

400

450

500

550

600

Time (Seconds)

Figure 5.39 Validation of the Simulation Model (Time-Space Diagram for Departures, B727-100).

201

250

200

Speed (fps)

Liftoff point
150

100

50

0
0

10

15

20

25

30

35

25

30

35

Time (Seconds)

6000

5000

Distance (ft)

4000

3000

2000

1000

0
0

10

15

20
Time (Seconds)

Figure 5.40 Validation of the Simulation Model (Takeoff Profile, B727-100).

202

9000

ROT

Separation
8000

7000

Taxiing Distance

Distance (ft)

6000

5000
4000

3000

Landing Distance

2000

1000
0
0

100

200

300

400

500

Time (Seconds)

Figure 5.41 Validation of the Simulation Model (Time-Space diagram For Arrivals, B727-100).

203

600

250

Start Braking
(9.1 sec.)
200

Speed (fps)

Start Free Rolling

(7.1 sec.)

Start Coasting
(21.0 sec.)

150

100

50

Start Exiting
(29.6 sec.)
0
0

10

15

20

25

20

25

Time
Time(Seconds)
(second)

5000
4500
4000

Distance (ft)

3500
3000
2500
2000
1500
1000
500
0
0

10

15
Time(Seconds)
(second)
Time

Figure 5.42 Validation of the Simulation Model (Touchdown Profile, B727-100).

204

300

250

Headway (ft)

200

150

100

50

0
0

10

15
Speed (fps)

20

25

Figure 5.43 Validation of Simulation Model (Headway-Speed Profile, B727-100).

205

30

Chapter 6. Case Study

One of the main benefits of a microscopic simulation model is the wealth of information derived
from each simulation run. In this section, we first define several types of delays encountered in
airport networks. A case study is then presented to illustrated the use of the model developed.

6.1 Definition of Delays

The Consolidated Operations and Delay Analysis System (CODAS) prepared by the FAA defines
three types of delays involved in airport operations [FAA, 1997].

Gate delay: the difference between the actual gate departure time reported in ASQP (Airline
Service Quality Performance) system and the scheduled gate departure time reported in
ETMS (Enhanced Traffic Management System).

Taxi-out delay: The difference between the actual taxi-out time (= wheels-off time gate-out
time) and the unimpeded taxi-out time at the airport. The unimpeded taxi-out time is the
estimated average taxi-out time for an aircraft under optimal operating conditions when
neither congestion, weather, or other factors delay the operation during its movement from
the gate to takeoff.

Taxi-in delay: The difference between the actual taxi-in time (= gate arrival time wheels-on
time) and the unimpeded taxi-in time under an unimpeded condition.

The taxi-out delays defined in CODAS involve not only the delays due to the taxiway congestion
itself, but also delays due to the excess demand on runway operations. On the other hand, taxi-in
delay does not contain runway delays, but only consider taxiway delays. This shows a
discrepancy between taxi-in and taxi-out delays. Motivated by this point, let us define a single
delay called total delay applicable to both arriving and departing operations. The total delay is
defined as follows (See Figures 6.1 and 6.2):

Total delay: the difference between two completion times of the nominal (or unimpeded)
operation time and actual operation time. Here, the completion time of nominal operation is

206

the time duration which is needed for a flight to complete its operation impeded by no other
operations.
Even though it is not easy to divide the total delay into various sub-types, for simulation
purposes, the taxiing delay and runway delays are defined as follows:

Runway delay: The difference between the time when an aircraft is scheduled to start its
runway operation and the time when the actual operation takes place.

Taxiing delay: During taxiing duration, the taxiing delay accrues whenever any flights
taxiing speed is less than a nominal taxiing speed. The taxiing delay is estimated by the
following equation.

Taxiing delay =

simulation time
0

nominal speed - current speed

dt .
nominal speed

Taxiing duration (or taxiing time) is defined as the time required for a departing aircraft to taxi
from the gate to the runway departure queue, For an arriving aircraft is the time to taxi from the
runway exit to the gate.
Figures 6.1 and 6.2 illustrate the various types of delays for both arriving and departing flights.

6.2 Sample Airport

In this research project, the Ronald Reagan National Airport (DCA) is selected for further study.
Along with Dulles Airport and Baltimore-Washington Airports, DCA serves the Washington
D.C. metropolitan area. In FY 1997, total enplanements and operations at DCA were 7,231,903
and 316,404, respectively, placing it as the 26th busiest airport in the U.S. [FAA, 1998].
The existing DCA Airport has 45 gates and three crossing runways designated 3/21 (4,506 ft),
15/33 (5,189 ft), and 18/36 (6,869 ft). (As February 2000, Runway 18/36 has been changed to
01/19 due to magnetic declination.) Because of the relatively short length of its runways, DCA
has short to medium size transport aircraft operations. Figure 6.3 shows the present configuration
of DCA. In this preliminary analysis, the gates are aggregated into 12 groups and it is assumed
that several flights can occupy one aggregated gate at the same time. (This modeling practice is
common in other simulation models.)

207

Total Delay
Nominal
Communication
Time for Taxiing
Clearance

Nominal
Communication
Time for Takeoff
Clearance

Nominal Taxiing Time

to Departure Queue

Takeoff

Nominal Operation Time

Nominal
Communication
Time for Taxiing
Clearance

Ready to
Pushback

Comm.
Dealy

Nominal Taxiing Time

to Departure Queue

Nominal
Communication
Time for Takeoff
Clearance

Taxiing
Dealy

Runway
Dealy

Arrie at
Departure Queue

Start Taxiing

Takeoff

Start
Takeoff Roll

Pass Runway
Threshold

Actual Operation Time

Figure 6.1

Delays Associated with a Departing Flight.

Total Delay
Nominal
Comm. Time
for Landing
Clearance

Landing

Nominal
Communication
Time for Taxiing
Clearance

Taxiing to Gate

Nominal Operation Time

Nominal
Comm. Time
for Landing
Clearance

Runway
Dealy

Ready
to Land

Landing

Touchdown

Nominal
Communication
Time for Taxiing
Clearance

Exit Runway

Comm.
Dealy

Start Taxiing
to Gate

Actual Operation Time

Figure 6.2

Delays Associated with an Arriving Flight.

208

Taxiing to Gate

Taxiing
Dealy

Park
at Gate

15

2001

19

1001

2002
1003

1002
1004

2003
1005

2004

1006
1008

1007

2005

2006

1010

1013

1011

21

1009
1

2009
1012

2008

1014
3

2007

1015
1016

2011

1017

2010
1018

1019

6
7

1020

8
12

1022

2015
1023
2013

2014

33

10
1024
9

11
1028

2012

1021

1026

1029

1025
1027

2016

1030
1031
2017

1032

2018

1033

2020

2019

2021

Node numbering:
1-999 : gate
1001-1999: taxi node
2001-2999: runway node

01

5000ft

Figure 6.3

Configuration of the Washington National Airport (DCA).

209

6.3 Scenarios
To evaluate the efficiency of the airport control system, a total 12 scenarios are generated through
variations in three important decision variables: 1) Network assignment strategy, 2) sequencing
strategy, and 3) pilot-controller communication method. Two network assignment strategies are
considered: static and time-dependent assignment methods. The static network assignment uses
the Euclidean distances for the shortest path algorithm. The sequencing strategy involves pure
first-come-first-serve (FCFS), FCFS with landing priority, and 2-exchange sequences. The impact
of two types of pilot-controller communication methods are also integrated using standard voice
channel and data link methods.
A base line scenario attempts to reproduce the current ATC system using principle of FCFS with
landing priority. In this scenario, both the local and the ground controllers use standard voice
channel communications to provide traffic control advisories. In the scenario, a static assignment
method is used for ground controller to find the taxiing route.
The most advanced scenario studied represents an advanced ATC system where the local
controllers follow optimal aircraft sequences using results from the ASP (Aircraft Sequencing
Problem) model, and the ground controllers guide the taxiing flights based on dynamic shortest
paths which result from NAP (Network Assignment Problem). All 12 scenarios are summarized
in Table 6.1.
Table 6.1
Network Assignment Strategy

Scenarios for Case Study.

Sequence Method
Pure
FCFS

Static
Network
Assignment

FCFS
(w/ Landing Priority)
2-exchange
Pure
FCFS

Time-dependent
Network
Assignment

FCFS
(w/ Landing Priority)
2-exchange

210

Communication Method.
Voice Channel
Data Link
Voice Channel (Base line scenario)
Data Link
Voice Channel
Data Link
Voice Channel
Data Link
Voice Channel
Data Link
Voice Channel
Data Link

6.4 Computational Process

The computations for the case study are derived using the following steps: Data generation,
sequencing, simulation, and the analysis of results. Figure 6.4 illustrates a flowchart with all
computations along with data and output for each step.

6.4.1

Data Generation

Using random number generation techniques, the ready-times (or nominal times) for runway
operations are generated. A total of nine levels of hourly demand (ranging from 10 to 50 flights
per hour) are generated. To consider randomness of generated data, ten data sets are generated for
each level of hourly demand. In all test scenarios, the interval for any two consecutive runway
operations (either takeoff or landing) follows a negative exponential distribution. The aircraft mix
which is another important factor in the delay analysis, is set to 0% heavy, 70% large and 30%
small. For computational simplicity, it is assumed that all flights use a single runway 01. (This
issue will be discussed later in further study.)
Once nominal times for runway operations are available, the activation times for departing flights
are obtained by subtracting the sum of nominal taxiing, communication and some buffer times
from nominal times. The link and node data which are pertinent to taxiway topology are used to
obtain nominal taxiing times. Unlike departing flights, the activation times for arriving flights are
obtained by subtracting only communication times from nominal times.

6.4.2

Sequencing

In this step, three types of sequences for runway operations are computed using nominal times:
pure FCFS sequence, FCFS sequence with landing priority and 2-exchange sequence. Table 6.2
shows a sample output of the sequencing process. In the sequencing process, a maximum of 600
seconds of delay is assumed tolerable as practical limit. This limit can be altered by a planner and
applied for each flight time window. In fact, the schedule from a pure FCFS sequence is the same
one as that of nominal times.
Table 6.2 also shows two types of time savings attained if the swapped sequence is applied. These
are: cumulative time savings obtained from all individual flights, and time savings in completion
time of all flights. For example, the table shows that if the runway operations are performed in

211

accordance with a 2-exchange sequence instead of the FCFS sequence with landing priority, a
total of 669 seconds can be saved over all flights. In this case, the completion time for all
operations are reduced from 1243 to 1149 seconds.

Table 6.2
---

-------

----

acft_id

Type

--1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
---

------DEP_1
DEP_2
DEP_3
DEP_4
DEP_5
DEP_6
DEP_7
DEP_8
DEP_9
DEP_10
ARR_1
ARR_2
ARR_3
ARR_4
ARR_5
ARR_6
ARR_7
ARR_8
ARR_9
ARR_10
-------

---L
S
S
L
L
S
L
L
L
L
L
S
L
L
L
L
S
L
L
S
----

---

-------

----

----------------Nominal
ReadyTime DueTime
(1)
----------------[ 186
786]
[ 218
818]
[ 302
902]
[ 322
918]
[ 378
978]
[ 414
1014]
[ 444
1044]
[ 536
1123]
[ 583
1154]
[ 614
1214]
[
17
582]
[
83
683]
[
89
648]
[ 155
755]
[ 269
800]
[ 307
851]
[ 352
952]
[ 358
924]
[ 431
1031]
[ 468
1068]
----------------Total Delay:
-----------------

A Sample Output from the Sequencing Model.

--------------------------FCFS w/ landing priority
StartTime Sequence Delay
(2)
=(2)-(1)
--------------------------268
4
82
375
6
157
482
8
180
589
10
267
800
13
422
907
15
493
1028
17
584
1088
18
552
1148
19
565
1208
20
594
17
1
0
148
2
65
228
3
139
335
5
180
442
7
173
549
9
242
680
11
328
760
12
402
867
14
436
998
16
530
--------------------------6391
---------------------------

--------------------------2-exchange
StartTime Sequence Delay
(3)
=(3)-(1)
--------------------------268
4
82
375
6
157
594
10
292
496
8
174
747
13
369
687
12
273
840
15
396
947
17
411
1054
19
471
1114
20
500
17
1
0
148
2
65
228
3
139
335
5
180
647
11
378
800
14
493
466
7
114
907
16
549
1014
18
583
564
9
96
--------------------------5722
---------------------------

-------Saving
=(3)-(2)
-------0
0
-112
93
53
220
188
141
94
94
0
0
0
0
-205
-251
214
-147
-147
434
-------669
--------

Completion time: FCFS w/land -> 1243 second, SWAP -> 1149 second

It is important to notice that some flights might not be operated as they are scheduled. This is
because the resulting schedules are an analytical solution which do not reflect any congestion in
communication or taxiing. As pointed out at the beginning of this research, it is very difficult to
develop a single analytical model which considers all of types of delays. This is the main
justification for using a simulation model.

212

node_DCA data
edge_DCA data
Step 1:
Generate data sets using a random number.

Nominal times

Ready times

Step 2:
Compute both FCFS and exchanged sequences.

swap.out

sim_all.dat

node_DCA.dat
edge_DCA.dat
aircraft model.
dat
Step 3:
Simulate both FCFS and exchanged sequences
with various scenarios

flight_state.out
Log_flight.out
Controller.out
taxiPath.out

Step 4:
Analysis of simulation results

Figure 6.4

Flowchart of the Computational Process Employed in the Case Study.

213

6.4.3

Simulation

6.4.3.1

Assumptions

The VTASM model has numerous constants representing human or aircraft behaviors. For
example, the free flow speed, normal speed and jam headways employed in the aircraft-following
model are set to 45 km/hr, 30 km/hr and 27 m, respectively. It should be pointed out that, since
some of these constant values have been drived using common sense, more accurate values could
be collected from future field studies. Some of important constants used in the simulation model
are summarized in Table 6.3.
Table 6.3
Related model
Aircraft
following
Model
Flaring out

Free rolling

Braking
Runway exit

Communication
(Voice channel)

Communication
(Data Link)
Link travel
time function

Constant Values used in the VTASM Simulation Model.

Name
Maximum taxiing speed
Normal taxiing speed
Jam headway
Gamma
Runway threshold crossing height
Flare load factor
Weight factor for landing
Time for free rolling
Acceleration for free rolling
Weight for decision speed
Decision speed for heavy aircraft
Decision speed for large or small aircraft
Exit speed for normal runway exit
Sending request time
(same to receiving request time for controller)
Waiting command time
(same to receiving request time)
Receiving command time
(same to judging time for controller)
Sending confirmation time
(same to receiving request time for controller)
Waiting time for next contact
Sending request time
Waiting command time
Receiving command time
Sending confirmation time
current link travel time
+ 5 seconds for every one conflicting aircraft at the
intersecting point

214

Values
45 (km/hr)
30 (km/hr)
27 (m)
2.75 (degree)
15 (m)
1.1
0.5
2.0 (s)
-0.7 (m/s2 )
18450 (kg)
= 41000 (lb)
35 (m/s)
27 (m/s)
15 (m/s)
4.0 (s)
5.0 (s)
3.0 (s)
3.0 (s)
10.0 (s)
0.0 (s)
3.0 (s)
0.0 (s)
0.0 (s)

6.4.3.2

Input Data

Input data for simulation model include link and node information representing the taxiway and
runway configurations, the aircraft model data, and the flight schedule data. Aircraft model data
involves individual aircraft information such as size, weight and performance data. The flight
schedule data reflects the results of the previous sequencing step. Using the given schedule data,
recommended pushback times for departing flights are internally computed. (For a detailed
description about the recommended pushback times, see Section 2.3.1.) A sample of schedule is
shown in Figure 6.5.

Takeoff/Landing Time
(Pure FCFS sequence)
Aircraft type

Simulation
Input Time

Takeoff/Landing Time
(FCFS w/ Landing Priority sequence)
Takeoff/Landing Time
(Swap sequence)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

DEP_1
DEP_2
DEP_3
DEP_4
DEP_5
DEP_6
DEP_7
DEP_8
DEP_9
DEP_10
ARR_1
ARR_2
ARR_3
ARR_4
ARR_5
ARR_6
ARR_7
ARR_8
ARR_9
ARR_10

B727-100
SF-340
SF-340
B727-100
B727-100
SF-340
B727-100
B727-100
B727-100
B727-100
B727-100
SF-340
B727-100
B727-100
B727-100
B727-100
SF-340
B727-100
B727-100
SF-340

D
D
D
D
D
D
D
D
D
D
A
A
A
A
A
A
A
A
A
A

7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7

0
0
1
2
3
4
4
6
6
7
0
1
1
2
4
4
5
5
6
7

1
33
57
17
13
2
32
4
51
22
3
9
15
21
15
53
38
44
57
34

7 3 6
7 3 38
7 5 2
7 5 22
7 6 18
7 6 54
7 7 24
7 8 56
7 9 43
7 10 14
7 0 17
7 1 23
7 1 29
7 2 35
7 4 29
7 5 7
7 5 52
7 5 58
7 7 11
7 7 48

7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7

4
6
8
9
13
15
17
18
19
20
0
2
3
5
7
9
11
12
14
16

28
15
2
49
20
7
8
8
8
8
17
28
48
35
22
9
20
40
27
38

Gate Number

Runway

Figure 6.5

Sample of Schedule Data.

215

7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7

4
6
9
8
12
11
14
15
17
18
0
2
3
5
10
13
7
15
16
9

28
15
54
16
27
27
0
47
34
34
17
28
48
35
47
20
46
7
54
24

1
1
1
1
2
2
2
2
2
3
12
12
12
12
11
11
11
11
11
10

36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36
36

6.4.3.3

Implementation of the Simulation Model

Each simulation is executed for two-hour duration (i.e., 7200 seconds). This is done to secure
enough time for all flights to finish their operations during the simulation duration. The system
clock is set to advance by one second. This time interval, dt, is one of important settings
particularly in association with aircraft-following model. There is a tradeoff in selecting the size
of dt. Smaller dt provides more detailed results in aircraft behavior but requires more time and
storage space in the implementation simulation.
For the time-dependent NAP, a total of 120 time slices are prepared so that the time-dependent
shortest path information can reflect any change in link travel time with a resolution of 60
seconds. The simulation is repeated for all 12 scenarios.

6.4.3.4

Output Files

VTASM provides several output files for further scrutiny of the data.
1)

1) Log.out reports important events for both flights and controllers including a summary
report with statistics.

2)

2) FlightState.out includes the flight state at each time slice.

3) Controller.out contains the controller state at each time slice.

4) ForwardStar.out/backwardStar.out shows forward-star/backward-star of network
configuration (used for verification).
5)

TaxiPath.out contains static and time-dependent taxi paths for all flights (used for
verification).

The summary section in the log.out file reports diverse statistics related to the delay analysis for
each flight such as taxiing duration, runway occupancy time, runway delay, etc. The flight state in
file flight_state.out includes position, communication state, movement state, permission, speed,
acceleration and traveled distance at time t. Figures 6.6 and 6.7 show samples of the log,out and
the flight_state.out files. A sample of the path.out file is illustrated in Figure 6.8. In this figure, it
is shown that some flights have different paths in the static and in the time-dependent NAP.

216

Data files were opened.

FS and BS were made.
FLight DEP_1 is pushed back to GC's PENDING list
FLight DEP_2 is pushed back to GC's PENDING list
...
FLight ARR_10 is pushed back to LC's PENDING list
Flight data were read.
Shortest Path was made.
< Simulation starts >
system clock = 0 second
At 1 sec, DEP_1 is removed from GC's PENDING list
At 1 sec, DEP_1 is pushed back to GC's PROCESSING list
At 3 sec, ARR_1 is removed from LC's PENDING list
At 3 sec, ARR_1 is pushed back to LC's PROCESSING list
This flight (DEP_1) is ahead the schedule.
So, need to contact the Ground Controller again.
-> scheduled time: 79.9
sysTime: 17
At 17 sec., DEP_1 got "waitThere".
this flight (ARR_1) is behind the schedule.
-> scheduled time: 17
sysTime: 19
At 19 sec., ARR_1 got "clearToLand".
At 33 sec, DEP_2 is removed from GC's PENDING list
At 33 sec, DEP_2 is pushed back to GC's PROCESSING list
This flight (DEP_2) is ahead the schedule.
So, need to contact the Ground Controller again.
-> scheduled time: 186.9
sysTime: 49
...
system clock = 7000 second
system clock = 7200 second
< Simulation ends. >
------------------------------- SUMMARY ------------------------------Flight (Departure DEP_1, B727-100, Gate 1, Runway 36)
Enters into the simulation at
: 1 sec.
Taxiing Duration
: 73 - 217
Taxiing Delay
: 2.22827
Nominal Takeoff Time
(= NTOT)
: 186
Sequenced Takeoff Time (= STOT)
: 268
Actual Takeoff Time
(= ATOT)
: 289
Runway Occupancy Time (= ROT)
: 289 - 328
Sequenced Delay
(= ATOT - STOT) : 21
Runway Delay
(= ATOT - NTOT) : 103
...
Flight (Arrival ARR_10, SF-340, Runway 36, Gate 10)
Enters into the simulation at
: 454 sec.
Nominal Touchdown Time
(= NTDT)
: 468
Sequenced TouchDown Time (= STDT)
: 998
Actual Touchdown Time
(= ATDT)
: 991
Runway Occupancy Time
(= ROT)
: 991 - 1018
Sequenced Delay
(= ATDT - STDT) : 0
Runway Delay
(= ATDT - NTDT) : 523
Taxiing Duration
: 1045 - 1147
Taxiing Delay (sec.)
: 4.52267
TotTaxiingDelay_sec = 47.9558
TotRunwayDelay_sec = 6486
TotDealy_sec
= 6533.96
AvgTaxiingDelay_sec = 2.39779
AvgRunwayDelay_sec = 324.3
AvgDealy_sec
= 326.698
Utilization factor (L/C) = totBusyTimeLC (=1234) / first 1 hour (= 3600) = 0.342778
Utilization factor (G/C) = totBusyTimeGC (=1188) / first 1 hour (= 3600) = 0.33

Figure 6.6

A Sample of the Log.out File.

217

Time
FLT #
---------

(x, y)
------------------

currCommState
------------------

permission
------------

currMoveState
-------------

speed
--------

accel
--------

currLink linkLength distInLink totDist

-------- ---------- ---------- -------

(4.27860,
(3.44770,
(3.65123,
(3.24660,
(3.47540,
(3.47540,
(3.47540,
(3.47540,
(3.47540,
(3.33330,
(2.80910,
(2.98857,
(4.13276,
(4.08470,
(4.08470,
(4.08470,
(4.08470,
(4.08470,
(4.08470,
(4.08470,

7.23847)
3.71363)
6.51975)
6.64350)
6.59730)
6.59730)
6.59730)
6.59730)
6.59730)
6.32750)
5.01500)
4.53792)
8.73577)
3.21800)
3.21800)
3.21800)
3.21800)
3.21800)
3.21800)
3.21800)

readyToCommunicate
readyToCommunicate
readyToCommunicate
waitControllerContact
waitControllerContact
waitControllerContact
waitControllerContact
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate
waitingCommand
waitControllerContact
waitControllerContact
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate

clearToTakeOff
clearToTaxi
clearToTaxi
waitThere
waitThere
waitThere
waitThere
fileApproved
fileApproved
fileApproved
clearToTaxi
clearToTaxi
clearToTaxi
waitThere
waitThere
waitThere
unDecided
unDecided
unDecided
unDecided

rolling
228.557
taxiingToDepQue 27.3409
taxiingToDepQue 27.3409
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
taxiingToGate
27.3409
taxiingToGate
16.3510
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000

5.65931
2006 -> 2005
0.000000
1031 -> 2018
0.000000
1011 -> 1014
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
0 -> 0
0.000000
1029 -> 1028
4.41148
1003 -> 2003
0.000000
2021 -> 2019
0.000000
2021 -> 2019
0.000000
2021 -> 2019
0.000000
2021 -> 2019
0.000000
2021 -> 2019
0.000000
2021 -> 2019
0.000000
2021 -> 2019

(4.28917,
(3.44770,
(3.66271,
(3.24660,
(3.47540,
(3.47540,
(3.47540,
(3.47540,
(3.47540,
(3.33330,
(2.80910,
(2.96257,
(4.12726,
(4.08470,
(4.08470,
(4.08470,
(4.08470,
(4.08470,
(4.08470,
(4.08470,

7.45945)
3.68748)
6.49626)
6.64350)
6.59730)
6.59730)
6.59730)
6.59730)
6.59730)
6.32750)
5.01500)
4.53519)
8.71929)
3.21800)
3.21800)
3.21800)
3.21800)
3.21800)
3.21800)
3.21800)

readyToCommunicate
readyToCommunicate
readyToCommunicate
waitControllerContact
waitControllerContact
waitControllerContact
waitControllerContact
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate
receivingCommand
waitControllerContact
waitControllerContact
readyToCommunicate
readyToCommunicate
readyToCommunicate
readyToCommunicate

clearToTakeOff
clearToTaxi
clearToTaxi
waitThere
waitThere
waitThere
waitThere
fileApproved
fileApproved
fileApproved
clearToTaxi
clearToTaxi
clearToTaxi
waitThere
waitThere
waitThere
unDecided
unDecided
unDecided
unDecided

liftingOff
234.179
taxiingToDepQue 27.3409
taxiingToDepQue 27.3409
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
parking
0.000000
taxiingToGate
27.3409
taxiingToGate
19.9686
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000
onFinal
0.000000

0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
3.61763
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000

...
320.000
DEP_1
DEP_2
DEP_3
DEP_4
DEP_5
DEP_6
DEP_7
DEP_8
DEP_9
DEP_10
ARR_1
ARR_2
ARR_3
ARR_4
ARR_5
ARR_6
ARR_7
ARR_8
ARR_9
ARR_10
321.000
DEP_1
DEP_2
DEP_3
DEP_4
DEP_5
DEP_6
DEP_7
DEP_8
DEP_9
DEP_10
ARR_1
ARR_2
ARR_3
ARR_4
ARR_5
ARR_6
ARR_7
ARR_8
ARR_9
ARR_10

2005 -> 2002

1031 -> 2018
1011 -> 1014
0 -> 0
0 -> 0
0 -> 0
0 -> 0
0 -> 0
0 -> 0
0 -> 0
0 -> 0
1029 -> 1028
1003 -> 2003
2021 -> 2019
2021 -> 2019
2021 -> 2019
2021 -> 2019
2021 -> 2019
2021 -> 2019
2021 -> 2019

...
Figure 6.7

A Sample of the flightState.out File.

218

347.582 322.875 8907.85

782.058 727.237 3832.22
185.988 107.714 608.929
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
233.737 4.76052 6039.35
915.958 24.2862 6123.22
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
1624.27 206.661 9139.22
782.058 754.578 3859.57
185.988 135.055 636.270
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
0 0.000000 0.000000
233.737 32.1014 6066.69
915.958 42.4460 6141.38
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000
493.258 0.000000 0.000000

ARR_1(system clock: 65)

Static Path: 1003 -> 2003 -> 1005 -> 1008 -> 1010 -> 1012 -> 1015 -> 1018 -> 1021 -> 1020 -> 1024 -> 1026 -> 1030 -> 1029 -> 1028 -> 12
td_SP_2 Path: 1003 -> 2003 -> 1005 -> 1008 -> 1010 -> 1012 -> 1015 -> 1018 -> 1021 -> 1020 -> 1024 -> 1026 -> 1030 -> 1029 -> 1028 -> 12
DEP_1(system clock: 73)
Static Path: 1009 -> 1011 -> 1014 -> 1016 -> 1017 -> 1019 -> 1020 -> 1024 -> 1027 -> 1031 -> 2018 -> 2021
td_SP_2 Path: 1009 -> 1011 -> 1014 -> 1016 -> 1017 -> 1019 -> 1020 -> 1024 -> 1027 -> 1031 -> 2018 -> 2021
DEP_2(system clock: 180)
Static Path: 1009 -> 1011 -> 1014 -> 1016 -> 1017 -> 1019 -> 1020 -> 1024 -> 1027 -> 1031 -> 2018 -> 2021
td_SP_2 Path: 1009 -> 1010 -> 1012 -> 1015 -> 1018 -> 1021 -> 1022 -> 1025 -> 1027 -> 1031 -> 2018 -> 2021
ARR_2(system clock: 192)
Static Path: 1015 -> 1018 -> 1021 -> 1020 -> 1024 -> 1026 -> 1030 -> 1029 -> 1028 -> 12
td_SP_2 Path: 1015 -> 1018 -> 1021 -> 1020 -> 1024 -> 1026 -> 1030 -> 1029 -> 1028 -> 12
ARR_3(system clock: 291)
Static Path: 1003 -> 2003 -> 1005 -> 1008 -> 1010 -> 1012 -> 1015 -> 1018 -> 1021 -> 1020 -> 1024 -> 1026 -> 1030 -> 1029 -> 1028 -> 12
td_SP_2 Path: 1003 -> 2003 -> 1005 -> 1008 -> 1010 -> 1012 -> 1015 -> 1018 -> 1021 -> 1020 -> 1024 -> 1026 -> 1030 -> 1029 -> 1028 -> 12
...
DEP_8(system clock: 908)
Static Path: 1011 -> 1014 -> 1016 -> 1017 -> 1019 -> 1020 -> 1024 -> 1027 -> 1031 -> 2018 -> 2021
td_SP_2 Path: 1011 -> 1014 -> 1012 -> 1015 -> 1018 -> 1021 -> 1022 -> 1025 -> 1027 -> 1031 -> 2018 -> 2021
DEP_9(system clock: 968)
Static Path: 1011 -> 1014 -> 1016 -> 1017 -> 1019 -> 1020 -> 1024 -> 1027 -> 1031 -> 2018 -> 2021
td_SP_2 Path: 1011 -> 1014 -> 1016 -> 1017 -> 1019 -> 1020 -> 1024 -> 1027 -> 1031 -> 1032 -> 1033 -> 2018 -> 2021

Figure 6.8

A Sample of TaxiPath.out File.

219

6.5 Computational Results

6.5.1

Total Taxiing Time as Related to Various Network Assignment Strategies

Table 6.4 shows results for the static and time-dependent NAP in total taxiing time. As shown in
the table, the impact of the time-dependent NAP varies depending on a predefined unit delay
time, tentatively called Conflict Delay Time (CDT), which represents the impact of a conflicting
flight on taxiing delay and is used when the time-dependent taxiing route is planned. For
example, if CDT is set to 5 seconds, then the travel time for a certain link increases 5 seconds for
every one possible conflicting aircraft.
Table 6.4

Total Taxiing Times.

(Unit: Seconds)

Scenarios
Network
Assign.

Static
Network
Assign.

Sequence

Comm.

Pure
FCFS

Voice Ch.
Data Link
Voice Ch.
(Base Sce.)
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link
Voice Ch.
Data Link

FCFS
w/ Land.

2-exch.
Time-Dep.
Network
Assign.
(CDT* =
1 sec.)
Time-Dep.
Network
Assign
(CDT =
2 sec.)
Time-Dep.
Network
Assign.
(CDT =
5 sec.)

Number of operations per hour

Pure
FCFS
FCFS
w/ Land.

2-exch.
Pure
FCFS
FCFS
w/ Land.

2-exch.
Pure
FCFS
FCFS
w/ Land.

2-exch.

10

15

20

25

30

35

40

45

50

1650.0
1648.1

2410.8
2410.1

3122.6
3121.8

3917.4
3916.7

4570.9
4574.8

5265.3
5258.2

5886.8
5889.1

6584.4
6584.3

7141.3
7150.6

1650.4

2413.2

3122.9

3916.6

4577.0

5270.9

5888.2

6589.8

7140.8

1647.9
1650.6
1648.1
1650.0
1648.1
1650.4
1647.9
1650.6
1648.1
1650.0
1648.1
1650.4
1647.9
1650.6
1648.1

2409.5
2413.2
2409.6
2410.8
2410.1
2413.2
2409.5
2413.2
2409.6
2410.8
2410.1
2413.2
2409.5
2413.2
2409.6

3120.3
3123.0
3120.2
3122.6
3121.8
3122.9
3120.3
3123.0
3120.2
3123.7
3121.8
3122.9
3120.8
3123.0
3120.7

3913.8
3917.6
3913.1
3917.4
3916.7
3916.6
3913.8
3917.6
3913.1
3917.4
3916.7
3916.6
3914.2
3918.1
3913.1

4573.2
4577.8
4573.0
4570.9
4574.8
4577.0
4573.2
4577.8
4573.0
4570.9
4574.8
4577.0
4573.6
4577.8
4573.4

5259.1
5271.4
5262.6
5265.3
5258.2
5270.9
5259.1
5271.4
5262.6
5265.3
5258.2
5270.0
5259.9
5271.4
5262.6

5885.9
5889.7
5885.8
5886.8
5889.1
5888.2
5885.9
5889.7
5885.8
5886.6
5890.1
5889.2
5886.5
5890.7
5886.4

6577.9
6594.3
6580.8
6584.4
6584.3
6589.8
6577.9
6594.3
6580.8
6587.7
6584.8
6589.8
6577.9
6593.6
6580.8

7144.2
7142.1
7148.0
7141.3
7150.6
7140.8
7144.2
7142.1
7148.0
7142.8
7153.2
7141.9
7145.4
7142.4
7148.4

1650.8
1648.1
1651.3
1647.9
1651.5
1648.1

2410.8
2410.5
2413.6
2411.3
2413.6
2411.4

3125.0
3122.3
3124.8
3122.5
3125.5
3122.5

3920.5
3919.0
3918.7
3916.6
3919.8
3916.4

4575.6
4580.5
4578.2
4579.0
4580.5
4579.2

5266.3
5266.8
5273.9
5268.2
5274.6
5269.3

5890.5
5895.5
5900.2
5895.1
5899.0
5893.6

6597.3
6593.2
6598.9
6589.0
6602.3
6592.7

7150.0
7161.9
7151.7
7154.5
7156.7
7158.1

*CDT: Conflict Delay Time.

220

The simulation results summarized in the Table 6.4 indicate that the time-dependent taxiing
routes planed based on 5 seconds of CDT cause more taxiing time than the static taxiing routes.
In the case that CDT is 2 seconds, some of time-dependent taxiing plans help to reduce the
taxiing time but some of them still cause more taxiing time than static taxiing plans. In the case of
1 second of CDT, the resulting taxiing times are exactly the same ones as those founded in the
static case. Based on these results, we can postulate that CDT value for this case study will be
between 1.0 and 2.0. (For the computational convenience, 2.0 of CDT value will be used from
this point.) We also can see that the communication method does not show any correlation with
taxiing time itself.

6.5.2

Average Runway Delay for Analysis of Aircraft Sequencing Strategies

The average runway delays for all three types of sequencing strategies are summarized in Table
6.5. The results clearly show that, if the 2-exchange sequences are used in runway operations, the
savings in runway delays reaches up to 15% compared to base scenario. And it is also showed
that the communication based on the data link help in saving the runway delay.

Table 6.5

Average Runway Delays resulting from the Simulation.

(Unit: Seconds / Flight)

Scenarios
Network
Assign.

Sequence

Number of operations per hour

Comm.

15

20

25

30

35

40

45

50

Voice Ch.
Data Link
Voice Ch.
FCFS
(Base Sce.)
w/ Land.
Data Link

17.9
8.8

31.5
19.3

36.0
24.3

45.9
28.6

48.0
34.2

100.4
64.8

102.8
77.1

170.6
112.7

324.4
211.6

18.4

30.2

32.8

40.9

45.5

63.5

81.6

94.8

137.6

10.7

21.9

23.6

32.3

35.7

52.1

69.0

83.0

123.6

Voice Ch.
Data Link
Voice Ch.

17.7
9.7
17.9

29.7
21.0
31.5

32.9
22.4
36.1

39.4
27.9
45.9

44.8
33.8
48.0

62.4
47.9
100.4

76.6
60.7
102.8

90.1
76.2
170.7

127.6
110.1
324.4

Data Link
Voice Ch.
Data Link

8.8
18.4
10.7

19.3
30.2
21.9

24.3
32.8
23.6

28.6
40.9
32.3

34.2
45.5
35.7

64.8
63.5
52.1

77.1
81.7
69.0

112.7
94.8
83.0

211.6
137.7
123.6

Voice Ch.
Data Link

17.7
9.7

29.7
21.0

32.9
22.4

39.4
27.9

44.8
33.8

62.4
47.9

76.7
60.7

90.5
76.2

127.6
110.1

Pure
FCFS

Static
Network
Assign.

10

SWAP
Pure
FCFS

Time-Dep.
FCFS
Network
Assign. w/ Land.
(5sec)
SWAP

221

It should be pointed out that average delays obtained from the simulation model are not same as
those from the analytical solution shown in Table 6.6. This is because in some cases, analytical
sequences cannot be implemented due to the communication time lags (delays) as well as the
several assumptions used in simulation model.

Table 6.6

Average Runway Delays resulting from Sequencing Step.

(Unit: Seconds / Flights)

Sequence
FCFS
W/ Land. (1)
2-exch. (2)
Savings (= (1)-(2))

Number of operations per hour

20
25
30
35
40

10

15

10.9

23.2

24.9

35.1

38.3

56.3

9.6
1.3

22.0
1.2

23.0
1.9

29.6
5.5

35.7
2.6

51.5
4.8

45

50

73.2

89.0

130.5

64.0
9.2

81.1
7.9

115.6
14.9

The average delays obtained using the sequencing methods are illustrated in Figures 6.9 and 6.10.
Figure 6.9 indicates that, if the runway practical capacity is decided at the level of four minutes
of delay per aircraft, the runway capacity is about 46 or 47 arrivals per hour. This seems to
correlate well with the analytical results obtained using the airport capacity model (ACM) for the
same aircraft mix.

222

350

Runway Delays per Flight (Seconds)

Static, pure FCFS, Voice Ch.

Static, FCFS, Voice Ch.

300

Static, 2-exch., Voice Ch.

250
200

150
100

50
0
10

15

20

25

30

35

40

45

50

Aircraft Operations per Hour

Figure 6.9

Average Runway Delay by Sequencing Methods (Communication: Voice Channel).

350

Runway Delays per Flight (Seconds)

Static, pure FCFS, Data Link

Static, FCFS, Data Link

300

Static, 2-exch., Data Link

250
200
150
100
50
0
10

15

20

25

30

35

40

45

50

Aircraft Operations per Hour

Figure 6.10 Average Runway Delay by Sequencing Methods (Communication: Data Link).

223

6.5.3

Total Operation Time

Total operation time is a good index to compare various air traffic control strategies. The total
operation obtained for all 12 scenarios are shown in Table 6.7. The results indicate that the total
operation time can be reduced by up to 9.2% if all three advanced air traffic control technologies,
including 2-excahnge sequencing, time-dependent network assignment technique and data link
are used. It is also evident that among these three technologies, the pilot-controller
communication method is the most effective at reducing total operation time.
Interestingly, the time-dependent taxiing planning does not provide a significant advantages at
reducing delays. Nevertheless, it should be noted that time-dependent taxiing feature in the
simulation model is inevitable to model the proper temporal changes in the operation of every
taxiway link. Furthermore, the time-dependent taxiing planning algorithm is expected to play a
substantive role to reduce the total operation time at airports having more complicated taxiway
network with higher taxiing demands.
The results of three sequencing strategies are compared in Figure 6.11. As expected, the pure
FCFS policy yields the highest delays. The impact of two communication methods on the total
delays is compared in Figure 6.12. Here we note certain reduction in delays when pilot controller
datalink communications are used.
Total Operation Time 1).

Table 6.7

(Unit: Seconds)
Scenarios
Network
Assign.

Static
Network
Assign.

Number of operations per hour

Sequence

Comm.

Pure
FCFS

Voice Ch.
Data Link
Voice Ch.
(Base Sce.)
Data Link
Voice Ch.
Data Link

FCFS

10

15

20

25

30

35

40

45

50

2589.1 4017.4 5345.2 6935.3 8272.7 11421.1 13029.4 17664.3 27150.2

2420.3 3712.9 4971.1 6328.2 7656.7 9952.9 11756.1 14794.7 21239.0
2593.9 3998.9 5277.3 6814.0 8198.2 10136.0 12171.6 14264.9 17810.1

2435.4 3743.1 4949.0 6406.0 7691.6 9492.4 11409.6

2587.3 3989.7 5279.3 6774.8 8175.7 10102.2 11974.1
2-exch.
2426.2 3731.1 4927.1 6303.7 7635.8 9353.1 11087.6
Voice Ch.
Pure
2589.1 4017.4 5346.9 6935.3 8272.7 11421.1 13028.6
FCFS
Data Link
2420.3 3712.9 4971.1 6328.2 7656.7 9952.9 11756.5
Time-Dep.
Voice Ch.
2593.9 3998.9 5277.3 6813.9 8198.2 10135.2 12175.4
Network
FCFS
Data
Link
2435.4 3743.1 4949.0 6406.0 7691.8 9492.4 11410.9
Assign.
Voice Ch.
2587.3 3989.7 5279.3 6774.4 8175.7 10102.2 11977.9
2-exch.
Data Link
2426.2 3731.1 4927.1 6303.7 7636.0 9353.1 11088.9
1)
Total Operation Time = i = all flights (Time to finish operationi - Time to enter the systemi ).

224

13427.4
14056.6
13128.2
17665.5
14794.7
14263.1
13427.4
14076.4
13128.2

16821.8
17323.6
16155.5
27150.2
21239.1
17815.9
16821.8
17323.9
16155.7

30000

Static, pure FCFS, Voice Ch.

Total System Costs (Seconds)

Static, FCFS, Voice Ch.

25000

Static, 2-exch., Voice Ch.

20000

15000

10000

5000

0
10

15

20

25

30

35

40

45

50

Aircraft Operations per Hour

Figure 6.11 Total System Costs by Sequencing Methods (from the Simulation Run).

20000

Static, FCFS, Voice Ch.

18000

Static, FCFS, Data Link

Total System Costs (Seconds)

16000
14000
12000
10000
8000
6000
4000
2000
0

10

15

20

25

30

35

Aircraft Operations per Hour

40

45

Figure 6.12 Total System Costs by Sequencing Methods (from the Simulation Run).

225

50

Chapter 7. Summary, Conclusions and Future

Research
7.1 Summary of Results
Unless the weather is adverse, flight delays occur mainly due to excessive demands on airport
facilities such as runways, taxiways, gates, communication system, etc. This research focuses on
the development of optimization models and algorithms and a computer simulation model to
study various activities inside the airport terminal area. These models are intended to help reduce
congestion on runways and taxiways.
In order to manage aircraft traffic at busy airports and terminal areas, aircraft sequencing methods
can be used in conjunction with advanced Air Traffic Control (ATC) automation tools. This
research discusses a combinatorial optimization approach to the Aircraft Sequencing Problem
(ASP). Consideration is given to aircraft arrival and departure streams on a single runway or in
closely spaced runways where arrivals and departures are dependent. Previous studies conducted
in this area have mainly focused on the sequencing problem for arriving aircraft. Since many
airports in the U.S. have dependent arrival and departure stream operations, consideration is given
to both conditions simultaneously. This makes the problem more realistic yet at the same time,
more challenging. Starting with preliminary information about the aircraft such as the aircraft
types, desired arrival/departure times, maximum delay times, minimum separation rules, etc., the
problem can be formulated as a traveling salesman problem with time-windows, and with
nonconsecutive separation enforcement.
To solve the ASP, an exact approach using integer programming techniques is developed. Tight
lower bounds are generated using the Reformulation-Linearization Technique (RLT) of Sherali
and Adams (1990, 1994). Compared with the linear programming relaxation of the original
model, the proposed reformulated ASP problems provide tighter representations, producing
significantly improved lower bounds. As a result, several previously unsolvable instances are now
computationally tractable within the set limits. The computational results show that, by changing
the traditional FCFS sequence intelligently, about 17% of the overall operational time can be
saved.

226

An important consideration for the ASP algorithm is its eventual implementation in real-time
runway operations. As such, the computation time required to solve the ASP is of paramount
importance. To reduce computation time, we suggest several heuristic approaches by modifying
2-exchange and swap methods which are widely used in solving TSP problems. Here, the exact
method serves to help enumerate the heuristic procedures for reasonably sized problems as well
as to develop such heuristic procedures themselves. Computational results show that the 2exchage heuristic method provides sequences very close to exact solutions in reasonable time.
Given an optimal sequence output from the ASP model, the Network Assignment Problem (NAP)
on the taxiway-runway system is considered in a single framework. To resolve the relationships
between runway and taxiway operations, it is desirable to establish certain connections between
ASP and NAP. In our case, we place a higher priority on runway operations. This means that an
optimal aircraft sequence for runway operations which completes the scheduled departures and
landings as soon as possible will be decided first. Taking this sequence as a given condition, the
NAP problem is solved. In this reaserch, the quasi-dynamic network assignment stategy is
adopted as the method for NAP. By taking advantage of the dynamic aspects of the problem,
potential conflicts on the taxiways are detected and avoided if needed. This feature helps design a
more effective network assignment procedure.
To evaluate the system performance in detail, a microscopic simulation model has been
developed. Some salient points of the developed model include: 1) a hybrid-type simulation
model that can analyze the total delay due not only to network congestion but also to
communication channel capacity; 2) an aircraft-following model that captures more dynamic and
detailed behavior of the moving aircraft, and 3) computer codes are developed in ANSI C++ for
the sake of portability. Furthermore, the object-oriented-programming concept employed in
developing simulation model is expected to render the source codes more readable and handy to
modify for the future development.
Adopting Washington National (DCA) Airport as a sample airport, a case study is presented
along with computational results. Results confirm that for high demand levels, communication
can be another source of delay that is not considered in the ASP and NAP problems. Results show
that if an advanced ATC system using the 2-exchange sequence in runway operations and the
data-link system in communication is used, the savings in runway delays reaches up to 19%
compared to the base scenario. Results also reveal that up to 5% of the total operational time in

227

the terminal area can be reduced by upgrading the current voice-channel communication system
to the data-link communication system.

7.2 Recommendations for Future Research

Applying Lagrangian relaxation techniques to ASP: Lagrangian relaxation can be applied to
solving integer programming problems exactly or approximately in a more effective fashion by
exploiting inherent special structures. Lagrangian relaxation can also be applied in conjunction
with RLT, by using it to efficiently solve the LP relaxations through duality considerations.

Consideration of gate allocation: It is frequently observed at busy airports that some landing
flights wait on the taxiway for gates to be vacated. Gate delay is another major source of total
delay which has not been considered in this research. Gates can be managed more efficiently by
solving a so-called "Gate Assignment Problem (GAP)" (see Sherali and Brown, 1994). Since
gates are facilities for both aircraft and passengers, the passenger delays are also considered in
GAP. The effect of GAP could be incorporated in future extensions of our research.
Modifying the shortest path algorithm in the time -dependent NAP: Waiting times at the
nodes can be considered when the dynamic shortest paths are calculated. Instead of detouring the
blocked link, the aircraft can wait at the crossing point until the blockage is released. This is
unlike the ground transportation network where any waiting at intersections is prohibited due to
the operational characteristics of highways. To take node waiting into account, Orda and Roms
study (1990) discussed in Chapter 4 can be applied.
Consideration of stochastic factors in the simulation model: For a more realistic analysis,
probabilistic functions can be used to characterize the following possible stochastic components:
1) the time duration for each phase of the communication process such as receiving request,
judging, sending commands, receiving confirmations, and communication processes; 2) aircraft
performance on the runway with modifications to the descent flight path, the threshold crossing
height, the threshold crossing speed, braking speed, etc., and 3) the lift-off speed in the departure
procedure. In order to obtain these probability functions, a data collection process and statistical
analyses could be conducted in the future. (All aspects of the second point above have already
been studied in detail at Virginia Tech.)

228

Enhancing certain features of the simulation model: It is assumed in the simulation model that
only a single runway is used for both arrival and departure operations. For the simulation model
to be more versatile, it needs to be extended to handle a more diverse set of runway
configurations. These include multiple runways with dependent operational conditions along with
runway crossing procedures. In addition, there are several important features that have not been
implemented in this research: 1) weather condition, 2) multiple controllers, 3) pushback behavior
in association with gate occupancy, 4) service vehicle movements, 5) icing process, 6) holding
stack, etc. All these are valid extensions to this model.
Data and problem horizon: From a practical implementation point of view, it is desirable to
divide the entire data horizon into several relatively smaller problem horizons. The fragmentation
of the data horizon provides us with two practical benefits. First, we can handle the data in a
reasonable computational time, which is a critical factor in real-time ATC systems. For example,
as discussed earlier, the computational time for ASP grows dramatically as the number of aircraft
considered increases. Second, by making the problem horizon smaller, we can both reduce the
uncertainty and re-consider residual (or missed) operations in the next problem.
Using this approach, operations that have been considered during some imminent duration
periods are eliminated from further consideration (see Figure 7.1). The operations starting at the
end of the imminent duration period constitute new operations for the next problem, having
suitably revised input data. On the other hand, aircraft that are at the initial or intermediate stages
of operations will continue according to the prescribed related decisions as determined in the
previous periods' problems. Figure 7.2 displays the problem structure and data- flows for the ASP
and NAP models in a multi-data-horizon framework.
Problem Horizon

Imminent Duration

Data Horizon

Figure 7.1 Definition of Problem and Data Horizons.

229

Data Horizon = [ 0,T]

Size of each Problem Horizon ( = t ) = T/N
N = the number of div ided data horizon

n=0

Desired/Original Schedule
for Arrivals and Departures
for Data Horizon [0,T}

Problem Horizon = [ n t , ( n + 1) t ]
Pick the data within
the problem horizon

Ready/Due-time
to Touchdown for
Problem Horizon
(r_tdni, d_tdn i)

Put missed/not started operations into

the desired schedule set
with ri= n t , original due-time

Ready- time to Push Back from the Gate

for Problem Horizon
(rti)

yes
yes

Any operations
not started yet?

no

Ready/ Due-time
to Takeoff or Departure
(r_toffi* , d_toffi)

Problem Horizon = [ n t , ( n + 1) t ]
Minimum
Separation Rules

Aircraft
Sequencing Problem
(ASP)

no
n=N

yes
End
yes

Optimal
Touchdown time
(t_tdni)

Optimal
Takeoff time
(t_toffi)

Expected Exit Time

from the Runway
(t_exti)

Network Configuration

n = n+1

Recommended
Pushback Time
from the Gate

Network
Assignment Problem
(NAP)

Optimal Route
from the gate to runway
(or from the runway to gate)

Figure 7.2 Problem Structure and Data-Flow for the ASP and NAP Model Framework (MultiData Horizon).

230

Bibliography
Adams, W. P., and H. D. Sherali. A tight linearization and an algorithm for zero-one quadratic
programs. Management Science, 32:1274-1290, 1986.
Adams, W. P., and H. D. Sherali. Mixed-integer bilinear programming problems. Mathematical
Programming, 59(3):279-305, 1993.
Ahuja, R. K., T. L. Magnanti, and J. B. Orlin. Network Flows. Prentice Hall, New Jersey, 1993.
Andreatta, G., and G. Romanin-Jacur. Aircraft flow management under congestion.
Transportation Science, 21(4):249-253, 1987.
Ascheuer, N., M. Fischetti, and M. Grotschel. Solving the asymmetric traveling salesman
problem with time-window by branch-and-cut. Preprint SC-99-31, ZIB Berlin, Germany, 1999.
Baker, K. R. Introduction to Sequencing and Scheduling. John Wiley & Sons, Inc., New York,
1974.
Baker, E. K., and J. R. Schaffer. Solution improvement heuristics for the vehicle routing and
scheduling problem with time-window constraints. American Journal of Mathematical and
Management Sciences 6(3):261-300, 1986.
Baker, K. R., and L. E. Schrage. Finding an optimal sequence by dynamic programming: An
extension to precedence-related tasks. Operations Research, 26(1): , 1978.
Bakker, G., H. Enting, and K. Nienwenhuys. OMT object model, Method Engineering
Encyclopaedia. Online. Available: http://www.univ-paris1.fr/CRINFO/dmrg/MEE/ misop009,
Dec. 1995.
Bazaraa, M. S., J. J. Jarvis, and H. D. Sherali. Linear Programming and Network Flows. Second
Edition, John Wiley and Sons, New York, 1990.
Bellman, R. On a routing problem. Quarterly of Applied Mathematics, 16:87-90, 1958.
231

Bianco, L., G. Rinaldi, and A. Sassano. A combinatorial optimization approach to aircraft

sequencing problem. Flow Control of Congested Networks, Edited by A. R. Odoni et al., NATO
ASI series, F38:323-339, 1987.
Bianco, L., S. Ricciardelli, G. Rinaldi, and

A. Sassano. Scheduling tasks with sequence-

dependent processing times. Naval Research Logistics, 35:177-184, 1988.

Bianco, L., P. DellOlmo, and S. Giordani. Scheduling models and algorithms for TMA traffic
management. Modeling and Simulation in Air Traffic Management, Edited by Bianco, L. et al.,
Springer, 139-167, 1997.
Bodin, L., B. Golden, A. Assad, and M. Ball. Routing and scheduling of vehicles and crews- The
state-of-the-art. Computers & Operations Research, 10(2):63-211, 1983.
Booch, G. Object-oriented Analysis and Design with Application. Addison-Wesley, 1994.
Booch, G., J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. AddisonWesley, Massachusetts, 1998.
Clarke, G., and J. Wright. Scheduling of vehicles from a central depot to a number of delivery
points. Operations Research, 12:568-581, 1964.
Cook, K. L., and E. Halsey. The shortest route through a network with time-dependent internodal
transit time. Journal of Mathematical Analysis and Application, 14:493-498, 1966.
Dear, R. D. The dynamic scheduling of aircraft in the near terminal area. MIT Flight
Transportation Laboratory Report R76-9, MIT, Cambridge, MA., 1976.
Dear, R. G., and Y. S. Sherif. An algorithm for computer assisted sequencing and scheduling of
terminal area operations. Transportation Research, 25A:129-139, 1991
Derr, K. W. Applying OMT: A Practical Step-by-step Guide to Using the Object Modeling
Technique. SIGS Books, New York, 1995.

232

Desrochers, M., J. Desrosiers, and M. Solomon. A new optimization algorithm for the vehicle
routing problem with time-windows. Operations Research 40(2):342-354, 1992.
Desrosiers, J., Y. Dumas, and M. Solomon. A dynamic programming solution of the large-scale
single-vehicle dial-a-ride problem with time-windows. American Journal of Mathematical and
Management Sciences, 6(3):301-325, 1986.
Dial, R., F. Glover, D. Karney, and D. Klingman. A Computational analysis of alternative and
labeling techniques for finding shortest path trees. Networks, 9:215-245, 1979.
Dijkstra, E. W. A note on two Problems in connection with Graphs. Numerische Mathematik ,
1:269-271, 1959.
Dreyfus, S. E. An appraisal of some shortest path algorithms. Operations Research, 17:395-412,
1969.
Driscoll, P. J. A new hierarchy of relaxations for 0-1 mixed integer problems with application to
some specially structured problem. Ph. D. Dissertation, Virginia Polytechnic Institute and State
university, 1995.
Dumas, Y., J. Desrosiers, and F. Soumis. The pickup and delivery problem with time-windows.
European Journal of Operational Research, 54:7-22, 1991.
Dumas, Y., J. Desrosiers, E. Gelinas, and M. M. Solomon. An optimal algorithm for the traveling
salesman problem with time-windows. Operations Research, 43(2):367-371, 1995.
Frank R. L., and P. Wolfe. An algorithm of Quadratic Programming. Naval Research Logistics,
3:95-110, 1956.
French, S. Sequencing and Scheduling: An Introduction to the Mathematics of the Job Shop. John
Wiley & Sons, Inc., New York, 1982.

233

Friesz, T. L., J. Luque, R. L. Tobin, and B. Wie. Dynamic network traffic assignment considered
as a continuous time optimal control problem. Operations Research, 37(6):893-901, 1989.
Friesz, T. L., D. Bernstein, T. E. Smith, R. L. Tobin, and B. Wie. A variational inequality
formulation of the dynamic network user-equilibrium problem. Operations Research, 41(1):179191, 1993.
Gallo, G., and S. Pallottino. Shortest path methods in transportation models. Transportation
Planning Models, Ed. M. Florian. Elsevier Science Publishers B. V., North-Holland, 227-256.

Gallo, G., and S. Pallottino. Shortest path algorithms. Annals of Operations Research, 13:3-79,
1988.
Garey, M., and D. Johnson. Computers and Intractability: A Guide to the Theory of NPcompleteness. Freeman, San Francisco, California, 1979.
Gendreu, M., A. Hertz, and G. Laporte. New insertion and postoptimization procedures for the
traveling salesman problem. Operations Research, 40(16):1086-1093, 1992.
Gendreu, M., A. Hertz, G. Laporte and M. Stan. A generalized insertion heuristic for the traveling
salesman problem with time-windows. Operations Research, 46(3):330-335, 1998.
Gerlough, D. L., and M. J. Huber. Traffic flow theory. TRB Special report 165, TRB, 1975.
Golden, B., T. Doyle, and W. Stewart, Jr. Approximate traveling salesman algorithms.
Operations Research, 28(3):694-711, 1980.
Golden, B., and W. R. Stewart. Empirical analysis of heuristics. The Traveling Salesman
Problem. Lawler, E. L., J. L. Lenstra, A. H. G. Rinnooy Kan, and D. B. Shmoys (Ed.), John
Wiley & Sons, New York, 207-249, 1985.
Glover, F., D. Klingman, and N. Phillips. A new ploynomially bounded shortest path Algorithm.
Operations Research, 33(1):65-73, 1985.

234

Halpern, J. L. Shortest route with time-dependent length of edges and limited delay possibilities
in Nodes. Zeitschrift fur Operations Research, 21:177-124, 1977.
Held, M. and R. M. Karp. A dynamic approach to sequencing Problems. Journal of Society of
Applied Mathematics, 10(1): , 1962.
Jacobson, I. Object-oriented software engineering: A use case driven approach. Addison-Wesley,
Massachusetts, 1992.
Janson, B. N. A convergent algorithm for urban road networks. Transportation Research Record,
1318:69-80, 1991.
Kafura D. Object-oriented Software Design and Construction with C++. Prentice-Hall, Inc. New
Jersey, 1998.
Kanellakis, P., and C. H. Papadimitriou. Local search for the asymmetric traveling salesman
problem. Operations Research, 28(5):1086-1099, 1980.
Kaufman, D. E., and R. L. Smith. Fastest paths in time-dependent networks for IVHS
Application. IVHS Journal, 1:1-11, 1993.
Kim, B. J., A. A. Trani, X. Gu, and C. Zhong. Computer simulation model for airplane landingperformance prediction. Transportation Research Record, 1562:53-62, 1996.
Laporte G. The traveling salesman problem: An overview of exact and approximate algorithms.
European Journal of Operational Research, 59:231-247, 1992a.
Laporte G. The vehicle routing problem: An overview of exact and approximate algorithms.
European Journal of Operational Research, 59:345-358, 1992b.
Law, A. M. and W. D. Kelton. Simulation modeling and analysis, 2nd Edition. McGraw-Hill, Inc.,
New York, 1991.

235

Lawler, E. L. Combinatorial Optimization: Networks and Matroids. Holt, Rinehart and Winston,
New York, 1976.
Lawler, E. L., J. L. Lenstra, A. H. G. Rinnooy Kan, and D. B. Shmoys. The Traveling Salesman
Problem. John Wiley & Sons, New York, 1985.
Leonard, D. R., J. B. Tough, and P. C. Baguley. CONTRAM - A traffic assignment model for
predicting flows and queues during peak periods. TRRL SR 568, 1978.
Lieberman, E. and A. K. Rathi. Traffic Flow Theory, A State-of-the-Art Report. TRB, 1992.
Available: http://www.tfhrc.gov/its/tft/chap10.pdf.
Lin, S. Computer solutions to the traveling salesman problem. Bell System Technical Journal,
44:2245-2269, 1965.
Lin, S., and B. W. Kernighan. An effective heuristic algorithm for the traveling salesman
problem. Operations Research, 21:498-516, 1973.
Luffsey, W. S. Air traffic control: How to become an FAA air traffic controller. Random House,
New York, 1990.
May, A. D. Traffic flow fundamentals. Prentice-Hall, Inc., New Jersey, 1990.
Mahmassani, H. S. Dynamic traffic simulation and assignment: Models, algorithms and
application to ATIS/ATMS evaluation and operation. Operation research and decision aid
methodologies in traffic and transportation management, Edited by Martine L. et al., NATO ASI
Series, F166:104-135, 1998.
Morton, T. E., and D. W. Pentico. Heuristic Scheduling Systems: with applications to the
production systems and project management, John Wiley & Sons, Inc., New York, 1993.
Neuman, F., and H. Erberger. Analysis of sequencing and scheduling methods for arrival traffic.
NASA Technical Memorandum 102795, Apr. 1990.

236

Newell, G. F. Airport capacity and delay. Transportation Science, 13(3):201-241, 1979.

Odoni , A. R. The flow management problem in air traffic management. Flow control of
congested networks, Edited by A. R. Odoni et al., NATO ASI series, F38:269-288, 1987.
Or, I. Traveling salesmantype combinatorial problems and their relation to the logistics of
regional blood banking. Ph.D. thesis, Northwestern University, Evanston, IL., 1976.
Orda, A., and R. Rom. Shortest-path and minimum-delay algorithm in networks with timedependent edge-length. Journal of the Association for Computing Machinery, 37:603-625, 1990.
Papacostas, C. S., and P. D. Prevedouros. Transportation engineering and planning. PrenticeHall, Inc., New Jersey, 1993.
Papadimitriou, C. H., and K. Steiglitz. Combinatorial Optimization Algorithms and Complexity.
Prentice-Hall Inc, New Jersey, 1982.
Peeta, S., and H. S. Mahmassani. System optimal and user equilibrium time-dependent traffic
assignment in congested networks. Annals of Operation Research, 60:81-113, 1995.
Psaraftis, H. N. Dynamic programming approach for sequencing group of identified jobs.
Operations Research, 28(6):1347-1359, 1980.
Psaraftis H. N. A dynamic programming solution to the single vehicle many-to-many immediate
request Dial-A-Ride problem. Transportation Science, 14(2):130-154, 1980.
Psaraftis H. N. Analysis of an O(N2 ) heuristic for the single vehicle many-to-many Euclidean dial
a ride problem. Transportation Research, 17B:133-145, 1983a.
Psaraftis H. N. k-Interchange procedures for local search in a precedence-constrained routing
problem. European Journal of Operational Research, 13:391-402, 1983b.
Rakha, H. A. An evaluation of benefits of user and system optimized route guidance strategies.
Master Thesis, Queen's University, Kingston, Ontario, Canada, 1990.

237

Ran, B., D. E. Boyce, and L. J. LeBlanc. A new class of instantaneous dynamic user-optimal
traffic assignment models. Operations Research, 41(1):192-202, 1993.
Ran, B., N. M. Rouphail, A. Tarko, and D. E. Boyce. Toward a class of link time functions for
dynamic assignment models on signalized networks. Transportation Research, 31B:277-290,
1997.
Reinelt, G. The traveling salesman-computational solutions for TSP applications. Number 840 in
lecture notes in computer science, Springer-Verlag, 1994.
Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, and W. Lorenson. Object-oriented modeling
and design. Prentice Hall, 1991.
Savelsbergh, M. W. P. Local search routing problems with time-windows. Annals of Operations
Research, 4:285-305, 1985.
Savelsbergh, M. W. P. A parallel insertion heuristic for vehicle routing with side constraints.
Statistica Neerlandica, 44(4):139-148, 1990a.
Savelsbergh, M. W. P. An efficient implementation of local search algorithm for constrained
routing problems. European Journal of Operational Research, 47:75-85, 1990b.
Savelsbergh, M. W. P. The vehicle routing problem with time-windows: Minimizing route
duration. ORSA Journal on Computing, 4(2):146-154, 1992.
Schildt, H. The complete reference C++, 3rd Edition. Osborne McGraw-Hill, Inc., New York,
1998.
Schildt, H. The complete reference C, 3rd Edition. Osborne McGraw-Hill, Inc., New York, 1995.
Sexton T., and L. Bodin. Optimizing single vehicle many-to-many operations with desired
delivery times: I. Scheduling. Transportation Science, 19(4):387-410, 1985a.

238

Sexton T., and L. Bodin. Optimizing single vehicle many-to-many operations with desired
delivery times: II. Routing. Transportation Science, 19(4): 411-435, 1985b.
Shaffer, C. A. A practical introduction to data structures and algorithm analysis. Prentice-Hall
Inc., New Jersey, 1997.
Sheffi, Y. Urban Transportation Networks: Equilibrium Analysis with Mathematical
Programming Methods. Prentice-Hall Inc., New Jersey, 1985.
Sherif, Y. S., and A. K. Erdman. Program solves N-Job, M-Machine sequencing Problem.
Microelectronics and Reliability, 25(1):55-58, 1985.
Simpson, R. W. An integrated view of air traffic management problems. Flow control of
congested networks, Edited by A. R. Odoni et al., NATO ASI series, F38:309-322, 1987.
Sherali, H. D., and W. P. Adams. A hierarchy of relaxations between the continuous and convex
hull representations for zero-one programming problems. SIAM J. Discrete Math., 3:411-430,
1990.
Sherali, H. D., and A. Alameddine. A New Reformulation-Linearization Algorithm for Bilinear
Programming Problems. Journal of Global Optimization, 2:379-410, 1992.
Sherali, H. D., and C. H. Tuncbilek. A Reformulation-Convexification approach for solving
nonconvex quadratic programming problems. Journal of Global Optimization, 7:1-31, 1995.
Sherali, H. D., and C. H. Tuncbilek. New reformulation-linearization/convexification relaxations
for univariate and multivariate polynomial programming problems. Operations Research Letters,
21(1):1-10, 1997.
Sherali, H. D., W. P. Adams, and P. J. Driscoll. Exploiting special structures in constructing a
hierarchy of relaxations for 0-1 mixed integer programs. Operations Research, 46(3):396-s405,
1998.

239

Sherali, H. D., and W. P. Adams. A Reformulation-Linearization Technique for Solving Discrete

and Continuous Nonconvex Problems. Kluwer Academic Publishers, Dordrecht/Boston/London,
1999.
S herali, H. D., and E. L. Brown. A Quadratic Partial Assignment and Packing Model and
Algorithm for the Airline Gate Assignment Problem. Quadratic Assignment and Related
Problems, DIMACS Series in Discrete Mathematics and Theoretical Computer Science,
American Mathematical Society, eds. Pardalos, P. M., and H. Wolkowicz, 16:343-364, 1994.
Sherali, H. D., K. Ozbay, and S. Subramanian. The time-dependent shortest pair of disjoint paths
problem: complexity, models, and algorithms. Networks, 31:259-272, 1998.
Sherali, H. D., and P. J. Driscoll. On tightening the relaxations of Miller-Tucker-Zemlin
formulations for asymmetric traveling salesman problems, manuscript, Department of ISE,
Virginia Polytechnic Institute and State University, Blacksburg, Virginia, 1997.
Sherali, H. D., and Wang, H. Global Optimization of nonconvex factorable programming
problems, manuscript, Department of ISE, Virginia Polytechnic Institute and State University,
Blacksburg, Virginia, 1998.
Solomon M. M. The minimum spanning tree problem with time-window constraints. American
Journal of Mathematical and Management Sciences, 6(3):399-421, 1986.
Solomon M. M. Algorithms for the vehicle routing and scheduling problems with time-window
constraints. Operations Research, 35(2):254-265, 1987.
Solomon M. M., E. K. Baker, and J. R. Schaffer. Vehicle routing and scheduling problems with
time-window constraints: efficient implementations of solution improvement procedures. Vehicle
routing: Methods and studies, B. L. Golden and A. A. Assad (Ed.), Elsevier science publishers,
North-Holland, 85-105, 1988.
Starfield, A. M., K. A. Amith, and A. L. Bleloch. How to model it: Problem solving for the
computer age. McGraw-Hill Inc., New York, 1990.

240

Subramanian, S. Routing algorithm for dynamic, intelligent transportation network. Master

Thesis, Virginia Polytechnic Institute and State University, 1997.
Syslo, M. M., N. Deo, and J. S. Kowalik. Discrete Optimization Algorithms with PASCAL
programs. Prentice Hall, New Jersey, 1983.
Taha, H. A. Integer programming: Theory, application and computations. Academic press, New
York, 1975.
Taha, H. A. Operations research, 4th edition. McMillan Publishing Company, London, 1987.
Trani, A. A., X. Gu, C. Zhong, and J. Cao. A system approach to enhance the ground simulation
capabilities of SIMMOD. Research paper, Virginia Polytechnic Institute and State University,
Blacksburg, Virginia, 1993.
Van Aerde, M. W. Modeling of Traffic Flows, Assignment and Queueing in Integrated
Freeway/Traffic Signal Networks. Ph.D. Dissertation, University of Waterloo, 1985.
Van Aerde, M. W., and S. Yagar. Dynamic integrated freeway/traffic signal networks: Problems
and proposed solutions. Transportation Research, 22A:435-444, 1988a.
Van Aerde, M. W., and S. Yagar. Dynamic integrated freeway/traffic signal networks: A routingbased modeling approach. Transportation Research, 22A:445-453, 1988b.
Van Aerde, M. W. Class Notes. Unpublished, 1998.
Van Aerde, M. & Associates. INTEGRATION Released for WINDOWS: User's guide Volume I
& II: Fundamental model features and advanced model Features". Blackburg, VA, 1999.
Vankatakrishnan, C. S., A. Barnett, and A. R. Odoni. Landings at Logan airport: describing and
increasing airport capacity. Transportation Science, 27(3):211-227, 1993.

241

Weijers, T., G. Maters, and P. Aardema. State transition diagram by OMT, Method Engineering
Encyclopaedia. Online, Available: http://www.univ-paris1.fr/CRINFO/dmrg/ MEE/misop009/,
1995.
Wie, B. An application of optimal control theory to dynamic user equilibrium traffic assignment.
Transportation Research Record, 1251:66-73, 1989.
Winston, P. H. On to C++. Addison-Wesley, Massachusetts, 1994.
Zhong, Caoyuan. Modeling of Airport Operations Using an Object-Oriented Approach. Ph.D.
Dissertation, Virginia Polytechnic Institute and State University, 1997.
Ziliaskopoulos, A., and H. S. Mahmassani. Time-Dependent Shortest Path Algorithm for RealTime Intlligent Vehicle Highway System Applications. Transportation Research Record,
1408:94-100, 1993.
Aviation capacity enhancement plan. FAA, Dec. 1998.
Documentation for the Consolidated Operations and Delay Analysis System. Office of avia tion
policy and plans, FAA, 1997.
Integrated Noise Model (INM) Users guide ver. 5.1. FAA, 1996.
RAMS 2.3 Functional overview. Eurocontrol experimental Centre, 1998.
SIMMOD3 Simulation module: Software design documentation. ATAC Corporation, 1993.
SIMMOD3 Simulation module: Functional specification. ATAC Corporation, 1993.

242

Appendix A: List of Input Data

Node data
field 1
field 2

field 3

field 4
field 5

serial number
id number
node number for gate: 1-999,
node number for taxiway: 10019999,
node number for runway: 20012999.
node type
G(gate),
T(Taxiway),
R(Runway),
I(Intersection).
x coordinate
y coordinate

Flight schedule
field
field
field
field

1
2
3
4

field
field
field
field
field

5
6
7
8
9

serial number
flight number (ex, AA2456)
Aircraft type (ex, B727-100)
operation type
D(Departure)/A(Arrival)
Initial time (hour)
Initial time (minute)
Initial time (second)
Gate number
Runway number

Edge date
Line 1

field
field
field
field
field

1
1
2
3
4

Line 2 field 5
field 6
field 7

scale
serial number
from node id
to node id
Edge type
T(Taxiway)/R(Runway)/E(Runway
exit)
Edge id
maximum speed (mph)
direction (ex, 2 (ways))

243

Aircraft data
field
field
field
field
field
field

1
2
3
4
5
6

field 7
field 8
field 9
field 10
field 11
field 12
field

13

field
field

14
15

field

16

field
field
field

17
18
19

field
field

20
21

Serial number
Aircraft type
B727-100
wheel base (m)
16.23
OEW (Operating Empty Weight, kg) 72600
MLW (Maximum Landing Weight, kg) 62400
CLmax
(Maximum
Lifting 2.59872
Coefficient)
Wing area (m2)
157.90
Wing span (m)
32.92
Length (m)
40.59
normal taxiing speed (km/hr)
30.0
maximum taxiing speed (km/hr)
40.0
maximum acceleration for taxiing 2.0
(m/s2)
maximum deceleration for taxiing -5.0
(m/s2)
//normal takeoff speed (km/hr)
// 300.0
//maximum
acceleration
for // 9.80
rolling (m/s2)
//maximum
acceleration
for // 9.80
takeoff (m/s2)
velocity at brake-release (ft/s) 27.41
velocity at lifting-off (ft/s)
230.6
acceleration
at
brake-release 6.96
(ft/s2)
k1
7.053357
k2 (accel. for takeoff = k1 k2 0.00357250
*speed)

244

Appendix B: Constants used in the Simulation Model

//Definition.h
#ifndef _DEFINITION_H
#define _DEFINITION_H
//----------------------------------------// Controls parameters for for Simulation
//----------------------------------------#define BATCH_JOB
0
// 0: NO, 1: YES If yes, then use "test.bat".
#define COMMUNICATION 1
// 1: voice channel, 2: data link
#define SEQUENCING
1 // 1: pure FCFS,
// 2: FCFS w/ landing priority, or
// 3: SWAP squencing
#define spAlgorithm td_SP_2 // static_SP: Static SP
// td_SP_1 : time-dependent shortest path algorithm for rNode->all, for all timeSlices
// td_SP_2
: time-dependent shortest path algorithm for rNode->all, for a
timeSlice
// ------------------- CAUTION ------------------//
// "td_SP_1" may cause a memory deficiency poblem. cause this method takes huge memories such as
//
//
int
td_shortPath[MAX_NODES][MAX_NODES][NumTimeSlices]
//
float td_shortTime[MAX_NODES][MAX_NODES][NumTimeSlices]
//
//
Also, takes much more computation time comparing with method 2.
//
In conclusion, not recommended.

SINGLE

#define PRINT_FLIGHT_STATE
0
#define PRINT_CONTROLLER_STATE 0
// 0: the flight/cotroller state file is not written. (This will save time a lot.)
//------------------------------// Definitions for Problem Size
//------------------------------#define MAX_NODES
70
// Max. number of Nodes this simulation can handle
#define MAX_FLIGHTS
120
// Max. number of Flights this simulation can handle
#define MaxRunways
10
// Max. number of Runways this simulation can handle
#define MaxNodesPerIntersection 5 // Max. number of Nodes which are connected to one intersection
#define MaxAcftModels 50
// Max. number of AcftModels this simulation can handle
#define InfDistance
99999.9
// Inifite distance for SP algorithm (considered as infinity)
#define MaxNodeIndex 99999
// Max. index for node numbering

//------------------------------// Definitions for Simulation Parameters

//------------------------------//#define UpdateTDSP
300
// Update TDSP every UpdateTDSP seconds and
// NumTimeSlices = SimulationDuration / UpdateTDSP in Simulation
#define
#define
#define
#define
#define
#define
#define
#define
time for TDSP
#define
flight
#define
#define

dt
(float) 1.0 //second
StartHour
7
StartMinute 0
StartSecond 0
EndHour
9
EndMinute
0
EndSecond
0
NumTimeSlices 180
// Max. number of time slices to keep the Time-dependent link travel
algorithm
AddLinkTravelTime 3.5
// (sec) expected extra link travel time for each connflicting
MaxDelay
BufferTimeRatio

600
// (sec.) should be variable to each problem.
1.1
// norminal ROT for departure =
// ready time to taxi + normal taxiing time * BufferTimeRatio (=1.1) )
// this number is also used in "Random Generation"

//------------------------------// UK(ft) -> SI(meter) Unit

// Multiply the conversion factor
//------------------------------#define meter_per_ft
0.305
// Conversion factor (ft -> meter)
#define fps_per_mph
1.4667
// Conversion factor (mi/hr -> ft/sec)
#define km_per_mile
1.609
// Conversion factor (mile -> km)
#define kg_per_lb
0.4536
// Conversion factor (pound -> kg)
//------------------------------// SI(meter) -> UK(ft) Unit
//------------------------------#define ft_per_meter
3.28
#define mile_per_km
0.62137
#define lb_per_kg
2.2046

// Conversion factor (meter -> ft)

// Conversion factor (mile -> km)
// Conversion factor (kg -> pound)

245

//------------------------------// Aircraft Classification Weight

//------------------------------#define WtSmallLarge
60000
// if acft weight < WtSmallLarge (lb) then this is "small"
#define WtLargeHeavy
300000
// if acft weight > WtLargeHeavy (lb) then this is "heavy"
//------------------------------// Car-Following
//------------------------------#define minGap
15 // minimum gap (second) for coflicting aircraft at Intersection
// if increase this, the TDSP will be more effective.
#define SafeDistanceFromCrossToStop 50
// Safe Distance from the cross end for

aircraft

to

stop.

(ft)
#define maxLegs 5

// maximum number of legs for a intersection.

// this number is the same to the maximum

number of conflicting flights

intersection
#define u_f
41.0
//free flow speed (ft/sec) = 45kph
#define h_j
83.0
//jam headway (ft/veh)
#define k_h
// design parameter
for headwayControl logic in vehicle-following model
#define k_s
// design parameter
for speedControl logic in vehicle-following model
#define reactionTime 1.55
// delta_t
for micro car-following model
#define alpha_
.37
// sensitivity paprameter (for micro car-following model)
#define normSpeed_mph 18.65 // normal taxiing speed (mph) = 30 (kph)
#define normSpeed_fps (normSpeed_mph*fps_per_mph) // normal taxiing speed (fps)
//#define safetyDist

at

//------------------------------// For Landing Module

//------------------------------//
1) for Flaring Out phase
#define gamma
(2.75 * 3.1415 / 180) // radian
// Tangent value of the descent flight path angle (degree, ~N(2.73,0.08^2))
#define h_th_ft
50.
// Threashold crossing height (ft) (meter, ~N(15.2,3^2))
#define g_mps2
9.8
// Acceleration of gravity
(meter/sec^2)
#define n_fl
1.1
// Flare load factor
(1.1~1.3)
#define delta_m
25.0
// Correction distance for touchdown diatnce in association with
runway length (m/100 m runway length)
#define rho
1.1673 // Standard atmosphere air density at 500m
(kg/m^3)
#define wtFactor
0.5
// weight factor for landing weight (= (OEW + MLW) * wtFactor)
//
2) for Free Rolling (FR) phase
#define timeFR
2
// Time for free rolling (sec)
#define accFR_mps2
-0.7
// the acceleration for Free Rolling (m/sec^2)
//
3) for Braking phase
#define wtForDecSpd
#define decisionSpdHeavy_mps
#define decisionSpdLarge_mps
#define
#define
#define
#define
#define
#define

accBrakeB727_mps2
accBrakeB737_mps2
accBrakeB757_mps2
accBrakeDC9_mps2
accBrakeMD80_mps2
accBrakeDefault_mps2

//
4) for Coasting phase
#define EXIT_SPEED_mps
#define EXIT_SPEED_fps

41000
// decision speed for heavy aircraft (wt > 41000 lb)
// decision speed for large aircraft (wt < 41000 lb)

35
27
-2.19
-2.25
-2.01
-2.03
-2.05
-2.10

//
//
//
//
//
//

decaleration
decaleration
decaleration
decaleration
decaleration
decaleration

15
49.2

for
for
for
for
for
for

braking
braking
braking
braking
braking
braking

phase
phase
phase
phase
phase
phase

(B727)
(B737)
(B757)
(DC9)
(MD80)
(else)

~N(2.19,
~N(2.25,
~N(2.01,
~N(2.03,
~N(2.05,
~N(2.05,

0.416^2)
0.471^2)
0.478^2)
0.414^2)
0.387^2)
0.387^2)

// exit speed from the runway

//------------------------------//InterEventTimes in communication
//------------------------------#if (COMMUNICATION == 1) // VOICE_CHANNEL
#define waitngToContactTime
#define
#define
#define
#define
#define
#define
#define
#define

10.0//10.00 // for waiting to the next contact

// due to either communication jam, or pushback congestion for dep
sendingRequestTime
4.0//11.00
// for sendingRequest
(flight)
receivingRequestTime
4.0//11.00
// for receivingRequest
(controller)
waitingCommandTime
3.0
// for waitingCommand
(flight)
judgingTime
3.0
// for judging
(controller)
receivingCommandTime
4.0//14.00
// for receivingCommand
(flight)
sendingCommandTime
4.0//14.00
// for sendingCommand
(controller)
sendingConfirmationTime
3.0//15.00
// for sendingConfirmation(flight)
recievingConfirmationTime 3.0//15.00
// for receivingConfirmation(controller)

#else // DATA_LINK
#define waitngToContactTime

1.0

// for waiting to the next contact

246

// due to either communication jam, or pushback congestion for

dep
#define
#define
#define
#define
#define
#define
#define
#define

sendingRequestTime
receivingRequestTime
waitingCommandTime
judgingTime
receivingCommandTime
sendingCommandTime
sendingConfirmationTime
recievingConfirmationTime

0.0
0.0
3.0
3.0
0.0
0.0
0.0
0.0

//
//
//
//
//
//
//
//

for
for
for
for
for
for
for
for

sendingRequest
(flight)
receivingRequest
(controller)
waitingCommand
(flight)
judging
(controller)
receivingCommand
(flight)
sendingCommand
(controller)
sendingConfirmation(flight)
receivingConfirmation(controller)

#endif
#define
TotalCommunicationTime
sendingConfirmationTime)
#define MaxEarlierContactTime
scheduled time

(sendingRequestTime
15

waitingCommandTime

receivingCommandTime

// if flight contact no earlier than the

//
by
MaxEarlierContactTime
then
he
can
continue
to comminicate
//------------------------------//etc.
//------------------------------#define PILOT_SCAN_RATE
3.0
//
Pilot
detect
the
potential
conflict
every
PILOT_SCAN_RATE secconds
#define TOL_TAXING_SPEED_GAP
0.01
// Tolerable speed gap between normalTaxiSpeed and
currentSpeed
// (this is only for the first flight in the link)
// if abs(normalTaxiSpeed - currentSpeed) > TOL_TAXING_SPEED_GAP, then need accel or
decel
#define maxValue(a, b) (((a) > (b)) ? ((a) : (b)))
#define minValue(a, b) (((a) > (b)) ? ((b) : (a)))
#endif

247

Appendix C: Header Files for the Simulation Model

//AcftModel.h
#ifndef _ACFTMODEL_H
#define _ACFTMODEL_H
class AcftModel{
public:
AcftModel();
AcftModel(char* id, float
float
float
float
float
~AcftModel();

wb_m, float oew_kg, float mlw_kg,

cl_m, float wa_m2, float ws_m, float l_m,
vT_kph, float vMT_kph, float aMT_mps2, float dMT_mps2,
vTo_kph, float aMR_mps2, float aMTo_mps2,
v1, float v2, float a1, float k1, float k2);

//readers
char* read_id();
float read_cl_max();
float read_spdAccelCoeff();
// SI
float
float
float
float
float
float

--------------------------------------------------------------------------------read_wheelBase_m();
read_OEW_kg();
read_MLW_kg();
read_wingArea_m2();
read_wingSpan_m();
read_length_m();

//Taxing
float read_velNormTaxi_kph();
float read_velMaxTaxi_kph();
float read_accMaxTaxi_mps2();
float read_decMaxTaxi_mps2();
float read_decNormTaxi_mps2();
float read_distNormalStop_m();

float read_velNormTaxi_mps();
float read_velMaxTaxi_mps();

// FlaringOut
float read_timeFlare();
float
float
float
float

read_velApproach_kph();
read_velFlare_kph();
read_velTouchdown_kph();
read_accFlare_mps2();

float read_velApproach_mps();
float read_velFlare_mps();
float read_velTouchdown_mps();

// FreeRolling
float read_accFreeRoll_mps2();
float read_timeFreeRoll();
// Braking
float read_decisionSpd_mps();
float read_accBrake_mps2();
// Takeoff
float read_velTakeoff_kph();
float read_accMaxRoll_mps2();
float read_accMaxTakeoff_mps2();
// UK
float
float
float
float
float
float

float read_velTakeoff_mps();

--------------------------------------------------------------------------------read_wheelBase_ft();
read_OEW_lb();
read_MLW_lb();
read_wingArea_ft2();
read_wingSpan_ft();
read_length_ft();

//Taxing
float read_velNormTaxi_mph();
float read_velMaxTaxi_mph();
float read_accMaxTaxi_fps2();
float read_decMaxTaxi_fps2();
float read_decNormTaxi_fps2();
float read_distNormalStop_ft();

// FlaringOut
float read_velApproach_mph();
float read_velFlare_mph();
float read_velTouchdown_mph();
float read_accFlare_fps2();

float read_velNormTaxi_fps();
float read_velMaxTaxi_fps();

float read_velApproach_fps();
float read_velFlare_fps();
float read_velTouchdown_fps();

248

// FreeRolling
float read_accFreeRoll_fps2();
// Braking
float read_decisionSpd_fps();
float read_accBrake_fps2();
// Takeoff
float read_velTakeoff_mph();
float read_accMaxRoll_fps2();
float read_accMaxTakeoff_fps2();
float
float
float
float
float

read_v1_fps();
read_v2_fps();
read_a1_fps2();
read_k1();
read_k2();

private:
char* id_str;
float spdAccelCoeff,
cl_max;

//
//
//
//

float read_velTakeoff_fps();

velocity at brake-release (ft/sec)

velocity at lifting-off (ft/sec)
acceleration at lifting-off (ft/sec^2)
a = k1 + k2 * v

// spdAccelCoeff(=k)= maxAccel / maxSpeed;

// max. landing lift coeffcient

/*--------------------------------------------------SI Unit (The international System of Units)

-----------------------------------------------------*/
float
// Dimensions
wheelBase_m,
OEW_kg,
MLW_kg,
wingArea_m2,
wingSpan_m,
length_m,
// Taxing
velNormTaxi_kph, velNormTaxi_mps,
velMaxTaxi_kph,
velMaxTaxi_mps,
accMaxTaxi_mps2,
decMaxTaxi_mps2,
decNormTaxi_mps2,
distNormalStop_m,

//
//
//
//
//
//

normal taxing speed

maximum taxing speed
maximum accel for taxing
maximum decel for taxing
normal decel for taxing
stopping distance at normal taxing speed

// Landing
// 1) Flaring phase
velStall_kph,
velStall_mps,
//vCruise_kph,
vCruise_mps,
velApproach_kph, velApproach_mps,
velFlare_kph,
velFlare_mps,
velTouchdown_kph, velTouchdown_mps,
distFlare_m,
accFlare_mps2,

//
//
//
//
//
//
//

stall speed
normal cruising speed
normal approach speed
threshold crossing speed
normal Touchdown speed
Flaring distance
flaring
acceleration

(actually

deceleration)
timeFlare,
//dFlare_m,
//tFlare,

// flaring duration
// fixed Flare dist, cummulative Flare dist

// 2) Free Rolling phase

accFreeRoll_mps2,
timeFreeRoll,
//tFreeRolling,
//dFreeRolling_m,
// 3) Braking phase
decisionSpd_mps,
accBrake_mps2,
//tBrake,
//dBrake_m,
// 4) Coasting phase
//aCoast_mps2,
//dCoast_m,
//tCoast_m,
// Takeoff
velTakeoff_kph,
accMaxRoll_mps2,
accMaxTakeoff_mps2;

velTakeoff_mps,

/*---------------------------------------------------

249

// normal Takeoff speed

// maximum accel for rolling
// maximum accel for takeoff

UK Unit (The British Units)

-----------------------------------------------------*/
float
// Dimensions
wheelBase_ft,
OEW_lb,
MLW_lb,
wingArea_ft2,
wingSpan_ft,
length_ft,
// Taxing
velNormTaxi_mph, velNormTaxi_fps,
velMaxTaxi_mph, velMaxTaxi_fps,
accMaxTaxi_fps2,
decMaxTaxi_fps2,
decNormTaxi_fps2,
distNormalStop_ft,

//
//
//
//
//
//

normal taxing speed

maximum taxing speed
maximum accel for taxing
maximum decel for taxing
normal decel for taxing
stopping distance at normal

taxing

speed

// stall speed (constant from equation)

// normal cruising speed (constant from equation)
// normal approach speed (constant from equation)
//
threshold
crossing
speed
(constant

from

// Landing
// 1) Flaring phase
velStall_mph,
velStall_fps,
//vCruise_mph,
vCruise_fps,
velApproach_mph, velApproach_fps,
velFlare_mph,
velFlare_fps,
equation)
velTouchdown_mph,

velTouchdown_fps,

//

normal

Touchdown

speed

equation)
distFlare_ft,
accFlare_fps2,

// flare dist (constant from equation)

// average acceleration during Flaring out phase

// 2) Free Rolling phase

accFreeRoll_fps2,
// 3) Braking phase
decisionSpd_fps,
accBrake_fps2,
// 4) Coasting phase
//Takeoff
velTakeoff_mph,
velTakeoff_fps,
accMaxRoll_fps2,
accMaxTakeoff_fps2,
v1_fps, // velocity at brake-release (ft/sec)
v2_fps, // velocity at lifting-off (ft/sec)
a1_fps2,// acceleration at lifting-off (ft/sec^2)
k1,
// a = k1 - k2 * v
k2;
};
#endif

250

(constant

from

// Array3D.cpp : Defines the entry point for the console application.

//3DARRAY.h
#ifndef _3DARRAY_H
#define _3DARRAY_H
#include "ostream.h"
template <class type> class TwoDArray{
public:
TwoDArray(int nRows, int nCols): m_nRows(nRows), m_nCols(nCols){
m_p2DData = new type[nRows*nCols];
}
~TwoDArray(){
delete m_p2DData;
}
type& operator()(int nRow, int nCol)
{
//check dimensions
if(nRow<0 || nRow>=m_nRows ||
nCol<0 || nCol>=m_nCols)
{
throw "Trying to acces array out of bounds\n";
}
return *(m_p2DData + nRow*m_nCols + nCol);
}
private:
type*
m_p2DData;
const int m_nRows;
const int m_nCols;
};
template <class type> class ThreeDArray{
public:
ThreeDArray(int nPages, int nRows, int nCols):m_nPages(nPages), m_nRows(nRows), m_nCols(nCols){
m_p3DData = new type[nPages*nRows*nCols];
if(m_p3DData == NULL)
cout << "Array allocation error: Too big array allocation in ThreeDArray
constructor.\nPlease use the td_SP_2 as a TDSP method\n\n";
}
~ThreeDArray(){
delete m_p3DData;
}
type& operator()(int nPage, int nRow, int nCol)
{
//check dimensions
if(nPage<0 || nPage>=m_nPages ||
nRow<0 || nRow>=m_nRows ||
nCol<0 || nCol>=m_nCols)
{
cout << "nPage" << nPage << " nRow" << nRow << " nCol" << nCol;
throw "Trying to acces array out of bounds\n";
}
return *(m_p3DData + nPage*m_nRows*m_nCols + nRow*m_nCols + nCol);
}
private:
type*
m_p3DData;
const int m_nPages;
const int m_nRows;
const int m_nCols;
};
#endif

251

//Clock.h
#ifndef _CLOCK_H
#define _CLOCK_H
#include "Definition.h"

252

class NormalTime{
public:

253

254

NormalTime();
~NormalTime();
NormalTime(int h, int m, float s);
void write_NormalTime(int h, int m, float s);
protected:
int
hour, minute;
float second;
// ( float to keep the deci-second )
};

class SystemTime{
public:
SystemTime();
~SystemTime();
protected:
float systemSecond;
};

// ( absolute time starting from 0.0 second)

class Clock: private NormalTime, private SystemTime {

public:
Clock();
~Clock();
Clock(float st);
Clock(int h, int m, float s);
// reader and writer for NormalTime
void write_Time(float st);
void write_Time(int h, int m, float s);
int
read_hour();
int
read_minute();
float read_second();
float read_systemTime();
void convertSystemTimeToNormalTime(float st);
float convertNormalTimeToSystemTime(int h, int m, float s);
// reader and writer for SystemTime
void advanceTime();
void advanceTime(float deltaT);
};
#endif

255

//Controller.h
#ifndef _CONTROLLER_H
#define _CONTROLLER_H
#include "AcftModel.h"
#include "ARRAY.h"
#include "Clock.h"
#include "Definition.h"
#include "Edge.h"
#include "Flight.h"
#include "Header.h"
#include "Node.h"
#include "Point.h"
#include "Graph.h"
#include "TaxiEdge.h"
#include "TaxiEdgeList.h"
#include "Type.h"
#include "Clock.h"
#include "Q.h"
#include "Runway.h"

class Controller{
public:
Controller();
~Controller();
Controller(int totNodes, Flight* f_p, Node* n_p, Graph* FS_p = NULL, Graph* BS_p = NULL);
virtual void communicate(Flight* f, FlightState_Type currFlightCommState, float sysTime);
void static_Dijkstra(unsigned int rIndex, int totNodes, ofstream& fStar_out);
void findStaticPath(Flight* f, int totNodes, unsigned int sPath[]); //find enRoute
//find & write shortPath
void findStaticPath(int totNodes, unsigned int rIndex, unsigned int d, unsigned int sPath[]);
// update the TDSP from this flight's origin to other nodes.
void td_Dijkstra_Forward(Flight* cFlight_p, int totNodes, ofstream& fowardStar_out);
void td_Dijkstra_Forward(unsigned int rIndex, int totNodes, ofstream& forwardStar_out);
// find Time Dependent Shortest Path for all time slices from rNode
//
-> all nodes, i.e., forward search style
void td_Dijkstra_Forward_2(float sTime, Flight* cFlight_p, int totNodes, ofstream& fStar_out);
void
td_Dijkstra_Forward_2(float
sTime,
unsigned
int
rIndex,
int
totNodes,
ofstream&
forwardStar_out);
// find Time Dependent Shortest Path for a single start time slice from rNode -> all nodes,
i.e., forward search style
int
findTotalConfFlights(Edge*
currEdge_p,
int
tSlice);
//
find
the
number
of
conflicting
flights on the all conflicting edges
void findTDPath(Flight *f, int totNodes, unsigned int td_sPath[], float sTime);
void findTDPath(int totNodes, unsigned int oIndex, unsigned int dIndex, unsigned int td_sPath[],
int timeSlice);
void update_NumAcft_TravelTimes(TaxiEdgeList* nTaxiEdgeList_p, float sysTime);
TaxiEdgeList* make_TaxiEdgeList_p(Flight* f, SP_Algorithm spMethod, int timeSlice = -999);
TaxiEdgeList*
make_TaxiEdgeList_p(int
oNodeIndex,
int
dNodeIndex,
SP_Algorithm
spMethod,
int
timeSlice = -999);
//update the flight strips
std::list<Flight*> read_pendingFlightList();
std::list<Flight*> read_processingFlightList();
std::list<Flight*> read_doneFlightList();
void pushbackPendingList(Flight* f_p, ofstream& log_out, char* controllerName);
void
pushbackProcessingList_1(int
sTime,
Flight*
f_p,ofstream&
controllerName1, char* controllerName2);

log_out,

// remove from pending, and pushback to processing list

void pushbackProcessingList_2(int sTime, Flight* f_p, ofstream& log_out, char* controllerName);
// just pushback to processing list
void pushbackDoneList(int sTime, Flight* f_p, ofstream& log_out, char* controllerName);
// remove from processing list, and pushback to done list
virtual void judge(ofstream& log_out, Flight* f_p, float sysTime);
//readers
ControllerState_Type
read_currState();
float
read_shortTime(unsigned int i, unsigned int j);
float
read_td_shortTimes(unsigned int r, unsigned int d, int tS);
float
read_td_shortTime_2(unsigned int r, unsigned int d);
Flight*
read_currFlightComm_p();
Flight*
read_prevRunwayOccupiedFlight_p();
float
read_delayTimeForFlight();
// writers
void
write_currState(ControllerState_Type cst);
void
write_prevRunwayOccupiedFlight_p(Flight* pf);

256

char*

void
void
void

write_currFlightComm_p(Flight* cf);
write_delayTimeForFlight(float dTFF);
write_initFlightsList_p(Flight* f_p);

protected:
ControllerState_Type currState;
ControllerMessage_Type decision;
float delayTimeForFlight;
//if
delayTime.

delayTime

>

// write the pointer

Flights linked list

0.00,

then

the

flight

to

will

the

starting

contact

L/C

point

of

again

in

// for STATIC SHORTEST PATH

unsigned int shortPath[MAX_NODES][MAX_NODES], //shortest path matrix
sPath[MAX_NODES];
//shortest path from one node to the other nodes
float
shortTime[MAX_NODES][MAX_NODES]; //travel Time for semi-dynamic
// for TIME_DEPENDENT SHORTEST PATH
unsigned int td_sPath[MAX_NODES];
unsigned int td_shortPath_2[MAX_NODES][MAX_NODES]; //shortest path matrix
float
td_shortTime_2[MAX_NODES][MAX_NODES]; //travel Time for semi-dynamic
Clock
nextEventTime;
Flight* initFlightsList_p,
// pointer to the starting point of Flights linked-list
*
prevRunwayOccupiedFlight_p,// previous Flight which occupied runway
(for
min. separation rule)
* currFlightComm_p;
// current communicating Flight
Node*
nodes_p;
// pointer to the starting point of Nodes array
Edge**
initEdgeNodes_p;
// pointer to the starting point of EdgeNodes array
Graph*
forwardStar_p,
// pointer to the airport network with forwardStar_p
*
backwardStar_p;
// pointer to the airport network with backwardStar_p
std::list<Flight*> pendingFlightList,
processingFlightList,
doneFlightList;
std::list<Flight*>::iterator p;

the

};

/**************** GROUND CONTROLLER **********************/

class GroundController: public Controller{
public:
GroundController();
GroundController(int totNodes, Flight* f_p, Node* n_p, Graph* FS_p = NULL, Graph* BS_p = NULL);
~GroundController();
virtual
void
communicate(ofstream&
log_out,
Flight*
f_p,
FlightState_Type
currFlightCommState,
float sysTime);
virtual void judge(ofstream& log_out, Flight* f_p, float sysTime);
private:
TaxiEdgeList* newTaxiEdgeList_p;
// pointer to the starting point of New TaxiEdge list
};
/**************** LOCAL CONTROLLER **********************/
class LocalController: public Controller{
public:
LocalController();
LocalController(int totNodes, Flight* f_p, Node* n_p, int totRwy, Runway **rwy_p, Graph* FS_p =
NULL, Graph* BS_p = NULL);
~LocalController();
virtual
void
communicate(ofstream&
log_out,
Flight*
f_p,
FlightState_Type
currFlightCommState, float sysTime);
virtual void judge(ofstream& log_out, Flight* f_p, float sysTime);
float
judgeForClearance(float
sysTime);//decide
the
clearance
for
takeoff/landing
with
delayTimeForFlight if needed.
void write_prevFlight_p(Flight* pF);
void write_currFlight_p(Flight* cF);
void write_nextFlight_p(Flight* nF);
Flight* read_prevFlight_p();
Flight* read_currFlight_p();
Flight* read_nextFlight_p();
private:
int totRunway;
Runway **runway_p;
TaxiEdgeList* newRunwayEdgeList_p;
// pointer to the starting point of New RunwayEdge list
for Takeoff/Landing
Flight *prevFlight_p,
//previous flight on the runway operation
*currFlight_p,
//currnet flight on the runway operation
*nextFlight_p;
//next flight on the runway operation
float minSep[4][3][3]; // Min. Separtion Rule
};
#endif

257

//Edge.h
#ifndef _EDGE_H
#define _EDGE_H
#include "Type.h"
#include "Definition.h"
#include "Node.h"
#include <Math.h> //for the "sqrt" and "pow"
class Flight;
class Edge{
public:
Edge();
~Edge();
Edge(float scale, char* id_str, char type, Node* f, Node* t, float r);
// readers
char*
read_id_str_p();
Edge_Type read_edgeType();
Node*
read_fromNode_p();
Node*
read_toNode_p();
int
read_fromNodeId();
int
read_toNodeId();
int
read_fromNodeIndex();
int
read_toNodeIndex();
float
read_restrict();
float
read_distance_ft();
float
read_distance_m();
float
read_travelTime();
float*
read_travelTimes();
// return the pointer to array of "the travelTimes"
float
read_travelTimes(int tSlice);
Flight*
read_flightInEdge_p();
// return the pointer to the flight in the edge
int
read_numFlightInEdge();
int
read_numFlightInEdge(int tSlice); //
Edge*
read_nextEdge_p();
Edge*
read_nextBSEdge_p();
// writers
void
write_distance_ft(float d_ft);
void
write_distance_m(float d_m);
void
write_travelTime(float tt);
void
add_numAcft(int tSlice);
void
write_travelTimes(int tSlice, float tt);
void
write_nextEdge_p(Edge* nxt_p);
void
write_nextBSEdge_p(Edge* nxtBS_p);
void
write_flightInEdge_p(Flight* tempFlightInEdge_p);
void
write_numFlightInEdge(int nFIE);
private:
char
*id_str_p;
Edge_Type edgeType;
float
distance_ft,
distance_m,
travelTime,
restrict;
//e.g. exit speed if this edge is exit edge.
float
*travelTimes;
// For Time dependent SP algorithm (Variable Array)
//CurrentEdgeDirection_Type currentDirection;
Node
*fromNode_p,
*toNode_p;
Flight
*flightInEdge_p;
int
numFlightInEdge,
*numAcft;
// # of vehicles in the edge
for Time dependent SP algorithm
(Variable Array)
Edge
*nextEdge_p,
// Pointer to NextEdge in forwardStar
*nextBSEdge_p;
// Pointer to NextEdge in backwardStar
};
#endif

258

//Flight.h
#ifndef _FLIGHT_H
#define _FLIGHT_H
#include "Type.h"
#include "Point.h"
#include "AcftModel.h"
#include "Header.h"
#include "Point.h"
#include "Position.h"
#include "Clock.h"
#include "Graph.h"
#include "Edge.h"
#include "Runway.h"
#include "TaxiEdge.h"
#include "TaxiEdgeList.h"
#include "Definition.h"
class GroundController;
class LocalController;
class Flight{
public:
Flight(char* fId_p, AcftModel* mdl_p, char oper,
int sHour, int sMin, float sSec,
int hour_norm, int min_norm, float sec_norm,
int hour_fcfs, int min_fcfs, float sec_fcfs,
int hour_swap, int min_swap, float sec_swap,
int gIndex, char *rId_p,
Runway** runway_p, int totRunway, Node* nodes, Graph* FS_p, Graph* BS_p, Flight* pFIL_p,
GroundController* GC_p, LocalController* LC_p);
~Flight();
//Communication
bool checkNeedToComm(float nxtCommEventTime, float sysTime);
void communicateGroundController(ofstream& log_out, float sysTime);
void communicateLocalController(ofstream& log_out, float sysTime);
//TakeOff
void roll();
void liftOff();
//Landing
void flareOut();
void freeRoll();
void brake();
void coast(float dToExit);
void exitRunway(float dToExitEnd);
void parkingForArrival();
Node* findExitNode_p();
float findDistToExit();
float findDistToTaxiDestination();
float findDistToTheCross();
//Taxing
void taxiToDest(Clock sysTime, float scale, ofstream& log_out);
void move(TaxiEdgeList* crrEdgeList_p, int desNodeIndex);
void deQueue(Edge* currTaxiEdge_p);
void enQueue(Edge* nextTaxiEdge_p);
float computeNextAccel_1();
float computeNextAccel_2(float d, float v_fnl);
float computeNextAccel_3(Clock sysTime);
float computeSpdAfterD(float distToNextExit);
float computeNextTaxiAccel(Clock sysTime, float scale, ofstream& log_out);
void collisionDetectResolve(Clock sysTime, float scale, ofstream& log_out);
float carFollowing();
//Statistics
void statistics(ofstream& log_out);
// For
// The
friend
friend
friend
friend

sorting the STL list (see 651 pp., in "complete reference C++")
required operator overloadings are dependent on the compiler.
bool operator < (Flight &o1, Flight &o2);
bool operator > (Flight &o1, Flight &o2);
bool operator == (Flight &o1, Flight &o2);
bool operator != (Flight &o1, Flight &o2);

//Readers
char*
char*
AcftModel*
Operation_Type
int
int
int
int

read_flightId_p();
read_runwayId_p();
read_acftModel_p();
read_operationType();
read_orgNodeIndex();
read_desNodeIndex();
read_gateNodeIndex();
read_exitEnterNodeIndex();

259

int
read_currNodeIndex();
int
read_nextNodeIndex();
Point
read_currPoint();
float
read_currSpeed();
Position*
read_currPosition_p();
float
read_nextAccel();
ControllerMessage_Type
read_permission();
Priority_Type
read_priority();
ConflictChecked_Type
read_conflictChecked();
Flight*
read_conflictingFlight_p();
float
read_depTimeAtCross();
float
read_nextCommEventTime();
float
read_nextMoveEventTime();
float
read_rotTimeRecommended();
float
read_pushbackTimeRecommended();
float
read_rotTimeNorm();
float
read_rotTimeFcfs();
float
read_rotTimeSwap();
float
read_phaseTimeStamp_b();
float
read_phaseTimeStamp_e();
float
read_linkTimeStamp_b();
float
read_linkTimeStamp_e();
float
read_taxingTimeStamp_b();
// the begin/end time stamp of taxing
float
read_taxingTimeStamp_e();
float
read_rotTimeStamp_b();
float
read_rotTimeStamp_e();
float
read_GC_TimeStamp_b();
float
read_GC_TimeStamp_e();
float
read_LC_TimeStamp_b();
float
read_LC_TimeStamp_e();
float
read_taxingDelay_sec();
// delay due to taxiway congestion
float
read_runwayDelay_sec();
// delay due to runway congestion
float
read_commGCDelay_sec();
// delay due to communication jam
float
read_commLCDelay_sec();
// delay due to communication jam
float
read_travelTime();
float
read_lastTaxiEdgeLength_ft();
GroundController* read_groundController_p();
LocalController*
read_localController_p();
Graph*
read_forwardStar_p();
Graph*
read_backwardStar_p();
TaxiEdgeList*
read_taxiEdgeList_p();
TaxiEdgeList*
read_runwayEdgeList_p();
Edge*
read_currTaxiEdge_p();
Edge*
read_currRunwayEdge_p();
Node*
read_exitNode_p();
Flight*
read_leadingFlightInEdge_p();
Flight*
read_followingFlightInEdge_p();
Flight*
read_nextFlightInList_p();
Flight*
read_prevFlightInList_p();
FlightState_Type
read_currMoveState();
FlightState_Type
read_currCommState();
int
read_numTrialToContactLC();
int

read_numTrialToContactGC();

//Writers
friend ofstream &operator<<(ofstream &stream, Flight f);
void write_currMoveState(FlightState_Type fst);
void write_currCommState(FlightState_Type fst);
void write_currSpeed(float cSpd);
void write_permission(ControllerMessage_Type pt);
void write_priority(Priority_Type pr);
void write_conflictChecked(ConflictChecked_Type cC);
void write_conflictingFlight_p(Flight* cF);
void write_depTimeAtCross(float dTAC);
void write_nextAccel(float nxtAccel);
void write_systemInputTime(float sysInputTime);
void write_nextCommEventTime(float nextCETime);
void write_nextMoveEventTime(float nextMETime);
void write_startTime(float stTime);
// write the simulation input time.
void write_phaseTimeStamp_b(float sysTime);
void write_phaseTimeStamp_e(float sysTime);
void write_linkTimeStamp_b(float sysTime);
void write_linkTimeStamp_e(float sysTime);
void write_taxingTimeStamp_b(float sysTime);
// the begin/end time stamp of taxing
void write_taxingTimeStamp_e(float sysTime);
void write_rotTimeStamp_b(float sysTime);
void write_rotTimeStamp_e(float sysTime);
void write_GC_TimeStamp_b(float sysTime);
void write_GC_TimeStamp_e(float sysTime);

260

void
void
void
void
void
void
void
void
void

write_LC_TimeStamp_b(float sysTime);
write_LC_TimeStamp_e(float sysTime);
write_taxingDelay_sec(float tTD);
add_numTrialToContactLC();
//
subtract_numTrialToContactLC();
//
add_numTrialToContactGC();
//
subtract_numTrialToContactGC();
//
add_taxingDelay_sec(float tD_sec); // delay due
add_runwayDelay_sec(float rD_sec); // delay

add by 1
subtract by 1
add by 1
subtract by 1
to taxiway congestion
due to runway congestion (not used for the time

being)
void add_commGCDelay_sec(float cGCD_sec);
// delay due to communication jam
void add_commLCDelay_sec(float cLCD_sec);
// delay due to communication jam
void write_lastTaxiEdgeLength_ft(float lTEL_ft);
void write_taxiEdgeList_p(TaxiEdgeList *newEdgeList_p);
void write_runwayEdgeList_p(TaxiEdgeList *newEdgeList_p);
void write_currTaxiEdge_p(Edge*
cTaxiEdge_p);
void write_currRunwayEdge_p(Edge* cRunwayEdge_p);
void write_orgNodeIndex(int oNI);
void write_desNodeIndex(int dNI);
void write_exitNode_p(Node* eNode_p);
void write_currPosition_p(Position* cPosition_p);
void write_groundController_p(GroundController* gc_p);
void write_localController_p (LocalController* lc_p);
void write_leadingFlightInEdge_p(Flight* lFIE_p);
void write_nextFlightInList(Flight* nxt_p);
void write_prevFlightInList(Flight* prv_p);
void write_rotTimeRecommended(float rotRec);
void write_pushbackTimeRecommended(float pbRec);
protected:
Flight(); // constructor. never be used.
private:
char*
flightId_p,
*
runwayId_p;
AcftModel*
acftModel_p;
Operation_Type
operationType;
FlightState_Type
currMoveState,
currCommState;
bool
everStoppedInLastEdge;
ControllerMessage_Type permission;
Priority_Type
priority;
ConflictChecked_Type
conflictChecked;
Flight*
conflictingFlight_p;// Conflicting flight for taxing
Clock
depTimeAtCross;
int
orgNodeIndex,
desNodeIndex,
currNodeIndex;
Node*
gateNode_p;
Position*
currPosition_p;
float
currSpeed,
nextAccel;
Clock
systemInputTime,
nextCommEventTime,
nextMoveEventTime,
pushbackTimeRecommended,
// for deprtures
rotTimeRecommended,
// assigned to one of rotTimeNorm or rotTimeSwap.
rotTimeNorm,
rotTimeFcfs,
rotTimeSwap,
linkTimeStamp_b,
linkTimeStamp_e,
phaseTimeStamp_b,
phaseTimeStamp_e,
taxingTimeStamp_b, taxingTimeStamp_e,
GC_TimeStamp_b,
GC_TimeStamp_e,
LC_TimeStamp_b,
LC_TimeStamp_e,
rotTimeStamp_b,
rotTimeStamp_e;
int
numTrialToContactGC,
// number of trials to contact
controller
numTrialToContactLC;
// number of trials to contact local controller
float
taxingDelay_sec,
// delay due to taxiway congestion
runwayDelay_sec,
// delay due to runway congestion
commGCDelay_sec,
//
delay
due
to
communication
jam
with
Controller
commLCDelay_sec;
//
delay
due
to
communication
jam
with
Controller
float
travelTime,
lastTaxiEdgeLength_ft;
GroundController* groundController_p;
Graph
*forwardStar_p,
*backwardStar_p;
// for conflict resoltion and (un)blocking the link
TaxiEdgeList
*taxiEdgeList_p;
// for Taxing path
Edge
*currTaxiEdge_p;
// The curr Edge in Taxi path.

261

ground

Ground
Local

LocalController
TaxiEdgeList
Edge
Node

*localController_p;
*runwayEdgeList_p;
*currRunwayEdge_p;
*exitNode_p;

Flight *leadingFlightInEdge_p,
*followingFlightInEdge_p,
*prevFlightInList_p,
*nextFlightInList_p;

// for Takeoff/Landing path

// The curr Edge in Runway path.
// exit Node

//
//
//
//

Leading Flight in a CuurEdge

Following Flight in a CuurEdge
prev Flight in Flight List
Next Flight in Flight List

};
#endif

//Graph.h
#ifndef _GRAPH_H
#define _GRAPH_H
#include
#include
#include
#include
#include

"Type.h"
"Definition.h"
"Node.h"
"Node.h"
"Edge.h"

typedef Edge* Edge_p;

class Graph{
public:
Graph(int totNodes, int totEdges);
~Graph();
int n();
int e();
Edge* first(int nodeIndex); // get the first edge for a node
bool isEdge(Edge* edg_p);
// return 1 if (edge != null)
Edge* next(Edge* edg_p);
// get the next edge for a node
Edge* nextBS(Edge* edgBS_p);
int fromNodeId(Edge* edg_p);// get the fromNodeId for this edge
int toNodeId(Edge* edg_p); // get the toNodeId for this edge
Edge* Graph::findEdge_p (int fnIndex, int tnIndex); // find the pointer to the edge from fnIndex
to tnIndex
float tTime (int fnIndex, int tnIndex);
// find the travel time for the edge from fnIndex to
tnIndex
float* tTimes(int fnIndex, int tnIndex);
// find the pointer to the travel time matrix for the
edge from fnIndex to tnIndex
float Dist (int fnIndex, int tnIndex);
// find the distance for the edge from fnIndex to
tnIndex
float tTime(Edge* edg_p);
// find the travel time for edge
float* tTimes(Edge* edg_p);
// find the travel time matrix for edge
float Dist (Edge* edg_p);
// find the diatnce for edge
//readers
Edge* read_list(int fnIndex); //return the pointer to (Edge*) list[fnIndex]
Edge** read_list();
//return the pointer to (Edge**)list
//writers
void write_list(int fnIndex, Edge* newEdge_p); // list[fnIndex] = newEdge_p;
void write_totNodes(int tN);
// write total Nodes
void write_totEdges(int tE);
// write total Edges
private:
Edge_p* list;
int totNodes;
int totEdges;
VisitMark_Type* visitMark;
};
#endif _GRAPH_H

262

// Header.h
#ifndef _HEADER_H
#define _HEADER_H
#include<conio.h>
#include<stdio.h>
#include<fstream.h>
#include<iostream.h>
#include<istream.h>
#include<ostream.h>
#include<stdlib.h>
#include<string.h>
//#include<search.h>
#include<math.h>
#include<assert.h>
#include<iomanip.h>
#include <list>
#include <algorithm>
#endif

//Node.h
#ifndef _NODE_H
#define _NODE_H
#include "Type.h"
#include "Header.h"
#include "Point.h"
class Flight;
class Edge;
class Node{
public:
Node();
~Node();
Node(int ind, int id, char type, Point point, float p=0.0);
Node(int ind, int id, char type, float x, float y, float p=0.0);
Node(int ind, int id, char type, float x, float y, float p, Flight* fin_p);
//readers
int
read_index();
int
read_id();
float
read_x();
float
read_y();
Node_ Type read_nodeType();
float
read_passingTime();
Point& read_pt();
Bool
read_haveEverEntered(); // {true, false}; for DEQueue in TDSP
Bool
read_isInQueue();
// {true, false}; for DEQueue in TDSP
//writers
void
write_fs_p(Edge* f_p);
void
write_bs_p(Edge* b_p);
void
write_haveEverEntered(bool hEE);
void
write_isInQueue(bool iIQ);
private:
int index,
// serial index (= 1,2,3,...)
id;
// id (= User defined id) ex, 2001, 2005,...
Node_Type nodeType;
bool haveEverEntered,
// {true, false}; for DEQueue in TDSP
isInQueue;
float passingTime;
Point pt;
Flight* flightInNode_p;
Edge* fs_p,
//pointer to ForewardStar
* bs_p;
//pointer to BackwardStar
};
#endif

263

//Point.h
#ifndef _POINT_H
#define _POINT_H
class Point{
public:
Point();
~Point();
Point(float x1, float y1);
float read_x();
float read_y();
void write_x(float x1);
void write_y(float y1);
private:
float x, y;
};
#endif

//Position.h
#ifndef _POSITION_H
#define _POSITION_H
#include "Point.h"
class Position{
public:
Position();
~Position();
Position(float x1, float y1, float tDT = 0.0);
Position(Point& p, float tDT = 0.0);
//readers
float read_traveledDistInLink();
float read_traveledDistTotal();
float read_currX();
float read_currY();
//writers
void write_traveledDistInLink(float tDistL);
void write_traveledDistTotal(float tDistT);
void write_currX(float);
void write_currY(float );
private:
float traveledDistInLink,
traveledDistTotal;
Point pt;
};
#endif _POSITION_H

264

//Q.h (for the SP algorithm)

#ifndef _Q_H
#define _Q_H
#include "Node.h"
#include "definition.h"
class NodeList{ // Doubly-linked lists (100-shaffer)
public:
int
nodeIndex;
NodeList* prevNodeList_p,
* nextNodeList_p;
NodeList(int nIndex, NodeList* prv_p = NULL, NodeList* nxt_p = NULL);
NodeList(NodeList* prv_p = NULL, NodeList* nxt_p = NULL);
~NodeList();
};
class Q{
//115page in Shaffer's text book
public:
Q();
~Q();
int firstNodeIndex();
// return the first node's index
int deQueueFirst();
// return the from-node's index of the first Node in the queue.
int
deQueueMin(int r, float shortTime[][MAX_NODES]); // find the minimum distance node from
root node, r, to to-nodes in the (Node) queue and return the to-node's
index
void enQueueFirst(int nIndex);
void enQueueLast(int nIndex);
void deleteNodeList(NodeList* nl_p);
bool isEmpty() const;
int totCurrElements() const;
void clear();
private:
NodeList* headNodeList_p,
* tailNodeList_p,
* currNodeList_p;
void deleteNode(int* n_p);
};
#endif

////Runway.cpp
#ifndef _RUNWAY_H
#define _RUNWAY_H
#include "TaxiEdge.h"
#include "Header.h"
#include "Definition.h"
class Runway{
public:
Runway();
Runway(char* rId_p, TaxiEdge* rLink_p);
~Runway();
char*
read_runwayId();
TaxiEdge* read_runwayLink_p();
TaxiEdge* read_nextRunwayLink();
private:
char* id_p;
TaxiEdge* runwayLink_p; // pointer to starting link
// next runwayLink = runwayLink_p->read_nextTaxiEdge_p();
};
#endif

265

// Simulation.h
#ifndef _SIMULATION_H
#define _SIMULATION_H
#include "Header.h"
#include "Type.h"
#include "Definition.h"
#include "Clock.h"
#include "Point.h"
#include "Node.h"
#include "Edge.h"
#include "Graph.h"
#include "Runway.h"
#include "AcftModel.h"
#include "Controller.h"
#include "Flight.h"
#include "Q.h"
#include "ARRAY.h"
#include<ostream.h>
ThreeDArray<unsigned
int>
td_shortPath(MAX_NODES,
MAX_NODES,
NumTimeSlices);
//travelPath by keeping the next node to destination
ThreeDArray<float>
td_shortTime(MAX_NODES, MAX_NODES, NumTimeSlices);
//travelTime
float
float
float
float
float

totTaxingTime_sec
totTaxingDelay_sec
totRunwayDelay_sec
totCommLCDealy_sec
totCommGCDealy_sec

=
=
=
=
=

0.0;
0.0;
0.0;
0.0;
0.0;

typedef Edge* Edge_p;

int comp(const void *a , const void *b);
struct FlightData{
int
sn;
// serial number
char
*id_str,
// AA234
*model_str;
// B757-300
AcftModel *acftModel_p;
char
operationType;
// char ('A' or 'D')
int
startHour,
// 7 (o'clock)
startMin;
// 6 (minute)
float
startSec;
// 34.0 (second)
int rotHour_norm,
// 7 (o'clock)
rotMin_norm;
// 6 (minute)
float
rotSec_norm;
// 34.0 (second)
int rotHour_fcfs,
// 7 (o'clock)
rotMin_fcfs;
// 6 (minute)
float
rotSec_fcfs;
// 34.0 (second)
int rotHour_swap,
// 7 (o'clock)
rotMin_swap;
// 6 (minute)
float
rotSec_swap;
// 34.0 (second)
float
startTime;
int
gateId,
// Gate Node Number = 7
gateIndex;
char*
runway_str;
// Runway, ex, R15
};
ofstream& operator<<(ofstream &stream, Flight f){
if(f.taxiEdgeList_p != NULL || f.runwayEdgeList_p != NULL){
stream //<< f.sysTime.read_systemTime()
<< setw(10)
<< setprecision(7)
<< f.read_flightId_p() << " "
<< setiosflags(ios::showpoint) << "("
<< f.currPosition_p->read_currX() << ", "
<< f.currPosition_p->read_currY() << ") ";
switch (f.currCommState){
case readyToCommunicate:
stream << " readyToCommunicate
"; break;
case waitNextContact:
stream << " waitNextContact
"; break;
case sendingRequest:
stream << " sendingRequest
"; break;
case waitingCommand:
stream << " waitingCommand
"; break;
case receivingCommand:
stream << " receivingCommand
"; break;
case sendingConfirmation:
stream << " sendingConfirmation
"; break;
case waitControllerContact:
stream << " waitControllerContact "; break;
default:
stream << " somthing wrong in currCommState ";
}
switch (f.permission){
case unDecided:
stream << " unDecided
"; break;
case fileApproved:
stream << " fileApproved
"; break;
case reRoute:
stream << " reRoute
"; break;
case stopThere:
stream << " stopThere
"; break;
case waitThere:
stream << " waitThere
"; break;

266

case reStart:
case clearToPushback:
case clearToTaxi:
case clearToTakeOff:
case clearToLand:
default:

stream << " reStart

";
break;
stream << " clearToPushback "; break;
stream << " clearToTaxi
";
break;
stream << " clearToTakeOff
";
break;
stream << " clearToLand
";
break;
stream << " somthing wrong in currPermission ";

}
switch (f.currMoveState){
case parking:
case pushingBack:
case taxingToDepartureQueue:
case waitingToTaxi:
case delayedAtCross:
case speedUp:
case steadyTaxing:
case slowDown:
case turning:
case waitingOnRunway:
case rolling:
case liftingOff:
case endOfDeparture:
case
case
case
case
case
case
case

onFinal:
flaringOut:
freeRolling:
braking:
coasting:
exitingRunway:
taxingToGate:

stream << " parking "

; break;
stream << " pushingBack
"; break;
stream << " taxingToDepQue ";
stream << " waitingToTaxi ";
stream << " delayedAtCross ";
stream << " speedUp
"; break;
stream << " steadyTaxing
";
stream << " slowDown
"; break;
stream << " turning
";
stream << " waitingOnRnwy ";
stream << " rolling
";
stream << " liftingOff
"; break;
stream << " endOfDeparture ";
stream
stream
stream
stream
stream

default:

<<
<<
<<
<<
<<

" onFinal
"; break;
" flaringOut
"; break;
" freeRolling
"; break;
" braking
"; break;
" coasting
"; break;
stream << " exitingRnwy
";
stream << " taxingToGate
";

break;
break;
break;
break;
break;
break;
break;
break;

break;
break;

stream << " somthing wrong in currMoveState ";

}
stream
<< f.currSpeed << "
<< f.nextAccel << "
<< setw(5);

"
"

if(f.taxiEdgeList_p != NULL){
stream
<< f.taxiEdgeList_p->currEdge_p()->read_fromNode_p()->read_id() << " -> "
<< f.taxiEdgeList_p->currEdge_p()->read_toNode_p()->read_id()
<< " "
<< setw(10)
<< f.taxiEdgeList_p->currEdge_p()->read_distance_ft()
<< " ";
}
else if(f.runwayEdgeList_p != NULL){
stream
<< f.runwayEdgeList_p->currEdge_p()->read_fromNode_p()->read_id() << " -> "
<< f.runwayEdgeList_p->currEdge_p()->read_toNode_p()->read_id()
<< " "
<< setw(10)
<< f.runwayEdgeList_p->currEdge_p()->read_distance_ft()
<< " ";
}
else stream << " somthing wrong in node -> node ";

stream
<< f.currPosition_p->read_traveledDistInLink() << "
<< f.currPosition_p->read_traveledDistTotal() << "
<< endl;

"
"

}// if
else{
stream //<< f.sysTime.read_systemTime()
<< setw(10)
<< setprecision(7)
//<< setiosflags(ios::fixed)
<< f.read_flightId_p() << " "
<< setiosflags(ios::showpoint) << "("
<< f.currPosition_p->read_currX() << ", "
<< f.currPosition_p->read_currY() << ") ";
switch (f.currCommState){
case readyToCommunicate:
stream << " readyToCommunicate
"; break;
case waitNextContact:
stream << " waitNextContact
";
case sendingRequest:
stream << " sendingRequest
";
case waitingCommand:
stream << " waitingCommand
";
case receivingCommand:
stream << " receivingCommand
";
case sendingConfirmation:
stream << " sendingConfirmation
"; break;
case waitControllerContact:
stream << " waitControllerContact ";
default:
stream << " somthing wrong in currCommState ";
}

267

break;
break;
break;
break;
break;

switch (f.permission){
case unDecided:
case fileApproved:
case reRoute:
case stopThere:
case waitThere:
case reStart:
case clearToPushback:
case clearToTaxi:
case clearToTakeOff:
case clearToLand:
default:
}

stream << " unDecided

"; break;
stream << " fileApproved
"; break;
stream << " reRoute
"; break;
stream << " stopThere
"; break;
stream << " waitThere
"; break;
stream << " reStart
";
break;
stream << " clearToPushback "; break;
stream << " clearToTaxi
";
break;
stream << " clearToTakeOff
";
break;
stream << " clearToLand
";
break;
stream << " somthing wrong in currPermission ";

switch (f.currMoveState){
case parking:
case pushingBack:
case taxingToDepartureQueue:
case waitingToTaxi:
case speedUp:
case steadyTaxing:
case slowDown:
case turning:
case waitingOnRunway:
case rolling:
case liftingOff:
case endOfDeparture:
case
case
case
case
case
case
case

onFinal:
flaringOut:
freeRolling:
braking:
coasting:
exitingRunway:
taxingToGate:

stream << " parking

"; break;
stream << " pushingBack
"; break;
stream << " taxingToDepQue ";
stream << " waitingToTaxi ";
stream << " speedUp
"; break;
stream << " steadyTaxing
";
stream << " slowDown
"; break;
stream << " turning
";
stream << " waitingOnRnwy ";
stream << " rolling
";
stream << " liftingOff
"; break;
stream << " endOfDeparture ";
stream
stream
stream
stream
stream

default:

<<
<<
<<
<<
<<

" onFinal
"; break;
" flaringOut
"; break;
" freeRolling
"; break;
" braking
"; break;
" coasting
"; break;
stream << " exitingRunway ";
stream << " taxingToGate
";

break;
break;
break;
break;
break;
break;
break;

break;
break;

stream << " somthing wrong currMoveState ";

}
stream
<< f.currSpeed << "
<< f.nextAccel << "
<<
<<
<<
<<
<<

"
"

setw(5)
0 << " -> "
0 << " "
setw(10)
0 << " "

<< f.currPosition_p->read_traveledDistInLink() << "

<< f.currPosition_p->read_traveledDistTotal() << "
<< endl;

"
"

}// else
return stream;
};
bool operator<(Flight &o1, Flight &o2)
{ return o1.rotTimeRecommended.read_systemTime() < o2.rotTimeRecommended.read_systemTime(); }
bool operator>(Flight &o1, Flight &o2)
{ return o1.rotTimeRecommended.read_systemTime() > o2.rotTimeRecommended.read_systemTime(); }
bool operator==(Flight &o1, Flight &o2)
{ return o1.rotTimeRecommended.read_systemTime() == o2.rotTimeRecommended.read_systemTime(); }
bool operator!=(Flight &o1, Flight &o2)
{ return o1.rotTimeRecommended.read_systemTime() != o2.rotTimeRecommended.read_systemTime(); }
#endif

268

// TaxiEdge.h
#ifndef _TAXIEDGE_H
#define _TAXIEDGE_H
#include "Edge.h"
class TaxiEdge{
public:
TaxiEdge();
TaxiEdge(Edge* const newEdge_p, TaxiEdge* nxt = NULL);
~TaxiEdge();
Edge*
read_edgeEle_p();
TaxiEdge*
read_nextTaxiEdge_p();
void write_nextTaxiEdge_p(TaxiEdge* tempNextTaxiEdge_p);
private:
Edge*
edgeEle_p;
TaxiEdge*
nextTaxiEdge_p;
};
#endif

// TaxiEdgeList.h
#ifndef _TaxiEdgeLIST_H
#define _TaxiEdgeLIST_H
#include "TaxiEdge.h"
class TaxiEdgeList{
public:
TaxiEdgeList();
TaxiEdgeList(TaxiEdge* TaxiEdge_p);
~TaxiEdgeList();
void append(Edge* const);
void setFirst();
void moveNext();
void movePrev();
int length() const;
Edge* currEdge_p() const;
Edge* nextEdge_p() const;
Edge* tailEdge_p() const;
bool isInList() const;
TaxiEdge* read_curr_p();
void write_curr_p(TaxiEdge* cTaxiEdge_p);
void print_taxiEdgeList(TaxiEdge* cTaxiEdge_p);
private:
TaxiEdge *head_p,
*tail_p,
*curr_p;
};

//
//
//
//
//
//
//
//
//

#endif

269

Append ELEM at tail_p of list

set curr_p to first position
Move curr_p to next position
Move curr_p to previous position
Return current length of list
Return value of current ELEM
Return value of next ELEM
Return value of tail ELEM
TRUE if curr is within list

// TaxiPath.h
#ifndef _TAXIPATH_H
#define _TAXIPATH_H
#include "Edge.h"
class TaxiPath{
public:
TaxiPath();
TaxiPath(Edge* currEdge_p);
~TaxiPath();
Edge*
read_edgeEle_p();
TaxiPath*
read_nextTaxiPath_p();
void write_nextTaxiPath_p(TaxiPath* tempNextTaxiPath_p);
private:
Edge*
edgeEle_p;
TaxiPath*
nextTaxiPath_p;
};
#endif

// TaxiPathList.h
#ifndef _TAXIPATHLIST_H
#define _TAXIPATHLIST_H
#include "TaxiPath.h"
class TaxiPathList{
public:
TaxiPathList();
TaxiPathList(TaxiPath* taxiPath_p);
~TaxiPathList();
void append(const TaxiPath&);
// TaxiPath* remove();
// void setFirst();
void next();
void prev();
int length() const;
// int setPos(const int);
// void setValue(const TaxiPath&);
Edge* currEdge_p() const;
Edge* nextEdge_p() const;
// bool isEmpty() const;
bool isInList() const;
// bool find(const TaxiPath&);
private:
TaxiPath *head_p,
*tail_p,
*curr_p;
};

//
//
//
//
//
//
//
//
//
//
//
//
//

#endif

270

Insert ELEM at tail_p of list

Remove and return current ELEM
set curr_p to first position
Move curr_p to next position
Move curr_p to previous position
Return current length of list
Set curr_p to specific position
Set current ELEM's value
Return value of current ELEM
Return value of next ELEM
TRUE if list is empty
TRUE if curr is within list
Find the specifin value

//Type.h
#ifndef _TYPE_H
#define _TYPE_H
enum Node_Type{
taxiNode,
rwyNode,
gate,
rwyIntersectionNode
};
enum Edge_Type{
taxiEdge,
rwyEdge,
exitEdge
};
enum Operation_Type{
departure,
arrival
};
//enum Permission_Type
{yes, no};
enum VisitMark_Type
{visited, unvisited};
enum Priority_Type
{low, high};
// flight's priority for conflicting at intersection
enum ConflictChecked_Type
{done, notYet};
//
flight's
priority
for
conflicting
at
intersection
enum CurrentEdgeDirection_Type
{thisDirection, reverseDirection};
//
Edge's
curretn
operational direction
enum Aircraft_Type
{heavy, large, smal_};
// "small" is reserved for certain compiler
enum TwoOperations{dep_dep, dep_arr, arr_dep, arr_arr};
enum SP_Algorithm{
static_SP,
// static shortest path algorithm 1
td_SP_1, // time-dependent shortest path algorithm 1
td_SP_2
// time-dependent shortest path algorithm 2
};
enum FlightState_Type{
//for departure
pushingBack,
// taxing from gate to arpon(=ramp area)
rolling,
liftingOff,
endOfDeparture,
// take-off (rolling with const accel)
waitingOnRunway, // waiting around the runway or gate or from runway exit to gate
//for arrival
onFinal,
flaringOut,
freeRolling,
braking,
coasting,
adjustingBrake,
freeRollingSlow,
exitingRunway,
//touch-down -> exit
//for taxing for both operations (arrival/departure)
parking,
taxingToDepartureQueue,
taxingToGate,
delayedAtCross, //
waitingToTaxi,
speedUp,
steadyTaxing,
slowDown,
turning,
// taxing from gate to the around of runway
waitingInLine,
areaHolding,
//for both operations' communication
waitNextContact,
readyToCommunicate,
sendingRequest,
waitingCommand,
receivingCommand,
sendingConfirmation,
waitControllerContact
};
enum IdleBusy_Type
{idle, busy};
enum ControllerState_Type{
standby,
receivingRequest,
judgingCommand,
sendingCommand,
receivingConfirmation
};

271

enum ControllerMessage_Type{
unDecided,
fileApproved,
reRoute,
stopThere,
waitThere,
//waitControllerContact,
reStart,
clearToPushback,
clearToTaxi,
clearToTakeOff,
clearToLand
};
enum PilotRequest_Type{
requestTaxi,
requestPushBack,
requestTakeOff,
requestLanding
};
#endif

272

VITA

Hojong Baik was born in Seoul, Korea on May 1, 1962. After completing Dongsung High School
in Seoul, he entered the Civil Engineering program of Yonsei University in 1981. Upon
completion of his bachelor degree, he entered the graduate school in Seoul National University
for his master degree.
In May 1989, after graduating with his master degree in transportation planning and completing
his military service in the army, he joined the Korea Transport Institute (KOTI) as a researcher.
He had worked at KOTI for more than five years in KOTI. During this period, he joined several
projects in various fields including urban transportation, intelligent transportation system (ITS),
and logistics.
In August 1994, he enrolled the Department of Civil Engineering at Virginia Polytechnic Institute
and State University, to pursue his Ph. D. degree. He worked as a teaching assistant and also as a
research assistant at the National Center of Excellence for Aviation Operations Research
(NEXSTOR).

273