From: \"Howard, Ken (CSC/Arcon)\" \<HOWARDK@volpe5.dot.gov\>

To: CDM Workgroup \<cdm@vivaldi.metsci.com\>

Subject: SMA Interface Control Document

Date: Wed, 25 Nov 98 11:12:00 EST

CDMers,

Several months ago CDM was approached by the SMA program office who were

looking for an easy way to ship data to the AOCs. They had heard that
the

CDMNET was the way to go. We assured them that it was, and initiated an

effort to provide a conduit for shipping SMA data to interested
airlines.

The first step of this data feed is to provide ARTS tracking data from
two

TRACONs, Philadelphia and Detroit. This is targeted for December this
year.

Given the short time frame, we defined a simple protocol that will allow
an

interested user to connect over the CDM net and get the raw SMA ARTS
data.

The protocol and data content is defined in the attached SMA Interface

Control Document (ICD).

We hope that this is only a first step of \"integrating\" SMA data. We
are

looking at the possibility of follow-ons, such as incorporating the ARTS

tracking data in the ASDI feed, and getting other useful data from SMA.
The

likelihood of these happening is greater, we hope, now that the door is

ajar.

As always, any and all feedback is welcome.

Ken

DRAFT

Interface Control Document

for SMA-ARTS Data

November 2, 1998

Prepared by:

Ken Howard

Dave Reiser

Volpe National Transportation System Center

Kendall Square

Cambridge, Massachusetts 02142

Interface Control Document for SMA ARTS Data

# 1. Introduction

The FAA's Surface Movement Advisory system (SMA) has been operating as a
prototype for several years in Atlanta. It is soon due to go on-line at
two new airports: Detroit and Philadelphia. As part of the SMA
development, an agreement was made to provide SMA data to authorized air
carriers (these will be referred to as *users*). The first step of this
data feed is provide filtered ARTS tracking data from Philadelphia and
Detroit to the users by December 31, 1998. This data is referred to in
this document as *SMA-ARTS data.*

The Collaborative Decision Making (CDM) project is an on-going
development effort by the FAA and participating air carriers. As part of
the initial CDM capabilities, a data distribution infrastructure, known
as CDMNET, has been developed for exchanging data between certain
airline operating centers (AOCs) and the FAA. The CDM data distribution
system has a hub and spoke architecture, with the hub being implemented
at the Volpe National Transportation System Center (Volpe). AOCs connect
to the CDM hub using communications capabilities provide by third party
vendors; this capability is referred to as the CDMNET. The CDM
infrastructure will be used to make the SMA-ARTS data available to the
users.

# Scope

This ICD defines the interface that an authorized user must use to
acquire SMA-ARTS data. This interface supports only the ARTS tracking
data defined herein. The user is responsible for providing the
communications connectivity and client software that meets this
protocol. The ICD includes:

-   Technical Requirements

-   Communications Protocol

-   Message Formats

-   ARTS Data Content and Frequency

# Overview

The SMA-ARTS data will be distributed in the following manner. The FAA
SMA systems resident at the TRACONs will acquire the tracking data from
the ARTS IIIA system. The SMA systems will filter the data (primarily to
remove military flights) and transmit that data to a server at Volpe
over dedicated communication lines. The SMA data server at Volpe will
relay the data to any connected users.

Users will get the SMA-ARTS data using a simple protocol based on TCP/IP
sockets. The user's client software will open a socket to the SMA data
server and keep that connection open as long as the user wants data. The
SMA data server will send ARTS data packets to the client as long as the
connection is open. All data (i.e., data from all participating airport
facilities) will be sent to each client. The client terminates the data
feed simply by closing the connection.

SMA-ARTS will be a real-time, non-buffered data feed; that is, when a
client connects, the SMA data server will only transmit any new ARTS
data received. If, for example, a client disconnects and re-connects,
the client will lose any data processed by the server during the time it
was disconnected.

In the descriptions below, the *client* is the user software that is
acquiring the data; the *server* is the Volpe software running at the
hub that is providing the data.

# Technical Specifications

### Technical Requirements

In order to acquire SMA ARTS Data, a user must:

1.  Have a communications link that provides TCP/IP capability between
    the user site and the CDM hub at Volpe.

2.  Develop or otherwise acquire client software that follows the
    protocol prescribed below.

### Communications Protocol

The sequence of steps for acquiring SMA ARTS data is as follows:

1.  The client opens a TCP/IP socket connection to the SMA data server
    using a well-known IP address and port number.

2.  The client transmits a registration message.

3.  The server validates that the client is authorized.

4.  The server begins transmitting SMA-ARTS data packets to the
    authorized client.

5.  The client terminates the data stream by closing the socket
    connection to the server.

NOTE: The SMA data server does not require or expect an acknowledgment
from the client for data packets.

A request-reply protocol is used to assure that all client connections
are viable in the following manner:

1.  Periodically, the SMA data server sends a *reply request* message to
    each client.

2.  Each client responds immediately with a *reply response* message.

3.  If the SMA data server does not receive a *reply response* message
    from a client within 30 seconds, it will terminate the data feed to
    that client and close the socket connection.

The SMA data server also supports the client-side of the request-reply
protocol. It is recommended that the client software make use of it.

The SMA data server continues to feed SMA-ARTS data to a client until
any one of the following conditions is met:

1.  The server receives notification that the socket has been closed
    (presumably by the client).

2.  The server cannot write to the socket for 30 seconds.

3.  The server does not receive a response to a *reply request* within
    30 seconds.

Every effort will be made to keep the data server running on a
continuous basis. However, it is inevitable that the server, or the
communications, will experience a failure. It is incumbent on the client
to ensure that its connection to the server is viable. If the client
experiences a failure, it should immediately close the connection and
begin periodic attempts to re-connect.

### Message Formats

Messages exchanged between the clients and the SMA data server all
follow a consistent format. SMA messages consist of a header optionally
followed by data, depending on the message type. All messages are ASCII
text.

The SMA-ARTS message header contains four lines of ASCII text. Each line
is terminated by a *newline* character (octal 012). The message header
block is terminated by an additional *newline*.

Each line in the header contains a field identifier followed by a ':'
followed by a value or values for that field. No single line may contain
more than 1024 characters including the *newline* at the end. The four
field identifiers used in SMA headers are as follows. The field
identifier for each is shown in parentheses.

1.  Message type (type) -- Indicates what type of message this is. This
    field is always required

2.  Client identifier (client_id) -- A unique string assigned to the
    client.

3.  Optional data fields (options) -- Data fields particular to the
    delivery of a message; for example, a future use might be
    BOUNDARY=EOF indicating that a message is string delimited rather
    than by a byte count.

4.  Number of bytes of following data (byte_count) -- If this message is
    a data packet, the number of bytes of following data that should be
    expected in that packet.

The specific message types are described in the following sections.

#### *Register Message (client to server)*

A register message consists of a header only. The message type is
*register SMA*. A register message must be the first message sent by the
client when a connection is established with the server. A sample
registration header is as follows:

> type: register SMA\
> client_id: ABC1234\
> options:\
> byte_count: 0

NOTE: The client ID will be assigned by Volpe.

#### *ARTS Data Message (server to client)*

An ARTS data message consists of a header followed by a block of data.
The message type is *ARTS data.* The byte count indicates how many bytes
of data follow the header. A sample ARTS data message is as follows:

> type: ARTS data\
> client_id: ABC1234\
> options:\
> byte_count: 225
>
> MSP,UAL387,1467,0,-6.5,-2.0,261.1875,28.875,4500,12345678,B747,ARR-MSP,ARTS
>
> MSP,FFT128,605,1,14.3125,35.4375,232.8125,457.75,4500,12345678,B747,ARR-MSP,ARTS
>
> MSP,VGD405,6560,0,28.75,0.4375,416.6875,40.6875,4500,12345678,B747,DEP-MSP,ARTS

Note that the header is separated from the data packet by one blank
line; this is the extra *newline* required to terminate the header. The
*byte_count* field specifying the number of bytes in the data packet
does NOT include the extra newline that terminates the header (i.e.,
byte 1 of the data packet is "M").

The content of the ARTS data packet is described in the last section of
the document.

#### *Reply Request Message*

A reply request message consists of a header with an optional attached
data block. The message type is *reply request*. A reply request message
is sent by the server to verify that the client is still connected and
responding. It can also be sent by the client to verify that the server
is still viable. The recipient of this message is obligated to reply
with a reply response message. Any data attached to the reply request
must be extracted and attached to the reply response. A sample reply
request header is as follows:

> type: reply request\
> client_id: ABC1234\
> options:\
> byte_count: 10
>
> 123456789

#### Reply Response Message 

A reply response message consists of a header only. The message type is
*reply response*. A reply response message is sent by either the server
or the client in response to a reply request message. A sample reply
response header is as follows:

> type: reply response\
> client_id: ABC1234\
> options:\
> byte_count: 10
>
> 123456789

### ARTS Data Content and Frequency

The ARTS tracking data includes track updates for flights arriving at or
departing from the airport identified in the data message header. The
data filtered by SMA to include only the following categories of
flights:

1.  General aviation: "Nd..."

2.  Lifeguard flights: "LNd..."

3.  Commercial flights: "llld..."

4.  Air Taxis: "TNd..."

5.  Canadian GA: "CGlll" or "CGlll"

6.  International flights: "llll..."

ARTS track data is sent every 20 seconds.

The data packet for an ARTS data message contains a series of flight
records, formatted as follows:

1.  Each record is contained on one line (i.e., is terminated by a
    *newline*).

2.  Each line contains thirteen fields separated by commas describing a
    particular flight.

The thirteen flight data fields represent:

1.  Site ID (the facility from which the message was received)

2.  Flight ID

3.  Beacon Code

4.  Sensor Number (which sensor the track data is from)

5.  X position (nautical miles from sensor)

6.  Y position (nautical miles from sensor)

7.  X velocity (nautical miles/hour)

8.  X velocity (nautical miles/hour)

9.  Altitude (feet)

10. Timestamp (number of milliseconds since Jan. 1, 1970, 0000Z)

11. Aircraft Type

12. Arrival/Departure Status (either ARR- or DEP- followed by the
    airport identifier or UNKNOWN; OVR; or UNK)

13. 'Controlled By' Status (either ARTS or CENTER)

Field 12 includes the airport name at which an arriving or departing
flight is operating.

A sample ARTS data block is as follows:

> MSP,UAL387,1467,0,-6.5,-2.0,261.1875,28.875,4500,12345678,B747,ARR-MSP,ARTS
>
> MSP,FFT128,605,1,14.3125,35.4375,232.8125,457.75,4500,12345678,B747,ARR-MSP,ARTS
>
> MSP,VGD405,6560,0,28.75,0.4375,416.6875,40.6875,4500,12345678,B747,DEP-MSP,ARTS

The first flight record of the sample block is interpreted as follows:

  ----------------------- ----------------------- -----------------------
  **Field Name**          **Units**               **Value**

  Site ID                 \-                      MSP

  Flight ID               \-                      UAL387

  Beacon Code             \-                      1467

  Sensor Number           \-                      0

  X position              (nautical miles from    -6.5
                          sensor)                 

  Y position              (nautical miles from    -2.0
                          sensor)                 

  X velocity              (nautical miles/hour)   261.1875

  X velocity              (nautical miles/hour)   28.875

  Altitude                (feet)                  4500

  Timestamp               (number of milliseconds 12345678
                          since Jan. 1, 1970,     
                          0000Z)                  

  Aircraft Type           \-                      B747

  Arrival/Departure       (either ARR, DEP, OVR,  ARR-MSP
  Status                  or UNK)                 

  'Controlled By' Status  (either ARTS or CENTER) ARTS
  ----------------------- ----------------------- -----------------------