![](media/image1.wmf){width="0.4576388888888889in"
height="0.5097222222222222in"} Memorandum

U.S. Department

of Transportation

Research and John A. Volpe

Special Programs National Transportation Systems Center

Administration

Date: April 7, 1997 Reply to Attn. of: DTS--56

Subject: Version 2.0 of the System Requirements for Task 3 of the
Collaborative\
Decision--Making Program

From: Ken Howard/Volpe Center (617) 494--2697

To: CDM Workgroup

Attached is Version 2.0 of the System Requirements Document for Task 3
of the Collaborative Decision--Making (CDM) Program. Version 2.0 is a
significant rewrite of the previous version (1.2). The document has been
re-organized and has many functional changes reflecting the evolution of
the system over the past 8 months.

The changes are primarily in the message exchange portion of the
document; that is, the section that describes what messages an airline
must send, how they must be sent, and how ATMS must process them. The
portion of the requirements describing the slot alocation is largely
unchanged from the previous version (1.2).

We strongly recommend that all parties who are building the CDM Task 3
software carefully reread these requirements. This is a good time to
re-validate that our development is converging on a consistent
functionality and that there are no expectations that will be unmet. Any
comments, corrections, or questions should be sent to the author.

The major changes in the document are as follows:

-   The document has been organized to separate airline requirements
    from ATMS requirements.

-   Requirements have been added for diversion and cancellation
    processing.

SYSTEM REQUIREMENTS DOCUMENT FOR TASK 3\
OF THE COLLABORATIVE DECISION--MAKING PROGRAM

# Introduction

## Overview

This document describes the system requirements for Task 3 of the ATMS
Collaborative Decision--Making (CDM) Ground Delay Program (GDP)
Enhancements Program. Task 3 consists of modifying airline and FAA data
processing systems to provide several significant new functions:

-   send data directly from airlines to FAA concerning delays,
    cancellations, and other schedule changes

-   send data from FAA to airlines concerning the aggregate traffic
    demand at airports

-   assign arrival slots during ground delay programs according to OAG
    schedule

-   apply compression to allow airlines to fully utilize their arrival
    slots

The advantage that this software offers to the FAA and the airlines is
to reduce the number of ground delays issued and to preserve key aspects
of the airlines' scheduling when a program is run. This can be
accomplished for several reasons.

-   FAA modeling (and therefore Monitor/Alert) will be based on current
    information on delays and cancellations rather than on the stale and
    less accurate information that is now used.

-   The airlines will no longer be penalized if they submit early
    information on delays and cancellations to the FAA.

-   The order of flights in the OAG schedule will be preserved during
    ground delay programs.

The CDM GDP Enhancements Program includes other tasks that will be
documented at a later date. These tasks include:

-   incorporating airline operational schedules

-   simplifying the substitution process

-   controlling by time of arrival

-   exchanging additional data

## Organization of this Document

This document has been organized into separate sections for the
different major components of the CDM GDP system to facilitate its use
by the different organizations involved in CDM. However, it is strongly
recommended that anyone participating in the CDM GDP system development
read the entire document to gain an understanding of the entire CDM
system. For example, an airline developer needs to understand the ATMS
requirements for accepting and rejecting messages described in section 3
to ensure that the messages will be properly generated.

This document is divided into four main sections:

-   Section 1. - Introduction

-   Section 2. - Airline Requirements

-   Section 3. - ATMS Requirements

-   Section 4. - FSM Requirements

## Definitions

There are terms used throughout this document with a very specific
meaning. These are defined as follows:

-   ***Advanced Traffic Management System (ATMS)*** is the prototype FAA
    system for processing CDM flight data messages along with other
    flight data to maintain a national flight data base. ATMS provides
    that data to the FAA traffic management specialists. ATMS is the R&D
    counterpart to ETMS.

-   ***Aggregate Demand List (ADL)*** is a set of data that provides a
    picture of the total predicted arrival demand at an airport.

-   ***Airline*** is used generically to refer to any organization that
    regularly operates a schedule of flights in the NAS and is
    participating in the CDM GDP Enhancements program

-   ***Compression*** is an algorithm used when computing a ground delay
    program that creates a "bridge" across a gap in a substitution
    sequence by moving other flights up in time.

-   ***Enhanced Traffic Management System (ETMS)*** is the operational
    FAA traffic management system.

-   ***Flight*** refers to a single occurrence of a single leg of a
    flight (e.g., United flight 123 from BOS to ORD on January 30,
    1996).

-   ***Flight Data Message*** refers to the airline messages that
    create, modify, or cancel flights.

-   ***Flight Data System*** is used generically to refer to an
    airline's data processing system for maintaining operational flight
    schedule data.

-   ***Flight Database*** is the ATMS hub site database containing
    national flight data which is used for FAA traffic management.

-   ***Flight Schedule Monitor (FSM)*** is the prototype software
    developed by FAA for viewing flight data and running traffic
    management programs associated with managing arrivals at an airport.

-   ***Ground Delay Program (GDP)*** is a set of departure and arrival
    times assigned by FAA to flights to manage an airport arrival
    overload.

-   ***National Airspace System (NAS)*** is the FAA's air traffic
    control system.

-   ***NAS Data*** is automated data from the NAS including flight
    plans, amendments, cancellations, departures, arrivals, track
    (position) updates, and center boundary crossings.

-   ***Substitution*** is an action whereby an airline moves a flight
    from one assigned arrival slot into another arrival slot. A
    substitution may involve moving a flight into a cancelled flight's
    slot, moving a flight into a previously vacated slot, or exchanging
    two flights' arrival slots.

## Associated Documents

Other documents related to the CDM program are as follows:

-   ***ADL Data Format*** specifies the ADL report format and contents.

-   ***CDM Message Formats*** specifies the message formats and
    protocols for flight data exchange between airlines and FAA.

# Airline Requirements

## Overview

Airlines currently make many decisions on how they will operate their
flights of which the FAA is unaware. In particular, during a bad weather
situation at an airport, an airline may be aware of delays and/or
cancellations that affect the arrival situation at that airport.
Airlines have in the past been discouraged from sending delays and
cancellations to FAA as they may lose arrival slots or receive
additional delays once a GDP is run. Under CDM Task 3, the GDP software
and policy are being modified to remove these penalties. As a
consequence, also as part of Task 3, airline Flight Data Systems are
being modified to send flight data messages directly to ATMS notifying
FAA of the latest and best data that the airlines have for the flights.
Section 2.2 specifies the requirements for the airline generation of
flight data messages.

Simplifying the substitution process is beyond the scope of Task 3. The
airlines will continue to use the current operational SI process, as
stated in Section 2.3.

## Flight Data Message Generation

Airlines will generate three types of flight data messages.

-   ***Create*** message - Either creates a new flight or reinstates a
    flight that had previously been cancelled.

-   ***Modify*** message - Provides new data for a flight.

-   ***Cancel*** message - Cancels a flight.

The requirements for generating these messages are as follows.

### Communications

Two mechanisms are currently being provided for airlines to use for
sending flight data messages to ATMS: the pre-existing ARINC network and
the new private AOCNet. In the future, the Internet may also be used for
transmitting flight data messages.

**Req. 2.2.1-1** An airline shall feed flight data messages to ATMS in
one of the two following manners:

a)  via ARINC to an ARINC address designated by FAA

b)  via AOCNet to an IP address designated by FAA

**Req. 2. 2.1-2** An airline shall provide a default address (ARINC or
IP) for ATMS to use when generating message replies and error messages.

**Req. 2. 2.1-3** An airline shall follow the message formats and
protocols specified in the document *CDM Message Formats*.

### Message Formatting

Some general requirements about the contents of the messages are
specified here. Requirements specific to each message type are specified
in sections 2.2.3 - 2.2.5. Detailed formats for the messages are
documented separately, as stated in requirement 2.2.2-4:

**Req. 2.2.2-1** The airlines shall provide all dates and times in
Universal Time Coordinates (formerly GMT).

**Req. 2.2.2-2** For the purposes of uniquely identifying a flight, the
airlines shall provide on each flight message the following fields: the
flight ID, original departure date/time, origin airport, and destination
airport.

**Req. 2.2.2-3** The original departure date time shall be the month,
date, hour, and minute on which the flight leg was originally planned to
leave the gate at its departure airport; that is,

a)  for a flight in OAG, the original departure date/time shall be the
    gate departure time for that flight leg as specified in the OAG
    schedule

b)  for a flight not in OAG, the original departure date/time shall be
    the gate departure time for that flight leg as specified in the
    message which first created the flight in the ATMS flight database

Additional data fields and message types will be specified in the
future; however, they are not required to complete CDM Task 3.

**Req. 2.2.2-4** Airline flight data messages shall be formatted
according to the specifications found in the document *CDM Message
Formats*.

### Create Message

Airlines will send create messages to ATMS to ensure that all flights
that will be operating are in the ATMS database. Create messages will be
sent to add a new flight or to re-instate a flight that has previously
been cancelled.

**Req. 2.2.3-1** An airline shall send a create message to ATMS whenever
any of the following conditions is met:

a)  a new flight is created in its Flight Data System

b)  a previously cancelled flight has been reinstated in its Flight Data
    System (i.e., the airline is now planning to operate the flight)

c)  a flight on the ground is diverted to a new destination (see section
    2.2.6 for diversion processing)

**Req. 2.2.3-2** An airline create message shall specify the following
information for the flight being created:

a)  flight ID

b)  original departure date/time

c)  departure airport

d)  arrival airport

e)  gate departure date/time

f)  runway departure date/time (optional)

g)  arrival airport

h)  gate arrival date/time

i)  runway arrival date/time (optional)

j)  aircraft type

**Req. 2.2.3-3** The airlines shall always provide gate times when a
flight is first created. The airline shall also provide runway times
whenever available.

### Modify Message

Airlines will send modify messages to ATMS to ensure that ATMS has the
latest data for its flights.

**Req. 2.2.4-1** An airline shall send a modify message to ATMS whenever
any of the following conditions is met:

a)  the call sign changes

b)  the equipment type changes

c)  the destination changes for an airborne flight

d)  the gate departure time changes by more than 15 minutes from the
    last value sent to ATMS

e)  the gate arrival time changes by more than 15 minutes from the last
    value sent to ATMS

f)  the runway departure time changes by more than 15 minutes from the
    last value sent to ATMS

g)  the runway arrival time changes by more than 15 minutes from the
    last value sent to ATMS

**Req. 2.2.4-2** An airline modify message shall specify the following
information for the flight being modified:

a)  flight ID

b)  original departure date/time

c)  departure airport

d)  arrival airport

e)  modified flight data (can be multiple fields)

### Cancel Message

Airlines will send cancel messages to ATMS to ensure that FAA is aware
of any flights that are not going to operate. (NOTE: Once a flight is
cancelled it can only be re-instated with a create message.)

**Req. 2.2.5-1** An airline shall send a cancel message to ATMS whenever
any of the following conditions is met:

a)  a flight is not going to operate

b)  a flight on the ground has been diverted to another airport (see
    section 2.2.6 for diversion processing)

**Req. 2.2.5-2** An airline cancel message shall specify the following
information for the flight being cancelled:

a)  flight ID

b)  original departure date/time

c)  departure airport

d)  arrival airport

### Exception Cases

Although the general message requirements above implicitly cover the
exception cases (diversions and cancellations), they should be restated
explicitly to ensure proper message generation. The message requirements
for these cases are in some cases dictated by the data requirements of
FSM and by the processing required to combine the airline data with NAS
data.

**Req. 2.2.6-1** An airline shall divert a flight on the ground to a new
destination by sending a cancel message for the old flight (i.e., old
destination) and a create message for the new flight (i.e., new
destination).

**Req. 2.2.6-2** An airline shall divert a flight in the air to a
different destination by sending a modify message with the revised
destination.

**Req. 2.2.6-3** An airline shall indicate that a flight has returned to
the gate by either:

a)  sending a modify message with the new flight data if the airline is
    still planning to operate the flight to the same destination

b)  sending a cancel message if the airline is not planning to operate
    the flight

c)  sending a cancel and create message if the airline is planning to
    operate the flight to a new destination (i.e., process it as a
    diversion for a flight on the ground)

We have not stated an explicit requirement for a flight that departs and
then returns to its originating station. This case should be handled as
an airborne diversion (requirement 2.2.6-2).

Examples of exception case processing can be found in the memo *Message
Processing for Exception Cases*.

## Substitution Messages

Task 3 does not include any modifications to the substitution processing
that occurs after a GDP is issued, so the old rules and message formats
must still be followed.

**Req. 2.3-1** Following the issuance of a GDP by FAA, an airline shall
substitute flights by using the existing ETMS message formats and
processing rules.

# ATMS Requirements

## Overview

The main function of ATMS is to provide traffic management specialists
with the best possible prediction of traffic demands to allow the
specialists to anticipate and avoid traffic congestion and delays. ATMS
currently receives flight data from two primary sources. OAG provides
airline schedules for far look--ahead planning; flights from the OAG
schedules are loaded into the ATMS databases twelve hours prior to their
departure time. NAS provides real--time data about flights as they
operate; NAS data typically begins to enter the ATMS databases about one
hour prior to departure. These two data sources leave a gap during a
critical time when much traffic management planning is done. Under CDM
Task 3, this gap will be filled by data sent directly from airlines to
ATMS via flight data messages. The requirements for processing the
flight data messages are specified in Section 3.2.

ATMS will incorporate the airline flight data into its databases along
with the OAG and NAS data, and provide the enhanced data through its
normal outputs to the FAA traffic management specialists. ATMS will also
be enhanced to provide ADL files to both traffic management specialists
and airline personnel for viewing through FSM. Section 3.3 gives the
requirements for generating CDM-related outputs

## Flight Data Message Processing

When a flight data message is received, the main processing job for each
message will normally be to:

-   Create message: insert that flight into the Flight Database.

-   Modify message: change the flight data in the Flight Database;

-   Cancel message: mark that flight in the Flight Database as
    cancelled.

The requirements for processing these messages are as follows.

### Communications

Two mechanisms are currently being provided for airlines to use for
sending flight data messages to ATMS: the pre-existing ARINC network and
the new private AOCNet. In the future, the Internet may also be used for
transmitting flight data messages. ATMS will keep CDM communications
separate from any communications with the operational system.

**Req. 3.2.1-1** ATMS shall provide two destinations for airline flight
data messages

a)  an ARINC address on the existing ARINC network

b)  an IP address on the new AOCNet

**Req. 3. 2.1-2** ATMS shall send replies and error messages to the
return address associated with the message, or in lieu of any return
address, a default address provided by the airline.

**Req. 3. 2.1-3** ATMS shall follow the message formats and protocols
specified in the document *CDM Message Formats*.

**Req. 3. 2.1-4** ATMS shall keep the CDM communications paths separate
from the operational ETMS.

### Packet Handling

ATMS will by default acknowledge every message that it receives. To
reduce the amount of data going back to the airline, an airline may
optionally specify that no reply is wanted if no errors are found.

**Req. 3. 2.2-1** ATMS shall positively acknowledge every message packet
that is received unless indicated otherwise by the sending airline.

**Req. 3. 2.2-2** ATMS shall allow the airline to suppress an
acknowledgment when no errors are found in a message packet.

**Req. 3. 2.2-3** ATMS shall always send a reply when an error is
encountered in a packet.

**Req. 3. 2.2-4** ATMS shall indicate in a packet reply whether each
message in the packet was processed successfully or not.

**Req. 3. 2.2-5** ATMS shall send an explanatory error message for each
message in a packet that is not processed successfully.

**Req. 3. 2.2-6** ATMS shall send any reply within one minute of
receiving a message packet.

The format of the acknowledgment and error messages is specified in the
document *CDM Message Formats.*

### Syntax Checking

The formats of the flight data messages are specified in the document
*CDM Message Formats.* Prior to performing any processing of the data,
ATMS will check the syntax of the messages according to those
specifications. ATMS will reject messages that have syntax errors and
not use them for updating the ATMS Flight Databases.

**Req. 3. 2.3-1** ATMS shall verify the syntax of each message prior to
processing the data in the message and shall reject any message which is
found to have incorrect syntax.

### Message Timing

At any given time, the ATMS Flight Database maintains data only for
flights scheduled to depart in the next twelve hours. Airlines, however,
know about changes to their flight operations, in some cases, weeks or
months ahead of time. In order to ease the job of implementation for the
airlines, ATMS will accept airline flight data messages at any time and
enter them into the Flight Database when appropriate. Because the
departure date on the messages is limited to month and date, the
airlines are practically limited from sending in flight messages more
than one year prior to a flight's departure time. To reduce the
possibility of errors, we suggest that the time period be limited to 11
months following the current month (this prohibits receiving messages
for March 1998 during March 1997 and perhaps confusing them).

**Req. 3.2.4-1** ATMS shall use any flight message showing an original
or estimated gate departure time within 12 hours of the current time to
immediately update the Flight Database.

**Req. 3.2.4-2** ATMS shall store any flight message showing an original
and estimated gate departure beyond 12 hours from the current time and
within 11 months from the current month and re-process it when the
departure time is within the 12 hour window of the current time.

**Req. 3.2.4-3** ATMS shall process the stored messages in the order
that they were originally received.

**Req. 3.2.4-4** When a stored message is re-processed, ATMS shall not
generate a reply to the airline if the message is processed correctly.

**Req. 3.2.4-5** When a stored message is re-processed, ATMS shall
generate a reply to the airline's default address if an error occurs
when processing the message.

###  Create Message Processing

A create message is normally used to create a new entry in the ATMS
Flight Database. However, it may be difficult for an airline to always
know whether a flight exists in the ATMS Flight Database prior to
generating a message. In particular, an airline may think that a flight
is missing from the ATMS database and send a create only to have it
rejected by ATMS because the flight already exists from OAG data. To
reduce unnecessary message rejections, ATMS will accept a create message
for a flight that is already in the Flight Database as long as it is the
first airline message received for that flight.

Create messages are also used to re-instate flights that have already
been cancelled by an airline. A create message is the only airline
message that can re-instate a cancelled flight.

The determination of whether a flight specified in a create message
already exists in the Flight Database can be ambiguous. For example, if
a flight exists that departs the same airport at the same time but has a
different destination than the create message, it is not clear whether
it is the same flight. To properly define the requirements we must
define two types of matches:

-   ***perfect match*** is used when the flight in the message matches
    an entry in the database in flight ID, origin, destination, and
    approximate time of operation

-   ***partial match*** is used when the flight in the message matches
    an entry in the database in origin or destination (but not both),
    and approximate time of operation

A message that has neither type of match is considered to have no
matching entry.

For create messages, a partial match is generally rejected, as it is
likely that there has been some kind of error. The only case that is
accepted is when only OAG data exists for the flight; in this case, it
is most likely that the OAG data is in error and the airline data is
correct. In other cases, the airline data either conflicts with previous
airline data or NAS data and is therefore considered an error.

The next set of requirements explains how create messages will be
handled.

**Req. 3.2.5-1** ATMS shall accept a create message for any flight that
does not match a flight in the Flight Database and add the flight to the
Flight Database.

**Req. 3.2.5-2** ATMS shall accept a create message and update the
flight data for a perfect match in the Flight Database if that flight
meets one of the following criteria:

a)  that flight has previously been cancelled by the airline and has not
    yet been re-instated, or

b)  the create message is the first message that has been received from
    the airline for this flight

**Req. 3.2.5-3** ATMS shall accept a create message and update the
flight data for a partial match in the Flight Database if only OAG data
has previously been received for the flight.

**Req. 3.2.5-4** ATMS shall reject any create message that does not meet
the conditions stated in requirements 3.2.5-1 to 3.2.5-3.

### Modify Message Processing

A modify message is normally used to update data for a flight that
already exists in the Flight Database. However, the same difficulty
exists for the airline as with the create message; namely, the airline
may not know for certain that the flight exists in the ATMS database. To
reduce the amount of message rejections, ATMS will accept a modify
message for a flight that is not already in the database as long as
sufficient data is provided to create the flight entry. However, ATMS
will not allow a modify message to re-instate a cancelled flight.

The decision of whether a modify message matches an existing Flight
Database entry presents the same problems as with the create message.
The terms *perfect match* and *partial match* are again used to clarify
the requirements; see the definition of these terms in section 3.2.5.
The same general principle is used for the modify message as for the
create message; that is, when a modify message partially matches an
entry created from OAG data, ATMS corrects the entry with the airline
data, but ATMS rejects a modify message that partially matches an entry
which has previous airline or NAS data.

There are a number of conditions that can cause a modify message to be
rejected. If none of these is met, ATMS will use the data to update the
database.

The following requirements specify how modify messages will be
processed.

**Req. 3.2.6-1** ATMS shall reject a modify message for a partial match
in the Flight Database if any of the following conditions is met:

a)  airline data has previously been received for this flight

b)  NAS data has previously been received for this flight

c)  an EDCT has been previously received for the flight

**Req. 3.2.6-2** ATMS shall reject a modify message for a perfect match
in the Flight Database if any of the following conditions is met:

a)  the flight has been previously cancelled by the airline and has not
    been re-instated

b)  the flight is on the ground and the origin or destination is being
    modified

c)  the flight is in the air and the origin is being modified

d)  the flight is completed and the origin or destination is being
    modified

e)  the flight is in the air or completed and the estimated gate or
    runway time of departure is being modified

f)  the flight has been completed and the estimated gate or runway time
    of arrival is being modified

g)  the controlled departure time, controlled arrival time, or assigned
    arrival slot is being modified

NOTE: An exception to condition f) is being allowed until the actual
time of arrival field is implemented. Until such time, ATMS will allow
the arrival time to be modified up to one hour after the flight is
completed.

**Req. 3.2.6-3** ATMS shall accept a modify message for a flight that
already exists in the Flight Database and update the data for that
flight as long as the conditions specified in requirement 3.2.6-1 and
3.2.6-2 are not met.

**Req. 3.2.6-4** ATMS shall accept a modify message for a flight that
does **not** exist in the Flight Database if the following data fields
are provided in the message:

-   flight ID

-   departure date

-   departure airport

-   arrival airport

-   gate departure date/time

-   arrival airport

-   gate arrival date/time

-   aircraft type

### Cancel Messages

A cancel message is normally used to indicate that a flight that already
exists in the Flight Database is not going to be operating.
Additionally, to ensure that diversions are properly represented in FSM,
a cancel message is used as part of a diversion of a flight on the
ground (the flight is cancelled and re-created).

The decision of whether a cancel message matches an existing Flight
Database entry presents the same problems as with the create and modify.
The terms *perfect match* and *partial match* are used to clarify the
requirements. See the definition of these terms in section 3.2.5. Cancel
messages with partial matches are always rejected.

There are a number of conditions under which a cancel message is
rejected. If none of these is met, the matching flight in the database
is marked as cancelled.

The following requirements specify how cancel messages will be
processed.

**Req. 3.2.7-1** ATMS shall reject a cancel message that matches no
entry in the Flight Database.

**Req. 3.2.7-2** ATMS shall reject a cancel message that has a partial
match in the Flight Database.

**Req. 3.2.7-3** ATMS shall reject a cancel message that has a perfect
match in the Flight Database if any of the following conditions is met:

a)  the flight has already been cancelled by the airline.

b)  the flight has already departed.

c)  the flight has received an EDCT.

**Req. 3.2.7-4** ATMS shall update the Flight Database for any cancel
message that does not meet any of the criteria in requirements 3.2.7-1
to 3.2.7-3.

### Flight Database Maintenance

ATMS receives flight data from OAG and NAS as well as from the airlines.
ATMS combines incoming data in the Flight Database to provide the best
possible data to the traffic management specialist and airline user. The
definition of "best" data is difficult. A general precedence has been
adopted for resolving data conflicts:

-   NAS data has precedence over airline data

-   Airline data has precedence over OAG data

There are several exceptions to these rules in the current requirements:

-   Airline predicted departure and arrival times have precedence over
    NAS flight plan times.

-   Airline cancellation data has precedence over NAS flight plan data.

Additionally, runway departure and arrival times provided by the
airlines are given precedence over times modeled by ATMS.

This section does not pretend to state the entire requirements for ATMS
Flight Database maintenance but only those relevant to the CDM message
processing. It is assumed that current ETMS processing is followed
except where specified below. Some of these requirements are redundant
with the individual message processing requirements but are included
here to fully clarify the processing requirements.

Cancellations

Following are the requirements for determining whether a flight is
cancelled given conflicting NAS and airline data:

**Req. 3.2.8-1** If a NAS flight plan cancel message is received and
airline flight data messages have previously been received for the
flight and the airline has not cancelled the flight, ATMS shall not
cancel the flight.

**Req. 3.2.8-2** If a NAS flight plan is received for a flight that has
been cancelled by an airline, ATMS shall consider the flight to still be
cancelled.

**Req. 3.2.8-3** If either a NAS flight plan cancellation or airline
cancel message is received for a flight that has only OAG data, ATMS
shall consider the flight cancelled.

In addition to NAS cancellations, a flight may be manually cancelled by
a traffic management specialist through an ASD command. The command
causes an "RS" message to be generated. This is a rare occurrence, and
typically occurs when a specialist has been in communication with an
airline. For this reason, the RS will override the airline flight data
messages.

**Req. 3.2.8-4** If an RS message is received for a flight for which
airline flight data messages have been received, ATMS shall consider the
flight cancelled.

ATMS cancels flights which have not departed well past their planned
departure time and for which no updates have been received. The time out
logic shall remain unchanged from ETMS, but ATMS will allow an airline
message to update the departure time for a "timed-out" flight, and if
the new time is valid, will re-instate the flight. (Note that if a
timed-out flight departs, current ATMS logic will also re-instate the
flight.)

**Req. 3.2.8-5** If a flight for which airline messages have been
received has not departed within one hour of its estimated runway
departure time, ATMS shall consider the flight cancelled.

**Req. 3.2.8-6** If a valid airline flight data message is received for
a flight which has previously been timed out and if the message provides
a new departure time for the flight that is in the future, ATMS shall
re-instate the flight.

[Data Field Updates]{.underline}

The data field updates again rely on the distinction between perfect and
partial matches. Refer to section 3.2.5 for the definition of these
terms. In essence, when a NAS flight plan is a perfect match with
previously received airline data, there are no issues. When a NAS flight
plan has a different origin or destination than previously received
airline data, it is processed as if the flight has been diverted. This
might occur in a situation where an airline diverts a flight close to
departure time and ATMS receives the flight plan before the airline
cancel and create message. This processing is intended to create the
same result in the database as if the cancel and create messages were
received before the flight plan.

Following are the requirements for updating flight data fields in the
Flight Database:

**Req. 3.2.8-7** ATMS shall not allow an airline, through a modify or
cancel message, to change certain fields that have been received in a
NAS flight plan. The fields that may not be changed are:

a)  call sign

b)  departure airport,

c)  arrival airport, and

d)  aircraft type.

**Req. 3.2.8-8** When a NAS flight plan is a perfect match with a flight
that has been created or modified by an airline message, ATMS will only
use the aircraft type to update the database (NOTE: The flight plan
times will be saved but not used to update the estimated runway times of
departure and arrival).

**Req. 3.2.8-9** When a NAS flight plan is received that is a partial
match with a flight that has been created or modified by an airline
message, ATMS shall process the flight plan as if it is a diversion;
that is, ATMS shall:

a)  cancel the flight with the airline data

b)  create a new flight entry from the flight plan data

ATMS maintains a best estimated runway departure and arrival time for
each flight. These times are used for projecting traffic demands at an
airport and displaying those demands to the traffic management
specialist and airline user through FSM. These times will be maintained
according to the following requirement:

**Req. 3.2.8-10** ATMS shall maintain best estimated runway departure
and arrival times according to the following precedence (from high to
low)

a)  actual time from NAS

b)  latest runway times provided by airline

c)  time from latest EDCT file

d)  time modeled from latest airline gate times

e)  time modeled from latest NAS flight plan times

f)  time modeled from OAG gate times

In addition to departure and arrival times, ATMS models times at
intermediate points along a flight's route such as sector entry and exit
points. ATMS must resolve the airline-provided runway times with the
intermediate event times as stated in the following requirement:

**Req. 3.2.8-11** When ATMS uses airline provided runway departure and
arrival times, ATMS shall update the intermediate event times to
maintain temporal consistency with the runway times.

### EDCTs and Subs

Task 3 does not include any modifications to the substitution processing
that occurs after a GDP is issued, so the old rules and message formats
must still be followed. However, additional data -- assigned arrival
slot and slot class \-- is available in an FSM-generated GDP. ATMS will
maintain this data throughout the EDCT and SI processing.

**Req. 3.2.9-1** ATMS shall in general process EDCTs in the same manner
as ETMS.

**Req. 3.2.9-2** When processing an EDCT program, ATMS shall store
assigned arrival slot and slot class along with the other EDCT data.

**Req. 3.2.9-3** ATMS shall in general process SIs in the same manner as
ETMS.

**Req. 3.2.9-4** When processing an SI message, ATMS shall maintain
assigned arrival slot and slot class data so that when a flight is moved
into another flight's arrival slot, it assumes the assigned arrival slot
and slot class of the flight that previously owned the slot.

## Demand Data

The new flight data whose processing is described in section 3.2 must be
incorporated into outputs for the traffic management specialist and
airline user to view. The primary tool for viewing the data is FSM,
described in section 4. FSM gets its data by requesting ADL files from
ATMS. The ADL file is based on a new type of REQ report that
incorporates the new CDM data. The CDM data also affects other ATMS
outputs; that is, the data outputs that ETMS provides. The general
approach has been to:

-   Make no changes to existing output formats.

-   Use airline data to improve accuracy of data fields where possible.

-   Make all new CDM data available through a new report type.

The requirements for these outputs are specified below.

### Existing Outputs

As CDM Task 3 is a prototype, it will not include any changes to the
existing ETMS outputs except as the data accuracy can be improved
through the processing described in section 3.2.

**Req. 3.3.1-1** ATMS shall maintain all existing ETMS data output
formats.

**Req. 3.3.1-2** ATMS shall use CDM data to update data values in
existing ETMS data output formats as indicated by the data processing
requirements specified in section 3.2.

### CDM Report

ATMS shall provide a new report type similar to the current REQ LIST
report that makes new data fields particular to CDM available to the
user. The detailed formatting of the report and report requests are
described in a separate document *ADL Data Format.*

**Req. 3.3.2-1** ATMS shall provide a new report type for CDM data (REQ
CDM).

**Req. 3.3.2-2** In a CDM report, ATMS shall display all flight times as
6-digits containing two digits each for date, hour, and minute.

**Req. 3.3.2-3** In a CDM report, ATMS shall include cancelled flights
and an indication of why they were cancelled.

**Req. 3.3.2-4** In a CDM report, ATMS shall provide the current ETMS
report data fields.

**Req. 3.3.2-5** In a CDM report, ATMS shall provide new fields for the
new data elements provided by the airline flight data messages.

**Req. 3.3.2-6** In a CDM report, ATMS shall provide new fields for the
new data elements provided by an FSM-generated GDP.

**Req. 3.3.2-7** In a CDM report, ATMS shall indicate when an ETD or ETA
is a value provided by the airline.

**Req. 3.3.2-8** In a CDM report, ATMS shall make available the
estimated runway departure and arrival time from when the flight was
first created in the database.

### ADL Distribution

To support operational use of FSM, ATMS must provide a capability of
distributing a fixed format CDM report to all user sites that are using
FSM to monitor a particular airport. The reports must be synchronized so
that various users who are collaborating in a decision-making process
are looking at the same data at the same time. Furthermore, the data
must be filtered in a manner so that airlines do not see sensitive
information from their competitors, yet the full functionality of FSM is
still supported. This section defines the requirements for the ADL
distribution.

The detailed format of the ADL report file is described in the document
*ADL Data Format.* The messages for ADL data registry and retrieval are
defined in the document *CDM Message Formats.*

**Req. 3.3.3-1** ATMS shall allow any authorized user to register for
ADL data for a given airport.

**Req. 3.3.3-2** ATMS shall distribute fixed format ADL files to all
registered users at a fixed time interval.

**Req. 3.3.3-3** ATMS shall ensure that ADL files sent to all users
contain the same data except as restricted by requirement 3.3.3-4

**Req. 3.3.3-4** ATMS shall filter ADL files sent to airline so that an
airline can see call signs only for its own flights or for flights
belonging to an associated sub-carrier.

**Req. 3.3.3-5** When filtering call signs (requirement 3.3.3-4), ATMS
shall replace unauthorized call signs with dummy call signs in a manner
that ensures that all airlines will get the same results when running
the FSM compression and substitution algorithms.

# FSM Requirements

## Background

When significant arrival delays are predicted at an airport, generally
due to a reduction in the airport acceptance rate, a traffic management
specialist may run a ground delay program for that airport. Currently,
when a specialist decides to run a ground delay program at an airport,
he or she prepares a list of flights that ETMS predicts to arrive at
that airport during the time interval when the ground delay program is
to be in effect. That list of flights is then passed to the Groverjack
program, which then assigns those flights to the available landing
slots.

The functions of producing the flight list and assigning flights to
slots will be taken over by the Flight Schedule Monitor (FSM). Assigning
flights to slots, which is performed in a single step by Groverjack,
shall be performed in two steps by FSM. First, ration by schedule is
used to determine which slots are assigned to each airline. Second, the
slots belonging to each airline are filled with that airline's flights.

## Preparing the List of Flights for Rationing by Schedule

Preparing the list of flights that serve as input to the rationing by
schedule algorithm has several complications. Flights that were
originally scheduled to be in the program time interval may now be
expected to arrive before or after the program, or these flights may
have been canceled. Flights originally scheduled to arrive before the
program may now be arriving in the program. Also, flights that were not
scheduled at any time may now be expected to arrive during the program.
These complications must be dealt with so that slots are assigned
without penalizing airlines submitting accurate information on delays
and cancellations.

The following definitions are needed.

Definition: A flight is a *scheduled flight* if it

a)  was in the most recent update of the OAG airline schedule database
    or

b)  was created by a create message submitted by an airline.

Any other flight is an *unscheduled flight*.

Definition: A flight is a *Class I* flight if it

a)  was in the most recent update of the OAG airline schedule database
    or

b)  was created by a create message submitted by an airline at least
    forty--eight hours before its originally scheduled runway departure
    time.

Any other flight is a *Class II* flight.

Definition: The *original scheduled arrival time* for a scheduled flight
is the runway arrival time that the flight had when it first entered the
ATMS Flight Database. (If a runway arrival time is not provided, ATMS
will estimate the runway arrival time from the gate arrival time
provided in the OAG or the create message.)

Definition: The *original predicted arrival time* for an unscheduled
flight is the runway arrival time derived from the NAS flight plan when
the flight was first created in the ATMS Flight Database. (ATMS will
estimate the original runway time from the original gate arrival time
provided in the NAS flight plan.)

Definition: The *current predicted arrival time* for a flight is the
most recent runway arrival time that the ATMS Flight Database shows.
(This arrival time is provided by, or modeled on the basis of, a create
message, modify message, NAS flight plan, or NAS flight plan amendment.)

When a specialist wants to compute a ground delay program at an airport
for an interval of time, FSM must give the specialist the capability to
produce the list of flights that will be used by the ration by schedule
algorithm. The following requirements specify which flights will be
included in this flight list.

**Req. 4.2-1** FSM shall provide the specialist with a command that,
when executed, prepares a list of flights to be used by the ration by
schedule algorithm.

**Req. 4.2-2** The ration by schedule flight list shall include the
following categories of flights:

a)  scheduled flights that have an original scheduled arrival time in
    the program time interval and that are currently predicted to arrive
    during or after the program time interval

b)  scheduled flights that have an original scheduled arrival time in
    the program time interval and that have been cancelled

c)  scheduled flights that have an original scheduled arrival time
    before the program time interval and that have a current predicted
    arrival time in the program time interval

d)  unscheduled flights with a current predicted arrival time during the
    program time interval

**Req. 4.2-3** The ration by schedule flight list shall **not** include
the following categories of flights:

a)  flights that have an original scheduled arrival time during the
    program time interval and that have a current predicted arrival time
    before the program time interval

b)  flights that have neither an original scheduled arrival time during
    the program time interval nor a current predicted arrival time
    during the program time interval

**Req. 4.2-4** FSM shall sort the flights in the ration by schedule
flight list in ascending order by arrival time; if two flights have the
same arrival time, then they shall be ordered randomly. The arrival
times used for these flights shall be:

a)  original scheduled arrival times for all scheduled flights and

b)  original predicted arrival times for all unscheduled flights

## Assigning Slots to Airlines

Once the list of flights described above has been prepared, the next
step is to apply the ration by schedule algorithm to that list to
produce the list of EDCTs. After slots are assigned to exempt flights, a
first--come, first--served algorithm is used to assign the remaining
flights to the remaining slots. All flights on the list that are not
assigned a slot are pushed into the time after the interval ends. If
there is no flight available for a slot, then that slot goes unassigned.
This leads to the following requirements.

**Req. 4.3-1** FSM shall, after assigning slots to exempt flights,
assign arrival slots to flights in the order they appear in the flight
list produced according to requirements 3.39. to 3.40. The result is a
list of slots; for each slot is shown the airline that owns that slot.
If a slot could not be assigned to an airline, this list shows that the
slot is open.

**Req. 4.3-2** The algorithm that FSM uses to assign EDCTs to flights
shall be equivalent to the Groverjack algorithm.

While this algorithm assigns flights to slots, this is only a tentative
assignment; the real significance of this algorithm is not that it
assigns flights to slots but rather than it assigns slots to airlines.
That is, the real output of this algorithm is a list that shows the
slots and the airline to which each slot is assigned.

It should be noted that, in assigning slots to airlines, FSM treats
flights in the OAG and flights that are created by airlines exactly the
same, even if flights are created by an airline at the last minute. It
is in the process of substitution that flights created at the last
minute are treated differently; it is at this time that the distinction
between Class I and Class II flights is used.

### Assigning Flights to Slots

Once the list of slots that are assigned to each airline has been drawn
up, the next step is to assign flights to these slots. There are at
least three methods that can be used to do this.

-   The *scheduled flight method* assigns scheduled flights to slots.

-   The *actual flight method* takes into account cancellations and
    delays in assigning flights to slots but does not transfer slots
    among airlines.

-   The *actual flight method plus compression* is the same as the
    actual flight method except that it determines which slots cannot be
    used and attempts to fill them.

The advantage of the scheduled flight method is that it does not
interfere with the assignment of flights to slots that is produced in
the previous step; this is the tentative assignment of flights to slots
referred to above. The disadvantage of this method is that it can result
in an unrealistic ground delay program since it might assign a slot to a
canceled flight or to a flight that has been delayed and cannot fill
that slot. The actual flight method avoids this disadvantage and perhaps
decreases the amount of substitution that airlines will do, but by doing
so it must move flights from their originally assigned slots; this
method does not change the slots that are assigned to each airline, but
it does change the flights that are assigned to the slots. The actual
flight plus compression has the advantage of potentially making a more
efficient use of slots; it has the disadvantage of reducing the control
that an airline has over the slots that are originally assigned to it.

During the experimental phase the FAA and airlines might want to
experiment with all three ways of assigning flights to slots, so the
software needs to be able to support all three methods.

The actual flight method and the actual flight method plus compression
both use the assumption that during a ground delay program an airline
wants a flight to be moved earlier in time as long as two conditions
hold.

-   The earlier time does not violate the minimum notice requirement.
    That each, each airline specifies that it wants to receive a
    departure time at least *n* minutes before that departure time. For
    example, an airline might require that it receive a departure time
    at least 30 minutes before that time so that it has time to prepare
    the flight for take--off.

-   The earlier time is not before the earliest runway departure time or
    the earliest runway arrival time specified by the airline. By
    default, the earliest allowed times are the scheduled (or proposed)
    times since an airline normally would not want a flight moved up
    earlier than its scheduled time. If desired, an airline can change
    these times. For example, if an aircraft has a mechanical problem,
    the earliest time that it can depart might be moved back.

It is required that FSM allow an airline to change these times.

**Req. 4.3.1-1** FSM shall allow each airline to specify the minimum
notice that the airline shall receive for an EDCT. This minimum notice
is the same for all flights at all airports.

**Req. 4.3.1-2** FSM shall allow an airline to specify for each flight
the earliest runway departure time and the earliest runway arrival time.

After slots have been assigned to each airline, the actual flight method
uses the following algorithm to assign flights to each airline's slots.

-   FSM shall draw up a list of slots assigned to that airline. These
    slots shall be ordered in ascending chronological order.

-   FSM shall draw up a list of the flights of that airline that are
    currently predicted to arrive at the controlled airport.

-   FSM shall start with the first slot assigned to that airline. It
    will assign the first flight on the list of flights to that slot
    unless this results in a violation of the minimum notice time, the
    earliest runway departure time, or the earliest runway arrival time.
    Proceeding in this way, each slot shall be filled with the earliest
    flight on the flight list that has not yet been assigned to a slot
    and that does not violate the minimum notice time and the earliest
    departure and arrival times.

-   If no flight can be assigned to a slot, that slot shall be
    designated as an open slot that belongs to that airline.

The algorithm used by the actual flight method plus compression will be
spelled out elsewhere.

The following requirements govern how FSM shall assign flights to slots.

**Req. 4.3.1-3** FSM shall give the traffic management specialist the
option of assigning flights to slots by using the scheduled flight
method, the actual flight method, or the actual flight method plus
compression.

## Issuing a Ground Delay Program

Once the ground delay program has been defined, it must be sent to each
airline.

**Req. 4.4-1** Once FSM has completed the process of assigning flights
to slots, it shall prepare for each airline a report that shows the
following data on each flight that is in the ground delay program

a)  Call sign

b)  Departure airport

c)  Scheduled or proposed departure time

d)  EDCT

e)  Controlled time of arrival

f)  Assigned arrival slot

g)  Slot class

Once these EDCTs have been calculated, no further changes are needed to
the software. That is, the subsequent processing shall be performed by
existing ATMS software. The following are among the events that might
happen.

-   The traffic management specialist will use Autosend to issue the
    EDCTs, i.e., to send to the airlines the report prepared under
    requirement 3.48.

-   The airlines submit substitution messages to reorder their flights.

-   EDCTs are sent to towers.

## Revising a Ground Delay Program

It is sometimes necessary for the traffic management specialist to
revise a ground delay program by changing the length of the program or
changing the acceptance rate for all or part of the program. If a
program is revised, then the procedure described above that assigns
slots to airlines is followed. The algorithm for assigning flights to
slots will be documented elsewhere.