This area of the website is intended to familiarize the reader with the CTAS software as implemented at NASA Ames Research Center; this version is known as the "Concept Development Software". Following this Overview is a description of how CTAS fits into the ATC infrastructure. Then, the individual executable processes that make up CTAS are described.
CTAS is comprised of multiple executable processes that communicate with each via messages sent using a TCP/IP socket protocol. The processes typically run on distributed workstations connected by a high-speed network. Running each CTAS tool implies invoking the processes required for that tool, each with the appropriate run-time options. Most processes are required for any of the tools, while some are required for only one or two of them. Similarly, much of the adaptation data, which is used to tailor the software to a particular site, is common to all of the tools, while each tool has some adaptation unique to it.
The majority of the CTAS software is implemented in the ANSI C language and runs under the Unix operating system. About 20% of the software is implemented in C++. The primary platform for CTAS is the Sun Microsystems Sparcstation, running Sun's Solaris 2.x operating system, which is compliant with the AT&T System V Release 4 (SVR4) version of Unix.
The graphical elements of CTAS are implemented using the X11R5 release of X-Windows; all of the CTAS GUI's use the Motif toolkit except for one, which was implemented using the Open-Windows toolkit.
CTAS relies on the description of the airspace provided in the FAA's Host computer adaptation data, known as Aces, and other national adaptation sources. These data specify waypoints, airways, airspace boundaries, airport and runway locations, expected aircraft types, and other parameters unique to a region, typically an ARTCC. These data are updated every 56 days. The data are formatted into files are intended especially for CTAS, and are read in by CTAS at start-up.
CTAS requires up-to-date weather information in order to generate accurate aircraft trajectories. Currently this data is provided by the National Meteorological Council (NMC), in the form of a 3-dimensional grid of wind, temperature, and pressure data based on a 1-, 2-, or 3-hour forecast generated by NOAA's Rapid-Update Cycle (RUC) processing.
CTAS requires real-time flight plan and track data for all aircraft of interest. For the Center tools TMA, and EDA/Direct-To, the aircraft data source is the Center Host computer. For FAST, both the TRACON ARTS computer and the Center Host computer data are used. During laboratory simulation, with controllers and pilots in-the-loop, the Ames-developed Pseudo-Aircraft Simulation tool provides the flight plan and track data.
During full operational use, TMA provides advisories to individual sector controllers via a two-way interface to the Host computer. The advisories consist of ETA's, STA's, and delay values for each aircraft. These data are shown in an alpha-numeric, ordered "linear" list on the controller's Planview Display (PVD). During two-way operations, the controller may make inputs via the PVD that are sent to and processed by CTAS. These inputs include, for example, a command to swap the order of two aircraft in the linear list.
Similarly, during full operational use, FAST sends advisories to the TRACON controllers' displays via a two-way interface. These advisories consist of runway assignment and landing sequence for each aircraft, and are displayed in the aircraft's flight data block on the controller's Fully Digital ARTS Display (FDAD). During two-way operations, controller inputs are sent to and processed by CTAS, for example, a command to override the CTAS-suggested runway assignment.
The individual processes that comprise CTAS each play one of three roles: communication, algorithm, or graphical-user interface (GUI). The communications processes manage the data into and out of CTAS and route messages among the processes. The algorithmic processes perform the prediction and automation functions. The GUI processes provide the interface for users and developers of the CTAS tools.
As stated previously, the CTAS tools (TMA, FAST, EDA/Direct-To, etc.) have most of their software in common. Each tool relies on running a certain combination of processes, in certain 'modes', to get the desired behavior. The processes required for each tool are described below, starting with a list of each CTAS process' short and full name. The links go to the more detailed process descriptions, which follow the figure describing how the processes are configured. The figure does not stand on its own but is meant to make the process descriptions more clear.
As indicated in the figure, the algorithmic processes are run in accordance with which tool is desired. DP, the Center scheduler, is run only for the TMA and EDA tools. The PFS/TS pair is only run for the FAST tool, and the PFS_C/TS pair is run for the Direct-To and EDA tools. The RA/TS pair is used for all the tools, and multiple RA/TS pairs may be run to speed up processing. Beyond the selection of which processes to run, there are also considerations of the mode of each process. When running TMA, the use of TRACON data via ADAR is optional; if it is desired, the ADAR is run in a one-way mode, delivering TRACON track data to TMA. When running FAST, the TRACON/ADAR connection is required, and it is a two-way connection. In this case, the HDAR connection is one way, delivering Center track data to FAST. ADAR is not generally used for Direct-To or EDA, but there is nothing to prevent it from being used.
Further, for each tool PGUI and TGUI are run in special tool-specific modes that enable some features while disabling others. For example, the Direct-To/EDA-mode PGUI has many features not available in the TMA or FAST modes. Multiple PGUI's and TGUI's may be run on a single CTAS system.
This section provides a summary of the functionalities of each CTAS process.
CM: Communications Manager
The CM, as its name implies, manages the communications among all of the CTAS processes shown connected to it in the figures above. The exceptions are ISM, which acts as a server to CM, and TS, which communicates via shared memory with its calling process. The other processes, namely, RA, PFS, PFS_C, DP, PGUI, and TGUI, are clients to CM and depend on it for their communications. CM does not have a direct connection to WDPD. Instead, CM periodically checks the rendezvous file that WDPD writes to see if a new weather file name has been posted there. If so, it begins the weather update process with the CTAS processes that need knowledge of the weather.
CM receives all of the aircraft tracks and flight plans sent by ISM, and distributes those data in a controlled manner to all the other processes. CM uses the aircraft data to create and maintain its own aircraft database; its clients depend on CM to know when an aircraft has been added to or deleted from CTAS.
CM is the intermediary for any message passed from one client process to another, and all messages pass through CM on their way to their intended destination. Often, a message sent by one process is intended for several processes, and CM manages the transmission of each message to all intended recipients. In fact, CM manages the connection and initialization of all the client processes. If those processes are started and cannot establish communication with CM, they are programmed to exit. Once connected, CM completes their initialization, including sending all current aircraft and airspace configuration information of interest in the form of messages. It is able to do this because, since it receives all transmitted messages, it is able to extract information from the messages in order to maintain key parameters in its aircraft database, as well as airspace variables. Then, if a new process is started, for example, a PGUI, CM is able to send it the latest information on each aircraft, along with any other global parameters that the PGUI needs in order to become current with the rest of the system.
Similarly, since CM receives all messages, it is able to record all data necessary for analysis and/or playback.
CM has a GUI that provides several categories of information to the user, as well as enabling key user inputs. The status information includes a panel showing all the aircraft in the system, their aircraft and flight plan types, their track status (tracked, coasting, planned, etc.), and their ETA status. For each aircraft, the user can bring up additional information such as the complete flight plan, current track data, and current ETA's.
The CM GUI permits the user to do the following: dynamically connect to and disconnect from all valid flight plan and track data sources, start and stop data recording or playback, initiate two-way communications with the Host, initiate use of live weather, configure the ground speed and vertical speed filters, specify which TGUI is in control of the DP, and create "fake" aircraft for testing purposes. Another panel allows the user to filter which aircraft are sent to which processes by flight plan type (e.g., arrival, departure, overflight, etc.). In addition, the CM GUI scrolling text window is used by the software to display important messages to the user.
ADAR: ARTS Data Acquisition and Routing
The ADAR process provides two-way communication between CTAS and the TRACON ARTS computer systems as required for FAST. Specifically, it is the process that operates between ISM and the TRACON 's ARTS Data Gatherer (ADG), which in turn communicates with the TRACON ARTS computer and FDAD displays. The ADAR provides aircraft track and flight plan data from the ARTS. It also transmits to ISM controller FDAD inputs of interest to FAST, such as runway assignment and missed approach commands. From ISM ADAR accepts the FAST runway assignment and sequence number for each aircraft and sends it on to the ADG for processing by the ARTS and display on the FDAD. The ADAR software is written and maintained by CSC.
HDAR: Host Data Acquisition and Routing
The HDAR process provides CTAS with critical aircraft data from the ARTCC Host computer. In addition, during operational use, HDAR sends CTAS-generated data back to the Host for display on the Center controllers' PVD's.
All data passed between HDAR and the rest of CTAS are in the form of messages. The messages received from the Host by HDAR and passed to the rest of CTAS include:
Flight Plans describing the aircraft type, route of flight, cruise altitude, cruise speed, and take-off time for each aircraft
The route as it is converted into individual waypoints by the Host, known as the "AK" route
Radar tracking data giving the position, altitude, and speed of all aircraft at 12 second intervals
Amendments to flight plans as they are entered by controllers into the Host
Deletion of flight plans
Controller commands to CTAS such as manual swap, aircraft resequence, and suspend/unsuspend messages
The HDAR also sends data back to the Host whenever CTAS TMA is being used in its operational "two-way" mode. The messages sent from CTAS to the Host during two-way operations include:
Aircraft STA's to the outer fix and meter fix, and current delay values
Various control and health checking messages
The HDAR is actually composed of several executable processes. The radar_daemon is the primary process for the functionality described above. In addition, for research and evaluation purposes, Host data is provided on dedicated serial lines to NASA Ames and other facilities. The radar_io_server process reads the serial line and converts the data into socket-based messages. For research purposes, a single radar_daemon can allow many CTAS systems to connect to it.
ISM: Input Source Manager
The ISM manages communication and data processing for the many sources of flight plan and track data that CTAS may receive, and passes any two-way messages back to the relevant data sources via the appropriate daemon. The purpose of ISM is to transform disparate data from multiple sources into source-independent messages, then send them to the CM for distribution to the other CTAS processes. In this way CM and all the other processes need not concern themselves with the source of the data. This applies in particular to flight plan and track data. In addition, HDAR and ADAR each send and receive unique message types to/from CTAS, and for those messages ISM simply passes the data through to CM. Another major purpose of ISM is to provide flexible merging of data sources. The data merging is critical for FAST, in which ARTCC/Host and TRACON/ARTS track and flight plan data are both required. ISM merges the data and handles the case of data from both sources being received for the same aircraft. ISM contains the logic required to identify uniquely an aircraft or flight for which data is being received from multiple sources. Finally, ISM performs track data filtering. In the case of the ground speed, ISM can either smooth the ground speed signal that comes from the source, or can generate its own signal based on position measurements. ISM also generates the aircraft course (heading) and vertical speed signals that the downstream processes require. ISM provides the ability to filter data sources individually and/or after two sources are merged.
Currently ISM is able to merge data from one ARTCC and one TRACON source. It is also able to process data from PAS, as if it were a Center source, and to merge PAS data with a single TRACON source. Some infrastructure has been developed to prepare for merging of multiple ARTCC's, however the precise requirements for this capability have not yet been established.
WDAD: Weather Data Acquisition Daemon
The WDAD process is a perl script that is responsible for gathering weather predictions from the Rapid Update Cycle (RUC) model produced at the National Centers for Environmental Prediction (NCEP) or other hosts and making them available on the CTAS network file system. The primary RUC data set used is the one hour forecast, which is generated approximately every hour. The data file from NCEP covers the entire continental US and some offshore areas. When a new file arrives and is successfully transferred to the designated file system, WDAD writes the new file name to a rendezvous file. WDPD polls the rendezvous file on a periodic basis, and when it is updated, WDPD begins its processing tasks on the data file named in the rendezvous file.
DP: Dynamic Planner
The DP performs the major automation function of TMA, namely, the scheduling of aircraft arriving to an airport. To perform its function, the DP requires flight plan and track data from the Host, ETA's to all eligible runways from the RA's, and scheduling constraints as input by the controller. The DP makes intensive use of site adaptation files that provide the scheduling and runway allocation rules for a particular airport. A complete description of the DP functionality is provided in the TMA section of this web site.
The DP was designed using the Object Modeling Technique, an object-oriented design method developed by Rumbaugh. The DP is implemented in the C language.
PFS: Profile Selector
The PFS performs the major automation function for FAST, namely, generating the runway assignment and sequence to that runway for each aircraft arriving at an airport. The runway allocation and sequencing are designed to maximize the efficiency of traffic flow without increasing controller workload. To perform its function, the PFS requires flight plan and track data from both the Center/Host and the TRACON/ARTS sources. It also requires the results of the RA analysis of all possible routes for an aircraft, which it uses to bound its search for the optimum solution. Like PFS_C and RA, the PFS utilizes the TS and its trajectory generation function, communicating with it via the shared memory interface. The PFS makes extensive use of site adaptation in the form of runway allocation rules and rules that specify how aircraft routes and speeds may be varied from their nominal values. A complete description of the PFS functionality is provided in the FAST section of this website.
PFS_C: Profile Selector - Center
The PFS_C performs functions required by the EDA and Direct-To tools. For Direct-To, it performs probing of all aircraft to identify those that can save significant amounts of flight time by going off of standard routes to follow shorter, more direct routes. It also identifies conflicts among aircraft on both the standard and direct routes, computing how likely the conflicts are to occur, where, and when. The Direct-To and conflict data are sent to PGUI for display. For EDA, PFS_C generates descent advisories for arrival aircraft to meet the schedules generated by the DP. In other words, given a desired time to arrive at the meter fix, PFS_C computes the aircraft's required cruise speed, where and when it should begin to descend, and its descent speed. The resulting ETA to the meter fix is a close as possible to the input STA. When being used for Direct-To only, PFS_C does not rely on having scheduled times as inputs, while they are required when running EDA. It is possible to use PFS_C for both Direct-To and EDA simultaneously, since the direct-to search and conflict probing functions are separate from the advisory generation function. Like RA and PFS, PFS_C uses TS extensively via the shared memory interface.
site adaptation data, especially analysis category information
flight plan and track data
RA analysis results in the form of an analysis packet
STA's from DP (if descent advisories are desired)
controller inputs from the PGUI
Processing (EDA and Direct-To in use):
For arrival aircraft only:
determines fast/slow ETA range based on RA analysis
sets desired meter fix arrival time equal to DP-generated STA
accepts any controller constraints entered via the PGUI
applies allowable degrees of freedom to iterate on trajectory until ETA meets STA within a tolerance
if DOF is within TS, TS iterates on various trajectory segments to meet time
if DOF is within PFS_C, PFS invokes TS with different iteration values until ETA meets STA
extracts advisory information from solution trajectories, including: cruise Mach/cas, descent Mach/cas, top-of-descent location, meter fix crossing altitude and speed, first turn location and heading
For ALL aircraft:
probes all non-arrival aircraft for possible direct-to routing
probes all aircraft trajectories for conflicts as defined by PGUI-input criteria
computes time and locationof initial loss-of-separation and minimum separation, and probability of conflict for all aircraft pairs that were predicted to be in conflict
can compute predicted minimum separation distance of one or more aircraft to a selected reference point (Spacing Tool)
sends 'advisory' ETA's and descent advisories for arrival aircraft to PGUI
sends direct-to list to PGUI
sends conflict list to PGUI
records various data files for analysis
RA: Route Analyzer
Like TS, RA is a fundamental algorithmic element for all of the CTAS tools. RA determines and generates all possible routes for an aircraft from its current position to its end point, in accordance with the site-adaptable analysis category decision tree. The analysis category is re-computed for every radar track update. Typical inputs into the determination of the category include aircraft category (arrival, departure, overflight), aircraft location, engine type, destination airport, and current runway being analyzed. Within each analysis category is defined a set of routes to fly, each having different degrees-of-freedom (DOF's). The DOF's can include such items as speed slowdown points and turn locations. For each of these routes, RA determines the ETA and other desired parameters at points of interest along the route. The ETA information is passed to the DP as the basis for scheduling, and to the GUI processes for display. A larger set of data, incorporating information about the degrees of freedom used to generate each ETA, is sent to PFS and PFS_C. This analysis packet sets up the ETA limits within which the solution must fall for each aircraft.
site-adaption data, especially the analysis category decision tree, which defines how to determine which category an aircraft falls in to, and for each category, all route and speed degrees-of-freedom that may be exercised to reach the destination
flight plan and track data
current airport configuration, specifying the runways in use
controller constraints entered from the GUI's
once per flight plan per aircraft, parses the route of flight into a linked list of route segments
for each eligible runway (or just once for non-arrivals), determines the analysis category of an aircraft based on flight plan, track, and controller inputs, using the analysis category decision tree
for each nominal route defined in the analysis category, for each degree of freedom:
modifies the nominal route, speeds, and end-point conditions versus the nominal
sends aircraft state info, route waypoints, and end-point conditions to TS
receives and processes end-point ETA set and 4D trajectory from TS
extracts intermediate ETA, distance, and ground speed information from 4D trajectory
sends ETA's to every eligible runway to DP and TGUI; ETA message includes fast, nominal, and slow ETA's to outer fix, meter fix, final approach fix, and runway threshold, and ground speeds at the meter fix and FAF.
sends analysis packets to PFS and PFS_C
sends a derived ETA message to CM for display, to support FAST
TS: Trajectory Synthesizer
TS is often referred to as the 'computational engine' of CTAS, because it provides the accurate 4-dimensional trajectories, and associated ETA's, that all of the CTAS tools depend on. The 4D trajectories are defined by aircraft x, y, altitude, and future time. The time of the last point in the trajectory is the ETA of the aircraft for that set of input parameters.
aircraft model data for all aircraft types to be processed, including aircraft aerodynamics, propulsion characteristics, and preferred speeds
site adaptation data, especially waypoint information
weather data from WDPD via CM and calling process (RA, PFS, PFS_C)
from the calling process, the aircraft initial condition, waypoints to be flown through, desired end conditions (altitude, airspeed, and location), and intermediate altitude and speed constraints
constructs a smooth horizontal path from the input waypoints, including turns
constructs a vertical profile using forward or backward integration along a series of discrete segments - result is the estimated time-to-fly
for Center arrival trajectories, computes fast and slow times to fly based on setting the cruise and descent speeds to the limits of the aircraft capability
for Center arrival trajectories, if requested, generates a trajectory that meets a desired arrival time
nominal, fast, slow, and meet-time ETA's
nominal 4D trajectory
The TS has a standalone capability in which single trajectory requests can be input and their results stored in text files. This is very useful for development and debugging of the TS software and the aircraft models. The TS has recently been redesigned in C++ using the Object Modeling Technique.
WDPD: Weather Data Processing Daemon
The WDPD is responsible for converting raw weather files provided by the WDAD into binary weather files usable by CTAS. Currently, WDPD processes 80km, 40km and 20km forecast files which are provided in the form of a Lambert conformal grid that covers the continental US. The grid data includes wind component speeds, temperature, and pressure as a function of latitude/longitude. WDPD extracts a site-adaptable section of the grid appropriate for the Center of interest, and converts the coordinate system of the data into the local Center x-y coordinate system. The resulting grid points are equally spaced along each of the 3 dimensions to allow for maximum computational efficiency in interpolating between grid points. Once the binary file has been successfully processed, WDPD writes the new filename to a rendezvous file. CM polls the file periodically, looking for a new file. Once a new file is found, CM then forwards the filename in a message to all processes having interest in the weather data, and manages the weather update process. An associated library provides functions and macros for clients to access the weather data efficiently and to get the desired data easily.
PGUI: Planview Graphical User Interface
The PGUI fills several distinct roles within CTAS, for several diverse customer groups. It
is used by Traffic Management Coordinators (TMC's) in the Traffic Management Unit during TMA and FAST operations, to provide a planview of the traffic situation, and also to display the CTAS advisories that are being sent to the controllers on the floor
is used by CTAS developers to display a wide variety of debugging information
is used by CTAS research teams to emulate an individual controller's station, for the purposes of simulating what would be seen on the operational floor
is used by CTAS research teams to prototype the computer-human interface for future systems intended for use on the operational floor
The PGUI performs all of these functions in both a Center and a TRACON environment. Start-up command line options and default files are used to configure the PGUI for the CTAS tool, user, and environment in which it will be used.
To support this diversity of uses with as much flexibility as possible, the software is both complex and very general. For example, the user may configure the aircraft "full data blocks" (FDB's), which are the tags associated with each aircraft track symbol, to have up to five lines of information, each line having two fields, each field being able to time share a number of items, and some items having color override capability. These items may all be adjusted during operation of the system. Therefore, the software to drive the FDB's is very general and makes no assumptions about what might be displayed in any situation.
The primary inputs to the PGUI are aircraft flight plan and track data; ETA's and STA's, runway assignments and sequence numbers (if PFS is running); descent advisories and/or conflict prediction and direct-to information (if PFS_C is running); responses to user requests, such as flight plan, RA or PFS routes to be displayed for a particular aircraft; developer-requested debugging information. The PGUI also receives and processes weather information, but only for the purpose of displaying it to the user.
The PGUI design philosophy is that it not do any algorithmic processing of data. Therefore, its outputs are limited to messages that result from user requests that must be forwarded to other processes. These outputs include requests for flight plan route display, flight plan amendments, emulation of controller inputs such as manual runway assignment, and aircraft altitude or speed clearance entries.
TGUI: Timeline Graphical User Interface
The TGUI is the TMC's primary interface to the TMA tool. The functionality of the TGUI is described fully in the TMA GUI portion of this website. In summary, TGUI provides the mechanism by which the TMC configures the TMA scheduler, and provides situational awareness to the TMC in the form of timeline, load graph, and textual data. In addition, the TGUI provides utilities for delay reporting, saving TMC's the chore of doing it manually. The TGUI is used to support development, and in particular provides a debugging interface to the DP.
Aside from user inputs, the primary CTAS messages utilized by TGUI are the ETA and STA messages, and messages that support delay reporting, such as meter-fix crossing events.