![](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

Subject: Airport Demand List (ADL) Data Format

To: CDM Workgroup

From: Ken Howard

Date: 2 September 1999

This document was last released on 5 Feb 1997. Many changes have
occurred since then that have been documented separately. Some changes
were not documented at all. This version brings the document up-to-date
to the ADL format as it exists today. This document supercedes the
previous documents:

-   *ADL Data Format* dated 5 February 1997

-   *ADL Format Changes* dated 30 June 1998

# Introduction

The ADL is the data product that drives FSM and the CDM Ground Delay
Program Enhancements prototype operations. The ADL is primarily composed
of data extracted from the CDM hub site databases, which are maintained
with a combination of OAG data, airline-provided flight data messages,
NAS messages generated from the ATC system, and issued ground delays
(EDCTs). The ADL also includes GDP-specific data entered by the traffic
management specialist using FSM. The purpose of this memo is to describe
the contents of the ADL file in detail.

-   Part 1: Provides a general description of the ADL.

-   Part 2: Describes the data blocks provided in the ADL.

-   Part 3: Describes the data fields provided in the ADL flight data
    records.

# Part 1 -- General Description

## Contents

An ADL file contains all data pertinent to running a ground delay
program for arrivals at an airport. A particular ADL contains data for
only one airport. The data provided includes:

-   The airport acceptance rate (required)

-   The arrival fixes (required)

-   The parameters defining a proposed or actual ground delay programs
    (optional)

-   The status of the "EDCT SUB" flag (optional)

-   A list of all arrivals from one hour in the past to twenty hours in
    the future (required)

-   For each arrival, a record containing virtually every field in the
    ETMS database, except for route-of-flight related fields.

## File Naming

ETMS uses a file naming convention that facilitates users who are trying
to find particular files in a directory full of data files. The file
naming for the ADL files follows this convention for two reasons:

-   it has proven to be useful to FAA users

-   it allows the ADL files to be co-mingled with ETMS data files in a
    logical manner

A file name consists of four parts separated by periods (.):

-   the location identifier for which the data was generated; five
    characters with trailing blanks filled with underscores (\_);

-   the report type; four characters; for ADL files, type is "lcdm"

-   the date and time the file was requested; 8 digits; ddhhmmss

-   sequence number, used to distinguish two identical files requested
    in the same second; 2 digits; 01, 02, etc.

All letters in a file name are lower case.

For example, an ADL report generated for Boston on February 6 at
15:35:33 Z would be named:

bos\_\_.lcdm.06153533.01

## Organization

An ADL file consists of two main parts: the header and the data update.
The header consists of five fixed-format lines required by FSM,
interspersed by some comment lines containing useful information for
reading the report. The data update section consists of multiple blocks
of data delimited by keywords. Each data block starts with a keyword
"START_xxx" where "xxx" is a mnemonic indicating the data type. Each
data block ends with a corresponding "END_xxx" keyword. The entire data
update section is delimited by its own keywords: "START_UDPATE" and
"END_UPDATE".

The use of the "START" and "END" keywords is designed to make is easier
to keep backwards compatibility when new data is added to the file. When
a software program encounters a "START" keyword, it should check to see
if the keyword is one that the program recognizes. If not, the program
should discard lines until it reaches the corresponding "END" keyword.

## General Formatting

The ADL files are formatted to enhance the readability of the files. The
general characteristics of the formatting follow.

-   An ADL contains ASCII records terminated by NEWLINE characters.

-   Comment lines are used to provide helpful information or to separate
    blocks of text. A comment line contains a "#" character in column 1.

-   FSM Header lines contain a ":" character in column 1.

-   "START_xxx" and "END_xxx" keywords appear on separate lines starting
    in column 1.

-   Lines within a data block are indented by one column; that is, a
    space character appears in column 1.

-   There can be no blank lines within a data block.

-   Within the flight records:

```{=html}
<!-- -->
```
-   fields are fixed-width (column-aligned)

-   a blank field is indicated by "-" in the first column of the field.

-   the value of a true/false field is shown as "Y" (true) or "-"
    (false)

# Part 2 -- ADL Data Blocks

## Header 

The header of an ADL file consists of five lines required by FSM
interspersed with comment lines. Required lines are indicated by a colon
(:) in column 1. Comment lines are indicated by a pound sign (#) in
column 1. The required lines must be in the order listed below; the
comment lines can appear anywhere. In many cases, blank comment lines
are used just to improve the readability of the file.

The five required lines are defined as follows. (NOTE: The line numbers
ignore any interspersed comment lines.)

-   Required line 1 --":Product Code:" followed by the FSM product code.

-   Required line 2 -- ":Magic Number:" followed by the FSM magic number

-   Required line 3 -- ":Version Num:" followed by the ADL version
    number

-   Required line 4 -- ":Date:" followed by the date the ADL was
    generated

-   Required line 5 -- ":First Update:" followed by the day/time of the
    start of the flight records

The comment lines currently included are as follows. (NOTE: The list
does not include blank comment lines.) The comment lines are not
required and should not be expected by any programs that read the ADL
files.

-   Comment 1 -- the internal ETMS data request used to generate the ADL

-   Comment 2 -- the word "ARRIVALS" (this precedes the arrival flight
    list)

-   Comment 3 -- the word "DEPARTURES" (this precedes the arrival flight
    list)

-   Comment 4 --the flight record column headers, column-aligned with
    the flight record data fields (this precedes a list of either
    arrivals or departures)

A sample header follows:

:Product Code: 0xfaa

:Magic Number: 0xfaa1

:Version Num: 0x2

\#

\# HUBSITE CDM A LAX -1 +20 EVERY 1500 LIST ACID DEST ACENTR AFIX ORIG
DCENTR TYPE AC_CAT CLASS ETD \...

\#

:Date: 08/16/1999

:First Update: 160103

\#

\# ARRIVALS

#ACID DEST ACENTR AFIX ORIG DCENTR TYPE CTG CLS ETD ETA ARTD ARTA \...

\#

## Data Update (required)

The remainder of the file is the data update. It starts with a single
line containing the day-hour-minute of the update, as follows:

START_UPDATE ddhhmm

The data update is terminated by a single line that also includes the
update time, as follows:

END_UPDATE ddhhmm

The data update is itself composed of many data blocks, described in the
following sub-sections.

## AAR (required)

The AAR block will always contain at least one line showing the default
values. It may contain an additional line showing values that a
specialist has entered, either through an AAR update or as part of a
GDP. A sample AAR block follows:

START_AAR

DEFAULT 60

AAR_TIME 161500 IDX 9 AARs 60 60 60 25 25 25 25 25 25 60 60 60 60 60 60

END_AAR

The AAR_TIME value is the date/time of the hour to which the first AAR
should be applied. The remaining AARs are for the subsequent hours. The
"IDX 9" should be ignored.

## AFIX (required)

The AFIX block will always appear. It will contain a list of the arrival
fixes defined in ETMS for this airport. A sample AFIX block follows:

START_AFIX

ROBRT

BARIN

TRIXY

FINKS

MUMSY

END_AFIX

## GDP_PARAMS (optional)

The GDP_PARAMS block contains all the parameters specified when a
specialist either proposed or issued a ground delay program. Each
parameter is preceded by an explanatory keyword. The first line after
START_GDP_PARAMS will contain either PROPOSED or ACTUAL indicating
whether the GDP has actually been issued. Times are shown as day/time
(DDHHMM) as well as in an internal Metron format. A proposed GDP_PARAM
block will appear whenever a CDM GDP advisory has been sent. An actual
GDP_PARAMS block will appear if EDCTs have actually been issued. Only
the parameters from the last GDP issued will be shown.

A sample GDP_PARAMS block follows:

START_GDP_PARAMS

ACTUAL

\#

START_COMMON_PARAM

AIRPORT BOS

CURRENT_TIME 151958 : 4358 :

START_TIME 151958 : 4358 :

END_TIME 160159 : 4959 :

AIRCRAFT_TYPE All

ARRIVAL_FIX All

CARRIER_NAME All

NOW_PLUS 45

GA_FACTOR 0

SEL_APT MSP

INCLUDE_CENTER SECOND_TIER

END_COMMON_PARAM

DELAY_CEILING 999

OPERATION_TYPE RBS++

FULL_BRIDGE_ONLY UAL

LIMIT_BRIDGE_ONLY AAL

LIMIT_BRIDGE_ONLY DAL

START_GDP_AAR

:0000: 38

:0100: 38

:0200: 38

:0300: 38

:0400: 38

:0500: 38

:0600: 38

:0700: 38

:0800: 38

:0900: 38

:1000: 38

:1100: 38

:1200: 38

:1300: 38

:1400: 38

:1500: 38

:1600: 38

:1700: 38

:1800: 38

:1900: 38

:2000: 38

:2100: 38

:2200: 38

:2300: 38

END_GDP_AAR

DEP_EXEMPT_TYPE By_Status

LAST_GDP_END_TIME NA

TOTAL_FLIGHTS 326

AFFECTED_FLIGHTS 191

TOTAL_DELAY 31551

MAX_DELAY 206

AVG_DELAY 165

REPORT_TIME 152002ZZ

END_GDP_PARAMS

## COMP_PARAMS (optional)

The COMP_PARAMS block contains all the parameters specified when a
specialist performs a compression of a previously issued ground delay
program. It is similar to the GDP_PARAMS block.

A sample COMP_PARAMS block follows:

START_GDP_PARAMS

ACTUAL

\#

AIRPORT BOS

ADL_TIME 8/15/1999 22:03Z

REPORT_TIME 15220521

WINDOW_PARAMETER 0

START_TIME 152203

END_TIME 160459

BRIDGE_ONLY UAL

COMP_RULE MEMBERS_ONLY

TOTAL_FLIGHTS 142

AFFECTED_FLIGHTS 71

TOTAL_DELAY 22407/21644/-763

MAX_DELAY 203/203/0

MIN_DELAY 3/3/0

AVG_DELAY 157.8/152.4/-5.4

END_COMP_PARAMS

## BKT_PARAMS (optional)

The BKT_PARAMS block contains all the parameters specified when a
specialist performs a blanket delay of a previously issued ground delay
program. It is similar to the GDP_PARAMS and COMP_PARAMS blocks.

A sample BKT_PARAMS block follows:

START_BKT_PARAMS

ACTUAL

START_COMMON_PARAM

AIRPORT ORD

CURRENT_TIME 232024 : 4424 :

START_TIME 232200 : 4600 :

END_TIME 240357 : 5157 :

AIRCRAFT_TYPE All

ARRIVAL_FIX All

CARRIER_NAME ALL

NOW_PLUS 45

GA_FACTOR 0

INCLUDE_CENTER ALL

END_COMMON_PARAM

ADJUST_MINUTE 20

REPORT_TIME 232032ZZ

END_BKT_PARAMS

## SUB_FLAG (optional)

The SUB_FLAG block contains one line indicating whether the airline
substitution process is currently ON or OFF in ETMS. A sample SUB_FLAG
block follows:

START_SUB_FLAG

ON

END_SUB_FLAG

## ARRIVALS (required)

The ARRIVALS block contains most of the data in the ADL. The
START_ARRIVALS line contains an additional field indicating the number
of flight records that appear in the block. START_ARRIVALS is then
followed by a line for each flight in the ARRIVALS block. The contents
of each line and the definition of the data fields are the subject of
Part 3 of this document.

It was stated earlier that an ADL contains the arriving flights for a
specified airport and time interval. That time interval was stated to be
from one hour earlier to twenty hours later than the current time.
Following is a more precise description of these items.

### ADL Time Range

The ADL time range is computed as follows:

-   Get the current time.

-   Truncate to the start of the hours.

-   Subtract 1:00; this is the start time.

-   Add 19:59; this is the end time.

For example, if a report is generated at 12:35, it will contain the
flights arriving from 11:00 the same day to 7:59 the next day.

### Arriving Flights

ETMS defines a flight to be a flight leg; that is, a unique combination
of origin, destination, call sign, and time of operation. For example,
flight ABC1223 from BOS to ORD to SFO on 8/23/99 is two flights, one
operating from BOS to ORD, another operating from ORD to SFO. Given this
definition, the ARRIVALS block contains the following flights for the
ADL time range:

-   All flights that ETMS currently predicts to arrive in the ADL time
    range.

-   All canceled flights that, when they originally entered the ATMS
    database via an FS, FC, FM, or FZ message, were predicted to arrive
    in the ADL time range.

-   All flights that are diverted but that, when they originally entered
    the ATMS database via an FS, FC, FM, or FZ message, were predicted
    to arrive in the ADL time range.

A sample ARRIVALS block follows (NOTE: the records have been truncated
to the width of the page):

START_ARRIVALS 2

UCA4467 BOS ZBW ISP ZNY WOONS 152343 B190 T S A152316 A160002\...

AAL155 BOS ZBW EGLL ZEU SCUPP 152343 A306 J H A151716 A160003\...

END_ARRIVALS

## DEPARTURES (future)

A DEPARTURES block has been reserved for future use. It will look
exactly like the ARRIVALS block but will contain flights departing the
ADL airport within the ADL time range.

# Part 3 -- Flight-Specific Data

Part 3 describes the data items that ATMS will provide for a flight.
Each data item description includes:

-   the name under which the data item will appear in the ADL file
    (NOTE: the data field headers are included in the ADL file in a
    comment line near the top of the file)

-   an expanded descriptor for the data item

-   the CDM message field reference number, when it exists, in square
    brackets

-   the format of the field

-   when necessary, a definition of the field and how it will be filled

Some general notes about the field descriptions and formats:

-   Fields with null values will appear in the ADL file as the character
    '-'.

-   Field syntax is given in an abbreviated shorthand using the
    following conventions:

```{=html}
<!-- -->
```
-   L -- represents one upper-case letter

-   d -- represents any digit

-   c -- represents any character

-   \[\] -- means the characters within are optional; any characters not
    shown in brackets are required

-   Example: Ldd\[cc\] means an upper case letter followed by two
    required digits and zero, one, or two characters.

```{=html}
<!-- -->
```
-   All time-of-day fields will be 6 digits: two digits each of
    day-hour-minute (ddhhmm).

-   Field values are left aligned with their column headers.

-   No field will be blank; this is, is no value exists for that field,
    a '-' will appear.

-   Column widths are defined as the greater of the width of the value
    and the width of the header.

-   Columns are separated by two spaces.

-   Current ETMS report field names have been used wherever appropriate.
    Some new names have been suggested where the existing field names
    are misleading or confusing.

-   The name choices are constrained so that all of the current ETMS
    field names can still be used (this is critical for backwards
    compatibility). This leads to what may seem like some strange
    choices for names. For example: Airline Gate Time of Departure would
    be logically abbreviated as AGTD. Unfortunately, this is a
    pre-existing name for the Actual Gate Time of Departure (although it
    is not a gate time!). CDM Gate Time of Departure might also be a
    desirable choice, but CGTD is Controlled Time of Departure (again,
    even though it is not a gate time). So I settled for LGTD (its at
    least somewhat mnemonic: air[L]{.underline}ine).

-   Flag name lengths have been minimized in an attempt to keep the ADL
    files from getting any bigger than necessary. This again follows
    ETMS convention.

## Parsing Hints

The ADL file formatting has been designed to parse by name rather than
by position. Although every effort will be made not to rearrange the
file, it may be desirable to do so in order to add fields but still keep
the file readable. The approach that some have used to parse data out of
the ETMS reports is to:

-   define the field names that you are looking for as constants

-   search for those names in the column header line counting what
    position each is in

-   read the flight data records, assigning the values in the previously
    determined positions into the appropriate internal variables

For example, if I am interested in PGTD, I search the column header line
to find that it is the 20th field. I parse each flight record, grab the
20th token, convert it to internal format, and store it in the
appropriate internal variable (this works because we ensure that a token
exists in every column). Additionally, you can flag an error if a key
field that you need is not in the ADL file. This generally keeps the
parsing software forwards compatible through file format changes.

## Flight Data Fields

The fields currently provided for each flight in an ADL are, from left
to right:

1.  ACID: Aircraft ID (AKA. flight identifier, call sign) \[CDM Field
    02\] -- Lc\[ccccc\]

The flight identifier from OAG, CDM message, or NAS. This must identify
the flight as it will be filed on its NAS flight plan.

2.  DEST: Destination Airport (AKA. arrival airport) \[CDM Field 27\] --
    Lcc\[c\]

3.  ACENTR Arrival Center -- LLL

ARTCC of the destination airport

4.  ORIG: Origin Airport (AKA. departure airport) \[CDM Field 26\] --
    Lcc\[c\]

5.  DCENTR: Departure Center -- LLL

ARTCC of the origin airport

6.  AFIX: Arrival Fix -- LLL\[LL\]

Name of arrival fix as determined by ETMS modeling.

7.  EFTA: Estimated Fix Time of Arrival -- dddddd

Time over the fix as estimated by ETMS

8.  TYPE: Aircraft Type \[CDM Field 03\] -- \[L/\]Lcc\[c\]\[\\L\]

Rules of precedence for setting this field, in decreasing order of
priority are:

-   value received from NAS

-   value received from airline

-   value received from OAG

9.  CTG: Aircraft Category -- L

> One character indicating J=Jets, T=Turbo, P=Props

10. CLS: Aircraft Weight Class -- L

> One character indicating H=Heavy, L=Large, S=Small

11. ETD: Estimated Time of Departure -- Ldddddd

The ETD is the best, estimated runway departure time considering all
data sources. The time is preceded by a prefix indicating the status of
the flight. The prefix values are:

-   S - the estimate is based solely on OAG data

-   P - the estimate is based on flight plan data

-   L - the estimate is based on an airline-generated CDM message (the L
    prefix will be used if the time is based on an airline-provided gate
    departure time or runway departure time)

-   C - the estimate is a controlled departure time

-   A - the estimate is from a NAS activation message (DZ); the flight
    is airborne

-   E - the estimate has been extrapolated from an active NAS message
    other than a DZ; the flight is airborne

The precedence for the runway time in decreasing priority order is:

-   The actual time of departure taken from an DZ, or estimated from
    another "active" NAS message (prefix is A or E)

-   The current time if the flight is five minutes past its previous ETD
    and hasn't yet departed (prefix is S, L, or P; TOD flag is true);
    this is known as the ETMS "time-out" delay

-   The runway time of departure taken from the latest FM/FC/EDCT/SI.
    (Field T1 in a CDM message gives this time; prefix is L or C)

-   The runway time of departure modeled from the gate time of departure
    from the latest FM/FC. (Field T3 in a CDM message gives this time;
    prefix is L)

-   The runway time of departure modeled from the P-time in a NAS flight
    plan (prefix is P)

-   The runway time of departure modeled from the scheduled gate time of
    departure in the OAG (prefix is S)

12. ETA: Estimated Time of Arrival -- Ldddddd

The ETA is the best, estimated runway arrival time; it uses a prefix to
indicate the status of the flight. The values of the prefix are:

-   L - ETA is an airline provided runway arrival time

-   E - Time has been estimated by ETMS modeling.

-   A - Time is from a NAS termination (AZ) message.

The sources of this runway time are dependent on whether the flight has
departed.

-   For flights which have departed, the precedence in decreasing
    priority order is:

```{=html}
<!-- -->
```
-   The actual time of arrival taken from a NAS arrival message AZ
    (prefix is \"A\"); flight is completed.

-   The time modeled from en route data updates (TZ's and UZ's). (prefix
    is E)

-   (Actual departure time + previous ETE) when a DZ has been received.
    (prefix is E)

```{=html}
<!-- -->
```
-   For flights which have not departed, the precedence in decreasing
    priority order is:

```{=html}
<!-- -->
```
-   (Current time + current ETE) if the flight is five minutes past its
    previous ETD and hasn't yet departed. (prefix is E); this is known
    as the ETMS "time-out" delay

-   The runway time of arrival taken from the latest FM/FC/EDCT/SI.
    (Field T2 in a CDM message gives this time; prefix is L or C)

-   The runway time of arrival modeled from the gate time of arrival
    from the latest FM/FC. (Field T4 in a CDM message gives this time;
    prefix is E)

-   The runway time of arrival modeled from the P-time in a NAS flight
    plan. (prefix is E)

-   The runway time of arrival modeled from the scheduled gate time of
    departure in the OAG. (prefix is E)

13. ARTD: Actual Runway Time of Departure (AGTD in ETMS) -- dddddd

Name changed as previous name was misleading (it is a runway time not a
gate time). ARTD is the time from a NAS DZ message. If no DZ has been
received, this field is blank.

14. ARTA: Actual Runway Time of Arrival (AGTA in ETMS) -- dddddd

Name changed as previous name was misleading (it is a runway time not a
gate time). ARTA is the time from a NAS AZ message. If no AZ has been
received, this field is blank.

15. SGTD: Scheduled Gate Time of Departure -- dddddd

Gate departure time from OAG. Null if no OAG data available for the
flight.

16. SGTA: Scheduled Gate Time of Arrival -- dddddd

Gate arrival time from OAG. Null if no OAG data available for the
flight.

17. OETD: Original Estimated Departure Time (OGTD in ETMS) -- dddddd

OETD is used to save the ETD at the time a ground delay program is
issued or the flight departs. The OETD is used to "back out" of a ground
delay program. Renamed from OGTD because the ETMS name is misleading.
OETD is set in the following manner:

-   Whenever an ETD is updated from an FS, FC, FM, or FZ, as long as the
    flight is not controlled or active, the OETD is set to the new ETD.

18. OETA: Original Estimated Arrival Time (OGTA in ETMS) -- dddddd

See discussion of Original Estimated Departure Time. OETA will be set in
the following manner:

-   Whenever the ETA is updated from an FS, FC, FM, or FZ, as long as
    the flight is not controlled or active, the OETA will be updated to
    the ETA.

19. OGTD: Original Gate Time of Departure (different meaning than ETMS)
    -- dddddd

New field used to save the original gate departure time of the flight.
Useful for flight data matching. OGTD is set as follows:

-   When a flight is first created, if it is created from OAG data,
    airline data (from CDM message), or flight plan data, the OGTD is
    set to the gate departure time from that source. It will thereafter
    never be changed.

-   If a flight is created from an "active" message (e.g., departure
    message, airborne flight plan, etc.), the OGTD is set to null.

20. OGTA: Original Gate Time of Arrival (different meaning than ETMS) --
    dddddd

New field used to save the original gate arrival time of the flight.
Useful for flight data matching. OGTA is set as follows:

-   When a flight is first created, if it is created from OAG data,
    airline data (from CDM message), or flight plan data, the OGTA is
    set to the gate arrival time from that source. It will thereafter
    never be changed.

-   If a flight is created from an "active" message (e.g., departure
    message, airborne flight plan, etc.), the OGTA is set to null.

21. PGTD: Proposed Gate Time of Departure -- dddddd

Departure time from NAS flight plan. Null if no flight plan has been
received for the flight. If multiple flight plans have been processed,
shows the P time from the last one.

22. PGTA: Proposed Gate Time of Arrival -- dddddd

Arrival time from NAS. Generally this is initially set from the flight
plan, then updated when DZ and UZs are processed. Null if no NAS arrival
time has been received for the flight.

23. OCTD: Original Controlled Time of Departure (new) -- dddddd

OCTD preserves the first controlled departure time (CTD, a.k.a. EDCT)
for a flight. OCTD is set in the following manner:

-   If an EDCT is received for a flight and the flight is not already
    controlled, the OCTD is set to the EDCT time.

-   If an EDCT is received for a flight and the flight is already
    controlled, the OCTD is not changed.

-   If an EDCT purge is received for a flight and the flight is not
    active or completed, the OCTD is cleared.

-   If a flight is not currently controlled, nor was it controlled when
    it departed, the value of OCTD is null.

24. OCTA: Original Controlled Time of Arrival (new) -- dddddd

OCTA preserves the first controlled arrival time (CTA) for a flight.
OCTA is set in the following manner:

-   If an EDCT is received for a flight and the flight is not already
    controlled, the OCTA is set to the CTA.

-   If an EDCT is received for a flight and the flight is already
    controlled, the OCTA is not changed.

-   If an EDCT purge is received for a flight and the flight is not
    active or completed, the OCTA is cleared.

-   If a flight is not currently controlled, nor was it controlled when
    it departed, the value of OCTA is null.

25. CTD: Controlled Time of Departure (CGTD in ETMS) -- dddddd

CTD is the current controlled departure time (EDCT) for a flight. CTD is
set in the following manner:

-   If an EDCT is received for a flight, the CTD is set to the EDCT
    time.

-   If an EDCT purge is received for a flight and the flight is not
    active or completed, the CTD is cleared.

-   If a flight is not currently controlled, nor was it controlled when
    it departed, the value of CTD is null.

26. CTA: Controlled Time of Arrival (CGTA in ETMS) -- dddddd

CTA is the current controlled arrival time (EDCT) for a flight. CTA is
set in the following manner:

-   If an EDCT is received for a flight, the CTA is set to the CTA from
    the EDCT.

-   If an EDCT purge is received for a flight and the flight is not
    active or completed, the CTA is cleared.

-   If a flight is not currently controlled, nor was it controlled when
    it departed, the value of CTA is null.

27. LRTD: Airline Runway Time of Departure (new) \[CDM Field T1\] --
    dddddd

Predicted runway time of departure provided by the airline in a CDM
message. If an airline has sent in a runway departure time in a CDM
message, then this field contains the most recent such time. Otherwise,
the value is null

28. LRTA: Airline Runway Time of Arrival (new) \[CDM Field T2\] --
    dddddd

Predicted runway time of arrival provided by the airline in a CDM
message. If an airline has sent in a runway arrival time in a CDM
message, then this field contains the most recent such time. Otherwise,
the value is null.

29. LGTD: Airline Gate Time of Departure (new) \[CDM Field T3\] --
    dddddd

Predicted gate time of departure provided by the airline in a CDM
message. If an airline has sent in a gate departure time in a CDM
message, then this field contains the most recent such time. Otherwise,
the value is null

30. LGTA: Airline Gate Time of Arrival (new) \[CDM Field T4\] -- dddddd

Predicted gate time of arrival provided by the airline in a CDM message.
If an airline has sent in a gate arrival time in a CDM message, then
this field contains the most recent such time. Otherwise, the value is
null.

31. ERTD: Earliest Runway Time of Departure (new) \[CDM Field T7\] --
    dddddd

The earliest departure time that the airline would like to have assigned
to this flight in a ground delay program. If the airline has sent this
field in a CDM FC or FM message, then the most recent such time is
contained in this field. Otherwise, the value is null.

32. ERTD: Earliest Runway Time of Arrival (new) \[CDM Field T8\] --
    dddddd

The earliest arrival time that the airline would like to have assigned
to this flight in a ground delay program. If the airline has sent this
field in a CDM FC or FM message, then the most recent such time is
contained in this field. Otherwise, the value is null.

33. PETE: Filed ETE (new) -- dddd

The PETE field was created because the PGTD and PGTA pair do not
preserver the ETE filed by the flight operator on the flight plan. PETE
is set in the following manner:

-   If a NAS flight plan has been received for this flight with an ETE
    field, PETE is set to latest such value. Otherwise the value is
    null. PETE is in units of minutes.

34. SI: SI Cancelled (new) -- L

Indicates whether the flight is currently cancelled and an SI cancel
message has been processed for this flight. An SI cancel message is used
by an airline when substituting flights during a GDP.

35. FX: FX Cancelled (new) -- L

Indicates whether the flight is currently cancelled and an FX message
has been processed for this flight. An FX message is the CDM message
used by an airline to indicate a flight is not operating.

36. RZ: RZ or NAS Cancelled (new) -- L

Indicates whether the flight is currently cancelled and an RZ message
has been processed for this flight. An RZ message is a NAS flight plan
cancel message.

37. RS: RS Cancelled (new) -- L

Indicates whether the flight is currently cancelled and an RS message
has been processed for this flight. An RS message is an internal ETMS
message generated when a specialist takes an OAG flight out of the
database.

38. TO: Time Out Cancelled (new) -- L

Indicates whether the flight is currently cancelled and timed out by
ETMS. ETMS times out flights when no activation message has been
received within a certain time of the predicted departure time. The time
out logic is as follows:

-   If NAS or CDM messages have been received for a flight, ETMS will
    time out the flight one hour after its predicted departure time.

-   If only OAG data has been received for a flight, ETMS will time out
    the flight five minutes after departure time.

39. DV: Diversion Cancelled (new) -- L

Indicates whether the flight is currently cancelled and was diverted to
an alternate destination. The diversion may have come from either a NAS
flight plan or a CDM modify (FM) message.

40. ID: ID Cancelled (new) -- L

Indicates a flight that is now in the database under a different call
sign.

41. ALD: Airline Delayed (new) -- L

Indicates that the airline has at some point sent in a departure time
estimate (via a FC or FM) for a flight that was later than the estimate
previously in the database.

42. GDP: GDP Delayed (new) -- L

Indicates that an EDCT has been applied to this flight.

43. FAD: FA Delayed (new) -- L

Indicates that an FA delay has been applied to this flight.

44. GSD: Ground Stop Delayed (new) -- L

For future use.

45. TOD: Time Out Delayed (new) -- L

Indicates that ETMS has delayed this flight due to the fact that it has
not yet departed. The TOD status precedes a time out cancel. A time-out
delay occurs when a flight has a flight plan or CDM message, its
departure time is in the past, and it has not been activated yet. In
this case, ETMS moves the flight back in time in 5-minute increments
until one hour past departure time, at which time ETMS "time-out
cancels" the flight and sets the TO flag.

46. MAT: Maturity Flag (new) -- L

For future use.

47. SCLS: Slot Class Flag (new) -- L

The slot class filed is set by FSM whenever a GDP is issued. The value
of this flag will be the latest received in a GDP, or null if no GDP has
been issued. The meaning of the flag as set by FSM during a GDP is as
follows:

> 2 -- if the flight is either delayed into the GDP time interval or is
> not a scheduled flight
>
> 1 - otherwise

48. SREL: Slot Released Flag (new) -- L

For future use.

49. ASLOT: Assigned Arrival Slot (new) \[CDM Field A2\] -- LLLddddddL

When a CDM GDP is issued, each controlled flight is assigned an arrival
slot. The ASLOT filed is set as follows:

-   If an EDCT is received for a flight, the ASLOT is assigned to the
    value from the message.

-   If an EDCT purge is received for a flight and the flight is not
    active or completed, the ALSOT is cleared.

-   If a flight is not currently controlled, nor was it controlled when
    it departed, the value of ASLOT is null.

50. USR -- User Category -- L

> One character indicating C=Air Carrier, T=Air Taxi, F=Freight/Cargo
> Carrier, M=Military, G=General Aviation, O=Other

51. ALM: Alarm Flag (new) -- L

For future use.

52. CDM_MBR CDM Member Flag (new) -- L

Flag indicating whether this flight belongs to a CDM participant carrier
and is eligible for the full benefits of compression.

53. SUB: Substituted Flag (new) -- L

For future use.

54. EXMPT: Exempt Flight Flag (new) -- L

For future use.