A What-if Analysis Tool for Planning Airport Traffic
Dr. Sebastian Timar, Mr. Mark Peters, Mr. Paul
Davis
Architecture Technology Corporation
Campbell, USA
stimar@atcorp.com
Dr. Phil Smith
The Ohio State University
Columbus, USA
smith.131@osu.edu
Abstract—This paper presents the implementation and
application of a prototype What-if Analysis decision support tool
for airport traffic planning. The What-if Analysis tool is used to
predict airport traffic performance during a future time horizon
with forecast operating conditions and to design Departure
Management Programs to mitigate the negative impacts of
predicted demand/capacity imbalances. Application scenarios
include dynamic weather imposing ground hold and/or Miles-In-
Trial restrictions on airport departures. We demonstrate the use
of the prototype for a historical traffic and weather scenario at
Charlotte Douglas International Airport (CLT). Future work
includes enhancing the capabilities and user interfaces of the tool,
and researching methods to predict future traffic management
initiatives from forecast weather and traffic conditions.
Keywords—departure management programs; integrated
airport arrival, departure and surface operations; airport traffic
modeling; airport traffic performance
I. INTRODUCTION
The FAA Surface Collaborative Decision Making (CDM)
Concept of Operations calls for managing departing aircraft to
balance airport surface traffic levels with both airport and
airspace capacity [1]. The NASA Airspace Technology
Demonstration (ATD)-2 concept calls for traffic management
technologies and operations to enable departing aircraft to
absorb delay at the gate, taxi unimpeded on the airport surface,
spend minimum time in the departure runway queue, and climb
continuously to cruise altitude [2][3][4].
A what-if analysis tool supports these goals by enabling
airport traffic managers to predict airport departure, arrival and
surface traffic over a time horizon of forecast operating
conditions, identify time periods when traffic demand is
estimated to exceed capacity, and specify Departure
Management Programs (DMPs) to mitigate the negative effects
of the predicted demand-capacity imbalance. What-if analysis
is particularly important for planning DMPs during periods of
dynamic convective weather. What-if analysis enables the
traffic managers to address important questions such as: How
will anticipated Traffic Management Initiatives (TMIs), such
as Miles-In-Trail (MIT) restrictions, impact airport traffic
978-1-5386-0365-9/17/$31.00 ©2017 IEEE
Ms. Mary Beth Lapis, Mr. Ian Wilson, Mr. Paul van
Tulder
The Boeing Company
Chicago, USA
mary.b.lapis@boeing.com
performance? How could a DMP be used to manage such
forecast TMIs? How could other traffic management initiatives
complement the DMP? What should the DMP parameters be?
DMP parameters can include categories of aircraft, target
queue lengths and queue length thresholds, capacity allocations
and time periods of application. Airport traffic management
decisions are especially complex if categorical DMPs (e.g.
departures to particular fixes) are needed, or if different airport
departure queues need to be managed differently.
This paper is organized as follows. Section II describes the
role and potential integration of what-if analysis into airport
arrival, departure and surface traffic management. Section III
presents implementation of a prototype what-if analysis tool.
Section IV presents results of using the prototype for airport
traffic analysis and DMP design analysis with historical traffic
and weather scenarios at Charlotte Douglas International
Airport (CLT). Sections V presents future work, and Section
VI presents conclusions.
II. OVERVIEW
This section summarizes the FAA CDM Concept of
Operations, the NASA ATD-2 concept of operations, how
what-if analysis integrates with these concepts, and scenarios
for what-if analysis.
A. Role of What-if Analysis in Airport DMP Planning
The FAA Surface CDM Concept of Operations [1] calls for
DMPs to meter the entries of departing aircraft into the
airport’s movement area to balance traffic levels with both
airport and airspace capacity. A Departure Reservoir
Coordinator (DRC) is responsible for planning, monitoring and
revising DMPs. The DRC performs what-if analysis to predict
time periods of demand-capacity imbalance and to specify
DMPs to mitigate their negative effects. The NASA Airspace
Technology Demonstration (ATD)-2 concept calls for
technologies and operations for integrated planning and
management of airport arrival, departure and surface traffic. A
goal is to enable departures to absorb delay at the gate, taxi
unimpeded on the airport surface, spend minimum time in the
departure runway queue, and climb continuously to cruise
altitude [2][3][4].
DMPs are implemented for bounded time periods when
runway queue lengths are predicted to exceed a Target
Departure Queue Length (TDQL). DMPs assign Target
Movement Area Entry Times (TMATs) to departures to control
traffic levels in the airport movement area. The TMATs may
minimize taxi-out time while meeting the TDQL to maintain
departure throughput. Aircraft operators comply with TMATs
by holding aircraft at the gates and other delay reservoirs in the
non-movement area of the airport. DMPs are planned and
implemented by a DRC. A what-if analysis capability and
candidate requirements are called for in [1][5][6][7] to assess
the impact of changes in departure restrictions, airport or route
configurations, traffic schedules or DMP parameters on airport
traffic performance, and to plan or revise DMPs as needed to
address these changes.
NASA’s ATD-2 is developing traffic management systems
for airports. The systems comprise traffic scheduling and
management technologies, decision support tools and
operations for integrated management of arrival, departure and
surface operations to enable ideal trajectories. Ideal departure
trajectories comprise delay absorbed at the gate, unimpeded
taxi on the airport surface, minimum time in the departure
runway queue, and continuous climb to cruise altitude [2][3].
The DMP can support the ATD-2 system by managing and
metering departures to minimize delay in taxi-out and climb,
and facilitating the use of airport surface delay reservoirs to
manage traffic. In the ATD-2 concept the departure controller,
supported by the NASA Spot and Runway Departure Advisor
(SARDA) [8] or similar tools and operations, can optimize the
sequencing of departures at the movement area entry points
and the runways in conjunction with the metering implied by
the TMATs. The ramp controllers can optimize the use of
delay reservoirs as per the TMATs and the gate pushback times
they may imply. A potential integration of what-if planning
with FAA Surface CDM DMPs and NASA ATD-2 traffic
management is depicted in Figure 1.
Fig. 1. Integration of What-if Analysis with Airport Departure Management.
The seven steps of the departure management process are
depicted in Fig. 1. Steps 1-5 comprise what-if analysis, and
steps 6-7 comprise departure management. Of the what-if
analysis process, steps 1-3 comprise airport demand analysis to
assess traffic performance over a forecasting time period, and
steps 4-5 comprise DMP design analysis to mitigate the
negative effects of the demand/capacity imbalance predicted to
occur. Specifically, in step 1, the DRC performs the what-if
analysis of the far-term forecasts (e.g., 45 minutes) of traffic
schedule, operating conditions and departure restrictions for
the traffic planning time period (e.g., 1-2 hours) to assess
airport traffic performance (e.g. throughput, queue lengths and
taxi times). In step 2, the DRC analyzes the impact of potential
changes to restrictions, runway rates, and scheduled traffic. In
step 3, the DRC predicts the need for a DMP, and DMP
parameters such as start time and duration. In step 4, the DRC
iteratively proposes and evaluates the effect of candidate
DMPs on managing demand/capacity imbalances and meeting
airport performance objectives. In step 5, the DRC specifies the
DMP using the selected parameters. In step 6, the DMP
specifies TMATs for departures using the near-term forecasts
(e.g., 15 minutes) of traffic schedule, operating conditions and
departure restrictions for the traffic planning time period. In
step 7, at the current traffic schedule, operating conditions and
departure restrictions, the ATD-2 system performs integrated
arrival-departure management.
B. Conditions for What-if Analysis
What-if analysis is useful when changes in TMIs impacting
airport departures, airport or route configurations, traffic
schedules or DMP parameters are forecast to occur. Changes in
TMIs include imposing MIT restrictions on departures to
particular fixes, airspaces or destination airports in response to
weather or traffic congestion. Changes in airport operating
conditions include changing the configuration or capacities of
airport runways or taxiways or terminal airspace departure
fixes. Changes in airport traffic include changing runways and
fixes assigned to flights, substituting flights, changing the
estimated off-block time or changing the gating plan. DMP
changes include extending or terminating the DMP and
evaluating different queue lengths.
In such dynamic forecast weather, traffic and airport
conditions, what-if analysis helps plan DMPs to minimize the
negative impact on airport traffic performance. Previous
research [9][10][11] has characterized the nature of the
challenges in managing weather patterns and has demonstrated
how decision support tools can improve the use of DMPs. The
what-if analysis would be used to design categorical (fix-,
runway- or destination-specific) DMPs and other traffic
management initiatives for departures subject to the particular
forecast restrictions. What-if analysis enables proactive
implementation of DMPs based on forecast traffic management
initiatives or other conditions, rather than reactive
implementation after the conditions are in effect.
C. Illustrative Example
As an example, we consider the impact of an actual
weather scenario at CLT shown in Fig. 2. For brevity, we only
address the impact on north-, east- and south-bound departures
via runway 18L after the storm has passed over the airport. At
4:45PM local time, the weather closed the airport and
continued to move east. Scheduled departures from runway
18L were delayed during the departure stop from 4:45PM to
5:15PM, and were impacted for another hour as the storm
moved across the departure fixes of the east gate.
Fig. 2. Example Convective Weather Event Sequence Causing an Airport
Departure Stop.
Under these conditions, what-if analysis could have been
performed as follows. 30 minutes prior to 4:45 PM, the airport,
Terminal Radar Approach Control (TRACON), Air Route
Traffic Control Center (ARTCC) and the Air Traffic Control
System Command Center (ATCSCC) traffic managers provide
the DRC with a 2-hour traffic management forecast. The
forecast anticipates a departure stop for 30-45 minutes and 30
MIT for departures via east gate departure fixes LILLS and
MERIL for 2 hours. The DRC performs what-if analysis and
determines that the quantity of scheduled departures and the
proposed traffic restrictions will result in excessive departure
queue lengths and surface traffic levels. The DRC evaluates
possible DMPs to mitigate the negative impacts on airport
traffic: a DMP for south gate departures from runway 18L to
address the backlog of flights after the ground stop, and DMPs
for departures via fixes MERIL and LILLS to address the
ongoing MIT restrictions. For departures via fixes MERIL and
LILLS, the DRC arrives at a DMP with a TDQL of 8 with an
upper threshold of 10 and a lower threshold of 8 to start at 5:15
PM and end at 6:45 PM. The DMP extends beyond the MIT
restriction end time to address the buildup of flights to these
fixes. For departures from runway 18L to the south gate
departure fixes subject to the ground stop, the DRC determines
a DMP to start at 5:15 PM and end at 6:45 PM, with a higher
TDQL of 10 because those fixes do not have MIT restrictions.
III. PROTOTYPE IMPLEMENTATION
The prototype what-if analysis tool comprises data inputs, a
user interface, a traffic simulation, a DMP emulation, and
assessment metrics. A block diagram of the components of the
prototype is depicted in Fig. 3.
Fig. 3. Block Diagram of What-if Analysis Prototype Components.
Data inputs specify pre-defined parameters for different
typical airport operating conditions. The user interface enables
selecting particular conditions and parameters and tailoring
them to the forecast operating conditions for evaluation, and
presents metrics for assessing predicted airport traffic
performance. The fast-time simulation is used to predict airport
traffic under the specified conditions without and with the
DMP. The DMP emulation meters departing aircraft to the
airport movement area as per user-specified parameters.
Metrics computation enables assessing airport traffic
performance. Each component is described in this section.
A. Data Input
Data input to the what-if analysis tool include scheduled
airport traffic, airport and terminal airspace configuration
information, and forecast traffic flow restrictions.
1) Airport Traffic Schedule and Configuration
The prototype what-if analysis tool takes as input the airline
scheduled airport arrivals and departures for the time horizon
of assessment. Embedded in these data are the implied
operating configuration of the airport and airspace. The data for
each flight include the anticipated origin or destination airport,
arrival or departure route, runway, terminal gate, non-
movement area entry or exit point (spot), gate out or in time,
and other flight information (e.g., aircraft type). The user
interface enables specifying the operations rate of each airport
runway. For prototyping, these data were derived from
historical airport traffic and listed in a format compatible with
the NASA Surface Operations Simulator and Scheduler
(SOSS) simulation software [12]. For actual implementation,
data would be obtained from the FAA System Wide
Information System (SWIM) Traffic Flow Management
System (TFMS) flight schedule data, airline gate plans and
typical airport operating procedures. Actual implementation
should also account for the state of airport arrival, departure
and surface traffic at the start of the forecast time period,
including gate occupancy, movement area traffic levels and
locations, and incoming arrivals and outgoing departures.
2) Traffic Management Initiatives
The what-if tool must also account for TMIs planned or
anticipated as per forecast conditions. The prototype models
MIT restrictions on departures to particular departure fixes or
destination airports or airspaces. The input restriction data
includes the control point, the start and end times, and the in-
trail separation. The user interface enables adding, removing or
altering the restrictions. Modeling is to be extended to TMIs
including Expected Departure Clearance Times (EDCTs),
Ground Delay Programs (GDPs), Airspace Flow Programs
(AFPs), Severe Weather Avoidance Programs (SWAPs) and
others. For actual implementation, restrictions would be
estimated from forecast traffic and weather conditions.
B. Airport Traffic Simulation
The prototype what-if analysis tool uses a fast-time
queueing simulation to predict airport traffic and performance.
The simulation uses a graphical node-link model of the airport
surface and terminal airspace, and parameters representing the
service rates at queuing nodes and the transit times of aircraft
along links connecting the nodes.
1) Airport Graphical Model
The graphical model of the airport surface and terminal
airspace captures the individual terminal gates, spots, runways
and arrival and departure fixes as nodes. The nodes are
connected by links representing airport surface and terminal
airspace transit routes. The gate, spot, runway and fix nodes
and their interconnections are synthesized from the input traffic
scenario file. Interactions of traffic at points other than the
gates, spots, runways and fixes are not currently modeled.
Future enhancements include runway crossing and other
congestion points, gate groups and other delay reservoirs.
2) Traffic Queuing Simulation
The traffic queuing simulation models each node in the
airport graphical model as a queue. Nodes are points where
traffic flow is constrained. If the arrival rate of traffic to the
node exceeds the effective traffic flow rate that can be met at
the node, the aircraft form a queue as they wait for entry to,
and passage through, the node [13]. Links are transit segments
between nodes.
Queue parameters for each node include a service time,
Tservice, to process each flight, and a queue size limit, Qmax. The
service time can represent the time for the controller to clear
the aircraft to take off or enter the movement area, the
minimum in-trail separation with the previous flight for safety,
for example. The queue size limit specifies the maximum
number of aircraft that may wait in line for service by the node.
This can represent the number of aircraft a taxiway or
hardstand can accommodate. Links are modeled as nominal
inter-node transit times, Ttransit. Node models process flights in
first-in, first-out order. A flight, j, is serviced by a node, i, at its
node entry time which is the later of its node arrival time or the
exit time of its node predecessor, Ti,jentry = max(Ti,jarrival, Ti,j-
1 The prototype tool implements a DMP emulation. The
exit). Each flight exits the node at its node entry time (i.e., the
time at which it is serviced) plus the node’s service time, Ti,jexit
= Ti,jentry + Tiservice. Delay accrued due to waiting in the queue is
Ti,jdelay = Ti,jentry – Ti,jarrival. Link models propagate each flight to
the next i+1 node in its prescribed route, Ti+1,jarrival = Ti,jexit +
Ti,i+1transit, processing flights in their order of exit from the node.
The runway node queuing models account for MIT
restrictions on departures to particular fixes, airports or
airspaces by modeling the typical local controller practice of
applying in-trail separation at the runway between successive
departures to that control point to satisfy the MIT restriction at
the control point. Based on analysis of CLT operations [14],
the model applies inter-departure spacing which is 2/3 of the
MIT at the control point. This is converted to time assuming a
takeoff speed of 150 knots [15]. Modeling includes splitting
the departure sequence to maintain throughput.
The gate node queuing models account for single aircraft
occupancy for the modeled occupancy time (service time).
Departures enter their assigned gates as per their airline-
scheduled gate pushback times. Arrivals enter their assigned
gates when the gate is unoccupied and there is sufficient time
to occupy the gate. Tail tracking of arrivals and departures is
not accounted for. This modeling approach can result in
significant taxi-in delay and should be enhanced.
3) Modeling Parameters
Queue service times for the fix nodes correspond to in-trail
separation of 3-nautical miles and a speed of 250 knots.
Runway queue service times correspond to 30 operations per
hour. Spot queue service times of 5 minutes correspond to time
for movement area entry clearance to be requested, granted and
acted upon. Terminal gate queue service times correspond to
occupancy of 30 minutes.
Links are modeled as the nominal transit times of aircraft
between pairs of nodes. For prototyping focused on CLT,
values were estimated from previous analyses of multiple days
of ASDE-X surveillance data for CLT [16]. The gate-spot time
of 4.0 minutes is an average of all the gate-spot transit times.
The spot-runway time of 2.0 minutes is the 5th percentile of all
the spot-runway times. The runway-fix time of 14.0 minutes is
the average of values obtained from high-fidelity simulations
of aircraft flying the CLT MERIL departure procedure [17] and
scaling that average to other CLT departure procedures based
on flight procedure leg distances obtained from National Flight
Data Center (NFDC) data.
C. Departure Management Program Emulation
The prototype what-if analysis tool emulates a user-
specified DMP as TMATs to meter the entries of departures
into the movement area of the airport. The what-if analysis tool
then simulates airport traffic under the DMP in fast-time to
assess the impact of the DMP on airport traffic performance.
DMP parameters include categories of flights, start and stop
time, TDQL and its thresholds, unscheduled demand buffer,
and many others. The DMP parameters may be varied, and
successive simulations conducted, to find DMP parameters for
implementation in the future time period of interest.
1) Target Movement Area Entry Time (TMAT) Scheduling
DMP emulation generates a candidate schedule of TMATs for
departures as per user-specified conditions including departure
rates for each departure runway, applicable TMIs on individual
departures, and candidate DMP parameters. Each departure’s
TMAT implies a scheduled gate pushback time to absorb
scheduled delay, which is the TMAT minus the nominal gate-
spot transit time for its terminal. In turn, the what-if tool
simulates airport traffic using the DMP gate pushback times to
assess its airport traffic performance impact. The time-based
scheduling methods follow the principles, including the Order
of Consideration algorithm, specified in [18]. The prototype
includes a feedback control law which adjusts the movement
area entry rate of departures used in scheduling the TMATs to
maintain the target departure queue length at each runway.
TMAT scheduling initializes with identifying the set of
departures subject to the DMP and the terminal gates, runways
and departure fixes they use. These are scheduling reference
points. The estimated times of arrival of a departure flight to its
reference points are obtained from its airline-scheduled gate
out time and the nominal transit times modeled for the airport
links. The TMAT scheduling initially sorts the flights at each
reference point based on their estimated times of arrival. At
each reference point, TMAT scheduling sorts flights by
increasing time, and locally schedules their times of arrival,
delaying the flights as needed, to satisfy flow restrictions,
separation minima, runway operations rate or other inter-flight
time spacing limits associated with the reference point.
TMAT scheduling ensues with scheduling the time of each
departure at each of its reference points, working sequentially
through each reference point, delaying the scheduled time of
arrival of the flight at the reference point as needed to satisfy
in-trail separation with the previous flight at the reference point
as per the applicable constraints. The scheduling algorithm
iterates until converging on scheduled times of arrival at
reference points which yield no conflicts or further delays
while satisfying all applicable inter-aircraft spacing limits. The
TMATs imply a takeoff sequence and schedule at the departure
runway which satisfies the specified runway operations rate,
departure restrictions (in this case, MIT restrictions for specific
fixes and time periods) and target queue length, assuming
unimpeded transit to the departure runway queue.
2) Queue Length Control
Throughout the process, TMAT scheduling monitors the
resulting departure queue length at each runway with a DMP,
and uses a control law based on the error between the actual
queue length and the TDQL to adjust the departure pushback
rate used for scheduling TMATs.
D. Traffic Performance Analysis
The prototype tool evaluates airport traffic performance
indicators for the simulated traffic to assess the impact of
demand/capacity imbalances on airport operations, and to
estimate the impact of DMPs to mitigate those impacts. Time-
series and aggregate metrics for departures and arrivals for
each runway are evaluated. Metrics for departures include per-
runway throughput, runway queue length relative to the TDQL,
average taxi-out times and gate-out delay. Metrics for arrivals
include per-runway throughput, taxi-in time, and gate-in delay
(due to gate holding of departures). The user interface presents
time-histories as bar or line charts of data in 15- or 60-minute
bins, and presents aggregate metrics in tables.
E. User Interfaces
The prototype tool includes a user interface for specifying
the scenario, configuring the DMP, and assessing airport traffic
flow performance. The goal is to provide the DRC and
stakeholders with an ability to have situational awareness,
explore alternative scenarios and conditions, evaluate
alternative DMP designs, and assess sensitivity of airport
traffic performance to changing conditions. The prototype
implementation is very simple, but sufficient to provide access
to the data of interest. Future work includes extending and
enhancing the interface.
F. Verification
To verify the airport traffic simulation, we verified the
modeling logic and compared simulated airport traffic to FAA
Aviation System Performance Metrics (ASPM). We verified
the modeling logic by ensuring the trajectories of the simulated
flights (described by the sequence of gate, spot, runway and fix
nodes and simulated times at those nodes) complied with the
queue service rates, queue entry/exit sequencing, link transit
times, and departure restrictions.
We compared simulated airport traffic to FAA ASPM data
for August 8, 2014, a day where CLT consistently operated in
the south flow runway configuration with typical departure
restrictions. The modeled traffic schedule was created from
operations data as described in [17] and captured 19-hours of
arrivals and departures. Simulated operations were fewer than
ASPM-recorded scheduled operations due to deriving the
traffic input file from actual operations; flight cancellations and
consolidations by aircraft operators inherent in the operations
data are not in the schedule data. Simulated throughput was
lower than ASPM due to a conservative modeled runway
capacity. Average taxi-out time from the simulation compared
closely to ASPM. Average taxi-in time from the simulation
was higher due to the simple modeling of gate management.
For verification of the DMP emulation, we used the
prototype tool for other CLT scenarios of high traffic demand
and significant TMIs. We verified the DMP emulation
specified TMATs such that the runway queue lengths complied
with the TDQL, throughput complied with the runway rates,
and departures complied with their MIT restrictions.
IV. PROTOTYPE DEMONSTRATION
We evaluated and demonstrated the what-if analysis tool
using multiple historical traffic and weather scenarios for CLT.
We present the results for one particular scenario.
A. Conditions
Conditions comprised a schedule of arrivals and departures
representing aircraft operator scheduling intent, and traffic
restrictions representing management initiatives to address
weather events. Modeling used operator Out-Off-On-In
(OOOI) data for a month of operations at CLT to estimate
pushback and landing times, ramp control procedures for a
major aircraft operator at CLT to obtain gate-spot assignments,
Aircraft Situation Display to Industry (ASDI) data to estimate
arrival and departure fixes, historical weather data, and data
from NASA describing ATCSCC TMIs to model restrictions.
Airport traffic conditions represent August 8, 2014
operations at CLT discussed in the Verification section. The
scheduled pushback times of departures exhibited 9 banks
occurring at approximately 1.5 hour intervals, peaking at 25 to
35 departures in a 15-minute time period, depicted in Fig. 4.
Our demonstration evaluated operations from 2:08 PM to 5:58
PM, local time. During this time, scheduled departures
exhibited two 45-minute banks of approximately 20 pushbacks
per 15-minute period, bounded by the dashed lines in Fig. 4.

Fig. 5. Airport demand analysis predicted departure throughout, runway

queue length, taxi-out time and gate delay by runway.

In this case, the TDQL (Target Departure Queue Length)

was specified somewhat arbitrarily. For actual operations, the
TDQL would be specified to maximize airport throughput,
Fig. 4. Modeled Quarter-hour Scheduled Pushbacks for CLT on August 8, while avoiding excess traffic, as per forecast runway
2014 and 4-hour Period Selected for What-if Analysis. configuration and other operating conditions [19][20][21].

We identified multiple weather days of interest for CLT in 2) DMP Design Analysis
August 2014, corresponding to convective weather at CLT or We used the prototype tool to perform DMP design
proximate facilities, resulting in significant restrictions on analysis. While numerous other DMP types and parameters
departures, including MIT restrictions, Calls For Release may be specified, for example multiple coincident categorical
(CFRs), and Expected Departure Clearance Times (EDCTs). DMPs for all departures to different fixes and/or runways, we
For this demonstration, we considered traffic restrictions for implemented a single DMP for all departures. Automated
August 18, 2014, where heavy rainfall near CLT resulted in analysis of the predicted queue lengths proposed the DMP start
MIT restrictions that impacted 180 departures, CFRs that at 3:00 PM, before the runway 18L queue exceeded the TDQL
impacted 41 departures, and EDCTs that impacted 2 of 3 aircraft, and end at 7:00 PM, after the runway 18C queue
departures. During the period from 2:08 PM to 5:58 PM, local drops below the TDQL. Our analyses of other periods at CLT
time, the restrictions comprised 15 MIT for departures via the of significant departure push and departure restrictions
MERIL fix from 2:28 PM to 5:10 PM. This impacted 40 of the determined that initiating the DMP prior to the restrictions
159 departures in this time period. Of the 40 departures, 36 avoids queue buildup and enables consistent and efficient
departed runway 18L, and 4 departed runway 18C. traffic performance throughout the time period of restricted
traffic flow. Results with the DMP are depicted in Fig. 6.
B. Results
The prototype what-if analysis tool was used for airport
demand analysis and DMP design analysis for the specified
conditions at CLT. Results are presented in this section.
1) Airport Demand Analysis
The prototype tool was used to perform airport demand
analysis for the 4-hour period of scheduled departures under
the prescribed departure restrictions. The airport traffic state at
the start of the prediction period did not account for prior
traffic; in practice the prediction should initiate from the
current or estimated traffic state. Analysis of scheduled
pushbacks identified quarter-hour time periods where their
quantities exceeded airport departure capacity. Predictions of
airport traffic movement estimated the departure queue lengths
for runways 18L and 18C would exceed 3 aircraft, reaching 11
and 12 aircraft respectively, and average quarter-hour taxi-out
times would peak in excess of 30 minutes. Throughput would Fig. 6. DMP design analysis proposed departure throughout, runway queue
saturate at the prescribed 30 operations per hour. Results are length, taxi-out time and gate delay by runway.
depicted in Fig. 5.
 The results show that, with the DMP, throughput saturates Regarding tool enhancements, Fig. 7 depicts a notional
at the prescribed 30 operations per hour (7-8 operations per interface for modeling forecast TMIs, planning DMPs and
quarter-hour). For runway 18L, the departure queue length evaluating the impact on airport departure and arrival traffic
comes close to the TDQL of 3 aircraft, peaking at 4 aircraft, performance for baseline (B) and alternative (A1) operating
and average quarter-hour taxi-out times reduce to 15 minutes. plans.
The reduced taxi-out delay is shifted to gate departure delay,
which reaches 10 minutes for runway 18L departures, and
almost 12 minutes for runway 18C departures.
For runway 18C, however, the queue length is predicted to
reach 7 aircraft and average taxi-out time reaches 25 minutes.
This is because runway 18C is shared with arrivals, and
arrivals land to runway 18C in the subject time period. To
account for the shared runway use, the DRC could reduce the
departure rate of the DMP for runway 18C to release fewer
departures to runway 18C.
What-if analysis predicted the changes in aggregate
performance of airport departure traffic as a result of
implementing the DMP listed in TABLE I.

TABLE I. IMPACT OF DMP ON PERFORMACE OF DEPARTURES BY

RUNWAY
Departure Traffic Performance
Runway & Average Maximum Average Average Average
DMP Throughp Queue Queue Taxi-out Gate
Condition ut Length Length Time Delay
(Aircraft) (Aircraft) (Aircraft) (Minutes) (Minutes)
No 22 12 3 17.1 0.0
18L Fig. 7. Notional interface for what-if analysis tool to predict airport traffic
Yes 22 4 1 12.6 2.9 performance and design DMPs.

No 20 14 4 18.6 0.0 This depicts the example scenario of weather passing over
18C
Yes 20 10 3 16.3 3.0 CLT, calling for a departure ground stop on runway 18L
ending at 2115 ZULU, and 30MIT for departures via fixes
MERIL and LILLS, from 2115 to 2215. The departure queue
What-if analysis also predicted the changes in aggregate lengths are predicted to exceed 16 aircraft in the 15-minute
performance of airport arrival traffic as a result of the DMP. time periods from 2115 to 2230. The DMP reduces the
Average arrival throughput for runways 18R, 23 and 18C were predicted queue lengths to 16 aircraft, within the thresholds of
predicted to remain at 20 aircraft, 17 aircraft and 7 aircraft, +20/+10 aircraft. Queue length, off-out and off delay metrics
respectively. ON-to-IN times for arrivals from runways 18R, indicate significant improvement in airport traffic performance
23 and 18C were predicted to increase by 1.6 minutes, 1.0 under the alternative. Situational awareness is enhanced with a
minutes and 2.1 minutes, respectively, if departures were held planview display of the traffic color-coded by applicable
at their gates during the DMP and gate assignments for arrivals restriction, depicted in Fig. 8.
were maintained.

V. FUTURE WORK
Future work for what-if analysis includes developing
methods for estimating traffic management initiatives from
forecast weather, developing and enhancing what-if analysis
tool prototypes with improved traffic prediction capabilities
and DMP planning features, and further exploring what-if
analysis operations including stakeholder collaboration in
situational assessment and DMP planning.
Regarding conditions forecasting, proactive designs and
implementations of DMPs will have to be developed based on
forecasts of traffic management initiatives. Methods are needed
to estimate traffic flow management restrictions and other
conditions from weather forecasts as input to the what-if
analysis, and to use what-if analysis to design DMPs to
accommodate those forecasts and their uncertainties.

Fig. 8. Notional interface for what-if analysis tool for situational awarenesss
of airport traffic. Flights color-coded by applicable departure restrictions.
The interface highlights in yellow the locations of departing
aircraft assigned to the MERIL departure fix. The DRC can
allocate these aircraft to delay reservoirs in the non-movement
and movement areas of the airport as needed to satisfy TMATs
and the departure restrictions.
Future work includes enhancing the what-if tool modeling
and analysis capabilities. This includes enhancing airport and
airspace representation, in particular to capture delay reservoirs
(e.g., hardstands and taxiway segments used for holding
aircraft) and user interfaces and utilities to support managing
their use. Future work also includes enhancing the tool to
perform sensitivity analysis of traffic performance to variations
in forecast operating conditions and DMP parameters.
Extending and enhancing interfaces for aircraft operators and
other stakeholders would be helpful for common situational
awareness and collaborative traffic planning.
VI. CONCLUSIONS
This paper presents a prototype what-if analysis tool for
airport traffic planners to predict airport traffic performance
over forecast operating conditions and design DMPs to
mitigate the negative effects of predicted demand-capacity
imbalances. The tool is demonstrated for an historical traffic
and weather scenario at CLT to assess airport traffic
performance, specify the start and end times of a DMP for
airport-wide departures, and evaluate the resulting traffic
performance.
General requirements for what-if analysis include the
following. Airport demand analysis requires representing
airport traffic and weather scenarios and modeling airport
traffic movement. DMP design analysis requires specifying the
parameters for one or more DMPs, and emulating the DMP to
assess its impact on airport traffic performance. Scenario
modeling includes anticipated airport arrivals and departures,
airport operating conditions and traffic management initiatives
which could impact airport traffic performance. Airport traffic
modeling should capture surface characteristics which impact
traffic flow and timing, including arrival and departure runway
and route resources, arrival-departure interaction points, traffic
control points and delay reservoirs while enabling rapid
evaluation. DMP emulation requires DMP parameter
configuration, algorithms for TMAT computation, and
modeling of traffic control as per the TMATs. Interfaces for
specifying airport conditions, traffic demand and traffic
restrictions are useful for exploring and assessing the impact of
possible deviations from current or anticipated operating
conditions, and designing responses to mitigate their effects.
Algorithms for recommending DMP parameters, and
accounting for the uncertainty in forecast data and parameters,
can significantly enhance the decision support of the what-if
analysis tool.
ACKNOWLEDGMENT
We thank Savita Verma and Yoon Jung of NASA Ames
Research Center for their support in conducting this work.
REFERENCES
[1] Federal Aviation Administration. 2012. “US Airport Surface
Collaborative Decision Making (CDM) Concept of Operations in the
Near-Term.”
[2] National Aeronautics and Space Administration. 2015. “A Concept for
Integrated Arrival/Departure/Surface (IADS) Traffic Management for
the Metroplex, Airspace Technology 2 Concept of Operations
Synopsis.”
[3] National Aeronautics and Space Administration. 2016. “Airspace
Technology Demonstrations (ATD) Project Industry Day, ATD-2 IADS
Metroplex Traffic Management Overview Brief.”
[4] Saraf, A., Timar, S., Shen, N., Idris, H. 2015. “Preliminary Queueing
Analysis of Integrated Departure Operations in Metroplex Systems,”
Proceedings of the 34th Digital Avionics Systems Conference (DASC),
Prague, Czech Republic.
[5] Metron Aviation. 2012. “Surface Collaborative Decision Making
Concept, HITL 01 Summary, August 21-23, 2012.”
[6] Metron Aviation. 2012. “Surface Collaborative Decision Making
Concept, HITL 01 Summary, June 26-28, 2012.”
[7] Metron Aviation. 2013. “Surface Collaborative Decision Making, HITL
7 Summary, January 15-17, 2013.”
[8] Jung, Y., Montoya, J., Gupta, G., Malik, W., Tobias, L., Want, H. 2011.
“Performance Evaluation of a Surface Traffic Management Tool for
Dallas/Fort Worth International Airport.” Proceedings of 9th USA
Europe Air Traffic Management Research and Development Seminar
(ATM2011), Berlin, Germany.
[9] Smith, P.J., Weaver, K., Fernandes, A., Durham, K., Evans, M.,
Spencer, A. and Johnson, D. 2012. “Supporting distributed management
of the airport surface.” Proceedings of the 2012 AIAA Digital Avionics
Systems Conference (DASC), Williamsburg, VA.
[10] Fernandes, A., Smith, P.J., Durham, K. and Evans, M. 2015.
“Individual Problem Representations in Distributed Work.” Proceedings
of the 2015 International Symposium on Aviation Psychology, Dayton,
OH.
[11] Smith, P.J., Fernandes, A.B., Durham, K., Evans, M., Spencer, A.,
Beatty, R. Wiley, E. & Spencer, A. 2011. “Airport Surface
Management as a Distributed Supervisory Control Task.” Proceedings
of the 2011 AIAA Digital Avionics Systems Conference (DASC),
Orlando, FL.
[12] Windhorst, R.. 2012. “Towards a Fast-time Simulation Analysis of
Benefits of the Spot and Runway Departure Advisor.” Proceedings of
the AIAA Guidance, Navigation and Control (GNC) Conference,
Minneapolis, MN.
[13] deNeufville, R., Odoni, A. 2003. Airport Systems: Planning, Design and
Management. McGraw-Hill, New York, New York, pp. 819-850.
[14] Lohr, G. 2016. “Air Traffic Operations at the Charlotte Douglas
International Airport (KCLT).”
[15] “Airliner Takeoff Speeds.”
http://www.aerospaceweb.org/question/performance/q0088.shtml. (As
of 19 September 2016).
[16] Saab Sensis Corporation. 2012. “Systematic Assessment of Surface
Optimization Functions—Methods and Metrics Report, for the
Adaptation of a Surface Management Tool to Multiple, Capacity
Constrained Airports Project.” Contract NNA11AC50C.
[17] Architecture Technology Corporation. 2016. “Methods of Increasing
Terminal Airspace Flexibility and Control Authority, Option Year 1
Final Report.” Contract NNA14AC42C.
[18] Wong, G.. 2000. “The Dynamic Planner: The Sequencer, Scheduler, and
Runway Allocator for Air Traffic Control Automation.” NASA/TM-
2000-209586.
[19] Anagnostakis, I., Idris, H., Clarke, J.-P., Feron, E., Hansman, R. J.,
Odoni, A., Hall, W. 2000. “A Conceptual Design of A Departure
Planner Decision Aid.” Proceedings of the 3rd USA/Europe Air Traffic
Management R&D Seminar, Napoli, Italy.
[20] Welch, J., Bussolari, S., Atkins, S. 2001. “Using Surface Surveillance
To Help Reduce Taxi Delays.” Proceedings of the 2001 AIAA Guidance,
Navigation and Control (GNC) Conference, Montreal, Canada.
[21] Nakahara, A., Reynolds, T. 2011. “Analysis of a Surface Congestion
Management Technique at New York JFK Airport.” Proceedings of the
11th AIAA Aviation Technology, Integration and Operations (ATIO)
Conference, Virginia Beach, VA.