An Object Oriented Analysis Of Air Traffic ControlAn Object Oriented Analysis Of Air Traffic ControlThis section provides the results of the problem analysis subtask, including descriptions of an experiment model and two legacy software models and a comparison of experiment needs (represented by the experiment model) with legacy software capabilities (represented by legacy software models). The models are based upon the ATC model and upon the written and verbal knowledge of the experiment and software authors. The specifications for the models are contained in appendices B, C, and D.The methodology for constructing and comparing the models is described in section 2.3.
In March 1992, I-Lab will be ready to perform ATC experiments of interest to the FAA and to The MITRE Corporation, as well as to establish an environment for operational personnel to provide input to new or proposed automation for future enhancements to the ATC system. The first I-Lab experiment has been proposed to the FAA, and is a result of many iterations in the areas of problem definition, operational concepts, and experimental design. The experiment, as it was defined in December 1990, was expressed in terms of the ATC model.The proposed experiment focuses on the interactions between AERA 2, the terminal area with Terminal Advanced Automation System (TAAS) capabilities, and metering with Advanced Automation System (AAS) capabilities. During periods of heavy ground demand, the metering program of the AAS will sequence and schedule the traffic and will issue flow restrictions to flights still in en route airspace. The flow restrictions will specify the time each flight should cross a meter fix at the boundary of the terminal airspace. The en route controllers must issue clearances to ensure that flights projected to arrive at the meter fix will arrive when scheduled. The controllers are assisted in this task by AERA 2 software.
Successful interaction among metering, en route, and terminal automation would be reflected as a smooth flow of traffic into the terminal area that fully utilizes available arrival capacity without overburdening the terminal area arrival controller. Successful interaction also implies that traffic in the en route area is managed in such a way that it remains controllable in en route airspace (i.e., excessive tactical maneuvering is not required to maintain separation or to meet metering restrictions).
One of the factors likely to affect the interaction among the automation programs is the timing of flow restrictions. The experiment will vary the delay absorption interval, which is defined to be the interval of time between when AERA 2 receives a meter fix restriction for an aircraft and the time that the aircraft would arrive at the meter fix if the aircraft were not delayed. Proposed values for the delay absorption interval are 90 minutes, 60 minutes, and 30 minutes.
If the delay absorption interval is too long, it may cause imprecise delivery to the meter fixes so that controllability in the terminal area is not acceptable (e.g., many aircraft must be maneuvered to absorb delay in the relatively small terminal area). Shortening the delay absorption interval so that capacity utilization and terminal area controllability is accomplished may cause en route difficulties. If this is the case, an en route delay allocation mechanism may be needed, such as additional control points.
At the time the ATC model was used to describe the experiment, the New York Metroplex was considered the most probable site to study these interactions. The airport of interest would be La Guardia, where the arrival acceptance rate depends on several factors (e.g. runways in use, weather conditions). Arrival demand would be allowed to vary during the experiment. The terminal area would be represented by the New York Terminal Radar Approach Control (TRACON), and all meter fixes would be located on the boundary between en route airspace and the TRACON.
Testbed requirements were identified in the experimental design. These requirements specified categories of airspace and ground resources and how they would be modelled in the laboratory. The airspace requirements included specific automation capabilities for terminal and en route ATC and for metering.
4.1.1 Analysis of the Experiment vs. the ATC Model
Running an I-Lab experiment is similar to running any other type of experiment: it is a process which involves setting initial conditions, executing a set of procedures, and analyzing the results. Initial conditions are set by assigning values to the attributes at the start of the experiment. Measurements of ATC system performance are derived by analyzing the variation of certain attributes throughout the experiment.Components (e.g., objects, attributes, services) necessary to run the experiment were identified by performing an object-oriented problem analysis of the proposed experiment definition, resulting in a model of the experiment (hereafter called the "Experiment model"). The process of abstracting high level classes and determining their hierarchical structure was not necessary because the ATC model could be used as a reference model. It was necessary to abstract the data, control, and processes required by the experiment, thus creating lower-level domain-unique classes and structures.
By using a common reference model (the ATC model) for both the experiment analysis and the legacy software analysis, it was possible to make direct comparisons between the components that must exist in the I-Lab to run the proposed experiment and the components that can be provided by the legacy software. The process of evaluating and comparing the Experiment model with legacy software models is described in section 2.3, Model Usage.
4.1.2 The Experiment Model
The Experiment model contains all three subjects identified by the ATC model: User, Resource, and Manager. Each subject contains a structure with a base class of the same name as the subject, and with the Manager subject being contained within the User subject. Figure 4-1 shows the three subjects of the Experiment model; only the first and second levels of classes are shown.Lower-level domain-unique components were abstracted from the experiment definition proposed in December 1990. The interactions of interest defined in the proposed experiment narrowed the experiment problem domain from the ATC domain. The class and object types identified in section 2.2.1 (e.g., other systems, devices, things or events remembered, roles played, operational procedures, sites, and organizational units) were used as a guideline in identifying classes and objects.
For the experiment, sources and sinks of flights were of importance in determining airspace boundaries and airports. The three proposed values of the delay absorption interval also influenced the shape and size of airspace volumes. An experiment scenario traffic pattern was also identified within these airspace boundaries.
Figure 4-1. Experiment Model: Subjects
Attributes were determined both by an analysis of the metrics important to the experiment and by the need for descriptive attributes for the domain-unique classes and objects.
In defining domain-unique specializations in the Manager class structure, services performed by automation were not distinguished from services accomplished by human intervention. In particular, the services provided by a regional traffic manager were not distinguished from services provided by metering algorithms, and services provided by an en route controller were not distinguished from services provided by AERA 2 software.
Although the experiment focuses on the AERA 2 functions which interact with metering and terminal area functions, the Experiment model does not include a complete representation of the AERA 2 model. A complete AERA 2 model is included in section 4.2.2.
The following subsections explain the Experiment model in detail. The notation used, whereby classes are shaded to indicate components borrowed from the ATC model, is the notation defined in section 2.3, Model Usage.
4.1.2.1 The User Subject
The User subject, borrowed from the ATC model, contains the same two structures as the ATC model: the Manager class structure and the Traffic class structure. Since the Manager class also belongs to the Manager subject, the Manager class structure will be discussed separately in section 4.1.2.3. The remainder of this section discusses the Traffic class structure.The Traffic Class Structure. The Traffic class of the experiment, shown in part 1 of figure 4-2, is only concerned with the Air Traffic class. The experiment is not concerned with the movement of vehicles on the ground. Only after traffic originating on the ground has departed and must be sequenced into the terminal area traffic is it of concern to the experiment. However, it is necessary to identify the ground movement areas (discussed in section 4.1.2.2, The Resource Subject) since they are a source of air traffic.
A domain-unique specialization of the Air Traffic class, the Experiment Scenario Traffic Pattern class, was identified in the experiment by the definition of a scenario traffic pattern needed, both in en route (AREA 2) airspace and the terminal area. Specific traffic patterns define the volume and complexity of traffic, and influence resource load and demand throughout the experiment.
Individual flights are also of interest to the experiment since each en route flight will be assigned a meter fix time and can be maneuvered individually while en route, and each flight in the terminal area will also be maneuvered on an individual basis. Relevant parts of a Flight object are an Aircraft object, a Flight Plan object, and a Flight Clearance object.
The relevant parts of an Aircraft object are a Pilot object, a Vehicle Communications System object, and a Vehicle Navigation System object. Pilot object services in the terminal area are performed by automation and by a staffed simulated pilot ("sim-pilot") position, while Pilot object services in en route airspace are automated. The Vehicle Communications System class is necessary in terminal airspace so that the terminal area controllers can communicate with the sim-pilots, but Vehicle Communications System object services are automated in en route airspace. The Vehicle Navigation System class is necessary so that flights can fly either a Microwave Landing System (MLS) or Instrument Landing System (ILS) approach to La Guardia airport, as well as fly point-to-point.
The domain-unique Flight Plan object attributes of interest to the experiment are the Expected Meter Fix Time, Expected Airport Arrival Time, and the Flow Restriction Time. A complete representation of the Flight Plan class and object is identified in the AERA 2 model. All parts of a Flight Clearance object are of interest to the experiment, i.e., an En Route Clearance object, a Departure Clearance object, and an Arrival Clearance object.
Figure 4-2. Experiment Model: User Subject (Traffic) (Part 1)
Figure 4-2. Experiment Model: User Subject (Traffic) (Part 2)
Classes Supporting Problem Detection. The AERA 2 domain-unique classes of interest to the experiment pertain to the way in which AERA 2 detects and handles problems. Trajectory objects are used in predicting problems. The problems of interest to the experiment, shown in part 2 of figure 4-2, are aircraft-to-aircraft conflicts, aircraft-to-airspace conflicts, and flow instruction non-compliance problems. (The attributes and services of these objects are explained in the AERA 2 model.) For the experiment, the "best" resolution to a problem (as determined by AERA 2 software), called the highest-ranked resolution (HRR), will automatically be chosen when a problem occurs.
4.1.2.2 The Resource Subject
The Resource class specializations of interest to the experiment are the Airspace/Ground Resource class, the Surveillance Resource class, the Communications Resource class, and the Navigation Resource class. The Aviation Weather Resource class is not involved in the experiment.The Airspace/Ground Resource Class. Both parts of the Airspace/Ground Resource object are necessary; these parts are the Controlled Airspace object and Airport Movement Area objects. The Airport Movement Area class, shown in part 1 of figure 4-3, is referred to in the experiment as "airport." Two domain-unique, specialized classes of the Airport Movement Area class are the La Guardia Airport and Washington Area Airport classes. Since the site of the terminal area in the experiment is the New York TRACON, the attributes of the La Guardia Airport object that are of interest to the experiment are Arrival Capacity, Departure Capacity, Runway Configuration, and Expected Departure Rate. Washington Area Airport objects are identified since they will be sources and sinks of flights in the en route airspace. The attributes of interest of a Washington Area Airport object are Runway Configuration and Expected Departure Rate.
The Controlled Airspace Class. Shown in part 2 of figure 4-3, the parts of the Controlled Airspace object needed for the experiment are the En Route Controlled Airspace object and a Terminal Controlled Airspace object. One important aspect of the experiment is the location of the meter fixes which are on the boundary between the en route and terminal areas. For this reason, the attribute Boundary is defined as a domain-unique attribute for both airspace-type objects.
The Terminal Controlled Airspace Class. The parts of the Terminal Controlled Airspace object (a Terminal Route object and a Terminal Airspace Volume object) are of interest. A specialization of the Terminal Airspace Volume class is the New York TRACON class. The Terminal Route class specializations identify the ILS Route class and the MLS Route class.
The En Route Controlled Airspace Class. The En Route Controlled Airspace object is composed of Route objects and an Airspace Volume object, all required for the experiment. The airspace volume which of interest is the 90-minute flying-time wedge which extends southeast from the New York TRACON toward and past the Washington area airports. Of interest from a Route object is the part Fix/Waypoint object. Instances of the Fix/Waypoint class will be used by all flights in the en route airspace (whether metered or not). A specialization of the Fix/Waypoint class, the Meter Fix class, is identified for those fixes which are metered. An instance (object) of a Flow Instruction class would be associated (by instance connection) with an instance of the Meter Fix class.
The Other Resource Classes. The Surveillance Resource structure, Communications Resource structure, and the Navigation Resource structure are shown in figure 4-4.
Figure 4-3. Experiment Model: Resource Subject (Part 1)
Figure 4-3. Experiment Model: Resource Subject (Part 2)
Figure 4-4. Experiment Model: Resource Subject (Other Resources)
The Surveillance Resource Class. The surveillance resource of interest is the Airspace Surveillance System class, a specialization of the Surveillance System class. Two specializations of the Airspace Surveillance System class are identified in the experiment. One specialization, the ARTS-Like Terminal Surveillance System class, is identified for use in the terminal area. An ARTS-Like Terminal Surveillance System object is assumed to include the primary radar antenna, the radar data acquisition system, the ATC radar beacon system (secondary radar surveillance) antenna, the beacon data acquisition system, and the data processing subsystem (commonly called an Automated Radar Terminal System [ARTS] by itself). At a design level, the object is also assumed to include a data entry and display subsystem and a continuous data recording subsystem. An ARTS-Like Terminal Surveillance System object is required to provide the services for a user interface and to provide TAAS capabilities. The experiment is similarly provided with radar data processing (RDP) services for en route airspace by the other specialization of the Airspace Surveillance System class, the RDP-Like En Route Surveillance System class. An RDP-Like En Route Surveillance System object is assumed to include primary and secondary radar antennas, a beacon data acquisition system, an RDP subsystem, a data entry and display subsystem, and a continuous recording subsystem.
The Communications Resource Class. The communications resource of interest is the Air/Ground Communications System class, a specialization of the Communications System class. Two specializations of the Air/Ground Communications System class identified in the experiment are the Data Link-Like Communications System class and the Voice Radio-Like Communications System class.
The Navigation Resource Class. The navigation resource of interest is the Landing Navigation System class, a specialization of the Navigation System class. The Landing Navigation System class is needed to provide the resource counterparts to the navigational equipment which exists in the aircraft. The two specializations of the Landing Navigation System class identified by the experiment are the ILS-Like Landing Navigation System class and the MLS-Like Landing Navigation System class. For the experiment, these systems and equipment will be used for flying approaches to La Guardia airport.
4.1.2.3 The Manager Subject
The Manager subject is shown in figure 4-5. As mentioned in section 3.2.3, a close coupling exists between the Manager class structure and the Traffic class structure. Those managers of interest to the experiment are specializations of the Traffic Manager class and of the Flight Manager class. The Traffic Manager class specialization of interest is the Air Traffic Manager class since only air traffic is of interest. The domain-unique specialization identified is the Regional Air Traffic Manager which is necessary because metering is a regional traffic management function. The services of a Regional Air Traffic Manager object include services which would be performed by the metering program and those performed by a human traffic manager. Those services performed by the metering program are Impose Flow Instruction, Create Metering Flow Restriction, Sequence/Resequence Flight, and Adjust Flight Schedule. The service provided by the human traffic manager is Monitor.Three Flight Manager class specializations were identified: the En Route Controller class, the Terminal Controller class, and the Tower Controller class. The En Route Controller class encapsulates services performed by AERA 2 software and those performed by a human en route controller (automated for the experiment). Those services performed by AERA 2 are Identify Conflicts, Propose Resolutions, and Compute Delay-Absorbing Maneuvers. Those performed by the automated human controller are Issue Delay-Absorbing Maneuvers and Handoff Aircraft to Terminal Controller.
Figure 4-5. Experiment Model: Manager Subject
The New York TRACON has a terminal controller to perform those services necessary to control traffic in the terminal area. Services identified by the experiment for a Terminal Controller object are Final Arrival Sequencing and Spacing, Coordinate Arrivals With Departures, and Accept/Initiate Handoffs. La Guardia Airport has a tower controller to perform those functions which will affect the coordination of arrivals and departures in the terminal area. Each Washington area airport has a tower controller to respond to flow instructions that require ground delay of Washington area departures.
4.1.2.4 Event View: Handoff of a Flight from En Route Controller to Terminal Controller
As discussed in section 3.2.6.2, a change in flight state is associated with a change in manager rather than with a change in resource usage. The change in flight state of interest to the experiment is the state change from en route to arrival. This state change occurs when the flight is handed off from the en route controller to the terminal controller.For the experiment, the en route controller services will be automated and the terminal controller position (actually the arrival controller position) will be staffed. The handoff event will occur without a means of coordination between the two controllers. The en route controller will determine when a flight should be handed off, and the terminal controller will accept it at that time. This will be true whether or not AERA 2 has successfully maneuvered the flight to meet the meter fix time.
Figure 4-6 is a view of the event causing this state change, using the classes and objects identified in the experiment definition. At the beginning of the event, an En Route Controller object exists with instance connections to an En Route Airspace Volume object for which the controller is responsible and to a Flight object under the controller's control. All three parts of the Flight object, the Aircraft object, the Flight Plan object, and the Flight Clearance object, are necessary. The Flight Clearance object has two parts, the Arrival Clearance object and the En Route Clearance object. An instance connection exists between the Aircraft object and the same En Route Airspace Volume object. This instance connection indicates that the Aircraft object is being taken into account in the Load attribute of the En Route Airspace Volume object and is observed by the en route airspace surveillance systems. An instance connection also exists between the Flight object and the Terminal Airspace Volume object and between the Flight object and the En Route Airspace Volume object indicating that the Flight is being taken into account in the Demand attribute of each airspace-type object.
The En Route Controller object monitors the Location attribute of the Aircraft object and the Route and Altitude Profile of the Flight Plan object with respect to the Boundary and Altitude Limit attributes of the En Route Airspace Volume object. The controller determines when the flight is about to leave the en route airspace volume and enter the terminal airspace volume. At this point, the En Route Controller object sends a message to the Terminal Controller object requesting acceptance of control responsibility for the flight, and the Terminal Controller object automatically accepts. At this time, the instance connection between the Flight object and the En Route Controller object can be deleted and an instance connection between the Flight object and the Terminal Controller can be created. The state change of the Flight object is now complete.
Figure 4-6. Experiment Model View: Handoff Of A Flight From En Route Controller To Terminal Controller
Although not shown in this view, the following will also occur:
- When the En Route Controller object tells the Pilot object of the Aircraft object to change radio frequency to the frequency for the Terminal Controller object, the Pilot object will comply and will also tell the En Route Clearance class to delete the En Route Clearance object (see section 3.2.6.2 for a similar event).
- When a Surveillance System object detects that the aircraft object is no longer in the en route airspace volume, the Surveillance System object will request the Aircraft class to delete the instance connection (based on load) between the Aircraft object and the En Route Airspace Volume object and will request the Flight class to delete the instance connection (based on demand) between the Flight object and the En Route Airspace Volume object.
- When a surveillance system detects that the aircraft is in the terminal airspace volume, the Surveillance System object will request the Aircraft class to add an instance connection (based on load) between the Aircraft object and the Terminal Airspace Volume object.
The first milestone of the I-Lab was met six months into the project and was called the Six Month Illustration of Technical Feasibility, or 6-MITF. It was a proof of concept that demonstrated the ability to integrate six functionally different ATC software components, which were developed independently and without the requirement of interoperability, to form a complete ATC system. These software components, referred to as "legacy" software components, were existing simulations, prototypes, and operational prototypes developed over the past five years in support of various MITRE projects. Mapping the legacy software components used for the 6-MITF onto the ATC model was intended to explore the possibilities of using the legacy software to perform the proposed experiment. The process by which the experiment capabilities were compared to the capabilities offered by legacy software is discussed in section 2.3, Model Usage.Two pieces of legacy software, the Terminal Area Simulation Facility (TASF) and the Automated En Route Air Traffic Control Phase 2 (AERA 2) Computer-Human Interface (CHI) Prototype were defined in terms of the ATC model and are discussed in this paper.
4.2.1 TASF
TASF was built as a simulation platform to support the development and evaluation of automation in the terminal area. TASF simulates the necessary environment so that various ATC automation aids can be developed and evaluated using "real life" scenarios before being tested in the field. For the purposes of accurately developing and assessing the ATC automation aids, TASF attempts to separate the simulated environment from the automation. The simulated models used in the six-month configuration were an ARTS III computer, a wind model, and an aircraft true trajectory modeler; the automation aid used was the ghosting aid. The ghosting, or "imaging," aid generates and projects false targets, called "ghosts," based on real targets and displays them on ARTS III displays in TRACON facilities.The true trajectory modeler, which calculates the point position of aircraft in the terminal area, accepts many different forms of input: a route, route segment, maneuver, or point position. At any of these levels, the input can be retrieved from files; at the route segment and maneuver level, the input can be made by a simulated pilot ("sim-pilot"). TASF does not use filed flight plan information, such as proposed route data, to predict the future position of the aircraft. The aircraft target displayed by the simulated ARTS III computer was the actual calculated position (taking into consideration output from the wind model). For the 6-MITF, the simulated ARTS III computer supported a bright radar indicator tower equipment (BRITE) display for the La Guardia tower and three displays for the New York TRACON (North arrivals, South arrivals, and departures/final approach).
Currently in the terminal area, there are no standard or accepted airways or jetways (STARs and SIDs are precursors), but the standard procedure is for a pilot to fly the current course until vectored by a controller. However, for the six-month illustration, TASF had the "concept" of two defined routes. One route was defined by the ILS approach procedure, and the other was defined by a curved MLS approach route. A flight could be maneuvered by a sim-pilot, or could capture and fly the ILS route, or could capture and fly the MLS route, or could join the MLS route.
The configuration of TASF used for the six-month illustration provided the laboratory the capability to simulate, display, and maneuver aircraft through the New York terminal area. Operations centered around arrivals into La Guardia Airport on runway 13 during inclement weather conditions. Arrivals on the La Guardia ILS approach route interfere with arrivals bound for nearby Teterboro airport. To create gaps in the ILS route which would allow arrivals into Teterboro, a curved MLS approach route was used.
For the 6-MITF, the La Guardia arrivals on both approach routes had to be merged by the final approach controller for landing. The controller was aided in the task of sequencing and spacing the aircraft by the ghosting aid, which projected MLS aircraft onto the ILS route. The final approach controller issued clearance directives to the sim-pilots using simulated radio communications, and the sim-pilot entered the individual aircraft maneuvers into a VT 220 computer terminal which was input to the true trajectory modeler of TASF.
4.2.1.1 Analysis of TASF vs. the ATC Model
The configuration of TASF used for the six-month milestone was described using the ATC model. TASF may not be the terminal area component used in March 1992, but the resulting analysis was intended to identify existing terminal area components that might correspond to terminal area components required by the experiment. TASF was not designed as an object-oriented system, and the model (hereafter called the "TASF model") merely describes the TASF software component in an object-oriented manner for the purposes of comparing the TASF capabilities with experiment requirements.Using the ATC model as a reference model was accomplished the same way as for the experiment: high-level classes were provided, and it was necessary to determine the domain-unique subset of these classes and to define the lower-level domain-unique classes and structures. The data, control, and processes performed by this configuration of TASF are abstracted in these domain-unique classes and structures.
TASF identifies several classes which are not strictly within the terminal area domain. An example of this in the Manager subject is the En Route Controller class specialization which is also, more appropriately, found in the AERA 2 model. Other examples are found in the Resource subject where, in addition to identifying the Terminal Controlled Airspace class, the En Route Controlled Airspace class is identified, as well as the Airport Movement Area class. These classes provide a means to interface with neighboring (en route and ground) resources and managers when TASF is operating in a stand-alone mode, and were not used when TASF was integrated in the 6-MITF.
4.2.1.2 The TASF Model
The TASF model contains all three subjects identified by the ATC model: User, Resource, and Manager. Each subject contains a structure with a base class of the same name as the subject, and with the Manager subject being contained within the User subject. Figure 4-7 shows the three subjects of the Experiment model; only the first and second level of classes are shown.
Figure 4-7. TASF Model: Subjects
Lower-level domain-unique components were found by reading available documentation, talking with domain-knowledgeable people, and examining sections of the source code. Documentation and discussions gave a good overall understanding of how TASF modelled the terminal area. Data structures identified in the source code were good sources for classes and their attributes, and subroutines were sources for services. When using all sources of information, the categories identified in section 2.2.1 for identifying classes and objects were kept in mind.
Sources and sinks of flights in the terminal area include the en route airspace and the airport movement areas. Interfaces to these sources and sinks are abstracted in the services of the controller objects, which include accepting and delivering aircraft handoffs and flight data.
The following subsections explain the TASF model in detail. The same notation used to map the experiment onto the ATC model was used to map TASF; the notation is defined in section 2.2.
The User Subject. The TASF User subject also consists of the same two structures as the ATC model, the Traffic class which is discussed immediately following and the Manager class which is discussed later. The Traffic class structure of the TASF model is shown in figure 4-8.
Traffic in the terminal area is all air traffic; therefore, the TASF model is only concerned with the Air Traffic class from the ATC model. TASF is concerned with flights on an individual basis as well. Flight objects and all the parts identified in the ATC model are relevant to the TASF model, including the Flight Clearance object, the Flight Plan object, and the Aircraft object. Domain-unique attributes of Flight are an attribute which identifies the airline and an attribute which identifies the flight number.
Flight Clearance objects and the parts Departure Clearance object and Arrival Clearance object are needed, without identifying domain-unique components. Although the departure clearance is issued on the ground, the cleared route extends into the terminal area and must be known by the departure controller in the terminal area. The approach clearance is a dynamic clearance for an aircraft that is maneuvered by the controller and the sim-pilot and is a static clearance for an aircraft following a specified route.
Flight information required by TASF is a subset of what is contained in an actual flight plan. As discussed earlier, TASF does not use flight plan data for route prediction; however, TASF does need arrival and departure information for those flights that originate or land within the terminal area. The pertinent information is found in the following attributes: Flight Type, Departure Airport, Arrival Airport, Runway, and Departure Fix.
An Aircraft object has attributes defined in the aircraft data structure which identify the aircraft limits, position, and velocity. Position attributes are input to the simulated ARTS III computer and displayed. Aircraft services were abstracted from the trajectory modeler and determine the true position of the aircraft. These services allow any accepted form of input described in section 4.2.1 above.
Relevant parts of an Aircraft object are a Pilot object, a Vehicle Navigation System object, and a Vehicle Communications System object. The two domain-unique services of a Pilot object are Accept Clearance Directives From Controller and Maneuver Aircraft.
Two domain-unique classes which are specializations of the Vehicle Navigation System class are the Aircraft ILS Navigation System class and the Aircraft MLS Navigation System class; these classes are needed so that the aircraft can fly the appropriate approach route. The Vehicle Communications System class is taken directly from the ATC model with no modifications.
Figure 4-8. TASF Model: User Subject (Traffic)
The Resource Subject. The Resource structure, shown in figure 4-9, (parts 1, 2, and 3) borrowed all the specializations of the ATC model with the exception of the Aviation Weather Resource class.
The Airspace/Ground Resource object of TASF, shown in figure 4-9, (part 1) borrowed both objects which were part of the Airspace/Ground object of the ATC model: the Controlled Airspace object and the Airport Movement Area object. TASF is concerned with the location of airports for the purposes of spacing and sequencing flights for landing and as a source of flights. The specializations of the Airport Movement Area class identified in the six-month configuration of TASF are the La Guardia Airport class and the Teterboro Airport class. A part of an Airport Movement Area object of interest is a Runway object. The specialization of the Runway class identified is the La Guardia Runway 13 class. There is only one object belonging to the La Guardia Runway 13 class, and it represents the active runway at La Guardia Airport.
Parts of the Controlled Airspace object of importance to TASF are the En Route Controlled Airspace object and Terminal Controlled Airspace objects. Classes and objects identified in the En Route Controlled Airspace class and object structures, shown in figure 4-9, (part 2) are not domain-unique but are also found in the AERA 2 model. Both parts of the En Route Controlled Airspace object are identified, Route ("En Route Airway") objects and Airspace Volume objects. A specialization of the Airspace Volume class was identified, the Holding Pattern Airspace ("Holding Pattern") class. Part of a Route ("En Route Airway") object identified is the Fix/Waypoint ("En Route Waypoint") object.
Parts of the Terminal Controlled Airspace object, shown in figure 4-9, (part 3) are used in TASF, including Terminal Route objects and the Terminal Airspace Volume object. A specialization of the Terminal Airspace Volume class, called the New York TRACON class, was identified. Four specializations of the Terminal Route class are the MLS Route class, the ILS Route class, the STAR class (which was not used in the 6-MITF) and the SID class (which was also not used).
Other resources identified in the six-month configuration of TASF are shown in figure 4-10. The Airspace Surveillance System class, a specialization of the Surveillance System class, was borrowed from the ATC model. (The Ground Surveillance System specialization class is not a TASF concern.) The domain-unique specialization of the Airspace Surveillance System class is the ARTS III class. The ARTS III computer provides a display for the controller. A specialization of the ARTS III class identified by TASF is the ARTS III With Ghosting class.
The Navigation Resource class and the Navigation System class were borrowed from the ATC model. Of importance to TASF is the Landing Navigation System class, a specialization of the Navigation System class. The two domain-unique specializations of the Landing Navigation System class are the Instrument Landing System (ILS) class and the Microwave Landing System (MLS) class. The attributes of the Instrument Landing System (ILS) class identify variable data (signals) produced by the localizer and the glide slope transmitters. A part of the Instrument Landing System (ILS) object, the ILS Marker Beacon object, was also identified (although not used in the 6-MITF). An ILS Marker Beacon object can be used to represent either an outer marker beacon or a middle marker beacon. Services of a Microwave Landing System (MLS) object provide lateral and vertical position information to the aircraft.
The Communication Resource class and the Communication System class were borrowed from the ATC model. The specialization of the Communications System class used in TASF is the Air/Ground Communications System. Two domain-unique specializations of the Air/Ground Communications System class, called the Data Link Communications System class and the Voice Radio Communications System class, are also used. The Voice Radio Communications System class was used in the laboratory for the communications between the final approach controller and the sim-pilots.
Figure 4-9. TASF Model: Resource Subject (Airspace/Ground Resource) (Part 1)
Figure 4-9. TASF Model: Resource Subject (Airspace/Ground Resource) (Part 2)
Figure 4-9. TASF Model: Resource Subject (Airspace/Ground Resource) (Part 3)
Figure 4-10. TASF Model: Resource Subject (Other Resources)
Since it was a direct communication, the frequency attribute defined in TASF was not modeled. The Data Link Communications System class was identified in TASF but not used in the 6-MITF.
The Manager Subject. The Manager subject of TASF, shown in figure 4-11, contains the Flight Manager class borrowed from the ATC model with several domain-unique classes identified. The Terminal Flight Manager class and the En Route Flight Manager class are the domain-unique specializations of the Flight Manager class. The en route flight manager is of importance to TASF for the purposes of accepting and receiving handoffs from a terminal flight manager in the stand-alone mode.
The Terminal Flight Manager class has four domain-unique specialization classes: the North Arrival Controller class, the South Arrival Controller class, the Departure Controller class, and the Final Approach Controller class. The North and South arrival controllers are the controllers that will accept flights from the en route controllers. The final approach controller is the controller who interacts with the sim-pilot to space and sequence flights on the approach routes. The departure controller accepts flights from the local controller on the ground and spaces them on the departure routes.
For the six-month illustration, there was no coordination between the controllers during handoffs. It was assumed that a controller in the next area of responsibility would be able to take the aircraft when the current controller was ready to hand it off.
Event View: Spacing ILS Flight on Arrival Route. This view is an example of how aircraft were maneuvered in the terminal area so that MLS and ILS approaches were merged for landing on runway 13 at La Guardia Airport. The final approach controller spaced the aircraft with the aid of the ARTS III ghosting aid. MLS approaches were projected onto the ILS route, and, in the 6-MITF, only the ILS aircraft were maneuvered in the spacing process. Figure 4-12 is a view of the spacing event using the classes and objects identified in TASF.
At the beginning of the event, a flight is flying an ILS approach to La Guardia Airport with the use of an ILS-specialized navigational system. The Flight object has an instance connection to a Final Approach Controller object which has control of the Flight. The Final Approach Controller is continually requesting the ARTS III With Ghosting object to perform the services of Display Aircraft Location and Project MLS Flight Onto ILS Route.
The Final Approach Controller object is performing the service Space Aircraft on Arrival Route. If the particular flight is not spaced properly with the other ILS flights or the ghosts of the MLS flights, the Final Approach Controller object will perform the service Issue Clearance Directives to Pilot and request the Pilot object to perform the services of Accept Clearance Directives From Controller and Maneuver Aircraft. The Pilot object will then request the Aircraft ILS Navigation System object to perform the service Accept/Implement Maneuver Information and will request the Aircraft object to perform the services Calculate Aircraft Point Position and Send Aircraft Point Position to ARTS (in this instance, ARTS III With Ghosting).
After the above-described services are performed, the flight should be properly spaced; however, this event is a continual process for the final approach controller.
Figure 4-11. TASF Model: Manager Subject
Figure 4-12. TASF Model View: Spacing ILS Flight On Arrival Route
4.2.2 AERA 2
The NAS Plan states that Automated En Route Air Traffic Control (AERA)will provide interactive software for use by the area control facility to plan and monitor the 4-dimensional flow of air traffic. Specifically, AERA will: (1) permit most aircraft on IFR flight plans to fly fuel-efficient profiles, (2) increase safety of the system by reducing the potential for operational error, (3) increase system capacity by integrating en route metering with local and national flow control, and (4) increase controller productivity by increasing the number of aircraft and volume of airspace that a control team can safely manage.AERA Phase 2 (AERA 2) provides the following functionality: automatic reconformance of a flight plan with the flight track; trial planning; automatic detection and resolution of aircraft conflicts, airspace conflicts, and flow instruction problems; automated coordination aids; automatic clearance generation; automatic generation of controller reminders; and support for the automated use of data link in clearance delivery and information interchange.The AERA 2 CHI Prototype (Mayo, 1990) was created for the purpose of supporting the evaluation of operational concepts, and provides a simulated ATC environment, simulated aircraft behavior, a subset of AERA 2 functionality, an interface for controller subjects and prototype developers, and tools for customizing (e.g., "scripting") sessions. In creating a model of the AERA 2 CHI Prototype, the human interface and the customizing tools were not modeled, but when information was needed for a display, the creation of that information was modeled. In addition, no distinction was made between processing that occurs offline and processing that happens "real time." For example, a Flight Plan is always created offline but a Flight Plan can be converted into a Current Plan, by the addition of a Trajectory, either offline during scenario generation or online during a simulation session. The service Create (an intrinsic service) was merely placed with the appropriate plan type (Flight Plan or Current Plan). When the plan type is "current," the service Create also involves a message sent to the Trajectory class to create a Trajectory object as part of the Current Plan object. (A Flight Plan does not have a Trajectory object as a part object.)
The AERA 2 CHI Prototype was not designed as an object-oriented system. The model of the AERA 2 CHI Prototype (hereafter called the "AERA 2 model") merely describes the prototype as if it were object-oriented, for the purpose of comparing prototype capabilities with experimental requirements. The AERA 2 model should not be interpreted as the design for the AERA 2 CHI Prototype.
4.2.2.1 Analysis of AERA 2 vs. the ATC Model
AERA 2 is usually described as a collection of functions (see, for example, [Ball and Taber, 1990] for a functional decomposition of AERA 2), and descriptions of the AERA 2 CHI Prototype follow this convention. Primary sources of information for classes, objects, attributes, and instance connections for the AERA 2 model were descriptions of the AERA 2 CHI Prototype database. Services and messages were inferred from functional descriptions and were placed with appropriate classes and objects. Except for (Mayo, 1990), the sources of information were unpublished internal MITRE documents and MITRE management and staff.The AERA 2 model adds a large number of classes and objects to the ATC model for the purpose of storing data for use by the services of a few classes and objects. These new classes and objects tend to have only the intrinsic services and to behave passively (i.e., respond to requests rather than initiate requests). If the ATC model had been developed several levels lower, then many of these new classes and objects would have naturally appeared. These new classes and objects, and their relationships with classes, objects and services of the ATC model, are described in section 4.2.2.2 below.
Table 4-1 summarizes the assignment of AERA 2 CHI Prototype functionality to services of classes and objects. As stated above, processing to support logical displays (for the human interface) is not included in this assignment, e.g., the Situation Monitor functionality Conflict Notification is not included, but the processing to create the information (Automated Problem Detection) is. In the ATC model, no distinction is made between the human and the automation in providing a service; however, in the AERA 2 model, when a function is clearly automatic with no human intervention (e.g., the automatic handoff of an aircraft), that function might be placed as the service of an object that is not a manager (e.g., Handoff is a service of a Trajectory object). More information about the services in the AERA 2 model is provided in the model specification in appendix D.
4.2.2.2 The AERA 2 Model
In creating the AERA 2 model, the ATC model was examined for reusable components. AERA 2, for the most part, provides en route services for individual aircraft, and thus, for the most part, the Traffic class structure can be collapsed to the Flight class level, manager resources can be limited to flight managers, and airspace/ground resources can be limited to en route airspace resources (with new specializations). The AERA 2 CHI Prototype also uses information about terminal airspace and winds in order to model the aircraft planned path (the trajectory) and uses information about radar weather areas for display. The AERA 2 CHI Prototype does not need the Navigation Resource or Surveillance Resource structures of the ATC model. A Track object, which might have been produced by a Surveillance System object, is instead simulated based upon a Trajectory object. This restriction in the AERA 2 model scope is illustrated by figure 4-13 showing the AERA 2 model subjects. In this figure, and in later figures illustrating the AERA 2 model, components borrowed from the ATC model are shaded.The AERA 2 model adds new classes and objects to represent the increase in detail needed by the AERA 2 CHI Prototype. While the ATC model contains only the flight plan, the AERA 2 model must contain all the plan types of interest to the AERA 2 CHI Prototype, thus adding a new structure for plans with new specializations and parts which subsume the flight plan. Processing of the new plan types requires special services. The AERA 2 CHI Prototype trajectory modeling capabilities require information about aircraft classes, normal routings near airports, and winds in order to build trajectories and require new classes and objects to store trajectories once they are built. Because of the new problem detection and resolution capabilities, new classes and objects are added to help in the detection of problems (e.g., airspace specializations and restrictions), and new classes and objects are added to represent the problems themselves and their resolutions. These additions are described in more detail below.
The User Subject. Figure 4-14 (a three-part figure) shows the User subject for the AERA 2 model. Part 1 of the figure emphasizes the classes and objects associated with the Flight class, part 2 emphasizes the Plan class, and part 3 emphasizes the Problem class. Parts 1 and 2 have the Flight Plan class in common, while parts 2 and 3 have the Plan and Machine Plan classes in common. (Alternatively, two new subjects called Plan and Problem could have been introduced.)
As shown in part 1 of the figure, a Flight object is made up of an Aircraft object and a Flight Plan object. (The clearance-type classes are not used in the AERA 2 model.) Each Flight Plan object may be connected to one or more Flight Plan Amendment objects. An Aircraft object may be connected with one or more Track objects, representing the actual position (past and present) of the aircraft (as opposed to the intended position, represented by attributes of the Flight Plan object). The Track object would normally be created based upon reports from a surveillance system-type object, but, in the AERA 2 model, Track objects are created based upon simulated information from a Trajectory object. An Aircraft object is also connected with an Aircraft Class object, which is further connected with several Climb Profile, Descent Profile, and Long Range Cruise Profile objects. These new classes and objects behave passively and exist to provide information for trajectory modeling.
Table 4-1. Translation of AERA 2 CHI Prototype Functions to AERA 2 Model Services
* - Inherited
AERA 2 CHI Prototype Functionality AERA 2 Model Class & Object AERA 2 Model Service Plan Construction (All) En Route Controller Assist in Flight Planning* Plan Construction (Creation) adds to Plan Construction (All) En Route Controller Request New Plan Creation Flight Plan; Plan Create Plan Construction (Amendment) adds to Plan Construction (All) En Route Controller Request Plan Amendment Flight Plan Amend Flight Plan Plan Construction (Reconformance Aid) adds to Plan Construction (All) En Route Controller Request Reconformance Aid Trial Plan Create Plan Construction (Limited Resolution Aid) adds to Plan Construction (All) En Route Controller Request Limited Resolution Aid Trial Plan Create Automated Replan Processing adds to Plan Construction (All) En Route Controller Request Automated Replan Automated Replan Amendment Request Trial Plan Creation Trial Plan Create Automated Coordination adds to Plan Construction (All) En Route Controller Request Automated Coordination Trajectory Estimation Trajectory Trajectory Estimation Flight Simulation Trajectory Request Track Creation Situation Monitoring (Resynchronization) Trajectory Resynchronization Situation Monitoring (Handoff Control) Trajectory Handoff Situation Monitoring (Top-of-Descent Controller Reminder) Trajectory Trajectory Estimation Controller Reminder Deliver Controller Reminder Situation Monitoring (Out-of-Conformance Detection) Track Out-of-Conformance Detection Problem Detection and Resolution (Automated Problem Detection) En Route Controller Detect, Predict & Report Separation Violation;* Detect, Predict & Report Restriction Violation * Problem Detection and Resolution (Automated Resolution Generation) En Route Controller Separate IFR Flights;* Ensure Restriction Compliance* Data Link En Route Controller Generate & Deliver Clearance* Data Link Transmit Message* Pending Plan Create
Figure 4-13. AERA 2 Model: Subjects
Figure 4-14. AERA 2 Model: User Subject (Flight) (Part 1)
Figure 4-14. AERA 2 Model: User Subject (Flight) (Part 2)
Figure 4-14. AERA 2 Model: User Subject (Flight) (Part 3)
Part 2 of the figure introduces the new Plan class. A Plan object has at least three part objects: a Flight Plan object, a Trajectory object, and one or more Clearance Directive objects. The Flight Plan class of the AERA 2 model is essentially the same as the Flight Plan class of the ATC model. A trajectory provides a more detailed description of the four-dimensional predicted path of an aircraft; a Trajectory object is made up of State Segment objects, each of which is connected to a State Segment Start object and a State Segment End object. State segments describe the physical movement of an aircraft in terms of its bearing, acceleration, and gradient at given times and places. The Planning Region State Segment class is a specialization of the State Segment class, and represents that part of a trajectory that is contained within the planning region of interest (the "Planning Region" object). A Clearance Directive object represents an action, or maneuver, planned for the aircraft. A clearance directive is not an ATC clearance.
The Plan class has two specialization classes, the Current Flight Plan class and the Non-Current Flight Plan class. Each of the specialization classes, of course, also "inherit" the whole-part structure of the Plan class. The Non-Current Flight Plan class also has specializations, the Pending Plan class, the Trial Plan class, and the Machine Plan class. A specialization of the Trial Plan class is the Automated Replan Plan class. An Automated Replan Plan object is connected (by instance connection) to an Automated Replan Amendment object. An Automated Replan amendment represents a template for creating trial plans, called here automated replan plans, at specified times for re-evaluation.
Part 3 of the figure introduces problems and resolutions to problems. A Plan object may be connected to one or more Problem objects. A Multiple Problem object has one or more Problem objects as parts, where each of the Problem objects is connected to the same Plan object. The Problem class has four specializations: the Non-Conformance class, the Aircraft-Aircraft Conflict class, the Aircraft-Airspace Conflict class, and the Flow Instruction Non-Compliance class. Each Problem object is connected to up to ten Resolution objects, of which one is the highest-ranked resolution (i.e., the Resolution class has a specialization, the Highest-Ranked Resolution (HRR) class). A Resolution object is connected to one or two Machine Plan objects (i.e., a resolution to a problem can maneuver one or two aircraft).
The Resource Subject. Figure 4-15 ( a two-part figure) shows the Airspace/Ground Resource structure of the Resource subject for the AERA 2 model. Part 1 contains all of the Airspace/Ground Resource class structure except for the structure beneath the En Route Controlled Airspace class, which is found in part 2.
The Airspace/Ground Resource object has several parts: a Controlled Airspace object and one or more Airport Movement Area objects. The Airport Movement Area class has a specialization, the Airport class. The AERA 2 model provides only limited information about an Airport object, needed for trajectory modeling. The Controlled Airspace object has several parts, including an En Route Controlled Airspace object and several Terminal Controlled Airspace objects. A Terminal Controlled Airspace object has several parts: at least one Terminal Route object and at least one Terminal Airspace Volume object. The Terminal Route class has the STAR class and the Aircraft Descent Altitude Profile class as specializations, which are used by trajectory modeling. Since problem detection and resolution are not performed for that part of an aircraft trajectory in an approach control area or an Automated Problem Detection Inhibited Area (APDIA), the Terminal Airspace Volume class has the Approach Control Area class and the APDIA class as specializations.
Figure 4-15. AERA 2 Model: Resource Subject (Airspace/Ground Resource) (Part 1)
Figure 4-15. AREA 2 Model: Resource Subject (Airspace/Ground Resource) (Part 2)
An Airport object has instance connections with STAR, Aircraft Descent Altitude Profile, and APDIA objects. Only the lowest-level classes and objects in part 1 are specifically named by the AERA 2 CHI Prototype; the higher-level classes and objects and structure are borrowed from the ATC model.
An En Route Controlled Airspace object has Route objects and Airspace Volume objects as parts. The Route class has one specialization, the Victor/Jet Route class (similar to the Jet Route class and Airway class of the ATC model). A Route object has one or more Route Segment (called "Airway Segment") objects and Fix/Waypoint (called "Fix") objects as parts. The Airspace Volume class has specialization classes ACF Airspace (called "Planning Region"), Sector, Protected Airspace Volume (called "Blocked Airspace"), and Holding Pattern Airspace (called "Holding Pattern"). An ACF Airspace object also contains Sector objects as parts. The Protected Airspace Volume class has specialization classes Restricted Area, Heavy Weather Area, and Holding Pattern. The Holding Pattern Airspace class is a specialization of the Airspace Volume class because of the ATC model, and a specialization of the Protected Airspace Volume class because of the AERA 2 CHI Prototype. An aircraft is allowed to enter a blocked airspace only by permission.
An ACF Airspace ("Planning Region") object may have an instance connection with one or more Restriction objects, representing flow restrictions. The Metering Restriction class is a specialization of the Restriction class, and a Metering Restriction object is made up of Metering Slot objects. A Metering Restriction object has an instance connection with a Fix/Waypoint (called "Fix") object, because the metering restriction calls for aircraft to be "metered to" a particular fix, which is accomplished by assigning aircraft to metering slots.
In part 2 of figure 4-15, many of the classes and objects coincide with classes and objects from the ATC model, differing mostly in the precise definitions of the attributes and services.
Figure 4-16 shows the other resources of the Resource subject for the AERA 2 model. These other resources have only peripheral use. The Data Link Communications System class is a specialization of the Air/Ground Communications System class, which is a specialization of the Communications System class. A Communications System object is a part of a Communications Resource object. The Data Link Communications System class, which is the only communications resource-type class unique to the AERA 2 model, represents an automatic acceptance of a plan amendment by a data link-equipped aircraft.
An Aviation Weather Resource object is made up of Aviation Weather System objects, each of which is made up of one or more Wind/Weather Product objects. Each of these classes and objects are borrowed from the ATC model. A Wind/Weather Product class has two AERA 2 model-unique specializations, the Radar Weather Area class and the Wind class. A Radar Weather Area object is only used for display. A Wind object is made up of Horizontal Wind Layer objects, and is used by trajectory modeling.
The Manager Subject. Figure 4-17 shows the Manager subject for the AERA 2 model. The Manager class has the Flight Manager class as a specialization, and the AERA 2 model adds the En Route Controller as a specialization of the Flight Manager class. The AERA 2 CHI Prototype does not include traffic manager or vehicle manager capabilities.
Event View: Aircraft-to-Aircraft Conflict Detection and Resolution. Because of the AERA 2 emphasis on automated problem detection and resolution, the ATC views in section 3.2.4.3 are applicable to the AERA 2 model with minimal changes: change the manager names from "Flight Manager" to "En Route Controller" and remove clearance-type classes and objects. For example, figure 4-18 illustrates an AERA 2 model version of figure 3-12, Aircraft-to-Aircraft Conflict Detection and Resolution Event.
Figure 4-16. AERA 2 Model: Resource Subject (Other Resources)
Figure 4-17. AERA 2 Model: Manager Subject
Figure 4-18. AERA 2 Model View: Aircraft-to-Aircraft Conflict Detection and Resolution
At the beginning of the event, an En Route Controller object (called "En Route Controller 1") with an instance connection with the En Route Controlled Airspace object has been performing its service Detect, Predict & Report Separation Violation. A violation of separation minima is predicted between two IFR flights that are planned to be in the same sector at the same time. It is assumed that the two Flight objects now have instance connections to the same En Route Controller object, called "En Route Controller 2." En Route Controller 1 sends a message to En Route Controller 2, requesting the performance of the Separate IFR Flights service. In carrying out this service, En Route Controller 2 also performs the general service Generate & Deliver Clearance, requesting the pilot of one of the two Flight objects ("Flight 2") to perform its service Plan Flight. If the Plan Flight service determines that the proposed change to the flight plan cannot be accepted, then a negative response is returned to En Route Controller 2; otherwise, a positive response is returned and the Pilot object requests the Flight Plan object to amend itself. The attributes of the Flight Plan which are affected by the Amend Flight Plan service are determined by the actual amendment.
This view makes use of two (possibly) different En Route Controller objects. En Route Controller 1, for which the service Detect, Predict & Report Separation Violation is automated in the AERA 2 CHI Prototype, identifies an aircraft conflict. En Route Controller 2, in performing the service Separate IFR Flights, determines resolutions for the conflict (automated) and selects a resolution (manual) for implementation. The Flight 2 services Plan Flight and the message Request Amend Flight Plan are simulated, since the amendment is always accepted by the flight.
Table 4-2 compares the needed capabilities of the experiment with the available capabilities of TASF and AERA 2 legacy software. The first column lists the classes and objects, attributes, and services of the experiment model. The second and third columns list the corresponding model components of the TASF model and the AERA 2 model components. A dash "-" in a model column means that this model does not have a component corresponding to the one listed on the same line for another model. Attribute and service names are prefixed by "a" and "s," respectively, and italicized so that they are easier to distinguish from class and object names. Using this table, a direct comparison between experiment needs and legacy software capabilities can be made. Some obvious conclusions are as follows:
- Terminal capabilities are available only from TASF, and are not provided by AERA 2 software.
- En route capabilities are available only from AERA 2 software, and are not provided by TASF software.
- Neither TASF nor AERA 2 provide some needed capabilities, such as the RDP-Like En Route Surveillance System; the Arrival Clearance, Departure Clearance, and En Route Clearance; the Flight Plan; the Point; the Washington Area Airport; the Regional Air Traffic Manager; the Tower Controller; certain services of the Terminal Controller (Final Arrival Sequencing & Spacing, Coordinate Arrivals With Departures, and Accept/Initiate Handoff); and certain services of the En Route Controller (Compute/Issue Delay-Absorbing Maneuvers, Handoff Aircraft to Terminal Controller). These capabilities must be found elsewhere.
- For some experiment components, there are similar components in both the TASF model and the AERA 2 model, e.g., the Meter Fix and the Trajectory. In these cases, a more careful comparison is needed in order to determine which version of a component (if either) should be used.
Table 4-2. Experiment Capabilities vs. Legacy Software Capabilities
Experiment TASF AERA 2 90-Minute Flying Time Wedge En Route Controlled Airspace En Route Controlled Airspace a: Boundary a: Boundary Code a: Location s: None - - Aircraft-Aircraft Conflict - Aircraft-Aircraft Conflict a: Object Aircraft - a: Object Aircraft a: Start of Delay - a: Start of Delay a: End of Delay - a: End of Delay a: Subject Aircraft Start Location - a: Subject Aircraft Start Location : Object Aircraft Start Location - a: Object Aircraft Start Location a: (many more - refer to AERA 2 model) - a: (many more) s: None - - Aircraft-Airspace Conflict - Aircraft-Airspace Conflict a: Separation - a: Separation a: Minimum Miss Distance - a: Minimum Miss Distance a: Start Location - a: Start Location a: End Location - a: End Location a: Airspace Name - a: Airspace Name a: Airspace Type - a: Airspace Type s: None - - Arrival Clearance - - a: Approach Procedure (from ATC model) - - s: Amend Clearance (from ATC model) - - ARTS-Like Terminal Surveillance System ARTS III/ARTS III With Ghosting - a: Area of Coverage a: Area of Coverage - s: Provide User Interface s: Display Aircraft location - s: Provide TAAS Capabilities s: Project MLS Flight onto ILS Route (ARTS III With Ghosting only) - Data Link-Like Communications System Data Link Communications System Data Link Communications System a: Equipment Type (inherited) a: Type (Mode S/ACARS) - a: Status (inherited) a: Status - s: Provide Data Link-Like Services - - Departure Clearance - - a: Departure Procedure - - s: Amend Clearance - - En Route Clearance - - a: Route - - a: Altitude Profile - - a: Speed Schedule - - a: Holding Instructions - - a: Clearance Limit - - s: Amend Clearance - - En Route Controller En Route Flight Manager En Route Controller a: Area of Responsibility (inherited) - a: Sector Identification s: Identify Conflicts - s: Detect, Predict & Report Separation Violation (inherited) s: Detect, Predict & Report Restriction Violation (inherited)
s: Propose Resolutions - s: Assist in Flight Planning (inherited) s: Request Plan Amendment
s: Request New Plan Creation
s: Separate IFR Flights (inherited)
s: Ensure Restriction Compliance (inherited)
s: Compute Delay-Absorbing Maneuvers - s: Ensure Restriction Compliance (inherited) s: Issue Delay-Absorbing Maneuvers - s: Generate & Deliver Clearance (inherited) s: Handoff Aircraft to Terminal Controller - s: (see Trajectory) Experiment Scenario Traffic Pattern Air Traffic - a: Demand - - s: None - - Flight Plan Flight Plan Flight Plan a: Expected Meter Fix Time - - a: Expected Airport Arrival Time - - a: Flow Restriction Time - - s: None - - Flow Instruction Non-Compliance - Flow Instruction Non-Compliance a: None - - s: None - - Highest-Ranked Resolution - Highest-Ranked Resolution a: None - - s: None - - ILS-Like Landing Navigation System Instrument Landing System (ILS) - a: Location (La Guardia) a: Localizer Bearing a: Localizer Latitude
a:Localizer Longitude
- s: Provide ILS Data to Aircraft s: Provide Glide Slope to Aircraft Avionics s: Provide Distance to Aircraft Avionics
- ILS Route ILS Route - a: Location (La Guardia) a: Location (La Guardia) - s: None - - La Guardia Airport La Guardia Airport - a: Arrival Capacity - - a: Departure Capacity - - a: Runway Configuration - - a: Expected Departure Rate - - s: None - - Meter Fix Fix/Waypoint ("En Route Waypoint") Fix/Waypoint ("Fix") a: Location (En Route/Terminal Boundary) a: Waypoint Type a: Region Code
a: Flow Instruction a: Position (latitude/longitude)
a: Minimum/Maximum Altitude
s: Update Demand (inherited) - - s: Update Load (inherited) - - MLS-Like Landing Navigation System Microwave Landing System. (MSL) - a: Location (La Guardia) - - s: Provide MLS Data to Aircraft s: Provide x-y-z to Aircraft Avionics - MLS Route MLS Route - a: Location (La Guardia) a: Location (La Guardia) - s: None - - Multiple Problem - Multiple Problem a: None - - s: None - - New York TRACON New York TRACON - a: Boundary a: Criteria - s: None - - Pilot Pilot - a: None - - s: Receive/Implement Vectoring Instructions s: Accept Clearance Directives from Controller s: Maneuver Aircraft
- Point - - a: None - - s: None - - Problem - Problem a: Subject Aircraft - a: Subject Aircraft s: None - - RDP-Like En Route Surveillance System - - a: Area of Coverage - - s: Provide Radar Data Processing (RDP) Services for En Route Airspace - - Regional Air Traffic Manager - - a: None - - s: Impose Flow Instruction - - s: Create Metering Flow Restriction - - s: Sequence/Resequence Flights - - s: Adjust Flight Schedule - - Resolution - Resolution a: Aircraft Identification - a: Aircraft Identification a: Expiration Time - a: Expiration Time a: Maneuver Type - a: Maneuver Type a: Maneuver Parameters - a: Maneuver Parameters s: None - - Segment - State Segment a: Bearing - a: Bearing a: Acceleration - a: Acceleration a: Gradient - a: Gradient s: None - - Terminal Controller North, South, Departure, Final Approach Controller - a: None - - s: Accept/Initiate Handoffs s: Accept North Arrival Flights from En Route Flight Manager (North Controller) s: Accept South Arrival Flights from En Route Flight Manager (South Controller)
s: Accept Flights from Local Controller (Departure Controller)
- s: Coordinate Arrivals With Departures. - - - s: Space Aircraft on Departure Routes (Departure Controller) - s: Final Arrival Sequencing & Spacing s: Space Aircraft on Arrival Route (FinalApproach Controller) s: Issue Clearance Directives to Pilot (Final Approach Controller)
- Tower Controller - - a: None - - s: Coordinate Arrivals With Terminal Controller - - s: Coordinate Departures With Terminal Controller - - Trajectory - Trajectory a: None - - s: Trajectory Estimation - s: Trajectory Estimation - - s: Handoff Vehicle Navigation System Aircraft ILS Navigation System - a: Equipment Type a: Type (ILS) - s: Accept Navigational Guidance s: Localizer Detected s: Altitude Phase
s: Heading Phase
s: Speed Phase
s: Altitude Lock Phase
s: Altitude Lock Phase
s: Altitude Lock
s: Heading Lock s: Speed Lock
- s: Interrogate Navigational Aid - - Vehicle Navigation System Aircraft MLS Navigation System - a: Equipment Type a: Type (MLS) - s: Accept Navigational Guidance - - s: Interrogate Navigational Aid - - Voice Radio-Like Communications System Voice Radio Communications System - a: Equipment Type (Voice Radio-Like) a: Equipment Type (Voice Radio) - Washington Area Airport - - a: Runway Configuration - - a: Expected Departure Rate - - s: None - -