CM_srdd_rev10

Document Sample
CM_srdd_rev10 Powered By Docstoc
					CM SRDD                                                                                                          CSC/CFF-03/0065
April 2009

                                                          Table of Contents



SECTION 1.0 SCOPE .........................................................................................................................1
   1.1    Identification ......................................................................................................................1
   1.2    System Overview ...............................................................................................................1
     1.2.1     TMA Processing .........................................................................................................1
             Figure 1-1 TMA Functions...........................................................................................2
        1.2.1.1 TMA Software Architecture .................................................................................3
             Figure 1-2 TMA Software Architecture .....................................................................5
   1.3    Document Purpose and Overview ..................................................................................6
SECTION 2.0 REFERENCED DOCUMENTS ................................................................................7
   2.1    Applicable Documents......................................................................................................7
SECTION 3.0 Communications Manager Design..........................................................................8
   3.1    Communications Manager Overview ............................................................................8
     3.1.1     Reschedule Suppression .........................................................................................10
     3.1.2     Multiple Super Stream Class Deconfliction (EDC) .............................................10
     3.1.3     Multiple Meter Point Functionality ......................................................................11
        3.1.3.1 Cloned Flight Plans .............................................................................................11
        3.1.3.2 MMP Data Structures ..........................................................................................11
        3.1.3.3 Downstream Coordination Information ..........................................................12
        3.1.3.4 Messages ...............................................................................................................12
     3.1.4     Meter List Alternate Sequence ...............................................................................13
   3.2    Connection management ................................................................................................14
     3.2.1     The Application Table and Application Management .......................................14
     3.2.2     Application Type-to-Index Lookup Table ...........................................................18
     3.2.3     The SSA Table and Socket Management ..............................................................20
   3.3    The Aircraft Tree ..............................................................................................................21
   3.4    Fix Assignment ................................................................................................................23
   3.5    Flow Rate Change Lists ..................................................................................................24
   3.6    Blocked Interval List .......................................................................................................24
   3.7    Landed Aircraft List ........................................................................................................25
   3.8    Open Slot Processing.......................................................................................................25
     3.8.1     Open Slot Creation ..................................................................................................25
     3.8.2     Open Slot Scheduling ..............................................................................................27
     3.8.3     Open slot Deletion Determination ........................................................................28
   3.9    Data Source Configuration .............................................................................................29
   3.10 Messages ...........................................................................................................................31
   3.11 The CM GUI .....................................................................................................................34
   3.12 CM Startup and Initialization ........................................................................................36
     3.12.1 Log File Initialization ..............................................................................................37
     3.12.2 Initialize Weather Data ...........................................................................................37
     3.12.3 Initialize Data Recording ........................................................................................37
     3.12.4 Initial Command-Line Option Processing ...........................................................38
        3.12.4.1 Pre-Adaptation Command-Line Options........................................................38
     3.12.5 Attach to Shared-Memory Adaptation .................................................................39


                                                                    iii                                                               R10
CM SRDD                                                                                                    CSC/CFF-03/0065
April 2009

       3.12.6 Initialize Socket Connection and Applications ...................................................39
       3.12.7 Initialize M&C – CM Connection ..........................................................................39
       3.12.8 Initialize Center Information .................................................................................40
       3.12.9 Initialize SSC and MSSD Lists ...............................................................................40
       3.12.10     Reading Local (Read/Write) Adaptation .........................................................40
       3.12.11     Initialize Two-Way Communication and Metering Information Lists ........40
       3.12.12     Process Post Data File Command-Line Options .............................................41
       3.12.13     Process Panel Defaults ........................................................................................41
       3.12.14     Get Data Source Information .............................................................................41
       3.12.15     Motif Window Initialization ..............................................................................41
       3.12.16     Weather Processing Initialization......................................................................41
       3.12.17     Setting Control Times..........................................................................................41
       3.12.18     CM Initialization ..................................................................................................41
       3.12.19     Inform the M&C that CM has Initialized .........................................................43
       3.12.20     Enter the Main Processing Loop ........................................................................44
     3.13 The Main Processing Loop .............................................................................................44
       3.13.1 Socket Connection Processing ...............................................................................45
          3.13.1.1 Establishing the Listening Socket .....................................................................45
          3.13.1.2 Listening Socket Processing ..............................................................................47
          3.13.1.3 Application Socket Message Processing..........................................................47
          3.13.1.4 TRACON Switching ...........................................................................................49
          3.13.1.5 Handshaking .......................................................................................................50
       3.13.2 Updating and Distributing Aircraft Data.............................................................52
          3.13.2.1 Checking Radar Connection .............................................................................52
          3.13.2.2 Updating Weather Data .....................................................................................52
          3.13.2.3 Distributing New Flight Plans and Requesting ETAs ...................................54
          3.13.2.4 Checking For Runway Flow Changes .............................................................54
          3.13.2.5 Updating the Traffic Count ...............................................................................55
          3.13.2.6 Assigning RAs .....................................................................................................58
          3.13.2.7 Balancing RA Loads ...........................................................................................59
          3.13.2.8 Checking for Landed Aircraft ...........................................................................59
          3.13.2.9 Processing Hovering Aircraft ...........................................................................60
          3.13.2.10 Updating Active Aircraft (Track Processing) ...............................................60
          3.13.2.11 Processing Expired Open/Blocked Slots and Inactive Aircraft .................62
          3.13.2.12 Updating Aircraft ETA Status.........................................................................64
          3.13.2.13 Two-Way Communication and Meter Processing .......................................64
            3.13.2.13.1 Host Display Parameters ..........................................................................69
     3.14 Application Processing ...................................................................................................70
       3.14.1 RA Processing ..........................................................................................................70
          3.14.1.1 RA Connection and Initialization .....................................................................71
          3.14.1.2 RA Message Handling .......................................................................................72
          3.14.1.3 RA Connection Termination and Cleanup .....................................................77
       3.14.2 TGUI Processing ......................................................................................................77
          3.14.2.1 TGUI Connection and Initialization.................................................................77
          3.14.2.2 TGUI Message Handling ...................................................................................81
          3.14.2.3 TGUI Termination and Cleanup.......................................................................99
       3.14.3 PGUI Processing ......................................................................................................99


                                                               iv                                                              R10
CM SRDD                                                                                                      CSC/CFF-03/0065
April 2009

        3.14.3.1 PGUI Connection and Initialization...............................................................100
        3.14.3.2 PGUI Message Handling .................................................................................101
        3.14.3.3 PGUI Termination and Cleanup.....................................................................105
     3.14.4 DP Processing.........................................................................................................105
        3.14.4.1 DP Connection and Initialization ...................................................................106
        3.14.4.2 DP Message Handling .....................................................................................107
        3.14.4.3 DP Termination and Cleanup .........................................................................110
     3.14.5 ISM Processing .......................................................................................................110
        3.14.5.1 Flight Plan Categories and Category Determination ..................................110
        3.14.5.2 ISM Connection and Initialization .................................................................111
        3.14.5.3 ISM Message Handling ....................................................................................112
        3.14.5.4 ISM Termination and Cleanup .......................................................................120
     3.14.6 M&C Processing ....................................................................................................121
        3.14.6.1 M&C Connection and Initialization ...............................................................121
        3.14.6.2 M&C Message Handling .................................................................................121
     3.14.7 GUIR Processing ....................................................................................................126
        3.14.7.1 GUIR Connection and Initialization ..............................................................126
        3.14.7.2 GUIR Message Handling .................................................................................126
        3.14.7.3 GUIR Termination and Cleanup ....................................................................126
     3.14.8 WDPD Processing..................................................................................................126
        3.14.8.1 WDPD Connection and Initialization ............................................................126
        3.14.8.2 WDPD Message Handling ..............................................................................127
        3.14.8.3 WDPD Termination and Cleanup ..................................................................127
     3.14.9 CM Processing .......................................................................................................127
        3.14.9.1 CM Connection and Initialization ..................................................................127
        3.14.9.2 CM Message Handling ....................................................................................128
        3.14.9.3 CM Termination and Cleanup ........................................................................130
     3.14.10     SIP Processing ....................................................................................................130
     3.14.11     IDR Processing ...................................................................................................130
        3.14.11.1 IDR Connection and Initialization ...............................................................130
        3.14.11.2 IDR Message Handling ..................................................................................131
        3.14.11.3 IDR Termination and Cleanup .....................................................................133
     3.14.12     CAP Processing ..................................................................................................134
   3.15 Active Replication and Casualty Recovery ................................................................134
     3.15.1 CM Active Replication ..........................................................................................134
     3.15.2 CTAS Process Casualty Recovery .......................................................................135
        3.15.2.1 TGUI Recovery..................................................................................................137
        3.15.2.2 PGUI Recovery ..................................................................................................138
        3.15.2.3 ISM Recovery ....................................................................................................138
        3.15.2.4 DP Recovery ......................................................................................................139
        3.15.2.5 RA Recovery ......................................................................................................140
   3.16 CM Shutdown ................................................................................................................140
Appendix A CM Requirements ......................................................................................................141
Appendix B Acronyms ....................................................................................................................182
Appendix C: Aircraft Database Structures ...................................................................................185




                                                                  v                                                               R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


                                 SECTION 1.0 SCOPE

1.1     Identification
This Communications Manager (CM) Software Requirements/Design Document (SRDD) has
been prepared by Computer Sciences Corporation for the Federal Aviation Administration
(FAA) to satisfy the requirements of CDRL Sequence No. B020 under Delivery Order No.
0006 for CTAS TMA Software, Major Adaptation Maintenance, and Integrated Support,
under Contract No. DTFA03-02-D-00001, CTAS Free Flight Software and Adaptation
Development.

1.2     System Overview
TMA graphically depicts fix/arc crossing times of departure, overflight, and arrival aircraft,
and delays to be absorbed, on color workstations within the Traffic Management Unit
(TMU). When enabled by the Traffic Management Coordinator (TMC), this information is
displayed by the Host Computer System (HCS) in meter lists on the Air Route Traffic
Control Center (ARTCC) controller‟s Display System Replacement (DSR) console.

1.2.1 TMA Processing
The TMA processing function operates in the En Route environment. TMA produces an
arrival plan, which meets the flow requirements for an adapted airport.

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

As depicted in Figure 1-1, the functions within TMA are:
•     Aircraft Processing
•     Route Analysis
•     Estimated Times of Arrival (ETA) Generation
•     Scheduling

These functions use site-adaptable adaptation data.




                                             1                                          R10
CM SRDD                                                                                           CSC/CFF-03/0065
April 2009

                                                            Adjacent           Local Host
             WDPD                            ETMS                                                          TMC-GUI
                                                          ARTS or Host
                                                                                   HID


             Weather      A d ap ta t io n                 Flight Plans        Flight Plans   Controller      TMC
                              data                           & Tracks            & Tracks      entries
              data                                                                                           entries




                                                          Aircraft Processing
                                                          Initial meter point, or meter fix & runway


                                                               Route Analysis
                                                                          Routes


                                                              ETA Generation
                                                                           ETAs


                                                                   Scheduling
                                                     Meter List                         STAs,
                                                                                       Runways,
     All processes interact
          With M&C

                                             Local & Adjacent Hosts                  TMC-GUI



                                       Figure 1-1 TMA Functions

Adaptation and flight information are forwarded to the Collaborative Arrival Planner (CAP),
which converts the information to clients in XML format.

Based on the TMA converted route as derived from received Host flight plan data, the
current track, and winds aloft data, TMA makes continuous predictions of arrival aircraft
routes and ETAs for several locations: Runway Threshold, Final Approach Fix (FAF), Meter
Fix (MF) (CTAS and Scheduling), Meter Fix Arc (MFA), Outer Fix (OF), Outer Meter Arc
(OMA), Outer Outer Arc (OOA), Outer Three Arc (O3A), and Outer Four Arc (04A). The
ETAs are used by the scheduling function to determine the aircraft Scheduled Times of
Arrival (STAs).

TMA uses its En Route Departure Capability (EDC) to schedule flights at meter points. These
metering constructs are used to schedule overcrossing flights, departure flights destined for
external airports, and to extend the arrival metering horizon for the meter fix/runway.
Meter points also have optional, adaptable Outer Points, Outer Outer Points (OOP), Outer
Three Points (O3P), and Outer Four Points (O4P). Though named points, MPs, OPs, OOPs,
O3Ps, and O4Ps are arcs.

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



                                                      2                                                           R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



Scheduling is time-based. Miles-in-trail restrictions can be manually entered by the TMC. In-
Center and In-TRACON departures can also be scheduled.

After the scheduling is complete, the scheduled load to the TRACON and airport or meter
point(s) is displayed to the TMCs. ETAs and STAs are output to the TMCs. Additionally, if
time-based scheduling is in effect, the scheduling results, in the form of a meter list, can be
sent to local and adjacent Hosts for display.


1.2.1.1        TMA Software Architecture
Figure 1-2, TMA Software Architecture, depicts the software architecture for an ARTCC
configured with a scheduling CTAS. This depiction includes data sources external to TMA:
HADDS, local and adjacent Center Hosts, weather (CREWS), and TRACONs
(ARTSIIIA/IIIE, STARS).

The TMA architecture can contain three groups of software:

   A single core group that handles data collection and distribution.
   One or more TRACON groups, TRACON groups are per-TRACON processing suites
    that can be started and stopped independently of other TRACON groups. A TRACON
    group generates schedules for adapted arrival airports within the TRACON.
   Zero or one meter point groups. A meter point group schedules all meter point traffic (
    overflights and departing flights destined for external, adapted airports, and meter point
    traffic feeding an arrival TRACON).


The following list describes TMA process details.

       The HADDS Data Interface (HDIF) CSCI receives flight plan messages, including
        track update messages, from the local Host Computer System (HCS) via Host/ATM
        Data Distribution System (HADDS), and from Adjacent Centers if requested. HDIF
        performs rudimentary field range checking before it sends flight plans to the Input
        Source Manager (ISM) CSCI. For facilities so configured, the Multi-Metering Gateway
        (MMG) CSCI multiplexes several TMA-to-Host data streams using a single TMA
        string‟s identiy. MMG also demultiplexes the one-Host-to-TMA message stream so
        that messages go to the correct TMA string. This provides for adjacent Center
        metering.
       The ARTS Data Interface (ADIF) CSCI receives data from ARTS IIIE, ARTS IIIA, or
        STARS system.
       The ETMS Data Interface (EDIF) CSCI receives ETMS data, transforms and filters that
        data and forwards the data to ISM.
       The Input Source Manager (ISM) CSCI receives flight plans, information, and Host
        converted routes from HDIF, and also receives ARTS flight plans and tracking data
        from ADIF. ISM merges these multiple data streams into a single, unified data
        stream.



                                             3                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


       New flight plans, amendments, and radar tracks for active aircraft are routed through
        the Communications Manager (CM) CSCI to other TMA scheduling and display
        components. The CM CSCI formats this information into meter lists for
        communication to HDIF and local and adjacent HCSs for display. The primary CM
        (CMp) is mirrored by a backup (CMb).
       Flight trajectories, and Estimated Times of Arrival (ETAs) are constantly refined by
        the Route Analyzer (RA)/Trajectory Synthesizer (TS) CSCI pairs, providing input to
        the Dynamic Planner (DP) CSCI for aircraft STA calculation. A form of DP, known as
        Meter Point DP (MPDP) schedules non-arrivals to meter points. Integrated adaptation
        provides TMA with the data necessary for scheduling up to five adapted airports
        within a TRACON.
       The Weather Data Processing Daemon (WDPD) CSCI processes weather data and
        provides timely weather information to the TS and Planview Graphical User Interface
        (PGUI) CSCIs.
       The PGUI and Timeline GUI (TGUI) CSCIs provide graphical depictions airspace
        activity and aircraft metering to various reference points. The GUI Router (GUIR)
        CSCI multiplexes local airspace/metering information to remote T/PGUIs.
       The Collaborative Arrival Planning (CAP) server provides flight, configuration,
        status, scheduling, and adaptation data in XML format to clients.




                                            4                                          R10
CM SRDD                                             CSC/CFF-03/0065
April 2009




             Figure 1-2 TMA Software Architecture




                             5                                   R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009




1.3       Document Purpose and Overview
This document contains an overview of TMA processing, and contains a description of the
Communications Manager (CM) design.

This document contains the following sections:

         Section 1, Scope, provides an overview of TMA processing.

         Section 2, Referenced Documents, identifies the documents referenced in this SRDD.

         Section 3, Communications Manager Design, descibes the CM system: The data that
          flows through the system, messages, design, and processing.

         Appendix A, CM Requirements, lists CM requirements.

         Appendix B, Acronyms, describes the acronyms used in this document.

         Appendix C, Aircraft Database Structures, lists important CM data structures.




                                              6                                           R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009


                SECTION 2.0 REFERENCED DOCUMENTS

2.1     Applicable Documents
The following documents were used to prepare this SRDD.


Computer Sciences Corporation            Monitor     and   Control   (M&C)     Software
                                         Requirements/Design Document (SRDD) for Center-
                                         TRACON Automation System Workstation (CTAS)
                                         April, 2009

Federal Aviation Administration          System Specification, Traffic Management Advisor
                                         (TMA) FAA-E-2971, Rev N, December 2008




                                         7                                           R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


                  SECTION 3.0 Communications Manager Design

3.1      Communications Manager Overview
TMA processes can be divided into two categories:

     Processes that connect with external systems to receive flight data, and that provide those
      external systems with information computed from that flight data. An example of this
      process type is HDIF: it receives Center-origin flight data, and provides Centers with
      metering information via HADDS/MMG.
     Processes that use flight data to compute and display flight information, and send this
      flight information to external systems. Examples of this process type are PGUI, which
      provides a graphical display of an airspace, and DP, which computes STAs to various
      metering points.

CM occupies a unique position in this organization. CM receives all external flight data, and
distributes that data to the other TMA processes; and forwards metering information derived
from data received from those processes to the local primary HCS display and/or multiple
adjacent HCS displays.

CM is the communications hub and data manager for the other CTAS processes. CM
maintains all aircraft and system state data for use by the other CTAS processes. As data
arrives, CM gathers, processes, and distributes the data to the other CTAS processes. Some
data is maintained to support starting and initializing new processes with current data, and
for helping failed processes recover. Specifically, CM is responsible for the following tasks:

     Using adaptation data to initialize and configure the CTAS system
     Supervising socket connections with the other CTAS processes and acting as a message
      center for those processes
     Maintaining an up-to-date aircraft flight information database per processing group
      (TRACON and EDC)
     Distributing current flight information
     Maintaining system state information to send to newly connecting and reconnecting
      processes
     Distributing and managing aircraft among multiple RA instances
     Providing fix arc determinations (meter, outer, and outer-outer) based on the flight plan
      route and Host converted route data, and default runways based on the meter fix/arc
      selected.
     Providing ETA smoothing (averaging)
     Providing meter list and sector information to Host displays
     Keeping an aircraft traffic count for a prescribed time period spanning a prescribed past,
      and future time period, as well as a list of flight events and the time they occurred
     Data recording for analysis and playback
     Maintaining a backup CM for failure recovery, with actively-replicated aircraft and state
      data
     Maintains the latest copies of the TGUI/PGUI user‟s preference files, along with their
      creation and last access times.


                                               8                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


   Maintains both Estimated Departure Clearance Time (EDCT) and FAA coordination time.
   Performs meter point determination and assignment for departure flights (EDC/non-
    arrivals).
   Supports hard altitude amendment suppression. If adapted, CM flags flights when
    within a suppression zone - an adaptable altitude and distance from the meter fix. This
    flag is sent to DP and RA who use it to suppress these hard altitude amendments. Hard
    altitude suppression ranges are in the gates adaptation file.
   Stream class and route value determination. These determinations are provided to other
    CSCIs via the flight plan.
   Supports preserving vacated scheduling slots for resuse (open slot processing)
   In EDC mode, supports Multiple Super Stream Class Deconfliction (MSSD)
   Supports reschedule suppression (see below)
   Supports meter point (EDC) acceptance rates (current and future) for both MP/airport
    pairs and MP gate (groups)/airport pairs.
   Supports sending Meter List Alternate Sequence (MLAS) to the Host.

CM inputs are:

   Adaptation data to configure CM. CM attaches to per-TRACON/MP group adaption
    data contained in shared memory (read only), and reads in adaptation from files (read-
    write). This data denotes the specifics of an individual Center and of multiple TRACONS
    (including the MP group) within the Center, specifics of available adjacent Centers and a
    limited set of their attributes, as well as system defaults.
   Flight information (for example, flight plans and tracks) for all aircraft within the CTAS
    system. These arrive in the form of messages on socket connections.
   Weather information which arrives periodically to aid in calculating current aircraft
    information.
   Controller commands from the Host and TGUI/PGUIs.

CM outputs are:

   Aircraft traffic count data (arrivals only)
   Metering list data for display on HCS Sector Meter Lists and DSR consoles.

The following data structures are central to the CM design:

   The application table - Contains information about each connected application. CM keeps
    information on all applications in the application table. Each application‟s CM connection
    state can be either connected or disconnected.
   The aircraft tree – A flight database containing current flight information about each
    aircraft in the CTAS system.
   The Select Socket Array (SSA)- Contains all the socket connection information for each
    connected application, and is based on the non-blocking socket library. Entries in the SSA
    are used for creating socket select calls.




                                             9                                          R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


       Flow lists – Linked lists containing aircraft flow data (for example, meter fix, airport,
        super stream class). In EDC mode (non-arrivals), only super stream class flow lists are
        used.

Note that in the ongoing text the term application is synonymous with the term process. Also,
references to TRACON specific processing inclues the Meter Point Group, unless where
noted.

3.1.1 Reschedule Suppression
When a flight change causes a flight to be amended to a new MRP, TMA supports the ability
to suppress rescheduling qualified flights that are amended to qualified MRPs.

If processing is successful, reschedule-suppressed flights retain their original MRP STAs but
to the new MRP.

Reschedule suppression can occur when a flight is amended to another MRP (known as a
mirror MRP), and the following conditions are met:

       The flight is frozen
       Reschedule suppression is enabled
       The amended-to MRP is defined in adaptation as a mirror MRP for the flight's
        original MRP, and
       The flight is within the adapted reschedule suppression distance of the mirror MRP
       DP, finding no scheduling conflict with another flight, allows the existing STAs to the
        new MRP; otherwise DP rejects the flight

Reschedule suppression state default value is indicated in adaptation. This value can be
changed via the TGUI. Mirror MRPs and reschedule-suppression distances are indicated in
adaptation.

DP sends the TGUIs the results of reschedule-suppressed flight amendments: whether it
causes a conflict with another flight or not, and if so, the AID of the affected flight.

Adaptation defines mirror reference points and default reschedule-suppression status per
TRACON group.

3.1.2 Multiple Super Stream Class Deconfliction (EDC)
Previous to MSSD all aircraft that needed to be deconflicted at a single meter point had to be
combined into the same SSC, first come first serve (FCFS) order was to be maintained among
all flights, and a single MiT number was applied to all flights.

TMA provides MSSD for multiple SSCs over a common EDC meter point, while maintaining
FCFS within SSCs and preventing FCFS among SSCs, while maintaining individual SSC
MiTs and providing an intra-SSC MiT.

See the Dynamic Planner SRDD for more MSSD information.



                                             10                                           R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


3.1.3 Multiple Meter Point Functionality
The TMA Multiple Meter Point (MMP) capability extends the metering horizon for arrival
and en route aircraft, enhances intra-Center metering, and extends the functionality of both
the Multi-TRACON arrival TMA and EDC as described below.

For overflight and departure (EDC) traffic traversing a Center, MMP functionality allows for
multiple meter points located anywhere in Center or upstream of the Center (for example
adjacent Center arcs). Center departures may be scheduled to available slots in the overhead
en route traffic stream, and then continue through additional meter points before exiting a
Center‟s airspace.

For arrivals (TRACON), MMP provides additional upstream deconflicted metering locations
where arrival aircraft can be scheduled independently from the arrival TRACON. These
upstream points provide additional metering opportunities for controllers working arrival
traffic flows in a Center or adjacent Center. Traffic can be metered at any of the approaching
meter points in addition to the meter fixes and runways. Aircraft can be frozen relative to the
next meter point it approaches while still remaining unfrozen to further downstream meter
points. This reduces errors induced by a long freeze horizon. This is termed independent
freeze and can be applied to either arrival or en route aircraft.

Sector meter list data for each meter point can be selected for display on DSR sector lists.
EDC TGUI timelines can be configured to display aircraft scheduled to each adapted meter
point. Arrival TMA TGUIs can also be configured to display aircraft scheduled to each
adapted meter fix, runway, and arrival meter point.

Super stream classes may group one or more meter points, and super stream classes may be
grouped via MSSD. Aircraft belonging to a super stream class or MSSD group are
deconflicted independently from aircraft belonging to a different super stream class or MSSD
group. Scheduling is also independent between the arrival TMA and any upstream arrival
MPs. Scheduling parameters put into effect for the arrival TMA (for example, airport
acceptance rates, runway rates) affect only the arrival TMA scheduler. These rates are not
passed back to any additional meter points. As in EDC, traffic can be controlled by specifying
restrictions over each of the meter points.

3.1.3.1        Cloned Flight Plans
If a flight passes through both an EDC meter point and a TMA arrival meter fix then CM will
receive two flight plans for that flight, known as clones; if a flight‟s route goes through both a
MP and an arrival MF, then CM receives two unique flight plans. CM stores these clones in
separate, database trees for each processing group (TRACON or EDC). Each flight plan
contains the TRACON id of its clone (clone_traconid), if any.

3.1.3.2        MMP Data Structures
A cloned flight has an entry (Ac_st) in both the TRACON and EDC trees of the aircraft
database. Each entry contains a flight‟s assigned MPs/MF information stored in mp[] (see
Flight_plan_st). mp[0] is reserved for meter fix information, and the other entries used to
store meter point information, with mp[1] containing the most downstream meter point. For



                                              11                                           R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

those assigned MRPs, ETAs/STAs and other flight data are stored in mp_info[]; only meter
fix/arrival flight data is stored in the arrival tree flight entry, and likewise for the EDC tree.

3.1.3.3        Downstream Coordination Information
Downstream Coordination Information (DCI) is defined as the speed, altitude, x-y
coordinates and ETA at the final (that is, most downstream) meter point in an EDC group.

For all arrival aircraft, CM sends DCI for the final traversed MP to the arrival TRACON
processes. This information is used by RA, in lieu of flight plan and track information, for
computing downstream trajectories and ETAs.

The DOWNSTREAM_COORD_INFO message contains following information for a single
MP:
    x,y coordinates and altitude (received from AC_CROSSING_INFO message)
    Speed and ETA at the MP crossing (received in AIRCRAFT_ETA message)

A DOWNSTREAM_COORD_INFO message is sent to the arrival TRACON RA process in
the following conditions:

   CM receives an AIRCRAFT_ETA message for an arrival aircraft, and the MP in the ETA
    message is the most downstream MP for the flight (mp[1]). Altitude and x,y coordinates
    in the message are set to the current stored values (cm_ra_aircraft_eta()).

   CM receives a display point crossing time for the most downstream MP in the
    AC_CROSSING_TIME message. CM sends coordination information for this final
    traversed MP to RA. A last-message indicator is set indicating that the flight has crossed
    the final MP, and the crossing time is updated in corresponding aircraft mp_info[] entry
    (cm_ra_crossing_msg())

   If an arrival flight cloned, then a DOWNSTREAM_COORD_INFO message is sent in lieu
    of any ETA request.

   A delete is received from ISM for an EDC flight that has an arrival clone. CM sends a
    DOWNSTREAM_COORD_INFO message to the clone arrival TRACON RA process with
    last-message flag set to indicate that DOWNSTREAM_COORD_INFO message should no
    longer be used for coordination information. NOTE TO REVIEWERS: This IDR item
    appears to be obsolete, correct?

3.1.3.4        Messages
These messages contain information for a single fix:
      AC_CROSSING_INFO, AC_CROSSING_TIME
These messages contain information for multiple fixes:
      TMA_FREEZE_INSTRUCTION, TMA_RESET_AIRCRAFT
      AIRCRAFT_FIND_SLOT, SUSPEND_SCHEDULING,
      SCHEDULING_SUSPENDED, RESUME_SCHEDULING,
      SCHEDULING_RESUMED, PRIORITY_AIRCRAFT_RESCHEDULE



                                              12                                           R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009

        REMOVE_PRIORITY_AIRCRAFT, COMPUTE_SCHEDULE


3.1.4 Meter List Alternate Sequence
Due to differences in flight speed and delay assignment, upstream and downstream
metering arcs can display different aircraft sequences. TMA provides for sending alternate
metering lists to the Host-side displays that show the same sequence at both metering arcs.

If adapted, TMA provides the MRP type, STA, and delay values of a downstream metering
arc as alternate values for display on the Host meter list of any upstream MRP. This is done
while continuing to use the upstream MRP‟s meter list control parameters (display/drop
interval) and aircraft filtering during meter determination processing.

In short, a metering arc can take on a pseudonym, then take it‟s STAs from an upstream
metering arc, and computes a pseudo delay to go with that STA. This to keep the aircraft
sequence between those downstream and upstream metering arcs the same.

An alternate sequence list is defined by three things:

   Two adaptation options defined for MRP definitions in the meter_reference_points file.
    One option cannot be adapted without the other. These items are:
        o Pseudo-time type - A downstream MRP type, whose STA is to be used instead of
           the STA for the MRP being defined. The value must an MRP downstream of the
           MRP being defined. Valid values are DPT, OMA, OOA, or O3A.
        o Pseudo-name arc – A name associated with an outer arc (OMA, OOA, O3A, O4A)
           in the meter_reference_point file. This name is used in place of the actual MRP
           name being defined when sending an IM and IE message to the Host.
   A pseudo-delay time - If the upstream MRP and downstream MRP contain more than
    one level (that is, there is one or more intervening MRPs), the pseudo delay is the
    downstream MRP delay minus the sum of those AMDT values between those 2 MRPs. If
    the downstream MRP delay is negative, the pseudo-delay amount is the same negative
    value.

See the Adaptation ICD for complete pseudo-time type and pseudo-name arc descriptions.

When adapted to do so, CM does the following:

   In place of the actual arc name and meter time, CM to sends the pseudo-name arc and
    meter time of the adapted pseudo-time type to the Host within an IM message.

   Applies the appropriate arc AMDT value(s) when computing the pseudo-delay time to
    be sent to the Host within an IM message that contains a pseudo-name arc.

   Sends IM messages to the Host to update arc meter times, while using a pseudo-name
    arc, when the adapted (and upstream) MRP type meter time changes.




                                             13                                      R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


     Deletes pseudo arcs from the Host and sends a new IM with the actual MRP name, meter
      time, and meter delay time when aircraft is amended to an MRP assignment that is not
      adapted with a pseudo-arc name.

When an MRP meter time or meter delay time changes by the required amount to cause an
IM message send, CM determines if the MRP is metering to a pseudo-name arc. If not, CM
populates and sends the IM message normally. If a pseudo-name arc is used, the IM message
is not sent; in this case the IM message should only be sent to the Host when there is a
change to the adapted pseudo-time type‟s meter time or meter delay time.

Dynamic changes to AMDT settings can affect MRP arcs that are metering using pseudo
delay times. After processing the changes within a CTAS_AIRPORT_AMDT_CHANGE
message, CM determine if new meter IM messages need to be sent to the Host, and if so sets
the force_mrp_pseudo_to_host flag to true to subsequently force sending an IM message to
the Host.




3.2      Connection management
One of CM‟s primary tasks is maintaining and managing communication with many
processes. Along with the TMA processes previously mentioned, CM maintains a connection
with a backup CM (known as CMb); the primary CM (CMp) constantly keeps CMb updated.

CM communicates with other processes over non-blocking socket connections. CM
connection management software is based on the CTAS non-blocking socket library. The
application table (App[]), type-to-index table (T2i[]), and select socket array (SSA) each play a
part in managing these connections. These data structures are described in the following
sections.

3.2.1 The Application Table and Application Management
CM creates and maintains a table that contains information about each connected
application. Each application table slot contains an App_st structure which is defined as
follows:

         struct app_s
         {
             int               sockRef;                    /* socket reference       */
             int               idx;                        /* process index          */
             unsigned int      pif;                        /* p:16, i:8, f:8         */
             Ipc_proc_type     process_type;               /* PROC_CM, ...           */
             unsigned char     process_instance;           /* 1, 2, 3, ...           */
             unsigned char     process_facility;           /* 0, 1, 2, ...           */
             Protocol_state    protocol_state;             /* enum STATE_xxx         */
             unsigned char     protocol_type;              /* _UDS_PROTO, _TCP_PROTO */
             Message_fd_type   socket_type;                /* RA_SOCKET, ...         */
             service_type      service;                    /* 0=client, >0=server    */
             unsigned char     temporary;                  /* cm_app_tmp create flag */
             unsigned char     send;                       /* indx for multiple send */
             char              host_name[MAX_HOSTNAME_LEN];/* process on hostname    */
             char              tracon_id;                  /* Tracon identifier      */
             Bool_type         connect;               /* 0=not connected, 1=connected */



                                             14                                           R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

             App_st         *relay;                         /* relay process in use   */
             Proc_op_con_type op_con_type;                /* operational connection type */
             /*
              * End of cm_app control information
              */
             int                 sector;
             Area                area;
             client_wthr_status wthr_status;
             Bool_type           send_use_wthr_msg;           /*   Flag indicating whether to
                                                               *   send CTAS_USE_NEW_WTHR_FILE
                                                               *   message to PGUI or not */
             int                   wthr_msg_count;            /*   Increments for every "get"
                                                               *   msg sent and decrements for
                                                               *   every "ack" received */
             unsigned              dp_control;
             int                   mode;
             struct list_list      *sent_list;                 /* used only by DP        */
             struct list_list      *seq_constraints;           /* used only by DP        */
             App_st                *dp;                        /* used only by TGUI      */
        };

        typedef struct app_s App_st;

The App_st fields are defined as follows:

   sockRef – Reference to this application‟s non-blocking socket.
   idx – Index number into idx->ida[] table (see cm_app_idx_add()). Maintained to give a
    reconnecting application it‟s same slot in the index table.
   pif – A unique process instance identifier generated from the process type, instance, and
    facility:

        #define PIF(pt,pi,pf)      ((pt << 16) | (pi << 8) | pf)

    This field is used to differentiate different instances of the same application type.
   process_type – For example, PROC_RA (see global_includes/ctas_defs.h)
   process_instance – Received from M&C at startup, specifies the instance number of an
    application.
   process_facility – Facility where the application is running
   protocol_state – Describes the current state of the application‟s socket connection, which
    can be one of the following values:

        typedef enum
        {
        STATE_CLOSED = 0,        /*   no connection                                */
        STATE_CLOSING,           /*   process is in a closing down state           */
        STATE_MC_CONNECTING,     /*   connecting to M&C client (connect)           */
        STATE_ISM_CONNECTING,    /*   connecting to ISM client (connect)           */
        STATE_LISTENING,         /*   listening for connection requests            */
        STATE_CONNECTED,         /*   connection established (accept)              */
        STATE_DATAXFER           /*   rcved SEND_HOST_NAME, data transfer mode     */
        } Protocol_state;


   protocol_type – Specifies the client application‟s socket type:

        #define _TCP_PROTO 1       /* TCP communications */
        #define _UDS_PROTO 2       /* UNIX Domain SOCK_STREAM communications */


                                             15                                          R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



   socket_type – One of the following (defined in global_includes/ctas_defs.h):

        typedef enum {
            UNUSED_FD = 0,
            GUIR_SOCKET = 5,
            TRACON_TM_SOCKET = 10,
            CENTER_TM_SOCKET = 20,
            DP_SOCKET = 30,
            TRACON_PGUI_SOCKET = 60,
            CENTER_PGUI_SOCKET = 70,
            RA_SOCKET = 80,
            PS_SOCKET = 90,
            PFSA_SOCKET = 100,
            PEER_CM_SOCKET = 240,
            SIP_SOCKET = 250,
            NOAA_WDPD_SOCKET = 310,
            WDPD_CM_SOCKET = 330,
            IDR_SOCKET = 340,
            MUT_SOCKET = 360,
            ISM_SOCKET = 400
        } Message_fd_type;


   service – Indicates a CM server type. If set to 0, indicates a CM client (for example, RA,
    DP, TGUI). Services are define as follows (defined in global_includes/tfm_mc_msgs.h):

        typedef enum
        {
            NONE_SVC=0,
            DR_SVC,                 /*    data recording service */
            CM_SVC,                 /*    communications manager */
            ISM_SVC,                /*    input source manager */
            HDIF_SVC,               /*    host data interface */
            ADAR_OP_SVC,            /*    ADAR 2-way */
            ADAR_SUPP_SVC,          /*    ADAR support string */
            ADIF_SVC = ADAR_SUPP_SVC,     /* ADIF service */
            HADDS_SVC,              /*    HOST service */
            WEATHER_SVC,            /*    weather service */
            GUI_RTR_SVC,            /*    GUI router service */
            MC_SVC,                 /*    monitor & control */
            IDR_SVC,                /*    Internal Departures relay service */
            CAP_SVC,                /*    Collaborative Arrival Planner */
            XML_SVC,                /*    Extensible Markup Language */
            MAX_SERVICE_TYPE        /*    Number of service types */
        } service_type;


   temporary – Flag that is set when the application entry is for a temporary application.
    Temporary applications are those newly connecting applications whose process type is
    not yet know, and therefore are not yet fully connected. This facilitates reassigning a
    reconnecting process it‟s form slot.
   send – Flag to prevent sending multiple messages to a relay process (GUIR).
   hostname – Name of the host on which the application is running.
   tracon_id – Specifies the TRACON group for which the application (DP, RA, TGUI,
    PGUI, or GUIR) is connecting and expecting flight data. tracon_id is derived from the
    application‟s -data command line option and the site_id passed within the
    SEND_HOST_NAME message sent from the connecting process to CM.



                                            16                                         R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


   connect – Connection to CM state
   relay – If the application uses a relay application, this field contains a pointer to the relay
    application‟s entry in the application table (for example, remote TGUIs have this field set
    to the GUIR).
   sector – Contains airspace sector number (used by PGUI only).
   area – One of the following values (see global_includes/ctas_defs.h):

        enum Area
        {
            AREA_MASK_CLEAR         =   0,
            AREA_TRACON             =   1,
            AREA_CENTER             =   2,
            AREA_CENTER_TRACON      =   3,
            AREA_NONE               =   4,
        };


   wthr_status – defines the current weather status, and is one of the following values
    (cm_defs.h):

        typedef enum {
            CLIENT_WTHR_NO_USE = 0,          /* client doesn't use weather */
            CLIENT_WTHR_CURRENT,
            CLIENT_WTHR_UPDATE_ACK,
            CLIENT_WTHR_UPDATE_SENT,
            CLIENT_WTHR_UPDATE_FAILED,
            CLIENT_WTHR_REVERT_SENT,
            CLIENT_WTHR_REVERT_ACK,
            CLIENT_WTHR_REVERT_FAILED,
            CLIENT_WTHR_UNUSED,
            CLIENT_WTHR_NONE,
            CLIENT_WTHR_INIT_SENT,
            CLIENT_WTHR_INIT_ACK,
            CLIENT_WTHR_INIT_FAILED
        } client_wthr_status ;


   send_use_wthr_msg – a flag that indicates whether or not to send a
    CTAS_USE_NEW_WTHR_FILE message to a PGUI
   wthr_msg_count – Keeps count to prevent unnecessary weather message sends
   dp_control – Indicates whether the TGUI for this App_st can issue commands that affect
    scheduling (used by TGUI applications only)
   mode - Indicates the PGUI mode:

        typedef enum Pgui_mode_type
        {
            NO_MODE,
            FAST_MODE,
            FAST_MONITOR_MODE,
            DA_MODE,
            DA_MONITOR_MODE,
            TMA_MODE
        }
        Pgui_mode_type;




                                              17                                            R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009


   sent_list – Some CM-sent messages require a response. This list contains messages sent
    and still awaiting a response. Used for casualty recovery. Currently used by CM for
    resending TGUI messages not processed when a DP failure occurs.
   seq_constraints – Used by TGUI (for casualty recovery) to maintain sequence constraints
    send to DP.
   dp – Pointer to a TGUI‟s DP application entry.

The application table is declared as a static array of App_st structures:

        static App_st      App[APP_N + 1]

APP_N defines the number of application connections CM can support:

#define APP_N       ( MAX_MC_SOCKETS     +   MAX_RA_SOCKETS     +   MAX_DP_SOCKETS + \
                      MAX_PFSA_SOCKETS   +   MAX_PS_SOCKETS     +   MAX_ISM_SOCKETS + \
                      MAX_TGUI_SOCKETS   +   MAX_PGUI_SOCKETS   +   MAX_GUIR_SOCKETS + \
                      MAX_IDR_SOCKETS    +   MAX_MUT_SOCKETS    +   MAX_CAP_SOCKETS + 16)




Convenience pointers are used for accessing and looping through the application table:

        /*
         * The    first general purpose entry (Frst) is entry APPS_RESERVED.
         */
        static   App_st   *Frst = (App + APPS_RESERVED);
        static   App_st   *Last = (App + APP_N - 1);       /* last available entry           */
        static   App_st   *CmBack = 0;             /* pointer to Backup CM process           */

The first three entries in the application table are reserved for the listening socket, the backup
CM (CMb), and the M&C (cm_app.h):

        #define   APPS_RESERVED               3
        #define   APP_LISTENING_ENTRY         0     /* unused app, but same SSA index */
        #define   APP_PEER_CM_ENTRY           1
        #define   APP_MC_ENTRY                2

The file cm_app.c contains functions for accessing the application table.

At system startup, App[] is cleared in cm_app_ini() by a call to cm_app_clr() for each App[]
table entry.

3.2.2 Application Type-to-Index Lookup Table
Since a given TMA installation usually runs multiple instance of some processes, CM
maintains an additional table to enumerate processes of the same type (for example, all
TGUIs). The type-to-index (T2i) array contains a slot for each process type, and is defined as
follows:

        static Idx_st     *T2i[PROC_COUNT] = {0};       /* process_type -> idx handle       */




                                               18                                           R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

Each slot entry (Idx_st) defines the maximum number of process instances, actual number of
process instances, and an array of ida_t structures for each instance of that process type:

        struct idx_s
        {
            int             max;
            int             num;
            ida_t           ida[1];
        };
        typedef struct idx_s Idx_st;

Each ida_t in ida[] contains a pointer to an App_st in the application table for each process,
and an indication of whether the table entry is used:

        typedef struct
        {
            App_st             *app;
            char                used;
        } ida_t;

This is needed because when a process connection is lost, the application pointer is cleared.
At startup, T2i is initialized by cm_app_ini():

        T2i[PROC_MC]     =   cm_app_idx_new(MAX_MC_SOCKETS);
        T2i[PROC_RA]     =   cm_app_idx_new(MAX_RA_SOCKETS);
        T2i[PROC_DP]     =   cm_app_idx_new(MAX_DP_SOCKETS);
        T2i[PROC_CM]     =   cm_app_idx_new(MAX_CM_SOCKETS);
        T2i[PROC_PFS]    =   cm_app_idx_new(MAX_PS_SOCKETS);
        T2i[PROC_ISM]    =   cm_app_idx_new(MAX_ISM_SOCKETS);
        T2i[PROC_TGUI]   =   cm_app_idx_new(MAX_TM_SOCKETS);
        T2i[PROC_PGUI]   =   cm_app_idx_new(MAX_PGUI_SOCKETS);
        T2i[PROC_GUIR]   =   cm_app_idx_new(MAX_GUIR_SOCKETS);
        T2i[PROC_SIP]    =   cm_app_idx_new(MAX_SIP_SOCKETS);
        T2i[PROC_IDR]    =   cm_app_idx_new(MAX_IDR_SOCKETS);
        T2i[PROC_MUT]    =   cm_app_idx_new(MAX_MUT_SOCKETS);
        T2i[PROC_WDPD]   =   cm_app_idx_new(MAX_WDPD_SOCKETS);
        T2i[PROC_CAP]    =   cm_app_idx_new(MAX_CAP_SOCKETS);

When a new application moves from temporary to permanent, cm_app_new() calls
cm_app_idx_add():

        app->idx = cm_app_idx_add(T2i[process_type], app)

This function finds the next available slot in the Idx_st->ida[] table for the given process type,
sets that slot‟s App_st pointer to the application, sets the used status, and returns the index
number:

        cm_app_idx_add(Idx_st * idx, App_st * app)
        {
            int             i;

             for (i = 0; i < idx->max; i++)
             {
                 if (!idx->ida[i].used)
                 {
                     idx->ida[i].app = app;



                                              19                                           R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

                     idx->ida[i].used = 1;
                     idx->num++;
                     return (i);
                 }
             }
             return (-1);

If an application is reconnecting, then cm_app_idx_set() is called with the reconnecting
application‟s App_st->index:

        cm_app_idx_set(T2i[process_type], app->idx, app)

This puts the reconnecting application back in its previous slot:

        cm_app_idx_set(Idx_st * idx, int i, App_st * app)
        {
            idx->ida[i].app = app;
            idx->ida[i].used = 1;
            idx->num++;
        }

In this way processes are grouped by process type.

3.2.3 The SSA Table and Socket Management
CM receives messages over socket connections: either requests for new connections from
CTAS applications fielded over CM‟s listening socket, or data messages from those
applications after their socket connection has been successfully established. After first
making a connection request on CM‟s listening socket, CTAS applications then send a
SEND_HOST_NAME message to establish a permanent slot in the application table. Upon
receiving a SEND_HOST_NAME message, CM then

            Learns the identity of the connection process (PROC_ISM, PROC_TGUI, …)
            Creates a permanent entry in the application table for that application
             (cm_app_new())
            Create an entry in the type-to-index lookup table (cm_app_idx_add())
            Creates an entry in the socket table for that application (ssa_set())
            Informs the M&C about the successful connection

CM maintains the Select Socket Array (SSA) which contains structures holding information
about each socket connection. Each of these structures is in a format suitable for passing to
the non-blocking socket library select function. The file ssa.c contains socket management
functions for building and maintaining SSAs, and interfacing to the non-blocking socket
library. Note that there is a one-to-one correspondence entries in the App[] table and the
SSA.

The SSA management structure is defined as follows:

        typedef struct ssa_s ssa_t;
        struct ssa_s
        {
            int             ssa_N;          /* total entries in array       */



                                             20                                       R10
CM SRDD                                                                         CSC/CFF-03/0065
April 2009

              int               ssa_n;        /* highest used entry in array */
              int               ssa_b;        /* size of object in bytes     */
              selectSocketI     ssa_a[1];     /* entry array                */
        };

The ssa_a array contains the following structures from the non-blocking sockets library:

        typedef struct
        {
            int     sockRef;
            bool    writeReady;
            bool    readReady;
        }selectSocketI;

The SSA is accessed via these global pointers:

        int                SsaMain;        /* really ssa_t* */
        int                SsaTemp;        /* really ssa_t* */

At CM startup, cm_initialize() initializes the SSA via a call to ssa_new():

        SsaMain = ssa_new(cm_app_n());
        SsaTemp = ssa_new(cm_app_n());

This call allocates space for APP_N number of selectSocketI structures within the SSA
structures.

3.3     The Aircraft Tree
The aircraft tree contains flight plans and other flight information for each aircraft in the
CTAS system. The aircraft tree is a doubly-linked list designed to work with the standard
Unix twalk() functionality. It is searched and maintained using the C binary tree functions
twalk, tfind (returns entry or error), or tsearch (returns entry or a pointer to a new entry). See
the twalk man page for more information. Two structures define the aircraft tree: list_list and
list_link, defined in lib/list.h.

The list_list structure contains pointers to the first and last elements of the list:

        struct list_list
        {
                list_list         *p_next;     /* used by this module internally ONLY */
                list_link         *p_first     /* pointer to first link on list */
                list_link         *p_last;     /* pointer to last link on list */
        };

The list_link structure defines each link within the list:

        struct list_link
        {
                list_link        *p_next;     /*   pointer   to   next list element */
                list_link        *p_prev;     /*   pointer   to   previous list element */
                list_list        *p_parent;   /*   pointer   to   list containing this element */
                void             *p_data;     /*   pointer   to   client data */
        };




                                               21                                            R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

The aircraft tree contains Ac_st structures, organized by CTAS Enhanced ACID: The flight
aircraft identifier (ACID), followed by a /, followed by the departure airport, followed by a
„.‟, followed by CID padded four digits (for example, AAL123/DFW.0231). Each tree node‟s
data pointer (p_data) points to an Ac_st. Ac_st includes the following information:

       Aircraft flight plan and flight information
       Radar track information (aircraft state)
       ETAs
       STAs
       Internal departure flight information
       User constraints (entered via PGUI)
       Route information
       Overcrossing times
       Runway landed times
       Miscellaneous metering information

See Appendix C for a complete listing of the Ac_st.


The aircraft tree root pointer is defined in cm_common.h:

        struct Ac_st     *Cm_list_root [MAX_ARRIVAL_TRACONS]

Flights are maintained per TRACON group; each TRACON (including any EDC/meter point
group) has a separate tree. Flights that cross both a meter point (or more) and a meter fix arc
have their flight plans cloned and stored for each processing group.

As flight plans or updates are received from ISM, the aircraft tree is searched, and updated.
CM then disseminates this information to its clients (DP, RA, PGUI, …). CTAS applications
are kept current from this central database.

New nodes are added to the aircraft tree when a new flight plan arrives from ISM. When
cm_msg() receives a PROC_ISM message, it calls cm_ism_msg(). On receiving an
IC_FLIGHT_PLAN_ADD message, cm_ism_msg() calls ism_handle_fp_add().

ism_handle_fp_add() checks if the flight plan is already in the aircraft tree by calling
find_tree_ac().If the aircraft identifier is found, ism_handle_fp_add() considers the new flight
plan a duplicate, and returns. Processing for new flight plans proceeds as follows:

If the flight has a valid destination airport, and the message contains a Host converted route,
then the flight is added to the aircraft tree (add_flight_plan()), and the FID is assigned
(ism_flight_info_add_ak_route()). For arrivals, assign_meter_fix_from_tree() determines the
flights meter fix; for non-arrivals (EDC mode), the meter point arcs information is
determined if possible by determine_mp_arcs(). If the non-arrival flight does not cross an
adapted MP, then the ADD_FLIGHT_PLAN is sent to PGUI and RA only.

Finally, has_airport_changed() is called to update the airport destination if necessary.


                                             22                                            R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009



The add_flight_plan() function calls malloc() to create space for the new Ac_st, looks for the
new flight plan‟s aircraft identifier in the aircraft tree using tsearch() and ac_list_compare() to
compare the new Ac_st->state.id field with the same field in each Ac_st in the aircraft tree. If
this FP represents a new aircraft, then initialize_new_aircraft() is called to initialize Ac_st
fields to default settings (not done for open slots). This includes clearing ETA hovering fields
(update_aircraft_reset_hover_ac()). If the route10b field is empty, the flight plan route is
used; this covers non-ISM created flights. This also includes hard altitude suppression fields,
and sets the reschedule flag to true (that is, no reschedule suppression).

3.4      Fix Assignment
For flight plan adds and some amendments, CM performs meter fix/point assignment for
that flight.

For meter fixes, CM uses adaptation and information from the flight plan to assign a meter
fix (see assign_meter_fix_from_tree()). For meter points, CM uses following flight plan data
to determine any MP assignments:

     Converted route intersection with MP arcs
     Destination airport
     Engine type
     Assigned altitude

The determine_mp_arcs() function (see /lib) starts at the last waypoint in the converted
route, and determines if the route crosses any adapted MP in Ctas_gates[] for the given
destination airport and engine type.

CM attempts MP reassignment when any of the following change:

     Assigned altitude
     Engine type
     Destination airport
     Converted route.

If a MP is assigned the Outer Point (OP) and Outer-Outer Point (OOP) are set if adapted.

Since a Meter Point (MP) cannot always be determined from the converted route, processing
allows for an aircraft to have no FID assigned. For these flights, the ADD_FLIGHT_PLAN
message and subsequest amendments and ETA requests are sent to the RA and PGUI
processes only. (So flights without an FID are sent only to RA and PGUI).

If during MP reassignment:

     The flight did not previously have an assigned MP, an ADD_FLIGHT_PLAN message is
      subsequently sent.
     A new MP is assigned, and AMEND_FLIGHT_PLAN is subsequently sent.



                                              23                                            R10
CM SRDD                                                                        CSC/CFF-03/0065
April 2009


     A new MP cannot be assigned to a flight that previously had an assigned MP, then a
      DELETE_FLIGHT_PLAN message is subsequently generated. CM, RA, and PGUI will
      still know about the flight, but it will be deleted from TGUI timelines.

If the converted route is “same”, the MP does not change. If the converted route is “none”
and the flight previously had a MP assigned, a DELETE_FLIGHT_PLAN is generated and a
warning is sent to the M&C process.

Note: CM stores a flight plan status for each aircraft. This value is maintained for each
process (TGUI, DP, PGUI, RA), and indicates if the flight plan has been sent to the process, if
an ETA request has been sent, or if the flight plan was removed from the process (but CM
still has the aircraft in its database). This allows CM to keep track of the flight plan status on
a per-process basis and avoid resending messages or sending messages for an aircraft which
was never added. In some cases, such as when no MP is assigned, one process will received
the ADD_FLIGHT_PLAN and another process will not.

3.5      Flow Rate Change Lists
CM maintains various aircraft flow rate change lists to initialize newly starting or restarting
CTAS processes to the current state of the system. Flow rate changes associate times with an
aircraft flow rate over a given reference point. These include runway, airport, meter
fix/point, gate, super stream class, and TRACON flow rate changes.

Flow rate changes are made from the TGUI, which sends corresponding messages to CM.
CM reads the messages, processes the data in them using the functions in the
tma_flow_changes.c file, and forwards the messages to DP and back to the TGUI.

The flow rate change lists are declared in tma_flow_changes.c.

When a DP, TGUI, or PGUI process is started or restarted (casualty recovery), the
information      in      these   lists   is    sent   to the     new      process
(initial_synchronization_of_new_tma_or_dp_or_pgui()).

Note that only super stream class and meter point flow changes are used in EDC mode.

3.6      Blocked Interval List
The blocked interval list is defined in blocked_interval_changes.c. Blocked intervals are
created by the TGUI for either a runway or meter fix. Scheduling is affected by the creation of
blocked intervals since aircraft may not be scheduled to cross the indicated runway
thresholds or meter fixes during the specified time period.

At CM startup, initialize_system() initializes the blocked interval list by calling bi_initialize().

After receiving a BLOCKED_INTERVAL messages from TGUI, CM adds the blocked
interval to the list, and forwards the messages to all TGUIs and DP. The current list of
blocked intervals is sent by the CM to a new/restarted TGUI or scheduler as part of their
initialization.



                                               24                                            R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


3.7     Landed Aircraft List
CM maintains a landed aircraft list to assist starting/restarting DP, and for maintaining the
traffic count after aircraft have been removed from the aircraft tree due to deletes from ISM.

The landed aircraft list is defined in cm_recovery.c. The list is created at CM startup by a call
to rcv_create_landed_list(). Aircraft are added as they are reported landed, and removed
after a specified time period.

When a DP is started or restarted, the current landed aircraft list information is sent in the
form of an AIRCRAFT_LANDED message for each entry in the landed aircraft list so DP can
adjust its acceptance rate bins.

3.8     Open Slot Processing
In some circumstances when a frozen flight becomes ineligible for current the schedule, that
flight's scheduling slot is preserved for reuse. This slot is known as an open slot. An open slot
is a scheduling slot that is preserved for reuse when that scheduling slot has been vacated by
a flight.

Open slot creation causes are defined in the following structure:

typedef enum Sch_del_reason_type
{
    OS_UNUSED = 0,
    OS_REMOVE,          /* removed */
    OS_DIVERT,          /* diverted */
    OS_VFR              /* IFR to VFR */
} Sch_del_reason_type;

These reasons and their action are explained as follows:

Reason: CM receives a IC_FLIGHT_PLAN_DEL message from ISM as a result of a diversion
to an airport in a different TRACON group (OS_DIVERT).

Action: CM sends an ADD_FLIGHT_PLAN message for an open slot flight to
DP/TGUI/PGUI with the open_slot_reason field set to the value indicated in the new field
item reason within the IC_FLIGHT_PLAN_DEL message. A DELETE_FLIGHT_PLAN
message is then sent to all processes for the original flight.

Reasons: ISM amends the flight's destination airport to a different airport within the same
TRACON group, or ISM amends the flight's altitude status to VFR.

Action: CM sends an ADD_FLIGHT_PLAN for an open slot flight to DP/TGUI/PGUI. An
AMEND_FLIGHT_PLAN message is then sent to all processes for the original flight.

3.8.1 Open Slot Creation
On open slot creation CM does the following:




                                             25                                           R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009

Adds a new entry in the aircraft tree using the new open slot acid (aircraft callsign/OS_X)
and stores the following in the new open slot's Ac_st:

       A copy of the original flight's scheduling data. This data includes the STA values, the
        runway assignment, the manually scheduled status, and the priority status.

       The open slot creation reason and creation time. The creation_time is set to the
        current time. The creation_reason is set to the reason the open slot was created
        (based on the DELETE/AMEND from ISM). The possible reasons are defined in the
        enumerated type Sch_del_reason_type.

The following information is entered into the open slot flight plan:

       The first (ISM) entry of the flight plan‟s dsc_id[] array contains the newly created
        ACID of the open slot.

       The PROC_SLOT entry of the flight plan‟s dsc_id[] array contains the original aircraft
        id. This acid is used for display purposes as well as for copying data from the original
        flight to the new open slot flight.

       The flight plan‟s category field contains a new OPEN_SLOT type (added to
        enumerated type AC_fp_category).

       All other flight plan fields contain the values from the original flight plan.

CM sends an ADD_FLIGHT_PLAN message for the open slot flight to DP/PGUI/TGUI
containing the flight plan (as described above).

CM sends the OPEN_SLOT_SETTINGS message to TGUI only. The creation_time and
creation_reason fields are set in the "slot" structure within the message.

CM sends a SCHEDULE message for the open slot acid to TGUI/PGUI only, containing the
STAs of the original flight. The manually_scheduled field in the SCHEDULE message is set
to the current value for the original flight (stored in the Ac_st structure). If the original flight
is a manually scheduled flight, this status is retained so that the "m" is displayed for the open
slot.

If the original flight has priority status, then a PRIORITY_AIRCRAFT_RESCHEDULE
message is sent to TGUI for the open slot acid, so that the "PR" is displayed for the open slot.

CM will not consider open slot aircraft when determining traffic counts.

All PGUIs and TGUIs will provide an indication that the aircraft is an open slot. Details are
provided in the TMA Build 2 CHI Requirements Specification.




                                               26                                            R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

DP, upon receiving an ADD for an OPEN_SLOT category flight, copies the necessary data
from the original flight into the new open slot flight using the PROC_SLOT entry of the flight
plan dsc_id[] array (which indicates the original flight plan data).

3.8.2 Open Slot Scheduling
If the TGUI user selects a flight and places it in the open slot flight position, the following
values for the open slot are assigned to the selected flight:

   STAs
   Runway assignment
   Priority status
   Manually scheduled status

TGUI sends the TMC_SCHEDULE_AC_TO_SLOT message to CM. If the flight is an internal
departure, the int_dep_slot fields are set accordingly.

CM forwards the TMC_SCHEDULE_AC_TO_SLOT message to DP and places the new
message on the DP sent list.

DP sets the status field in the MSG_PROCESSED message based on whether scheduling over
the open slot is successful (Ac_slot_status_type). If there is an error, DP does not assign the
open slot STAs to the selected flight.

       If the selected flight (flight_id) is not in the same superstream class as the open slot
        (slot_id), and stream class validation is turned on, DP sets the status field in the
        MSG_PROCESSED message to AC_SLOT_FAIL_SUPERSTREAM. Scheduling over
        the open slot is not successful.

       If the selected flight (flight_id) is not in the same superstream class as the open slot
        (slot_id), and stream class validation is turned off, DP sets the status field in the
        MSG_PROCESSED message to AC_SLOT_WARN_SUPERSTREAM. Scheduling over
        the open slot is successful.

       If the slot_id is not found, DP sets the status field in the MSG_PROCESSED message
        to AC_SLOT_AC_NOT_FOUND. Scheduling over the open slot is not successful.

       If the flight_id is not found, DP sets the status field in the MSG_PROCESSED message
        to ACTIVE_AC_NOT_FOUND. Scheduling over the open slot is not successful.

DP   sends the MSG_PROCESSED                 message    to    CM indicating that the
TMC_SCHEDULE_AC_TO_SLOT message was processed. CM removes the corresponding
message from the "sent list", based on message type and acid.

If standard_open_slot_processing is turned on, DP will assign the runway and the STA times
for all fixes of the open slot to the selected flight verbatim, without adjusting the STA values




                                             27                                          R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

If standard_open_slot_processing is turned off (non-standard processing), STAs for the
selected flight are assigned based on the open slot STAs, using an enhanced STA
computation method. The computed STAs are assigned by apportioning delay along the
flight route.

TGUI determines if the open slot data tag and the selected flight data tag are both from
runway timelines, or if they are from any other combination of timelines.

If both flights are from runway timelines:
      The open slot runway and the runway STA are assigned to the selected flight.
      A runway delay is calculated based on the new runway STA and the selected flight's
        current runway ETA.
      The total runway delay is apportioned to the scheduling segments beginning with the
        TRACON area and going backwards along the flight route until all delay has been
        distributed.
If either flight is from a non-runway timeline:
      The "meter point level" is determined by the data tag that is selected from the timeline
        that is closest to the runway.
      The selected flight STAs at the meter point level will be assigned from the
        corresponding open slot STA values.
      The total delay at the meter point level will be computed based on the new STA at the
        meter point level and the flight?s current ETA at that meter point level.
      The total delay at that meter point level will be apportioned to the scheduling
        segment going backwards along the flight route until all delay has been distributed.
      All of the selected flight‟s downstream route segments will be assigned maximum
        delay.

When CM receives the MSG_PROCESSED message, the status field is checked to determine
if the STAs were updated successfully. If the status indicates a failure/warning, the
MSG_PROCESSED message is sent to TGUI indicating the failure/warning reason.

If the open slot assignment is successful, DP assigns the following values from the open slot
flight (slot_id) to the selected flight (flight_id):
      STA values
      Runway assignment
      Manually scheduled status
      Priority status

DP then sends a DELETE_FLIGHT_PLAN message to CM with the acid of the open slot.

When CM receives the DELETE_FLIGHT_PLAN message for the open slot acid, the delete is
forwarded to all other processes except RA.

3.8.3 Open slot Deletion Determination
Whenever an open slot flight is rescheduled as a result of a TMC rescheduling event or
manually scheduling an aircraft over the open slot, DP marks the open slot aircraft to be



                                            28                                          R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

ignored from all DP processing and generates and sends a DELETE_FLIGHT_PLAN
message to CM. CM forward the deletion message to all other processes, except RA,
including the originating DP, and CM removes the open slot aircraft from its database.

Whenever an open slot flight is suspended by the TMC from a TGUI, CM generates and
sends a DELETE_FLIGHT_PLAN message to all other processes, except RA, and CM
removes the open slot aircraft from its database.

For each processing loop cycle, CM evaluates whether the STA of any open slot aircraft has
become stale (that is, older than the current time). For an arrival TMA (non-EDC), the
runway STA is evaluated. For EDC, CM evaluates the meter point STA. For each open slot
aircraft determined by CM to be stale, CM generates and sends a DELETE_FLIGHT_PLAN
message to all other processes, except RA, and CM removes the open slot aircraft from its
database.

3.9       Data Source Configuration
Data source configuration (DSC) is a technique for keeping track of available flight data
sources within a given airspace. Data sources can include multiple Centers and TRACONs,
and ETMS, all connected via ISM. See the dsc_read_data_source_config_file() function and
g_data_source_list array (lib/data_source_config.c) for more information. Each data source
configuration is defined by the following structure:

struct DSC_data_source_config_t
{
    int                       index;               /* the index of this struct            */
    int                       count;               /* total number of structs             */
    DSC_data_source_id_t      data_source_id;      /* 3 char semi-official id             */
    DSC_data_source_sname_t data_source_sname;     /* 12 char short name                  */
    DSC_data_source_lname_t data_source_lname;     /* 80 char long name                   */
    DSC_computer_identifier_t    computer_identifier; /* 3 char Host id (ZCx)             */
    DSC_adaptation_identifier_t adaptation_identifier;/* adaptation name                  */
    char                      computer_prefix;     /* lower case 3rd char ZCx             */
    Ipc_proc_type             data_source_type;    /* arts, artcc, etms                   */
    DSC_mosaic_type_t         mosaic_type;         /* T, C1, C2, C3                       */
    CTAS_INET_hostname_t      hostname;            /* INET data source host               */
    CTAS_INET_service_t       service;             /* INET data source service            */
    double                    track_update_period; /* time exp. between tracks            */
    int                       track_timeout;       /* track time out value sec            */
    int                       track_priority;      /* track priority */
    Source_status_type        on_off;              /* online/offline status               */
    DSC_data_source_id_t      domain_id;           /* 3 char OARS domain id               */
    char                      traconid;            /* Tracon id number                    */
    void                      *user_data;          /* user data                           */
};
typedef struct DSC_data_source_config_t DSC_data_source_config_t;

The fields are described as follows:

         index and count indicate where in the list a particular is, and how many elements are
          in the list.

         data_source_id is the official FAA name for the facility the data source comes from.



                                               29                                         R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

        struct DSC_data_source_id_t
        {
            char s[DSC_SHORT_STR_SIZE];
        };
        typedef struct DSC_data_source_id_t DSC_data_source_id_t;

    However, some sources such as blocked slotes are not real facilities so the name might be
    made up and may differ from one site to another.

       data_source_sname is the short name for the facility suitable for use with data
        displayed on GUIs and in log files.

    struct DSC_data_source_sname_t
    {
        char s[DSC_MED_STR_SIZE];
    };
    typedef struct DSC_data_source_sname_t DSC_data_source_sname_t;


       data_source_lname is the long name for the facility suitable for use as titles on GUIs
        and in log files.

    struct DSC_data_source_lname_t
    {
        char s[DSC_LONG_STR_SIZE];
    };
    typedef struct DSC_data_source_lname_t DSC_data_source_lname_t;


       computer_identifier identifies the Host data source name.

       adaptation_identifier names the data source adaptation name.

       computer_prefix is computed from the computer_identifier and is used to distinguish
        between like-named waypoints in different airspaces.

       data_source_type describes the type of the data source (for example, PROC_HDIF,
        PROC_ADAR).

       mosaic_type indicates the relationship between each data source so that CM knows
        which data source to use when there is redundant data.

    enum DSC_mosaic_type_t
    {
        DSC_MT_UNKNOWN,
        DSC_MT_CTAS_ISM,         /* Input Source Manager            */
        DSC_MT_TRACON_PRIMARY,   /* FAST primary data source        */
        DSC_MT_CENTER_PRIMARY,   /* TMA primary data center         */
        DSC_MT_CENTER_SECONDARY, /* direct neighbors                */
        DSC_MT_CENTER_TERTIARY, /* ETMS                             */
        DSC_MT_PASS_THROUGH      /* Independent data source         */
    };
    typedef enum DSC_mosaic_type_t DSC_mosaic_type_t;




                                            30                                         R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


       hostname is the TCP/IP hostname. This hostname is the lowest priority default as it is
        overriddin by all other defaults or user value.

    struct CTAS_INET_hostname_t
    {
        char s[80];
    };
    typedef struct CTAS_INET_hostname_t CTAS_INET_hostname_t;


       service is the TCP/IP service/port number. As with hostname, this is the lowest
        priority default, and is over-ridden by other defaults or user values.

    struct CTAS_INET_service_t
    {
        char s[80];
    };
    typedef struct CTAS_INET_service_t CTAS_INET_service_t;


       track_update_period is the expected time between track updates. This is used to
        determine the CM main loop update rate. This rate depends on what sources are
        connected. CM always uses the fastest update cycle.
       track_timeout is used by ISM to determine which data source to use when ISM is
        receiving track data for a flight from two or more sources.

       track_priority is used by ISM to determine when a data source is no longer tracking a
        flight.

       on_off is not in the data file, but like index and count, provided for convenience of the
        application to track whether or not this entry is currently on-line or off-line. The
        default is SOURCE_STATUS_OFFLINE.

    enum Source_status_type
    {
        SOURCE_STATUS_ONLINE,
        SOURCE_STATUS_OFFLINE,
        SOURCE_STATUS_NO_DATA
    };
    typedef enum Source_status_type Source_status_type;


   domain_id specifies the three-character Offline Application Registration Service (OARS)
    identifier for each possible (local and adjacent) Center data source.

       user_data is a pointer to a user data struct. The default is NULL. The main reason for
        this is that it allows the user to attach data to this struct without modifying the struct.
        The could be useful for testing or eliminating global variables by passing the value
        here. No specific use has been defined, but often one would like to pass user data to
        tsearch() and qsort(), but can't. This eliminates that problem.

The DSC list is defined lib/data_source_config.h.

3.10 Messages

                                              31                                            R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009

Each type of message CM handles contains a message header, defined as follows:

        typedef struct
        {
            int                   msg_len;        /* message length */
            Ipc_msg_type          msg_type;       /* message type, short_t */

             Ipc_proc_type        src_process;    /* source process, char_t */
             Ipc_proc_type        dst_process;    /* destination process, char_t */
             Ipc_proc_type        org_process;    /* originator process, char_t */

             uchar_t              src_instance;   /* source instance */
             uchar_t              src_facility;   /* source facility */
             uchar_t              src_dscindex;   /* data source config index */

             uchar_t              dst_instance;   /* destination instance */
             uchar_t              dst_facility;   /* destination facility */

             uchar_t              org_instance;   /* originator instance */
             uchar_t              org_facility;   /* originator facility */

             ushort_t             org_sequence;   /* originator sequence number */


             char                 dst_traconid;   /* specific tracon identifier */

             /*
              * Structure padding added to support even boundary access
              * used by compiler but unsupported in all software code. If
              * padding is not included parts of the software will experience
              * a bus error core dump. The problem presents itself in
              * structures that contain other structures. The compiler aligns
              * structures following other structures on even boundaries.
              * The use of sizeof operations to advance past a structure to
              * the next will cause access problems in the cases where the
              * compiler added padding since the sizeof operation doesn't
              * account for padding between structures; only padding in the
              * structure being sizeof'ed. This structure currently must be
              * evenly divisible by 4 but not by 8. manders1
              */
             uchar_t            spb1;
        }        msg_hdr_st;

All CTAS messages are defined with msg_hdr_st as the first field in the message. For
example, the AMEND_FLIGHT_INFO message is defined as follows:

        typedef struct amend_flight_info_st
        {
            msg_hdr_st                  msg_hdr;
            char                        acid[ID_LENGTH];
            Flight_info_amendment_bit   amend_flight_info_msgs;
            CTAS_flight_info_st         amended_flight_info;

        } amend_flight_info_st;

The message header‟s ipc_msg_type field is an enumeration whose value maps message
types to their corresponding C message structures. CM message processing examines
msg_hdr_st->msg_type to determine the type of message received. This value, combined




                                          32                                       R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

with which process sent the message (msg_hdr_st->src_process) determines how CM
processes received messages.

The file cm_com.c contains lower-level functions to facilitate message processing.

If the message to be sent is a TRACON message type, and the destination process is a
TRACON group process, and the destination process‟s TRACON identifier does not match
the current TRACON indentifier in use, then the message is not written to the destination
process (cm_com_write_app()).

Messages are sent to the correct TRACON group CSCI(s) by setting the destination TRACON
identifier as follows (cm_com_header_app()):

   If the destination process is CAP (a non-TRACON related process) and the message being
    sent is a TRACON-related message (see cm_app_tracon_message_type()), assign message
    the current TRACON identifier.

   For TRACON-specific CSCIs that are being sent a TRACON-related message, assign the
    TRACON identifier of the current TRACON group to the message header.

   For TRACON-specific CSCIs that are being sent a non-TRACON related message (Center
    information) assign the destination CSCI‟s TRACON identifier (stored within the app_st)
    to the message header.

   CSCIs that are not specific to a TRACON assign zero to the message header, for data
    recording purposes.

The function cm_com_write_pt() uses the type-to-index table (T2i[]) to broadcast messages to
all processes of a type (for example, all TGUIs). The arguments passed to cm_com_write_pt()
are:

       Process type
       Message to be sent
       Size of the message
       Process type to be put in message destination
       Iteration count for GUIR multi-message elimination

The cm_com_write_pt() function broadcasts the message as follows:

   Retrieves a pointer to the process type idx_st (cm_app_t2i())
   Retrieves maximum number of index entries(idx->max, via cm_app_idx_max())
   Loops through from 1 to max entries:
        Retrieves the nth app pointer (cm_app_idx_i2a())
        Retrieves this app‟s process instance number (app->process_instance via
           cm_app_process_instance())




                                            33                                         R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009


            Determine if the applications TRACON identifier matches the current TRACON
             identifier. If a match, proceed; otherwise return.
            Determines if there is a relay application (app->relay via cm_app_relay()). If there
             is a relay (GUIR) then
                   Check to see if the relay applications app->send equals the passed in and
                      incremented Send global static. If equal go back to top of loop (the next
                      application instance). If not equal, set relay->send to passed in Send value,
                      set the message pt type to that passed in (destination process type), and
                      process instance to 0.
            Calls cm_com_header_pt() to fill in the message header for a message that is
             destined for one or more applications of a specified type
            Calls cm_com_write() to writes the message to the socket associated with the
             input application

The file cm_snd.c contains higher-level message sending functions, built on the functions in
cm_com.c, for sending messages to all processes of a specific type. For example,
cm_snd_tgui() uses cm_com_write_pt() to write a message to all TGUI instances.

3.11 The CM GUI
The CM Graphical User Interface is a set of Motif windows used to control and observe
various aspects of CM and CTAS operation. CM can run without its GUI.

User‟s can do the following via the CM GUI:
 Specify which TGUI process has the ability to change DP settings
 Allow the user to filter which aircraft are sent to which processes by flight plan type (for
   example, arrival, departure, overflight, etc.)
 Switch between live, default, and user-defined weather files
 When running in Developer mode, -R CM command line option, allows user to
   enable/disable Two Way communications and turn on/off Metering for the primary
   Host center and all Two Way adjacent Host centers from the <F3> “Two Way & Metering
   Options” panel. However, this is not recommended when using CM in an Operational
   environment.

In addition, the CM GUI scrolling text window is used by the software to display important
messages to the user.

Figure 3-1 shows the Developmental mode CM GUI main window, CM started using the –R
command line option.




                                               34                                           R10
CM SRDD                                                           CSC/CFF-03/0065
April 2009




                Figure 3-1. Developmental mode CM GUI Main Window

Pressing keyboard function keys (F1 – F12) windows displays other CM GUI windows. For
example, pressing F1 displays the Aircraft Status window, shown in figure 3-2.




                                        35                                     R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009




                            Figure 3-2. CM Aircraft Status Window

The Aircraft Status displays a list of all known aircraft/flight plans in the system. This list
shows the aircraft ID, flight type, aircraft type, and current status of each known aircraft. By
dwelling the cursor over an aircraft in the Aircraft Status display and pressing the „w‟ key, an
Aircraft Watch Window for that aircraft is displayed. This window contains detailed flight
information for that aircraft.

Other CM GUI windows include the following:

   Weather Input (F2) - This panel lets the user specify a weather source.
   Categories and Tracks Panel (F11) – This window displays total aircraft and the number
    of tracks sent for each flight plan category, and the total number of tracks sent to PGUI,
    DP/TGUI, and RA processes. This window also lets the user specify the which flight plan
    categories get sent to which processes.
   Help Options (F12) – Displays a list of function keys and the CM GUI windows they
    display when pressed. Also lists aircraft status color codes. See this window for a full list
    of CM GUI windows.

3.12 CM Startup and Initialization
The following sections describe, in sequence, the actions CM takes on startup.



                                             36                                           R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009



3.12.1 Log File Initialization
At startup, CM initializes log structures for logging debugging information (.dbg), and TMA
messages (.msg). Debugging files are ASCII; message files are binary.

The lib/ctas_file_initialize() function initializes the specified log file characteristics structure
(log_st). Because this function is called prior to the first write to the file, the file descriptor
(fd) is initialized to -1. Because this function is called prior to receiving an
APP_CONTROL_RECORDING message from M&C, the recording_state is set to
RECORD_OFF.

The process name (for example, ISM, CM, etc.) and file extension (for example, .msg, . .dbg,
etc.) are stored in the log_st for use by the ctas_file_open() function. The ctas_file_open()
function uses the process name and file extension to create a standard CTAS filename. The
ctas_file_initialize() arguments are

       process type - Type of process recording the information (PROC_CM, PROC_ISM,
        etc.)
       ctas_data_type - Type of data to record: CM_MSG (.dbg), DBG_MSG_DATA (.dbg)
       log_ptr - pointer to the particular log structure (log_st)

3.12.2 Initialize Weather Data
CM calls cm_initialize_wdpd() to initialize live weather data. This is done prior to any
command-line option processing and subsequent cm_wdpd_initialize() processing. Weather
file names and ancillary information are stored in a Global_wthr_info_st, which is defined in
global_includes/ctas_struct.h.

3.12.3 Initialize Data Recording
The initialize_dr() function initializes the on-off data recording state for each CTAS process.
Data recording is controlled by the M&C.

The Dr_interfaces[] array indicates the recording status for each process as set by the M&C
(from cm_mc.h):

        uchar_t           Dr_interfaces[PROC_COUNT];

The values Dr_interfaces[] can hold (from tfm_mc_msgs.h) are defined as follows:

        #define   APP_ACR_NONE      '-'      /*   not supported and off */
        #define   APP_ACR_OFF       '0'      /*   Off */
        #define   APP_ACR_HDRS      '1'      /*   headers only */
        #define   APP_ONE_DATA      '2'      /*   one data, balance headers only, no dups*/
        #define   APP_ACR_ON        '3'      /*   no duplicates */
        #define   APP_ACR_DUPS      '4'      /*   duplicates */

The “on” state is represented by the last four definitions. The meaning of each is as follows:
 APP_ACR_NONE – Not supported by the application
 APP_ACR_OFF – Supported but turned off


                                               37                                            R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


   APP_ACR_HDRS – Only message headers recorded
   APP_ONE_DATA – One data message for each process type (if 6 TGUIs are connected,
    only one data message is recorded), with ensuing headers recorded, no duplicates
   APP_ACR_ON – One message recorded for each process type (if 6 TGUIs are connected,
    only 1 message is recorded)
   APP_ACR_DUPS – All messages from multiple source of the same type are recorded
    (that is, one message for each process type instance: 6 TGUIs, 6 messges)

The M&C controls data recording by sending CM an APP_CONTROL_RECORDING
message.

3.12.4 Initial Command-Line Option Processing
CM first checks the command-line for those options that should be processed before
adaptation is processed. This processing is

       Initialize           CM           defaults.             See         the          file
        realtime_procs/Common_data_system/cm_defaults for an explanation of CM
        defaults and their processing.
       Motif Initialization. If the –Windows option is given, then motif_main() initializes
        various Motif intrinsics.
       Process pre-adaptation options. Possible pre-adaptation options are listed in
        runtime_option_table[], which is defined in initialize.c.
       Build adaptation (input) and diagnostic (output) file names. These names are defined
        in global_includes/ctas_defs.h and initialize.c.

3.12.4.1       Pre-Adaptation Command-Line Options
The following list describes important command-line options processed before adaptation is
processed.

-no_ipc_dbg -- Don‟t write CTAS interprocess communication messages to .msg file. See the
–rectype option.

-no_log – Don‟t write debug information to a .dbg file.

-rectype <type> [<status>] - Specify data recording for type(s).
       <type> 'dp', 'tgui', ..., or 'all'
       <status> optionally toggles data recording for the defined type, default is 'on'
              'off' - no data recorded
              'hdrs' - message headers only
              'on' - header + data (one for PROC_ALL_[T,P]GUIS)
              'dups' - header + data (one per destination)
While CM records all incoming messages, to minimize the amount of data written, CM only
records outgoing message headers for those messages “passed through” to other TMA
processes, with no change to their content. In this situation it is only important for CM to
know which processes the messages were forwarded to. Messages generated by CM, and
messages that have their content changed by CM before distribution continue to have the



                                            38                                        R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

entire message contents recorded, but only to the first process CSCI. All other processes that
are sent or forwarded the same message only have the header information recorded.


-wmode <mode> -- Set the weather data mode. Available options:
     0. Use Standard Atmosphere with Zero Wind Field.
     1. Use Live Weather from WDPD.
     2. Use User-Specified Weather File

-X class [level ...] -- Turn on debugging for class on specified levels. No level specification
turns on all levels. The ALL class specification indicates all classes. See lib/ctas_debug.h.

These options are defined in runtime_option_table[] (initialize.c). The –help option lists all
CM options.

3.12.5 Attach to Shared-Memory Adaptation
At startup, CM attaches to shared-memory adaptation (read only data) for the default
TRACON/adaptation (specified by the –data command-line option). The shared memory
data and API are defined in lib/ctas_adp.c. The shared-memory manager (SAM), maintains
read-only segments for each active TRACON‟s adaptation. See the M&C SRDD for more
information.

3.12.6 Initialize Socket Connection and Applications
CM calls cm_initialize() to initialize the connection management infrastructure. This function
does the following:

   Calls ssa_new() to create two SSAs: SsaMain and SsaTemp.
   Calls cm_app_ini() clears the application table App[] with a call to cm_app_clr() for each
    table entry, and initializes the type-to-index table T2i[] with a call to cm_app_idx_new()
    for each table entry.
   Calls cm_com_ini() to initialize CM-global communication information (CM process type,
    instance, and facility).

Once the socket and application infrastructure are initialized, CM can establish a connection
with the M&C.

3.12.7 Initialize M&C – CM Connection
CM establishes a connection with the M&C by calling cm_mc_connect(), which does the
following:

   Creates a client socket connection with the M&C, using the non-blocking socket library
    functions createClientSocket() and connectClientSocketUDSI().
   Creates a temporary application object within the application table for the M&C via
    cm_app_tmp(), which also sets the corresponding entry in the SSA. Temporary objects
    are used to hold connection information during the time that a connection has been
    established but before CM learns the connecting process‟s identity.



                                            39                                          R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009


   Sets the service (MC_SVC, see global_includes/tfm_mc_msgs.h) and                     process
    (PROC_MC,     see     global_includes/tfm_mc_msgs.h)  in the M&C                     App_st
    (cm_app_service_set() and cm_app_process_type_set()).

After establishing a socket connection with the M&C, CM is ready to read in adaptation and
configuration information. If it cannot establish an M&C socket connection, CM quits.

3.12.8 Initialize Center Information
Center identifiers for the local and available              adjacent   Centers   are   initialize.
(center_id_initialize()). See Centers[] in lib/centers.c.

3.12.9 Initialize SSC and MSSD Lists
SSC and MSSD identifier management lists (ssc_id_initialize ()) for all scheduling groups are
initialized. These identifiers are stored in Ssc_flow_list[][] and Mssd_flow_list[][]
(lib/ssc_id.c).

3.12.10         Reading Local (Read/Write) Adaptation
At this point, input_data_files() allocates memory and initializes data structures for
adaptation, and read in files containing local adaptation for the default TRACON. This local
data is read/write data. This data includes the following:

       TMC default settings (currently reschedule suppression default setting)
       Airport configuration arrays
       SGFF items
       Stream and super stream class and MSSD group information, and separation
        distances and freeze-ahead settings (cm_read_ssc_flows())
       Flow parameter sets
       DP defaults
       Traffic flow change lists
       Super stream class definitions
       Airport metering lists
       TRACON metering lists

Each active TRACON has read/write adaptation in local memory, and read-only adaption in
shared memory. See the M&C SRDD for a description of the shared memory manager
(SAM).

3.12.11     Initialize Two-Way Communication and Metering Information
      Lists
Initializes Two-Way and metering state information for local and adjacent Hosts
(cmu_build_host_metering_list()), and TRACONs (cmu_build_tracon_metering_list()).




                                             40                                           R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


3.12.12         Process Post Data File Command-Line Options
The post_datafiles_runtime_options() function calls a lib function, option_processor(), to
process the options entered at the command line that are post data file runtime options; that
is options that can be handled only after the adaptation data files have been read in.

-C <airport> <configuration_index> -- Set specified airport to specified configuration.

-delay_meter_fix <meter_fix_name> -- Specify delay meter fix.

These options are defined in post_datafiles_runtime_option_table[] (initialize.c). See
lib/runtime_options.h for option processing information.

3.12.13         Process Panel Defaults
The process_panel_defaults() function is called to read the information in the standard CM
defaults file (Common_data/system/cm_defaults).

3.12.14         Get Data Source Information
The get_data_source_info() function gets the list of data sources to be included in the CM
main window GUI.

3.12.15        Motif Window Initialization
The motif_create_windows() function oversees the various creation/initialization processing
necessary to create the CM windows and attributes. This processing includes calls to function
in lib_motif.

3.12.16        Weather Processing Initialization
The cm_wdpd_initialize() function initializes the global weather processing structure
Wthr_current_files. See sections 3.11.2.2 and 3.12.8 for descriptions of weather data
processing.

3.12.17        Setting Control Times
The cm_set_control_times() function sets Ctas_precision_current_time to the current time
and One_second_update to one second after current time.

3.12.18        CM Initialization
The initialize_tracon_items() function initializes TRACON-specific data, as follows:

   Initializes airport configuration, flow change, and departure-time-in-use arrays to default
    values (initialize_airport_configuration()), and for each arrival airport, calls
    tfc_add_flow_parameter_set() function to populate the current flow set (airport flow,
    runway flow, gate flow, meter fix flow, and super stream flow (and MSSD information
    for EDC) for each arrival airport. For a meter point group (EDC), only super stream flow
    data is populated. Note that airport and runway flows are populated at system
    initialization only (TRACON).




                                            41                                            R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


   Initializes the departure airport delay buffer list (cm_airport_utils_init_dep_buf_list()).
    This specifies the portion of delay that can be taken airborne, for each adapted airport
    (TMA or EDC) for the specified TRACONs.

   Calls bi_initialize() to initialize the blocked interval list structure (defined in
    blocked_interval_changes.c). Blocked intervals are created using the TGUI. They may be
    created for either a runway or meter fix. Scheduling is affected by the creation of blocked
    intervals since aircraft may not be scheduled to cross the runway threshold or meter fix
    during the specified time period. CM receives blocked interval messages, maintains a list
    of blocked intervals and forwards the messages to all TGUIs and the scheduler being
    used (DP). The current list of blocked intervals is sent by the CM to a new TGUI or
    scheduler as part of their initialization process. Also if not in EDC mode, calls
    tc_initialize_tc_pointers() to initialize the traffic count pointers and apparatus. See section
    3.12.2.5 for a description of traffic count processing.

   If not in EDC mode do the following: if the –C option is given at startup,
    opt_set_configuration() reads in and sets the specified airport configuration. If the –
    delay_meter_fix option is given, opt_set_delay_meter_fix() sets the specified delay meter
    fix.

   Calls initialize_number_of_ac_in_each_ra() to zero the number of aircraft assigned to
    each available RA, and set each RA to inactive.

   Calls rcv_create_landed_list() to initialize the landed aircraft list, Landed_aircraft[], used
    to store landed aircraft, and which is maintained for DP casualty recovery.

   cm_dep_sd_category_init() initializes satellite departure airport configuration categories
    (Satellite_airport[apt].satellite_config_cat) from the satellite airport decsion tree.

   Initializes sequence and schedule data (cm_send_initialize_schedule_items()).

   initialize_ac_track_items() initializes TRACON-specific aircraft track data. For EDC, data
    is initialized for reception of non-arrival tracks.

   cm_tgui_initialize_tgui_items() initializes TRACON-specific TGUI data. Runway spacing
    information is only initialized when not in EDC mode.

   win_cat_initialize_for_tracon() initializes CM GUI toggle options/callbacks.

   cm_pref_list_initialize() initializes the user preference filename list for each GUI (TGUI
    and PGUI), for each arrival TRACON. This linked list contains the preference file names
    and their access/modification times.

   cm_airport_utils_init_amdt_lists() initializes arc Allowed Maximum Delay Time (AMDT)
    lists for all outer arc types to default values read in from the gates file.




                                              42                                            R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


   If in EDC mode, initialize the EDC meter point/airports (that is, non-arrivals) list
    (cm_edc_mp_utils_init_mp_airport_list()),   and       initialize     the        list
    (Mp_and_gate_flow_list[]) that holds the EDC gate and meter point flow changes
    (efc_initialize()).

   cm_pref_list_send() sends the names and creation times of all CM preference files to the
    backup CM.

   Initializes ETA     hovering      parameters    from    shared-memory             adaptation
    (hio_get_hover_enabled(), hio_get_hover_max(), and hio_get_hover_pedt()).

The initialize_system() function initializes miscellaneous global data, as follows:

   Sets CM‟s CTAS time of day. (global)
   Initializes data recording values. (global)
   Calls ism_initialize() to initialize ISM connection sources. Initializes the g_source_info[]
    array, which contains Source_status_st structures for each data source (global):

    struct Source_status_st
    {
        int dsc_index;                        /* ism, center, tracon, edr */
        Source_action_type what_to_do;        /* connection/disconnect    */
        Source_status_type status_value;      /* source's up/down status */
    };
    typedef struct Source_status_st Source_status_st;

    enum Source_action_type
    {
        SOURCE_ACTION_CONNECT,
        SOURCE_ACTION_RECONNECT,
        SOURCE_ACTION_DISCONNECT
    };
    typedef enum Source_action_type Source_action_type;

    enum Source_status_type
    {
        SOURCE_STATUS_ONLINE,
        SOURCE_STATUS_OFFLINE,
        SOURCE_STATUS_NO_DATA
    };
    typedef enum Source_status_type Source_status_type;



   Initialize TRACON map/start data (Tracon_start[]) used to determine if a TRACON
    group has started (that is, and APP_GROUP_START message was received and
    processed successfully). This value is checked for each TRACON before attempting to
    send TRACON information to CAP.

   Initialize ETA hovering data (Tracon_hover[]) for each TRACON.

3.12.19         Inform the M&C that CM has Initialized
At this point, CM sends the M&C an APP_INIT message (cm_mc_snd_app_init()) to indicate
that CM has read in adaptation, initialized itself correctly, and is ready to receive listening


                                             43                                          R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009

and connection-request messages.. This function also resets the M&C process type to
PROC_NONE so normal first message receipt logic in cm_msg() performs correctly. The
process type was set so that messages could be sent correctly during the time when CM
connected to M&C, and when the first message was processed from the M&C.

M&C responds to the APP_INIT listen by sending an APP_INIT_LISTENING message to
CM, instructing it to open a listening socket. Once CM has done this, it informs the M&C by
sending it an APP_LISTENING message.

3.12.20          Enter the Main Processing Loop
After initialization, CM enters cm_main_loop() which contains an endless loop that calls
cm_main_call(). This function does two things: calls cm_processing() to do message
processing, and calls update_aircraft() to update and propagate current aircraft data. The
following section describes the main loop processing.

3.13 The Main Processing Loop
Once CM has connected with the M&C, initialized the system, and done all its startup duties,
it enters the main processing loop by calling cm_main_loop(). This function contains an
endless loop that sets up a timer and calls cm_main_call(). The cm_main_call() function calls
two functions that kick off the two primary types of processing that CM performs:

       Socket connection processing (cm_processing())
       Updating and distributing aircraft data (update_aircraft())

The following outline describes the CM main processing loop:

   cm_main_loop()

       cm_main_call()

            cm_processing() – called each time through loop. Handles all socket processing.

                ssa_copy (SsaTemp, SsaMain)

                cm_com_select(SsaTemp, 0) – check for socket activity. If there‟s activity, then:

                    Check       listening      socket       read        status        (ssa_read())-
                     App[APP_LISTENING_ENTRY] is reserved for this. The index entries in
                     SSA are the same as those in the application table. If activity, then:
                      Accept the connection (cm_com_accept())
                      Create a temporary process object (cm_app_tmp()). Used to hold
                        connection information during the time that a connection has been
                        established but before we learn of the identity of the connecting
                        process.

                    Check other sockets (again ssa_read()).



                                               44                                            R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009


                      Check state (cm_app_protocol_state()). If not closed, then:
                      Read socket (cm_com_read()). If read successful, then:
                      Handle message (cm_msg()).

            End cm_processing()

            update_aircraft() - This routine is called about once per second. It manages
             updating the aircraft information in CM‟s aircraft database.

The following sections describe the socket aircraft processing, and aircraft data updating and
distribution details.

3.13.1 Socket Connection Processing
With the main processing loop, cm_processing() controls CM connection and message
processing. This includes:

       Retrieving the read/write-ready state of each socket by calling cm_com_select(). This
        function calls selectSocketsI() in the non-blocking socket library.
       Checking the listening socket for new or renewed connection requests by calling
        ssa_read() on the listening socket.
       Checking application sockets for messages and distruting them to processing
        functions

The following sections describe the details of CM connection and message processing.

3.13.1.1        Establishing the Listening Socket
CM must first establish a listening socket to field requests for application connections. This
section describes how the listening socket is established, and also describes how new
applications socket requests are handled.

At startup, CM establishes a socket connection with the M&C to receive, among other things,
direction in opening a listening socket. As previously described, main() calls
cm_mc_connect() to do the following:

       Create a client socket connection with the M&C
       Create a temporary object (cm_app_tmp()) for the M&C
       Sets service type to MC_SVC (cm_app_service_set()) and process type to PROC_MC
        (via cm_app_process_type_set()). Set process type to be able to send
        APP_BAD_ADAPTATION and APP_INIT msgs to M&C in initialization processing
        that follows. After the APP_INIT msg is sent, the process type is reset to
        PROC_NONE to support first message receipt logic in cm_msg().

As with all first-time application communications, the M&C is given a temporary slot in the
application table.




                                             45                                         R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

After adaptation and system initialization files are read in, main() calls
cm_mc_snd_app_init() to send an APP_INIT message to the M&C. This indicates that CM
has read in adaptation, initialized, and is ready to receive listening and connection messages.
Note that cm_mc_snd_app_init() also resets the M&C process type to PROC_NONE so that
normal first message receipt logic in cm_msg() performs properly for the M&C (in changing
it from a temporary to permanent application). The process type was set so that messages
could be sent correctly between the time when CM connected to M&C and when the first
message was processed from M&C.

At this point the M&C is the only connected application, it has a temporary slot in the
application table, and the main processing loop is entered. Socket connection processing is
the first thing to occur in the main loop.

The M&C sends CM an APP_INIT_LISTEN message, which directs CM to establish a
listening socket. This message is the equivalent of the SEND_HOST_NAME message sent
from other applications, in that it causes “first message” processing for the M&C.

Within the main processing loop, cm_processing() copies SsaMain to SsaTemp for passing to
the non-blocking socket library (this preserves SsaMain‟s socket settings), does the socket
select (via cm_com_select()), checks the (at this time non-existent) listening socket, then
checks the application sockets.

With the arrival of the APP_INIT_LISTEN message on the M&C socket, the M&C socket is
read-ready. The read is done (via cm_com_read()), and the message processing function,
cm_msg(), is called.

Before processing incoming messages, cm_msg() first checks for new applications (that is,
temporary or reconnecting). Because the M&C is currently in a temporary application table
slot, cm_msg() calls cm_app_new(). This function gives the M&C its permanent, reserved
slot, and sets the M&C‟s SSA socket entry (via cm_app_idx_add()).

At this point, the M&C has its permanent slot in the application table and its SSA socket
information set. Processing for the APP_INIT_LISTEN message is yet to come.

The cm_msg() contains a switch statement for processing messages based on the process type
from which the message originated. APP_INIT_LISTEN originates from the M&C, so
cm_mc_msg() (the M&C message handler) is called. This function, in turn, has a switch
statement for processing based on message type, and cm_mc_init_listen() is called to process
the APP_INIT_LISTEN message.

cm_mc_init_listen() calls cm_com_listen() to open a listening socket and send an
APP_LISTENING message back to the M&C (confirmation that the CM listening socket is
working), then calls ssa_set() to set SsaMain entry 0 (the listening socket entry) sockRef and
ready-ready status.

At this point CM has




                                            46                                          R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


   A permanent entry in the application table for the M&C, and its SSA (SsaMain) entry
    contains the M&C‟s sockRef with the read-ready status set to true.
   A working listening socket (entry 0 in the application table and SsaMain) for listening to
    connection requests from applications.

3.13.1.2       Listening Socket Processing
The application table‟s APP_LISTENING_ENTRY is reserved for the listening socket. The
listening socket is checked by a call to ssa_read():

        ssa_read(SsaTemp, APP_LISTENING_ENTRY)

Connection requests are accepted with a call to cm_com_accept(), which does the following:

   Calls createAcceptSocket() (from the non-blocking socket library) to create the new
    socket.
   Calls acceptConnectionI() (from the non-blocking socket library) to open the socket,
    accept an incoming connection (the client) on the socket, and convert the socket to non-
    blocking.
   Calls cm_app_tmp() to create a temporary process object (App_st), which is used to hold
    connection information during the time that a connection has been established but before
    we learn of the identity of the connecting process (by receiving a SEND_HOST_NAME
    message from an application, or an APP_INIT_LISTENING message from the M&C).
    This must be done because at the time the connection is established we don't know the
    identity of the process connecting and we don't want to step on a temporarily deleted
    entry of another process. The cm_app_tmp() function goes through the application table
    looking for an empty slot (app->protocol_state == STATE_CLOSED). If it finds one, it
    uses that slot for the temporary process object. If an empty slot cannot be found, CM
    notifies the M&C that there is no room in the application table via a call to
    cm_mc_snd_app_warning() to inform the operator. The information is also written to a
    file.

3.13.1.3       Application Socket Message Processing
Once any connection requests have their temporary slot in the application table, the
application sockets are checked. This processing involves the following:

   An ssa_read() is done on each entry (but the first) in the SSA.
   If the socket has something to read on it, the address of the socket‟s application is
    retrieved:

        app = cm_app_adr(ssa)


   A socket read loop does up to CM_MAX_READS_PER_SOCKET reads on the socket. No
    reads are done if the socket protocol state is STATE_CLOSED (the loop is exited).
   Data is read via cm_com_read(), and returned in a msg_hdr_st buffer. Note that if the
    backup CM (CMb) is connected and the input message is not from CMb or the M&C, a
    copy of the message is sent to CMb.



                                            47                                         R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


   CM message processing is then started by passing the message (the msg_hdr_st buffer) to
    cm_msg().

The cm_com_read() function also calls msg_count() to keep a message count. Message counts
are tracked in the message list, defined as follows:

        static list_list    *g_list_msg;

Each node in the message count list contains is a message count structure, defined as follows:

        struct msg_st
        {
            Ipc_msg_type    type;
            int    count;
            int    src;
        };
        typedef struct msg_st msg_st;

Each message type has a node in the message count list. If there is already an instance of that
message in the list, then msg_count() increments the count for that message. If this is the first
instance of that message, it creates a new node for that message.

The cm_msg() function then takes the msg_hdr_st retrieved by cm_com_read(), and, based
on the which application sent the message, distributes the message to a function responsible
for processing messages from that application type. This function then calls a function based
on the message type (that is, msg_hdr_st->msg_type field). This is the cm_msg() primary
task: to distribute messages to the appropriate message handler, based on message type.

Before distributing the message, cm_msg() first checks to see if the message is from a newly-
connected application, or from a relay application (GUIR). It checks by determining if the
application‟s type (determined by which socket the message came from) matches the type
specified in the incoming message header. If they don‟t match, then the message either 1)
arrived from a new process, or 2) arrived via a relay process.

If there is a mismatch, cm_msg() calls cm_app_find_pifc() to attempt to find the real
originating process, based on the process type, instance, and facility information in the
incoming message (msg_hdr_st). If found (and its protocol state is not STATE_CLOSED), a
pointer to the correct app_st in the application table.

If the application is not found, then it‟s assumed it is a new application, and cm_app_new() is
called. New applications are those that occupy a temporary slot in the application table; they
must be moved to their permanent place in the table. The cm_app_new() function‟s task is to
return a pointer to the appropriate app_st in the application table.

cm_app_new() first checks for process types PROC_CM and PROC_MC, both of which
occupy reserved slots in the application table.

If a process type other than PROC_CM or PROC_MC is passed in, cm_app_new() searches
the application table for a match in case an application has previously closed and is now


                                             48                                           R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

reopening its connection. In this case, the application is given the same application table slot
it previously occupied. Additionally, the type-to-index table, (T2i[]) is updated by a call to
cm_app_idx_set(). This function maps process type to a specific process instance.

If no match (that is, previously used application table slot for this application instance) is
found, then a new entry is needed, and cm_app_new() tries to find a closed entry which was
not previously used (that is, with an app_st with app->protocol_state set to STATE_CLOSED
and app->process_type set to PROC_NONE). For new applications, cm_app_idx_add() is
called to add a new application instance to the T2i[] table.

At this point the application‟s app_st is filled with relevant information about the connecting
application (either for a direct connection, or a relay process), the SSA entry for the
temporary connection is cleared (ssa_clear()),the SSA entry for the new connection is set
(ssa_set()), and the temporary application entry in the application table is cleared
(cm_app_clear()). Finally, cm_app_new() returns the new or revised application structure to
cm_msg().

3.13.1.4       TRACON Switching
To switch CM to use the correct TRACON, cm_msg() must determine which process is
sending a message to CM. When a message originates from a TRACON-specific process
(DP/MPDP, RA, GUIR, TGUI, PGUI), the following happens:

       When the message type is SEND_HOST_NAME then a call to shared-memory
        management function adp_use_tra() points to the shared memory area that matches
        the TRACON identifier within the message's header (dst_traconid) field; when the
        state of the shared memory area is available and active, as indicated by the return
        value from the adp_use_tra() call, the VERSION_ID_OK message is sent in response
        and processing continues to make the connection to CM. When the state of the shared
        memory area is not available an error message is generated and sent to M&C and
        processing ceases for this message.

       When the message type is not SEND_HOST_NAME then adp_use_tra() points to the
        TRACON identifier stored within CM‟s application data structure for the originating
        application process. When the state of the shared memory area is available and
        activeprocessing for the message continues; otherwise an error message is sent to
        M&C and processing ceases for this message.

When peer CM messages are generated from primary CM to backup CM, adp_use_tra()
points to the shared memory area that matches the TRACON identifier within the message's
header (dst_traconid) as follows:

       If the message type is SEND_HOST_NAME then, when the state of the shared
        memory area is available and active the VERSION_ID_OK message is sent in
        response and processing continues to make the connection to CM, otherwise, an error
        message is sent to M&C and processing ceases for this message.




                                             49                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


       When the message type is not SEND_HOST_NAME, processing continues regardless
        of the message header‟s dst_traconid value.

For ISM messages, adp_use_tra() points to the shared memory area that matches the
TRACON identifier within the message's header field (dst_traconid). When the state of the
shared memory area is available and active, as indicated by the return value from the
adp_use_tra() call, message processing continues. When the state of the shared memory area
is not available an error message is generated and sent to M&C and processing ceases for this
message. When the state of the shared memory area is available but not active, only
IC_FLIGHT_PLAN_DEL messages are processed while all other messages are ignored.

For TRACON-specific processes in EDC mode, some messages need to be dropped. For these
meter point (non-arrival) flights, if the following conditions are both true, the message is
dropped:
 If the message specifies an aircraft identifier, and that aircraft doesn‟t have an assigned
    meter point , AND
 The message is of a type that can‟t be sent to the given process without an assigned meter
    point.

When the message originates from any non-TRACON-specific process (M&C, WDPD, etc.),
message processing continues regardless of the message's header (dst_traconid) value.

3.13.1.5      Handshaking
Before processing application messages, cm_msg() checks to see if the application is fully
connected (that is, cm_app_protocol_state() returns STATE_DATAXFER). If the protocol
state for the application that sent the message is not STATE_DATAXFER (for example, new
applications), then cm_msg_handshake() is called to fully connect with the application.
Application communication protocol states are defined as follows:

        typedef enum
        {
            STATE_CLOSED = 0,        /*   no connection                              */
            STATE_CLOSING,           /*   process is in a closing down state         */
            STATE_MC_CONNECTING,     /*   connecting to M&C client (connect)         */
            STATE_ISM_CONNECTING,    /*   connecting to ISM client (connect)         */
            STATE_LISTENING,         /*   listening for connection requests          */
            STATE_CONNECTED,         /*   connection established (accept)            */
            STATE_DATAXFER           /*   rcved SEND_HOST_NAME, data transfer mode   */
        } Protocol_state;

Handshaking for each application occurs as follows:

   M&C      –   Sets    the   M&C‟s    app->protocol_state      to   STATE_DATAXFER
    (cm_app_protocol_state_set())
   ISM – (new ISM) Calls cm_msg_generic_handshake() to check that the message received
    is SEND_HOST_NAME, and if so, sets the application‟s host name in the app_st, sends a
    VERSION_ID_OK message back to the application, sets the application‟s socket type
    (app->socket_type), and sets the application‟s protocol state (app->protocol_state) to
    STATE_DATAXFER.


                                            50                                        R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009


   IDR (Internal Departures Relay) – Either end of an IDR socket connection can initiate
    handshaking. So the cm_msg_idr_handshake() function, which handles handshaking for
    IDR connections, must handle both socket connection requests the CM has initiated (that
    is, receipt of a VERSION_ID_OK message), and responding to an IDR socket connection
    request from a remote entity (that is, receipt of a REMOTE_SEND_HOST_NAME
    message). If the VERSION_ID_OK message is received and the protocol state is
    STATE_CONNECTED, then the protocol state is changed to STATE_DATAXFER. If the
    REMOTE_SEND_HOST_NAME message is received, then the connectin IDR area
    (Center or TRACON) and tool (TMA or FAST) are set, the IDR application protocol state
    is set to STATE_DATAXFER, the IDR host name is set, and a VERSION_ID_OK messae is
    sent back in response.
   CMb – If the message received is VERSION_ID_OK, then this is CMb, and the message is
    received in response to a SEND_HOST_NAME message that CMb sent to CMp. In this
    case, the CMb‟s protocol state is set to STATE_DATAXFER. Otherwise, this must be CMp
    receiving the SEND_HOST_NAME message from CMb. In this case,
    cm_msg_generic_handshake() is called to treat the connecting CMb like a typical client
    application.
   Other applications - cm_msg_generic_handshake() is called to verify that the message is
    SEND_HOST_NAME, and verify socket type, that the maximum number of connections
    hasn‟t been exceeded, hostname, CTAS version number, and site (for non-TRACON
    specific applications) are correct. If correct the generic handshake is completed by setting
    the sending application‟s hostname, protocol state (to STATE_DATAXFER), and socket
    type, and sending the application a VERSION_ID_OK message to complete the
    handshake.

If an error occurs during application handshaking, cm_msg_handshake() calls
cm_mc_lost_server_client() to determine the type of process that failed handshaking and
how to proceed. The cm_mc_lost_server_client() function does the following:

   If the M&C handshake failed, sets the global variable Mc_sockref to 0.
   If a temporay application handshake failed, sends an APP_WARNING message to the
    M&C.
   If    a    service   handshake      failed    (for  example,    ISM     or    IDR),   calls
    cm_mc_snd_app_lost_datafeed() to send an APP_LOST_DATAFEED message to the
    M&C.
   If    a    client   handshake      failed   (for   example,    RA     or    TGUI),    calls
    cm_mc_snd_app_lost_client() to send an APP_LOST_CLIENT message to the M&C.
   Lastly, cm_app_del() is called to do the following:
     Cleared the failed application‟s SSA entry (ssa_clr()).
     Clear the failed applications connection information
     Disconnects the application‟s index entry (T2i[]) from pointing to the application table
         and indicates one less process connected (only if a permanent application).

Upon a successful handshake, cm_msg() moves on to distributing the messages to the
appropriate message handler. See section 3.12, Application Processing, for the message
handling details.



                                             51                                          R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

After message handling, CM updates its database, as described in the next section.

3.13.2 Updating and Distributing Aircraft Data
CM receives and processes messages received from CTAS applications and other data
sources. With this information CM keeps the aircraft tree and other CTAS state information
current. The update_aircraft() functions updates aircraft and related information for the other
CTAS applications. The update_aircraft() function is called from the main processing loop
about once per second. The following sections describe update processing.

3.13.2.1       Checking Radar Connection
In the update cycle, CM first checks radar connectivity status. This information is sent to CM
by ISM in status messages. If radar updates have been interrupted, the CM writes error
information to the radar error file.

3.13.2.2       Updating Weather Data
CM distributes weather updates to “weather-interested” applications. For TMA, these
applications are RA (for TS), PGUI, and GUIR. Weather arrives in a file at a specified location
via FTP. Weather status is tracked and maintained in a global structure defined in
cm_common.h:

        Global_wthr_info_st    Wthr_current_files;

The structure type is defined in cm_struct.h:

        typedef struct {
            char                  bin_filename[WTHR_LINE_LENGTH];
            char                  previous_bin_file[WTHR_LINE_LENGTH];
            char                  pending_bin_file[WTHR_LINE_LENGTH];
            char                  live_filename[WTHR_LINE_LENGTH];
            char                  default_filename[WTHR_LINE_LENGTH];
            char                  std_atm_file[WTHR_LINE_LENGTH];
            Wthr_mode_type        wthr_mode;
            Cm_wthr_status        cm_wthr_status;
            long                  live_file_time;
            Wthr_file_status_st   ctas_file_status;
        } Global_wthr_info_st;

This structure stores information about weather file names, if a weather update or revert is
pending, the original production time of the current live weather file, and the current live
weather file status structure. The Wthr_file_status_st structure contains the current live
weather file status (whether the current live weather file production time, forecast time, or
forecast cycle are stale (outdated) or not), and is in the form of text strings that can be
displayed on any adapted GUI. The contents of the structure are listed below.

        typedef struct Wthr_file_status_st
        {
            char forecast_time[WTHR_STATUS_TEXT_LENGTH];
            /* "Last Forecast: 0700-0800z" and "Current" or "(+1hr)" OR
               "Defaulted to Standard Atmosphere" */

             char   production_time[WTHR_STATUS_TEXT_LENGTH];



                                            52                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

             /* "Produced at: 07/22/2003 0600z" and "Current" or "(+1hr)" OR blank */

             char wind_data_time[WTHR_STATUS_TEXT_LENGTH];
             /* Current file type in use and forecast age, display on TGUIs and PGUIs
        */

             int   current_bin_file_state;
             /* current state, see ctas_defs.h Wthr_file_state_type emun */

        } Wthr_file_status_st;

The cm_wdpd_update() function is called in the update cycle to process any weather
updates. It updates weather-related filenames and checks the client‟s weather status, as
appropriate. CM handles up to two weather failures. If the current update fails CM will
revert to the previous file. If the revert fails CM resets weather to the standard atmosphere
file, which is the default file.

Reception of a WDPD_CM_NEW_WTHR causes CM to perform a weather update. The
cm_wdpd_new_wthr() function handles reception of this message. This function is passed a
ctas_get_wthr_st message structure which contains the updated raw and binary weather file
names sent from WDPD. This function updates the global weather structure so that the
update is done during the next processing cycle. This includes the new pending weather file
name and setting the update pending flag.

In normal weather file processing, weather-aware processes respond to
CTAS_GET_NEW_WTHR_FILE message from CM with *_WEATHER_RECEIVED, then CM
proceeds with the CTAS_USE_NEW_WTHR_FILE sequence and the weather-aware
 processes begin using the new weather.

If any RA process responds to CTAS_GET_NEW_WTHR_FILE with a RA_WTHR_FAILED
message, then a weather revert is flagged for the next processing cycle.

If any PGUI process responds to CTAS_GET_NEW_WTHR_FILE with a
PGUI_WTHR_FAILED message, then no weather revert processing occurs. That PGUI
process is flagged (send_use_wthr_msg) so as not to be sent subsequent
CTAS_USE_NEW_WTHR_FILE or CTAS_REVERT_WTHR messages.

If an RA causes a weather-file revert, and a PGUI fails on the revert, then that PGUI process
is    flagged   (send_use_wthr_msg)        so   as     not    to    be     sent    subsequent
CTAS_USE_NEW_WTHR_FILE or CTAS_REVERT_WTHR messages.

CTAS_GET_NEW_WTHR_FILE, CTAS_REVERT_WTHR, and WDPD_CM_NEW_WTHR
messages are defined by the following structure:

        typedef struct
        {
            msg_hdr_st msg_hdr;
            char        bin_filename[LINE_LENGTH];
        } ctas_get_wthr_st;




                                           53                                         R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

If a live weather file update from WDPD is successful then CM informs WDPD of the
success, otherwise, CM informs WDPD of the failure.

After every live weather file update from WDPD, after every weather mode change, and
every 65 minutes, the weather cycle will call the cm_wdpd_is_wthr_file_stale() function to
parse the current live weather file name to determine the current live weather file production
time, forecast time, and forecast cycle. With this information the function will determine
whether the current weather file production time, forecast time, and forecast cycle are stale
(outdated) or not and this information will be sent to all connected GUIs for display via the
CTAS_WTHR_FILE_STATUS message.

3.13.2.3       Distributing New Flight Plans and Requesting ETAs
When a new flight plan arrives from ISM, and the aircraft tree is updated, the aircraft‟s
Ac_st->fp_to_clients field is set to FP_NEW. Flight plan distribution status can be one of the
following values:

    typedef enum
    {
        FP_NEW,              /* newly added - not yet sent and no eta requested */
        FP_REMOVED,          /* removed from specific process, not from CM database */
        FP_UPDATE,           /* periodic update - not yet sent/no eta req */
        FP_SENT,             /* fp sent to clients - eta not yet requested */
        FP_CURRENT            /* flight plan sent to all clients and eta requested */}
    fp_cm2client_status;

At update time, CM walks the aircraft tree, and calls send_fps() on each node. This function
does the following:

   Checks if the aircraft is really a open or blocked slot; if so, send_fps() simply returns, and
    twalk moves on to the next aircraft tree node.
   send_fps() also switches to the correct TRACON adaptation memory segment
    (adp_use_tra()). If unable to locate the TRACON adaptation, then send_fps() returns.
   Send out ADD_FLIGHT_PLAN to each process which can currently receive that message
    (forward_flight_plan_add())
   Update the FP status per process: If ADD_FLIGHT_PLAN has been sent (current FP
    status is FP_UPDATE), change status to FP_SENT; if the current status is FP_SENT, send
    a     FLIGHT_PLAN_ETA_REQUEST                  message        to     the      assigned      RA
    (send_request_for_flight_plan_eta()), and change the status to FP_CURRENT.

CM first sends EDC (MP) group flight plans, then arrival (TRACON) flight plans.

3.13.2.4       Checking For Runway Flow Changes
The update cycle next calls check_for_flow_changes() to check for any aircraft runway flow
changes that have gone into effect since the last update. This is done for each active
TRACON.

In EDC mode, check_for_flow_changes() does the following:




                                              54                                           R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


   Removes      any     SSC   flows    superceded    by     a    more     current     flow
    (tfc_remove_expired_super_stream_flow_nodes()).
   Checks if any future MSSD and SSC management lists are eligible to become current.
   Checks if any EDC meter point flows have become current. Any meter point flows found
    eligible are removed from the future list, and added to the current list
    (efc_check_for_flow_changes()).

The following paragraphs describe TRACON (arrival) group check_for_flow_changes()
processing.

Runway configuration change requests are made by a TGUI sending a
TMA_CONFIG_CHANGE_REQUEST message to CM. This message specifies the following
runway change information for an airport:

       The time the runway change is needed (Configuration_change_horizon[])
       The     requested     (new)     runway       configuration  and       flow          set
        (Future_configuration_index[] and Current_flow_set[])
       The runway change is pending (Configuration_change_in_progress[])

The update cycle checks each airport for a pending runway configuration change. If a change
is needed, the pending configuration is made the current configuration, and a
CURRENT_CONFIGURATION message is sent to DP (not used), RA, TGUIs, PGUIs, and
CAP (send_configuration_change()). The Gen_config_st structure encapsulates the airport
configuration change information sent to those applications:

        typedef struct
        {
            msg_hdr_st        msg_hdr;
            int               airport;
            Time_type         time;
            unsigned int      index;
            unsigned int      set_index; /* sometimes sent to DP, XTM only */
            Bool_type         exempt_manually_scheduled;
            Bool_type         reschedule_all_airports;
            Airport_list_st   airport_setting [MAX_ARRIVAL_AIRPORTS];
        } Gen_config_st;

If two-way Host communication is enabled, a metering list header message (IX), containing
any airport configuration change, is sent to the Host (via HDIF) for any airport that has a
flow change (cm_meter_ix_update()). Additionally, if not in EDC mode an IX message is sent
if a new airport flow has gone into effect (as determined by tfc_has_airport_flow_changed()).

3.13.2.5       Updating the Traffic Count
The tc_update_tc() function manages traffic count data. CM keeps air traffic count statistics
for display reports. Traffic count processing has the following characteristics:

       Total aircraft counts are kept for each active TRACON.




                                            55                                        R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009


       Counts are contained in 5-minute time slices, called bins, stretching from a prescribed
        past time span (currently 24 hours), through the current time, into a prescribed future
        time span (currently 3 hours).
       Within each bin, individual counts are kept for CTAS meter fix, scheduling meter fix,
        threshold ETAs, STAs, and overcrossings (9 total).
       Counts are further distinguished by engine type (jet and prop, where jet is both jet
        and jet prop).
       Counts are constantly updated (currently every 12 seconds).

TGUIs display traffic-count information, and can request counts from a 3 hour time range:
from 1 hour in the past until 2 hour in the future. TGUIs may also request printouts from
approximately 24 hours in past until 1 hour in future, approximately.

Traffic count software is designed around the traffic count data structure:

        struct Traffic_count_st
        {
            long curr_future_start_time;
            long curr_future_end_time;
            long history_start_time;
            long history_end_time;
            unsigned char current_future
                [MAX_AIRPORTS][TC_CURRENT_FUTURE_BINS]
                [TC_MAX_COUNT_TYPES][TC_MAX_ENGINE_TYPES];
            unsigned char history
                [MAX_AIRPORTS][TC_HISTORY_BINS]
                [TC_MAX_COUNT_TYPES][TC_MAX_ENGINE_TYPES];
        };
        typedef struct Traffic_count_st Traffic_count_st;

The current_future buffer contains the current and future traffic counts. Each update period
the current_future buffer is cleared and updated, with current time always represented by
the first bin.

The history buffer contains air traffic counts from current time until 24 hours in the past.
Each update period, the current time bin is cleared (overwriting the oldest bin when the time
comes) and most current 30 minutes “window” of the buffer is updated. The history buffer is
circular.

Traffic count processing is dependant on another data structure, the occurred list. The
occurred list contains information about specific events that have occurred for each aircraft.
This information is maintained even after a flight has been removed from the system. The
occurred list is defined as follows:

        static list_list    *Occurred_q = NULL;

With each node defined by the Occurred_node_st:

        struct Occurred_node_st {
                char    id[ID_LENGTH];
                long    last_record_time;
                long    threshold_nominal_eta;                /* Rwy ETA                   */



                                             56                                            R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

                long      sta_to_threshold;                   /*   Rwy STA                */
                long      cmf_nominal_eta;                    /*   Mfx ETA (CTAS)         */
                long      sta_to_cmf;                         /*   Mfx STA (CTAS)         */
                long      cmf_crossed_time;                   /*   Mfx LANDED (CTAS)      */
                long      smf_nominal_eta;                    /*   Mfx ETA (SCHEDULING)   */
                long      sta_to_smf;                         /*   Mfx STA (SCHEDULING)   */
                long      smf_crossed_time;                   /*   Mfx LANDED (SCHED..)   */
                long      rwy_landed_time;                    /*   Rwy LANDED             */
                int       airport;                            /*   airport index          */
                int       ac_type;                            /*   aircraft type index    */
                int       deleted;                            /*   False - 0, True - 1    */
        };
        typedef struct Occurred_node_st Occurred_node_st;

The occurred list keeps occurred event information for 1 hour.

The following enumerations define the aircraft traffic count types and engine types
(ctas_defs.h):

        typedef enum {
                RWY_ETA = 0,
                RWY_STA,
                RWY_LANDED,                 /* flight landed at arpt */

                MFX_ETA_CTAS,
                MFX_STA_CTAS,
                MFX_LANDED_CTAS,            /* flight crossed ctas mfx */

                MFX_ETA_SCHEDULING,
                MFX_STA_SCHEDULING,
                MFX_LANDED_SCHEDULING,      /* flight crossed scheduling mfx */

                TC_MAX_COUNT_TYPES          /* must always be last item */
        } Tc_count_type;

        typedef enum {
                TC_JET = 0,                 /* contains data for only JETS */
                TC_PROP,                    /* contains data for PISTON and TURBOPROP */
                TC_MAX_ENGINE_TYPES         /* must always be last item */
        } Tc_engine_type;

At update time and for each active TRACON, tc_update_tc() updates the traffic count and
occurred list as follows:

   Call tc_update_tc_config() to bump time if current time has moved to the next bin. Buffer
    configuration is updated when current time has progressed enough to warrant such a
    change (that is, current time now falls in the next bin).

   If not in EDC mode, update the                 occurred list      (using   twalk   function
    tc_check_for_occurred_events()),     and          remove          any       old      nodes
    (tc_check_for_old_occurred_nodes()).

   Clear the current history buffer bin (that is, the bin containing the current time) for each
    arrival airport.




                                             57                                           R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


   Call tc_count_history_traffic() which walks the occurred list to count the aircraft events
    which fall within the TC_HISTORY_UPDATE_PERIOD period (from the current time to
    30 minutes ago) of the history buffer.

   Clear the entire current_future array.

   Walk the aircraft tree, and count current and future air traffic.

Aircraft times which have been surpassed are maintained in the occurred list and are used to
compute the past counts and current counts where the aircraft is landing and has just
dropped below radar or has just been deleted.

Traffic count information is sent via the following data structures (from traffic_count.c):

        /* Used for the TRAFFIC_COUNT_DATA_REQUEST and TRAFFIC_COUNT_DATA messages */
        struct Traffic_count_data_ipc_st
        {
            msg_hdr_st            msg_hdr;
            long                  start_time;
            long                  stop_time;
            int                   type;
            /*
              * In the TRAFFIC_COUNT_DATA message, the start_time, stop_time, and type
              * will be filled in from the request message. The data requested will
              * directly follow the type information and be in the data format as
        found
              * in One_bins_data_st. Its start may be located by using code similar
              * to the following:
              * data = (unsigned char *) (((Traffic_count_data_ipc_st *) msg_ptr) +
        1);
              */
        };
        typedef struct Traffic_count_data_ipc_st Traffic_count_data_ipc_st;

        /*
          *-------------------------------------------------------------
          * Structure used to hold traffic counts being sent from the CM
          * to a TGUI.
          *-------------------------------------------------------------
          */
        struct One_bins_data_st
        {
             unsigned char bin[TC_MAX_COUNT_TYPES][TC_MAX_ENGINE_TYPES];
        };
        typedef struct One_bins_data_st One_bins_data_st;


3.13.2.6       Assigning RAs
The distribute_aircraft_to_ras() function distributes any unassigned (new) flights among
active RA(s) for each active TRACON. This function walks the aircraft tree and calls
distribute_one_aircraft() on each node (open slots are not distributed to RAs). This latter
function scans the connected RAs, assigns the aircraft to the RA with the least assigned
aircraft, and hands off the aircraft to the indicated RA by sending it a
CM_SET_RA_OWNERSHIP message, which includes the aircraft identifier.




                                              58                                          R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


3.13.2.7       Balancing RA Loads
CM periodically balances the aircraft assigned to each RA, for each active TRACON. Aircraft
are always assigned to a single RA only, and the load on each RA is maintained in balance
with the other RAs. The balance is maintained separately for two types of aircraft: planned
(Planned_ac_per_ra) and tracked (Tracked_ac_per_ra). See distribute_ac.c.

An aircraft is first assigned to an RA when its initial fight plan is received. Immediately after
an ADD_FLIGHT_PLAN is sent to all RAs, a single CM_SET_RA_OWNERSHIP is sent to the
assigned RA. Note that the ADD_FLIGHT_PLAN RA receives also causes the ownership, if
any, to be unset so that during a CM failover any previous RA ownership is forgotten. If the
aircraft changes state from planned to tracked or tracked to non-tracked, reassignment takes
place. When a reassignment or redistribution occurs, CM selects the least busy RA.

At redistribution time, CM checks if the aircraft need to be redistributed among the active
RAs. The check_and_redistribute_aircraft_to_ras() function checks the difference between the
RAs with the most and least assigned aircraft. If this difference exceeds an allowable limit,
the aircraft are redistributed among the RAs.

If the load is unbalanced, redistribute_aircraft_to_ras() is called. This function walks the
aircraft tree calling redistribute_one_aircraft() on each node. If the flight needs reassignment,
then redistribute_one_aircraft() calls assign_one_ac_to_ra() to find the RA with the least
assigned flights. The handoff_aircraft_to_ra() function performs redistribution.

Once it is determined that an aircraft has landed, CM generates and sends a
CM_UNSET_RA_OWNERSHIP message to the RA that has ownership of the aircraft to
remove the ownership. This prevents unnecessary processing by the owning RA for the
length of time the aircraft remains in the aircraft database after it has landed and before it is
removed from the aircraft database.

3.13.2.8       Checking for Landed Aircraft
Every 60 seconds, check_for_landed_aircraft() is called on each aircraft tree node (except
open slots) to check if the aircraft has landed at its destination airport. Landed aircraft are not
included in scheduling. check_for_landed_aircraft() determines if the plane has landed by
determining if it has been in the landed zone within a specified amount of time, and sends
AIRCRAFT_INACTIVE and AIRCRAFT_LANDED messages to all interested applications.

After the AIRCRAFT_LANDED message is sent, any landed aircraft‟s Ac_st is added to the
landed aircraft list (cm_recovery.c) by a call t rcv_add_landed_aircraft(). This list is
maintained to aid in DP failure recovery.

Next, CM scans the application table for DP processes, and the aircraft is removed if it is in
any DP‟s sequence constraint list.

Finally, for each active TRACON, CM calls rcv_del_landed_aircraft() to remove any aircraft
in the Landed_aircraft list that have been in the last for a prescribed time.




                                              59                                            R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009


3.13.2.9       Processing Hovering Aircraft
During the update cycle CM checks for hovering aircraft (hover_aircraft()). For TRACONs
that have hovering enabled, this processing checks for aircraft that have hovering completed,
aircraft that need to have hovering started, and aircraft that are already hovering. This check
is not done for open slots.

CM first determines if coordination time or EDCT time should be used for hovering
processing, and uses this time as the compare time. In order to determine if an aircraft has
completed hovering, CM checks if the maximum hovering duration has elapsed since the
compare time. If so, CM sets the aircraft‟s hover state to HOVER_END, sets the hover stop
time, and sends this information and the latest hover ETAs (AIRCRAFT_ETA_AVERAGED
message) to all TRACON TGUIs (cm_send_hover_etas()).

Next, CM checks for aircraft that can have hovering started by detemining hovering
eligibility which includes the following criteria:

   An internal departure (aka satellite airport) aircraft
   Aircraft has not been scheduled
   Aircraft has not departed
   Hovering is currently enabled for the aircraft not disabled by TGUI)
   Aircraft has not already completed a hovering cycle
   Aircraft has an RA assigned for receiving ETA messages

If a flight is eligible for hovering, CM compares the appropriate time against the current
time. If the aircraft is not currently hovering or has never hovered, CM sets the hovering
state so that the next ETA message sent to TGUI(s) indicates that hovering has started (that
is, the HOVER_START state). To keep track of how long the aircraft has been hovering (past
the estimated departure time), CM sets the time that hovering started for the aircraft. CM
then sends AMEND_FLIGHT_PLAN_RA (coordination time amendment) and
FLIGHT_PLAN_ETA_REQUEST messages to RA (cm_send_hover_msg()).

If the aircraft is already hovering (that is, is in the HOVER_ON state) and the hover ETA time
period has elapsed (Request_hover_eta_time) then an AMEND_FLIGHT_PLAN_RA
(coordination time amendment) and a FLIGHT_PLAN_ETA_REQUEST message are sent to
RA to generate new hover ETAs (cm_send_hover_msg()). If the hover request time has not
elapsed, then the current hover ETAs are sent to TGUI (cm_send_hover_etas()).

When CM receives an AIRCRAFT_ETA message as a result of a hovering ETA request, the
current hovering ETAs for the aircraft are updated and sent to TGUI. If the current hovering
state is HOVER_START, it is updated to HOVER_ON. If the current hovering state is
HOVER_END, hovering times are reset for the aircraft.

3.13.2.10      Updating Active Aircraft (Track Processing)
Track processing has three steps:

    1. Processing received (buffered) tracks



                                            60                                          R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

    2. Loading the tracks into the output buffers
    3. Broadcasting the tracks to CTAS processes

Each step is done for each active TRACON.

Processing Buffered Tracks
The update_active_aircraft() function updates the aircraft tree with any tracks received and
buffered       in         the        interval        between          aircraft       updates
(ism_update_cm_tree_with_buffered_tracks()).

Tracks arrive from ISM and are stored in the track buffer:

        static Track_data_st       g_buffered_track_data[MAX_AIRCRAFT];

As track messages come in from ISM, ism_put_track_message_into_buffer() populates the
track buffer.

The      track     buffer   is    processed      each    aircraft   update     period     by
ism_update_cm_tree_with_buffered_tracks(). This function calls ism_update_cm_tree() to
read track data from the track buffer, calling ism_process_a_track_message() to process each
individual track message. If the aircraft‟s TRACON identifier matches the current TRACON
identifier, then ism_process_a_track_message() does the following:

       Drops tracks to distant from the airport.
       Retrieves the track‟s corresponding Ac_st from the aircraft tree.
       If the flight isn‟t found, or the flight has landed, or the track is from a deleted data
        source, then return. Otherwise continues.
       Copies the new track message data to the aircraft‟s (Ac_st) flight information
       On reception of an aircraft‟s first track message, the following occurs:
             Calls send_fi_data_src_amendment() to forward amended flight information
                 (the data source) to interested CTAS processes. When the flight plan arrives,
                 the dsc_index is set to PROC_ISM. When the first track comes in the dsc_index
                 is changed to the track dsc_index.
             If an arrival and an ADIF track, sends the flight‟s runway to ADIF
                 (send_runway_to_dads())
             If an arrival and an ADIF track, sends the flight‟s sequence identifier to ADIF
                 (send_individual_seq_number_to_dads())
       Calls update_tree_with_active_aircraft() to update the aircraft tree for flights that are
        either active and have track information or flights that only have flight plan
        information.
       If a track message is received for a hovering aircraft, the aircraft can no longer be
        hovering so set hover state accordingly (update_aircraft_stop_hover()).

When each aircraft‟s track has been processed, the aircraft‟s Ac_st->track_was_broadcast is
set to false.




                                             61                                           R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

Loading the Output Buffers
Next, output buffers are loaded with the latest tracks. These buffers are defined in
cm_common.h. The twalk function load_output_buffer() manages processing which loads
the buffers for flights (excluding open slots) to be sent to other processes. This function does
the following:

       Counts the total number of flight plans (total_fp_category_count) for each flight plan
        category (increment_fp_category_count()). Open slots are not included in this count.
       If the aircraft is active and the track wasn‟t already broadcast
         Increments count of active aircraft with updated track information
             (Number_of_ac_updated)
         Increments active aircraft count (active_fp_category_count)
         If aircraft had been dead reckoned and the aircraft has not entered the landed
             zone, then unset dead reckoning, and inform all the P/TGUIs by sending them an
             AIRCRAFT_DATA_NORMAL message (send_global())
         If the aircraft data is ready (current flight plan, not landed, and other conditions
             are met), then load the buffers (load_buffer())
                  Increments the send_fp_category_count
                  Filters tracks according to various conditions and process, and puts the
                     track in the appropriate buffer if conditions are met
             Also set Ac_st->track_was_broadcast to true
         If the aircraft track data is old (is_lost_track_data()), and the aircraft isn‟t in the
             landed zone, and the aircraft isn‟t already flagged as dead reckoned (that is, it
             hasn‟t already sent an AIRCRAFT_DEAD_RECKONED message), then set the
             aircraft‟s      dead-reckoned       state      to     true    and     send        an
             AIRCRAFT_DEAD_RECKONED message to all T/PGUIs.

Broadcasting the Tracks
After the track output buffers have been loaded, send_aircraft() distributes the buffered
tracks to the CTAS processes. This function constructs a SENDING_AIRCRAFT message for
each output buffer that has content, and sends the message to the target CTAS processes.
Except for tracks sent to CAP, all tracks are filtered by flight plan type. CAP tracks are
unfiltered.

3.13.2.11      Processing Expired Open/Blocked Slots and Inactive Aircraft
At update time and for each active TRACON, weed_out_old_aircraft() supervises aircraft
and open or blocked slot removal from the aircraft tree.

Expired open/blocked slots are added to the delete aircraft list (delete_ac_list[]), and inactive
aircraft are added to the inactive aircraft list (inactive_ac_list[]) by the twalk function
mark_deleteable_aircraft().

Expired Open/Blocked Slots
If any open/blocked slots have been moved to the delete aircraft list, delete_aircraft() is
called to remove them. For each deletion, remove_flight_plan() (and remove_aircraft()) does
the following:



                                             62                                           R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009



   Records pertinent event information into the flight‟s occurred list node if it‟s a countable
    aircraft , that is, not for blocked slots (tc_record_occurred_events_before_delete()).

   Turns off Host-side metering display (cmm_meter_removal_by_ac()) by sending a
    remove from Metering (IE_CTAS) message to any Hosts (local or adjacent) displaying the
    aircraft when any of these Hosts are in Two Way communications and actively Metering.

   If   necessary,   clears   any     proposed            meter      fix   that    is     assigned
    (cm_send_meter_fix_balance_clear()).

   Adds the aircraft to the inactive aircraft list for later inactive aircraft processing
    (set_inactive()). This includes informing all interested CTAS applications of the aircraft‟s
    state    change       to    inactive    via     an     AIRCRAFT_INACTIVE          message
    (cm_send_aircraft_inactive ()). This processing isn‟t done for open slots.

   Relinquishes RA assignment for the flight (reassign_ac_to_ra()).

   Clears the fix indentifiers (mfu_clear_fid()).

   If a blocked slot, resets the blocked slot (bs_reset_slot()).

   If an open slot, resets the open slot and sends a DELETE_FLIGHT_PLAN to interested
    processes forward_flight_plan_delete(). For open slots processing now finishes; the
    following processing is done for other that open slots.

   If the delete is not a result of a Host clear strip message, then sets the TGUI and DP flight
    plan status for the flight to FP_NEW, leaving RA and PGUI flight plan status as is
    (cm_send_set_fp_status()).

   Sends a DELETE_FLIGHT_PLAN to all CTAS processes who should get it, based on the
    aircraft flight plan category. First checks to see if the aircraft has landed, and if so, first
    sends an AIRCRAFT_LANDED message.

   Clears     the      flight‟s     fix,    STA,          and      overcrossing         information
    (update_aircraft_initialize_crossing_info()).

   Removes the flight from metering (cmm_save_and_check_mrp_info()).

   Removes the aircraft‟s node from the aircraft tree (tdelete()).



Inactive Aircraft
Next, aircraft entered into the inactive list are processed. The set_inactive_aircraft() function
calls set_inactive() on each entry in the inactive aircraft list, which updates the aircraft‟s state



                                               63                                             R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

to reflect its inactivity, and notifies any interested applications of this state change via an
AIRCRAFT_INACTIVE message(cm_send_aircraft_inactive ()). Since the aircraft state has
changed to inactive CM checks if RA reassignment is necessary (reassign_ac_to_ra()). This
processing is not done for open slots.

3.13.2.12      Updating Aircraft ETA Status
The update cycle next walks the aircraft tree calling update_eta_status_from_twalk() on each
node to determine if each aircraft‟s ETA status needs updating (Ac_st->eta_status). ETA
status can be one of the following values:

        typedef enum {
            NO_ETA = 0,
            OLD_ETA = 1,
            ETA_OK = 2
        } Eta_status_type;

ETA status changes from ETA_OK to OLD_ETA only if the aircraft has been active for a
prescribed time period and there has not been an ETA update from an RA for a prescribed
time period. NO_ETA is the initialized value.

3.13.2.13      Two-Way Communication and Meter Processing
Two Way communications between CTAS and multiple Host centers is possible with the
implementation of Adjacent Center Metering (ACM) processing. Two-way communication
connections are available for a local “primary” Host center and some number of adjacent
Host Centers. Currently, the use or non use of the –two_way command line option for HDIF
controls whether Two Way communications is accepted for any and all Host centers. When
HDIF uses the –two_way command line option it is assumed that all two-way Host centers
communicating with HDIF will accept two-way messages from CTAS. When HDIF does not
use the –two_way command line option it is assumed that all two-way Host centers
communicating with HDIF will not accept messages originating from CTAS.

When HDIF uses the –two_way command line option, CTAS two-way meter states are
processed by two_way_proc_twoway_change().

When CM is started in Operational mode (not using the –R command line option) CTAS two-
way status for any given eligible Host center can only be toggled enabled/disabled from the
M&C. Each Host Center two-way state is toggled individually and doing so has no effect on
any other Host Center. Successfully toggling a two-way state to be enabled does not
automatically enable metering for that Host Center, however, toggling a two-way state to be
disabled does automatically disable metering for that Host Center when the metering state is
currently enabled. One single message, SOURCE_TWOWAY_METER_CHANGE, is used to
indicate all successful two -way state changes to all interested processes for all eligible Host
Centers.

The metering state for any given eligible Host center can only be toggled on/off from
authorized TGUI(s), as adapted, from the <F1> “Status and Schedule” panel. Toggling the
metering state for a given Host Center has no effect on any other Host Center, nor does it
affect the given Host‟s two-way state.


                                             64                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009



Successfully toggling any Host‟s metering state to on makes all flights eligible for metering
(given all other metering criteria are met), and eligible to have each successfully metered
flight„s information sent to the given Host Center, and only that center, based on
MRP/FPA/destination-specific adapted values within the meter reference points adaptation.

The metering header message (IX_CTAS) is sent to the given Host center to indicate that
metering information will be sent from CTAS via an individual IM_CTAS message for each
actively metered MRP/FPA combination for every aircraft actively metering and adapted to
have its metering information sent to the specific Host Center.

Toggling any Host‟s metering state off sends an IE_CTAS to that given Host Center for each
MRP for which an IM_CTAS message was previously sent for every aircraft actively being
metered and having that metering information sent to that Host Center to ultimately have all
metering information removed from the HCS display of that Host Center. If, after toggling a
given Host center Metering state off, there continues to be at least one Host Center currently
actively metering, then meter determination processing continues. However, if after toggling
a given Host center metering state off there are no other Host centers actively metering then
meter determination processing is discontinued for all aircraft until at least one Host center
toggles their metering state on and becomes actively metering.

The SOURCE_TWOWAY_METER_CHANGE message is used to indicate all successful
metering state changes to all interested processes for all eligible Host centers. The current
Two Way and Metering status for all eligible Host centers can be observed from the CM
<F3> “Two Way & Metering Status” panel.

When CM is started in developmental mode (CM is using the –R command line option) the
CTAS Two Way state and CTAS Metering state for any given eligible Host center can also be
toggled enabled/disabled and on/off respectively from the CM <F3> “Two Way & Metering
Options” panel. Performing the toggling on this display has the same effect and limitations
as performing the toggle from the M&C window or a TGUI <F1> “Status and Schedule”
panel.

The following paragraphs describe two-way and metering state toggling for arrivals and
non-arrivals (EDC), and it‟s affect on what is displayed on target Host displays (DSRs).

Toggling a specific airport to enable or disable for metering only enables or disables flights
assigned to arrive at that specific airport within that specific TRACON group for which that
airport is adapted. Other airports within the same TRACON group and other TRACON
groups adapted for the given Center are not affected.

Example:

Data Source     TRACON        Airport            Airport
--------------------------------------------------------
ZMA             MIA           MIA                FLL




                                            65                                         R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

If ZMA Two Way is enabled, ZMA metering is enabled, and both airports are enabled then
all flights assigned to arrive at either MIA or FLL adapted to be sent to ZMA will be sent to
the ZMA Host DSR. If FLL airport is disabled, only the flights assigned to arrive at FLL that
are adapted to be sent to ZMA will be removed from the ZMA Host DSR and no longer be
eligible for metering. All flights assigned to arrive at MIA and adapted to be sent to ZMA
will continue to be sent to the ZMA Host DSR.

Example:

Data Source         TRACON        Airport            Airport
------------------------------------------------------------
ZMA                 MIA           MIA                FLL
ZJX                 MIA           MIA                FLL

If ZMA and ZJX two-way communication is enabled, ZMA and ZJX metering is enabled, and
both airports are enabled for both data sources (ZMA and ZJX), then, all flights assigned to
arrive at either MIA or FLL, and adapted to be sent to ZMA are sent to the ZMA Host DSR
and all flights assigned to arrive at either MIA or FLL adapted to be sent to ZJX are sent to
the ZJX Host DSR. If FLL airport is disabled for only the ZJX data source, then only the
flights assigned to arrive at FLL that are adapted to be sent to ZJX are removed from the ZJX
Host DSR and are no longer for metering. All flights assigned to arrive at either MIA or FLL
and adapted to be sent to ZMA will continue to be sent to the ZMA Host DSR and all flights
assigned to arrive at MIA adapted to be sent to ZJX will continue to be sent to the ZJX Host
DSR.

Toggling a specific meter data source, ZMA for example, to enable or disable for metering
only enables or disables flights assigned to arrive at any and all airports within that specific
TRACON group for which those airports are adapted. Other TRACON groups adapted for
the given Center are not affected.

Example:

Data Source         TRACON        Airport            Airport
------------------------------------------------------------
ZMA                 MIA           MIA                FLL
ZJX                 MIA           MIA                FLL

If ZMA and ZJX two-way communication is enabled, ZMA and ZJX metering is enabled, and
both airports are enabled for both data sources ZMA and ZJX, then, all flights assigned to
arrive at either MIA or FLL adapted to be sent to ZMA are sent to the ZMA Host DSR and all
flights assigned to arrive at either MIA or FLL adapted to be sent to ZJX are sent to the ZJX
Host DSR. If ZMA data source is disabled, all the flights assigned to arrive at either MIA or
FLL that are adapted to be sent to ZMA are removed from the ZMA Host DSR and are no
longer eligible for metering. All flights assigned to arrive at either MIA or FLL adapted to be
sent to ZJX will continue to be sent to the ZJX Host DSR.




                                             66                                          R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

Example:

Data Source            TRACON        Airport
--------------------------------------------
ZTL                    A80           ATL
ZME                    A80           ATL

ZTL                      CLT             CLT
ZME                      CLT             CLT

If ZTL and ZME two-way communication is enabled, ZTL and ZME metering is enabled for
TRACON A80 and ZTL and ZME metering is enabled for TRACON CLT , and ATL and CLT
airports are enabled for both data sources ZTL and ZME for both TRACON groups A80 and
CLT, then, all flights assigned to arrive at either ATL or CLT adapted to be sent to ZTL are
sent to the ZTL Host DSR and all flights assigned to arrive at either ATL or CLT adapted to
be sent to ZME are sent to the ZME Host DSR. If ZME data source is disable only for the
CLT TRACON group, then all the flights assigned to arrive at CLT that are adapted to be
sent to ZME are removed from the ZME Host DSR and are longer eligible for metering. All
flights assigned to arrive at CLT, within the CLT TRACON group, adapted to be sent to ZTL
will continue to be sent to the ZTL Host DSR. All flights assigned to arrive at ATL, within the
A80 TRACON group, adapted to be sent to ZTL will continue to be sent to the ZTL Host
DSR. All flights assigned to arrive at ATL, within the A80 TRACON group, adapted to be
sent to ZME will continue to be sent to the ZME Host DSR.

Toggling a specific data source's Two Way state on M&C to enable or disable will enable or
disable all flights assigned to arrive at any and all airports for all TRACON groups for the
specific data source that was toggled. Metering messages intended to be forwarded to other
connected data sources are not affected.

Example:

Data Source            TRACON        Airport
--------------------------------------------
ZTL                    A80           ATL
ZME                    A80           ATL

ZTL                      CLT             CLT
ZME                      CLT             CLT

If ZTL and ZME two-way communication is enabled, ZTL and ZME metering is enabled for
TRACON A80 and ZTL and ZME metering is enabled for TRACON CLT , and ATL and CLT
airports are enabled for both data sources ZTL and ZME for both TRACON groups A80 and
CLT, then, all flights assigned to arrive at either ATL or CLT adapted to be sent to ZTL are
sent to the ZTL Host DSR and all flights assigned to arrive at either ATL or CLT adapted to
be sent to ZME are sent to the ZME Host DSR. If ZME two-way state is disabled, all the
flights assigned to arrive at CLT and ATL that are adapted to be sent to ZME are removed
from the ZME Host DSR and are longer eligible for metering. ZME is disabled for all
TRACON groups. All flights assigned to arrive at ATL or CLT adapted to be sent to ZTL
will continue to be sent to the ZTL Host DSR for all TRACON groups.




                                            67                                          R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

Toggling a specific airport (EDC) to enable or disable for metering only enables or disables
flights assigned to arrive at that specific airport, within that specific TRACON group for
which that airport is adapted, that are associated with the specific meter point for which the
airport is listed. Other airports within the same TRACON group are not affected. Other
airports associated with the same meter point are not affected. The same airport name
associated with different meter points are not affected.

Example:

Data Source   TRACON   Meter Point   Airport   Airport   Airport   Airport   Airport
------------------------------------------------------------------------------------
ZTL           MPA      HU1           HOU       IAH
ZTL           MPA      HU2           HOU       IAH
ZTL           MPA      DC3           ACY       ALB       ISP        RDU      RIC
ZTL           MPA      DC4           ACY       ALB       ISP         RDU     RIC
ZTL           MPA      ID7           CLE

If ZTL two-way communication is enabled, ZTL metering is enabled for TRACON group
MPA, and metering is enabled for all listed meter points and all listed airports, then, all
flights assigned to one of any of the listed meter points and that are assigned to arrive at any
of the listed airports for the assigned meter point, and are adapted to be sent to ZTL are sent
to the ZTL Host DSR. If the IAH airport listed under the HU1 meter point is disabled, only
flights arriving at IAH that are assigned the HU1 meter point are removed from the ZTL
Host DSR and are no longer eligible for metering. All flights arriving at IAH that are
assigned the HU2 meter point will continue to be enabled and to be sent to the ZTL Host
DSR. All flights arriving at all other meter point/airport combinations listed will continue to
be enabled and to be sent to the ZTL Host DSR.

Toggling a specific meter point (EDC) to enable or disable for metering only enables or
disables flights assigned to that specific meter point regardless of the airports associated with
that meter point. Other airports within the same TRACON group are not affected. Other
airports within other TRACON groups are not affected. All other meter points listed are not
affected.

Example:

Data Source   TRACON   Meter Point   Airport   Airport   Airport   Airport   Airport
------------------------------------------------------------------------------------
ZTL            MPA     HU1           HOU       IAH
ZTL            MPA     HU2           HOU       IAH
ZTL            MPA     DC3           ACY       ALB       ISP        RDU       RIC
ZTL            MPA     DC4           ACY       ALB       ISP        RDU       RIC
ZTL            MPA     ID7           CLE

If ZTL two-way communication is enabled, ZTL metering is enabled for TRACON group
MPA, and metering is enabled for all listed meter points and all listed airports, then, all
flights assigned to one of any of the listed meter points and that are assigned to arrive at any
of the listed airports for the assigned meter point, and are adapted to be sent to ZTL are sent
to the ZTL Host DSR. If HU2 meter point is disabled, only the flights that are assigned to the
HU2 meter point are removed, regardless of their arrival airport, from the ZTL Host DSR



                                             68                                           R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

and are no longer eligible for metering. All flights assigned to all other listed meter points
arriving at all associated listed airports will continue to be enabled and to be sent to the ZTL
Host DSR.

Toggling the primary center data source metering (EDC) to enable or disable for metering
only enables or disables metering for this specific TRACON group and within this TRACON
group all flights assigned to any meter point listed, regardless of the airports associated with
that meter point. Other airports within other TRACON groups for the primary center data
source are not affected.

Example:

Data Source   TRACON   Meter Point Airport    Airport   Airport   Airport   Airport
------------------------------------------------------------------------------------
ZTL           MPA      HU1          HOU       IAH
ZTL           MPA      HU2          HOU       IAH
ZTL           MPA      DC3          ACY       ALB       ISP        RDU      RIC
ZTL           MPA      DC4          ACY       ALB       ISP        RDU      RIC
ZTL           MPA      ID7          CLE

If ZTL two-way communication is enabled, ZTL metering is enabled for TRACON group
MPA, and metering is enabled for all listed meter points and all listed airports, then, all
flights assigned to one of any of the listed meter points and that are assigned to arrive at any
of the listed airports for the assigned meter point, and are adapted to be sent to ZTL are sent
to the ZTL Host DSR. If the primary Center data source is disabled, ZTL in this example,
then all flights within this TRACON group are removed from the ZTL Host DSR and are no
longer eligible for metering. All flights for all other TRACON groups will continue to be
enabled and to be sent to the ZTL Host DSR.

Toggling the primary center data source Two Way state on the M&C (EDC) to enable or
disable enables or disables metering for all TRACON groups for the primary center data
source, ZTL in this example. For the EDC specific example the results would be the same as
the toggling of the primary center data source metering state, listed directly above.

3.13.2.13.1    Host Display Parameters
Adaptable Host meter list display parameters for each meter list display facility (local or
adjacent) are:
 Display/non-display of frozen/non-frozen aircraft
 Display/non-display of indicator for frozen/non-frozen aircraft
 Rounding/truncation of delay value

Adaptable Host meter list display parameters for each adapted metering reference point are:
 Meter list display interval control value (TIME, DIST, BOTH)
 Meter list display drop control value (TIME, DIST, BOTH)
 Meter list display time values (add time followed by drop time)
 Meter list display distance value (add distance followed by drop distance)




                                             69                                          R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

Aircraft are eligible for display on Host meter lists if the flight matches the frozen/nonfrozen
adaptation indication, and the following are true:
 The flight‟s ETA or distance, depending on adaptation, is calculated to be inside the
   meter list display interval value
 The flight has not yet reached the meter reference point, if just by time the flight‟s ETA
   hasn‟t reached current time, or the flight‟s STA or distance, depending on adaptation, has
   not yet reached the meter list drop value.
TMA can selectively block Host meter list broadcast by airport.

When an aircraft (frozen or non-frozen) is eligible for Host meter list display, its display
eligibility does not change if its ETA or distance (adaptation dependent) is calculated to be
outside the meter list display interval value.

This ends aircraft update cycle processing. The following section describes how CM
processes messages received from the other TMA processes.

3.14 Application Processing
This section describes processing for each application type that connects to CM. The
following topics are described for each application:

       Startup/initialization processing – After receiving an initial message from each
        application that identifies the application (usually SEND_HOST_NAME), CM
        performs initialization processing for that application. This processing is described
        for each application type.

       General message processing – Each application communicates with CM and other
        applications (via CM) with messages. The messages received and subsequent
        processing and message sending/forwarding are described.

       Shutdown/cleanup processing – When an application shuts down, shutdown and
        cleanup processing is performed for each application type. This processing begins
        when CM receives an APP_CLEANUP_SOCKET message from the M&C, which
        eventually results in a call to cm_close(). This function determines if the application to
        be closed is a TRACON-specific process (DP, RA, PGUI, TGUI, or GUIR). If the
        application is TRACON-specific, then all shared memory and local pointers are set to
        point to the TRACON group that matches the process CSCI that is being closed;
        otherwise (ISM, HDIF, ADIF) cm_close() uses the first available TRACON group it
        finds. Then, cm_close() calls an application-specific shutdown function (for example,
        cm_ra_close(), cm_dp_close) to handle the peculiarities of each applications
        shutdown/cleanup processing.

3.14.1 RA Processing
RA calculates and provides various ETAs (for example, meter fix ETAs); generates detailed
route and control conditions; sends aircraft state information, route, and control conditions to
the Trajectory Synthesizer (TS); receives and processes trajectories and flight times from TS;
and sends ETAs, routes, and trajectories to other CTAS applications.



                                              70                                           R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



CM performs ETA averaging (also known as ETA smoothing) for RA. This entails saving a
number of most recent meter fix and runway ETAs sent from RA, and sending back an
averaged ETA in an AIRCRAFT_ETA_AVERAGED message. This processing starts when
RA sends CM an AIRCRAFT_ETA message. The CM message handler calls eta_update()
which populates the aircraft structure with (non-averaged) information contained within the
message (eta_update_ac_with_data()).

For non-PROPOSED aircraft, eta_update() performs meter fix (eta_update_mfx()) and
runway (eta_update_rwy()) ETA averaging. This averaging includes the following:

   Updates the OETA array (ac->filter_oetamf_array[]) and generate OETA averages for
    both CTAS and scheduling meter fixes.
   If the aircraft crossed center and delay reporting is ON, then updates the delay reporting
    OETA array (ac->drs_filter_oetamf_array[]) and generates CTAS and scheduling DRS
    average OETAs.
   Updates the meter fix nominal ETA array (ac->eta_average.meter_fix_nominal_eta[]) and
    generates nominal ETA averages for both CTAS and scheduling meter fixes.
   Updates       the    final   approach     fix    (FAF)    nominal     ETA     array    (ac-
    >eta_average.faf_nominal_eta[]) and generates an average FAF nominal eta.
   Updates and generates averages for the following runway threshold ETAs: Runway
    threshold OETA (ac->filter_oeta_array[runway]), threshold slow ETA (ac-
    >eta_average.threshold_slow_eta[]),          threshold       nominal       ETA         (ac-
    >eta_average.threshold_nominal_eta[]),           threshold       fast      ETA         (ac-
    >eta_average.threshold_fast_eta[]).

For PROPOSED aircraft, eta_update() updates the aircraft eta_average structure without
averaging ETA values by calls eta_update_mfx_proposed() and eta_update_rwy_proposed().
These functions simply update the eta_average structure with values from the
AIRCRAFT_ETA message.

3.14.1.1       RA Connection and Initialization
As with most CTAS applications, RA sends a SEND_HOST_NAME to identify itself to CM,
which then begins initializing an RA connection. This message is handled by cm_ra_init(),
and does the following for the new RA:

   Verifies    the     TRACON         information   before     allowing   a    connection
    (cm_app_verify_connection()).
   Sets the RA‟s weather status to CLIENT_WTHR_UNUSED (cm_app_wthr_status_set())
   Sends the current airport configuration in an INIT_CONFIG message to the newly-
    connected RA (initialize_configuration_info())
   Sends current time information to the new RA (initialize_time_info()
   Sends weather information to weather-aware processes (initialize_weather_info())
   Sends satellite airport information (cm_dep_sd_category_send())
   Sends the active status (SUA_STATUS_LIST message) for all Special Use Airspace for the
    TRACON group of the connecting RA (cm_send_sua_status())



                                            71                                          R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009


   Sends all flight plans (twalk function send_all_flight_plans())
   Send AC_CROSSING_INFO and/or AC_CROSSING_TIME messages if necessary
    (send_over_crossing_info()). This message is not sent for open slots.
   Sets the RA‟s status to active
   Redistribute aircraft among RAs if necessary (check_and_redistribute_aircraft_to_ras()
   Send ETA request message to RA for all inactive, non-open slot aircraft of the current
    TRACON that haven‟t had an ETA yet computed (twalk function
    send_request_for_fp_eta_for_all_remaining_ac())
   Send PGUI options for each aircraft excluding open slots (twalk function
    ra_initialize_pgui_options()). Options are as follows:
     User Constraints (PGUI_USER_CONSTRAINTS message)
     Auxiliary waypoints (PGUI_AUX_WAYPOINTs message)
     Route display (PGUI_RA_AIRCRAFT_ROUTE and PGUI_RA_AIRCRAFT_ROUTE
        messages)
     New sector owner (PGUI_NEW_OWNER message)
   Send new meter fix ETA information if necessary (twalk function
    twalk_send_meter_fix_balance()). This information is not sent for open slots.

3.14.1.2      RA Message Handling
The following paragraphs describe how CM handles RA messages.

CROSSED_CENTER_MSG: This message is handled by cm_ra_crossed_center_msg(),
which sets the aircraft‟s crossed_center flag to TRUE, and forwards the message to all TGUIs
via cm_snd_tgui().

WATCH_AIRCRAFT: Updates the CM watch window.

AIRCRAFT_ETA: This message is handled by cm_ra_aircraft_eta(). ETA information looks
like this:
        /*
          * Structure for transmitting a full set of ETAs and ground speeds
          * for a single aircraft from RA to CM.
          */
        typedef struct Aircraft_eta_comm_st
        {
             char           acid[ID_LENGTH];
             int            gate;
             int            airport;
             int            configuration;
             Dep_time_type dep_time_used;
             Time_type      track_time;
             short          fp_status;
             Bool_type      active;
             Eta_generation_type     eta_type;
             Hover_eta_info_st       hover_eta_info;
             float          meter_fix_distance;
             Arc_etas_st    arc [MAX_ARC_TYPES];
             Time_type      meter_fix_nominal_eta        [MAX_METER_FIXES_PER_GATE];
             float          meter_fix_ground_speed       [MAX_METER_FIXES_PER_GATE];
             Time_type      original_ctas_meter_fix_time [MAX_METER_FIXES_PER_GATE];
             Time_type      drs_mf_oeta                  [MAX_METER_FIXES_PER_GATE];
             Time_type      runway_oeta                  [MAX_RUNWAYS];



                                           72                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

            Time_type      faf_slow_eta                      [MAX_RUNWAYS];
            Time_type      faf_nominal_eta                   [MAX_RUNWAYS];
            Time_type      faf_fast_eta                      [MAX_RUNWAYS];
            float          faf_ground_speed                  [MAX_RUNWAYS];
            float          faf_distance                      [MAX_RUNWAYS];
            Time_type      threshold_slow_eta                [MAX_RUNWAYS];
            Time_type      threshold_nominal_eta             [MAX_RUNWAYS];
            Time_type      threshold_fast_eta                [MAX_RUNWAYS];
            float          threshold_ground_speed            [MAX_RUNWAYS];
            float          threshold_distance                [MAX_RUNWAYS];
            Bool_type      using_threshold_eta               [MAX_RUNWAYS];
            Bool_type      using_faf_eta                     [MAX_RUNWAYS];
        } Aircraft_eta_comm_st;

The message handler does the following:

   Unpacks the ETA message (uppack_aircraft_eta_message()), and locates the given aircraft
    in the aircraft tree (find_tree_ac()).
   Handles any trajectories attached to the end of the message (cm_ra_handle_trajectory()).
   If the message contains hover ETAs, then updates the aircraft‟s hover time and state.
    Builds and sends an AIRCRAFT_ETA_AVERAGED message, containing hovered ETAs,
    to all TRACON group TGUIs. If the aircraft the hover state is stopped (HOVER_END),
    resets the aircraft‟s hover start/stop times so it can be reconsidered for ETA hovering
    (update_aircraft_reset_hover_ac()); if the aircraft‟s hover state is HOVER_START, then
    it‟s hover state is moved to HOVER_ON. Determines whether the hovering aircraft‟s
    display point ETA has adjustment has exceeds a future airport configuration change
    time; if it does exceed then the new ETAs are sent to DP to force an amendment for this
    new airport configuration.
   For non-hovered ETA types, calls eta_update() to check the validity of the message, and if
    valid, some of the contained ETAs are used to update the specified aircraft‟s data. This
    function calls the following functions:
     eta_update_ac_with_data() – Handles populating the aircraft‟s structure with non-
         averaged items (for example, meter fix nominal ETA, meter fix ground speed).
     eta_update_mfx() - Handles averaging meter fix ETAs and updating the aircraft tree
     eta_update_rwy () - Handles averaging runway ETAs and updating the aircraft tree
   set_stored_etas_and_ground_speeds() - builds the AIRCRAFT_ETA_AVERAGED
    message containing estimated ground speeds and average ETAs.
   If a suggested departure time message was just received from DP, an
    AIRCRAFT_ETA_AVERAGED message is forwarded to all TGUIs only; otherwise, the
    AIRCRAFT_ETA_AVERAGED message is forwarded to all TGUIs and to DP. If the ETA
    message is for an internal departure flight scheduled into an open slot, the
    AIRCRAFT_ETA_AVERAGED message is sent to TGUIs only. Blocked slot ETAs are not
    forwarded to CAP.
   For EDC mode, if the ETA message is for the flight‟s most downstream MP then the
    handler sends DOWNSTREAM_COORD_INFO to an arrival RA.

PRIORITY_AIRCRAFT_RESCHEDULE, REMOVE_PRIORITY_AIRCRAFT: These messages
are processed by cm_ra_process_priority_aircraft(), which clears ETA and Original Estimated
Time of Arrival (OETA) averaging time filter arrays and variables (reset_time_filters()), and
forwards the message to all DPs and TGUIs (cm_snd_dp(), cm_snd_tgui()).


                                            73                                         R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009



RA_GATE_BALANCE_ETA: This message is processed by cm_ra_gate_balance_eta(), which
forwards meter fix, final approach, and runway ETAs to all TGUIs.

RECEIVE_OETA_FREEZE: This message is processed by cm_ra_receive_oeta_freeze(). The
message contains the OETA for an aircraft. Processing sets the aircraft‟s (Ac_st) runway
OETA to the time from the message, sets the filter count so the OETA is frozen, and sets the
OETA filter array to the time from the message. The message is then forwarded to all TGUI
instances.

RA_AIRCRAFT_ROUTE: This message is processed by cm_ra_aircraft_route(), which
forwards the message (containing estimated route information) to all PGUIs.

RA_AIRCRAFT_APPROACH_SEGMENTS:                            Processed                        by
cm_ra_aircraft_approach_segments(), which forwards the message to all PGUIs.

RA_INVALID_AIRCRAFT_ROUTE: Processed by cm_ra_invalid_aircraft_route(). If the
aircraft is a blocket slot, the blocked-slot is removed from the CM database; otherwise the
message is forwarded to all PGUIs.

FLIGHT_PLAN_ROUTE: Processed by cm_ra_flight_plan_route(), which forwards the
message to all PGUIs.

HOST_AK_ROUTE: Processed by cm_ra_host_ak_route(), which forwards the message to all
PGUIs.

AIRCRAFT_CAPTURE_VOR: Processed by cm_ra_aircraft_capture_vor(), which forwards
the message to all PGUIs.

DISPLAY_GRAPHIC_ON_PGUI: Processed by cm_ra_display_graphic_on_pgui(), which
forwards the message to all PGUIs. This message is used to display flight plan and converted
route (AK) information on PGUIs.

RA_WTHR_RECEIVED: Processed by cm_ra_wthr_received(). On receiving this message, if
the RA‟s weather status is CM_WTHR_CURRENT, it remains so; if the RA‟s weather status
is CLIENT_WTHR_INIT_SENT, it is set to CLIENT_WTHR_INIT_ACK; otherwise it is set to
CLIENT_WTHR_UPDATE_ACK. The RA‟s weather update count is also decremented. CM
and application weather status are defined as follows:

        /* defines status of cm weather */
        typedef enum {
            CM_WTHR_CURRENT = 0,
            CM_WTHR_PROC_INIT,
            CM_WTHR_UPDATE,
            CM_WTHR_UPDATE_PENDING,
            CM_WTHR_REVERT,
            CM_WTHR_REVERT_PENDING,
            CM_WTHR_NONE
        } Cm_wthr_status ;




                                           74                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009



        /* defines current weather status of clients */
        typedef enum {
            CLIENT_WTHR_NO_USE = 0,     /* client doesn't use weather */
            CLIENT_WTHR_CURRENT,
            CLIENT_WTHR_UPDATE_ACK,
            CLIENT_WTHR_UPDATE_SENT,
            CLIENT_WTHR_UPDATE_FAILED,
            CLIENT_WTHR_REVERT_SENT,
            CLIENT_WTHR_REVERT_ACK,
            CLIENT_WTHR_REVERT_FAILED,
            CLIENT_WTHR_UNUSED,
            CLIENT_WTHR_NONE,
            CLIENT_WTHR_INIT_SENT,
            CLIENT_WTHR_INIT_ACK,
            CLIENT_WTHR_INIT_FAILED
        } client_wthr_status ;

RA_WTHR_FAILED: Processed by cm_ra_wthr_failed(). This message indicates that the
weather data RA received was invalid. If the RA‟s weather status is
CLIENT_WTHR_INIT_SENT, then this message resets it to CLIENT_WTHR_INIT_FAILED.
Otherwise   this  message     resets    the       RA‟s     weather  status     to
CLIENT_WTHR_UPDATE_FAILED, and the update count is decremented.

RA_WTHR_REVERT_COMPLETE: Processed by cm_ra_wthr_revert_complete(). This
message indicates that RA has successfully reverted to a previous weather file. Sets the RA‟s
weather status to CLIENT_WTHR_REVERT_ACK, and decrements the update counter.

RA_WTHR_REVERT_FAILED: Processed by cm_ra_wthr_revert_failed(). This message
indicates that RA has failed when attempting to revert to a previous weather file. Sets the
RA‟s weather status to CLIENT_WTHR_REVERT_FAILED, and decrements the update
counter.

PGUI_USER_CONSTRAINTS:          Processed      by    cm_ra_pgui_user_constraints().          If
MISSED_APPROACH_MODE              is       being       toggled       off,   then              a
CD_MISSED_APPROACH_CANCEL               message       is    sent      to  ADIF,             via
send_id_message_to_dads(), which contains the following information:

        /* Used for ac idents, flight plan cancels and ac resets */
        struct DADS_ac_identifier_st
        {
            char id[DADS_SIZE_ID];
            int center_id;
            int beacon;
            int fdf;
        };
        typedef struct DADS_ac_identifier_st DADS_ac_identifier_st;

If MISSED_APPROACH_MODE is being toggled on, then a CD_MISSED_APPROACH
message is sent to ADIF.

        typedef struct
        {
                msg_hdr_st                msg_hdr;



                                           75                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

                char                      acid[ID_LENGTH];
                User_constraint_st        user_constraints;
        } set_user_constraint_st;

        /**********************************************************************
        Bitmasks used by the cm, gui, ra, and pfs to signal which controller
        modes are currently enabled.
        ***********************************************************************/

        typedef enum {
            PRIORITY_MODE = 1,
            MISSED_APPROACH_MODE = 2,
            WAYPOINT_CAPTURE_MODE = 4,
            PATH_STRETCH_MODE = 8,
            CRUISE_ADVISORY_LOCKED_MODE = 16,
            DESCENT_ADVISORY_LOCKED_MODE = 32,
            SUPPRESS_DESCENT_SPEED_MODE = 64,
            SUPPRESS_CRUISE_SPEED_MODE = 128,
            SUPPRESS_FP_FOR_WPT_CAPTURE_MODE = 256,
            NON_ARRIVAL_WAYPOINT_CAPTURE_MODE = 512
        } Controller_directed_mode_type;

AC_CROSSING_TIME: This message is handled by cm_ra_crossing_msg(), and contains a
meter fix identifier, type, and crossing time (Crossing_time_ipc_st). Meter fixes are defined
as follows:

       typedef enum Fix_crossing_type
       {
           CROSS_INV = -1,
           CROSS_O4A = 0,   /* Outer four arc */
           CROSS_O3A       /* Outer three arc */
           CROSS_OOA,       /* Outer-outer arc */
           CROSS_OMA,       /* Outer arc */
           CROSS_DPT,       /* Meter fix display */
           CROSS_SCH,       /* Meter fix scheduling */
           CROSS_HDA        /* AutoSwap holding arc */
} Fix_crossing_type;
Crossing information is saved into the flight database, and the message is forwarded based
on meter fix type:

       Scheduling meter fix - All DPs, RAs, TGUIs, PGUIs.
       Display point meter fix – All DPs, RAs, TGUIs, PGUIs.
       Outer arc – All DPs and PGUIs.
       Outer-outer and outer-outer-outer arc – Not forwarded.
       Holding arc – All DPs.

For EDC mode, if the received crossing time is for the flight‟s most downstream MP, then
CM sends a DOWNSTREAM_COORD_INFO message to an arrival RA. This information is
only sent if the flight has an arrival clone.

AC_CROSSING_INFO: This message is handled by cm_ra_crossing_info_msg() and contains
predicted intersection information for a specified metering reference point. Messages
specifying display point or scheduling crossing information are forwarded to DP and RAs;
messages specifying one of the other reference point types are sent to RAs only.



                                           76                                         R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009


3.14.1.3       RA Connection Termination and Cleanup
When RA shuts down, cm_ra_close() is called. This function performs the following
processing:
 Walks the aircraft tree and sets the Ac_st->index for any aircraft associated with the
   terminating RA to NOT_SET.
 Sets the number of aircraft associated with this RA to NOT_SET. The static array
   number_of_ac_in_each_ra[] keeps track of the number of aircraft associated with each
   RA.
 Sets the RA as inactive.
 Redistributes aircraft among any remaining RAs.

3.14.2 TGUI Processing
TGUI provides Controllers with timeline information containing the flights‟ ETA, the STA,
and current delay. Using TGUI, the Controller can select a flight to display flight
information. TGUI allows the Controller to manipulate the airport-specific parameters (for
example, airport configuration) to control TMA scheduling per arrival airport (non-EDC
mode). TGUI also provides Controllers with load graph information providing a quick look
at the current scheduling affects. This quick look allows Controllers to determine whether the
current parameter set is satisfactory or, because of a change in air traffic, the parameters must
be updated to accommodate the flow.

Controllers use TGUIs to request traffic counts, flight plan amendments, and airport
configuration changes; suspend or resume and aircraft‟s scheduling; to request new meter fix
ETAs; set an aircraft‟s priority; change a flight‟s runway; create and delete blocked intervals
and slots; change flows (for example, meter fix, TRACON); change aircraft and sequence
constraints; and for non-EDC mode, when more than one arrival airport is adapted, exclude
chosen airports from rescheduling.

TGUI messages are handled by cm_tgui_msg(). Before distributing the various TGUI
messages, cm_tgui_msg() calls cm_tgui_dp_control_ok() to validate whether or not the
indicated message may be entered by the specified TGUI process. (DP control means that the
TGUI for this application entry may enter commands which affect DP scheduling). This
function sends a TGUI_NOT_IN_CONTROL message, via cm_tgui_snd_no_control(), to the
specific TGUI process that entered an invalid message.

3.14.2.1       TGUI Connection and Initialization
TGUI connection and initialization processing begins when CM receives a
SEND_HOST_NAME message from the TGUI. This message is processed by cm_tgui_init().
This function supervises processing for initializing a new TGUI connection. The following
items describe each step in this initialization.

   Verifies   the     TRACON       information        before allowing  a  connection
    (cm_app_verify_connection()).
   Sets the TGUI area (App_st->area). This is set to AREA_CENTER for TMA.
   Sets App_st->dp_contol to true, allowing the TGUI to send messages to control
    scheduling by a DP (cm_app_dp_control_set()). If a DP instance is found in the



                                             77                                           R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

    application table, sets a pointer to that DP via cm_app_dp_set(). TGUIs have a related
    DP.
   Retrieves CTAS time information for a newly connected process (initialize_time_info()).
   Retrieves all airport configuration information for a newly connected process
    (initialize_configuration_info()). The init_config_info_st structure is filled with
    initialization values, put in an INIT_CONFIG message (init_config_st), and sent to the
    TGUI, via cm_snd_app().

        /*
          * Structure to hold airport configuration information
          * passed to each process upon connection to the CM
          */
        typedef struct
        {
             int                 horizon;
             int                 index;
             int                 set_index;
             unsigned            countdown_begun;
             int                 future_index;
             int                 future_flow_index;
        } init_config_info_st;

        typedef struct
        {
                msg_hdr_st                 msg_hdr;
                int                        ctas_cm_start_time;
                int                        sim_start_time;
                int                        n_airports;
                init_config_info_st        airports[MAX_AIRPORTS];
        } init_config_st;


   Builds and sends a TMC_TRACON_SETTINGS message to the initializing TGUI
    (cm_send_tracon_settings_msg). This message contains the mirror MRP status for the
    current TRACON (reschedule suppression).
   Builds and sends an SD_AIRPORT_CONFIG message to the new TGUI
    (cm_dep_sd_category_send()). This message contains data for all satellite airports that do
    not have a DIRECT type category.
   Broadcasts the current weather state information to the connecting TGUI
    (cm_wdpd_tgui_update()).
   Sends the current two-way communication and TRACON metering status via a
    SOURCE_TWOWAY_METER_CHANGE message, one for each metering data source,
    for the local primary and any adjacent Centers, to the connecting initializing TGUI
    (cm_send_tracon_meter_status()).
   If in EDC mode, send a CTAS_MP_AIRPORT_METER_STATUS_LIST message containg
    meter point/airport pairs (cm_edc_mp_utils_send_mp_airport_list()). Otherwise (TMA
    mode), sends the current metering status, for all airports at all Centers, via a
    CTAS_AIRPORT_METER_STATUS_LIST message (cm_send_airport_meter_status()),
    and sends runway minimum spacing information (initialize_runway_spacing_info()).
    For each runway at each airport, sends the TGUI the following information:




                                            78                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

        typedef struct
        {
                msg_hdr_st                  msg_hdr;
                int                         airport;
                int                         runway;
                long                        start_time;
                long                        stop_time;
                float                       min_spacing;
        } minimum_runway_spacing_st;


   Send the status for all adapted Special Use Airspace (SUA) to the connecting TGUI
    (cm_send_sua_status()).
   Sends an AIRPORT_EDCT_STATUS message for all arrival airports adapted for the
    TRACON group of the connecting TGUI (cm_send_airport_edct_status()). Note: If the
    TGUI user toggles the EDCT status for an airport, TGUI sends an
    AIRPORT_EDCT_STATUS message to CM containing the airport index and the new
    dep_time_in_use value (use EDCT or use FAA coordination time).
   Calls cm_mc_snd_app_ifc_update() to send the TGUI an interface update message if
    there is an interface update noted in the Ifc_update list. The interface update message is
    defined as follows:

        typedef struct
        {
          msg_hdr_st         msg_hdr;               /* message header */
          interface_type     interface;             /* interface whose status */
                                                    /* has changed */
          Interface_status status;                  /* 0=down 1=up 2=warn */
          uchar_t           op_mode;                /* 0=standby 1=active */
          time_t            detect_time;            /* detection time */
          Bool_type         display_info;           /* 0=do not display I/F status */
                                                    /* 1=display status on TGUI */
          Bool_type         display_client_text;    /* 0 = do not display text */
                                                    /* 1 = display text */
          unsigned int      ip_address;             /* IP address used by CAP only */
          char            faa_id[MAX_FAA_ID_LEN]; /* 3char NULL term. faa fac id */
          char            misc_info [MAX_AIU_MISC_INFO_LEN]; /* miscellaneous text */
        } App_interface_update_st;

        typedef enum
        {
            WTHR_INTERN_IF = 1,       /*   internal weather interface */
            WTHR_EXTERN_IF,           /*   external weather interface */
            HOST_IF,                  /*   HOST interface */
            ARTS_GW0_IF,              /*   AGW0 interface */
            ARTS_GW1_IF,              /*   AGW1 interface */
            MONITORCONTROL_IF,        /*   M&C interface */
            STARS_AIG_IF,             /*   STARS AIG interface */
            TMA_OUTPUT_IF,            /*   Output from TMA interface */
            MAX_INTERFACE_TYPE        /*   Number of interface types */
            CAP_IF,                   /*   CAP external clients */
            ERAM_IF,                  /*   ERAM interface */
        } interface_type;

        If the array contains an entry (that is, an interface has been updated), the update
        message is forwarded to any and all TGUIs via cm_snd_tgui().




                                            79                                         R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


       Calls initial_synchronization_of_new_tma_or_dp_or_pgui() to send pertinent CM
        information to the TGUI so that it is synchronized with the other applications. This
        function calls dp_opt_get_dp_setting_msg() to get the requested local DP setting
        messages to be sent for establishing various system settings and defaults. See the
        TGUI Message Handling section for a DP settings list. ETA hovering information is
        sent via an ADJUST_DEPARTURE_TIME message (send_hover_params_to_tgui()).

    Forwards each to TGUI via cm_snd_app().

    Next, flow change information is sent to the initializing TGUI. Messages sent to the TGUI
    containing flow change information for the following:

    TMA/DP Only
     Runways (for each arrival airport)
     Meter fixes (TMA only, for each arrival airport)
     Gates (TMA only, for each arrival airport)
     Airports (TMA only, for each arrival airport)
     SGFF Intervals (TMA only, for each arrival airport)
     TRACON

    TMA/DP and EDC/MPDP
     Super Stream
     Blocked Intervals

    EDC/MPDP Only
     Meter point

   Next, cm_tgui_init() sends a CTAS_AIRPORT_AMDT_CHANGE message to to the
    initializing TGUI. This message contains AMDT information for outer arcs
    (cm_airport_utils_send_amdt_lists()).
   Next, cm_tgui_init() walks the aircraft tree, calling the following functions on each node:

       send_all_flight_plans() - Sends flight plan by calling send_flight_plan_to_app(),
        which sends the TGUI an ADD_FLIGHT_PLAN message.
       send_suspended_aircraft() - Sends the TGUI a SCHEDULING_SUSPENDED message
        for each aircraft that has scheduling suspended (ac->scheduling_suspended).
       send_over_crossing_info() – Sends the TGUI AC_CROSSING_INFO messages for
        display and scheduling meter fix crossing times when appropriate. This message is
        not sent for open slots.
       twalk_send_inactive_aircraft() - Sends an AIRCRAFT_INACTIVE message for any
        inactive aircraft found in the aircraft tree. This message is not sent for open slots.
       twalk_send_landed_aircraft() – Sends an AIRCRAFT_LANDED message for any
        landed aircraft that are found in the aircraft tree. This message is not sent for open
        slots.
       When a TGUI is restarted and connects to CM, a SCHEDULE message is sent from
        CM for all flights (rcv_aircraft_schedules()).



                                            80                                          R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


       twalk_send_priority_aircraft() – Sends a PRIORITY_AIRCRAFT_RESCHEDULE
        message for any priority aircraft found in the aircraft tree.
       twalk_send_hovering_aircraft() – Sends and AIRCRAFT_ETA_AVERAGED message
        is sent to TGUI for any aircraft found hovering.
       cm_dep_tgui_recovery_twalk() – Sends information needed for the recovery of any
        internal departure aircraft to the TGUI.
       cm_send_auto_resch_ac_msg_twalk () – Within a given time period, sends
        AUTO_RESCHEDULE_AC to TGUI for any aircraft flagged as recent auto_resched
        aircraft.

   Next, a determination is made about which TGUI has control to write DRS (delay
    reporting) files and print initial airport configuration, and sends a DRS_CONTROL,
    NO_DRS_CONTROL message as appropriate. The first TGUI only has this privilege.
    When that TGUI is disconnected another TGUI receives the privilege.

   CM calls cm_send_broadcast_blocked_msg() to send the state of TGUI data flow (blocked
    or not) to the newly-initialized TGUI. Arrival airports can be blocked individually.

   CM      calls     cm_airport_utils_send_internal_dep_buf_list()         to    send a
    AIRPORT_INTERNAL_DEP_BUFFER message, containing the current buffer value for
    each adapted internal departure satellite airport, to the newly-connected TGUI.

   CM calls the cm_send_wthr_file_status() function to have the production time, forecast
    time, and forecast cycle status information for the current live weather file, if any, sent to
    all connected GUIs via the CTAS_WTHR_FILE_STATUS message. Also sends this
    information to the M&C via a APP_CTAS_WTHR_FILE_STATUS message. CM only
    sends this message to M&C when there is no live weather file to use, or the current live
    weather file is outdated. Additionally, at CM to M&C connection time, the first default,
    weather file status message is not sent to the M&C.

3.14.2.2       TGUI Message Handling
This section describes how CM processes TGUI messages.

WATCH_AIRCRAFT: Processed by cm_tgui_watch_aircraft(), which populates a CM watch
window with flight information.

AMEND_FLIGHT_PLAN: Processed by cm_tgui_amend_flight_plan(), which does the
following:

       Returns if the destination for the aircraft has changed (cm_read_runway_message()).
       Checks for meter fix updates (cm_read_meter_fix_message()). If updates are made, a
        default runway is assigned. Returns if the meter fix information has not changed.
       If the AMSG_FID bit and the old and new fixes differ and if the flight is reschedule-
        suppressed (cm_amend_util_determine_prevent_reschedule()) then add the
        amendment message to the sent list (rcv_addmsg_sent_list()), and reset overcrossing
        items (cm_amend_util_reset_crossing()). Reschedule-suppressed aircraft fix



                                              81                                           R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

        amendments are added to the sent list, so that DP can communicate back to TGUI
        (via the MSG_PROCESSED response) whether or not there was a conflict wit any
        other aircraft, as a result of NOT rescheduling the amended aircraft, and if there is a
        conflict, DP needs to send the aircraft id of the aircraft affected.
       If AMSG_FAA_COORD_TIME is set, calls faa_to_ctas_coord_time() to convert FAA
        coordination time to CTAS coordination time and stores this value in the flight plan.
        If there is a change, the AMSG_COORDINATION_TIME bit is set in the
        amendments.          If      AMSG_COORDINATION_TIME                  is    set,      calls
        ctas_time_to_faa_coordination_time() to convert the CTAS coordination time to FAA
        coordination time and stores it in the flight plan‟s faa_coordination field. If there is a
        change, the AMSG_FAA_COORD_TIME bit is set in the amendments.
       If an AMSG_FID amendment is indicated, CM checks if a stream class amendment is
        necessary (sc_get_stream_class_assignment(), sc_get_stream_route_assignment()). If
        amended, the AMSG_STREAM_CLASS and AMSG_STREAM_ROUTE amendment
        bits are set.
       Checks amendments and clears ETA and OETA averaging time arrays if necessary. If
        amendments have been made that effect arrival times, then the function
        reset_time_filters() is called to reset the ETA averaging filter arrays. If amendments
        indicated a new coordination time, then the aircraft is removed from ETA hovering
        (cm_amend_util_check_hover_ac()).
       Forwards the flight plan amendment message to all DP, RA, TGUI, and PGUI
        instances.
       If a meter fix amendment was made, then metering reference point information is
        updated, over-crossing information for any affected fix is cleared, a gate amendment
        AMEND_FLIGHT_PLAN message is sent, and Host AK route messages are sent.
       The flight‟s received_ak_route flag is set to true. This indicates that an ETA request
        needs to be sent to the flight‟s owning RA.

CURRENT_CONFIGURATION: This message indicates a change to the current
configuration for the specified airport. Processed by cm_tgui_current_configuration(), which
updates       the      airport    current     configuration     and      flow     set    arrays
(Current_configuration_index[],                      Current_flow_set[],                   and
Configuration_change_in_progress[]) from the message contents, saves any airport user
settings contained in the message (cm_tgui_save_airport_user_settings_list()), writes the
configuration change to a file, and forwards a CURRENT_CONFIGURATION message to all
DPs (not used), RAs, TGUIs, and PGUIs.
SUSPEND_SCHEDULING,                    RESUME_SCHEDULING:                  Processed         by
cm_tgui_sus_res_scheduling(). If SUSPEND_SCHEDULING is received:
 If an open slot is being suspended, the message is forwarded to all TGUIs, and the open
    slot is deleted from the aircraft database. The handler then returns. Otherwise proceed.
 Calls cmm_meter_removal_by_ac() to send a remove from Metering (IE_CTAS) message,
    one each for every assigned and actively Metered MRP, to every data source actively
    metering the aircraft.
 Calls send_id_message_to_dads() to send CD_SUSPEND_SCHEDULING_COMPLETED
    message to ADIF. If the aircraft is not yet ARTS-tracked, no message is sent.
If RESUME_SCHEDULING is received:



                                              82                                           R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


  The aircraft‟s scheduling_suspended flag is set to false and the aircraft will be available
   for Metering when other conditions make it eligible.
 Calls send_id_message_to_dads() to send a CD_RESUME_SCHEDULING_COMPLETED
   message to ADIF.
Finally, the message is forwarded message to all DP, TGUI, and PGUI instances.

SCHEDULING_REQUEST_DENIED: Processed by cm_tgui_scheduling_request_denied().
This message indicates that a previous schedule change for an aircraft has been denied, and
is forwarded to PGUIs.

TGUI_CONTROL_STAT: Processed by cm_tgui_control_stat(), which sets the TGUI‟s DP
control state (via cm_app_dp_control_set()). DP control indicates whether or not the TGUI
may enter commands which affect DP scheduling.

TMA_METER_FIX_BALANCE: This message requests that a new ETA be determined, given
a meter fix and aircraft. This message is processed by cm_tgui_tma_meter_fix_balance(),
which does the following processing, involving the following structures.

        typedef struct
        {
                msg_hdr_st                 msg_hdr;
                char                       acid[ID_LENGTH];
                Meter_point_fid fid;
        } tma_meter_fix_balance_st;


        /*
          * Structure to identify a meter fix according to the heirarchy that a
          * gate may contain several meter fixes, but a meter fix is always
          * associated with one gate.
          */
        typedef struct Meter_fix_id_st
        {
             char        gate_index;
             char        ctas_meter_fix_index;
             char        display_point_index;
             char        scheduling_meter_fix_index;
             char        outer_fix_index;
             char        oma_index;                      /* outer meter arc */
             char        ooa_index;                      /* outer outer arc */
             char        o3a_index;                      /* third outer arc */
             char        o4a_index;                      /* fourth outer arc */
             char        hold_arc_index;                 /* AutoSwap holding arc index
        */
        } Meter_fix_id_st;

Reassign meter fix index in the message:

        msg->fid.scheduling_meter_fix_index = smf_index;

Store meter fix balance information for recovery:

        ac->gate_balance_eta_info = msg->fid;
        ac->gate_balance_eta_info_cleared = FALSE;




                                            83                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009



Forward to RA:

        cm_snd_ra(msg, size);

TMA_METER_FIX_BALANCE_CLEAR:                             Processed                      by
cm_tgui_tma_meter_fix_balance_clear(), which sets the meter fix balance flag, and forwards
the message to all TGUIs.

COMPUTE_SCHEDULE: Processed by cm_tgui_compute_schedule(). This message causes
an aircraft reschedule. The handler function calls cm_tgui_update_broadcast_blocking() to
set the Host meter list broadcast state to blocked (via a BROADCAST_BLOCKED message)
per airport. The broadcast blocked state means that during periods of change no metering
information is being sent to the HOST by CM. Forwards message to TGUI via
cm_tgui_send_to_dp(). If no DP is active, a NO_DP_AVAILABLE_FOR_LAST_REQUEST
message is sent back to the TGUI via cm_tgui_no_dp_msg(). Any airport user settings
specified in the message are saved (cm_tgui_save_airport_user_settings_list()).

PRIORITY_AIRCRAFT_RESCHEDULE, REMOVE_PRIORITY_AIRCRAFT : Processed by
cm_tgui_priority_aircraft(),toggles the priority mode for the specified aircraft to or from
PRIORITY_MODE accordingly (see Controller_directed_mode_type in User_constraint_st).
Removes any sequencing constraint for the specified aircraft (sqc_del_seq_constr()). Sets or
clears the priority mode. Forwards message to RA, and sends updated user constraints (via
send_user_constraints()) to all interested applications. Updates broacast blocking state and
forwards that state in a BROADCAST_BLOCKED message to other TGUIs
(cm_tgui_update_broadcast_blocking()). Sends updated user constraints in a
PGUI_USER_CONSTRAINTS message to all PGUIs (send_user_constraints()).

TMA_RESEQUENCE_INSTRUCTION: Processed by cm_tgui_tma_resequence_instruction(),
which forwards the message to DP (cm_tgui_send_to_dp()).

TMA_FREEZE_INSTRUCTION: Processed by cm_tgui_tma_freeze_instruction(). Forwards
the message to DP via cm_tgui_send_to_dp().Removes any sequencing constraint for the
specified aircraft (sqc_del_seq_constr()). Calls rcv_addmsg_sent_list() to add this message to
the associated DP‟s sent list to aid in DP casualty recovery (rcv_addmsg_sent_list()); on
completion DP sends a MSG_PROCESSED message back to CM, and the message is removed
from the sent list (rcv_delmsg_sent_list()).

TMA_RUNWAY_CHANGE_FROM: Processed by cm_tgui_tma_runway_change_from().
Forwards the message to the DP (cm_tgui_send_to_dp()). Adds the message to the associated
DP‟s sent list (rcv_addmsg_sent_list()); on processing completion DP sends a
MSG_PROCESSED message back to CM, and the message is removed from the sent list
(rcv_delmsg_sent_list()).Blocks Host meter list broadcasting for affected arrival airports and
forwards the information via a BROADCAST_BLOCKED message to all TGUIs
(cm_tgui_update_broadcast_blocking()).




                                            84                                         R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

BROADCAST_ALL_ACS: Processed by cm_tgui_broadcast_all_acs(), which forwards the
message     to    all    TGUIs     and     updates     the     Host    broadcast    state
(cm_state_set_broadcast_blocked() for each arrival airport). Forwards the message to the
TGUI‟s associated DP (cm_tgui_send_to_dp()).

BROADCAST_SINGLE: Processed by cm_tgui_broadcast_single().Forwards the message to
the TGUI‟s associated DP (cm_tgui_send_to_dp()).

TMA_RESET_AIRCRAFT: Processed by cm_tgui_tma_reset_aircraft(). This message lets the
TMC erase all scheduling information except the last track data and flight plan information,
causing the aircraft to be scheduled as though for the first time. This message also requests
runway analysis on the priority aircraft specified. The following processing occurs:
 Updates the broadcast state (update_broadcast_blocking(TRUE))
 Clears ETA and OETA averaging time arrays (reset_time_filters()).
 Unsets PRIORITY_MODE if set.
 Forwards the message to RA, TGUI, and PGUI.
 Delete any sequencing constraints for the aircraft (sqc_del_seq_constr()).
 Add this message to the associated DP‟s sent list to aid in casualty recovery
   (rcv_addmsg_sent_list()). On processing completion DP sends a MSG_PROCESSED
   message back to CM, and the message is removed from the sent list
   (rcv_delmsg_sent_list()).
 Forward this message to the TGUI‟s associated DP (cm_tgui_send_to_dp()).
 Removes the flight from scheduling (cm_dep_internal_unschedule()).

TMA_RUNWAY_CHANGE_ALL: Processed by cm_tgui_tma_runway_change_all(). This
message indicates changes to flight runway assignments. All flights having the same airport
and the same runway as the specified flight are affected. The message is forwarded to DP,
and added to that DP‟s sent list (rcv_addmsg_sent_list()), and blocks Host meter list
broadcast for all affected airports and sends a BROADCAST_BLOCKED message to all
TGUIs (cm_tgui_update_broadcast_blocking()).

BLOCKED_INTERVAL: Processed by cm_tgui_blocked_interval(). This message indicates a
blocked interval constraint is to be added to the list of scheduling constraints. The following
processing occurs:
 Forwards the message to all DPs, and TGUIs(cm_tgui_send())
 Updates the Host broadcast state (cm_tgui_update_broadcast_blocking() and sends a
    BROADCAST blocked message containing the current broadcast blocking state. (non-
    EDC only)
 Saves       any      airport     user     settings      contained     in     the     message
    (cm_tgui_save_airport_user_settings_list()) (non-EDC only).
 Clears out the landed aircraft list (Landed_list) (rcv_remove_all_landed()) (non-EDC
    only).
 Inserts the new blocked interval into the blocked interval list, ordered by
    time(bi_insert_blocked_interval_change()) (both TMA and EDC).




                                            85                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

DELETE_BLOCKED_INTERVAL: Processed by cm_tgui_delete_blocked_interval(), which
does the following processing:
 Forwards the message to all DPs, and TGUIs(cm_tgui_send()).
 Blocks       Host      meter      list    broadcasting        for    affected airports
   (cm_tgui_update_broadcast_blocking() and sends a BROADCAST_BLOCKED message
   containing the current broadcast blocking state to all TGUIs (non-EDC only)
 Saves the airport user settings/reschedule flag contained in the message
   (cm_tgui_save_airport_user_settings_list()) (non-EDC only).
 Clears out the landed aircraft list (Landed_list) (rcv_remove_all_landed()) (non-EDC
   only).
 Removes the specified blocked interval from the blocked interval list
   (bi_delete_blocked_interval_change()) (TMA and EDC).

BLOCKED_SLOT:          Processed      by      cm_tgui_blocked_slot(),    which        calls
bs_receive_blocked_slot_message(). This function determines whether a meter fix or runway
blocked slot is being created, then calls either bs_add_meter_fix_blocked_slot() or
bs_add_runway_blocked_slot() to create the blocked slot.

DELETE_BLOCKED_SLOT: Processed by cm_tgui_delete_blocked_slot(), which calls
bs_receive_delete_blocked_slot_message() to search the aircraft tree for the blocked slot. If
found, this function calls remove_flight_plan() to remove the blocked slot.

TMA_CONFIG_CHANGE_REQUEST: Processed by cm_tgui_tma_config_change_request().
This message requests that the runway configuration be set for the specified airport. The
message handler processes the message as follows:
 Forwards the message to all RAs, PGUIs, and TGUIs (cm_tgui_send()).
 Blocks Host meter list broadcasting for all affected airports and forwards that
   information      in a     BROADCAST_BLOCKED             message     to    all  TGUIs
   (cm_tgui_update_broadcast_blocking()).
 Saves message configuration information into adaptation shared memory.
 Saves the airport user settings/reschedule flag specified in the message
   (cm_tgui_save_airport_user_settings_list()).
 Calls tfc_add_flow_parameter_set() to add gate flow, meter fix flow, and super stream
   flow (and MSSD information for EDC) for the passed in time, airport, configuration
   index, and flow parameter set index. In EDC mode, only super stream flow and MSSD
   information are populated. (The airport and runway flows are only populated on
   initialization).
 Clears the landed aircraft list (rcv_remove_all_landed())

TMA_CONFIG_CHANGE_CANCEL: Processed by cm_tgui_tma_config_change_cancel(),
which does the following:
 Forwards the message to all RAs, PGUIs, and TGUIs (cm_tgui_send()).
 Blocks Host meter list broadcast for all affected airports (as specified in the message) and
   forwards that information in a BROADCAST_BLOCKED message to all TGUIs
   (cm_tgui_update_broadcast_blocking()).




                                            86                                         R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


   Saves the airport user settings specified/reschedule flag in the message
    (cm_tgui_save_airport_user_settings_list()).
   Saves message configuration information into adaptation shared memory.
   If not in EDC mode, removes the gate flow, meter fix, and super stream flow for the
    passed in time and airport (tfc_delete_flow_parameter_set()).
   Writes the information to the cm_ac file (write_config_change_to_file())
   Clears the landed aircraft list (rcv_remove_all_landed())

RUNWAY_FLOW: Processed by cm_tgui_runway_flow(). This message inserts a runway
flow change into the runway flow list, ordered by time, for a specified arrival airport. The
RUNWAY_FLOW message (and flow messages in general) changes runway (or TRACON,
gate, …) flow limit(s), including acceptance rate, separation distances, and occupancy times.
Processing proceeds as follows:
 Adds the message to the TRACON sent list for the specified arrival airport, to aid in DP
    casualty recovery (rcv_addmsg_tracon_sent_list()). This message is removed from the
    TRACON sent list (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of
    the message via a MSG_PROCESSED message.
 Forwards the message to other TGUIs and DP (cm_tgui_send()).
 Blocks        Host     meter     list    broadcasting     for     all    affected    airports
    (cm_tgui_update_broadcast_blocking()).
 Saves airport user settings/reschedule flag specified in the message
    (cm_tgui_save_airport_user_settings_list()).
 Insert       the   new      runway      flow     into    the    list,   based     on     time
    (tfc_insert_runway_flow_change()).
 Clears out the landed aircraft list (rcv_remove_all_landed())

METER_FIX_FLOW: Processed by cm_tgui_meter_fix_flow(), this message adds a meter fix
flow change to the scheduling constraints for a specified arrival airport, as follows:
 Adds the message to the TRACON sent list for the specified arrival airport, to aid in DP
    casualty recovery (rcv_addmsg_tracon_sent_list()). This message is removed from the
    TRACON sent list (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of
    the message via a MSG_PROCESSED message.
 Forwards the message to the other TGUIs and DP (cm_tgui_send()).
 Blocks       Host    meter   list    broadcasting     for    the    all    affected  airports
    (cm_tgui_update_broadcast_blocking()).
 Saves the airport user settings/reschedule flag specified in the message
    (cm_tgui_save_airport_user_settings_list()).
 Inserts the new meter fix flow change into the meter fix flow change list
    (tfc_insert_meter_fix_flow_change())
 Clears out the landed aircraft list (rcv_remove_all_landed())

DELETE_RUNWAY_FLOW,             DELETE_METER_FIX_FLOW:           Processed                     by
cm_tgui_delete_runway_flow() and cm_tgui_delete_meter_fix_flow(), which do                    the
following:
 Forward the message to other TGUIs and DP (cm_tgui_send()).




                                            87                                          R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


   Blocks     Host     meter    list    broadcasting     for the  affected airports
    (cm_tgui_update_broadcast_blocking()).
   Saves       airport     user      settings      specified   in    the   message
    (cm_tgui_save_airport_user_settings_list()).
   Removes the specified meter fix flow change from the meter fix flow change list
    (tfc_delete_runway_flow_change()).

   Clears the landed aircraft list (rcv_remove_all_landed()).

SCHEDULE_DEPARTURE: Processed by cm_dep_schedule_departure(). This message is a
request to schedule an aircraft departing a satellite airport (known as an internal departure).
The aircraft has its ETAs set to the values contained in the message, and the aircraft will be
reallocated. This message is processed as follows:
     Check message validity: for example, ensure CM is not already processing a
        SCHEDULE_DEPARTURE message for this aircraft (cm_dep_validity_check()). The
        handler returns on invalid messages.
     Stores the information for a new internal departure aircraft into the flight database.
        This includes handling amendments and updating the flight plan
        (cm_dep_handle_schedule_departure()).
     Makes stream class/route change if necessary.
     If the aircraft is ETA hovering, then stop hovering: set the hover state to
        HOVER_END, send the hover ETAs to all TRACON TGUIs, and clear the aircraft‟s
        hover state data (update_aircraft_stop_hover()).
     Forwards the SCHEDULE_DEPARTURE message to other TGUIs and DP
     Builds and sends an AMEND_FLIGHT_PLAN message to interested processes
        (forward_flight_plan_amend()). If the internal departure open_slot field is TRUE,
        indicating a flight was scheduled into the open slot, then the amendment is sent to
        RA/PGUI/TGUI. Then an ETA request message is sent to RA with the type set to
        ETA_OS_SUGGESTED, since this request is a result of a new suggested departure
        time when an internal departure flight was scheduled into an open slot.
     If the departure time in use at the arrival airport is EDCT, then change it to FAA
        coordination time, and send an AMEND_FLIGHT_INFO message, indicating the
        departure-time-in-use change for that flight, to all TGUIs, RAs, and the DP for that
        TRACON group; finally, send an ETA request to the flight‟s owning RA.
     Sends a FLIGHT_PLAN_ETA_REQUEST message to the flight‟s owning RA
        (send_request_for_flight_plan_eta()). If an arrival flight has a clone, then send an
        DOWNSTREAM_COORD_INFO message instead of an ETA request.

DEPARTURE_STATUS: Processed by cm_dep_departure_status(). This message indicates
status for an internal departure flight and is sent to indicate departure time status, or to
unschedule an internal departure flight. Departure status is defined and communicated by
the following structure and enumeration:

        typedef struct Departure_status_comm_st
        {
            char                        acid[ID_LENGTH];
            Departure_status_type       status;
        } Departure_status_comm_st;



                                             88                                         R10
CM SRDD                                                              CSC/CFF-03/0065
April 2009


        typedef enum Departure_status_type
        {
            NO_STATUS_TYPE = NOT_SET,   /*   For TGUI use */
            ACCEPT_ID,                  /*   Accept Internal Departure */
            ACCEPT_AND_FREEZE_ID,       /*   Accept and Freeze Internal Departure */
            UNSCHEDULE_ID,              /*   Unschedule Internal Departure */
            FIND_STA_ID                 /*   Find STA for the Internal Departure */
            RESET_ID,                   /*   Reset Internal Departure flight data */
            REJECT_SCH_DEP_TIME         /*   Schedule departure time rejected */
            DP_SCH_REJECT               /*   DP unable to schedule flight */
        }
        Departure_status_type;

CM does the following processing on this message:
 Adds the message to the TGUIs sent list to aid in DP casualty recovery
  (rcv_addmsg_sent_list(); on completion DP sends a MSG_PROCESSED message back to
  CM, and the message is removed from the sent list (rcv_delmsg_sent_list()).
 Forwards the DEPARTURE_STATUS message to DP (cm_snd_dp()). This message must
  be sent before CM handles it because an amendment may be sent out.
 If the departure status type is REJECT_SCH_DEP_TIME, then unschedules the flight and
  sends TGUI a DEPARTURE_MISC_INFO message with flight reset information
  (cm_dep_internal_unschedule()).         Otherwise       updates      departure   status
  (cm_dep_handle_departure_status()), and changes the departure status state, sending a
  pertinent amendment message if the state moves to unscheduled. See the IDR Processing
  section, or cm_departures.c for an internal departure state machine description.

DEPARTURE_MISC_INFO: Processed by cm_tgui_departure_misc_info(), which forwards
the message to all other TGUIs.

TMA_COMMAND_TO_DP: Processed by cm_tgui_tma_command_to_dp(), which forwards
the message to all DPs.

TGUI_SELECT_AC: Processed by cm_tgui_select_ac(), which forwards the message to the
other TGUIs (cm_snd_tgui()).

TGUI_CONFIRM_WARNING: Processed by cm_tgui_confirm_warning(), which forwards
the message to the other TGUIs.

AIRCRAFT_FIND_SLOT: Processed by cm_tgui_aircraft_find_slot(), which does the
following processing:
 Adds the message to the TGUI‟s sent list to aid in DP casualty recovery
    (rcv_addmsg_sent_list()). On processing completion DP sends a MSG_PROCESSED
    message back to CM, and the message is removed from the sent list
    (rcv_delmsg_sent_list()).
 Forwards the message to the other TGUIs (cm_snd_tgui()).

TRACON_FLOW: Processed by cm_tgui_tracon_flow(). This message adds a TRACON flow
setting to the scheduling constraints. This function does the following:




                                         89                                       R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


   Adds      the    message     to   the     TRACON      sent    list   (casualty   recovery)
    (rcv_addmsg_tracon_sent_list()).This message is removed from the TRACON sent list
    (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of the message via a
    MSG_PROCESSED message.
   Forwards the message to the other TGUIs and all DPs (cm_tgui_send()).
   Blocks Host meter list broadcasting for the affected airport and forwards a
    BROADCAST_BLOCKED message, containing the current broadcast state for each
    adapted arrival airport, to all TGUIs (cm_tgui_update_broadcast_blocking()).
   Saves airport user settings/reschedule flag specified in the message
    (cm_tgui_save_airport_user_settings_list()).
   Inserts the change into the proper place of the TRACON flow list ordered by time
    (tfc_insert_tracon_flow_change()). If the time of the new flow change is the same as an
    existing flow change, then the existing flow change is replaced by the new flow change.

   Clears the landed aircraft list (rcv_remove_all_landed()).

DELETE_TRACON_FLOW: Processed by cm_tgui_delete_tracon_flow(), which does the
following processing:
 Forwards the message to other TGUIs and DP (cm_tgui_send()).
 Blocks Host meter list broadcasting for the affected airport and forwards a
    BROADCAST_BLOCKED message, containing the current broadcast state for each
    adapted arrival airport, to all TGUIs (cm_tgui_update_broadcast_blocking()).
 Removes the specified TRACON flow change from the TRACON flow changes list
    (tfc_delete_tracon_flow_change()).
 Forwards the message to the other TGUIs and DPs.
 Clears the landed aircraft list (rcv_remove_all_landed()).

ACCEPTANCE_RATE_INTERVAL: Processed by cm_tgui_acceptance_rate_interval(), which
does the following:

  Saves the DP settings from this message (dp_opt_save_dp_settings()). These settings are
   defined the struct Adp_dpd_s (lib/dp_options.c).
Forward the message to the other TGUIs and DPs.

SEQUENCE_CONSTRAINT: Processed by cm_tgui_sequence_constraint(), which does the
following:
 Forwards the message to all DPs (cm_tgui_send_to_dp()).
 Adds the new sequence constraint to the sequence constraint list (sqc_add_seq_constr()).
 Clears the landed aircraft list (rcv_remove_all_landed()).

DELETE_SEQUENCE_CONSTRAINTS_FOR_ONE_AC:                              Processed               by
cm_tgui_delete_sequence_constraints_for_one_ac(), which does the following:
 Forwards the message to all DPs (cm_snd_dp()).
 Deletes the sequence constraint for the specified aircraft (sqc_del_seq_constr()).
 Clears the landed-aircraft list (rcv_remove_all_landed()).




                                            90                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

AIRPORT_FLOW: This message updates the airport flow list (airport_flow_list[airport]) for
the specified arrival airport. Airport flows are added to DP scheduling constraints for a
specified arrival airport. This message is processed by cm_tgui_airport_flow(), which does
the following:
 Adds the message to the TRACON sent list for the specified arrival airport, to aid in DP
    casualty recovery (rcv_addmsg_tracon_sent_list()).This message is removed from the
    TRACON sent list (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of
    the message via a MSG_PROCESSED message.
 Forwards the message to all DPs, TGUIs and PGUIs (cm_tgui_send()).
 Blocks Host meter list broadcast for the affected arrival airports (marked for reschedule)
    (cm_tgui_update_broadcast_blocking() ) and sends out a BROADCAST_BLOCKED
    message containing the current broadcast state to all TGUIs.
 Save      the    arrival   airports‟   user    settings    contained   in   the    message
    (cm_tgui_save_airport_user_settings_list()).
 Insert the new airport flow change in the list (tfc_insert_airport_flow_change()).
 Clears the landed aircraft list (rcv_remove_all_landed()).

DELETE_AIRPORT_FLOW: Processed by cm_tgui_delete_airport_flow(), which does the
following:
 Forwards the message to all DPs, TGUIs and PGUIs (cm_tgui_send()).
 Blocks        Host      meter   list    broadcast        for     the affected airports
    (cm_tgui_update_broadcast_blocking() ) and sends out a BROADCAST_BLOCKED
    message, containing the current broadcast state, to all TGUIs.
 Saves the airport user settings/reschedule flag contained in the message
    (cm_tgui_save_airport_user_settings_list()).
 Deletes the specified flow change from the airport flow list (airport_flow_list[])
    (tfc_delete_airport_flow_change()).

GATE_FLOW: Adds a gate flow constraint for the specified arrival airport. Processed by
cm_tgui_gate_flow(), which does the following:
 Adds the message to the TRACON sent list for the specified arrival airport, to aid in DP
   casualty recovery (rcv_addmsg_tracon_sent_list()).This message is removed from the
   TRACON sent list (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of
   the message via a MSG_PROCESSED message.
 Forwards the message to all DPs, and TGUIs (cm_tgui_send()).
 Blocks       Host    meter       list     broadcast  for   affected     arrival    airports
   (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
   message containing the current broadcast blocked state to all TGUIs.
 Saves the airport user settings/reschedule flag contained in the message
   (cm_tgui_save_airport_user_settings_list()).
 Adds       the    new     gate        flow    change   to   the     feeder_gate_flow_list[]
   (tfc_insert_gate_flow_change()).
 Clears the landed aircraft list (rcv_remove_all_landed()).

DELETE_GATE_FLOW: Handled by cm_tgui_delete_gate_flow(), which does the following:
 Forwards the message to all DPs, and TGUIs (cm_tgui_send()).



                                           91                                         R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009


   Blocks     Host     meter        list  broadcast    for     affected arrival airports
    (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
    message containing the current broadcast state to all TGUIs.
   Save any airport user settings/reschedule flag contained in the message to
    (cm_tgui_save_airport_user_settings_list()).
   Deletes the specified gate flow change for the specified arrival airport from the
    feeder_gate_ flow_list[][] (tfc_delete_gate_flow_change()).
   Clears the landed aircraft list (rcv_remove_all_landed()).

FREEZE_HORIZON_SETTINGS: Handled by cm_tgui_freeze_horizon_settings(), which does
the following:
 Adds the message to the TRACON sent list for the given airport, to aid in DP casualty
    recovery (rcv_addmsg_tracon_sent_list()).This message is removed from the TRACON
    sent list (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of the
    message via a MSG_PROCESSED message.
 Forwards the message to all DPs (if the current TRACON group‟s DP is connected),
    PGUIs, and TGUIs (cm_tgui_send()).
 Saves the updated freeze horizon setting and the TGUI user settings from the message to
    the DP settings buffers (see lib/dp_options.c) (dp_opt_save_dp_settings()).
 Blocks         Host        meter       list       broadcast      for       the  affected
    airports,(cm_tgui_update_broadcast_blocking()), and sends a BROADCAST_BLOCKED
    message containing the current broadcast state for each airport to all TGUIs.

SCHEDULE_MANAGEMENT_SETTINGS:                              Handled                  by
cm_tgui_schedule_management_settings(), which does the following:
 Saves the updated DP settings from the input message to the DP settings buffers. The
   settings are passed an appropriate handler function to do the save to the approriate
   buffer (dp_opt_save_dp_settings()). See the ACCEPTANCE_RATE_INTERVAL message
   for a list of the DP settings buffers.
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).

RUNWAY_ALLOCATOR_SETTINGS: Handled cm_tgui_runway_allocator_settings(), which
does the following:
 Saves the updated DP settings from the input message to the DP settings buffers. The
   settings are passed an appropriate handler function to do the save to the approriate
   buffer (dp_opt_save_dp_settings()). See the ACCEPTANCE_RATE_INTERVAL message
   for a list of the DP settings buffers.
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).

SCHEDULABLE_OBJECT_SETTINGS: Handled by cm_tgui_schedulable_object_settings(),
which does the following:
 Saves the updated DP settings from the input message to the DP settings buffers. The
   settings are passed an appropriate handler function to do the save to the approriate
   buffer (dp_opt_save_dp_settings()). See the ACCEPTANCE_RATE_INTERVAL message
   for a list of the DP settings buffers.
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).



                                          92                                       R10
CM SRDD                                                                CSC/CFF-03/0065
April 2009



ETA_SETTINGS: Handled by cm_tgui_eta_settings()), which does the following:
 Saves the updated DP settings from the input message to the DP settings buffers. The
   settings are passed an appropriate handler function to do the save to the approriate
   buffer (dp_opt_save_dp_settings()). See the ACCEPTANCE_RATE_INTERVAL message
   for a list of the DP settings buffers.
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).

SCHEDULE_FLIGHT_PLAN_AIRCRAFT:                               Handled                by
cm_tgui_schedule_flight_plan_aircraft(), which does the following:
 Saves the updated DP settings from the input message to the DP settings buffers. The
   settings are passed an appropriate handler function to do the save to the approriate
   buffer (dp_opt_save_dp_settings()). See the ACCEPTANCE_RATE_INTERVAL message
   for a list of the DP settings buffers.
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).

SUPER_STREAM_CLASS_FLOW: Handled by cm_tgui_super_stream_class_flow(), which
does the following:
 Adds the message to the TRACON sent list to aid in DP casualty recovery
   (rcv_addmsg_tracon_sent_list()).This message is removed from the TRACON sent list
   (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of the message via a
   MSG_PROCESSED message.
 Blocks        Host      meter         list    broadcast      for    affected     airports
   (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
   message containing the current broadcast blocked state to all TGUIs. Broadcast blocking
   is not done when this message is for synchronizing the SSC/MSSD flow mapping among
   all processes which occurs only once at startup. This message instance is indicated by
   having an orign of CM.
 For EDC only, adds or updates the SSC and MSSD flow lists from message contents, and
   inserts the SSC and MSSD identifiers into the message before forwarding
   (ssc_id_process_update()).
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).
 Saves        the      airport        settings      contained     in     the     message
   (cm_tgui_save_airport_user_settings_list()).
 Inserts the new SSF into the SSF list (tfc_insert_super_stream_flow_change()).
 Sends DELETE_SUPER_STREAM_CLASS message to CAP for any redundant SSCs if
   necessary and sends the updated SSCs to CAP.
 Saves SSF settings in case of DP or TGUI failure (tfc_save_super_stream_user_settings()).
 Clears the landed aircraft list (rcv_remove_all_landed()).

DELETE_SUPER_STREAM_CLASS_FLOW:                               Handled               by
cm_tgui_super_stream_class_flow_del(), which does the following:
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).
 Blocks      Host       meter       list     broadcast       for     affected airports
   (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
   message containing the current broadcast blocked state to all TGUIs.



                                          93                                        R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


   Save airport settings specified in the message (cm_tgui_save_airport_user_settings_list()).
   Deletes          the          SSF         from         the        super_stream_flow_list
    (tfc_delete_super_stream_flow_change()).
   Clears the landed aircraft list (rcv_remove_all_landed()).

LOAD_DATA_REQUEST: Handled by cm_tgui_process_load_data_req_msg(). This message
is sent by TGUI which initiates sending a SUPER_STREAM_CLASS_FLOW message back to
the originating TGUI. When this is the first TGUI to connect to CM for a specific TRACON
group, CM sends the LOAD_DATA_REQUEST message back to the TGUI to have the TGUI
send the SUPER_STREAM_CLASS_FLOW message back to CM containing the TGUI version
of the default SSC/MSSD mapping set information (EDC only), which needs to be stored by
CM and forwarded to DP.

SAVE_DATA_REQUEST: Handled by cm_tgui_save_data_request(), which writes the DP
settings to the DP settings file.

COMPUTE_RUNWAY_ALLOCATION:                                 Handled                       by
cm_tgui_compute_runway_allocation()), which does the following:
 Forwards the message to all connected DPs (cm_tgui_send_to_dp()).
 Saves     airport    settings/reschedule      flag  contained       in     the   message
   (cm_tgui_save_airport_user_settings_list()).
 Blocks     Host      meter     list    broadcast     for      all     affected    airports
   (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
   message containing the current broadcast blocked state, for all runway allocation modes
   but ALLOCATE_SINGLE, to all TGUIs.

SCHEDULE_TRACON_DELAY_AMOUNT:                   This     message       is      handled    by
cm_tgui_schedule_tracon_delay_amount() which does the following:
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).
 Saves the updated DP settings from the input message to the DP settings buffers. The
   settings are passed an appropriate handler function to do the save to the approriate
   buffer (dp_opt_save_dp_settings()). See the ACCEPTANCE_RATE_INTERVAL message
   for a list of the DP settings buffers.
 Blocks         Host     meter       list broadcast    for       all    affected    airports
   (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
   message, containing the current broadcast blocked state, to all TGUIs.

SGFF_STREAM_CLASS: Handled by (cm_tgui_sgff_stream_class()), which does the
following:
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).
 Blocks      Host     meter     list        broadcast     for      all    affected airports
    (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
    message, containing the current broadcast blocked state, to all TGUIs.
 Saves the airport settings/reschedule flag contained in the message
    (cm_tgui_save_airport_user_settings_list()).




                                            94                                          R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009


   Inserts the passed-in single gate free flow message into the SGFF interval list
    (sc_sgff_insert_interval_message()).

DELETE_SGFF_STREAM_CLASS: Handled by cm_tgui_delete_sgff_stream_class(), which
does the following:
 Forwards the message to all TGUIs and DPs (cm_tgui_send()).
 Deletes the passed-in single gate free flow message from the SGFF interval list
   (sc_sgff_insert_interval_message()).
 Blocks       Host      meter    list     broadcast    for       all   affected airports
   (cm_tgui_update_broadcast_blocking()) and sends out a BROADCAST_BLOCKED
   message, containing the current broadcast blocked state, to all TGUIs.
 Saves        the       airport     settings     contained         in     the   message
   (cm_tgui_save_airport_user_settings_list()).

WEATHER_SOURCE_UPDATE: Handled by cm_tgui_weather_update()), which
manages processing which changes the weather mode. This function calls
cm_wdpd_change_mode(), which checks if the new weather mode is different than current
mode and changes mode settings if modes are different.

TRAFFIC_COUNT_DATA_REQUEST: Handled by cm_tgui_traffic_count_data_request(),
which calls tc_send_tc_data(). If not in EDC mode, this function builds a
TRAFFIC_COUNT_DATA message that contains the requested traffic count data time period
and sends it out to the requesting TGUI.

SOURCE_TWOWAY_METER_CHANGE: Handled by cm_tgui_set_metering_twoway(). The
handler calls two_way_proc_tracon_meter_change() to determine whether the state change
(metering on or off) for the given TRACON group is valid. If metering is being turned on,
sends a meter list header message (IX_CTAS) to the specific Host Center, based on the
src_dscindex field within the message header, via HDIF. The meter list header message
contains a list of all local primary Center airports eligible for metering and their associated
current configuration and arrival acceptance rate. If metering is being turned off, sends a
remove from metering message (IE_CTAS) to the specific Host Center, based on the
src_dscindex field within the message header via HDIF for each actively metered MRP of
every aircraft for which the specified Host Center is actively receiving metering information.
This processing is done for the primary Center and any adjacent Centers.

CTAS_AIRPORT_METER_STATUS_LIST:                               Handled                    by
cm_tgui_set_airport_metering_status(). Data source and arrival airport indexes are checked,
and    if    not   valid,    processing    of    the    message     ends    and     a   new
CTAS_AIRPORT_METER_STATUS_LIST message is generated and sent to the original TGUI
process application to resynchronize the arrival airport meter status information. Otherwise
each message entry's Host/airport metering information is copied to g_meter_hosts_list[],
and the received message is forwarded to all connected TGUIs.

CM_IO_FILE: This message indicates that a TGUI preference file has been added or changed,
and contains the new or changed file. This message is handled by cm_tgui_rcv_io_file(),
which calls cm_pref_rcv_file() to write a preference file to disk and distribute the file to the


                                             95                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

appropriate processes (specified in the message). When a GUI creates a new preference file or
updates an existing file that file is sent to CM and CM either creates an entry for it in the
"ctas_gui_pref_file_list" file or updates the modification and access times for the matching
preference file entry already in the list file. CM maintains preference file lists per TRACON
for each GUI type (PGUI and TGUI).

HOST_FREETEXT: Handled by cm_tgui_freetext_message(), which calls parses and sends
the message to the Host via ISM (if two-way communication is enabled).

SD_AIRPORT_CONFIG: Handled by cm_tgui_sd_airport_config(), which does the
following:
 Stores passed-in configuration changes in the Satellite airport list Satellite_airport[] (
 Forwards the configuration changes to all RAs (cm_snd_ra()), TGUIs and DPs
    (cm_snd_tgui()),.

SD_AIRPORT_REQUEST_DEFAULTS: Handled by cm_tgui_sd_airport_defaults(), which
does the following:
 Re-initializes the configurations of each satellite airport(cm_dep_sd_category_init()).
 Sends the SD_AIRPORT_CONFIG message to the TGUI that sent the message, and to all
   RAs (cm_snd_ra()), other TGUIs (cm_snd_tgui()), and all DPs if connected
   (cm_tgui_sd_airport_defaults()).

STREAM_CLASS_DELAY_PREFERENCE: Handled by cm_tgui_sd_delay_percent(), which
updates the broadcast state, saves the DP settings contained in the message, and forwards
the message to other TGUIs and DPs.

HIGHLIGHT_AIRCRAFT: Handled by cm_tgui_highlight_aircraft(), which forwards the
message to all other GUIs, indicating a flight tag to highlight.

CTAS_GUI_PREF_FILE_LIST: This message is handled by cm_pref_process_pref_file_msg(),
and      indicates      one    of     two     actions:    GUI_PREF_FILE_STARTUP,            or
GUI_PREF_FILE_LOADED. Processing proceeds for each as follow:
 At startup, each GUI sends this message containing this GUI‟s preference file list. If CM's
   list has a more recent copy for any file in the list, CM then sends a copy of the more
   current file to the connecting GUI; if the GUI list contains a file name that CM doesn‟t
   have, then CM ignores the specific file until a GUI accesses or modifies the file, at which
   point CM requests a copy; if the CM list contains a file name that the GUI list doesn't
   have, CM sends the file to this GUI. Files are transmitted via CM_IO_FILE messages. If
   the sending application was a TGUI, then CM sends that TGUI a
   CTAS_GUI_PREF_FILE_LIST file with an action of GUI_PREF_FILE_COMPLETE.
 The GUI also sends this message when it loads a preference file. In this case, CM checks
   that it has the file named in the message. If CM does have the named preference file, CM
   updates the file‟s access time; if CM doesn't have the file CM requests a copy of the file
   from the GUI.

AIRPORT_EDCT_STATUS: Handled by cm_tgui_process_edct_status_msg() which updates
the global airport EDCT array with the departure-time type (EDCT or FAA coordination


                                            96                                         R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

time) for each arrival airport (cm_dtu_update_airport_edct_status()). Updates departure-
time type for all proposed aircraft for the current TRACON and arriving at the airport(s)
whose departure-time type (EDCT status) has changed, and sends an
AMEND_FLIGHT_INFO message to all RAs, all TGUIs, and the DP associated with the same
TRACON group.
 If the amendment indicates a time type change (EDCT/FAA), then the DP awaits ETAs
    for the affected aircraft.
 RA processes this AMEND_FLIGHT_INFO message and stores the change in EDCT
    status. RA receives an ETA request from CM for each flight affected by a change in EDCT
    status at an airport. RA uses EDCT when calculating the ETA for an aircraft when EDCT
    is in effect for the aircraft and an EDCT time greater than zero is available; otherwise the
    FAA coordination time is used. RA sets the dep_time_used value in the AIRCRAFT_ETA
    message that is sent to CM to indicate which time was used in calculating the ETA.
 Upon receipt of the AIRCRAFT_ETA message from RA, CM stores the departure time
    type used in the eta_average structure for the aircraft. CM sends the
    AIRCRAFT_ETA_AVERAGED message to DP and TGUI with the dep_time_used value
    set as received in the AIRCRAFT_ETA message from RA.
 When DP receives the AIRCRAFT_ETA_AVERAGED message from CM, the message is
    checked for validity based on the departure time type used to compute the ETA. The
    dep_time_used value in the message is compared with the departure-time type currently
    being used by DP. The ETA message is processed if: The departure-time type in the
    message is DEP_EDCT_TIME, DP has an EDCT time, and DP is currently using EDCT
    time for the aircraft; the departure time type in the message is DEP_FAA_TIME and DP is
    using FAA time; the departure time type in the message is DEP_FAA_TIME, and DP is
    currently using EDCT time for the aircraft, but has no EDCT time for the aircraft.
If departure time in use changed to FAA time (from EDCT time), or if the departure time in
use changed to EDCT time (from p-time), then CM checks if the current coordination time
removes the aircraft from hovering, (that is, the coordination time is no longer later than the
CTAS current time); if so, the hovering state is amended accordingly
(cm_amend_util_check_hover_ac()). CM then sends a FLIGHT_PLAN_ETA_REQUEST
message for every affected aircraft, for all flights arriving to the toggled airport, to the
owning RA process of each affected aircraft. (cm_dtu_update_edct_status_twalk()). Forwards
the message to all other TGUIs from the same TRACON group.

AUTO_SWAP_AC: CM forwards this message to all other connected TGUIs, and DPs.
AutoSwap provides the capability to swap STAs for aircraft that are in holding, into the
order they are expected to depart holding. The user specifies streams of aircraft whose STAs
should be exchanged with other aircraft in the same stream class, and selects the criteria for
setting the order. The aircraft can be sequenced based on altitude, or their crossing time at
the outer or holding arc depending on which is adapted for that site.

MANUAL_ALLOC_FOR_CONFIG_CHANGE:                This      message     is     handled            by
cm_tgui_send_to_dp(), which forwards the message to the DP for the current TRACON.

SUA_STATUS_LIST: The handler updates the global Sua_status list for all adapted Special
Sse Airspace (SUA), and forwards the message to all RAs and TGUIs within the same
TRACON group. The handler then calls process_sua_status_twalk() to have a


                                             97                                          R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

FLIGHT_PLAN_ETA_REQUEST message sent to the owning RA for any inactive, non-
tracked and non-landed aircraft for ETA recalculation. TMA can dynamically use SUA
information to determine an aircraft‟s route.

CTAS_AIRPORT_AMDT_CHANGE: The message specifies an AMDT change for a specified
airport. The handler (cm_tgui_process_amdt_change_msg()) does the following:

   Adds the message to the TRACON sent list for the specified arrival airport, to aid in DP
    casualty recovery (rcv_addmsg_tracon_sent_list()). This message is removed from the
    TRACON sent list (rcv_delmsg_tracon_sent_list()) after DP has acknowledged receipt of
    the message via a MSG_PROCESSED message.
   Forwards this message to DP and all other TGUIs in the same TRACON group
    (cm_tgui_send()).
   Blocks schedule broadcast and sends a BROADCAST_BLOCKED message, containing
    the updated broadcast state, to the TGUIs (cm_tgui_update_broadcast_blocking()).
   Saves         airport       settings       contained       in        the        message
    (cm_tgui_save_airport_user_settings_list()).
   Updates the AMDT list for each arc (cm_airport_utils_process_amdt_msg()).
   Determine if AMDT changes affect flights using pseudo metering settings. Affected
    flights have their amdt_for_pseudo_changed flag set to true to subsequently force an IM
    send to the Host (cmu_determine_force_pseudo_to_host()).

CTAS_MP_AIRPORT_METER_STATUS_LIST:                        The                  handler
(cm_tgui_process_mp_airport_change_msg()) forwards the messages to all other TGUIs for
the same TRACON group, and updates the EDC Meter Point/Airports list from the message
contents (cm_edc_mp_utils_process_mp_airport_msg()).

TMC_SWAP_AC: This message represents a TGUI-origin STA swap for a pair of aircraft. The
handler (cm_tgui_process_swap_ac_msg()) swaps the STA information, then sends a
DP_SWAP_STA message to DP (send_swap_sta_message_to_dp()). This message is added to
the sent list (rcv_addmsg_sent_list()) to aid in DP casualty recovery. On completion DP sends
a MSG_PROCESSED message back to CM, containing the swap results, and the message is
removed from the sent list (rcv_delmsg_sent_list()). On swap failure, CM forwards this result
(in a MSG_PROCESSED message) to the originating TGUI.

AIRPORT_INTERNAL_DEP_BUFFER: This message provides the satellite airport departure
buffer value for each adapted departure airport, arrival or EDC, for a specific TRACON. This
buffer specifies what portion of a departure delay, if any, that a flight can take airborne,
thereby reducing the flight‟s chance of missing a scheduling slot. The handler
(cm_tgui_process_airport_internal_dep_buf_msg()) forwards this message to all TGUIs in
the same TRACON group, then stores the buffer values in Dep_buf_list[] for use in casualty
recovery.

HOVER_AIRCRAFT: This message enables or disable ETA hovering for a specified internal
departure aircraft. The handler (cm_tgui_process_hover_ac_msg()) forwards the message to
all other TGUIs in the same TRACON group.



                                           98                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

ADJUST_DEPARTURE_TIME: This message specifies whether hovering is enabled or
disabled hovering for internal departure aircraft, and/or specifies the maximum hover
duration a given TRACON. The handler (cm_tgui_process_adj_dep_time_msg()) stores this
data in Tracon_hover[], and forwards the message to all other TGUIs in the same TRACON
group. Halts hovering for all aircraft for a TRACON for which hovering has been disabled. If
a flight that was hovering has its hover state set to HOVER_END, the new hover state
information is sent to all same-TRACON TGUIs, and the flight‟s hover times are cleared
(update_aircraft_hover_disable()).

METER_POINT_FLOW: This message modifies or deletes EDC gate or meter point flow
changes: one message is used per airport to indicate current flow modifications, and future
flow additions and deletions. The handler (cm_tgui_process_meter_point_flow_msg()) does
the following:
 Adds the message to the TRACON-level sent list (rcv_addmsg_tracon_sent_list()).This
    message is removed from the TRACON sent list (rcv_delmsg_tracon_sent_list()) after DP
    has acknowledged receipt of the message via a MSG_PROCESSED message.
 Forwards the message to all TGUIs and the associated DP (cm_tgui_send()).
 If the message indicates a change or addition, calls efc_process_flow_change() to store the
    flow       change      by       airport      (Mp_and_gate_flow_list[MAX_AIRPORTS]
    [MAX_EDC_FLOWS]).
 If the message indicates a future flow change delete, calls efc_process_flow_delete() to
    remove the flow change from the list.

TMC_TRACON_SETTINGS: This message contains flight reschedule suppression flag value
(when switching to a mirror MRP). The handler (cm_tgui_process_tracon_settings_msg())
stores the setting in Tmc_current_settings[], and forwards the setting to other active TGUIs.

TMC_SCHEDULE_AC_TO_SLOT: This message contains a request to schedule a flight into
an open slot. The handler (cm_tgui_process_sched_ac_to_slot_msg()) adds the message to
the DP sent list, and forwards the message to DP.

3.14.2.3      TGUI Termination and Cleanup
On TGUI termination, cm_tgui_close() is called. This function performs the following
processing:
 If CM thinks it has a socket connection with the TGUI (either direct or via a GUIR), then
   CM just closes the socket and does not clean out TGUI data. This is in preparation for an
   expected restart/reconnect, where the data is still needed. In this case, cm_tgui_close()
   returns. Otherwise the following steps are taken to do a full shutdown/cleanup.
 If the last TGUI is shutting down, update broadcast blocking to FALSE.
 If the TGUI has DRS control (delay reporting), then this capability is handed to the next
   TGUI if any are still active.

3.14.3 PGUI Processing
PGUIs provide Controllers with a spatial view of all the aircraft in an area selected by the
Controller. PGUIs display flight, track, route, and airspace information. The Controller can
select any aircraft to obtain more information. Using PGUI, a Controller can suspend or



                                           99                                         R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

resume scheduling of an aircraft, amend an aircraft flight plan, and set aircraft constraints.
PGUI messages are handled by cm_pgui_msg().

By calling cm_pgui_flight_eligible(), cm_pgui_msg() drops any PGUI messages for non-
arrival (EDC) flights that don‟t have an assigned meter point.

3.14.3.1       PGUI Connection and Initialization
A SEND_HOST_NAME message is sent to CM from a PGUI on PGUI startup or
restart/reconnect. This message is handled by cm_pgui_init(), which does the following:
 Verifies          TRACON             information         before      allowing   a     connection
    (cm_app_verify_connection()).
 Initializes some of the new PGUI‟s application (App_st) values (for example,
    cm_app_area_set(), cm_app_wthr_status_set(), cm_app_sector_set()).
 Sends airport configuration information to the TGUI (initialize_configuration_info()).
 Sends time information to the TGUI (initialize_time_info()).
 Sends all weather information to the PGUI (initialize_weather_info()).
 Sends PGUI_SCHEDULING_STATUS message to the PGUI (cm_snd_flag()) to tell it the
    CTAS scheduling state (defaults to TRUE).
 Sends the the two-way connection and metering status to the initializing PGUI (sends a
    SOURCE_TWOWAY_METER_CHANGE message via
    cm_send_twoway_meter_status()).
 Sends              PGUI             a           PGUI_SPEED_ADVISORY_MODE                message
    (pgui_initialize_pgui_options()).
 Send DP settings, and various flow change information (for example, runway, TRACON)
    to     synchronize        the       initializng      PGUI     with     other TMA     processes
    (initial_synchronization_of_new_tma_or_dp_or_pgui()). In EDC mode, only super
    stream class flow change, meter point flow change, MSSD information, and blocked
    interval information is sent.
 Next cm_pgui_init() walks the aircraft tree, calling the following function on each node
    for the given processing group (TRACON or MP):
         send_all_flight_plans() - Sends flight plan (except for blocked slots) by calling
             send_flight_plan_to_app(), which sends the PGUI an ADD_FLIGHT_PLAN
             message.
         send_owner_of_each_aircraft() – Sends each aircraft‟s sector owner in a
             PGUI_NEW_OWNER message, to the new PGUI. This is not sent for open slots.
         send_suspended_aircraft() - Sends the PGUI a SCHEDULING_SUSPENDED
             message       for      each        aircraft    with    scheduling   suspended    (ac-
             >scheduling_suspended).
         send_over_crossing_info() – Sends the PGUI AC_CROSSING_INFO messages for
             display and scheduling meter fix crossing times where appropriate. This message
             is not sent for open slots.
         pgui_initialize_options() – Sends each aircraft‟s (not blocked or open slots) user
             constraints (send_user_constraints()), any indication of a trajectory error, and if
             the aircraft is in it‟s final arrival state, a FINAL_ARRIVAL_STATE message to the
             PGUI.




                                             100                                          R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


          send_all_tracon_scratch_pad()       –     Sends    runway    information,       in    a
           AC_TRACON_SCRATCH_PAD message, to the PGUI. This message is not sent
           for open slots.
   Send the PGUI_MIN_TURNOUT_ANGLE message to initialize the turnout angle
    (send_min_turnout_msg()).
   Checks the health of the connection (cm_con_open_close()).
   CM calls the cm_send_wthr_file_status() function to have the production time, forecast
    time, and forecast cycle status information for the current live weather file, if any, sent to
    all connected GUIs via the CTAS_WTHR_FILE_STATUS message. Also sends this
    information to the M&C via a APP_CTAS_WTHR_FILE_STATUS message. CM only
    sends this message to M&C when there is no live weather file to use, or the current live
    weather file is outdated. Additionally, at CM to M&C connection time, the first default,
    weather file status message is not sent to the M&C.
   CM calls the cm_send_twoway_meter_status() function to have the current Two Way and
    Metering state for the primary Host center and any and all connected adjacent centers
    sent    to    all    connected     GUIs      for    display,   as   adapted,       via    the
    SOURCE_TWOWAY_METER_CHANGE message.

3.14.3.2       PGUI Message Handling
The following paragraphs desribe how PGUI messages are handled.

WATCH_AIRCRAFT: Processed by cm_pgui_watch_aircraft(), which populates a CM watch
window with flight information.

DELETE_AUXS:     The     delete   auxiliary   waypoint     message    is           handled      by
cm_pgui_delete_auxs(), which forwards the message to the other PGUIs.

HANDOFF_AIRCRAFT: This message is sent to inform CM that an aircraft sector handoff
has been requested (from one sector controller to another). This message is processed by
cm_pgui_handoff_aircraft(). If the aircraft is active, searches all TGUI instances (via the type-
to-index table (T2i[]) and forwards this message to any TGUIs whose sector matches the
to_sector field in the HANDOFF_AIRCRAFT message (see handoff_aircraft_st).

ACCEPT_HANDOFF_AIRCRAFT: This message indicates to CM that a transfer of radar
responsibility for the given aircraft (from sector to sector) has been accepted by the
controller. This message is handled by cm_pgui_accept_handoff_aircraft(), which does the
following:
 Determines if the aircraft is active (find_active_ac()).
 Sends a PGUI_NEW_OWNER message (new_owner_st) to all PGUIs and RAs
    (set_new_gui_aircraft_owner()). This is not sent for open slots.
 Sets items that indicate the aircraft‟s sector ownership

CANCEL_HANDOFF_AIRCRAFT: This message informs the CM that a controller handoff
from one sector to another has been canceled. This message his handled by
cm_pgui_cancel_handoff_aircraft(), which sends a PGUI_NEW_OWNER message




                                             101                                          R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009

(new_owner_st) to all PGUIs and RAs (set_new_gui_aircraft_owner()). This message is not
sent for open slots.

DUMP_ONE_TRAJECTORY: This message requests that a flight‟s trajectory be written to a
file. This message is handled by cm_pgui_dump_one_trajectory(), which forwards the
message to all RAs.

CONTROLLER_SEQUENCE_CONSTRAINTS: This message contains new controller
sequence constraints to be added to DPs list of current sequence constraints. The message is
handled by cm_pgui_controller_sequence_constraints(), which forwards the constraints to all
DPs (cm_snd_dp()).

SEND_AC_INFO_TO_NEW_OWNER: This message is sent from a flight‟s owning PGUI to
the PGUI that will own the flight, and contains handoff information (see
Handoff_information_st in global_includes/ctas_struct.h). This message is handled by
cm_pgui_send_ac_info_to_new_owner() which forwards the message to PGUIs whose sector
matches the message‟s Ac_st->sector_owner.

PGUI_SPEED_ADVISORY_MODE: Updates the current speed advisory mode for the other
PGUIs. Each PGUI‟s current speed advisory mode is stored in Pgui_speed_advisory_mode[].
This message is handled by cm_pgui_speed_advisory_mode(), which forwards the message
to any PGUIs with the same sector number.

PGUI_SCHEDULING_STATUS: Contains CTAS scheduling status (on or off). Handled by
cm_pgui_scheduling_status() which sets the global Ctas_scheduling, and forwards the
message to the other PGUIs.

PGUI_CHANGE_PGUI_SECTOR: This message is sent when a PGUI user changes the PGUI
sector. This message is handled by cm_pgui_change_pgui_sector(), which changes the
PGUI‟s      App_st->sector   number    (cm_app_sector_set()),    and    sends    a
PGUI_CONFIRM_NEW_SECTOR message back to the PGUI.

DEACTIVATE_T_ALTITUDE: Handled by cm_pgui_deactivate_t_altitude(). If the aircraft is
active, then its Ac_st->flight_info.T_altitude field is set to FLOAT_NOT_SET, and the
message is forwarded to all RAs.

PGUI_RA_AIRCRAFT_APPROACH_SEGMENTS: This message sets the RAs route approach
segment     flag   for  the    given   flight.     This     message     is   handled     by
cm_pgui_ra_aircraft_approach_segments(). If the aircraft is active the message is forwarded
to all RAs.

PGUI_USER_CONSTRAINTS: This message contains user constraints for the given aircraft.
User constraints are entered via a PGUI, and are used by RA to set route and trajectory
parameters for an aircraft (see the User_constraint_st in ctas_struct.h). This message is
handled by cm_pgui_user_constraints() as follows:
 If the message indicates a missed approach, then CM sends ADIF a
   CD_MISSED_APPROACH message for the given flight. If the message indicates a missed


                                          102                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

    approach cancel, then CM sends ADIF a CD_MISSED_APPROACH_CANCEL message
    for the given flight.
   The new user constraints are copied to the aircraft‟s user constraints (Ac_st-
    >user_constraint).
   The message is forwarded to all PGUIs and RAs.

PGUI_RA_AIRCRAFT_ROUTE: This message requests RA route information for display.
This message is processed by cm_pgui_ra_aircraft_route(), which sets the given aircraft‟s RA
route request flag (Ac_st->ra_route_request_on), and forwards the request to all RAs.

PGUI_FLIGHT_PLAN_ROUTE: This message requests flight plan route information from
the RA for PGUI display. This message is processed by cm_pgui_flight_plan_route(), which
sets the given aircraft‟s flight plan request flag (Ac_st->fp_route_request_on), and forwards
the message to all RAs.

PGUI_RA_HOST_AK_ROUTE: This message requests Host AK route information from the
RA for PGUI display. This message is processed by cm_pgui_ra_host_ak_route(), which
forwards the message to all RAs.

SUSPEND_SCHEDULING, RESUME_SCHEDULING: These messages indicate that a
controller (via a PGUI) has requested suspending or resuming scheduling for an aircraft.
These messages are processed by cm_pgui_sus_res_scheduling(), which proceeds as follows:
 The flight‟s entry in the aircraft tree is found (find_tree_ac()).
 Suspend requests are processed as follows:
    The flight‟s Ac_st->scheduling_suspended field is set to TRUE.
    Calls cmm_meter_removal_by_ac() to send a remove from metering (IE_CTAS)
       message, one each for every assigned and actively metered MRP, to every data source
       actively metering the aircraft.
    Sends a CD_SUSPEND_SCHEDULING_COMPLETED message to ADIF.
 Resume requests are processed as follows:
    The aircraft‟s scheduling_suspended flag is set to false and the aircraft will be
       available for metering when other conditions make it eligible.
    Sends a CD_RESUME_SCHEDULING_COMPLETED message to ADIF.
    Sends a CD_PS_SEQUENCE_NUMBERS message to ADIF.
 In each case, CM sends a SCHEDULING_SUSPENDED or SCHEDULING_RESUMED
   message to all GUIs and DPs.

PGUI_DUMP_PVD_TO_TS: Handled by cm_pgui_dump_pvd_to_ts(), which forwards the
message to all RAs.

PGUI_AUX_WAYPOINTS: Handled by cm_pgui_aux_waypoints(), which sets the flight‟s
auxilliary waypoints (Ac_st->->ac_aux_waypoint) from message data, and forwards the
message to all RAs.




                                           103                                       R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

PGUI_ALTIMETER_SETTING: Handled by cm_pgui_altimeter_setting(), which sets the
global value Altimeter_setting to the message value, and forwards the message to all RAs
and PGUIs.

TMA_FREEZE_INSTRUCTION: This message is a manual request to schedule and freeze a
schedulable object (that is, an aircraft or blocked slot). This message is handled by
cm_pgui_tma_freeze_instruction(), which forwards it to all connected DPs.

TMA_RESET_AIRCRAFT: This message lets the TMC erase all scheduling information
except the last track and flight plan information, causing the aircraft to be scheduled as
though for the first time. DP removes the object from the system and adds it back in. This
message is handled by cm_pgui_tma_reset_aircraft(), which forwards this message to all
connected DPs.

PGUI_WTHR_RECEIVED, PGUI_WTHR_FAILED: These messages are sent by the PGUI in
response to a CTAS_GET_NEW_WTHR_FILE message sent from CM, acknowledging the
receipt or failure of a new weather file. These messages are handled by
cm_pgui_wthr_received(). For receipt, the handler sets the PGUI‟s weather status to
CLIENT_WTHR_INIT_ACK or CLIENT_WTHR_UPDATE_ACK, and sets the PGUIs
weather-use flag to TRUE (cm_app_wthr_use_flag_set()). For failure, the PGUI‟s weather-use
flag is set to FALSE to prevent sending weather messages to that PGUI. In both cases the
handler decrements the sending PGUI‟s weather counter (cm_app_decrement_wthr_count()).
The weather counter apparatus prevents needless weather messages from being sent.

PGUI_WTHR_REVERT_COMPLETE, PGUI_WTHR_REVERT_FAILED: These messages are
sent to CM in response to a CTAS_REVERT_WTHR message sent from CM. These messages
are handled by cm_pgui_wthr_revert_complete() which sets the PGUI‟s weather status to
CLIENT_WTHR_REVERT_ACK. On completion, the PGUI‟s weather-use flag is set to TRUE;
on failure, the weather-use flag is set to false. In either case, the handler decrements the
sending PGUI‟s weather counter.

PGUI_MODE: This message is handled by cm_pgui_mode(), which set‟s the PGUI‟s runtime
mode (App_st->mode) to the passed in value. See Pgui_mode_type in ctas_defs.h.

PGUI_MIN_TURNOUT_ANGLE:                 This       message        is       handled  by
cm_pgui_min_turnout_angle(), which sets the global value Minimum_turnout_angle to the
value in the message, and forwards the message to all the other PGUIs, and all RAs.

CM_IO_FILE: This message indicates that a user preference file has been created or changed
and contains that new or changed preference file. The file is written to disk, and the
information is sent to the appropriate processes (specified in the message). This message is
handled by cm_pgui_rcv_io_file(). When a GUI creates a new preference file or updates an
existing file that file is sent to CM and CM either creates an entry for it in the
"ctas_gui_pref_file_list" file or updates the modification and access times for the matching
preference file entry already in the list file. CM maintains preference file lists per TRACON
for each GUI type (PGUI and TGUI).




                                           104                                       R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

HIGHLIGHT_AIRCRAFT: Handled by cm_pgui_highlight_aircraft(), which forwards the
message to all other GUIs, indicating a flight tag to highlight.

DROP_STALE_AIRCRAFT: Handled by cm_pgui_drop_stale_aircraft(), which forwards the
message to any other PGUIs.

CTAS_GUI_PREF_FILE_LIST: Handled by cm_pref_process_pref_file_msg(), and indicates
one of two actions: GUI_PREF_FILE_STARTUP, or GUI_PREF_FILE_LOADED. Processing
proceeds for each as follow:
 At startup, each GUI sends this message containing this GUI‟s preference file list. If CM's
   list has a more recent copy for any file in the list, CM then sends a copy of the more
   current file to the connecting GUI; if the GUI list contains a file name that CM doesn‟t
   have, then CM ignores the specific file until a GUI accesses or modifies the file, at which
   point CM requests a copy; if the CM list contains a file name that the GUI list doesn't
   have, CM sends the file to this GUI. Files are transmitted via CM_IO_FILE messages.
 The GUI also sends this message when it loads a preference file. In this case, CM checks
   that it has the file named in the message. If CM does have the named preference file, CM
   updates the file‟s access time; if CM doesn't have the file CM requests a copy of the file
   from the GUI.

3.14.3.3       PGUI Termination and Cleanup
PGUI shutdown is handled by cm_pgui_close() which does the following:
 Closes the PGUI socket (cm_con_open_close()).
 Walks the aircraft tree calling clean_all_aircraft_owned_by_pgui() on each aircraft node.
  This function does the following
   If the aircraft is owned by the PGUI‟s sector, sets the aircraft sector owner ship (Ac_st-
      >sector_owner) to NOT_SET.
   Informs other PGUIs and RAs of the change by sending each a PGUI_NEW_OWNER
      message (set_new_gui_aircraft_owner()). This message is not sent for open slots.
   Sets the aircraft‟s auxiliary waypoints (Ac_st-> ac_aux_waypoint) to
      FLOAT_NOT_SET, and forwards this information to all RAs via a
      PGUI_AUX_WAYPOINTS message.
   Turns off RA and flight plan routes (if on), and forwards the change to all RAs via
      PGUI_RA_AIRCRAFT_ROUTE and PGUI_FLIGHT_PLAN_ROUTE messages.
   Clears the amended route pointer (Ac_st->pgui_app_amended_route) if necessary.
   Turns off trajectory file dumping by sending a PGUI_TS_DUMP_TRAJECTORY_FILE
      message to all RAs.
   Removes all user constraints (initialize_user_constraints()), and forwards this
      information to all RAs and PGUIs (send_user_constraints()).

3.14.4 DP Processing
DP performs aircraft scheduling. DP‟s goal is to maximize airport landing and TRACON
handling capacity without compromising safety. DP can sequence Scheduled Objects (SOs)
to the meter fix, and schedule them to the outer fix, meter fix, final approach fix, and runway
threshold so to maximize airport and TRACON capacity without compromising safety. DP
also assigns aircraft to optimal runways. DP updates these sequences, schedules, and runway



                                            105                                        R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

assignments constantly to adapt to changes in the traffic situation, the environment, or in
response to input by the TMCs.

Using flight plans, tracks, and scheduling constraints forwarded from CM, DP generates and
sends STAs, runway assignments (to TGUIs), and flight plan amendments (to RA and
TGUIs).

For TMA Centers with more than one adapted arrival airport, arrival TMA can enable or
disable airport rescheduling per airport. DP computes STAs for aircraft destined for airports
that are specified for rescheduling without affecting the STAs of frozen aircraft destined for
arrival airports not specified for rescheduling. Centers with more than one arrival airport can
also have freeze horizons enabled/disabled per airport. Both of the above capabilities are
excluded from EDC.

CM maintains local adaptation data to support independent airport scheduling and freeze
horizon enabling.

CM calls cm_dp_msg() to process messages it receives from DP. The following sections DP
connection and initialization, and how each DP message is processed.

3.14.4.1       DP Connection and Initialization
The DP SEND_HOST_NAME message is handled by cm_dp_init(), which initializes the new
DP by doing the following:
 Verifies       TRACON           information        before       allowing       a    connection
   (cm_app_verify_connection()).
 Sets the DP‟s system area (cm_app_area_set(app, AREA_TRACON | AREA_CENTER)).
 Searches the application table for all TGUIs (PROC_TGUI) and IDR (PROC_IDR)
   instances, setting those application‟s related DP via cm_app_dp_set().
 Calls initialize_configuration_info() to send airport configuration initialization
   information back to the DP.
 Sends CTAS time information to the DP (initialize_time_info()).
 Builds and sends an SD_AIRPORT_CONFIG message, containing satellite airport
   category information, to the DP (cm_dep_sd_category_send()).
 Calls initial_synchronization_of_new_tma_or_dp_or_pgui() to download the pertinent
   CM information to synchronize the new process. See SEND_HOST_NAME in the TGUI
   section.
 Sends a CTAS_AIRPORT_AMDT_CHANGE message to to the initializing DP. This
   message        contains       AMDT          information        for      the     outer     arcs
   (cm_airport_utils_send_amdt_lists()).
 Walks the aircraft tree to send the DP all flight plan, suspended aircraft, over-crossing,
   frozen aircraft, inactive aircraft, and priority aircraft information. See the TGUI section.
 Walks the aircraft tree and sends any AMDT ETAs to the connecting DP via a
   DP_AMDT_SAVED_ETAS message (amdt_saved_etas_recovery_twalk()). Flights and the
   DP must have the same TRACON. This is for DP casualty recovery. Open slots are not
   processed.




                                             106                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


   Sends sequence constraints to the DP in a SEQUENCE_CONSTRAINT message
    (sqc_send_seq_constraints(app)).
   If not in EDC mode, sends contents of the landed aircraft list to the DP
    (rcv_send_landed_aircraft()).
   On DP restart, sends any contents of the DP sent list to the DP (rcv_send_sent_list()).
   Sends a CM_DATA_COMPLETE message to the DP (send_data_complete()).
   On DP restart, sends any contents of the TRACON sent list (per airport list) to the DP
    (rcv_send_tracon_sent_list()).

3.14.4.2      DP Message Handling
The following paragraphs describe how CM handles DP messages.

AMEND_FLIGHT_PLAN: Handled by cm_dp_amend_flight_plan()). This message contains
amended flight plan data. CM applies the amendments to the aircraft tree and forwards the
message to all DPs, RAs, TGUIs, and, if not a blocked slot, to all PGUIs.

SCHEDULE: Handled by cm_dp_schedule(). This message contains one or more aircraft
schedules (STAs), as defined by the Schedule_st structure:

        typedef struct Schedule_st
        {
            char          acid [ID_LENGTH];
            int           airport;            /* airport index */
            int           runway;             /* runway index */
            Meter_point_fid fid;
            Bool_type     center_area;
            Bool_type     frozen;
            Bool_type     sequence_constrained;
            Bool_type     pop_up;
            Bool_type     scheduled;
            Bool_type     manually_scheduled;
            Bool_type     meter;
            Time_type     arc_sta [MAX_ARC_TYPES];
            Time_type     sta_to_display_point;
            Time_type     sta_to_scheduling_meter_fix;
            Time_type     sta_to_faf;
            Time_type     sta_to_threshold;
        } Schedule_st;

The handler stores the information in the flight database. The message is then forwarded to
all TGUIs. Then the schedule message, excluding any blocked slots, is forwarded to all
PGUIs.

The handler then calls cm_meter() to send the schedule (that is, metering information) to the
Host-side, if eligible. If two-way Host communication or metering is enabled for the local
Host or any adjacent Center, this processing proceeds as follows:

For each data source, sends a meter list header update message (IX_CTAS) for each arrival
airport as necessary (cm_meter_ix_update()).




                                           107                                       R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

Removes ineligible flights from metering display (cm_meter_in_display_horizon()). This
includes:

   Flights not yet tracked, no track message received from any source
   An arrival airport is not defined or is invalid for the curren site.
   The arrival airport is not defined as a metering airport.
   A meter fix is not assigned or is invalid for the current site.
   The CTAS FID indexes do not match the Host FID indexes.
   The Host sent a drop track message (set to true) to CTAS for the given flight.
   The flight does not contain a valid STA to the assigned meter fix.
   The Host sent a schedule suspend message (set to true) to CTAS for the flight.
   The flight has departed from a locally departed airport.
   For EDC flights, either the meter point or airport have metering disabled.

If metering has been suppressed for internal departure flights undergoing automatic
reschedule, then these flights are made ineligible.

For each eligible flight, sends an IM (metering information) message to HDIF (via ISM as
usual). Prior to sending, final eligibility is determined by cm_meter_check_positions(), which
checks if the flight is in the display horizon for the pertinent meter fix or if the pertinent
meter fix does not qualify for transmission to the Host, but is adapted to use a pseudo meter
settings (MLAS). The cm_meter_send() function then calls the appropriate function
(cm_send_tway_im_meter(),                          cm_send_tway_im_outer(),                 or
cm_send_tway_im_outer_outer()) to send the metering information.

Now that a metering-determination send cycle has completed, resets all the IM message send
flags, both data source specific (via cmu_reset_im_send_flags(), and global
(g_send_all_nas_meter and g_set_all_position_change) to false.

SUGGESTED_DEPARTURE_TIME: Handled by cm_dp_departure_time(), which does the
following:
 If this time is for a flight scheduled into an open slot, the flights coordination times are
    update from the message times, and sends an AMEND_FLIGHT_PLAN message back to
    DP (cm_dp_slot_departure_time()). The handler returns after open slot processing.
 Checks that this message isn‟t received after the controller unschedules the flight
    (cm_dep_validity_check()).
 Updates the aircraft tree with the suggested internal departure time information
    (cm_dep_handle_departure_time()) and status state
 Forwards message to TGUIs (cm_snd_tgui()).
 If the controller-entered time and suggested time differ, update and send out an
    AMEND_FLIGHT_PLAN message, clear the ETA filter arrays, and send an
    FLIGHT_PLAN_ETA_REQUEST message to RA.

This message contains an internal departure‟s suggested departure time as computed by DP.

DEPARTURE_STATUS: Handled by cm_dp_departure_status(), which does the following:



                                           108                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


  Updates departure status and state information (cm_dep_handle_departure_status()).
  Handle      as      if     MSG_PROCESSED            was      received        from  DP
   (cm_dep_handle_msg_processed()).
The DEPARTURE_STATUS message indicates the controller selection during a find STA
operation for Accept or Accept and Freeze of an internal departure. DP can send this
message to TGUI to indicate the unscheduling of an internal departure aircraft.

MSG_PROCESSED: Handled by cm_dp_msg_processed(). This message indicates a message
was processed, and can be removed from its sent list (DP or TRACON). The handler removes
the     message      from      the     appropriate       sent    list (rcv_delmsg_sent_list(),
rcv_delmsg_tracon_sent_list()). The handler first checks that, for aircraft-related messages,
the aircraft TRACON identifier matches the TRACON identifier for the application‟s from
which the message was received. If match, processing proceeds as follows:
 If a TMA_RESET_AIRCRAFT message is being removed from the DP sent list, then the
    flight‟s STAs are cleared (clear_out_stas()).
 If a DEPARTURE_STATUS message (internal departures) is being removed from the DP
    sent list, then a DEPARTURE_STATUS message is forwarded to TGUIs; the flight is
    unscheduled, and AMEND_FLIGHT_INFO and AMEND_FLIGHT_PLAN messages are
    sent as necessary; and finally, updates the flight‟s status.
 If a DP_SWAP_STA or TMC_SCHEDULE_AC_TO_SLOT (open slot) message is being
    removed from the DP sent list, and the MSG_PROCESSED indicates a warning or failure,
    then the original message is sent back to the originating TGUI indicating results.
 If an AMEND_FLIGHT_PLAN message is indicated, the MSG_PROCESSED message
    communicates DP‟s ability to accommodate a reschedule-suppressed flight at a mirror
    MRP. The AMEND_FLIGHT_PLAN message is removed from the DP sent list, and if the
    reschedule suppression failed or spawned a warning the MSG_PROCESSED message is
    forwarded to all TGUIs.

CONFIG_ETA_UPDATE_STATUS, CONFIG_CHANGE_ALLOC_STATUS: These two
messages are handled by cm_snd_tgui(), which forwards the messages to all connected
TGUIs.

DP_AMDT_SAVED_ETAS: The handler (process_amdt_saved_etas_msg()) saves the
message ETAs for casualty recovery. DP sends these values to CM for casualty recovery: on
DP restart CM sends these to the DP.

DP_DEP_BUFF_SAVED_ETAS: The handler (process_dep_buff_saved_etas_msg()) saves
these ETAs for casualty recovery. These ETAs are used for departure scheduling when a
flight can take some of it‟s departure delay airborne, thereby, getting airborne flights off
early and reducing the likelihood of missing a scheduling slot.

DELETE_FLIGHT_PLAN: This message is received from DP for open slots that have been
scheduled/rescheduled. The handler (process_delete_flight_plan_msg()) removes the flight
from the aircraft tree.

AUTO_RESCHEDULE_AC:



                                           109                                        R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

This message indicates to TGUI that an aircraft has advanced to an earlier runway/MF STA
slot as a result of internal departure auto rescheduling processing. The handler
(process_auto_resch_ac_msg ()) stores the message time (for casualty recovery) and forwards
the message to TGUIs.




3.14.4.3       DP Termination and Cleanup
DP shutdown is handled by cm_dp_close() which does the following:
 If CM thinks it has a socket connection with the DP, then CM just closes the DP socket
   and does not clean out DP data. This is in preparation for an expected restart/reconnect,
   where the DP data is still needed. In this case, cm_dp_close() returns. Otherwise the
   following steps are taken to do a full shutdown/cleanup.
 If this is the last DP shutdown, then the global Use_prerecorded_stas is set to TRUE.
 The DP‟s sent list is deleted (rcv_del_sent_list()).
 The TRACON sent list is deleted (rcv_del_tracon_sent_list()).

3.14.5 ISM Processing
ISM receives and manages flight plan and track data sources, sends CM flight plans and
tracks, and passes two-way messages back to the relevant data sources. ISM transforms
disparate data from multiple sources into source-independent messages, then sends the
messages to CM for distribution to the other CTAS applications.

ISM also provides flexible filtering and merging of data sources. The data filtering is required
to smooth the ground speed estimates from the sources, and to generate reasonable aircraft
course and general speed numbers. ISM provides the ability to filter data sources
individually and/or after two sources have been merged.

CM calls cm_ism_msg() to handle all messages received from ISM.

3.14.5.1       Flight Plan Categories and Category Determination
Before delivering flight plans (Flight_plan_st) to CM, ISM determines the flight plan category
type. CM maintains this information each aircraft‟s Ac_st->flight_plan field. Flight plan
categories can be one of the following enumeration constants (AC_fp_category):

        DEPARTURE
        ARRIVAL
        OVERFLIGHT
        SATELLITE_ARRIVAL
        SATELLITE
        DEPARTURE_ARRIVAL
        SATELLITE_DEPARTURE
        SATELLITE_TO_EXTERNAL
        EXTERNAL_TO_SATELLITE




                                            110                                         R10
CM SRDD                                                                        CSC/CFF-03/0065
April 2009

ISM uses the fp_category_set() function (lib/fp_procs.c) to determine the flight plan category
for each flight plan. The category is initialized to AMBIGUOUS_CATEGORY, then a
determination algorithm uses the departure and destination fixes, if they are available. The
algorithm first determines what airports the fixes are from. There are two types of airports,
primary and satellite:

            Primary airports are the arrival airports that are stored in the Ctas_airport
             structure.
            Satellite airports are any other airports that are listed in the nas_airports file. Each
             Satellite airport may be either internal or external to the center. These airports are
             read into the Satellite_airport structure.

Three possible values can be assigned for the fix, PRIMARY_AIRPORT,
SATELLITE_AIRPORT, and OUTSIDE_CENTER (either any external satellite airport, or not
an adapted airport). The fp_category_set() function then assigns the category based on the
following:

1. If the destination airport is a PRIMARY_AIRPORT and the departure airport is a
   PRIMARY_AIRPORT, the FP category is set to DEPARTURE_ARRIVAL.
2. If the destination airport is a PRIMARY_AIRPORT and the departure airport is a
   SATELLITE_AIRPORT, the FP category is set to SATELLITE_ARRIVAL.
3. If the destination airport is a PRIMARY_AIRPORT and the departure airport is
   OUTSIDE_CENTER, the FP category is set to ARRIVAL.
4. If the destination airport is a SATELLITE_AIRPORT and the departure airport is a
   PRIMARY_AIRPORT, the FP category is set to SATELLITE_DEPARTURE.
5. If the destination airport is a SATELLITE_AIRPORT and the departure airport is a
   SATELLITE_AIRPORT, the FP category is set to SATELLITE.
6. If the destination airport is a SATELLITE_AIRPORT and the departure airport is
   OUTSIDE_CENTER, the FP category is set to EXTERNAL_TO_SATELLITE.
7. If the destination airport is OUTSIDE_CENTER and the departure airport is a
   PRIMARY_AIRPORT, the FP category is set to DEPARTURE.
8. If the destination airport is OUTSIDE_CENTER and the departure airport is a
   SATELLITE_AIRPORT, the FP category is set to SATELLITE_TO_EXTERNAL.
9. If the destination airport is OUTSIDE_CENTER and the departure airport is
   OUTSIDE_CENTER, the FP category is set to OVERFLIGHT.

3.14.5.2        ISM Connection and Initialization
The ISM SEND_HOST_NAME is handled by cm_ism_init(), which initializes the connection
with ISM by doing the following:
 Sends time synchronization information to ISM (initialize_time_info()).
 Walks the aircraft trees, sending ISM any flight plans in the aircraft tree, via a
   CI_ADD_FP message. This is for ISM casualty recovery (ism_send_all_flight_plans()).
   Open slots are not sent. Flight plan downloads are surrounded by
   DOWNLOAD_FLT_BEGIN_MESSAGE                 and      DOWNLOAD_FLT_END_MESSAGE
   messages.
The ism_socket_write() is used to send messages to ISM. This function discriminates between
messages destined for processes on the “other side” of ISM (prefixed with and encapsulated


                                               111                                           R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

within a CI_GENERIC message), and those messages destined for ISM itself. This function
also indicates destination Host (local or adjacent), via the src_dscindex field within the
message header, which contains the data source DSC index for the destination Host.

3.14.5.3       ISM Message Handling
IC_FLIGHT_PLAN_ADD: Handled by ism_handle_fp_add(), which does the following to
process flight plan add message from ISM:
 Determines if CM already has the flight plan(find_tree_ac()).The flight plan is discarded
   if CM already has it.
 Adds the new flight plan to the aircraft tree (add_flight_plan()).
 Computes and assigns meter fix FID for arrivals, or meter point FIDs for non-arrivals
   (EDC) if possible (ism_assign()). Stores the route 10b field, and sets the flight‟s stream
   class       (sc_get_stream_class_assignment()),        and        stream      class     route
   (sc_get_stream_route_assignment()) for each MP/MF ( update_aircraft_set_sc()). Sets the
   flight plan status (via cm_send_update_fp_status()) accordingly. If a MP/MF FID cannot
   be assigned, then the (subsequent) ADD_FLIGHT_PLAN message is only forwarded to
   RA and PGUI.
 If the flight is cloned (that is, clone_traconid is set), then fetch the clone Ac_st and copy
   Meter_point information to the appropriate mp[] entry in the clone Ac_st
   (assign_clone()): if the new FP is an arrival FP, then copy the new FP‟s Meter_point info
   into the clone Ac_st's mp[1-3] as appropriate (if it has at least 1 assigned MP); ff the new
   FP is a MP FP then copy the new FP's Meter_point info (for the meter fix) into the clone
   Ac_st's mp[0].
 Checks for airport change. Changes aircraft‟s airport identifier if it is different than
   current destination fix (has_airport_changed()).

IC_FLIGHT_PLAN_AMD: Handled by ism_handle_fp_amd(), which does the following:
 Verifies that the specified aircraft exists (find_tree_ac()).
 Checks for a route 10b change, and stores any change and flags a change indication if
   necessary (route10b_changed).
 Stores the converted route from the IC_FLIGHT_PLAN_AMD message for use in FID
   determination. If the converted route string contains “same”, then meter fix/meter point
   reassignment may still be necessary, based on other possible amendments in the message
   (altitude, engine type, or destination fix amendments). If the converted route string
   contains “none”, then the aircraft may need to be removed (EDC/non-arrival flights), or
   the Host flight plan route may need to be reprocessed (arrival flights).
 If the CID is being amended, then save the old CID before setting the new CID. This is to
   prevent multiple CIDs for the same flight when a flight leaves and reenters an airspace.
 If specific amendments are indicated which make the flight eligible for open slot creation,
   create an open slot (cm_os_process_amend()). On successful open slot creation an
   ADD_FLIGHT_PLAN            message        is     forwarded      to    DP/TGUI/PGUI,      an
   OPEN_SLOT_SETTINGS message is sent to TGUIs, and a SENDING_AIRCRAFT
   message       is   sent   to     TGUIs/PGUIs.          If  a     priority   open  slot,   a
   PRIORITY_AIRCRAFT_RESCHEDULE message is sent to the TGUIs.
 Ensures       that    the    destination       for    the    aircraft    has   not  changed
   (cm_read_runway_message()).



                                            112                                         R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


   If the flight‟s CID has changed, then any actively metered MRPs for the flight‟s old CID
    are removed from the HCS display of the Host Center that generated and sent the
    amendment message, via the remove from Metering (IE_CTAS) message. The flight then
    is available for metering under the new CID when other conditions make it eligible.
    Since a flight can have two different CIDs when it leaves and reenters an airspace, this
    prevents the same flight from appearing under two different CIDs on the metering lists
    (cmm_meter_removal_by_name()).
   If the departure airport is amended, then the amended airport is checked to see if it is a
    local-departure airport based on the airport‟s inclusion in the local_departure_airports
    adaptation file. The amended flight plan‟s locally_departed flag is set accordingly
    (au_is_airport_local_departure()).
   Updates the aircraft tree using the specified flight plan (amend_flight_plan()).
   Calls a series of functions which compares the original flight plan to the new amended
    flight plan to determine if a particular amendment needs to be made, and if so, makes the
    amendment. Amended fields are flagged using the Flight_plan_amd_type enumeration
    (global_includes/msg_defs.h).
   If the flight status has changed from PROPOSED, then clear the internal departure
    information. Check if status change or coordination time change removes the aircraft
    from hovering (cm_amend_util_check_hover_ac()). Hard altitude suppression prevents
    needless ETA generation and the possibility of ETA discontinuties.
   If an altitude amendment (aka hard altitude amendment) is indicated,
    cm_amend_util_process_hard_alt_amd() is called to determine if this amendment takes
    place within the hard altitude amendment suppression zone. If the amendment occurs
    within the suppression zone, an indication is set that informs RA and DP that
    suppression is necessary. Pre-suppression altitude and in suppression zone indication are
    set when the flight is within the suppression zone; if the flight is not in the suppression
    zone, and the flight plan indicates the flight was previously in the suppression zone, then
    the pre-suppression altitude and in suppression zone indication are cleared.
   Forwards the AK route and amendments to all interested processes if necessary
    (ism_handle_ak_amd()). This include stream class changes where necessary, FID, route,
    ATC_TYPE, departures, destination, configuration, and altitude amendments, or if
    route10b or converted route changed. For FID changes, reschedule suppression is
    checked.
   Based on the amendments made, resets the ETA-averaging filters if necessary
    (cm_check_amend_for_reset()).
   If the flights destination has changed, displays the change on a CM message panel
    (check_for_airport_diversion())
   If the flight‟s airport has changed (has_airport_changed()), changes the flight‟s
    information and, if Two Way Host communication is enabled, removes the flight from all
    metering HCS displays by sending a remove from metering (IE_CTAS) message to all
    Hosts actively metering the flight, processing performed by functions
    cmm_meter_removal_by_ac() and cm_send_tway_ie().
   If an AMSG_ACID has ocurred, then data source amend indexes are updated.
   If there is any proposed meter fix, calls cm_send_meter_fix_balance_clear() to send
    TMA_METER_FIX_BALANCE_CLEAR message, to all connected TGUIs matching the
    flight‟s TRACON identifier, to have the proposed meter fix cleared.



                                            113                                        R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



IC_FLIGHT_PLAN_DEL: Handled by ism_handle_fp_del(), which finds the flight plan in the
aircraft tree (find_tree_ac()), and then does the following if the aircraft's TRACON identifier
matches the TRACON identifier within the IC_FLIGHT_PLAN_DEL message received from
ISM (otherwise the flight is not deleted):
 The handler checks if the amendment is a result of a diversion to a different destination
    airport. If so, the handler attempts to create an open slot (cm_os_create_open_slot()). See
    IC_FLIGHT_PLAN_ADD (above) for the message traffic created if the open slot is
    created.
 Records traffic count information in the Occurred list for eligible flights: has an
    appropriate aircraft type index, and is an active arrival or inactive arrival but not a
    blocked or open slot or proposed flight.
 If two-way Host communication is enabled, removes the flight from all metering HCS
    displays by sending a remove from metering (IE_CTAS) message to all Hosts actively
    metering the flight (cmm_meter_removal_by_ac() and (cm_send_tway_ie()).Also resets
    PGUI metering information via a RADAR_METER_TO_PGUI_TWO_WAY message for
    local primary Host center flights only.
 Changes the flights status to inactive (set_inactive()). Not done for open slots.
 Resets the slot if the flight is a blocked slot (bs_reset_slot()), and the fix identifier
    (mfu_clear_fid()).
 Sends a DELETE_FLIGHT_PLAN message to all interested processes, based on aircraft
    category. If the delete is for an open slot, this message is not sent to RA and CAP. If the
    aircraft     is     landed,     also   sends      an    AIRCRAFT_LANDED           message
    (forward_flight_plan_delete()).
 Removes the flight from any CM displays (delete_ac_panel_items(),delete_ac_watch()).
 Removes the flight from CM‟s aircraft tree (tdelete()).

IC_TRACK_DATA: Handled by ism_handle_track_data(). This function calls
ism_put_track_message_into_buffer() puts the track into the global track buffer
g_buffered_track_data[]. This buffer is then processed each aircraft update period, within the
update cycle, by function ism_update_cm_tree_with_buffered_tracks().

IC_SOURCE_STATUS: This message indicates Host or ARTS online/offline status. The
message is handled by ism_handle_source_status(), which interprets and responds to the
contents of the status message. Responses include connecting to a source, disconnecting from
a source, connecting to ISM, disconnecting from ISM with a shutdown of the socket, or
sending current filter information to ISM. ism_handle_source_status() calls
ism_process_source_status(), passing it the status message defined by the following
structures:

        struct Source_status_st
        {
            Source_action_type what_to_do;            /*   connection/disconnect      */
            int dsc_index;                            /*   ism, center, tracon, edr   */
            Source_connection_type type;              /*   mosaic, center, tracon     */
            Ipc_proc_type source;                     /*   DADS, TWOWAY               */
            char hostname[CTAS_STR_SIZE_M];           /*   source's hostname          */
            char service[CTAS_STR_SIZE_M];            /*   source's service port      */
            Source_status_type status_value;          /*   source's up/down status    */



                                            114                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

            char status_message[CTAS_STR_SIZE_M]; /* source's up/down reason         */
        };
        typedef struct Source_status_st Source_status_st;

        enum Source_status_type
        {
            SOURCE_STATUS_ONLINE,
            SOURCE_STATUS_OFFLINE,
            SOURCE_STATUS_NO_DATA
        };
        typedef enum Source_status_type Source_status_type;

        enum Source_action_type
        {
            SOURCE_ACTION_CONNECT,
            SOURCE_ACTION_RECONNECT,
            SOURCE_ACTION_DISCONNECT
        };
        typedef enum Source_action_type Source_action_type;

The ism_process_source_status() function uses the Source_status_type, what_to_do, and
source fields to determine how to process the message.

If the source status_type is SOURCE_STATUS_ONLINE, then the following occurs:

   The what_to_do field is set            to    either   SOURCE_ACTION_CONNECT             or
    SOURCE_ACTION_RECONNECT.

   If    the     source     is     ISM,   then   ism_process_source_status()    calls
    ism_send_filter_configuration()     to   send    ISM      filter   configurations
    (CI_ISMUI_COMMAND message). After filters are sent, CM sends ISM a
    CI_FILTERS_SENT message.

   If the source is ADIF, then the aircraft tree is walked and adar_initialize() is called on
    each node to assist ADIF recovery. This function tells ADIF if a current-TRACON flight
    has missed an approach (CD_MISSED_APPROACH message), if it‟s a priority flight
    (CD_PRIORITY message), or if it has been removed from scheduling suspension
    (CD_SUSPEND_SCHEDULING_COMPLETED message).

   Calls ism_connect_source() to set Active_live_data appropriately. This contains a bitwise
    indication of the connection state for the data sources. If ISM is reconnecting, then an
    APP_INTERFACE_UPDATE message is sent to TGUIs.

If the status_type is SOURCE_STATUS_OFFLINE, then the what_to_do field is set to
SOURCE_ACTION_DISCONNECT, and the source process‟s status is unset in the global
value Active_live_data (ism_disconnect_source()).

If the status_type is SOURCE_STATUS_NO_DATA, then uac_reset_first_tracon_track_time()
is called. This function sets each aircrafts first TRACON track to to not set (Ac_st-
>first_tracon_track=NOT_SET)            by          calling    twalk         function
uac_reset_first_tracon_track_time_twalk() on each node.


                                           115                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009



Finally ism_process_source_status() calls ism_set_update_period() to update the global
Aircraft_update_period.      This      function      examines       each   data source‟s
DSC_data_source_config_t->track_update_period (the expected time between track
updates), and sets the update time to that source with the fastest period.

IC_SOURCE_MESSAGE: Handled by ism_handle_source_message(), which calls bswprint()
to print a text string in the scrollable text box at the bottom of the main CM window.

IC_FLIGHT_INFO: Handled by ism_handle_flight_info(), which processes flight information
amendment messages received from ISM. This information arrives in the following
structure:

        typedef struct amend_flight_info_st
        {
            msg_hdr_st                  msg_hdr;
            char                        acid[ID_LENGTH];

             /*
              * Set a bit for each field that contains amended flight info and
              * unmask it in target to read the contents of the msg
              */
             Flight_info_amendment_bit   amend_flight_info_msgs;
             CTAS_flight_info_st         amended_flight_info;

        } amend_flight_info_st;

The message indicates what information has been amended by setting a corresponding bit in
the Flight_info_amendment_bit enumeration:

        typedef enum
        {
            FLT_INFO_MSG_NONE                   = 0,
            FLT_INFO_MSG_T_ALT                  = (1<<0),
            FLT_INFO_MSG_HOLD_INFO              = (1<<1),
            FLT_INFO_MSG_LOST_TRK               = (1<<2),
            FLT_INFO_MSG_TRACON_RWY_FROZEN      = (1<<3),
            FLT_INFO_MSG_IN_TRACON_RWY_HORIZON = (1<<4),
            FLT_INFO_MSG_ON_FLT_PLN             = (1<<5),
            FLT_INFO_MSG_ON_FLT_PLN_OR_PAR      = (1<<6),
            FLT_INFO_MSG_TRACK_DATA_SOURCE      = (1<<7),
            FLT_INFO_MSG_BLOCKED_SLOT_INFO      = (1<<8),
            FLT_INFO_MSG_FILED_AK_ROUTE         = (1<<9),
            FLT_INFO_MSG_METER_LIST_INDICATOR   = (1<<10),
            FLT_INFO_MSG_METERING_FIX_TIME      = (1<<11),
            FLT_INFO_MSG_NOFIX_INFO             = (1<<12),
            FLT_INFO_MSG_EDCT_TIME              = (1<<13),
            FLT_INFO_MSG_DEP_TIME_IN_USE        = (1<<14),
            FLT_INFO_MSG_COMPRESSED             = (1<<31)
        }               Flight_info_amendment_bit;

The ism_handle_flight_info() function searches the aircraft tree for the specified flight plan
(find_tree_ac()). Next, the message handler checks the message‟s amendment bits, and calls
the following functions if their corresponding amendment bit is set:
 ism_flight_info_interim_alt() - Sets the flight‟s altitude information accordingly.



                                           116                                        R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009


   ism_flight_info_lost_track()     –    If     a    drop      track   message     (RH),    calls
    cmm_meter_removal_by_ac() to remove the associated flight from metering lists, also
    sets the flight‟s drop_track field to true. If a restore track message (RH), sets the flight‟s
    drop_track field to false and force_send_to_host field to true.
   For Host converted route amendments, checks for a previously saved Host converted
    route (the saved_host_ak_route field) due to a meter point/fix change to an internal
    departure scheduled flight (ism_process_ak_route()). If a previously saved route is
    found, the new converted route is saved but not processed, and the flight‟s actual Host
    converted route is cleared. Otherwise, the handler first sets the a_ak_route_status field
    based on the Host AK route status, then calls ism_flight_info_amend_ak_route()to
    process the Host converted route amendment. This processing locates the flight‟s meter
    fix/point        and      stream        class/route        (sc_get_stream_class_assignment(),
    sc_get_stream_route_assignment()). In the event of an FID change, the handler calls
    cm_amend_util_determine_prevent_reschedule() to set the flight‟s reschedule
    suppression flag appropriately. The flight‟s flight plan status is updated based on the
    FID, and if any meter fix/point reassignment is done, appropriate amendments are sent
    out (send_flight_plan_amendment()). Any related overcrossing items are reset
    ((cm_amend_util_reset_crossing()). Miscellanous fix information for the flight is saved
    (cmm_save_and_check_mrp_info()). If the flight‟s nofix status (previous_nofix_state) or
    pseudo fix has changed, sends an AMEND_FLIGHT_INFO message to interested
    processes (send_flight_info_amend_nofix()) and removes the flight from metering
    displays (cmm_meter_removal_by_ac()). If the AK route is valid forwards it in an
    AMEND_FLIGHT_INFO message to RA (ism_forward_ak_route()).
   ism_flight_info_meter_list_indicator() – Processes meter list suppression information
    amendments.
   ism_flight_info_hold() – Sets the flight‟s hold information accordingly.
   For proposed aircraft, if an EDCT time change amendment has arrived, then send it (via
    an AMEND_FLIGHT_INFO message) to DP, RA, and TGUI processes in the same
    TRACON group. If CM is currently using EDCT time for the aircraft, CM sends an ETA
    request to the owning RA process for the flight. If a change to EDCT time, and the aircraft
    is currently using EDCT time, then check if the new EDCT time removes the aircraft from
    hovering (cm_amend_util_check_hover_ac()).
   Any other amendments are forwarded to all RA, DP, PGUI, and TGUI processes.

Lastly, if the AK route was received, the flight‟s received_ak_route flag is set to true.

IC_FLIGHT_CHANGE: Handled by ism_handle_flight_change(). Flight changes are are
enumerated by Flight_change_en:

        enum Flight_change_en
        {
            FLIGHT_CHANGE_MISSED_APPROACH = 0x01,
            FLIGHT_CHANGE_PRIORITY        = 0x02,
            FLIGHT_CHANGE_RESET_SEQUENCE = 0x04,
            FLIGHT_CHANGE_SUSPEND         = 0x08,
            FLIGHT_CHANGE_RUNWAY          = 0x10,
            FLIGHT_CHANGE_MASK            = 0x1f
        };
        typedef enum Flight_change_en Flight_change_en;




                                             117                                            R10
CM SRDD                                                            CSC/CFF-03/0065
April 2009



The ism_handle_flight_change() function processes the IC_FLIGHT_CHANGE message as
follows:

   If the FLIGHT_CHANGE_MISSED_APPROACH bit is set then
     Sets or clears the MISSED_APPROACH_MODE bit in Ac_st->user_constraint.modes.
     Sends the new user constraints (PGUI_USER_CONSTRAINTS message) to all
         interested processes (send_user_constraints()).

   If the FLIGHT_CHANGE_PRIORITY bit is set then
     Sets or clears the PRIORITY_MODE bit in Ac_st->user_constraint.modes.
     Sends the new user constraints (PGUI_USER_CONSTRAINTS message) to all
         interested processes (send_user_constraints(ac, NULL)).

   If the FLIGHT_CHANGE_SUSPEND bit is set then
     Sets the Ac_st->scheduling_suspended state.
     Sends            a         CD_SUSPEND_SCHEDULING_COMPLETED    or
         CD_RESUME_SCHEDULING_COMPLETED            message    to ADIF
         (send_id_message_to_dads()).
     Sends a SCHEDULING_SUSPENDED or SCHEDULING_RESUMED message to all
         DPs and GUIs.

   If the FLIGHT_CHANGE_RUNWAY bit is set then
     Sets the Ac_st->scheduling_suspended state.
     Sets     the   flight  plan‟s   runway.     Sets flight_plan.runway_frozen     to
         FROZEN_BY_CONTROLLER.
     Sends an AMEND_FLIGHT_PLAN message to all interested processes.

IC_SWAP_AC: Handled by ism_handle_swap_ac(), which involves the following data
structures:

        struct order_swap_st g_multiswap[ MX_SWAPPABLE ];
        struct order_swap_st *g_ac_xc_array[ MX_SWAPPABLE ];
        struct g_swap_array_st g_swap_array[ MX_SWAPPABLE ];

        struct order_swap_st
        {
            char ac_name[ID_LENGTH];
            int cid;
            struct Ac_st *ac;
            int time;
        };

Aircraft to be swapped are passed in a swap structure:

        struct Swap_ac_st
        {
            Id_st acid1;
            Id_st acid2;
            int cid1;




                                           118                                 R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

             int cid2;
             char reference[CTAS_STR_SIZE_M];
             int sequence_num;
             int block_transmission_num;
       };
typedef struct Swap_ac_st Swap_ac_st;

ism_handle_swap_ac() does the following:
 Readies a reject message in case one is needed (cm_tway_update_reference_data()).
 Initializes the swapping data structures (cm_swap_initialize_swap()).
 Loads the g_ac_xc_array[]swap table with the swap data (cm_swap_fill_host_swap_table
   ()).
 Ensures         both      aircraft     can      be     swapped        with      one   another
   (cm_swap_validate_host_swap()). Confirms the aircraft data is correct, and checks a
   series of criteria for each aircraft entered in the swap table. Criteria include
         Data represents different flights
         Active aircraft (that is, in the CM aircraft tree and being actively metered)
         Frozen aircraft
         Same airport, gate, and aircraft type
 Swaps the aircraft (cm_swap_swap_two_ac()()). This results in the aircraft switching
   positions on the metering lists.
 On swap failure sends an information reject (IR) to HDIF via ISM (cm_send_tway_ir()).

IC_RESEQUENCE_AC: Handled by ism_handle_resequence_ac().
Process resequence aircraft messages from ISM. The resequence data structure is defined as
follows:

        struct Resequence_ac_st
        {
            int num_ac_to_resequence;
            Id_st acid[RESEQUENCE_AC_ST_MAX];
            int cid[RESEQUENCE_AC_ST_MAX];
            char reference[CTAS_STR_SIZE_M];
            int sequence_num;
            int block_transmission_num;
        };

The handler does the following:

   Readies a reject message in case one is needed (cm_tway_update_reference_data()).
   Initializes resequence data structures (cm_swap_initialize_swap()). These are the same as
    used for IC_SWAP_AC.
   Fills the swap table (cm_swap_fill_host_swap_table()).
   Determines the current order of the selected aircraft, based on time
    (cm_swap_establish_current_positions()).
   Validates swapping (cm_swap_validate_host_swap()).
   Calls cm_swap_xc_swap() to do the aircraft data swapping (swaps the aircraft metering
    information, which results in the aircraft switching positions in the meter list).
   On resequence error, sends an information reject (IR) to HDIF via ISM
    (cm_send_tway_ir()).



                                            119                                        R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



IC_TIME_SYNC: Handled by ism_handle_time_sync(), which send messages to sync up time
throughout CTAS. This includes the following processing:
 Sets the internal CTAS time to the desired time truncated to seconds
    (ct_manipulate_current_time()). This change is communicated to all processes attached to
    the CM.
 Sends the new time update rate, new time offset and a set of reference times to all
    connected processes (send_new_time_info_to_all()).
 If not in EDC mode, reset the traffic count control times and recomputes the counts
    (tc_initialize_tc()).

IC_TEST_MESSAGE: This message is handled by ism_handle_test_msg().If the message is a
test request from HDIF, then CM sends an interface reply message (IL_MESSAGE).

IC_HS_MESSAGE: This message contains Host two-way communication and metering state
updates,     and    is    handled      by    ism_handle_hs_msg().       This    function  calls
parse_a_two_way_event() to parse these messages from HDIF, as follows:
 If the message indicates METEROFF, then the specified Host‟s host_accepting_metering
   is set to false, CM distributes SOURCE_TWOWAY_METER_CHANGE messages to all
   interested TMA processes, and CM removes all aircraft from metering for that Host via
   IE_CTAS messages.
 If the message indicates METERON, then the specified Host‟s host_accepting_metering is
   set to true, and CM distributes SOURCE_TWOWAY_METER_CHANGE messages to all
   interested TMA processes. If the Host and CTAS are already in two-way mode, metering
   begins for the specific Host. An IX_MSG will be generated and sent for each metering
   eligible arrival airport and IM_MSG messages are generated as flights become metering
   eligible.; otherwise, the request fails and error messages are sent to HDIF and TGUI.
 If the message indicates -TWOWAY, then the host_using_two_way_option state is set to
   false for all Hosts. When this status is received from the primary Center, two-way
   communication and metering are not on, enabled, or accepted by any Host.
 If     the     message      indicates     DEGRADED,       then     the     specified   Host‟s
   host_not_in_degraded_state flag is set to false (this prevents two-way communication
   and metering). The DEGRADED message occurs when HDIF fails to connect to a specific
   Host in two-way mode and is forced to degrade the connection to One Way mode
Note: Host interface state updates (interface up or down) arrive via the M&C-sent
APP_INTERFACE_UPDATE message.

IC_MISC_INFO: Causes CM to send a flight plan ETA request to the owning RA for the
flight indicated in the message. This message is handled by ism_handle_misc_info_msg().

AC_TRACON_SCRATCH_PAD: This message is handled by ism_handle_scratch_pad()
forwards the scratchpad to all connected PGUIs.

3.14.5.4       ISM Termination and Cleanup
ISM shutdown is handled by cm_ism_close(), which does the following:




                                            120                                        R10
CM SRDD                                                                CSC/CFF-03/0065
April 2009


   Shuts down all connected data sources, by constructing and sending a
    SOURCE_ACTION_DISCONNECT                  message,    with a      value       of
    SOURCE_STATUS_OFFLINE, to each connected source (ism_socket_quit()). Each source
    is disconnected by a call to ism_disconnect_source().
   Closes the ISM socket connection (ism_socket_quit()).

3.14.6 M&C Processing
The M&C starts, restarts, and terminates CTAS processes, supervises socket connections, and
manages all CTAS hardware and software components. Messages arriving from the M&C are
processed by cm_mc_msg().

3.14.6.1       M&C Connection and Initialization
Upon receiving the first MC message, cm_mc_msg() sets the global static MCapp to point to
the passed in App_st, and clears the Ifc_update array. This array stores interface update
messages sent from the M&C. These stored messages are sent to a TGUI upon initial
connection or reconnection. These data structures are defined as follows:

        static App_interface_update_st      Ifc_update[MAX_INTERFACE_TYPE];

        typedef struct
        {
            msg_hdr_st            msg_hdr;             /* message header */
            interface_type        interface;           /* interface whose status */
                                                       /* has changed */
             Interface_status    status;               /* 0=down 1=up 2=warn */
             uchar_t             op_mode;              /* 0=standby 1=active */
             time_t              detect_time;          /* detection time */
             Bool_type          display_info;        /* 0=do not display I/F status */
                                                     /* 1=display status on TGUI */
            char                faa_id[MAX_FAA_ID_LEN]; /* 3char NULL term. faa fac id
        */
        } App_interface_update_st;

        typedef enum
        {
            WTHR_INTERN_IF = 1,       /*   internal weather interface */
            WTHR_EXTERN_IF,           /*   external weather interface */
            HOST_IF,                  /*   HOST interface */
            ARTS_GW0_IF,              /*   AGW0 interface */
            ARTS_GW1_IF,              /*   AGW1 interface */
            MONITORCONTROL_IF,        /*   M&C interface */
            STARS_AIG_IF,             /*   STARS AIG interface */
            TMA_OUTPUT_IF,            /*   Output from TMA interface */
            MAX_INTERFACE_TYPE        /*   Number of interface types */
        } interface_type;


3.14.6.2       M&C Message Handling
M&C message processing is described in the following paragraphs.

APP_CLEANUP_SOCKET: Handled by cm_mc_app_cleanup(). This function looks up the
message‟s associated entry in the application table, and calls cm_app_cleanup(), which does
the following:




                                            121                                     R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


   Calls cm_close(), which in turn calls application-specific socket cleanup routines
    (cm_ra_close(), cm_dp_close(), …).
   Clears the index-to-type table (cm_app_ida_clr()).
   Clears the application table entry (cm_app_clr()).

APP_IDENTIFIER: Handled by cm_mc_app_identifier(). This message is sent by the M&C to
inform an application of its instance identifier. When CM receives this message, it indicates
that the M&C is making the backup CM into the primary. The following processing occurs:
 Breaks the socket connection with CMp (cm_close()). In this case CMb has received the
    APP_IDENTIFIER before it has detected the CMp loss (and closed its connection to it)
    and when the M&C has told CMb to be primary.
 Sets process type (PROC_CM), instance, and facility global statics (cm_com_ini()).

APP_INIT_CONNECT: Handled by cm_mc_app_init_connect(). The M&C sends this
message to request that a CM socket connection be made to a service process (HDIF, IDR, or
another CM). This message is defined by the App_init_connect_st structure, which specifies a
service type:

        /*
          * APP_INIT_CONNECT - m&c->client to initiate connection
          */
        typedef struct
        {
             msg_hdr_st   msg_hdr;                 /* message header */
             service_type svc_service;             /* service to connect to */
             process_type svc_process;             /* server process to connect to */
             uchar_t      svc_instance;            /* instance of server process */
             uchar_t      svc_facility;            /* facility of server process */
             char        svc_host [MAX_HOSTNAME_LEN]; /* host name of srvr process */
             ushort_t     svc_port;                /* TCP port of server process */
             char         faa_id[MAX_FAA_ID_LEN]; /* 3 char NULL term. FAA fac. id */
             ushort_t     two_way;               /* Should only be used by HDIF - */
                                                 /* it will indicate whether this */
                                                 /* facility will need a one way or */
                                                 /* two way connection */
        } App_init_connect_st;

        typedef enum
        {
            NONE_SVC=0,
            DR_SVC,                 /*   data recording service */
            CM_SVC,                 /*   communications manager */
            ISM_SVC,                /*   input source manager */
            HDIF_SVC,               /*   host data interface */
            ADAR_OP_SVC,            /*   ADAR 2-way */
            ADAR_SUPP_SVC,          /*   ADAR support string */
            ADIF_SVC = ADAR_SUPP_SVC,    /* ADIF service */
            HADDS_SVC,              /*   HOST service */
            WEATHER_SVC,            /*   weather service */
            GUI_RTR_SVC,            /*   GUI router service */
            MC_SVC,                 /*   monitor & control */
            IDR_SVC,                /*   Internal Departures relay service */
            MAX_SERVICE_TYPE        /*   Number of service types */
        } service_type;

The APP_INIT_CONNECT message is processed as follows:


                                           122                                       R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009


  If CM still thinks the process is connected, close the socket connection (cm_close()) before
   trying to reconnect.
 Calls functions depending on service_type.
    ISM_SVC: cm_ism_connect()
    CM_SVC: cm_cm_connect()
    IDR_SVC: cm_idr_connect()
Each connection function creates creates a non-blocking socket connection on the host/port
specified in the message, initializes service-specific data structures, creates a temporary
application object in the application table, sends an initial message to the service
(CS_INITIAL_MESSAGE           for     ISM_SVC,       SEND_HOSTNAME            for   CM_SVC,
REMOTE_SEND_HOST_NAME for IDR_SVC), and sends an APP_CONNECTED message
back to M&C.

APP_INIT_LISTEN: Directs the CM to open a listening socket. Handled                          by
cm_mc_init_listen(), which does the following:
 Establishes a listening socket on the specified port (cm_com_listen()):
    Creates the socket (createListenSocket(_TCP_PROTO))
    Begins listening (beginListenTCPI())
    Sends an APP_LISTENING message to M&C (cm_mc_snd_app_listening())
 Sets the CM listening socket entry in the SSA for the CM listening socket (ssa_set()).

APP_INTERFACE_UPDATE: Handled by cm_mc_app_interface_update(), which updates
the interface update array (Ifc_update[]), and calls cm_mc_snd_app_ifc_update() to forward
the Host interface update message to all TGUIs/CAP, and TRACON interface updates to
PGUIs. If the interface update message originated from WDPD, then the weather file status is
updated accordingly. If the message indicates a Host is connecting (IF_UP), then the handler
calls center_host_connection() to have Two-Way flags set for the given host; if the message
indicates     a    Host    disconnecting     (IF_DOWN),      then     the    handler    calls
center_host_disconnection() to clear all Two-Way and metering flags for the given Host.

APP_HEARTBEAT: Sends message back to the M&C via cm_com_write_app(). This lets the
M&C know that CM is healthy.

APP_SHUTDOWN: Handled by cm_mc_shutdown(), which calls cm_shutdown() to do the
following:
     If not in EDC mode, flushes the occurred list if not empty (tc_cleanup_tc()).
     Sends an application exiting message back to the M&C if connected
       (cm_mc_snd_app_exiting(NORMAL_SHUTDOWN)).

APP_CONTROL_RECORDING: Handled by cm_mc_app_control_recording() to handle data
record settings. This message is defined by the following structure:

        typedef struct
        {
            msg_hdr_st            msg_hdr;                   /*   message header */
            uchar_t               recording_state;           /*   OFF = 0, ON = 1 */
            Recorded_data_type    recorded_data_type;        /*   enumeration */
            long                  max_file_size_kbytes;      /*   max file size in kbytes */



                                            123                                        R10
CM SRDD                                                                CSC/CFF-03/0065
April 2009

            int                 max_file_duration_hrs; /* file length in hrs */
            uchar_t             interfaces [PROC_COUNT];/* msg interface control */
        } App_control_recording_st;

Recording types are as follows:

        typedef enum
        {
           HADDS_MSG = 1,
           ETMS_MSG,
           HDIF_MSG,
           ADAR_MSG,
           ADIF_MSG = ADAR_MSG,
           EDIF_MSG,
           CM_MSG,
           CAP_MSG,
           ISM_MSG,
           GUIR_MSG,
           DBGMSG_DATA,
           TGUI_DELAY,
           USER_XML,
           USER_ASCII,
           USER_MSG,
           USER_BIN,
        } Recorded_data_type;

Recording settings for each recording types are stored in global log structures, defined as
follows:

typedef struct log_s log_st;

struct log_s
{
    char         pathname[128];    /* current pathname */
    char         userpath[MAX_PATH_SIZE];     /* user requested pathname */
    char         userfile[MAX_FILE_SIZE];     /* user requested filename */
    char         description[11];    /* 10 characters - used in filename */
    char         process[6];        /* adar, cm, hadds, hdif, ism, dp, pfs, etc */
    char         data_type[4];      /* three character type: dbg, msg, etc */
    short int    data_format;       /* 0 = binary, 1 = ascii */
    short int    recording_state; /* 0 = off, 1 = on */
    int          fd;                /* open log file descriptor */
    short int    sequence;          /* current log sequence number (init to 0) */
    short int    recorded_data_type; /*enumeration type */
    long         maximum_size_bytes; /* max size of log file (byte) (0=none) */
    int          max_file_duration_hrs; /* max duration in hours (0=none) */
    int          stop_time_hour; /* next hour to close/reopen */
    long         current_size;      /* current size of log file (bytes) */
    short int    current_gmt_hour; /* hour at the time a file was opened */
    short int    current_gmt_day; /* log file rollover day at midnight*/
    short int    current_gmt_mon; /* used for path name and file name*/
    short int    current_gmt_year; /* used for path name and file name */
    char         interfaces [PROC_COUNT]; /* binary msg interfaces */
    facb_t       callback_day;    /* file rollover app call back */
    facb_t       callback_opn;    /* file opening app call back */
    facb_t       callback_cls;    /* file closing app call back */
};

cm_mc_app_control_recording() calls cm_mc_handle_rec() to handle the data recording
change processing. For each recording data type occurs as follows the handler calls


                                          124                                       R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

ctas_file_mc_message() which calls ctas_file_control() to insert data recording settings from
the APP_CONTROL_RECORDING message into the global CM log_st structure, and then
call either ctas_file_close() if recording is being turned off, or calls ctas_file_open() if
recording is being turned on.

APP_HCI_CONNECT_SET: This message toggles the two-way connection state for TMA
data source connections, (local primary or adjacent Hosts), and is handled by
cm_mc_app_hci_connect_set(). The handler calls two_way_proc_twoway_change() which
updates the two-way state for the given data source, affecting the metering display fo all
TRACON groups for that data source. The handler sends an APP_INFO message to the M&C
if the two-way connection state changes or remains the same, sends an APP_WARNING
message if the change failed, and sends the updated Two Way state value via the
SOURCE_TWOWAY_METER_CHANGE message, to all interested processes and HDIF via
ISM when the change request completes successfully.

APP_FLIGHT_INFO_REQ: The M&C requests flight information with this message, which is
handled by cm_mc_app_flight_info_req(). The handler returns the message to the M&C
populated with the requested information (currently total flight plans and tracks).

APP_GROUP_START: This message specifies a new TRACON group, or an update to an
existing TRACON group. The message handler, cm_mc_app_group_start_req(), does the
following:
 Maps to the shared memory adaptation for the TRACON group named within the
    APP_GROUP_START message. The message handler returns if shared memory mapping
    is unsuccessful.
 Stores the current TRACON identifier, and determines the adaptation directory path that
    matches the TRACON group.
 Reads in local (read-write) adaption to process global memory (input_data_files()), and
    initializes local data structures (initialize_tracon_items()).
 Flag the TRACON group as started in the global Tracon_start[]. CM checks this global to
    determine if a TRACON has been started, before sending TRACON data to CAP.
 Sends an APP_GROUP_STARTED message back to the M&C.
 If CAP is connected (and this is CMp), sends TRACON-related data (flow rate changes,
    airport metering status, configurations, SSC/MSSD data) to the connected CAP
    (cm_cap_tracon_data()).

APP_GROUP_STOP: The message handler, cm_mc_app_group_stop_req(), marks the
TRACON or meter point group‟s adaptation as “don‟t use”, sends an
APP_GROUP_STOPPED message back to the M&C, clears SSC and MSSD identifiers from
all current and future lists, and clears traffic count lists (except for meter point groups). The
handler then determines whether a TRACON being stopped is the last active TRACON or
not. When there is an active TRACON still running after stopping the requested TRACON,
processing ends. When there are no active TRACONs and only the "core" group is running,
the CTAS metering flag is disabled, and the CM “Two Way and Metering Status” (F3) panel
is updated for every metering-eligible Center; all other Two Way and Metering flags retain
their current state until changed by normal events. The TRACON group‟s entry in



                                             125                                         R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

Tracon_start[] is cleared, indicating that TRACON data for this group should not be sent to
CAP.

3.14.7 GUIR Processing
GUIR acts as a multiplexor for remote PGUIs and TGUIs. Rather than sending the same
message multiple times, CM sends the message once to the GUIR, which fans it out to all
interested GUIs that are connected to the GUIR. GUIR messages are handled by
cm_guir_msg(). GUIR is designed to support a single facility. If CTAS needs to invoke
displays on more than a single adjacent facility, additional GUIRs must be invoked to
support them.

3.14.7.1       GUIR Connection and Initialization
The GUIR‟s SEND_HOST_NAME message is handled by cm_guir_init() which checks the
TRACON information before allowing a connection, calls cm_con_open_close() to check the
connection‟s health, and outputs an indication of the GUIR connection to the CM GUI.

3.14.7.2       GUIR Message Handling
The CLOSE_CM_CONNECTION is handled by cm_guir_close_connect(). This message is
sent by the GUIR to CM when the GUIR has lost a GUI connection. Informs CM and M&C.
Calls cm_close() to close the remote GUI connection.

3.14.7.3       GUIR Termination and Cleanup
GUIR shutdown is handled by cm_guir_close(), which does the following:
 Closes any remote GUIs connected through the closing GUIR (cm_close_remotes()). This
  is done by cycling through the application table, and calling cm_close() on all
  applications that have the GUIR as a relay (that is, App_st->relay points to the GUIR‟s
  entry in the application table).
 Closes the GUIR socket (cm_con_open_close()).

3.14.8 WDPD Processing
WDPD converts site-specific raw weather files, provided by the CTAS Remote Weather
Service (CREWS), into binary weather files usable to CTAS. Weather data includes wind
component speeds, temperature, and pressure versus latitude/longitude for the site at hand.
Once the binary file has been successfully processed, WDPD distributes the file, via ftp, to all
workstations configured with weather clients, and sends a message to CM stating the name
and full path location of the new weather file. CM then forwards this message to all
processes having interest in weather data, and manages the update process. Weather
messages are handled by cm_wdpd_msg().

3.14.8.1       WDPD Connection and Initialization
The WDPD SEND_HOST_NAME message is handled by cm_wdpd_init(),which calls
cm_con_open_close() to check the connection‟s health, and writes an indication of the WDPD
connection to the CM GUI. Also sets the global WDPD pointer (WDPDapp) to point to the
WDPD entry in the application table.




                                            126                                         R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009


3.14.8.2      WDPD Message Handling
The WDPD_CM_NEW_WTHR message is handled by cm_wdpd_new_wthr(), which
updates the global weather information structure from the contents of the message. This will
cause a weather update the next time CM goes through an update cycle and the
cm_wdpd_update() function is called.

3.14.8.3      WDPD Termination and Cleanup
WDPD shutdown is handled by cm_wdpd_close(), which outputs to file or the CM GUI an
indication of the socket closing (cm_con_open_close()), and sets the global WDPDapp to 0.

3.14.9 CM Processing
The cm_cm_msg() function handles peer-to-peer CM communications (that is,
communications between the primary and backup CMs). This communication revolves
around downloading aircraft and other information from CMp to CMb.

3.14.9.1      CM Connection and Initialization
The SEND_HOST_NAME message is sent from CMb to CMp, and is handled by
cm_cm_init(). This function handles CMp initialization of CMb – downloading of the flight
database, and global information. This processing proceeds as follows:
 Writes an indication of the CMb connection to a file and the CM GUI
   (cm_con_open_close()).
 Sets global CmBack to point to the CMb entry in the application table
   (cm_app_backup_set()).
 Sends (synchronizes) CM time (initialize_time_info()).
 Verifies       the    TRACON       information       before    allowing   a   download
   (cm_app_verify_connection()).
 Downloads information to the backup CM (cm_dld_encode()). Encodes and downloads
   the flight database to CMb for database synchronization. Encodes and sends the
   following to CMb:
    Application information – The application table is sent via CM_DOWNLOAD_APP
       message (possibly multiple messages depending on application table contents)
    General        Global  Information      -   The     following    are sent  via    the
       CM_DOWNLOAD_GLOBAL general message: blocked slot list, global information
       (see cm_common.h), interface status, data source configuration information, traffic
       count information, host communication (two way) information, weather information,
       scheduler settings and stream class settings from lib.
    Download TRACON related items (blocked intervals, state of data flow to TGUIs,
       which TGUI has control for DRS duties, number of aircraft distributed to each RA,
       current speed advisory mode of each PGUI, blocked interval changes, flow changes,
       MSSD information (EDC), etc.) for each arrival TRACON (cm_dld_tracon_encode()).
    General Flow Information – The following flow information is sent via a
       CM_DOWNLOAD_GLOBAL flow message: runway, meter fix, gate, super stream,
       TRACON, and airport flows.
    Two types of CM_DOWNLOAD_AC messages: LANDED_AC for each landed
       aircraft, and TREE_AC for each aircraft in the aircraft tree. Each landed aircraft‟s



                                          127                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

        Ac_st is sent in a separate message and entered in the CMb‟s Landed_aircraft list.
        Then each Ac_st in the aircraft tree is sent in a separate message to CMb.
     Lastly, CM_DOWNLOAD_COMPLETE is sent (cm_snd_hdr()).
   Sends a CTAS_AIRPORT_AMDT_CHANGE message to to the initializing CMb. This
    message       contains    AMDT       (delay)      information    for    the    outer arcs
    (cm_airport_utils_send_amdt_lists()).
   Sends CTAS_MP_AIRPORT_METER_STATUS_LIST (EDC only) message to the CMb to
    update its list of gate/meter point values.
   Sends the CTAS_AIRPORT_METER_STATUS_LIST message to CMb to update its list of
    arrival metering airport toggle values.
   Sends an AIRPORT_INTERNAL_DEP_BUFFER message to CMb to update its satellite
    departure airport buffer list.

See section 3.14.1, CM Active Replication, for more information on CM downloads.

3.14.9.2       CM Message Handling
CM peer message handling is described in the following paragraphs. Most messages involve
keeping CMb in synch with CMp during runtime, as system values change.

The VERSION_ID_OK message is sent by CMp to CMb in response to the CMb‟s
SEND_HOST_NAME message. Calls cm_con_open_close(), which checks the connection‟s
health, and outputs an indication of the CMp.

TOO_MANY_CONNECTS, INVALID_VERSION_ID, INVALID_SITE_ID: These messages
are sent from CMp to CMb when a connection error occurs. All result in an APP_CRITICAL
message being sent to the M&C (cm_mc_snd_app_critical()), and CMb exiting.

CM_OFFLINE_CLOCK_UPDATE: This message is sent from CMp to CMb to synchronize
time, and is handled by cm_cm_clock_update(). The offline clock structure is defined as
follows:

        typedef struct
        {
                msg_hdr_st                msg_hdr;
                long                      new_offset;
                double                    new_rate;
                double                    real_sec;
                double                    real_usec;
                double                    mod_sec;
                double                    mod_usec;
        } cm_offline_clock_update_st;

CM_DOWNLOAD_APP: This message is sent from CMp to CMb. It contains application
information used to populate CMb‟s application table, and is handled by
cm_dld_app_decode().

CM_DOWNLOAD_GLOBAL: This message is sent from CMp to CMb, contains global
variable information used to populate CMb global variables and flow data used to populate
CMb flow lists, and is handled by cm_dld_global_decode()).


                                           128                                       R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009



CM_DOWNLOAD_AC: This message is sent from CMp to CMb, and is handled by
cm_dld_ac_decode()).Two types of CM_DOWNLOAD_AC messages exist: LANDED_AC
message contents are used to populate CMb‟s landed aircraft list; TREE_AC message
contents are used to populate CMb‟s aircraft tree.

CM_DOWNLOAD_COMPLETE: Signals the completion of the CMb download. The function
two_way_update_meter_twoway() is called to ensure that the two-way connection and
metering status display panel is updated with the current values after the download is
complete. The CMb sends a CTAS_GUI_PREF_FILE_LIST to CMp to synchronize their user
preference lists (cm_pref_list_send()).

CM_LOST_CONNECTION: Handled by cm_cm_lost_process()). Manages processing for
handling lost process msgs from CMp. CMp sends this message to CMb to let it know when
CMp has lost a process connection (simply to keep the two CM‟s states synchronized, since
CMb has no real connection to the processes). Calls cm_close() to close the specified
application.

SOURCE_TWOWAY_METER_CHANGE: Calls two_way_update_meter_twoway() to make
sure that any metering status changed via the primary CM are updated on the backup CM
and that the <F3> "Two Way & Metering Status" display panel is updated on the backup CM
with those changes.

CM_DOWNLOAD_WTHR: Handled by cm_wdpd_receive_wthr_download(). Sends
weather information from CMp to CMb after any weather mode changes or any live weather
file status changes.

CTAS_AIRPORT_AMDT_CHANGE: Handled by cm_airport_utils_process_amdt_msg(),
which updates the appropriate AMDT list information.

CTAS_GUI_PREF_FILE_LIST: Handled by cm_pref_process_pref_file_msg(). Sent between
peer CMs to synchronize T/GUI user preference files.

CM_IO_FILE: Contains a preference file sent by a peer CM when synchronizing T/PGUI
user preference files between CMp and CMb.

CTAS_AIRPORT_METER_STATUS_LIST: Contains the updates for the airport metering
status list.

CTAS_MP_AIRPORT_METER_STATUS_LIST: Contains the updates for the metering status
of EDC meter point/airport pairs. At initial connection, this message sent from CM to TGUI
contains all default adapted values for the specific data source. If a change is made from the
TGUI panel, this message is sent from TGUI to CM and contains all modified MP/airport
combinations.

AIRPORT_INTERNAL_DEP_BUFFER: Updates the departure airport departure delay buffer
(cm_airport_utils_process_internal_dep_buf_msg()).


                                           129                                        R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



SUPER_STREAM_CLASS_FLOW:             Updates      the   SSC   and    MSSD     identifier     lists
(ssc_id_process_recovery()).

3.14.9.3       CM Termination and Cleanup
CM shutdown is handled by cm_cm_close(), which does the following:
 Outputs an indication of socket connection change to a file and the CM GUI
  (cm_con_open_close()).
 Clears out appropriate application fields in all non-reserved entries when CMb loses the
  connection with CMp:

        app->protocol_state = STATE_CLOSED;
        app->temporary = 0;
        app->relay     = 0;
        app->sockRef   = 0;


   Clears the global CmBack pointer (cm_app_backup_set()).

3.14.10        SIP Processing
Simulation Interface Process (SIP) is the interface to the Pseudo Aircraft Simulator (PAS). SIP
messages are handled by cm_sip_msg(). SIP sends only the NEW_RATE message, which
updates the time rate value modifier, then sends the new new time update rate, new time
offset an a set of reference times to DP, RA, TGUI, PGUI, and ISM. This rate indicates the
speed at which file playback will occur (for example, 1, 2, or 4 seconds per second).

When SIP terminates, it is noted to a file and the CM GUI, the time rate value modifier is
reset to 1.0, and the change is forwarded to DP, RA, TGUI, PGUI, and ISM.

3.14.11        IDR Processing
IDR processing supports flights that begin and end within a Center. From CM‟s point of
view, IDR is a remote process with which it shares flight information about internal flights.

Internal Departures Relay messages are handled by cm_idr_msg().

3.14.11.1      IDR Connection and Initialization
At startup the IDR sends a REMOTE_SEND_HOST_NAME message to CM, which initializes
the IDR connection. The handler function calls cm_idr_init() to do the following:
 Assigns a DP instance to the IDR application (cm_app_dp_set()).
 Sets        the    IDR     socket      type    (app->socket_type)        to    IDR_SOCKET
    (cm_app_socket_type_set()).
 If the aircraft‟s TRACON identifier matches the current TRACON identifier, walks the
    aircraft tree (cm_idr_send_twalk()) and, if the flight is locally entered and has not been
    unscheduled, then builds (cm_idr_build_internal_departure_msg()) and sends
    (cm_snd_app()) INTERNAL_DEPARTURE messages to the connecting IDR process.
    Internal departure types are represented by the following enumeration (from
    cm_departures.h), which is a field in each Ac_st:




                                            130                                        R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

        enum Internal_dep_mask_type
        {
           IDMASK_ON                = (1 <<      0),   /*   internal departure flight   */
           IDMASK_ORIGINAL_DATA     = (1 <<      1),   /*   general data recorded       */
           IDMASK_SCHEDULED_BEFOR   = (1 <<      2),   /*   flight scheduled before     */
           IDMASK_LOCALLY_ENTERED   = (1 <<      3),   /*   flight entered locally      */
           IDMASK_ORIGINAL_STA_DATA = (1 <<      4)    /*   STA data recorded           */
        };
        typedef enum Internal_dep_mask_type      Internal_dep_mask_type;


   After   sending      all   locally      entered     internal flights,  then    sends    a
    CM_DOWNLOAD_COMPLETE                  message      to    the connecting    IDR    process
    (cm_snd_idr_hdr()).
   Outputs an indication of the IDR connection to a file and the CM GUI
    (cm_con_open_close()).
   Sets DP control (app->dp_control) to TRUE (cm_app_dp_control_set()) to act as a flag
    that CM has sent all internal, locally entered flights.

On the other side, the IDR process (that is, the pFast CM) receives a REMOTE_HOST_NAME
message from CM, and the IDR reciprocally sends all its locally entered flights in
INTERNAL_DEPARTURE messages.

3.14.11.2      IDR Message Handling
CM‟s internal departure processing is described in the following list. CM uses a state
machine (see cm_dep_handle_state_update()) to logically manage the departure processing.
Internal departure processing proceeds as follows:

   INTERNAL_DEPARTURE message arrives from the IDR, is converted to a
    SCHEDULE_DEPARTURE message and sent to DP for scheduling, and sent to all TGUIs.
    This puts the internal flight in state 1.
   DP responds with a SUGGESTED_DEPARTURE_TIME message which is handled by
    cm_dp_departure_time(). This function calls cm_dep_handle_departure_time() to update
    the aircraft information with the suggested time and forwards the message to all TGUIs.
    If the Controller issued a find STA command, then the flight is moved to state 2; if not,
    then the flight is scheduled and moved back to state 0.
   TGUI responds with a DEPARTURE_STATUS message indicating either accept, accept
    and     freeze,     or  unschedule.       CM  handles   this   TGUI    message      with
    cm_dep_departure_status(), which adds this message to its sent list, forwards the
    message to all DPs, updates the aircraft entry‟s internal departure status (ac-
    >internal_dep.status), and updates the aircraft‟s internal departure state (ac-
    >internal_dep.state) to state 3.
   DP receives and processes the DEPARTURE status message, and sends a
    MSG_PROCESSED message back to CM. The handler function eventually calls
    cm_dep_handle_msg_processed(), which moves flight‟s internal departure state to 0.

When a flight returns to state 0, CM builds and sends an INTERNAL_DEPARTURE message
to the IDR process, which includes the suggested departure time.

The following paragraphs details how IDR messages are handled.


                                           131                                          R10
CM SRDD                                                                CSC/CFF-03/0065
April 2009



INTERNAL_DEPARTURE: Handled by cm_idr_internal_departure(). This message contains
the data necessary for an internal departure flight to be scheduled or unscheduled in a
remote system. This message is defined as follows:

        /*
         * The following is the structure which is used for the INTERNAL_DEPARTURE
         * message which travels between the CM and a remote process.
         */
        struct Int_dep_remote_ipc_st {
            msg_hdr_st   msg_hdr;
            char         acid[64];       /* enhanced acid        */
            char         time_stamp_yr; /* year     (95-) + 1900 */
            char         time_stamp_mon; /* month (0-11)         */
            char         time_stamp_day; /* day     (1-31)       */
            char         time_stamp_hr; /* hour     (0-23)       */
            char         time_stamp_min; /* minute (0-59)        */
            char         time_stamp_sec; /* second (0-59)        */
            char         spare;          /* alignment (unused)   */
            char         status_type;    /* e.g. 'A' - ACCEPT_ID */
            char         dep_time_yr;    /* year    (95-) + 1900 */
            char         dep_time_mon;   /* month (0-11)         */
            char         dep_time_day;   /* day     (1-31)       */
            char         dep_time_hr;    /* hour    (0-23)       */
            char         dep_time_min;   /* minute (0-59)        */
            char         dep_time_sec;   /* second (0-59)        */
            char         spare1;         /* alignment (unused)   */
            char         sched_method;   /* scheduling method    */
            char         arr_apt[64];    /* arr apt              */
            char         arr_rwy[64];    /* arr rwy name         */
            char         dep_cat[64];    /* dep category name    */
        };
        typedef struct Int_dep_remote_ipc_st Int_dep_remote_ipc_st;

Each aircraft structure (Ac_st) contains a field for internal departure flight information,
defined by the following structure:

        struct Int_dep_st {
            char                                                      saved_host_ak_route
        [MAX_HOST_AK_ROUTE_LENGTH];
            Bool_type                    find_best_slot;
            Bool_type                    high_priority;
            Bool_type                    open_slot;
            Bool_type                    mf_updated;
            int                          scheduled_from_tracon_id;
            int                          state; /* processing state */
            int                          pif;    /* entering process' pif */
            int                          faa_coord_time;      /* time from TMC */
            int                          coordination_time; /* time from TMC */
            int                          host_faa_coord_time;     /* from host */
            int                          host_coordination_time; /* from host */
            int                          prev_faa_coord_time;      /* time from TMC */
            int                          prev_coordination_time; /* time from TMC */
            int                         orig_sd_pif;     /* Original Sch Dep app pif */
            int                          dep_cat_when_man_sched_dep;
            unsigned int                 bitmask;/* flags bitmask */
            unsigned int                 buffer;
            Time_type                    otime; /* last complete operation time */
            Time_type                    ctime; /* controller entered time */
            Time_type                    stime; /* scheduler's departure time */



                                          132                                       R10
CM SRDD                                                                CSC/CFF-03/0065
April 2009

            Meter_point_fid             orig_fid;
            Departure_status_type       status; /* controller entered status */
            Flight_plan_amd_fld         amendments; /* amended fields bitmask */
            Departure_tgui_time_comm_st tgui;   /* TGUI time information */
            Departure_tgui_misc_comm_st misc;   /* TGUI misc information */
            Hover_info_st               hover_info; /* hovering information */
            departure_time_st           curr_sched_dep_msg;};
        typedef struct Int_dep_st Int_dep_st;

        typedef enum Departure_status_type
        {
            NO_STATUS_TYPE = NOT_SET,   /*   For TGUI use */
            ACCEPT_ID = 0,              /*   Accept Internal Departure */
            ACCEPT_AND_FREEZE_ID,       /*   Accept and Freeze Internal Departure */
            UNSCHEDULE_ID,              /*   Unschedule Internal Departure */
            FIND_STA_ID,                /*   Find STA for the Internal Departure */
            RESET_ID,                   /*   Reset Internal Departure flight data */
            REJECT_SCH_DEP_TIME         /*   Schedule departure time rejected */
            DP_SCH_REJECT               /*   DP unable to schedule flight */
        }
        Departure_status_type;

Based on the message status type, processing proceeds as follows:
If status is UNSCHEDULE_ID („U‟) then
         Convert INTERNAL_DEPARTURE to a DEPARTURE_STATUS message
             (cm_idr_cnvt_to_ds_msg()).
         Process the converted message (cm_dep_departure_status()). This processing
             includes adding the message to the IDR‟s sent list (rcv_addmsg_sent_list()),
             sending the message to all DPs, and updating the internal departure state
             (cm_dep_handle_departure_status()).

For other status types then
        Convert from INTERNAL_DEPARTURE to a SCHEDULE_DEPARTURE message
           (cm_idr_cnvt_to_sd_msg()).
        Process the converted message. This processing includes storing the internal
           departure information in the aircraft tree, and updating the internal departure
           state, forwarding the SCHEDULE_DEPARTURE message to all DPs and TGUIs,
           sending an AMEND_FLIGHT_PLAN message to all processes with an interest in
           flight plans of that category, and sending a FLIGHT_PLAN_ETA_REQUEST
           message to RA.

INVALID_VERSION_ID: Handled by cm_idr_invalid_version_id(), which sends the M&C
and APP_WARNING message, and closes the IDR application entry (cm_close which calls
cm_idr_close()).

The following two message indicate internal departure scheduling status between CM and
TGUI. The SCHEDULE_DEPARTURE_INFO message contains basic original flight plan and
schedule information for a single internal departure aircraft. The SCHEDULE_ REJECTION
indicates failure to process the last internal departure message (from a TGUI).

3.14.11.3     IDR Termination and Cleanup
IDR termination and cleanup is handled by cm_idr_close(), which does the following:


                                          133                                         R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009


   Outputs an indication of socket connection change to a file and the CM GUI
    (cm_con_open_close()).
   Clears out IDR application information related to the IDR connection
    (cm_app_reset_entry()), as follows:
     Clears the IDR index table (T2i[]) entry (cm_app_ida_clr()).
     Clears the IDR application table entry (cm_app_clr()).

3.14.12       CAP Processing
At connection time, CM sends CAP a downloading containing most of the type of
information in the CM database, including Host interface and metering nformation,
configurations, flow changes, flight plans, inactive and landed aircraft.

CAP Message Processing
CAP connection/reconnection message is handled by (). This handler calls cm_cap_init()
which checks the health of the CAP connection (cm_con_open_close()), then sends CAP the
following:
 CTAS time (initialize_time_info()).
 A SOURCE_TWOWAY_METER_CHANGE message containing the two-way connection
    state for the primary and all adjacent Centers (cm_send_tracon_meter_status()).
 APP_INTERFACE_UPDATE messages containing the metering state for the primary and
    each adjacent Centers (cm_mc_dld_app_ifc_update()).
 TRACON information for each active TRACON as flagged in Tracon_start[]. This
    includes each airports metering status, airport configurations, flow rate changes, and
    SSC/MSSD data (cm_cap_tracon_data()).
 All flight plans (send_all_flight_plans()).
 All inactive aircraft (twalk_send_inactive_aircraft()). This message is not sent for open
    slots.
 All landed aircraft (twalk_send_landed_aircraft()) (not sent for open slots).

For CAP connections that persist, CM sends information updates as they occur.

CAP Termination and Cleanup
CAP termination and cleanup is handled by cm_cap_close(), which does the following:
Outputs an indication of socket connection change to a file and the CM GUI
(cm_con_open_close()).

3.15     Active Replication and Casualty Recovery
CTAS maintains a backup CM in case the primary CM fails. Additionally, CM maintains
recovery data for other CTAS processes to aid in their casualty recovery. Casualty recovery is
supervised by the M&C.

3.15.1 CM Active Replication
Because CM maintains significant amounts of CTAS state information, CTAS must be able
CTAS to survive CM failure. CM Active Replication provides CTAS with the ability to
survive hardware failure of the primary CM machine.




                                           134                                        R10
CM SRDD                                                                  CSC/CFF-03/0065
April 2009

Active Replication employs a second CM machine (CMb) running in parallel with the
primary CM (CMp), and which processes identical input messages and maintains identical
state information in its database.

Both CMs execute in parallel, with CMp responsible for maintaining connections to existing
applications and for sending all input data to the CMb. CMb, in turn, receives all input data
from CMp and uses that information for maintaining its internal database.

All application processes continue to communicate with the CMp only and have no
knowledge of CMb. The primary CM is responsible for sending all input messages to the
backup CM over a dedicated socket connection. Thus CMb has only a single connection with
CMp over which all messages are received.

If CMp fails, M&C redirects all other processes to reconnect to the backup CM and the
former backup CM becomes the primary CM. At some later point, the failed CM machine is
brought back online and assumes CMb duties after having its database synchronized to the
primary CM database.

During startup, CMp is started and after normal initialization (of all other processes connect
to the primary CM), the M&C instructs CMb to connect to CMb. When this connection is
established, all data is processed in parallel. Any responses generated by CMp are sent to the
applications, while responses generated by CMb are dropped.

In order to synchronize the backup CM database with that maintained by the primary CM,
some time is devoted to downloading information from the primary CM to the backup CM
before the system is characterized as being completely recovered.

The cm_download.c file contains code that supports downloading state information to CMb.

At startup, CMb sends a SEND_HOST_NAME message to CMp, which responds by calling
cm_cm_init(). See section 3.14.9.1 for a cm_cm_init() description.

Once all the information is sent, cm_dld_encode() sends a CM_DOWNLOAD_COMPLETE
message to CMb.

During socket reads (performed by cm_com_read() within cm_processing()), CMp‟s
incoming messages are echoed to CMb (cm_com_write()). In this way CMb maintains its
state data in step with CMp.

When the M&C determines that CMp has failed, it assigns CMb the primary role by sending
it an APP_IDENTIFIER message. CMb breaks its connection with CMp and is made primary.
The M&C then instructs the other CTAS to connect to the new CMp.

3.15.2 CTAS Process Casualty Recovery
In general, if there is a problem with a connection, CM indicates that the connection is down
but retains process connection information pending a reconnect. If the process is shut down,
any data that CM retained for that process is cleaned up.


                                           135                                        R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009



In either case CM determines that a connection is broken, invokes processing to indicate that
the connection is down, and retains process information (including connection information).
At this point CM is operating under the assumption that the process will be restarted. Any
messages CM sent that need a reply from the receiving from are maintained while the
connection is down so that they can be resent later on reconnection.

When a CM detects a connection loss, it calls cm_mc_lost_server_client() to determine
whether it‟s a client or server connection lost.

If a server (service) connection (CM peer connection, IDR, ISM) is down, then
cm_mc_snd_app_lost_datafeed() is called to send an APP_LOST_DATAFEED to the M&C. If
the service process is still healthy, the M&C directs CM to reconnect to the service by sending
CM an APP_INIT_CONNECT message, which is handled by cm_mc_app_init_connect().

If a client connection (RA, DP, TGUI) is down, then cm_mc_snd_app_lost_client() is called to
send the M&C an APP_LOST_CLIENT message. In this case, the M&C directs the CM client
to reconnect to CM via an APP_INIT_CONNECT message. The client sends CM a
SEND_HOST_NAME. NOTE message: If a DP connection is lost, DP is killed, and restarted.
All other processes attempt reconnect.

Restarted/Reconnected Process - Upon a successful restart and reconnection, CM sends the
general information needed to bring the connected process up to speed. Furthermore, CM
sends any information that it required to bring the process up to the general state it was in
before the restart/reconnect occurred (this includes forwarding any messages in the sent
list).

CM maintains static information to help with CTAS process recovery. The sent list, sequence
constraint list, and landed aircraft list are maintained by CM to provide newly connecting or
reconnection processes with current information.

The Sent List
CM maintains lists used for casualty recovery that contains messages requiring a response
from the receiving process. Messages are added to the sent list when forwarded by CM to
DP. When DP sends acknowledgement back to CM that a message was received and
processed (via MSG_PROCESSED), the message is then removed from the sent list.

If the target process fails before acknowledgement can be sent, any messages in the sent list
are sent to the target process again after it has been restarted and reconnected. The
cm_recovery.c file contains functions that maintain the sent list.

Sequence Constraint List
CM also maintains a sequence constraint list for DP casualty recovery. The App_st
application structure contains the sequence constraint list definition:

        struct list_list   *seq_constraints;




                                            136                                        R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

The seq_constraint.c file contains functions that initialize, store, and delete sequence
constraints received from the TGUI.

When      CM      processes       a       TGUI        SEQUENCE_CONSTRAINT                message
(cm_tgui_sequence_constraint()), it first adds it to the sequence constraint list, then forwards
it to DP:

        sqc_add_seq_constr(cm_app_dp(app), (char *) msg);
        cm_snd_dp(msg, size);

When a DP is restarted and connects to CM, a SEQUENCE_CONSTRAINT message is sent
from CM to that DP for any and all sequence constraints in that DP‟s sequence constraint list.
The cm_dp_init() function calls sqc_send_seq_constraints() to do this.

Landed Aircraft List
The landed aircraft list is maintained to bring a new or restarting DP up-to-date on landed
aircraft. The landed aircraft list is defined as follows:

        static list_list    *Landed_aircraft;

At CM startup, initialize_system() calls rcv_create_landed_list() to initialize the landed
aircraft list.

When aircraft are reported as landed (for example, during the update cycle), a copy of the
aircraft‟s Ac_st is added to the landed aircraft list (rcv_add_landed_aircraft()). After a
prescribed period, current TRACON aircraft are deleted from the landed aircraft list
(rcv_del_landed_aircraft()).

If not in EDC mode, when a DP is restarted and connects to CM, an AIRCRAFT_LANDED
message is sent (along with other recovery messages) from CM to that DP for any and all
current-TRACON landed aircraft in the list. The cm_dp_init() function calls
rcv_send_landed_aircraft() to do this.

3.15.2.1       TGUI Recovery
When a TGUI is restarted and connects, CM sends the following information:
 Flight Plans - Sends a flight plan for all flights in the aircraft tree to the TGUI.
 Priority flights - CM receives these flights in a PRIORITY_AIRCRAFT_RESCHEDULE
  message from the TGUI. The information is stored in ac->user_constraint.modes. The
  message        is     forwarded     to     the      RA.     The       RA      then   sends   a
  PRIORITY_AIRCRAFT_RESCHEDULE message to the DP and TGUI.                                   The
  PRIORITY_AIRCRAFT_RESCHEDULE message will be sent for each priority aircraft
  when a TGUI is restarted and connects to CM.
 Inactive and landed aircraft - CM sends an AIRCRAFT_INACTIVE message out for those
  aircraft that are truly inactive (no track updates) and those that areinactive because they
  have entered the landed zone area.
 Landed aircraft - CM sends an AIRCRAFT_ LANDED message out for landed aircraft
  (that is, aircraft that have entered the landed zone area, and landed is TRUE).



                                            137                                         R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009


   Meter fix balancing- Controllers can propose a flight go over a given meter fix. RA then
    computes the new ETA over the proposed meter fix and send it for display on the TGUI.
    CM stores this information in the aircraft tree. The controller can remove the proposal
    from the TGUI at a later time. This infomation is sent to TGUI on restart.
   Internal Departures - CM receives SCHEDULE_DEPARTURE messages from the TGUI.
    CM stores the internal flight information, and on restart, forwards the TGUI the
    information.
   STAs – CM sends a SCHEDULE message containing STAs for all flights in the aircraft
    tree to the restarting TGUI.
   Time - Sends a CM_OFFLINE_CLOCK_UPDATE message to synchronize time
   Current airport configuration.
   Minimum runway spacing.
   Satellite departure categories.
   TGUI user preference information – Sent via a CM_IO_FILE message.
   Current weather status – Sent via WEATHER_SOURCE_UPDATE message.
   Local primary Host center and adjacent center Two Way and Metering status via the
    SOURCE_TWOWAY_METER_CHANGE message.
   Current live weather file status via the CTAS_WTHR_FILE_STATUS message.
   Interface (Host, ADIF, weather) status.

3.15.2.2      PGUI Recovery
When a PGUI is restarted and connects, CM sends the following recovery information:
 All flight plans.
 Each aircraft‟s sector owner.
 Which aircraft that have scheduling suspended (ac->scheduling_suspended).
 CTAS and scheduled meter fix crossing times.
 Sends each aircraft‟s user constraints, any indication of a trajectory error, and if the
  aircraft is in it‟s final arrival state.
 Runway information.
 Area, sector, and weather status.
 Current airport configuration.
 Time - Sends a CM_OFFLINE_CLOCK_UPDATE message to synchronize time.
 PGUI configuration – Sent via a CM_IO_FILE message.
 Weather               information        (CTAS_GET_NEW_WTHR_FILE),              altimeter
  (PGUI_ALTIMETER_SETTING),                  and     ground       wind         information
  (CM_GROUND_WIND_SETTING).
 Scheduling (PGUI_SCHEDULING_STATUS).
 Local primary Host center and adjacent center Two Way and Metering status via the
  SOURCE_TWOWAY_METER_CHANGE message.
 Current live weather file status via the CTAS_WTHR_FILE_STATUS message.

3.15.2.3      ISM Recovery
On ISM restart/reconnect, CM sends ISM the following information:
 Current system time via a CM_OFFLINE_CLOCK_UPDATE message.
 A DOWNLOAD_FLT_BEGIN_MESSAGE message.
 All flight plans in the CM database (via CI_ADD_FP messages).


                                          138                                        R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009


   A DOWNLOAD_FLT_END_MESSAGE message.

3.15.2.4       DP Recovery
When DP fails and restarts, CM sends the following information:
 Flight plans – CM sends an ADD_FLIGHT_PLAN message to the DP for each flight plan
  in the aircraft tree (send_all_flight_plans()).
 Suspended aircraft – CM sends DP a SCHEDULING_SUSPENDED message for each
  suspended aircraft in the aircraft tree (send_suspended_aircraft()).
 Overcrossing flights – CM sends DP a AC_CROSSING_INFO message for meter fix
  overcrossing flight information.
 Frozen flights (including manually scheduled flights) - CM receives this status in the
  SCHEDULE message sent from DP, and stores the current Schedule_st information into
  the aircraft tree. It also keeps track of the flight's frozen status in ac->previous_frozen.
  When a DP is restarted and connects to CM, SCHEDULE messages are sent for all frozen
  flights.
 Priority flights - CM receives these flights in a PRIORITY_AIRCRAFT_RESCHEDULE
  message from the TGUI. CM stores this information in ac->user_constraint.modes, and
  forwards       the     message       to    the    RA.     The     RA     then      sends     a
  PRIORITY_AIRCRAFT_RESCHEDULE message to the DP and TGUI. CM sends this
  reschedule message for each priority aircraft when a DP is restarted/reconnected to CM
  (twalk_send_priority_aircraft()).
 Internal Departures – CM sends DP SCHEDULE_DEPARTURE messages with
  information on any internal departure flights.
 Sequence Constraints – At runtime, CM receives sequence constraints in a
  SEQUENCE_CONSTRAINT message from a TGUI. CM stores the constraint information
  in the aircraft‟s aircraft tree node (sqc_add_seq_constr()). The constraints are stored in the
  DPs app->sequence_constraint list. If DP fails and is restarted, CM puts the contents of
  this list into a SEQUENCE_CONSTRAINT message and sends it to the DP
  (sqc_send_seq_constraints()).
 Landed Aircraft – Another casualty recovery list maintained by CM is the landed aircraft
  list. CM maintains the static global list Landed_aircraft. When CM discerns that an
  aircraft has landed, it broadcasts an AIRCRAFT_LANDED message, and adds the flight
  to Landed_aircraft. On DP failure/restart and when not in EDC mode,
  rcv_send_landed_aircraft()         walks     Landed_aircraft     and     sends      DP      an
  AIRCRAFT_LANDED message for each aircraft in the list.
 Pending messages – CM maintains a list of messages sent to DP that are awaiting a
  response known as the sent list (app->sent_list). When a message requiring a response is
  sent to DP, CM adds it to the DP‟s sent_list. When CM receives a response for the
  message, it is removed from the DP‟s sent_list. If DP fails/restarts, any messages in the
  sent_list are resent to DP.
 Airport configuration – Sends the current airport configuration (via an INIT_CONFIG
  message).
 Time – Sends the current system time (via CM_OFFLINE_CLOCK_UPDATE)
 Satellite departure categories –via an SD_AIRPORT_CONFIG message

When CM is done sending restart data, it sends DP a CM_DATA_COMPLETE message.



                                            139                                         R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009



3.15.2.5       RA Recovery
If there is a problem with an RA connection, CM indicates that it is down but retains other
connection information for the process, pending a restart/reconnect. If a process is explicitly
shut down, any data that was being held for that process is cleaned up. As usual, CM is
notified by the M&C when an application is shutdown. On startup, CM sends RA the
following:
 Current airport configuration
 Current system time
 Current weather information
 Satellite departure categories
 All flight plans
 ETA requests for inactive flights that haven‟t had a previous ETA
 PGUI options/selections/constraints
 Meter fix balance information (TMA_METER_FIX_BALANCE)

Additionally, an RA load redistribution is performed by calling
check_and_redistribute_aircraft_to_ras().

3.16 CM Shutdown
CM shuts down when an APP_SHUTDOWN message is received from the M&C. The
cm_shutdown() function processes this message, and does the following:

   If not in EDC mode, cleans up the occurred list (tc_cleanup_tc()).
   Prints a sorted list of message counts (counted by the library function msg_count(), which
    is called within cm_com_read() and com_com_write().
   Sends the M&C an APP_EXITING message (cm_mc_snd_app_exiting()).




                                            140                                         R10
CM SRDD                                                                              CSC/CFF-03/0065
April 2009



                                Appendix A CM Requirements

0017   3.1        Spiral_1                           CM          The following condition SHALL      RPR057 -1/26/98,
                                                                 be indicated to the air traffic    RPR159 -3/17/98,
                                                                 user: a) A TGUI has not            RPR414 -3/23/01
                                                                 received schedule updates for a    adapt type.
                                                                 system parameter length of time
                                                                 (Site Adaptable Installation
                                                                 Data). See requirements 0017b
                                                                 - 0017c
0017b 3.1         Spiral_1                           CM          The following condition SHALL      RPR057 -1/26/98,
                                                                 be indicated to the air traffic    RPR159 -3/17/98,
                                                                 user: b) A TGUI has not            RPR414 -3/23/01
                                                                 received radar track updates for   adapt type.
                                                                 a system parameter length of
                                                                 time(Site Adaptable Installation
                                                                 Data).
0017c 3.1         Spiral_1                           CM          The following condition SHALL      RPR057 -1/26/98,
                                                                 be indicated to the air traffic    RPR159 -3/17/98,
                                                                 user: c) The percentage of         RPR414 -3/23/01
                                                                 ETAs received and displayed by
                                                                 the TGUI during an update cycle
                                                                 is below a system parameter
                                                                 percentage of Estimated TIme of
                                                                 Arrivals (ETAs) (Site Adaptable
                                                                 Installation Data).
0065   3.2        3.9.0, 3.5.0, 3.1.4.26, 2.3.7.2,   System CM   For the purposes of system         RPR027
                                                                 design and performance, each       RPR716
                  S1                                             TMA system SHALL have the          RPR1098
                                                                 capability of populating a         RPR1337
                                                                 maximum of 50 Timeline             RPR1613
                                                                 Graphical User Interface (TGUI)
                                                                 displays and 50 Planview
                                                                 Graphical User Interface (PGUI)
                                                                 displays.
0135   3.2.1      Spiral3.2                          SMC CM      Changes to the state of TMA        RPR1116 -3/2/04
                                                     TGUI PGUI   processing for a TRACON (e.g.,
                                                     GUIR ISM DP restarts, termination) SHALL not
                                                     RA TS       impact the outputs for other
                                                                 TRACONs.


0169   3.2.1.1    3.1.6, 3.3.0, 3.4.0, 3.7.0         Multiple      TMA SHALL support up to 8        This requirement
                                                                   Adjacent Centers.                was transferred
                                                                                                    from the CHI spec
                                                                                                    to the system
                                                                                                    spec.


0180   3.2.1.1.   Spiral_1/S2                        CM DP PGUI TMA SHALL read and use the          RPR412 -2/7/00
                                                     RA TGUI TS following adaptation databases:     item g, RPR582 -
                                                                a. Meter fixes (Host adapted        9/28/00
                                                                meter fixes, CTAS meter fixes,
                                                                Scheduling meter fixes) See
                                                                requirements 0180e – 0180h.
0180e 3.2.1.1     NASA_prototype                     CM DP PGUI TMA SHALL read and use the          TGUI is
                                                     TGUI       following adaptaation databases:    Spiral_1d1/2/3
                                                                e. Stream class definitions.



                                                 141                                                 R10
CM SRDD                                                                               CSC/CFF-03/0065
April 2009

0180f   3.2.1.1    NASA/Spiral_1                     CM DP TGUI TMA SHALL read and use the             TGUI is
                                                                following adaptation databases:        Spiral_1d2
                                                                f. Permissible super stream
                                                                classes.
0180g 3.2.1.1      NASA/Spiral_1                     CM DP PGUI TMA SHALL read and use the             TGUI is
                                                     RA TGUI TS following adaptation databases:        Spiral_1d1,
                                                                g. TMA adaptable airports (Static      RPR412 -2/7/00
                                                                Site Adaptable Scheduler Data).

0180h 3.2.1.1      NASA/Spiral_1                     CM DP PGUI TMA SHALL read and use the      TGUI is
                                                     RA TGUI TS following adaptation databases: Spiral_1d1
                                                                h. Available runways.
0200    3.2.1.1.   Spiral_1                          CM PGUI      Whenever the TMA function            RPR168 -1/26/98
                                                     TGUI TS      receives new weather data, it
                                                     WDPD         SHALL update its weather
                                                                  information within 30 seconds.
0202    3.2.1.1    3.9.0 - Spec Only, 3.6.3, 3.6.0   CM DP TGUI   For cases in which only the          RPR1382
                                                                  standard TMC swap processing         RPR1410
                                                                  has been enabled in adaptation       RPR1487
                                                                  and TMA has received TMC             RPR1584
                                                                  input to swap two aircraft
                                                                  destined for the same airport
                                                                  where either aircraft type has no
                                                                  adapted restriction on runway
                                                                  use, TMA SHALL re-sequence
                                                                  the affected aircraft by
                                                                  exchanging the STAs and
                                                                  runway assignments, unless a
                                                                  rejection condition is met, as
                                                                  described in requirement [0204].
203     3.2.1.1    3.9.0 - Spec Only, 3.6.3, 3.6.0   CM DP TGUI   For cases in which only the          RPR1410
                                                                  standard TMC swap processing         RPR1487
                                                                  has been enabled in adaptation       RPR1584
                                                                  and TMA has received TMC
                                                                  input to swap two aircraft
                                                                  destined for different airports or
                                                                  where either aircraft type has an
                                                                  adapted restriction on runway
                                                                  use, TMA SHALL re-sequence
                                                                  the affected aircraft by
                                                                  recalculating the runway STAs
                                                                  and exchanging other STAs,
                                                                  unless a rejection condition is
                                                                  met, as described in requirement
                                                                  [0204].
0204    3.2.1.1    3.6.0                             CM DP TGUI   TMA SHALL reject the TMC input of 1382, 1410
                                                                  a swap request if the aircraft have
                                                                  different stream classes that are not
                                                                  in the same superstream.
0204a   3.2.1.1    3.6.0                             CM DP TGUI   TMA SHALL reject the TMC input of 1382, 1410
                                                                  a swap request if the aircraft have
                                                                  different stream classes that are not
                                                                  in the same superstream. a. A
                                                                  different arrival airport (for arrival
                                                                  TMA only)
0204b   3.2.1.1    3.6.0                             CM DP TGUI   TMA SHALL reject the TMC input of 1382, 1410
                                                                  a swap request if the aircraft have
                                                                  different stream classes that are not
                                                                  in the same superstream b. Different
                                                                  stream classes that are not in the
                                                                  same superstream




                                                     142                                                R10
CM SRDD                                                                   CSC/CFF-03/0065
April 2009

0206   3.2.1.1    3.9.0                  CM, DP, TGUI   For cases in which standard       RPR1588
                                                        TMC swap processing has been
                                                        enabled in adaptation and TMA
                                                        has received TMC input to swap
                                                        two scheduled, but not departed,
                                                        internal departure aircraft
                                                        departing from the same airport
                                                        and departure configuration, if
                                                        assigned, TMA SHALL exchange
                                                        the scheduled departure times
                                                        (STDs) in addition to performing
                                                        other standard TMC swap
                                                        processing, unless a rejection
                                                        condition is met, as described in
                                                        requirement (0204).
0252   3.2.1.1    3.9.0                  CM, TGUI       If adapted, TMA SHALL provide RPR1585
                                                        the following as alternate values
                                                        for display on the meter list of
                                                        any upstream meter reference
                                                        point:
0252-a 3.2.1.1    3.9.0                  CM, TGUI       a. MRP name                       RPR1585



0252-b 3.2.1.1    3.9.0                  CM, TGUI       b. Downstream MRP STA           RPR1585



0252-c 3.2.1.1    3.9.0                  CM, TGUI       c. Delay value based on         RPR1585
                                                        downstream MRP delay and
                                                        AMDT
0253   3.2.1.1    3.9.0                  CM, TGUI   When an alternate downstream        RPR1585
                                                    MRP is used TMA SHALL use
                                                    the upstream meter reference
                                                    point's meter list control
                                                    parameters (eg. display/drop
                                                    interval) and aircraft filtering
                                                    during meter determination
                                                    processing.
0210   3.2.1.1.   NASA/S3.1.3.7, 3.5.0   CM DP      Whenever TMA receives the           RPR240-6/11/99,
                                                    Sector Controller command to        RPR983 -
                                                    swap between two and five           8/12/2002,
                                                    aircraft, TMA SHALL re-             RPR1317 -5/23/06
                                                    sequence the affected aircraft by
                                                    exchanging the STAs and
                                                    runway assignments, unless a
                                                    rejection condition is met, as
                                                    described in requirement (0237).
0212   3.2.1.1    Spiral3.4.0            CM DP TGUI Whenever TMA receives TMC           RPR1188 -
                                         RA         input to AutoSwap aircraft (i.e.,   8/31/05, RPR1290
                                                    swap aircraft in a stream class),   -9/23/05
                                                    TMA SHALL re-sequence only
                                                    frozen aircraft by exchanging the
                                                    STAs and runway assignments.
0213   3.2.1.1    Spiral3.4.0            CM DP TGUI TMA SHALL be able to swap           RPR1188 -8/31/05
                                         RA         flights based on: a. altitude.
                                                    See Requirements 0213b -
                                                    0213c




                                         143                                             R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009

0213b 3.2.1.1     Spiral3.4.0        CM DP TGUI TMA SHALL be able to swap        RPR1188 -8/31/05
                                     RA         flights based on: b. holding arc
                                                crossing time


0213c 3.2.1.1     Spiral3.4.0        CM DP TGUI TMA SHALL be able to swap            RPR1188 -8/31/05
                                     RA         flights based on: c. outer arc
                                                crossing time


0215   3.2.1.1    Spiral3.4.0        CM DP TGUI The type of arc to use at a site     RPR1188 -8/31/05
                                     RA         SHALL be defined in site
                                                adaptation data.


0216   3.2.1.1    Spiral3.4.0        CM DP TGUI When swapping, TMA SHALL           RPR1188 -
                                     RA         exempt from swapping aircraft in 8/31/05, RPR1290
                                                the stream that do not have a      -9/23/05
                                                crossing time at the arc in use at
                                                the site.
0217   3.2.1.1    Spiral3.4.0        CM DP TGUI TMA SHALL optionally include in RPR1188 -8/31/05
                                     RA         swapping any of the following: a.
                                                manually scheduled aircraft.
                                                See Requirement 0217b.

0217b 3.2.1.1     Spiral3.4.0        CM DP TGUI TMA SHALL optionally include in RPR1188 -8/31/05
                                     RA         swapping any of the following: a.
                                                manually scheduled aircraft.
                                                See Requirement 0217b.

0219   3.2.1.1    Spiral3.4.0        CM DP TGUI The meter list broadcast status RPR1188 -8/31/05
                                     RA         SHALL remain in the same state
                                                as it was before the swapping.


0221   3.2.1.1    S3                 CM DP TGUI TMA SHALL be capable of              RPR089 -9/30/97,
                                                handling a maximum of two            TGUI is
                                                future configuration changes at      Spiral_1d3
                                                any given time.
0230   3.2.1.1.   NASA/Spiral_1      CM HADDS The TMA SHALL send the                 RPR061 -1/9/98
                                     HDIFTGUI   following meter list data to the
                                                HCS via the HID/NAS LAN:
                                                a. Aircraft computer ID (CID).
                                                See requirements 0230b -
                                                0230h.
0230b 3.2.1.1     NASA/Spiral_1      CM HADDS The TMA SHALL send the                 RPR061 -1/9/98
                                     HDIF       following meter list data to the
                                                HCS via the HID/NAS LAN: b.
                                                Airport identifier.
0230c 3.2.1.1     NASA/Spiral_1      CM HADDS The TMA SHALL send the                 RPR061 -1/9/98
                                     HDIF       following meter list data to the
                                                HCS via the HID/NAS LAN: c.
                                                Runway configuration.
0230d 3.2.1.1     NASA/Spiral_1      CM HADDS The TMA SHALL send the                 RPR061 -1/9/98
                                     HDIF       following meter list data to the
                                                HCS via the HID/NAS LAN: d.
                                                Airport acceptance rate.
0230e 3.2.1.1     NASA/Spiral2.1.4   CM HADDS The TMA SHALL send the                 RPR061 -1/9/98,
                                     HDIF       following meter list data to the     RPR170 -1/26/98,
                                                HCS via the HID/NAS LAN: e.          RPR582 -9/28/00
                                                Assigned CTAS meter fix or
                                                meter fix arc and, if adapted, the



                                     144                                              R10
CM SRDD                                                                            CSC/CFF-03/0065
April 2009

                                                             assigned outer fix.




0230f   3.2.1.1   NASA/Spiral2.1.4/ Spiral3.4.0   CM HDIF    The TMA SHALL send the              RPR061 -1/9/98,
                                                  HADDS RA   following meter list data to the    RPR170 -1/26/98,
                                                  TGUI       HCS via the HID/NAS LAN: f.         RPR582-9/28/00,
                                                             Scheduled time of arrival (STA) RPR990 -9/18/02,
                                                             to the CTAS meter fix or meter RPR1155 - 8/4/04,
                                                             fix arc and, if adapted, the outer RPR1277 -8/8/05
                                                             meter arc.                          spec update only
0230g 3.2.1.1     Bld3.1.4.1/Bld3.1.4.22/         CM HDIF    The TMA SHALL send the              RPR061 -1/9/98,
                  Bld3.1.4.26/ Spiral3.4.0        HADDS RA   following meter list data to the    RPR170 -1/26/98,
                                                  TGUI       HCS via the HID/NAS LAN: g.         RPR582 -9/28/00,
                                                             Delay to absorb prior to reaching RPR990 -9/18/02,
                                                             the CTAS meter fix or meter         RPR1076 - 8/4/03.
                                                             meter arc and, if adapted, outer RPR1155 -8/4/04,
                                                             fix arc. The delay time will be     Spiral3.4.0,
                                                             sent to the HCS in the form "(-     RPR1277 -8/8/05
                                                             )mms", where s is tens of           spec update only
                                                             seconds. If adapted for delay
                                                             time rounding, delay times sent
                                                             to the HOST will be rounded to
                                                             the nearest tens of seconds. If
                                                             adapted for delay time
                                                             truncating, delay time minutes
                                                             sent to the HOST will be rounded
                                                             down and have the tens of
                                                             seconds set to zero. The HCS
                                                             controls the format of the delay
                                                             time display on the DSR.
0230h 3.2.1.1     NASA/Spiral2.1.4                CM HADDS   The TMA SHALL send the              RPR061 -1/9/98,
                                                  HDIF       following meter list data to the    RPR170 -1/26/98
                                                             HCS via the HID/NAS LAN: h.
                                                             Special display indicators. If a
                                                             meter fix arc is adapted, the
                                                             meter fix sector display indicator
                                                             will be set to arc mode. If no
                                                             meter fix arc is adapted, the
                                                             meter fix sector display indicator
                                                             will be set to list mode. The outer
                                                             fix sector display will be set to
                                                             arc mode. (See HCS/ATM IRD,
                                                             NAS-IR-82170001, for details).
0231    3.2.1.1   Spiral_1                        CM TGUI    TMA SHALL block the output of RPR599 -9/28/00
                                                             the meter list data after the
                                                             following TMC inputs: a.
                                                             Changes to airport/runway
                                                             configuration or scheduling
                                                             constraints. See requirements
                                                             0231b - 0231k
0231b 3.2.1.1     Spiral_1                        CM TGUI    TMA SHALL block the output of RPR599 -9/28/00
                                                             the meter list data after the
                                                             following TMC inputs: b.
                                                             Changes to TRACON
                                                             acceptance rate.
0231c 3.2.1.1     Spiral_1                        CM TGUI    TMA SHALL block the output of RPR599 -9/28/00
                                                             the meter list data after the
                                                             following TMC inputs: c.
                                                             Changes to TRACON buffer



                                                  145                                           R10
CM SRDD                                                          CSC/CFF-03/0065
April 2009

0231d 3.2.1.1     Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data after the
                                            following TMC inputs: d.
                                            Changes to Gate and Meter Fix
                                            acceptance rates.
0231e 3.2.1.1     Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data aaafter the
                                            following TMC inputs: e.
                                            Changes to stream class miles-
                                            in-trail constraints.
0231f   3.2.1.1   Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data after the
                                            following TMC inputs: f.
                                            Creation of or changes to
                                            Blocked intervals for meter fixes
                                            or runways.
0231g 3.2.1.1     Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data after the
                                            following TMC inputs: g.
                                            Creation of or changes to Single
                                            Gate Free Flow periods.
0231h 3.2.1.1     Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 - 9/28/00
                                            the meter list data after the
                                            following TMC inputs: h.
                                            Reschedule of multiple aircraft.
0231i   3.2.1.1   Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data after the
                                            following TMC inputs: i. Allocate
                                            runway for multiple aircraft.
0231j   3.2.1.1   Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data after the
                                            following TMC inputs: j. Assign
                                            runway for multiple aircraft.
0231k 3.2.1.1     Spiral_1      CM TGUI     TMA SHALL block the output of RPR599 -9/28/00
                                            the meter list data after the
                                            following TMC inputs: k.
                                            Changes to the freeze horizon
                                            settings.
0232    3.2.1.1   Spiral_1      CM TGUI     The output of meter list data       RPR599 - 9/28/00
                                            SHALL be blocked until re-
                                            enabled by the TMC.
0234    3.2.1.1   Bld3.1.4.27   CM TGUI     The meter list data SHALL be        RPR1099 -
                                            able to be filtered by arrival      11/13/03
                                            airport (Dynamic site adaptable
                                            data).
0233    3.2.1.1   Spiral3.2     SMC CM      The output of meter list data for a RPR1116 -3/2/04
                                TGUI PGUI   TRACON SHALL not be blocked
                                GUIR ISM DP or re-enabled due to TMC inputs
                                RA TS       for other TRACONs.
0236    3.2.1.1   S2.1.1        CM          TMA SHALL prevent meter list RPR422 -1/31/00
                                            information from being sent to
                                            the HOST for NOFIX aircraft
                                            when operating in the 320 patch
                                            environment.




                                146                                             R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009

0237   3.2.1.1   Spiral_2           CM           TMA SHALL send a reject               RPR369 -1/11/01
                                                 message to the HCS whenever it
                                                 receives a swap or resequence
                                                 message from a sector controller
                                                 for between two and five aircraft
                                                 and any of the aircraft have: a.
                                                 a different arrival airport See
                                                 requirements 0237b - 0237e
0237b 3.2.1.1    Spiral_2           CM           TMA SHALL send a reject               RPR369 -1/11/01
                                                 message to the HCS whenever it
                                                 receives a swap or resequence
                                                 message from a sector controller
                                                 for between two and five aircraft
                                                 and any of the aircraft have: b. a
                                                 different gate.
0237c 3.2.1.1    Spiral_2           CM           TMA SHALL send a reject               RPR369 -1/11/01
                                                 message to the HCS whenever it
                                                 receives a swap or resequence
                                                 message from a sector controller
                                                 for between two and five aircraft
                                                 and any of the aircraft have: c. a
                                                 different engine type
0237e 3.2.1.1    Spiral_2           CM           TMA SHALL send a reject               RPR369 -1/11/01
                                                 message to the HCS whenever it
                                                 receives a swap or resequence
                                                 message from a sector controller
                                                 for between two and five aircraft
                                                 and any of the aircraft have: e.
                                                 not been frozen
0239   3.2.1.1   3.6.0              CM DP TGUI   TMA SHALL be capable of blocking      1362
                                                 and re-enabling the output of the
                                                 meter list data separately for each
                                                 airport.



0241   3.2.1.1   S2.1.4             CM           Eligibility for non-frozen aircraft   RPR474 -6/19/00
                                                 to be selected for inclusiion in
                                                 the meter list information sent to
                                                 the HOST SHALL be defined as
                                                 Static Site Adaptable Data.
0242   3.2.1.1   S2.1.4/Spiral3.2   CM           Aircraft SHALL be eligible for        RPR474 -6/19/00,
                                                 display on the Host Meter Lists if    RPR995 -7/20/04
                                                 all the following are true: a. The
                                                 flight is frozen, or the receiving
                                                 metering facility is adapted to
                                                 display metering data for non-
                                                 frozen flights See requirements
                                                 0242b and 0242c.
0242b 3.2.1.1    Spiral3.2          CM           Aircraft SHALL be eligible for        RPR995 -7/20/04
                                                 display on the Host Meter Lists if
                                                 all the following are true: b. The
                                                 flight's ETA or distance,
                                                 depending on adaptation, is
                                                 calculated to be inside the meter
                                                 list display interval value
0242c 3.2.1.1    Spiral3.2          CM           Aircraft SHALL be eligible for        RPR995 -7/20/04
                                                 display on the Host Meter Lists if
                                                 all the following are true: c. The
                                                 flight has not yet reached the
                                                 meter reference point, or the
                                                 flight's ETA or diatance,



                                    147                                                 R10
CM SRDD                                                            CSC/CFF-03/0065
April 2009

                                              depending on adaptation, has
                                              not yet reached the meter list
                                              drop point.



0243   3.2.1.1   S2.1.4               CM      TMA SHALL have the capability          RPR474 -6/19/00
                                              to set the frozen status indicator
                                              symbol display parameter to
                                              apply to either frozen or non-
                                              frozen aircraft through Static Site
                                              Adaptable Data.
0244   3.2.1.1   Spiral_2/Spiral3.2   CM      Once an aircraft (frozen or non-       RPR767 -3/23/01.
                                              frozen) is eligible for meter list     This requirement
                                              display, its eligibility for display   is on FCA/PCA
                                              SHALL not change if its ETA or         Waiver #23.
                                              distance, depending on                 RPR995 -7/20/04
                                              adaptation, is calculated to be
                                              outside the meter list display
                                              Interval value.
0247   3.2.1.1   Spiral3.2            CM      Meter list display eligibility         RPR995 -7/20/04
                                              SHALL be computed using the
                                              aircraft's ETA or distance,
                                              depending on adaptation, to the
                                              associated meter reference
                                              point.
0248   3.2.1.1   Spiral3.2            CM/RA   TMA SHALL be capable of                RPR995 - 7/20/04
                                              setting unique static site
                                              adaptable values for each meter
                                              reference point for the following
                                              meter list display parameters: a.
                                              Meter list display interval value
                                              See requirements 0248b - 0248d
0248b 3.2.1.1    Spiral3.2            CM/RA   TMA SHALL be capable of                RPR995 - 7/20/04
                                              setting unique static site
                                              adaptable values for each meter
                                              reference point for the following
                                              meter list display parameters: b.
                                              Meter list display drop parameter
                                              value
0248c 3.2.1.1    Spiral3.2            CM/RA   TMA SHALL be capable of                RPR995 - 7/20/04
                                              setting unique static site
                                              adaptable values for each meter
                                              reference point for the following
                                              meter list display parameters: c.
                                              Meter list display interval value
                                              set by distance or time
0248d 3.2.1.1    Spiral3.2            CM/RA   TMA SHALL be capable of                RPR995 - 7/20/04
                                              setting unique static site
                                              adaptable values for each meter
                                              reference point for the following
                                              meter list display parameters: d.
                                              Meter list display drop parameter
                                              value by distance or time
0249   3.2.1.1   Spiral3.2            CM/RA   TMA SHALL be capable of                RPR995 - 7/20/04
                                              setting unique static site
                                              adaptable values for each
                                              metered facility (local and
                                              adjacent) for the following meter
                                              list display parameters: a.
                                              Display/non-display of



                                      148                                             R10
CM SRDD                                                    CSC/CFF-03/0065
April 2009

                                       frozen/non-frozen aircraft




0249b 3.2.1.1     Spiral3.2   CM/RA    TMA SHALL be capable of            RPR995 - 7/20/04
                                       setting unique static site
                                       adaptable values for each
                                       metered facility (local and
                                       adjacent) for the following meter
                                       list display parameters: b.
                                       Display/non-display of pennant
                                       symbol for frozen/non-frozen
                                       aircraft
0249c 3.2.1.1     Spiral3.2   CM/RA    TMA SHALL be capable of            RPR995 - 7/20/04
                                       setting unique static site
                                       adaptable values for each
                                       metered facility (local and
                                       adjacent) for the following meter
                                       list display parameters: c.
                                       Rounding/truncation of delay
                                       value
0251   3.2.1.1    3.4.1       CM, RA   TMA SHALL provide the              RPR1218 -1/12/06
                                       capability to dynamically use
                                       Special Use Airspace (SUA) in
                                       determining an aircraft's route of
                                       flight.

0270   3.2.1.2.   S3          CM       Upon receipt of a HOST             RPR047 -1/9/98,
                                       converted route, TMA SHALL         RPR329 -9/20/01
                                       determine the following
                                       information based on the current
                                       flight plan information and the
                                       Host converted route: a.
                                       Coordination Time See
                                       requirements 0270b - 0270e.
0270b 3.2.1.2     S3          CM       Upon receipt of a HOST             RPR047 -1/9/98,
                                       converted route, TMA SHALL         RPR329 -9/20/01
                                       determine the following
                                       information based on the current
                                       flight plan information and the
                                       Host converted route: b.
                                       Coordination Fix
0270c 3.2.1.2     S3          CM       Upon receipt of a HOST             RPR582 -9/28/00,
                                       converted route, TMA SHALL         RPR329 -9/20/01
                                       determine the following
                                       information based on the current
                                       flight plan information and the
                                       Host converted route: c. CTAS
                                       Meter Fix
0270e 3.2.1.2     S3          CM       Upon receipt of a HOST             RPR329 -9/20/01
                                       converted route, TMA SHALL
                                       determine the following
                                       information based on the current
                                       flight plan information and the
                                       Host coverted route: e. NOFIX
                                       Indication (TMA Pseudo Fix
                                       determination).




                              149                                          R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009

0275   3.2.1.2       Spiral_1            CM TGUI   Upon receipt of the first track    RPR162 -1/26/98,
                                                   message for a flight plan, TMA RPR1117 -5/10/04
                                                   SHALL delete any duplicate flight
                                                   plans for the same AID from
                                                   TMA processing and display.
0276   3.2.1.2       NASA_prototype      CM        TMA shall delete a flight plan     RPR143 -7/29/99
                                                   from processing and display as a
                                                   result of any of the following: a.
                                                   TMA receives a deletion
                                                   message from the HCS or
                                                   ARTS. See requirement 0276b.
0276b 3.2.1.2        Spiral_1            CM        TMA shall delete a flight plan     RPR143 -7/29/99
                                                   from processing and display as a
                                                   result of any of the following: b.
                                                   the flight plan has not been
                                                   updated for 6 hours.
0325   3.2.1.3.1.1   S3.8.0, S2.1.2.1/   CM        TMA SHALL determine the            RPR329 -9/20/01.
                     S3.1.4_aug                    CTAS meter fix based on logic This requirement
                                                   defined in static site adaptable   is on FCA/PCA
                                                   scheduler data and based on        Waiver #23.
                                                   one of the following: a. Upon      RPR1069 -6/11/03
                                                   receipt of an en route flight plan
                                                   (See requirement 0325b - 0325c)
0325b 3.2.1.3.1.1    S2.1.2.1            CM        TMA SHALL determine the            RPR329 -9/20/01.
                                                   CTAS meter fix based on logic This requirement
                                                   defined in static site adaptable is on FCA/PCA
                                                   scheduler data and based on        Waiver #23
                                                   one of the following: b. Upon
                                                   receipt of an ARTS/STARS flight
                                                   plan when no en route flight plan
                                                   and converted route have been
                                                   received.
0325c 3.2.1.3.1.1    S3.1.4_aug          CM        TMA SHALL determine the            RPR1058 -5/15/03
                                                   CTAS meter fix based on logic
                                                   defined in static site adaptable
                                                   scheduler data and based on
                                                   one of the following: c. Upon a
                                                   change in the airport
                                                   configuration anticipated to be in
                                                   effect at the aircraft's projected
                                                   arrival time.
0330   3.2.1.3.1.1   Spiral_2.1.1        CM        TMA SHALL first attempt to         RPR582 -9/28/00
                                                   assign an aircraft a CTAS meter
                                                   fix using site adaptable logic
                                                   (meter fix decision tree) based
                                                   on the following inputs:       a.
                                                   The presence or absence of site
                                                   specific waypoints in the
                                                   converted route. See
                                                   requirements 0330b - 0330c.
0330b 3.2.1.3.1.1    Spiral_2.1.1        CM        TMA SHALL first attempt to         RPR582 -9/28/00
                                                   assign an aircraft a CTAS meter
                                                   fix using site adaptable logic
                                                   (meter fix decision tree) based
                                                   on the following inputs: b. The
                                                   aircraft`s engine class (i.e.,
                                                   Heavy, Jet, Turboprop or Piston).




                                         150                                         R10
CM SRDD                                                            CSC/CFF-03/0065
April 2009

0331   3.2.1.3.1.1   Spiral_1/S2/         CM    If there is more than one eligible RPR216 -1/4/99,
                     S3.1.4_aug                 CTAS meter fix in the converted RPR582 -9/28/00
                                                route, TMA SHALL assign the         RPR1069 -6/11/03
                                                CTAS meter fix that is farthest
                                                along the route from the current
                                                position.
0332   3.2.1.3.1.2   S2.1.4/ S3.1.4_aug   CM    TMA SHALL assign a meter fix RPR171 -1/26/98,
                                                arc to an aircraft using site       RPR412 -2/7/00
                                                adaptable logic (Static Site        RPR1069 -6/11/03
                                                Adaptable Scheduler Data)
                                                based on the following: a. The
                                                intersection of the projected
                                                converted route with an adapted
                                                meter fix arc. See Requirement
                                                0332b and 0332d.
0332b 3.2.1.3.1.2    S2.1.4               CM    TMA SHALL assign a meter fix RPR171 -1/26/98,
                                                arc to an aircraft using site       RPR412 -2/7/00
                                                adaptable logic (Static Site
                                                Adaptable Scheduler Data)
                                                based on the following: b. The
                                                aircraft`s engine class.
0332c 3.2.1.3.1.2    S2.1.4               CM    TMA SHALL assign a meter fix RPR171 -1/26/98,
                                                arc to an aircraft using site       RPR412 -2/7/00
                                                adaptable logic (Static Site
                                                Adaptable Scheduler Data)
                                                based on the following: c. The
                                                airport configuration anticipated
                                                to be in effect at the aircraft`s
                                                projected arrival time.
0332d 3.2.1.3.1.2                         CM    TMA SHALL assign a meter fix RPR171 -1/26/98,
                                                arc to an aircraft using site       RPR412 -2/7/00,
                                                adaptable logic (Static Site        RPR329 -9/20/01.
                                                Adaptable Scheduler Data)           This requirement
                                                based on the following: d. CTAS is on FCA/PCA
                                                meter fix.                          Waiver #23
0334   3.2.1.3.1.2   S2.1.4               CM    TMA SHALL assign a meter fix RPR171 -1/26/98
                                                arc for an aircraft whenever it: a.
                                                Receives a new flight plan. See
                                                Requirement 0334b and 0334c.
0334b 3.2.1.3.1.2    S2.1.4               CM    TMA SHALL assign a meter fix RPR171 -1/26/98
                                                arc for an aircraft whenever it: b.
                                                Receives a flight plan
                                                amendment for an aircraft
                                                modifying the converted route of
                                                flight.
0334c 3.2.1.3.1.2    S2.1.4               CM    TMA SHALL assign a meter fix RPR171 -1/26/98
                                                arc for an aircraft whenever it: c.
                                                Determines that the aircraft will
                                                land under a different
                                                configuration than currently
                                                assigned.
0340b 3.2.1.3.1.1    Spiral_3             CM    In the event that the site          RPR092 -1/26/98,
                                                adaptable logic (Static Site        RPR412 -2/7/00,
                                                Adaptable Scheduler Data) does RPR582 -9/28/00
                                                not assign a CTAS meter fix from
                                                the route, TMA SHALL: b.
                                                Determine the CTAS meter fix
                                                closest to the TRACON
                                                intersection that is compatible
                                                with the aircraft's engine type.




                                          151                                      R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009

0341   3.2.1.3.1.1   Spiral_2                CM    TMA SHALL assign a scheduling RPR582 -9/28/00
                                                   meter fix using site adaptable
                                                   logic based on the following: a.
                                                   The assigned CTAS Meter Fix.
                                                   (See requirements 0341b -
                                                   0341d)
0341b 3.2.1.3.1.1    Spiral_2                CM    TMA SHALL assign a scheduling RPR582 -9/28/00
                                                   meter fix using site adaptable
                                                   logic based on the following: b.
                                                   The aircraft`s engine type.
0341c 3.2.1.3.1.1    Spiral_2                CM    TMA SHALL assign a scheduling RPR582 -9/28/00
                                                   meter fix using site adaptable
                                                   logic based on the following: c.
                                                   The destination airport.
0341d 3.2.1.3.1.1                            CM    TMA SHALL assign a scheduling RPR582 -9/28/00,
                                                   meter fix using site adaptable      RPR329 -9/20/01
                                                   logic based on the following: d.
                                                   Configuration
0342   3.2.1.3.1.3   NASA/S2                 CM    TMA SHALL assign an outer fix RPR132 -1/9/98,
                                                   to an aircraft using site adaptable RPR412 -2/7/00,
                                                   logic (Static Site Adaptable        RPR582 -9/28/00
                                                   Scheduler Data) based on the
                                                   following: a. The assigned
                                                   CTAS meter fix. See
                                                   requirements 0342b -0342c.
0342b 3.2.1.3.1.3    NASA_prototype          CM    TMA SHALL assign an outer fix RPR132 -1/9/98,
                                                   to an aircraft using site adaptable RPR412 -2/7/00
                                                   logic (Static Site Adaptable
                                                   Scheduler Data) based on the
                                                   following: b. The presence of the
                                                   site adaptable outer fix in the
                                                   converted route of flight.
0342c 3.2.1.3.1.3    Spiral_3                CM    TMA SHALL assign an outer fix RPR132 -1/9/98,
                                                   to an aircraft using site adaptable RPR412 -2/7/00.
                                                   logic (Static Site Adaptable        This requirement
                                                   Scheduler Data) based on the        is on FCA/PCA
                                                   following: c. Adaptable engine Waiver #23
                                                   class.
0344   3.2.1.3.1.3   NASA_prototype/         CM    If there is more than one eligible RPR132 -1/9/98,
                     S3.1.4_aug                    outer fix in the converted route, RPR216 -1/4/99
                                                   TMA SHALL assign the outer fix RPR1069 -6/11/03
                                                   that is farthest along the route
                                                   from the current position.
0346   3.2.1.3.1.3   NASA_prototype/S3.1.5   CM    TMA SHALL assign an outer fix RPR132 -1/9/98,
                                                   for an aircraft whenever it: a.     RPR1117 -5/10/04
                                                   Receives a new flight plan, i.e.
                                                   unknown to TMA. See
                                                   requirement 0346b.
0346b 3.2.1.3.1.3    NASA_prototype          CM    TMA SHALL assign an outer fix RPR132 -1/9/98
                                                   for an aircraft whenever it: b.
                                                   Receives a flight plan
                                                   amendment for an aircraft
                                                   modifying the converted route.
0352   3.2.1.3.1.4   NASA_prototype          CM    TMA SHALL assign an outer           RPR133 -
                     S3.1.4_aug                    meter arc to an aircraft using site 08/13/98, RPR412
                                                   adaptable logic (Static Site        -2/7/00, RPR1069
                                                   Adaptable Scheduler Data)           -6/11/03
                                                   based on the following: a. the
                                                   intersection of the HCS
                                                   converted route with an adapted




                                             152                                      R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

                                                       outer fix arc See requirements
                                                       0352b - 0352d.




0352b 3.2.1.3.1.4    NASA/S2/Spiral3.4.          CM    TMA SHALL assign an outer           RPR133 -
                                                       meter arc to an aircraft using site 08/13/98, RPR412
                                                       adaptable logic (Static Site        -2/7/00, RPR582 -
                                                       Adaptable Scheduler Data)           9/28/00, RPR1277
                                                       based on the following: b.          -8/8/05 spec
                                                       assigned CTAS meter fix, or         update only
                                                       associated CTAS meter fix, as
                                                       applicable
0352c 3.2.1.3.1.4    NASA_prototype/Spiral3.4.   CM    TMA SHALL assign an outer           RPR133 -
                                                       meter arc to an aircraft using site 08/13/98, RPR412
                                                       adaptable logic (Static Site        -2/7/00, RPR1277
                                                       Adaptable Scheduler Data)           -8/8/05 spec
                                                       based on the following: c.          update only
                                                       engine type
0352d 3.2.1.3.1.4    S2.4.2/Spiral3.4.           CM    TMA SHALL assign an outer           RPR638 -3/12/01,
                                                       meter arc to an aircraft using      RPR1277 -8/8/05
                                                       site-adaptable logic (Static Site spec update only
                                                       Adaptable Scheduler Data)
                                                       based on the following: d.
                                                       Aircraft filed altitude.
0353   3.2.1.3.1.4   S3.1.4.5/Spiral3.4.         CM    If an aircraft cannot be assigned RPR1060 –
                                                       an outer meter arc via the above 11/14/02,
                                                       criteria, then TMA SHALL assign RPR1277 -8/8/05
                                                       the first elibible outer fix arc    spec update only
                                                       adapted.
0354   3.2.1.3.1.4   S3.2/Spiral3.4.             CM    If an aircraft is eligible for more RPR133 -
                                                       than one outer meter arc, then 08/13/98,
                                                       TMA SHALL assign the outer fix RPR1277 -8/8/05
                                                       arc furthest along the route of     spec update only
                                                       flight.
0356   3.2.1.3.1.4   NASA_prototype/Spiral3.4.   CM    TMA SHALL assign an outer           RPR133 -
                                                       meter arc to an aircraft whenever 08/13/98, RPR638
                                                       it: a. receives a new flight plan -3/12/01 adds new
                                                       See requirement 0356c.              element c,
                                                                                           RPR1277 -8/8/05
                                                                                           spec update only
0356b 3.2.1.3.1.4    NASA_prototype              CM    TMA SHALL assign an outer fix RPR133 -08/13/98
                                                       arc to an aircraft whenever it: b.
                                                       receives a flight plan amendment
                                                       that modifies the converted route
                                                       of flight or engine type
0356c 3.2.1.3.1.4    S2.4.2                      CM    TMA SHALL assign an outer fix RPR638 -3/12/01
                                                       arc to an aircraft whenever it: c.
                                                       Receives a flight plan
                                                       amendment that modifies the
                                                       filed altitude.
0361   3.2.1.3.1.1   Spiral_2                    CM    TMA SHALL assign a gate for an RPR369 -1/11/01
                                                       aircraft from static site adaptable
                                                       scheduler data based on the
                                                       assigned meter fix.
0362   3.2.1.3.1.1   Spiral_2                    CM    TMA SHALL assign a gate for an RPR369 -1/11/01
                                                       aircraft whenever it: a. receives
                                                       a new flight plan See
                                                       requirement 0362b.


                                                 153                                      R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009

0362b 3.2.1.2.1.1    Spiral_2             CM            TMA SHALL assign a gate for an        RPR369 -1/11/01
                                                        aircraft whenever it: b.
                                                        determines the meter fix has
                                                        changed.
0372   3.2.1.3.1.5   S3.1.4.5             CM            If an aircraft cannot be assigned     RPR1016 -
                                                        an Outer-outer arc via the above      11/14/02, This
                                                        criteria, then TMA SHALL assign       requirement is on
                                                        the first eligible Outer-outer arc    FCA/PCA Waiver
                                                        adpated.                              #23
0381   3.2.1.3.1.6   3.7.0                Multiple      TMA SHALL assign an Outer-
                                                        Three Arc to an aircraft using
                                                        site-adaptable logic (Static Site
                                                        Adaptable Scheduler Data)
                                                        based on the following:
0381-a 3.2.1.3.1.6   3.7.0                Multiple      a. The intersection of the HCS
                                                        converted route with an adapted
                                                        Outer-Three Arc.
0381-b 3.2.1.3.1.6   3.7.0                Multiple      b. Assigned Outer-Outer Arc.



0381-c 3.2.1.3.1.6   3.7.0                Multiple      c. Engine type.



0381-d 3.2.1.3.1.6   3.7.0                Multiple      d. Aircraft assigned altitude.



0383   3.2.1.3.1.6   3.7.0                Multiple      If an aircraft is eligible for more
                                                        than one Outer-Three Arc, then
                                                        TMA SHALL assign the first
                                                        adapted Outer-Three Arc.
0384   3.2.1.3.1.6   3.7.0                Multiple      TMA SHALL assign an Outer-
                                                        Three Arc to an aircraft
                                                        whenever it:
0384-a 3.2.1.3.1.6   3.7.0                Multiple      a. Receives a new flight plan.



0384-b 3.2.1.3.1.6   3.7.0                Multiple      b. Receives a flight plan
                                                        amendment that modifies the
                                                        converted route of flight or
                                                        engine type.
0384-c 3.2.1.3.1.6   3.7.0                Multiple      c. Receives a flight plan
                                                        amendment that modifies the
                                                        assigned altitude.




0385   3.2.1.3.1.6   Spiral3.4.0, 3.7.0   CM CP TGUI TMA SHALL assign a holding arc RPR1188 -8/31/05
                                          RA         to an aircraft using site-
                                                     adaptable logic (Static Site
                                                     Adaptable Scheduler Data)
                                                     based on the intersection of the
                                                     converted route with an adapted
                                                     holding arc.
0387   3.2.1.3.1.7   Spiral3.4.0, 3.7.0   CM CP TGUI If an aircraft is eligible for more RPR1188 -8/31/05
                                          RA         than one holding arc, then TMA
                                                     SHALL assign the first eligible



                                          154                                                  R10
CM SRDD                                                                        CSC/CFF-03/0065
April 2009

                                                          adapted holding arc.



0389   3.2.1.3.1.7   Spiral3.4.0, 3.7.0      CM CP TGUI TMA SHALL assign a holding arc RPR1188 -8/31/05
                                             RA         to an aircraft whenever it: a.
                                                        Receives a new flight plan. See
                                                        Requriements 0389b - 0389c
0389b 3.2.1.3.1.7    Spiral3.4.0, 3.7.0      CM CP TGUI TMA SHALL assign a holding arc RPR1188 -8/31/05
                                             RA         to an aircraft whenever it: b.
                                                        Receives a flight plan
                                                        amendment that modifies the
                                                        converted route of flight.
0389c 3.2.1.3.1.7    Spiral3.4.0, 3.7.0      CM CP TGUI TMA SHALL assign a holding arc RPR1188 -8/31/05
                                             RA         to an aircraft whenever it: c.
                                                        Receives a new airport
                                                        configuration change.
0390   3.2.1.3.2     2.1.1, 2.1.2.1, 3.7.0   CM         TMA SHALL reassign a stream
                                                        class for each aircraft whenever
                                                        any of that aircraft's following
                                                        data changes:
0390-a 3.2.1.3.2     3.7.0                   CM         a. CTAS meter fix



0390-b 3.2.1.3.2     3.7.0                   CM           b. route



0400   3.2.1.3.2                             CM           TMA SHALL assign a stream
                                                          class for each aircraft based on
                                                          site adapted rules that take into
                                                          account:
0400-a 3.2.1.3.2     NASA                    CM           a. Aircraft engine class.



0400-b 3.2.1.3.2     2.1.1, 2.1.4            CM           b. Presently assigned CTAS
                                                          meter fix.


0400-c 3.2.1.3.2     2.1.1                   CM           c. Airport configuration
                                                          anticipated for the time of landing
                                                          at the arrival airport.
0400-d 3.2.1.3.2     NASA                    CM           d. Destination airport.



0400-f 3.2.1.3.2     2.1.1                   CM           f. Departure fix.



0400-g 3.2.1.3.2     2.1.1                   CM           g. Filed altitude.



0400-h 3.2.1.3.2                             CM           h. Filed airspeed.



0400-i 3.2.1.3.2     3.7.0                   CM           i. Route string




                                             155                                                R10
CM SRDD                                                             CSC/CFF-03/0065
April 2009




0410   3.2.1.3.3.   NASA/S2.1.1   CM         Whenever TMA receives a new
                                             flight plan for an aircraft, it
                                             SHALL assign the aircraft to the
                                             default runway based on site
                                             adapted rules that take into
                                             account:       a. Aircraft engine
                                             class. See requirements 0410b
                                             - 0410c.
412    3.2.1.3.3    Spiral3.3.0   CM DP HDIF When TMA modifies the ETA for RPR884 -
                                  ISM RA     an unscheduled internal               12/15/04
                                             departure due to a change in
                                             EDCT processing, and the
                                             change in ETA causes the
                                             aircraft to land in a different
                                             airport configuration, it SHALL
                                             assign the aircraft to the default
                                             runway based on site adapted
                                             rules that take into accunt: a.
                                             Aircraft engine class. See
                                             requirements 0412b and 0412c
412b   3.2.1.3.3    Spiral3.3.0   CM DP HDIF When TMA modifies the ETA for RPR884 -
                                  ISM RA     an unscheduled internal               12/15/04
                                             departure due to a change in
                                             EDCT processing, and the
                                             change in ETA causes the
                                             aircraft to land in a different
                                             airport configuration, it SHALL
                                             assign the aircraft to the default
                                             runway based on site adapted
                                             rules that take into accunt: b.
                                             Assigned stream class
412c   3.2.1.3.3    Spiral3.3.0   CM DP HDIF When TMA modifies the ETA for RPR884 -
                                  ISM RA     an unscheduled internal               12/15/04
                                             departure due to a change in
                                             EDCT processing, and the
                                             change in ETA causes the
                                             aircraft to land in a different
                                             airport configuration, it SHALL
                                             assign the aircraft to the default
                                             runway based on site adapted
                                             rules that take into accunt: c.
                                             Anticipated arrival configuration
                                             at the time of landing.
0414   3.2.1.3.3    3.7.0         CM, TGUI   When TMA modifies the ETA for
                                             an unscheduled internal
                                             departure that has not departed
                                             at its estimated time of
                                             departure, and the change in
                                             ETA causes the aircraft to land in
                                             a different airport configuration, it
                                             SHALL assign the aircraft to the
                                             default runway based on site
                                             adapted rules that take into
                                             account:




                                  156                                              R10
CM SRDD                                                       CSC/CFF-03/0065
April 2009

0414-a 3.2.1.3.3   3.7.0   CM, TGUI     a. Aircraft engine class.




0414-b 3.2.1.3.3   3.7.0   CM, TGUI     b. Assigned stream class.




0414-c 3.2.1.3.3   3.7.0   CM, TGUI     c. Anticipated arrival
                                        configuration at the time of
                                        landing.



0422   3.2.1.3.3   3.6.0   CM DP TGUI   If the TMC entered a command to       1362
                                        "reallocate runway" and selected
                                        airports to be rescheduled, only
                                        flights for those airports SHALL be
                                        affected
0510-l 3.2.1.4     3.7.0   CM, TGUI     TMA SHALL calculate a new
                                        ETA for each aircraft for the
                                        following: l. Change in departure
                                        time for an unscheduled internal
                                        departure that has not departed
                                        at its estimated time of departure
0512   3.2.1.4     3.7.0   CM, TGUI     If enabled, TMA SHALL set an
                                        aircraft's departure time to the
                                        current time for an unscheduled
                                        internal departure that has not
                                        departed an adapted time after
                                        its estimed time of departure.
0514   3.2.1.4     3.7.0   CM, TGUI     TMA SHALL continue to set the
                                        departure time to the current
                                        time until any of the following:


0514-a 3.2.1.4     3.7.0   CM, TGUI     a. the flight has departed




0514-b 3.2.1.4     3.7.0   CM, TGUI     b. the flight is scheduled




0514-c 3.2.1.4     3.7.0   CM, TGUI     c. the controller disables the
                                        departure time resets for the
                                        flight


0514-d 3.2.1.4     3.7.0   CM, TGUI     d. the controller disables the
                                        departure time reset function




                           157                                                 R10
CM SRDD                                                             CSC/CFF-03/0065
April 2009

0514-e 3.2.1.4      3.7.0            CM, TGUI   e. a specified time has passed




0516   3.2.1.4      3.7.0            CM, TGUI   If the departure time reset is
                                                reenabled for the function or for
                                                a flight, adjustments SHALL be
                                                resumed.

0585   3.2.1.4.1.   NASA_prototype   CM TGUI    TMA SHALL calculate and
                                                display the Original ETA (OETA)
                                                calculated as follows:      a. If no
                                                track updates have been
                                                received, the OETA is the most
                                                recently calculated ETA. Seer
                                                equirements 0585b - 0585c.
0585b 3.2.1.4.1     Spiral_1         CM TGUI    TMA SHALL calculate and
                                                display the Original ETA (OETA)
                                                calculated as follows: b. if
                                                between one and five track
                                                updates have been received, the
                                                OETA is the average ETA
                                                resulting from all track updates.
0585c 3.2.1.4.1     Spiral_1d1       CM TGUI    TMA SHALL calculate and
                                                display the Original ETA (OETA)
                                                calculated as follows: c. If more
                                                than five track updates have
                                                been received, the OETA is the
                                                average of the ETAAs resulting
                                                from the first five track updates.
0590   3.2.1.4.1.   NASA/S2.1.4      CM         The percentage of error, in          RPR170 -1/26/98,
                                                absolute value, associated with RPR582 -9/28/00
                                                the final track OETA for a
                                                statistical sample of 500 aircraft
                                                with "unimpeded" flight to the
                                                CTAS meter fix/meter fix arc
                                                SHALL have a sample mean of
                                                not more than 6% and a 99th
                                                percentile of not more than 10%,
                                                respectively, where percentage
                                                error is defined as: [See SSS for
                                                formula]
0692   3.2.1.4.3    3.7.0            Multiple   TMA SHALL define adapted
                                                angle of descent data (optional)
                                                in site adaptation data using:
0692-a 3.2.1.4.3    3.7.0            Multiple   a. flight path angle (descent
                                                angle) in degrees
0692-b 3.2.1.4.3    3.7.0            Multiple   b. calibrated airspeed (CAS) for
                                                the descent portion of the
                                                adapted angle of descent
                                                (optional)

0694   3.2.1.4.3    3.7.0            Multiple   TMA SHALL identify aircraft to
                                                be modeled with adapted angle
                                                descents by categories in site
                                                adaptation data.




                                     158                                            R10
CM SRDD                                                                             CSC/CFF-03/0065
April 2009

0720   3.2.1.4.5.   NASA_prototype              CM            TMA SHALL limit the fluctuation
                                                              of an aircraft`s ETA due to
                                                              estimation errors by:      a. Using
                                                              the most recent flight plan ETA if
                                                              no track updates have occurred.
                                                              See requirements 0720b -
                                                              0720c.
0720b 3.2.1.4.5     NASA/Spiral_1               CM            TMA SHALL limit the fluctuation
                                                              of an aircraft`s ETA due to
                                                              estimation errors by: b.
                                                              Averaging the last five ETAs
                                                              based on track updated provided
                                                              they are available and no change
                                                              has occurred in the route in the
                                                              last five track updates. (NOTE:
                                                              This is known as a moving
                                                              window average.)
0720c 3.2.1.4.5     NASA/Spiral_1               CM            TMA SHALL limit the fluctuation
                                                              of an aircraft`s ETA due to
                                                              estimation errors by: c.
                                                              Averaging all ETAs following a
                                                              route change if a change has
                                                              occurred in the last five track
                                                              updates.
0747   3.2.1.5.1    S2.1.1                      CM TGUI       TMA SHALL provide departure RPR321 -9/20/99
                                                              times to FAST for internal
                                                              departures that have been
                                                              manually scheduled through
                                                              TMA.
0779   3.2.1.5.1    3.6.0                       CM DP TGUI    If multiple arrival airports exist, TMA 1387
                                                              SHALL be capable of
                                                              enabling/disabling freeze processing
                                                              for each airport via site adaptable
                                                              scheduler data or in response to a
                                                              TMC entered command.
0783   3.2.1.5      3.6.0                       CM DP TGUI    For a TMC input of a swap request, 1382
                                                              TMA SHALL disregard the 12
                                                              seconds DP restriction for displaying
                                                              a stabilized STA.
0794   3.2.1.5.5    NASA/S_1/S2.1.2/S3.1.5      CM TGUI    Whenever any of the following is         RPR095 -1/9/98,
                                                           received for a flight whose STA          TGUI is
                                                           is not frozen, TMA SHALL delete          Spiral_1d1,
                                                           the flight from TMA processing           RPR1117 -5/10/04
                                                           and display: a. Manually
                                                           generated Remove Strip
                                                           message. See requirements
                                                           0794b - 0794e.
0794b 3.2.1.5.5     3.8.0, NASA/S2.1.2/S3.1.5   CM TGUI    Whenever any of the following is         RPR095 -1/9/98,
                                                           received for a flight whose STA          RPR1117 -5/10/04
                                                           is not frozen, TMA SHALL delete
                                                           the flight from TMA processing
                                                           and display: b. Amendment that
                                                           changes the flight`s destination
                                                           airport to a non-TMA airport.
0795   3.2.1.5.5    3.8.0                       CM DP TGUI Whenever any of the following is         RPR095 -1/9/98,
                                                           received for a flight whose STA          RPR633 -3/12/01
                                                           is frozen, TMA SHALL convert
                                                           the flight into an "open slot": a.
                                                           Manually generated Remove
                                                           Strip message. See requirement
                                                           0795b - 0795e.




                                                159                                                   R10
CM SRDD                                                        CSC/CFF-03/0065
April 2009

0795b 3.2.1.5.5     3.8.0   CM DP TGUI Whenever any of the following is        RPR095 -1/9/98,
                                       received for a flight whose STA         RPR633 -3/12/01
                                       is frozen, TMA SHALL convert
                                       the flight into an "open slot": b.
                                       Amendment that changes the
                                       flight`s destination airport.
0795e 3.2.1.5.5     3.8.0   CM DP TGUI Whenever any of the following is        RPR095 -1/9/98,
                                       received for a flight whose STA         RPR633 -3/12/01
                                       is frozen, TMA SHALL convert
                                       the flight into an "open slot": e.
                                       Amendment that changes the
                                       flight`s altitude status to VFR.
0797    3.2.1.5.5   3.8.0   CM DP      TMA SHALL delete an "open               RPR095 -1/9/98,
                                       slot" from TMA processing and           RPR633 -3/12/01,
                                       display whenever any of the             RPR1117 -5/10/04
                                       following occurs: a. The "open
                                       slot" is rescheduled See
                                       requirement 0797b - 0797c.


0797b 3.2.1.5.5     3.8.0   CM DP         TMA SHALL delete an "open            RPR095 -1/9/98,
                                          slot" from TMA processing and        RPR633 -3/12/01,
                                          display whenever any of the          RPR1117 -5/10/04
                                          following occurs: b. The STA
                                          expires, (i.e. times out) from the
                                          schedule.
0797c 3.2.1.5.5     3.8.0   CM DP         TMA SHALL delete an "open            RPR095 -1/9/98,
                                          slot" from TMA processing and        RPR633 -3/12/01,
                                          display whenever any of the          RPR1117 -5/10/04
                                          following occurs: c. The "open
                                          slot" is suspended by operator
                                          input on the TGUI.
0798    3.2.1.5.5   3.8.0   CM DP         If a new flight plan or an           RPR095 -1/9/98,
                                          amendment is received that           RPR633 -3/12/01
                                          reverses the condition that
                                          created the "open slot", TMA
                                          SHALL retain the "open slot" and
                                          process the newly entered or
                                          amended flight plan as a unique
                                          new flight plan.
0800i   3.2.1.5.1   3.6.0   CM DP TGUI    i. In response to the TMC-entered    1382
                                          command to swap the STAs of
                                          aircraft
807     3.2.1.5.1   3.8.0   Multiple      TMA SHALL provide the
                                          capability to optionally freeze
                                          aircraft whose STAs are earlier
                                          than a frozen aircraft in the same
                                          super stream, provided that the
                                          aircraft was not manually frozen.
0808    3.2.1.5.1   3.9.0   CM, DP,       If specified by adaptation, TMA RPR1586
                            PGUI, TGUI    SHALL reschedule a manually-
                                          scheduled frozen internal
                                          departure aircraft upon receiving
                                          the first track-based ETA:
0808-a 3.2.1.5.1    3.9.0   CM, DP,       a. if the rescheduling results in RPR1586
                            PGUI, TGUI    an earlier runway or meter
                                          fix/meter fix arc STA, the earlier
                                          runway and meter fix/meter fix
                                          arc STAs will be used and the
                                          current AMDT values reapplied
                                          to any assigned outer arc STAs



                            160                                                 R10
CM SRDD                                                                      CSC/CFF-03/0065
April 2009

0808-b 3.2.1.5.1    3.9.0               CM, DP,      b. if the rescheduling does not RPR1586
                                        PGUI, TGUI   result in an earlier runway or
                                                     meter fix/meter fix arc STA and
                                                     the meter fix/meter fix arc delay
                                                     is
0808-b1 3.2.1.5.1   3.9.0               CM, DP,      1. positive or zero, retain the      RPR1586
                                        PGUI, TGUI   original runway and meter
                                                     fix/meter fix arc STAs and
                                                     reapply the current AMDT values
                                                     to any assigned outer arc STAs
0808-b2 3.2.1.5.1   3.9.0               CM, DP,      2. negative, retain all the original RPR1586
                                        PGUI, TGUI   STAs

0808-c 3.2.1.5.1    3.9.0               CM, DP,      c. Retain or remove the fight's            RPR1586
                                        PGUI, TGUI   manually scheduled status as
                                                     specified in adaptation
0808-d 3.2.1.5.1    3.9.0               CM, DP,      d. Only send metering                      RPR1586
                                        PGUI, TGUI   information to controllers after
                                                     the rescheduling is performed
0814    3.2.1.5.1   S2.1.2/S3.1.4_aug   CM DP TGUI   As s result of the following TMC           RPR550 -5/23/00,
                                                     commands, TMA SHALL                        RPR1058 -5/15/03
                                                     recalculate STAs for frozen
                                                     aircraft that have been manually
                                                     scheduled: a. Configuration
                                                     change (subject to SHALLs
                                                     [0746] and [0744]). (See
                                                     subrequirements 0814b through
                                                     0184e).
0814b 3.2.1.5.1     S2.1.2              CM DP TGUI   As a result of the following TMC           RPR550 -5/23/00
                                                     commands, TMA SHALL
                                                     recalculate STAs for frozen
                                                     aircraft that have been manually
                                                     scheduled: b. THD separation,
                                                     THD separation bufer, THD
                                                     occupancy time change, or THD
                                                     acceptance rate change. (See
                                                     subrequirements 0184b through
                                                     0184e).
0814c 3.2.1.5.1     S2.1.2              CM DP TGUI   As a result of the following TMC           RPR550 -5/23/00
                                                     commands, TMA SHALL
                                                     recalcualte STAs for frozen
                                                     aircraft that have been manually
                                                     scheduled: c. Reschedule this
                                                     aircraft, all aircraft, or this aircraft
                                                     and after. (See subrequirements
                                                     0814b through 0814e).
0814d 3.2.1.5.1     S2.1.2              CM DP TGUI   As a result of the following TMC           RPR550 -5/23/00
                                                     commands, TMA SHALL
                                                     recalculate STAs for frozen
                                                     aircraft that have been manually
                                                     scheduled: d. Reassign runway
                                                     for this aircraft, all aircraft, or this
                                                     aircraft and after. (See
                                                     subrequirements 0184b through
                                                     0814e).




                                        161                                                      R10
CM SRDD                                                               CSC/CFF-03/0065
April 2009

0814e 3.2.1.5.1      S2.1.2      CM DP TGUI As a result of the following TMC RPR550 -5/23/00
                                            commands, TMA SHALL
                                            recalculate STAs for frozen
                                            aircraft that have been manually
                                            scheduled: e. Add/delete MFX or
                                            runway blocked interval. (See
                                            subrequirements 0814b through
                                            0814e).
0822   3.2.1.5.1.    3.6.0       CM DP TGUI    TMA SHALL be capable of                 1362
                                               rescheduling aircraft arriving at
                                               specified airports without changing
                                               the STAs for frozen aircraft at other
                                               airports.
0832   3.2.1.5       Spiral3.2   SMC CM        The schedule for each TRACON RPR1116 -3/2/04
                                 TGUI PGUI     SHALL not be affected by events
                                 GUIR ISM DP   that trigger rescheduling in other
                                 RA TS         TRACONs.



0870s 3.2.1.5.1.1    3.4.1       CM, DP, TGUI TMA SHALL generate a               RPR1312 -1/12/06
                                              schedule for each super stream
                                              class (at the Outer Meter Arc, if
                                              adapted, the CTAS Meter Fix,
                                              the Scheduling Meter or Meter
                                              Fix Arc if adapted, the Final
                                              Approach Fix, and the Runway
                                              threshold) and a set of derived
                                              schedules periodically, nominally
                                              every 6 seconds, or when
                                              triggered by any of a specific set
                                              of events, as follows: s. Change
                                              in the Outer Fix Delay (OFD),
                                              Outer-outer Arc Delay (OOAD)
                                              or Outside Outer-outer Arc Delay
                                              (OOOAD)
0873   3.2.1.5.1.1   3.8.0       Multiple     TMA SHALL allow adapted
                                              CTAS Meter Fixes to be defined
                                              as Mirror Meter Fixes for an
                                              adapted CTAS Meter Fix.



0875   3.2.1.5.1.1   3.8.0       Multiple      TMA SHALL allow the TMC to
                                               dynamically enable or disable
                                               rescheduling when flights are
                                               reassigned to a Mirror Meter Fix.



0877   3.2.1.5.1.1   3.8.0       Multiple      When Mirror Meter Fixes are
                                               enabled and a frozen aircraft
                                               assigned to a CTAS Meter Fix
                                               that is within an adapted
                                               distance from that CTAS Meter
                                               Fix is reassigned to an adapted
                                               Mirror Meter Fix of that original
                                               CTAS Meter Fix TMA SHALL




                                 162                                                    R10
CM SRDD                                                                                CSC/CFF-03/0065
April 2009

0877-a 3.2.1.5.1.1   3.8.0                          Multiple       a. maintain the current STA
                                                                   times to the Mirror Meter Fix and
                                                                   to the runway.




0877-b 3.2.1.5.1.1   3.8.0                          Multiple       b. be notified of any conflict as
                                                                   defined in Static Site Adaptable
                                                                   Scheduler Data.




1050   3.2.1.5.1.7   Bld2.1.2.1/Bld3.2.0/Bld3.4.0/Bld CM, DP, TGUI TMA SHALL calculate schedules RPR170 -1/26/98,
                     3.4.1                                         at the Outer Meter Arc based on RPR412 -1/31/00,
                                                                   the CTAS Meter Fix or Meter Fix RPR582 -9/28/00.
                                                                   Arc schedules, the TTF from the This requirement
                                                                   Outer Meter Arc to the CTAS       is on FCA/PCA
                                                                   Meter Fix/Meter Fix Arc, the      Waiver #24.
                                                                   delay to be absorbed in the       RPR1119 - 3/2/04,
                                                                   Center airspace, any computed RPR1277 -8/8/05
                                                                   Excess Outer Fix Delay EOFD spec update only,
                                                                   and a dynamically assignable      RPR1312 -1/12/06
                                                                   parameter called Outer Fix Delay
                                                                   (OFD) ( Dynamic Site Adaptable
                                                                   Scheduler Data).
1051   3.2.1.5.1.4   3.7.0                            Multiple     Upon a change to the Outer Fix
                                                                   Delay (OFD), TMA SHALL
                                                                   reallocate the delay at the Outer
                                                                   Meter Arc, the Outer-Outer Arc,
                                                                   and the Outer-Three Arc.
1053   3.2.1.5.1.7   3.7.0                          Multiple       Upon a change to the Outside
                                                                   O3A Delay (OO3AD), TMA
                                                                   SHALL reallocate the delay at
                                                                   the Outer Meter Arc, Outer-Outer
                                                                   Arc and the Outer-Three Arc.
1055   3.2.1.5.1.7   3.7.0                            Multiple     Upon a change to the Outside
                                                                   Outer-outer Arc Delay (OOOAD),
                                                                   TMA SHALL reallocate the delay
                                                                   at the Outer Meter Arc, the Outer
                                                                   Outer Arc, the Outer-Three Arc,
                                                                   and Outer Four Arc.
1052   3.2.1.5.1.7   Bld3.2.0/Bld3.4.0/Bld3.4.1       CM, DP, TGUI TMA SHALL compute excess          RPR1119 -3/2/04,
                                                                   delay amounts (for use in         RPR1277 -8/8/05
                                                                   scheduling at the Outer Meter     spec update only,
                                                                   Arc and Outer-outer Arc) only     RPR1312 -
                                                                   when a dynamically assignable 1/12/06
                                                                   parameter called Outside Outer-
                                                                   outer Arc Delay (OOOAD)
                                                                   (Dynamic Static Site Adaptable
                                                                   Scheduler Data) is adapted for
                                                                   an aircraft's assigned OOA.
1092   3.2.1.5.1.5   Bld3.1.3.2/Bld3.2.0/Bld3.4.0/Bld CM, DP, TGUI TMA SHALL calculate schedules RPR643 -5/20/02,
                     3.4.1                                         at the Outer-outer Arc based on RPR1119 -3/2/04,
                                                                   the Outer Meter Arc schedules, RPR1277 -8/8/05
                                                                   the TTF from the Outer-outer Arc spec update only,
                                                                   to the Outer Meter Arc, the delay RPR1312 -1/12/06
                                                                   to be absorbed in the Outer-
                                                                   Center airspace, any computed



                                                   163                                                 R10
CM SRDD                                                                              CSC/CFF-03/0065
April 2009

                                                               Excess Outer-outer Arc Delay
                                                               EOOAD and a dynamically
                                                               assignable parameter called
                                                               Outer-outer Arc Delay (OOAD)
                                                               (Dynamic Static Site Adaptable
                                                               Scheduler Data).

1093   3.2.1.5.1.5   3.7.0                          Multiple   Upon a change to the Outer-
                                                               Outer Arc Delay (OOAD), TMA
                                                               SHALL reallocate the delay at
                                                               the Outer Meter Arc, the Outer-
                                                               Outer Arc, the Outer-Three Arc,
                                                               and the Outer-Four Arc.

1096   3.2.1.5.1.5   3.7.0                          Multiple   Upon a change to the O3AD,
                                                               TMA SHALL reallocate the delay
                                                               at the Outer meter Arc, Outer-
                                                               Outer Arc, the Outer-Three Arc,
                                                               and the Outer-Four Arc.


1101   3.2.1.5.1.7   3.7.0                          Multiple   TMA SHALL calculate schedules
                                                               at the Outer-Three Arc based on
                                                               the Outer-Outer Arc schedules,
                                                               the TTF from the Outer-Three
                                                               Arc to the Outer-Outer Arc, the
                                                               ODCA, any computed EO3AD,
                                                               and a dynamically assignable
                                                               parameter, O3AD (Dynmaic Site
                                                               Adaptable Scheduler Data).
1102   3.2.1.5.1.7   S3.1.4.12/Spiral3.3.0, 3.7.0   CM, DP     TMA SHALL provide the                   RPR1036 -2/4/03,
                                                               capability to suppress normal           RPR1206 -3/1/05
                                                               scheduling functionality for
                                                               aircraft departing from selected
                                                               airports to all or a specified
                                                               arrival airport and provide
                                                               alternative handling instead.
                                                               (Candidate internal departure
                                                               airports, known as locally
                                                               departed airports, will be
                                                               identified for this functionality via
                                                               adaptation (Static Site Adaptable
                                                               Scheduler Data)). The following
                                                               conditions will apply for this
                                                               functionality: See 1102a - 1102e
1102a 3.2.1.5.1.7    S3.1.4.12/Spiral3.3.0, 3.7.0   CM, DP     TMA SHALL provide the                   RPR1036 -2/4/03,
                                                               capability to suppress normal           RPR1206 -3/1/05
                                                               scheduling functionality for
                                                               aircraft departing from selected
                                                               airports to all or a specified
                                                               arrival airport and provide
                                                               alternative handling instead.
                                                               (Candidate internal departure
                                                               airports, known as locally
                                                               departed airports, will be
                                                               identified for this functionality via
                                                               adaptation (Static Site Adaptable
                                                               Scheduler Data)). The following
                                                               conditions will apply for this
                                                               functionality: a) The Scheduler
                                                               will not apply its normal



                                                    164                                                 R10
CM SRDD                                                                         CSC/CFF-03/0065
April 2009

                                                            scheduling algorithms to any
                                                            flight originating from an airport
                                                            listed in the adaptation file and
                                                            flying to all or a specified arrival
                                                            airport. Instead, the Scheduler
                                                            will set the STA of such a flight to
                                                            be equal to its ETA. If the user
                                                            sets a departure time using the
                                                            TGUI interface, the ETA will
                                                            change, and the STA will follow
                                                            exactly.
1102b 3.2.1.5.1.7   S3.1.4.12/Spiral3.3.0, 3.7.0   CM, DP   TMA SHALL provide the                 RPR1036 -2/4/03,
                                                            capability to suppress normal         RPR1206 -3/1/05
                                                            scheduling functionality for
                                                            aircraft departing from selected
                                                            airports to all or a specified
                                                            arrival airport and provide
                                                            alternative handling instead.
                                                            (Candidate internal departure
                                                            airports, known as locally
                                                            departed airports, will be
                                                            identified for this functionality via
                                                            adaptation (Static Site Adaptable
                                                            Scheduler Data)). The following
                                                            conditions will apply for this
                                                            functionality: b) A local
                                                            departure’s STA will not affect
                                                            the STAs of any other flights.
                                                            Note this implies that the
                                                            Scheduler will not schedule such
                                                            flights to achieve legal
                                                            separation or to meet any other
                                                            constraints such as airport
                                                            acceptance rate.
1102c 3.2.1.5.1.7   S3.1.4.12/Spiral3.3.0, 3.7.0   CM, DP   TMA SHALL provide the                 RPR1036 -2/4/03,
                                                            capability to suppress normal         RPR1206 -3/1/05
                                                            scheduling functionality for
                                                            aircraft departing from selected
                                                            airports to all or a specified
                                                            arrival airport and provide
                                                            alternative handling instead.
                                                            (Candidate internal departure
                                                            airports, known as locally
                                                            departed airports, will be
                                                            identified for this functionality via
                                                            adaptation (Static Site Adaptable
                                                            Scheduler Data)). The following
                                                            conditions will apply for this
                                                            functionality: c) Once such a
                                                            flight becomes active, the
                                                            Scheduler will continually set its
                                                            STA to be equal to its ETA as
                                                            computed.
1102d 3.2.1.5.1.7   S3.1.4.12/Spiral3.3.0, 3.7.0   CM, DP   TMA SHALL provide the                 RPR1036 -2/4/03,
                                                            capability to suppress normal         RPR1206 -3/1/05
                                                            scheduling functionality for
                                                            aircraft departing from selected
                                                            airports to all or a specified
                                                            arrival airport and provide
                                                            alternative handling instead.
                                                            (Candidate internal departure
                                                            airports, known as locally


                                                   165                                           R10
CM SRDD                                                                            CSC/CFF-03/0065
April 2009

                                                               departed airports, will be
                                                               identified for this functionality via
                                                               adaptation (Static Site Adaptable
                                                               Scheduler Data)). The following
                                                               conditions will apply for this
                                                               functionality: d) The locally
                                                               departed aircraft will be
                                                               distinguishable on the TGUI from
                                                               other aircraft. TGUI load graphs
                                                               will reflect these local departure
                                                               flights just like any other flights.
                                                               Since the Scheduler does not
                                                               provide true scheduling for these
                                                               aircraft, acceptance rates may
                                                               be exceeded. This will be
                                                               reflected on the load graphs
1102e 3.2.1.5.1.7    S3.1.4.12/Spiral3.3.0, 3.7.0   CM, DP     TMA SHALL provide the                 RPR1036 -2/4/03,
                                                               capability to suppress normal         RPR1206 -3/1/05
                                                               scheduling functionality for
                                                               aircraft departing from selected
                                                               airports to all or a specified
                                                               arrival airport and provide
                                                               alternative handling instead.
                                                               (Candidate internal departure
                                                               airports, known as locally
                                                               departed airports, will be
                                                               identified for this functionality via
                                                               adaptation (Static Site Adaptable
                                                               Scheduler Data)). The following
                                                               conditions will apply for this
                                                               functionality: e) Meter list data
                                                               for all aircraft departing the
                                                               identified locally departed
                                                               airports and arriving at any of the
                                                               associated arrival airports will not
                                                               be sent to the HOST controller
                                                               sector lists.
1103   3.2.1.5.1.7   3.7.0                          Multiple   TMA SHALL assign an Outer-
                                                               Three Arc STA to an aircraft:
1103-a 3.2.1.5.1.7   3.7.0                          Multiple   a. No later than the Outer-Outer
                                                               Arc STA minus the nominal TTF
                                                               between the Outer-Three Arc
                                                               and the Outer-Outer Arc.
1103-b 3.2.1.5.1.7   3.7.0                          Multiple   b. No earlier than the Outer-
                                                               Outer Arc STA minus the sum of
                                                               the nominal TTF between Outer-
                                                               Three Arc and Outer-Outer Arc,
                                                               any computed EO3AD and the
                                                               value of the relevant O3AD.
1108   3.2.1.5.1.7   3.7.0                          Multiple   TMA SHALL calculate the
                                                               difference of ETA and STA for
                                                               each aircraft at the Outer-Outer
                                                               Arc, i.e., the "Delay to be
                                                               absorbed in the Outer-Outer
                                                               Center Airspace" (OODCA) by
                                                               that aircraft.




                                                    166                                             R10
CM SRDD                                                     CSC/CFF-03/0065
April 2009

1112   3.2.1.5.1.7   3.7.0   Multiple   TMA SHALL assign an Outer-
                                        Three Arc STA for an aircraft
                                        equal to the ETA at the Outer-
                                        Three Arc if OODCA is less than
                                        or equal to the sum of any
                                        computed EO3AD and O3AD for
                                        the assigned Outer-Three Arc
                                        and Outer-Outer Arc (since the
                                        total Outer-Outer Center delay
                                        can then be comfortably
                                        absorbed between the Outer-
                                        Three Arc and the Outer-Outer
                                        Arc).
1114   3.2.1.5.1.7   3.7.0   Multiple   TMA SHALL assign an STA for
                                        an aircraft equal to the ETA plus
                                        the difference OODCA minus the
                                        sum of any computed EO3AD
                                        and O3AD, when OODCA is
                                        larger than the sum of any
                                        computer EO3AD and O3AD.
1132   3.2.1.5.1.7   3.7.0   Multiple   If the outermost assigned arc is
                                        the O3A, TMA SHALL compute
                                        excess delay when a
                                        dynamically assignable
                                        parameter, OO3AD (Dynamic
                                        Site Adaptable Scheduler Data),
                                        is adapted for the assigned O3A.
1134   3.2.1.5.1.7   3.7.0   Multiple   If SHALL [1132] applies, TMA
                                        SHALL compute excess delay as
                                        the difference between the DCA
                                        and the sum of; OFD, OOAD,
                                        O3A Delay (O3AD) and OO3AD.
1136   3.2.1.5.1.7   3.7.0   Multiple   If SHALL [1132] applies, TMA
                                        SHALL assign all excess delay
                                        to one of the following, based on
                                        Static Site Adaptable Scheduler
                                        Data:
1136-a 3.2.1.5.1.7   3.7.0   Multiple   a. Excess Outer Fix Delay
1136-b 3.2.1.5.1.7   3.7.0   Multiple   b. Excess Outer-Outer Arc Delay
1136-c 3.2.1.5.1.7   3.7.0   Multiple   c. Excess Outer-Three Arc Delay
1142 3.2.1.5.1.7     3.7.0   Multiple   If the outermost assigned arc is
                                        the OOA, TMA SHALL compute
                                        excess delay when a
                                        dynamically assignable
                                        parameter, OOOAD (Dynamic
                                        Site Adaptable Scheduler Data),
                                        is adapted for the assigned
                                        OOA.
1144   3.2.1.5.1.7   3.7.0   Multiple   If SHALL [1142] applies, TMA
                                        SHALL compute excess delay as
                                        the difference between the DCA
                                        and the sum of; OFD, OOAD,
                                        and the OOOAD.
1146   3.2.1.5.1.7   3.7.0   Multiple   If SHALL [1142] applies, TMA
                                        SHALL assign all excess delay
                                        to one of the following, based on
                                        Static Site Adaptable Scheduler
                                        Data:
1146-a 3.2.1.5.1.7   3.7.0   Multiple   a. Excess Outer Fix Delay



                             167                                            R10
CM SRDD                                                                                CSC/CFF-03/0065
April 2009

1146-b 3.2.1.5.1.7   3.7.0                            Multiple      b. Excess Outer-Outer Arc Delay
1400   3.2.1.5.3.    S3/S3.1.5                        DP HDIF       TMA SHALL schedule all arrival RPR1117 -5/10/04
                                                      HADDS         aircraft for which tracks have
                                                      ADAR ISM      been received from other
                                                      RA CM PGUI    facilities and are destined to a
                                                                    TMA adapted airport in the same
                                                                    way as TMA schedules aircraft
                                                                    reported to be in its Center.
1453   3.2.1.5.3     S3.1.4_aug                       M+C CM ADIF   TMA SHALL be capable of             RPR1064 -6/11/03
                                                      ISM PGUI      sending metering data for display
                                                      TGUI MMG      on sector controllers' displays to
                                                                    any one, or combination of the
                                                                    following; a. The Primary
                                                                    Center. See requirement 1453b.
1453b 3.2.1.5.3      3.8.0, S3.1.4_aug/               M+C CM ADIF   TMA SHALL be capable of             RPR1064 -
                     Spiral3.3.0/Spiral3.4.0, 3.7.0   ISM PGUI      sending metering data for display 6/11/03, RPR1152
                                                      TGUI MMG      on sector controllers' displays to -7/7/04, RPR1229
                                                                    any one, or combination of the -3/16/05,
                                                                    following; b. Up to 8 Adjacent      RPR1250 -6/23/05
                                                                    Centers.
1454   3.2.1.5.3     S3.1.4_aug                       M+C CM ADIF   When sending flight specific        RPR1064 -6/11/03
                                                      ISM PGUI      messages to an Adjacent
                                                      TGUI MMG      Center's Host, TMA SHALL send
                                                                    CID values used by the Adjacent
                                                                    Center's Host in its processing of
                                                                    the flights.
1455   3.2.1.5.3     S3.1.4_aug                       M+C CM ADIF   TMA SHALL be capable of             RPR1064 -6/11/03
                                                      ISM PGUI      accepting the specification for,
                                                      TGUI MMG      via Static Site Adaptable
                                                                    Scheduler Data, the Center, or
                                                                    Centers, where metering data for
                                                                    a Meter Reference Point (MRP),
                                                                    or portion of an MRP, is to be
                                                                    displayed.
1456   3.2.1.5.3     S3.1.4_aug                       M+C CM ADIF   TMA SHALL be capable of             RPR1064 -6/11/03
                                                      ISM PGUI      sending metering data to an
                                                      TGUI MMG      Adjacent Center's Host when the
                                                                    Adjacent Center's TMA is;
                                                                    running, not running, or none is
                                                                    configured.
1457   3.2.1.5.3     S3.1.4_aug                       M+C CM ADIF   TMA SHALL be capable of             RPR1064 -6/11/03
                                                      ISM PGUI      restricting, via Site Adaptable
                                                      TGUI MMG      Installation Data, the ability to
                                                                    turn on or off the display of
                                                                    metering data, by TGUI instance
                                                                    and by Center where the
                                                                    metering data is to be displayed.
2291   3.2.3.1.      Spiral_1/S3.1.5                  CM TGUI       TMA SHALL be capable of             RPR1117 -5/10/04
                                                                    printing out the following:      a.
                                                                    Traffic count. See requirement
                                                                    2291b.
2530   3.2.3.2.4     Spiral_1/S3.1.5                  CM TGUI       TMA SHALL provide the               RPR055 -9/30/97,
                                                                    capability to calculate the         RPR1117 -5/10/04
                                                                    following quantities for display
                                                                    purposes:        a. Traffic Count.
                                                                    See requirement 2530b.




                                                      168                                              R10
CM SRDD                                                              CSC/CFF-03/0065
April 2009

2540    3.2.3.2.4   Spiral_1/S3.1.5   CM TGUI   TMA SHALL compute a daily             RPR139 -1/26/98,
                                                traffic count according to the        RPR1117 -5/10/04
                                                following:     a. Over a time
                                                interval of 60 minutes in the past
                                                to 120 minutes in the future (-75
                                                to 134 minutes). See
                                                requirements 2540b - 2540g.
2540b 3.2.3.2.4     Spiral_1/S3.1.5   CM TGUI   TMA SHALL compute a daily             RPR139 -1/26/98,
                                                traffic count according to the        RPR1117 -5/10/04
                                                following: b. By selected time
                                                intervals: 10, 15 minutes.
2540d 3.2.3.2.4     Spiral_1/S3.1.5   CM TGUI   CTAS SHALL compute a daily            RPR582 -9/28/00,
                                                traffic count according to the        RPR1117 -5/10/04
                                                following: d. By runway
                                                threshold and/or CTAS meter fix
                                                according to STA.
2540e 3.2.3.2.4     Spiral_1/S3.1.5   CM TGUI   CTAS SHALL compute a daily            RPR582 -9/28/00,
                                                traffic count according to the        RPR1117 -5/10/04
                                                following: e. By runway
                                                threshold and/or CTAS meter fix
                                                according to ETA.
2540g 3.2.3.2.4     Spiral_1/S3.1.5   CM TGUI   TMA SHALL compute a daily             RPR582 -9/28/00,
                                                traffic count according to the        RPR1117 -5/10/04
                                                following: g. By runway
                                                threshold and/or CTAS meter fix
                                                according to actual aircraft
                                                crossing time.
3451    3.2.7       S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following informaiton for an          RPR1117 -5/10/04
                                                aircraft: a. Aircraft Enhanced
                                                ID. See Requirements 3451b -
                                                3451j.
3451b 3.2.7         S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following information for an          RPR1117 -5/10/04
                                                aircraft: b. data sources in use.
3451c 3.2.7         S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following information for an          RPR1117 -5/10/04
                                                aircraft: c. Flight Plan
3451d 3.2.7         S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following information for an          RPR1117 -5/10/04
                                                aircraft: d. track data
                                                information.
3451e 3.2.7         S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following information for an          RPR1117 -5/10/04
                                                aircraft: e. STA information.
3451f   3.2.7       S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following information for an          RPR1117 -5/10/04
                                                aircraft: f. RA generated ETAs,
                                                process, and times to each
                                                runway.
3451g 3.2.7         S2.1.3/S3.1.5     CM        TMA SHALL provide a user              RPR358 -
                                                initiated capability to display the   12/16/1999,
                                                following information for an          RPR1117 -5/10/04
                                                aircraft: g. Analysis Category



                                      169                                              R10
CM SRDD                                                                           CSC/CFF-03/0065
April 2009

3451h 3.2.7         S2.1.3/S3.1.5             CM              TMA SHALL provide a user             RPR358 -
                                                              initiated capability ti display the 12/16/1999,
                                                              following information for an         RPR1117 -5/10/04
                                                              aircraft: h. Route Segment
                                                              Category
3451i   3.2.7       S2.1.3/S3.1.5             CM              TMA SHALL provide a user             RPR358 -
                                                              initiated capability to display the 12/16/1999,
                                                              following information for an         RPR1117 -5/10/04
                                                              aircraft: i. Scheduler freeze
                                                              information
3451j   3.2.7       S2.1.3/S3.1.5             CM              TMA SHALL provide a user             RPR358 -
                                                              initiated capability to display the 12/16/1999,
                                                              following information for an         RPR1117 -5/10/04
                                                              aircraft: j. Route area(TRACON,
                                                              CENTER, CENTER_TRACON)
3501    3.2.8       pending                   CM              TMA SHALL provide a playback RPR494 -9/20/01,
                                                              capability that allows for the start RPR1117 -5/10/04
                                                              time associated with the
                                                              playback to be different from the
                                                              start of the associated playback
                                                              file while maintaining all pertinent
                                                              information to result in a valid
                                                              playback at the designated start
                                                              time.
3502    3.2.8       pending                   CM              TMA SHALL provide a playback RPR494 -9/20/01,
                                                              capability that allows for the       RPR1117 -5/10/04
                                                              playback clock to be a dynamic
                                                              user selection that is faster than
                                                              realtime.
3503    3.2.8       pending                   CM              TMA SHALL provide a playback RPR494 -9/20/01,
                                                              capability that allows for the       RPR1117 -5/10/04
                                                              playback clock to be a dynamic
                                                              user selection that is slower than
                                                              realtime.

EDC Requirements

4200    3.2.1.5.8    Spiral3.5.0    HDIF, ISM,     The following naming           RPR1327 -5/8/06
                                    CM, DP, RA,    convention changes
                                    TS, TGUI,      SHALL, for the purposes of
                                    PGUI, SMC      display, apply to the system
                                                   in EDC mode: a) Meter
                                                   Fix to Meter Point (see
                                                   requirements 4200b -
                                                   4200g)
4200b   3.2.1.5.8    Spiral3.5.0    HDIF, ISM,     The following naming           RPR1327 -5/8/06
                                    CM, DP, RA,    convention changes
                                    TS, TGUI,      SHALL, for the purposes of
                                    PGUI, SMC      display, apply to the system
                                                   in EDC mode: b) Meter Fix
                                                   Arc to Meter Point
4200c   3.2.1.5.8    Spiral3.5.0    HDIF, ISM,     The following naming           RPR1327 -5/8/06
                                    CM, DP, RA,    convention changes
                                    TS, TGUI,      SHALL, for the purposes of
                                    PGUI, SMC      display, apply to the system
                                                   in EDC mode: c) Outer
                                                   Meter Arc/Outer Arc to
                                                   Outer Point




                                             170                                                 R10
CM SRDD                                                                           CSC/CFF-03/0065
April 2009

4200d   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The following naming           RPR1327 -5/8/06
                                  CM, DP, RA,      convention changes
                                  TS, TGUI,        SHALL, for the purposes of
                                  PGUI, SMC        display, apply to the system
                                                   in EDC mode: d) Outer-
                                                   Outer Arc to Outer-Outer
                                                   Point
4200e   3.2.1.5.8   deleted       HDIF, ISM,       *****This subrequirement       RPR1327 -5/8/06,
                                  CM, DP, RA,      has been deleted by RPR-       RPR1351 - 6/21/06
                                  TS, TGUI,        1351*****The following
                                  PGUI, SMC        naming convention
                                                   changes SHALL, for the
                                                   purposes of display, apply
                                                   to the system in EDC
                                                   mode: e) Internal
                                                   Departures to Meter Point
                                                   Departures
4200f   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The following naming           RPR1327 -5/8/06
                                  CM, DP, RA,      convention changes
                                  TS, TGUI,        SHALL, for the purposes of
                                  PGUI, SMC        display, apply to the system
                                                   in EDC mode: f) Arrival
                                                   Airport to Destination
                                                   Airport
4200g   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The following naming           RPR1327 -5/8/06
                                  CM, DP, RA,      convention changes
                                  TS, TGUI,        SHALL, for the purposes of
                                  PGUI, SMC        display, apply to the system
                                                   in EDC mode: g) Meter
                                                   Reference Point to Meter
                                                   Point.
4200-   3.2.1.5.8   3.7.0         Multiple         h. Outer-Three Arc to
h                                                  Outer-Three Point




4205    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The following acronym          RPR1327 -5/8/06
                                  CM, DP, RA,      changes SHALL, for the
                                  TS, TGUI,        purposes of display, apply
                                  PGUI, SMC        to the system in EDC
                                                   mode: a) MFA to MP. (see
                                                   requirements 4205b -
                                                   4205c)
4205b   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The following acronym          RPR1327 -5/8/06
                                  CM, DP, RA,      changes SHALL, for the
                                  TS, TGUI,        purposes of display, apply
                                  PGUI, SMC        to the system in EDC
                                                   mode: b) OMA to OP

4205c   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The following acronym          RPR1327 -5/8/06
                                  CM, DP, RA,      changes SHALL, for the
                                  TS, TGUI,        purposes of display, apply
                                  PGUI, SMC        to the system in EDC
                                                   mode: c) OOA to OOP




                                             171                                                R10
CM SRDD                                                                            CSC/CFF-03/0065
April 2009

4205-   3.2.1.5.8   3.7.0         Multiple         d. O3A to O3P
d




4210    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL define a Meter        RPR1327 -5/8/06
                                  CM, DP, RA,      Point (MP) over which it will
                                  TS, TGUI,        deconflict (sequence and
                                  PGUI, SMC        schedule) aircraft outbound
                                                   from a Center.

4215    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The MP SHALL be defined         RPR1327 -5/8/06
                                  CM, DP, RA,      in site adaptation data
                                  TS, TGUI,        using: a) distance and
                                  PGUI, SMC        radial ends from a Meter
                                                   Point Arc center. (see
                                                   requirements 4215b -
                                                   4215e)
4215b   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The MP SHALL be defined         RPR1327 -5/8/06
                                  CM, DP, RA,      in site adaptation data
                                  TS, TGUI,        using: b) lower and upper
                                  PGUI, SMC        altitude limits



4215c   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The MP SHALL be defined         RPR1327 -5/8/06
                                  CM, DP, RA,      in site adaptation data
                                  TS, TGUI,        using: c) destination
                                  PGUI, SMC        airport(s)


4215d   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The MP SHALL be defined         RPR1327 -5/8/06
                                  CM, DP, RA,      in site adaptation data
                                  TS, TGUI,        using: d) engine type(s)
                                  PGUI, SMC



4215e   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       The MP SHALL be defined         RPR1327 -5/8/06
                                  CM, DP, RA,      in site adaptation data
                                  TS, TGUI,        using: e) altitude and
                                  PGUI, SMC        speed crossing restrictions,
                                                   optional.

4220    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL assign and            RPR1327 -5/8/06
                                  CM, DP, RA,      deconflict aircraft at one
                                  TS, TGUI,        Meter Point.
                                  PGUI, SMC



4223    3.2.1.5.8   3.9.0         CM, DP, ISM,     EDC SHALL disable TMC           RPR1583
                                  PGUI, RA,        MP reassignment for
                                  TGUI             aircraft until all upstream
                                                   meter points have been
                                                   crossed.




                                             172                                                R10
CM SRDD                                                                          CSC/CFF-03/0065
April 2009

4230    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL perform Meter         RPR1327 -5/8/06
                                  CM, DP, RA,    Point assignment in order
                                  TS, TGUI,      to determine that a flight is
                                  PGUI, SMC      eligible for EDC
                                                 processing.

4235    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL consider the          RPR1327 -5/8/06
                                  CM, DP, RA,    following flight plan data
                                  TS, TGUI,      during MP assignment: a)
                                  PGUI, SMC      intersection of converted
                                                 route with MP Arc. (see
                                                 requirements 4235b -
                                                 4235d)
4235b   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL consider the          RPR1327 -5/8/06
                                  CM, DP, RA,    following flight plan data
                                  TS, TGUI,      during MP assignment: b)
                                  PGUI, SMC      destination airport


4235c   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL consider the          RPR1327 -5/8/06
                                  CM, DP, RA,    following flight plan data
                                  TS, TGUI,      during MP assignment: c)
                                  PGUI, SMC      engine type


4235d   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL consider the          RPR1327 -5/8/06
                                  CM, DP, RA,    following flight plan data
                                  TS, TGUI,      during MP assignment: d)
                                  PGUI, SMC      assigned altitude


4240    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL perform MP            RPR1327 -5/8/06
                                  CM, DP, RA,    reassignment if any of the
                                  TS, TGUI,      following are changed: a)
                                  PGUI, SMC      assigned altitude. (see
                                                 requirements 4240b -
                                                 4240d
4240b   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL perform MP            RPR1327 -5/8/06
                                  CM, DP, RA,    reassignment if any of the
                                  TS, TGUI,      following are changed: b)
                                  PGUI, SMC      engine type


4240c   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL perform MP            RPR1327 -5/8/06
                                  CM, DP, RA,    reassignment if any of the
                                  TS, TGUI,      following are changed: c)
                                  PGUI, SMC      destination airport


4240d   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL perform MP            RPR1327 -5/8/06
                                  CM, DP, RA,    reassignment if any of the
                                  TS, TGUI,      following are changed: a)
                                  PGUI, SMC      converted route




                                           173                                                R10
CM SRDD                                                                            CSC/CFF-03/0065
April 2009

4245    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,     After performing MP             RPR1327 -5/8/06
                                    CM, DP, RA,    reassignment, if the aircraft
                                    TS, TGUI,      did not have an MP
                                    PGUI, SMC      assigned previously, a
                                                   message adding the flight
                                                   plan SHALL be generated
4250    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,     After performing MP             RPR1327 -5/8/06
                                    CM, DP, RA,    reassignment, if a new MP
                                    TS, TGUI,      is assigned, an amendment
                                    PGUI, SMC      message SHALL be
                                                   generated.

4255    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,     After performing MP             RPR1327 -5/8/06
                                    CM, DP, RA,    reassignment, if a new MP
                                    TS, TGUI,      cannot be assigned from
                                    PGUI, SMC      the converted route for a
                                                   flight that previously had an
                                                   assigned MP a delete
                                                   message SHALL be
                                                   generated.
4260    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,     Flights that are not            RPR1327 -5/8/06
                                    CM, DP, RA,    assigned an MP SHALL
                                    TS, TGUI,      cause a warning message
                                    PGUI, SMC      to be generated.



4265    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,     In EDC mode, the Meter          RPR1327 -5/8/06
                                    CM, DP, RA,    Point, the Scheduling Meter
                                    TS, TGUI,      Point and the Display Point
                                    PGUI, SMC      SHALL be coincident.


4270    3.2.1.5.8   3.9.0, 3.5.0    HDIF, ISM,     EDC SHALL assign the            RPR1327
                                    CM, DP, RA,    most downstream eligible        RPR1583
                                    TS, TGUI,      MPs to a flight, as specified
                                    PGUI, SMC      in adaptation.


4275    3.2.1.5.8   Spiral3.5.0,    HDIF, ISM,     In addition to Meter Points,    RPR1327 -5/8/06
                    3.7.0           CM, DP, RA,    EDC SHALL optionally
                                    TS, TGUI,      adapt Outer Points (OP),
                                    PGUI, SMC      Outer-Outer Points (OOP)
                                                   and Outer-Three Points as
                                                   additional processing
                                                   locations associated with
                                                   the Meter Points.
4280    3.2.1.5.8   3.9.0, 3.8.0,   HDIF, ISM,     Each Aircraft SHALL have        RPR1327 -5/8/06
                    3.7.0, 3.5.0    CM, DP, RA,    up to a maximum of one
                                    TS, TGUI,      MP, one OP, one OOP and
                                    PGUI, SMC      one O3P assigned.



4285    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,     The OP SHALL be                 RPR1327 -5/8/06
                                    CM, DP, RA,    determined from the
                                    TS, TGUI,      assigned MP's associated
                                    PGUI, SMC      OPs.




                                             174                                                R10
CM SRDD                                                                            CSC/CFF-03/0065
April 2009

4290    3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       The OOP SHALL be               RPR1327 -5/8/06
                                   CM, DP, RA,      determined from the
                                   TS, TGUI,        assigned OP's associated
                                   PGUI, SMC        OOPs.



4292    3.2.1.5.8   3.7.0          Multiple         The O3P SHALL be
                                                    determined from the
                                                    assigned OOP's associated
                                                    O3Ps.
4295    3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       M+C SHALL support the          RPR1327 -5/8/06
                                   CM, DP, RA,      capability to: a) start
                                   TS, TGUI,        TRACON groups and the
                                   PGUI, SMC        EDC group independently
                                                    (see requirements 4295b -
                                                    4295c)
4295b   3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       M+C SHALL support the          RPR1327 -5/8/06
                                   CM, DP, RA,      capability to: b) stop
                                   TS, TGUI,        TRACON groups and the
                                   PGUI, SMC        EDC group ndependently


4295c   3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       M+C SHALL support the          RPR1327 -5/8/06
                                   CM, DP, RA,      capability to: c) configure
                                   TS, TGUI,        TRACON groups and the
                                   PGUI, SMC        EDC group independently.


4305    3.2.1.5.8   Spiral3.5.0,   HDIF, ISM,       EDC SHALL provide the          RPR1327 -5/8/06
                    3.7.0          CM, DP, RA,      Center the capability for
                                   TS, TGUI,        outbound EDC processing
                                   PGUI, SMC        for up to 128 airports.


4310    3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       EDC SHALL provide the          RPR1327 -5/8/06
                                   CM, DP, RA,      capability to manage the
                                   TS, TGUI,        display of meter lists by
                                   PGUI, SMC        Center and Meter Point and
                                                    airport.

4315    3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       EDC SHALL be capable of        RPR1327 -5/8/06,
                                   CM, DP, RA,      setting freeze horizons on a   RPR1338 -5/23/06
                                   TS, TGUI,        stream class basis.
                                   PGUI, SMC


4320    3.2.1.5.8   Spiral3.5.0    HDIF, ISM,       EDC SHALL be capable of        RPR1327 -5/8/06
                                   CM, DP, RA,      combining aircraft assigned
                                   TS, TGUI,        to a stream classs destined
                                   PGUI, SMC        to different EDC airports
                                                    over the same Meter Point
                                                    into a single super stream
                                                    class using "predetermined
                                                    Sets".




                                              175                                               R10
CM SRDD                                                                          CSC/CFF-03/0065
April 2009

4325    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL be capable of         RPR1327 -5/8/06
                                  CM, DP, RA,    combining aircraft assigned
                                  TS, TGUI,      to a stream classs destined
                                  PGUI, SMC      for the same or different
                                                 airports going over multiple
                                                 Meter Points into a single
                                                 super stream class using
                                                 "predetermined Sets".
4330    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL provide the           RPR1327 -5/8/06
                                  CM, DP, RA,    capability to specify up to
                                  TS, TGUI,      two future super stream
                                  PGUI, SMC      class mappings for EDC
                                                 processing.

4335    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL provide the           RPR1327 -5/8/06
                                  CM, DP, RA,    capability to specify a super
                                  TS, TGUI,      stream class miles-in-trail
                                  PGUI, SMC      constraint.


4340    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL provide the           RPR1327 -5/8/06
                                  CM, DP, RA,    capability to specify up to
                                  TS, TGUI,      two future miles-in-trail
                                  PGUI, SMC      restrictions for EDC
                                                 processing.


4345    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL support               RPR1327 -5/8/06
                                  CM, DP, RA,    independent scheduling of
                                  TS, TGUI,      each EDC super stream
                                  PGUI, SMC      class such that constraint
                                                 changes intended to affect
                                                 one do not affect
                                                 scheduling information for
                                                 any other.
4350    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL provide the           RPR1327 -5/8/06
                                  CM, DP, RA,    capabity to reschedule all
                                  TS, TGUI,      flights in a super stream
                                  PGUI, SMC      class.



4355    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL provide the           RPR1327 -5/8/06
                                  CM, DP, RA,    capability to reschedule
                                  TS, TGUI,      only flights in a super
                                  PGUI, SMC      stream class after and
                                                 including a selected
                                                 aircraft.
4360    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL optionally            RPR1327 -5/8/06
                                  CM, DP, RA,    include manually scheduled
                                  TS, TGUI,      aircraft in EDC processing
                                  PGUI, SMC      when rescheduling.



4365    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,     EDC SHALL calculate             RPR1327 -5/8/06
                                  CM, DP, RA,    ETAs at assigned: a)
                                  TS, TGUI,      Meter Points (see
                                  PGUI, SMC      requirements 4365b -
                                                 4365c)




                                           176                                                R10
CM SRDD                                                                          CSC/CFF-03/0065
April 2009

4365b   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL calculate           RPR1327 -5/8/06
                                  CM, DP, RA,      ETAs at assigned: b)
                                  TS, TGUI,        Outer Points
                                  PGUI, SMC


4365c   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL calculate           RPR1327 -5/8/06
                                  CM, DP, RA,      ETAs at assigned: c)
                                  TS, TGUI,        Outer-Outer Points.
                                  PGUI, SMC



4365-   3.2.1.5.8   3.7.0         Multiple         d. Outer-Three Points
d




4370    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL calculate           RPR1327 -5/8/06
                                  CM, DP, RA,      STAs at assigned: a)
                                  TS, TGUI,        Meter Points (see
                                  PGUI, SMC        requirements 4370b -
                                                   4370c)


4370b   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL calculate           RPR1327 -5/8/06
                                  CM, DP, RA,      STAs at assigned: b)
                                  TS, TGUI,        Outer Points
                                  PGUI, SMC



4370c   3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL calculate           RPR1327 -5/8/06
                                  CM, DP, RA,      STAs at assigned: c)
                                  TS, TGUI,        Outer-Outer Points
                                  PGUI, SMC



4370-   3.2.1.5.8   3.7.0         Multiple         d. Outer-Three Points
d




4375    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL allow a TMC         RPR1327 -5/8/06
                                  CM, DP, RA,      to manually assign an MP
                                  TS, TGUI,        STA to a flight over an MP.
                                  PGUI, SMC



4380    3.2.1.5.8   Spiral3.5.0   HDIF, ISM,       EDC SHALL allow a TMC         RPR1327 -5/8/06
                                  CM, DP, RA,      to manually reassign an
                                  TS, TGUI,        aircraft from one MP to
                                  PGUI, SMC        another MP.




                                             177                                              R10
CM SRDD                                                                             CSC/CFF-03/0065
April 2009

4385    3.2.1.5.8   Spiral3.5.0     HDIF, ISM,       EDC SHALL support EDC          RPR1327 -5/8/06
                                    CM, DP, RA,      processing using existing
                                    TS, TGUI,        CMS Metering message
                                    PGUI, SMC        formats for the ability to
                                                     manage and display meter
                                                     lists on the HOST DSR.
4390    3.2.1.5.8   3.9.0, 3.5.0    HDIF, ISM,       EDC SHALL provide the          RPR1327
                                    CM, DP, RA       following information for      RPR1587
                                                     display to sector
                                                     controllers:



4390-   3.2.1.5.8   3.9.0           HDIF, ISM,       1. Airport identifier ("MP"    RPR1327
a1                                  CM, DP, RA       or an adapted 3 character      RPR1587
                                                     alphanumeric ID)




4390-   3.2.1.5.8   3.9.0           HDIF, ISM,       3. Airport acceptance rate     RPR1327
a3                                  CM, DP, RA                                      RPR1587




4390b   3.2.1.5.8   3.9.0           HDIF, ISM,       b. For each aircraft entry,    RPR1327
                    3.5.0           CM, DP, RA       the airport field is "MP" or   RPR1587
                                                     an adapted 3 character
                                                     alphanumeric ID



4395    3.2.1.5.8   3.9.0, 3.8.0,   HDIF, ISM,       EDC SHALL provide the          RPR1327
                    3.7.0, 3.5.0    CM, DP, RA,      capability to manually         RPR1438
                                    TS, TGUI,        schedule a proposed flight     RPR1521
                                    PGUI, SMC        departing from a local         RPR1583
                                                     airport referenced to its
                                                     assigned Meter Point or, if
                                                     adapted, its Outer Point,
                                                     Outer-Outer Point, Outer-
                                                     Three Point , or Outer-Four
                                                     Point..
4397    3.2.1.5.8   3.9.0           Multiple         When a proposed internal       RPR1614
                                                     departure flight is manually
                                                     scheduled to a Meter Point,
                                                     and is destined for an
                                                     arrival TRACON in the
                                                     same center, TMA SHALL
                                                     schedule and display the
                                                     STD on the arrival
                                                     TRACON TGUI(s).
4398    3.2.1.5.8   3.9.0           Multiple         When a proposed internal       RPR1614
                                                     departure flight is manually
                                                     scheduled to a Meter Fix,
                                                     and is assigned to a meter
                                                     point in the same center,
                                                     TMA SHALL schedule and
                                                     display the STD on the
                                                     meter point TGUI(s).




                                               178                                               R10
CM SRDD                                                                            CSC/CFF-03/0065
April 2009

4400    3.2.1.5.8     Spiral3.5.0   HDIF, ISM,     When running in EDC             RPR1327 -5/8/06
                                    CM, DP, RA,    mode, the periodic
                                    TS, TGUI,      reschedule duration SHALL
                                    PGUI, SMC      be set to 12 seconds.



4600    3.2.1.5.8.1   3.9.0         CM, DP, ISM,   TMA's MMP capability            RPR1583
                                    PGUI, RA,      SHALL allow the
                                    TGUI           assignment of up to three
                                                   (3) MPs to an En Route
                                                   aircraft (e.g. overflight, MP
                                                   departure) or an arrival
                                                   aircraft upstream of the
                                                   arrival TRACON boundary
                                                   (i.e. arrival airport in the
                                                   local ARTCCC).
4602    3.2.1.5.8.1   3.9.0         CM, DP, ISM,   TMA's MMP capability            RPR1583
                                    PGUI, RA,      SHALL deconflict up to a
                                    TGUI           total of 25 MPs for either
                                                   En Route or arrival aircraft.



4604    3.2.1.5.8.1   3.9.0         CM, DP, ISM,   TMA's MMP capability            RPR1583
                                    PGUI, RA,      SHALL disallow the
                                    TGUI           grouping of upstream and
                                                   downstream MP stream
                                                   classes into


4604-   3.2.1.5.8.1   3.9.0         CM, DP, ISM,   a. super stream classes         RPR1583
a                                   PGUI, RA,
                                    TGUI




4604-   3.2.1.5.8.1   3.9.0         CM, DP, ISM,   b. super stream class           RPR1583
b                                   PGUI, RA,      groups
                                    TGUI




4606    3.2.1.5.8.1   3.9.0         CM, DP, ISM,   TMA's MMP capability            RPR1583
                                    PGUI, RA,      SHALL deconflict a MP
                                    TGUI           superstream independently
                                                   from deconfliction at any
                                                   upstream or downstream
                                                   MP superstreams.
4608    3.2.1.5.8.1   3.9.0         CM, DP, ISM,   TMA's MMP capability            RPR1583
                                    PGUI, RA,      SHALL deconflict a MSSD
                                    TGUI           group independently from
                                                   deconfliction at any
                                                   upstream or downstream
                                                   MSSD groups.




                                             179                                                R10
CM SRDD                                                                       CSC/CFF-03/0065
April 2009

4610    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   TMA's MMP capability             RPR1583
                              PGUI, RA,      SHALL deconflict EDC MP
                              TGUI           superstreams
                                             independently from
                                             deconfliction of arrival
                                             TRACON meter fixes/arcs
                                             and runway.
4612    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   TMA's MMP capability             RPR1583
                              PGUI, RA,      SHALL deconflict EDC
                              TGUI           MSSD groups
                                             independently from
                                             deconfliction of arrival
                                             TRACON meter fixes/arcs
                                             and runway.
4614    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   TMA's MMP capability             RPR1583
                              PGUI, RA,      SHALL be capable of
                              TGUI           setting freeze horizons on a
                                             stream class basis.



4616    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   TMA's MMP capability             RPR1583
                              PGUI, RA,      SHALL allow for optionally
                              TGUI           adapted crossing
                                             restrictions to be applied for
                                             En Route aircraft at the last
                                             MP in the set of MPs a
                                             flight traverses.
4618    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   For MMP processing, the          RPR1583
                              PGUI, RA,      arrival TRACON SHALL
                              TGUI           use available downstream
                                             coordination information
                                             from the very last assigned
                                             MP for computation of an
                                             ETA until the aircraft
                                             crosses that MP.
4620    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   When TMA receives the            RPR1583
                              PGUI, RA,      Sector Controller command
                              TGUI           to swap between two and
                                             five aircraft at a MP, TMA
                                             SHALL re-sequence the
                                             affected aircraft by
                                             exchanging the STAs
                                             unless a rejection condition
                                             is met, as described in
                                             requirement [4624]
4622    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   When a flight is assigned to     RPR1583
                              PGUI, RA,      more than one MP, Sector
                              TGUI           Controller swap validation
                                             and STA exchange SHALL
                                             be performed at the first
                                             non-traversed MP for each
                                             flight included in the swap.
4624    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   TMA SHALL send a reject          RPR1583
                              PGUI, RA,      message to the HCS
                              TGUI           whenever it receives a
                                             swap or resequence
                                             message from a sector
                                             controller for between two
                                             and five aircraft at a MP
                                             and any of the aircraft
                                             have:



                                       180                                                R10
CM SRDD                                                                     CSC/CFF-03/0065
April 2009

4624-   3.2.1.5.8.1   3.9.0   CM, DP, ISM,   a. A different assigned MP     RPR1583
a                             PGUI, RA,      gate
                              TGUI




4624-   3.2.1.5.8.1   3.9.0   CM, DP, ISM,   b. A different engine type     RPR1583
b                             PGUI, RA,
                              TGUI




4624-   3.2.1.5.8.1   3.9.0   CM, DP, ISM,   c. Not been frozen             RPR1583
c                             PGUI, RA,
                              TGUI




4626    3.2.1.5.8.1   3.9.0   CM, DP, ISM,   If the TMC entered a           RPR1583
                              PGUI, RA,      command to "reset aircraft
                              TGUI           ID" after a TMC meter fix or
                                             meter point reassignment,
                                             TMA SHALL reapply the
                                             current flight plan routing
                                             and assigned MRPs to that
                                             aircraft and recalculate
                                             ETAs and STAs.




                                       181                                              R10
CM SRDD                                                    CSC/CFF-03/0065
April 2009



                      Appendix B Acronyms

ACES         Adaptation Controlled Environment System
ACID         Aircraft Identifier
ACM          Adjacent Center Metering
ADAR         ARTS Data Acquisition and Routing
ADIF         ARTS Data Interface
AGW          ARTS Gateway
AMDT         Allowed Maximum Delay Time
ARTCC        Air Route Traffic Control Center
ARTS         Automated Radar Terminal System
ATM          Air Traffic Management

CAP          Collaborative Arrival Planner
CID          Computer Identifier
CM           Communications Manager
CMb          Communications Manager (backup)
CMp          Communications Manager (primary)
CREWS        CTAS Remote Weather Service
CSCI         Computer Software Configuration Item
CTAS-W       Center-TRACON Automation System Workstation

DCI          Downstream Coordination Information
DP           Dynamic Planner
DR           Data Recording
DSC          Data Source Configuration
DSR          Display System Replacement

EDC          En route Departure Capability
EDIF         ETMS Data Interface
ETA          Estimated Time of Arrival
ETMS         Enhanced Traffic Management System

FAA          Federal Aviation Administration
FAF          Final Approach Fix
FDB          Full Data Block
FFP1         Free Flight Phase 1
FP           Flight Plan
FPA          Fix Posting Area

GUI          Graphical User Interface
GUIR         GUI Router

HADDS        Host/ATM Data Distribution System
HCS          Host Computer System



                                 182                                   R10
CM SRDD                                                        CSC/CFF-03/0065
April 2009

HDIF         Host Data Interface
HID          Host Interface Device

IDR          Internal Departures Relay
ILS          Instrument Landing System
IPC          Inter-Process Communication
ISM          Input Source Manager

M&C          Monitor & Control
MF           Meter Fix
MFA          Meter Fix Arc
MLAS         Meter List Alternate Sequence
MMP          Multiple Meter Points
MP           Meter Point
MRP          Meter Reference Point
MSDD         Multiple Super Stream Class Deconfliction

NAS          National Airspace System
NCP          NAS Change Proposal
NOAA         National Oceanic and Atmospheric Administration
NWA          National Weather Service

OAT          Outer Meter Arc Time
OETA         Original Estimated Time of Arrival
OMF          Outer Meter Fix
OMA          Outer Meter Arc
OOA          Outer Outer Arc
O3A          Outer Three Arc
O4A          Outer Four Arc
OP           Outer Point
OOP          Outer Outer Point
O3P          Outher Three Point
O4P          Outer Four Point

PAR          Preferred Arrival Route
PAS          Pseudo Aircraft Simulator
PDAR         Preferential Departure/Arrival Routes
pFAST        Passive Final Approach Spacing Tool
PFS          Profile Selector
PGUI         Plan View Graphical User Interface
PVD          Plan View Display

RA           Route Analyzer
RWAY         Runway

SD           Satellite (airport) Departure
SGFF         Single Gate Free Flow


                                   183                                     R10
CM SRDD                                                   CSC/CFF-03/0065
April 2009

SIP          Simulation Interface Process
SRDD         Software Requirements/Design Document
SSA          Select Socket Array
SSC          Super Stream Class
STA          Scheduled Time of Arrival
STARS        Standard Terminal Automation Replacement System
SUA          Special Use Airspace
SVC          Service

TCP          Transmission Control Protocol
TFC          Traffic Flow Change
TGUI         Timeline Graphical User Interface
TMA          Traffic Management Advisor
TMC          Traffic Management Coordinator
TMU          Traffic Management Unit
TRACON       Terminal Radar Approach Control
TS           Trajectory Synthesizer

UDS          Unix Domain Socket

WDPD         Weather Data Processing Daemon




                                  184                                 R10
CM SRDD                                                                 CSC/CFF-03/0065
April 2009




                   Appendix C: Aircraft Database Structures
CM processing is centered on the aircraft structure. CM uses Unix twalk functionality to
create search and maintain a binary tree whose nodes are Ac_st structures. Each aircraft‟s
Ac_st serves as a central repository of current aircraft information which CM can forward to
the other CTAS processes. Ac_st is defined as follows:

struct Ac_st
{
    char                            tracon_id;
    char                            route10b [MAX_FILED_ROUTE_LENGTH];
    char                            TRACON_scratch_pad [DADS_SIZE_SCRATCH_PAD];
    char                            secondary_scratch_pad [DADS_SIZE_SCRATCH_PAD];
    char                            debug_analysis_category [LINE_LENGTH];
    char                            debug_route_segment_category [LINE_LENGTH];
    char                            ra_ak_route_status [MAX_RA_AK_ROUTE_STATUS_LEN];
    char                            airport_id [MAX_NAME_LENGTH];
    Bool_type                       route10b_changed;
    Bool_type                       cnvroute_changed;
    Bool_type                       active;
    Bool_type                       received_ak_route;
    Bool_type                       track_was_broadcast;
    Bool_type                       landed;
    Bool_type                       dead_reckoned;
    Bool_type                       include;
    Bool_type                       ra_route_request_on;
    Bool_type                       ps_route_request_on;
    Bool_type                       fp_route_request_on;
    Bool_type                       crossed_center;
    Bool_type                       ra_invalid_route_msg;
    Bool_type                       first_tracon_track;
    Bool_type                       first_center_track;
    Bool_type                       drop_track;
    Bool_type                       heavy_jet;
    Bool_type                       in_hold;
    int                             ra_index;
    int                             item_index;
    int                             watch_index;
    int                             handoff_to;
    int                             sector_owner;
    int                             sequence_number;
    int                             oeta_filter_count [MAX_RUNWAYS];
    Engine_type                     engine_type;
    Time_type                   filter_oeta_array[MAX_RUNWAYS][OETA_FILTER_LENGTH];
    Time_type                   filter_eta_array [MAX_RUNWAYS][ETA_FILTER_LENGTH];
    Time_type                   filter_faf_eta_array [MAX_RUNWAYS][ETA_FILTER_LENGTH];
    Time_type                       cruise_alt_timer;
    Time_type                       last_track_time;
    Time_type                       became_active_time;
    Time_type                       entered_landed_zone_time;
    Time_type                       relative_time_of_last_fp_eta_request;
    Time_type                       rwy_landed_time;
    Time_type                       ra_invalid_route_msg_time;
    Time_type                       last_f1_update_time;
    Time_type                       auto_resch_time;
    App_st                          *ra_app_for_last_eta_update;
    Cm_ac_st                        state;
    Flight_plan_st                  flight_plan;
    CTAS_flight_info_st             flight_info;
    Cm_gate_balance_eta_st          gate_balance_eta;


                                          185                                        R10
CM SRDD                                                                    CSC/CFF-03/0065
April 2009

     User_constraint_st                user_constraint;
     Cm_ac_aux_waypoint                ac_aux_waypoint;
     Int_dep_st                        internal_dep;
     Tgui_mirror_mf_st                 tgui_mirror_mf;
     Open_slot_info_st                 open_slot_info;
     Cm_mp_info_st                     mp_info [MAX_FID_POINTS];
     fp_cm2client_status               fp_to_clients [NUM_SEND_PROCS];
     Debug_string_option               datablock_debug_string_option [MAX_PGUI_SOCKETS];
};

The following structures are defined in global_includes/ctas_struct.h.

The Cm_ac_st structure contains radar track information passed to CM from external data
sources, and represents the current aircraft state:

        struct Cm_ac_st
        {
            char                   id[ID_LENGTH];
            float                  time;           /* secs since CM start time      */
            float                  x;              /* nm                            */
            float                  y;              /* nm                            */
            float                  altitude;       /* ft above sea level            */
            float                  ground_speed;   /* kts                           */
            float                  heading;        /* deg, 0=North, 90=East, etc    */
            float                  vertical_speed; /* fpm                           */
            Areas                  area;           /* Areas                         */
            short                  sector_id;      /* current owning sector number */
            char                   turn_status;    /* Turn_status_t                 */
            char                   altitude_status;/* Altitude_status_t             */
            Bool_type              coast;          /* coast track from host         */
            Bool_type              active;         /* active status                 */
            Bool_type              use_current_speed; /* use track speed    (1:TRUE) */
                                                      /* use filed airspeed (0:FALSE) */
            Bool_type              reached_cruise_altitude; /* reached assigned alt
        */};
        typedef struct Cm_ac_st Cm_ac_st;

The Flight_plan_st structure holds the aircraft‟s current flight plan information:

struct Flight_plan_st
{
    int             amend_index; /* data_source_config entry for amd/add fp */
    char            dst_traconid;
    int             is_packed_start_point; /* 0=nopack 1=pack */
    DSC_flight_plan_id_st dsc_id[MAX_DATA_SOURCE_CONFIG_ENTRIES];
    char            type[MAX_TYPE_CHARS];
    Meter_fix_id    fid;
    AC_fp_category category;
    char            departure_fix[MAX_NAME_LENGTH];
    int             departure_time;
    unsigned int    locally_departed;
    int             assigned_altitude;
    int             assigned_altitude_num;      /* altitude in feet   */
    int             pre_suppression_alt;        /* altitude in feet   */
    Bool_type       in_suppression_zone;
    float           filed_speed;                /* kts, true airspeed */
    int             time_enroute;
    float           approach_speed;
    float           landing_speed;
    char            coordination_frd[MAX_NAME_LENGTH];



                                            186                                        R10
CM SRDD                                                                CSC/CFF-03/0065
April 2009

     char            coordination_fix[MAX_NAME_LENGTH];
     float           coordination_x;     /* nm                               */
     float           coordination_y;     /* nm                               */
     int             faa_coord_time;
     int             coordination_time;
     char            destination_fix[MAX_NAME_LENGTH];
     int             destination;        /* Airport[] index                  */
     int             runway;             /* Airport[].runway[] index         */
     Runway_frozen_type
                     runway_frozen;
     char            DADS_runway[MAX_SHORT_RWY_NAME_LENGTH];
     int             configuration;
     int             beacon;             /* transponder code                 */
     char            atc_type[MAX_TYPE_CHARS];
     int             time_received;
     int             ac_types_index;

                     /*
                      * TRUE if there is model for this ac in Ac_types.
                      * If FALSE, then we are using a default B727.
                      */
     unsigned        ac_type_found;

                     /*
                      * 1 = proposed, 2 = estimated,
                      * 3 = departed, 4 = blocked slot
                      */
     short           status;
     char            clone_traconid;
     int             satellite_category; /* internal departures */

     char            pdar_name[PREF_ROUTE_NAME_LENGTH];
     char            pdr_name[PREF_ROUTE_NAME_LENGTH];
     char            par_name[PREF_ROUTE_NAME_LENGTH];
     NAS_delay_st    nas_delay[MAX_NAS_DELAY_ENTRIES];

     /* following must always remain last element since compressed */
     char            route[MAX_FILED_ROUTE_LENGTH];/* must be last */
};
typedef struct Flight_plan_st Flight_plan_st;

The CTAS_flight_info_st structure contains an aircraft‟s CTAS-generated information based
on a flight plan:

struct CTAS_flight_info_st {
    char                          id[ID_LENGTH];

                                  /* controller assigned altitude */
     float                        T_altitude;

     Hold_flight_info_st          hold_info;

     unsigned                     lost_track;

                                  /* PFS runway allocation window flags */
     unsigned                     tracon_runway_allocation_closed[MAX_RUNWAYS];
     unsigned                     in_tracon_runway_time_horizon[MAX_RUNWAYS];

                                  /* ac flying along its filed flight plan */
     unsigned                     on_flight_plan;

                                  /*



                                          187                                      R10
CM SRDD                                                           CSC/CFF-03/0065
April 2009

                                 * ac flying along its filed flight plan
                                 * or following a PAR
                                 */
     unsigned                   on_flight_plan_or_par;

     int                        dsc_index;/* Will replace track_data_source */
     int                        acid_amend_dsc_index;
                                /*
                                 * The index of the data source that last
                                 * sent an ACID amendment.
                                 */
     int                        previous_acid_amend_dsc_index;
                                /*
                                 * The index of the next to last data source
                                 * that sent an ACID amendment.
                                 */
     int                        last_track_dsc_index;
                                /*
                                 * The index of the data source that last
                                 * sent a track message.
                                 */

     Blocked_slot_flight_info_st blocked_slot_info;

     Suppression_st             suppression_info;

     Bool_type                  nofix;
     float                      pseudo_fix_x;
     float                      pseudo_fix_y;

    Time_type                   edct_time;
    Dep_time_type               dep_time_in_use;
    char                        ctrl_facility_dsc;
    char                        ctrl_facility_str [MAX_CTRL_FACILITY_NAME_LEN];
    /* leave as last */
    char                        host_ak_route_string[MAX_HOST_AK_ROUTE_LENGTH];};
typedef struct CTAS_flight_info_st CTAS_flight_info_st;




                                        188                                   R10

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:40
posted:5/13/2011
language:Swedish
pages:191