**Airspace GDP Meeting**

**13 April 2005**

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

**Airspace GDP Meeting**

TABLE OF CONTENTS

[EXECUTIVE SUMMARY 1](#__RefHeading___Toc101602602)

[MEETING NOTES 2](#__RefHeading___Toc101602603)

[Introduction and Opening Remarks 2](#__RefHeading___Toc101602604)

[Airspace GDP Project SCOPE Discussions 2](#__RefHeading___Toc101602605)

[Basic Steps for an Airspace GDP 4](#__RefHeading___Toc101602606)

[Next Steps 6](#refheading___toc101602607)

[Design / Project Questions Yet to be Determined
6](#__RefHeading___Toc101602608)

[Appendix A: Attendees 8](#__RefHeading___Toc101602609)

[Appendix B: Metron Memorandum Airspace Ground Delay Programs -- Initial
Draft Requirements 9](#__RefHeading___Toc101602610)

[]{#__RefHeading___Toc101602602 .anchor}EXECUTIVE SUMMARY

A meeting was convened on 13 April 2005 to review project directions,
questions and issues for implementing an Airspace-based Delay Program in
Release 8.2 (Spring 2006). Many undefined technical, procedural and
project management questions needed to be resolved before requirements
can be defined and development can begin.

The meeting covered drivers and benefits for the Airspace-based GDP
project, the scope of the project, and the functional steps necessary to
deliver the program. Four basic actions were identified to define the
program and move it towards requirements definition in time for delivery
in 2006:

1.  Define the Format for the Airspace FADT List

2.  Define the Airspace ADL

3.  Define the broadcast mechanism to disseminate FCAs to FSM for GDP
    actions

4.  Establish a working group to help define functional requirements,
    workflows, operational procedures, training, etc.

[]{#__RefHeading___Toc101602603 .anchor}MEETING NOTES

[]{#__RefHeading___Toc101602604 .anchor}Introduction and Opening Remarks

An Airspace GDP meeting was held on 13 April 2005 in Room 1006 of the
ATCSCC. The attendees listed in Appendix A were requested to read the
Metron Aviation memorandum "Airspace Ground Delay Programs -- Initial
Draft Requirements" (Appendix B) as a starting point for discussion at
this meeting.

Meeting Notes and Presentations will be posted at:
<http://ksn.faa.gov/km/ATO/coo/sysops/sysopsprograms/TFMprograms/TFMresearch/ERCM/Tab1b.aspx>

Ved Sud kicked off the meeting and indicated the purpose of the session
was to discuss how to deliver an operational Airspace GDP application in
the ETMS 8.2 release. The meeting would determine initial development
activities, resources, and capabilities needed to accomplish this.

Mark Novak said that Airspace GDP is the highest FAA priority
requirement for ETMS 8.2. He said a \$75 million benefit per year has
been advertised, which makes Airspace GDP the number one work item for
v8.2. Mark and others expressed concern with managing expectations and
being able to deliver this capability. The Return on Investment figure
advertised could be premature and may only be reached after significant
investment in multiple technical and procedural enhancements are made.
Tim Grovac said he wanted a realistic assessment up front and wanted a
discussion on what is required to deliver the minimum acceptable
operational capability in v8.2. Later releases could add to this
functionality. All agreed that expectations may be a bit premature and
unrealistic at the moment, but expected benefits are the clear driver of
this project.

The Metron memo by Mike Brennan and Chris Ermatinger (Appendix B)
distinguishes what they feel are "nice-to-have" features, "important but
high-risk" features, and approaches with less risk but less
functionality.

**Airspace GDP for Legacy vs. TFM-Modernization Platforms**

Jim Ries said the benefit for both legacy and TFM-M needed to be broken
out and that Russ Chew would be reasonable when the assessments were
presented to him

-   Organizations that provide benefits should update the assessments

Mark Novak said this functionality was targeted for the legacy TFM
system and was expected to be available before TFM-M initial delivery

[]{#__RefHeading___Toc101602605 .anchor}Airspace GDP Project SCOPE
Discussions

-   Need to manage expectations and determine level of effort for Metron
    and Volpe in the current budget-constrained environment

    -   Increased resources would have to come from other places

    -   Adaptive Compression:

        -   May drop down or even off the v8.2 priority work item list

        -   It was agreed that Adaptive Compression is [not]{.underline}
            a prerequisite to realize benefits from this Airspace Delay
            Program project.

        -   Rick Oiesen said Volpe may not have developer resources for
            Adaptive Compression

            -   Should have Adaptive Compression in airport program
                first anyway in order to see if it works properly before
                trying in an Airspace-based program

            -   Adaptive Compression requirement is that individual
                airports can be turned on or off

    -   Pop-up work needs to be assessed also

    -   Miro Lehky said there were "gaps" in the GAAP and other GDP
        items that needed clean-up

    -   We also need to carefully analyze to make sure the new Airspace
        program does not mess up regular GDPs

-   Tim Grovac said he wanted the "Studebaker" and not the Cadillac in
    ETMS 8.2 release, but wanted real operational functionality for the
    users (not just a 'prototype' version); enhancements could come in
    later releases.

    -   Command Center only functionality for v8.2 is okay

    -   ECR (EDCT Change Request) functionality may not be possible in
        v8.2

    -   A GAAP version of Airspace GDP would be in a later phase.

    -   Tim doesn't want to lose the FEA/FCA filtering; therefore, TSD
        is the tool Volpe will build FEA/FCAs on for Airspace GDPs

    -   Miro said we need to establish the minimum acceptable
        functionality required

    -   Discussion led Miro to conclusion that FSM would probably be the
        Metron tool chosen for Airspace GDPs

        -   Although a hard requirement for implementation on the
            current FSM was not mandated, Miro believed that other
            conditions would lead this to be the only appropriate choice
            \-- a separate, distinct FSM for Airspace Program use may
            not be practical.

    -   The first release can be a basic operational tool; e.g., just
        delay aircraft on the ground with an FCA List.

    -   No substitutions or other enhanced functions would be required
        in Release 1.

    -   Is ECR necessary in Airspace Delay Program Release 1?

        -   Maybe not?

        -   ATCT already has a list for GDP airports?

        -   Airspace GDP: If the EDCT is past, you would release anyway?

    -   The Release 1 product must be operationally sound, but not
        necessarily fully functional\
        (NOTE: Points to the need for operations personnel to input to
        the Requirements and Ops Concept.)

    -   Rick Oiesen noted two key Volpe/Hub site requirements for a
        Release 1 functionality:

        -   Produce airport FADT Lists

        -   Produce Airspace Aggregate Demand Lists (ADL)\
            There was some discussion that a simple FCA List might be
            used as a fallback if there was no Airspace ADL, but Rick
            pointed out the great advantage of the ADL to common
            situation awareness.\
            Most think the ADL should therefore be produced as it was
            not seen as a big risk.

    -   A new tool would *[not]{.underline}* be provided to
        filter/display FCAs and Filters; just use the current TSD
        toolset to create FCAs and Filters.

    -   Once an FCA and FCA List are generated, the necessary
        requirement is to get that information to FSM

        -   Rick Oiesen pointed out that the Flight Schedule Monitors
            would have to know all FEA/FCAs and that the specialists
            would pick out which ones to use for Airspace GDPs

            -   The number of Airspace GDPs is expected to be small but
                Jim Ries said not to advertise this; Jim said the "devil
                is in the details" and this needed to work to be
                accepted by the field (especially with the EDCTs in the
                ATCT cabs and the printing of strips)

**Operational Impact Discussion:**

-   Jim Ries pointed out that a number of FCAs in the NAS at one time
    (e.g., airport plus airspace) could be a tremendous impact on the
    system, Air Traffic Control Towers (ATCTs) in particular.

    -   There could be a lot of confusion about EDCTs.\
        What happens when you have an airport EDCT and an FCA EDCT
        somewhere else?

    -   There should be no changes to Host and we need to consider when
        strips are generated versus alerts being sent to the "CRD"

    -   Tim said that ATCTs get the airport listings for airport GDPs

    -   ATCTs would not get Airspace GDPs listings

    -   How could EDCT times be changed, or how do we tell an ATCT an
        EDCT is lifted?\
        There was some brainstorming of ways we might do this (e.g.,
        resetting time to some standard indicator like 0800).

    -   The seriousness of this issue can be seen in the fact that many
        distance-based Ground Stop programs have had to be halted
        because of the problem of getting good information to ATCTs.

[]{#__RefHeading___Toc101602606 .anchor}Basic Steps for an Airspace GDP

The group then put the basic steps for an Airspace-based Delay Program
on the board to help walk through plans, issues, ideas, requirements,
etc. for the project.

**Step 1:** User creates FCA on TSD

-   NOTE: FCAs need to distributed to all users.\
    FEAs would be good for doing local modeling, but that is not likely
    a Release 1 capability.)

-   A Baseline time or "snapshot" is taken to determine flights, events,
    etc., that are included in the Airspace GDP program

**Step 2:** Inform all FSMs about the FCA

-   Hub needs to be able to broadcast to all users

**Step 3:** Create an ADL for the FCA

-   Graphical display of the FCA ADL is needed, especially for analyses

**Step 4:** Model the Program

-   Hub would have to handle proposed as well as actual program

-   The modeled proposed parameters would be sent out to all FSMs

    -   Proposed is nice-to-have; may not be in v8.2

    -   Need to check on changes to Autosend, although not believed to
        be needed

    -   Ken Howard said using the current method reduces risk

    -   Need to consider FDB changes for pop-ups, etc.

**Step 5:** Send program to Hub

-   Mike Brennan and Volpe will discuss ADL updates and how to include,
    exclude, and update set of flights to keep track of

    -   Could suppress EDCTs at Hub if flight reroutes out of FCA

**Step 6:** Manage changes to the ADL vs. Baseline (see Step 1)

**Step 7:** General Data Flow for the program to be handled mostly as it
is in today's GDPs.

-   A hierarchy of Programs may need to be defined.

    -   Airport GDPs should have higher precedence than Airspace GDPs.

    -   For aircraft traversing more than one FCA, first Airspace GDP
        FCA encountered by a flight is higher than second or later FCA.

-   Includes transmission to customers.

    -   Slot lists, etc.

    -   IGTD or ACID for tracking (same flight, same time w/ different
        arrival airports)

-   Question on airlines' software.

    -   Ken Howard said there were two models (ADL-based and Slot list-
        based)

    -   Subs may be able to be handled, but this is not settled and not
        mandatory for Release 1 if it would prohibit delivery

    -   How to handle ADLs and FADTs is necessary

    -   Airlines often require up to a year for their own software
        development mods

-   It was noted that the Stop time for a GDP would have to be separate
    from the FCA time -- the FCA time should always be longer to avoid
    potential problems.

**Step 8:** Purge the Program

-   A discussion was held regarding choosing a closing time for a Delay
    Program

    -   Host will take any valid time (e.g., 0800 could be used as an
        identifying indicator for stopping a program)

    -   Can search database for a good time

    -   Trigger time to alert of change (handle internal to Volpe?)

    -   How to notify ATCTs?

    -   EDCT update time?

    -   Need to know of other FCAs

    -   Use current FSM capabilities -- ECR request for uncontrolled
        flight

[]{#refheading___toc101602607 .anchor}Next Steps

Three major steps were defined to get the Airspace Delay Program moving:

1.  Define the Format for the Airspace FADT List

    a.  WHO: Metron: Miro Lehky and Kevin Rosengren

    b.  WHEN: 1MAY2005

2.  Define the Airspace ADL

    a.  WHO: Mike Brennan, Metron and Ken Howard, Volpe

    b.  WHEN: 1MAY2005

3.  Define the broadcast mechanism to disseminate FCAs (e.g., may just
    be LAT/LONG)\
    NOTE: FCAs only for Release 1 (not FEAs)

    a.  WHO: Metron: Miro Lehky and Kevin Rosengren

    b.  WHEN: 1MAY2005

Other assumed Milestones needed to get to requirements completion:

-   Concept of Operations: by 30MAY2005

-   HITL Testing: by 30JUN2005

    -   A principal objective of the HITL will be to determine:\
        Does the "Studebaker" version of the Airspace-based Delay
        Program provide enough information/functionality to be of use to
        TMCs?

An operational Work Group is to be defined to help define functional
requirements, operational concepts, procedures, training needs, etc.

-   This will likely be the new CDM "Flow Evaluation Sub-team"

-   Mark Libby has been designated to lead this WG.

-   Jim Ries will help define group membership.

[]{#__RefHeading___Toc101602608 .anchor}Design / Project Questions Yet
to be Determined

Tim Grovac led the group in a review and discussion of scope/design
questions that are yet to be determined. (Some of this is repetitive
with the SCOPE discussion above.)

-   Substitutions

-   Slot Credit Substitutions

-   Adaptive Compression

    -   Likely "No"

-   ECR -- for SCS and EDCT

    -   If no ECR,

        -   Need to avoid possible human factors frustrations of having
            different or unusable functionality

        -   Need a way to 'safety-out'/inhibit some current ECR
            functions that will not be usable for airspace based delay
            programs.

-   GAAP-style airspace program

    -   [Agreed]{.underline}: "No" -- not in Release 1

-   Connectivity to other Applications, such as: OIS, Web Cover Sheet,
    NTML, Real-time FSA (for post-analysis), Post-Analysis FSA

-   ADVZY/NOTAM changes

-   Support for non-ESM (Enhanced Substitution Module) users

    -   The definition of the FADT will determine the impact on these
        users. They should be advised/trained as soon as possible.

-   Separate Tool or merged into FSM program

    -   [Agreed]{.underline}: Use current FSM software platform for
        development efficiency and to ensure a method for common
        situational awareness

-   Deploy to ATCSCC only, or to Field and Airlines as well

    -   [Agreed]{.underline}: Probably just ATCSCC in Release 1

-   Training and Procedures: TBD, but assume the new Work Group will
    address these issues.

    -   What Training is required? When?

    -   Jupiter Mods for Training need to be defined

    -   NAS Customer Training needs to be defined

    -   ConOps needed to define who is the tool user, what is the use
        plan, etc.

        -   This is expected to be a real time operational tool; that
            is, a 24x7 requirement, etc.

-   Modeling version of Airspace GDP

    -   Can there be a specific FEA type of Airspace GDP for Modeling --
        not to run a Delay Program, just to do "what if" analyses?

    -   Developers will consider the possibility; it should be possible
        from the FSM side

    -   Not likely in the first release

    -   Maybe a "Naming Convention" solution could be used to designate
        "model only" programs distinct from actual delay programs.

**Other Schedule Questions:**

-   Can the Requirements Documentation be worked in parallel with HITLs,
    prototype builds, etc.?

    -   Just use the HITLs to answer unknowns, issues, etc.

-   Metron pointed out that the planned 8.03 FSM release may not be
    possible with the work required for this Airspace Program.

    -   Tim Grovac indicated Metron should review schedule questions and
        offer choices, and then we can make logical choices and
        decisions about what can be done and when.

[]{#__RefHeading___Toc101602609 .anchor}Appendix A: Attendees

  ---------------------------------------------------------------------------------
  **NAME**                           **ORGANIZATION**        **TELEPHONE NO.**
  ---------- ----------------------- ----------------------- ----------------------
             Joe Bertapelle          MITRE/CAASD             703-983-2690

             Mike Brennan            Metron Aviation         703-925-3123

             Barry Davis             FAA/ATO-R               703-326-3837

             Chris Ermatinger        Metron Aviation         703-234-0736

             Tim Grovac              FAA/ATO-R               703-904-4402

             Nayeem Hoq              FAA/ATO-R               202-385-8494

             Ken Howard (telcon)     Volpe Center/DTS-56     617-494-2697

             Mike Krause             TAC2/CTA                703-345-6943

             Joe Lahoud              FAA/ATO-R               202-385-8459

             Miro Lehky              Metron Aviation         703-234-0737

             John Mayo               MITRE/CAASD             703-983-7991

             Judy Morrill            FAA/ATO-R               703-326-3909

             Mark Novak              FAA/ATO-R               703-326-3781

             Rick Oiesen             Volpe Center/DTS-56     617-494-2309

             Paul Pederson           TAC2/NGIT               703-345-7276

             Jim Ries                FAA/ZOB/CDM             703-326-3847

             Kevin Rosengren         Metron Aviation         703-234-0790

             Bill Sears              Metron Aviation         703-234-0788

             Midori Tanino           Flatirons Solutions     703-201-9065

             Ved Sud                 FAA/ATO-R               202-385-8474
  ---------------------------------------------------------------------------------

[]{#__RefHeading___Toc101602610 .anchor}Appendix B: Metron Memorandum\
Airspace Ground Delay Programs -- Initial Draft Requirements

**to:** CDM, GDPE

**from:** Michael Brennan, Chris ermatinger

**subject:** Airspace Ground Delay Programs -- Initial Draft
Requirements

**date:** April 12, 2005

**cc:**

**Airspace Ground Delay Programs -- Initial Draft Requirements**

**Introduction**

As congestion throughout the National Airspace System (NAS) and delays
increase, the need for more sophisticated procedures to handle airspace
congestion increases. Currently, a number of procedures are used to
handle airspace congestion, en route spacing programs and miles in trail
are often used to meter traffic into a specific volume of airspace. Flow
constrained areas (FCA) are used as a method of communicating limited
capacity to system users in order to reduce demand by way of reroutes.
In times when severe weather avoidance is the priority, multiple ground
delay programs may be issued with the goal of reducing overall demand in
the volume of airspace. The Collaborative Traffic Flow Management (CTFM)
community has acknowledged the aforementioned methods of dealing with
airspace congestion are inefficient, ineffective, inequitable, and lead
to the over-controlling of flights.

An alternative approach to managing airspace congestion is to merge
existing technologies in the arenas of ground delay program rationing
algorithms and FCA flight list generation. The merging of the two
technologies allows for formal control times to be issued to flights
traversing a congested volume of airspace, while more accurately
defining those flights that shall be controlled.

**The Purpose of this Document**

This document provides a concept of operations and a rough draft of
requirements for one candidate approach to applying ground delay for
airspace constraints, the Airspace Flight Situation Monitor (AFSM) and
the related processes that will be required from the Enhanced Traffic
Management System (ETMS), and communication functions handled by
processes at the Air Traffic Control Systems Command Center (ATCSCC).
The following sections list the functionality that must be provided for
an operational system that handles airspace congestion management
through the application of air traffic control ground delay under the
AFSM model.

This is the first attempt at specifying the initial requirements for
airspace ground delay procedures and is currently only the opinion of
Metron Aviation, although most of the good ideas in this approach came
from elsewhere.\
We expect this document will be revised extensively.

There is a certain amount of color coding in this document. The colors
as used as follows:

Blue indicates things that would be nice to have in an initial
deployment but aren't required for the system to be functional. These
might be better put off for a later release.

Red indicates things that are important for the system as designed and
are identified as high risk. These topics should be thoroughly discussed
before any deployment decisions are made.

Text in green discusses alternative approaches that involve less risk
but provide less functionality. These could be considered as first-step
solutions until the risk issues have been addressed for a later release.

**General Operating Model for AFSM**

Currently, the Flow Constrained Area / Flow Evaluation Area (FCA/FEA)
technology is in place to let users define specific sets of flights in
the NAS by specifying geometries, time windows and flight filters. This
technology can also create lists of flights projected, at any specified
time, be in a given set. The airspace delay program should use FEAs that
are created with this technology through the TSD as the basis for AFSM
flight lists. Any FEA that is defined in the TSD should be a candidate
for an AFSM GDP.

In the initial implementation the FEA creation function and the
rationing function will be in separate modules, the former in TSD and
the latter in AFSM. In a future release these functions can be combined.

Under the candidate model, AFSM will be used to manage the flights in an
FEA much like FSM is used to manage arrivals at an airport. It will be
driven by periodically updated list of flights in the FEA generated by
ETMS, equivalent to an airport ADL. Each such update will contain the
entire state of the FEA, as in the airport ADL.

The general display and analysis functions of FSM will be available in
AFSM. These include the bar graph, the time line, flight lists, flight
detail tables, and report generation functions.

AFSM will be able to run GDPs on the FEA flight lists to reduce demand
in the FEA. A GDP will be based on a stated capacity which will specify
the rate at which flight can enter the FEA volume (for FEAs with a
volume) or cross the FEA point (for FEAs based on specific fixes or NAS
elements).

AFSM will be able to execute GDPs as either DAS programs or GAAP
programs.

When a GDP is run in AFSM EDCTs will be distributed through a modified
Autosend process. These EDCTs will be sent to ETMS, the field
facilities, (the Host?), and the flight operators.

AFSM will support manual compression and revisions. At some later point
AFSM will support Adaptive Compression.

When a flight first appears in the FEA, either as a popup or because it
rerouted into the FEA, it will be treated similar to a popup into an
airport GDP and assigned an EDCT. In GAAP programs the flight should be
given the first available slot, as in airport GAAP programs. In DAS
programs the EDCT may be computed based on FA delay, or another rule
could be applied.

When a flight in the FEA is cancelled, the flight operator (if a CDM
participant) will retain rights to the slot held by the cancelled flight
for compression and substitution purposes, as in airport GDPs today.

When a flight in the FEA routes out of the FEA, the flight operator (if
a CDM participant) will retain rights to the slot held by the rerouted
flight for compression and substitution purposes.

When a flight in the FEA routes out of the FEA, the EDCT for that flight
will be lifted.

Operator substitution of flights in an AFSM program will be supported as
early as is feasible.

**Detailed Functionality and Requirements**

***Flight List Generation for AFSM and Details of Flight Data***

When an instantiation of AFSM is first run it should allow a specialist
to select the FEA that is to be loaded, monitored and perhaps used for
imposing an AFSM GDP.

Multiple instantiations of AFSM can be run to control multiple FEAs.

ETMS should on request provide a list of flights associated with a given
FEA. This list should contain general flight data as in the current ADL
feed, plus additional fields mentioned below.

This flight list should be updated periodically, probably every 5
minutes, and distributed to any requesting FSM servers through existing
data distribution channels.

This regularly generated flight list constitutes the airspace version of
the Aggregate Demand List, called here the AADL. A new term for the AADL
should be coined.

The AADL should also contain the expect time of arrival at the FEA.

The AADL should have control fields associated with the airspace control
program, such as control element, control exemption status, control
type, control time of entry, and controlled slot.

The AADL should include flights that were traversing the geometry at
some point during the program but that have now routed out of the
airspace. These flights should be labeled as such.

The AADL will include data blocks similar to those in the ADL containing
additional FEA and program information.

The AADL should also contain a data block describing the associated FEA.

The FSM server should be modified to accept an AADL and pass it on to
any requesting AFSM clients. Alternatively, a modified version of the
FSM server could be created to accept AADLs.

An alternative to an FEA ADL would be to use the FCA/FEA Flight List
function from ETMS and have AFSM periodically request a flight list in
lieu of an FEA ADL. This approach would limit the level of common
situational awareness that could be achieved.

***Modeling a GDP***

At any time a specialist can choose to execute a GDP on the flights in
an FEA.

The GDP parameter specification will be much like that for an airport
program, including time frame, rate profile over time, and exemptions.

Distance-based GDPs will not be supported as there is no defined or
easily computable distance from a departure airport to an FEA.

A program can be run under either the DAS model or the GAAP model.

The program parameters will include an arrival rate profile -- the
number of flights that can be managed in each 15 minute period of the
program. This rate will be interpreted as the number of flights that can
enter the FEA airspace volume, pass through the FEA line, or cross over
the FEA fix in the given period, depending on the nature of the FEA
geometry. Dwell time in an FEA will not be considered.

The specialists will be able to specify a reduction factor instead of an
arrival rate profile. That is, they will be able to reduce traffic by a
given percentage. This will be interpreted to mean that they wish to
reduce the total number of flights arriving during the program to the
specified fraction of the number of flights that would arrive in the
absence of controls, and that they want the flow to be uniform across
the extent of the program.

The specialist will be able to send out advisories for a program to
other users, as in airport programs today. The parameters of the
proposed program will be distributed in the AADL.

***Initial Schedule in the FEA for RBS Purposes***

Ration by Schedule (RBS) needs an initial schedule to work from. AFSM
should create the initial schedule for the FEA based on the initial
flight list produced by ETMS at the time AFSM is first run for the FEA.
This flight list will typically depend on scheduled flight plans for
many of the flights.

Cancelled flights should appear on this list if their last entered
flight plan implies inclusion in the FEA list. This will minimize double
penalty issues.

For flights in queue 1 in RBS, the flights should be sorted on
'scheduled FEA arrival time' rather than IGTA. This time is defined as
the expected entry time into the FEA as given in the FEA flight list
adjusted by the difference between airport ETA and IGTA. This adjustment
is applied to remove any double penalty issues.

The other queues would be constructed as with airport GDPs.

***Sending out a Program***

After a program has been modeled it can be executed by sending out
control times (EDCTs) for the affected flights and program parameters.

The FADT will have to be modified to include arrival airports for each
flight.

Autosend will have to be modified to deal with the modified FADT.

The FADT for an airspace program will be identified as such.

The control element for the FADT flights will be the FEA involved in the
GDP.

The FADT will contain applicable FA delay tables for popups.

The FADT should contain information describing the associated FEA.

ETMS will have to accept and process EDCT lists with flights with
multiple arrival airports.

Airlines and other operators will have to ensure their software can
accept the new EDCT lists.

AFSM should create advisories for the airspace initiative that should be
machine readable for the posting of the program on the Operational
Information System webpage and storing in the ATCSCC advisories
database.

As a low-risk alternative to the multiple-airport FADT, a major portion
of the flights in the FEA could be controlled by issuing a limited
number of airport-specific FADTs. AFSM could by modified to identify the
set of X arrival airports that control the most flights in the FEA and
exempt flights destined to the remaining airports. EDCTs for the
exempted flights would not be sent.

***Popup Handling***

For AFSM a popup is a flight that either newly entered ETMS and is
involved in the FEA or an existing flight that newly entered the FEA
through either a reroute or a departure time change.

Popups should be recognized and controlled. Treatment for these two
types of popups could be different. The former kind, flights newly in
ETMS might be handled as current popups are while flights routing into
the congested area may be treated differently.

For a GAAP program flights would get the earliest available slot, as
with airport GAAP programs.

***Drop-out Handling***

Flights can drop out of the constrained airspace in two ways -- they can
be cancelled or they can reroute around the FEA.

Flights that are cancelled would retain their EDCT, as in airport
programs.

Flights that route around the FEA should have their EDCTs lifted and be
free to depart without constraint (unless otherwise controlled). There
is presently no way to remove an EDCT from a single controlled flight.
This may require a Host change. Several suboptimal workarounds for this,
such as issuing an EDCT at the BETD or at the current time, are
available if a better solution can't be found.

If a flight leaves the FEA through either a reroute or cancellation the
carrier would retain ownership of the vacated slot for compression and
substitution purposes. This would not be applied to unaffiliated
flights.

***Compressions and Revisions***

Similarly to airport programs, popups, delays and cancellations will
affect the smoothness of the demand profile in the FEA. Additionally,
the capacity of the FEA may change with the weather. AFSM will support
the compression and revision functions developed for FSM to adjust
demand to capacity.

All rules for these functions developed for airport programs will be
applied.

New control times will be sent out through FADTs.

Exempt flights will not be affected by these procedures.

Exempt flights will not be included in the FADT.

***Flights in Multiple Ground Delay Programs***

Flights involved in airport GDPs when AFSM program is run will be
considered exempt by AFSM. Their demand will be considered in the
allocation of slots to non-exempt flights but they will not be delayed.

The inclusion of a flight in an airport GDP will be determined by the
presence of an initial EDCT for the flight and the destination airport
for the flight being in a GDP.

These exempt flights will not be included in the FADT and so will have
no change to their control time or control type.

If a flight is in an airspace GDP when an airport program is run the
airport program will take precedence and the airspace EDCT will be
overwritten. This will disrupt the smooth flow through the FEA and may
eventually trigger a revision or compression.

If a flight is in both an airport program and an airspace program and
the airport program is cancelled, the flight should receive an FA delay
appropriate for the airspace program.

If a flight is in both an airport program and an airspace program and
the airspace program is cancelled, the flight will not be affected as
the airport program had priority all along.

If a flight in an airport program reroutes into an airspace program, the
flight will not be affected.

If a popup flight enters an airport program and an airspace program, the
delay associated with the airport program should be applied. (An
alternative would be to apply the larger of the two delays.)

If a flight is already controlled by an airspace program when another
airspace program is run, the controls from the earlier program will
still apply, and the flight will be exempt in the later program.

If a flight is in more than one FEA program and the program with the
operative controls is cancelled, the flight should be treated as a popup
in the remaining program.

***Purging of Control Times***

AFSM should be able to create a purge airspace control message, by which
all flights in the controlled geometry that not involved in other
programs have their control information voided and their EDCTs removed.

Currently no clear mechanism for removing EDCTs from the host has been
identified.