George Mason University
| | |
| | |
| |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 |
TABLE OF CONTENTS
1 INTRODUCTION 5
2 Modeling Overview 5
2.1 Current Functionality 7
2.1.1 Aircraft 7
2.1.2 ATCSCC 7
2.1.3 En Route 7
2.1.4 En Route Congestion 8
2.1.5 En Route Conflict Detection and Resolution 9
2.1.6 Terminal 10
2.1.7 Terminal Area Modeling 10
2.1.8 Separation at the Arrival Meter Fix 14
2.1.9 Arrival Fix Rerouting 15
2.1.10 Overlapping TRACONS 15
2.1.11 Airport 15
2.1.12 Dynamic Airport Arrival and Departure Capacities 16
2.1.13 Surface Traffic Limitations 16
2.1.14 AOC 17
2.1.15 Airline Operations Center Cancellations and Delays 17
2.1.16 Traffic Demand 18
2.1.17 Weather 18
2.1.18 Constrained Airspace Rerouting Planner (CARP) 18
2.1.19 Rerouting in En Route CD&R for Separation Assurance 20
2.1.20 Airspace 21
2.1.21 Advanced Airspace Concept 21
2.1.22 Uncertainty Capability for CNS 23
2.1.23 International Flights 23
2.1.24 International Overflights 23
2.1.25 Tail Tracking 24
2.1.26 Variable Descent Profile 24
2.1.27 Sector Grid Redesign 25
2.1.28 BADA 3.6 25
2.1.29 Visualization/Scenario/Simulation Control 25
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 26
2.2.2 ACES with FACET TFM 26
2.2.3 Capability to Change Look-ahead Time for Re-sectorization 27
2.2.4 Climb and Descent Profile 27
2.2.8 Enhanced Terminal Model 27
Appendix A: BADA Updated aircraft models 28
APPENDIX B : ACRONYMS 30
LIST OF ILLUSTRATIONS
FIGURE 2-1 ACES SIMPLIFIED TERMINAL AIRSPACE NETWORK 11
Figure 2-2 ACES Multiple Airport Simplified Terminal Airspace Network 11
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
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.
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.
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.
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.
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 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.
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).
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.
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.
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
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.
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 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.
7 Terminal Area Modeling
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.
[pic]
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.
[pic]
Figure 2-2 ACES Multiple Airport Simplified Terminal Airspace Network
2 Link-Node Model
ACES 6.0 incorporates the Link-Node model to enable more complex terminal scenario analyses. This enhanced design adheres in general to the existing ACES 4.6 agent-based concept, subject to extensions and adaptations, and provides compatibility with NASA’s separately-developed ACES-X to the maximum extent possible. This enhanced design implements Command and Control (C2 or C2) and Plant 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.
[pic]
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.
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
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.
o For details on Meter Fix and Runway assignments, refer to System/Subsystem Design Description (SSDD) / Software Design Document (SDD) – Appendix A.3 – Terminal Area Operations
4 Individual Runway Identification and Aircraft Spacing Matrices (Runway Aircraft Spacing)
ACES provides the capability to assign a takeoff or landing time by individual runway to a specific flight in conformance with airport operating procedures, runway configurations and airport operating conditions:
o Definition of active runway configurations and eligible arrival or departure operations by operating condition for an airport.
o Definition of pair-wise aircraft spacing rules (defined by minimum separation requirements by aircraft class and buffer matrices) by runway configuration and airport operating condition.
o Automatic assignment of takeoff and landing time in conformance with spacing rules and runway assignments.
o User selection of default spacing rules for selected generic runway configurations and VFR and IFR airport operation conditions (the spacing rules automatically override any acceptance rate limits defined for the airport).
o User specification for an airport of active runway configurations and eligible arrival or departure operations by operating condition and of pair-wise aircraft spacing rules by runway configuration and airport operation condition.
o For details on Runway Aircraft Spacing, refer to System/Subsystem Design Description (SSDD) / Software Design Document (SDD) – Appendix A.3 – Terminal Area Operations
5 Runway System Departure-Arrival Mixing
ACES provides the automatic capability to re-sequence flights so as to interleave takeoffs and landings where warranted to prevent inappropriate batching of arrivals or departures. For details on Runway System departure-arrival mixing, refer to System/Subsystem Design Description (SSDD) / Software Design Document (SDD) – Appendix A.3 – Terminal Area Operations.
6 Airport TFM Planning
ACES enables the Airport TFM model, for special runway-modeled airports, to project takeoff and landing times and delays according to pair-wise aircraft separation rules, a combination of pair-wise aircraft separation rules and acceptance rates, or manual acceptance rates. This feature enables user selection of the following TFM planning modes for a special runway-modeled airport:
Basic Airport TFM Planning
This feature enables the Airport TFM model to determine projected takeoff and landing times according to pair-wise aircraft separation rules for individual runway operations and issue arrival flight TFM restrictions.
7 Airport ATC Runway Operations Assignment
ACES enables the Airport ATC model to determine actual takeoff and landing times according to pair-wise aircraft separation rules for individual runway operations (not according to acceptance rates).
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.
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.
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.
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 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.
12 Dynamic Airport Arrival and Departure Capacities
ACES processes runway system capacity input data for each airport specifying VFR and IFR arrival, departure and total acceptance rate limits. These six values are specified for each airport. Default acceptance rate limits for all airports are defined in a comma separated value (CSV) static data file that is read at simulation startup.
ACES allows users to define an unlimited number of additional airport operating conditions and a set of three acceptance rate limits (arrival, departure and total) for each such operating condition. Each airport operating condition and associated set of acceptance rate limits is triggered by time. The user would optionally access a file to specify the airport capacity as VFR, IFR, or user-defined arrival, departure, and total acceptance rate limits.
The User-Adjustable Runway System Capacities capability supports the following capability:
• The scenario capability provides the ability to script a scenario, introducing changes in capacities of airspace or airports to create desired traffic flow management situations. Refer to the ACES Software User Manual to configure the scenario file.
13 Surface Traffic Limitations Enhancement (STLE)
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 Surface Modeling
1 Basic STL - The original ACES STL function provides a very basic capability to account for surface congestion constraints on traffic operations. The basic ACES STL functionality simultaneously models different airports at either of two levels of fidelity per user definition:
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.
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.
1 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.
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.
5 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.
6 Capabilities
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
• Enables user-defined activation of the Surface Traffic Limit function on an individual airport or all-airport selection basis
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
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.
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
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.
1. 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.
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.
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.
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.
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.
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.
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.
• 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.
20 Airspace
ACES utilizes the current NAS airspace. The CONUS ARTCC facility / sector boundaries, TRACON meter fixes, airport locations, and waypoints define the airspace.
21 Advanced Airspace Concept
[Note: Advanced Airspace Concept is currently an external/companion release for ACES Build 5.0. AAC will be formally part of Build 6.0 and this document will be updated to reflect any updates to AAC in the meantime]
The purpose of the AAC model is to provide the user with a programmable CD&R capability. The AAC model interacts with a user-supplied CD&R module. The user-supplied CD&R module receives conflict data from the AAC model and submits trial resolution plans. The AAC model then provides data resulting from the hypothetical implementation of the trial plan. The user-supplied CD&R module may submit any number of trial plans, in series, as it searches for the desired resolution maneuver. This process continues until the user-supplied CD&R module arrives at a decision. It may choose a resolution from one of the trial plans it has submitted, it may choose yet a different resolution maneuver, or it may choose not to implement a resolution. The AAC model provides all of the facilities required for a programmable, advanced CD&R module. The relevant capabilities are given below.
• All predicted conflicts are output, including the following information:
1. time at which the prediction is made,
2. flight ID and aircraft type of the two aircraft,
3. maneuver status of the two aircraft at time of prediction,
4. top of descent and top of climb data for the two aircraft at time of prediction,
5. flight status of the two aircraft (i.e., climb, descent, or cruise) at time of prediction,
6. time and location of predicted PCA (point of closest approach) and first loss of separation (FLS) at time of prediction,
7. wind vector at time and location of the predicted PCA,
8. state (position and velocity) of the two aircraft at time of prediction, time of predicted first loss of separation, and time of predicted PCA,[?]
9. resolution information (e.g., was a resolution maneuver performed? If so, which aircraft performed the maneuver?), and
10. time and location of actual violations that occurred.
• pass as output the predicted conflict data to the AAC concept module at the time at which the conflict is predicted:
1. time at which the prediction is made (i.e., current time),
2. flight ID and aircraft type of the two aircraft,
3. maneuver status of the two aircraft at time of prediction,
4. top of descent and top of climb data for the two aircraft at time of prediction,
5. flight status of the two aircraft (i.e., climb, descent, or cruise) at time of prediction,
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.
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:
• 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.
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.
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.
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.
• 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).
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.
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 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
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.
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.
• the ability to run the simulation without the plan view display (batch mode) while maintaining simulation control and scenario capabilities.
30 Communication, Navigation, and Surveillance (CNS)
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 Functionality - ACES CNS functionality includes:
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 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.
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.
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.
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 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.
32 Swappable Trajectory Generator
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 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)
[pic]
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.
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
• 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
33 Traffic Monitor Advisor (TMA)
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 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.
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.
8 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.
10 Capabilities - The Traffic Manager Advisor supports the following capabilities via a plug-in architecture:
11 Recalculates Estimated Times of Arrival at a rate that is rapid enough to allow the study of schedule dynamics resulting from ETA uncertainties.
12 Uses a trajectory generator, such as MPAS, to calculate Estimated Times of Arrival at points outside the terminal area.
13 Uses the ACES Nodal Airport/Runway Linkage terminal model to calculate transit times between the terminal area boundary and points within the terminal area.
14 Processes the flight data during initialization to determine the set of flights going to the TMA destination.
15 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.
16 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.
17 Receives runway assignments from the existing Airport ATC activities and runway assignment utilities.
18 Uses existing ACES logic for identifying which arrival fix each flight will use to enter the terminal area airspace.
19 Includes arrival fix balancing logic, which may be enabled or disabled.
20 Supports the designation of an airport or TRACON as a TMA destination.
21 Defines the TMA metering architecture via reference to runways, airports, arrival fixes, ARTCC boundaries and sector boundaries
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.
1 ACES with FACET TFM
ACES responds to FACET’s TFM commands:
• Miles-In-Trail
• Ground Delay Program
• Ground Stop
• Playbook Routing
• Coded Departure Routing
• Flow Constrained Area Avoidance
2 Enhanced AAC
1 Improve descent speed profile functionality.
2 Provide arrival flight schedules and trajectories.
3 Provide flight state information at future waypoints.
4 Allow multiple/decentralized AACs to be run at the same time: one AAC per flight.
5 Allow users to introduce error into trial planned trajectories.
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.
1 4DOF MPAS in terminal area to runway thresholds
2 FMS capability in terminal area with updated ATC and TFM agents
3 Sequencing and Spacing of arrival and departures
4 Runway operating procedures
5 Flexible arrival & departure procedures
6 Dynamic waypoints
7 Multiplex/Super Density Operations (SDO)
8 Optimized integration of airspace-surface traffic
4 Airport ATC
1 Model 4D Traffic Movement on Surface (modeling with autonomous flight movement) (31 Jan 2009)
2 Determine runway takeoffs/landing and gate entries/exits
3 Surface 4D route/reroute planning with/without RTAs
4 Surface 4D route/reroute and clearance limit assignment
5 Surface domain representation: Gate, Ramp, Taxiway, Runway
6 Gate assignment and occupancy management
7 Ramp and Taxiway intersection transit control with gridlock resolution
8 Takeoff runway assignment
9 Runway takeoff/landing/taxi crossing transit control
10 Surface transit RTA conformance monitoring/alerting
11 Surface traffic state monitoring/alerting
12 Autonomous flight movement with aircraft in-trail self-separation
• Acceleration/Deceleration
• Nominal Roll/Stochastic speed assignment subject to speed limit
13 Data collection & distribution/publication
5 Airport TFM
1 Generate TFM Landing Restrictions (31 Jan 2009)
2 Gate assignment and occupancy time prediction
3 Runway assignment prediction
4 Surface 4D route prediction with/without RTAs
5 TFM Runway takeoff/landing planning
6 Takeoff-time TFM Restriction generation
7 Data collection & distribution/publication
6 Airport ATC/TFM Utilities
1 Gate selector
2 Runway selector
3 Surface prescribed route assigner
4 Surface shortest path calculator
5 ATC Runway takeoff/landing planner
6 Data collection & distribution/publication
7 TRACON TFM
1 Propagate Arrival Fix Crossing Restrictions (30 April 2009)
2 Terminal airspace 4D route prediction with/without RTAs
3 Arrival/Departure fix crossing planning
4 Airports operating conditions forecasting
5 Airports runway configuration planning
6 Arrival fix crossing-time TFM Restriction propagation
7 Data collection & distribution/publication
8 TRACON ATC
1 Model 4D Traffic Movement through Terminal Airspace (30 April 2009)
2 Determine Airport Landing/Departure Fix Crossings
3 Terminal airspace 4D route/reroute planning with/without RTAs
4 Terminal airspace 4D route/reroute and clearance limit assignment
5 Landing runway assignment
6 Airspace fix transit control
7 Airspace transit RTA conformance monitoring/alerting
8 Airspace traffic state monitoring/alerting
9 Data collection & distribution/publication
9 Flight
1 Reconstitute MPAS for Terminal/En Route Airspace (30 April 2009)
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
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
10 Closely-Spaced Parallel Arrivals (CSPA)
1 TRACON TFM
• Arrival flight coupling prediction
• Terminal airspace coupled 4D route prediction
• Data collection & distribution/publication
2 TRACON ATC
• Arrival flight coupling
• Terminal airspace coupled 4D route planning
• Terminal airspace coupled 4D route assignment
• Airspace transit coupling conformance monitoring/alerting
• Data collection & distribution/publication
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 |
|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 |
|MD11 |MD11 |
|MD80 |MD80 |
1. Four new aircraft models are:
RJ85 - BAe 146
B462 - BAe 146-200
A332 - Airbus A330-200
B773 - Boeing 777-300
2. Updated sublist in MS Excel spreadsheet:
sublist.csv
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
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
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
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
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
-----------------------
Figure 1 - ACES Model Overview
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- current proposed position statement
- 2019 form 1099 g
- quarterly contribution return and report
- 21 internal revenue service department of the treasury
- how to get proof of social security numbers or
- new hire reporting for employment development department
- employment development department
- welcome to the employment development
- employment development department customer
- appointments
Related searches
- george mason university mason core
- george mason core requirements
- george mason university graduate school
- george mason university information technology
- george mason core courses
- george mason core
- george mason university library catalog
- george mason university course catalog
- george mason university course schedule
- george mason university admissions requirements
- george mason university reputation
- george mason university sat requirements