SSS Master 2/14 Edition

Center-TRACON Automation System Build 2

System Specification

Revised Draft, 14 February 1997

Prepared for:

Department of Transportation, Federal Aviation Administration

TATCA Program Office (AUA-540)

800 Independence Avenue, S.W.

Washington, D.C. 20591

Massachusetts Institute of Technology Lincoln Laboratory

TABLE OF CONTENTS

List of Illustrations viii List of Tables ix

1. SCOPE 1

1.1. Identification 1

1.2. System Overview 1

1.3. Document Overview 2

2. REFERENCED DOCUMENTS 4

3. REQUIREMENTS 17

3.1. Required States 17

3.2. System Capability Requirements 22

3.2.1. TMA Processing 26

3.2.1.1. Inputs & Outputs 27

3.2.1.2. Aircraft Processing 29

3.2.1.3. Route Analysis 30

3.2.1.3.1. Meter Fix Assignment 31

3.2.1.3.2. Stream Class Assignment 32

3.2.1.3.3. Runway Assignment 33

3.2.1.3.3.1. Identification of the Reallocation Procedure from Site Adaptation 35

3.2.1.3.3.2. Runway Search 35

3.2.1.3.4. TRACON Speed & Altitude Parameter Specification 36

3.2.1.3.5. Situation Categorization 36

3.2.1.3.6. Route Estimation 36

3.2.1.4. ETA Generation 38

3.2.1.4.1. Determination of Vertices 39

3.2.1.4.2. Determination of Horizontal Ground Track 42

3.2.1.4.3. Determination of the Vertical Profile Along the Ground Track 42

3.2.1.4.3.1. Vertical Profile in Center Airspace 42

3.2.1.4.3.2. Vertical Profile in TRACON Airspace 43

3.2.1.4.4. Variable Speed Crossing Restriction (VSCR) [deleted] 43

3.2.1.4.5. ETA Smoothing 44

3.2.1.5. Scheduling 44

3.2.1.5.1. Scheduling Using Time Based Metering 45

3.2.1.5.1.1 Separation at the Meter Fix 47

3.2.1.5.1.2. Separation at the Runway 49

3.2.1.5.1.3. Feedback from Runway Schedules to Meter Fix Schedules 50

3.2.1.5.1.4. Scheduling at the Outer Fix/Arc 51

3.2.1.5.2. Scheduling Using Automated Miles-in-Trail 52

3.2.1.5.2.1. Recommend Start and Stop Time 54

3.2.1.5.2.2. Recommend Stream Class Combinations into Super Stream Classes 55

3.2.1.5.2.3. Finalize the Miles-in-Trail Restrictions for Manually Set and "Lightly" Loaded Streams 55

3.2.1.5.2.4. Iterate the non-finalized Miles-in-Trail Settings to Meet the Requested AAR. 56

3.2.1.5.3. Adjacent Facility Metering 57

3.2.1.5.4. Arrival Plan Preview Capability 63

3.2.2. FAST Processing 65

3.2.2.1. Inputs & Outputs 66

3.2.2.2. Aircraft Processing 68

3.2.2.3. Generation of Unconstrained Trajectories and TAs 68

3.2.2.3.1. Calculate Analysis Category 70

3.2.2.3.2. Generate Unconstrained Trajectories for All DOFs 72

3.2.2.3.3. Select TA for Display 73

3.2.2.4. Sequencing 74

3.2.2.4.1. Rules for Pairwise Ordering 74

3.2.2.4.1.1. Rules for Ordering On a General Constraint 77

3.2.2.4.1.2. Rules for Ordering on a Final Constraint 78

3.2.2.4.1.3. Ordering on a Dependency Constraint 81

3.2.2.4.2. Applying the Ordering Rules 81

3.2.2.4.2.1. Establishing the Membership List for All Route Segments 82

3.2.2.4.2.2. Sequencing Aircraft on any Segment 82

3.2.2.5. Scheduling at the Runway 83

3.2.2.6. Global Constraint Resolution 84

3.2.2.7. Runway Reassignment 86

3.2.2.7.1. Determine a Candidate Aircraft-Runway Pair for Reassignment (Short Cycle). 87

3.2.2.7.2. Alternate Global Conflict-minimized Trajectory Analysis (Long Cycle) 89

3.2.2.7.3. Select Either the Current or Alternate Arrival Plan (Long Cycle) 89

3.2.2.7.4. Modify Accepted Runway Reallocation by "Switch Criteria" 90

3.2.3. TMC Graphical User Interface 92

3.2.3.1. Inputs & Outputs 93

3.2.3.2. Display Presentation 94

3.2.3.2.1. Timeline Display 95

3.2.3.2.2. Load Graph Display 95

3.2.3.2.3. Plan View Display 95

3.2.3.2.4. Statistical Calculations 95

3.2.3.3. Display Definition 97

3.2.3.4. Parameter Interaction 97

3.2.3.5. Data Retrieval 100

3.2.3.6. Display Interaction 100

3.2.4. Monitor & Control 101

3.2.4.1. Inputs & Outputs 102

3.2.4.2. Monitoring 103

3.2.4.3. Control 103

3.2.4.4. Diagnostics 103

3.2.4.5. Maintenance of System Log 103

3.2.5. Data Management (DM) 104

3.2.6. Adaptation, Validation, and Analysis 104

3.2.6.1. Adaptation 105

3.2.6.1.1. Inputs & Outputs 105

3.2.6.1.2. Data Processing 106

3.2.6.2. Validation 106

3.2.6.3. Analysis 106

3.2.7. Data Analysis 107

3.2.8. Playback 107

3.2.9. Simulation 107

3.3. System External Interface Requirements 108

3.3.1. Interface Identification and Diagram 108

3.3.2. HCS Interface 110

3.3.3. ARTS Interfaces 111

3.3.3.1. ARTS GateWay 111

3.3.3.2. STARS Interface 111

3.3.3.3. ARTS Data Gatherer 111

3.3.4. ETMS Interface 112

3.3.4.1. ETMS Weather Interface 112

3.3.4.2. ETMS Center/TRACON Traffic Data 112

3.3.4.3. ETMS PGUI Display on TSD 112

3.3.5. Adjacent Facility CTAS Data I/O Interfaces 113

3.3.5.1. Adjacent Center CTAS Data I/O Interface 113

3.3.5.2. Adjacent TRACON CTAS Data I/O Interface 113

3.3.6. Adjacent Facility User I/O Interfaces 114

3.3.6.1. Adjacent Center Facility User I/O Interface 114

3.3.6.2 Adjacent TRACON Facility User I/O Interface 114

3.3.6.3 Tower CTAS User I/O Interface 115

3.3.7 AMCC Interface for a Center CTAS Installation 115

3.4. System Internal Interface Requirements 115

3.5. System Internal Data Requirements 115

3.6. Adaptation Requirements 116

3.7. Safety Requirements 118

3.8. Security and Privacy Requirements 118

3.9. System Environment Requirements 119

3.10. Computer Resource Requirements 119

3.10.1. Computer Hardware Requirements 119

3.10.2. Computer Hardware Resource Utilization Requirements 120

3.10.3. Computer Software Requirements 120

3.10.4. Computer Communication Requirements 120

3.11. System Quality Factors 121

3.11.1. System Functionality 121

3.11.2. System Reliability 121

3.11.3. System Maintainability 121

3.11.4. System Availability 122

3.11.5. System Flexibility 122

3.11.6. System Portability 122

3.11.7. System Reusability 122

3.11.8. System Testability 123

3.11.9. System Usability 123

3.12. Design and Construction Constraints 123

3.13. Personnel-Related Requirements 123

3.14. Training-Related Requirements 123

3.15. Logistics-Related Requirements 123

3.16. Other Requirements 123

3.17. Packaging Requirements 123

3.18. Precedence and Criticality Requirements 123

4. QUALIFICATION PROVISIONS 124

5. REQUIREMENTS TRACEABILITY 125

6. NOTES 126

6.1. Acronyms 126

6.2. Glossary 133

APPENDIX A. SOURCE OF REQUIREMENTS 151

APPENDIX B. Antecedent and consequence functions for
ordering rules in fast 154

List of Illustrations

Figure 3.1-1. Operational System State Transition Diagram 19

Figure 3.2-1. CTAS Generic Installation 24

Figure 3.2.1-1. TMA Function 26

Figure 3.2.1.5.3-1. CTAS Near a Center Boundary 57

Figure 3.2.1.5.3-2. Calculation of Coordination Fix STA 59

Figure 3.2.1.5.3-3. Assignment of Adjacent Facility Aircraft to an Adapted
"In-range" Coordination Fix 60

Figure 3.2.1.5.3-4. Stream Classes Entering the CTAS Center 61

Figure 3.2.1.5.3-5. Calculation of Miles-in-Trail Recommendation 62

Figure 3.2.1.5.4-1. Preview Capability 63

Figure 3.2.2-1. FAST Function 65

Figure 3.2.2.3.2-1. An Example Analysis Packet 73

Figure 3.2.2.4.1.1-1. Fuzzy Rules on a General Constraint 78

Figure 3.2.2.4.1.2-1. Fuzzy Rules on a FINAL Constraint 79

Figure 3.2.2.7.4-1. Double Over the Top Switch Criteria 91

Figure 3.2.3-1. TMC-GUI Function 92

Figure 3.3.1-1. Diagram of Interfaces for Generic CTAS Installations 109

Figure B-1. Membership Function for "Causes Less Delay" 155

Figure B-2. Membership Functions for "Is Slightly Delayed", "Is Delayed"
and "Is Significantly Delayed". 155

Figure B-3. Membership Functions for "Is Out of Delay" and
"Is Significantly Out of Delay" 155

Figure B-4 . Membership Functions for "Is Slightly Ahead at FCTS,
"Is Ahead at FCTS", and "Is Significantly Ahead at FCTS" 156

Figure B-5. Membership Function for "Is Ahead Along Downwind" 156

Figure B-6. Membership Function for "Is Currently Ahead" 156

Figure B-7. Membership Function for "Is Faster at FCTS" 157

Figure B-8. Membership Function for "Is Currently Lower" 157

Figure B-9. Membership Function for "Have In-trail ETAs" 157

Figure B-10. Membership Function for "Have In-trail Tracks" 158

Figure B-11. Membership Function of "Is Close" 158

Figure B-12. Consequences for Describing One Aircraft Being "AHEAD" 158

Figure B-13. Membership Function for the Antecedent "Lower Than" 159

Figure B-14. Consequence for Aircraft A is MARGINALLY AHEAD 160

Figure B-15. Evaluation of all Consequences in Favor of A and B 160

List of Tables

Table 2-1. FAA Development/Acquisition Documents 4

Table 2-2. ATM-IPT Specific Documents 6

Table 2-3. External System Documents, En Route Automation, HCS General 7

Table 2-4. External System Documents, En Route Automation, HCS/CTAS Patch 10

Table 2-5. External System Documents, En Route Automation, HCS/ATM 11

Table 2-6. External System Documents, En Route Automation, HID/NAS LAN 11

Table 2-7. External System Documents, Terminal Automation 12

Table 2-8. External System Documents, Enhanced Traffic Management System (ETMS) 15

Table 3.1-1. Operational System States 18

Table 3.2-1. Operational & Support Functions 22

Table 3.2.1.3.6-1. Route Estimate Generation 37

Table 3.2.2.3.1-1. Unconstrained DOF Settings 72

Table 3.2.4.1-1. M&C Inputs 102

Table 3.2.4.1-2. M&C Outputs 102

Table 3.2.6.1.1-1. Inputs to AVA 105

Table 3.3.1-1. Required External Interfaces 108

Table A-1. Requirement Information Sources 151

1. SCOPE

1.1. Identification

The Center-TRACON Automation System (CTAS) is being developed by the Federal Aviation Administration (FAA) under its Air Traffic Management-Integrated Product Team (ATM-IPT). According to the Plan for Development and Deployment of Air Traffic Management Functionality, the activities of the ATM-IPT are intended to result in a decision support system that will enhance the capacity and efficiency and maintain the safety of the National Airspace System (NAS).

CTAS is the result of prototyping efforts that were demonstrated at the Denver and Fort Worth Air Route Traffic Control Centers (ARTCCs) and Terminal Radar Approach Controls (TRACONs) through a cooperative effort conducted principally by the FAA, NASA Ames Research Center, and Massachusetts Institute of Technology Lincoln Laboratory. CTAS Build 1, the first build of CTAS, has been installed at Denver, Miami, Los Angeles, and Atlanta. This document specifies the requirements for CTAS Build 2, herein referred to as CTAS or the System.

CTAS is intended to be inter-operable with other ATM products, including the Enhanced Traffic Management System (ETMS), the Automated En Route Air Traffic Control (AERA) system, and the Surface Movement Automation (SMA) system. In the future, these ATM products will be upgraded on an as-needed basis to be compatible with National Airspace System (NAS) improvements such as the Display System Replacement (DSR) and the Standard Terminal Automation Replacement System (STARS).

1.2. System Overview

The System provides computer automation to enhance the arrival/departure throughput and efficiency of air traffic operations in the extended terminal airspace surrounding major airports. The end users of the System are Traffic Management Coordinators (TMCs) and Controllers in both ARTCCs and TRACONs. The TMCs interact directly with the System via display and input devices added into the Traffic Management Unit (TMU). Controllers interact indirectly with the System via the existing en route or terminal Air Traffic Control (ATC) automation systems (e.g., HCS and ARTS).

The System's mission is to more efficiently utilize the available airport capacity without decreasing safety or increasing controller workload. It accomplishes this by providing automation aids to assist in optimizing:

a. The flow of traffic to adapted airports (i.e., airports for which adaptation data are available) within the ARTCC/TRACON.

b. The flow of aircraft departing from an in-Center or in-TRACON airport destined for adapted airports.

c. The use of the available runways and surrounding airspace.

The implementation of the System will result in other benefits such as fuel savings from reduced delays.

CTAS consists of two major operational capabilities: the Traffic Management Advisor (TMA) used in the ARTCC, TRACON and Tower, and the Final Approach Spacing Tool (FAST) used in the TRACON. Both TMA and FAST calculate arrival schedules in real time based on: a) flight plan and track information received from NAS components, including National ATM automation (ETMS), En-Route Automation (HCS) and Terminal Automation (ARTS, STARS, etc.), and b) information entered by the TMCs and controllers about airport configuration, required wake vortex separation and whether IFR or VFR rules apply to arrivals.

The TMA provides TMCs with tools to coordinate the arrival traffic flow by graphically depicting the traffic demand and arrival schedules to the adapted airport(s). Graphic displays of arrival and delay information can be customized on an individual facility and user basis. CTAS-assigned fix/arc crossing times of arrival aircraft and delays to be absorbed are displayed on color workstations in the Traffic Management Unit (TMU). When enabled by the TMC, this information is displayed by the Host Computer System (HCS) in meter lists on the ARTCC controller 's Plan View Displays (PVDs), and ultimately on DSR consoles.

FAST optimizes aircraft landing sequence and runway assignments in the TRACON to assist in the merging and spacing of aircraft to the runway. FAST generates a landing sequence number and runway assignment for each aircraft, and sends these advisories to the Automated Radar Terminal System (ARTS) for display to TRACON controllers in the aircraft data block. Until the introduction of new terminal displays, the full FAST capability for controllers will be available only at sites which are equipped with Full Digital ARTS Displays (FDADs).

The FAST system which produces sequence number and runway assignment advisories on FDADs is sometimes referred to as "Passive FAST" to distinguish it from "Active FAST" which additionally produces speed and vector advisories. Build 2 will incorporate Passive FAST, herein referred to as FAST.

Details regarding the CTAS operational concept may be found in the CTAS Build 2 Operational Concept document.

1.3. Document Overview

This document establishes the characteristics, performance, development, and verification requirements for the System.

The document follows the Data Item Description (DID) for the System/Subsystem Specification (SSS) as detailed in MIL-STD-498.

The convention for stating system requirements or "SHALLs" in this document is to capitalize and number each SHALL. An example is: "When requested, the System SHALL [20], etc." If a requirement has siblings, they are listed as part of the top-level or parent requirement. In the example, if requirement 20 has three siblings, those are listed as a, b, and c under requirement 20. In a Verification Requirements Traceability Matrix (VRTM), the requirement in the example would therefore have four requirements associated with it: 20, 20a, 20b, and 20c.

The System requirements, especially the algorithm requirements, are augmented with expository detail which some might construe to be excessive for an SSS document. This detail is intentionally included to reflect the algorithms embodied in the NASA Ames prototype, thus providing the background and rationale for the requirements.

2. REFERENCED DOCUMENTS

Table 2-1. FAA Development/Acquisition Documents

Reference Number	Reference Title	Applicability
AD-A226 707	A Glossary of Terms, Definitions, Acronyms and Abbreviations Related to the National Airspace System (NAS).	Official FAA definition of "alarm" and "alert".
MIL-STD-498	Software Development and Documentation, Department of Defense, 5 December 1994.	Military Standard for Software Development and Documentation.
FAA-STD-025b	Preparation of Interface Documentation.	FAA Standard for Producing Interface Requirement Documents.
FAA-STD-028	Contract Training Programs.
FAA Order 1800.58	National Airspace System Integrated Logistics Support (NAILS) Policy.
RFC 1098	"Simple Network Management Protocol (SNMP) Version 2", SNMP V2 Group, University of Twente, 1994.	A software protocol for monitoring local area networks and their components such as processors, servers and routers.
ISO 8859-1	International Standard: Information Processing -8-Bit Single-Byte Coded Graphic Character Set - Part 1: Latin Alphabet No. 1.	ISO 8859-1 specifies a set of 191 printable characters.
ANSI/IEEE 754	Standard for Binary Floating-Point arithmetic and data types.	IEEE Floating Point Format.
IEEE Std 1003.1	Portable Operating System Interface Part 1. Library Routines, System Calls, and Header Files.	Defines the POSIX Compatible Operating System.
IEEE Std 1003.2	Portable Operating System Interface Part 2. Shells and Utility Programs.	Defines the POSIX Compatible Operating System.
XPG4 CAE	X/Open Portability Guide, Issue 4 for a Common Applications Environment (DAE).	XPG4 CAE Standard. Defines components of the operating system and their functionality.
SVID3	System V Interface Definition, Third Edition.	SVID3 Standard specifies the operating system environment for the source-code interface and run-time behavior of each operating system component.
SVR4 ABI	System V Release 4 Application Binary Interface.	SVR4 ABI Standard defines a standard format for application programs that are compiled and packaged for different hardware architectures.
X11R5	X-Window Version 11 Release 5.	Standard for the distributed window system originally designed by MIT.
ICCCM Version 1.0	Inter-Client Communic.ation Conventions Manual	Standard that defines the X environment.
OSF/Motif 1.2.2	Open Software Foundation - User Interface Toolkit.	Defines an Open Systems Foundation graphics toolkit.
ANSI/ISO 9899-1990	ANSI Standard for the C Programming Language.	The ANSI/ISO C standard which is currently accepted.
C++ ARM Pre-Standard	The Annotated C++ Reference Manual by Margaret A. Ellis & Bjarne Stroustrup (Addison-Wesley Publishing Company).	The basis of the ANSI/ISO C++ standard which is still under development.
RFC 791	Internet Protocol.	Internet addressing and packet definition. The lower level half of the TCI/IP standard.
RFC 793	Transmission Control Protocol (TCP).	Standard that defines reliable stream based communication between processors. The higler level half of the TCP/IP standard.
RFC 950	File Transfer Protocol.	Protocol covering network file transfers associated with the transfer of weather data.
RFC 1305	Network Time Protocol.	This protocol synchronizes processor clocks across a network.
PPP	Point-to-Point Protocol.	Standard that defines a protocol for sending IP packets over point-to-point serial links.
FIPS PUB 158	Federal Information Processing Standard Publication 158.	A U. S. government standard defining a set of tools for developing user interfaces in an X window environment.
FIPS PUB 160	Federal Information Processing Standard Publication 160.
FAA-G-2100G	Electronic Equipment, General Requirements.
FAA Order 1810.6	"Policy for Non-developmental Items (NDI) in FAA Acquisitions", 13 Nov 1992.

Table 2-2. ATM-IPT Specific Documents

Reference Number	Reference Title	Applicability
	Plan for Development and Deployment of Air Traffic Management Functionality, Version 1.0, September 1, 1996.	The mission statement for the ATM IPT.
	Traffic Flow Management (TFM) Operational Requirements Document (ORD) AUA-500, September 20, 1995.
	TFM Domain Definition, Volpe/Stanford Telecommunications for AUA-500, April 29, 1996.
	Human-Computer Interface Requirements for FAA Traffic Flow Management Applications, Mitre/CAASD for ATM-510, ASE-100, July 1995.
	CTAS Build 2 Operational Concept Document.	Describes CTAS Build 2 Operational Usage.
	ATM CHI Document.	Details Human Factor Requirements Across the ATM IPT.
	CTAS Build 2 CHI Requirements Document.	Details CTAS Build 2 Human Factor Requirements.

Table 2-3. External System Documents, En Route Automation, HCS General

Reference Number	Reference Title	Applicability
NAS-MD-310	Introduction to Specification Series.
NAS-MD-311	Message Entry and Checking.	Appendix E describes message fields referred to in message definition documents.
NAS-MD-312		Describes the route of flight field included in the flight plan and other messages.
NAS-MD-313	Flight Plan Position Processing and Beacon Code Assignment.	Describes why ACID alone or beacon code alone are not sufficient flight identifiers for use in automation processing flights. Describes criteria for dropping flights from Host flight database -- this has implications for CTAS’s use of the remove strip (formerly RS) message.
NAS-MD-314	Local Outputs.	Describes metering list as shown to R-controller. CTAS Build 2 displays a metering list.
NAS-MD-315	Remote Outputs.	The NAS to ARTS section describes messages that the interfacility portion of the ARTS data gatherer will receive. This is useful for the ARTS-to-ARTS-through-NAS messages (these are not picked up by the NAS patch). These messages provide data to CTAS on Tower En Route Control (TEC) aircraft.
NAS-MD-316	Adaptation.	The adaptation data process in Host, which is of great interest to CTAS.
NAS-MD-317	Monitor.	Describes the operating system of Host, which contains the device drivers. I/O between Host and CTAS uses device drivers, either modified INTI and INTO for PAMRI emulator, or new device drivers for HID. Startup/switchover and system analysis recording (SAR) also in this volume. Replacement of operational elements, which was relevant to PAMRI Emulator approach and to HID approach also included.
NAS-MD-318	Performance Criteria.	Describes performance criteria for Host. These must not be exceeded by CTAS modifications, and form part of the non-interference testing criteria for CTAS Host modifications.
NAS-MD-319 placeholder	not used
NAS-MD-320	Multiple Radar Data Processing.	Describes the data (and limitations) in the track messages received by CTAS.
NAS-MD-321	Automatic Tracking.	Describes the data (and limitations) in the track messages received by CTAS.
NAS-MD-322	Real Time Quality Control of Radar Data.	Describes the data (and limitations) in the track messages received by CTAS.
NAS-MD-323	Dynamic Simulation of Radar Data.	Describes DYSIM tracks, and explains why they might be useful in training controllers to use CTAS, and why the DYSIM tracks must not be mixed in with actual tracks in operational meter lists.
NAS-MD-324	Display Channel Interface Requirements.	Describes the relative priority of the meter list with other components of display to R-controllers.
NAS-MD-325	Software Design Requirements.	These apply to the organiza-tions participating in Host code modification.
NAS-MD-326	Adaptation Collection Guideline.	Adaptation data of interest to CTAS
FIPS PUB 60	Federal Information Processing Standard Publication 60.		Defines the Host channel to which the HID-LAN is connected.
NAS-SR-1000	National Airspace System Requirements.	Details the reliability requirements for an "essential system" including CTAS.
	National Airspace Infrastructure Management System (NIMS).	Describes the Monitor and Control of all FAA operational systems via an interface to the NIMS system.
FAA Order 6040.15C	National Airspace Performance Reporting System (NAPRS).	Describes the Official Format for NAPRS Reporting.
NAS-IR-yyyyyyyy	Interface Requirements Document, Automated Maintenance Control Center (AMCC) to Center-TRACON Automation System (CTAS) Build 2.	Interface between the CTAS System Monitor and Control (SMC) and the Automated Maintenance Control Center (AMCC).
NAS Change Proposal/Casefile UA500-CPF-001	"Modification of HCS Software to provide an HCS/Air Traffic Management Common Interface", AUA-540, June 24, 1996.
	"Interface Requirements Document, ARTCC Host Computer System / Air Traffic Management Applications (CTAS, ETMS, AERA)", AUA-TAC for AUA-500, 10/31/96.
	Host Computer System Functional Requirements to Accommodate ATM Applications", AUA-TAC for AUA-500, 8/28/96.
	"Catalog of CTAS Build 2 Adaptation Databases" Wyndemere, Inc.	Describes the AVA produced adaptation for CTAS Build 2.
	"NFDC Database Record Layouts", National Flight Data Center.	Defines the data format of NFDC tapes. This is used by AVA as a starting point for site adaptation.
none	En Route Architecture Team Study Findings, May 16, 1996.	Describes the automation environment into which CTAS must integrate, including time-phased development of En Route infrastructure and other User Benefit Applications.

Table 2-4. External System Documents, En Route Automation, HCS/CTAS Patch

Reference Number	Reference Title	Applicability
FAA Order 7110.65	Air Traffic Controllers' Handbook.	This document lists all the separation requirements which CTAS must obey as it produces arrival schedules.
	HCS/CTAS TMA IRD
NAS Change Proposal/Casefile CT200-CPF-315	"Two-way interface for CTAS, with display drivers, for ZDV and ZFW", May 30, 1995.
	"Interface Requirements Document, ARTCC Host Computer System/CTAS Traffic Management Advisor".
	"Host Computer System (HCS) Functional Requirements to Accommodate the Traffic Management Advisor of the Center-TRACON Automation System".

Table 2-5. External System Documents, En Route Automation, HCS/ATM

Reference Number	Reference Title	Applicability
ATM-IRD-001	"ARTCC Host Computer System (HCS) / Air Traffic Management (ATM) Applications (CTAS, ETMS, AERA) Interface Requirements Document".	Describes the interface between the Host and the ATM-LAN.

Table 2-6. External System Documents, En Route Automation, HID/NAS LAN

Reference Number	Reference Title	Applicability
NAS-IR-90062819	"Interface Requirements Document for the HID-LAN".	Interface requirements for the HID/NAS-LAN.
NAS-IR-82179015	"ARTCC Host Computer System (HCS) to Host Interface Device (HID) IRD".
NAS-IR-40100001	"ARTCC NAS LAN/User System IRD", 12/21/95.
	"Preliminary Network System Management Interface Requirements Specification for Host Datalink", Camber Corporation for CSC, 2/27/95.
	"Software User's Manual for the HID LAN", Camber Corporation for CSC, 4/28/96.
	"Computer Systems Operator's Manual for the HID LAN, Camber Corporation for CSC, 4/28/96.
	ARTCC NAS LAN / end user IRD.

Table 2-7. External System Documents, Terminal Automation

Reference Number	Reference Title		Applicability
NAS Change Proposal/Casefile Number UA540-AR3E-001	"ARTS IIIE to CTAS/Passive FAST Interface Requirements Document", 7/12/96.
NAS-IR-90068219	"ARTS IIIE to CTAS/Passive FAST Interface Requirements Document", Revision B, 2/10/97.		The communications between the ARTS-IIIE and the CTAS FAST Environment.
	"Design Document for the Incorporation of the Final Approach Spacing Tool (FAST) of the Center-TRACON Automation System (CTAS) into ARTS IIIE," Lockheed Martin, September 30, 1996.		Describes the changes to the ARTS-IIIE system required for the interface to CTAS.
NAS Change Proposal/Casefile Number (TBS)	"ARTS Data Gatherer (ADG) at Atlanta", ACT-250.
ATC-21000	ATC Hardware Design Data.		Describes the channel on the ARTS to which the TIU attaches.
ATC-23000	ARTS IIIA Systems Design Data.		Describes the requirements for the ARTS IIIA, including the software.
SB 10205	Input/Output Channel Characteristics Input/Output Processor (IOP).		Specification of the Type A channel.
NAS-MD-631	NAS En Route Stage A -ARTS IIIA, for the current release.
NAS-MD-632	Conflict Alert Adaptation Standards and Guidelines.
NAS-MD-633	Standards for Defining and Adapting Values for MSAW Site Variables.
NAS-MD-634	System Description and Specification Series.
NAS-MD-635	Multiprocessor Executive (MPE).		This is the operating system in the ARTS IIIA. This real time scheduled machine uses a set of cyclic executives.
NAS-MD-636	Parallel SRAP Processing.		Describes the radar data input to ARTS.
NAS-MD-637	Target Processing (Tracking) and Inter-Sensor Linking.		Tracking, especially the way displays are connected to single sensor’s data, quite in contrast to the mosaic technique used in Host/En Route.
NAS-MD-638	Keyboard.		Keyboard messages, they are received by CTAS from ARTS.
NAS-MD-639	Display Output Processing.		What gets put on the display by ARTS.
NAS-MD-640	Interfacility Data Transfer.		Describes the interfacility data passed between en route Center and ARTS. Useful for understanding interfacility portion of ARTS data gatherer data. Needed for Tower En Route Control (TEC) aircraft.
NAS-MD-641	Bulk Store Flight Plan.
NAS-MD-642	ASR-37 Non-Executive Error and Status Messages.
NAS-MD-643	Site Adaptation.
NAS-MD-644	MSAW and Altitude Tracking.
NAS-MD-645	Non-Executive Console Teletype Input Processing and On-Call Tasks.
NAS-MD-646	Builder/BUP and CDR Editor.
NAS-MD-647	Recovery.
NAS-MD-648	Continuous Data Recording Processing.
NAS-MD-649	Remote Display Processing.
NASP-2501-05	ARTS IIIA Systems Operators Manual.
	ARTS IIIA Program Coding Specifications, Vol. 1.
	ARTS IIIA Program Coding Specifications, Vol. 2.
	ARTS IIIA Program Coding Specifications, Vol. 3.		Describes the Central Track store, which is the track and related data given to CTAS by ARTS. Also, the data tables which allow CTAS to know which console serves which controller position for use in interpreting keyboard messages, track data, sending datatag augmentations, etc.
	Specification for a Modification of the ARTS Input/Output Processor (IOP) Software for the Final Approach Spacing Tool.		The software changes to ARTS IIIA for CTAS.
DOT FAA Mike Monroney Aeronautical Center FAA Academy C-50022, C-50025	NAS ARTS III and ARTS IIIA Operations and Procedures.
DOT FAA Mike Monroney Aeronautical Center FAA Academy, 42033-1	ARTS System Introduction.
NAS-IR-90060001	Automated Radar Terminal System (ARTS) IIIA Common Interface to User Systems, Part 2: Common Message Suite.
E053, ATC 31223	New York TRACON Software Product Specification, Appendix II - Software Detailed Design Document, Volume 3, Stroke Display Controller.		This ARTS IIIE document describes part of the full digital ARTS display (FDAD). The FDAD modification was made possible by the FDAD design described in this document.
	"Documentation of FDAD modifications required for CTAS", Magnavox.		Description of the FDAD software modification.
FAA-E-2747	New York TRACON Full Digital ARTS Display Technical Specification.		Specification for FDADs
ATC 60060 Lockheed Martin			Describes the Micro Common Processor.
FAA-E-STARS	NAS Subsystem Level Specification for the Standard Terminal Automation Replacement System (STARS).		The Subsystem Level Specification for the STARS procurement.
	"TRACON Map Definition", Department of Commerce, National Oceanic and Atmospheric Administration.	Defines the electronic format for TRACON Video Maps used by AVA.

Table 2-8. External System Documents, Enhanced Traffic Management System (ETMS)

NAS-MD-313	Flight Plan Position Processing and Beacon Code Assignment.	Describes why ACID alone or beacon code alone are not sufficient flight identifiers for use in automation processing flights. Describes criteria for dropping flights from Host flight database -- this has implications for CTAS’s use of the remove strip (formerly RS) message.
NAS-MD-314	Local Outputs.	Describes metering list as shown to R-controller. CTAS Build 2 displays a metering list.
NAS-MD-315	Remote Outputs.	The NAS to ARTS section describes messages that the interfacility portion of the ARTS data gatherer will receive. This is useful for the ARTS-to-ARTS-through-NAS messages (these are not picked up by the NAS patch). These messages provide data to CTAS on Tower En Route Control (TEC) aircraft.
NAS-MD-316	Adaptation.	The adaptation data process in Host, which is of great interest to CTAS.
NAS-MD-317	Monitor.	Describes the operating system of Host, which contains the device drivers. I/O between Host and CTAS uses device drivers, either modified INTI and INTO for PAMRI emulator, or new device drivers for HID. Startup/switchover and system analysis recording (SAR) also in this volume. Replacement of operational elements, which was relevant to PAMRI Emulator approach and to HID approach also included.

3. REQUIREMENTS

3.1. Required States

The System's capabilities fall into two categories, Operational and Support. The Operational capabilities provide the ability to conduct the live ATC mission of CTAS in an operational environment, and the Support capabilities provide a number of off-line support functions. The state requirements in this section apply only to the Operational capabilities and not to the Support capabilities.

The Monitor & Control (M&C) function, which is detailed in Section 3.2.4, provides the overall system management and control of the Operational System (i.e., it manages the computational assets of the Operational System). Requirements 0010 through 0022 are general M&C requirements, with detailed requirements found in Sections 3.2.4. and 3.11.

During a live operation in the field, the System SHALL [0010] monitor and control the System's hardware and software resources.

Whenever hardware or software faults or degradation in operation occur, the System SHALL [0012] indicate this condition to maintenance personnel.

Whenever displayed data are faulty, out of date or degraded, the System SHALL [0014] indicate this condition to air traffic users.

The System SHALL [0020] include the ability to automatically reconfigure the system whenever hardware or software failures occur.

The System SHALL [0022] include the ability to manually reconfigure the system in the event that automatic reconfiguration fails.

In order to meet the above requirements, the System is required to have the set of Operational States as listed in Table 3.1-1. These states reflect the condition of the application processes that carry out the CTAS operational functions. Each application process is classified as either an "essential process" or a "non-essential process", and as either a "restartable process" or a "non-restartable process".

An essential process is defined as a process which, if it failed and could not be restarted, would destroy the usefulness of CTAS as an operational system. For example, route analysis would be an essential process, since CTAS could not proceed without it. On the other hand, weather data acquisition would be a non-essential process, since CTAS could continue to use older weather data or revert to Standard Atmosphere backup files.

Table 3.1-1. Operational System States

State Name	Description
Off	No software is executing.

Standby	M&C is ready to control & monitor the application.

Initialize	Transitional state where the application processes are being initialized. If successful for all essential processes within the allotted time, the system transitions automatically to the Run State. If not, it transitions to the Recovery State.

Run	The full-up system is operating normally.

Recovery	Transitional state which attempts to restore the failed process(es) and return the application to either the Run State if successful, or the Reduced State if not successful and the process involved was non-essential, or the Standby State if not successful and the process involved was essential.

Reduced	The system is operating in a reduced or degraded manner (i.e., one or more non-essential processes are not running).

A re-startable process is defined as a process that can be re-initialized while the system is operating (including a "fail-over" to another machine) to the state it had no more than an adaptable amount of time prior to the failure. Except for the M&C function itself, all processes are intended to be restartable.

Figure 3.1-1 depicts the transitions between the Operational States of the system. Some states represent semi-permanent operational states (such as Off, Standby, Run and Reduced) and others are transitional states (such as Initialize and Recovery).

An application process is always in one of the following modes:

• Stopped (process not running),

• Initializing (process is initializing), or

• Running (process is running).

Figure 3.1-1. Operational System State Transition Diagram.

The M&C process will monitor the health of each individual process to see whether or not it has to declare a process failure. For each process, the adaptation prescribes several allotted times within which the process must accomplish a task:

• "Initialization Time" (e.g., 30 seconds) for process initialization to be completed.

• "Stable Time" (e.g., 10 seconds) for the maximum time allowed for a status response to an M&C status query (after which M&C declares the process delayed).

• "Delayed Time" for the maximum response time delay allowed (e.g., 20 seconds) before M&C declares a process failure.

• "Off-line Time" (e.g., 5 seconds) for the maximum time between receipt of a shutdown instruction and process exit before the process is forcibly terminated.

Process failures are important trigger events causing System State transitions. Note that these process failures can either be triggered by hardware or software faults.

The System SHALL [0025] declare a process to be failed if any of the following occur:

a. The process terminates due to an error condition.

b. The process fails to respond to a status query within the adaptable delay time.

c. The process is forcibly terminated because it failed to terminate within the adaptable off-line period following a shutdown instruction.

As depicted in Figure 3.1.1-1, the M&C of the Operational System is initialized from the Off state.

From the Off state, the Operational System SHALL [0030] enter the Standby state in which the M&C function executes, and gets ready to manage and control the application.

Upon entering the Standby State, the Operational System SHALL [0035] determine from adaptation data whether each process is:

a. an essential process or non-essential process, and

b. a restartable process or a non-restartable process.

In the Standby State, the pushing of the Start CTAS button on the M&C interface SHALL [0036] cause the System to transition to the Initialize State, where it attempts to initialize all processes.

If the System can initialize all its essential processes within the initialization time for each essential process, the System SHALL [0045] transition to the Run State.

If the System cannot initialize one or more essential processes within the allotted time, then the System SHALL [0046] transition to the Recovery State.

Requirements 0040 and 0050 have been deleted.

While in the Run State, a transition of the Operational System to the Recovery State SHALL [0060] occur whenever:

a. process failure is detected, or

b. a non-essential process fails to initialize within the allotted time.

If the failed process is restartable and can be restored within the adaptable process initialization time, a transition from the Recovery State to the Run State SHALL [0061] occur.

If the failed process is an essential process and cannot be restored within the allotted time, then a transition from the Recovery State to the Standby State SHALL [0062] occur.

If the failed process is a non-essential process and cannot be restored within the allotted time, then a transition from the Recovery State to the Reduced State SHALL [0063] occur.

While in the Reduced state, a transition of the Operational System to the Recovery state SHALL [0070] occur whenever a new failure is detected.

While in the Run state or in the Reduced state, each restartable process of the Operational System SHALL [0080] be capable of being restored to the state it had no more than an adaptable time (e.g., 10 seconds) prior to the failure.

Requirements 0090, 0100, 110, 120 and 130 have been deleted.

A failure in the M&C function itself in any state SHALL [0140] cause the transition of the Operational System to the Off state.

While in either the Run or Reduced States, the pushing of the CTAS Stop button on the M&C interface SHALL [0141] transition the system to the Standby State.

No other System State transitions other than those described above SHALL [0142] be allowed.

3.2. System Capability Requirements

The System's functions are listed in Table 3.2-1 subdivided into the Operational, and Support categories. The table also identifies the section in which each function is discussed.

Table 3.2-1. Operational & Support Functions

Category	Function	Section
Operational	• TMA Processing	3.2.1
	• FAST Processing	3.2.2
	• TMC-Graphical User Interface (GUI)	3.2.3
	• Monitor and Control (M&C)	3.2.4
	• Data Management (DM) [deleted]	3.2.5

Support	• Adaptation, Validation, and Analysis (AVA)	3.2.6
	• Data Analysis (DAN)	3.2.7
	• Playback	3.2.8
	• Simulation	3.2.9

The Operational functions, listed in Table 3.2-1, provide the required CTAS functions at each of the operational ATC facilities, i.e., ARTCC, TRACON, and Tower. The processing functions, TMA and FAST, provide the principal processing to optimize the flow of traffic in the operational ATC environment. The TMC-GUI function provides interactive capabilities for the TMC. The M&C function provides the overall system management and control of the Operational CTAS. NOTE: The DM function has been eliminated.

The Operational functions are designed so that stand-alone instances of the Operational System can be created with ability to interact with other instances. Each stand-alone CTAS executes in hardware which is separate from the primary ATC systems but is interfaced to the primary ATC systems at that facility. The interface is two-way in some facilities, and in others, is one-way.

The Support functions, listed in Table 3.2-1, support the Operational System. These functions execute in a manner such that they do not interfere with the execution of the Operational System.

The AVA Support function generates site adaptation data for the Operational System, and validates and analyzes the adaptation data. The DAN Support function provides the ability to examine data recorded by the Operational System. Although both of these functions are used in field facilities, they will also be used in development laboratories to support live operations.

The two remaining Support functions in Table 3.2-1, Playback and Simulation, are expected to be used only in laboratory environments. The Playback function provides the ability to play recorded data into the Operational System, and the Simulation function allows the Operational System to be exercised with simulated aircraft.

Each installation of CTAS consists of a set of functional groups. Four different functional groups are identified, as follows:

• Monitoring and Control (M&C) group, which is one of the following:

1) Center M&C group

2) TRACON M&C group

3) Tower M&C group

• Data Input/Output (I/O) group, which is one of the following:

1) Center Data I/O (CDI) group

2) TRACON Data I/O (TDI) group

• User Input/Output (I/O) group capable of supporting:

1) TMA displays

2) FAST displays

• Data Processing function, which is one of the following:

1) TMA Data Processing group

2) FAST Data Processing group

The M&C group is always present for any CTAS installation. The other groups may or may not be present for a particular installation.

Figure 3.2-1 is a diagram of the CTAS system in its four generic installations:

• Arrival Center CTAS

• Arrival TRACON CTAS

• Adjacent Facility CTAS without TMA or FAST

• Control Tower CTAS

The figure shows the functional groups necessary for each generic installation.

Figure 3.2-1. CTAS Generic Installation.

The CTAS installation in the Arrival Center consists of:

1) A Center M&C functional group.

2) A Data I/O group which consists of a two-way HOST interface and interfaces to other CTAS installations.

3) One or two User I/O groups, each capable of displaying local TMA output and FAST output from the associated TRACON.

4) One or two Data Processing groups consisting of TMAs. TMA receives external inputs from the associated TRACON and other CTAS installations.

The CTAS installation in an Arrival TRACON consists of:

1) A TRACON M&C functional group.

2) A Data I/O group which consists of a one-way or two-way interface with the local ARTS.

3) A User I/O group capable of displaying local FAST output and TMA output from the associated Center.

4) A Data Processing group consisting of FAST. FAST receives external inputs from the corresponding Center and other CTAS installations.

The Adjacent Facility Installation can be full-blown Arrival Center installations described above or a skeletal adjacent installation providing surveillance data to a CTAS-equipped adjacent Center or TRACON. In the latter case, an installation consists of up to three groups:

1) An M&C group.

2) An optional User I/O group.

3) A Data I/O group.

A CTAS installation in a Tower consists of :

1) A Tower M&C group.

2) A User I/O group capable of displaying local FAST output and TMA output from the associated Center.

Support functions such as Data Recording and Adaptation are not shown on the diagram and are assumed to be present where there is a Data Processing group.

3.2.1. TMA Processing

The TMA Processing function, hereafter in the section referred to as TMA, operates in the En Route environment. It produces an arrival plan which meets the flow requirements for the adapted airport. It does this by generating a schedule which is conflict-free at the runway and the meter fix.

TMA is depicted in Figure 3.2.1-1. The input sources, appearing in italics, are shown at the top of the figure. The processing steps or sub-functions are shown in the central portion of the figure. The outputs of the function and their destinations, appearing in italics, are shown at the bottom.

Figure 3.2.1-1. TMA Function.

As depicted in Figure 3.2.1-1, the functions within TMA are:

• Aircraft Processing.

• Route Analysis.

• Estimated Times of Arrival (ETA) Generation.

• Scheduling.

The site-specific adaptation data for TMA are obtained from AVA.

TMA makes continuous predictions, based on the current track or Host converted route (received with the HCS flight plan) and winds aloft data, of arrival aircraft routes and ETAs for several locations, i.e., Runway Threshold, Final Approach Fix (FAF), Meter Fix and Outer Arc. The ETAs are used by the Scheduling function to determine the aircraft Scheduled Times of Arrival (STAs).

The Scheduling function utilizes the available airspace at, or as close as possible to, its designated capacity, operating in light of several constraints on the arrival traffic.

Scheduling is based on two separate modes, a time-based metering approach or an automated Miles-in-Trail (MiT) approach. Miles-in-trail scheduling can be fully automatic or modified by manual TMC inputs. The scheduling can also combine Miles-in-Trail restrictions at one arrival gate with time-based scheduling at the others. Finally, In-Center and In-TRACON departures can also be scheduled.

After the Scheduling is complete the scheduled load to the TRACON and airport is displayed to the TMCs. ETAs and STAs are output to the TMCs. Additionally, if time-based scheduling is in effect, the results in the form of a meter list can be sent to the Host Computer System (HCS) by the TMC via the HID for display to feeder Sector Controllers at the en-route facility.

3.2.1.1. Inputs & Outputs

TMA SHALL [0145] use the following inputs:

a. Adaptation data from AVA.

b. In-Center aircraft data from the local HID/NAS LAN.

c. Adjacent ARTCC aircraft data from an adjacent ARTCC HID/NAS LAN.

d. Weather data from ETMS.

e. TMC entries from the TMC-GUI.

f. Sector controller entries from the HCS via the HID/NAS LAN.

g. Control data from the M&C function.

TMA SHALL [0150] for the purposes of scheduling be capable of receiving aircraft data, i.e., flight plans and tracks, for up to 750 aircraft from all sources.

TMA SHALL [0160] be capable of scheduling up to 360 tracked arrival aircraft from all sources every HCS track update interval.

TMA SHALL [0170] be capable of scheduling aircraft to up to six airports within the TRACON airspace at any given time.

TMA SHALL [0180] read and use the following adaptation databases:

a. Meter fixes.

b. Alternate meter fixes.

c. Nominal TRACON routes.

d. Nominal TRACON speeds.

e. Stream class definitions.

f. Permissible super stream classes.

g. CTAS adaptable airports.

h. Available runways.

i. Permissible MiT settings including blends (i.e., use of different MiT values for different aircraft types in the same super stream).

j. Runway allocation adaptation.

k. Aircraft characteristics including engine and drag models.

Whenever the TMA function receives aircraft data, it SHALL [0190] update its arrival plan ETAs.

Whenever the TMA function receives new weather data, it SHALL [0200] update its weather information and recalculate its ETAs.

Whenever TMA receives the Sector Controller command to swap between two and five aircraft, TMA SHALL [0210] re-sequence the affected aircraft keeping the ETAs the same and recalculating the STAs.

Whenever it receives any of the TMC commands specified in Section 3.2.3.4, TMA SHALL [0220] update its arrival plan :

a. New schedule restriction.

b. Airport configuration change.

c. Gate reassignment.

d. Runway reassignment.

e. Preview plan becomes the current plan.

f. Designate or remove an aircraft as priority.

g. Assign priority aircraft the shortest possible route to the runway threshold.

TMA SHALL [0225] produce the following outputs:

a. TMC display data to the TMC-GUI.

b. Meter List to Sector Controllers via the HID/NAS LAN and HCS.

c. Status monitoring data to the M&C function.

The TMA SHALL [0230] send the following meter list data to the HID/NAS LAN, via the Center Data Interface (CDI) function, as specified in Document References NAS IR-90062819 and NAS-IR-82179015:

a. Aircraft computer ID (CID).

b. Airport identifier.

c. Runway configuration.

d. Assigned meter fix and outer fix/arc.

e. STA to each assigned fix/arc.

f. ETA to each assigned fix/arc.

g. Delay to absorb prior to reaching each assigned fix/arc.

h. Four display bits (for frozen, heavy, holding and down-arrow processed status).

Requirements 0240 and 0250 have been eliminated.

3.2.1.2. Aircraft Processing

In most cases, the first notification of a new aircraft to the TMA Processing function is the receipt of the Flight Plan from the HCS. In other cases, the initial receipt of a flight plan may be from the TRACON Data Interface (TDI) especially if the TRACON is very large such as in the case of the Southern California TRACON. The initial flight plan may be received from the adjacent center in some cases, or could be received from a nearby TRACON. In response to an initial flight plan, the function calculates a nominal ETA which is sent to the TMC GUI function.

In the event that the first notification concerning an aircraft is a track message instead of a flight plan, TMA SHALL [0255] request the flight plan from the HCS.

Upon receipt of a new flight plan, TMA SHALL [0260] parse:

a. Aircraft type.

b. Assigned altitude.

c. Filed True Air Speed (TAS).

d. Route of flight in field 10 (as defined in NAS-MD-312).

e. Aircraft ID (CID and call sign).

f. Aircraft beacon code.

g. Company ID.

Upon receipt of a new flight plan or amendment, TMA SHALL [0270] parse the converted route for the following information:

a. Coordination Time (for entering the local facility from either the Center, TRACON, Adjacent Center or near-by TRACON).

b. Coordination Fix (where the flight will enter the local facility from either the Center, TRACON, Adjacent Center or Adjacent TRACON).

c. Meter Fix assignment.

d. Route of flight from the Coordination Fix to the Meter Fix.

Requirement 0280 has been replaced by requirement 0410.

Requirement 0290 has been eliminated.

Upon receipt of and based on a flight plan, TMA SHALL [0300] calculate an initial ETA for the aircraft at the:

a. Outer Fix.

b. Meter Fix.

c. Final Approach Fix (FAF).

d. Runway Threshold.

3.2.1.3. Route Analysis

The Route Analysis (RA) function determines the aircraft situation (analysis category), assigns a meter fix to the aircraft, generates a route to the meter fix, assigns an initial runway, and generates a nominal route from the meter fix to the runway.

TMA SHALL [0310] process the following information, at a minimum, to construct a nominal route from the aircraft’s current position to an adapted runway threshold:

a. Track data.

b. Flight plan converted route data.

c. Aircraft type data.

d. Adapted information about the assigned runway.

e. Configuration anticipated to be in effect at landing.

f. Arrival feeder gate information.

g. Arrival meter fix information.

h. Aircraft analysis category.

i. Stream class definitions.

j. Airline preferred speed and altitude profiles, if applicable.

TMA SHALL [0315] detect that an aircraft is in a Holding Pattern.

TMA SHALL [0316] assign an adaptation determined groundspeed to an aircraft which it has determined to be in a Holding Pattern.

3.2.1.3.1. Meter Fix Assignment

This function chooses the arrival meter fix utilizing the Host converted route, the anticipated airport configuration, and aircraft type. Ordinarily, it is the meter fix closest to the Host converted route. However, certain irregular TRACONs can pose complications.

The Northern California TRACON contains the major airports SFO, OAK, and SJC. Under certain airport configurations, the available meter fixes are a function of arrival airport. Aircraft destined for San Francisco, Oakland, and San Jose arriving from the same direction will be assigned to different meter fixes.

The Southern California TRACON uses a different set of meter fixes when it is in east configuration than when it is in west configuration. Jets use a different set of meter fixes than turbo-props and piston aircraft.

Finally, CTAS may predict a different airport configuration for a distant aircraft than the HCS. CTAS may be forced to predict a meter fix different from the one in the Host converted route.

TMA SHALL [0320] calculate a new meter fix assignment for an aircraft whenever it:

a. Receives a new flight plan (i.e., unknown to CTAS) from the HCS.

b. Receives a flight plan amendment for an aircraft modifying the Host Converted route (A-K route).

c. Determines that the aircraft will land under a different configuration than currently anticipated.

The first step in meter fix assignment is an examination of the converted route. If this does not result in a meter fix assignment, then the second step is to look at the geometry of the aircraft position with respect to the TRACON. If this does not result in a meter fix assignment, TMA will assume that the aircraft is intentionally entering the TRACON at a point other than a meter fix. The nearest meter fix will then be assigned, and the "nearest meter flag" will be activated.

TMA SHALL [0330] first attempt to assign an aircraft's meter fix using site adaptable logic (gate decision tree) based on the following inputs:

a. The presence or absence of site specific waypoints in the converted route.

b. The aircraft's engine class (i.e., Heavy, Jet, Turboprop or Piston).

c. The airport configuration anticipated by CTAS to be in effect at the aircraft's projected time of landing.

In the event that the site adaptable logic (gate decision tree) can not assign a meter fix with the available information, TMA SHALL [0340]:

a. Calculate the intersection point between the Host Converted Route and the TRACON boundary (the TRACON penetration point).

b. Assign the aircraft to the meter fix nearest to the TRACON penetration point which is compatible with the following parameters

1) Aircraft's engine class.

2) Aircraft's destination airport.

3) Aircraft's anticipated airport landing configuration.

c. Calculate the distance from the TRACON penetration point to the assigned meter fix.

d. If the distance calculated in part (c) is greater than the Site Adaptable "Meter Fix Tolerance" distance, set the aircraft's "Nearest Meter Fix" flag.

Setting the aircraft's "Nearest Meter Fix" flag will remove it from deconfliction at the meter fix and from inclusion in the flow statistics which are gathered for the purposes of automatically recommending Miles-in-Trail restrictions.

Requirements 0350, 0360, 0370 and 0380 have been deleted.

3.2.1.3.2. Stream Class Assignment

TMA SHALL [0400] assign a stream class for each aircraft based on site adapted rules that take into account:

a. Aircraft engine class.

b. Presently assigned meter fix.

c. Airport configuration anticipated for the time of landing at the arrival airport.

d. Destination airport.

e. Total straight line flight distance (from departure airport to arrival airport as calculated from flight plan information).

TMA SHALL [0390] assign a stream class for each aircraft whenever that aircraft's meter fix or anticipated arrival configuration changes.

3.2.1.3.3. Runway Assignment

Whenever TMA receives a new flight plan for an aircraft, it SHALL [0410] assign the aircraft to the default runway based on site adapted rules that take into account:

a. Aircraft engine class.

b. Assigned stream class.

c. Anticipated arrival configuration at the time of landing.

From the time of initial runway assignment until the time that scheduling of the aircraft is terminated (or "frozen"), an aircraft is periodically considered for alternate runway assignments. Different events cause different subsets of aircraft to be reviewed for runway reassignment, as described below.

TMA SHALL [0420] perform runway allocation on all aircraft whose schedule is not frozen, based on certain conditions or events as follows:

	Event	TMA SHALL [0420] allocate runways for:
a.	TMC enters: New blocked runway interval.	All aircraft assigned to the runway being blocked which are currently scheduled to land during the blocked interval.
b.	TMC enters: Remove blocked runway interval.	All aircraft on any other runway scheduled during the blocked interval.
c.	TMC enters: Increase of a runway acceptance rate.	All aircraft assigned to any other runway.
d.	TMC enters: Decrease of a runway acceptance rate.	All aircraft assigned to this runway.
e.	TMC enters: Changes concerning pending airport configuration change(s).	The aircraft whose arrival configuration is anticipated to change.
f.	TMC enters: Manual Scheduling of an In-Center Departure.	The manually scheduled aircraft.
g.	Receipt of an "Aircraft Departed" message from the HCS for an In-Center Departure.	Only the aircraft which just departed.
h.	Determination that an aircraft's STA is about to be frozen (by TMA).	Only the aircraft which is about to be frozen.
i.	TMC enters: A command "resetting" an aircraft's ETA. This procedure will remove an aircraft from scheduling for one scheduling cycle, following which it will be added to the schedule.	Only the aircraft which has been reset.
j.	TMC enters: Changes concerning an aircraft's "priority" status.	Only the aircraft which had a change in priority status.
k.	TMC enters: A command causing an aircraft which has been suspended from scheduling to have its scheduling resumed.	Only the aircraft which has had scheduling resumed.
l.	TMC enters a command to reassign a single aircraft to another gate (or meter fix).	Only the aircraft which has had its gate (or meter fix) reassigned.
m.	TMC enters a command to reassign all aircraft on a certain gate (or meter fix) after a certain aircraft to another gate (or meter fix).	All aircraft which had a gate or meter fix re-assignment as a result of this command.
n.	TMC enters a command to reassign all aircraft on a certain gate (or meter fix) to another gate.	All aircraft which had a gate or meter fix re-assignment as a result of this command.
o.	TMA receives a flight plan amendment.	Only the aircraft whose flight plan is amended.
p.	TMA calculates an aircraft's ETA for the first time	Only the aircraft which has had its first ETA calculated.
q.	TMA is initialized.	All aircraft.
r.	TMC enters: The "reallocate runway" command ALLOCATE_SINGLE (aircraft).	Only the specified aircraft.
s.	TMC enters: The "reallocate runway" command ALLOCATE_AFTER (all aircraft after).	All aircraft with a threshold STA later or equal to the threshold ETA of the specified aircraft.
t.	TMC enters: The "reallocate runway" command ALLOCATE_ALL (all aircraft).	All aircraft.

All of the above events except the last three (r, s & t) are events which trigger automatic runway reallocation, while the last three are commands which cause manual runway reallocation.

Runway allocation for an aircraft examines several alternate runway selections to identify the alternate runway which results in the lowest "total time to fly" for all the aircraft in the System. In order for this alternate runway allocation to occur, the savings in the total time to fly must exceed an amount which is specified in adaptation.

The practical effect, however, is to produce trial schedules with the aircraft reassigned to several candidate runways which might be appropriate to the airport arrival configuration (and several other factors).

Runway allocation is accomplished in two steps. The first is the identification of the reallocation procedures for each aircraft from the site adaptation. The second is a search over all alternate runways for each aircraft to find the one which provides the largest total delay savings.

3.2.1.3.3.1. Identification of the Reallocation Procedure from Site Adaptation

A realloction procedure consists of a set of candidate runways to be tried for a given aircraft. Each aircraft has its own reallocation procedure.

TMA SHALL [0430] identify a list of reallocation procedures from the site adaptation for each aircraft to be reallocated based on:

a. Anticipated airport arrival configuration.

b. The aircraft's assigned meter fix.

c. The aircraft's currently assigned runway.

d. The type of reallocation (i.e., automatic or manual).

3.2.1.3.3.2. Runway Search

Once the reallocation procedures have been identified, they are carried out. The runway search consists of calculating the total time to fly for each of the candidate runway reallocations.

Based on the current runway assignment (and schedule) a total time to fly is calculated. Then a new total time to fly is calculated based on a tentative schedule in which the aircraft is assigned to the new runway (and removed from the current runway).

If the resulting savings in Total Time to Fly is larger than a site adaptable value (adaptable for each proposed transition), the transition is accepted.

The reallocation procedure (which is a list of runway transitions) is examined to completion. The final runway resulting from this procedure becomes the newly -assigned runway.

TMA SHALL [0440] implement a site adaptable runway reallocation procedure for each aircraft to be reallocated, based on:

a. An aircraft's currently assigned runway.

b. The reduction in Total Time to Fly for all aircraft affected by the proposed runway change.

c. Any future runway acceptance rate changes for the aircraft's currently assigned runway.

3.2.1.3.4. TRACON Speed & Altitude Parameter Specification

Based on an aircraft's assigned stream class, TMA SHALL [0450] retrieve from adaptation an aircraft's TRACON entering parameters, including:

a. Meter fix crossing speed (Calibrated Airspeed, CAS).

b. Meter fix crossing altitude.

c. TRACON altitude profile.

d. (subrequirement deleted).

3.2.1.3.5. Situation Categorization

On every track data update cycle, TMA SHALL [0460] determine the "analysis category" of each aircraft, based on the following conditions:

a. Whether the aircraft is in track.

b. Whether the aircraft is on the ground.

c. Whether the aircraft is following its converted route.

d. Whether the runway assignment is frozen.

e. Whether the aircraft is a priority aircraft.

f. The meter fix assigned.

g. The anticipated airport configuration.

h. The runway assignment.

3.2.1.3.6. Route Estimation

The aircraft state, as far as routing is concerned, depends on four Boolean states. The exact prescription for route construction is detailed in the next requirement.

TMA SHALL [0470] generate route estimates depending on aircraft status (In Track, On Ground, On A-K Route and Priority Aircraft) as shown Table 3.2.1.3.6-1.

Table 3.2.1.3.6-1. Route Estimate Generation

	Aircraft Status
	In Trk ?	On Gnd?	On A-K rte?	Prior-ity a/c?	Route Estimate
a.	No	No	Don't Care	No	Places the aircraft at the coordination fix at the coordination time with an initial heading toward the first Host Converted waypoint, follows the Host Converted route to the meter fix, and then follows the nominal TRACON route to the runway.
b.	No	Yes	Yes	No	Places the aircraft at the departure airport fix at the coordination time with an initial heading along the adapted departure heading. This initial heading is followed for an adapted distance and is followed by an immediate turn toward the first Host Converted waypoint. The route follows the Host Converted route to the meter fix, and then follows the nominal TRACON route to the runway.
c.	Yes	No	Yes	No	Places the aircraft at the track location at the track time, follows an immediate turn heading toward the next Host Converted waypoint using the tracker's heading as the initial heading, follows the Host Converted route to the meter fix, and then follows the nominal TRACON route to the runway.
d.	Yes	No	No	No	Places the aircraft at the track location at the track time, and using the heading reported by the tracker as the initial heading: a) If the aircraft is within a site adaptable distance of its assigned gate (generally 50 nautical miles (nmi)), follows an immediate turn heading toward the TRACON gate, and then follows the nominal TRACON route to the runway, or b) If the aircraft is beyond the site adaptable distance from its assigned gate (generally 50 nmi), follows a recovery route (see Requirement 0475) from the current position (and heading) to one of the remaining waypoints in the Host Converted route, follows the remainder of the Host Converted route to the TRACON gate, and then follows the nominal TRACON route to the runway.
e.	Yes	No	Don't Care	Yes	Places the aircraft at the track location at the track time, follows an immediate turn heading toward the assigned meter fix and then a straight line to the meter fix.

For every track update, it is determined whether each aircraft is off its A-K route (i.e., its closest distance to the A-K route exceeds a site-adaptable distance, e.g., 5 nmi). For each aircraft off its A-K route, the "route recovery procedure" is carried out as follows.

TMA SHALL [0475] apply the following route recovery procedure for each aircraft which is off its A-K route:

a. Determine the two waypoints in the A-K route that are closest to the aircraft position and select the one which is furthest along the A-K route as the "test waypoint".

b. If the distance from the aircraft to test waypoint exceeds the distance to the A-K route by a factor of two, the test waypoint is selected as the "recovery waypoint".

c. If the test in (b) fails, each subsequent waypoint along the A-K route is tried in a similar manner as a test waypoint until one is found which passes the test. That waypoint is then selected as the recovery waypoint.

d. If the waypoint to be tested is the Meter Fix, it is selected as the recovery waypoint.

e. The first segment of the recovered route is the direct segment from the current position to the recovery waypoint, after which the remainder of the A-K route is used.

If meter fix assignment results in the assignment of a "nearest meter fix", a slight modification is required to all the route generation methods listed above. The point where the Host Converted route enters the TRACON will be used in place of the TRACON gate. The nominal TRACON route used will be that listed in the adaptation for the gate nearest the point of TRACON entry.

If the Nearest Meter Fix Flag is set for an aircraft, then TMA SHALL [0480]

a. Retrieve the TRACON route from the nearest meter fix (i.e., the meter fix closest to the TRACON entry location).

b. Amend that route by replacing the meter fix with the TRACON entry location.

Requirement 0490 has been deleted.

3.2.1.4. ETA Generation

TMA calculates the Time To Fly (TTF) from the aircraft's current position or coordination fix to Outer Fixes/Arcs, Meter Fixes, Final Approach Fixes and Runway Thresholds. These TTFs are added to the current time or coordination time to produce the ETAs at these locations.

The first step in calculating the TTF is to convert a list of waypoints into a ground track which includes turns which are capable of being flown according to the aircraft model. The second step is to calculate the vertical speed profile along this ground track in accordance with standard aircraft arrival procedures.

ETAs are recalculated for each aircraft whenever any information about aircraft status is received from the HCS system or whenever new weather information is received.

TMA SHALL [0500] calculate ETAs based upon:

a. Aircraft position (HCS reported position and altitude).

b. Aircraft speed reported by NCS.

c. Aircraft heading reported by NCS.

d. Aircraft models (Engine Thrust and Airframe Drag models).

e. Horizontal route.

f. Weather data (wind speed, wind direction, temperature, and pressure).

g. Ascent and Descent profiles.

h. Prescribed altitude regimes (current altitude, flight plan altitude, meter fix crossing altitude, and TRACON altitude profile).

TMA SHALL [0510] calculate a new ETA for each aircraft for the following:

a. Every new radar update.

b. Flight plan route amendment.

c. Change of the anticipated airport configuration.

d. Meter fix reassignment.

e Runway reassignment..

f. Change in coordination time.

g. Updated weather data.

Requirements 0520 and 0530 have been deleted.

3.2.1.4.1. Determination of Vertices

This section describes the determination of vertices, which are selected waypoints used for Time To Fly calculations. Vertices most commonly used in this context are the Outer Fix/Arc, the Meter Fix/Arc, the Final Approach Fix and the Threshold Fix.

TMA SHALL [0540] obtain the TTF by modeling the three-dimensional flight of the aircraft as a function of time (a so-called 4D trajectory) based on the following inputs:

a. Aircraft track position.

b. Routing information.

c. Altitude profile.

d. Aircraft type.

e. Aircraft ground speed.

f. Aircraft characteristics.

g. Weather data.

TMA SHALL [0550] be capable of calculating an aircraft’s TTF from the following vertices:

a. The aircraft's most recently reported position.

b. The aircraft's coordination fix at the en-route center boundary.

c. An adapted airport within the en-route center (including the TRACON).

TMA SHALL [0560] be capable of calculating an aircraft’s ETA to the following adapted vertices:

a. Outer fix or outer fix arc.

b. Meter fix or meter fix arc.

c. Final approach fix.

d. Runway threshold.

For aircraft that are airborne and tracked in the Center airspace, TMA SHALL [0571] calculate an aircraft’s ETA by summing the aircraft’s track time and the TTF from the aircraft’s current position to the:

a. Outer fix or outer fix arc.

b. Meter fix or meter fix arc.

c. Final approach fix.

d. Runway threshold.

For aircraft that are airborne in an adjacent center, TMA SHALL [0572] calculate an aircraft’s ETA by summing the aircraft’s projected coordination time and the TTF from the aircraft’s coordination fix to the:

a. Outer fix or outer fix arc.

b. Meter fix or meter fix arc.

c. Final approach fix.

d. Runway threshold.

For aircraft that are within 30 minutes of takeoff at an In-Center airport, TMA SHALL [0573] calculate an aircraft’s ETA by summing the aircraft’s projected departure time, and the TTY from the aircraft's departure fix to the:

a. Outer fix or outer fix arc.

b. Meter fix or meter fix arc.

c. Final approach fix.

d. Runway threshold.

Requirement 0570 has been deleted.

Accuracy of the calculated ETAs is required to establish the proper sequence at an early time and to properly predict the demand on the airport.

TMA SHALL [0580] be capable of computing the track-based ETA for all aircraft type trajectories to within an accuracy of +/- 60 seconds of the actual feeder meter fix crossing time for undelayed flight of aircraft which are up to 19 minutes from feeder meter fix.

TMA SHALL [0585] calculate and display the Original ETA (OETA) calculated as follows:

a. If no track updates have been received, the OETA is the most recently calculated ETA.

b. If between one and five track updates have been received, the OETA is the average ETA resulting from all track updates.

c. If more than five track updates have been received, the OETA is the average of the ETAs resulting from the first five track updates.

TMA's prediction of the TTF is required to satisfy the following performance requirement:

The percentage of error, in absolute value, associated with the final track OETA for a statistical sample of 500 aircraft with "unimpeded" flight to the meter fix SHALL [0590] have a sample mean of not more than 6% and a 99th percentile of not more than 10%, respectively, where percentage error is defined as:

| OETA - Actual meter fix crossing time | * 100

------------------------------------------------------------------------------------------------

| Actual meter fix crossing time - Average time when the OETA was calculated |

In this context, the final track OETA refers to the average of the first five ETAs based on track updates. The "Average time of OETA calculation" is the average "track time" of

the first five track updates. Unimpeded flight is one which was not affected by the presence of other aircraft while traversing the planned path to the meter fix.

3.2.1.4.2. Determination of Horizontal Ground Track

The horizontal ground track is determined so that the horizontal motion can be decoupled from the vertical solution. The first step in the determination of the horizontal ground track is to complete the Host converted route by inserting turns at each waypoint. This, in turn, requires the computation of the approximate ground speed at each waypoint. These velocities are then used to calculate the turn radii. Finally, the straight segments of flight are connected with the constant radius turns to produce the refined ground track.

TMA SHALL [0600] use constant radius horizontal turns, taking into account aircraft type, speed, permissible bank angle, and winds aloft.

3.2.1.4.3. Determination of the Vertical Profile Along the Ground Track

Once the ground track has been refined, the four-dimensional trajectory is produced by solving the coupled differential equations for position, speed, and altitude.

The differential equations are solved in trajectory segments which define the operating constraints of the aircraft in each stage of flight. Each trajectory segment transitions to the next when its predefined capture condition is reached. A capture condition may be a Calibrated Air Speed, a Mach number, an altitude, or a certain path distance. The prediction of flight in each segment is made by the solution of the appropriate differential equations using a numerical integration method.

3.2.1.4.3.1. Vertical Profile in Center Airspace

TMA SHALL [0610] model the flight of aircraft using realistic aircraft models and the following control variables, which mimic piloting procedures:

a. Thrust (either idle or maximum).

b. Speed in the form of Calibrated Air Speed (CAS) or Mach.

c. Vertical rate (climb rate or descent rate expressed either in feet per minute or as a prescribed inertial flight path angle.

TMA SHALL [0620] model flight over trajectory segments by solving equations of motions where constant values are chosen for any two of the following control variables:

a. Thrust (either idle or maximum).

b. Speed in the form of CAS or Mach.

c. Vertical rate (climb rate or descent rate expressed either in feet per minute or as a prescribed inertial flight path angle).

TMA SHALL [0630] model the flight of jets at constant speed at or above FL280, whether flying level or descending, using a constant Mach number.

Below FL280, TMA SHALL [0640] use constant CAS numbers.

TMA SHALL [0650] model en route descents for jets using idle-thrust descents in the following four phases:

a. Mach acceleration.

b. Constant Mach.

c. Constant CAS.

d. Level deceleration.

The permissible values for CAS or Mach SHALL [0660] be defined by the aircraft performance model and ATC procedures.

TMA SHALL [0670] be capable of modeling descents using maximum (fast) and minimum (slow) speed descent profiles when called upon to do so for the purposes of scheduling arrivals earlier than the nominal ETA.

Requirement 0680 has been deleted.

TMA SHALL [0690] be capable of modeling aircraft descents using company preferred descent speeds, where known.

3.2.1.4.3.2. Vertical Profile in TRACON Airspace

TMA SHALL [0695] model flight within the TRACON following air traffic procedures from the adaptation

TMA SHALL [0697] model flight within the TRACON by using segments of the following types.

a. Constant CAS at constant altitude.

b. Constant CAS descents with constant glide slopes.

c. Idle thrust deceleration at constant altitude.

3.2.1.4.4. Variable Speed Crossing Restriction (VSCR) [deleted]

The requirements for Variable Speed Crossing Restrictions (VSCR) [Requirements 0700 and 0710] have been deleted.

3.2.1.4.5. ETA Smoothing

ETA estimation must be temporally stable so that arrival sequences are not switched unnecessarily. This requires the result of the ETA process to be temporally smoothed by appropriate algorithms.

TMA SHALL [0720] limit the fluctuation of an aircraft’s ETA due to estimation errors by:

a. Using the most recent flight plan ETA if no track updates have occurred.

b. Averaging the last five ETAs based on track updated provided they are available and no change has occurred in the route in the last five track updates.
NOTE: This is known as a moving window average.

c. Averaging all ETAs following a route change if a change has occurred in the last five track updates.

Requirement 0730 has been deleted.

Requirements 0740 through 0820 have been moved to Section 3.2.1.5.1.

3.2.1.5. Scheduling

The Scheduling function determines the time in which aircraft will arrive over a meter fix or over a runway threshold (or FAF) based on aircraft ETAs, operator selected constraints, or operator entered sequencing constraints. Scheduling uses the super stream class sequence and the ETAs generated by the ETA generation function to generate an STA for each aircraft by applying site adapted or operator selected scheduling constraints and required minimum separation constraints.

Free Flow does not alter the normal arrival sequence, but schedules aircraft at their ETA (STA=ETA). However, whenever Free Flow is not in effect, sequencing proceeds as detailed below.

For every super stream of aircraft entering the TRACON, the initial order or sequence is First Come First Served (FCFS) based on the ETA at the Meter Fix. This initial sequence can be modified to take into account any user-specified constraints.

Sequencing and scheduling occurs periodically, e.g., every 6 seconds, or when triggered by specific events, such as an aircraft being added or subtracted from the list of aircraft for a particular super stream for which the scheduling operation is being considered.

TMA SHALL [0830] generate a sequence of aircraft for each Meter Fix/Arc, Outer Fix/Arc, and runway threshold (or FAF if in VFR conditions).

TMA SHALL [0840] sequence aircraft at the Meter Fix in each super stream on a First-Come-First-Served (FCFS) order, in accordance with each aircraft's:

a. ETA at the Meter Fix , for aircraft which are further from the meter fix than the Spatially Based Sequence Distance (SBSD), usually 50 nmi, or

b. Distance from the Meter Fix, otherwise.

TMA SHALL [0850] modify its sequences at the Meter Fix to accommodate any sequence constraints entered manually by the TMC.

Requirement 0860 has been deleted.

After the sequence is established, STAs will be generated by one of two algorithms described below depending on the scheduling mode setting. The scheduling mode is a single run time parameter which affects all of TMA and may either be set to "Time Based Metering" or "Automatic Miles-in-Trail Metering."

The scheduling algorithm in TMA SHALL [0865] be controlled by the "scheduling mode" parameter which may be set while the system is running to either:

a. Time-Based Metering.

b. Automatic Miles-in-Trail Metering.

3.2.1.5.1. Scheduling Using Time Based Metering

The Scheduler begins by scheduling each super stream at the meter fix, and then checks for conflicts defined as violations of separation constraints between consecutive aircraft. The scheduler then attempts to build runway schedules. Several iterations may occur in an attempt to reconcile constraints applicable at runways and meter fixes, leading to a final schedule at the meter fix and at the runway. This schedule should be conflict free to within specified separation requirements at the runway and at the meter fix. Finally, the schedule at the outer fix/arc is calculated based on the schedule at the meter fix.

TMA SHALL [0740] schedule:

a Tracked flights (flight plans and radar tracks).

b. Untracked flights (flight plans only).

TMA SHALL [0745] only schedule proposed aircraft by manual scheduling.

TMA SHALL [0750] be capable of scheduling arrivals to a single TRACON within the ARTCC.

TMA SHALL [0760] generate an STA for each aircraft to each site adapted Meter Fix, Outer Fix/Arc, Final Approach Fix, and Runway Threshold.

TMA SHALL [0770] generate an STA based on the following constraints:

a. Feeder gate acceptance rate.

b. (subrequirement deleted)

c. Stream class Miles-in-Trail separation.

d. Meter Fix Acceptance Rate.

e. Airport Acceptance Rate.

f. Runway threshold (or FAF) Acceptance Rate.

g. Aircraft ETAs.

h. (subrequirement deleted)

i. Generated sequence.

j. Delay information fed back from the TRACON and delay allocation rules between TRACON and Center.

k. Separation criteria from FAA Order 7110.65 (wake vortex constraints).

l. ATC metering constraints as defined in NAS-MD-313.

m. TMC-entered STA, blocked slots, blocked intervals.

n. Runway occupancy time.

o. (subrequirement deleted).

p. Runway separation buffer.

TMA SHALL [0780] update the "stabilized STA" only if it differs from the current STA by more than a site selectable value between 0-24 seconds. The STA of frozen aircraft is never changed.

TMA SHALL [0790] generate an STA for a priority aircraft to be equal to its ETA.

The following requirements deal with a condition called "down-arrow processing". Down-arrow processing occurs when an aircraft, whose STA was already in the frozen condition in CTAS, files a new flight plan that either: a) diverts it to a non-CTAS airport or b) changes its status to VFR.

Requirements 0795 and 0796 have been moved to Section 3.2.3.2.

TMA SHALL [0800] freeze the STA of aircraft:

a. Designated as undergoing notification of diversion (similar to down arrow processing as defined in NAS-MD-313).

b. Whose TTF is less than a site selectable time value between 0-60 minutes from the Meter Fix/Arc. This time value is called the schedule freeze horizon.

c. Depending upon an adaptable distance between 0 - 120 nmi from the meter fix.

TMA SHALL [0810] recompute an aircraft’s STA within the schedule freeze horizon:

a. To accommodate priority aircraft.

b. In response to a TMC-entered command.

TMA SHALL [0820] generate STAs for a stream class of aircraft to be equal to their ETA when the Meter Fix flow restriction for the stream class is designated as "Free Flow".

3.2.1.5.1.1. Separation at the Meter Fix

Schedules for every super stream class are made at all Meter Fixes. Derived schedules are also made for outer arcs, if so desired. Schedules are also made for runway FAF's or thresholds. The latter are made simultaneously with Meter Fix schedules since they have mutual dependencies.

Once the sequence at the Meter Fix has been determined, the scheduler generates a schedule at the Meter Fix consisting of an STA for each aircraft in the sequence, using the following rules:

• No aircraft is scheduled to arrive earlier than its ETA. Many aircraft are scheduled at a time later than their ETA to satisfy separation requirements between aircraft in the sequence.

• The separation imposed between specific aircraft depends on a variety of constraints at the Meter Fix.

• Separation constraints at the runways are fed back to the appropriate Meter Fixes and may further increase separations.

• Separations at the Meter Fix based on Manual Miles-in-Trail settings are absolute and are not affected by conflicts at the runway.

TMA SHALL [0870] generate a schedule for each super stream class (at the Outer Fix, Meter Fix/Arc, Final Approach Fix/Arc, and Runway) and a set of derived schedules periodically, nominally every 6 seconds, or when triggered by any of a specific set of events, as follows:

a. Anything that causes immediate runway allocation.

b. Addition or deletion of a gate blocked interval.

c. Addition or deletion of a meter fix blocked interval.

d. Change in the Airport Acceptance Rate.

e. Change in runway occupancy time.

f. Change in any value in the runway wake vortex separation matrix.

g. Change in the gate acceptance rate.

h. Change in the meter fix acceptance rate.

i. Change in super stream class definition.

j. Change in MiT restriction.

k. Change in TRACON acceptance rate.

l. Addition of a meter fix sequence constraint.

m. Define slot operation initiated by the TMC.

n. Manual STA setting of any aircraft.

o. User requests a reschedule.

p. Rescheduling caused by pending scheduling events of three types:

1. Flight plan amendment changes a runway.

2. Flight plan amendment changes coordination fix.

3. Aircraft ETA is hovered (i.e., an aircraft fails to meet its coordination time and Host continues to increment at three minute intervals).

where rescheduling is triggered whenever either:

1. The type of a new pending event is different from any in the pending list.

2. The new pending event if added to the pending list causes the number of pending events to exceed the maximum number of pending events.

Requirement 0880 has been deleted.

IF Manual Super Stream Class Miles-in-Trail restrictions are placed on a super stream then TMA SHALL [0885] base the STA at the Meter Fix for each aircraft on the Manual Miles-in-Trail restriction exclusively ignoring all other constraints and the STA at the runway on the STA at the Meter Fix plus the nominal TTF through the TRACON.

Requirement 0890 has been deleted.

TMA SHALL [0900] delay the STA of an aircraft to fall outside of any Meter Fix blocked time interval if the tentative STA falls within such interval, unless the tentative STA is based on a Manual Miles-in-Trail restriction or the aircraft has the "nearest gate" indicator set.

TMA SHALL [0910] not schedule an aircraft within a blocked time interval except in the case of a priority designated aircraft, an aircraft obeying a manual Miles-in-Trail restriction or an aircraft that has the "nearest gate" indicator set.

TMA SHALL [0920] associate a specific aircraft type (e.g., Heavy, Large, Small or 757), which may optionally be derived from a specific call sign, with a blocked time slot.

TMA SHALL [0930] schedule other aircraft around a blocked time slot, taking into account the wake vortex requirement for the type of aircraft for which the slot is reserved, except for:

a. Aircraft obeying a manual Miles-in-Trail restriction, or

b. An aircraft that has the "nearest gate" indicator set.

TMA SHALL [0935] schedule every aircraft having the "nearest gate" indicator so that its initial meter fix STA is equal to its meter fix ETA. These STAs will not be deconflicted with any other aircraft at the meter fix.

The delay to be absorbed in Center airspace may cause other aircraft in the sequence to be delayed in order to retain adequate separation but should never change the established sequence.

3.2.1.5.1.2. Separation at the Runway

For the purposes of runway scheduling, "runway" means the runway threshold if the airport is operating under IFR, and means the FAF if the airport is under VFR.

Although in the En Route airspace, scheduling applies principally to scheduled times to the Meter Fix, it also needs to consider the implications of these schedules on the operations at the runways. Therefore, a tentative runway schedule to all runways is calculated where runway separation constraints are applied. Aircraft obeying a Manual Miles-in-Trail restriction have special status. These aircraft are not deconflicted from each other, and have first call on their desired landing time.

If, for any aircraft (except aircraft obeying a manual MiT constraint), the scheduled time at the runway is later than the scheduled time at the Meter Fix plus the nominal TTF from the Meter Fix to the runway then the aircraft must be delayed. Since the delay absorbing ability within the TRACON airspace is limited, it is necessary to absorb the excess delay in Center airspace or, in other words, to make the Meter Fix STA later with exactly that excess delay. This feedback of delays to the Center is discussed in the next section.

Since the runway schedule is derived from the Meter Fix schedules, it is not necessarily FCFS ordering based on ETAs to the assigned runway. Instead, the runway sequence and schedule depends on the so-called "order of consideration". This order establishes the precedence with which each aircraft that is assigned to the runway is allowed to establish its "landing slot", taking into account only the STA of aircraft already scheduled and the set of separation constraints at the runway.

TMA SHALL [0940] establish a schedule for each runway based on the following order of consideration:

a. All aircraft obeying manual Miles-in-Trail constraints are given absolute preference in the runway schedule over all other aircraft. No attempt is made to deconflict one MiT aircraft with another at the runway threshold.

b. Only aircraft assigned to the runway under consideration are considered in establishing the precedence.

c. Aircraft from the same super stream have a precedence based on their sequence in the super stream.

d. When considering aircraft from different super streams only the "next-to-be-scheduled" aircraft from each super stream can compete, and precedence goes to the aircraft with the earliest projected STA at the runway, defined as the Meter Fix STA plus the nominal TTF from the Meter Fix to the runway.

TMA SHALL [0950] schedule the STA (at the runway) of aircraft not obeying a Manual MiT restriction, as the later of:

a. The STA at the Meter Fix plus the nominal TTF from the Meter Fix to the runway.

b. The earliest time which does not conflict with the aircraft which have already been scheduled at the runway in this cycle.

In case of conflict at the runway for an aircraft not obeying a Manual MiT restriction, TMA SHALL [0960] delay the STA at the runway of the selected aircraft until no further conflict exists.

For aircraft not obeying a Manual MiT restriction, TMA SHALL [0970] derive the minimum required separation as the largest separation (converted to time based on the ground speed) compatible with the following constraints:

a. Runway threshold (or FAF) acceptance rate.

b. Runway occupancy time.

c. Separation criteria from FAA Order 7110.65 (wake vortex constraints).

d. Runway separation buffer.

e. TMC-entered runway blocked slots and intervals.

Except for aircraft obeying a Manual MiT restriction or priority aircraft, TMA SHALL [0980] delay any STA which falls within a runway blocked time interval to be outside and later than that interval, at which time the STA must be checked again for possible conflict with other scheduled aircraft.

3.2.1.5.1.3. Feedback from Runway Schedules to Meter Fix Schedules

Allocation of excess TRACON delays into the ARTCC arrival scheduling process is based on a parameter called Route Maximum Delay (RMD). This parameter quantifies the delay which could be absorbed in the TRACON by delaying the aircraft on its path between the meter fix and the runway.

If, for any aircraft not obeying a manual MiT restriction, the scheduled time at the runway is later than the scheduled time at the Meter Fix plus the nominal TTF from the

Meter Fix to the runway, the scheduled time at the Meter Fix must be delayed. Since the delay absorbing ability within TRACON airspace is limited to a maximum value, specified by the RMD in the site adaptation for each route, it may be necessary to absorb the excess delay in ARTCC airspace or, in other words, to set the Meter Fix STA later with exactly that excess delay.

TMA SHALL [0990] delay the Meter Fix STA for each aircraft for which the STA at the runway is later than the sum of the Meter Fix STA, the TTF from the Meter Fix to the runway, and the site adaptable parameter RMD.

TMA SHALL [1000] delay the Meter Fix STA by the amount of time the runway STA is later than the sum specified in requirement 0990. This amount of time is the excess delay to be absorbed in the Center airspace.

TMA SHALL [1010] not change the sequence of aircraft in the Meter Fix schedules due to any feedback from the TRACON runway schedules.

Requirement 1020 has been deleted.

TMA SHALL [1030] re-examine the Meter Fix schedule for possible conflicts if any aircraft in the sequence was delayed due to feedback from the runway schedule.

TMA SHALL [1040] iterate the process of setting up runway schedules and Meter Fix schedules until all constraints are met both at the runways and Meter Fixes, allocating no delays greater than RMD to the TRACON.

For aircraft obeying a manual Mile-in-Trail restriction, TMA SHALL [1042] not change the STA at the meter fix due to any conflicts at the runway.

For aircraft with the "nearest gate" indicator set, TMA SHALL [1044] feed back delays at the runway to the meter fix to the extent that they exceed the RMD.

For aircraft with the "nearest gate" indicator set, TMA SHALL [1046] not deconflict the final STA at the meter fix with the STA(s) of any other aircraft.

3.2.1.5.1.4. Scheduling at the Outer Fix/Arc

TMA SHALL [1050] calculate schedules at the Outer Fix/Arcs based on the Meter Fix schedules, the TTF from the Outer Fix/Arc to the Meter Fix, the delay to be absorbed in the Center airspace and a site adaptable parameter called Outer Fix Delay (OFD). The OFD is the maximum delay that can be absorbed within the performance characteristics of a large set of aircraft types on the trajectory between the Outer Fix/Arc and the Meter Fix.

TMA SHALL [1060] assign an Outer Fix/Arc STA to an aircraft:

a. No later than the Meter Fix STA minus the nominal TTF between Outer Fix/Arc and Meter Fix.

b. No earlier than the Meter Fix STA minus the sum of the nominal TTF between Outer Fix/Arc and Meter Fix, and the value of OFD valid for the chosen pair of fixes.

TMA SHALL [1070] calculate the difference of ETA and STA for each aircraft at the Meter Fix , i.e., the "Delay to be absorbed in the Center Airspace" (DCA) by that aircraft.

TMA SHALL [1080] assign an Outer Fix/Arc STA for an aircraft equal to the ETA at the Outer Fix/Arc if DCA is less than the OFD for the assigned Outer Fix/Arc and Meter Fix (since the total Center delay can then be comfortably absorbed between Outer Fix/Arc and Meter Fix).

TMA SHALL [1090] assign an STA for an aircraft equal to the ETA plus the difference DCA minus OFD, when DCA is larger than the OFD.

Requirement 1100 was deleted. NOTE: The former Section 3.2.1.5.5 was deleted.

3.2.1.5.2. Scheduling Using Automated Miles-in-Trail

The automated Miles-in-Trail (MiT) scheduling mode is based solely on deconfliction of aircraft at the meter fix. No attempt is made to guarantee deconfliction at the runway or to reassign aircraft to different runways to minimize conflicts. This simplified scheduler is necessary so that the automated Miles-in-Trail software can correctly calculate the contribution of each super stream to the flow rate at the airport.

The imposed Miles-in-Trail restriction in this mode, is the only constraint used by the scheduling function to calculate a schedule or STAs. Many sites use a Miles-in-Trail flow management scheme in place of time based metering. The purpose of the automated Miles-in-Trail capability is to create a plan that meets the desired airport acceptance rate over a specified period.

In the automated Miles-in-Trail scheduling mode TMA SHALL [1105] generate STAs at the meter fix based exclusively on:

a. ETAs at the Meter Fix.

b. Automatically or Manually entered Miles-in-Trail Restrictions at the Meter Fix.

c. Predicted Ground Speed at theMeter Fix.

In the automated Miles-in-Trail scheduling mode TMA SHALL [1106] generate STAs at the FAF based exclusively on:

a. STA at the Meter Fix.

b. Nominal TTF from the Meter Fix to the FAF.

In the automated Miles-in-Trail scheduling mode TMA SHALL [1107] generate STAs at the Runway Threshold based exclusively on:

a. STA at the Meter Fix.

b. Nominal TTF from the Meter Fix to the Runway Threshold.

TMA SHALL [1110] have the capability of automatically devising a Miles-in-Trail arrival plan which achieves the desired airport acceptance rate over a specified time period, based on arrival times measured either:

a. At the Runway Threshold.

b. At the Meter Fix.

Requirements 1120-1140 have been moved to Section 3.2.1.5.2.1.

TMA SHALL [1150] devise a Miles-in-Trail arrival plan which equitably distributes delays among arriving super streams (based on average delay over the super stream).

TMA SHALL [1160] accept the following inputs when generating Miles-in-Trail plan:

a. Airport Acceptance Rate (AAR).

b. Airport Arrival Configuration in effect after the start time.

c. Start time of the Miles-in-Trail Plan (immediate if not defined).

d. End time of the Miles-in-Trail Plan (automatically calculated if not defined).

e. Manually entered Miles-in-Trail restrictions.

f. The combination of stream classes into super stream classes.

TMA SHALL [1170] segregate all flows into an airport into "regions" which define the streams in an airport which may be combined (based on site adaptation).

Requirement [1180] has been deleted.

TMA SHALL [1190] generate a new Miles-in-Trail plan, whenever any of the following are modified by the TMC:

a. Airport Acceptance Rate (AAR).

b. Airport Arrival Configuration in effect after the start time.

c. Start time of the Miles-in-Trail Plan either immediate or in the future.

d. End time of the Miles-in-Trail Plan.

e. Manual entered Miles-in-Trail restrictions.

f. The combination of stream classes into super stream classes.

g. Immediate change of current Miles-in-Trail plan.

TMA SHALL [1200] allow the TMC to merge streams into super streams based only on combinations specified in the site adaptation.

TMA SHALL [1210] provide the TMC the means to place an automatically or manually generated Miles-in-Trail plan into effect in the schedule.

The Scheduler implements the automated Miles-in-Trail recommendation in four steps:

a. Recommend a start and stop time for accumulating flow statistics

b. Recommend stream class combination into super stream classes.

c. Finalize the Miles-in-Trail Restrictions for Manually Set and "Lightly" Loaded Streams.

d. Iterate the non-finalized Miles-in-Trail settings to meet the requested AAR.

Requirements 1220, 1230, 1240, 1250, 1260, 1270, 1280, and 1290 have been deleted.

3.2.1.5.2.1. Recommend Start and Stop Time

The automatic Miles-in-Trail recommendations are based on flow statistics gathered for the time during which the Miles-in-Trail plan is expected to be in effect. This time period usually covers a specific arrival rush at the airport, and has a specified start time and stop time. A change in Miles-in-Trail plan should occur whenever the demand on the airport changes, or when the character of the demand (rush) changes (i.e., East Rush changes to a West Rush).

TMA SHALL [1320] have the ability to determine when changes in Miles-in-Trail plans should occur.

TMA SHALL [1330] recommend changes in the Miles-in-Trail plan no more often than twice per hour.

TMA SHALL [1120] initiate the new Miles-in-Trail arrival plan at the start time specified or calculated for the Meter Fix.

TMA SHALL [1130] convert between time at the Meter Fix and time at the Runway Threshold by adding the average predicted time to fly (in the TRACON) for all aircraft in the time period specified.

TMA SHALL [1140] automatically recommend a stop time for measurement of flow statistics if a start time has been entered or calculated.

TMA SHALL [1340] notify the TMC about a recommended change in Miles-in-Trail plan as soon as TMA determines that a change should be pending.

TMA SHALL [1350] accept modification of its recommended Miles-in-Trail plan at any time before it becomes pending.

TMA SHALL [1360] only place the recommended Miles-in-Trail change into pending status when it is accepted by a TMC.

Requirements 1370 have been deleted.

3.2.1.5.2.2 Recommend Stream Class Combinations into Super Stream Classes

Most facilities have the ability to combine streams of traffic into super streams. This is designed to keep the Miles-in-Trail restrictions from being excessive (always between 5 and 35 nmi) and also to invoke stream procedures that are preferred at each facility.

TMA SHALL [1300] recommend possible super stream combinations for each region which produce Miles-in-Trail recommendations in the range of 5 to 35 nmi.

TMA SHALL [1310] recommend possible super stream combinations in accordance with site preference as listed in the adaptation.

3.2.1.5.2.3. Finalize the Miles-in-Trail Restrictions for Manually Set and "Lightly" Loaded Streams

Some of the automatic Miles-in-Trail restrictions can be determined at the outset. Any super stream which has been manually set is not modified. Any super stream which has fewer than two aircraft is unaffected by the setting, and is set to 5 nmi in trail. Any super stream which would show no delays at the maximum Miles-in-Trail setting (generally 35 nmi) will be set to 5 nmi in trail since the super stream is too sparsely populated to be affected by any Miles-in-Trail restriction.

TMA SHALL [1311] set the Miles-in-Trail restrictions for the manually set super streams to their manually set restrictions and finalize them.

TMA SHALL [1312] set the Miles-in-Trail restrictions for super-streams to the minimum adapted level (generally 5 nmi) and finalize them if:

a. The super stream currently contains less than two aircraft.

b. No aircraft would delayed if the Miles-in-Trail restriction were to be set to the maximum adapted level (generally 35 nmi).

3.2.1.5.2.4 Iterate the Non-finalized Miles-in-Trail Settings to Meet the Requested AAR

All the super streams which have not been finalized are set to the maximum Miles-in-Trail restriction (generally 35 nmi). These restrictions are gradually lowered for super streams with the highest delays. When the Miles-in-Trail plan approximately reaches the desired AAR, the Miles-in-Trail restrictions for the various super streams are finalized.

TMA SHALL [1313] initialize Miles-in-Trail restrictions for super streams which have not been finalized to the maximum adapted level (generally 35 nmi).

TMA SHALL [1314] carry out an iterative process which successively lowers and finalizes the Miles-in-Trail restrictions for super streams using the following steps:

a. Calculate the average delay for each super stream using the current Miles-in-Trail restrictions.

b. For the super stream which has not been finalized and which has the highest average delay, decrement the separation value (i.e., the Miles-in-Trail restriction) to the next lower separation value in the adaptation.

c. Recompute the airport acceptance rate.

d. If the recomputed airport acceptance rate exceeds the target, the Miles-in-Trail restriction for this super stream reverts to its previous value, and the Miles-in-Trail restriction for this super stream is finalized.

e. The procedure is repeated until the Miles-in-Trail restrictions for all super streams have been finalized.

3.2.1.5.3. Adjacent Facility Metering

In order to get a view of future demand, TMA must receive track surveillance data for all aircraft within 200 nmi of the arrival airport except for oceanic airspace and the airspace of a foreign country. Figure 3.2.1.5.3-1 depicts a situation in which the 200-nmi radius circle centered at the CTAS airport extends beyond the Center boundary and includes Adjacent Center airspace.

Figure 3.2.1.5.3-1. CTAS Near a Center Boundary.

TMA SHALL [1380] receive track surveillance data from all airborne aircraft within 200 nmi destined to a CTAS adapted airport, except in the following cases:

a. Arrival aircraft currently over oceanic airspace.

b. Arrival aircraft currently over the airspace of a foreign country.

TMA SHALL [1390] receive track surveillance data from all airborne aircraft within 200 nmi destined to a CTAS adapted airport, from the following facilities:

a. The En Route Center containing the CTAS adapted airports.

b. The TRACON containing the CTAS adapted airports.

c. All En Route Centers which control any airspace within 200 nmi of a CTAS adapted airport.

d. ALL TRACONs which are within 100 nmi of a CTAS adapted airport.

TMA SHALL [1400] schedule all arrival aircraft for which tracks have been received from other facilities and are destined to a CTAS adapted airport in the same way as TMA schedules aircraft reported to be in its Center.

Having determined the total demand at the CTAS airport, it is necessary to meter aircraft arriving from the adjacent Center through coordination fixes that are closer than 200 nmi. This is because there is not enough delay capability within the arrival Center to produce an orderly arrival flow. The schedule at the coordination fix is calculated by passing excess delay back to the adjacent Center. A recommended Miles-in-Trail restriction is then calculated for each coordination fix.

Requirement 1410 has been deleted.

TMA SHALL [1420] calculate an aircraft's Center Maximum Delay (CMD) as the distance along the converted route from the coordination fix to the meter fix divided by twice the filed flight speed.

Figure 3.2.1.5.3-2 depicts the calculation of STAs at the coordination fix.

Figure 3.2.1.5.3-2. Calculation of Coordination Fix STA.

TMA SHALL [1430] calculate STAs for each coordination fix which will be the later of:

a. The ETA at the coordination fix.

b. The ETA at the coordination fix plus the excess delay allocated to the adjacent Center. The excess delay equals the delay calculated at the meter fix (STA minus ETA) minus the CMD (the delay that can be absorbed in the Center).

Figure 3.2.1.5.3-3 depicts the assignment of adjacent facility aircraft to an adapted "In-range" coordination fix (i.e., a coordination fix within 200 nmi of the arrival airport).

Figure 3.2.1.5.3-3. Assignment of Adjacent Facility Aircraft to an Adapted "In-range" Coordination Fix.

TMA SHALL [1431] assign every aircraft airborne in an adjacent facility within 200 nmi of the arrival airport to an adapted coordination fix by choosing the adapted coordination fix which is:

a. Closest to the entry point in the center, and

b. Accepts aircraft of the proper engine class (J=Jet, T=Turbo Prop, A=Piston).

Figure 3.2.1.5.3-4 depicts the assignment of adjacent Center aircraft to stream classes at an "In-range" coordination fix.

Figure 3.2.1.5.3-4. Stream Classes Entering the CTAS Center.

TMA SHALL [1432] assign every aircraft airborne in an adjacent facility within 200 nmi of the arrival airport to an Adapted Arrival Stream which is defined by adaptation for:

a. The selected coordination fix.

b. The aircraft engine class (J, T, A).

Figure 3.2.1.5.3-5 illustrates the Miles-in-Trail recommendation for a single stream at the coordination fix.

Figure 3.2.1.5.3-5. Calculation of Miles-in-Trail Recommendation.

TMA SHALL [1433] provide a Miles-in-Trail recommendation for every adaptation defined stream class entering the center from an adjacent facility recalculated every 15 minutes.

TMA SHALL [1434] calculate adjacent facility Miles-in-Trail recommendations as the average ground speed of all aircraft in the stream class multiplied by the number of aircraft in the stream class, then divided by the time between the first and last aircraft's STAs at the coordination fix.

TMA SHALL [1450] transmit the schedule at each major entry point and the Miles-in-Trail restriction for each major entry point back to the sending facility (ARTCC or TRACON).

3.2.1.5.4. Arrival Plan Preview Capability

In general usage, all TMA displays at the En Route Center and the TRACON will see a unified arrival plan which has been agreed upon by controllers at both facilities. At times, however, it will be beneficial for controllers to investigate alternate arrival plans, that is, to preview an alternate plan. Figure 3.2.1.5.4-1 depicts the preview capability.

Figure 3.2.1.5.4-1. Preview Capability.

TMA SHALL [1460] provide one preview arrival plan at the En Route Center, and one preview arrival plan at the TRACON without causing any degradation in the computation of the main arrival plan.

TMA SHALL [1470] allow a TMC to study the effect of modifying the following parameters:

a. Airport Configuration Changes.

b. Flow Rate or Acceptance Rate Changes.

c. Miles-in-Trail changes.

d. Gate / Meter Fix Changes (multiple aircraft).

e. Runway Change (multiple aircraft).

f. Blocked Intervals.

g. Blocked Slots.

h. Sequence Constraints.

i. Grouping and Merging of Stream Classes.

TMA SHALL [1480] provide the capability for TMCs in either facility to view:

a. The current arrival plan.

b. The Center's preview arrival plan.

c. The TRACON's preview arrival plan.

TMA SHALL [1490] mark all preview information in a way that makes it readily distinguishable from information from the main arrival plan.

TMA SHALL [1500] provide the capability for TMCs to duplicate the preview arrival plan parameters from the main arrival plan.

TMA SHALL [1510] provide the capability for TMC's to accept a preview plan as the main arrival plan.

3.2.2. FAST Processing

The FAST Processing function, hereafter in this section referred to as FAST, sequences, schedules and assigns runways to all arrival traffic destined for its adapted airport and controlled by the TRACON.

FAST provides and, constantly updates, a complete trajectory estimate of all aircraft into and within the TRACON airspace. It produces runway assignment and landing sequence number advisories for each aircraft, and sends them to the ARTS for display in aircraft data blocks on TRACON controller displays. It also provides ETAs and STAs which are displayed on timelines produced by the TMC GUI function on TMC displays available in the TRACON, Tower, and ARTCC. The ETAs are estimates of an aircraft's landing time if there were no air traffic considerations. The STAs provided are estimates of an aircraft's landing time taking into account all air traffic considerations.

The FAST Processing function is depicted in Figure 3.2.2-1. The input sources, appearing in italics, are shown at the top of the figure. The processing steps or subfunctions are shown in the central portion of the figure. The outputs of the function and their destinations, appearing in italics, are shown at the bottom.

Figure 3.2.2-1. FAST Function.

As depicted in Figure 3.2.2-1, functions within FAST are:

• Aircraft Processing.

• Generation of Unconstrained Trajectories & ETAs.

• Scheduling & Generation of a Global Trajectory Solution.

• Runway Reassignment.

These functions are site-adapted through the use of site adaptation data produced by the System's AVA capability.

3.2.2.1. Inputs & Outputs

FAST SHALL [1515] use the following inputs:

a. Adaptation data from AVA.

b. TRACON aircraft data from the TRACON Data Interface (TDI).

c. Center aircraft data from the Center Data Interface (CDI).

d. Adjacent Facility aircraft data from the Adjacent Facility TDI or CDI.

e. NWS Weather data via ETMS.

f. TMC entries from the TMC-GUI.

g. TRACON controller entries via the TDI.

h. Control data from the TRACON M&C function.

Upon initialization, FAST SHALL [1520] use the following adaptation data:

a. Feeder gates.

b. (subrequirement deleted)

c. Nominal TRACON routes.

d. Nominal TRACON speeds.

e. (subrequirement deleted)

f. (subrequirement deleted)

g. CTAS Adaptable airports.

h. Available runways.

i. Route Analysis Categories.

j. Degrees of Freedom.

k. Initial Routes.

l. Constraint definitions.

m. (subrequirement deleted)

n. Short Cycle Runway Decision Tree.

o. Long Cycle Runway Categories.

Requirement 1530 has been deleted.

FAST SHALL [1540] be capable of processing up to 200 aircraft (tracked, untracked with flight plan or tower en-route proposed) of which up to 100 aircraft can be scheduled if they meet all of the following criteria:

a. The aircraft is tracked by the HCS or ARTS.

b. The aircraft is destined to one of the six adapted airports in the TRACON.

c. The aircraft is within a site adaptable distance from TRACON airspace.

d. The scheduling for the aircraft has not been suspended by the TMC.

FAST SHALL [1550] calculate a new arrival plan every 6 seconds.

Whenever FAST receives new weather data, it SHALL [1560]

a. Update its weather information.

b. Update its flight plan ETAs.

Whenever it receives any of the TMC commands specified in Section 3.2.3.4, FAST SHALL [1570] update its arrival plan at the next 6-second schedule update.

Requirement 1580 has been deleted.

FAST SHALL [1585] produce the following outputs every 6 seconds:

a. TMC display data (including runway and sequence numbers) to the TMC-GUI.

b. Runway and sequence numbers sent to controller's screens via TRACON Data Interface (TDI).

c. Status monitoring data to the M&C function.

Track data are sent (from the Center Data Interface) for every aircraft that is within an adaptable distance from the TRACON. The Center Data Interface continues sending data to FAST until an aircraft is established under track on the TRACON system (ARTS or STARS). TRACON data are sent to FAST for the remainder of the flight.

Requirement 1590 has been deleted.

3.2.2.2. Aircraft Processing

In most cases, the first notification of a new aircraft to the FAST Processing function is the receipt of the Flight Plan from the Center Data Interface. In response to this, the function calculates a nominal ETA which is sent to the TMC GUI function. If the track data indicate that an aircraft is within a site adaptable distance from the TRACON, the aircraft is considered to be a "new" aircraft. An aircraft which is new to the FAST Processing function and which was processed by the Center TMA Processing function of the En Route CTAS will be assigned initially to the default runway from the adaptation. This runway may or may not agree with the TMA assignment. The default runway assignment will remain in effect until the FAST Processing function's runway re-assignment time window is reached. FAST uses the "direct to the gate route" for new aircraft outside the TRACON, which may not be the same as the TMA route.

Whenever FAST receives a new aircraft (via a flight plan or a first track report), it SHALL [1600] initialize a new arrival plan containing:

a. Runway assignment.

b. Direct-to-gate route assignment.

Whenever FAST receives a new aircraft via a first track report (without a flight plan) it SHALL [1605] request a flight plan from both the Center Data Interface (CDI) and the Adjacent Facility.

Requirements 1610 and 1620 have been deleted.

Every 6 seconds, FAST SHALL [1630] estimate and make available for display the number of arrival aircraft airborne and visible in the TRACON based on ARTS radar reports.

3.2.2.3. Generation of Unconstrained Trajectories and TAs

A trajectory is calculated by modeling the flight of the particular type of aircraft over the prescribed ground track, and by applying appropriate speed and altitude constraints. A byproduct of the trajectory calculation is the TTF over that trajectory. This time, added to the track report time, is called the Time of Arrival (TA).

Since the inputs to the trajectory generation are based on adaptation and the current aircraft situation, the adaptation and current aircraft situation are evaluated before any trajectory construction begins. In the terminal airspace, vertical flight paths are prescribed by air traffic procedures. Therefore, simplified algorithm and aircraft models can be used to model flight in the TRACON airspace as compared to flight in Center airspace.

Descents can be modeled using prescribed speed (CAS) and a fixed inertial flight path angle, e.g., a 3:1 ratio (3 nmi flown per 1000-foot descent) for jets and a 4:1 ratio (4 nmi flown per 1000-foot descent) for other types of aircraft. Simplified aircraft models can be used to determine deceleration rates and landing speeds for the flight segment between FAF and the runway threshold.

FAST SHALL [1640] calculate all trajectories using kinematic equations based on air traffic control procedures chosen to be within the capability of the aircraft type. The kinematic equations are first order differential equations which reflect four existing modes, as follows:

a. Fixed speed and fixed altitude.

b. Fixed CAS and constant glide slope descent.

c. Fixed altitude and idle thrust deceleration.

d. Ascent modes for departures within the TRACON.

This function generates a set of TAs for each aircraft on every track position update (from either the HCS or the ARTS). The trajectory is termed "unconstrained," since it does not take into account the presence of other aircraft . The function executes asynchronously, triggered by the an aircraft's track update, and acts as a server for the rest of the FAST processing. On each track update, the function calculates a number of TAs for different pre-planned routes from the current position to landing on an eligible runway.

The function uses a constant CAS/constant glide slope descent profile which is different from the fuel efficient descent profile used by TMA. The adaptation is set so that the route with all Degrees of Freedom (DOFs) set to their nominal position is the same as the TRACON nominal route used by TMA. This reduces ETA discrepancies between TMA and FAST.

All potential TAs for an aircraft to a particular eligible runway are grouped into a data structure known as the "Analysis Packet." The analysis packet contains TAs for all "initial routes" and all adapted settings of the applicable DOFs. The DOF settings specified by the adaptation are usually "Fast", "Slow", "Nominal", "Only", and "Simultaneous".

Unconstrained trajectories and TAs are calculated to all candidate runways to support runway re-assignment. Once a runway assignment has been finalized, unconstrained trajectories are constructed only to the assigned runway in support of scheduling.

FAST SHALL [1650] calculate unconstrained trajectories and their associated TAs for all aircraft to all eligible runways on all specified initial routes using all DOFs.

3.2.2.3.1. Calculate Analysis Category

The analysis category defines the situation of an aircraft as determined by a set of rules specified in site adaptation. Examples of categories for an aircraft might be as follows:

• On the Ground in the ARTCC (about to take-off).

• On the Ground in the TRACON (about to take-off).

• Airborne in the ARTCC within 50 nmi of the TRACON.

• Airborne in the TRACON on the RIGHT_DOWNWIND part of the landing pattern for runway 35L.

•. Airborne in the TRACON on the LEFT_DOWNWIND part of the landing pattern for runway 35L.

• Airborne in the TRACON on the RIGHT_BASE part of the landing pattern for runway 35L.

• Airborne in the TRACON on the LEFT_BASE part of the landing pattern for runway 35L.

• Airborne in the TRACON on the FINAL_APPROACH part of the landing pattern for runway 35L.

• Airborne in the TRACON on the RIGHT_LONG part of the landing pattern for runway 35L.

• Airborne in the TRACON on the LEFT_LONG (Over the top) part of the landing pattern for runway 35L.

• Airborne in the TRACON on the RIGHT_SHORT part of the landing pattern for runway 35L.

• Airborne in the TRACON on the LEFT_SHORT (Over the top) part of the landing pattern for runway 35L.

• Missed Approach.

• Priority Aircraft.

The nominal routing, the available DOFs remaining in the route, and the DOF settings requested for analysis depend upon the analysis category determined for the aircraft. This analysis category is also important for the TRACON area deconfliction algorithm. This category determines which segments of the landing pattern remain and must be assessed for conflict.

FAST SHALL [1660] have a repertoire of DOFs available in adaptation which includes, at a minimum:

a. (subrequirement deleted).

b. Vary location of speed reductions.

c. Trombone base extension.

d. (subrequirement deleted).

e. S-turns.

f. (subrequirement deleted).

g. Corners varying intercept distance.

h. Base fanning.

i. Base extensions.

j. Fan from waypoints.

k. Path stretch from waypoints.

On each radar update, FAST SHALL [1670] determine each aircraft's adapted analysis category based on:

a. The aircraft track data.

b. Anticipated airport configuration.

c. Site Adaptation.

d. Manual input.

e. Meter Fix.

f. Gate.

g. Engine Type.

h. Airport.

i. Runway.

j. Approach Segment.

k. Flight Plan Status.

l. Priority Aircraft.

Based on the adapted analysis category, FAST SHALL [1680] determine for each aircraft:

a. The DOFs.

b. The number of initial routes.

c. The order of preferred application of DOFs for the remaining flight segments.

d. The eligible runways.

e. The unconstrained DOF settings, i.e., Fast, Slow, Nominal, Only, and Simultaneous, as defined in Table 3.2.2.3.1-1.

Table 3.2.2.3.1-1. Unconstrained DOF Settings

Setting	Description of Unconstrained DOF
Fast	Results in the Fastest trajectory for the specified route.
Slow	Results in the Slowest trajectory for the specified route.
Nominal	Results in the trajectory specified in the adaptation as "Nominal".
Only	Results in the trajectory specified in the adaptation as the only allowable route.
Simultaneous	The degree of freedom is positioned however it would be necessary so that the aircraft performs a simultaneous approach with another aircraft.

3.2.2.3.2. Generate Unconstrained Trajectories for All DOFs

This function generates unconstrained trajectories for each aircraft, for each eligible runway for each initial route, and all variations requested by DOF variation. The results of this calculation (for each aircraft and runway) are placed into the analysis packet. Figure 3.2.2.3.2-1 represents an example analysis packet in which three DOFs are applicable for a route which leads to a certain runway.

In addition to the TA information, data about the path length and delay are stored in the analysis packet. The example shown in Figure 3.2.2.3.2-1 contains three DOF levels. The path length from the aircraft's current position to the point at which the DOF applies is depicted in the upper box for that DOF level. At each level, the possible delays, i.e., the TA differences caused by the DOF, are depicted in the boxes below the path length box.

Figure 3.2.2.3.2-1. An Example Analysis Packet.

Based on the DOF settings requested in the adaptation, as depicted at the bottom of Figure 3.2.2.3.2-1, the following seven routes are generated in this example:

Route #	DOF 1	DOF 2	DOF 3
1	Fast	Only	Fast
2	Fast	Only	Slow
3	Nominal	Only	Fast
4	Nominal	Only	Nominal
5	Nominal	Only	Slow
6	Slow	Only	Fast
7	Slow	Only	Slow

On each radar update, FAST SHALL [1690] calculate the analysis packet for each aircraft for each eligible runway containing:

a. The set of TAs.

b. For each route, the path distances at which specific DOF's are applied.

c. The resultant incremental delay (zero for the fastest setting and larger than zero for other settings of that degree of freedom).

3.2.2.3.3. Select TA for Display

Out of the entire tree of degree of freedom settings, one particular trajectory is defined as the nominal trajectory. This trajectory is used to generate the TA which is displayed on the TMC display. This TA, called the ETA, is usually defined in the adaptation to be the route with all the DOFs set to their Fast position.

FAST SHALL [1710] select the TA corresponding to the DOF settings specified in the adaptation for display on the TMC display as the ETA.

FAST SHALL [1715] SHALL display "ZZZ" for any aircraft for which no TA could be calculated.

3.2.2.4. Sequencing

Sequencing is described in two sections. The first section describes the fuzzy rules for comparing one aircraft in a sequence against another, and the second describes the mechanism by which these rules are applied to generating a global sequence with all conflicts minimized.

FAST SHALL [1720] generate a sequence for all schedulable aircraft on all adapted runways for all adapted airports.

3.2.2.4.1. Rules for Pairwise Ordering

Several attributes are compared for each aircraft in the pair (call them aircraft A and aircraft B) to be ordered. Among these attributes are: altitude, speed, and position at the present time or at some future time. The difference in attribute values contributes in some measure to a scalar decision variable which accumulates values "in favor of aircraft A going first" or "in favor of aircraft B going first". In order to be able to add values of attributes with incompatible physical dimensions (e.g., feet for altitude, knots for speed, and nautical miles for distance) the differences are first mapped by prescribed attribute functions into dimensionless quantities (in this case values between 0.0 and 1.0).

For example, an altitude difference (A lower than B) would be mapped by (for example) a linear function in the range 500 to 1500 feet such that a 500 feet difference maps into 0.0 and 1500 feet into 1.0. Values below 500 feet all map to 0.0 and values greater than 1500 feet all map to 1.0. An observed altitude difference where A is lower than B of 1000 feet would result in a dimensionless number 0.5. This number is referred to as the "membership value" and will be used to obtain a value for the contribution of the altitude difference property in favor of A.

First one must decide how important the contribution of each attribute is in the ordering decision. For example, the fact that A is lower than B could be only marginally important to the decision to order A ahead of B. This might be reflected in the placing of triangles on an x scale from 0 to 50 for contributions in favor of A, and from 0 to -50 for contributions in favor of B. A triangle (its size and its placement on the x axis) represents the relative importance of an attribute contribution to the ordering decision, since that decision will be based on a moment calculation adding the moments (x times the area of the triangle after that area has been modified by the membership value) of all attributes. For simplicity, all triangles were chosen to be identical isosceles with base 10 and height 1 and placed with the base on the x-axis so that the midpoints are located on multiples of 7.5. In the range of 0 to 50 this allows for 6 triangles.

The attribute membership value is now used as a limit on the height of the triangle and thus reduces the area to that of a regular trapezoid. For example, the triangle which represents a weighting that A is only marginally ahead (center of base at x=7.5) will have its height limited to the value of the attribute membership (e.g., 0.5). The area of the triangle is now reduced to that of a trapezoid which in the example would equal 3.75 and the contribution to the sum of moments would be 7.5 times 3.75 in favor of A. When all the attributes have been examined, both in favor of A and in favor of B, the decision will be to order A ahead of B if the scalar value which is the sum of moments in favor of A exceeds the scalar value in favor of B, and vice versa.

In general, each type of ordering process can define a set of contributing attributes and the ways in which they are to be evaluated. These are the "antecedents" of the rules. As explained before, a mapping is applied to translate the result into a membership value between 0 and 1. For each antecedent, a "consequence function" is defined, which identifies which triangle is to be used. The membership value, applied to the triangle, allows the calculation of the contribution of the given rule.

The "fuzzy rule" specifies the antecedent and the consequence. The word "fuzzy " refers to the fact that an antecedent is not just true or false (usually associated with membership values 1 and 0) but is most of the time only partially true (thence the provision of membership values which can be any number between 0.0 and 1.0).

The use of isosceles triangles to represent the consequence functions and the choice of their shape and their location on the x-axis is a quite arbitrary implementation choice. We therefore relegate the specification of membership functions in the antecedents and the weighting functions in the consequences (triangle description) to Appendix B.

In this section, we have three different ordering operations, each of which has its own set of fuzzy rules: 1) ordering aircraft when merging them onto the final segment, 2) ordering them when on a final segment, and 3) ordering when on a general (not final) segment. However, all three sets of rules use some or all of the same antecedent membership functions shown in Appendix B. And, while these membership functions apply for evaluations of rules "in favor of A", the same functions can be used when evaluating the mirror rules when evaluating the rules "in favor of B".

FAST SHALL [1730] order two aircraft based on the combined outcomes of a set of rules where each rule examines a particular attribute of an aircraft (such as altitude or speed or position on a common segment).

FAST SHALL [1740] sequence each type of trajectory segment with the appropriate set of fuzzy rules:

a. GENERAL, reference Section 3.2.2.4.1.1.

b. FINAL, reference Section 3.2.2.4.1.2.

c. DEPENDENCY, reference Section 3.2.2.4.1.3.

d. CROSSOVER, reference Section 3.2.2.4.1.1 (same as GENERAL).

With each of the following attributes listed below FAST SHALL [1750] associate a membership function (mapping an attribute value to a membership value between 0.0 and 1.0):

a. Delay Required.

b. Delay Remaining.

c. Delay Savings.

d. Altitude Difference.

e. Current In-trail Separation.

f. Current Ahead Separation.

g. Ground Speed Difference.

h. Ahead on Downwind Separation.

i. Separation at common time step.

j. Distance between aircraft.

FAST SHALL [1760] use fuzzy logic consequences which are:

a. Marginally ahead.

b. Slightly ahead.

c. Somewhat ahead.

d. Ahead.

e. Quite ahead.

f. Significantly ahead.

FAST SHALL [1765] implement the consequence functions in the form of isosceles triangles with the base resting on the X axis, the base having width 10, the height being 1, and the center of the base is:

a. Marginally ahead. X = 7.5

b. Slightly ahead. X = 15.0

c. Somewhat ahead. X = 22.5

d. Ahead. X = 30.0

e. Quite ahead. X = 37.5

f. Significantly ahead. X = 45.0

FAST SHALL [1770] sum the consequence functions resulting from all fuzzy rules for aircraft-to-aircraft comparison.

In aircraft to aircraft comparison, FAST SHALL [1780] order the two aircraft based on the sign of the centroid of all consequence functions.

3.2.2.4.1.1. Rules for Ordering On a General Constraint

When comparing two aircraft, five fuzzy logic rules are used, each with at least one consequence. These five rules are used to sort the list of aircraft currently on this segment. These rules are also used to merge all the lists into the sequence for this general segment as shown in Figure 3.2.2.4.1.1-1. The list of aircraft currently on feeding segments was sorted by the same operation when that feeder segment was the current segment in the previous iteration of this algorithm.

When sequencing aircraft A and B on a GENERAL constraint segment, FAST SHALL [1790] use the following fuzzy rules :

a. Antecedent: is SA less than SB ? Consequence: A is slightly ahead where SA is defined to be the path distance from the current location of A to the predicted position of A valid at the first instant when both aircraft are predicted to be on this segment. Similarly, define SB for aircraft B.

b. Antecedent: At the first instant when both aircraft are predicted to be on this segment, how far is A ahead (in path length) of B? Consequences: A is significantly ahead, A is ahead, A is slightly ahead.

c. Antecedent: At the first instant when both aircraft are predicted to be on this segment, how much lower (in altitude) is A than B? Consequence: A is marginally ahead.

d. Antecedent: At the first instant when both aircraft are predicted to be on this segment, how much faster (in ground speed) is A than B? Consequence: A is marginally ahead.

e. Antecedent: At the first instance when both aircraft are predicted to be on this segment how close is A to B? AND how much faster is A than B? Consequence: A is slightly ahead.

FAST SHALL [1800] use a set of fuzzy rules identical to the ones listed in requirement 1790 where the roles of aircraft A and B are interchanged. This set of fuzzy rules is sometimes referred to as the "mirror image" set of rules.

Figure 3.2.2.4.1.1-1. Fuzzy Rules on a General Constraint.

3.2.2.4.1.2. Rules for Ordering on a Final Constraint

Two sets of rules are applicable during the sequencing operation for a FINAL Constraint.

The first set of rules is for the merging of the list of aircraft currently "on FINAL" with the list of aircraft currently "near FINAL."

The second set of rules is for merging the resulting list with possibly several lists of aircraft on feeding segments.

The relationship between lists and fuzzy rules 1 and 2 is shown in Figure 3.2.2.4.1.2-1.

Figure 3.2.2.4.1.2-1. Fuzzy Rules on a FINAL Constraint.

FAST SHALL [1810] construct two lists of aircraft which are "on or near FINAL", consisting of:

a. Aircraft which are currently on FINAL, sorted by current path distance to the runway threshold.

b. Aircraft which are near the FINAL approach segment, as defined in the adaptation, sorted according to the FINAL approach sequence from the previous update cycle.

FAST SHALL [1820] calculate TRACON delay capability based on the maximum delay achieved during the generation of unconstrained ETAs.

FAST SHALL [1830] use the relative ordering of two aircraft on the previous cycle if both aircraft have used up more than 95% of their TRACON delay capability.

Otherwise, to merge an aircraft A which is on FINAL with an aircraft B which is near FINAL, FAST SHALL [1840] use fuzzy rules (set 1 in Figure 3.2.2.4.1.2-1) which are:

a. Antecedent: By how much is A's TTF to the runway less than B's? Consequences: A is marginally ahead, A is slightly ahead, A is somewhat ahead.

b. Antecedent: By how much has A exceeded its 95% delay time (out of delay, significantly out of delay)? Consequences: A is ahead, A is significantly ahead.

c. Antecedent: Is aircraft A currently at a lower altitude than aircraft B? Consequence: A is somewhat ahead.

d. Antecedent: By how much is A's TTF to the runway less than B's? AND aircraft B is not significantly delayed. Consequence: A is ahead.

e. Antecedent: How much less is the total delay with A ahead of B than with B ahead of A? Consequence: A is marginally ahead.

f. Antecedent: How much is aircraft A delayed (slightly delayed, delayed, significantly delayed)? Consequences: A is slightly ahead, A is marginally ahead.

FAST SHALL [1845] use a set of fuzzy rules identical to the ones listed in requirement 1840 where the role of aircraft A and B is interchanged.

FAST SHALL [1850] retain the ordering from the previous update cycle of FAST when comparing two aircraft which have both expended 95% of their TRACON delay capability.

Otherwise, to merge an aircraft A which is on FINAL with an aircraft B which is currently on or near FINAL, FAST SHALL [1860] use fuzzy rules (set 2 in Figure 3.2.2.4.1.2-1) which are:

a. Antecedent: How much is A closer than B to the end of DOWNWIND? Consequence: A is somewhat ahead.

b. Antecedent: Is aircraft A currently at a lower altitude than aircraft B? Consequence: A is slightly ahead.

c. Antecedent: By how much has A's schedule exceeded the maximum delay time (out of delay)? Consequence: A is significantly ahead.

d. Antecedent: How much is aircraft A delayed (significantly delayed, delayed or slightly delayed)? Consequence: A is either ahead, A is slightly ahead, A is marginally ahead.

e. Antecedent: How much less is the total delay with A ahead of B than with B ahead of A? Consequence: A is slightly ahead.

f. Antecedent: Is aircraft A "in trail" behind any aircraft? Consequence: A is marginally ahead.

g. Antecedent: Is any aircraft "in trail" behind aircraft A? Consequence: B is marginally ahead.

FAST SHALL [1865] use a set of fuzzy rules identical to the ones listed in requirement 1860 where the role of aircraft A and B is interchanged.

3.2.2.4.1.3. Ordering on a Dependency Constraint

FAST SHALL [1870] sequence aircraft on the following DEPENDENCY constraints using exactly the same rules as are used for a FINAL constraint:

a. Staggered Approach. The "staggered approach" may begin as close to the runway as 2 nmi outside the outer marker. Aircraft on the same runway must have wake vortex separation. The aircraft on staggered dependent runways are required to be separated by 2 nmi at all times.

b. Simultaneous Approach. The "simultaneous approach" must be initiated approximately 11.5 nmi from the threshold at a published fix. Aircraft are initially required to be altitude separated. Aircraft on the same runway must have wake vortex separation. Once parallel runway monitoring is established there is no separation requirement for aircraft on simultaneous dependent runways. These aircraft are allowed to land truly simultaneously, if desired.

3.2.2.4.2. Applying the Ordering Rules

This section details the mechanism by which the rules for pairwise ordering of aircraft are applied to create the sequence for all aircraft assigned to a given runway. Sequences for all runways will thus be created.

3.2.2.4.2.1. Establishing the Membership List for All Route Segments

The first step in creating the (final or global) sequence for a runway is to identify all route segments of all selected trajectories which will be traversed by any of the aircraft destined to land on the runway at some future time. These selected trajectories are the set of fastest trajectories (i.e., where all Degrees-of-Freedom are set to their fastest values). Since an aircraft could reach a runway via several routes only the fastest of all trajectories over these several routes is retained in the selected set ("working set"). The underlying route segments of the selected trajectories play a crucial role in the sequencing operation. For each such segment one identifies a list of all pairings of aircraft and time-intervals during which that aircraft will be traversing the segment. This list is the "membership list" (and is implemented by a list of pointers into the trajectories of the working set).

FAST SHALL [1880] create the set of fastest trajectories for each initial route for each eligible runway for each aircraft. This set is called the "initialization set."

FAST SHALL [1890] create the "satisfaction" set of trajectories which consists of the subset of the trajectories in the initialization set where for each aircraft only the fastest the trajectory over all its initial routes to the current runway is retained.

FAST SHALL [1900] decompose the satisfaction set trajectories into a set of standard segments and construct the membership list for each segment.

3.2.2.4.2.2. Sequencing Aircraft on Any Segment

A segment is "sequenced" when its membership list of aircraft is ordered. By definition the global sequence (i.e., involving all aircraft currently destined and assigned to the runway) will be obtained when the FINAL segment has been sequenced.

In order to sequence aircraft for ANY segment one must first have ordered its feeding segments since ordering any segment involves merging an ordered list of aircraft currently on the segment with ordered lists of aircraft currently on the direct or indirect feeder segments. This means that, in order to obtain the sequence for segment FINAL, one must first have sequenced its feeder segments, which in turn requires that their feeder segments were first sequenced, etc. The first segment to be sequenced will therefore be the farthest out segment which itself has no feeder segments and has currently aircraft "on" it destined to the runway.

FAST SHALL [1910] recursively sequence aircraft for all segments which directly or indirectly are feeder segments for the FINAL segment and sequence the FINAL segment by the methods described below.

For any segment which is not the FINAL segment FAST SHALL [1920] sequence aircraft for that segment by merging the ordered list of aircraft currently on the segment with ordered lists of aircraft for direct feeder segments.

FAST SHALL [1930] execute this merge by ordering the set of aircraft which are first on each list by applying the fuzzy rules of Section 3.2.2.4.1.1 for each pair of aircraft in the set.

The aircraft declared "first" is then removed from its list and the next aircraft on the list is now first. The operation continues until all lists are exhausted and the merge is terminated.

For the FINAL segment FAST SHALL [1940] sequence aircraft in two steps:

a. The lists of aircraft "currently on" FINAL and the list of aircraft "currently near" FINAL are merged by comparing the pair of aircraft listed first using fuzzy rules set 1 in Section 3.2.2.4.1.2 and sequencing the winner as first, removing it from its list to reveal the next candidate for comparison etc. The resulting merged list is now input to step b.

b. The resulting list is merged with the sequenced list of the direct feeder segments using the same procedure of merging and selection of pairs of aircraft for comparison but using fuzzy set of rules Set 2 in Section 3.2.2.4.1.2).

The two steps are illustrated in the Figure 3.2.2.4.1.2-1.

The resulting sequence is the final sequence for the runway which will be scheduled next.

3.2.2.5. Scheduling at the Runway

A schedule is derived for the timeline display. This schedule shows aircraft in the established sequence, but with time separations derived from the minimum required wake vortex separations at the runway, as provided by the adaptation. This schedule does not guarantee that the trajectories which could implement this schedule would be conflict free everywhere since the calculation of global conflict minimized trajectories has yet to be completed. These calculations may require additional delays which make the displayed STAs invalid. NOTE: The STAs resulting from the calculation of conflict minimized trajectories are not displayed.

FAST SHALL [1950] generate schedules for every active runway in the established sequence such that the STA of a given aircraft is the later of:

a. The ETA of that aircraft.

b. The STA of the aircraft ahead of that aircraft in the sequence (for this runway) plus the minimum aircraft separation (expressed in time units) at the threshold based on wake vortex rules.

From update cycle to update cycle, FAST SHALL [1960] not change the STA for any aircraft that it sends to TMC-GUI unless the change exceeds a site adaptable value (nominally 5 seconds).

3.2.2.6. Global Constraint Resolution

The definition of required separation (violation of which is defined as a conflict) is given in the adaptation. Separation is defined in terms of wake vortex distance and in terms of altitude separation. The separation requirements for the FINAL_APPROACH segment may be changed by a controller entry, but those on other segments in the TRACON may not be changed.

FAST SHALL [1970] attempt to produce a set of global conflict free trajectory solutions by adding delay to flight segments (constraints) prior to conflicts through the use of available DOFs.

Requirement 1980 has been deleted.

If the delay from the available DOFs is not sufficient to resolve all conflicts, then FAST SHALL [1990] attempt to use longer "initial routes" for the aircraft, if any are defined in adaptation.

FAST SHALL [2000] define separation requirements (on each constraint) in terms of altitude and wake vortex separation in the adaptation.

FAST SHALL [2010] allow the separations requirements for FINAL approach to be modified by controller input.

The number of aircraft in the sequence to be analyzed for potential conflict is set to two. This means that each aircraft is checked for conflict with the two aircraft ahead of it in the sequence on each constraint independently.

FAST SHALL [2020] search for conflicts between the present aircraft and two leading aircraft in the sequence of each constraint.

A basic rule about the deconfliction process is that the FINAL_APPROACH sequence is maintained throughout the TRACON except for the "constraint segment" which the aircraft is actually on. This has occurred in an automatic fashion as all feeding sequences have been preserved in each merged sequence.

If a fast aircraft is behind a slow one, but is sequenced to land first, FAST assumes that the faster aircraft will pass the slower one immediately (on the current segment). In other words, order violations are moved as far as possible away from the airport.

The first aircraft sequenced to a runway is assigned to its fastest trajectory (all DOFs set to the fast setting). This trajectory becomes permanently established and cannot be changed.

Each subsequent aircraft compares its fastest trajectory with the established trajectories for the two aircraft (adaptation dependent) ahead of it. Starting with the current position a search is made for any conflict between this aircraft and the two ahead of it.

Starting with aircraft closest to the runway, FAST SHALL [2030] select the next later aircraft checking for conflicts of the aircraft with the previous two aircraft, until that aircraft is closest to the runway.

FAST SHALL [2040] resolve each conflict it detects before searching along the rest of the route for subsequent potential conflicts.

If no conflict is found, the fast trajectory for this aircraft becomes permanently established. However, as soon as any conflict is detected, the software branches immediately to the delay resolution code. No further analysis is performed until that conflict is eliminated.

The analysis packet provided for this aircraft (to this runway) lists all the DOFs ahead of the aircraft, and the path distance ahead at which they occur. All DOFs between the current position and the detected conflict are considered for conflict resolution.

The DOFs listed in the adaptation are in the order of preferred use. From the adaptation list, all DOFs that are between the aircraft and the conflict are tried in order. If the delay from one DOF is insufficient to resolve the conflict, the current DOF is left at the slowest position and the next DOF is added.

FAST SHALL [2050] use DOFs between the current aircraft position and the potential conflict to insert delay to resolve the conflict if necessary in the order of preference listed in the adaptation.

If the conflict can be resolved with the available DOFs, the DOF settings are kept, and the remainder of the trajectory is searched for conflict. If further conflicts are detected, additional delay is inserted using DOFs. There is a chance that DOFs which were not available to solve the first conflict may be available to solve the second. If possible, additional delay from all available DOFs is inserted to resolve the conflict.

If the second conflict is resolved, the conflict search continues until the runway threshold is reached. If this occurs successfully with all conflicts being resolved, the resulting trajectory becomes permanently established.

If any of the conflicts cannot be resolved by use of the DOFs, the trajectory is said to be at its DOF limit. In this case, the adaptation is searched for any other initial routes which lead from the current position to the assigned runway. These other initial routes presumably have a longer flight time to the runway, and may have a better chance of resolving any conflicts which are found. In order to analyze potential conflicts the new initial route trajectory must be segmented again by constraint segments, creating another membership list.

If an aircraft cannot be deconflicted using all available DOFS, FAST SHALL [2060] attempt to use other (slower) initial routes for that aircraft.

If a variant of one of these other initial routes is found that resolves all conflicts, its trajectory becomes permanently established.

If the slowest initial route using all available DOFs is unable to resolve a particular conflict, it is still used with the slowest DOF settings. The remainder of the trajectory is still analyzed for conflict. Additional DOFs may be used to resolve further conflicts. If these other conflicts cannot be resolved, the slowest DOF settings are used.

This slowest possible route (with at least one conflict unresolved) becomes permanently established.

If a conflict-free trajectory cannot be achieved, FAST SHALL [2070] produce a conflict-minimized trajectory by applying the maximum possible delay prior to each violation.

This task of trajectory deconfliction is continued (aircraft by aircraft) until a permanently established trajectory is determined for every aircraft. This set of trajectories is known as the global conflict-minimized trajectory set.

FAST SHALL [2080] calculate the total TTF of all aircraft presently scheduled by FAST, for the established runway assignment and conflict-minimized trajectory solutions to all runways.

3.2.2.7. Runway Reassignment

All aircraft in the satisfaction set are examined for runway reassignment every FAST update cycle. This processing intensive task ultimately requires the calculation of complete alternate arrival plans. Computer workload is reduced by a process known as the "Short Cycle", where the number of aircraft-runway pairs which are candidates for re-assignment is quickly reduced to just a few (between zero and five).

These final runway reassignment candidates are evaluated in more detail for benefit by a full calculation known as the "Long Cycle", which results in a single recommendation.

But even this recommended reassignment may be modified or substituted by means of the "switch criteria" consisting of a lookup table recommending that certain types of runway reassignments be switched with other runway reassignments.

The runway reassignment process is limited to investigating the effect of reassigning a single aircraft to another runway, as opposed to reassigning multiple aircraft simultaneously. The criterion used for evaluating the benefit of such single reassignment is that overall delay will be reduced by at least a prescribed amount (such thresholding is intended to compensate for the likely increase in workload ensuing from the execution of the reassignment).

3.2.2.7.1. Determine a Candidate Aircraft-Runway Pair for Reassignment (Short Cycle)

Aircraft are eligible for runway assignment only between certain (adaptation specified) estimated times to landing, referred to as the "allocation window". For example, all aircraft predicted to be between 13 and 24 minutes from landing are eligible for reallocation. The allocation window is defined per runway and per configuration in the configurations file of the adaptation. The runways to which a specific aircraft can be reallocated depend on the aircraft position and on adaptation that limits the runways to those most likely ever to be used by controllers (instead of all open runways). The aircraft-runway pairs eligible for examination in the short cycle reallocation algorithm constitute the work list.

When an aircraft has just entered the window there are usually multiple runways in the airport configuration to which it could be assigned As time continues, there will be fewer and fewer runways to which it could be assigned.

The evaluation of candidate aircraft is based in large part on the nominal STAs generated in Section 3.2.2.5. These schedules are based on deconfliction at the runway only, and not on deconflicted trajectories of all involved aircraft down to the runway (this is reserved for the long cycle). Each entry in the work list (an aircraft/alternate runway pair) is evaluated for its effect on "system flight time". The term system flight time is used to mean total TTF and refers to the sum of time to fly of all aircraft in the schedules for all runways.

First, the current schedules are used to calculate the current total TTF. Then the aircraft mentioned in the selected entry of the work list is removed from its currently assigned runway (which is defined as the "off-loaded runway") and tentatively assigned to the alternate runway (which is defined as the "on-loaded runway"). The new system flight time differs only from the current one by the TTF of the schedule of the on-loaded and the off-loaded runway, which are calculated separately.

FAST SHALL [2090] select an aircraft for runway reassignment if its nominal ETA (i.e., from the fastest trajectory) falls within the allocation window.

FAST SHALL [2100] evaluate all aircraft reassignments to all eligible runways based on system flight time for all aircraft in the system. The evaluation of this quantity will be based on the STAs at the runways.

FAST SHALL [2110] evaluate the total time to fly for an off-loaded runway schedule based on the nominal runway schedule from which the designated aircraft (offloaded aircraft) is removed.

In order to calculate the total TTF for the on-loaded runway, the new aircraft has to be inserted into the schedule. This is done based on the ETAs for aircraft on the new runway and using the first come first served sequencing method. A simple scheduler is now run for this runway using wake vortex separation requirements at the runway threshold. Several aircraft in the sequence behind the new aircraft may be scheduled to land at a later time because of delays caused by the inserted aircraft.

FAST SHALL [2120] evaluate total time to fly for an on-loaded runway by recalculating the nominal schedule with the on-loaded aircraft inserted based on its ETA order (relative to the other aircraft).

The system flight time for the alternate assignment is the sum of the time to fly calculated in requirements 2110 and 2120 plus the total times to fly for the other runways unaffected by the re-assignment. The difference of the system flight times before and after the tentative reassignment is called the "global delay saving" (not necessarily a positive number) for the aircraft/runway pair examined and is stored in the work list. The above mentioned process is repeated for all entries on the work list (aircraft/runway pairs). When this process is completed, every entry in the work list has an associated global delay saving.

FAST SHALL [2130] calculate the global delay saving for every eligible reassignment (aircraft-runway pair).

A decision tree is consulted for each of the entries in the work list. There are eight criteria called the "short cycle criteria". The effect of the decision tree is to determine (under different circumstances) how much global delay saving is required to advance an aircraft-runway pair to candidacy.

FAST SHALL [2140] assign every candidate aircraft-runway reassignment pair a minimum global delay saving to be achieved for consideration. This minimum global delay saving will be based on a decision tree specified in the adaptation.

Only the work list entries which have sufficient global delay savings to pass the delay reduction decision tree criteria (specified in adaptation) will be retained for further consideration.

FAST SHALL [2150] advance every aircraft-runway pair to the final candidate list of assignments if that pair produces a global delay saving that exceeds its adaptation specified minimum.

Experience at DFW has shown that the Short Cycle produces between zero and five candidate aircraft reassignments (on each cycle). Out of these candidates, the ones which have never been considered for Long Cycle analysis are given absolute priority. Of the remaining candidates, or of all the candidates if all pairs had previously been considered in a Long Cycle analysis, only the one pair which is ranked the highest by a set of rules is retained for the "alternate trajectory analysis" in the Long Cycle. The other pairs in the ranking are retained until long cycle analysis has been completed.

FAST SHALL [2160] give absolute preference to the candidate aircraft-runway pairs which has never been considered for the Long Cycle analysis.

FAST SHALL [2170] rank successful Short Cycle candidate aircraft/runway pairs by:

a. First, the number of cycles since this aircraft-runway pair was last considered for alternate trajectory analysis.

b. Then, by the amount by which this aircraft-runway pair exceeded its decision tree specified global delay saving minimum.

The list is sorted so that in the future, perhaps, more than one candidate runway reassignment may be considered or if the highest ranked pair fails Long Cycle analysis a next highest ranked candidate can be examined.

At the end of the Short Cycle, FAST SHALL [2180] select the highest ranked aircraft/runway pair for Long Cycle analysis.

3.2.2.7.2. Alternate Global Conflict-minimized Trajectory Analysis (Long Cycle)

The selected reassignment is further examined to see if all aircraft in the schedule can meet the STA with conflict minimized trajectories. When conflicts are detected, it may be necessary to delay aircraft in order to resolve the conflict, a fact which would make it impossible to meet the proposed STA's and which at a minimum would call into question the delay savings calculated in the short cycle (based on those STA's).

FAST SHALL [2190] calculate an "alternate plan" (alternate global conflict-minimized trajectory solution) based on the aircraft-runway reassignment pair selected at the end of the Short Cycle analysis.

The final result of this calculation is a complete trajectory for each aircraft in the system which is guaranteed to be conflict minimized. A recommended time of landing is a by-product of each of these trajectories.

3.2.2.7.3. Select Either the Current or Alternate Arrival Plan (Long Cycle)

The comparison of the current and the alternate plan is made using a set of decision rules (in adaptation) similar to the one used in the Short Cycle to consider whether the alternate runway assignment should be retained.

FAST SHALL [2200] reject the alternate plan if:

a. The adaptation does not have a criterion listed for this reassignment.

b. If the reassigned aircraft is outside its reallocation time window.

c. If the alternate plan had at least one trajectory conflict which was not present in the trajectory solutions for the current plan.

d. If any aircraft's delay increases (due to this reassignment) beyond an adaptation specified limit.

FAST SHALL [2210] calculate the total TTF of all aircraft presently in the schedules for the alternate runway assignment based on conflict-minimized trajectory solutions to all these runways.

FAST SHALL [2220] calculate the global delay saving by subtracting the total TTF for the alternate plan from the previously calculated TTF for the current plan.

FAST SHALL [2230] assign the final candidate aircraft-runway reassignment pair a minimum global delay saving, based on adaptation, to be achieved for consideration. This minimum global delay saving will be based on a linear list of rules specified in the adaptation.

FAST SHALL [2240] reassign a runway if the candidate runway reassignment achieves the required delay reduction and this result moreover recurs on several re-assignment update cycles, as often as required by a parameter called "the confidence level" specified in the adaptation.

3.2.2.7.4. Modify Accepted Runway Reallocation by "Switch Criteria"

FAST SHALL [2250] be capable of detecting and eliminating "double over the top" routing, reference Figure 3.2.2.7.4-1, when directed to do so in the adaptation.

Based on site adaptation, FAST SHALL [2260] be capable of changing an aircraft-runway reallocation pair to a similar (based on engine class) aircraft-runway pair if this removes an odd (based on engine class) type from an arrival stream.

FAST calculates that aircraft A should be moved from Runway R to Runway L

A Switch criterion recognizes the creation of a "Double Over the Top" situation.
The Switch criteria changes the reassignment such that aircraft B is moved
from Runway R to L instead.

Figure 3.2.2.7.4-1. Double Over the Top Switch Criteria.

3.2.3. TMC Graphical User Interface

The TMC-GUI function provides the Computer Human Interface (CHI) for the TMC. The function is capable of generating a number of generic display presentations which can be provided at any of the facilities, i.e., En Route, Terminal, or Tower, in which CTAS is installed.

The TMC-GUI function is depicted in Figure 3.2.3-1.

Figure 3.2.3-1. TMC-GUI Function.

As depicted in Figure 3.2.1-1, the TMA Processing sub-functions are:

• Display Presentation.

• Display Definition.

• Parameter Interaction.

• Data Retrieval.

• Display Interaction.

These sub-functions are site-adapted through the use of site adaptation data produced by the System's AVA capability.

3.2.3.1. Inputs & Outputs

The TMC GUI SHALL [2265] be capable of processing the following inputs:

a. Adaptation data.

b. TMC entries.

c. TMA and FAST data.

Whenever it recalculates ETAs or STAs, CTAS SHALL [2270] also update the TMC display presentations.

CTAS SHALL [2280] display requested data to the TMC (response) as a result of the TMC data requests (stimuli) with a mean response time 3 seconds or less, a 99th percentile response time of 5 seconds or less, and a maximum response time of 10 seconds or less.

CTAS SHALL [2290] place a print request in the queue (response) as a result of the TMC request to print a report (stimuli) with a mean response time of 3 seconds or less, a 99th percentile response time of 5 seconds or less, and a maximum response time of 10 seconds or less.

CTAS SHALL [2291] be capable of printing out the following:

a. Traffic count.

b. Statistical delay information.

The outputs of the TMC-GUI function are identified in Table 3.2.3.1-2. In addition to a brief description of each output, the table identifies whether the output is to an External or Internal interface.

The TMC GUI SHALL [2295] be capable of producing the following outputs:

a. TMC display .

b. TMC entries.

Upon receipt of any of the scheduling entries listed in Section 3.2.3.4, the TMC-GUI function SHALL [2300] forward data to the either the TMA, or FAST Processing functions, whichever is applicable.

CTAS SHALL [2310] display lexical feedback (response) for TMC input (stimuli) with a mean response time of 0.15 second or less, a 99th percentile response time of 0.2 second or less, and a maximum response time of 0.25 second or less.

NOTE: Lexical feedback is the feedback for operator input actions such as display keyboard inputs on the display device. The time measurement is taken from the moment that the operator entry occurs to the completion of the feedback response.

CTAS SHALL [2320] display syntactic feedback (response) for TMC sent messages (stimuli) with a mean response time of 0.6 second or less, a 99th percentile response time of 1.2 seconds or less, and a maximum response time of 1.8 seconds or less.

NOTE: Syntactic feedback is the confirmation received for message format validity. The time measurement for a syntactic feedback starts from the moment that the message is sent for processing (e.g., an operator enters a command) to the moment that the syntactic feedback is either returned to the operator or when the message is cleared to be processed.
3.2.3.2. Display Presentation

The Display Presentation function provides the following logical displays for the TMC:

• Timeline display.

• Load graph display.

• Plan View display.

• Auxiliary Info display.

These displays are specified in terms of logical display formats, i.e., identification of objects on the screen, organization of objects on the screen, sizing, orientation, etc.

Upon receipt of data from the TMA or FAST functions, CTAS SHALL [2330] update the TMC displays.

Upon receipt of TMC entries affecting display presentations, CTAS SHALL [2340] update the TMC displays.

For an aircraft undergoing down-arrow processing, TMA SHALL [2345]:

a. Highlight that aircraft on the TGUI timeline and in the PGUI sequence list, and

b. Add the aircraft to the diverted aircraft list (where it is to stay for 10 minutes).

TMA SHALL [2346] remove the highlighted aircraft from the timeline and sequence list when any of the following events occurs:

a. The frozen aircraft is rescheduled.

b. The airport configuration is changed.

c. The schedule times out.

d. The aircraft is suspended by operator input on the TGUI.

3.2.3.2.1. Timeline Display

Requirements 2350-2410 have been deleted. These requirements have been moved to the CHI Requirements Document.

3.2.3.2.2. Load Graph Display

Requirements 2420-2460 have been deleted. These requirements have been moved to the CHI Requirements Document.

3.2.3.2.3. Plan View Display

Requirements 2470-2520 have been deleted. These requirements have been moved to the CHI Requirements Document.

CTAS SHALL [2520] be capable of sending the data required to generate the Plan View display to ETMS.

3.2.3.2.4. Statistical Calculations

CTAS SHALL [2530] provide the capability to calculate the following quantities for display purposes:

a. Daily Traffic Count.

b. Delay Data.

as described in the following sections.

A. Daily Traffic Count

CTAS SHALL [2540] compute a daily traffic count according to the following:

a. Over a time interval of 60 minutes in the past to 120 minutes in the future (-79 to 139 minutes).

b. By selected time intervals: 10, 15, 20 minutes.

c. (subrequirement deleted).

d. By runway threshold and/or meter fix according to STA.

e. By runway threshold and/or meter fix according to ETA.

f. (subrequirement deleted).

g. By runway threshold and/or meter fix according to actual aircraft crossing time.

B. Delay Data

This section describes the delay calculations required by the TMC GUI. In this context, delay is defined as the difference between the OETA and the actual crossing time at the chosen fix (meter fix or runway threshold). If the delay for an given aircraft exceeds an adaptation-defined threshold, it will be considered a "reportable delay".

CTAS SHALL [2550] compile delay data for all airports supported by CTAS.

CTAS SHALL [2551] organize Statistical Delay Information (SDI) into sessions which contain information about one or more reportable delays.

CTAS SHALL [2552] initialize a new SDI session when all of the following conditions are true:

a. The SDI function is active.

b. No SDI session is currently open.

c. The SDI function has just detected a reportable delay.

CTAS SHALL [2553] terminate an open SDI session when any one of the following conditions are true:

a. The SDI function is terminated.

b. Midnight local time occurs.

c. The elapsed time since the most recent reportable delay exceeds the "delay close-out time". The delay close-out time is a site adaptable variable which is generally chosen to be 45 minutes.

CTAS SHALL [2554] record and retain the SDI information (in session format) concerning the lesser of:

a. The most recent 50 sessions.

b. The most recent 2000 reportable delays.

The delay close-out time SHALL [2650] be adjustable by the TMC.

CTAS SHALL [2555] record the SDI information (in session format) and retain the lesser of:

a. The most recent 50 sessions.

b. The most recent 2000 reportable delays.

CTAS SHALL [2560] automatically record actual crossing times of arrival aircraft at (or closest approach to) the Meter Fix/arc.

Requirement 2570 has been deleted.

CTAS SHALL [2580] recalculate delay summary to take into account modified/updated data.

CTAS SHALL [2590] recognize when an aircraft is re-routed to a different gate or when an aircraft does not go over a gate while compiling delay data.

Requirements 2600 and 2610 have been deleted.

CTAS SHALL [2620] be able print selected delay data while delay recording is in effect.

Requirement 2630-2640 have been deleted.

Requirements 2660-2680 (Rush Alert) have been deleted.

Requirements 2690-2720 (Preview of Proposed Change) have been deleted. These

requirements have been moved to the CTAS Build 2 CHI Requirements document.

3.2.3.3. Display Definition

Requirements 2730-2740 have been deleted. These requirements have been moved to the CHI Requirements document

3.2.3.4. Parameter Interaction

CTAS SHALL [2750] if authorized by the site adaptation on a GUI by GUI basis provide TMCs the capability to issue the following commands to TMA:

a. Designate/remove an aircraft as priority.

b. Suspend/resume aircraft scheduling.

c. Resequence aircraft routed over the same feeder gate in the sector metering list.

d Change airport acceptance rate effective at an entered time.

e. Cancel pending airport acceptance rate change.

f. Cancel pending airport/runway configuration change.

g. Create/remove a blocked interval.

h. Insert/remove a blocked time slot.

i. Assign departure release time to an internal departure aircraft.

j. Cancel pending feeder gate acceptance rate change.

k. Group traffic flow based on engine class into a stream class.

l. Group traffic flow based on aircraft feeder gate crossing altitude into a stream class.

m. Combine two or more stream classes into a super stream class.

n. Change stream class Miles-in-Trail separation effective at an entered time.

o. Cancel pending stream class Miles-in-Trail separation change.

p. Change the airport/runway configuration effective at an entered time and continuing.

q. Reschedule an aircraft (i.e., assign STA to an aircraft).

r. Reset an aircraft scheduling (i.e., erases all scheduling information except the last track data and flight plan information and the aircraft is scheduled as though for the first time).

s. Change runway threshold acceptance rate effective at an entered time.

t. Cancel pending runway flow constraints change.

u. Change an aircraft’s feeder gate for a particular aircraft.

v. Change feeder gate for a particular aircraft with schedule frozen.

w. Change aircraft feeder gate assignment for all aircraft to fly over a particular fix, waypoint, or feeder gate starting immediately.

x. Change aircraft feeder gate assignment for all aircraft to fly over a particular fix, waypoint, or feeder gate starting at an entered time in the future and continuing.

y. Change Meter Fix acceptance rate effective at an entered time.

z. Cancel pending Meter Fix acceptance rate change.

aa. Change the Meter Fix for a particular aircraft.

bb. Change the Meter Fix for all aircraft to fly over a particular fix, waypoint, or feeder gate starting immediately.

cc. Change the Meter Fix for all aircraft to fly over a particular fix, waypoint, or feeder gate starting at an entered time in the future and continuing.

dd. Set Meter Fix to meter using Miles-in-Trail separation, meter using time-based separation, free flow arrival aircraft, or hold arrival aircraft.

ee. Recompute schedule inside the freeze horizon.

ff. Change the runway assignment for a particular aircraft.

gg. Change the runway assignment for all aircraft flying over a particular fix or waypoint.

hh. Change runway threshold separation effective at an entered time.

ii. Change runway threshold separation buffer effective at an entered time.

jj. Change runway occupancy time effective at an entered time.

CTAS SHALL [2760] if authorized by the site adaptation on a GUI by GUI basis provide TMCs the capability to issue the following commands to FAST:

a. Designate/remove an aircraft as priority.

b. Resequence aircraft destined to the same runway.

c. Change airport acceptance rate effective at an entered time.

d. Cancel pending airport acceptance rate change.

e. Change airport/runway configuration effective at an entered time period.

f. Cancel pending airport/runway configuration change.

g. Create/remove a blocked interval.

h. Insert/remove a blocked time slot.

i. Reschedule an aircraft (i.e., assign STA to an aircraft).

j. Reset an aircraft scheduling (i.e., erases all scheduling information except the last track data and flight plan information and the aircraft is scheduled as though for the first time).

k. Change runway threshold acceptance rate effective at an entered time.

l. Cancel pending runway flow constraints change.

m. Assign dependent parallel runways balancing/biasing values.

n. Reset an aircraft scheduling (i.e., erases all scheduling information except the last track data and flight plan information and the aircraft is scheduled as though for the first time).

o. Change the runway assignment for a particular aircraft.

p. Change the runway assignment for all aircraft flying over a particular fix or waypoint.

q. Change runway threshold separation effective at an entered time.

r. Change runway threshold separation buffer effective at an entered time.

s. Change runway occupancy time effective at an entered time.

t. Restart landing sequence (i.e., the first aircraft to the runway threshold is assigned the number one sequence and each subsequent aircraft is assigned the next sequence number).

Requirements 2770 and 2780 have been deleted.

Semantic feedback is the feedback response from the system to a TMC-issued message. The time measurement for semantic feedback starts from the completion of the syntactic feedback to the moment that the results from the message processing are either (1) completed, and a completion indication is sent back to the originator, or (2) to the

moment that the message or control signal is passed on to non-CTAS equipment (for situations that do not require a completion indication).

CTAS SHALL [2790] provide semantic feedback, e.g., new STAs on the screen, in response to TMC-entered:

a. Schedule constraints with a mean response time 3 seconds or less, a 99th percentile response time of 4 seconds or less, and a maximum response time of 5 seconds or less, and

b. Configuration changes with a mean response time 15 seconds or less, a 99th percentile response time of 25 seconds or less, and a maximum response time of 30 seconds or less.

3.2.3.5. Data Retrieval

This section, including requirements 2800-2820, has been deleted.

3.2.3.6. Display Interaction

This section, including requirement 2830, has been deleted.

3.2.4. Monitor & Control

The M&C function provides centralized system management of the Operational System. It manages the computational assets of the Operational System. This includes the allocation of software processes to hardware, initiation and termination of processes, the collection of status information pertaining to computer resources and software processes.

The M&C function monitors and displays computer resource utilization information (e.g., CPU, memory, etc.), and generates visual and audible alarms when thresholds are exceeded. It provides fault detection and recovery when resource problems arise. It monitors the status of CTAS processes and manages initialization, failure recovery and shutdown of these processes. The M&C function also includes event logging.

Each facility where CTAS is installed will have its own M&C functional group. Each M&C functional group has the ability to monitor CTAS hardware and software at other connected sites beyond the particular facility. Note that Center facilities with two TMAs will have single M&C functional group.

The M&C functional group at the TRACON will monitor and control all the local CTAS hardware and software This type of TRACON Monitor & Control functional group also has the ability to monitor CTAS hardware and software at sites beyond this TRACON.

The M&C functional group at the Tower facility will monitor and control all the local CTAS hardware and software This type of Tower Monitor & Control functional group also has the ability to monitor CTAS hardware and software at sites beyond this Tower facility.

The M&C functional group at the Adjacent Facility is either a TRACON M&C or a Center M&C depending on the type of facility. In some cases, the only functioning component of CTAS in a facility may be the Data I/O (Center Data Interface or TRACON Data Interface). If Data Processing (type FAST) is running but Data Processing (type TMA) is not, it will be necessary for the Data I/O (type Center Data Interface) in the Center to be running. It is possible that the Data I/O (type Center Data Interface) might be running to support one Data Processing (type TMA) (for one arrival TRACON) while another Data Processing (type TMA) (for another arrival TRACON) is turned off. The Data I/O (type TRACON Data Interface) in the TRACON might be turned on solely to support Data Processing (type TMA) in for example one of theTower Enroute Control facilities like LAX.

All CTAS hardware and software control by M&C SHALL [2841] be accomplished locally at each facility.

The M&C station SHALL [2842] have the capability of interfacing to the AMCC in the Center.

The Center type of M&C station SHALL [2843] have the ability to control all functional groups of Data Processing (TMA type), User I/O (GDS type), and Data I/O (Center Data Interface type) independently. The same M&C can control up to two such TMA groups with the associated User and Data I/O groups.

The TRACON type of M&C station SHALL [2844] have the ability to control all functional groups of Data Processing (FAST type), User I/O (GDS type) , and Data I/O (TRACON Data Interface type) independently.

The Tower type of M&C station SHALL [2845] have the ability to control all functional groups of User I/O (GDS type) independently.

All hardware (workstation and networks) anywhere in the overall CTAS system (excluding the HCS and ARTS) SHALL [2846] be capable of being monitored by user tools taking advantage of the SNMP protocol.

All software anywhere in the overall CTAS system (excluding the HCS and ARTS) SHALL [2847] be capable of being monitored by using the SNMP protocol with the construction of the necessary MIBs, agents and proxies.

3.2.4.1. Inputs & Outputs

The inputs to the M&C function are identified in Table 3.2.4.1-1.

Table 3.2.4.1-1. M&C Inputs

Input	Description
Configuration data	Hardware & Software Configuration data
SMC entries	SMC entries
Status data	Status from CTAS processes

The outputs of the M&C function are identified in Table 3.2.4.1-2.

Table 3.2.4.1-2. M&C Outputs

Output	Description
SMC display data	SMC displays
Control data	Control data messages to, e.g., start, stop, recover, etc., sent to CTAS processes.

Requirement 2840 has been deleted.

The local interface SHALL [2850] provide for M&C a graphical display and input capability via mouse and/or keyboard for control and diagnostic functions.

Upon request or status change, CTAS SHALL [2860] provide status, alert, and alarm information to the ARTCC Maintenance Control Center (AMCC).

3.2.4.2. Monitoring

CTAS SHALL [2880] monitor and report at a minimum (but is not limited to) the following:

a. Overall system status and status changes.

b. Hardware component availability.

c. Software component status.

CTAS SHALL [2890] recognize and present alarm and alert conditions. Alarm conditions are defined as any condition when a subsystem parameter is outside of an acceptable operating range. Alert conditions are defined as any condition when a subsystem parameter is outside of normal operating range but within an acceptable operating range.

CTAS SHALL [2900] provide for operator input to effect dynamic change to the subsystem parameter settings.

CTAS SHALL [2870] provide for remote monitoring via a data transmission interface.

3.2.4.3. Control

CTAS SHALL [2910] provide for the local start/stop and processor/task allocation.

3.2.4.4. Diagnostics

CTAS SHALL [2920] provide internal diagnostic capability for fault isolation.

CTAS local and/or remote execution and reporting of diagnostic procedures SHALL [2930] be provided.

Diagnostics SHALL [2940] identify the Line Replaceable Unit (LRU) of a failed or degraded component whenever possible and provide visual and hard copy diagnostic data for fault isolation analysis.

3.2.4.5. Maintenance of System Log

CTAS SHALL [2950] maintain an event log recording containing alarms, alerts, system status changes, and manually entered system configuration changes.

CTAS SHALL [2960] time-stamp all system log entries with the system Coordinated Universal Time.

CTAS SHALL [2970] provide the ability to display the system log.

CTAS SHALL [2980] provide the ability to print the system log.

CTAS SHALL [2990] preserve the system log files for a minimum of 48 hours.

3.2.5. Data Management (DM)

This section has been deleted. All references to DM in this specification have been expunged.

Requirements 3050-3060 related to interfaces have been incorporated in Section 3.3 on Interfaces.

Requirements 3000-3040 and 3070-3210 have been deleted.

3.2.6. Adaptation, Validation, and Analysis

CTAS SHALL [3220] provide an adaptation, validation, and analysis (AVA) capability which executes independently from the operational CTAS capabilities and generates all of the necessary CTAS site adaptation data described in Section 3.6.

Requirement 3230 has been deleted.

AVA SHALL [3240] retrieve geographic data from the Center’s Adaptation Controlled Environment System (ACES) tape, National Flight Data Center (NFDC) data, and TRACON video maps.

Requirements 3250 and 3260 have been deleted.

AVA SHALL [3251] provide a display of information needed to complete an adaptation.

AVA SHALL [3252] provide the ability to display, modify, and create nominal TRACON routes.

AVA SHALL [3253] provide the ability to display, modify, and create procedural routing data.

AVA SHALL [3254] provide the capability to display TRACON video and ARTCC maps.

AVA SHALL [3255] provide the ability to display PAR routes.

AVA SHALL [3270] provide for validation and analysis of the adaptation data through the use of simulated data, recorded live data and controller-in-the-loop exercises.

3.2.6.1. Adaptation

3.2.6.1.1. Inputs & Outputs

AVA SHALL [3280] be capable of reading the following:

Table 3.2.6.1.1-1. Inputs to AVA

ACES data	ACES data from ARTCC.	NAS-MD-326.
NFDC APT	Airport list from NFDC.	NFDC Database Record Layout descriptions for APT-FILE.
NFDC NAV	Navigational information from NFDC.	NFDC Database Record Layout descriptions for NAV-FILE.
NFDC FIX	Meter fix information from NFDC.	NFDC Database Record Layout descriptions for FIX-FILE.
NFDC ILS	Instrument landing information from NFDC.	NFDC Database Record Layout descriptions for ILS-FILL.
NFDC ARB	Boundary information from NFDC.	NFDC Database Record Layout descriptions for ARB-FILE.
video maps	TRACON video maps.	Department of Commerce, National Oceanic and Atmospheric Administration.
Misc. files	Aircraft model specifications, weather files, etc.	Adaptation IDD.

AVA output requirements are cataloged in Section 3.6.

Requirements 3290 and 3300 have been deleted.

AVA SHALL [3310] provide tools which allow an operator to view data from multiple input files.

AVA SHALL [3320] allow the operator to make manual entries to correct erroneous or incomplete electronic data.

AVA SHALL [3330] provide tools to allow for the input of adaptation information from the operator not available from electronic sources.

3.2.6.1.2. Data Processing

AVA SHALL [3340] have the capability to modify the adaptation upon the release of each NAS update cycle (which occurs every 56 days).

AVA SHALL [3350] have the capability of managing the adaptation data directories and files for CTAS.

3.2.6.2. Validation

AVA SHALL [3360] be able to input an existing adaptation data for further modification.

AVA SHALL [3370] display to the operator tasks which need to be completed in order for the data to be considered complete.

AVA SHALL [3380] allow a complete adaptation to be created only when the data set has enough information such that it can be used by CTAS to generate ETAs.

3.2.6.3. Analysis

AVA SHALL [3390] provide tools to analyze the adaptation for consistency and accuracy in ETA generation and runway assignment.

AVA SHALL [3400] provide the ability to use the route analysis capabilities of TMA to generate ETAs for simulated aircraft along every adapted route.

AVA SHALL [3410] display information to the operator for determining the validity of computed ETAs. All routes failing to generate an ETA will be reported to the operator.

AVA SHALL [3420] provide the ability to use elements of FAST to generate runway and analysis category assignments for simulated aircraft.

AVA SHALL [3425] display information to the operator to help determine the validity of runway and analysis category assignments.

Requirement 3430 has been deleted.

3.2.7. Data Analysis

CTAS SHALL [3440] provide a Data Analysis (DAN) capability which executes independently from the operational CTAS and can analyze data recorded by the operational CTAS to generate reports and/or incident analyses.

DAN SHALL [3450] provide for the display and hard copy generation of graphical and tabular presentations of data recorded by the operational CTAS.

DAN SHALL [3460] provide the capability to process data recorded by the operational CTAS to analyze the validity of:

a. Aircraft routes.

b. Generated routes.

c. Selected routes that satisfy scheduling constraints.

DAN SHALL [3470] provide the ability to process data recorded by the operational CTAS to:

a. Compare CTAS-generated runway assignments and sequences with actuals.

b. Compare CTAS-generated ETAs with actual arrival times.

c. Analyze STAs.

d. Compare CTAS-generated STAs with actual arrival times.

For the purpose of analytical isolation, DAN SHALL [3480] provide the capability to select designated data recorded by the operational CTAS by:

a. Time interval.

b. Data message type.

3.2.8. Playback

CTAS SHALL [3490] provide a Playback capability which executes independently from the operational CTAS, reading HCS and ARTS data previously recorded by the operational CTAS, and provides the ability to exercise all of the functions of the operational CTAS.

The Playback SHALL [3500] provide the capability for setting system time to "recorded" instead of actual time of day for the duration of the playback.

3.2.9. Simulation

CTAS SHALL [3510] provide a Simulation capability, such as the Pseudo Aircraft Simulator (PAS) which can exercise the Operational CTAS in a laboratory environment.

3.3. System External Interface Requirements
3.3.1. Interface Identification and Diagram

The external interfaces for a generic CTAS installation are shown in Table 3.3.1-1. Included is the applicable reference for each interface.

Table 3.3.1-1. Required External Interfaces

Category	Description/Reference	ID	Section
HOST	Reference in Table 2-6
HID/LAN Interface	HOST messages	HID	3.3.2
TRACON Interfaces	Reference in Table 2-7		3.3.3
ARTS GateWay	ARTS IIIE messages	AGW	3.3.3.1
STARS Interface	STARS messages	STARS	3.3.3.2
ARTS Data Gatherer	ARTS IIIA messages	ADG	3.3.3.3
ETMS Interface	Reference in Table 2-8		3.3.4
RUC Weather Data	WMO GRIB format	EWX	3.3.4.1
Center/TRACON Traffic Data	ETMS internal format	ETD	3.3.4.2
PGUI on ETMS display	X/Motif (Ref. Table 2-1)	EXD	3.3.4.3
Adjacent Facility Data I/O Interfaces	Reference in Table 2-1		3.3.5
Adjacent Center Data I/O	CTAS internal format	ACD	3.3.5.1
Adjacent TRACON Data I/O	CTAS internal format	ATRD	3.3.5.2
Adjacent Facility User I/O Group	Reference in Table 2-1		3.3.6
Adjacent Center User I/O	CTAS internal format	ACG	3.3.6.1
Adjacent TRACON User I/O	CTAS internal format	ATRG	3.3.6.2
Tower User I/O	CTAS internal format	ATWG	3.3.6.3
ARTCC Maintenance Control Center	Reference in Table 2-1
CTAS/AMCC Interface	CTAS/AMCC IRD	AMCC	3.3.7

Figure 3.3.1-1 depicts how these external interfaces are connected for generic Center and TRACON CTAS Installations.

The principal interface in every CTAS installation is the Data I/O Group, which connects to the Host in the Center installation or to ARTS in the TRACON installation. The same Data I/O group interfaces to ETMS in both types of installations. Other interfaces in the Center installation are the interface of M&C to AMCC and interfaces of TMA to Adjacent Facility Data I/O Groups. Other interfaces in the TRACON installation are of FAST to Data I/O groups in Adjacent facilities.

Figure 3.3.1-1. Diagram of Interfaces for Generic CTAS Installations.

The Data I/O Group in a Center installation consists of all the hardware and software necessary to perform two way communication with a single Host HID; it includes all the hardware and software necessary to send data to a single Host HID, and to receive and distribute data from the same Host. Software to select data to be sent to other functional groups within CTAS is included in this functional group. The Data I/O group also interfaces to ETMS to provide Weather Data and, in some cases, to provide FP and track data from adjacent facilities which do not have any CTAS equipment (with Data I/O groups) installed.

Except for specific cases (in special cases such as LAX via an ATMIS data connection), there is no requirement for ARTS data to be used by TMA. Each Center display station can be made to toggle between a TMA driven display and a FAST driven display. The "Instantaneous TRACON traffic count" calculated by FAST and displayed on FAST displays in the local TRACON, can also be displayed in the connected Center, Tower and adjacent facilities.

The Data I/O Group in a TRACON Installation consists of all the hardware and software necessary to perform two way communication with a single ARTS (via either a ARTS GateWay, ADG, or connection to STARS ); it includes all the hardware and software necessary to send data to a single ARTS, and to receive and distribute data from the same ARTS. Software to select data to be sent to other functional groups within CTAS is included in this functional group. The Data I/O group also interfaces to ETMS

to provide Weather Data and, in some cases, to provide FP and track data from adjacent facilities which do not have any CTAS equipment (with DataI/O groups) installed.

The Data I/O group in an Adjacent Facility Installation with a Data processing Group (either TMA or FAST) is either a TRACON DATA Interface or a Center Data Interface depending on the type of facility. An Adjacent Facility without a Data Processing Group (either TMA or FAST) does not have a Data I/O group.

Observe that data exchange with the CTAS Graphical User Interface (GUI), whether PGUI or TGUI, is considered internal to CTAS. The manual inputs from the Traffic Management Coordinator (TMC) and the display capability is discussed as part of the CHI.

Also note that the data inputs to AVA (from ACES or NFDC or other sources) are part of the requirements description of the adaptation support function.

3.3.2. HCS Interface

This section states the requirements for the interface, referred to as HID in Table 3.3.1-1, between the HCS and any Center CTAS installation.

All information related to the Host Interface is collected in Table 2-6, especially as related to the HID/LAN.

CTAS SHALL [3520] be capable of receiving flight plan and track data from the HCS via the HID

CTAS SHALL [3530] be capable of sending flight plan requests to the HCS via the HID.

CTAS SHALL [3050] be capable of receiving Sector controller commands from the HCS via the HID.

CTAS SHALL [3060] be capable of sending the following meter list data to the HCS via the HID:

a. Aircraft computer ID (CID).

b. Airport identifier.

c. Runway configuration.

d. Assigned fixes/arc and outer fixes/arc.

e. STA to each assigned fix/arc.

f. ETA to each assigned fix/arc.

g. Delay to absorb prior to reaching each assigned fix/arc.

h. Four display bits (for frozen, heavy, holding and down-arrow processed status).

3.3.3. ARTS Interfaces

This section states the requirements for the interface between an ARTS installation and a TRACON CTAS installation. This interface is referred to as either the ADG or AGW or STARS in Table 3.3.1-1.

3.3.3.1. ARTS GateWay

If the ARTS is an ARTS III-E, the interface is called the ARTS GateWay (AGW). The reference for the IRD is NAS-IR-90068219.

CTAS SHALL [3541] be capable of interfacing to an ARTS AGW for receiving flight plan and aircraft track data.

CTAS SHALL [3542] be capable of receiving controller commands from ARTS AGW and forwarding corresponding data messages to FAST.

CTAS SHALL [3543] transmit runway assignment and sequence numbers information to the ARTS AGW for display in the aircraft’s data block.

Requirement 3540 has been deleted.

3.3.3.2. STARS Interface

If the ARTS is a STARS (currently being developed), the interface is called the STARS interface. The reference will be the STARS IRD (not yet available).

CTAS SHALL [3551] be capable of interfacing to an ARTS STARS for receiving flight plan and aircraft track data.

CTAS SHALL [3552] be capable of receiving controller commands from ARTS STARS and forwarding corresponding data messages to FAST.

CTAS SHALL [3553] transmit runway assignment and sequence numbers information to the ARTS STARS for display in the aircraft’s data block.

Requirement 3550 has been deleted.

3.3.3.3. ARTS Data Gatherer

If the ARTS is an ARTS III-A, the interface is referred to as the ARTS Data Gatherer (ADG). The reference for the IRD is NAS Change Proposal/Change File Nbr TBS. Note that an ADG can only be used to receive flight plan and track data.

CTAS SHALL [3561] be capable of interfacing to an ARTS ADG for receiving flight plan and aircraft track data.

Requirement 3560 has been deleted.

3.3.4. ETMS Interface

This section states the interface requirements between a CTAS installation and ETMS.

The overall reference for the ETMS interface is the CTAS/ETMS Interface Requirements Document (document number to be assigned).

The interfaces are referred to as EWX for the ETMS interface handling the RUC weather data, as ETD for an ETMS interface handling Center/TRACON flight plan and track data, and as EXD for the ETMS interface handling PGUI display data being sent to ETMS in the X/Motif format.

3.3.4.1. ETMS Weather Interface

The ETMS will provide gridded RUC (Rapid Update Cycle) weather data to CTAS in the World Meteorological Organization (WMO) GRIB (Gridded Binary) format. The reference for GRIB format is National Weather Service (NWS) National Meteorological Center (now NCEP) Office Note 388, "The WMO Format for the Storage of Weather Product Information and the Exchange of Weather Product Messages in Gridded Binary Form". The currently distributed GRIB format for RUC data is Grid 87. The ETMS data distribution will initially be in the AWIPS 211 format and later in the AWIPS 212 format.

The ETMS weather interface will initially be implemented as a serial interface and later as a network interface. CTAS must be capable of handling either case.

CTAS SHALL [3570] be capable of receiving RUC weather data from ETMS in either the AWIPS 211 or AWIPS 212 GRIB formats, as specified in the CTAS/ETMS IRD.

3.3.4.2. ETMS Center/TRACON Traffic Data

The ETMS will provide Center and TRACON flight plan and track data to CTAS in an ETMS internal format as specified in the references in Table 2-8.

CTAS SHALL [3571] be capable of receiving FP and track data from ETMS.

3.3.4.3. ETMS PGUI Display on TSD

The ETMS will eventually have a network connection with CTAS capable of displaying a PGUI on the Traffic Situation Display (TSD) in X/Motif format. The reference for the X/Motif protocol is in Table 2-1.

CTAS SHALL [ 3572] be capable of displaying a PGUI on the ETMS Traffic Situation Display in X/Motif format.

Requirement 3580 has been deleted.

3.3.5. Adjacent Facility CTAS Data I/O Interfaces

This section states the interface requirements between a CTAS installation and an Adjacent Facility CTAS Data I/O Group which can be in either a Center or TRACON installation. The interfaces are referred to as ACD or ATRD in Table 3.3.1-1.

3 .3.5.1. Adjacent Center CTAS Data I/O Interface

This section states the requirements for the interface between a Center CTAS installation and any other CTAS installation. This interface is referred to as ACD in Table 3.3.1-1

The Data I/O Group of an Adjacent Center Facility SHALL [3591] be capable of sending FP and track data to the TMA in the Center.

For aircraft within a site adaptable distance from the TRACON, the Data I/O Functional Group in the Center Adjacent Facility SHALL [3592] be capable of sending FP and track data to the FAST in the TRACON.

CTAS (at TMA or FAST) SHALL [3593] be capable of receiving and processing FP and track data from the Data I/O group of an Adjacent Center facility.

Requirement 3590 has been deleted.

3.3.5.2. Adjacent TRACON CTAS Data I/O Interface

This section states the requirements for the interface between a TRACON CTAS installation and any CTAS installation. This interface is referred to as ATRD in Table 3.3.1-1.

The Data I/O Group of an Adjacent TRACON Facility SHALL [3601] be capable of sending FP and track data to the TMA in the Center which contains that TRACON.

The Data Processing Group of CTAS (either TMA at the Center or FAST at the TRACON) SHALL [3602] be capable of receiving and processing FP and track data from the Data I/O group of an Adjacent TRACON facility

Requirement 3600 has been deleted.

3.3.6. Adjacent Facility User I/O Interfaces

This section states the interface requirements between a CTAS installation and an Adjacent Facility CTAS User I/O Group which can be in either a Center or TRACON or Tower installation. The interfaces are referred to as ACG or ATRG or ATWG in Table 3.3.1-1.

In general, displayed data from any connected facility can be requested and displayed locally. Also, any keyboard entries made locally can be made to affect operations at any connected facility. However, site adaptation will limit and circumscribe this capability. For example, a Tower facility could ask for the display data from the connected TRACON CTAS User I/O Group and the Center CTAS User I/O group, but would almost never be allowed to command an airport configuration change.

3.3.6.1. Adjacent Center Facility User I/O Interface

This section states the requirements for the interface between a Center CTAS User I/O Group and any CTAS installation. This interface is referred to as ACG in Table 3.3.1-1.

The User I/O Group at a Center Facility SHALL [3611] be capable of issuing keyboard commands to connected CTAS facilities and displaying GDS data received from these facilities in response.

The User I/O Group at a Center Facility SHALL [3612] be capable of receiving keyboard commands from connected CTAS facilities and providing GDS data to these facilities in response.

3.3.6.2. Adjacent TRACON Facility User I/O Interface

This section states the requirements for the interface between a TRACON CTAS User I/O Group and any CTAS installation. This interface is referred to as ATRG in Table 3.3.1-1.

The User I/O Group at a TRACON Facility SHALL [3613] be capable of issuing keyboard commands to connected CTAS facilities and displaying GDS data received from these facilities in response.

The User I/O Group at a TRACON Facility SHALL [3614] be capable of receiving keyboard commands from connected CTAS facilities and providing GDS data to these facilities in response.

3.3.6.3. Tower CTAS User I/O Interface

This section states the requirements for the interface between a Tower installation User I/O Group and any CTAS installation. This interface is referred to as ATWG in Table 3.3.1-1.

Interfaces between any CTAS installation and the TOWER CTAS installation is limited to GUI display data being sent from any connected facility to the Tower.

The User I/O Group at a Tower Facility SHALL [3615] be capable of issuing keyboard commands to connected CTAS facilities and displaying GDS data received from these facilities in response.

Requirements 3610, 3620, 3630 and 3640 have been deleted.

3.3.7. AMCC Interface for a Center CTAS Installation

This section states the requirements for the interface between a Center CTAS installation and the Center AMCC. This interface is referred to as AMCC in Table 3.3.1-1.

The CTAS M&C Group in the Center SHALL [3660] interface with the AMCC as specified in the CTAS/AMCC Interface Requirements Document (document number to be assigned).

Requirement 3650 has been deleted.

Sections 3.3.8-3.3.9 have been deleted. Requirement 3670 has been deleted.

3.4. System Internal Interface Requirements

CTAS SHALL [3680] employ a common Inter-Process Communication (IPC) capability allowing processes to communicate with each other via messages.

The CTAS IPC capability SHALL [3690] transmit messages from a sender to one or more receivers reliably, i.e., preserving the data content of each message and the order in they were sent.

Sections 3.4.1-3.4.5, including requirements 3700-3730, have been deleted.

3.5. System Internal Data Requirements

All decisions about system internal data will be left to design.

3.6. Adaptation Requirements

The operational CTAS SHALL [3740] be adaptable to airspace parameters including at a minimum:

a. Arrival gates.

b. Meter Fixes.

c. Outer Fix Arcs.

d. Primary airports.

e. Runways at primary airports.

f. Final Approach Fixes (FAFs).

g. Satellite airports.

h. Airspace fixes (Waypoints).

i. Preferential Arrival Routes (PARs).

j. Center Airway Routes for display.

k. TRACON maps for display.

l. ARTCC sector boundaries.

m. TRACON boundaries.

n. Special Use Airspace (SUA).

The operational CTAS SHALL [3750] be adaptable to:

a. Dependencies between gates and airports.

b. Dependencies between Meter Fixes and airports.

c. Dependencies between Meter Fixes and configurations.

d. Dependencies between FAFs and configurations.

e. Mapping between aircraft types and engine class.

f. For TMA, a total of up to 20 adjacent TRACONs that are either:

1) within the ARTCC or

2) not located in the ARTCC, but within 200 nmi of the CTAS arrival airport.

g. (subrequirement deleted)

h. Up to six adapted arrival airports within the TRACON airspace.

Requirements 3800 and 3810 have been deleted.

Requirement 3860 has been deleted.

The operational CTAS in an ARTCC and the associated TRACON SHALL [3870] be adaptable to procedural parameters including at a minimum:

a. Nominal TRACON routes.

b. Airport Configurations.

c. Arrival gate crossing altitude and speed restrictions.

d. Runway assignment preferences.

The operational CTAS SHALL [3880] be adaptable to the minimum separation requirements for final approach including at a minimum:

a. Single runway approach in IFR conditions.

b. Single runway approach in VFR conditions.

c. Independent simultaneous approaches in IFR conditions.

d. Independent simultaneous approaches in VFR conditions.

e. Dependent approaches to parallel runways in IFR conditions.

f. Dependent approaches to parallel runways in VFR conditions.

g. Dependent converging approaches in IFR conditions.

h. Dependent converging approaches in VFR conditions.

The operational CTAS SHALL [3890] be adaptable to:

a. Techniques that are used for vectoring and speed control at the TRACON(s) where it is installed.

b. Routes used when assigning aircraft to a different feeder gate.

c. TRACON analysis categories when establishing routes.

d. Degrees of freedom associated for each TRACON analysis category.

e. TRACON altitude profiles when establishing routes.

f. Irregular TRACON shapes.

g. Landing approach segments.

h. Approach segment determination information.

i. Prohibited runway assignments for particular aircraft types.

j. Runway deconfliction information.

k. Runway reassignment interval.

l. Profile Selector Runway decision information.

m. Profile Selector merge sequencing information.

n. Stream Class definitions.

o. Allowable combinations of Stream Classes into Super Stream Classes.

p. Meter Fix assignment information.

q. Allowable distance from converted route to gate for assignment of "nearest gate".

r. The amount the ETA or STA needs to change before automatic rescheduling.

s. The maximum amount of delay an aircraft can be expected to absorb on a particular nominal TRACON route.

t. The maximum amount of delay an aircraft can be expected to absorb from the outer fix arc to the Meter Fix.

u. Weather Grid conversion information.

v. Default Weather Model.

w. Wake vortex separation information.

x. Aircraft models used for Trajectory synthesis.

y. Aircraft model performance information.

z. Airline descent preferences.

3.7. Safety Requirements

There are no special safety requirements for CTAS beyond than the normal safety requirements for FAA equipment.

3.8. Security and Privacy Requirements

The Commercial Off the Shelf (COTS) software products utilized by CTAS SHALL [3891] meet the C2 criteria of DoD 5200.28 STD when such products are available and their use is cost effective.

In order to obtain a waiver from FAA ACO-1 (Office of Security) or an agreement that CTAS complies with FAA Order 1600.54B, paragraph 8, Section 800, CTAS must satisfy the following three requirements on Identification, Authentication, and Access Control, and another three requirements on System Accountability:

For the purpose of Identification and Authentication CTAS SHALL [3892]:

a. Provide the requirement to log on all users to the system with a user-identification and password, and

b. Provide the capability to create and maintain user-identifications and passwords.

For the purpose of Discretionary Access Control CTAS SHALL [3893] provide the capability to:

a. Control access between each named subject and object.

b. Provide the mechanisms to add, change, or delete user permissions by a authorized user.

c. Provide the capability to create and maintain user-IDs and password providing three categories of access privilege.

The three categories of access or roles, along with an example of their rights and responsibilities, are:

1) CTAS User - is allowed to use only the users functions of the CTAS system.

2) M & C / Maintenance User - will perform system start-up, shut-down, maintenance, communication line checks, etc., type of functions.

3) System Administrator - will perform the adding/deleting of users, setting up new/user directories, configuring, add in new releases, etc., type of functions.

The access and restriction for each user category SHALL [3894] be determined by the CTAS System Developer working in cooperation with the FAA.

For the purposes of System Accountability (Auditing) CTAS SHALL [3895]:

a. Provide the capability to create and maintain an audit trail of all relevant events and accesses to security and mission critical objects.

b. Protect the audit trail from unauthorized access, modifications and destruction.

c. Provide the capability to audit the following types of security-relevant events:

1) All identification and authentication procedures to include all logon attempts.

2) Access and access attempts (modification and/or deletions to any security or mission critical object).

d. Provide the capability to tailor events to be audited and reported.

e. Provide the capability to produce audit reports which are formatted for both on-line viewing and printing.

CTAS SHALL [3896] provide the capability to have the audit reports viewed on the CTAS workstations and at the facility providing the remote maintenance capability.

CTAS SHALL [3897] provide the capability to perform checks to detect changes to the system and operational software.

3.9. System Environment Requirements

There are no special environmental requirements for CTAS beyond than the normal environmental conditions for FAA equipment.

3.10. Computer Resource Requirements

3.10.1. Computer Hardware Requirements

The System SHALL [3900] use standard, non-developmental computer resources, including central processor units (CPUs), servers, interfaces, storage devices, switches, and peripherals.

3.10.2. Computer Hardware Resource Utilization Requirements

Reserves of at least fifty percent SHALL [3910] exist for memory utilization when averaged over any 12-second interval in each hardware unit containing CTAS software.

Reserves of at least fifty percent SHALL [3920] exist for network utilization when averaged over any 12-second interval in each hardware unit containing CTAS software.

Reserves of at least fifty percent SHALL [3930] exist for processor utilization when averaged over a 12-second interval in each hardware unit containing CTAS software.

3.10.3. Computer Software Requirements

CTAS SHALL [3940] use a standard, non-developmental computer operating system that conforms to the POSIX (IEEE 1003.1) standard and is compliant with the SVID, Third Edition AT&T.

Computer program software firmware and data bases SHALL [3950] be designated as Computer Software Configuration Items (CSCIs).

New software SHALL [3960] be implemented either in the ANSI C programming language (as specified in ANSI/ISO Standard 9899-1990) or the ANSI C++ programming language (as specified in the C++ Annotated Reference Manual).

NOTE: New software refers either to completely new modules which did not exist at the start of the development or NDI/existing software modules, which require revision to more than 30% of the code.

NDI software used in CTAS SHALL [3970]:

a. Meet the reliability and maintainability requirements stated herein.

b. Not be modified without the approval of the FAA.

c. Be such that its licensing, use, and limits of use do not degrade specified performance and protect the FAA's ability to use the software for the purpose procured and to maintain the software.

d. Be documented in published technical descriptions that show suitability of use.

3.10.4. Computer Communication Requirements

All decisions regarding computer communications requirements (e.g., geographics locations, network topology, data transfer rates, type and volume of data, etc.) are left to design.

3.11. System Quality Factors

3.11.1. System Functionality

The ability to perform all required functions will be demonstrated as part of the qualification procedure defined in Section 4.

3.11.2. System Reliability

CTAS SHALL [3980] meet a hardware mean-time-between-failure (MTBF) of 2190 hours.

3.11.3. System Maintainability

CTAS provides the capability for fault detection or reduced service recognition, fault verification, fault isolation, and ease of rapid fault correction to support the mission.

CTAS SHALL [3990] provide hardware diagnostic capabilities capable of determining, at a minimum, whether the following are available for use:

a. Individual processors.

b Inter-process communication paths.

c. Data recording equipment.

d. The coded time reference.

e. Communication network interfacing equipment.

The operational CTAS SHALL [4000] require periodic maintenance no more than two times per year.

The periodic maintenance of the operational CTAS SHALL [4010] be completed within 12 hours.

CTAS SHALL [4020] satisfy a mean-time-to-repair (MTTR) for hardware failures of 30 minutes from the commencement of repair activity.

NOTE: MTTR is calculated based upon the total time of all interruption of service regardless of their duration. MTTR does not include the delay times associated with the technician notification and response, but does include the total time for isolation and retest.

3.11.4. System Availability

Failures of system components are expected to occur. Automatic fault detection, isolation, and recovery mechanisms will be employed to ensure rapid restoration of critical functions and to sustain system availability. CTAS must meet the system availability requirements for "Essential" services as specified in NAS-SR-1000. NOTE: Time allocated to maintenance as defined in Section 3.11.3 is not considered for the purposes of computing system availability.

The operational CTAS SHALL [4030] meet an inherent availability of 0.999.

No single equipment failure in the operational CTAS SHALL [4031] cause loss of service to the user (i.e., the system must be redundant).

The duration of any single loss of service SHALL [4032] not exceed 10 minutes.

The frequency of occurrence of loss of service SHALL [4033] not exceed once per week.

3.11.5. System Flexibility

The System will be functionally and operationally modular to facilitate System modification, support, and expansion.

The System SHALL [4040] be composed of hardware configuration items, software configuration items and database configuration items, selected based upon intended use, support, maintenance and configuration control.

The System will incorporate design features that support modification with minimal impact to unaffected components.

When feasible, algorithms SHALL [4050] use a database design for frequently modified parameters and site-specific data.

3.11.6. System Portability

CTAS SHALL [4060] be portable across platforms that conform to the POSIX (IEEE 1003.1) standard and is compliant with the SVID, Third Edition AT&T.

3.11.7. System Reusability

To minimize development and assure compatibility with existing and planned improvements, the use of existing software and hardware components, including commercial off-the shelf (COTS) components, Government Furnished Data (GFD), Government Furnished Item (GFI) software, and Government Furnished Equipment (GFE) is encouraged. Proprietary software SHALL [4070] not be used without prior Government approval.

3.11.8. System Testability

All decisions regarding system testability will be left to design.

3.11.9. System Usability

All decisions regarding system usability will be left to design.

3.12. Design and Construction Constraints

All decisions regarding design and construction constraints (e.g., weight limits, dimensional limits, etc.) will be left to design.

3.13. Personnel-Related Requirements

There are no special personnel-related requirements for CTAS beyond the normal FAA personnel procedures.

3.14. Training-Related Requirements

Training manuals SHALL [4080] be prepared for the installation, operation and maintenance of the System.

3.15. Logistics-Related Requirements

There are no special logistics-related requirements for CTAS beyond the normal FAA logistics procedures.

3.16. Other Requirements

There are no other special requirements for CTAS.

3.17. Packaging Requirements

There are no special packaging requirements for CTAS.

3.18. Precedence and Criticality Requirements

All requirements specified in this document SHALL [4090] have equal weight.

4. QUALIFICATION PROVISIONS

A set of qualification methods SHALL [5000] be developed for CTAS and specify for each requirement in Section 3 the method(s) to be used to ensure that the requirement has been met.

Qualification methods may include:

a. Demonstration: The operation of the system, or part of the system, that relies on observable functional operation not requiring the use of instrumentation, special test equipment, or subsequent analysis.

b. Test: The operation of the system, or a part of the system, using instrumentation or other special test equipment to collect data for later analysis.

c. Analysis: The processing of accumulated data obtained from other qualification methods. Examples are reduction, interpolation or extrapolation of test results.

d. Inspection: The visual examination of system components, documentation, etc.

e. Special qualification methods: Any special qualification methods for the system, such as special techniques, procedures, use of standard samples or any other method not covered by a-d above.

5. REQUIREMENTS TRACEABILITY

Not required for this system-level specification.

6. NOTES

This section contains information intended to aid the understanding of this document.

6.1. Acronyms

AAR	Airport Acceptance Rate
A/C	Aircraft
ACES	Adaptation Controlled Environment System
ACID	Aircraft ID or Aircraft Identification
ADG	Arts Data Gatherer
AERA	Automated En Route ATC
AF	Airways Facilities
AGW	ARTS GateWay
AMCC	ARTCC Maintenance Control Center
ANSI	American National Standards Institute
AOC	Airline Operations Center
ARTCC	Air Route Traffic Control Center
ARTS	Automated Radar Terminal System
ASD	Aircraft Situation Display
ASP	Arrival Sequencing Program
AT	Air Traffic
ATC	Air Traffic Control
ATCT	Airport Traffic Control Tower
ATM	Air Traffic Management
ATMIS	ARTS Traffic Management Interface Subsystem
AVA	Adaptation Validation and Analysis

BITE	Built-ln-Test-Equipment

CAS	Calibrated Air Speed
CCB	Configuration Control Board
CDR	Continuous Data Recording
CDI	Center Data Interface
CDRL	Contract Data Requirements List
CHI	Computer Human Interface
CM	Configuration Management
CMD	Center Maximum Delay
CNS	Communications, Navigation, and Surveillance
COTS	Commercial Off-The-Shelf
CPDP	Company Preferred Descent Procedures
CPU	Central Processing Unit
CR	Crossing Restrictions
CSCI	Computer Software Configuration Item
CTAS	Center/TRACON Automation System
CTS	Coded Time Source

DA	Descent Advisor
DCA	Delay to be absorbed in Center Airspace
DCE	Distributed Computing Environment
DFW	Dallas/Fort Worth
DID	Data Item Description
DOF	Degree of Freedom
DOT	Department of Transportation
DP	Dynamic Planner
DSP	Departure Sequencing Program
DSR	Display System Replacement
DT&E	Development Test & Evaluation
DYSIM	Dynamic Simulator

EDP	Expedite Departure Path
EMC	Electromagnetic Compatibility
EMI	Electromagnetic Interference
EPR	Engine-Pressure Ratio

ESP	En Route Spacing Program
ETA	Estimated Time of Arrival
ETD	Estimated Time of Departure
ETG	Enhanced Target Generator
ETMS	Enhanced Traffic Management System

FAA	Federal Aviation Administration
FAATC	Federal Aviation Administration Technical Center
FAF	Final Approach Fix
FAR	Field Action Request
FAST	Final Approach Spacing Tool
FCC	Federal Communications Commission
FCFS	First Come First Served (scheduling method)
FCTS	First Common Time Step
FDAD	Full Digital ARTS Display
FDB	Full Data Block
FIPS	Federal Information Processing Standard
FP	Flight Plan

GFE	Government Furnished Equipment
GFI	Government Furnished Information
GFP	Government Furnished Property
GMT	Greenwich Mean Time (ZULU)
GPS	Global Positioning System
GRIB	Gridded Binary
GUI	Graphical User Interface

HCS	Host Computer System
HID	Host Interface Device
HW	Hardware
HWCI	Hardware Configuration Item

ICD	Interface Control Document
ID	Identification
IEEE	Institute of Electrical & Electronics Engineers
l/ F	Interface
IFR	Instrument Flight Rules
ILS	Instrument Landing System
I/ O	Input/Output
IOP	Input Output Processor
IPC	Inter Process Communication
IPT	Integrated Product Team
IRD	Interface Requirements Document
ISO	International Standards Organization
ITWS	Integrated Terminal Weather System

KDP	Key Decision Point

LAN	Local Area Network
LRU	Line Replaceable Unit; Lowest Replaceable Unit

M&C	Monitor and Control
MACH	MACH number (speed ratio to speed of sound)
MF	Meter Fix
MIL	Military
MIT	Miles-in-trail
MIT/LL	Massachusetts Institute of Technology / Lincoln Laboratory
MOTIF	Modular Toolkit Interface
MOU	Memorandum of Understanding
MTBF	Mean-Time-Between-Failure
MTTR	Mean-Time-to-Restore; Mean-Time-to-Repair


NAILS	National Airspace Integrated Logistics Support
NAPRS	National Airspace Performance Reporting System
NAS	National Airspace System
NASA	National Aeronautics & Space Administration
NAVAID	Navigational Aid
NCP	NAS Change Proposal
NDI	Non-developmental Items
NFDC	National Flight Data Center
NFS	Network File System
NMI	Nautical Miles
NOAA	National Oceanic and Atmospheric Administration
NWS	National Weather System

OETA	Original Estimated Time of Arrival
OFT	Outer Fix Time
OFD	Outer Fix Delay
OFX	Outer fix
OO	Object-Oriented
ORD	Operational Requirements Document
OSE	Open Software Environment
OSF	Open Software Foundation
OT&E	Operational Test & Evaluation
PAMRI	Peripheral Adapter Module Replacement Item
PAR	Preferred Arrival Route
PAS	Pseudo Aircraft Simulation
PFS	Profile Selector
PGUI	Planview Graphical User Interface
POSIX	Portable Operating System Interface for OSE
PVD	Plan View Display (Radar Display)

QA	Quality Assurance

RA	Route Analysis
RAID	Redundant Array of Inexpensive Disks
RAR	Runway Acceptance Rate
R&D	Research & Development
RFC	Request for Comments
RMA	Reliability-Maintainability-Availability
RMD	Route Maximum Delay
RMMS	Remote Maintenance Monitoring System
RMS	Remote Monitoring Subsystem
RPC	Remote Procedure Call

SAR	System Analysis Recording
SBSD	Spatially Based Sequencing Distance
SCSI	Small Computer System Interface
SDI	Statistical Delay Information
SDP	Software Development Plan
SDT	System Design Team; Systems Development Team
SLS	System Level Specification
SMA	Surface Movement Advisor
SMC	System Maintenance Coordinator
	System Manager Console
SMC-GUI	System Manager's Console Graphical User Interface
SMMC	System Maintenance Monitoring Console
SNMP	Simple Network Management Protocol
SSS	SubSystem Level Specification
STA	Scheduled Time of Arrival
STAR	Standard Terminal Arrival Route
STARS	Standard Terminal Automation Replacement System



STD	Scheduled Time of Departure; Standard
SW	Software
SWAP	Severe Weather Avoidance Procedure

TA	Time of Arrival
TAS	True Air Speed
TATCA	Terminal Air Traffic Control Automation
TBD	To Be Determined
TBS	To Be Supplied
TCP/IP	Transmission Control Protocol/Internet Protocol
TEC	Tower En route Control
TDI	TRACON Data Interface
TFM	Traffic Flow Management
TGUI	Traffic Management Advisor Graphical User Interface
TIM	Technical Interchange Meeting
TMA	Traffic Management Advisor
TMC	Traffic Management Coordinator
TMC-GUI	Traffic Management Coordinator Graphical User Interface
TMU	Traffic Management Unit
TOD	Top of Descent
TRACON	Terminal Radar Approach Control
TS	Trajectory Synthesis
TTF	Time to Fly

UPS	Uninterruptible Power Supply
UTC	Coordinated Universal Time (Zulu)

VFR	Visual Flight Rules
VOR	Very High Frequency Omni-Directional Range
VRTM	Verification Requirements Traceability Matrix

V&V	Verification and Validation

WAN	Wide Area Network
WMO	World Meteorological Organization
WX	Weather

ZDV	Denver ARTCC
ZFW	Fort Worth ARTCC

6.2. Glossary

Active Aircraft

Aircraft that are actively flying within the NAS environment.

Active FAST

See Final Approach Spacing Tool.

Adaptation

A collection of data generated by AVA which customizes the functions of CTAS to a specific air traffic site.

Adaptation Function

The process of tailoring a system to the relevant ARTCC and associated primary airports within a single TRACON.

Adaptation Validation and Analysis (AVA)

An automated tool which produces CTAS adaptation from NAS data sources such as ACES tapes, and manual inputs in graphical form from controllers for routes and procedures not in computerized media. AVA validates CTAS adaptations after they are created. AVA also has a data analysis capability which analyzes CTAS performance.

Adapted Airport

An airport for which AVA has supplied adaptation data to allow CTAS to schedules arrivals. Each instance of TMA or FAST may support six Adapted Airports, all of which must be within the same TRACON.

Aircraft's Total Flight Distance

The great circle distance from departure airport to arrival airport. This is the shortest distance the aircraft could travel and accomplish its flight.

Air Route Traffic Control Center (ARTCC) (also called "Center")

Has the responsibility for the enroute portion of Instrument Flight Rules (IFR) flights.

Airport Acceptance Rate (AAR)

A dynamic input parameter specifying the number of arriving aircraft (measured at the runway threshold) which an airport or airspace can accept from the ARTCC per hour. AAR is used to calculate the desired interval between successive arrival aircraft.

Airport Runway Configuration

The list of arrival runways at an airport that are active (i.e., operational) for any specific time interval.

A-K Route

This is also known as the Host Converted Route. It is the final computerized version of the route of flight taken originally from the field ten route of flight in the flight plan. The process of converting this route of flight involves translating all fixes into standard ones for that area, expanding all short hand expressions to their full form, converting the end of the flight using the active Preferred Arrival Route (PAR), and calculating a predicted time of passage for every fix in the route.

Alarm

An alarm is defined as a condition that occurs when a subsystem determines that a key monitored parameter, condition, or status is outside required operating limits, or changed to an invalid state. When this happens, the subsystem shall be considered to be in an alarm condition. An alarm message shall be generated when the subsystem is in an alarm condition.

Alert

An alert is defined as a condition that occurs when a subsystem determines that a key monitored parameter, condition or status is within required operating limits but outside desired operating limits. When this happens, the subsystem shall be considered to be in an alert state. An alert message shall be generated when the subsystem is in an alert condition.

Analysis Category

The same as the Route Analysis Category. A categorization of an aircraft's current situation. This basic categorization determines the estimate of an aircraft's future intention (especially in FAST). Based on this categorization, CTAS determines an aircraft's probable future route and all permissible routing variations.

Analysis Category Decision Tree

A list of rules found in the site adaptation which assign an aircraft to an analysis category. The analysis category decision tree examines an aircraft's position and heading, and compares it to the local airspace route structure.

Analysis Packet

In FAST, a packet of information from RA to PFS which contains all the Times of Arrival from the current aircraft position to one runway with all adapted Degree of Freedom settings, along with their path lengths and delay values.

Antecedent

The first part of a fuzzy rule consisting of the evaluation of the extent to which a condition is true. In FAST, the condition is related to a comparison between the attributes of two aircraft such as altitude difference, speed difference, or position difference.

Automated Maintenance Control Center (AMCC)

A central facility within each ARTCC (En-Route Center) which monitors the functioning of all the facility's hardware and software. The AMCC will also have some control capability over the hardware and software in the ARTCC. CTAS will have an interface to the AMCC.

Availability

The probability that an item will be operationally ready to perform its function where called upon at any point in time. Steady state availability of installed equipment is a function of equipment mean-time-between-failures (MTBF) and equipment downtime (MDT), as follows:

Base

The portion of a standard landing pattern in which the aircraft is moving in the perpendicular direction of the arrival runway. This is the last segment of flight before the aircraft turns to make its final approach to land. The base segment is preceded by either the downwind segment or the short segment.

Blocked Meter Fix Interval

A length of time during which no aircraft can be automatically assigned to a meter fix. This is usually used for periods of hazardous weather over a meter fix.

Blocked Runway Interval

A length of time during which no aircraft can automatically be assigned to a specified runway. This is usually used for a large departure rush or for runway maintenance such as snow plowing.

Blocked Slot

A runway landing interval reserved for a specific type of aircraft. The specific type of aircraft may be derived from a specific aircraft for which the Blocked Slot is reserved.

Calibrated Air Speed (CAS)

The airspeed measured on an aircraft using a forward mounted pivot tube. This measured speed is relative to the local wind, and is lower than the true air speed by the square root of the ratio of the density of the local atmosphere to the density of the atmosphere at sea level.

Center

Air Route Traffic Control Center (also called ARTCC).

Center Maximum Delay (CMD)

The maximum delay which can be absorbed by an aircraft traveling along its converted route of flight between the boundary of the Center's airspace and the aircraft's assigned meter fix.

Center-TRACON Automation System (CTAS)

The collection of integrated software and hardware ATC automation tools developed for the purpose of providing automated schedules on arrival and departure air traffic at TRACON and En Route Centers.

Company Preferred Descent Procedures (CPDP)

The airline specific portion of the descent procedures used by the Trajectory Synthesis algorithms to predict the aircraft arrival trajectory. The company specific portion of each descent is the idle thrust descent speed (Mach or CAS) to be used in each descent segment.

Commercial Off the Shelf (COTS).

Hardware of Software which is available for sale in a commercial catalog (and which is likely to be mass produced). Hardware and Software which is commercial off the shelf is likely to be less expensive than specially ordered hardware and software.

Consequence

Same as Consequents. The second part of a fuzzy rule specifying the weight assigned to the antecedent for a given attribute.

Consequents

Same as Consequence. The second part of a fuzzy rule specifying the weight assigned to the antecedent for a given attribute.

Constraint

In FAST, a condition within the TRACON in which the flight of one aircraft might constrain the flight of another. Some FAST constraints involve rules for approaches to parallel runways, or rules concerning conflicts occurring when an aircraft goes "over the top" of the airport. Mostly, however, constraints in FAST refer to aircraft sharing the same landing pattern segment such as downwind, base, or final.

Critical System

Any air traffic control system which would make the job of maintaining adequate separation impossible if it failed. Critical systems are required to be powered by the critical electrical power supply and are also required to maintain a 0.9999 availability rating.

Data Item Description (DID)

Describes the format and required contents of a document developed under military standard 498.

Decision Tree

A list of rules found in the site adaptation which will categorize an aircraft in a specific way. Examples are the Stream Class Decision Tree, the Meter Fix Decision Tree and the Analysis Category Decision Tree. These assign an aircraft's Meter Fix, Stream Class, or Analysis Category based on an aircraft's situation and a site specific set of rules.

Degrees of Freedom (DOF)

Variations to the arrival route or speed profile of an aircraft that cause it to be delayed. These are used by controllers to increase the delay an aircraft will absorb on a specific segment of the route. They are used by the FAST system to estimate the total delay which the system can absorb without causing conflicts between arriving aircraft.

Delay Close-Out Time

A SDI session ends if there is no reportable delay within the Delay Close-Out Time. This time is read from adaptation but is usually 45 minutes.

Delay to be absorbed in Center Airspace (DCA)

The difference between the STA and ETA at the Meter Fix.

Departed Flight Plan

A flight plan issued for an aircraft which has just become airborne and has been detected on any NAS system. The coordination time is the actual time of takeoff.

Development Test and Evaluation (DT&E)

DT&E is that T&E conducted primarily to assist the engineering design and development process by determining incrementally the degree to which functional engineering specifications are attained. DT&E includes T&E of systems, subsystems, units, hardware, software, full-scale engineering models and prototypes. DT&E includes functional T&E of unit, subsystem, and system integration; testing functional integration of hardware with software and the operational program; and testing functional capability and integration with operational systems on sites and with the NAS.

Downwind

The portion of a standard landing pattern in which the aircraft is moving in the opposite direction of the arrival runway. Presumably, the aircraft is traveling in the downwind direction during this portion of the flight. The downwind segment is preceded by either the long segment or the over the top segment.

Dynamic Planner (DP)

A TMA process responsible for scheduling arrival aircraft at the Meter Fix and the Runway. DP is usually defined to be Essential and Non-Restartable.

Essential Process

A process/function/service that if lost will cause the entire CTAS system to fail if the non-critical item itself fails or is shut down and can not be restarted.

Essential System

Any air traffic control system which would make the job of maintaining adequate separation more difficult if it failed. Essential systems are required to maintain a 0.999 availability rating.

Estimated Flight Plan

A flight plan issued for an aircraft that is currently airborne in the NAS system. The coordination time listed is the estimated time of entry into this ARTCC.

Estimated Time of Arrival (ETA)

This is the time at which the aircraft is estimated to cross the runway threshold (or meter fix, FAF). The ETA is determined without any restrictions imposed by other aircraft. A non-radar based ETA is derived from an aircraft's flight plan. It is used until the aircraft is tracked by radar. A radar-based ETA is computed based on the aircraft's current position and velocity estimates given by the surveillance processor, the expected route, speed, altitude profile of the aircraft to the threshold, and the projected wind.

The ETA is the earliest time an aircraft would cross a fix or runway threshold if allowed to follow its assigned flight path without being impeded by separation constraints to other aircraft and with no weather or air traffic control restrictions are placed on the aircraft flight.

Fail-over

A method of automatic recovery from a hardware failure in which all the processes on the failed platform are restarted on a spare hardware platform by the system Monitor and Control Function. In CTAS Build 2, only restartable processes may failover to another platform.

Feeder Gate

A region in which arrival aircraft enter the TRACON. A feeder gate may contain one or more meter fixes. The typical TRACON has four feeder gates, one each to the North East, North West, South East and South West of the airport.

Final Approach

The last portion of a standard landing pattern in which the aircraft is moving on the runway heading and is approaching the runway in an attempt to land. There is very little variability in potential landing time after an aircraft has established itself on the Final Approach segment.

Final Approach Fix (FAF)

This is a fix which marks the beginning of the ILS approach for a runway.

Final Approach Spacing Tool (FAST)

A primary functional component of CTAS that is primarily a tactical tool that aids controllers in making the maximum use of airport capacity. Passive FAST generates runway assignments, landing sequences. Active FAST additionally issues speed and turn advisories to controllers.

First Common Time Step (FCTS)

In FAST, the time at which two aircraft are predicted to be simultaneously a particular landing pattern segment (constraint). This time, which is also an index into the trajectories of both aircraft, is used by FAST to determine when two aircraft might conflict on a constraint.

Fix

A geographical position determined by visual reference to the surface, by reference to one or more radio NAVAIDs, by celestial plotting, or by another navigational device. A geographical point expressed in latitude and longitude (which Is converted to system coordinates). The fix is stored and uniquely identified in adaptation. A fix is both an aid for navigation and a reference point for control purposes. The geographical position of an aircraft for a specified time which is established by reference to navigational aids or celestial plot.

Flight Plan

A detailed plan for each flight occurring under Instrument Flight Rules. The flight plan contains a route of flight, anticipated departure and arrival times, aircraft identification, aircraft call sign, aircraft type, on board equipment, anticipated speed and altitude, and other information pertinent to the flight. CTAS makes substantial use of this information in order to anticipate aircraft routing and procedures.

Flow

A generic orthogonal categorization of aircraft with similar scheduling characteristics (e.g., all aircraft in a Super Stream Class are said to be in one flow).

Frozen Schedule

In TMA, the portion of the schedule which is beyond the Freeze Horizon and which is not subject to further change.

Full Data Block (FDB)

Refers to the display tag that conveys information such as aircraft id, altitude, and speed on a CTAS situation display.

Full Digital ARTS Display (FDAD)

The air traffic controller's display used in the TRACON in sites that use the ARTS-IIIE system.

Fuzzy Logic

A body of control theory where conditions can be partially true (instead of the usual true or false) and where controls can be partially applied (instead of the usual on or off). Developed by Professor Zadeh of Berkeley.

Gate Dependencies

A relationship between available gates and some other condition, e.g., arrival configuration, and destination airport. For instance, in Oakland some gates are not used by aircraft going to San Jose. In Los Angeles, some gates are used only in West configuration and others are used only during East configuration.

Ground Speed

The rate of travel of an aircraft relative to earth fixed coordinates. This is the velocity reported by ground based radar tracking. It is also the velocity reported by the Global Positioning System.

HCS Update Cycle

The period between track reports provided by the HCS to CTAS. This value is hard coded in the CTAS patch to twelve seconds.

Host Computer System (HCS)

The existing mainframe computer system which is at the heart of every ARTCC. The HCS conveys Flight Plans, assembles radar data within the ARTCC, plots the position of all tracked aircraft and prints flight progress strips for controllers. It is a primary source of information for the TMA and FAST systems.

Host Converted Route

This is also known as the A-K or Alpha Kilo Route. It is the final computerized version of the route of flight taken originally from the field ten route of flight in the flight plan. The process of converting this route of flight involves translating all fixes into standard ones for that area, expanding all short hand expressions to their full form, converting the end of the flight using the active Preferred Arrival Route (PAR), and calculating a predicted time of passage for every fix in the route.

Hovering ETA or STA

A situation in which the predicted time of flight is not changing and the ETA or STA of one aircraft appears to be "hovering" on the timeline while all the others move down inexorably toward landing. This is usually due to the predicted entry of an aircraft into the arrival center not occurring. If the aircraft does not enter the center airspace within three minutes of its prediction, the HCS adds another three minutes to this predicted time. This can go on for a considerable time until the aircraft actually enters the center, or the HCS determines that the expected arrival is not actually going to occur.

In-Center Departure

A flight destined for a CTAS airport which originates in the same center as the CTAS airport.

Inertial Flight Path Angle

The angle between the path of motion of an aircraft and the local horizontal plane defined as normal to the earth's local gravitational field.

Initial Routes

In FAST, the set of un-modified routes from the current aircraft position to the assigned runway. These routes are eventually modified by degrees of freedom to minimize conflicts in the TRACON.

Initialization List

In FAST, a data structure containing a list of aircraft associated with their currently assigned runways. Other associated information is included such as the initial trajectory segmented according to its constraints.

Instrument Flight Rules (IFR)

Rules governing the procedures for conducting instrument flight. Also a term used by pilots and controllers to indicate type of flight plan.

Instrument Landing System (ILS)

A microwave landing system which allows an aircraft to fly most of the final approach segment under instrument conditions. It provides an indication of the runway center line and the recommended glide slope for the landing approach.

In-TRACON Departure

A flight destined for a CTAS airport which originates within the same TRACON as the CTAS airport (a very short flight).

Kinematic Trajectory Modeling

Trajectory modeling based on air traffic procedures. In this type of trajectory modeling, it is assumed that the pilot will supply what ever commands are necessary to achieve certain air traffic procedures. It is assumed that the procedures call for flight modes that are well within the capability of all airframes in the CTAS system. This type of trajectory modeling is used in the TRACON by TMA and is used everywhere in the FAST system.

Kinetic Trajectory Modeling

Trajectory modeling using the complete force model equation. In this type of trajectory modeling, the flight capabilities of the aircraft model are used. The trajectory of each aircraft is calculated from its engine thrust and airframe drag models. This type of trajectory modeling is used in the En-Route Center in TMA.

Long

The portion of a standard landing pattern in which the aircraft is moving at a 135-degree angle to the arrival runway. Aircraft on the short segment will make a 45-degree turn to downwind and then a 90-degree turn in the opposite direction to base followed by another 90 degree turn to final approach.

Long Cycle

In FAST, an algorithm for making a final determination about the benefit of reallocating an aircraft from one runway to another. This determination is based on the predicted total remaining time to fly for all aircraft in the FAST system. The long cycle analyzes the single most promising runway reallocation identified by the Short Cycle.

Main Arrival Plan

In TMA, the arrival plan viewed in both the ARTCC and the TRACON. The main arrival plan is in contrast to a Preview Arrival Plan which has not been agreed upon by both facilities.

Membership

The membership is a number between 0 and 1 which expresses the extent to which a condition in the antecedent is considered to be true. The membership value is obtained using the membership functions shown in Appendix B.

Metering

(1) Controlling the flow rate (aircraft per hour) into the terminal area.

(2) Controlling the traffic flow rate past a particular gate, usually without concern for spacing the traffic or the particular sequence that results.

(3) The En Route Metering (ERM) or the Arrival Sequencing Program (ASP) functions.

Meter Fix (MF)

A navigational fix, along an established route, depicted on published instrument approach procedures and charts, used to meter air traffic flows into a TRACON. A typical configuration has four meter fixes distributed evenly around the congested TRACON airspace.

Meter Fix Arc

An arc with a distance equal to the closest meter fix.

Meter Fix Crossing Tolerance

When determining the meter fix assignment for an aircraft, TMA determines the intersection of the Host Converted Route with the TRACON boundary. If this intersection point is within the Meter Fix Crossing Tolerance distance of the closest meter fix, than the aircraft is assigned to that Meter Fix. This value is found in the site adaptation.

Meter Fix Decision Tree

A list of rules found in the site adaptation which assign an aircraft to a meter fix. The meter fix decision tree looks for the presence of certain site specific indicators in the converted route. It also examines the anticipated arrival configuration and the destination airport as part of the decision process.

Miles-In-Trail (MiT)

A method of restricting aircraft flow in a stream based on defining a minimum separation distance between aircraft.

Monitor and Control (M&C)

The portion of a distributed computing system which controls the function of all the system's parts. This system component is also responsible for monitoring the health of all the system hardware and software and is responsible for attempting to correct any system failures it detects.

National Airspace Performance Reporting System (NAPRS)

Records delay data by fix and total, foray aircraft which enter the ARTCC airspace and experience delays greater than a user-specified time. FAA Order 6040.15 covers the reporting of air traffic delays of more than 15 minutes, and the procedures to report these delays occurring under the control of each respective Air Traffic Facility.

National Airspace System (NAS)

The common network of U.S. air traffic airspace; air navigation facilities, equipment and services, airports or landing areas; aeronautical charts, information

and services; rules, regulations, and procedures, technical information, manpower, and materials. Included are system components shared jointly with the military.

Nominal TRACON Routes

A set of routes of flight for aircraft within the arrival TRACON. These routes are defined in the site adaptation. The nominal TRACON routes do not include any degrees of freedom variations which might be examined by FAST.

Nominal TRACON Speeds

A set of air speeds used in conjunction with Nominal TRACON Routes. These are stored in the site adaptation in association with the routes and the different aircraft engine classes for aircraft that use each route.

Non-Essential Process

A process/function/service that, if lost, will not cause the entire CTAS system to fail if the non-critical item itself fails or is shut down and cannot be restarted.

Non-Restartable Process

A process/function/service that if lost cannot be restarted automatically by the CTAS Monitor and Control function. This usually applies to processes which would require the restoration a great deal of state memory.

Original Estimated Time of Arrival (OETA)

The ETA calculated when the aircraft first enters the CTAS area. It is determined from the first five ETA calculations based on track data.

Outer Fix Arc

An arc at a distance beyond the meter fix.

Outer Fix Delay (OFD)

The maximum delay that can be absorbed as an aircraft travels from a specific Outer Fix/Arc to a specific Meter Fix/Arc.

Over the Top

A landing pattern segment immediately prior to downwind, in which an aircraft travels across and above the airspace used by departure aircraft (on the arrival runway). This segment (and the maneuver of the same name) is often used to assign an aircraft to the parallel runway on the opposite side of the airport.

Passive FAST

See Final Approach Spacing Tool.

Plan View Display (PVD)

An Air Traffic Controller's Display that plots the position of aircraft along with identifying data tags.

Preferred Arrival Route (PAR)

The last portion of a Host Converted Route that concerns the portion of flight immediately before the meter fix. The Host Computer System adds this detailed portion of the route to the Host Converted Route about an hour before landing. The exact PAR assigned may be a function of the Airport Runway Configuration or the details of which meter fixes are available at the time of landing.

Preview Arrival Plan

In TMA, the arrival plan viewed by a single TMC as a tool for visualizing the effect of proposed flow rate changes. The Preview Arrival Plan is local to a small number of displays, and has an appearance that is distinguishable from the Main Arrival Plan. If the Center and TRACON facilities agree on a particular Preview Arrival Plan, it may replace the Main Arrival Plan.

Priority Aircraft

An aircraft status designated by the TMC to a particular aircraft that causes that aircraft to have priority in sequencing at the meter fix and at the runway. All other air traffic in CTAS will be scheduled to accommodate an aircraft with the Priority Aircraft designation.

Profile Selector (PFS)

A FAST process responsible for calculating a conflict minimized global arrival plan and assigning runways and sequence numbers for individual aircraft. PFS is usually defined to be Essential and Non-Restartable.

Proposed Flight Plan

A flight plan issued for an aircraft that has not yet become airborne. The coordination time is the proposed time of takeoff.

Region

A closed set of all arrival stream classes that could ever be combined into super streams at a facility. In Denver, the set of stream classes TOMSN Jets, TOMSN Props, RAMMS Jets, and RAMMS Props, form the North West Region of stream classes.

Restartable Process

A process/function/service that, if lost, may be restarted automatically by the CTAS Monitor and Control function. This usually applies to processes which would require the restoration little or no state memory. Restartable processes can be restarted on alternate machines in the event of hardware failure giving CTAS some "failover" capability.

Route Analysis (RA)

A CTAS process responsible for predicting the ground track of all arrival aircraft from their current position through landing. RA is usually defined to be Essential and Restartable.

Route Analysis Category

A categorization of an aircraft's current situation. This basic categorization determines the estimate of an aircraft's future intention (especially in FAST). Based on this categorization, CTAS determines an aircraft's probable future route and all permissible routing variations.

Route Maximum Delay (RMD)

The maximum delay which can be absorbed between the Meter Fix and the Runway along a specific TRACON route.

Runway Threshold

The beginning of the arrival runway, and the location of aircraft touchdown used by CTAS in its scheduling calculations.

Rush Alert

Alerts the TMC when a rush (time of traffic congestion) could require arrival metering to better control the entry of aircraft to the terminal airspace.

Satellite Airports

Airports that lie under or within the airspace of the ARTCC. Usually used by CTAS in the sense of airports from which aircraft are departing, to go to a CTAS-adapted airport.

Schedule

A specific sequenced list of Scheduled Times of Arrival (STAs) and the corresponding times in which each aircraft will cross the runway threshold or other point of reference.

Scheduled Time of Arrival (STA)

An STA is the desired time that an aircraft should cross the runway threshold. It takes other traffic and airspace configuration into account. An STA shows the results of the TMA scheduler which has calculated an arrival time according to parameters such as spacing, aircraft performance, and weather.

Schedule Freeze

In TMA, aircraft at a certain distance or time from the meter fix have their schedule "Frozen". This means that its STA is no longer recalculated, and that the aircraft's meter fix and runway assignment will not be changed.

Sector Controller

The generic name for an air traffic controller who is actually responsible for air traffic in one or more sectors either in an ARTCC or in a TRACON.

Short

The portion of a standard landing pattern in which the aircraft is moving at a 45-degree angle to the arrival runway. Aircraft on the short segment will make a 45-degree turn to base and then a 90-degree turn in the opposite direction to final approach.

Short Cycle

In FAST, an algorithm for screening a large number of potential runway reassignments. It is strictly based on wake vortex separation at the runway threshold. Aircraft which seem likely to benefit from runway reassignment are then submitted to the Long Cycle.

Simultaneous Approach

A condition in which two aircraft can land simultaneously on parallel runways that are separated by a sufficient distance.

Spatially Based Sequencing Distance (SBSD)

The distance from the arrival airport at which TMA switches from time based sequencing to spatially based sequencing. TMA is programmed to predict that aircraft will not be allowed to pass one another within a certain distance of the arrival airport. This specific distance is part of the site adaptation.

Standard Terminal Automation Replacement System (STARS)

The replacement to the present ARTS system in the TRACON. The first STARS system is scheduled for Boston TRACON in late 1997.

Staggered Approach

A condition in which two aircraft are simultaneously approaching parallel runways that are not separated by a sufficient distance to allow a simultaneous approach. In this case, the required separation is achieved by causing one aircraft to be substantially ahead of the other during the approach and landing.

Statistical Delay Information (SDI)

Information compiled by CTAS summarizing flights experiencing major air traffic delays. This information is similar to their type of information gathered in the National Airspace Performance Reporting System (NAPRS).

Stream Class

The set of aircraft of specific type(s) that will cross a particular feeder gate meter fix (e.g., all jets crossing LANDR). Within a stream class, all aircraft must maintain a specified minimum miles-in-trail separation at the feeder gate. For aircraft in different stream classes, there may be no in-trail separation requirements at the feeder gate.

Stream Class Decision Tree

A list of rules found in the site adaptation that assign an aircraft to a stream class. The stream class decision tree examines an aircraft's assigned meter fix, its engine class, the anticipated airport arrival configuration, and the total straight line distance of the flight from takeoff to landing.

Super Stream Class

The set of one or more stream classes that have a combined miles-in-trail separation constraint.

Switch Criteria

In FAST, nominally a pass-fail criteria for the Long Cycle, it is actually a mechanism for switching one runway reassignment with another. When the switch criteria fails, the pending runway reassignment is not accepted, however, another replacement runway reassignment is accepted in its place.

System Flight Time

The total time of flight remaining to all aircraft in the CTAS system if all the aircraft behave as predicted by the arrival plan. This time is used as a metric to determine the relative benefit of one arrival plan versus another.

System Management

A primary functional component of CTAS that monitors the health of the hardware and software. It also provides control functions to start and stop CTAS operations.

System Management Console (SMC)

A CTAS workstation with a Graphical User Interface that allows an operator to access the CTAS Monitor and Control Functions. The System Management Console displays the status of all CTAS hardware and software, and allows the user to start, stop, and reconfigure the CTAS system.

System Management Coordinator (SMC)

The title for an individual who is responsible for initialization, termination and monitoring the health of CTAS.

Terminal Radar Approach Control Facility (TRACON)

Concerned with the approach and departure portions of IFR flights in relation to a major airport.

Threshold

The beginning of the arrival runway, and the location of aircraft touchdown used by CTAS in its scheduling calculations.

Time-Based Metering

A method of restricting aircraft flow by scheduling the time at which each aircraft should cross a predetermined fix.

Time of Arrival (TA)

Any time calculated by the FAST system that, in accordance with a specific routing option and Degree of Freedom settings, could be a landing time. FAST considers many Times of Arrival before sequencing and scheduling aircraft.

Time to Fly (TTF)

The time (either predicted or actual) for an aircraft to fly along a prescribed route from one specified location (on the route) to another.

Tower En Route Control (TEC)

Tower En Route Control aircraft are generally those that fly at lower altitudes and that are controlled by a series of abutting TRACONs as they proceed along their route of flight. They are not in contact with the overlying ARTCC. Very often, they are turboprop aircraft.

Track Time

The time associated with a radar track report.

TRACON Acceptance Rate (TAR)

A dynamic input parameter specifying the number of arriving aircraft (measured at the TRACON boundary) that the TRACON airspace can accept from the ARTCC per hour. TRACON Acceptance Rate is used to calculate the desired interval between successive arrival aircraft.

TRACON Altitude Profile

A complete prescription for the altitude profile of an aircraft's flight in the TRACON. This is a list of altitudes and distances from the runway at which they are to become effective. The TRACON Altitude Profile is part of the site adaptation and is associated with each TRACON route.

Traffic Management Advisor (TMA)

A primary functional component of CTAS that generates runway assignments, landing sequences, and schedules arriving aircraft to runway threshold and meter fix. It also assists in runway configuration control and flow management.

Traffic Management Coordinator (TMC)

The title for an individual air traffic controller located in the Traffic Management Unit who is responsible for metering traffic as it flows into and out of the Center or TRACON. Under CTAS, the person performing the system-wide management of air traffic. This person communicates directly with area supervisors (as opposed to communicating directly with pilots). A typical function is that of metering operations, for example, closing gates or controlling the volume to meet acceptable rates. Also known simply as Traffic Manager.

Trajectory Synthesis (TS)

A CTAS process responsible for converting a predicted ground track into a complete four dimensional predicted trajectory. This is done using a knowledge of each aircraft's flight capabilities and arrival procedures. TS is usually defined to be Essential and Restartable.

True Air Speed (TAS)

The rate of travel of an aircraft relative to the air mass in which it is flying. The True Air Speed vector is the Ground Speed vector minus the Wind vector.

Unimpeded Flight

An aircraft that is allowed to follow its assigned flight path without being impeded by separation constraints to other aircraft and with no weather or air traffic control restrictions are placed on the aircraft flight.

Universal Time Coordinated (UTC)

Also called Zulu time or Greenwich Mean Time (GMT).

Vertex

A fix that is also the endpoint of a route segment and to which aircraft are frequently scheduled. These points are usually Coordination Fixes, Outer Fixes/Arcs, Meter Fixes, and Final Approach Fixes.

Visual Flight Rules (VFR)

Rules governing the procedures for conducting non-instrument flight. ircraft operating under Visual Flight Rules are not required to file a flight plan and are not monitored by CTAS.

Wake Vortex Separation Matrix

A separation rule found in FAA Order 7110.65 for safe operation with respect to wake vortex turbulence. The rule is subdivided by seven aircraft types, and is further subdivided by leading and trailing aircraft. This produces a total of 49 different separation standards for the avoidance of wake vortex turbulence.

Work List

In FAST, a data structure containing a list of aircraft associated with candidate alternate runways. The Work List is the starting point for the Short Cycle evaluation of possible runway reassignments.

APPENDIX A. SOURCE OF REQUIREMENTS

This section provides information sources for the CTAS Build 2 requirements. Table A-1 provides references to the software source for each requirement, specifically:

• B1 Code if the requirement is met by in Build 1.

• B2 Code if the requirement is met by either the Build 2.

• New if the requirement is not met by existing code.

Table A-1. Requirement Information Sources

	-- Software Source --
Rqmt #	B1 code	B2 code	New
0010-0012	X
0014			X
0020-0146	X
0147 a,b,d,e	X	X
0147 c			X
0147 f		X
0147 g	X
0180 a-e,g,h,k	X	X
0180 f,i	X
0190-0220	X	X
0225 a	X	X
0225 b		X
0225 c	X
0230-0255		X
0260-0270	X	X
0300 a		X
0300 b-d	X	X
0310	X	X
0315-0316		X
0320 a, b	X	X
0320 c	X
0330-0390	X
0400 a,b	X	X
0400 c	X
0400 d			X
0400 e	X
0410	X	X
0420-0440		X
0450-0460	X	X
0470 a	X	X
0470 b		X
0470 c, d			X
0470 e		X
0480	X
0500-0760	X	X
0770		X
0780	X	X
0790		X
0795-0796			X
0800, 0810		X
0820			X
0830-0850		X
0865 a		X
0865 b	X
0870		X
0885			X
0900-0930		X
0935			X
0940 a			X
0940 b-d		X
0945			X
0950-1040		X
1042-1046			X
1050-1090		X
1105-1210	X
1300, 1310			X
1311-1314	X
1320-1340
1350	X
1380-1510			X
1515-2260		X
2270	X	X
2280-2290			X
2291		X
2300-2330			X
2340	X	X
2520			X
2530-2550		X
2551-2555
2560		X
2570-2590			X
2620		X
2630-2847			X
2850	X
2860, 2870			X
2880, 2890	X
2900			X
2910-3480	X
3490			X
3500	X	X
3510	X
3520-3553			X
3561		X
3570	X	X
3571-3612			X
3613	X	X
3660			X
3680-3870	X	X
3880, 3890		X
3891-3897			X
3900	X	X
3910-4030	X
4031			X
4032-4040	X
4050			X
4060-4080	X
4090			X
5000	X

APPENDIX B. Antecedent and consequence functions for ordering rules in fast

Clearly, the crux of the sort (merge) algorithm for a "constraint segment" is the mechanism of comparing one aircraft (and its trajectory) against another to determine which should occur earliest in the combined sequence. The exact mechanism for employing "fuzzy" logic depends on the type of constraint segment being sequenced.

Three types of constraint segments exist in FAST:

1. GENERAL which includes BASE, DOWNWIND, LONG, & SHORT segments.

2. FINAL, i.e., the sequence on final which is shown to the controller.

3. DEPENDENCY which is similar to FINAL but is used for parallel runways using Staggered or Simultaneous approach.

Pairwise aircraft ordering is done by a set of fuzzy rules which are specific to the type of constraint (FINAL, GENERAL, or DEPENDENCY) being sequenced.

Each fuzzy rule has an antecedent and a consequence (or consequent). The antecedent examines a condition for a given attribute. This condition does not need to have an answer of true or false but can also be partially true (and false). The evaluation of the condition then results in a number between 0 and 1 called the membership value. The method used to evaluate the condition is the membership function. Currently, there are eleven antecedents as well as eleven membership functions included in FAST, as illustrated in Figures B-1 through B-11.

The consequence specifies the level of contribution a given attribute can make to the overall decision. For example, if aircraft A is lower in altitude than B, this contributes only "slightly" to A being favored to be ahead, etc. The levels of contribution are implemented in the form of identical weighting triangles spaced along the moment-axis ( x-axis ): choosing a triangle spaced at higher x-value means the contribution is weightier or more important to the decision. Figure B-12 shows the set of consequence triangles for aircraft A. There is a similar set for aircraft B on the negative x-axis.

The attribute membership number will now limit the triangle to a height equal to the membership number. The area of the remaining trapezoid ( call it Wi ) with the center of the base of the triangle at moment arm xi contributes moment Wi. xi in favor of aircraft A. The sum of all moments in favor of A are compared to the sum of moments in favor of B. The aircraft with the greatest total moment will be ordered first.

Figure B-1. Membership Function for "Causes Less Delay".

Figure B-2. Membership Functions for "Is Slightly Delayed", "Is Delayed" and "Is Significantly Delayed".

Figure B-3. Membership Functions for "Is Out of Delay" and "Is Significantly Out of Delay".

Figure B-4 . Membership Functions for "Is Slightly Ahead at FCTS, "Is Ahead at FCTS", and "Is Significantly Ahead at FCTS".

Figure B-5. Membership Function for "Is Ahead Along Downwind".

Figure B-6. Membership Function for "Is Currently Ahead".

Figure B-7. Membership Function for "Is Faster at FCTS".

Figure B-8. Membership Function for "Is Currently Lower".

Figure B-9. Membership Function for "Have In-trail ETAs".

Figure B-10. Membership Function for "Have In-trail Tracks".

Figure B-11. Membership Function of "Is Close".

Figure B-12. Consequences for Describing One Aircraft Being "AHEAD".

An example of a fuzzy rule may be as follows:

Rule: If aircraft A is lower than aircraft B, then aircraft A is "ahead."

In the example shown below, aircraft A is 500 feet lower than aircraft B.

Figure B-13. Membership Function for the Antecedent "Lower Than".

The antecedent is the phrase "aircraft A is lower than aircraft B" on a non-final segment. This statement is true.

The consequence is that aircraft A is "MARGINALLY AHEAD". However, aircraft A is not MARGINALLY AHEAD in an absolute sense, but according to the graph above, it is MARGINALLY AHEAD by a factor (based on the function shown) of 0.4.

Now look at the "consequence" function "MARGINALLY AHEAD." In this example, the consequence "MARGINALLY AHEAD" is 0 everywhere except between values of 20 and 30. It is 0 at 2.5 or 12.5, and increases linearly from either direction until it peaks at a 7.5 at a value of 1.

Because the membership of aircraft A in the property lower than was 0.4, only the consequence function below 0.4 is used in this evaluation.

Figure B-14. Consequence for Aircraft A is MARGINALLY AHEAD.

The result of the consequence of this one fuzzy rule (about altitude) is combined with the results from all the other fuzzy rules into the graph shown below.

Figure B-15. Evaluation of all Consequences in Favor of A and B.

The centroid of the sum of the consequences is then computed. In the example shown, the centroid will be slightly greater than 0. This causes the determination to be made that aircraft A will be sequenced ahead of aircraft B on the segment currently being analyzed.