Airspace Concept Evaluation System (ACES) Capabilities
DRAFT 510736277.doc
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 ............................................................................... 122.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 ........... 错误~未定义书签。26
2. 1.31 Swappable Trajectory Generator ................................ 错误~未定义书签。27
2.1.32 Traffic Monitor Advisor ............................................. 错误~未定义书签。27
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.......................................... 错误~未定义书签。27
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 Page 5 of 50
1 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-the-
NAS 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 SetAirport CapacitiesStatic Data
Origin/DestinationAirport AdaptationAirport StatesDataAircraft TypeVFRCenter/SectorTrajectoryACESIFRAdaptation DataFunctionalityVFRCruise Alt & SpeedRUCVFRGeneric/EnhancedVFRWindsSector CapacitiesDeparture TimeAirport Model
Winds On/Off
TFMDelay ManeuversCenter ACenter BTFMACES Simulation
TFMTRACONDeparture Meter FixSeparationATCATCTRACONATCTFMAirline OperationsATCControl40 nmTFMATCAirportRerouting40 nmATCSurface TrafficAirportLimitations
Conflict Detection &Resoluation
Local Data Collection
Center HandoffAirport AcceptanceFlight Time DataAircraft StateMessageRate MessageMessageMessage
ACES Outputs
Figure 1 - ACES Model Overview
DRAFT Page 8 of 50
2.1 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 Page 9 of 50
2.1.3 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:
, 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).
2.1.4 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.
, Flight Model: Conduct Maneuver
2.1.5 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:
, 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/en-
route meter fix.
2.1.7 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/near-by/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 LinkageRunway LinkageNodal Airport LinkageRunway 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 2maximum extent possible. This enhanced design implements Command and Control (C 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
Non-Runway Non-Runway Non-Runway Runway SystemRunway SystemRunway System
Taxiway Taxiway Taxiway with crossing & with crossing & with crossing &
NetworkNetworkNetworkadjoining taxiwaysadjoining taxiwaysadjoining taxiwaysGate & RampGate & RampGate & Ramp
Each link is assigned a domain:Each link is assigned a domain:
Gate-Ramp domain,Gate-Ramp domain,
Taxiway domain, orTaxiway domain, orSpecial Special Special Runway System domainRunway System domainPurpose Purpose Purpose Areas (parking, Areas (parking, Areas (parking, deicing, other)deicing, other)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 nd airport operating conditions: a
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.
7 Airport ATC Runway Operations Assignment
DRAFT Page 18 of 50
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 Page 19 of 50
2.1.9 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, eparture, and total acceptance rate limits. d
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 real-time 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,1
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 Page 28 of 50
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. 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 plug-
ins 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 time-
based 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 plug-
in 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
2.2 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.2.1 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.2.2 Enhanced AAC
2.2.2.1 Improve descent speed profile functionality.
2.2.2.2 Provide arrival flight schedules and trajectories.
2.2.2.3 Provide flight state information at future waypoints.
2.2.2.4 Allow multiple/decentralized AACs to be run at the same time: one AAC per
flight.
2.2.2.5 Allow users to introduce error into trial planned trajectories. 2.2.3 Enhanced Terminal Model (31 July 2009)
ACES will have a medium fidelity surface model with flight physics, data link, and highly-detail node-
link graph of airport surfaces.
2.2.3.1 4DOF MPAS in terminal area to runway thresholds
2.2.3.2 FMS capability in terminal area with updated ATC and TFM agents
2.2.3.3 Sequencing and Spacing of arrival and departures
2.2.3.4 Runway operating procedures
2.2.3.5 Flexible arrival & departure procedures
2.2.3.6 Dynamic waypoints
2.2.3.7 Multiplex/Super Density Operations (SDO)
2.2.3.8 Optimized integration of airspace-surface traffic
DRAFT Page 40 of 50
2.2.4 Airport ATC
2.2.4.1 Model 4D Traffic Movement on Surface (modeling with autonomous flight
movement) (31 Jan 2009)
2.2.4.2 Determine runway takeoffs/landing and gate entries/exits 2.2.4.3 Surface 4D route/reroute planning with/without RTAs
2.2.4.4 Surface 4D route/reroute and clearance limit assignment 2.2.4.5 Surface domain representation: Gate, Ramp, Taxiway, Runway 2.2.4.6 Gate assignment and occupancy management
2.2.4.7 Ramp and Taxiway intersection transit control with gridlock resolution 2.2.4.8 Takeoff runway assignment
2.2.4.9 Runway takeoff/landing/taxi crossing transit control 2.2.4.10 Surface transit RTA conformance monitoring/alerting
2.2.4.11 Surface traffic state monitoring/alerting
2.2.4.12 Autonomous flight movement with aircraft in-trail self-separation
, Acceleration/Deceleration
, Nominal Roll/Stochastic speed assignment subject to speed limit 2.2.4.13 Data collection & distribution/publication
DRAFT Page 41 of 50
2.2.5 Airport TFM
2.2.5.1 Generate TFM Landing Restrictions (31 Jan 2009)
2.2.5.2 Gate assignment and occupancy time prediction
2.2.5.3 Runway assignment prediction
2.2.5.4 Surface 4D route prediction with/without RTAs
2.2.5.5 TFM Runway takeoff/landing planning
2.2.5.6 Takeoff-time TFM Restriction generation
2.2.5.7 Data collection & distribution/publication 2.2.6 Airport ATC/TFM Utilities
2.2.6.1 Gate selector
2.2.6.2 Runway selector
2.2.6.3 Surface prescribed route assigner
2.2.6.4 Surface shortest path calculator
2.2.6.5 ATC Runway takeoff/landing planner
2.2.6.6 Data collection & distribution/publication 2.2.7 TRACON TFM
2.2.7.1 Propagate Arrival Fix Crossing Restrictions (30 April 2009)
2.2.7.2 Terminal airspace 4D route prediction with/without RTAs
2.2.7.3 Arrival/Departure fix crossing planning
2.2.7.4 Airports operating conditions forecasting
2.2.7.5 Airports runway configuration planning
2.2.7.6 Arrival fix crossing-time TFM Restriction propagation
2.2.7.7 Data collection & distribution/publication 2.2.8 TRACON ATC
2.2.8.1 Model 4D Traffic Movement through Terminal Airspace (30 April 2009)
2.2.8.2 Determine Airport Landing/Departure Fix Crossings
DRAFT Page 42 of 50
2.2.8.3 Terminal airspace 4D route/reroute planning with/without RTAs
2.2.8.4 Terminal airspace 4D route/reroute and clearance limit assignment
2.2.8.5 Landing runway assignment
2.2.8.6 Airspace fix transit control
2.2.8.7 Airspace transit RTA conformance monitoring/alerting 2.2.8.8 Airspace traffic state monitoring/alerting 2.2.8.9 Data collection & distribution/publication
2.2.9 Flight
2.2.9.1 Reconstitute MPAS for Terminal/En Route Airspace (30 April 2009)
2.2.9.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.2.9.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.2.10 Closely-Spaced Parallel Arrivals (CSPA)
2.2.10.1 TRACON TFM
, Arrival flight coupling prediction
, Terminal airspace coupled 4D route prediction
, Data collection & distribution/publication
2.2.10.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 A300, A306, A30B
A310 A310
A320 A319, A320, A321
A340 A340, EA34
B707 B701, B703, B707, E135, K35E
B727 B721, B722, B727, B728, B72Q
B73A 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 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 DC10, MD10
DC8 C141, DC86, DC87, DC8, DC8Q
DC9 B717, DC91, DC92, DC93, DC94, DC95, DC9, DC9Q, MD81, MD82,
MD83, MD87, MD88
F100 F100, FK10
F28 F28
F900 DA90, F900, F90, FA90
FA10 FA10
FA20 DA10, DA20, F2TH, FA20
FA50 DA50, F50, FA50
H25B H125, H25A, H25B, H25C, H25
L101 L101
LJ35 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
MD1MD11
1
MD8MD80
0
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 Page 48 of 50
FLS First Lost of Separation
FLTK Fast-light Tool Kit
FMS Flight Management System
FOM Flight Object Model
FST Flight Safety Technologies
FY Fiscal Year
GAO General Accounting Office
GDP Ground Delay Program
GoM Gulf of Mexico
GOTS Government Off-the-Shelf
GPS Global Positioning System
GRC Glenn Research Center
GSFC Goddard Space Flight Center
GUI Graphical User Interface
HITS Helicopter In-flight Tracking System HQ Headquarters
IAC Instantaneous Aircraft Count
IAD Washington Dulles
IAI Intelligent Automation Inc.
IAIMT Inter-Agency Integrated Management Team IAIPT Interagency Integrated Product Team IAR Independent Annual Review
IDIQ Indefinite Delivery/Indefinite Quantity IEEE Institute of Electrical and Electronics Engineers
IFR
INS Inertial Navigation System
IV&V Independent Verification and Validation JRC Joint Resources Council (FAA) LAAS Local Area Augmentation System LaRC (NASA) Langley Research Center LIDAR Light Detection and Ranging LDC 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 Page 50 of 50
STA Scheduled Time of Arrival
SUA Special Use Airspace
SUM Software User Manual
SW Software
SWEPT System-wide Evaluation and Planning Tool TCAS Traffic Collision and Avoidance System TCP/IP Transmission Control Protocol/Internet Protocol TFM 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