![](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: Arrival Demand List (ADL) Data Format for Version 7

To: CDM Workgroup

From: Ken Howard

Date: 25 November 2002

In conjunction with the release of ETMS and FSM version 7.6, the format
of the ADL file will be changing. This document describes the new
format. It will be effective upon the operational deployment of ETMS
7.6. At such time, this document will supercede the previous document:

-   *ADL Data Format* dated 11 June 2002

The body of the document has been fully updated to match the new format.
All changes to the body of the document have been highlighted using the
Microsoft Word "Track Changes" feature. Following is a summary list of
the specific ADL items that have changed:

-   The version number has been updated from 6 to 7.

-   The position of the flight specific ETD and ETA fields has been
    changed to improve readability.

-   New prefixes have been defined for the ETD to indicate flights that
    have provided early intent information ("N") or have taxied ("T").

-   The "C" prefix has been removed as a valid ETD prefix due to it
    inherent conflict with other prefixes. The determination of whether
    a flight is (or was) controlled must now be made be examining
    whether a CTD exists or whether a CTL_TYPE exists.

-   The descriptions of the ETD and ETA fields have been re-written for
    clarity and accuracy.

-   The new flight specific fields DP and STAR have been added and
    contain the specific transition and fix being used for departure or
    arrival.

-   A bug that caused an incorrect character of "A" to be used for
    Freight/Cargo carriers in the USR field has been corrected to
    reflect the proper character of "F".

-   New CTL_TYPES (SCS and BRG) have been defined to support Slot Credit
    Substitutions (SCS).

-   The content of the SUB_FLAG block has been updated to support Slot
    Credit Substitutions (SCS).

-   The SI Cancelled field has been renamed UX to better reflect it
    current usage.

-   The sample ADL flight lists have been updated to reflect the current
    format.

# 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 an overview 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 following items.
\[NOTE: The data block name for each item is shown in square brackets.\]

-   The airport arrival rate \[AAR\] (required)

-   The airport departure rate \[ADR\] (required)

-   The arrival fixes \[AFIX \] (required)

-   The departure fixes \[DFIX\] (required)

-   The parameters defining a proposed or actual ground delay programs
    \[GDP_PARAMS\] (optional)

-   The parameters defining a compression \[COMP_PARAMS\] (optional)

-   The parameters defining a blanket \[BKT_PARAMS\] (optional)

-   The parameters defining a ground stop \[GS_PARAMS\] (optional)

-   The status of airline substitutions \[SUB_FLAG\] (optional)

-   A list of all arrivals from one hour in the past to twenty hours in
    the future \[ARRIVALS\] (optional)

-   A list of all departures from one hour in the past to twenty hours
    in the future \[DEPARTURES\] (optional)

-   For each arrival and departure, 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 six 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.

-   data type; "arr" for arrivals only, "dep" for departures only, "all"
    for both

-   filtering type; "unfilt" for no filtering, "gamf" for GA and
    military filtering, "airline name" (e.g., aal) for airline-specific
    filtering

All letters in a file name are lower case.

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

bos\_\_.lcdm.06153533.01.arr.unfilt

An ADL file generated for Delta for Atlanta arrivals and departures on
July 17 at 09:17:05 would be named:

atl\_\_.lcdm.17091705.01.all.dal

NOTE: An ADL file is compressed and encrypted for transmission to user
sites. The suffix ".gz" indicates a file is compressed (using "gzip").
The suffix ".enc" indicates a file is encrypted.

## 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 about
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 the 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_UPDATE" 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)

## Header 

The header of an ADL file consists of five lines required by FSM
interspersed with comment lines. A colon (:) in column 1 indicates a
required header line. 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 some 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 data records

A sample header follows:

:Product Code: 0xfaa

:Magic Number: 0xfaa1

:Version Num : 0x7

\#

\#

:Date: 11/16/2002

:First Update: 16010315

\#

# Part 2 -- ADL Data Blocks

The bulk of an ADL file is the data update. It starts with a single line
containing the day-hour-minute at which the update was generated, as
follows:

START_UPDATE ddhhmmss

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

END_UPDATE ddhhmmss

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

## 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

## DFIX (required)

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

START_DFIX

ROBRT

BARIN

TRIXY

FINKS

MUMSY

END_DFIX

## AAR (required)

The AAR block will always contain at least one line showing the default
value for the airport arrival . 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.

## ADR (required)

The ADR 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 ADR update or as part of a
GDP. A sample ADR block follows:

START_ADR

DEFAULT 60

ADR_TIME 161500 IDX 9 AARs 60 60 60 25 25 25 25 25 25 60 60 60 60 60 60

END_ADR

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

## METAR (optional)

The METAR block will always contain the current METAR. A sample METAR
block follows:

START_METAR

KEWR 071851Z 22012G20KT 10SM OVC250 19/00 A3020 RMK AO2

SLP225 T01890000=

END_METAR

## TAF (optional)

The TAF block will always contain the current TAF. A sample TAF block
follows:

START_TAF

KEWR 071901Z 071918 24012KT P6SM OVC250

BECMG 0002 VRB03KT SCT060 BKN250

FM0800 VRB03KT P6SM SKC

TEMPO 0912 6SM BR

FM1400 17005KT P6SM SCT250=

END_TAF

## 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_PARAMS
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 actual GDP issued will be shown.

Once a GDP_PARAMS block appears in the ADL, it will stay in the ADL
until one of the following conditions occurs:

-   The GDP is cancelled (purged).

-   A new GDP (revision or extension) is issued.

This means the last GDP_PARAMS block will stay in the ADL even if a
compression, blanket, or ground stop is issued.

When a GDP is cancelled, all of the lines in the block will be removed
and will be replaced by the text GDP_PGM_TERMINATED followed by the time
of the cancellation in MMDDHHMMSS format. This message will be retained
until a new GDP, either actual or proposed, is started or until 0800z.

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_AAR

:0000 -- 38: 10 9 10 9

:0100 -- 38: 10 9 10 9

:0200 -- 38: 10 9 10 9

:0300 -- 38: 10 9 10 9

:0400 -- 38: 10 9 10 9

:0500 -- 38: 10 9 10 9

:0600 -- 38: 10 9 10 9

:0700 -- 38: 10 9 10 9

:0800 -- 38: 10 9 10 9

:0900 -- 38: 10 9 10 9

:1000 -- 38: 10 9 10 9

:1100 -- 38: 10 9 10 9

:1200 -- 38: 10 9 10 9

:1300 -- 38: 10 9 10 9

:1400 -- 38: 10 9 10 9

:1500 -- 38: 10 9 10 9

:1600 -- 38: 10 9 10 9

:1700 -- 38: 10 9 10 9

:1800 -- 38: 10 9 10 9

:1900 -- 38: 10 9 10 9

:2000 -- 38: 10 9 10 9

:2100 -- 38: 10 9 10 9

:2200 -- 38: 10 9 10 9

:2300 -- 38: 10 9 10 9

END_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.

Once a COMP_PARAMS block appears in the ADL, it will stay in the ADL
until one of the following conditions occurs:

-   The GDP is cancelled (purged).

-   A new GDP (revision or extension), compression, blanket, or ground
    stop is issued.

A sample COMP_PARAMS block follows:

START_COMP_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.

Once a BKT_PARAMS block appears in the ADL, it will stay in the ADL
until one of the following conditions occurs:

-   The GDP is cancelled (purged).

-   A new GDP (revision or extension), compression, blanket, or ground
    stop is issued.

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

## GS_PARAMS (optional)

The GS_PARAMS block contains all the parameters specified when a
specialist issues a ground stop using FSM. It is similar to the
GDP_PARAMS block.

Once a GS_PARAMS block appears in the ADL, it will stay in the ADL until
one of the following conditions occurs:

-   The GS is cancelled (purged).

-   A new GS (revision or extension), compression, blanket, or ground
    stop is issued.

When a GS is cancelled, all of the lines in the block will be removed
and will be replaced by the text GS_PGM_TERMINATED followed by the time
of the cancellation in MMDDHHMMSS format. This message will be retained
until a new GS, either actual or proposed, is started or until 0800z.

A sample GS_PARAMS block follows:

START_GS_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 15

GA_FACTOR 0

INCLUDE_CENTER ALL

END_COMMON_PARAM

START_AAR

:0000 -- 38: 10 9 10 9

:0100 -- 38: 10 9 10 9

:0200 -- 38: 10 9 10 9

:0300 -- 38: 10 9 10 9

:0400 -- 38: 10 9 10 9

:0500 -- 38: 10 9 10 9

:0600 -- 38: 10 9 10 9

:0700 -- 38: 10 9 10 9

:0800 -- 38: 10 9 10 9

:0900 -- 38: 10 9 10 9

:1000 -- 38: 10 9 10 9

:1100 -- 38: 10 9 10 9

:1200 -- 38: 10 9 10 9

:1300 -- 38: 10 9 10 9

:1400 -- 38: 10 9 10 9

:1500 -- 38: 10 9 10 9

:1600 -- 38: 10 9 10 9

:1700 -- 38: 10 9 10 9

:1800 -- 38: 10 9 10 9

:1900 -- 38: 10 9 10 9

:2000 -- 38: 10 9 10 9

:2100 -- 38: 10 9 10 9

:2200 -- 38: 10 9 10 9

:2300 -- 38: 10 9 10 9

END_AAR

REPORT_TIME 232032ZZ

END_GS_PARAMS

## SUB_FLAG (optional)

The SUB_FLAG block shows the status of the slot substitution process.
The SUB_FLAG block may contain the following keywords:

-   SUBS -- Indicates whether all substitutions are enabled (ON) or
    disabled (OFF).

-   SCS -- Indicates whether slot credit substitutions for all users are
    enabled (ON) or disabled (OFF).

-   BRIDGING -- Indicates whether bridging subs are disabled (OFF) for a
    particular user (airline name, GA, or MILITARY). If bridging is off
    for an airline, any flight whose MAJOR field or carrier code (from
    ACID) matches the airline name will not be used for an SCS bridge.
    If bridging is enabled for a user, no line will appear; that is, the
    only allowed value for this keyword is OFF.

A sample SUB_FLAG block follows:

START_SUB_FLAG

SUBS ON

SCS OFF

BRIDGING OFF AAL

BRIDGING OFF BLR

BRIDGING OFF GA

BRIDGING OFF MILITARY

END_SUB_FLAG

## FADT_TIMES (optional)

The FADT_TIMES block contains a list of each FADT file that has been
generated during the current traffic management event at the airport. A
FADT file is the file that FSM generates whenever a set of EDCTs or FA
delays is sent out. A GDP, a compression, a blanket program, and a
ground stop all cause a FADT to be generated. The FADT_TIMES list will
show each FADT that has been issued as well as the type of the FADT. The
FADT list will only appear if a traffic management initiative is in
place for this airport. A sample FADT_TIMES block follows:

START_FADT_TIMES

04173029 GDP

04184317 COMP

04200011 GDP

END_FADT_TIMES

## ARRIVALS (optional)

The ARRIVALS block contains the arriving flights for the airport. 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.

Two comment lines precede the ARRIVALS block. One indicates that the
following list is for arrivals. The other shows the column headers for
each of the data fields in the flight records.

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

### ADL Time Interval

The ADL time range is computed as follows:

-   Get the current time.

-   Truncate to the start of the current hour.

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

-   Add 19:59 to the current hour; 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 call sign, origin, destination, 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 at the given
    airport in the ADL time interval.

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

-   All flights that are diverted but that, when they originally entered
    the CDM database via an FS, FC, FM, or FZ message, were predicted to
    arrive at the given airport in the ADL time range. \[NOTE: The
    original diverted flight will not appear in the ADL if a diversion
    recovery is created with the same call sign.\]

A sample ARRIVALS block follows (NOTE: the records have been truncated
to the width of the page, and only two records are shown):

\# ARRIVALS

#ACID DEST ACENTR ORIG DCENTR ETD ETA DFIX EDFT ...

\#

START_ARRIVALS 592

UCA4467 BOS ZBW ISP ZNY A152320 A160001 - - ...

AAL155 BOS ZBW EGLL ZEU E151617 A160003 - - ...

...

END_ARRIVALS

## DEPARTURES

The DEPARTURES block contains the departing flights for the airport. The
START\_ DEPARTURES line contains an additional field indicating the
number of flight records that appear in the block. START_DEPARTURES is
then followed by a line for each flight in the DEPARTURES block. The
contents of each line and the definition of the data fields are the
subject of Part 3 of this document.

Two comment lines precede the DEPARTURES block. One indicates that the
following list is for departures. The other shows the column headers for
each of the data fields in the flight records.

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

### ADL Time Interval

The ADL time range is computed as follows:

-   Get the current time.

-   Truncate to the start of the current hour.

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

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

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

### Departing Flights

ETMS defines a flight to be a flight leg; that is, a unique combination
of call sign, origin, destination, 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 DEPARTURES block contains the following flights for the
ADL time range:

-   All flights that ETMS currently predicts to depart from the given
    airport in the ADL time interval.

-   All canceled flights that, when they originally entered the CDM
    database via an FS, FC, FM, or FZ message, were predicted to depart
    from the given airport in the ADL time interval.

-   All flights that are diverted but that, when they originally entered
    the CDM database via an FS, FC, FM, or FZ message, were predicted to
    depart from the given airport in the ADL time range. \[NOTE: The
    original diverted flight will not appear in the ADL if a diversion
    recovery is created with the same call sign.\]

A sample DEPARTURES block follows (NOTE: the records have been truncated
to the width of the page, and only two records are shown):

\# DEPARTURES

#ACID DEST ACENTR ORIG DCENTR ETD ETA DFIX EDFT ...

\#

START_DEPARTURES 608

GAA1234 ISP ZNY BOS ZBW A160004 E160057 LUCOS 160013 ...

SWA785 STL ZKC BOS ZBW A160007 E160402 MHT 160018 ...

END_DEPARTURES

# Part 3 -- Flight-Specific Data

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

-   the name under which the data item appears in the ADL file (these
    are the names that appear in the column header comment line)

-   an expanded descriptor for the data item

-   the corresponding 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 one digit

-   c -- represents one alphanumeric character (either letter or digit);
    by convention, CDM uses only upper case letters in the data fields

-   \[\] -- 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.

-   Fields are separated by two or more blanks.

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

-   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 LGTD is used (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 you are interested in PGTD, you 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 forward 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.  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, in increasing order of priority (that
is, the ADL will show the lowest prefix from this list that applies to a
flight):

-   S -- the flight data is based solely on OAG data

-   N -- an early intent flight plan has been processed for this flight

-   P -- a NAS flight plan has been processed for this flight

-   L - the airline has provided time estimates on a CDM message

-   T -- the airline sent an OUT time but the flight has not yet taken
    off

-   E -- the flight is active and the time has been extrapolated from an
    active NAS message other than a DZ.

-   A -- the flight is active and the time is from a NAS activation
    message (DZ) or an airline-provided OFF time.

ETMS evaluates the ETD time whenever new data is received for a flight.
If the new data provides a better ETD, ETMS updates it. Following is a
walkthrough of this processing.

-   When OAG data is processed for a flight, ETMS sets the ETD to the
    SGTD plus the estimated ground time for this flight. (Ground time is
    estimated from a historical record of gate times actual departure
    times.) (Prefix is S.)

-   When an airline sends a LRTD or LGTD, ETMS will update the ETD if
    the flight is not active, not controlled, or if the LRTD or LGTD is
    later than the controlled time. If an LRTD has been sent, ETMS sets
    the ETD to the LRTD. If an LGTD was sent, ETMS sets the ETD to the
    LGTD plus the estimated ground time. (Prefix is L.)

-   When a flight is controlled (e.g., GDP is issued) or substituted and
    the new control time is later than the current LRTD or LGTD, ETMS
    sets the ETD to the CTD. (Prefix is S, N, P, L, or T.)

-   When a proposed NAS flight plan is processed and the flight is not
    controlled nor active and no LRTD or LGTD exists, ETMS sets the ETD
    to the PGTD plus the estimated ground time for this flight. (Prefix
    is P.)

-   When an early intent flight plan is processed and the flight is not
    controlled nor active and no LRTD or LGTD exists and no NAS flight
    plan has been processed, ETMS sets the ETD to the P-time from the
    early intent message plus the estimated ground time for this flight.
    (Prefix is N.)

-   If at any time the current time is five minutes past a flight's
    current ETD, ETMS resets the ETD to the current time. The prefix in
    this case could be S, N, P, L, or T; TOD (time-out delay) flag will
    be true. Note: When a flight is time-out delayed, the ETD keeps the
    prefix it had when it entered TOD status.

-   When a flight is activated, ETMS sets the ETD to the actual time of
    departure taken from a DZ, an airline-provided OFF time, or
    estimated from another "active" NAS message. (Prefix is A or E.)

7.  ETA: Estimated Time of Arrival -- Ldddddd

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

-   E -- Time has been estimated by ETMS modeling.

-   L -- ETA is an airline provided runway arrival time.

-   C -- Time is estimated by ETMS modeling but the flight is
    controlled.

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

ETMS evaluates the ETA time whenever new data is received for a flight.
If the new data provides a better ETA, ETMS updates it. Following is a
walkthrough of this processing.

-   When OAG data is processed for a flight, ETMS models the ETE using
    the historical flight plan and current wind data then sets the ETA
    to the ETD plus the modeled ETE. (Prefix is E.)

-   When ETMS updates an ETD using an airline-provided LRTD, ETMS sets
    the ETA to the airline-provided LRTA. (Prefix is L or C.)

-   When ETMS receives a new LRTD and LRTA for a controlled flight, and
    the LRTD is earlier than the CTD, ETMS will update the ETA to
    reflect the new airline-provided ETE; that is, ETA = prior ETD +
    (LRTA -- LRTD). (Prefix is C).

-   When ETMS updates an ETD using a LGTD, control time (CTD), PGTD, or
    time-out delay, ETMS updates the ETA by adding the prior ETE to the
    new ETD. That is, the flight time is not re-modeled. (Prefix is E.)

-   When ETMS processes a new NAS or early intent flight plan, ETMS
    re-models the ETE and uses it to update the ETA unless the airline
    has sent an LRTD and LRTA. That is, if there is no LRTD and LRTA,
    ETMS sets the ETA = ETD + new modeled ETE. (Prefix is E.)

-   When a flight is activated, ETMS sets the ETA to the new ETD + prior
    ETE. That is, the ETE is not re-modeled. (Prefix is E.)

-   Once a flight is airborne, ETMS updates the ETA whenever track
    updates (TZs) are processed. ETMS estimates the ETA based on the
    current position, speed, planned route, and observed track. (Prefix
    is E.)

-   Once a flight lands, ETMS updates the ETA to the time from the NAS
    arrival (AZ) message.

8.  DFIX: Departure Fix -- LLL\[LL\]

The name of the departure fix as determined by ETMS modeling.

9.  EDFT: Estimated Departure Fix Time -- dddddd

Time over the departure fix as estimated by ETMS.

10. DP: Departure Procedure -- LLL\[LL\]d

The name of the DP taken from the historical, early intent, or NAS
flight plan.

11. DTRSN: DP Transition Fix -- LLL\[LL\]

The name of the DP transition taken fix from the historical, early
intent, or NAS flight plan.

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

The name of the arrival fix as determined by ETMS modeling.

13. EAFT: Estimated Arrival Fix Time -- dddddd

Time over the arrival fix as estimated by ETMS.

14. STAR: Standard Terminal Arrival Route -- LLL\[LL\]d

The name of the STAR taken from the historical, early intent, or NAS
flight plan.

15. STRSN: STAR Transition Fix -- LLL\[LL\]

The name of the STAR transition fix from the historical, early intent,
or NAS flight plan.

16. USR -- User Category -- L

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

17. 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

18. CTG: Aircraft Category -- L

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

19. CLS: Aircraft Weight Class -- L

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

20. 

-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   

21. 

-   
-   
-   
-   

```{=html}
<!-- -->
```
-   
-   
-   

```{=html}
<!-- -->
```
-   

```{=html}
<!-- -->
```
-   
-   
-   
-   
-   

22. 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.

23. 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.

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

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

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

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

26. IGTD: Initial Gate Time of Departure (formerly OGTD) -- dddddd

New field used to save the initial gate departure time of the flight.
Useful for flight data matching. IGTD 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 IGTD 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 IGTD is set to null.

27. IGTA: Initial Gate Time of Arrival (formerly OGTA) -- dddddd

New field used to save the original gate arrival time of the flight.
Useful for flight data matching. IGTA 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 IGTA 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 IGTA is set to null.

28. 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.

29. 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.

30. PETE: Filed ETE -- 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.

31. LRTD: Airline Runway Time of Departure \[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

32. LRTA: Airline Runway Time of Arrival \[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.

33. LGTD: Airline Gate Time of Departure \[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

34. LGTA: Airline Gate Time of Arrival \[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.

35. ERTD: Earliest Runway Time of Departure \[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.

36. ERTA: Earliest Runway Time of Arrival \[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.

37. OUT: Gate Out Time \[CDM Field TBD\] -- dddddd

The time at which a flight pushed out from the gate as reported by the
airline via a CDM message. If the airline sends more than one value,
then the most recent such time is contained in this field. Otherwise,
the value is null.

38. OFF: Time Off the Runway \[CDM Field TBD\] -- dddddd

The time at which a flight lifts off from the runway as reported by the
airline via a CDM message. If the airline sends more than one value,
then the most recent such time is contained in this field. Otherwise,
the value is null.

39. ON: On the Runway \[CDM Field TBD\] -- dddddd

The time at which a flight touches down on the runway as reported by the
airline via a CDM message. If the airline sends more than one value,
then the most recent such time is contained in this field. Otherwise,
the value is null.

40. IN: Gate In Time \[CDM Field TBD\] -- dddddd

The time at which a flight pulls in at the gate as reported by the
airline via a CDM message. If the airline sends more than one value,
then the most recent such time is contained in this field. Otherwise,
the value is null.

41. 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, or the flight is "time-out" delayed by
CDM. The OETD is used to "back out" of a ground delay program. The OETD
does NOT include any time-out delay modeled by CDM when a flight is late
departing. 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.

42. 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.

43. BETD: Base Estimated Departure Time (OGTD in ETMS) -- dddddd

BETD is used to save the ETD at the time a ground delay program is
issued or the flight departs. The BETD is used to compute the amount of
departure delay that can be attributed to a ground delay program. The
BETD includes any modeled time-out delay. BETD 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 BETD is set to the new ETD.

-   Whenever CDM re-models a departure time due to a "time-out" delay,
    the BETD is updated to the new ETD.

44. BETA: Base Estimated Arrival Time (OGTA in ETMS) -- dddddd

See discussion of Base Estimated Departure Time. BETA 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 BETA will be updated to
    the ETA.

-   Whenever CDM re-models a departure time due to a "time-out" delay,
    the BETA is updated to the new ETA.

45. OCTD: Original Controlled Time of Departure -- 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.

46. OCTA: Original Controlled Time of Arrival -- 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.

47. 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.

48. 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.

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

When a CDM GDP is issued, each controlled flight is assigned an arrival
slot. The ASLOT field 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. CTL_ELEM: Controlled Element -- Lcc\[cc\]

If a flight is controlled (i.e., has a CTD and CTA), CTL_ELEM indicates
the constrained NAS element for which a ground delay program or ground
stop was run. Currently, the CTL_ELEM can only be the arrival airport,
however, we are anticipating the expansion of GDPs into en route
constraints. It is set in the following manner:

-   If a flight is controlled, the CTL_ELEM is the airport, fix, or
    sector for which the GDP or ground stop was run.

-   If a flight is not controlled, the CTL_ELEM is null.

51. CTL_TYPE: Control Type -- LL\[LL\]

If a flight is controlled (i.e., has a CTD and CTA), CTL_TYPE indicates
the specific source of the current CTD/CTA. The possible sources are:

-   GS -- a ground stop program

-   GDP -- an initial GDP, an extension, or a revision

-   COMP -- compression

-   FA -- a fuel-advisory delay

-   BLKT -- a blanket (+/-) program

-   SUB -- a regularirline substitution message

-   SCS -- an airline slot credit substitution message

-   BRG -- a bridge created to handle a slot credit subsitution request

-   UPD -- an ETMS "EDCT UPDATE" command

52. CTL_EXMPT: Control Exempt Flag -- c

If a flight is controlled (i.e., has a CTD and CTA), CTL_EXMPT indicates
whether the flight was categorized as "exempt" (for example, due to
departure time status or departure center) when the GDP was computed.

53. SL_HOLD: Slot Hold Flag -- L

If a flight is controlled (i.e., has a CTD and CTA), the SL_HOLD flag
indicates whether the slot associated with this flight is being held, or
would be held, by the airline for the next compression. The compression
algorithm will not automatically fill slots that are held.

54. DV_REC: Diversion Recovery Flag -- c

Indicates that the flight is a recovery of a flight that was previously
diverted. A diversion recovery inherits data from the original flight to
ensure that it be given a priority in any GDP that has been or may be
run.

55. UX: Update Cancelled -- L

Indicates whether the flight is currently cancelled due to an EDCT
UPDATE cancel. An EDCT UPDATE cancel may be used by a traffic manager to
cancel a flight that is part of a GDP.

56. FX: FX Cancelled -- 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.

57. RZ: RZ or NAS Cancelled -- 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.

58. RS: RS Cancelled -- 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.

59. TO: Time Out Cancelled -- 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.

60. DV: Diversion Cancelled -- 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.

61. RM: Remove Cancelled -- L

Indicates a flight that has been manually removed by an FAA traffic
management specialist.

62. ALD: Airline Delayed -- 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.

63. GDP: GDP Delayed -- L

Indicates that an EDCT has been applied to this flight.

64. FAD: FA Delayed -- L

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

65. GSD: Ground Stop Delayed -- L

Indicates the flight is currently part of a ground stop program.

66. TOD: Time Out Delayed -- 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.

67. CTL_ALM: Alarm Flag -- Oxdddd

Indicates the alarm status flags that are set for a particular flight.
The CTL_ALM value is the hexidecimal value of the cumulative total of
all set flags, where each flag is a bit in the CTL_ALM word. Once set, a
flag is never cleared. More then one alarm can be set at a given time.

The alarm flags are defined as follows:

-   NO_ALARM = 0

-   CTA_COMPLIANCE (0x1) -- indicates that a flight landed outside the
    CTA compliance window (more than 5 minutes earlier or 5 minutes
    later than the CTA).

-   CTD_COMPLIANCE (0x2) -- indicates that a flight took off outside the
    CTD compliance window (more than 5 minutes earlier or 5 minutes
    later than the CTD).

-   ETE_VALUE (0x4) -- indicates the difference between the actual
    enroute time and the controlled enroute time is outside the
    compliance time range (more than 15 minutes).

-   SPURIOUS_FLT (0x8) --indicates that a flight was not scheduled (that
    is, was created on that day from a CDM message or flight plan), was
    controlled in a GDP, and was cancelled by a CDM message.

-   CANCELLED_FLEW (0x10) --indicates a flight that had a status of
    cancelled at the time that it was activated by a DZ, UZ, TZ, or AZ
    message.

Example: A CTL_ALM value of 0x0013 means that the CTA_COMPLIANCE,
CTD_COMPLIANCE, and CANCELLED_FLEW alarm flags are all set.

68. CDM_MBR: CDM Member Flag -- L

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

69. MAJOR: Major carrier -- LLL\[L\]

For CDM members, indicates the carrier that has substitution for the
flight. If the flight IDs for the major carrier are being filtered, the
MAJOR field will contain the filtered four-letter code.

70. GCD: Great Circle Distance -- ddddd

Indicates the great circle distance, in nautical miles, between the
origin and the destination.

71. LTOD: Length of Time Out Delay -- ddd

If the TOD flag is set, this field indicates the length of the time out
delay in minutes.

72. NRP: National Route Program flight-- L

Flight plan has been processed with the keyword "NRP" in field 11. This
indicates the flight is participating in the National Route Program.

73. LFG: Lifeguard or MEDEVAC flight-- L

Flight plan has been processed with the keyword "LIFEGUARD" in field 11.

74. IIIFlight is capable of utilizing CAT3 landing minimums.-- L

Flight plan has been processed with the keyword "CATIII" in field 11.

75. ATV: Altitude Reservation -- L

Flight plan has been processed with the keyword "ALTRV" in field 11.

76. SWP: Swapping-- L

Flight plan has been processed with the keyword "SWAP" in field 11.

77. DVT: Diversion Recovery flight-- L

Flight plan has been processed with the keyword "DVRSN" in field 11.

78. ADC: Advise Customs-- L

Flight plan has been processed with the keyword "ADCUS" in field 11.

79. FCA: Flow Contrained Area (new) -- L

Flight plan has been processed with the keyword "FCA" in field 11.

80. WXR: Severe weather reroute-- L

Flight plan has been processed with the keyword "WXRTE" in field 11.