See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/266602687

Process and Software Tools for Generating Airport Models to Support Surface
Operation Analyses

Article · August 2009

DOI: 10.2514/6.2009-5915

CITATION READS
1 1,488

7 authors, including:

Victor H. L. Cheng Gregory Sweriduk

Optimal Synthesis rLoop, Inc.
96 PUBLICATIONS   1,184 CITATIONS    33 PUBLICATIONS   816 CITATIONS   

SEE PROFILE SEE PROFILE

Aditya Saraf David Schleicher

ATAC Corporation ATAC
42 PUBLICATIONS   207 CITATIONS    31 PUBLICATIONS   188 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

PhD dissertation View project

Metroplex Terminal Area Airspace Operations View project

All content following this page was uploaded by Victor H. L. Cheng on 31 March 2015.

The user has requested enhancement of the downloaded file.

AIAA Modeling and Simulation Technologies Conference AIAA 2009-5915
10 - 13 August 2009, Chicago, Illinois

Process and Software Tools for Generating Airport Models

to Support Surface Operation Analyses

Victor H. L. Cheng 1, Gregory D. Sweriduk2, Anthony Y. Seo3, Wei-Man Lin4, and Jack C. Yeh5
Optimal Synthesis Inc., Los Altos, CA, 94022

and

Aditya Saraf6 and David R. Schleicher7

Sensis Corporation, Seagull Technology Center, Campbell, CA, 95008

In NASA’s NextGen-Airspace Project, the System Level Design, Analysis, and Simulation
Tools (SLDAST) Research Focus Area (RFA) has responsibility for developing system-level
analysis and simulation tools that can be used to assess concepts and technologies developed
by RFAs across several NASA projects. The most prominent assessment product from
SLDAST is the Airspace Concept Evaluation System (ACES), which provides simulation
capabilities over the whole NAS with details down to airport surface traffic. Among the
options in ACES for airport modeling, the most detailed one involves a link/node queuing
model which represents the complete layout of the airport surface including all runways,
taxiways, ramp area, and gates. This link/node surface model is adequate for assessing
various options of surface operations, including trajectory-based operations, an important
capability considered for the NextGen transformation. Due to the amount of details, the
generation of a link/node surface model for each airport is quite involved. It requires
modeling the airport surface layout by geo-registering all important locations on the surface
such as gates and runway/taxiway intersections, and connecting the nodes into a network to
include all the taxiways, runways, and taxi paths within the ramp area. The resulting
link/node data are eventually used in defining a queuing network for simulating the surface
operations. As a large number of such models will be required to support simulation of the
nation-wide traffic, a modeling process has been developed for generating the model data to
ease the effort in developing these surface models. In addition to generating the complex
link/node data, the process needs to specify procedures for gate assignment and route
planning. A suite of software tools, known as SurfTools, has been developed to support the
modeling process by automating the generation of the necessary data files required by the
simulation. This paper provides a high-level description of the modeling process, and
describes the design and implementation of SurfTools. A companion paper describes in more
detail the modeling process, the model data requirements, and how the models are used to
support surface-operation simulations.

I. Introduction
O realize the Next-Generation Air Transportation System (NextGen) Concept of Operations (ConOps)1
T envisioned by the Joint Planning and Development Office (JPDO), many programs have been organized by
different agencies to develop operational concepts and technologies to address the identified needs. In NASA’s
NextGen-Airspace Project2, the System Level Design, Analysis, and Simulation Tools (SLDAST) Research Focus
1
Vice President, Optimal Synthesis Inc., Los Altos, CA 94022, AIAA Associate Fellow.
2
Research Scientist, Optimal Synthesis Inc., Los Altos, CA 94022, AIAA Member.
3
Research Engineer, Optimal Synthesis Inc., Los Altos, CA 94022.
4
Research Engineer, Optimal Synthesis Inc., Los Altos, CA 94022.
5
Research Engineer, Optimal Synthesis Inc., Los Altos, CA 94022.
6
Systems Engineer, Sensis Corporation, Seagull Technology Center, Campbell, CA 95008, AIAA Member.
7
Senior Systems Engineer, Sensis Corporation, Seagull Technology Center, Campbell, CA 95008, AIAA Member.
1
American Institute of Aeronautics and Astronautics

Copyright © 2009 by Optimal Synthesis Inc. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.
Area (RFA) has responsibility for developing system-level analysis and simulation tools that can be used to assess
concepts and technologies developed by RFAs across several NASA projects, among which the most relevant ones
include the NextGen-Airspace Project and NextGen-Airportal Project3 of the Airspace Systems Program, and the
Intelligent Integrated Flight Deck Project of the Aviation Safety Program.
The most prominent assessment product from SLDAST is the Airspace Concept Evaluation System (ACES)4,5,
which provides simulation capabilities over the whole NAS with details down to airport surface traffic. ACES has
three options for airport modeling: (i) a nodal model which represents the whole airport as a source and sink node;
(ii) a runway model which contains representations of all runways for arrival and departure simulations; and (iii) a
detailed link/node model which represents the complete layout of the airport surface including all runways,
taxiways, ramp area, and gates. This last option—known as Surface Traffic Limitations Enhancement (STLE)6—is
adequate for assessing various options of surface operations, including trajectory-based operations, an important
capability considered for the NextGen transformation1.
Due to the amount of details, the generation of a link/node surface model for each airport is quite involved. It
requires modeling the airport surface layout by geo-registering all important locations on the surface such as gates
and runway/taxiway intersections, and connecting the nodes into a network to include all the taxiways, runways, and
taxi paths within the ramp area. The resulting link/node data are eventually used in defining a queuing network for
simulating the surface operations. To ease the effort in developing these link/node surface models, as a large number
of such models will be required to support simulation of the nation-wide traffic, a modeling process has been
developed for generating the model data and specifying procedures for gate assignment and route planning. A suite
of software tools, known as SurfTools, has been developed to support the modeling process by automating the
generation of the necessary data files required by the simulation. SurfTools also includes a visualization tool known
as SView to support editing of the data files and visualization of the simulation results to help verify the surface
models.
Section II provides an overview of the modeling requirements for building STLE models. Section III provides a
high-level description of the modeling process developed to build the models, including the roles of using SurfTools
and other publicly available tools in this process. This is followed by more detailed descriptions of the different
steps in the process, starting with Section IV on construction of the link/node graphical model and continuing with
Section V on creation of the necessary airport model files needed by STLE. To allow ACES to feed air traffic
through the terminal airspace to the STLE airport models, Section VI describes the process in preparing the
necessary ACES terminal area models. Section VII describes the animation function in SView to help with post-
simulation analyses by allowing the user to visualize the simulation data. A companion paper7 describes in more
detail the modeling process, the model data requirements, and how the models are used to support surface-operation
simulations.

II. Overview of Modeling Requirements

ACES provides the functions to assess the impacts of various concepts for improving and increasing the flow of
traffic in the National Airspace System (NAS), and the role of STLE is to provide ACES with the functions to assess
surface operations at a comparable level of fidelity that takes into consideration the layout and configuration of the
airports. ACES/STLE requires a substantial number of airport and operation model files for each airport to run a
simulation. For an airport to be an STLE-modeled airport, both an airport configuration and a terminal area
configuration are required. A complete set of files comprises a number of .xml, Drools, and MySQL files. To help
with preparation of these files, a suite of software tools have been developed. This suite of tools is referred to as
SurfTools, and it contains (i) a number of batch processes for building the necessary files based on a set of input
data files, as well as (ii) an interactive tool known as SView to ease the developer’s effort in preparing these input
files. SView also provides an animation function for visualizing simulation output data. The following subsections
describe the files required by STLE. The procedures for building the model files and data will be described in
subsequent sections, along with the description of the SurfTools components developed to help with the process.

A. Overview of STLE Files

STLE uses a graph-theoretic model to simulate the movement of surface traffic. It therefore needs information
on the structure of the graph, any constraints on movement, as well as logic for choosing gates for flights. It uses
functions provided by the Spring framework to read in the context files (*.xml) for STLE-modeled airports at
runtime. The ACES Enhanced Terminal Model (ETM) provides the necessary terminal airspace information in the
form of SQL database files to support moving traffic to and from the STLE airports. The next two sections describe
the airport and terminal file requirements, respectively. For these files, the letters “XXX” stand for the 3-letter

2
American Institute of Aeronautics and Astronautics
airport identifier code, such as “DFW” for Dallas-Fort Worth International Airport or “EWR” for Newark
International Airport.

B. STLE Airport Configuration Files

Each STLE airport model requires 14 xml files, and one .drl file, as described in Table 1. The first six of these
files require only a minor modification by the user by changing the 3-letter airport identifier code. The remaining
ones, indicated by the boldfaced filename, require generation of the file content by the user. SurfTools has been
developed to provide some functions to generate some of these files. Others, particularly those relating to gate
assignments, have to be edited by the user or model developer.

Table 1. Airport Configuration Files Required for STLE Model

File
AirportAtcAgent_Runway_KXXX.xml
AirportSurfaceAgent_KXXX.xml
AirportSurfaceAgent_KXXX_Misc.xml
AirportSurfaceAgent_KXXX_Mode_Constrained.xml
AirportSurfaceAgent_KXXX_Mode_Unconstrained.xml
AirportSurfaceAgent_KXXX_SystemBridge.xml
AirportSurfaceAgent_KXXX_Gate.xml
AirportSurfaceAgent_KXXX_Graph.xml
AirportSurfaceAgent_KXXX_Movement.xml
AirportSurfaceAgent_KXXX_Runway.xml
AirportSurfaceAgent_KXXX_Trajectory.xml
AirportSurfaceAgent_KXXX_Unconstrained_Graph.xml
AirportSurfaceAgent_KXXX_Unconstrained_Movement.xml
AirportSurfaceAgent_KXXX_ Unconstrained_Runway.xml
GateAssignment_KXXX.drl
Description
Overrides standard runway modeled behavior and creates an
STLE AirportSurfaceAgent for XXX.
Main configuration file for an STLE modeled XXX airport.
Contains a few bean definitions and imports either the
constrained or unconstrained configuration file.
Contains miscellaneous beans that do not directly align with the
content of the other configuration files.
Imports the configuration files appropriate for standard STLE
operations, or “Constrained Mode.”
Imports the configuration files appropriate for running STLE in
“Unconstrained Mode.”
Contains beans related to running STLE in the host environment
(i.e., ACES)
Contains beans related to the gate configuration for XXX.
Contains the beans that make up the Airport Surface Graph.
Contains beans related to movement along the surface of XXX.
Contains beans related to the runway system of XXX.
Contains beans related to trajectory generation and clearance
authorization.
Contains the beans that make up the Airport Surface Graph
when running in “Unconstrained Mode.”
Contains beans related to movement along the surface of XXX
when running in “Unconstrained Mode.”
Contains beans related to the runway system of XXX when
running in “Unconstrained Mode.”
Contains JBoss rules for gate assignment.

STLE uses JBoss Rules (Drools), a rule engine, to assign gates. The JBoss rules are contained in the file
GateAssignemnt_KXXX.drl. The rules and gate information are airport-specific, so currently this is done manually.
More details are given in Section V.A.1.

C. ACES Terminal Model Database

The Enhanced Terminal Model (ETM) used by ACES requires data for defining the terminal area, including
metering fixes, runway interactions, etc. This information is stored in MySQL tables in the form of the following
data sets:
• Aircraft Characteristics
• Fix Separation Rule
• Formation Landing
• Java Data Objects (JDO) Table
• Runway Assignment
• Runway Interaction
• Runway Interaction Geometry
• Runway Minimum Separation
• Runway Threshold Buffer
• Synchronized Procedures
• Terminal Model Management
3
American Institute of Aeronautics and Astronautics
 • TRACON Boundary Fix
• TRACON
The files can be created or modified using the software tool provided with ACES, acesUtilGUI. Section VI
discusses in detail how to modify these data for the terminal area model.

III. Overview of the Model-Building Procedure

The model-building procedure comprises constructing an airport model, generating configuration files, and
creating an ACES terminal area model. As shown in Figure 1, building an airport model is followed by generating
configuration files. Section IV.B lists a number of tools identified for helping with building of the STLE models.
Building the airport model usually starts with using Google Earth and other software tools to describe the
airport’s layout. Once the layout of the airport has been defined, a collection of batch processes provided by
SurfTools will help generate the STLE airport configuration files. Building the terminal area model starts by
gathering data on navigation fixes and arrival and departure procedures, usually from aeronautical charts. Creating
the ACES terminal area model can be done independently of the other steps. The process on the left side of Figure 1
can be further broken down as shown in Figure 2.

Figure 1. Model-Building Procedure

Figure 2 shows that the procedure uses Google Earth and yEd to generate the link/node model in the form of a
GraphML file and another file to store the attributes of the model. Other properties are edited either manually or by
using SView and stored in CSV files. With these input files ready, the “build” tools in SurfTools can be used to
generate the required XML files. Note that at the bottom of Figure 2, all 8 XML files identified in Table 1
(boldfaced) requiring adaptation to the airport are generated automatically by these “build” tools. The remaining
GateAssignment_KXXX.drl file in Table 1 contains the gate assignment rules and has to be editing manually.
Details of the modeling procedure are provided next: Section IV will explain the building of the airport graph model,
Section V will detail the creation of the STLE airport model files, and Section VI will explain the creation of the
ACES terminal area model.

4
American Institute of Aeronautics and Astronautics
 GoogleEarth &  OR
GoogleEarth & 
buildKML yEd File generated 
Airport Graph by program

yEd_xxx.graphml yEdref_xxx.xml File  generated 

manually
RampGateODArrival_xxx.csv
RampGateODDeparture_xxx.csv Software 
buildConfiguration
tool
Runway_xxx.csv

RoundRobinDefs.csv
buildAirport

buildTrajectory buildMovement buildGraph

buildGate buildRunway

AirportSurfaceAgent_KXXX_ AirportSurfaceAgent_KXXX_Movement.xml AirportSurfaceAgent_KXXX_Graph.xml

Trajectory.xml AirportSurfaceAgent_KXXX_Unconstrained_ AirportSurfaceAgent_KXXX_Unconstrained
Movement.xml _Graph.xml

AirportSurfaceAgent_KXXX_ AirportSurfaceAgent_KXXX_Runway.xml
Gate.xml AirportSurfaceAgent_KXXX_Unconstrained
_Runway.xml

Figure 2. Process for Generating STLE Airport Model Files

IV. Construction of Airport Graph Model

The purpose of this step is to model the layout of the actual airport. Starting with the geometry of the
runway/taxiway system of the airport to be modeled, the user defines nodes and links, and generates files that will be
processed to define the airport in a way that STLE understands.

A. Input and Output Files

The process typically begins with definition of the nodes associated with the airport layout. Nodes are defined at
specific locations on the airport surface. They include intersections of runways and/or taxiways, gates, ramp spots,
hold points, parking spots, deicing locations, etc. With the nodes defined, links are then defined as segments
between nodes on the airport surface where surface operations are possible. Each link definition is associated with a
begin-node and an end-node.
Generally, definition of the nodes and link is done manually. Data for about 80 airports have been made
available from Safe Flight 21 data files and extracted using the ATANG tool mentioned below. The output file is a
GraphML file with a name of the form yEd_xxx.graphml.

B. Available Tools
There is an assortment of software tools used in the process of making an airport model. These tools include:
Google Earth, yEd, buildKML, and conversion programs.
• ATANG: This tool has been developed by researchers at NASA Ames Research Center to convert computer
graphical model of airport layouts from Safe Flight 21 (SF-21) data sources into an initial set of approximate
link/node models. The resulting models are in GraphML format, and there are functions to convert between
GraphML format and the KML format used by Google Earth.
• Google Earth: The commonly-known tool from Google allows editing of the link/node model stored in KML
format by overlaying the model over satellite imagery for geo-referencing. Features within Google Earth allow
the user to define placemarks, which can be used in defining the nodes of the graph model.
• yEd: This graph editor from yWorks allows editing of the link/node model stored in GraphML format. Nodes
can be modified in yEd and links can be constructed between nodes.

5
American Institute of Aeronautics and Astronautics
 • SurfTools: A suite of software tools developed specifically for this modeling effort. It contains two types of
tools.
- “Build” Processes: These are a set of batch processes shown in Figure 2 for automatically processing the
appropriate input files to generate the intended output files.
- SView: This is an interactive program that allows the user to edit the attributes of the airport model, as well
as for viewing routes and playbacks of surface traffic after running STLE simulations. Specifically, SView
has the following four views:
ƒ Property View: This mode allows the user to easily adjust the directionality of the links, including
performing the alignment for a group of connected links.
ƒ GateRamp View: This mode allows the user to associate ramp spots to gates for the purpose of route
generation.
ƒ Route View: This mode allows the user to examine the routes generated for STLE between any origin-
destination node pairs on the airport surface, e.g., from a runway exit to a gate.
ƒ Animation View: This mode allows the user to play back simulation results by animating the aircraft
movements along the link-node network.
• KML-GraphML Conversion Files: These programs allow files in KML format and GraphML format to be
converted between the two formats. In order to check the accuracy of a link/node model, it is helpful to view the
model in Google Earth, where it can be superimposed on the image of the actual airport. Any changes can then
be made and then a new GraphML file can be generated.

C. Link/Node Model
The basis of the STLE airport model is a set of nodes and links that form a network, or graph. The link/node
model is used to model the flow of surface traffic at the airport being studied.

1. Link/Node Attributes
Each link and node in the model will have certain attributes, or properties, which the user needs to define, either
in Google Earth or yEd. These attributes can be edited in Google Earth (in properties window under description) or
yEd (in properties window under the data tab). In order for these files to be ready for processing by the code-
generation “build” tools, the following format has been adopted:
attribute_one:value_one;attribute_two:value;attribute_three:value_one/value_two;
where the semicolon (;) is used to separate each attribute name values pair, a colon (:) is used to separate attribute
names from their values, forward slash (/) is used to list multiple values of an attribute, where appropriate to do so,
and dash (-) is a possible future addition.
It is important to note that the properties of some nodes and links will depend on the direction of traffic flow, i.e.,
the airport configuration. Therefore, the model of an airport may comprise multiple sets of files, each representing a
different configuration. The standard practice is to create a master graph in Google Earth that is independent of the
configuration, then copy and edit the master graph to produce models for different airport configurations.
The outcome of this step is a GraphML file with a name yEd_xxx.graphml. To create a file from scratch, the user
would begin by creating Placemarks in Google Earth as node points and saving them in a KML file. The user may
then use yEd to create links between nodes. The user can convert back and forth to fine-tune the model using other
software tools. The remainder of this section discusses the process and the tools in detail.

2. Defining and Editing Nodes

Nodes occur whenever taxiways or runways intersect one another, or more precisely, where their centerlines
intersect. Nodes are also defined at the terminal gates. Nodes appear in the ramp area surrounding the gates as well;
these can often be identified by lines painted on the pavement. The method used in this work to designate nodes at
an airport to be modeled was to use images of the airport from Google Earth.

Node Naming Conventions

Nodes names depend on whether the node is on a taxiway, a runway, a ramp, or a gate. Taxiway nodes make use
of actual taxiway names. These taxiway names can be found on the FAA Airport Diagram, which is available online
for most airports at www.airnav.com/airports/ or in the U.S. Government Flight Information Publication “U.S.
Terminal Procedures” for the appropriate region. Table 2 summarizes the node naming conventions.

6
American Institute of Aeronautics and Astronautics
 Table 2. Node Naming Conventions
Type of Node Nomenclature
Gate Node: “Gate_terminalname_serialnumber”
Physical location of the terminalname: This should be a two-digit serial number for the terminal like ‘01’, ‘02’, etc.
airport gate serialnumber: This is a unique three-digit number assigned in a random order, or it is the
real-world gate number. (If relevant gate information is available, use the real-world gate
number otherwise use an arbitrary order). See example in Figure 3.
Ramp Area Node: “Ramp_terminalname_serialnumber”
Marked spot on the ramp
area terminalname: This should be a two-digit serial number for the terminal like ‘01’, ‘02’, etc.
Use the same terminalname nomenclature for gate and ramp-spot nodes belonging to one
terminal area.
serialnumber: This is a unique three-digit number assigned in an arbitrary order. See
example in Figure 3.
Taxiway Node: “Txy_taxiwayname_serialnumber”
Ramp-area route –
taxiway intersection OR taxiwayname: This is the real-world name of the taxiway on which the node lies
Taxiway start/end-point serialnumber: This is a unique three-digit number assigned in an arbitrary order starting
OR with ‘001’ from one end of the taxiway. See example in Figure 4.
Point added to a curved
section of a taxiway not at
any intersection
Taxiway Node: “Txy_taxiwayname1_taxiwayname2”
Taxiway-taxiway taxiwayname1 and taxiwayname2: These are the real-world names of the two taxiways on
intersection which the node lies. Order in which the taxiway names are placed is not important.
Runway Node: “Rwy_runwayname_serialnumber”
Runway start/end-point runwayname: This is a two-digit serial number for the runway like ‘01’, ‘02’, etc.
OR serialnumber: This is a unique three-digit number assigned in an arbitrary order starting
Taxiway-runway with ‘001’ from one end of the runway. See example in Figure 4.
intersection
Runway Node: “Rwy_runwayname1_ runwayname2”
Runway-Runway
intersection runwayname1 and runwayname2: These are two-digit serial number identifiers for the two
runways on which the intersection node lies. The order in which the runway names appear
in the name is not important.
Parking Node: “Parking_parkingareaname_serialnumber”
GA parking spots parkingareaname: This is a real name for the parking area (usually this name is painted on
OR the airport surface and is visible in the Google Earth picture) OR a made-up name such as
Other parking spots gaparking (which stands for General Aviation parking). For parking areas you may use the
name of the taxiway that goes to that parking area as the “parkingareaname”
serialnumber: This is a unique three-digit number assigned in an arbitrary order starting
with ‘001’.
De-icing Node: “Parking_deicing_serialnumber”
serialnumber: This is a unique three-digit number assigned in an arbitrary order starting
with ‘001’
If there are more than one de-icing area on the airport surface, one can use
“parking_deicing1_serialnumber”, “parking_deicing2_serialnumber”, etc. for nodes on the
individual de-icing areas.
Other Types of Nodes Naming conventions for nodes placed in other areas such as helipads, holding spots, etc.,
can be defined as needed. Figure 5 shows an example of a helipad.

7
American Institute of Aeronautics and Astronautics
 Figure 3. Examples of Gate and Ramp Nodes

Figure 4. Examples of Runway and Taxiway Nodes

8
American Institute of Aeronautics and Astronautics
 Figure 5. Example of Helipad Node

Node Properties
What sort of action takes place at a node depends on its location in the runway-taxiway system and on the
configuration of the airport at the time. This information is essential for determining surface routes. For example,
although there may be crossing taxiways at both ends of a runway, the one at the end where the aircraft are landing
cannot be used as an exit in that configuration. A set of standardized attributes has been developed to describe the
nodes as follows:
• Domain: This specifies the usage of the node. Possible values are: runway, taxiway, ramp, gate, parking, and
deice. The attributes RefName, Type and Dependency are dependent on the Domain attribute.
• RefName: This defines the specific object to which the Domain attribute refers. For the Runway domain, it is
the runway name. For an example, “13R” means that the node is on runway 13R. If the node is a crossing point
of two crossing runways, it would have two values such as “13R/22L”; note the forward slash separator for the
two values. If the node is the intersection of more than two taxiways, the names of all of the intersecting
taxiways can be the values for this attribute.
• Type: This represents the function, or purpose, of each node. Possible values include:
- HighSpeed: High-speed runway exit, i.e., taxiway centerline is 30°–45° from the runway centerline.
- Exit: Low-speed runway exit, i.e., a crossing taxiway that is approximately at right angles to the runway.
- Entry: Runway entry point for taking off.
- RwyCrossing: Crossing node of two crossing runways.
- TxyCrossing: Node that serves as a runway crossing point.
- Hold: Point where aircraft must hold before crossing an active runway (i.e., on a hold line).
- RampSpot: Ramp nodes where aircraft must hold while waiting for clearance from an ATC controller,
normally at the boundary of the non-movement area.
- Normal: This applies to Runway, Taxiway, or Ramp domains, for a node that does not have any special
purpose covered by the other types.
- For gates, the type of facility has not yet been defined.

9
American Institute of Aeronautics and Astronautics
 • Dependency: This lists other objects that may be used simultaneously with the node. In some airport models,
there are places where nodes are so close to each other that they are operationally dependent. In other words, if
an aircraft were on top of one node, there would not be enough clearance around adjacent nodes for another
aircraft to pass by. For example, in the Dallas-Fort Worth (DFW) model, Txy_Y_004 cannot be occupied by
itself. When an aircraft uses it, the adjacent nodes Txy_G_Y and Txy_Y_002 would be occupied as well.
• Jurisdiction: This indicates which controller has jurisdiction over it.
• Comments: This is reserved for any special information the user may want to include.
If a particular attribute does not apply, the value should be set to “None”. The node attributes are summarized in
Table 3.

Table 3. Summary of Node Attributes

Attribute Value Description
Domain Runway The area to which the node belongs.
Taxiway Runway and Taxiway domains are in the
movement area.
Ramp
Gate
Park
Deice
RefName Runway name A name to assist the user in recognizing
Taxiway name the node. Some nodes, in the link/node
airport models, are not apparent in geo-
Terminal name referencing, but it is better to put nodes for
Gate name sufficient airport models. For those nodes,
RefName are None
Parking lot name
Deicing station name
None
Type For Runway HighSpeed Type is dependent upon the node’s
domain Entry domain and defines usage.
Exit
RwyCrossing
TxyCrossing
Normal
For Taxiway Hold
domain Normal
For Ramp domain RampSpot
Normal
For Gate domain Type of gate
For Park domain Type of parking
For Deice domain Type of facility
Dependency List of dependent nodes Indicates nodes whose use may be
None affected by aircraft on other nodes.

Jurisdiction Controller Id Which ATC controller has the jurisdiction

over it
Comment Any comments on the node can be put this attribute.

3. Defining and Editing Links

The following paragraphs discuss these methods and related tasks in detail.

Using yEd to Define and Edit Links

After generating the Google Earth KML file of the nodes, the file can be converted to a yEd GraphML file. The
GraphML file can be opened in yEd as shown in Figure 6. Note that the runway and taxiway outlines that appear in
Figure 6 have come from other data for the airport. In yEd, creating a link involves simple click and drag between
nodes. In most cases the connections are obvious, but it is helpful to refer to the Google Earth image or other data
such as an FAA Airport Diagram or Jeppesen chart. After the links have been created, the yEd Graphml file can be
10
American Institute of Aeronautics and Astronautics
converted back to a Google Earth KML file for checking with the overhead imagery. The creation of the airport
model will likely require several iterations. The process is summarized in Figure 7.

Figure 6. yEd Window Displaying GraphML File Converted from KML File

atangRuntime_kmlToGraphML

GoogleEarth2_dfw.kml yEd_dfw.graphml

Select Airport GoogleEarth yEdref_dfw.xml yEd

‐ Editing nodes ‐ ‐ Editing links‐

GoogleEarth2_dfw.kml
yEd_dfw.graphml

No
atangRuntime_graphMLToKML Sufficient?

Yes
File generated by program

File  generated manually
Final yEd_dfw.graphml
Software tool

Figure 7. Generating a GraphML File Using yEd

11
American Institute of Aeronautics and Astronautics
 Link Naming Convention
The only convention for naming links is that the name is made up from the names of the two nodes that define
the two ends of the link, by inserting a hyphen between the two node names to form the link name. The order is
unimportant. After connecting links in yEd and converting the GraphML file back to a KML file, the conversion
software automatically names the links. They can be named manually if necessary.

Link Properties
As with nodes, a set of standardized attributes has been developed for links, as follows:
• Domain: This specifies the usage of the link. Possible values are: runway, taxiway, ramp, gate, parking, and
deice. If a link is directly connected a gate, the domain attribute must have the value “Gate”. RefName depends
on the domain attribute.
• RefName: This defines the specific object to which the domain attribute refers. If the domain is “Taxiway,” for
example, the “value” of RefName would be a taxiway name.
• Width: This is the actual width of the pavement, in feet. This attribute is useful to determine if some runways
and taxiways are constructed to handle larger aircraft.
• Direction: This integer flag defines the direction of travel. The convention for the values is:
- 0: The link is closed to traffic.
- 1: The direction of travel is from the first node in the link name to the second node in the link name.
- 2: The direction of travel is from the second node in the link name to the first node in the link name.
- 3: Traffic is allowed in either direction, though not simultaneously.
• Cost: This is a pair of numbers separated by a forward slash. One is for the cost when traversing from nodeOne
to nodeTwo (Direction = 1), the other is for the cost when traversing from nodeTwo to nodeOne (Direction =
2).
• Comments: This contains any special information the user may want to include.

Table 4 summarizes the link attributes.

Table 4. Link Attributes

Attribute Value Description
Domain Runway The same as nodes. If a link crosses two
Taxiway different domains, the domain would be
specified with reverse priority according to
Ramp the list on the left, e.g., a link between a
Gate taxiway node and a ramp node belongs to
the Ramp domain. The only exception is
Park
that any link connected to a Gate node is
Deice considered to belong to the Gate domain.
RefName For Runway domain Runway name Same as corresponding node attribute.
For Taxiway domain Taxiway name
For Ramp domain Terminal name
For Gate domain Gate name
For Park domain Parking lot name
For Deice domain Deicing station name
Width Width of the pavement being modeled by
Width of the link in feet
the link.
Direction Blocked 0 Under specific airport configurations, links
One way from node one to node two 1 that geographically connected are
blocked, one way, or bi-directional.
One way from node two to node one 2
Bi-directional 3
Cost Cost from one node to the other, To represent operational preference,
and cost from the other node to one node researchers may adjust link costs.
Comment Any comments on the link can be put this attribute.

SView provides the Property View mode to allow the link directions to be easily set. As shown in Figure 8, the
SView window displays the airport network graph and a table. The nodes are color-coded for the different domains.
Arrowheads on the links indicate the directions. If there are no arrowheads on a link, then its directionality is 0. The
12
American Institute of Aeronautics and Astronautics
directionality of a link can be changed by pressing the tab button on the keyboard after selecting the link to cycle
through the four possible values of the directionality index. This procedure can be performed for a set of links
simultaneously, though Direction of 1 or 2 for a set of links may not always produce the intended result because the
Direction property of a link depends on the order of the two nodes defining the link, and the order might have been
automatically assigned by the conversion software. In this view, the user can also select a set of connected links.
Now, the user can use the left/right arrow buttons on the keyboard to align all the links with the master link—the
link first selected in the group. This alignment is useful for aligning the directionality to indicate a continuous flow
direction as in the case of the links along a runway or a desired taxi route. Figure 9 shows an example of the
directionality alignment function in Property View.

Figure 8. Airport Network Graph in SView

13
American Institute of Aeronautics and Astronautics
 Align directionality of connected links

Figure 9. Alignment of Connected Links

V. Creation of the STLE Airport Model Files

STLE uses the Spring Framework for building the surface model. As such, “beans” are defined in a collection of
XML files which define the configuration of the airport and the movement of flights through it. As mentioned
previously, some of the airport configuration files require only minor modifications by the user using any available
text editor. Others require software tools to automatically generate the XML files based on the airport model
contained in the yEd_xxx.graphML file. The one exception is that STLE uses JBoss Rules (Drools) to assign gates.
That requires creating a .drl file. The overall file-generation process is shown in Figure 2. The input files that need to
be manually generated are:
• GateAssignment_KXXX.drl
• RoundRobinDefs.csv
• Runway_xxx.csv
• RampGateODArrivals_xxx.csv
• RampGateODDepartures_xxx.csv
and the output files that can be automatically generated using the SurfTools “build” functions include:
• AirportSurfaceAgent_KXXX_Gate.xml
• AirportSurfaceAgent_KXXX_Graph.xml
• AirportSurfaceAgent_KXXX_Unconstrained_Graph.xml
• AirportSurfaceAgent_KXXX_Movement.xml
• AirportSurfaceAgent_KXXX_Unconstrained _Movement.xml
• AirportSurfaceAgent_KXXX_Runway.xml
• AirportSurfaceAgent_KXXX_Unconstrained _Runway.xml
• AirportSurfaceAgent_KXXX_Trajectory.xml
The SView tool can help to perform some of the manual editing of the properties to be saved in the CSV files. This
is described in the following subsections.

A. XML File Generation (buildAirport)

This section discusses how to construct the input files that, along with the yEd_xxx.graphml file, allow the
SurfTools programs to generate the XML files required by STLE. The buildAirport Java project has been developed
to extract necessary information of a link/node model from “yEd_xxx.graphml” file and “yEdref_xxx.xml” file. The
input data files required are explained in the following subsections.

1. Gate Assignment
STLE requires the user to define how flights will be distributed among the gates and terminals. Details of this
model depend on whether actual gate assignment information is available. Currently, the user is required to provide
two files to perform gate assignments to flights: a .drl (Drools) file, and a .csv file. The former defines the higher-
level decision-making, while the latter is a “data” file used to generate the .xml file needed for gate assignment.

14
American Institute of Aeronautics and Astronautics
 Drools is a business rule management system (BRMS) with an inference-based rule engine, also known as a
production rule system, using a modified Rete algorithm. Drools is based on the Java Specifications Request JSR-
94. JSR-94 is the standard for business rule engines and enterprise frameworks for the construction, maintenance,
and enforcement of business policies in an organization, application, or service8. JBoss developed a commercial
product based on Drools, called JBoss Rules, although the original Drools project still exists as an independent
entity. Drools is a very comprehensive rule engine with many capabilities, but currently only a small part of its
capabilities have been used in gate assignment.
The current STLE gate assignment models are implemented with a round-robin strategy. The user provides a
table of round-robin names and the objects that the round-robin function will choose from. The user inserts rules to
call the round-robin functions in the .drl file. A tool has been developed to generate the
AirportSurfaceAgent_KXXX_Gate.xml file. The .drl file and the .csv file must agree in regard to functions defined.
SurfTools contains a software tool for generating the code necessary to do round robin. The user has to write a
text file which specifies the name of the round robin function and the objects (e.g., gates) that the round-robin
function will choose from. The name of the file is “RoundRobinDefs.csv”. Each line of this file contains the name of
a round-robin function, followed by a list of things that the function will choose from, separated by commas: e.g.,
roundRobinACA,Gate_04_02,Gate_04_05,Gate_04_08

In the current implementation, the rule engine looks at which air carrier a flight belongs to, and then calls a gate
selection function. This is accomplished with “when-then” statements. The code looks like this for the carrier UPS:
/*
Rule for UPS
*/
rule "UPS"
when // Conditions must be satisfied in order to activate this rule
f : Flight(icaoCode == "UPS")
then // Actions when this rule is activated
f.setGate( (String)roundRobinUPS.getNext() );
retract(f);
end

The code checks the flight’s airline name to see if it matches, and if so, it assigns a gate to the flight after calling
the round-robin function defined for that airline.
If each air carrier serving the airport can be associated with a particular terminal, then a lookup table can be used
to find the terminal. A round robin can then be defined for each terminal, if the simplifying assumption is made that
carriers share the gates in a terminal. The lookup table can also be used to avoid writing a lot of separate rules when
there are many small carriers that use the same terminal or part of a terminal.

2. Route Generation
The construction of routes actually occurs in two segments: between gate and ramp spot, and between ramp spot
and runway. The reason for this extra step is two-fold: (i) it reduces the number of possible combinations, since
there are fewer ramp spots than gates, and (ii) it enforces some practical constraints on how a flight might be routed.
SurfTools includes the tool buildAirport to generate surface routes to be used by STLE at runtime. The
BuildTrajectory function called by buildAirport will take the link/node model and find the lowest-cost route
(trajectory) between the start nodes and end nodes. This is done with the Floyd-Warshall algorithm. The cost in the
current implementation is simply the total length of the links, but other cost metrics can be used. Route generation
requires three input files in addition to the two gate assignment files:
• Runway_xxx.csv
• RampGateODArrivals_xxx.csv
• RampGateODDepartures_xxx.csv
The file Runway_xxx.csv defines all exit and entry points of each runway. The files
RampGateODArrivals_xxx.csv and RampGateODDepartures_xxx.csv define which ramp spots serve which gates.
After the 5 input files have been created, buildAirport can be run to generate the routes and the other STLE model
files.

15
American Institute of Aeronautics and Astronautics
B. Route Viewing Tool
SView includes a RouteView mode for viewing the routes generated by buildAirport. RouteView will display
the airport network graph with a route highlighted in green and yellow as shown in Figure 10. A table of the routes
is displayed on the right side of the window. Selecting a row from the table will cause that route to be highlighted.
The arrow keys can be used to move up and down the table or the mouse can be used. The zoom feature works as in
the PropertyView mode. This tool can be used to check visually if the routes make sense. If a link has been assigned
an incorrect direction, it often shows up indirectly in the route generation procedure.

Figure 10. SView Showing Minimum-Cost Routes

C. Gate Ramp View

With SView in the GateRamp View mode, the user can click on a gate which becomes “starred” (i.e., its icon
becomes a star) and it shows the user which ramps and taxiways it is connected to. For example, if the user selects
Gate_ 01_033 of airport ORD and the user sees that it is connected to Ramp_01_024 which happens to be both for
arrival and departure, the user can change this to just arrival or departure or have it be unconnected. After the user
finishes editing the ramp spot assignment, the assignment results can be saved to either the old file or a new file of
the user’s choice. If a new file is selected, the assignment will be saved to the appropriate airport directory with
filename RampGateODArrivals_xxx_new.csv or RampGateODDepartures_xxx_new.csv, depending on the type of
node.

VI. Construction of the ACES Terminal Area Model

The enhanced terminal model (ETM) in ACES allows the user to define approximate approach and departure
procedures to more accurately model the flow of traffic in the airspace around the airport as well as the flow into and

16
American Institute of Aeronautics and Astronautics
out of the airport. The user can define metering fixes, runway interactions, etc. The model is stored in a MySQL
database. The data sets involved are listed in Section II.C above.

A. Requirements
The user will need some idea of the routes in the terminal airspace around the airport being modeled, i.e., STARs
and SIDs (DPs). This information can be found in the U.S. Government Flight Information Publication “U.S.
Terminal Procedures” for the appropriate region. The arrival and departure procedure plates can be downloaded in
PDF form from www.airnav.com. Example of a SID is shown in Figure 11. The information can be obtained in text
files from the FAA Aeronautical Information Services, but some other software tool would be necessary to read and
display the data in a more useful form, such as an Electronic Flight Bag. It is also very helpful to have a copy of the
“IFR Enroute Low Altitude” aeronautical chart that covers the airport being modeled. An example is shown in
Figure 12. The fixes in the SIDs and STARs can be seen on this scale map. Some fixes in STARs and SIDS may
actually be high-altitude fixes and will not appear on a Low Altitude chart.

Figure 11. Standard Instrument Departure (SID) Plate

17
American Institute of Aeronautics and Astronautics
B. Tools Available
A couple of graphical user interface (GUI) tools exist for working with the ETM data in the MySQL database.
The first tool—acesUtilGUI—is provided with ACES for creating and editing the database.
The data can also be accessed using the MySQL Query Browser. In its current form, the acesUtilGUI prevents
the user from changing certain fields short of deleting an entire entry and re-entering it. The Query Browser can be
used to help edit, and, indirectly, to enter new data. A version of the MySQL Query Browser is available for
download as part of MySQL GUI Tools Bundle.

Figure 12. IFR Enroute Low Altitude Aeronautical Chart

C. Enhanced Airport/Terminal Area Model

For the Enhanced Airport/Terminal Model, the configuration data can be classified into four categories. They are
Terminal Area, Runway System, Aircraft Spacing, and Aircraft. Each data set category includes one or more data set
types as listed below. The italicized items are the ones that the user will normally need to specify, while the default
settings can be used for the others.
• Terminal Area: TRACON Boundary Fix
• Runway System
- Runway Assignment & Transit Time
- Runway Interaction
- Synchronization Procedures
- Formation Landing Procedures
• Aircraft Spacing
- Runway Minimum Separation Table
- Runway Threshold Buffer Table
• Aircraft: Aircraft Operating Characteristics
The configuration data for these categories are defined through Terminal Model Management Specifications by
launching the acesUtilGUI. Figure 13 shows the startup window of this GUI, which illustrates a tree structure
composed of these categories and the types of data sets within them. The pull-down menu under the single menu
item of “ACES Model” in the GUI of Figure 13 shows entries for the four categories with an additional entry of
“Terminal Model” above them. The pertinent settings for modeling the terminal area and the airports within are
described in the following subsections.

18
American Institute of Aeronautics and Astronautics
 1. Single/Multiple-Airport Runway Modeling Management and Activation
The parameters of the airports can be edited in the GUI by selecting “Terminal Model” from the menu under
“ACES Model” in Figure 13. The user can specify the airport and terminal airspace models applicable to each
TRACON using the parameters shown in the example of Table 5. The user identifies each TRACON and describes
each airport in the TRACON. The user defines modeling features of a TRACON including airport modeling mode,
boundary fix structure, and TFM modeling mode. ACES Enhanced Airport/Terminal Model automatically activates
each airport’s modeling configuration (e.g., runway vs. nodal modeling) based on these user specifications. To
invoke the STLE airport model, the Airport Model should be set to “Runway.” For user-defined fixes, the Boundary
type and Fix Configurations in the Terminal Model Management Specifications (see Table 5) should be set to
“Flexible” for the particular airport or TRACON being modeled. The TFM model should be set to “Basic.”

Figure 13. ACES Graphical User Interface Startup Window

Table 5. Example of Terminal Model Management Specifications

Airport Airport
Airport Reference Reference Airport TRACON Airport Fix TFM
Airport Name Boundary
ID Point Point Altitude ID Model Configuration Mode
Latitude Longitude
KBAB beale_afb_ca 39.136 121.4366 113 TKBAB Nodal R-40 Generic Nodal
KBIH bishop_ca 37.37308 118.3636 4120 TKBIH Nodal R-50 Generic Nodal
buchanan_field_
KCCR 37.98947 122.057 23 TKCCR Nodal R-20 Generic Nodal
ca
KCIC chico_muni_ca 39.79536 121.8584 238 TKCIC Nodal Radial Flexible Nodal
coalinga_muni_c
KCLG 36.1605 120.3604 714 TKCLG Runway R-50 Generic Basic
a
KCRO corcoran_ca 36.10244 119.5948 197 TKCRO Runway Radial Flexible Basic

2. Single/Multiple-Airport Flexible Terminal Airspace Boundary Specification

As shown in the example of Table 5, there are two options for defining the boundary fixes:
• Generic Boundary Fixes for Nodal Modeled Airport: The Enhanced Airport/Terminal model automatically
constructs the four generic arrival fixes and four generic departure fixes as in the airport nodal model, except
the fixes are constructed on the user-specified or default radial distance (see Table 5). ACES uses the Airport

19
American Institute of Aeronautics and Astronautics
 Reference Point latitude and longitude (see Table 5) to center the radials and to position the airport for linkage
association with each fix.
• User-Defined (Flexible) Boundary Fixes: The Enhanced Airport/Terminal model constructs the terminal
boundary fixes based on user specifications. Airports that do not have user-defined terminal boundary fixes are
automatically assigned the nodal default terminal area design. The TRACON Boundary Fix data can be entered
by accessing the “Terminal Area” menu entry of the GUI in Figure 13, and selecting the “TRACON Boundary
Fix” tab as shown in Figure 14.

Figure 14. GUI for Entering TRACON Boundary Fix Data

3. Runway Assignment & Transit Time

With the TRACON boundary fixes specified, the Enhanced Airport/Terminal model provides a user interface for
defining runway assignment specifications and a routine to assign runways to a flight based on user-defined fix-to-
runway mappings. The interface is the “Runway Assignment & Transit Time” specifications under the “Runway
System” menu entry of Figure 13. An example of the interface is shown in Figure 15. This interface allows the user
to specify Runway Assignment Parameters for determining the takeoff and landing runways based on fix and
operating condition:
• Airport Id: Airport identifier (3 or 4 letter) code
• Operating Condition: Name of the airport operating condition
• Fix Id: Fix identifier code (alphanumeric) of each eligible fix for the operating condition
• Flight Operation: Arrival (A) or Departure (D) operation for the fix and runway
• Aircraft Engine Type: Jet (J), Turboprop (T) and/or Piston (P) engine type for the fix and runway
• Default Runway Assignment Id: Identifier (alphanumeric) of the default runway associated with each fix for the
operating condition
The interface also allows the entry of the following Transit Time Calculation Time Parameters to allow ACES to
compute the transit times through the terminal area:

20
American Institute of Aeronautics and Astronautics
 • Runway Bearing: the true azimuth of the runway centerline
• TRACON Flight Distance: Representative flight distance (nmi) between the Fix Id and Default Runway
Assignment Id
• Final Approach Length: Representative flight distance (nmi) between the Default Runway Assignment Id and
its Final Approach Fix
ACES provides the capability to calculate automatically a representative transit time for each flight based on
user-definable or default (ACES calculated) terminal airspace flight distance and (user-adjustable) speed data. The
user has the option to enter the terminal airspace flight distance data for each fix-runway or fix-nodal airport link;
otherwise as a default, ACES calculates the flight distance based on latitude and longitude data for the boundary fix,
airport reference point and final approach fix. The user also has the option to enter the length of the final approach
course; otherwise ACES applies a user-definable value of 5 nmi for the final approach course length.

Figure 15. Runway Assignment and Transit Times Data Entry Window

4. Runway Aircraft Spacing Application

For each airport modeled with individual runway operations, the user specifies the runway interactions and the
appropriate spacing and buffer requirements. These common descriptors are encoded in Runway Interaction Tables,
Minimum Separation Tables, and Separation Buffer Tables.
The Runway Interaction Table allows the user to define the valid runway interactions and pair-wise runway
operations for the operating conditions. This table also identifies the Minimum Separation Table and Buffer Table
for each valid runway interaction. The Runway Interaction Table is accessed from the “Runway System” menu entry
of Figure 13, and it includes the following parameters as shown in Figure 16:
• Operating condition: name of the airport operating condition
• Runway 1: Runway identifier code for the first runway for a pair of aircraft operations
• Operation 1: Operation type—arrival (A) or departure (D)—of the first (lead) aircraft of a pair of aircraft
operations
21
American Institute of Aeronautics and Astronautics
 • Runway 2: Runway identifier code for the second runway for a pair of aircraft operations
• Operation 2: Operation type of the second (following) aircraft of a pair of aircraft operations
• Separation Table Name: Identification name of the appropriate Minimum Separation Table for the runway
interaction and aircraft operations pair
• Buffer Table Name: Identification Name of the Buffer Table for the runway interaction and aircraft operations
pair
Additional parameters such as separation or aircraft performance can be specified by the user, but the default
values correspond to current practice so the user typically does not have to specify these.

Figure 16. Runway Interaction Data Set Window

VII. Tools for Post-Simulation Analysis

The visualization tool SView provides an animation function to play back the simulated traffic at an STLE-
modeled airport. This is helpful in understanding how the traffic may become congested. The playback is also
helpful in determining if the directionality of the links has been correctly defined. Figure 17 shows an example of
this playback window. The control functions available to the user near the bottom of the window are explained in
Figure 18. The user can also select flights from the list on the right-hand side of Figure 17 to bring up the flights’
taxi routes.

22
American Institute of Aeronautics and Astronautics
 Figure 17. Animation View of SView to Play Back STLE Simulation Data

Set Desired  Set Start Time  Set End Time  Set Desired 

Start Time Back To Default  Back To Default  End Time

Fast  Play pause play Fast  Repeat  Adjust 

Backward Backward Forward Playback  Speed

Figure 18. User Control Functions Available in Animation View

VIII. Concluding Remarks

The process and software tools substantially ease the effort in generating airport models to support surface
operation simulation in ACES using its STLE function. The preparation of an STLE model was so tedious, time-
consuming, and error-prone that the development of STLE was originally accompanied by only one manually
prepared airport model, that of EWR. Manual generation of airport models requires editing of many airport model
files, including files to describe the surface layout graph, movement functions, gate assignment, runway entry and
exit assignment, route assignment, etc.
The process and software tools documented in this paper allow many of these files to be generated automatically
based on a fewer number of files prepared by the user to include the minimal amount of information. The user also
has access to interactive software tools to help prepare and debug these files and model data.
The resulting process and software tools have been applied to generate 60 airport link/node models within a few
months, including 23 fully defined airport models ready for validation in STLE. Some of the automatically
generated XML files for the models have more than 25,000 lines of XML tags and data, a size much too large for
human developers to edit without much concern for errors.

23
American Institute of Aeronautics and Astronautics
 Acknowledgments
This development effort was performed under support from NASA Contract Number NNA04AA18B. The
authors thank Mr. Michael Downs for sharing his technical expertise with the team, and Mr. Rob Fong and Dr. Jorge
Bardina for their support.

References
1
Concept of Operations for the Next Generation Air Transportation System, v. 2.0, Joint Planning and Development Office
(JPDO), June 13, 2007.
2
Swenson, H., R. Barhydt, and M. Landis, “Next Generation Air Transportation System (NGATS) Air Traffic Management
(ATM)–Airspace Project,” Reference Material, External Release Version, NASA, June 1, 2006.
3
Hinton, D., J. Koelling, and M. Madson, “Next Generation Air Transportation System (NextGen) Air Traffic Management
(ATM) – Airportal Project,” Reference Material, External Release Version, NASA, May 23, 2007.
4
Sweet, D. N., V. Manikonda, J. S. Aronson, K. Roth, and M. Blake, “Fast-Time Simulation System for Analysis of
Advanced Air Transportation Concepts,” Proceedings of the AIAA Modeling and Simulation Technologies Conference,
Monterey, CA, August 5–8, 2002, Paper No. AIAA-2002-4593.
5
Couluris, G. J., C. G. Hunter, M. Blake, K. Roth, D. Sweet, P. Stassart, J. Phillips, and A. Huang, “National Airspace System
Simulation Capturing The Interactions of Air Traffic Management and Flight Trajectories,” Proceedings of the AIAA Modeling
and Simulation Technologies Conference, Austin, TX, August 11–14, 2003, Paper No. AIAA-2003-5597.
6
Couluris, G. J., R. K. Fong, M. B. Downs, N. Mittler, D. Signor, A. Stassart, and T. Hsiao, “A New Modeling Capability for
Airport Surface Traffic Analysis,” Proceedings of the 27th Digital Avionics Systems Conference, October 26–30, 2008.
7
Saraf, A. P., D. R. Schleicher, K. Griffin, P. Yu, S. Ashok, J. Bushman, and V. H. L. Cheng, “Fast and Efficient Method for
Generating Airport Models to Support National Airspace System Analyses,” Proceedings of the AIAA Modeling and Simulation
Technologies Conference, Chicago, IL, August 10–12, 2009, Paper No. AIAA-2009-5914.
8
Drools Introduction and General User Guide. (http://downloads.jboss.com/drools/docs/5.0.1.26597.FINAL/drools-
introduction/html_single/index.html)

24
American Institute of Aeronautics and Astronautics

View publication stats