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

**John A. Volpe National**

**Transportation Systems Center**

**Automation Applications Division**

**U. S. Department**

**of Transportation**

**Memorandum**

**Research and**

**Special Programs**

**Administration**

**Date:** April 9, 1996 Reply to Attn. of: DTS‑56

**Subject:** Version 1.1 of the System Requirements for Task 3 of the
Collaborative Decision‑Making Program

**From:** Ken Howard (617) 494‑2697 and Rick Oiesen (617) 494‑2309/Volpe
Center

**To**: CDM Workgroup

Attached is Version 1.1 of the System Requirements Document for Task 3
of the Collaborative Decision‑Making Program. Version 1.1 contains
mostly minor corrections and clarifications. The changes are indicated
by \"rev bars\" in the left margin.

The only change of significance is the re‑statement of Requirements 3.14
through 3.16 so that a create message will always be rejected if the
flight already exists in the ATMS Flight Database.

**SYSTEM REQUIREMENTS DOCUMENT FOR TASK 3**

**OF THE COLLABORATIVE DECISION‑MAKING PROGRAM**

**Version 1.1**

**(9 April 1996)**

***Overview***

This document describes the system requirements for Task 3 of the ATMS
Collaborative Decision­Making Program. Task 3 consists of modifying the
ATMS software so that it will perform two new func­tions.

> • ATMS will accept messages from the airlines that contain updated
> information on the cre­ation, modification, and cancellation of
> flights.
>
> • ATMS will ration (i.e., assign arrival slots during ground delay
> programs) by OAG sched­ule.

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.

> • ATMS 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 can­cellations to the FAA.
>
> • The order of flights in the OAG schedule will be preserved during
> ground delay programs.
>
> Other tasks in the Collaborative Decision‑Making Program will be
> described in separate system re­quirements documents. These tasks
> include:
>
> • incorporating airline operational schedules
>
> • improving (simplifying) the substitution process
>
> • slot transfer between airlines (compression)
>
> • control by time of arrival

***Requirements Concerning Creations, Modifications, and Cancellations
of Flights***

**Background**

The main function of ATMS is to provide traffic management specialists
with the best possible predic­tion 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. The goal of
this work item is to fill this gap with data updates from airlines
notifying ATMS of changes in their flight schedules whenever they occur.

**Definitions**

For the purposes of these requirements, the following terms are used in
a very specific manner.

> • The term \"flight\" refers to a single occurrence of a single leg of
> a flight (e.g., United flight 123 from BOS to ORD on January 30th,
> 1996).
>
> • The term \"flight data messages\" refers to the airline messages
> that create, modify, or can­cel flights.

**Communications Link**

A communications link is required to get the airline flight data
messages to ATMS. The link must allow keeping the airline data separate
from the operational system until such a time that the airlines and the
FAA have agreed to make the airline data operational. ARINC will be used
initially for this pur­pose until a better alternative can be
implemented.

> Req. 3.1. ARINC shall be used to communicate the airline flight data
> messages to ATMS.
>
> Req. 3.2. A separate ARINC address shall be dedicated to the airline
> flight data messages.
>
> Req. 3.3. Messages received at this dedicated ARINC address shall go
> only to the non‑op­erational ATMS string on which the CDM software is
> being tested and not to an operational ETMS string.

**Message Handling**

Every time ATMS receives a message from the airlines, it will
acknowledge the receipt and processing of that message. This leads to
several requirements.

> Req. 3.4. ATMS shall positively acknowledge every message that is
> received.
>
> Req. 3.5. ATMS shall indicate whether a message was processed
> successfully or not.
>
> Req. 3.6. ATMS shall send an explanatory error message whenever a
> message is not pro­cessed successfully.
>
> Req. 3.7. ATMS shall send an acknowledgment or error message within
> one minute of receiving a message.
>
> NOTE: The format of the acknowledgment and error messages will be
> determined dur­ing the design phase.

**Message Content and Format**

ATMS will accept three types of flight data messages.

> • Creation message: Either creates a new flight or reinstates a flight
> that had previously been canceled.
>
> • Modify message: Changes previously defined data for a flight.
>
> • Cancellation message: Cancels a flight.

Requirements for the content of these messages will now be stated.

> **NOTE:** The formats of the flight data messages will be specified in
> detail during the software requirements phase.

Req. 3.8.A flight creation message shall contain

> a\. flight ID
>
> b\. departure date
>
> c\. departure airport
>
> d\. arrival airport
>
> e\. gate departure time
>
> f\. runway departure time
>
> g\. arrival date
>
> h\. arrival airport
>
> i\. gate arrival time
>
> j\. runway arrival time
>
> k\. aircraft type

Req. 3.9. A modify message shall contain

> a\. flight ID
>
> b\. departure date
>
> c\. departure airport
>
> d\. arrival airport
>
> e\. modified flight data (can be multiple fields)
>
> f\. continuation flag (optional)

Req. 3.10. A cancellation message shall contain

> a\. flight ID
>
> b\. departure date
>
> c\. departure airport
>
> d\. arrival airport
>
> e\. continuation flag (optional)

Some important notes about the contents of the messages specified in
requirements 3.8. to 3.10.:

> • All dates and times are in Universal Time Coordinates (formerly
> GMT).
>
> • The flight ID, departure date, origin airport, and destination
> airport are used to uniquely identify a flight.
>
> • Departure date refers to the date on which the flight was first
> scheduled to depart.
>
> • Either gate times or runway times must be provided for flight create
> messages. Both should be provided if available.
>
> • The modify message allows any flight data fields to be modified
> except as restricted by the substitution rules.
>
> The optional continuation flag in the modify and cancellation messages
> is to allow an assigned (con­trolled) arrival slot to be transferred
> from one flight to another, for example, in the case of a fuel stop.
> The modify message must be followed immediately by a create message
> for the continuing flight that will assume the original flight\'s
> arrival slot. This will be allowed only in the case where the
> destination airport of the original flight is modified.
>
> Additional data fields and message types will be specified in the
> future; however, they are not required to complete CDM Task 3.

**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, 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.

> Req. 3.11 ATMS shall accept flight messages up to one year before the
> flight is scheduled to depart.

ATMS receives flight messages from the NAS as well as from the airlines.
To ensure that the ATMS database is consistent with NAS, ATMS must apply
certain constraints. These constraints essentially enforce the policy
that once a flight plan is filed in the NAS, the airline has the
responsibility to keep the NAS completely informed of its intentions.

> Req. 3.12. ATMS shall reject any airline cancellation message that it
> receives after NAS flight plan has been received.
>
> Req. 3.13. ATMS shall not allow an airline, through a modification
> message, to change a field that has been received in a NAS flight
> plan. The fields that might conflict between the NAS flight plan and
> the airline flight data messages are: departure airport, arrival
> airport, and aircraft type.
>
> NOTE: Flight data messages and NAS flight plans both contain departure
> and arrival times. ATMS considers these different types of times, and
> saves them sep­arately in the database. Therefore, ATMS expects---and
> will accept---revised departure and arrival time estimates in
> modification messages even after the NAS flight plan has been
> received.

**Message Processing**

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

> • Creation message: insert that flight into the Flight Database.
>
> • Modify message: change the flight data in the Flight Database;
>
> • Cancellation message: mark that flight in the Flight Database as
> canceled;

There are, however, a number of unusual or pathological situations that
might arise when normal pro­cessing is inappropriate. For example, ATMS
might receive a cancellation message for a flight, and then twenty
minutes later it might receive a modify message for that flight.
Logically, this sequence of messages should not happen, but in reality
sequences like this do occur, and ATMS must deal with these pathological
sequences in a sensible manner that is acceptable to all parties.

*Creation Messages*

The next set of requirements spells out how creation messages should be
dealt with. The next three requirements ensure the logical consistency
of the ATMS database.

> Req. 3.14. ATMS shall reject a creation message for any flight that
> already exists in the Flight Database unless that flight has been
> canceled by the airline.
>
> Req. 3.15. ~~ATMS shall reject a creation message for a flight that
> already exists in the Flight Database due to a NAS flight plan or
> other NAS message~~.
>
> Req. 3.16. ~~ATMS shall issue a warning if a creation message *is*
> received for a flight that al ready exists in the Flight Database due
> to GAG data, but will use the data from the creation message to update
> the Flight Database~~.

This leaves us with the conditions that a creation message must meet if
it is to be processed.

> Req. 3.17. If a creation message is received for a flight that
>
> a\. is not in the Flight Database, or
>
> b\. exists in the Flight Database but has been canceled by the airline
>
> then ATMS shall update the Flight Database to reflect this message.

*Modify Messages*

The following requirements specify how modify messages will be
processed. The first two require­ments ensure the logical consistency of
the ATMS database.

> Req. 3.18. ATMS shall reject any modify message for a flight that is
> not in the Flight Data­base.
>
> Req. 3.19. ATMS shall reject any modify message for a flight that is
> in the Flight Database but which has been canceled.

If a modify message is received that modifies the departure time for a
flight that has received an EDCT, then ATMS will reject this message
since the proper way to modify such a flight is with an SI message
(NOTE: this is only true until changes in the substitution rules are
implemented in CDM Task 5).

> Req. 3.20. ATMS shall reject any modify message that changes the
> controlled departure time, controlled arrival time, or assigned
> arrival slot for a flight that has received an EDCT.

To keep the ATMS Flight Database accurate, the airlines should send time
changes frequently. How­ever, too many updates could overload the ATMS
processing. The next two requirements address this compromise. Note that
the time in the ATMS Flight Database that is being used as a reference
is either the time from the OAG, or the time previously sent by the
airline.

> Req. 3.21. Airlines shall send a new departure or arrival time
> whenever a that time has a cumulative change of more than fifteen
> minutes from the previous time sent to the ATMS database.
>
> Req. 3.22. Airlines shall not send a new departure or arrival time
> unless the time has a cumulative change of more than fifteen minutes
> from the time previously sent to the ATMS database.

Of course, the ATMS database must also be accurate with respect to
flight data other than times.

Req. 3.23. Airlines shall notify ATMS through a modify message of any
change in departure airport, arrival airport, or aircraft type for any
flight already in the ATMS data­base.

> **NOTE**: ATMS will only accept a modify message if a flight plan has
> not yet been received for the flight. A NAS amendment should be used
> to change these fields for flights with flight plans.

This leaves us with the conditions that a modify message must meet if it
is to be processed normally.

> Req. 3.24. If a modify message is received for a flight that
>
> a\. is in the Flight Database,
>
> b\. has not been canceled,
>
> c\. has not yet landed,
>
> d\. has not received an EDCT (departure time field only), and
>
> e\. changes an airline‑provided departure or arrival time by at least
> a cumu­lative fifteen minutes or changes the departure airport, arrival
> airport, or aircraft type

then ATMS shall update the Flight Database to reflect this message.

The next question is what record ATMS will keep of the changes that are
made to the departure time.

> Req. 3.25. ATMS shall keep the originally scheduled OAG departure and
> arrival times and the most current departure and arrival times
> provided by the airlines, but shall not keep any record of
> intermediate times that were provided by the airlines but later
> superseded by the airline.

*Cancellation Messages*

The next set of requirements spells out how cancellation messages should
be dealt with. The first three requirements ensure the logical
consistency of the ATMS database.

> Req. 3.26. ATMS shall reject a cancellation message for a flight that
> is not in the Flight Da­tabase.
>
> Req. 3.27. ATMS shall reject a cancellation message for a flight that
> is in the Flight Data­base but has already been canceled.
>
> Req. 3.28. ATMS shall reject a cancellation message for a flight that
> is in the Flight Data­base but has already departed.

If a cancellation message is received for a flight that has received an
EDCT, then ATMS will reject this message since the proper way to cancel
such a flight is with an SI message (NOTE: this is only true until
changes in the substitution rules are implemented in CDM Task 5).

> Req. 3.29. ATMS shall reject a cancellation message for a flight that
> has received an EDCT. To keep the ATMS database accurate, the airlines
> must send in all cancellation data.
>
> Req. 3.30. The airlines shall send a cancellation message to ATMS for
> every flight that is canceled.

This leaves us with the conditions that a cancellation message must meet
if it is to be processed.

> Req. 3.31. If a cancellation message is received for a flight that
>
> a\. is in the Flight Database,
>
> b\. has not been canceled,
>
> c\. has not yet departed,
>
> d\. has not received an EDCT, and
>
> e\. has not received a NAS flight plan then ATMS shall update the
> Flight Database to reflect this message.

*NAS Messages*

Possible conflicts arise because NAS messages will contradict the data
received directly from the air­lines. It is important that the ATMS
databases be kept consistent with the ATC system. Therefore, in most
cases the NAS message will override the flight data messages. The
exception is the handling of predicted arrival and departure times.

The following requirements assure consistency between the ATMS and NAS
databases in all respects except for times.

> Req. 3.32. If a NAS flight plan is received for a flight that has been
> created by an airline message, ATMS will use the data in the flight
> plan to update the Flight Database.
>
> Req. 3.33. If a NAS flight plan is received for a flight that has been
> canceled by an airline message, ATMS will reinstate the flight and use
> the data in the flight plan to up­date the Flight Database.
>
> Req. 3.34. If a NAS cancellation is received for a flight that has
> been created by an airline message, ATMS will cancel the flight in the
> Flight Database.

The times received from the airlines will be stored in the Flight
Database separately from the times received from NAS. However, there is
an issue regarding which times to show in the Flight Schedule Monitor
(FSM). The premise of this experiment is that the airline times are
better for judging the true demand. The following requirement states how
the times will be processed for FSM.

Req. 3.35. When ATMS receives a request for flight data from FSM, it
shall take one of the following actions:

> a\. If no modify or creation messages have been received for the
> flight, then ATMS shall use the times from NAS.
>
> b\. If any modify or creation messages have been received for this
> flight, then ATMS shall use the latest times from the modify and/or
> creation messages rather than the NAS times.

**New Information for the Specialist**

> Req. 3.36. ATMS will provide information on flight cancellations to
> the traffic management specialist via the FSM tool.

**Summary**

It is expected that airlines will send modify, cancel, and create
messages to ATMS via the dedicated ARINC address. Any of these messages
that satisfy the formatting and consistency requirements will be entered
into the Flight Database, and this information will be used by ATMS in
its flight modeling. ATMS will provide this updated information to the
traffic management specialists, and no special ac­tions are required from
them or from the FAA once the new ATMS software is in place.

***Requirements Concerning Rationing by OAG Schedule***

**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), and
this function of assigning flights to slots will be called the
Groverjack/FSM functionality.

**Preparing the list of Flights for a Ground Delay Program**

Preparing the list of flights under rationing by schedule 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. Flights originally scheduled to arrive before the program may
now be arriving in the pro­gram. Also, flights that were not scheduled at
any time may now be expected to arrive during the program. These
complications must be resolved in a manner such that every flight that
needs a slot gets a slot, and airlines are not penalized for submitting
accurate information on delays and cancellations.

The following requirements specify which flights will be included in the
flight list that is submitted to Groverjack/FSM.

> Req. 3.37. When a ground delay program is to be run at an airport for
> an interval of time, a list of flights shall be prepared and sent to
> Groverjack/FSM.
>
> Req. 3.38. The Groverjack/FSM flight list shall include the following
> categories of flights:
>
> a\. flights that were originally scheduled to arrive in the program
> time inter­val and that are currently predicted to arrive during or
> after the program time interval
>
> b\. flights that were originally scheduled to arrive in the program
> time inter­val and that have been canceled
>
> c\. flights that were originally scheduled to arrive before the
> program time interval and that are currently predicted to arrive in
> the program time interval
>
> d\. unscheduled flights that are now predicted to arrive during the
> program time interval
>
> Req. 3.39. The Groverjack/FSM flight list shall not include the
> following categories of flights:
>
> a\. flights that were originally scheduled to arrive in the program
> time inter­val and that are currently predicted to arrive before the
> program time interval
>
> b\. flights that were neither originally scheduled to arrive during
> the pro­gram time interval nor that are currently predicted to arrive
> during the program time interval
>
> Req. 3.40. The flights in the Groverjack/FSM flight list shall be
> sorted in ascending order by arrival time; if two flights have the
> same arrival time, then they shall ordered arbitrarily. 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

Requirements 3.38. through 3.40. require certain definitions, which are
important because ATMS must maintain certain data to apply the
definitions. These definitions are stated in the following requirements.

> Req. 3.41. Scheduled flights shall be determined through a policy as
> determined by the FAA and the airlines. The policy shall be based on
> one or more of the following criteria:
>
> a\. whether a flight was in the most recent update of the OAG airline
> schedule database
>
> b\. when the flight was first created through an airline creation
> message

NOTE: The current policy is that a flight will be considered to be a
scheduled flight if it is either in the OAG database or is created at
least 48 hours prior to the departure time.

> Req. 3.42 The original scheduled arrival time for a flight shall be
> defined as the runway ar­rival time provided by the OAG or airline when
> a scheduled flight was first created in the ATMS database. If a runway
> arrival time is not provided, ATMS will estimate the original runway
> time from the original gate arrival time.
>
> Req. 3.43. Unscheduled flights shall be any flight not categorized as
> a scheduled flight.
>
> Req. 3.44. The original predicted arrival time for an unscheduled
> flight shall be defined as the runway arrival time provided in the
> flight creation message or NAS flight plan when the flight was first
> created in the ATMS database. If a runway arrival time is not
> provided, ATMS will estimate the original runway time from the
> original gate arrival time.
>
> Req. 3.45. The current predicted arrival time for a flight shall be
> the most recent arrival time provided by the airlines through a
> creation message, modify message, NAS flight plan, or NAS flight plan
> amendment.

**Calculating a ground delay program.**

Once the list of flights described in the previous requirement has been
prepared, the next step is to run that list through the Groverjack/FSM
functionality 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. 3.46. Groverjack/FSM shall assign arrival slots to flights in the
> order they appear in the flight list produced according to
> requirements 3.37. through 3.45.
>
> Req. 3.47. The algorithm that FSM uses to assign EDCTs to flights
> shall be equivalent to the Groverjack algorithm.

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.

• The airlines submit substitution messages to reorder their flights.

• EDCTs are sent to towers.

The question that remains is what happens if a ground delay program is
revised. Revisions will be car­ried out using the current method. That
is, a flight list will be produced using current predicted data in the
manner specified in the following requirements rather than as specified
in requirements 3.37. through 3.45.

> Req. 3.48. When a ground delay program is revised, the Groverjack/FSM
> flight list shall in­clude all flights and only those flights that are
> currently predicted to arrive during the program time interval.
>
> Req. 3.49. When a ground delay program is revised, the Groverjack/FSM
> flight list shall be sorted in ascending order by arrival time; if two
> flights have the same arrival time, then they shall ordered
> arbitrarily. The arrival times used for these flights shall be the
> original predicted arrival times (as defined in requirement 3.44.).

**Substitution Processing**

While changes to the substitution processing are not part of Task 3, it
is important that some of the requirements of substitution be considered
so that the required data will be available in the ATMS databases. This
section specifies these requirements.

In order to facilitate further improvements in substitution processing,
there should be an identifier assigned to each arrival slot in a
program, as stated in the following requirement.

> Req. 3.50. Groverjack/FSM shall assign a unique slot identifier to
> each flight in the pro­gram. The slot identifier shall consist of the
> name of the airline getting the slot and the date and time of the
> slot. The slot identifiers shall be stored in the ATMS databases.

The inclusion of non‑scheduled airline flights in the list opens up the
door for airlines to take advan­tage of the system by introducing
artificial flights, then canceling them once a ground delay program is
issued. Therefore, it may be necessary to restrict certain flights from
use in a cancellation and sub­stitution sequence. The restrictions will
be determined through policy agreed upon between the FAA and airlines.
The policy will be stated in terms of two categories of flights: Class I
and Class II. The need to distinguish Class I and Class II flights calls
for the following requirements.

> Req. 3.51. A flight meeting the following criteria shall be considered
> a Class I flight.
>
> a\. the flight is a scheduled flight (as defined in requirement 3.41.)
>
> b\. the flight\'s original scheduled arrival time (as defined in
> requirement 3.42.) falls into the program time interval
>
> c\. the flight is currently predicted to arrive during or after the
> program time interval (NOTE: Flights that are predicted to arrive
> before the pro­gram time interval will not be given a slot, making this
> part of the re­quirement somewhat moot.)
>
> Req. 3.52. All flights included in the program that are not Class I
> flights shall be considered Class II flights.

**Summary**

A ground delay program will be primarily based on the flights that were
originally scheduled to arrive during the program, most notably
including those flights that have been canceled or delayed. Excep­tions
are: unscheduled flights and flights delayed into the interval---which
will be included---and flights that are expected to arrive before the
program---which will not be included. Slots will be as­signed based on
the original times for those flights. Names will be assigned to slots to
facilitate future improvements in the substitution processing. Flights
will be categorized into two groups for possible future restrictions on
substitutions. Class I flights---those originally scheduled to arrive in
the pro­gram---are expected to have full rights. Class II flights---those
delayed into the program or created close to the program time---might be
subjected to restrictions such as no cancel/sub, and no exchang­ing
forward in time. For now, it is important only that the data support the
proper categorization of the flights.