####### Report no. CDM-RVR-ICD-001

**Interface Control Document:**

Acquiring and Distributing Runway Visual Range Data

**Version 1.0**

###### 

###### 

###### 

###### 

**Prepared by**

**Volpe Center, DTS-56**

**55 Broadway**

**Cambridge, MA 02142**

**14 June 2000**

**Revision History**

  ------------- ---------- ------------ --------------------------------------------
  **Version**   **Date**   **Author**   **Summary of Changes**

                                        

  1.0           14 June    LK, DR, RO   Original baseline document.
                2000                    

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

# 1. Introduction

The New Generation Runway Visual Range (NGRVR) system uses input from
sensors at an airport to calculate values for the runway visual range
(RVR). For a fully instrumented runway, RVR values are given for the
touchdown, mid-point, and rollout portions of the runway, along with an
indication of whether the values are increasing, decreasing, or
stationary. In addition, the status of edge and centerline lights is
given. Every two seconds an RVR value is reported that is an average of
the values over the last minute.

These real-time RVR measurements are used by air traffic controllers in
towers and TRACONs, but in most cases are not available to other FAA
facilities or to air carriers. The goal of this work is to make this
real-time RVR data available to other FAA facilities (such as the
Command Center) and air carriers.

The Collaborative Decision Making (CDM) project is an on-going
development effort by the FAA and participating air carriers. As part of
the 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 at the Volpe National
Transportation System Center (Volpe). AOCs connect to the CDM hub using
communications capabilities provided by third party vendors. The CDM
infrastructure will be used to make the RVR data available to the users.

# Scope

This Interface Control Document (ICD) defines the interface that an
authorized user must use to acquire the RVR data described herein. It
also provides a description of the data so that the end user can
interpret it. The user is responsible for providing the communications
connectivity and client software that meets this protocol. The ICD
includes:

-   Bandwidth Requirements

-   Communications Protocol

-   Message Formats

-   RVR Data Content and Frequency

# How the RVR Data Will be Distributed

Sensors at an airport measure visibility, ambient light, and runway
light intensity. Every two seconds, data from these sensors is used to
calculate the RVR values, and the following data is reported.

-   Time.

-   Runway identifier, e.g., 26L.

-   RVR value at the runway touchdown point, and the trend of that RVR.

-   RVR value at the runway midpoint, and the trend of that RVR.

-   RVR value at the runway rollout point, and the trend of that RVR.

-   Setting of the runway edge lights.

-   Setting of the runway centerline lights.

If a runway is not fully instrumented, e.g., if there is no visibility
sensor at the rollout point of the runway, then some of this data might
not be included. A field is filled with two blank characters to indicate
that no RVR sensor was configured for that point on the runway. This is
the RVR data that goes to the controllers in the tower and the TRACON.
This same data, augmented with the airport ID and the date, is the data
that will be distributed to other FAA facilities and to air carriers.

Volpe will acquire RVR data from the roughly forty-five airports that
feed the thirty-one TRACONs that are Enhanced Traffic Management System
(ETMS) remote sites; these TRACONs are chosen because communications
lines already exist between these TRACONs and the ETMS Hubsite, which is
at the Volpe Center. From the ETMS Hubsite at Volpe, the data will be
sent on to the end users at FAA facilities and at air carriers.

The RVR data will be provided in two ways. First, it will be provided in
tabular, human-readable format on a web site hosted at Volpe. Second, it
will be provided as a stream of digital data from the RVR Hubsite Server
at Volpe. The purpose of this document is to provide a developer at an
end-user site with the information needed to get data from the RVR
Hubsite Server and to interpret it.

In this document, the *client* is the user software that acquires the
data from Volpe; the *server* is the RVR Hubsite Server, which is
software written by Volpe, that runs at Volpe, and that provides the RVR
data to connected clients.

A client gets RVR data by making a TCP/IP socket connection to the RVR
Hubsite Server and by following the protocol specified below. The RVR
digital data feed will be a real-time, non-buffered data feed; that is,
when a client connects, the RVR Hubsite Server will only transmit any
new RVR data received. If a client disconnects and re-connects, the
client will lose any data processed by the server during the time it was
disconnected.

# Technical Specifications

In order to acquire RVR data, a user shall:

1.  Become an authorized user by signing the National Airspace System
    (NAS) Status Information memorandum of agreement with the FAA.

```{=html}
<!-- -->
```
1.  Have a communications link that provides TCP/IP capability between
    the user site and the CDM hub at Volpe. The bandwidth requirements
    for this link are discussed below.

2.  Develop or otherwise acquire client software that follows the
    protocol prescribed below. In addition, the client software should
    be configurable so that it will cycle through a prescribed set of IP
    addresses when trying to connect; this will most likely be two
    addresses, depending on the total demand for data. Thus, if there
    are two RVR Hubsite Servers at Volpe and one fails, the client
    should be able to connect to the other one by automatically cycling
    through the given IP addresses until it is successful. The actual IP
    addresses will be given to authorized users.

## Bandwidth Requirements

The bandwidth usage for a single airport depends on the options
requested by the client, the number of runways at that airport, and the
frequency at which the data is sent.

Suppose that a client requests the **format=single_line** option defined
below. Every message will then contain 25 bytes plus 20 bytes per
runway, where the largest possible number of runways is 12. This means
that the size of a single message will vary between 45 and 265 bytes.
The frequency at which the messages will be sent varies (and depends on
which update option the client requests). The worst case is that a
message would be sent every two seconds for an airport with 12 runways,
in which case bandwidth usage would be 265/2 = 132.5 bytes/second.
Multiply this value by the number of airports to get an estimate of the
maximum required bandwidth.

The actual number of bytes per second would fall below this maximum for
several reasons.

-   Most airports have less than 12 instrumented runways.

-   The messages are sent less frequently than every two seconds. (How
    frequently these messages are received by Volpe from the field is
    configurable. Potential users will be notified once this value is
    set.)

-   If the client requests the **update_when=data_changes** option
    defined below, this would reduce the data flow by an indeterminate
    amount.

## Communications Protocol

A typical sequence of steps for acquiring RVR data (illustrated in the
figure below) is as follows:

1.  The client opens a TCP/IP socket connection to the RVR Hubsite
    Server using a known IP address and port number.

2.  The client transmits a Registration Message.

3.  The server verifies the syntax of the Registration Message and
    validates that the client is authorized. The server sends a
    Registration Acknowledgement Message to the client.

4.  The server begins transmitting RVR data to the client.

5.  If the client wishes to change any values specified in the
    Registration Message (such as the airports for which data are being
    requested), the client closes the existing socket connection, then
    opens a new socket connection and transmits a new Registration
    Message containing the desired options.

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

The RVR Hubsite Server does not require or expect an acknowledgment from
the client for data packets.

Initially, one IP address and port will be distributed to authorized
users to connect to, and it is planned that this port will provide RVR
data with 60 second updates. As the program matures, two additional
ports will be made available that provide faster updates. One of these
additional ports would provide updates at the maximum rate of 2 seconds,
and the other would provide updates at some intermediate rate yet to be
defined, perhaps 10 seconds. In short, the long run plan is to provide
three ports that provide slow, medium, and fast update rates, where the
slow update rate is 60 seconds and the fast is 2 seconds. Initially,
only the slow update rate of 60 seconds will be provided. A user can
decide which port to connect to depending on the use to which the data
is being put and the available bandwidth.

If the first transmission from a prospective client is not a valid *RVR
Registration* Message (i.e., if the syntax of the Registration Message
is incorrect), or if the client_id in the message is not valid or is
already in use, the new TCP connection is closed immediately by the RVR
server, with no explanation. The TCP connection is also closed if the
Registration Message syntax is correct, but there are no valid airports
listed in the **options: airports=** field. The first two airports for
which there will be an RVR digital data feed are Boston and Memphis. If
the syntax in the Registration Message is correct, the client ID is
valid, and at least one valid airport is provided, the server will send
a Registration Acknowledgement Message to the client that echoes the
options selected and provides a list of all airports currently included
in the RVR data feed.[^1] The syntax of this message is given in the
message format section below.

If the socket connection is opened and no Registration Message is
received for 10 minutes (allowing time for manual entry of the
Registration Message), the socket will be closed. Once the socket
connection is opened and a valid Registration Message has been received,
all further messages from the client will be ignored until the socket
has been closed and then reopened. If a client needs to reconnect for
any reason (such as a firewall reboot or testing new client software),
the active TCP connection should be closed before attempting to
reconnect. There is no de-registration message. When the client wants to
stop receiving data, it should close the socket.

## Message Formats

### Registration Message (client to server)

An RVR client Registration Message must be the first message sent by the
client when a connection is established with the server.

The RVR client Registration Message contains three lines of ASCII text.
Each line is terminated by a *newline* character (octal 012). The
message is terminated by an additional *newline*.

Each line in the Registration Message 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 three field identifiers used in RVR client
Registration Message are as follows:

1.  **type:** Indicates the message type. This field is required. For
    the Registration Message, this field must contain "register RVR".

```{=html}
<!-- -->
```
3.  **client_id:** A unique string assigned to the client. This field is
    required.

4.  **options:** Data fields pertaining to the format and timing of
    messages, and listing the airports for which data is being
    requested. The only required option is the **airports** option.

The syntax of the options field is \<parameter\>**=\<**value\>. If
multiple options are specified, they should be separated by a semi-colon
character.

The currently supported option parameters for RVR clients are:

**format=*single_line*\|*multi_line*** (\| means either/or; i.e. either
single_line or multi_line)**\
update_when=*data_available*\|*data_changes\
*airports=\<*airport_list*\>**

**format=*single_line*** indicates that an airport's data all appears on
one line. An example will be given below.

**format**=***multi_line*** indicates that an airport's data appears on
several lines with a header line containing the aiport id, a time stamp
and column names, followed by a single line for each runway for which
data is being received.

The ***single_line*** format is intended for parsing by a computer
program. The ***multi_line*** format is meant to be easily read by a
human. It is intended to be used for initial testing and debugging, not
for automation. An operational client should only use the
***single_line*** format; the ***multi_line*** format may be changed
without notice to the users.

The **update_when** parameter is used to determine when new data is sent
to the client. This option is only be available on the port that
provides the fast update rate described above; the ports that provide
slow and medium update rates will not support this option; the
**update_when** option is ignored if used with the slow or medium rate
ports. Any connection to the slow or medium rate ports will provide a
steady flow of data at the specified update rate. If on the fast port
**update_when** is set to ***data_available***, then all data received
by the server is sent to the client. If **update_when** is set to
***data_changes***, then, after the first RVR data message for an
airport is sent, subsequent RVR data messages for that airport are sent
only after either of the following events.

-   Any of the RVR data for that airport changes.

-   Valid RVR data is still being received for that airport by the
    server and a minute has elapsed since the last RVR data message for
    that airport was sent.

Thus, even if the client has selected the **update_when=data_changes**
option, it will be able to determine that data has stopped flowing from
an airport if no new messages are received from that airport for more
than one minute. Note than no messages are sent to clients explicitly
announcing an outage at an airport.

The **airports=\<*airport_list\>*** parameter indicates the airports
which the client wishes to monitor. The \<***airport_list\>*** is one or
more airport identifiers (separated by commas or spaces if there are
more than one). The client can send in 3- or 4-letter airport
identifiers. The messages from the server to the client will always use
4-letter identifiers. The identifier **ALL** can be used to indicate
that data is desired from all airports for which it is available.

Example:

**airports=KBOS,KMEM**

Example:

> **airports=ALL**

The default values for the **options** parameters are
**format**=***single_line*** and **update_when**=***data_changes***.
(Recall that the **update_when** option only applies to the fast update
rate.) There is no default for the **airports** option; at least one
valid airport identifier must be included in the message.

An example of a complete Registration Message is:

type: register RVR\\*n*\
client_id: CLXYNK\\*n*\
options: format=single_line; update_when=data_available;
airports=KBOS,KMEM\\*n*\
\\*n*

Note the extra newline (\\*n*) after the last line of the Registration
Message; the newline is used twice to indicate the end of the
Registration Message.

NOTE: The client ID will be assigned by Volpe.

### Registration Acknowledgement Message

If the server receives a syntactically correct Registration Message that
contains a valid client ID and at least one valid airport, it shall
respond with a Registration Acknowledgement Message. The purpose of this
message is to explicitly tell the client the options that are in effect.
The syntax of this message is:

**format=*single_line*\|*multi_line;***
**update_when=*data_available*\|*data_changes;* airports=\<*list of
valid airports requested*\>; airports_available=\<*list of all airports
for which RVR data is available*\>\\n**

In the lists, the airports are separated by commas or spaces. This
message is all on one line. The list of all airports for which RVR data
is available is included so that users will have a way of knowing when
new airports come on line.

An example of a Registration Acknowledgement Message is:

format=single_line; update_when=data_available; airports=KBOS,KMEM;
airports_available=KBOS,KDFW,KLGA,KMEM\\*n*

### RVR Data Message (server to client)

The RVR Data Message has the following components (the format depends on
whether the ***single_line*** or ***multi_line*** option has been
selected):

char airport\[4\];

char message_time\[8\]; /\* hh:mm:ss (this represents the TRACON time
stamp which might differ from true time)\*/

char message_date\[10\]; /\* mm/dd/yyyy \*/

struct runway_rvr_product_subgroup\[1-12\]

{

char Runway_Identifier\[2\];

char Runway_Sub_Identifier\[1\];

char RVR_Touchdown_Value\[2\];

char RVR_Touchdown_Trend\[1\];

char RVR_Midpoint_Value\[2\];

char RVR_Midpoint_Trend\[1\];

char RVR_Rollout_Value\[2\];

char RVR_Rollout_Trend\[1\];

char Runway_Edge_Light_Setting\[1\];

char Runway_Centerline_Light_Setting\[1\];

};

The allowable values for the runway_rvr_product_subgroup components are:

Runway_Identifier: Numeric Characters "01" through "36"

Runway_Sub_Identifier: ASCII "blank", "L", "R", or "C"

RVR_Touchdown_Value, RVR_Midpoint_Value, and RVR_Rollout_Value:
Calculated RVR value in hundreds of feet (ranging from "00" through
"60") or one of the following: 2 "blank" characters, or "FF", where:

1.  RVR Products are rounded to the nearest increments as follows:

-   100 feet increments for RVR products below 800 feet

-   200 feet increments for RVR products between 800 and 3000 feet

-   500 feet increments for RVR products between 3000 and 6000 feet

7.  Two "blank" characters represent that no RVR sensor has been
    configured for that point on the runway.

8.  "FF" represents invalid data.

RVR_Touchdown_Trend, RVR_Midpoint_Trend, and RVR_Rollout_Trend:

1.  "S" to represent neither increasing or decreasing RVR trend

```{=html}
<!-- -->
```
9.  "blank" to indicate that no sensor is configured for that point on
    the runway

10. "I" for increasing trend

11. "D" for decreasing trend

12. "+" to represent that the RVR product is above 6000 feet

13. "F" for invalid data.

Runway_Edge_Light_Setting: Numeric Character "0" through "5", or "F",
where

1.  "0" indicates the lights are off

```{=html}
<!-- -->
```
14. "5" indicates maximum intensity

15. "1", "2", "3", and "4" represent increasing levels of intensity
    between "0" and "5"

16. "F" indicates invalid data.

Runway_Centerline_Light_Setting: Numeric Character "0" through "5", "F",
or ASCII "blank", where

1.  "0" indicates the lights are off

```{=html}
<!-- -->
```
17. "5" indicates maximum intensity

18. "1", "2", "3", and "4" represent increasing levels of intensity
    between "0" and "5"

19. "F" indicates invalid data

20. ASCII "blank" indicates no centerline lights are configured for the
    runway.

The format of the ***single_line*** output is:

> \<airport\>,\<message_time\>,\<message_date\>**;\<**runway_rvr_product_subgroup1\>\[**;\<**runway_rvr_product_subgroup2\>\[**;**...\]\]\\n
>
> The format of each \<runway_rvr_product_subgroup\> field is:
>
> "(...),(...),(...),(...),(.),(.)" , or 3 characters, followed by a
> comma, (Runway)\
> 3 characters, followed by a comma, (TD)\
> 3 characters, followed by a comma, (MP)\
> 3 characters, followed by a comma, (RO)\
> 1 character, followed by a comma, (E)\
> 1 character. (C)
>
> where Runway refers to the concatenation of the Runway_Identifier and
> the Runway_Sub_Identifier; TD, MP, and RO refer to the concatenation
> of the Value and Trend for the RVR_Touchdown, RVR_Midpoint, and
> RVR_Rollout positions respectively; E refers to
> Runway_Edge_Light_Setting; and C is the
> Runway_Centerlight_Light_Setting.

Examples of RVR Data Messages with **format**=***single_line*** are:

> KBOS,02:27:16,04/17/2000;04R,35I,35I,35S,5,5;15R,30I, ,20I,\
> 5,5;22L,35S,35I,35I,5,5;33L,20I, ,30I,5,5;04L,35I, , ,5,5\\*n\
> *KMEM,02:27:18,04/17/2000; 09 ,20S, ,10S,4,4;27 ,10S,
> ,20S,4,4;36L,35I,35I,30I,3,3;36C,25S,35I,30I,\
> 3,3;36R,35D,FFF,30S,5,5; \\*n*

Note: The data for each airport should be on a single line; it is shown
here on multiple lines because the paper is too narrow to show all the
data for an airport on one line. Also, to see that spaces explicitly,
you should click the paragraph symbol in Word.

The format of the ***multi_line*** output is given below. Since the
***multi_line*** format is not meant to be parsed, the user should not
write code that depends on this format; it may be changed without
notice. Note: In the format description below, each "." represents a
space.

> \<airport\> . \<message_time\> . \<message_date\>\\n\
> ... RWY .. TD ... MP ... RO ... E .. C\\n\
> \<runway_rvr_product_subgroup 1\>\\n\
> \-\--\
> \<runway_rvr_product_subgroup n\>\\n
>
> The format of each \<runway_rvr_product_subgroup\> field is:
>
> ... \<Runway\> .. \<TD\> .. \<MP\> .. \<RO\> .. \<E\> .. \<C\>\\n
>
> where \<Runway\> refers to the concatenation of the Runway_Identifier
> and the Runway_Sub_Identifier; \<TD\>, \<MP\>, and \<RO\> refer to the
> concatenation of the Value and Trend for the RVR_Touchdown,
> RVR_Midpoint, and RVR_Rollout positions respectively; \<E\> refers to
> Runway_Edge_Light_Setting; and \<C\> is the
> Runway_Centerlight_Light_Setting.

An example of an RVR Data Message with **format**=***multi_line*** is:

> KBOS 02:27:16 04/17/2000\\n\
> RWY TD MP RO E C\\n\
> 04R 35I 35I 35S 5 5\\n\
> 15R 30I 20I 5 5\\n
>
> 22L 35S 35I 35I 5 5\\n\
> 33L 20I 30I 5 5\\n\
> KMEM 02:27:18 04/17/2000\\n\
> RWY TD MP RO E C\\n\
> 09 20S 10S 4 4\\n\
> 27 10S 20S 4 4\\n\
> 36L 35I 35I 30I 3 3\\n\
> 36C 35S 35I 30I 3 3\\n\
> 36R 35D FFF 30S 5 5\\n

Note that even if there is only one physical runway, e.g., 04R/22L, both
04R and 22L appear. The data for these two runways is not independent,
e.g., the touchdown value for 04R is the same as the rollout value for
22L.

# Issues

21. None at this time.

[^1]: This list will also be available on the RVR web page. In addition,
    authorized users will be notified as new airlines are added to the
    data feed.