Airspace Concept Evaluation System (aces) Capabilities December 5, 2008
En Route Conflict Detection and Resolution (CD&R)
Download 243.37 Kb.
|
2.1.5En Route Conflict Detection and Resolution (CD&R)The minimum vertical and horizontal separations are safety requirements. The CD&R activity in ACES is designed to detect upcoming violations of these minimums and resolve the predicted violations. ACES models today's work-load limited ATC environment which uses relatively simple resolution maneuvers. Therefore, the ACES CD&R activity maneuvers only one of the two aircraft in a conflict, and only a single resolution maneuver is used, along with a single recovery maneuver back to the flight plan. These separation minima account for limitations in surveillance, navigation and control of the aircraft position. Improvements in avionics technology, tracking surveillance, and ATC procedures and DSTs serve to reduce the separation minima. To model the impact of such reductions ACES provides a CD&R model that accounts for the separation minima. This capability in the current version provides for low-fidelity modeling only. When a researcher is interested in a high-fidelity modeling, AAC (described later) should be used instead. 2.1.6TerminalTerminal 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:
2.1.7Terminal Area Modeling2.1.7.1Foundation ModelsACES 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. 
Figure 2 1 ACES Simplified Terminal Airspace Network ACES also provides the capability to model multiple airports within a terminal area serviced by a single TRACON. ACES extends the simplified link network to connect boundary fixes with each runway threshold or nodal airport as illustrated in Figure 2-2. 
Figure 2 2 ACES Multiple Airport Simplified Terminal Airspace Network 2.1.7.2Link-Node ModelACES 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:
The STLE C2 functions include:
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. 
Figure 2.3 Conceptual User-Defined Link-Node Graph The C2 models are incorporated into the STLE-based ACES software, with provisions for user management by parametric input. The Plant and C2 functions are described in detail the ACES EDD Surface Terminal Limitations. Companion documents, which are the STLE Software Design Document (SDD) and the STLE User Manual, further describe modeling logic and data processing. 2.1.7.3Capabilities
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.
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:
ACES provides the capability to model ATM and flight operations for multiple airports within a single terminal area:
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.
ACES provides the capability to define the configuration and use of arrival and departure fixes on the terminal airspace boundary:
ACES provides the capability to define a specific runway assignment for each flight based on arrival and departure procedures:
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:
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.
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). 2.1.8Separation at the Arrival Meter FixIn 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.
The following capabilities apply to the ATC element.
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. 2.1.9Arrival Fix ReroutingIn ACES, aircraft can be routed to new meter fixes and airports.
The following capabilities apply to rerouting to an alternate arrival airport.
2.1.10Overlapping TRACONSIn 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.
2.1.11AirportA 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:
2.1.12Dynamic Airport Arrival and Departure CapacitiesACES 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:
2.1.13Surface Traffic Limitations Enhancement (STLE)2.1.13.1Description - ACES processes traffic schedule and runway capacity data to simulate airport flight operations, providing surface congestion constraints on traffic operations. The ACES software simulates runway system operations based on flight demand versus capacity traffic load analyses. In addition, it simulates non-runway surface operations by considering traffic load characteristics and limitations. ACES provides multiple STL options at varying levels of fidelity. The ACES user can choose to activate STL functionality at each individual airport at any of the available levels.2.1.13.2Surface Modeling2.1.13.2.1Basic 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:
2.1.13.2.2STL 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.
2.1.13.3Modeling Options - The ACES user has the option to assign a specific runway modeling mode to each airport. A single ACES run may implement a mix of simultaneous nodal/aggregate, runway, and Link-Node STLE modeling, each at a different airport.2.1.13.4Capabilities2.1.13.4.1 STL - The Surface Traffic Limitations (STL) basic function supports the following capabilities:
2.1.13.4.2STLE - The Surface Traffic Limitations Enhanced (STLE) function supports these additional capabilities:
2.1.14Airline Operations Center (AOC)A low fidelity Airline Operations Center (AOC) provides an AOC model that responds to real-time conditions within the NAS. The AOC has the capability to delay or cancel specific flights in response to TFM constraints imposed by the ATSP or ATCSCC. Located in the /cto7sim/data/static_data/AocParameter.csv file, a specific flight can be delayed or cancelled in the AOC. The default configuration is AOC automatically cancels a flight that has a delay greater than 2 hours. However, this default can be over-ridden by replacing the second parameter for “Maximum average delay of inbound flights;” e.g., with “999” value. 2.1.15Airline Operations Center Cancellations and DelaysACES 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:
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.
The AOC flight delay activity identifies whether an aircraft is banking, determines the passenger connecting relationship between an inbound and an outbound flight, estimates the amount of delay imposed on the outbound flight. 2.1.16Traffic DemandA traffic demand model creates a realistic day-in-the NAS simulation scenario file for ACES. The Traffic Demand model is derived from historical data of the NAS and provides a set of scheduled aircraft with realistic flight plans representing multiple airlines. The scenario file is used to initialize the ACES simulation. 2.1.17WeatherACES provides truth wind data from grid wind data files that are periodically updated (1 hour intervals). Interpolation between the data sets provides a 4D wind vector. Inclement weather effects for ACES are represented as capacity reductions in airspace or at airports. To configure capacity reductions, use the ../cto7sim/data/static data/Airport Capacity files and refer to the ACES Software User Manual. 2.1.18Constrained 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.
2.1.19Rerouting in En Route CD&R for Separation AssuranceACES 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 following requirements apply to the rerouting module created in this task:
2.1.20AirspaceACES utilizes the current NAS airspace. The CONUS ARTCC facility / sector boundaries, TRACON meter fixes, airport locations, and waypoints define the airspace. 2.1.21Advanced 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.
2.1.22Uncertainty Capability for CNSAccessability, 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.
2.1.23International FlightsInternational flights are included in the traffic demand model. The trajectories of international flights are simulated within the NAS airspace just as domestic flights are simulated. International flights are included in CD&R checks and resolutions. International flights are included in sector overload computations and terminal area congestion. International flights are maneuvered in like manner as domestic flights for CD&R and TFM reasons. International flights contribute to system performance statistics, such as traffic throughput at the domestic arrival and departure airports, conflict counts, flight time and fuel burn. AOC handles international flights. 2.1.24International OverflightsThe ACES software allows international overflights to be handled as potentially valid flights. International overflights are included in airspace sector congestion counts within CONUS. International overflights are created similarly to international arrivals, and terminated similarly to international departures. International overflights are included in conflict detection procedures within CONUS. International overflights are affected by conflict resolution maneuvers within CONUS. International overflights are able to be subjected to enroute TFM delays while in CONUS airspace. The data collection indicates whether a flight is an international overflight. TFM delays of international arrival flights can be disabled via user specified file located in ../cto7sim/data/international_flights/internationalflight.cfg. 2.1.25Tail TrackingACES 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.
2.1.26Variable Descent ProfileThe 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.
2.1.27Sector Grid RedesignACES 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.
2.1.28BADA 3.6In order to add new aircraft models to ACES, they must be introduced into the MPAS data folder as well as adding new entries into the ACES aces_model_input Terminal Area database. These models are represented as parameterized input data files for MPAS that are based on Base of Aircraft Data (BADA) models. Additionally, it may be desired to update the existing models to more accurate and recent versions of the BADA data. A tool has been created called UpdateMPASFiles that takes BADA input files, BADA synonym lists, a baseline MPAS file, and creates a new baseline MPAS data file for the aircraft model. Four new aircraft models were added to the base set of 37 independent aircraft models (depicted in Appendix A) and 27 new substitutions (depicted in Appendix A) were added to the sublist (depicted in Appendix A), and roughly 700 flights were added to the accepted flight list. 2.1.29Visualization/Scenario/Simulation ControlThe 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:
The scenario capability provides the user with:
The simulation control capability provides the user with:
2.1.30Communication, Navigation, and Surveillance (CNS)2.1.30.1Description - 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:
These models are not part of the core ACES software, and a user may or may not configure and run a simulation job using them. When these models are used, the user manually selects the specific plug-ins to load, and the ACES Plug-In framework loads them when the job is run. 2.1.30.2Functionality - ACES CNS functionality includes:2.1.30.2.1Communications:
2.1.30.2.2Navigation:
2.1.30.2.3Surveillance:
2.1.30.2.4Feedback:
2.1.30.3Capabilities - CNS 2.0 provides the following capabilities:
2.1.31Swappable Trajectory Generator2.1.31.1Description - An interface, Trajectory Generator Interface (TGI), has been built into ACES 6.0 that enables plug-and-play of the trajectory generator used by an ACES simulation. Previously, ACES was tightly integrated with the existing trajectory generation engine, Multipurpose Aircraft Simulation (MPAS). MPAS is an extensive library or collection of classes within ACES that can be activated within any activity. Its purpose is to model aircraft trajectories based on aircraft dynamics, arrival/departure fixes, waypoints, etc. Exclusive use of MPAS made it extremely difficult to introduce changes into simulation models. In ACES 6.0, when a lower fidelity and faster generator is desired, MPAS can be unplugged and replaced by another trajectory generation engine.2.1.31.2Interface Design - The TGI sits between ACES Agents and Trajectory Generators (TG) (FIGURE 1). Any trajectory generator that wishes to be invoked from ACES needs to conform to the interface, which requires them to implement essential methods and provide certain classes, described in the Swappable Trajectory Generator EDD. (Ref x)
Figure 2-5: ACES Trajectory Generator Interface To ensure maximum compatibility with future trajectory generators, wherever possible, TG states will be exchanged between ACES Agents/Activities. In situations where passing only state information is not sufficient (such as international flight creation) the trajectory generator object will be passed instead. 2.1.31.3Capabilities – The swappable trajectory generator interface provides the following capabilities:
2.1.32Traffic Monitor Advisor (TMA)2.1.32.1Description – The TMA functionality is integrated into ACES 6.0 as a plug-in. It provides an algorithm for traffic flow management that is an alternative to the existing ACES Traffic Flow Manager (TFM). TMA is an implementation of time-based metering (TBM) consistent with that being used by the FAA, allowing ACES to align more closely with current and future NAS configurations. TMA and TFM are not intended to operate on the same flights at the same time.2.1.32.2TMA 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. 2.1.32.3TMA 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:
The TMA model runs continuously, analyzing flights in those areas where metering geometry is defined. However, it only affects flights when a certain level of average delay is present.2.1.32.4TMA 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.
Download 243.37 Kb. Share with your friends:
|