 |
|
 |
 |
 |
 |
 |
 |
|
+ Home |
 |
 |
 |
 |
 |
 |
 |
 |
|
||
 |
||
|
||
|
 |
|
|
|
|
 |
|
|
||
|
||
| Contents
Overview 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. + Back to Top CTAS Operational Context The figure below shows how CTAS as a system fits into the existing air traffic control infrastructure of the U.S. Each element is described in more detail below.  D 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. + Back to Top CTAS Software Processes 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. Communications Processes
Running the CTAS Tools The figure below shows all of the CTAS processes and their interconnections.  D 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. + Back to Top Process Descriptions 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:
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. Inputs:
For arrival aircraft only:
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. Inputs:
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. Inputs:
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
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. + Back to Top |
||
|
||
 |
+ Freedom of Information Act + Budgets, Strategic Plans and Accountability Reports + NASA Web Privacy Policy and Important Notices + Accessibility |
 |
Curator: NASA Official: Last Updated: October 13, 2016 + Contact Us + About This Site |
|
|||