DRAFT
106761299
Airspace Concept Evaluation System (ACES) Capabilities
December 5, 2008
Based on CDRL 19 (see Reference)
Raytheon ACES Team
1001 Boston Post Road
Marlborough, MA 01752-3789
DRAFT
Page 2 of 50
TABLE OF CONTENTS
1
INTRODUCTION .................................................................................................................... 5
2
Modeling Overview .................................................................................................................. 5
2.1 Current Functionality................................................................................................ 8
2.1.1
Aircraft ............................................................................................................... 8
2.1.2
ATCSCC ............................................................................................................ 8
2.1.3
En Route ............................................................................................................ 9
2.1.4
En Route Congestion ......................................................................................... 9
2.1.5
En Route Conflict Detection and Resolution ................................................... 11
2.1.6
Terminal ........................................................................................................... 11
2.1.7
Terminal Area Modeling ................................................................................. 12
2.1.8
Separation at the Arrival Meter Fix ................................................................. 18
2.1.9
Arrival Fix Rerouting....................................................................................... 19
2.1.10
Overlapping TRACONS ................................................................................ 19
2.1.11
Airport ............................................................................................................ 19
2.1.12
Dynamic Airport Arrival and Departure Capacities ...................................... 20
2.1.13
Surface Traffic Limitations ............................................................................ 20
2.1.14
AOC ............................................................................................................... 22
2.1.15
Airline Operations Center Cancellations and Delays .................................... 22
2.1.16
Traffic Demand .............................................................................................. 23
2.1.17
Weather .......................................................................................................... 23
2.1.18
Constrained Airspace Rerouting Planner (CARP)......................................... 23
2.1.19
Rerouting in En Route CD&R for Separation Assurance.............................. 25
2.1.20
Airspace ......................................................................................................... 26
2.1.21
Advanced Airspace Concept .......................................................................... 27
2.1.22
Uncertainty Capability for CNS .................................................................... 28
2
DRAFT
Page 3 of 50
2.1.23
International Flights ....................................................................................... 29
2.1.24
International Overflights ................................................................................ 29
2.1.25
Tail Tracking.................................................................................................. 29
2.1.26
Variable Descent Profile ................................................................................ 30
2.1.27
Sector Grid Redesign ..................................................................................... 30
2.1.28
BADA 3.6 ...................................................................................................... 31
2.1.29
Visualization/Scenario/Simulation Control ................................................... 31
2.1.30 Communication, Navigation, and Surveillance Error! Bookmark not defined.
2. 1.31 Swappable Trajectory Generator ......................Error! Bookmark not defined.
2.1.32 Traffic Monitor Advisor ...................................Error! Bookmark not defined.
2.2
Planned Functionalities .......................................................................................... 38
2.2.2
ACES with FACET TFM ................................................................................ 38
2.2.3
Capability to Change Look-ahead Time for Re-sectorization ......................... 39
2.2.4
Climb and Descent Profile ................................Error! Bookmark not defined.
2.2.8
Enhanced Terminal Model............................................................................... 39
Appendix A: BADA Updated aircraft models .............................................................................. 44
APPENDIX B : ACRONYMS ..................................................................................................... 46
3
DRAFT
Page 4 of 50
LIST OF ILLUSTRATIONS
Figure 2-1 ACES Simplified Terminal Airspace Network ........................................................... 13
Figure 2-2 ACES Multiple Airport Simplified Terminal Airspace Network ............................... 13
Figure 2-3 ACES Link-Node Model
Figure 2-4 ACES Trajectory Generator Interface
REFERENCED DOCUMENTS
[1] CTOD 7.36 ACES Modeling Systems Requirements Document, 28 August 2004
[2] CDRL 17 Airspace Concept Evaluation System (ACES) Software User Manual, 31
October 2005
[3] CDRL 19 System/Subsystem Design Description (SSDD) / Software Design Document
(SDD) – Appendix A.3 – Terminal Area Operations, 29 September 2006
[4] EDD Swappable Trajectory Generator-SCR 1326, 13 October 2008
[5] EDD Dynamic Sector Capacity-SCR 1277, 17 June 2008
[6] EDD CNS Plug-ins 2.0-SCR 1289, 9 June 2008
[7] EDD Surface Traffic Limitations Enhancement-SCR 1288, 3 June 2008
[8] EDD Traffic Management Advisor-SCR 1233, 26 September 2008
[9] EDD Traffic Management Advisor-SCR 1037 V2.1, 31 October 2007 (ACES-X)
[10] ACES to MPAS ICD, 8 September 2006
[11] ACES STLE User Guide-SCR 1288, 3 June 2008
4
DRAFT
1
Page 5 of 50
INTRODUCTION
Increasing air traffic impacts passengers and airport operations. It results in airport congestion, lost
revenues, longer delays for passengers, and shorter decision times for air traffic controllers.
Researchers and planners are working on solutions to the nation’s air space capacity problems. The
Airspace Conception Evaluation System (ACES) provides them with a tool to assess the system wide
impacts of new aviation concepts and technologies. ACES simulates the complex interplay of the air
traffic system using a software architecture based on agents. These are individual assemblies of
mathematical models designed to emulate the functionality of air space entities using detailed
information about the dynamic evolution of the traffic in the system. Researchers can evaluate how
the National Air Space (NAS) will handle future flight demand and how the system will respond do
disruptions such as inclement weather. ACES extraordinary flexibility allows the researcher to study
the system-wide benefits and impacts of new ideas.
This document is intended to provide a description and top-level capabilities of the NAS models of the
Airspace Concept Evaluation System (ACES) Build 6. For the purpose of this document, these builds
represent the main copies. Other capabilities explored/developed in parallel in external copies are
planned to be integrated into main builds in due time. This document is intended to evolve,
incorporating new capabilities as built.
ACES is a combined architecture and modeling toolkit that provides the structure and NAS modeling
capabilities to create a variety of simulations tailored to the researcher's specific needs. The purpose of
this document is to provide an overview of the capabilities and NAS functionality enabled by the
models included in ACES Build 6.
2
MODELING OVERVIEW
From a user’s perspective (refer to Figure 1), the ACES modeling system provides the following
capabilities:
1. Day-in-the-NAS - The models support a simulation run that emulates an entire day-in-theNAS operation. This provides a timeframe to study the interactions among the different NAS
participants as they interact over the course of an entire day. How problems propagate through
the NAS and how the NAS recovers also requires the ability to emulate the entire NAS for an
extended period of time. The tool provides knobs for setting up a scenario of interest for
studying a particular aspect of the NAS by focusing on a higher level of detail of the aspect, or
the overall network effect of the entire NAS in a lower level of detail, or a combination of
both.
2. Gate-to-Gate - The models support a NAS-wide, gate-to-gate simulation. The models utilize
various levels of fidelity to provide NAS-wide simulation. The simulation tracks each
individual aircraft throughout the NAS. In the en route environment, high fidelity trajectory
modeling along with TFM and ATC capabilities combine to provide a medium fidelity
emulation of the en route domain. Traffic flow modeling in the terminal area and at the
airports, along with basic models of the Airline Operations Centers (AOCs) and the Air
Traffic Control System Command Center (ARTSCC) provide the necessary elements to
emulate traffic flow across the NAS.
DRAFT
Page 6 of 50
3. Traffic Flow - The models emulate the Traffic Flow Management interactions of the current
NAS environment. This build provides models for the traffic flow components of each ATC
domain along with the influence of the ATCSCC and the AOCs. This provides the basic
modeling necessary to show the propagation of delay throughout the NAS and the interactions
between the airlines, the ATCSCC, and the various Air Traffic Control domains in dealing
with capacity limitations.
4. NAS Metrics - The models support the collection of NAS-wide metrics for flight time delay, departure
delay, fuel costs, and controller workload measures. Research using this tool is expected to help
answer the cost and benefits of various approaches to addressing our NAS system imbalances in
demand, capacity, and safety areas.
DRAFT
Page 7 of 50
ACES Inputs
Flight Data Set
Airport Capacities
Static Data
Origin/Destination
Airport States
Airport Adaptation
Data
Aircraft Type
VFR
Trajectory
IFR
VFR
VFR
VFR
RUC
Winds
Cruise Alt & Speed
Departure Time
Center/Sector
Adaptation Data
ACES
Functionality
Sector Capacities
Generic/Enhanced
Airport Model
Winds On/Off
ACES Simulation
Center A
TFM
Center B
Delay Maneuvers
TFM
TRACON
TFM
ATC
ATC
TRACON
ATC
Airline Operations
Control
TFM
ATC
40
TFM
ATC
nm
Airport
Rerouting
40
ATC
nm
Airport
Departure Meter Fix
Separation
Surface Traffic
Limitations
Conflict Detection &
Resoluation
Local Data Collection
Center Handoff
Message
Airport Acceptance
Rate Message
Flight Time Data
Message
ACES Outputs
Figure 1 - ACES Model Overview
Aircraft State
Message
DRAFT
Page 8 of 50
Current Functionality
To support these capabilities, this build provides the models and data sets as listed in the table of
contents. In addition, a brief description of the visualization scenario tool is also presented, to provide
a more complete picture of the simulation functionality from the user-interface perspective. Agent
management control and data collection components are covered in the architectural description.
2.1.1
Aircraft
All aircraft are individually modeled. The aircraft model fidelity, however, depends on the flight
environment. See Appendix A for the list of supported aircraft.

For the en route environment, a 4 DOF (true airspeed, heading angle, roll angle, flight path angle
plus secondary variables: latitude, longitude, altitude, and weight/fuel), medium fidelity aircraft
model can be utilized for propagating aircraft in the en route environment and for providing
predictive trajectories. This 4 DOF model produces smooth and accurate aircraft maneuvers.

Aircraft fly their designated flight plan until redirected by en route ATC. In the terminal
environment, the flight time is specified by the terminal ATC and a low fidelity aircraft model
computes (with a simple table lookup) the fuel burn in the TRACON area A medium fidelity
aircraft model, using the BADA 3.6 (refer to Appendix A), computes the fuel burn in the En Route
area. Individual approach trajectories are not explicitly simulated. ACES 6.0 is enabled with
Surface Traffic Limitation Enhancement (STLE) which allows more complex analysis. When a
simulation with higher-fidelity approach trajectories is required, the user may use this capability.
Refer to Section 2.1.13 for more detail..

At the airport, a queuing model provides aircraft flow into and out of the airport. Similarly, see
section 2.1.13 for using a higher-fidelity model for aircraft flow into and out of the airport.
2.1.2
ATCSCC
ACES includes a model of the Air Traffic Control System Command Center (ATCSCC). The
key functions of the ATCSCC model are the prediction of future congestion events throughout the
NAS, dissemination of information on predicted congestion events to appropriate Air Traffic Service
Providers (ATSPs) and airlines, and a limited set of system level responses to system level congestion
problems. Specifically, the capabilities are:

The ATCSCC predicts the air traffic density of the entire NAS throughout the day-in-the-NAS
timeframe. Utilizing the flight plans for both active and planned flights, the ATCSCC model
predicts the density of traffic at each en route sector throughout the day, providing a long-term (8
to 24 hour) prediction of traffic densities through out the NAS.

The ATCSCC issues congestion alert messages to the Air Traffic Service Providers (ATSPs) as
well as to the airlines (through the AOCs) when predicted density exceeds capacity. Using the air
traffic density predictions and comparing them to the NAS capacities, the ATCSCC distributes
alert messages to all interested parties when demand exceeds capacity.
DRAFT
2.1.3
Page 9 of 50
En Route
The en route environment modeling can be divided into two distinct areas: the Traffic Flow
Management (TFM) and the Air Traffic Control (ATC). It is important to note that each individual
aircraft trajectory is modeled and can be altered by ATC as needed. The key functions of the en route
traffic flow management modeling are the facility (ARTCC) response to predicted congestion within a
30 - 60 minute range.
Specifically, the en route TFM capabilities are as follows:


The En Route TFM analyzes the predicted congestion event and decides on appropriate level
of facility response. The TFM model determines if the congestion problem can be handled
internally by absorbing delay within the facility or if the congestion problem is large enough
that it must be propagated to adjacent facilities with the introduction of TFM constraints.
The En Route TFM provides adjacent up-stream facility with required TFM constraints and
responds to adjacent down-stream facility TFM constraints. If congestion requires TFM
constraints to be put on an adjacent up-stream facility, the specific TFM constraint
information is communicated to the adjacent up-stream facility.
The key en route ATC functions are to respond to TFM constraints and maintain aircraft
separation through conflict detection and resolution.
Specifically, the en route ATC capabilities are as follows:




2.1.4
The En Route ATC detects conflicts between aircraft in the ARTCC airspace. The conflict
detection time horizon is sufficiently high to provide adequate time for resolution. To
perform conflict detection between aircraft in the ARTCC ATC, select CD&R option on
ACP editor from the MultipleRunManager GUI. The upcoming release of ACES will
integrate an alternative higher-fidelity CD&R modeling called the Advanced Airspace
Concept (AAC). Since AAC has its own conflict detection algorithm, AAC option cannot be
enabled on ACP editor.
The En Route ATC develops and implements a resolution plan for conflicts between aircraft
in the ARTCC airspace and provides aircraft with the necessary maneuvers to avoid conflict.
The En Route ATC responds to TFM restrictions. While resolving conflicts and maintaining
separation, the en route ATC also ensures that TFM restrictions from adjacent down-stream
facilities are met.
The En Route ATC delivers conflict free aircraft to adjacent down-stream facilities (ARTCC
or TRACON).
En Route Congestion
The en route traffic congestion assessment and resolution function generates and propagates
flight restrictions and resultant delays through the NAS-wide network of airports and ARTCCs.
ACES en route delay is originated by traffic flow limitations due to:
 Airport/runway system capacity
 En route sector traffic capacity.
DRAFT
Page 10 of 50
ACES 6.0 enhances the congestion assessment and resolution function by the introduction of dynamic
sector capacity. In previous builds, TFM did not consider future sector capacity configuration changes when
planning traffic flow throughout the NAS. It only considered the current sector capacity limits and used these
limits to “project” sector capacity limits. This manner of calculation leads to sub-optimal traffic flow
management throughout a simulation. For example, the total number of flight delays may be greater during a
simulation than when using a more optimal TFM schedule. The Dynamic Sector Capacity (DSC) feature
provides TFMs with the capability to consider future sector capacity changes when planning traffic flow
throughout the NAS. With DSC, a more realistic sector capacity change scenario may be modeled for a given
sector, thereby providing the TFMs with a more accurate depiction of what the actual capacity is for a given
sector at a given point in time (which may potentially be in the future). With DSC, there is no longer a need for
the TFM to “project” the capacity of a sector based on its current limits when performing its periodic sector
congestion forecasting activities.
The capabilities applicable to the ATCSCC, ARTCC TFM, ARTCC ATC and flight models are:

ATCSCC Model: Implement Monitor Alert
o Update Traffic Density (Flight and Sector) Data
o Assess NAS-wide Sector Traffic Overload with dynamic sector capacity
functionality:
Upon periodic activation, the ATCSCC TFM begins an assessment of sector congestion,
starting at the current simulation time. For the point in simulation time being evaluated,
the ATCSCC TFM performs the following for each sector in the NAS:
a. Compute the projected traffic density in the sector based on planned flight
trajectories.
b. Obtain the planned capacity for the sector (based on dynamic sector capacity) at
the specific time being evaluated. (If there is no planned capacity change for the
sector, this will be the default capacity.)
c. If the projected traffic density is higher than the planned capacity, issue a sector
congestion alert to the appropriate ARTCC TFM.
After congestion evaluation at a specific point in simulation time, ATCSCC TFM
increments the simulation look-ahead time by 15 minutes, and if the look-ahead is less
than or equal to 4 hours, the ATCSCC TFM will repeat the congestion evaluation for
each sector as described in steps “a” through “c” above.

ARTCC TFM Model: Conduct Congestion Resolution Planning
o Assess ARTCC Exit Boundary Crossing Restrictions
The ARTCC TFM model initiates en route traffic congestion assessments in response to
receipt of exit boundary crossing time restrictions. ARTCC TFM model determines delay
requirements for exit boundary-constrained flights, assign internal and external delay, and
assign ARTCC entry boundary crossing time requirements. ARTCC TFM model allocates
internal delay among sectors and assign sector boundary crossing time requirements.
DRAFT
Page 11 of 50
o Assess ARTCC Sector Traffic Overload with dynamic sector capacity
functionality.
The ARTCC TFM model initiates en route traffic congestion assessments in
response to receipt of sector congestion alerts. The ARTCC TFM model
determines projected instantaneous aircraft counts (IACs) for the subject sectors,
identifies overloaded sectors based on comparisons of projected sector IAC
loadings and IAC thresholds, determines external flight delay required to resolve
sector congestion (but uses previously-assigned internal delay to the extent
possible to minimize disruption to planned exit constraints), and assigns ARTCC
entry boundary crossing time requirements. If delays are initiated for a sector, the
ARTCC TFM will assign a delay to each flight which will enter the sector if and
only if the scheduled sector capacity at the time the flight will enter the sector will
be exceeded based on the dynamic sector capacity functionality.
o Disseminate Boundary Crossing Restrictions
The ARTCC TFM model issues inbound boundary crossing time restrictions to
upstream TFM agents and outbound boundary crossing time restrictions to its
ARTCC ATC agent.

ARTCC ATC Model: Implement Congestion Resolution

ATCSCC Model: Modify Trajectory
The ATCSCC model updates the flight predicted trajectory due to a flight maneuver and
issue notifications describing the updated predicted trajectory.

2.1.5
Flight Model: Conduct Maneuver
En Route Conflict Detection and Resolution (CD&R)
The minimum vertical and horizontal separations are safety requirements. The CD&R activity in
ACES is designed to detect upcoming violations of these minimums and resolve the predicted
violations. ACES models today's work-load limited ATC environment which uses relatively simple
resolution maneuvers. Therefore, the ACES CD&R activity maneuvers only one of the two aircraft in
a conflict, and only a single resolution maneuver is used, along with a single recovery maneuver back
to the flight plan.
These separation minima account for limitations in surveillance, navigation and control of the
aircraft position. Improvements in avionics technology, tracking surveillance, and ATC procedures
and DSTs serve to reduce the separation minima. To model the impact of such reductions ACES
provides a CD&R model that accounts for the separation minima.
This capability in the current version provides for low-fidelity modeling only. When a
researcher is interested in a high-fidelity modeling, AAC (described later) should be used instead.
2.1.6
Terminal
Terminal environment modeling can be divided into two distinct areas: Traffic Flow
Management (TFM) and Air Traffic Control (ATC). It is important to note that aircraft models in the
DRAFT
Page 12 of 50
terminal environment do not model each individual aircraft trajectory explicitly but provide nominal
flight time data adapted to the specific operational situation. The key functions of the terminal traffic
flow management modeling are the facility (TRACON) response to predicted congestion within a 15 30 minute range. Specifically, the terminal TFM capabilities are as follows:



The Terminal TFM analyzes the predicted congestion event and decides on an appropriate level of
facility response. The TFM model determines if the congestion problem can be handled internally
by absorbing delay within the facility or if the congestion problem is large enough that it must be
propagated to adjacent ARTCC with the introduction of TFM constraints.
The Terminal TFM provides adjacent en route facility with required TFM constraints. If it is
determined that the terminal facility cannot absorb the delay within the facility, the TFM model
provides the adjacent ARTCC with the specific TFM constraint information.
In the terminal area, flights are not explicitly modeled - nominal flight times are used to propagate
aircraft from the meter fix to the airport for arrival aircraft and from the airport to the meter fix for
departing aircraft. The terminal ATC adjusts these nominal flight times, within limits, to absorb
delay within the facility as necessary. The terminal ATC capabilities are:



2.1.7
The Terminal ATC absorbs delay in the terminal area, within limits and as needed, to
meet overall desired flow rate at airports within the terminal area.
The Terminal ATC delivers arrival aircraft that are conflict free to each airport within the
terminal area.
The Terminal ATC delivers departing aircraft that are conflict free to the terminal/enroute meter fix.
Terminal Area Modeling
2.1.7.1 Foundation Models
ACES introduces automatic calculation of terminal area transit times flight-by-flight for specific
boundary fix-and-runway/airport pairings and representative/average aircraft speeds (based on aircraft
type). ACES enables application of a simplified link network concept to connect TRACON boundary
fixes with nodal airports as well as individual runway thresholds of runway modeled airports as
illustrated in Figure 2-1. This network structure supports depiction of different link lengths between an
airport and different fixes. These capabilities support simulation of special terminal airspace
operations, specifically synchronized concurrent operations (e.g., closely-spaced, side-by/nearby/simultaneous runway approaches and landings).
An Enhanced Terminal Model is currently under parallel development, which provides yet
higher-fidelity capabilities, such as 4-DOF trajectories around the terminal area including surface.
DRAFT
Page 13 of 50
Nodal Airport Linkage
Runway Linkage
Figure 2-1 ACES Simplified Terminal Airspace Network
ACES also provides the capability to model multiple airports within a terminal area serviced by
a single TRACON. ACES extends the simplified link network to connect boundary fixes with each
runway threshold or nodal airport as illustrated in Figure 2-2.
Figure 2-2 ACES Multiple Airport Simplified Terminal Airspace Network
2.1.7.2 Link-Node Model
ACES 6.0 incorporates the Link-Node model to enable more complex terminal scenario analyses. This
enhanced design adheres in general to the existing ACES 4.6 agent-based concept, subject to extensions
and adaptations, and provides compatibility with NASA’s separately-developed ACES-X to the
maximum extent possible. This enhanced design implements Command and Control (C2 or C2) and Plant
DRAFT
Page 14 of 50
logical entities that operate in a link-node network modeling environment. It provides a basic link-node
network in its Terminal Area Plant (TAP), encompassing airport and terminal airspace components. An
airport (Plant) agent includes link, node and surface flight objects. A surface flight object moves through
the link-node network subject to C2 and aircraft motion modeling.
The ACES 4.6 provided a single Airport ATC agent that modelled gate, taxiway and runway operations.
ACES 6.0 uses this Airport ATC agent to model those airports that are not being modeled with the STLE
option.
At STLE-modeled airports, instead of the existing Airport ATC agent, STLE provides a new Airport
Surface agent modeling capability that implements Plant and C2 functions. Specific STLE capabilities
are discussed in Section 2.1.13.
The STLE Plant provides:
•
Link and Node Network Graph
•
Surface Flight Object
The STLE C2 functions include:
•
Gate Assignment
•
Runway Assignment (implements ACES 4.6 logic)
•
Surface Route Assignment
•
Trajectory Clearance Limit Assignment
•
Link Transit Control
•
Sequencing Node Transit Control
•
Complex Node Transit Control
•
Runway System Transit Control (incorporates ACES 4.6 logic)
•
Processing of Required Time of Arrival (RTA) Specifications
The STLE link and node graph is a specific representation of an individual airport and requires user-input
to define each link and node. The user determines and defines surface operational domains; typically
Gate-Ramp, Taxiway and Runway System. The conceptual airport link-node graph illustrated in Figure
2.3 encompasses a gate and ramp area, a runway system with crossing taxiways, and a remaining taxiway
network. Runways and taxiways, exclusive of loading ramps and parking areas, comprise the airport
movement area at NAS airports. Air traffic service provider ATC approval is required for entry onto the
movement area at airports with towers. Special purpose areas shown in the taxiway network area of the
graph may be part of (e.g., deicing stations) or outside (e.g., parking areas) the movement area depending
on local configurations.
DRAFT
Page 15 of 50
Gate & Ramp
Non-Runway
Taxiway
Network
Runway System
with crossing &
adjoining taxiways
Each link is assigned a domain:
Gate-Ramp domain,
Taxiway domain, or
Runway System domain
Special
Purpose
Areas (parking,
deicing, other)
Figure 2.3 Conceptual User-Defined Link-Node Graph
The C2 models are incorporated into the STLE-based ACES software, with provisions for user management by
parametric input.
The Plant and C2 functions are described in detail the ACES EDD Surface Terminal Limitations. Companion
documents, which are the STLE Software Design Document (SDD) and the STLE User Manual, further
describe modeling logic and data processing.
2.1.7.3 Capabilities

ACES Terminal Airspace capability includes the following specific capabilities:
1. Terminal Airspace Model Management
ACES provides a user interface using the Persistence Framework GUI (described in
Persistence Framework and Preliminary Data Management GUI for Airport Terminal Model
EDD) for identifying the modeling process applicable to each TRACON. This interface
enables user specification of: nodal or individual runway modeling, nominal or calculated
transit times, generic airspace or link network operations, and single versus multiple airport
modeling.
2. Simplified Link Network Operation (Boundary Fix – Airport/Runway Linkage)
ACES provides the capability to model ATM and flight operations based on interactions
between airport runway systems and TRACON boundary arrival and departure procedures.
This enhancement provides:
o
Flight transit links between specific boundary fixes and specific runways or a nodal
airport
DRAFT
Page 16 of 50
o
User-specification and default mechanisms for calculating transit times on links
between specific boundary fixes and specific runways or a nodal airport
o
Modeling logic to account for synchronized concurrent landing operations
3. Multiple Airports in a TRACON Airspace
ACES provides the capability to model ATM and flight operations for multiple airports
within a single terminal area:

o
User-specification mechanisms for identifying nodal-modeled and runway-modeled
airports in a TRACON
o
Modeling logic to synchronize traffic flow planning for arrival and for departure traffic
among airports within a common terminal airspace
ACES Runway Modeling capability includes the following capabilities:
1. Runway Modeling Activation
ACES provides a user interface for identifying special runway-modeled airports (i.e., those
for which individual runway operations are analyzed) and defining associated parameters.
2.
Multiple Terminal Area Boundary Fixes (Flexible Terminal Airspace Boundary)
ACES provides the capability to define the configuration and use of arrival and departure
fixes on the terminal airspace boundary:
o User specification of a terminal airspace boundary of variable radius with automatic
assignment of four fixed arrival fixes and four fixed departure fixes (all equally-spaced,
with a North-aligned arrival fix.
o User specification of an unlimited number of arrival and departure fixes in any
sequence on a circular terminal airspace boundary.
o User specification of an unlimited number of arrival and departure fixes at any location
corresponding to an irregular terminal airspace boundary.
o For an irregular terminal airspace boundary, user specification of any fix by either (1)
bearing and radial distance or (2) latitude and longitude, with automatic translation of
one format to the other
o Automatic determination and assignment in each Flight Data Set (an object stored in
memory for each flight) of arrival and departure fixes closest to the flight route
regardless of terminal airspace boundary configuration.
3.
Runway (and Fix) Assignment
ACES provides the capability to define a specific runway assignment for each flight based
on arrival and departure procedures:
o User specification of takeoff runway according to departure fix and aircraft type.
o User specification of landing runway according to arrival fix and aircraft type.
o Automatic determination and assignment in each Flight Data Set in memory of takeoff
and landing runways according to meter fix-aircraft type user specifications.
DRAFT
Page 17 of 50
o For details on Meter Fix and Runway assignments, refer to System/Subsystem Design
Description (SSDD) / Software Design Document (SDD) – Appendix A.3 – Terminal
Area Operations
4
Individual Runway Identification and Aircraft Spacing Matrices (Runway Aircraft
Spacing)
ACES provides the capability to assign a takeoff or landing time by individual runway to a
specific flight in conformance with airport operating procedures, runway configurations
and airport operating conditions:
o Definition of active runway configurations and eligible arrival or departure operations
by operating condition for an airport.
o Definition of pair-wise aircraft spacing rules (defined by minimum separation
requirements by aircraft class and buffer matrices) by runway configuration and airport
operating condition.
o Automatic assignment of takeoff and landing time in conformance with spacing rules
and runway assignments.
o User selection of default spacing rules for selected generic runway configurations and
VFR and IFR airport operation conditions (the spacing rules automatically override any
acceptance rate limits defined for the airport).
o User specification for an airport of active runway configurations and eligible arrival or
departure operations by operating condition and of pair-wise aircraft spacing rules by
runway configuration and airport operation condition.
o For details on Runway Aircraft Spacing, refer to System/Subsystem Design Description
(SSDD) / Software Design Document (SDD) – Appendix A.3 – Terminal Area
Operations
5
Runway System Departure-Arrival Mixing
ACES provides the automatic capability to re-sequence flights so as to interleave takeoffs
and landings where warranted to prevent inappropriate batching of arrivals or departures.
For details on Runway System departure-arrival mixing, refer to System/Subsystem Design
Description (SSDD) / Software Design Document (SDD) – Appendix A.3 – Terminal Area
Operations.
6
Airport TFM Planning
ACES enables the Airport TFM model, for special runway-modeled airports, to project
takeoff and landing times and delays according to pair-wise aircraft separation rules, a
combination of pair-wise aircraft separation rules and acceptance rates, or manual
acceptance rates. This feature enables user selection of the following TFM planning modes
for a special runway-modeled airport:
Basic Airport TFM Planning
This feature enables the Airport TFM model to determine projected takeoff and landing
times according to pair-wise aircraft separation rules for individual runway operations
and issue arrival flight TFM restrictions.
DRAFT
7
Page 18 of 50
Airport ATC Runway Operations Assignment
ACES enables the Airport ATC model to determine actual takeoff and landing times
according to pair-wise aircraft separation rules for individual runway operations (not
according to acceptance rates).
2.1.8
Separation at the Arrival Meter Fix
In ACES arrival aircraft descending and crossing the arrival fix, as they enter the TRACON,
may not be minimally separated (e.g., 5 nmi) because ACES ARTCC agents do not maintain
separation at the arrival fix. This capability is provided through the ARTCC TFM and ATC models.
In ACES, the ARTCC TFM agent monitors all aircraft within the Center that are flying to
common terminal area arrival fixes within that Center. It evaluates currently projected arrival fix
crossing times, determines delays necessary to ensure minimum separation at the arrival fix, and
reassigns projected crossing times. These updated projected crossing times are passed as TFM
restrictions to the ARTCC ATC agent and, if necessary, to upstream ARTCC TFM agents. The
upstream ARTCC TFM agent processes TFM restrictions.
ACES ARTCC ATC agent applies the set of maneuvers used in the AAC model in delaying the
aircraft in response to receipt of TFM restrictions.
This section gives the relevant capabilities for the TFM element.
1. A user interface is provided for activating or deactivating the TFM arrival fix spacing
function and for defining a TFM arrival fix spacing assessment (look-ahead) horizon
parameter. This parameter is strictly applicable only to arrival fix spacing and does not
impact the scope of the TFM restriction and Monitor Alert assessments.
2. The ARTCC TFM agent issues ARTCC boundary crossing time restrictions designed to
preclude violations of separation minima at TRACON arrival fixes. Restrictions are issued
to the corresponding ARTCC ATC agent and if necessary to upstream TFM agents.
The following capabilities apply to the ATC element.
1. The ARTCC ATC agent uses the speed control method to meet the required arrival fix
crossing time if reasonable speed control is capable of imparting the required delay.
2. The ARTCC ATC agent uses the path stretch method to meet the required arrival fix
crossing time if reasonable speed control is not capable of imparting the required delay.
3. The ARTCC ATC agent uses the holding pattern method to help to meet the required
arrival fix crossing time if reasonable path stretching is not capable of imparting the
required delay.
Limitations:
The model does not provide coordinated exchange of projected arrival traffic data between a
TRACON TFM agent and Airport TFM agents, and therefore the Airport TFM model does not
incorporate the effects of arrival fix crossing constraints into the process of determining planned
landing times.
DRAFT
2.1.9
Page 19 of 50
Arrival Fix Rerouting
In ACES, aircraft can be routed to new meter fixes and airports.

ACES allows a flight's departure metering fix to be changed to another metering fix (of the same
TRACON) prior to gate departure. This works for both the nodal and the enhanced (multiple
airports per TRACON) terminal area models.

ACES allows a flight's arrival metering fix to be changed to another metering fix (of the original
arrival TRACON) prior to takeoff.

ACES allows a flight's arrival metering fix to be changed to another metering fix (of the original
arrival TRACON), while the aircraft is in the en route phase of flight and prior to the top of
descent.

All MF and airport reroute actions are output to LDC for post processing purposes. En route
reroutes are output to LDC for post processing purposes.

The AOC, ARTCC ATC, and Flight agents are capable of requesting MF reroutes.
The following capabilities apply to rerouting to an alternate arrival airport.

ACES allows a flight's arrival airport to be changed to another airport prior to takeoff.

ACES allows a flight's arrival airport to be changed to another airport in the en route phase of
flight.

The AOC, ARTCC ATC, and Flight agents are capable of requesting airport reroutes.
2.1.10 Overlapping TRACONS
In ACES, we enhanced the TRACON and Airport logic to allow flights between overlapping
TRACONS to be processed within the simulation. In our design, the filtering for overlapping
TRACONS is removed as well as the filtering for aircraft with the arrival airport being identical to the
departure airport. An accepted overlapping TRACON flight has no en route segment, MPAS does not
generate an en route trajectory, and en route sector congestion alerting and ARTCC arrival fix spacing
functions are not applicable. Arrival and departure flight segments are modeled using existing ACES
capabilities.
This section gives the relevant capabilities.

Short flights, including Overlapping TRACON flights, are supported.

Short flights, including Overlapping TRACON flights, are added to TFM arrival scheduling.
2.1.11 Airport
A generic airport model provides ACES with both TFM and ATC functionality to enable
modeling of the individual aircraft as they enter and exit the airport. Individual airport capacities
(departure and arrival rates) are utilized to create realistic traffic flow into and out of each airport. The
Airport ATC model provides a first-come, first-serve queuing of departure aircraft, accounting for the
DRAFT
Page 20 of 50
necessary time delays between runway operations. If the numbers of aircraft scheduled for departure
exceed the airport departure capacity, the Airport ATC model delays the aircraft departures to meet the
airports departure capacity. The departures and arrivals are considered independent operations. Ground
operations are not modeled. Specific modeling capabilities are:




The Airport maintains a queue of departing aircraft, according to scheduled departure time.
The Airport model schedules aircraft actual departure time. If the scheduled departing time
cannot be met because departure demand exceeds capacity, the airport model delays the aircraft
scheduled departure time.
The Airport responds to ATCSCC TFM constraints. The Airport model implements ground
holds and ground delays specified by the ATCSCC.
The Airport responds to AOC flight delays and cancellations.
2.1.12 Dynamic Airport Arrival and Departure Capacities
ACES processes runway system capacity input data for each airport specifying VFR and IFR
arrival, departure and total acceptance rate limits. These six values are specified for each airport.
Default acceptance rate limits for all airports are defined in a comma separated value (CSV) static data
file that is read at simulation startup.
ACES allows users to define an unlimited number of additional airport operating conditions and
a set of three acceptance rate limits (arrival, departure and total) for each such operating condition.
Each airport operating condition and associated set of acceptance rate limits is triggered by time. The
user would optionally access a file to specify the airport capacity as VFR, IFR, or user-defined arrival,
departure, and total acceptance rate limits.
The User-Adjustable Runway System Capacities capability supports the following capability:

The scenario capability provides the ability to script a scenario, introducing changes in capacities
of airspace or airports to create desired traffic flow management situations. Refer to the ACES
Software User Manual to configure the scenario file.
2.1.13 Surface Traffic Limitations Enhancement (STLE)
2.1.13.1 Description - ACES processes traffic schedule and runway capacity data to simulate
airport flight operations, providing surface congestion constraints on traffic
operations. The ACES software simulates runway system operations based on flight
demand versus capacity traffic load analyses. In addition, it simulates non-runway
surface operations by considering traffic load characteristics and limitations. ACES
provides multiple STL options at varying levels of fidelity. The ACES user can
choose to activate STL functionality at each individual airport at any of the available
levels.
2.1.13.2 Surface Modeling
2.1.13.2.1 Basic STL - The original ACES STL function provides a very basic
capability to account for surface congestion constraints on traffic operations. The basic
DRAFT
Page 21 of 50
ACES STL functionality simultaneously models different airports at either of two levels
of fidelity per user definition:
o Nodal/aggregate modeling - Overall runway system throughput is governed by
acceptance rate limits. When this modeling is used, the Airport TFM model assigns
planned arrival and departure acceptance rates for application by the Airport ATC
nodal airport model.
o Runway modeling - Utilization of each runway is determined by descriptions of
local operating procedures for a special runway-modeled airport. When this
modeling is used, the Airport TFM and ATC models use aircraft minimum
separation requirements to evaluate runway system operations.
2.1.13.2.2 STL Enhancement (STLE) - The STL functionality in ACES 6.0 has
been enhanced to provide more detailed modeling to support higher fidelity analysis.
Additionally, it enables higher-complexity modeling of current surface traffic
operations and proposed future operational concepts.
o Link-Node modeling - STLE models surface traffic movement through the
gate/ramp-taxiway-runway network using a link-node modeling structure. The
airport’s set of link and node objects is a graphical abstraction of the surface system,
where surface modeling accuracy is dependent on the level of detail provided by the
ACES user input data. The link and node network graph defines the physical
location and geometry of surface taxiway and runway segments, intersections and
service facilities such as terminal gates, parking areas, de-icing stations and so forth.
These objects have parameters describing physical location (e.g., latitude and
longitude), dimension (e.g., taxiway length, intersection radius) and other attributes.
At STLE-modeled airports, instead of the existing Airport ATC agent, STLE
provides a new Airport Surface agent modeling capability that simulates individual
aircraft operations on the airport surface.
2.1.13.3 Modeling Options - The ACES user has the option to assign a specific runway
modeling mode to each airport. A single ACES run may implement a mix of
simultaneous nodal/aggregate, runway, and Link-Node STLE modeling, each at a
different airport.
2.1.13.4 Capabilities
2.1.13.4.1
STL - The Surface Traffic Limitations (STL) basic function supports the
following capabilities:

Interfaces with Airport TFM to incorporate surface traffic congestion to
determine runway system utilization plans

Interfaces with Airport ATC to incorporate surface traffic congestion to
determine actual movement of surface traffic
DRAFT
Page 22 of 50

Enables user-defined activation of the Surface Traffic Limit function on an
individual airport or all-airport selection basis
2.1.13.4.2
STLE - The Surface Traffic Limitations Enhanced (STLE) function
supports these additional capabilities:

Simulates actual airport surface traffic operations using gate/ramp-taxiway-runway
link-node network modeling between gates and runways inclusively (i.e., including
the gates and runways). This requires user definition of gate/ramp-taxiway-runway
link-node network representation of each airport to be modeled with STLE.

Enables modeling of alternative surface route network structural configurations and
alternative operating procedures, accounting for specified ATM-flight deck-AOC
interactions and communication, navigation and surveillance (CNS) system
deployments

Simulates surface aircraft movement trajectories and air traffic control processes

Enables plug-and-play modifications of modeling entities

Applies existing ACES terminal airspace/individual runway use modeling

Applies existing ACES airport surface traffic flow management modeling

Enables user-defined activation/deactivation of the STLE function on an individual
airport selection basis before runtime
2.1.14 Airline Operations Center (AOC)
A low fidelity Airline Operations Center (AOC) provides an AOC model that responds to realtime conditions within the NAS. The AOC has the capability to delay or cancel specific flights in
response to TFM constraints imposed by the ATSP or ATCSCC. Located in the
/cto7sim/data/static_data/AocParameter.csv file, a specific flight can be delayed or cancelled in the
AOC. The default configuration is AOC automatically cancels a flight that has a delay greater than 2
hours. However, this default can be over-ridden by replacing the second parameter for “Maximum
average delay of inbound flights;” e.g., with “999” value.
2.1.15 Airline Operations Center Cancellations and Delays
ACES provides two AOC agent activities: flight cancellations and flight delays. These allow the
AOC agent to monitor and provide cancellations and delays to the various other agents within the
simulation. The capabilities for the AOC model are:

AOC Model
1. AOC Agent Activity: Flight Cancellation
DRAFT
Page 23 of 50
The AOC flight cancellation activity determines flight cancellation status based on a low
fidelity model of the AOC pre-determined heuristic criteria. The activity is flexible enough to
allow user inputs. Refer to the ACES Software User Manual for more details on configuration
of the user input file.
2. AOC Agent Activity: Flight Delay
The AOC flight delay activity identifies whether an aircraft is banking, determines the passenger
connecting relationship between an inbound and an outbound flight, estimates the amount of delay
imposed on the outbound flight.
2.1.16 Traffic Demand
A traffic demand model creates a realistic day-in-the NAS simulation scenario file for ACES.
The Traffic Demand model is derived from historical data of the NAS and provides a set of scheduled
aircraft with realistic flight plans representing multiple airlines. The scenario file is used to initialize
the ACES simulation.
2.1.17 Weather
ACES provides truth wind data from grid wind data files that are periodically updated (1 hour
intervals). Interpolation between the data sets provides a 4D wind vector.
Inclement weather effects for ACES are represented as capacity reductions in airspace or at
airports. To configure capacity reductions, use the ../cto7sim/data/static data/Airport Capacity files
and refer to the ACES Software User Manual.
2.1.18 Constrained Airspace Rerouting Planner (CARP)
In ACES, a rerouting module that enables rerouting around constrained regions -- such as weather
-- defined by convex polygonal boundaries. In the design, the capability is implemented by a set of
classes that handle all of the reroute processing for a single ARTCC. The design also uses a new
Activity added to the ARTCC ATC that handles all of the interaction with other Activities, and
invokes the reroute classes as needed.
This section gives the relevant functional CARP capabilities.
5. The system allows a user to define a constrained airspace using Scenario files/messages via an
external/companion tool such as Matlab to generate polygons and scenario files to be placed in
../cto7sim/data/scenario_events/.
6. Constrained airspace regions in the scenario files are specified as either: 1) A set of one or
more centers; 2) A set of one or more sectors; or 3) A set of one or more polygons with upper
and lower altitude bounds. The vertices of the polygons are specified by latitude/longitude
pairs.
DRAFT
Page 24 of 50
7. The software allows for user-configurable offset distance that is applied to the polygons as a
buffer region. This offset distance should generally be greater than 0. The unit measurement
is defined as --Degree:Minute:Second(latitude)/Degree:Minute:Second(longitude).
8. The constrained airspace region description also includes an effective start and stop time for
the constraint to be effective, as well as a list of flights that are affected by the constrained
airspace (or an indication that all flights should be affected).
9. The constrained airspace region description may optionally include a vector offset that defines
the motion of the constrained region over the duration of the constraint, e.g. to simulate
weather cell movement. The offset is applied proportionally over time such that the polygon
moves from the originally defined position at the start of the effective constraint time to the
original position plus offset vector at the end of the effective constraint time. This only applies
to regions defined by generic polygons (above item 3).
10. CARP allows a user to define a constrained airspace using a GUI at run time.
11. The GUI provides a “mouse mode” that allows the user to interactively select a lat/long
position to specify the constrained region. The user may choose to indicate the constrained
region as: 1) a specific sector at the specified position; 2) all sectors at the specified position;
or 3) the entire ARTCC containing the specified position.
12. The GUI also provides a “mouse mode” that allows the user to interactively specify an
arbitrary polygon as the constrained region. A means of allowing the user to specify the
altitude bounds for the polygon is also provided. The GUI enforces the requirement that the
constrained region be convex as the user is designing the polygon by preventing the user from
designing a non-convex region.
13. The GUI provides a means of allowing the user to specify the start and stop effective times of
the airspace constraint.
14. The GUI provides a means of allowing the user to specify a specific set of flights to be
affected by the constrained region, or to specify that all flights should be affected.
15. The GUI indicates on the display the 2D polygon regions that are being constrained at the
current simulation time
16. The GUI allows an optional user-configurable buffer region offset distance to be specified.
17. The reroute model performs time-varying two-dimensional polygon-based rerouting of flight
plans around constrained (closed) airspace regions specified as polygons with upper and lower
altitude bounds. Flights that are above or below the altitude bounds are not rerouted.
18. The reroute model computes the minimum cost reroute given a specified cost function. This
cost function is simply overall distance, although other cost models could be substituted in the
future. A penalty cost is associated with routes that must pass through some portion of the
constrained region.
DRAFT
Page 25 of 50
19. The reroute model computes a reroute in the presence of multiple constrained airspace regions
within one ARTCC, which may or may not overlap.
20. In the event that no feasible reroute can be found, an error is indicated so that the original
route can be used.
21. The reroute model is designed and implemented such that alternate rerouting algorithms can
be swapped in place of the existing one. There is a generic interface that the reroute model
uses to calculate the reroutes.
22. The reroute module handles incoming and outgoing international flights properly.
2.1.19 Rerouting in En Route CD&R for Separation Assurance
ACES implements an in-flight rerouting capability so that aircraft can be routed around
congestion. The design, however, allows for a generic environmental "cost" to be specified so it is not
limited to congestion costs. For instance, convective weather or Special Use Airspace (SUA) could be
rerouted around.
In our design, the reroute module is a class. Therefore, it may be used by any agent to compute a
reroute. In this task we constructed a reroute module. Users may also construct their own reroute
modules. In this task we tested and demonstrated the use of the reroute module in the ARTCC ATC
agent.
A reroute is a new flight plan. As such it may alter the horizontal path, the cruise speed, and the
cruise altitude. If future off-route maneuvers had been planned for an aircraft that is rerouted, we
assume those maneuvers are no longer appropriate and they are eliminated. Also, aircraft that are
currently executing an off-route maneuver may not be rerouted. But if an aircraft is rerouted, it may
then execute off-route maneuvers just as before. Also, it may be rerouted again. The reroute module is
limited to two-dimensional (horizontal) reroutes.
Enroute rerouting is implemented. The reroute module does not cause the aircraft to be rerouted.
It merely computes a new flight plan which the invoking agent may then use. Therefore, the reroute
module does not modify ACES simulation data such as the FDS and sector loading predictions.
Instead, the output of the reroute module is a new flight plan which, if implemented, ACES uses to
modify those data and guide the remainder of the flight.
ACES reroute capability has been achieved by having the ARTCC ATC agent use the output of
the reroute module (i.e., the new flight plan) to change the flight plan of the aircraft. In particular,
aircraft FDS object is modified; TFM-related data is changed, such as the sector loading predictions,
boundary crossing times, and potentially the destination metering fix and TRACON.
This section gives the relevant capabilities.

The ARTCC ATC agent models congestion at the sector level by providing, to the reroute
module, predicted sector congestion cost data.
DRAFT
Page 26 of 50

ACES modeling architecture is such that any agent can send a reroute message (containing the
new flight plan) to the Flight agent and to the Distribution agent.

ACES architecture is such that any agent can receive congestion data.

Reroute requests are capable of changing the horizontal path, cruise altitude, cruise speed, or any
combination of those three. Note that the reroute module only computes horizontal path changes.

Reroute requests are capable of rerouting across ARTCC boundaries. Reroute is from current
aircraft location to a final point specified by user. The final point need not be inside current
ARTCC.

The ATCSCC, ARTCC TFM and ARTCC ATC agents are capable of handling rerouting
requests to another metering fix in the original destination TRACON. The final point is not
required to lie on the flight plan. Note that terminal area agents and models need to be updated
before this capability is functional.

The ATCSCC, ARTCC TFM and ARTCC ATC agents are capable of handling rerouting
requests to a different TRACON. Not only is the final point not required to lie on the flight plan,
but the aircraft can change destination airport. Note that terminal area agents and models need to
be updated before this capability is functional.

ACES architecture indicates, in the flight plan data provided to the reroute module, which part of
the plan has been flown and which part is yet to be flown. Note that the flight plan which has
been flown may be omitted except for the most recent waypoint that the aircraft has passed.

ACES architecture supports AAC trial planning using rerouting (upcoming Build capability of
supporting AAC trial planning using temporary off-route maneuvers).
The following requirements apply to the rerouting module created in this task:
1. This reroute module accepts as user input the congestion incursion cost parameters
specified for each sector.
2. This reroute module accepts a user input minimum cost. Reroutes are not performed for
flights if their existing route has a cost less than this minimum value.
3. This reroute module generates a reroute based on user-specified costs by estimating the
optimal route from the aircraft current location to a specified subsequent point along the
flight plan (somewhere between the aircraft current location and the arrival metering
fix).
4. This reroute module evaluates the original route to determine if a reroute is warranted,
unless the user input forces a reroute.
5. This reroute module estimates the shortest route given the environmental costs.
2.1.20 Airspace
ACES utilizes the current NAS airspace. The CONUS ARTCC facility / sector boundaries,
TRACON meter fixes, airport locations, and waypoints define the airspace.
DRAFT
Page 27 of 50
2.1.21 Advanced Airspace Concept
[Note: Advanced Airspace Concept is currently an external/companion release for ACES Build
5.0. AAC will be formally part of Build 6.0 and this document will be updated to reflect any updates
to AAC in the meantime]
The purpose of the AAC model is to provide the user with a programmable CD&R capability.
The AAC model interacts with a user-supplied CD&R module. The user-supplied CD&R module
receives conflict data from the AAC model and submits trial resolution plans. The AAC model then
provides data resulting from the hypothetical implementation of the trial plan. The user-supplied
CD&R module may submit any number of trial plans, in series, as it searches for the desired resolution
maneuver. This process continues until the user-supplied CD&R module arrives at a decision. It may
choose a resolution from one of the trial plans it has submitted, it may choose yet a different resolution
maneuver, or it may choose not to implement a resolution. The AAC model provides all of the
facilities required for a programmable, advanced CD&R module. The relevant capabilities are given
below.

All predicted conflicts are output, including the following information:
1. time at which the prediction is made,
2. flight ID and aircraft type of the two aircraft,
3. maneuver status of the two aircraft at time of prediction,
4. top of descent and top of climb data for the two aircraft at time of prediction,
5. flight status of the two aircraft (i.e., climb, descent, or cruise) at time of prediction,
6. time and location of predicted PCA (point of closest approach) and first loss of separation
(FLS) at time of prediction,
7. wind vector at time and location of the predicted PCA,
8. state (position and velocity) of the two aircraft at time of prediction, time of predicted first
loss of separation, and time of predicted PCA,
9. resolution information (e.g., was a resolution maneuver performed? If so, which aircraft
performed the maneuver?), and
10. time and location of actual violations that occurred.

pass as output the predicted conflict data to the AAC concept module at the time at which the
conflict is predicted:
1. time at which the prediction is made (i.e., current time),
2. flight ID and aircraft type of the two aircraft,
3. maneuver status of the two aircraft at time of prediction,
4. top of descent and top of climb data for the two aircraft at time of prediction,
5. flight status of the two aircraft (i.e., climb, descent, or cruise) at time of prediction,
DRAFT
6.
7.
8.
9.
Page 28 of 50
time and location of predicted PCA (point of closest approach) and first loss of separation
(FLS) at time of prediction,
wind vector at time and location of the predicted PCA,
state (position and velocity) of the two aircraft at time of prediction, time of predicted first
loss of separation, and time of predicted PCA,
current and predicted state (position and velocity, coordinate frames are defined) of the two
aircraft at S sec intervals (S is likely be somewhere between 10 – 30 sec) up to PCA.
o
detects conflicts from metering fix to metering fix.
o
detects conflicts based on intent (i.e., the flight plan). This baseline detection algorithm
checks a finite number of minutes into the future.
o
accepts as input candidate resolution data (i.e., the "trial plan") from the AAC module.
o
supports vertical-plane resolution maneuvers (speed and altitude) in addition to
horizontal-plane resolution maneuvers (turns).
o
evaluates the trial plan against all other traffic in the Center and passes as output the
predicted conflict data (assuming the trial plan is used) to the AAC concept module.
This trial plan detection algorithm checks a finite number of minutes into the future
(default = 10 minutes). We had worked with the NASA AAC concept development
team in defining the details of this process.
o
accept as input final resolution strategy to be used from the AAC module.
o
ACES AAC activity cycle time is a user-specifiable input (input via static file, default:
5 min, limits: 5 sec – 9999 min)
o
ACES simulation advances no more than 10 seconds during one entire AAC cycle.
2.1.22 Uncertainty Capability for CNS
Accessability, quality, and timeliness of data play an important role in the actions of the various
NAS agents. For specific studies of NAS-wide behavior, modeling of these limitations can be
important. To support this functionality, ACES provides the capability to model uncertainty.
The capabilities applicable to all of the agents and Flight models are specified below.

ACES logic supports multiple types of aircraft states. These are the true state and multiple
estimated states.

ACES logic supports multiple types of predicted trajectories and associated predictions, such as
facility boundary crossing times, and other 4D associated trajectory data. The different types of
predicted trajectories include the trajectory predicted by the Flight agent and the trajectory
predicted by the ATC.

Any agent can access or determine:
DRAFT
Page 29 of 50

Current state data (true or modified) relevant to its operational scope

Flight plan data relevant to its operational scope

Trajectory data relevant to its operational scope

Any agent can exchange state, flight plan and trajectory data with other agents.

ACES continues to collect true state data as well as predicted trajectories and estimated states. The
associated time tags are required as part of the predicted trajectories and estimated states.

The system demonstrates the uncertainty architecture with an uncertainty example.
2.1.23 International Flights
International flights are included in the traffic demand model. The trajectories of international
flights are simulated within the NAS airspace just as domestic flights are simulated. International
flights are included in CD&R checks and resolutions. International flights are included in sector
overload computations and terminal area congestion. International flights are maneuvered in like
manner as domestic flights for CD&R and TFM reasons. International flights contribute to system
performance statistics, such as traffic throughput at the domestic arrival and departure airports, conflict
counts, flight time and fuel burn. AOC handles international flights.
2.1.24 International Overflights
The ACES software allows international overflights to be handled as potentially valid flights.
International overflights are included in airspace sector congestion counts within CONUS.
International overflights are created similarly to international arrivals, and terminated similarly to
international departures. International overflights are included in conflict detection procedures within
CONUS. International overflights are affected by conflict resolution maneuvers within CONUS.
International overflights are able to be subjected to enroute TFM delays while in CONUS airspace.
The data collection indicates whether a flight is an international overflight. TFM delays of
international arrival flights can be disabled via user specified file located in
../cto7sim/data/international_flights/internationalflight.cfg.
2.1.25 Tail Tracking
ACES has a tail tracking capability so departure aircraft are constrained by aircraft availability.
This tail tracking capability constrains the departure time of a flight to time periods when its aircraft is
available. If the aircraft, used in a flight, is currently being used in an earlier flight, then the second
flight cannot depart. Also, after the aircraft does arrive at the gate, a nominal turn-around time is
required. Therefore, the second flight cannot depart immediately after the aircraft arrives.
This section gives the relevant capabilities.

The ACES software, or preprocessing software, uses the BTS database to extract associated
flights, by virtue of their using a common aircraft (i.e., tail) number.
DRAFT
Page 30 of 50

Associated flights are so designated in ACES so the associations can be accounted for in the
ACES simulation.

The minimum aircraft turn-around time, between flights are user specifiable, with a default value
of 30 minutes.

As an option, the minimum aircraft turn-around time is a function of airport and airline (i.e., a
two-dimensional table) that is user specifiable, with default values of 30 minutes.

Flights incur the necessary gate departure delay if necessary (i.e., if the gate arrival time of the
previous flight plus the minimum aircraft turn-around time is later than the scheduled gate
departure time). The new gate departure time is equal to the gate arrival time of the previous
flight plus the minimum aircraft turn-around time.

The user is able to choose options for using the existing AOC agent flight delay or using the gate
delay capability.

The existing AOC agent flight cancellation model accounts for associations with later flights
(i.e., a cancelled flight may cause a ripple effect of subsequent cancellations due to aircraft
unavailability).
2.1.26 Variable Descent Profile
The current ACES simulation executes a single Mach-CAS profile during descent for each aircraft
type. If an aircraft is accelerated or decelerated during the cruise portion of the flight by an AAC
(Advanced Airspace Concept) resolution, the speed change is not carried over into the descent. This
can result in the conflict reappearing during the descent. To prevent reappearing conflicts during
descent, ACES has the following capabilities:
Slow and fast profiles can be specified for the descent after a change in the cruise conditions.
Available as a route change, these profiles can therefore be used by any activity that reroutes flights,
not just AAC.


Allow variable descent profiles.
1.Queries Available for a Flight
2.Slower Speed Profiles for Jets
3.Faster Speed Profiles for Jets
4.Slower Speed Profiles for Turboprop and Piston
5.Faster Speed Profiles for Turboprop and Piston
Try out different descent speeds as part of the trial planning process. This means the desired
increment or decrement is passed when the route is changed.
2.1.27 Sector Grid Redesign
ACES provides modeling for more complex sector geometries based on Federal Aviation
Administration (FAA) adaptation data in Enhanced Traffic Management System (ETMS) format for
current and future data. ACES uses a sectorization model where sectors are described by single
DRAFT
Page 31 of 50
polygons with floor and ceiling altitude limits and are located three altitude bands, low, high, and
super.

Use current and future airspace models.

Accommodate any number of subsector references.

Read enhanced grid map data and store subsector data and combine into sectors internally.

Maintain output data reporting at sector level instead of subsector level.

Companion tool to generate Grid
2.1.28 BADA 3.6
In order to add new aircraft models to ACES, they must be introduced into the MPAS data
folder as well as adding new entries into the ACES aces_model_input Terminal Area database.
These models are represented as parameterized input data files for MPAS that are based on Base of
Aircraft Data (BADA) models. Additionally, it may be desired to update the existing models to
more accurate and recent versions of the BADA data. A tool has been created called
UpdateMPASFiles that takes BADA input files, BADA synonym lists, a baseline MPAS file, and
creates a new baseline MPAS data file for the aircraft model. Four new aircraft models were added
to the base set of 37 independent aircraft models (depicted in Appendix A) and 27 new substitutions
(depicted in Appendix A) were added to the sublist (depicted in Appendix A), and roughly 700
flights were added to the accepted flight list.
2.1.29 Visualization/Scenario/Simulation Control
The Visualization/Scenario/Simulation Control Tool (VSSCT) provides the user with the ability
to monitor the simulation, provide scenario inputs, and configure and control the simulation. The
visualization capability provides the user with:

A plan view display of the entire NAS, displaying aircraft and other desired NAS entities of the
simulation

An ability to select a specific aircraft, airspace region, or airport and obtain the current status.
The scenario capability provides the user with:

the ability to script a scenario, introducing changes in capacities of airspace or airports to create
desired traffic flow management situations

the ability to change the scenario during runtime by changing airspace or airport capacities or
specific aircraft flight plans
The simulation control capability provides the user with:



the ability to configure the simulation.
the ability to initialize the simulation.
the ability to start, stop, pause, resume, and control the execution speed of the simulation.
DRAFT

Page 32 of 50
the ability to run the simulation without the plan view display (batch mode) while maintaining
simulation control and scenario capabilities.
2.1.30 Communication, Navigation, and Surveillance (CNS)
2.1.30.1 Description - The ACES CNS functionality allows researchers to study the
relationship between NAS ATM CNS system performance and flight operations. The
system has a wide range of configuration options and flexibility, allowing mixed
mode system analysis. The CNS functions within ACES 6.0 are configured as plugins which are able to model:
o the communication between the flights and controllers,
o the feeding of data to and from the navigation systems on an aircraft, and
o the feeding of data to and from the ground surveillance facilities.
These models are not part of the core ACES software, and a user may or may not
configure and run a simulation job using them. When these models are used, the user
manually selects the specific plug-ins to load, and the ACES Plug-In framework loads
them when the job is run.
2.1.30.2 Functionality - ACES CNS functionality includes:
2.1.30.2.1 Communications:

Voice Communication - primary communication mechanism between the pilot and
Air Traffic Control facilities (Tower, TRACON, ARTCC) in the present NAS.
CNS implements voice communication, simulated voice message exchanges that
are typical for gate-to-gate aircraft/flight operations.

Controller-Pilot Data Link Communication (CPDLC Datalink/VDL-2) - data link
application providing the means of communication to transmit digital data
messages directly between computers on the ground and computers onboard the
aircraft for ATC communications.
2.1.30.2.2 Navigation:

VOR/DME Navigation - ground based electronic navigation aid which CNS
provides to generate simulated latitude/longitude information available to the
aircraft.

Global Positioning System (GPS) Navigation - provides a statistical model
represented as an onboard system and provides varied GPS accuracies by making
use of Local Area Augmentation System (LAAS) and Wide Area Augmentation
System (WAAS) for most applicable airspace.
DRAFT
Page 33 of 50
2.1.30.2.3 Surveillance:

Secondary Surveillance Radar - provides simulated ATC surveillance
information. The information provided by the SSR model is available for
post-simulation analysis.

Automatic Dependent Surveillance – Broadcast (ADS-B): provides data
automatically broadcast by aircraft, including latitude and longitude, velocity,
altitude, heading, identification and, optionally, intent as determined by the
avionics on board.
2.1.30.2.4 Feedback:

CNS activities are generated in response to ATC agents (ARTCC, TRACON,
Airport or Flight). The original capability of the CNS models was to perform
the requested computations and log the results. They did not feedback into
ACES and affect or alter ACES behavior. ACES 6.0 incorporates CNS 2.0
models as a plug-in and allows feedback into ACES.

As an example of CNS feedback into ACES, the Communication Activated
Maneuver (CAM) capability implemented in ACES with CNS Build 2.0 is a
feature that simulates the Air Traffic Controller to Pilot communication
during aircraft maneuvers for conflict resolution and rerouting. As part of
communication system modeling, both the Voice and VDL-2/CPDLC
communication models provide delivery of these types of maneuver messages
to the pilot as it would occur using such communications systems. With this
capability turned on, an interaction between ACES aircraft models and
communication system models occurs. As a result, a flight will implement an
ATC issued maneuver only after the maneuver message sequence (i.e.
maneuver instruction and maneuver Acknowledge) is successfully delivered
by the communication system.
2.1.30.3 Capabilities - CNS 2.0 provides the following capabilities:

Configuration of equipage of the flights. This will determine if a flight can use the
advanced CNS capabilities such as CPDLC communications, GPS navigation, and
ADS-B surveillance.

Selective simulation of CNS models by region. This allows realistic representation
of the CNS capabilities of the ATC systems in specific regions of the NAS.

Fallback to voice communication capability when CPDLC is not available

Delivery of maneuver messages to be delayed by a factor determined by
Communication model. This allows a “real world” modeling of communications,
whereby a delay is incurred due to the usage of voice or data link and waiting for
an acknowledgement from the pilot that he/she received the instructions. The use
DRAFT
Page 34 of 50
of a protocol, which ensures that the message is truly received by the pilot, might
also introduce further delay in radio frequency congested airspace.

Allowing flights to use Navigation model reported states instead of true states.
This adds realism to the simulation by allowing ACES to use data consistent with
an actual aircraft navigation system.

Allowing ATC (models) to use states reported by the Surveillance model instead of
true states. This adds realism to the simulation by allowing ACES to use data
consistent with an actual surveillance system.

Feedback to core ACES Agents, which allows them to affect ACES behavior with:
o A more complete representation of the communications traffic load required for
NAS operations,
o A distinct representation of communication message sequences to initiate
specific ACES conflict resolution and aircraft rerouting maneuvers,
o A more accurate simulation of the timing of communication messages required
for ATC to pilot communications to initiate maneuvers, and
o A more detailed output data file that provides specific messages that have a one
to one correlation between aircraft maneuvers and the communication message
data required to initiate them.
DRAFT
Page 35 of 50
2.1.31 Swappable Trajectory Generator
2.1.31.1 Description - An interface, Trajectory Generator Interface (TGI), has been built into
ACES 6.0 that enables plug-and-play of the trajectory generator used by an ACES
simulation. Previously, ACES was tightly integrated with the existing trajectory
generation engine, Multipurpose Aircraft Simulation (MPAS). MPAS is an extensive
library or collection of classes within ACES that can be activated within any activity.
Its purpose is to model aircraft trajectories based on aircraft dynamics,
arrival/departure fixes, waypoints, etc. Exclusive use of MPAS made it extremely
difficult to introduce changes into simulation models. In ACES 6.0, when a lower
fidelity and faster generator is desired, MPAS can be unplugged and replaced by
another trajectory generation engine.
2.1.31.2 Interface Design - The TGI sits between ACES Agents and Trajectory Generators
(TG) (FIGURE 1). Any trajectory generator that wishes to be invoked from ACES
needs to conform to the interface, which requires them to implement essential
methods and provide certain classes, described in the Swappable Trajectory
Generator EDD. (Ref x)
Figure 2-5: ACES Trajectory Generator Interface
To ensure maximum compatibility with future trajectory generators, wherever
possible, TG states will be exchanged between ACES Agents/Activities. In
situations where passing only state information is not sufficient (such as
international flight creation) the trajectory generator object will be passed instead.
2.1.31.3 Capabilities – The swappable trajectory generator interface provides the following
capabilities:
 Provides a clear separation between ACES and MPAS
 Provides an interface between ACES and third-party trajectory generators to allow
conforming trajectory generators to be swappable
DRAFT
Page 36 of 50
 Allows ACES to be able to use multiple trajectory generators in a simulation (one for each
category of agents). For example, ATC Agents could use one trajectory generator and
Flight Agents could use another.
 Allows users to select and configure the trajectory generator(s) to be used in a simulation
run
2.1.32 Traffic Monitor Advisor (TMA)
2.1.32.1 Description – The TMA functionality is integrated into ACES 6.0 as a plug-in. It
provides an algorithm for traffic flow management that is an alternative to the
existing ACES Traffic Flow Manager (TFM). TMA is an implementation of timebased metering (TBM) consistent with that being used by the FAA, allowing ACES
to align more closely with current and future NAS configurations. TMA and TFM are
not intended to operate on the same flights at the same time.
2.1.32.2 TMA Model - The TMA model provides efficient arrival sequence planning in the
extended terminal airspace surrounding an airport or TRACON. TMA activities are
established to act with respect to single points or boundaries that flights will cross.
These points, called meter points, may be set at runways, airports, arrival fixes,
ARTCC boundaries and sector boundaries. The various points and their related
specifications are referred to as the metering geometry.
The restriction at each meter point is expressed in terms of a maximum acceptance
rate and a minimum spacing requirement. For each cycle of execution of the TMA
model, the estimated schedule of flights is evaluated in order to determine current and
future capacity at each meter point. Capacity is communicated to all upstream meter
points as an input to the algorithm that assigns scheduled times of arrival (STAs) for
flights at each meter point. Delay that cannot be absorbed by flights as they approach
a meter point is passed up, to be applied at the next upstream meter point. While
TMA determines new schedules for flights, it depends on other agents to modify
flights to meet the new schedules.
DRAFT
Page 37 of 50
2.1.32.3 TMA and TFM: Preventing Interaction – TMA is designed to be an alternative to
TFM. In ACES 6.0, TMA and TFM do not operate on the same flights
simultaneously; therefore measures have been taken to prevent the TFM activities
from affecting the subset of flights that are being managed by TMA, as well as the
manner in which TMA will interact with the rest of ACES.
The set of flights going to a TMA destination is referred to as the TMA flight set. The
range of influence of the TMA is limited to the extent of the metering geometry and is
referred to as the TMA planning horizon. The interaction between TMA and TFM
will be implemented as follows:

Flights within a TMA destination’s flight set and within its planning horizon are
managed by TMA.

All other flights are managed by the existing TFM functionality.
The TMA model runs continuously, analyzing flights in those areas where metering
geometry is defined. However, it only affects flights when a certain level of average
delay is present.
2.1.32.4 TMA and ATC: New Sector Crossing Control - The TMA activities interact with
ATC activities just as the TFM activities do, sending the same messages to indicate
new scheduled times of arrival for the flights it controls. The TMA destination agent
receives messages from the corresponding Airport ATC agent to establish initial
conditions, including queues of arriving aircraft and current acceptance rates. As
flight schedules are modified by TMA activities, updated arrival times are sent to the
corresponding ATC agents.
TMA relies upon existing ATC capabilities to control flights at airports, arrival fixes,
and ARTCC crossings. Because TMA will also utilize sector crossings as points at
which a flight’s schedule may be controlled, the ARTCC ATC has been modified to
allow it to receive a new message that indicates a scheduled sector crossing time for a
flight under the control of TMA. In response to this message, the ARTCC ATC agent
initiates a delay maneuver, which is very similar to how it currently responds to
updated ARTCC crossing times.
DRAFT
Page 38 of 50

Capabilities - The Traffic Manager Advisor supports the following capabilities via a plugin architecture:

Recalculates Estimated Times of Arrival at a rate that is rapid enough to allow the study of
schedule dynamics resulting from ETA uncertainties.

Uses a trajectory generator, such as MPAS, to calculate Estimated Times of Arrival at
points outside the terminal area.

Uses the ACES Nodal Airport/Runway Linkage terminal model to calculate transit times
between the terminal area boundary and points within the terminal area.

Processes the flight data during initialization to determine the set of flights going to the
TMA destination.

Processes the flight data set during initialization to determine the set of flights passing
through meter points with acceptance rate restrictions (but not going to a TMA destination)
so they may be taken into account during TMA processing of flights going to TMA
destinations.

Allows flights to be dynamically added to the set of flights going to the TMA destination
or the set of flights going through a meter point but not going to the TMA destination.

Receives runway assignments from the existing Airport ATC activities and runway
assignment utilities.

Uses existing ACES logic for identifying which arrival fix each flight will use to enter the
terminal area airspace.

Includes arrival fix balancing logic, which may be enabled or disabled.

Supports the designation of an airport or TRACON as a TMA destination.

Defines the TMA metering architecture via reference to runways, airports, arrival fixes,
ARTCC boundaries and sector boundaries
Planned Capabilities
The following capabilities will be provided when software implementation is completed, with the last
piece (Enhanced Terminal Model and Enhanced Surface Traffic Limitation) by end of July 2009. The others
will be available sooner: in Spring 2009 timeframe.
2.1.33 ACES with FACET TFM
ACES responds to FACET’s TFM commands:

Miles-In-Trail
DRAFT
Page 39 of 50

Ground Delay Program

Ground Stop

Playbook Routing

Coded Departure Routing

Flow Constrained Area Avoidance
2.1.34 Enhanced AAC
2.1.34.1 Improve descent speed profile functionality.
2.1.34.2 Provide arrival flight schedules and trajectories.
2.1.34.3 Provide flight state information at future waypoints.
2.1.34.4 Allow multiple/decentralized AACs to be run at the same time: one AAC per
flight.
2.1.34.5 Allow users to introduce error into trial planned trajectories.
2.1.35 Enhanced Terminal Model (31 July 2009)
ACES will have a medium fidelity surface model with flight physics, data link, and highly-detail nodelink graph of airport surfaces.
2.1.35.1 4DOF MPAS in terminal area to runway thresholds
2.1.35.2 FMS capability in terminal area with updated ATC and TFM agents
2.1.35.3 Sequencing and Spacing of arrival and departures
2.1.35.4 Runway operating procedures
2.1.35.5 Flexible arrival & departure procedures
2.1.35.6 Dynamic waypoints
2.1.35.7 Multiplex/Super Density Operations (SDO)
2.1.35.8 Optimized integration of airspace-surface traffic
DRAFT
Page 40 of 50
2.1.36 Airport ATC
2.1.36.1 Model 4D Traffic Movement on Surface (modeling with autonomous flight
movement) (31 Jan 2009)
2.1.36.2 Determine runway takeoffs/landing and gate entries/exits
2.1.36.3 Surface 4D route/reroute planning with/without RTAs
2.1.36.4 Surface 4D route/reroute and clearance limit assignment
2.1.36.5 Surface domain representation: Gate, Ramp, Taxiway, Runway
2.1.36.6 Gate assignment and occupancy management
2.1.36.7 Ramp and Taxiway intersection transit control with gridlock resolution
2.1.36.8 Takeoff runway assignment
2.1.36.9 Runway takeoff/landing/taxi crossing transit control
2.1.36.10
Surface transit RTA conformance monitoring/alerting
2.1.36.11
Surface traffic state monitoring/alerting
2.1.36.12
Autonomous flight movement with aircraft in-trail self-separation
2.1.36.13

Acceleration/Deceleration

Nominal Roll/Stochastic speed assignment subject to speed limit
Data collection & distribution/publication
DRAFT
Page 41 of 50
2.1.37 Airport TFM
2.1.37.1 Generate TFM Landing Restrictions (31 Jan 2009)
2.1.37.2 Gate assignment and occupancy time prediction
2.1.37.3 Runway assignment prediction
2.1.37.4 Surface 4D route prediction with/without RTAs
2.1.37.5 TFM Runway takeoff/landing planning
2.1.37.6 Takeoff-time TFM Restriction generation
2.1.37.7 Data collection & distribution/publication
2.1.38 Airport ATC/TFM Utilities
2.1.38.1 Gate selector
2.1.38.2 Runway selector
2.1.38.3 Surface prescribed route assigner
2.1.38.4 Surface shortest path calculator
2.1.38.5 ATC Runway takeoff/landing planner
2.1.38.6 Data collection & distribution/publication
2.1.39 TRACON TFM
2.1.39.1 Propagate Arrival Fix Crossing Restrictions (30 April 2009)
2.1.39.2 Terminal airspace 4D route prediction with/without RTAs
2.1.39.3 Arrival/Departure fix crossing planning
2.1.39.4 Airports operating conditions forecasting
2.1.39.5 Airports runway configuration planning
2.1.39.6 Arrival fix crossing-time TFM Restriction propagation
2.1.39.7 Data collection & distribution/publication
2.1.40 TRACON ATC
2.1.40.1 Model 4D Traffic Movement through Terminal Airspace (30 April 2009)
2.1.40.2 Determine Airport Landing/Departure Fix Crossings
DRAFT
Page 42 of 50
2.1.40.3 Terminal airspace 4D route/reroute planning with/without RTAs
2.1.40.4 Terminal airspace 4D route/reroute and clearance limit assignment
2.1.40.5 Landing runway assignment
2.1.40.6 Airspace fix transit control
2.1.40.7 Airspace transit RTA conformance monitoring/alerting
2.1.40.8 Airspace traffic state monitoring/alerting
2.1.40.9 Data collection & distribution/publication
2.1.41 Flight
2.1.41.1 Reconstitute MPAS for Terminal/En Route Airspace (30 April 2009)
2.1.41.2 MPAS Improvements





Make stable at aircraft minimum speed
Model short flights and low altitude tower en route flights
Integrate FMS generated vertical trajectories to meet restrictions
Support holding patterns
Pluggable
2.1.41.3 Flight Management System (FMS)




Generate vertical trajectories from route, time, speed and altitude
restrictions
Model vertical profiles for jet, turboprop and piston aircraft
Interface with surface movement model at the runway threshold
Pluggable
2.1.42 Closely-Spaced Parallel Arrivals (CSPA)
2.1.42.1 TRACON TFM

Arrival flight coupling prediction

Terminal airspace coupled 4D route prediction

Data collection & distribution/publication
2.1.42.2 TRACON ATC

Arrival flight coupling

Terminal airspace coupled 4D route planning
DRAFT
Page 43 of 50

Terminal airspace coupled 4D route assignment

Airspace transit coupling conformance monitoring/alerting

Data collection & distribution/publication
DRAFT
Page 44 of 50
APPENDIX A: BADA UPDATED AIRCRAFT MODELS
Base set of 37 independent aircraft models:
A300
A310
A320
A340
B707
B727
B73A
A300, A306, A30B
A310
A319, A320, A321
A340, EA34
B701, B703, B707, E135, K35E
B721, B722, B727, B728, B72Q
A333, A343, A346, AC58, AJ25, B272, B40, B60, B732, B73A, B73Q,
BA41, DCP, T72Q
B73B B733, B734, B735, B73B, B73J, B73S
B73C B712, B737, B738, B739, B73C, MD90
B74A A124, B741, B742, B743, B747, B74A
B74B B744, B74B
B757 B752, B753, B757
B767 B762, B763, B764, B767
B777 B772, B777, B7X7
BA46 BA46
BE20 AC50, AC60, AC69, AC6T, AC90, AC95, AN26, AT42, AT43, AT72,
B190, B20, B300, B350, B400, B90L, B9L, BE02, BE10, BE20, BE30,
BE90, BE99, BE9F, BE9L, BE9T, C2, C425, C441, CE55, CJ, CV44,
CV58, D228, D328, DC6, DH8A, DH8B, DH8C, DH8D, DH8, DHC6,
DHC8, E110, E120, F27, FK27, JS31, JS32, JS41, MU2, P180, P46T, P68,
PA42, PA46, PAY1, PAY2, PAY3, PAY4, PAYE, PC12, SC7, SF34,
SH30, SH33, SH36, SW2B, SW2, SW3B, SW3, SW4A, SW4, SWS,
TBM7, TBN7
C130 C130, C160, CVLT, L188, P3
C421 A36, AA5, AC11, AEST, B36T, BE18, BE19, BE23, BE24, BE33, BE35,
BE36, BE50, BE55, BE58, BE60, BE65, BE76, BE77, BE80, BE8, BE95,
C150, C152, C172, C177, C180, C182, C185, C206, C208, C210, C301,
C303, C310, C320, C337, C340, C401, C402, C404, C414, C421, C72N,
C72R, C82R, CV24, CVLP, DA40, DC3, GA20, GA7, LC30, LNC4,
M020, M20C, M20F, M20, M20J, M20K, M20M, M20P, M20R, M20T,
MO20, P210, P28A, P28B, P28, P28R, P28T, P32A, P32, P32R, P32T,
PA23, PA24, PA27, PA28, PA30, PA31, PA32, PA34, PA38, PA44, PA60,
PARO, PASE, PAZT, SR20, SR22, T37, TB20, TOBA, TRIN
C550 C500, C501, C525, C526, C550, C551, MU30, MU3
C560 C560, C56X
CARJ CARJ, CRJ1, CRJ2, CRJ7, CRJ, L29B
DRAFT
Page 45 of 50
CL60
DC10
DC8
DC9
F100
F28
F900
FA10
FA20
FA50
H25B
L101
LJ35
MD1
1
MD8
0
ASTR, BE40, C25A, C750, CL60, CL64, CR2, E134, E145, F70, FK70,
G159, G2, G3, G4, G5, GALX, GL4, GLEX, GLF2, GLF3, GLF4, GLF5,
GLFA, GLF, GULF, HS25, J328, JCOM, LR24, S601, SB20, SBR1, SBR2,
SBR
DC10, MD10
C141, DC86, DC87, DC8, DC8Q
B717, DC91, DC92, DC93, DC94, DC95, DC9, DC9Q, MD81, MD82,
MD83, MD87, MD88
F100, FK10
F28
DA90, F900, F90, FA90
FA10
DA10, DA20, F2TH, FA20
DA50, F50, FA50
H125, H25A, H25B, H25C, H25
L101
C650, C65, CE52, LJ23, LJ24, LJ25, LJ28, LJ31, LJ35, LJ36, LJ45, LJ50,
LJ55, LJ60, LJ6, LR25, LR31, LR35, LR36, LR55, LR60, PRM1, STAR,
WW23, WW24
MD11
MD80
1. Four new aircraft models are:
RJ85
BAe 146
B462
-
BAe 146-200
A332
-
Airbus A330-200
B773
-
Boeing 777-300
2. Updated sublist in MS Excel spreadsheet:
sublist.csv
DRAFT
Page 46 of 50
APPENDIX B : ACRONYMS
AAC
Advanced Airspace Concepts
A/C
Aircraft
AAL
American Airlines
AAR
Airport Arrival Rate, Arrival Acceptance Rate, Airport Acceptance Rate
ACP
Auto-Configure Properties
AATT Advanced Air Transportation Technologies
ACES Airspace Concept Evaluation System
ADS-B Automatic Dependent Surveillance-Broadcast
AER
Agent En Route
AFAST Active Final Approach Spacing Tool
AGL
Above Ground Level
AOC
Airline Operations Center
AOP
Autonomous Operations Planner
AP
Action Plan
API
Application Programmer’s Interface
APMC Ames Project Management Council
ARC
(NASA) Ames Research Center
ARINC Aeronautical Radio Inc.
ARMD Aeronautics Research Mission Directorate
ARTCC Air Route Traffic Control Center
AS
Airspace Systems
ASDO Airspace Dynamic Operations
ASEB Aeronautics and Space Engineering Board
ASPO Airspace Systems Program Office
AT
Air Traffic
ATAC Aerospace Technology Advisory Committee
ATC
Air Traffic Control
ATCSCC
Air Traffic Control System Command Center
ATCT Air Traffic Control Tower
ATL
The William B. Hartsfield Atlanta Int'l Airport
ATM
Air Traffic Management
ATMESC
Air Traffic Management Executive Steering Committee
ATMSDI
Air Traffic Management System Development and Integration
ATS
Air Traffic Services
ATSP Air Traffic Service Provider
BADA Base of Aircraft Data
BTS
CAP
Collaborative Arrival Planning
CARP
Continuity and Recovery Plan;
Constrained Airspace Reroute Planner
CCI
Consolidated Contracting Initiative
CD&R
Conflict Detection & Resolution
CDRL Contract Data Requirements List
CDTI Cockpit Detection and Resolution
CE
Concept Elements
DRAFT
Page 47 of 50
CENA Centre d'Etudes de la Navigation Aérienne
CNS
Communication, Navigation, Surveillance
COA
Continental Airlines
Con Ops Concept of Operations
CONUS Continental US
CPDLC Controller-Pilot Data Link Communication
CRM
Continuous Risk Management
CS
Civil Servant
CSC
Computer Sciences Corporation
CSPA Closely Spaced Parallel Arrivals
CSV
CTAS Center TRACON (Terminal Radar Approach Control) Automation System
CTO
Contract Task Order
CTOD Contract Task Order Deliverable
CVSRF Crew Vehicle Systems Research Facility
D2
Direct-To
DAC
Dynamic Airspace Configuration
DAG
Distributed Air/Ground
DAG-TM
Distributed Air/Ground Traffic Management
DFW
Dallas/Fort Worth International Airport
DLR
Deutsches Zentrum fur Lüft- un Raumfahrt
DOD
Department of Defense
DOF
Degrees of Freedom
DOM Document Object Model
DOT
Department of Transportation
DROMS Dynamic Runway Occupancy Measurement System
DSC
Dynamic Sector Capacity
DSR
Display System Replace
DST
Decision Support Tool
DTW Detroit Metropolitan Airport
ECADS Environmental Compatibility Arrival, Departure
EDA
Enroute and Descent Advisor
EDP
Expedite Departure Path
EDX
En Route Data Exchange
EIA
Electronic Industries Alliance
ETA
Estimated Time of Arrival
ETMS Enhanced Traffic Management System
FAA
Federal Aviation Administration
FACET Future ATM Concepts Evaluation Tool
FAST Final Approach Spacing Tool
FFC
FutureFlight Central
FFP
Firm Fixed Price
FFP1
Free Flight Phase 1
FFP2
Free Flight Phase 2
FFPO Free Flight Program Office
FFRDC Federally Funded R&D Development Center
DRAFT
FLS
FLTK
FMS
FOM
FST
FY
GAO
GDP
GoM
GOTS
GPS
GRC
GSFC
GUI
HITS
HQ
IAC
IAD
IAI
IAIMT
IAIPT
IAR
IDIQ
IEEE
IFR
INS
IV&V
JRC
LAAS
LaRC
LIDAR
LDC
Page 48 of 50
First Lost of Separation
Fast-light Tool Kit
Flight Management System
Flight Object Model
Flight Safety Technologies
Fiscal Year
General Accounting Office
Ground Delay Program
Gulf of Mexico
Government Off-the-Shelf
Global Positioning System
Glenn Research Center
Goddard Space Flight Center
Graphical User Interface
Helicopter In-flight Tracking System
Headquarters
Instantaneous Aircraft Count
Washington Dulles
Intelligent Automation Inc.
Inter-Agency Integrated Management Team
Interagency Integrated Product Team
Independent Annual Review
Indefinite Delivery/Indefinite Quantity
Institute of Electrical and Electronics Engineers
Inertial Navigation System
Independent Verification and Validation
Joint Resources Council (FAA)
Local Area Augmentation System
(NASA) Langley Research Center
Light Detection and Ranging
Local Data Collection
Mach-CAS
McTMA Multi-Center TMA
MEM Memphis Airport
MF
MIT
Miles-in-Trail, i.e., a TFM restriction that increases the distance between
successive aircraft, the number of miles required between aircraft departing an
airport, over a fix, at an altitude, thru a sector, or route specific.
MoU
Memorandum of Understanding
M & S Modeling and Simulation
MPAS Multi-Purpose Aircraft Simulation
MS
Milestone
NARI National Aviation Research Institute
NAS
National Airspace System
DRAFT
Page 49 of 50
NASA National Aeronautics and Space Administration
NExTNAS
NASA Exploratory Technologies for the National
NLR
National Lucht- en Ruimtevaartlaboratorium
NMI
Nautical Miles (also nm)
NOAA National Oceanic and Atmospheric Administration
NPG
NASA Procedures and Guidelines
NRA
NASA Research Announcement
NRC
National Research Council
NTx
North Texas Metroplex
OMT
Object Model Template
OO
Object Oriented
OOD
Object Oriented Design
OCD
Operational Concept Description
OOOI Out-Off-On-InPCA Program Commitment Agreement
PCA
Point of closest approach
pFAST Passive Final Approach Spacing Tool
PRM
Parallel Runway Monitor
R & D Research and Development
RE&D Research Engineering and Development (FAA)
REACT Rogue Evaluation and Coordination Tool
RM
Regional Metering
RTA
RTCA "RTCA, Inc. (formerly Radio Technical Committee on Aeronautics)"
RUC
SA
Separation Assurance
SAIC Science Applications International Corp.
SB
Small Business
SBIR
Small Business Innovative Research
SCATS Scientific Consulting and Automated Technological Services
SSDD System/Subsystem Design Description
SDD
Software Design Document
SDI
System Development and Integration
SDO
Super Density Operations
SF
Safe Flight
SI
Simulation Integration
SM
Simulation Manager
SMA
Surface Movement Advisor
SMS
Surface Management System
SOO
Statement of Objectives
SOW
Statement of Work
SP
Sub-project
SRC
System Resources Corporation
SSDD Systems/Subsystems Design Description
SSR
Secondary Surveillance Radar
SSS
Systems/Subsystems Specification
STLE
Surface Traffic Limitation Enhancements
DRAFT
STA
SUA
SUM
SW
SWEPT
TCAS
TCP/IP
TFM
Page 50 of 50
Scheduled Time of Arrival
Special Use Airspace
Software User Manual
Software
System-wide Evaluation and Planning Tool
Traffic Collision and Avoidance System
Transmission Control Protocol/Internet Protocol
Traffic Flow Management, i.e., balancing of demand for ATC with NAS
system capabilities
TGI
Trajectory Generator Interface
TGIR Turning Goals Into Reality
TMA
Traffic Management Advisor
TMA-MC
Traffic Management Advisor -Multi-Center
TMC
Traffic Management Coordinator
TMS
Traffic Management System
TMU
Traffic Management Unit
TPSU
Trajectory Prediction & System Uncertainty
TRACONTerminal Radar Approach Control
TRDCM Taxi Route Detection and Conformance Monitoring System
TRL
Technology Readiness Level
UPS
United Parcel Service
UPS
User Preferred Routing
UPT
User Preferred Trajectory
URET User Request Evaluation Tool
V&V
Verification and Validation
VAM Virtual Airspace Simulation Technology
VDL
Voice Data Link
VFR
VOR/DME
VSSCT Visualization/Scenario/Simulation Control
WAAS Wide Area Augmentation System
WebRMS
Web Risk Management System
ZBW
Boston Center
ZDC
Washington
ZFW
Fort Worth Air Route Traffic Control Center
ZNY
New York