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

U.S. Department

of Transportation

Research and John A. Volpe

Special Programs National Transportation Systems Center

Administration

Date: June 18, 1996 Reply to Attn. of: DTS--56

Subject: CDM Message Formats

From: K. Howard/Arcon (617) 494--2697

To: CDM Developers

This memo revises the message format descriptions previously described
in my memo of April 9. The changes are to several of the data fields for
future implementation. The changes are indicated by "rev bars" in the
left column.

This version of the message descriptions has been named version 1.2.

The changes are summarized below:

-   The "Open" message has been renamed to "Released" to better reflect
    its usage.

-   Gate times are now required on a flight create message.

-   A different return address is allowed for message replies.

-   The continuation character has been changed from "&" to "C".

Message Formats for CDM Task 3 --- Version 1.2

Scope

This memo describes the message formats that the participating airlines
will send to the Advanced Traffic Management System (ATMS) as part of
Task 3 of the Collaborative Decision--Making program, as described in
the system requirements document. The goal of Task 3 is to improve the
data that the FAA uses to detect arrival problems at airports and to
manage arrival problems through EDCT (aka ground delay) programs. The
messages are also designed to support additional information exchange
needed to support other CDM improvements to EDCT programs such as
compression and control by arrival time.

The messages described in this memo only apply to individual occurrences
of flight legs. Messages for making permanent changes to the flight
schedules as downloaded from OAG, which were described in my previous
memo, have been omitted here to avoid confusion. They will be
re--instated at such time that we are ready to develop such
functionality.

Background

The ETMS already processes a set of messages we receive from the NAS
(flight plans, amendments and cancellations being the relevant three).
As we have created additional messages within ETMS, we have tried to
mimic the NAS format in order to simplify the processing requirements.
There is a tangible benefit for us if the airline messages have some
compatibility with the NAS messages.

A NAS flight plan, as you probably all know, looks like:

FZ RYN218/154 B727 0471 DAY P1000 290 DAY..PSB.J49.ALB..PSM..PSM/0129

where the fields from left to right are:

01 message type

02 call sign/computer ID

03 aircraft type

05 filed airspeed

06 coordination fix

07 coordination time (the P means *proposed*)

09 filed cruising altitude

10 route of flight/estimated time enroute

A NAS amendment has the form:

AF RLT950 MKG ROC 06 4313N/08121W 07 E0803 10 MKG./.BUF.V2.ROC

where the fields from left to right are:

01 message type

02 call sign

26 departure airport

27 arrival airport

and repeated pairings of:

12 field reference number to be modified

17 new value for that field (matches syntax of referred field)

A NAS cancellation has the form:

RZ RLT950 MKG ROC

where the fields from left to right are:

01 message type

02 call sign

26 departure airport

27 arrival airport

Overview of Flight Message Processing

Airlines will send flight data via three message types: Create, Modify,
and Cancel. These messages will be used to enhance the data which is
currently loaded into the ATMS daily (live) database from the OAG
schedules, often well ahead of the time that the flight operates. Once a
flight is in the NAS (through filing a flight plan), ATMS will in
general use the NAS data to replace the airline data (NOTE: we will use
the airline estimated departure and arrival times over the NAS message
times). Data in a specific airline message can only affect one day's
occurrence of one leg of a flight. The data sent in the airline messages
will initially be oriented towards that data required to support
improved EDCT processing; e.g., departure and arrival time estimates,
changes in origin/destination, etc.

The three messages will be formatted by choosing from a set of
pre--defined data fields. Certain fields are required on each message
type; these will be provided in a fixed format. Other fields will be
provided in a variable format, with each field being identified by a
reference number. Existing NAS field formats and definitions are used
wherever possible.

Messages will initially be transmitted from the airlines to ATMS through
ARINC. The packaging and handling of the messages will be similar to the
SI message processing with several significant exceptions:

-   ATMS will not generate flight--by--flight acknowledgement for
    messages that are processed correctly, but will rely on
    packet--level acknowledgements

-   airlines will assign a unique identifier (based in part on
    transmission time) to each packet which ATMS will return with the
    acknowledgement

Future CDM tasks will be implemented using these and additional
messages. In particular, improved (simplified) substitution processing
will be performed using the cancellation and modify messages defined
here.

Flight Data Fields

The possible fields which can be defined for an individual flight are
defined below. Individual messages are composed of combinations of these
fields. Flight data fields are referred to by a field reference number.
The first twelve fields are those required for the current goals of CDM;
additional fields are included in anticipation of future functionality.
New fields will be defined as the need arises.

Each field is described by a field reference number, a name, a syntax, a
text explanation of the field, and one or more examples. Syntax is
specified in a manner similar to that used in NAS--MD--311 Appendix E,
where:\
a --- denotes any alphanumeric character,

L --- denotes an upper case letter (A--Z),

d --- denotes any digit (0--9),

() --- indicates a character is optional.

other characters --- literals (i.e., the characters should appear as
specified)

For example, the syntax "Ld(a)" indicates a field that must start with a
letter followed by a digit, and can optional have a third character
which can be any alphanumeric.

**NOTES**: 1. All dates and times are in UTC.

2.  Fields identified by integers correspond to NAS fields and their
    syntax matches (or is a\
    subset of) that specified in NAS--MD--311 Appendix E.

3.  The fields designated A1, A2, \... and T1, T2, \... are new fields
    not defined in NAS.

Fields for Near--term Implementation

Field 02. [Flight Identification]{.underline} --- 2--8 characters.
La(a)(a)(a)(a)(a)(a)

Examples: N1, GAA1234

Flight call sign as it appears in the OAG and/or will subsequently be
filed on the NAS flight plan. Only the aircraft identification portion
of the NAS syntax will be accepted (i.e., no suffixes are used here).
Only seven character Flight IDs will be accepted for now. An extra
character has been defined to allow for the possibility for NAS to go to
an eight character ID. No padding is required.

Field 03. [Aircraft Type]{.underline} --- 2 to 9 characters.
(d)(L)/La(a)(a)/(L)

Examples: T6, B727, H/B747, B757/A, 4T/DC10/B

Aircraft equipment specification. Optional prefix number is the number
of aircraft. Optional prefix letter specifies whether flight is TCAS
equipped (T/), heavy (H/), or both (B/). Required middle portion is FAA
published aircraft type code. Optional suffix is equipment type (/A for
DME with altitude encoding, /B is DME with no altitude encoding, etc.) .

Field 26. [Departure Airport]{.underline} --- 4 characters. aaa(a)

Examples: JFK, KJFK, 32G

ICAO identifier for the airport of origin for this flight leg. Called
Departure Point in NAS.

Field 27. [Arrival Airport]{.underline} --- 4 characters. aaa(a)

Examples: JFK, KJFK, 32G

ICAO identifier for the destination airport for this flight leg. Called
Destination in NAS.

Field A1. [UTC Departure Date]{.underline} --- 4 digits. dddd

Example: 0626

Month and day on which the flight leg was originally scheduled to
depart. Date must be four digits, zero padded.

Field A2. [Assigned Arrival Slot]{.underline} --- 11 characters.
(L)LLLddddddL

Example: KORD261200A, KJFK261200C

Unique identifier of the arrival slot that this flight is currently
assigned to. Only applicable if a delay program is in place. First four
characters indicate the arrival airport; next 6 digits are the day,
hour, and minute of the slot; final letter indicates slot within the
minute (A is first slot, B is second, etc.). Date/time portion must be 6
digits, zero padded.

Field T1. [Runway Departure Time]{.underline} --- 6 digits. Dddddd

Example: 261210

Estimated day, hour, and minute the flight depart the runway. Must be 6
digits, zero padded.

Field T2. [Runway Arrival Time]{.underline} --- 6 digits. Dddddd

Example: 261518

Estimated day, hour, and minute the flight will touch down on the
arrival runway. Must be 6 digits, zero padded.

Field T3. [Gate Departure Time]{.underline} --- 6 digits. Dddddd

Example: 261200

Estimated day, hour, and minute the flight will push back from the
departure gate. Must be 6 digits, zero padded.

Field T4. [Gate Arrival Time]{.underline} --- 6 digits. Dddddd

Example: 261530

Estimated day, hour, and minute the flight will pull in at the arrival
gate. Must be 6 digits, zero padded.

Field T5. [Controlled Departure Time]{.underline} --- 6 digits. Dddddd

Example: 261245

Day, hour, and minute at which the flight will have to leave the
departure runway to make its controlled arrival time (aka EDCT). Only
valid if a delay program is in effect. Must be 6 digits, zero padded.

Field T6. [Controlled Arrival Time]{.underline} --- 6 digits. Dddddd

Example: 261553

Day, hour, and minute at which the flight must arrive to meet the goals
of an FAA delay program (aka CTA). Only valid if a delay program is in
effect. Must be 6 digits, zero padded.

Field T7. [Earliest Runway Departure Time]{.underline} --- 6 digits.
Dddddd

Example: 261210

Day, hour, and minute of the earliest runway departure time that an
airline is willing to accept for a flight. Only valid if a delay program
is in effect. Must be 6 digits, zero padded.

Field T8. [Earliest Runway Arrival Time]{.underline} --- 6 digits.
Dddddd

Example: 261518

Day, hour, and minute of the earliest runway arrival time that an
airline is willing to accept for a flight. Only valid if a delay program
is in effect. Must be 6 digits, zero padded.

Fields for Future Implementation

Field 05. [Cruising Speed]{.underline} --- 2 to 4 digits. Multiple
speeds can be provided separated by slashes and location identifiers.
dd(d)(d)(/LLL(L)(L)/dd(d)(d))\*

Example: 250

Planned true airspeed in knots.

Field 09. [Cruising Altitude]{.underline} --- 2 or 3 digits. Multiple
altitudes can be provided separated by slashes and location identifiers.
dd(d)(/LLL(L)(L)/dd(d))\*

Example: 370

Planned cruising altitude in hundreds of feet.

Field 10. [Route of Flight]{.underline} --- NAS flight plan format (see
NAS MD--312).

Example: RDM..DSD.V595.PDX

The planned route of flight expressed as a series of fixes and routes
connecting the departure airport and the arrival airport.

Field A3. [Landing Weight]{.underline} --- 1 to 4 digits. d(d)(d)(d)

Example: 336

Expected landing weight of the aircraft expressed in thousands of
pounds.

Field A4. [Preferred Runways]{.underline} --- 2 digits or 2 digits plus
one or two letters; multiple fields allowed separated by slashes.
dd(L)(L)(/dd(L)(L))\*

Example: 12L/12R

The runway or runways that the airline would prefer the flight to be
landed on.

Field A5. [Landing Limits]{.underline} --- 1,2, or 3 letters. L(L)(L)

Example: III

Landing qualification of the flight considering crew and equipment.
Possible values are I, II, and III.

Field T9. [Preferred Runway Arrival Time]{.underline} --- 6 digits.
Dddddd

Example: 1234

A runway arrival time (day, hour, minute) which when considered in
aggregate with other flights for that airline indicates the preferred
arrival sequence.

General Rules for Individual Flight Messages

The following rules apply to all individual flight message types.

Message Formatting

1\. Every message shall contain the following five fields. These five
fields will appear in order at the beginning of each message separated
by spaces.

a\. Message Type

b\. Call Sign

c\. Departure Airport

d\. Arrival Airport

e\. Local Departure Date

2\. Message fields shall be separated by one or more spaces (hex 20).

3\. Any fields in addition to the five mandatory fields shall be
explicitly identified by field reference number. The field reference
number shall precede the field value and be separated from the value by
a space (hex 20). For example, a Gate Departure Time would appear as:
**T1 101227**

4\. Multiple values within a field shall be separated by single slashes.
For example, a Preferred Runway specification would appear as: **A4
33R/33L**

5\. Optional fields which are not being included shall be omitted (i.e.,
there is no format for a blank field).

6\. A message may be continued on additional lines if too long to enter
on one line. A line continuation shall be indicated by a dash character
(hex 2D). The line continuation character shall appear as a separate
field and must be the last field on a line; i.e., it must be separated
from the preceding field by a space and followed by a new line sequence
(specified in item 10, below). A line continuation character is not
allowed in the middle of a field.

7\. The flight continuation indicator shall be the letter C appearing as
the last field on a message (The "C" must be separated from the previous
field by a space, as any other field is). The continuation symbol
indicates that the next message will create or modify a flight that
should get the rights to the arrival slot vacated by the flight
cancelled or modified in this message. The flight continuation character
shall appear as a separate field and must be the last field on a line;
i.e., it must be separated from the preceding field by a space and
followed by a new line sequence.

Message Packaging

8\. Flight messages shall be buffered into a single message for
transmission over ARINC. The ARINC message shall be called an FD (Flight
Data) message. An FD message may contain a variable number of the
individual flight messages specified below. (NOTE: This parallels the SI
message concept; an SI message contains a set of individual CNX, DLY,
and SUB messages.)

9.  The first line in an FD message (following the address lines
    provided by ARINC) shall include the message type (FD) followed by a
    unique packet identifier separated by one or more spaces, optionally
    followed by a return address. The packet ID shall consist of the
    three letter airline code, a 10 digit transmission date/time (month,
    day, hour, minute, second), and two digits for uniqueness (i.e., the
    extra two digits differentiate when multiple messages are generated
    in the same second). The format for the packet ID shall be:
    LLLddddddddd.dd. An example first line is:

FD SWA0206122217.01

A example first line with a return address is:

FD SWA0206122217.01 ABCDEFG

10\. A packet acknowledgement will be sent to the return address
provided by ARINC (i.e., the address from which the packet was sent)
unless an alternate return address is specified by the airline (the
third field in the packet header line). If an alternate return address
is specified, the acknowledgement will be sent only to that address.

11\. Messages within a packet shall be terminated by either a carriage
return/line feed combination (hex: 0D0A) or a single line feed (hex:
0A).

12\. Continuation messages (either flight or line continuations) must be
resolved within a single FD message. That is, the last message in an FD
cannot contain a continuation character.

13\. Maximum message length for an individual flight message shall be
1024 characters.

14\. Maximum length of an FD message shall be 32K (32,768) characters.
(NOTE: This maximum applies to the internal processing capability that
will be provided in ATMS. The actual message length might be limited due
to the communications medium. While we are using ARINC, the practical
limit is 1800(?) bytes.)

Acknowledgements and Errors

15\. ATMS shall positively acknowledge each FD packet. The
acknowledgement message will return the unique packet identifier, the
number of messages processed correctly, with errors, and with warnings.
These three numbers shall add up to the total number of messages
received in the FD packet. The message shall be formatted as in the
following example:\
\
FD SWA0206122217.01 processed. 21 OK, 0 errors, 0 warnings

16\. If ATMS does not encounter any processing errors in a packet, a
single line message (as shown in 15.) will be returned indicating the
packet was processed successfully.

17. If ATMS does encounter processing errors in an FD packet, a packet
    will be returned including the message(s) which caused the errors,
    and explanatory text describing the error. ATMS will generate an
    error whenever a flight message is not processed. Each message/error
    text pair will be separated by an extra linefeed for readability.
    The message shall be formatted as in the following example:\
    \
    FD SWA0206122217.01 processed. 19 OK, 2 errors, 0 warnings

FC AAL2824 LGA DFW 0206 03 B757 T3 061500 T4 061824

Error: Previous FC received for this flight

FC AAL2825 LGA ORD 0206 03 B759 T3 061500 T4 061824

Error: Unknown aircraft type

The full set of error messages will be provided later.

18. If ATMS generates any warnings processing an FD packet, a packet
    will be returned including the message(s) which caused the warnings,
    and explanatory text describing the warning. ATMS will generate
    warning messages only in cases where the flight message is processed
    but some condition is detected which the airlines should know about.
    Each message/error text pair will be separated by an extra linefeed
    for readability. The message shall be formatted as in the following
    example:\
    \
    FD SWA0206122217.01 processed. 20 OK, 0 errors, 1 warnings

FC AAL2824 LGA DFW 0206 03 B757 T3 061500 T4 061824

Warning: flight already exists in ATMS database (from OAG).

The full set of warning messages will be provided later.

Create Individual Flight Message

An individual flight shall be added to the ETMS database using a
*Create* message containing the following fields. By convention, the
variable fields shall be sent in the order specified below.

**NOTE:** Only the near--term fields have been listed below. Other
fields will be added in the future in an analogous manner.

Fixed Fields

Field 01 Message type = 'FC' --- Required

Field 02. Call Sign --- Required

Field 26. Departure Airport --- Required

Field 27. Arrival Airport --- Required

Field A1. UTC Departure Date --- Required

Variable Fields

Field 03. Aircraft Type --- Required

Field T1. Runway Departure Time --- Optional, but desired. Required if
Runway Arrival Time is present.

Field T2. Runway Arrival Time --- Optional, but desired. Required if
Runway Departure Time is present.

Field T3. Gate Departure Time --- Required

Field T4. Gate Arrival Time --- Required

Field T7. Earliest Runway Departure Time --- Optional

Field T8. Earliest Runway Arrival Time --- Optional

Examples:

FC TWA804 ORD JFK 0221 03 T/B727 T1 210918 T2 211109 T3 210900 T4 211117
T7 210918 T8 211115

FC AAL2824 LGA DFW 0206 03 B757 T3 061500 T4 061824

NOTES:

-   Additional fields will be added as new requirements arise. (NOTE:
    Any system which reads these messages should be implemented to
    ignore any fields whose reference numbers it does not recognize. In
    this manner, new fields can be added without causing a problem for
    existing applications or for older versions of applications.)

-   The flight continuation symbol is not allowed on an FC message.

-   The FC message is used to re--instate a flight that has previously
    been cancelled.

-   ATMS shall reject an FC if a previous FC or FM has already been
    processed for the same flight.

-   ATMS will use information from the FC message to overwrite OAG
    schedule information in the ATMS database, as long as it is the
    first message received from the airline for the flight.

-   ATMS will not use information from the FC to overwrite NAS flight
    plan data. Data which is not specified on the NAS flight plan
    (airline predicted departure and arrival times, earliest arrival and
    departure times) will be saved even if the flight already exists. A
    warning will be sent to the airline that the flight already exists
    in the database.

Modify Individual Flight Message

An individual flight in the ETMS database shall be modified by using a
*Modify* message containing the following fields in the indicated order:

Fixed Fields

Field 01 Message type = 'FM' --- Required

Field 02. Call Sign --- Required

Field 26. Departure Airport --- Required

Field 27. Arrival Airport --- Required

Field A1. UTC Departure Date --- Required

Variable Fields

field reference number

new value

field reference number

new value

etc.

Examples:

FM AAL2824 LGA DFW 0614 T6 141841

FM UAL123 ORD BOS 0221 02 UAL1234 03 B757

FM COA1630 ORF EWR 0111 27 PHL C

NOTES:

-   You may modify any field. (Field A1 should only be modified to
    correct a mistake).

-   If field 02, 26, 27, or A1 is modified, the new value will be used
    in the fixed portion of any subsequent message for that flight.

-   Fields T1 and T2 must always be specified as a pair in a modify
    message (i.e., if you change T1 you must include T2 and vice versa).

-   Fields T3 and T4 must always be specified as a pair in a modify
    message (i.e., if you change T3 you must include T4 and vice versa).

-   You may modify any number of fields in one message up to the maximum
    message length.

-   If the flight continuation symbol (C) is used, the next message must
    be an FC or FM for a flight arriving at the same airport as this
    flight.

-   The FM message (along with the FX message) will be used in the
    future to perform substitutions.

-   When modifying field 03, Aircraft Type, the entire previous
    specification will be replaced with the new value. For example, if
    the FC had a field 03 of T/B727, and a subsequent FM shows a field
    03 of B757, we will drop the TCAS indicator for that flight.

-   ATMS will not process an FM for a flight that is not already in the
    ATMS database, either through the OAG or an FC message.

-   ATMS will not use information from the FM to overwrite NAS flight
    plan data. Data which is not specified on the NAS flight plan
    (airline predicted departure and arrival times, earliest arrival and
    departure times) will be updated even if the flight already exists.
    A warning will be sent to the airline that the flight already exists
    in the database. It is the airlines responsibility to see that any
    changes are filed with NAS once the flight plan is filed.

-   By convention, the variable fields in a modify message will be
    specified in increasing numerical order (01, 02, \..., A1, A2, \...,
    T1, T2, \...). (This is to improve readability; for robustness, the
    software will recognize any ordering).

Cancel Individual Flight Message

An individual flight in the ETMS database shall be cancelled by using a
*Cancel* message containing the following fields in the indicated order:

Fixed Fields

Field 01 Message type = 'FX' --- Required

Field 02. Call Sign --- required

Field 26. Departure Airport --- Required

Field 27. Arrival Airport --- Required

Field A1. UTC Departure Date --- Required

Variable Fields

none

Examples:

FX AAL2824 LGA DFW 0614

FX COA 1630 ORF EWR 0111 C

NOTES:

-   If the flight continuation symbol (C) is used, the next message must
    be an FC or FM for a flight arriving at the same airport as this
    flight.

-   The FX message (along with the FM message) will be used in the
    future to perform substitutions.

Release Slot Message

An airline shall relinquish an arrival slot by using a *Release* message
containing the following fields in the indicated order:

**NOTE:** The FR message deviates from the requirement of the first five
fixed field, as the information provided does not apply to a specific
flight.

Fixed Fields

Field 01 Message type = 'FR' --- required

Variable Fields

Field A2. Assigned Arrival Slot --- required

Example:

FR A2 ORD061911A

NOTE:

-   The continuation symbol is not allowed on an Open message.

-   The FR message will not be processed during the initial
    implementation of Task 3.

Flight Schedule Messages

The flight schedule message have been deleted from this version of the
document to help maintain our focus on the near--term requirements. They
will be re--introduced at such time as is deemed necessary.