**CDM Memorandum**

**Subject:** Minutes of the Daily Download Telcon, 27 April 1999

**To:** CDM Workgroup

**From:** Rick Oiesen

**Date:** 30 April 1999

A telcon on the daily download was held on 27 April 1999. Participating
were Tim Grovac and Forrest Terral (ATCSCC), Tom Stamps and Larry Rimmer
(DAL), Patrick Metcalf (FDX), Joanne Stone and Leslie Dempsey (TWA),
Miro Lehky (ATA), and Ken Howard, Len Kurzweil, and Rick Oiesen (Volpe).

# Introduction

Rick started by reminding everyone of the goals of the daily download.

-   To bring the schedule data in the CDM database in line with the
    schedule data in the air carrier databases.

-   To always have the OAG schedule data as a back-up in case there is a
    problem with the daily download.

-   To keep the process simple and reliable.

It is important to keep in mind that there are three types of
inaccuracies in the OAG data that the daily download can correct.

a)  There might be flights in the OAG that are not in the carrier's
    daily operational schedule.

b)  There might be flights in the daily operational schedule that are
    not in the OAG.

c)  Flights that are in both the OAG and the daily operational schedule
    might have different data, e.g., different departure and arrival
    times.

# The Old View of the Daily Download

Looking back to our vague thoughts of two years ago, Rick summarized the
traditional view of the daily download in the following way.

-   A carrier sends in their daily operational schedule in the middle of
    the night.

-   The carrier sends Volpe a message saying that its entire operational
    schedule has been sent.

-   Volpe removes from the CDM database any flights for which no message
    has been received.

A problem with this scheme lies in the need for Volpe to remove any
flights that were not in the daily download. If there is some kind of a
foul-up, then Volpe might remove good flights and seriously damage the
database. In the telcon of January 19 we discussed various ways to guard
against this problem, but it was clear that this would be somewhat
complicated. Since this complication arises because of the desire to
take care of the case where a flight is in the OAG but not in the air
carrier's daily operational schedule, we ended the discussion on January
29 wondering how frequently this occurs. That is, how often is it the
case that there is a flight for which there is only OAG data that gets
time-out cancelled?

# The New View of the Daily Download

On April 18 Rick exploded the memo, "The Daily Download and Time-out
Cancels," which contained data for the thirty-nine day period February
17 through 27 on time-out cancels of flights for which there was only
OAG data. This data showed that for most air carriers for most days,
there are very few time-out cancels for which there is only OAG data.
For ten of the twelve primary CDM participating air carriers, there was
roughly one OAG timeout cancel per thousand flights; the other two
carriers are working to improve their feeds. Again, TWA was the champ
with only one OAG time-out cancel during these thirty-nine days; we
halted the telcon to salute Joanne for the stunning accuracy of the TWA
data.

This data changed the thinking on the daily download. For most days for
most air carriers, there are few if any flights that are in the OAG but
not in the daily operational schedule. Therefore, time-out cancels of
these flights is an episodic problem rather than a continuing, serious
problem. The implication is that we should abandon the idea of a carrier
notifying Volpe when its daily download is complete and Volpe then
removing flights that were not in the daily download. That is, if Volpe
automatically removes flights, this is a big risk and a big
complication; it makes no sense to take this big risk and to suffer this
big complication to deal with what is usually a minor problem. There was
consensus on this proposition. (This new thinking about the daily
download will be tested in the coming weeks as FedEx improves its feed
by sending in a daily download and sending in cancels for flights in the
OAG that are not flying.)

In light of this, the group agreed that the following seems to be the
most sensible course for implementing the daily download.

1.  Each carrier sends in a CDM message for each flight. This ensures
    that every flight that is flying is in the CDM database and that it
    has the right data. This takes care of accuracy problems b) and c)
    above.

2.  A carrier will request from the CDM database the information on its
    flights. It will compare its database to the CDM database and will
    send CDM FX, FC, and FM messages to correct the CDM database. This
    takes care of accuracy problem a) above as well as other problems.

3.  Volpe will make daily data on time-out cancels available on its web
    site, the CDM DataGate, so that carriers and the Command Center can
    quickly and easily see problems with the OAG. It is better to keep
    problems out of the OAG than to allow them into the OAG and then fix
    them.

The idea of a carrier being able to request its data from the CDM
database so it could "re-sync" the two databases was thought by the
group to be a very useful capability with many useful applications in
addition to the daily download. Rick pointed out that a carrier could do
a re-sync every few hours to keep the two databases from drifting apart.
Joanne thought it would be very useful to re-sync, e.g., if things get
confused when there is a ground delay program. Ken pointed out that if
an air carrier data feed is down for a while, the re-sync capability
would provide an easy way for it to recover. Ken also pointed out that
once the re-sync capability is in place, it wouldn't be necessary for an
air carrier to first send in a message on every flight; it could just do
a re-sync.

In short, everyone liked the idea of having the re-sync capability. It
not only allows the air carriers to correct all the inaccuracies in the
CDM database, but it provides other advantages as well.

The group also agreed that Volpe should every day post data on the
time-out cancels for each carrier. Volpe will also post suitable
summaries; for example, at the end of each week it might, say, post the
flights that have been time-out cancelled for five or more times. This
will help the carriers and the Command Center to see problems in the OAG
and take steps to correct them.

# Needed Development

If the scheme above is adopted, it implies that the following
development work is needed.

1.  Some air carriers would need to modify their software so that they
    will send in a message on every flights. (Some air carriers,
    including AAL, AWE, SWA, and TWA already do this.) The thinking was
    that the carriers would do this as soon as possible since this would
    handle two of the three sources of inaccuracy.

2.  Volpe would need to be able to send a carrier data on its flights in
    the CDM database. We still need to work out the details such as
    whether a carrier should be able to request a particular time period
    or particular airports. Volpe would get started on specifying the
    re-sync request and the data that is returned; Volpe would start
    development once the requirements and specifications are complete.

3.  The air carriers would need to write software to request and process
    the data from the CDM database on its flights, i.e., to examine this
    data, compare it to the air carrier database, and send in CDM
    messages to correct the CDM database. Priorities will be set
    individually for each carrier. That is, there might be some carriers
    for which this should be a high priority because of OAG problems;
    there might be other carriers whose data is so good that this would
    be a low priority.

4.  Volpe would provide daily reports on time-out cancels on its web
    page so that air carriers and the Command Center can monitor them
    and spot trouble areas.

# Other Issues

Currently air carriers are allowed to send in CDM messages up to eleven
months in advance; Volpe stores these in the Future Flights Database. If
carriers start sending in the messages each day for every flight, then
the Future Flights Database would no longer be needed. It was decided
that the Future Flights Database should be sunsetted as soon as
possible. This means that the CDM database will need to be modified so
that it can hold flights for twenty-four hours into the future, which it
cannot now do.

It was decided that carriers should have the option of sending in their
daily download all at once or incrementally. Tim G. said that the
Command Center would be satisfied if all messages were in by 0800Z; this
would typically be soon enough for any ground delay programs that would
be issued that day. Therefore, a carrier would have a choice: (1) Send
in messages on all flights for a day by 0800Z or (2) send in the message
for each flight at least fifteen hours before it departs. (If the Future
Flights Database is to be eliminated, there would have to be requirement
that the message for a flight was not sent in more than, say,
twenty-four hours before departure.)

There was a small amount of discussion of the questions of whether slots
should be given to flights in the OAG or in the daily download, and
whether ration-by-schedule should use the time in the OAG or the daily
download. One would think if the daily download is more accurate, then
it should be used for everything. Ken, however, pointed out there are
counterexamples. For example, consider a real flight that is in the OAG
but that has been cancelled by the time the daily download is made; this
is an example of a flight that should get a slot even though it is not
in the daily download. These operational issues were tabled until the
technical issues are settled. Ken pointed out that issues like this go
way beyond the daily download.

# The Next Step

It was agreed that the scheme agreed to above will be presented to the
full CDM Workgroup at the meeting on May 5, and we will see what the
reaction is. The ideal is that the full group will bless this approach.
If that happens, then we will start writing the detailed requirements
and specs, and development will begin.