**Traffic Flow Automation System (TFAS)**

# General Description

# January 31, 2002

# NAS2-98005

# Technical Research in Advanced Air Transportation Technologies

Final

General Description

Traffic Flow Automation System (TFAS)

CDRL Item 5e

# Prepared under

# RTO -- 62

# AATT Operational Concept for ATM -- Year 2002 Update

#### January 31, 2002

#### Prepared For: NASA Ames Research Center

#### Moffett Field, CA 94035-1000

#### Prepared By: Titan Systems Corporation -- SRC Division

#### Billerica, MA 01821-4134

![](media/image1.jpeg){width="5.416666666666667in" height="0.75in"}

**ACKNOWLEDGEMENT**

The description presented in this document is based primarily on the
information in References 1 through 4 and discussions with Ron Reisman
of NASA Ames Research who helped review and improve this draft document.

**Table of Contents**

### 1. Description 1

**2. Operational Concept 1**

**3. Functional Flow 6**

# Appendices

A.  **References and Bibliography 7**

B.  **ETMS Overview 8**

C.  **CTAS Processing Overview 26**

##### List of Figures

1.  **Typical Monitor-Alert TSD 2**

2.  **TFAS Monitor-Alert Graphs and Alert Timelines on TSD Display 2**

3.  **CTAS Elements of TFAS 4**

4.  **Moving TFAS M/A into ETMS Hub Site and Field Sites 5**

5.  **Inter Center Trajectory Coordination 5**

6.  **TFAS Functional Flow 6**

**B-1 ETMS Functional Flow 9**

**B-2 Data Flow of the ETMS 11**

**B-3 Data Flow of the ETMS Hub Site Function 14**

**B-4 Data Flow of the ETMS Field Site Function 16**

**B-5 Data Flow of the Traffic Model Functions 18**

**B-6 Airport Demand Processing 22**

**B-7 Sector Demand Processing 23**

**C-1 Data Flow of the RA Process 27**

### C-2 CTAS FAST Configuration 29

**C-3 CTAS TMA Configuration 30**

**General Description**

**Traffic Flow Automation System (TFAS)**

##  {#section .unnumbered}

1.  **Description**

The purpose of the Traffic Flow Automation System (TFAS) is to help
Traffic Management Coordinators (TMCs) in the Air Route Traffic Control
Centers (ARTCC), the Systems Command Center (SCC), and Terminal Radar
Control facilities (TRACONs) to manage the flow in domestic U.S.
airspace and into 21 major pacing U.S. airports. TFAS will accomplish
this by applying Center/TRACON Automation System (CTAS) technology to
improve the short-term (up to 45 minutes into the future) reliability of
the SCC Enhanced Traffic Management System (ETMS) Monitor-Alert (M/A)
tool.

The M/A function is based upon the *traffic demand* at each monitored
airport, sector, and fix, and will generate an *alert* whenever traffic
demand is projected to exceed a pre-defined *alert threshold*. The ARTCC
TMCs, working with the impacted sector controllers, are then responsible
for taking any required actions to alleviate the overload and achieve an
orderly flow.

An example of the M/A sector display is shown in Figure 1. The Traffic
Situation Display (TSD) shows a Red Sector indicating an active alert
(sector overloaded), and Yellow Sectors that indicate sectors that might
soon be overloaded. TFAS creates additional graphics such as
monitor-alert graphs and alert timelines, as shown in Figure 2.

TFAS will run multiple instances of CTAS (one per ARTCC), on networked
workstations or on multi-processor application servers, to create a
national CTAS functionality. TFAS will function as a trajectory
prediction and scheduling 'engine' for ETMS. TFAS will deliver useful
information to the SCC and Traffic Management Units (TMUs) by improving
the accuracy of the current ETMS. No new GUIs nor procedures will need
to be developed nor added to the SCC/TMU toolset.

TFAS will be developed in two phases. Phase I will result in a
demonstration system for evaluation by FAA SCC personnel. It will be
capable of being used as a daily-use operational test bed. Phase II will
result in a robust operational augmentation to ETMS which can be turned
over to the FAA for use as an operational system.

**2. Operational Concept**

The FAA's SCC and ARTCC TMCs use the ETMS to manage national and Center
air traffic flows. By reducing ETMS trajectory-modeling errors, the
effectiveness of the ETMS Monitor-Alert tool might be improved, thereby
reducing delays due to en route congestion.

TFAS will simultaneously run 18 CTAS instances, one for each of the 18
CONUS ARTCCs, which includes the airspace surrounding the 21 pacing U.S.
airports. TFAS will run in processors at ETMS Hub Site at the Volpe
Center.

![](media/image4.jpeg){width="5.25in" height="4.2in"}

F**igure 2. TFAS Monitor-Alert Graphs and Alert Timelines on TSD
Display**

The TFAS system will be comprised of separate CTAS systems adapted to
each of the TFAS Centers and airports, allowing for the most complete
system, with minimal changes to the current version of CTAS. During
Phase I, simplified adaptations of CTAS will be made. During Phase II,
these will be modified to incorporate more advanced scheduling, routing,
and procedural information as TFAS matures.

The underlying concept behind TFAS is to use the trajectory prediction
capabilities of CTAS with Traffic Management Advisor (TMA) to improve
upon the less accurate trajectory prediction capabilities of the current
ETMS, which in turn improves the accuracy of the Monitor-Alert (M/A)
function within ETMS. The improved accuracy will result in fewer false
alerts of upcoming capacity bottlenecks and fewer missed alerts, that
is, failure to get an alert when in fact an actual bottleneck occurs in
the future. TFAS will only be used to improve sector M/A and will not
affect fix or airport M/As.

TFAS will acquire flight plan, aircraft track, weather, and other
information from ETMS via the Input Source Manager (ISM). The typical
CTAS TMA system acquires aircraft data via an interface to the Center
Host computer. This provides CTAS with flight plans and radar track
data. The Host radar track data is updated every 12 seconds. The
logistics and code modifications necessary for utilizing Host data at
each facility preclude TFAS from using this Host data in Phase I. The
TFAS Phase I will connect to the ETMS system for track and flight plan
data.

As shown in Figure 3, each TFAS module (Center CTAS system) will keep
track of all sector Monitor-Alert conditions that will occur within the
next 45 minutes. The CTAS Route Analysis (RA) process has been modified
to produce a new aircraft trajectory event data-structure which contains
the times each aircraft enters and exits the sectors on its flight path.
Although the RA uses the Trajectory Synthesis (TS) process to generate
these Aircraft Sector Traversal Lists, the TS software itself did not
require modification for this purpose.

The Aircraft Sector Traversal Lists are passed to the Communications
Manager (CM), where sector occupancy counts are created from the
entry/exit time predictions. The CM software compares predicted
occupancy (i.e., number of aircraft traversing a sector within a
15-minute period) with the sector capacity limit. If a particular
sector's occupancy is greater than the capacity limit, a sector
Monitor-Alert condition is triggered.

The CM then sends the sector Monitor-Alert data to the TFAS Data Process
(TDP). The TDP is the repository for sector Monitor-Alert conditions
from all connected CMs. In this manner the TDP will assemble all CONUS
sector Monitor-Alerts.

The TDP will then scan the ETMS Traffic Monitor Database (TMD) file. If
TDP finds a sector Monitor-Alert in the TMD that is not in the TDP
database, that entry is deleted from the TMD file. If the TDP has a
Monitor-Alert condition that is not in the TMD file, then the TDP adds
this entry to the TMD. When this process is complete, the TMD file will
be identical to a normal ETMS file, **except** that the near- term
(i.e., within 45 minutes of present-time) sector Monitor-Alerts will
conform to the TDP internal model.

As shown in Figure 4, TFAS sends this modified composite sector
Monitor-Alert database to the Hub Site ETMS processors and to the
Traffic Situation Displays at the SCC, Centers, and TRACONS. If TFAS has
not yet been implemented for a particular ARTCC, the Monitor-Alerts in
that Center are not modified by TFAS.

![](media/image5.wmf){width="5.238888888888889in"
height="6.061111111111111in"}

**Figure 3. CTAS Elements of TFAS**

A basic TFAS algorithmic rule is: one trajectory per aircraft-track per
ARTCC. Each TFAS module (i.e., CTAS system) will generate a 4-D
trajectory that nominally terminates at the Center boundary
coordination-fix. Each TFAS module's Communication Manager (CM) process
will transmit the time the aircraft is predicted to arrive at the
coordination-fix to the

destination Center's CM, along with other information required
generating a 4-D trajectory for

![](media/image6.wmf){width="7.0in" height="2.41875in"}**Figure 4.
Moving TFAS M/A into ETMS Hub Site and Field Sites**

the aircraft in that Center. Each TFAS module CM will transmit such data
to each adjoining Center's CM, and will receive such data from each
adjoining Center's CM. In this manner multi-Center trajectories can be
created for each aircraft, although these will actually be discreet
single-Center trajectories linked by exchanged coordination-fix data.
Figure 5 schematically represents this scheme for a single aircraft
originating in Center A and traversing Center B.

**Figure 5. Inter Center Trajectory Coordination**

Appendices B and C show additional detail on the ETMS and CTAS
Processing.

**3. Functional Flow**

##### 

##### Figure 6 shows the functional flow of TFAS. The functional flow diagram is [not]{.underline} a data flow nor a software architecture diagram, and it does not represent how the TFAS function is implemented in software. It is meant to illustrate what functions TFAS performs and what are its primary inputs and outputs. The diagram was derived by modifying the functional flow for ETMS as shown in Appendix B. The grey boxes in the diagram are the primary functions that TFAS replaces in ETMS. The CTAS Route Analyzer Function in TFAS replaces the Flight Plan Processing function in ETMS and the CTAS Trajectory Synthesizer replaces the Flight Modeling function in ETMS. All other functions of ETMS are preserved, including the graphical user interfaces. 

##### ![](media/image7.wmf){width="5.80625in" height="4.310416666666667in"}Figure 6. TFAS Functional Flow

For each aircraft, the CTAS Route Analyzer takes flight plan information
to prepare a series of waypoints that the aircraft plans to traverse.
This information, along with aircraft flight data (position, speed,
profile), aircraft profile data (for the type of aircraft involved), and
geographic data such as sector and fix geometries, is used by the CTAS
Trajectory Synthesizer to calculate various flight times (e.g., ETAs)
and flight events (e.g., entry and leaving times of a sector) at various
points along the flight, and a speed/altitude profile for the aircraft.
This information for all aircraft forms part of the traffic demand
database (TDB). When the traffic demand is compared with the capacity of
the sectors, a Monitor-Alert is generated whenever the demand exceeds
the capacity. These Monitor-Alerts are sent to the various TSDs in the
SCC, Centers, and TRACONS for resolution by the TMCs.

**APPENDIX A. REFERENCES AND BIBLIOGRAPHY**

1.  Advanced Air Transportation Technologies Sub-element 2: Benefits and
    Safety Assessments; Modeling and Simulation TFAS Task Area Plan,
    Version 1.5, January 30, 2001.

2.  TMS-TFAS Development Briefing, Volpe National Transportation Systems
    Center, November 2000.

3.  TFAS Volpe Program Review, Volpe National Transportation Systems
    Center, December 5, 2000.

4.  Enhanced Traffic Management System (ETMS) Functional Description
    (DRAFT), Version 6.0, Word Version 2, January, 2000, Volpe National
    Transportation System Center Report Number VNTSC-DTS56-TMS-002

5.  FAA Denver ARTCC Traffic Management System (TMS),
    <http://www.nw.faa.gov/ats/zdvartcc/tmu_tools.html>, September 24,
    2000

6.  FAA Order 7210.3, Facility Operations and Administration, August 10,
    2000; <http://www.faa.gov/ATPubs/FAC/>, Chapter 17, Section 6
    (Enhanced Traffic Management System (ETMS)), Section 7 (Monitor and
    Alert Parameters), Section 8 (Traffic Flow Management)

7.  FAA Order 7110.65M, Air Traffic control, August 10, 2000;
    <http://www.faa.gov/ATPubs/ATC/index.htm>. Chapter 11 Traffic
    Management Procedures.

8.  AFD Process Description for the Design, Development, Release, and
    Maintenance of Software, AFD.0001, NASA Ames Research Center,
    November 27, 1999, <http://iadt.arc.nasa.gov/ISO9000/index.html>

9.  AFD Software Project Plan for CTAS, AFD.0002, NASA Ames Research
    Center, January 5, 1999.
    <http://iadt.arc.nasa.gov/ISO9000/index.html>

10. CSC/E2-97/7169, CTAS Route Analyzer FD/TLD -- Draft, November 1997

11. CSC/E2-92/7170, CTAS Trajectory Synthesizer FD/TLD -- Final, October
    1998

##### APPENDIX B. ETMS OVERVIEW

### B.1 Functional Overview

ETMS supports traffic managers in measuring traffic demand by showing,
on a national scale, current traffic surges, gaps, and volume. It also
predicts the flow of air traffic up to 12 hours in advance. Thus, a
traffic manager can access destinations, see the projected flow into
specific airports or sectors, and then take action to ensure that
traffic demand does not exceed system capacity.

The Traffic Situation Display (TSD) displays current aircraft positions
on a national scale superimposed on maps of the National Airspace System
(NAS) airspace and facilities. The M/A function, available through TSD,
is central to ETMS. It compares demand on components of the NAS to the
capacity of that component. M/A provides the capability to project
traffic demand for all airports, sectors, and fixes of interest in the
continental United States and it automatically generates alerts when the
projected demand exceeds capacity alert thresholds. Alerts are provided
in visual and aural form. Airport traffic demands are defined as the
number of arrivals and departures in a 15-minute interval. Sector
traffic demands are defined as the peak number of aircraft in a sector
at any one time during a 15-minute interval. Fix traffic demands are
defined as the number of fix crossings within a certain altitude range
during a 15-minute interval; the altitude ranges used correspond to the
altitude limits of the sectors that overlay the fixes. Alert thresholds
are defined in the same manner as the traffic demands. Predictions are
in 15-minute increments for up to 4 hours into the future. An alerted
sector can be isolated and enlarged on the map to display the predicted
congestion in greater detail. Traffic management coordinators can review
predicted traffic levels and time intervals of concern, which are
displayed graphically by red and yellow bars representing actual and
predicted traffic volume.

If the ARTCC traffic management coordinator needs more information,
lists of all concerned flights, along with their locations and intended
flight paths, may be displayed. This ETMS function assists traffic
managers in pinpointing potential traffic problems so they may take
action to reduce or eliminate congestion on the airways.

Monitor-Alert provides the traffic management coordinator with a
four-step process to display the predicted situation on the TSD screen.
First, the United States, or any selected area, can be viewed to
identify the existing and predicted alert sectors or airports. These are
displayed as red (active alert) or yellow (projected alert) (i.e., the
demand is projected to exceed the capacity). Once an alert area has been
addressed by the traffic management coordinator or sector controllers,
the alert color changes to green.

The second step in the process identifies some of the data behind the
alert. The screen displays a graphic bar chart that allows the sector
controller to visualize the nature of the alert as well as provide the
number of aircraft that exceed the capacity. The chart shows green for
the capacity of the sector or airport, yellow for the proposed, and red
for the active alert. Time is displayed in 15-minute increments.

Third, the traffic management coordinator can then display all of the
flights that make up the alert, or those that are projected flights that
will cause the demand to exceed the capacity. This allows the traffic
management coordinator to visualize the problem, spacing, and routes to
assist in establishing the necessary traffic management initiatives.

Fourth, traffic management coordinators may also display a printed
report of the aircraft that are affecting the alert which further
assists them in their decision making process.

![](media/image8.wmf){width="5.999305555555556in"
height="4.621527777777778in"}Figure B-1 illustrates how ETMS functions
currently create Monitor-Alerts (the Traffic Demand Database (TDB)),
which are sent to the ETMS Hub Site and Field Site TSDs.

**Figure B-1 ETMS Functional Flow**

For each aircraft, Flight Plan Processing takes flight plan information
to prepare a series of waypoints that the aircraft plans to traverse.
This information, along with aircraft flight data (position, speed,
profile), aircraft profile data (for the type of aircraft involved), and
geographic data such as sector and fix geometries, is used by Flight
Modeling to calculate various flight times (e.g., ETAs) and flight
events (e.g., entry and leaving times of a sector) at various points
along the flight, and a speed/altitude profile for the aircraft. This
information for all aircraft forms part of the traffic demand database
(TDB). When the traffic demand is compared with the capacity of the
sectors, a Monitor-Alert is generated whenever the demand exceeds the
capacity. These Monitor-Alerts are sent to the various TSDs in the SCC,
Centers, and TRACONS for resolution by the TMCs.

**B.2 ETMS Processing Overview**

This section presents the ETMS processing in a hierarchical fashion. The
[Summary]{.underline} groups the ETMS processing into three main
categories of functions: the *ETMS Hub Site Functions*, the *ETMS
Field‑site Functions*, and the *Ancillary Support Functions*. [ETMS Hub
Site Functions]{.underline} and [ETMS Field‑site Functions]{.underline}
describe the types of functions that compose the *ETMS Hub Site
Functions* and the *ETMS Field‑site Functions*, respectively. Each type
of function is further described in a subsequent section. T[raffic Model
Functions]{.underline} describes the *Traffic Model Functions*.

### [Summary]{.underline}

The ETMS processing functions are organized in three groups, as shown in
Figure B‑2.

The *ETMS Hub Site Functions* are real‑time, continuously running
functions that are located at the Volpe Center and support the entire
ETMS network. The *ETMS Hub Site Functions* process the real‑time
incoming data, maintain a large, distributed database, perform the
traffic modeling, and transmit processed data to the Field Sites where
traffic management is performed.

The *ETMS Field‑site Functions* are located at every Field Site where
traffic management is performed. The *ETMS Field‑site Functions* run
continuously. The *ETMS Field‑site Functions* maintain local databases
of data received from the *ETMS Hub Site Functions* and make the ETMS
data available to the traffic manager through the *Traffic Situation
Display (TSD)*.

The *Ancillary Support Functions* are off‑line functions that are run
periodically when data is received. The *Ancillary Support Functions*
produce static databases and files for data such as the airline schedule
data and geographical data. The *ETMS Hub Site Functions* and *ETMS
Field‑site Functions* use the static data during the real‑time
processing. The *Ancillary Support Functions* are run only at the Volpe
Center.

The ETMS continuously distributes all data that is pertinent to
individual flights for the next 12 hours to each Field Site as flight
data transactions. The ETMS also continuously distributes alert
summaries, jet streams, precipitation, and lightning data.

The ETMS maintains all other data only at the Hub Site. This data
includes schedule data beyond the next twelve hours, traffic demands for
airports, sectors, and fixes, capacities, general aviation (GA)
estimates, traffic management data concerning ground delay programs, and
weather reports: METAR/TAF. The *ETMS Field‑site Functions* answer a
traffic manager\'s request for this data by requesting the data from the
Hub Site. The manager can also update data on the Hub Site databases.
When a traffic manager enters capacities, GA estimates, alert status
changes, airline schedule updates at a Field Site, or a traffic
management command, the *ETMS Field‑site Functions* send the values to
the *ETMS Hub Site Functions*, which update the databases and send back
a reply.

### 

### [ETMS Hub Site Functions]{.underline}

The *ETMS Hub Site Functions* are organized in six groups as shown in
Figure B-3.

The *ETMS Communications Functions* handle all communications between
the ETMS Hub Site and Field Sites. The *ETMS Communications Functions*
distribute certain types of data

![](media/image1.wmf)Figure B-2. Data Flow of the ETMS

automatically to *User Interface Functions* at all Field Sites; these
data are the flight data transactions, alert summary data, and weather
data (jet streams, precipitation, radar tops, and lightning). The *ETMS
Communications Functions* pass commands and data requests entered by
traffic managers through *User Interface Functions* at Field Sites to
the appropriate functions at the Hub Site; the *ETMS Communications
Functions* also send update replies (SAs, FTs, TM data, TM replies,
detailed alert data, flight lists, etc.) from the Hub Site functions
back to the requesting sites. The commands and data requests that are
transmitted from the Field Sites are demand data requests, schedule
updates, schedule data requests, capacity updates, capacity requests, GA
estimate updates, GA estimate requests, TM requests, TM commands, and
alert status updates.

The *ETMS Communications Functions* also handle all message traffic
among ETMS components. The components can be located in geographically
diverse positions. The *ETMS Communications Functions* implement a Wide
Area Network (WAN) form of message switching that utilizes Local Area
Network (LAN) technologies wherever possible. Some external interfaces
that are not suitable to this unified WAN technology are handled by the
*External Communications Functions* described below.

NOTE: Message traffic between components at the same site are shown as
not going through the ETMS Communications Functions in Figure B‑3 to
maintain the simplicity of the diagram.

The *External Communications Functions* handle communications with
systems that are external to the ETMS. The external communications
components do not use the standard ETMS communications protocols and
therefore require specialized interface converters. The *External
Communications Functions* receive NAS messages from the NAS, oceanic
position updates (TOs) from Oceanic Message Processing (OMP), and
Estimated Departure Clearance Times (EDCTs) and Fuel Advisory messages
(FAs) from the ATCSCC, weather data from the WSI, and substitution
requests (SIs) from the airlines. The *External Communications
Functions* send control times (CTs) to the NAS and SI replies to the
airlines. The *External Communications Functions* send the NAS messages,
oceanic position updates (TOs), and grid winds weather data to the
*Traffic Model Functions,* send the EDCTs, FAs, and SIs to the *TM
Functions,* and send other weather data to the *ETMS Communications
Functions*. The *External Communications Functions* also receive
schedule messages from the *SDB Functions* and send them to the *Traffic
Model Functions*. The schedule messages are routed this way to include
them in the stream of NAS messages sent to the *Traffic Model
Functions*.

The main role of the *User Interface Functions* is to maintain and
display data for the traffic manager. This is performed at the Field
Site and at the Hub Site to support system monitoring and testing.

The *SDB Functions* integrate the airline schedule data into the ETMS.
The *Ancillary Support Functions* (not shown) periodically build an
airline schedule database from data received from the OAG. The *SDB
Functions* use the airline schedule database to feed *schedule messages*
for flights that are scheduled to depart within 12 hours of the current
time on the current day to the *External Communications Functions*.

The *SDB Functions* also perform maintenance of the airline schedule
database. Traffic managers may enter schedule updates to add/edit,
cancel, inhibit, or activate scheduled flights through the field‑site
*User Interface Functions*. The field‑site *User Interface Functions*
send the updates through the *ETMS Communications Functions* to the *SDB
Functions*, which modifies the database accordingly and sends a reply to
the manager. If the database change affects a flight that has already
been sent to the *External Communications Functions*, the *SDB
Functions* send a schedule message to indicate the change.

The *SDB Functions* also process schedule data requests from field‑site
*User Interface Functions* to support the request reports. The *SDB
Functions* look up the schedule data for the requested time interval,
date, and airport; and send the data back to the field‑site *User
Interface Functions* that made the request.

The *Traffic Model Functions* perform the detailed traffic modeling for
ETMS. The *Traffic Model Functions* use the following dynamic data
received from the *External Communications Functions*:

-   NAS messages - messages generated by the NAS computers including
    flight plans, departures, arrivals, etc.

-   Schedule messages - messages generated by the *SDB Functions* to
    feed scheduled airline flights for the next 12 hours into the
    traffic modeling

-   Oceanic position updates - messages obtained from OMP providing
    position updates for oceanic flights

-   Grid Winds - data describing the winds aloft

    The *Traffic Model Functions* use the following dynamic data
    received from the *TM Functions:*

```{=html}
<!-- -->
```
-   Flight control data - controlled departure times from EDCTs and SIs

-   Cancellations - flight cancellations from SIs

    The *Traffic Model Functions* use five static data sources produced
    by the *Ancillary Support Functions*:

```{=html}
<!-- -->
```
-   Grid database - geographical data for flight path processing

-   Aircraft dynamics database - data for modeling flight ascent and
    descent profiles

-   Element names file - names of airports, fixes, and sectors

-   Aircraft types file - definitions of all aircraft designators

```{=html}
<!-- -->
```
-   Departure ground times file - estimated time from gate pushback to
    wheels up

    The *Traffic Model Functions* interpret all incoming data and save
    them in internal databases. The *Traffic Model Functions* use the
    input data to maintain a best estimate of the performance of each
    flight and the traffic demands at each element. The *Traffic Model
    Functions* send flight data transactions and alert summaries to the
    local *User Interface Functions* and through the *ETMS
    Communications Functions* to the remote *User Interface Functions*.
    The flight data transactions contain data from the incoming messages
    along with processed flight data that is not directly available from
    the incoming messages, including the waypoints of the flight path
    and estimated departure and arrival times. The alert summaries
    contain summary demand and capacity values for all alerted airports,
    sectors, and fixes. The *Traffic Model Functions* provide flight and
    demand data to the *TM Functions*

    The *Traffic Model Functions* process commands and data requests
    entered by traffic managers through field‑site *User Interface
    Functions*. The commands allow a traffic manager to update
    capacities for any airport, sector, or fix; to update GA estimates
    for any airport; to change alert statuses; to update the schedule
    database; or to purge a ground delay program. The data requests
    allow a traffic manager to see existing capacities or GA estimates.
    (A traffic manager can cause the *User Interface Functions* to make
    demand data requests by requesting Monitor-Alert data and request
    reports.)

    ![](media/image1.wmf)

    **Figure B-3. Data Flow of the ETMS Hub Site Functions**

    *.*

The *TM Functions* implement controlled departure times determined by a
traffic manager at the ATCSCC by issuing control times to the NAS. The
*TM Functions* also apply changes to the control times issued by the
airlines according to traffic management policy. The *TM Functions*
receive EDCTs, FAs, and SIs from the *External Communication Functions*
and receive flight data and demand data from the *Traffic Model
Functions*. The *TM Functions* send flight control data, flight and
demand data requests, and cancellations to the *Traffic Model Functions*
and send SI replies and CTs to the *External Communications Functions*.
The *TM Functions* allow a manager to request control data and cancel
flight controls. The *ETMS Communications Functions* send TM commands
and data requests to the *TM Functions*, which in turn send back TM data
and replies.

[ETMS Field‑site Functions]{.underline}

The *ETMS Field‑site Functions* are organized in two groups as shown in
Figure B-4.

The *ETMS Communications Functions* perform all communications with the
Hub Site. All data available to the traffic manager through the *User
Interface Functions* are transmitted from the Hub Site through the *ETMS
Communications Functions*. The *ETMS Communications Functions* send all
data received from the Hub Site to the *User Interface Functions*, and
all data requests, updates, and TM commands received from the *User
Interface Functions* are sent to the Hub Site.

The *User Interface Functions* receive flight data transactions, alert
summaries, jet streams, radar tops, precipitation, and lightning data
automatically; i.e., the *User Interface Functions* do not request these
types of data. The *User Interface Functions* maintain these types of
data in tables at the Field Site and make them available to the traffic
manager through the *TSD* and other user interfaces. The *User Interface
Functions* request the remaining data from the Hub Site as needed to
support a traffic manager\'s data requests. The *User Interface
Functions* also use data from the following four static data sources
produced by the *Ancillary Support Functions*:

-   Maps database - geographical data used to draw map overlays on the
    *TSD* screen

-   Airports file - the name and location of each airport, used to
    *ghost* flights toward their final destinations

-   Codes file - many character codes (e.g., airport names, airline
    names, and aircraft designators) used to process requests for
    list/count reports

-   Arrival fixes - data used to associate arrival fixes with airports

    The *User Interface Functions* provide a variety of graphical and
    textual displays of the data. The *User Interface Functions* save
    replay files, which allow a traffic manager to replay traffic
    situation, weather, and alert data for the past. The *User Interface
    Functions* can support multiple traffic manager workstations at each
    site.

### [Traffic Model Functions]{.underline}

The *Traffic Model Functions* model the performance of flights; project
the traffic demands at all airports, sectors, and fixes of interest to
traffic management; and generate alerts for those

![](media/image1.wmf)

**Figure B-4. Data Flow of the ETMS Field-site Functions**

airports, sectors, or fixes whose demand exceeds capacity. The *Traffic
Model Functions* are shown in Figure B-5.*Parser* packages all
information extracted from the message and passes it to the *Flight
Database (FDB) Processor*, which uses the data to update the flight
databases.

A NAS amendment message (AF) may not contain sufficient data for the
*Parser* to produce an event list. For example, if an AF contains a
field 10 but not an aircraft type, a new event list cannot be produced.
In these cases, the *Parser* sends the data available in the AF to the
*FDB Processor* without an event list. *The FDB Processor* then looks up
the needed data in the flight database and sends it back to the
*Parser*. The *Parser* then models the flight, produces an event list,
and sends it back to the *FDB Processor*.

The *FDB Processor* maintains a database of all *active*, *proposed*,
*scheduled*, and *controlled* flights for the next 12 hours and previous
12 hours. The *FDB Processor* builds the flight database using the
information received from the *Parser* and the controlled departure
times and flight cancellations received from the *TM Functions*. The
*FDB Processor* also maintains a database of current and predicted grid
winds data extracted from the grid winds data received from the *Weather
Server*. The *FDB Processor* uses the flight data, the grid winds data,
departure ground times, and data from the aircraft dynamics database to
predict the event times for the flight. The *FDB Processor* re‑computes
a flight\'s event times whenever new data affecting the flight is
received. Projected (future) event times are updated to actual (past)
flight times as actual data is received in the NAS messages.

The *FDB Processor* sends update transactions containing flight events
and computed event times to the *Traffic Demands Database (TDB)
Processor*, which uses the data to update the traffic demands database.
The *FDB Processor* sends an update transaction whenever a flight\'s
events or event times change.

The *FDB Processor* sends flight data transactions containing data from
the parsed messages and computed data through the *ETMS Communication
Functions* to the Hub Site and Field Site *User Interface Functions*,
which use the data to update the local flight tables. The *FDB
Processor* sends flight data transactions automatically for each parsed
message received or as a reply to data requested by an *FTM*.

The *Parser* receives the NAS messages, OMP messages, and schedule
messages from the *External Communications Functions*, extracts the
contents of the messages, and converts the contents to the internal
format required for the subsequent processing. If a flight path (field
10) is contained in a message, the *Parser* interprets the flight path
using the geographical data from the grid database and flight profile
(i.e., ascent and descent) data from the aircraft dynamics database to
produce a detailed, three‑dimensional path for the flight. The internal
description of the flight path, known as an *event list*, includes all
events of interest to traffic management; i.e., airport arrivals and
departures, sector entries and exits, fix crossings, airway (i.e., jet
or Victor airway) entries and exits, and ARTCC entries and exits. The
*Parser* also uses the aircraft types file to determine the *user class*
(i.e., commercial, general aviation, military), *weight class* (i.e.,
small, large, heavy), and *aircraft type class* (e.g., single‑engine
piston prop) for the aircraft designator in the message. The

The *FDB Processor* sends data to *Store Flushed Flights (SFF)*, which
generates history files that are used to determine ground time
predictions. The *FDB Processor* also sends route messages (RT) back to
*NAS Distributor* for the *ASDI* process.

The *FDB Processor* sends flight data, either automatically or on
request, to the *TM Functions*, which use the data to apply controlled
departure times. The *FDB Processor* sends flight data automatically
when both a controlled departure time (CDT) and a flight plan (FZ) have
been received for a flight (causing a CT to be sent by the *TM
Functions*). The order in which the CDT and FZ are received does not
matter. The *FDB Processor* also sends flight data to the *TM Functions*
in response to a flight data request.

The *FDB Processor* also supports the *TM Functions* in the application
of Fuel Advisory messages (FAs). When the *TM Functions* receive an FA,
they send a transaction to the *FDB Processor* containing the controlled
airport and the controlled time periods. Upon receipt of a controlled
airport transaction, the *FDB Processor* sends a demand data request to
the *TDB Processor*, which returns an arrival list for the controlled
airport and times to the *TM Functions* (which apply fuel advisory
delays to any flights whose flight plans have already been received).
Flight plans received after this time are checked by the *FDB Processor*
to see if a fuel advisory delay should be applied to the flight. If so,
the *FDB Processor* sends a flight data transaction to the *TM
Functions*, which determine the amount of delay that should be applied
to the flight. The new controlled departure time for the flight is sent
back to the *FDB Processor* just as an EDCT would be. Normal EDCT
processing then continues in the *FDB Processor* and the *TM Functions.*

![](media/image1.wmf) Figure B-5. Data Flow of the Traffic Model
Functions

NOTE: The processing of fuel advisory delays is embedded in the *FDB
Processor* to ensure that the checking for existing flight plans and the
checking for new flight plans is completely synchronized*.*

The *TDB Processor* uses the update transactions from the *FDB
Processor* to maintain the predicted and actual traffic demands at each
monitored airport, sector, and fix. The *TDB Processor* keeps counts of
events for each element in 15‑minute intervals or *buckets*. The *TDB
Processor* also keeps the list of flights that comprise the demand in
each bucket. The *TDB Processor* keeps separate counts by flight status
(*scheduled, proposed, actual*) and can maintain demand data for 24
hours into the past and for up to 40 hours into the future.

When the *TDB Processor* updates a demand count, it checks the demand
against the capacity. If the capacity is exceeded by the active flight
count, the *TDB Processor* sets a flag, indicating a *red* alert for
that time interval. If the capacity is exceeded by the proposed flight
count, the *TDB Processor* sets a flag, indicating a *yellow* alert for
that time interval. Every five minutes, the *TDB Processor* scans all
the elements and generates alert summary files that contain the demand
counts for all alerted elements. The *TDB Processor* sends the alert
summary files to the local *ASP,* which distributes them to the Field
Sites.

The *TDB Processor* can receive alert status updates entered by traffic
managers at Field Sites. The *TDB Processor* first checks whether the
update is authorized. If the update is from the ATCSCC, it is always
authorized. Otherwise, the *TDB Processor* looks up the element
specified in the update in the element names file to find the ARTCC
associated with the updated element. The update is only allowed if it
was generated at the element\'s ARTCC or a TRACON within that ARTCC. If
an update is authorized, the *TDB Processor* sets the alert flag for the
specified time interval to *previously red* or *previously yellow*. Once
an alert status has been updated, the *TDB Processor* will not change it
back to its previous color regardless of changes in the demand count or
capacity value within that time interval. However, if the changes in the
demand counts or capacity cause a previously yellow alert to go red, the
alert status will be changed to red. After an alert status update is
processed, the *TDB Processor* generates a reply, which indicates that
the update was allowed or that an error was encountered.

The *TDB Processor* maintains *default* and *today\'s* capacity and GA
estimate values for each element by 15‑minute intervals. The default
values are pre‑defined and cannot be changed by the traffic manager. The
*TDB Processor* initially sets today\'s values to the default values
each day; it then changes them according to any capacity updates and GA
estimate updates received from traffic managers. The *TDB Processor*
checks the authorization of capacity and GA estimates updates in the
same manner as for alert status updates. The *TDB Processor* uses
today\'s capacities for determining alerts. When the *TDB Processor*
performs a capacity or GA estimate update, it generates a reply,
indicating either that the update was performed successfully or that an
error was encountered.

The *TDB Processor* processes requests for demand data, capacities, and
GA estimates. The demand data includes the demand counts, capacities, GA
estimates, list of flight IDs, and flight event times for the requested
element and time intervals. Capacity and GA estimate replies include
both the default and today\'s values for the requested element and time
intervals. Demand data requests for ARTCCs, airports, sectors, and fixes
are processed by the *TDB Processor*.

If a demand data request is for one or more ARTCCs, the *TDB Processor*
looks up all airports located within the ARTCC(s) and produces the
demand data for all those airports. An ARTCC demand data request may be
accompanied by one or more filtering ARTCCs. If so, the *TDB Processor*
assembles the demand data for the requested ARTCCs and passes the demand
data with the filtering ARTCC(s) to the *FDB Processor*. The *FDB
Processor* looks up each flight and keeps it only if it meets the
filtering criteria (for example, a flight in an arrival list is kept if
its departure airport is in a filtering ARTCC). The *FDB Processor*
sends the resultant, filtered set of demand data back to the requesting
site.

### B.3 Traffic Demand and Alert Processing

The ETMS uses the flight event data produced during the flight modeling
to estimate the *traffic demand* at each monitored airport, sector, and
fix, and to generate an *alert* whenever a traffic demand is projected
to exceed a pre-defined *alert threshol*d. Airport traffic demands are
defined as the number of arrivals and departures in a 15-minute
interval. Sector traffic demands are defined as the peak number of
aircraft in a sector at any one time during a 15-minute interval. Fix
traffic demands are defined as the number of fix crossings within a
certain altitude range during a 15-minute interval; the altitude ranges
used correspond to the altitude limits of the sectors that overlay the
fixes. Alert thresholds are defined in the same manner as the traffic
demands.

The ETMS computes the traffic demands from the flight event data
determined by the ETMS flight modeling based on the ETMS flight database
processing. The ETMS keeps a traffic demand database (TDB), which
contains the traffic demand count and alert threshold for each element,
event type, and 15-minute interval. When a projected demand exceeds a
threshold, the ETMS displays an alert for that element on the *TSD*. The
traffic manager can request data about the alert through the *TSD*; the
alert data includes a comparison of the demands and the alerts, and
flight lists for the alerted element.

This section consists of four parts: [Monitored Elements]{.underline}
describes the airports, sectors, and fixes that are monitored; [Traffic
Demand Processing]{.underline} describes the processing of the traffic
demand data; [Alert Thresholds]{.underline} describes the alert
thresholds; and [Alert Generation]{.underline} describes how the alerts
are generated.

### [Monitored Elements]{.underline}

The ETMS map database and grid database contain an enormous number of
airports, sectors, and fixes. Maintaining traffic demand counts and
lists for all known elements would require huge processing resources and
would be of questionable benefit. Instead, the ETMS maintains traffic
demand data only for elements determined to be of reasonable benefit to
traffic management. The *monitored elements* are specified in a manually
maintained list. The monitored elements list is generated according to
the criteria described below; however, elements can be added to or
deleted from the list according to direction from traffic management.

\(1\) Monitored Airports - The monitored airports consist of all U.S.
airports with *scheduled* flights, all Canadian and Mexican airports
with scheduled international flights, and several manually selected
international airports.

\(2\) Monitored Sectors - The ETMS monitors all sectors in the airspace
over the CONUS. The monitored sectors correspond to the sectors
displayed on the *TSD* in the low, high, and superhigh-sector, map
overlays. Oceanic sectors are not monitored.

\(3\) Monitored Fixes - The ETMS monitors all fixes defined by traffic
management as monitored fixes. They may or may not correspond to arrival
fixes. Furthermore, the monitored traffic for a fix consists only of
those flights whose flight path actually crosses the fix; that is,
arrival fix events are not passed to the TDB for inclusion in the fix
counts. The traffic for a fix is maintained in categories, which
correspond to the sector strata, which overlay the fix; that is, if a
fix has low, high, and superhigh sectors over it, it will have low,
high, and superhigh traffic counts. This is all borne out by the fact
that the manager can get low, high, and superhigh fix alerts but cannot
get an arrival fix alert.

### 

### 

### [Traffic Demand Processing]{.underline}

The ETMS maintains the traffic demand database so that it always
reflects the state of the data in the flight database. When the ETMS
adds a flight to the flight database (e.g., when an FZ is received), it
also adds it to the traffic demand database. When the ETMS updates a
flight in the flight database (e.g., when a DZ is received), the traffic
demand database is updated correspondingly. If a flight is cancelled in
the flight database (e.g., when an RZ is received), the flight is
removed from the traffic demand database. In every case, the information
(flight ID and status) needed to update the traffic demand database is
in the flight database or is produced by the ETMS flight modeling (the
element names, the event types, and the event times).

The ETMS maintains separate traffic demand counts for flights with
statuses of *schedule*d, *propose*d, and *activ*e. The ETMS determines
the appropriate count to update, for a flight, by examining the flight
status assigned in the flight database. The ETMS uses the separate
counts to distinguish alerts caused by flights in the air (active
flights) from alerts caused by flights in the air and on the ground
(scheduled and proposed); the *TSD* displays the former as red alerts
and the latter as yellow alerts.

The maintenance of the traffic demands for airports and fixes is the
most straightforward, since those demands consist simply of counts of
the flight events (arrivals, departures, and crossings) as they appear
in the event lists. When the ETMS adds a flight to the flight database,
it performs a separate *add* transaction for every airport and fix event
in the flight\'s event list. Similarly, when a flight is cancelled, the
ETMS performs separate *delete* transactions for each airport and fix
event. When the ETMS changes a flight status or updates a flight event
list, it performs a delete transaction for each previous airport and fix
event, and it performs an add transaction for each updated airport and
fix event.

Figure B-6 illustrates the processing for an add transaction of an
airport departure event for a proposed flight. The ETMS uses the element
type and name to look up the airport in the traffic demand database. The
ETMS computes the 15-minute interval into which the event falls from the
event time. The ETMS identifies the flight status as proposed and the
event type as a departure. Accordingly, the ETMS increments the proposed
departure count for the computed interval and inserts the flight into
the departure flight list for that interval (one flight list is
maintained for flights of all statuses). If the transaction type were
*delet*e, the same steps would be performed except that the count would
be decremented, and the flight would be removed from the flight list.
The fix demand processing is similar to the airport processing except
that instead of arrival and departure events, there are low, high, and
super-high crossings.

The maintenance of the sector traffic demands is more complex than for
airports and fixes because the sector demands (i.e., the peak numbers of
flights at any one time during an interval) are not just counts of the
sector events (i.e., sector entries and exits). To determine the peak
demands, the ETMS processes the sector events in pairs. When the ETMS
adds a flight to the flight database, it performs an add transaction for
the sector entry and exit pairs. When a flight is cancelled, the ETMS
performs a delete transaction for sector entry and exit pairs.

##### 

![](media/image2.png){width="5.28125in" height="3.995833333333333in"}

##### Figure B-6. Airport Demand Processing

When the ETMS updates a flight\'s event list, it performs a delete
transaction for each previous sector entry and exit pair and an add
transaction for each updated sector entry and exit pair. The ETMS
maintains separate demand counts by flight status for sectors as it does
for airports and fixes. Figure B-7 illustrates the processing of an add
transaction for a sector entry and exit pair for an active flight. The
ETMS initially processes the transaction as it does for the airport
transaction. The ETMS uses the element type and name to look up the
sector in the traffic demand database. The ETMS computes the 15-minute
interval into which the entry and exit events fall from the event times
and inserts the flight into the flight lists for those intervals.

At this point, the processing of the sector transaction departs
significantly from that of the airport. The sector traffic demand
database contains minute-by-minute counts of the number of flights in
the sector; a separate set of counts is maintained for each flight
status. In this example, the ETMS updates the active demand counts,
starting at the sector entry time (1201) and ending with the sector exit
time (1213). The ETMS then checks the updated active demand counts to
see if any exceed the previous active peak demand; if so, the active
peak is set to the new value. Similarly, the ETMS checks whether there
is a new *total* peak. The ETMS determines the total peak by summing the
scheduled, proposed, and active count for each minute, and by taking the
maximum of those sums.

######## 

**Figure B-7. Sector Demand Processing**![](media/image3.wmf)

A sector delete transaction is handled in a manner similar to an add,
but counts are decremented instead of incremented. The ETMS removes the
flight from the flight list, decrements the minute-by-minute demand
counts, and checks to see if any peak values should be reduced.

The example in Figure B-7 shows the case where the sector entry and exit
events are in the same interval, which is not always the case. When the
sector events happen in two different intervals, the ETMS computes the
entry and exit intervals. The ETMS inserts the flight into the flight
list for the entry and exit intervals and any intervals in between. As
before, the ETMS updates the

minute-by-minute demand counts from the entry time to the exit time. The
ETMS then checks the minute-by-minute demand counts against the peak
demands for each time interval involved, and updates the peak counts as
necessary.

[Alert Thresholds]{.underline}

An alert threshold is defined as the level of traffic demand required at
an element for it to be brought to the attention of a traffic manager.
The alert thresholds are sometimes referred to as the *capacities* of
the elements, but are not capacities in the classical sense. Alert
thresholds for an airport are defined by the numbers of arrivals and
departures in a 15-minute interval (two separate values). Alert
thresholds for a sector are defined by the number of aircraft in the
sector at any one time. Alert thresholds for a fix are defined by the
number of any low, high, or super-high flights (up to three separate
values) crossing the fix in each 15-minute interval.

The ETMS maintains two sets of alert thresholds for each element, event
type, and 15-minute interval: the *nominal* threshold and *today\'s*
threshold. The nominal thresholds are a set of default values, which are
stored in a manually maintained data file and read into the traffic
demand database. Each day, the ETMS uses the nominal thresholds to
initially set today\'s values. During the day, the ETMS uses today\'s
values to check traffic demands and generate alerts. Authorized traffic
managers can change today\'s by using the CAPS command available on the
*TSD*.

### [Alert Generation]{.underline}

The ETMS compares traffic demand values to alert thresholds every five
minutes to see if any alerts exist. The ETMS generates an alert if a
traffic demand exceeds an alert threshold for any 15-minute interval in
the next length of time as defined by the manager (up to nine hours).
For airports and fixes, the ETMS generates a red alert only if the
active demand exceeds the threshold; it generates a yellow alert if the
total demand (scheduled plus proposed plus active flights) is greater
than the threshold. For sectors, the ETMS generates a red alert only if
the active peak demand exceeds the threshold; it generates a yellow
alert if the total peak demand exceeds the threshold. A traffic manager
can alter the number of alerts displayed on his or her *TSD* by
specifying the desired element types, or by specifying a time range for
the alerts other than the one-hour default.

The ETMS also detects when alerted situations are relieved. If the
traffic demand is less than the alert threshold for an interval that was
previously alerted, the alert for that interval is disabled. When no
remaining intervals are alerted for a previously alerted element, that
element disappears from any *TSD* that is currently displaying alerts.

The ETMS also monitors whether alerts for specific 15-minute intervals
have been turned green by authorized traffic managers. When an
authorized manager has used the **Turn Green** command to indicate that
an alert is being resolved for a specific 15-minute interval, the
appropriate time bar interval changes color: from red to green with a
red horizontal stripe or from yellow to green with a yellow horizontal
stripe. The stripe indicates that there used to be an alert for the
element during that 15-minute interval. This allows the user to more
easily monitor that element.

If other 15-minute intervals shown on the time bar are still alerted,
the alert icon on the map will remain red or yellow. However, if all
alerted 15-minute intervals are turned green, the icon on the map will
also turn green.

Once a manager turns an alerted interval from red to green, the system
will not re-alert the element for that time interval, even if the
situation in that interval becomes much worse. Once a manager turns an
alerted interval from yellow to green, the system will re-alert the
element for that time interval if the traffic situation indicates a need
to upgrade to a red alert status. Also, if the Monitor-Alert bar charts
and text reports indicate that the situation has degraded, the manager
can choose to toggle off the **Turn Green** command to indicate that the
element should be monitored again. Afterwards, alerts could again be
generated for the interval.

The effects of the **Turn Green** command will appear immediately on the
*TSD* of the manager who issued the command. During the next
Monitor-Alert update, such effects will appear on all other *TSD*
displays at all ETMS sites.

APPENDIX C. CTAS PROCESSING OVERVIEW

Reference: CSC/E2-97/7169, CTAS Route Analyzer FD/TLD -- Draft, November
1997

CSC/E2-92/7170, CTAS Trajectory Synthesizer FD/TLD -- Final, October
1998

C.1 Introduction

CTAS provides automated tools for planning and controlling arrival air
traffic. CTAS generates air traffic advisories designed to increase fuel
efficiency, reduce delays, provide automation assistance to air traffic
controllers in achieving airport acceptance routes, and improve airport
capacity. CTAS accomplishes this without decreasing safety, or
increasing controller workload.

Twenty areas, approximately 400 miles across, comprise the airspace of
the 48 contiguous United States. These areas, known as Air Route Traffic
Control Centers (ARTCCs) or "Centers\'\', are further divided into
sectors. CTAS\' Traffic Management Advisor (TMA) helps ARTCC Traffic
Management Coordinator (TMC) to optimize the arrival traffic flow and
create a plan. The airspace within 40 miles of a major airport is known
as Terminal Radar Approach Controls (TRACONs). CTAS\' Final Approach
Spacing Tool (FAST) assists approach controllers to assign incoming
aircraft to runways, and to sequence and schedule aircraft onto the
final approach to the runway.

To accomplish its task, CTAS uses three main concepts: prediction,
control, and visualization. Prediction can only be done if necessary
information is present. CTAS\' Route Analyzer (RA) and Trajectory
Synthesizer (TS) are responsible for Estimated Time of Arrival (ETA)
generation based on weather condition, track data, and aircraft
information including the flight plan.

The RA computes the projected horizontal route that each aircraft will
follow. This information is then passed to TS.

**C.2 Functional Capabilities of RA**

The primary functional capabilities of the CTAS RA can be summarized as
follows:

-   The primary interpreter of CTAS expert-system decision trees

-   Generates ETA used by Dynamic Planner (DP), and sets up ETA
    iteration limits for Profile Selector (PFS)

For each eligible runway (determined by airport configuration) RA does
the following:

-   Uses flight plan, track, and decision trees to find analysis
    category

-   For each nominal route in category, for each Degree of Freedom (DOF)

    -   Modifies the route, speeds, and end-point conditions versus
        nominal

    -   Sends aircraft state information, route, and end conditions to
        TS

    -   Receives and processes four dimensional trajectories and flight
        times from TS

```{=html}
<!-- -->
```
-   Sends ETAs, routes, and trajectories to the Communications Manager
    (CM)

**C.3 RA Process Summary**

![](media/image4.wmf)The FAST and TMA depend on the accurate ETAs for
all aircraft. These arrival times are used by FAST and TMA for
sequencing and scheduling aircraft to the runway threshold. CTAS\' RA
and TS provide the rapid update and accurate calculation of ETAs based
on radar track and flight plan data. Figure C-1, Data Flow of the RA
Process, displays the input/output flow diagram of RA.

##### Figure C-1 Data Flow of the RA Process

The set of ETAs that the RA/TS computes represents ranges of possible
arrival times given an aircraft\'s predicted route of flight combined
with possible variations in DOFs along that route. Typical DOFs include
indicated airspeed and horizontal maneuvers. Upon receipt of a flight
plan, or radar track data update (x-coordinate, y-coordinate, altitude,
ground speed), the RA \"categorizes\" each aircraft\'s situation for
each potential landing runway in terms of destination airport, airport
configuration, geographical sections of airspace, engine type (jet,
turbo-prop, or piston), approach segment (downwind, final, base, etc.),
and aircraft states (x-coordinate, y-coordinate, altitude, heading,
speed). Each situation category has a name and a complete description of
route and DOF combinations that are possible for that aircraft. The RA
uses this site-adaptable data for each situational category to build a
series of one or more routes for each aircraft; applies DOFs to those
routes; and requests the TS to compute ETAs for each route and DOF
combination.

Inputs to the TS include the aircraft state, winds aloft, temperature
and pressure profiles, a series of waypoints depicting the expected
route of flight, and altitude and speed constraints along the predicted
route. Outputs from the TS include a complete time-based
(Four-Dimensional (4-D)) trajectory along the expected path, including
all data pertinent for resolving conflicts, and ETAs at points along the
path.

In the FAST environment, as the aircraft flies through the arrival
airspace and descends to the runway, it changes situation categories as
it transitions from one flight segment to the next, producing stable
sets of ETAs. These sets of ETAs form the basis for the sequencing and
scheduling process. Once the sequencing and scheduling process is
complete, the same set of RA/TS trajectories are used for conflict
resolution. Finally, they are used as a reference in computing expected
delay for aircraft in the runway allocation process.

Figure C-2 and C-3 show the relationship and data flow among CTAS
processes. Each entity shown in the figures has its own set of
responsibilities. The responsibilities can be summarized as follows:

-   CM - provides the communication and common database between each of
    the processes.

-   Host Data Acquisition and Router (HDAR) - serves as the interface
    between CTAS and the air traffic control facility\'s host computer.

-   Weather Data Acquisition Daemon (WDAD) - receives and process live
    weather information from the National Oceanic and Atmospheric
    Administration (NOAA), or the National Weather Service (NWS).

-   Timeline Graphical User Interface (TGUI) - receives input from and
    displays information to the TMCs.

-   Planview Graphical User Interface (PGUI) - receives input from and
    displays information to the controllers and TMCs.

```{=html}
<!-- -->
```
-   RA - computes the projected horizontal route that each aircraft
    follows. This information is passed to the TS.

-   TS - computes the ETAs and 4-D trajectories, including both the
    horizontal route and descent profile, for each aircraft.

```{=html}
<!-- -->
```
-   PFS - determines the runway assignment for each aircraft, computes
    the sequences and Scheduled Time of Arrivals (STA) to the Final
    Approach Fixes (FAF), and runway thresholds. DP - computes the
    runway assignment for each aircraft and computes the sequences and
    STAs to the outer meter arcs, meter fixes, FAFs, and runway
    thresholds

######## ![](media/image5.wmf){width="5.565277777777778in" height="7.625in"}

######## **Figure C-2 CTAS FAST Configuration** 

######## ![](media/image6.wmf){width="5.996527777777778in" height="7.8069444444444445in"}**Figure C-3 CTAS TMA Configuration** 

######## 

### C.4 TS Process Summary

The horizontal path and vertical segments are calculated for each
trajectory type (nominal, fast, slow and meet time). After the
horizontal path is determined, the vertical segments are built. Speeds
are calculated based on the type of trajectory being processed. Ascent,
cruise, or descent trajectory types (or all three) will dictate the
method(s) for determining speeds.

[Horizontal Path]{.underline}

The horizontal path is built to find an initial estimate of the path
distance. For Center trajectories, the estimate is calculated using
speeds and altitudes based on the 3::1 flight path angle (FPA). For
TRACON trajectories, the path distance is estimated using the TRACON
altitude profile (a mapping of path distances and corresponding
altitudes).

The initial values of the speed, altitude, and total path distance for
each waypoint are determined based on the input and default speeds in
different phases (climb, cruise, descent) of the trajectory.

Center trajectories are based on vertical shape, as well as speed. The
Center trajectory processing estimates top of ascent (TOA) and top of
descent (TOD) in addition to the speed, altitude, and distance. A
vertical shape is assigned to the trajectory according to the initial,
new cruise and final altitudes. Based upon the trajectory\'s vertical
shape, the TOA and TOD are estimated with a FPA that uses the 3::1 climb
rule of 3 NM / 1000 ft climb or descent rate.

TRACON trajectories use a one dimensional integration where only speed
is integrated and an altitude profile model is assumed. The bottom of
the center descent phase is an altitude that approximates the altitude
of the meter fix.

The total path distance of the trajectory is determined by adding the
path distances of the individual segments along the route. The path
distance of straight segments is calculated using the distance formula.
The path distance of turn segments can only be found after the turn is
created.

[Vertical Segment Strategy]{.underline}

The vertical path is built using the path distances found during the
computation of the horizontal path. The segments between the vertical
constraints are calculated and fused with previous segments until the
entire trajectory has been constructed.

.

Either the nominal trajectory or the meet time trajectory is calculated.
This is the second estimate of the path distance using the speeds
calculated during construction of the vertical path. The first path
distance estimate used speeds based on the 3::1 FPA.

The following is a legend for Figures C-2 and C-3.

4-D Four Dimensional

AC Aircraft

ARTS Automated Radar Terminal System

DADS Digital ARTS Display System

ETA Estimated Time of Arrival

FDAD Full Digital ARTS Display

HCS Host Computer System

HDAR Host Data Acquisition and Router

ISM Input Source Manager

NMC National Meteorological Center

PAMRI/E Peripheral Adapter Module Replacement Item Emulator

PAS Pseudo Aircraft Simulator

PGUI Plan-view Graphical User Interface

RA Route Analyzer

STA Scheduled Time of Arrival

TGUI Timeline Graphical User Interface

TIU Terminal Interface Unit

TS Trajectory Synthesizer

WDAD Weather Data Acquisition Daemon

WDPD Weather Data Processing Daemon