Document Title for the Traffic Flow Management ......ASDI) Interface Control Document (ICD) for the Traffic Flow Management-Modernization (TFM-M) Program TFMS-to-ASDI Interface Control

Final, Release 3, Revision 1

Contract Number: DTFAWA-04-C-00045 CDRL: E05

March 15, 2010

Prepared for: U.S. Federal Aviation Administration

Prepared by:

CSC North American Public Sector – Civil Group

15245 Shady Grove Road Rockville, MD 20850

Document Title for the Traffic Flow Management-Modernization (TFM-M) Program

Traffic Flow Management System-to-Aircraft Situation Display to Industry (TFMS-to-ASDI) Interface Control Document (ICD) for the Traffic Flow Management-Modernization (TFM-M) Program

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1

ii

Traffic Flow Management System-to-Aircraft Situation Display to Industry (TFMS-to-ASDI) Interface Control

Document (ICD) for the Traffic Flow Management-Modernization (TFM-M) Program

Final, Release 3, Revision 1

Contract Number: DTFAWA-04-C-00045 CDRL: E-5

March 15, 2010

Prepared for: U.S. Federal Aviation Administration

Prepared by:

CSC North American Public Sector – Civil Group

15245 Shady Grove Road Rockville, MD 20850


iii

CSC/TFMM-08/0473

Release 3 Final Revision 1 March 15, 2010

INTERFACE CONTROL DOCUMENT

APPROVAL SIGNATURE PAGE

TFMS/ASDI

APPROVAL SIGNATURES

PARTICIPANT NAME DATE


iv

Document History Record

Release Date Comment

Initial Draft September 21, 2007 Contractual delivery

Draft, Revision 1 November 22, 2007 Revised to address FAA comments received and

the following Change Request (CR):

TFMMP00003665

Final May 13, 2008 Revised to address FAA comments received and

the following CRs:

TFMMP00004365

TFMMP00006555

TFMMP00006131

Draft, Release 3 October 2, 2008 Contractual delivery

Revised Draft, Release 3 January 8, 2009 Delivery to address FAA comments.

Final, Release 3 August 24, 2009

Delivery to address FAA comments and the

following CR:

TFMMP00009761

Final, Release 3, Revision 1 March 15,2010

Delivery to address FAA comments and the

following CR:

TFMMP00028038


v

Table of Contents 1 Scope...................................................................................................... 1-1 1.1 Scope and Purpose ................................................................................ 1-1 1.2 Subsystem Responsibility List ................................................................ 1-1 1.3 Document Organization .......................................................................... 1-1 2 Applicable Documents ............................................................................ 2-1 2.1 Government Documents ......................................................................... 2-1 2.2 Non-Government Documents ................................................................. 2-2 2.3 Document Sources ................................................................................. 2-3 2.3.1 Source of FAA Documents ..................................................................... 2-3 2.3.2 Request for Comment (RFC) Documents ............................................... 2-3 2.3.3 ISO, IEEE, and ANSI Documents ........................................................... 2-3 2.3.4 ASDI Documents .................................................................................... 2-3 3 Interface Characteristics ......................................................................... 3-1 3.1 General Characteristics .......................................................................... 3-1 3.2 Functional Design Characteristics .......................................................... 3-2 3.2.1 Application Processes (APs) ................................................................... 3-2 3.2.1.1 Identification of Application Processes ................................................... 3-2 3.2.1.2 Category of Services Required by the AP ............................................... 3-2 3.2.1.3 Information Units ..................................................................................... 3-3 3.2.1.3.1 Information Code .................................................................................... 3-3 3.2.1.3.2 Information Structure .............................................................................. 3-5 3.2.1.3.2.1XML Data Packet Header ............................................................................ 3-5 3.2.1.3.2.2XML Data Packet Payload .......................................................................... 3-7 3.2.1.3.3 Information Unit Segmentation ............................................................. 3-11 3.2.1.3.4 Direction of Information Flow ................................................................ 3-11 3.2.1.3.5 Frequency of Transmission ................................................................... 3-11 3.2.1.3.6 Responses ............................................................................................ 3-11 3.2.1.4 Quality of Service .................................................................................. 3-11 3.2.1.5 AP Error Handling ................................................................................. 3-11 3.2.1.6 Interface Summary Table ...................................................................... 3-12 3.2.2 Protocol Implementation ....................................................................... 3-12 3.2.2.1 Application Services ............................................................................. 3-14 3.2.2.1.1 ASDI Registration Message .................................................................. 3-14 3.2.2.1.2 Filtering Protocols ................................................................................. 3-15 3.2.2.1.3 Data Clients .......................................................................................... 3-18 3.2.2.1.4 London Data ......................................................................................... 3-19 3.2.2.2 Network Services .................................................................................. 3-19 3.2.2.2.1 Data Compression ................................................................................ 3-20 3.2.2.3 Naming and Addressing........................................................................ 3-20 3.2.3 Security ................................................................................................. 3-20 3.2.4 Interface Design Characteristics Table ................................................. 3-20 3.3 Physical Design Characteristics ............................................................ 3-21 3.3.1 Electrical Power and Electronic Characteristics .................................... 3-22 3.3.1.1 Connectors ........................................................................................... 3-22


vi

3.3.1.2 Wire/Cable ............................................................................................ 3-22 3.3.1.3 Electrical Power/Grounding .................................................................. 3-22 3.3.1.4 Fasteners .............................................................................................. 3-22 3.3.1.5 Electromagnetic Compatibility ............................................................... 3-23 4 Verification Provisions............................................................................. 4-1 4.1 Responsibility for Verification .................................................................. 4-1 4.2 Special Verification Requirements .......................................................... 4-1 4.3 Verification Requirements Traceability Matrix (VRTM) ........................... 4-1 5 Preparation for Delivery .......................................................................... 5-1 6 Notes ...................................................................................................... 6-1 6.1 Definitions ............................................................................................... 6-1 6.1.1 Facility Identifiers .................................................................................... 6-1 6.1.2 ARTCC Identifiers ................................................................................... 6-3 6.2 Abbreviations and Acronyms .................................................................. 6-5 Appendix A XML Schemas ...........................................................................................A-1

List of Tables Table 3-I. TFMS-to-ASDI Interface Data Packets Table ............................................... 3-5 Table 3-II. TFMS-to-ASDI Interface Summary Table.................................................. 3-12 Table 3-III. ASDI Registration Message Format ......................................................... 3-14 Table 3-IV. Interface Design Characteristics of the TFMS-to-ASDI Interface ............. 3-21 Table 6-I. Facility Identifiers ......................................................................................... 6-1 Table 6-II. ARTCC Identifiers ....................................................................................... 6-4

List of Figures Figure 3-1. TFMS-to-ASDI Interface Block Diagram .................................................... 3-1 Figure 3-2. OSI Layer Functional Interface Connectivity Diagram for TFMS-to-ASDI 3-13 Figure 3-3. TFMS-to-ASDI Interface Physical Diagram .............................................. 3-22

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 RELEASE 3 FINAL, Revision 1 Scope

1-1

1 Scope

This section identifies the scope, purpose, and organization of this Interface Control

Document (ICD) and identifies the subsystem responsibility list.

1.1 Scope and Purpose

This ICD provides the design characteristics of the interface between the Traffic

Flow Management System (TFMS) and the Aircraft Situation Display to Industry

(ASDI). This ICD satisfies the interface design requirements contained in the Traffic

Flow Management System Interface Requirements Specification (IRS) for Traffic

Flow Management Modernization (TFM-M), Proposed Revision 2.2, August 5,

2008. This is a companion document to the CSC/TFMM-04/0025, Subsystem

Specification (SSS) for the Traffic Flow Management–Modernization (TFM-M)

Program, Baseline Revision 4.0 August 5, 2008. This ICD was prepared under

guidance from FAA-STD-025e, dated August 9, 2002 and the TFMM-ENGR-

05(E05), Traffic Flow Management Modernization (TFM-M), Data Item Description

(DID) for ICDs.

The purpose of this ICD is to specify:

Interface connectivity between the TFMS and the ASDI Vendors/Clients

Format of data transmitted from the ASDI to the TFMS

1.2 Subsystem Responsibility List

The following list provides the TFMS external system interface and identifies the

responsible Federal Aviation Administration (FAA) organizations:

TFMS - FAA-ATO

ASDI - FAA-ATO-R

1.3 Document Organization

This ICD is organized in six sections and appendix:

Section 1, Scope, describes the purpose and scope of this ICD.

Section 2, Applicable Documents, provides a listing of referenced government and

non-government documents, and document sources researched and used by this ICD.

Section 3, Interface Characteristics, identifies and describes the general, functional

design, and physical design characteristics for this ICD.

Section 4, Verification Provisions, contains verification provisions for this ICD.

Section 5, Preparation for Delivery, contains any specific preparations required by

this ICD.

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 RELEASE 3 FINAL, Revision 1 Scope

1-2

Section 6, Notes, provides a list of definitions, abbreviations, and acronyms used in

this ICD.

Appendix A, XML Schemas, describes the files which are provided as separate

XSD files.

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1 Applicable Documents

2-1

2 Applicable Documents

The following documents form part of this ICD to the extent specified herein.

2.1 Government Documents

FAA Standards:

FAA-STD-025e Preparation of Interface Documentation,

August 9, 2002

FAA-STD-039b Open Systems Architecture and Protocols, May 1, 1996

FAA-STD-043b Open System Interconnect Priority, 1996

FAA-STD-045 OSI Security Architecture, Protocol and Mechanisms,

1994

FAA Orders:

FAA Order 1370.82A Information Systems Security Program September 11,

2006

National Airspace System (NAS) Documents:

NAS-IR-24032410 Enhanced Traffic Management System (ETMS)

Interface Requirements Document (IRD) for Traffic

Flow Management Infrastructure (TFMI), Revision A,

September 16, 2005

NAS-IR-241400001 Traffic Flow Management System (TFMS) Interface

Requirements Document (IRD) for Traffic Flow

Management Modernization (TFM-M) Version 1.0,

August 14, 2006

NAS-MD-315 National Airspace System En Route Configuration

Management Document, Computer Program Functional

Specifications: Remote Outputs, Model A5f1.5,

October 4, 2004,

Request For Comments (RFC) Documents:

RFC 791 Internet Protocol, Sep 1981

RFC 793 Transmission Control Protocol, Sep 1983

RFC 3076 Canonical XML Version 1.0, Mar 2001


2-2

Other Government Documents:

ASDI-FD-001 Aircraft Situation Display to Industry: Functional

Description (FD) and Interface Control Document,

Version 5.4, November 15, 2005

ASDI ICD Aircraft Situation Display to Industry: Functional

Description and Interface Control Document for the

XML Version, Version 1.5, July 29, 2008.

ATO-W Federal Telecommunications Infrastructure (FTI) Operational Internet Protocol (IP) User’s Guide,

Version 3.1, Final Draft, March 2007

CSC/TFMM-04/0025 Subsystem Specification (SSS) for the Traffic Flow

Management–Modernization (TFM-M) Program,

Release3, Revision 5.0, May 19, 2009

CSC/TFMM-04/0048 Information Systems Security Plan (ISSP), Revision 2.2

for Traffic Flow Management–Modernization (TFM-

M), June 2, 2009

CSC/TFMM-05/0121 Interface Requirements Specification (IRS) for the

Traffic Flow Management – Modernization (TFM-M)

Release 3, Revision 2.3, May 19, 2009

CSC/TFMM-08/0473 Traffic Flow Management System-to-Airline Operation

Center Network (TFMS-to-AOCNET) Interface

Control Document (ICD), Release 3, Final, August 24,

2009

CSC/TFMM-08/0473 Traffic Flow Management System-to-Traffic Flow

Management Data to Government (TFMS-to-TFMDG)

Interface Control Document (ICD), Release 3 Final,

August 24, 2009

TFMM-ENGR-05(E05) Traffic Flow Management Modernization (TFM-M),

Data Item Description (DID), undated

2.2 Non-Government Documents

International Organization for Standardization (ISO):

ISO/IEC 7498-1 Information Processing Systems – Open Systems

Interconnect – Basic Reference Model, 1993


2-3

Institute of Electrical and Electronics Engineers (IEEE):

IEEE 802.3 IEEE Standard for Information Technology —

Telecommunications and Information Exchange

Between Systems, 2000

American National Standards Institute (ANSI):

ANSI X3.4 American National Standard Code for Information

Interchange (ASCII), REV. 1992

2.3 Document Sources

This subsection provides sources for FAA and International Organization for

Standardization (ISO) documents.

2.3.1 Source of FAA Documents

Copies of FAA specifications, standards, and publications may be obtained from the

Contracting Officer, Federal Aviation Administration, 800 Independence Avenue

S.W., Washington, DC, 20591. Requests should clearly identify the desired material

by number and date and state the intended use of the material.

2.3.2 Request for Comment (RFC) Documents

RFC documents are available from the reference area electronically at the following

Web address:

http://www.faqs.org/rfcs/

2.3.3 ISO, IEEE, and ANSI Documents

Copies of ISO, IEEE, and ANSI standards may be obtained from the American

National Standards Institute, 11 West 42nd Street, New York, NY, 10036.

2.3.4 ASDI Documents

The following web site contains current information about the ASDI feed. It also

includes the eXtensible Marhup Language (XML) schema definition files (XSD) and

sample ASDI XML data packages.

http://www.fly.faa.gov/ASDI/asdi.html

http://www.faqs.org/rfcs/http://www.fly.faa.gov/ASDI/asdi.html

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1 Interface Characteristics

3-1

3 Interface Characteristics

This section provides the general, functional, and physical interface characteristics

for the TFMS interface with ASDI Clients and Vendors.

3.1 General Characteristics

TFMS provides near real-time air traffic data to Vendors who are authorized by the

FAA to resell the data to downstream clients, and Clients who are direct users of the

ASDI data.

The heart of the ASDI feed is located at the Traffic Flow Management System

Production Center (TPC), located at the William J. Hughes Technical Center in

Atlantic City (WJHTC), New Jersey. This is the end system on the TFMS side. On

the ASDI side, the end systems are the various Vendor/Clients that interface with

TFMS for ASDI data.

Figure 3-1, TFMS-to-ASDI Interface Block Diagrams, illustrates the TFMS-to-ASDI

interfaces and the demarcation points. These are indicated as “Vendor/Clients’ in the

diagram below (and throughout the document) in the two interface diagrams (FAA

FTI ED-8 Gateway system and the AOCNET Wide Area Network (WAN)). Note,

there may be many clients of either type interfacing with the TFMS system.

Figure 3-1. TFMS-to-ASDI Interface Block Diagram


3-2

The Commercial Vendors/Clients communicate with the TFMS External Portal

Subsystem through either:

AOCNet/CDM Wide Area Network (WAN) (for more details, refer to

CSC/TFMM-08/0473, Traffic Flow Management System-to-Airline Operation

Center Network (TFMS-to-AOCNET) Interface Control Document (ICD)).

FAA’s FTI ED-8 gateway system. ED-8 provides a path for ‘untrusted’ and

‘partially trusted’ systems to have an interface to receive data. (Complete

information on the FTI ED-8 can be found in the FTI Operational IP User’s

Guide)

The demarcation points for these two interface types are switches contained within

the TFMS TPC. (Refer to Section 3.3 for full physical details)

The TFMS-to-ASDI interface has three different feeds of commercial

Vendor/Clients connected, as well as government feeds (designated Traffic Flow

Management to Government (TFMDG) and Federal BZ feeds) which are covered in

a separate ICD.

3.2 Functional Design Characteristics

This subsection describes the functional design characteristics of the TFMS and

ASDI.

3.2.1 Application Processes (APs)

This subsection identifies each application process and the applicable services,

including performance characteristics (information units, quality of service, error

handling, and responses).

3.2.1.1 Identification of Application Processes

The TFMS uses an AP called the External Portal Message Interface Server AP

contained within the External Portal Subsystem to receive and send data packets.

The corresponding ASDI AP is the ASDI Client AP, provided by the ASDI

Vendor/Clients.

3.2.1.2 Category of Services Required by the AP

The TFMS-to-ASDI interface is used to transfer flight data packets to authorized

ASDI clients via the following feeds:

ASDI – Class One London – This is a Filtered near-real time ASDI feed including London data. (Commercial feed)

ASDI – Class One noLondon – This is a Filtered near-real time ASDI feed without London data. (Commercial feed)

ASDI – Class Two noLondon Delayed – This is a Filtered delayed ASDI feed

without London data. (Commercial feed)


3-3

Filtering protocols are discussed in Section 3.2.2.1.2. The data transferred across the

TFMS-to-ASDI interface is detailed in Table 3-I below.

The following Message Types are transferred by the TFMS-to-ASDI interface:

Flow Control Amendment Information (AF) Message

Flow Control Arrival Information (AZ) Message

Departure (DZ) Message

Flight Plan Information (FZ) Message

Flight Management Information (RT) Message

Flow Control Cancellation (RZ) Message

Oceanic Report (TO) Message

Flow Control Track/Flight Data Block (TZ) Message

Flow Control Update (UZ) Message

Heartbeat Message

Loss of the TFMS-to-ASDI interface will impair full TFMS operation, but will not

degrade TFMS operations to the point of inoperability. Loss of the interface will

cause a significant impact to the ASDI Vendor/Clients utilizing the interface. This

interface is designated “essential” IAW NAS-SR-1000.

3.2.1.3 Information Units

This subsection describes the formats of the data files transferred from TFMS to

ASDI.

3.2.1.3.1 Information Code

All TFMS-to-ASDI interface data packets are encoded in eXtensible Markup

Language (XML). American Standard Code for Information Interchange (ASCII)

alphanumeric data format is used by XML in accordance with ANSI X3.4, American

National Standard Code for Information Interchange (ASCII).

The XML developed for the ASDI data feed is defined by XML Schema Definition

(XSD) files. These XSD files are used to describe and validate the elements used in

the XML documents sent over the ASDI data feed. The following schema definition

files are needed to validate, parse and process ASDI XML documents:

TFMS_XIS.xsd – The root schema, including all external interface schemas using the same name space.

ASDI.xsd – The schema definition representing all data transmitted over the ASDI interface.

MessageMetaData.xsd – The schema definition representing common header type information for external interfaces.


3-4

NasXCommonMessages.xsd – The schema definition describing common data sent and received over multiple TFMS interfaces (including ASDI.

NasXCoreElements.xsd – This schema definition describes all common element types used by NasXCommonMessages.xsd.

These XSD files were developed as part of the TFM-M program and as such contain

additional element/attribute definitions supporting multiple TFM-M data interfaces

and in some cases data is represented that will be available in future TFMM releases.

These XSD files will be attached to this interface control document.

There are a number of set procedures and data files for the XML format to provide

uniformity and coherence to all clients. The following are the basic rules:

The files contain only printable ASCII characters.

The file format follows standard XML structural conventions.

In XML terminology, the files are guaranteed to be:

o Valid – The XML file content matches the proper schema and documentation.

o "Well-Formed." - This means that every opening tag (i.e. - ) has a corresponding closing tag (i.e. - ), opening and closing tag pairs

are correctly matched and nested, and consistent capitalization is used.

Note - The first line of every file is the standard "" entry,

identifying the XML version number. This is the only tag which has no

corresponding close tag.

o Structured – The XML file consists of data element consisting of a pair of matching start and end tags, together with the data between them.

Elements can contain other elements, and are referred to as a container.

The container element is considered to be the ‘parent’ to the elements

contained within. Elements contained within the ‘parent’ container are

considered ‘child’ elements. Example:

...

All data is between matching start and end tags: data

A pair of matching start and end tags, together with the data between

them, is known as a data element or an element.

Characters that are not between matching start and end tags are ignored, .

They are and may be used occasionally for comments or enhancements of

clarity. Example:

This is data


3-5

This is a comment.

This is data

Data elements can be in any order within their container element's tag pair

(if element is a child of a parent element) or within the file (if an element

not acting as a container).

New-line characters between matching start and end tags are part of the

element's data.

3.2.1.3.2 Information Structure

The following subsections provide the detailed record layout of the products sent by

the ASDI. Table 3-I, TFMS-to-ASDI Interface Data Packets Table, presents the

TFMS-to-ASDI Interface Data Packets, including the subsection reference and

mnemonic.

Table 3-I. TFMS-to-ASDI Interface Data Packets Table

Product Name Product

Mnemonic ICD Subsection

XML Data Packet Header N/A 3.2.1.3.2.1

XML Data Packet Payload N/A 3.2.1.3.2.2

ASDI Registration Message N/A 3.2.2.1.1

The ASDI message consists of two distinct items:

The XML Data Packet Header – the uncompressed fixed length (32 byte) header in binary and standard ASCII format. (Refer to Section 3.2.1.3.2.1)

The XML Data Packet Payload – Variable length compressed data ‘payload’, consisting of multiple messages in a single XML formatted payload. (Refer to

Section 3.2.1.3.2.2)

3.2.1.3.2.1 XML Data Packet Header

The ASDI Data Packet Header consists of five fixed length fields:

Timestamp – 16 bytes, standard ASCII data

Data Type – 4 bytes, binary integer value

Sequence Number – 4 bytes, binary integer value

Compressed Size – 4 bytes, binary integer value

Decompressed Size – 4 bytes, binary integer value

All Clients must set their software to read these first 32 bytes. The data structure,

written in C, describes the components of this Header:


3-6

ASDI Data Packet Message Header Example

struct typedef xml_header_t

{

char timestamp[16];

int data_type;

int sequence_number;

int compressed_size;

int decompressed_size;

} xml_header_t;

The five fields of the Header are described below

Timestamp - The Timestamp indicates when the ASDI packet was transmitted. It is in the format YYYYMMDDhhmmss[null][null]:

o Y – Year (4 digits – Characters 1-4)

o M – Month (2 digits – Characters 5-6)

o D – Day (2 digits – Characters 7-8)

o h – Hour (2 digits – Characters 9-10)

o m – Minute (2 digits – Characters 11-12)

o s – Second (2 digits – Characters 13-14)

The time and date occupy the first fourteen places of the Timestamp. These

are followed by:

o Null character (1 byte – Character 15)

o Null character (1 byte – Character 16)

These characters are used to ensure proper alignment among the header

characters.

Data Type – There are two different types of ASDI Data Packets sent:

o Flight Data Payload – This is the flight data messages in XML format. The

Data Type field would read: #define XMLDataType 2

o Heartbeat Payload – This indicates that the Client that the ASDI feed is functioning even though no flight data is coming through. The Data Type

field would read: #define HeartBeatDataType 1

Sequence Number – Each ASDI data packet is given a sequential number, to allow Clients to keep track of packet reception. The range of possible numbers

is 0 through 100,000 (inclusive), but 0 is only used at initial program start. (If

the 100000 mark is reached, the sequence rolls over to the number 1, not 0)

Compressed Size – This tells the Client the size of the compressed data, allowing them to determine the capacity of the data buffer required to read the

payload. The files are compressed using the standard ‘gzip’ or similar

compression tools.

Decompressed Size – This tells the Client the size of the data after decompression, allowing them to determine the capacity of the data buffer


3-7

required to read the payload. The decompression returns the data payload to

XML format. The message must be decompressed prior to processing.

3.2.1.3.2.2 XML Data Packet Payload

Once decompressed, the ASDI XML payload is comprised of:

The Document Preamble – This starts off the message. It is comprised of:

o The Opening tag. Each ASDI XML data packet has an opening (“parent” level) XML tag of for each collection of container (‘child’

level) records, each noted with the tag . The maximum

number of messages following the preamble is determined by values

established prior to activating the ASDI feed. Refer to the attached XSD

files for full ASDI XML structure.

o XSD Tags – This is a series of XML tags, indicating what XSD files were used to construct the message. This allows the Client to use the correct

files when processing ASDI XML messages.

These files can be found in attachments to this document.

The Data Payload – Each payload is comprised of some number of ASDI messages. Each message begins and ends with the ASDI XML Tag:

ASDI XML message data

There may be multiple messages individually set out by ASDI Message

container tags, of any of the formats specified in the subsections below. Not

all Message types will be contained in every ASDI Data Packet.

The following subsections provide bulleted lists of the elements contained within

each message type. Refer to the attached ASDI XML and XSD files for a complete

detailing of these XML elements.

3.2.1.3.2.2.1 Flow Control Amendment Information (AF) Message

The Flow Control Amendment Information (AF) message provides revised flight

plan data whenever a flight plan is amended. It contains the following elements:

Aircraft Identification (ID)

Amendment Data

Departure Point

Destination

Field Reference


3-8

3.2.1.3.2.2.2 Flow Control Arrival Information (AZ) Message

The Flow Control Arrival Information (AZ) message is used to provide arrival date

and time information for all eligible arriving flights. It consists of the following

elements:

Aircraft ID

Arrival Time

Departure Point

Destination

3.2.1.3.2.2.3 Departure (DZ) Message

The Departure (DZ) message is transmitted for all eligible initially activated flight

plans when the activation is not from an adjacent NAS. It consists of the following

elements:

Departure Time (Actual or Estimated)

Aircraft ID

Aircraft Data

Departure Point

Destination

Estimated Time of Arrival (optional)

3.2.1.3.2.2.4 Flight Plan Information (FZ) Message

The Flight Plan Information (FZ) message is used to provide flight plan data for all

eligible flight plans. It consists of the following elements:

Aircraft ID

Aircraft Data

Assigned Altitude (Active) or Requested Altitude (Proposed)

Coordination Fix

Coordination Time

Route

Speed


3-9

3.2.1.3.2.2.5 Flight Management Information (RT) Message

The purpose of the Flight Management Information (RT) message is to provide data

from TFMS that is not otherwise available in other message. For example, this

message may contain the current prediction of wheels-up and wheels-down time for

a flight, where these predictions are based on all information available to TFMS. It

consists of the following elements:

Aircraft Category

Aircraft ID

Airways List

Arrival Fix Time (optional)

Center List

Controlled Arrival Time (optional)

Controlled Departure Time (optional)

Current Route

Departure Center

Destination

Estimated Time of Arrival (optional)

Estimated Time of Departure

Fix List

Flight Origin

Flight Status

Generated By Message Type

Original Gate Departure Time (optional)

Original Gate Arrival Time (optional)

Sector List

User Category

Waypoint List

3.2.1.3.2.2.6 Flow Control Cancellation (RZ) Message

The Flow Control Cancellation (RZ) Messages are used to provide cancellation data

for all eligible flight plans. It consists of the following elements:

Aircraft ID

Departure Point

Destination


3-10

3.2.1.3.2.2.7 Oceanic Report (TO) Message

A TO message is generated by TFMS when an oceanic position report is received

through NADIN. All transoceanic flights that are inbound from oceanic routes

provide these position reports each time they cross ten degrees of longitude. It

consists of the following elements:

Aircraft ID

Arrival Airport (optional)

Calculated Speed

Departure Airport (optional)

Planned Position Report 1 (optional)

Planned Position Report 2 (optional)

Reported Position Report

3.2.1.3.2.2.8 Flow Control Track/Flight Data Block (TZ) Message

Flow Control Track/Flight Data Block Information (TZ) message are used to provide

a position update along with other information used in a data block. TZ messages are

transmitted to TFMS on a cyclic basis on all flat-tracked and non-tentative free-

tracked eligible flight plans. It consists of the following elements:

Aircraft ID

Altitude

Ground Speed

Track Position Coordinates

3.2.1.3.2.2.9 Flow Control Update (UZ) Message

Flow Control Update Information (UZ) message are used to provide current flight

plan information on active eligible flights that enter an Air Route Traffic Control

Center (ARTCC). Generally speaking, a UZ payload is an ARTCC boundary

crossing message. The UZ payload is

transmitted by the receiving NAS En Route Center when the flight plan is eligible

for TFMS message transmission. It consists of the following elements:

Aircraft ID

Aircraft Data

Altitude

Boundary Crossing Point Inbound

Calculated Inbound Boundary Crossing Time

Route

Speed


3-11

3.2.1.3.2.2.10 Heartbeat Message (HB)

The ASDI Heartbeat message is sent from TFMS to the ASDI Vendors/Clients and

indicates the interface connection is still active even if no data is being sent. This

message is never combined with other ASDI XML message. It is always sent alone.

In the XML feed, the Heartbeat information is transmitted as a header only. It shows

a Data type of ‘1’, a Compressed Size of ‘0’, and a Decompressed Size of 0’’with a

unique data type indicating that it is an Heartbeat rather than XML data packet.

3.2.1.3.3 Information Unit Segmentation

Not applicable.

3.2.1.3.4 Direction of Information Flow

The information flow between the ASDI Client and TFMS is bi-directional. The

ASDI registration message flows from the ASDI client to TFMS to initiate traffic

flow. The XML Flight Data and Heartbeat data packets flow from TFMS to the

ASDI client.

3.2.1.3.5 Frequency of Transmission

The ASDI Registration message is transmitted only for initial connection. The

Heartbeat data packet is sent every 10 seconds. The other data packets frequencies

are transmitted as described in Section 3.2.2.2.1, according to the message

compression frequency described below.

When TFMS receives a message, it will hold it until either a defined number of

messages have arrived (m, which is currently set at 32 messages for optimum

compression and transmission size, but is a configurable parameter) or a defined

number of ¼ seconds (also designated ‘ticks’) have elapsed (s which is currently

determined as two ticks (½ second), but is a configurable parameter), whichever

occurs first. It then sends the accumulated messages as a data packet.

3.2.1.3.6 Responses

The ASDI Vendor/Client sends a registration message to begin data flow. There is

no response message; acceptance is indicated by the onset of the data flow.

3.2.1.4 Quality of Service

Not applicable.

3.2.1.5 AP Error Handling

For errors in registration, no data is sent until TFMS receives a valid registration

message. If TFMS has not received a legal registration message within 60 seconds

after the socket connection is made, it will close this socket. The Vendor/Client must

then resubmit a new ASDI Registration message to connect to the interface.


3-12

TFMS uses non-blocking write operations to the ASDI Clients, sending all data

packets in sequence. The standard interpretation of any missing data packets is that

they resulted from a buffer overflow forced by (1) the client’s not reading the data

packets fast enough or (2) the client’s communication link not being able to accept

the ASDI data feed fast enough.

Any write to a client that results in an error condition will cause ASDI to terminate

the connection. If the connection is terminated, the client must re-establish a

connection if it is to receive data. No data will be buffered for a disconnected client.

A ‘port filled’ or ‘no room in port’ condition is not considered to be an error. If

either of these conditions is returned when ASDI attempts to write to a socket, this

data is buffered, and a later attempt is made to re-transmit.

3.2.1.6 Interface Summary Table

An interface summary table (see Table 3-II below) shows the association between

the data packets that flow across the interface and the APs of the interfacing

subsystems. The left side of the interface summary table column lists the TFMS APs.

The center column contains the names of the data packets transferred, the reference

for each data packet, and the data flow direction. The right hand column lists the

ASDI APs.

Table 3-II. TFMS-to-ASDI Interface Summary Table

Subsystem A

TFMS AP Data Packet Data Flow Reference

Subsystem B

ASDI AP

External Portal

Message

Interface Server

ASDI Registration Message AB

ASDI FD/ICD

Ver 1.5, Section

6

ASDI Client AP

External Portal

Message

Interface Server

ASDI Data Packets AB

ASDI FD/ICD

Ver 1.5, Section

6

ASDI Client AP

External Portal

Message

Interface Server

ASDI Heartbeat Message AB

ASDI FD/ICD

Ver 1.5, Section

6

ASDI Client AP

3.2.2 Protocol Implementation

The TFMS to ASDI interface communications functions are implemented according

to OSI reference model as defined in FAA-STD-039b, Open Systems Architecture

and Protocols, and FAA-STD-043b, Open System Interconnect Priority.

Subsection 3.2.2 documents the OSI protocols implemented for each layer of the

interface. For the layers not used, this following text will be used "This layer is not

implemented within the TFMS-to-ASDI interface".

a. Application Layer (Layer 7) - This layer is not implemented within the TFMS-to-ASDI interface.


3-13

b. Presentation Layer (Layer 6) – This layer is not implemented within the TFMS-to-ASDI interface.

c. Session Layer (Layer 5) - This layer is not implemented within the TFMS-to-ASDI interface.

d. Transport Layer (Layer 4) - The TFMS-to-ASDI interface uses the TCP as its Transport layer protocol.

e. Network Layer (Layer 3) - The TFMS-to-ASDI interface uses the standard IP as its Network layer protocol.

f. Data-Link Layer (Layer 2) - The TFMS-to-ASDI uses the 100-baseT Ethernet standard in accordance with IEEE 802.3, IEEE Standard for Information

Technology — Telecommunications and Information Exchange Between

Systems, 2000 as the Data Link Layer

g. Physical Layer (Layer 1) - The TFMS-to-ASDI interface uses a standard Category 5 (Cat-5) Ethernet cable as its Physical layer protocol.

Figure 3-2, OSI Layer Functional Interface Connectivity Diagram for TFMS-to-

ASDI, gives a visual representation of the OSI layers and their structure.

Figure 3-2. OSI Layer Functional Interface Connectivity Diagram for TFMS-to-ASDI


3-14

3.2.2.1 Application Services

The interface between TFMS and the ASDI Vendor/Client’s software running on the

Vendor/Client’s premises is a standard TCP/IP socket. The redundant ASDI feeds

each listen separately on assigned IP addresses and port numbers for clients that

request to be registered to receive the data. The Vendor/Client is given these IP

addresses and port numbers (after it signs the ASDI memorandum of agreement with

the FAA) enabling the Vendor/Client to connect to one of the ASDI feeds.

TFMS sends identical ASDI data to all connected Vendor/Clients according to the

feed (Class One London, Class Two noLondon Delayed, etc). If necessary, TFMS

buffers packets for each connected Vendor/Client. This might happen in a case

where a Client is debugging their application or are doing some processing that

causes them to process the data stream slower than it is being written by the ASDI

Server. This buffer holds a configurable number of packets per Vendor/Client

(currently this is 32 packets, but this could change in the future).

3.2.2.1.1 ASDI Registration Message

All ASDI Vendors/Clients are required to register to receive data, using an ASDI

Registration Message. After a Vendor/Client opens a socket, it is given 60 seconds to

send an ASDI Registration to TFMS, containing the Vendor/Client name and

password. Once TFMS has received a valid registration message, the Vendor/Client

is said to be registered.

Table 3-III below specifies the format of the registration message, which contains a

Vendor/Client name and password. Each element of this message may be delimited

by one or more spaces. Spaces directly after an “=” sign are discarded and are not

considered part of the Client name or password. Registration message must be

terminated by a special character. The password and the termination character are

provided to the clients by TFMS Help Desk via secure out-of-band communication

methods before interface initiation. An out-of-band communication agreement is

an agreement or understanding that governs the semantics of the request/response

interface but which is not part of the formal description of the interface specification

itself. As an example, the password and the termination character to be used at the

end of the registration message will be conveyed to the clients via telephone

conversation.

Table 3-III. ASDI Registration Message Format

Field Function Unit/Format Description Bytes

Keyword ID Field ID Keyword specifying id

field. Static entry ID

2

= Field assignment

character

= Used to designate the data

following as the correct

entry for the ID field. Static

entry =

1

Name


3-15

Field Function Unit/Format Description Bytes

string> alphanumeric string, chosen

by the Vendor/Client. It

may include embedded

spaces.

, Separator . Field separator character.

Static entry (single period)

1

Keyword PASSWORD PASSWORD Keyword specifying

password field. Static Entry

PASSWORD

8

= Field assignment

character = Used to designate the data

following as the correct

entry for the Password

field. Static entry =

1

Password

a [a][a][a][a][a][a][a][a][a]

[a][a]

1 – 12 character

alphanumeric string.

1-12

TFMS sends identical data packet batches to all connected Clients. It buffers packets

for each connected Client, and will discard data if the Client’s buffer overflows.

(Currently, the buffer size is set at 32 packets, but is configurable.) TFMS uses the

following sequence to transmit messages to the registered Clients:

TFMS filters out any messages that are not allowed into the feed. (See Section 3.2.2.1.2 below)

TFMS removes any fields that are not allowed into the feed. (See Section 3.2.2.1.2 below)

TFMS adds a header to the data packet payload (See Section 3.2.1.3.2.1 above)

TFMS sends the filtered data packet batch to every client that is registered

3.2.2.1.2 Filtering Protocols

In all variants of the ASDI feed, some level of filtering is performed, to justify

inclusion or exclusion in one of the designated ASDI feeds. radiotelephony.dat

FilterCallSign.dat

IncludeInASDI.dat

FEDERAL_IncludeInASDI.dat

FEDERAL_FilterCallSign.dat

Radiotelephony.dat

For the filtered data, the following steps are performed to filter the data:


3-16

1. Check to see if the message is an allowed type. If not, e.g., the message is a BZ message, then the message is discarded; it does not go out in the ASDI

feed. If it is valid, continue to the next step.

2. Look at the code in the message that shows the facility that generated the message. If the code is not in the configuration file that specifies legal

facilities, then discard this message; it does not go out in the ASDI feed. If the

code is in this file, then continue to the next step. (Note: There are two feeds--

one that contains London data and one that does not. This configuration file

controls for each feed whether London data is included.)

3. Look at the aircraft call sign. If it is in the file FilterCallSign.dat, then discard this message; it does not go out in the feed. If the call sign is not in this file,

then continue to the next step.

4. Look at the aircraft call sign. If it is in the file IncludeInASDI.Dat, then it goes out in the ASDI feed. If it is not in the file, then continue to the next step.

5. Checks to see if the aircraft call sign is already in dynamic list of excluded military flights. If so, it is removed from the feed.

6. Check to see if the call sign starts with 'N' followed by a digit followed by a digit or letter. That is, check to see if the first three characters of the call sign

have the format 'Ndd' or ‘Ndl', where 'd' stands for digit and 'l' for letter. If so,

this is considered to be a General Aviation (GA) flight; it goes out in the

ASDI feed. If not, then continue to the next step.

7. Check to see if the call sign starts with 'LN' followed by a digit followed by a digit or letter. That is, check to see if the first four characters of the call sign

have the format 'LNdd' or ‘LNdl', where 'd' stands for digit and 'l' for letter. If

so, this is considered to be a lifeguard flight; it goes out in the ASDI feed. If

not, then continue to the next step.

8. Check to see if the call sign starts with 'TN' followed by a digit followed by a digit or letter. That is, check to see if the first four characters of the call sign

have the format 'TNdd' or ‘TNdl', where 'd' stands for digit and 'l' for letter. If

so, this is considered to be an air taxi flight; it goes out in the ASDI feed. If

not, then continue to the next step.

9. Check to see if the call sign is three letters followed by a digit. If not, the flight is considered to be military and is discarded; it does not go out in the

ASDI feed. If so, this is considered to be a commercial flight; continue to the

next step.

10. Check the first three letters of the call sign to see if they represent an airline for which messages are to be sent in the feed. (The Radiotelephony file,


3-17

which is maintained by the Air Traffic Control System Command Center,

specifies the airlines whose messages are to be included in the feed.) If not,

discard this message; it does not go out in the ASDI feed. If so, then this

message is included in the ASDI feed.

11. Check to see if the message is for a flight with a military aircraft type. (only FZ, DZ, UZ and some AF messages contain the aircraft type information). If

so, then the message is discarded; it does not go out in the ASDI feed and the

aircraft call sign is added to the dynamic list of excluded military flights.

Some message types, e.g., a TZ, do not have the aircraft type. The ASDI

Server handles this by remembering from previous messages that do have the

aircraft type, e.g., FZ, which call signs are associated with military aircraft.

The ASDI Server uses the aircraft_categories.map file to determine which

aircraft types are military.)

Filtering using these files provides the following feeds:

ASDI – Class One London – Commercial filtered near-real time ASDI feed including London data. This is provided to designated commercial clients.

(See Section 3.2.2.1.4 for how London data is defined)

ASDI – Class One noLondon – Commercial filtered near-real time ASDI feed without London data.

ASDI – Class Two noLondon Delayed– Commercial filtered delayed ASDI feed without London data

ASDI – Federal BZ – Government filtered delayed feed (Refer to TFMS-to-TFMDG ICD as listed in Section 2)

TFMDG – Government unfiltered undelayed feed (Refer to TFMS-to-TFMDG ICD as listed in Section 2)

TFMS provides the unfiltered base ASDI feed consisting of the following data

packets:

All of the NAS messages received by TFMS

All of the TZ messages from the Surface Movement Advisor (SMA) sites (TRACONS) received by TFMS

All of the TO messages generated by TFMS

All of the RT messages generated by TFMS

All Heartbeat messages

The filtered data runs through the steps above, filtering out specific kinds of data

(Note – The rules for filtering out sensitive flights are set conservatively, in the sense

that some flights that are not truly sensitive are filtered out. For example, most

messages on GA flights registered in countries other than the U.S. and Canada are

filtered out.):


3-18

The only message types currently allowed into the filtered ASDI data stream are AF, AZ, DZ, FZ, RZ, TZ, UZ, RT, TO, and HB messages.

Messages on sensitive flights (such as military flights) are filtered out.

Messages from certain facilities or regions are filtered out. Currently messages are included from facilities in the United States, Canada, and the

United Kingdom.

All Vendor/Clients who connect to TFMS for the same variant of the feed receive

exactly the same data, for the feed they have selected. For example, all ASDI Class

One London clients will receive the same unfiltered, undelayed data, including

London data, while all Class Two noLondon Delayed data would receive filtered

data with no London data at a specified delay rate.

3.2.2.1.3 Data Clients

When the ASDI feed was first established, data was sent out to all Vendor/Clients in

near real-time, i.e., with a delay that in practice was a few seconds. For security

reasons, it was determined that this near real-time feed was unnecessary for all

Vendor/Clients. It was then split into two Classes of commercial feed with one Class

of government Clients (This was later again divided into Federal BZ and TFMDG

Clients)

Commercial Class One Clients:

It was determined that undelayed ASDI data for commercial Vendor/Clients should

only go to those organizations with an established flight dispatch or planning

function that requires near real-time data. Some examples of Class One

Vendor/Clients are:

Air carriers

Regional air carriers

Air taxis

Organizations providing dispatch or tracking functions for aircraft owners

Flight operation centers

Professional flight planning service organizations.

There are two commercial varieties of the Class One data feed: London and

noLondon. See Section 3.2.2.1.4 for how London Vendor/Clients are authorized.

A Vendor that has both Class One and Class Two users will be allowed to get both

feeds. These Vendors are then obligated by the Memorandum of Agreement (MOA)

signed with the FAA to provide the undelayed feed only to Class One downstream

users. The FAA requires that a Vendor that receives an undelayed feed be audited

annually at the Vendor’s expense to verify that they are providing undelayed data

only to Class One downstream users. (Procedures for a Vendor/Client to gain

permission to receive Class One data can be found in Aircraft Situation Display to


3-19

Industry: Functional Description and Interface Control Document for the XML

Version, Version 1.5, Section 4.6.1.1)

Commercial Class Two Clients:

Any other commercial agency not requiring this near-real time data is designated a

“Class Two” Vendor/Client. Class Two Vendors receive the feed with a delay.

Examples of Class Two Vendor/Clients would be:

Most general aviation

Non-aviation related industries

A Vendor who has Class Two users will only be allowed to get a delayed ASDI feed.

The FAA retains the option of changing the amount of delay, which is currently set

at 5 minutes.

3.2.2.1.4 London Data

The British authorities have placed a requirement on the FAA to restrict distribution

of the data provided to TFMS for the ASDI feeds. Therefore, TFMS applies filtering

to remove this data, restricting the distribution to only the designated Class One

London Vendor/Clients.

It is required that a Vendor/Client only receives the London data if it satisfies one or

both of the following conditions:

It is an air carrier, including cargo carriers.

It owns and operates aircraft in Europe, and, therefore, pays landing fees and air traffic control fees in Europe.

If a Vendor/Client satisfies at least one of these conditions, it is designated an

approved recipient of the London data. If a user does not fulfill at least one of these

two conditions, then that user is not allowed to receive any of the London data, and

must then receive one of the other data feeds. (Procedures for a Vendor/Client to

gain permission to receive London data can be found in Aircraft Situation Display to

Industry: Functional Description and Interface Control Document for the XML

Version, Version 1.5, Section 4.5.1.1 and 4.5.1.2)

London data is identifiable in the data packets transferred to Vendor/Clients. Each

data packet on the ASDI feed has four characters that indicate the facility that

generated the message (designated by the sourceFacility attribute of the asdiMessage

element). If this XML tag contains the coding ‘LLON’, then this packet is from

London and must be filtered from all noLondon feeds. If these four characters are

anything else, then this packet is not from London and can be included in all feeds.

3.2.2.2 Network Services


3-20

The TFMS-to-ASDI interface uses the established standards of Transmission Control

Protocol (TCP) in accordance with RFC 793, Transmission Control Protocol, and

Internet Protocol (IP) in accordance with RFC 791, Internet Protocol.

3.2.2.2.1 Data Compression

Aside from using XML instead of ASCII, there is one other significant change in the

XML version of the ASDI feed: compression. The reason for using compression is

that, while XML is easy to read by human and machine interpreters, it achieves this

by using tags that significantly increase the amount of transmitted data. If

compression were not used, the bandwidth required to carry the ASDI feed would at

least triple, which is not desirable.

Compression follows the following process.

When it is time to send the accumulated messages’ data packet, TFMS will convert them to XML format and compress the converted data using gzip,

creating a data payload.

TFMS will prefix a header of fixed size to the zipped payload to provide the information needed to read and unzip it. (See the next section for discussion of

this header.)

TFMS will transmit the header and payload.

The Vendor/Client will read the fixed header and determine the size of the payload of data packets.

The Vendor/Client will then read the entire zipped packet and unzip it.

The Vendor/Client processes these unzipped XML data.

3.2.2.3 Naming and Addressing

This interface supports the transfer of the ASDI data headers data packet payload

listed above in accordance with the Aircraft Situation Display to Industry: Functional

Description and Interface Control Document for the XML. Details on how headers

are addressed are contained in Section 3.2.1.3.2.1.

3.2.3 Security

TFMS implements FAA information security guidelines in accordance with

Information Systems Security Plan (ISSP) for Traffic Flow Management–

Modernization (TFM-M), the FAA Information Systems Security Program, FAA

Order 1370.82A, and FAA-STD-045, OSI Security Architecture, Protocols and

Mechanisms. It will enact security strategies and measures on all incoming

information into TFMS.

3.2.4 Interface Design Characteristics Table

Subsection 3.2.4 summarizes the interface functional design characteristics in an

interface design characteristics table or matrix in addition to the text. Table 3-IV, the


3-21

Interface Design Characteristics Table of the TFMS-to-ASDI Interface serves as a

"quick-look" reference.

Table 3-IV. Interface Design Characteristics of the TFMS-to-ASDI Interface

Message Name Format

Size

Max/Min (Bytes)

Time Constraints

Frequency

Source: Aircraft Situation Display to Industry: Functional Description and Interface

Control Document for the XML Version (Refer to Section 2 for full document detail)

ASDI Registration Message ASCII 15/105 Must be sent

within 60

seconds of

opening socket

Upon

registration

ASDI Data Packet Header ASCII/

Binary

32 With each

data payload

packet

ASDI Data Packet XML/

ASCII

* At least every

½ second

Heartbeat Data Packet Header ASCII/

Binary

32 Every 10

seconds

*Note – The maximum size of the data packet is variable. If necessary, the system will buffer a

maximum 32 data packets.

3.3 Physical Design Characteristics

For Commercial Vendor/Clients, there are two ways to interface with the TFMS

system to receive ASDI data (depending on the AOCNET Participant):

ASDI Vendor/Clients using the AOCNET WAN interface with the Dataprobe WAN Fallback Switch (designated AB-TAPS) for the physical interface. The

data flows through the Cisco 7206 Router/Switch (designated EXTRTR) which

acts as a gateway to the subsystems of the TFMS. The data is passed through

the Firewall into the External Portal Message Interface Server, an HP PorLiant

DL380 (designated PRSR_3). The physical demarcation point is the AB-TAPS

switch

ASDI Vendor/Clients not using the AOCNET WAN system interface via the FAA FTI ED-8 Gateway system. This is an ‘untrusted’ system (Vendor/Clients

are considered ‘outside’ the FAA security area). The ASDI Vendor/Client

connects to ports on the two Cisco Catalyst 3560G switches (designated

SWPT_4) on the TPC side of the interface. The data flows through the Cisco

7206 Router/Switch (designated EXTRTR) and follows the same path into the

TFMS subsystems as the as in the previous bullet. The physical Demarcation is

at the SWPT_4 switch.

Note – the Demarcations for all forms of the interface are designated by encircled

dots on their line ends.


3-22

See Figure 3-3 below for the Physical diagram of the TFMS-to-ASDI interface.

Figure 3-3. TFMS-to-ASDI Interface Physical Diagram

3.3.1 Electrical Power and Electronic Characteristics

Not applicable.

3.3.1.1 Connectors

The TFMS-to-ASDI interface using the AOCNET WAN employs a standard RS-232

connector as the interface connection. Standard RS-232 pin assignments are used in

this case.

The TFMS-to-ASDI interface using the FTI ED-8 Gateway uses a standard RJ-45

Ethernet connection connector as the interface connection in all instances. Standard

RJ-45 pin assignments are used in this case.

3.3.1.2 Wire/Cable

Standard RS-232 communication cable is used for the TFMS-to-ASDI interface

instances using the AOCNET WAN.

Standard Cat-5 Ethernet cabling with R-J45 connectors are is used in all instances of

for the TFMS-to-ASDI interface instances using the FTI ED-8 Gateway.

3.3.1.3 Electrical Power/Grounding

Not applicable

3.3.1.4 Fasteners

Not applicable


3-23

3.3.1.5 Electromagnetic Compatibility

Not applicable

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1 Verification Provisions

4-1

4 Verification Provisions

4.1 Responsibility for Verification

Following are verification provisions for the TFMS-to-ASDI interface:

1. Each project is required to perform conformance testing.

2. Each project is required to perform interoperability testing at an FAA-approved test facility.

3. Noninterference testing will be conducted on the TFMS-to-ASDI interface.

4.2 Special Verification Requirements

Not applicable

4.3 Verification Requirements Traceability Matrix (VRTM)

Not applicable

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1 Preparation for Delivery

5-1

5 Preparation for Delivery

Not applicable.

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1 Notes

6-1

6 Notes

6.1 Definitions

6.1.1 Facility Identifiers

Table 6-I provides the facility identifiers used to label the origin (source facility) of

NAS messages. Note that the identifiers representing the departure facility and

centers in the Flight Management Information (RT) message use 3 character codes

that are described in Table 6-II. Table 6-I is broken out as follows:

The first column shows the four character identifier used in the ASDI feed. The

ASDI feed represents each facility with a four character identifier, which is right

justified and filled with leading blanks if necessary. These IDs, especially the

TRACON and foreign IDs, are tentative. In some cases, facilities that provide

multiple data sources will have the same facility identifier (i.e., ZAN EARTS and

ZAN OCS).

Following the identifier is a brief description of the facility that generated the

message.

Note - ODAPS stands for the Oceanic Display and Planning System, which provides

NAS messages other than TZs on oceanic flights; position updates on oceanic flights

are in the TO message.

Table 6-I. Facility Identifiers

ASDI ID Facility Name

KZAB Albuquerque Center

KZBW Boston Center

KZOB Cleveland Center

KZDV Denver Center

PZAN Anchorage Center

PZAN Anchorage Center

KZFW Fort Worth Center

KZAU Chicago Center

KZHU Houston Center

KZID Indianapolis Center

KZJX Jacksonville Center

KZKC Kansas City Center

KZLA Los Angeles Center

KZME Memphis Center

KZNY New York Center


6-2


KZOA Oakland Center

KZMP Minneapolis Center

PZHN Honolulu, Hawaii (NAS TZ only)

KZMA Miami Center

KZSE Seattle Center

KZTL Atlanta Center

KZLC Salt Lake Center

PZLB American Samoa (No data)

KZDC Washington (D.C.) Center

ETMS RT message generated by ETMS

TZSU San Juan, Puerto Rico

KF90 Boston TRACON (TZ only)

KCVG Cincinnati TRACON (TZ only)

KDEN Denver TRACON (NAS TZ only)

PZAN Anchorage AK (ODAPS)

KDFW Dallas/Fort Worth TRACON (NAS TZ only)

KC93 Chicago TRACON (TZ only)

KIND Indianapolis TRACON (TZ only)

KSDF Louisville TRACON (TZ only)

KMCO Orlando TRACON (TZ only)

KGTW Gateway (St. Louis) TRACON (NAS TZ only)

KPHX Phoenix TRACON (TZ only)

KMES Memphis Tracon (SMA TZ only)

KN90 New York TRACON (NAS TZ only)

KOOA ODAPS Oakland (AF, AZ, DZ, FZ, RZ, UZ only)

KPHL Philadelphia TRACON (TZ only)

PZUA Guam

KTPA Tampa

KA80 Atlanta TRACON (NAS TZ only)

KNCT Northern Cal TRACON (NAS TZ only)

KONY ODAPS New York (AF, AZ, DZ, FZ, RZ, UZ only)

KPCT Potomac TRACON (NAS TZ only) (No data)

ETMS TO message generated by ETMS

KMSP Minneapolis TRACON (NAS TZ only)

KSCT Southern California TRACON (NAS TZ only)

YOWT CANADA OTHER


6-3


CCZX GANDER

CCZM MONCTON

CCZU MONTREAL

CCZY TORONTO

CCZW WINNIPEG

CCZE EDMONTON

CCZV VANCOUVER

LLON LONDON

KA8S Atlanta TRACON (SMA TZ only)

KF9S Boston TRACON (SMA TZ only)

KC9S Chicago TRACON (SMA TZ only)

KCLS Charlotte TRACON (SMA TZ only)

KDFS Dallas-Ft. Worth TRACON (SMA TZ only)

KDTS Detroit TRACON (SMA TZ only)

KSDS Louisville TRACON (SMA TZ only)

KMSS Minneapolis TRACON (SMA TZ only)

KN9S New York TRACON (SMA TZ only)

KPHS Philadelphia TRACON (SMA TZ only)

KPIS Pittsburgh TRACON (SMA TZ only)

KGTS St. Louis TRACON (SMA TZ only)

6.1.2 ARTCC Identifiers

The Facility Identifiers listed above in Table 6-I correspond to the logical locations

which send NAS messages. The ARTCC codes listed in this section correspond to

actual physical areas containing airports and airspaces, and are associated with the

departure center, as well as the centers the flight traverses. Many of the one

character codes in the two tables are the same, but there are some in each table which

are not in the other.

Note that for international flights, the foreign centers may be artificially generated as

one of the listed codes for London/Europe, South America, Pacific/Australia, etc.

since the actual foreign centers may not be known or recognized.

The table is broken out as follows:

The first column contains the three character code used in ASDI XML feed.

The second column is a brief description of the ARTCC center corresponding to

the code.


6-4

Table 6-II. ARTCC Identifiers


CZE Edmonton, Alberta

CZM Moncton, New Brunswick

CZU Montreal, Quebec

CZV Vancouver, British Columbia

CZW Winnipeg, Manitoba

CZQ Gander Domestic, Newfoundland

CZY Toronto, Ontario

CZX Gander Oceanic, Newfoundland

ZAB Albuquerque, New Mexico

ZAN Anchorage, Alaska

ZAU Aurora, Illinois (Chicago)

ZBW Boston, Massachusetts

ZDC Washington, District of Columbia

ZDV Denver, Colorado

ZEU London (and Europe and India)

ZFW Dallas/Fort Worth, Texas

ZHN Honolulu, Hawaii

ZHU Houston, Texas

ZID Indianapolis, Indiana

ZJX Jacksonville, Florida

ZKC Kansas City, Missouri

ZLA Los Angeles, California

ZLB American Samoa

ZLC Salt Lake City, Utah

ZMA Miami, Florida

ZME Memphis, Tennessee

ZMP Minneapolis, Minnesota

ZMX Mexico

ZNY New York, New York (Inland Section)

ZOA Oakland, California

ZOB Oberlin, Ohio (Cleveland)

ZPA Pacific and Australia

ZSA South America

ZSE Seattle, Washington

ZSU San Juan, Puerto Rico


6-5


ZTL Atlanta, Georgia

ZUA GUAM

ZCA Central America

ZCX Chile

ZCO Colombia

6.2 Abbreviations and Acronyms

This section provides a definition of acronyms contained within this ICD.

ANSI American National Standards Institute

AOCNET Airline Operations Center Network

AP Application Process

ARTCC Air Route Traffic Control Center

ASCII American Standard Code for Information Interchange

ASDI Aircraft Situation Display to Industry

DID Data Item Description

ETA Estimated Time of Arrival

ETMS Enhanced Traffic Management System

FAA Federal Aviation Administration

FD Functional Description

FTI Federal Telecommunications Infrastructure

GA General Aviation

HB Heartbeat

ICD Interface Control Document

ID Identification

IEC International Electro-technical Commission

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

IRD Interface Requirement Document

IRS Interface Requirement Specification

ISO International Organization for Standardization

ISSP Information Systems Security Plan

LLON Identifier for the London Data

MD Management Document

MOA Memorandum of Agreement


6-6

NADIN National Airspace Data Interchange Network

NAS National Airspace System

ODAPS Oceanic Display and Planning System

OSI Open Systems Interconnect

REV Revision

RFC Request For Comments

SMA Surface Movement Advisor

SSS System/Subsystem Specification

STD Standard

TCP Transmission Control Protocol

TFM Traffic Flow Management

TFMDG Traffic Flow Management Data to Government

TFMI Traffic Flow Management Infrastructure

TFM-M Traffic Flow Management - Modernization

TFMS Traffic Flow Management System

TPC Traffic Flow Management System Production Center

TRACON Terminal Radar Approach Control Center

VRTM Verification Requirements Traceability Matrix

WAN Wide Area Netork

WJHTC William J Hughes Technical Center

XML eXtensible Markup Language

XSD XML Schema Definition

TFMS-to-ASDI Interface Control Document CSC/TFMM-08/0473 March 2010 Release 3 FINAL, Revision 1 Appendix A

A-1

Appendix A XML Schemas

The following XML schema files are provided as separate XSD files. They are:

1. ASDI.xsd

2. MessageMetaData.xsd

3. NasXCommonMessages.xsd

4. NasXCoreElements.xsd

5. TFMS_XIS.xsd

These files are also available on the Internet at the following FAA site:
