####### Report no. CDM-RVR-SRD-001 {#report-no.-cdm-rvr-srd-001 .unnumbered}

**System Requirements Document:**

Acquiring and Distributing Runway Visual Range Data

**Version 1.1**

######  {#section .unnumbered}

######  {#section-1 .unnumbered}

######  {#section-2 .unnumbered}

######  {#section-3 .unnumbered}

**Prepared by**

**Volpe Center, DTS-56**

**55 Broadway**

**Cambridge, MA 02142**

**14 June 2000**

**Revision History**

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

                                        

  1.0           3 May 2000 RO           Original baseline document.

  1.1           14 June    RO           Added requirements 2.8, 3.9, 4.7, and 4.8.
                2000                    Made other minor edits that did not change
                                        the requirements.
  ------------- ---------- ------------ ---------------------------------------------

# Background {#background .unnumbered}

Sensors at a number of airports provide real-time measurements of 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 purpose of this document is to state the requirements for what
should be accomplished but not to discuss details of how it should be
done. That is, this document is intended to describe a set of
requirements, which if met by the system, will satisfy the FAA and the
air carriers.

# Reference Documents {#reference-documents .unnumbered}

The following documents are relevant to the task of acquiring and
distributing RVR data. Dates and current version numbers of these
documents are given; if necessary, these will be updated as the work
proceeds.

"Software Development Plan: Acquiring and Distributing Runway Visual
Range Data," Volpe Center, DTS-56, report no. CDM-RVR-SDP-001, not yet
written. This document describes the overall environment in which this
system is being developed, sketches the work to be done, and provides a
schedule.

"Software Requirements Document: Acquiring and Distributing Runway
Visual Range Data," Volpe Center, DTS-56, report no. CDM-RVR-SWRD-001,
Version 0.5, 11 May 2000. This document provides detailed direction to
developers that specifies the software that needs to be developed; a
developer can use this document, in conjunction with the system
requirements document, to design and write the code.

"Operational Test and Evaluation Plan for the Collaborative Decision
Making System to Runway Visual Range Interface," William J. Hughes
Technical Center, ACT-320, 30 September 1999. This document describes
the test environment and the levels of testing that will be conducted.

"Interface Control Document: Acquiring and Distributing Runway Visual
Range Data," Volpe Center, DTS-56, report no. CDM-RVR-ICD-001, Version
0.8, 24 May 2000. This document provides the end users of the RVR data,
e.g., air carriers, with the information needed to write client software
that will fetch the streaming, digital RVR data from the RVR Hubsite
Server at Volpe.

"Software Requirements Specification for the Runway Visual Range System
Controller/Display (CD) CSCI," Contract no. DTFA01-88-C-00024, CDRL
sequence no. B015, Teledyne Controls, Inc., Drawing 861264.

# Brief Sketch of How RVR Data is Generated {#brief-sketch-of-how-rvr-data-is-generated .unnumbered}

Sensors at an airport measure visibility, ambient light, and runway
light intensity. Data from these sensors go to the Data Processing Unit
(DPU) at that airport, which uses these measurements to calculate the
RVR values. Every two seconds the DPU produces a data structure called
an application data unit (ADU), which contains the time that the ADU was
produced, a checksum that is used for error-checking, and the following
data about each runway at the airport.

-   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 in the ADU; the ADU indicates if the DPU either did not
receive data for a field or that the data was invalid. For more details
on the ADU, see the RVR test plan.

The ADU is the data that goes to the controllers in the tower and the
TRACON. The ADU, when augmented with the airport ID and the date, is
also the data that the work described in this document will capture and
distribute to other FAA facilities and to air carriers. See the Software
Development Plan for a more complete description of the material
discussed in this section and the next.

# Acquiring and Distributing the RVR Data {#acquiring-and-distributing-the-rvr-data .unnumbered}

The overall plan is to acquire RVR data from the 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, the data will be sent on to the
end users at FAA facilities and at air carriers.

Figure 1 shows a simplified diagram of the overall flow of the RVR data
from the airport where the data originates to the FAA or air carrier end
user that views the data. At a high level, the data will take three
hops.

-   From the airport to the TRACON.

-   From the TRACON to Volpe.

-   From Volpe to the end user at an FAA facility or at an air carrier.

There are four components to the software that will acquire and
distribute the RVR data.

-   *RVR TRACON Server:* Accepts the ADUs from each DPU over a serial
    line, error checks them, logs them, and acts as a server to send
    this data on to any client that registers; initially, the RVR
    Collector is planned to be the only client that connects. The RVR
    TRACON server runs on an ETMS fileserver at a TRACON.

-   *RVR Collector:* Makes a TCP/IP socket connection to the RVR TRACON
    Server at each TRACON to get the RVR data, error checks it, and
    passes it to the RVR Display Driver and the RVR Hubsite Server. The
    RVR Collector also sends a snapshot of RVR data for an airport to
    any Traffic Situation Display that requests it. (The Traffic
    Situation Display is the primary user interface to ETMS.) The RVR
    Collector runs at the ETMS hubsite.

```{=html}
<!-- -->
```
-   *RVR Display Driver*: Receives clean RVR data from the RVR Collector
    and posts it to the browsers of authorized users who are monitoring
    the RVR data. The RVR Display Driver runs at the ETMS hubsite.

```{=html}
<!-- -->
```
-   *RVR Hubsite Server*: Receives clean RVR data from the RVR Collector
    and provides it to authorized users who are connected via a TCP/IP
    socket connection. The RVR Hubsite Server runs at the ETMS hubsite.

The plan, therefore, is that the RVR TRACON Server at a TRACON will
receive the ADUs over a serial connection from all airports that feed
that TRACON and will send a slightly augmented version of the ADUs over
a socket connection to the RVR Collector, which runs at the hubsite.
That is, the RVR Collector collects these augmented ADUs from all the
RVR TRACON Servers and, therefore, concentrates the RVR data from all
over the country in one place. Once this data is acquired, it is
distributed to air carriers in two ways, depending on whether it is to
be used by a human or a computer. First, if the data is to be used by a
human, the natural way to provide it is on a web page; the RVR Display
Driver provides such a web page that can be browsed by users at FAA
facilities or air carriers. Second, if the data is to be ingested by a
computer, the natural way to provide it is in the form of digital data
over a socket connection; the RVR Hubsite Server will feed this digital
data to any authorized client that connects.

The terms RVR Collector, RVR Display Driver, and RVR Hubsite server are
used to indicate the areas of functionality that must be provided and to
make it easier to state the requirements. Nothing is implied here about
how this functionality is divided into processes or how many different
boxes it will run on; these are design decisions that are beyond the
scope of this document.

# Requirements {#requirements .unnumbered}

The boldface, numbered items below are the requirements. Parenthetical,
unbolded passages are included for clarity but are not part of the
requirements.

## Functional Requirements for the RVR TRACON Server {#functional-requirements-for-the-rvr-tracon-server .unnumbered}

### Req. 1.1: The feed of RVR data to ETMS shall not degrade the display of RVR data to the controllers. It also shall not degrade any ETMS functionality. 

### Req. 1.2: The RVR TRACON Server shall be able to accept RVR data from as many as sixteen different airports. 

### Req. 1.3: The RVR TRACON Server shall have a configuration file that specifies for each serial port the airport whose data comes in on that port as well as any other information specific to that port. (The plan is that a serial card with eight ports will be installed in each ETMS fileserver; if necessary, two serial cards will be installed to provide sixteen ports. One port will be dedicated to each airport, and the RVR TRACON Server uses the data in the configuration file referred to in this requirement to determine which airport the data coming in on a port is from.) 

### Req. 1.4: The RVR TRACON Server shall allow TCP/IP socket connections from as many as eight clients. (At the moment it is expected that the only client will be the RVR Collector at the ETMS hubsite, but we need to allow for the possibility that other clients will connect. For example, the Command Center might want to connect to the RVR TRACON Server to get the data. For this reason, the generic word "clients" is used to refer to the process(es) that will receive the RVR data.) 

### Req. 1.5: The RVR TRACON Server shall be configurable so that it will only accept connections from specified IP addresses. (Only authorized clients should be able to get the RVR data from the server. Initially, the only authorized client will be the RVR Collector at Volpe.) 

### Req. 1.6: The RVR TRACON Server shall error-check every ADU that it receives. It shall error-check not only the checksum but also the validity of every field in the ADU. For each error that is found, The RVR TRACON Server shall log an error message that describes the error; this error message shall contain not only the ADU that was received but also the ID of the airport that generated the ADU and the date and time that the RVR TRACON Server received the ADU. 

### Req. 1.7: The RVR TRACON Server shall from an ADU form what is termed an augmented ADU. The augmented ADU differs from the ADU in the following ways.

a.  The four-character ID of the airport that generated the ADU is
    added.

b.  The date on which the ADU was generated is added. (The time is
    already in the ADU.)

c.  A count of the number of valid ADUs that have been received since
    the last augmented ADU is added.

d.  A count of the number of invalid ADUs that have been received since
    the last augmented ADU is added.

e.  The start of text and end of text characters are modified.

f.  The checksum is omitted.

g.  The end of transmission character is omitted.

###  {#section-4 .unnumbered}

### (The general idea is that fields are either added or removed from the ADU to form the augmented ADU, which then contains the information that needs to be transmitted to the ETMS hubsite. The start of text and end of text characters are modified to make them more readable. The checksum and end of transmission character are omitted since they are not needed for the TCP/IP transmission to the hubsite; each TCP packet includes a 16-bit checksum.)  {#the-general-idea-is-that-fields-are-either-added-or-removed-from-the-adu-to-form-the-augmented-adu-which-then-contains-the-information-that-needs-to-be-transmitted-to-the-etms-hubsite.-the-start-of-text-and-end-of-text-characters-are-modified-to-make-them-more-readable.-the-checksum-and-end-of-transmission-character-are-omitted-since-they-are-not-needed-for-the-tcpip-transmission-to-the-hubsite-each-tcp-packet-includes-a-16-bit-checksum. .unnumbered}

### Req. 1.8: The RVR TRACON Server shall send augmented ADUs to all connected clients. (That is, the RVR TRACON server sends to clients not the ADU that is received but rather the augmented ADU that it constructs from the ADU.) 

### Req. 1.9: The RVR TRACON Server shall be configurable so that the rate at which it sends augmented ADUs to clients can be controlled by a configuration file. (The RVR TRACON Server should receive an ADU every two seconds for each airport. Therefore, the fastest rate at which the RVR TRACON Server could send would be every two seconds, but it might be desirable to set the update rate to every ten seconds or every sixty seconds.) 

### Req. 1.10: The RVR TRACON Server shall send at the same data rate to all clients. (This rules out, for example, the situation where one client gets the data every two seconds while another client gets the data every ten seconds.) 

### Req. 1.11: The RVR TRACON Server shall for each hour keep a single log file that will contain the following. 

a.  All ADUs that were received. The RVR TRACON Server shall add to each
    log entry the ID of the airport that generated the ADU and the time
    that the RVR TRACON Server received it.

```{=html}
<!-- -->
```
h.  Any error messages that are generated.

i.  Successful connection attempts. (The RVR TRACON Server might log the
    IP address of the client and when the connection occurred.)

j.  Unsuccessful connection attempts. (The RVR TRACON Server might log
    the IP address of the client, the reason why the connection failed,
    and when the attempt occurred.)

k.  Closing of a connection. (The RVR TRACON Server might log the IP
    address of the client, the reason the socket was closed, when the
    connection was established, and when the connection was broken.)

    (It is not expected that these logs will be examined daily or on any
    regular basis. Rather, they will be examined whenever there is some
    problem that is being investigated.)

### Req. 1.12: The RVR TRACON Server logs shall be kept for at least six hours. 

### Req. 1.13: The RVR TRACON Server shall connect to the ETMS Node Switch. (Node Switch is a process that runs on ETMS machines. The RVR TRACON Server gets access to ETMS communications when it connects to Node Switch.) 

### Req. 1.14: The RVR TRACON Server shall respond to ETMS statistics requests. (ETMS allows as many as ten "standard questions" to be asked of each ETMS process; these questions are used to support the system. Each of these standard questions is called a statistics request. The statistics requests are customized to each process. For example, a statistics request for the RVR TRACON Server might be: What clients are connected, how long have they been connected, how much data have you shipped them, and what are their IP addresses? Volpe will work with the FAA to determine exactly what statistics requests should be supported by the RVR TRACON Server.) 

### Req. 1.15: If the RVR TRACON Server is unable to write to a socket for a configurable interval of time, it shall close the socket. (For example, the RVR TRACON Server might be configured so that if it is unable to write to a socket for thirty seconds, it will close that socket.) 

### Req. 1.16: The RVR TRACON Server shall, for each connected client, buffer data that flows in faster than it can be written. This buffer shall be of a configurable size. If this buffer fills up, then the RVR TRACON Server shall close the socket. (For example, the buffer for a client might be set to five kilobytes. If this buffer fills up, that is taken to be the signal that there is a problem with the client, so that client's socket is closed.) 

### Req. 1.17: If a user is logged into the active ETMS fileserver, then this fileserver shall display the status of the RVR feed from each airport that feeds the TRACON and shall also show the status of any clients that are connected. (This display is used by field site support personnel to get a quick look at the status of the system. Statistics requests are used for a more detailed look. It is a limitation of the ETMS fileserver that a status window can only be displayed if the X Server is running, and the X Server can only run if a user is logged into the fileserver. If no user is logged in, then all the other requirements must be satisfied; this is the only requirement that is conditional on a user being logged in.) 

## Functional Requirements for the RVR Collector {#functional-requirements-for-the-rvr-collector .unnumbered}

### Req. 2.1: The RVR Collector shall be responsible for maintaining a connection to the active RVR TRACON Server at every TRACON that is providing RVR data. (This means that the RVR Collector will be the client that opens a socket connection to initiate a session. If this connection is lost, it is the responsibility of the RVR Collector to re-establish this connection. This is further discussed under the recoverability and reliability requirements.) 

### Req. 2.2: If the RVR Collector receives no data from a particular TRACON for a configurable interval of time, it shall close the socket and try to reconnect. If the RVR Collector closes the connection to a TRACON, this shall not affect the flow of data from other TRACONs. 

### Req. 2.3: The RVR Collector shall log every augmented ADU that it receives. Volpe shall keep this log for at least fifteen days. Moreover, Volpe shall keep this log on-line for at least three days. (The intent is that logs of all RVR data received will be kept on-line for three days for trouble-shooting purposes; if Volpe gets a call about bad data, it is very helpful if Volpe can immediately look at the data that has come in so that it can track down the problem. In addition, logs will be kept for fifteen days in case they are needed for some other purpose; for this longer time period, Volpe has the option of keeping these logs off-line if desired.) 

### Req. 2.4: The RVR Collector shall error-check every augmented ADU that it receives. The RVR Collector shall error-check not only the checksum but also the validity of every field in the augmented ADU. (The error-checking has three steps. First, the checksum is checked. Second, the syntax of every field is checked. Third, insofar as possible, the semantics of every field are checked, e.g., an RVR value must be in the allowed range. If any of these tests is failed, then the augmented ADU fails the error-checking. If the augmented ADU explicitly indicates that data is invalid or unavailable, this is not considered to be an error. See the test plan for an explanation of how the various fields in the ADU are coded and interpreted.) 

### Req. 2.5: If the RVR Collector finds an error in an augmented ADU, it shall log that augmented ADU in an error file and then discard that augmented ADU. (We want to have a log of all errors so that we can periodically inspect and analyze it. If an error is found anywhere in an augmented ADU, then that entire ADU is thrown away after it is logged in the error file; the thinking is that one error anywhere in an ADU casts suspicion on the entire ADU.) 

### Req. 2.6: If the RVR Collector finds that an augmented ADU is error-free, then it shall pass the data in the augmented ADU to both the RVR Display Driver and also the RVR Hubsite Server. 

### 

### Req. 2.7: If the RVR Collector receives a request from a Traffic Situation Display (TSD) for RVR data for an airport and if the stale data time-out period has not passed since the last valid augmented ADU was received for that airport, then the RVR Collector shall return the most current RVR data for that airport to the TSD; if the stale data time-out period has passed, then the RVR Collector shall send the TSD a message saying that data is not available for that airport.

### 

### Req. 2.8: The RVR Collector shall respond to ETMS statistics requests. 

## Functional Requirements for the RVR Display Driver  {#functional-requirements-for-the-rvr-display-driver .unnumbered}

### Req. 3.1: The RVR Display Driver shall make the RVR data available via a web browser to any user who has access to the CDM DataGate. (The CDM DataGate is the web site hosted by Volpe that is accessible over the CDMnet. Currently, air carriers that participate in the Collaborative Decision Making (CDM) Program and the Air Traffic Control System Command Center have access to the CDM DataGate. It is likely that other ETMS sites, e.g., ARTCCs, will be given access to the CDM DataGate. In the future, it is possible that access might be allowed over the public Internet. See the user requirements for a statement of what browsers will be supported)

### Req. 3.2: When a user initiates an RVR browsing session, the RVR Display Driver shall force that user to view a page that states: "The data provided on this screen shall only be used for flight planning purposes. The RVR obtained from ATC is the official RVR." After the user clicks to acknowledge this page, the RVR Display Driver shall force that user to view another page that states how the RVR data is to be used and interpreted. Only after the user clicks to acknowledge this page shall the RVR Display Driver allow him or her to view the RVR data. 

### Req. 3.3: The RVR Display Driver shall allow the user to specify the airports for which RVR data is displayed. 

### Req. 3.4: The RVR Display Driver shall allow the user to request the rate at which the RVR values shall be updated for an airport. At a minimum, the update rates offered would be every two, ten, or sixty seconds. (For example, suppose that a user requests ten seconds as the update rate. This means that when the RVR Display Driver receives an update for an airport that this user is monitoring, it will only send that update if at least ten seconds have elapsed since the last update was sent to that user. If the user requests a faster rate than the rate at which the data is being provided, then the user will not receive updates at the requested rate; see the next requirement. The rationale for this requirement is that is allows a user that is short on bandwidth to specify a slower rate to conserve bandwidth.) 

### Req. 3.5: The RVR Display Driver shall update the user's display of the RVR data for an airport at either the update rate requested by the user (see previous requirement) or at the update rate provided by that airport, whichever is slower. (For example, if the RVR TRACON server is configured to provide updates every two seconds, and if the user asked to get updates every two seconds, then in fact the user would receive an update every two seconds. If, instead, the RVR TRACON server is configured to provide updates every ten seconds, and if the user asked to get updates every two seconds, then the user would receive an update every ten seconds. In other words, the user can ask for an update rate, and the RVR Display Driver will come as close to meeting it as possible, given the rate at which the RVR TRACON Server sends the data.) 

### Req. 3.6: The RVR Display Driver shall provide the following data for each airport.

a.  Airport ID.

```{=html}
<!-- -->
```
l.  Date and time of the update that is displayed.

m.  All additional data included in the augmented ADU as follows:

    1.  Runway ID for each runway

    2.  Touchdown, mid-point, and roll-out RVR product for each runway.

    3.  Touchdown, midpoint, and rollout RVR trend indicators for each
        runway.

    4.  Edge light setting for each runway.

    5.  Centerline light setting for each runway.

        (All of this data comes from the augmented ADU. All dates and
        times will be in Universal Coordinated Time, which was formerly
        known as Greenwich Mean Time. The times in the augmented ADUs
        from different airports might well differ by several minutes
        since the clocks in DPUs at different airports are not perfectly
        synchronized. For now, we will assume that this is not a
        problem. If it turns out to be a problem, then we will figure
        out a way to deal with it.)

### Req. 3.7: When the RVR Display Driver receives an update for an airport, it shall cause that data to be displayed until the next update for that airport comes in or until the stale data time-out period has passed. The stale data time-out period for an airport shall be 30 seconds or twice the interval at which augmented ADUs are being sent for that airport, whichever is larger. (For example, if BOS is sending an augmented ADU every 10 seconds, then the stale data time-out period is 30 seconds. If BOS is sending an augmented ADU every 20 seconds, then the stale data time-out period is 40 seconds. Each airport will have its own stale data time-out period.)

### 

### Req 3.8: If the stale data time-out period has passed since the RVR Display Driver received the last update on an airport, it shall remove the data for that airport from the display and indicate that RVR data is not available for that airport. (The message "Data Not Available" will be posted.)

### 

### Req 3.9: The RVR Display Driver shall allow the user to specify runways for which the Display Drive shall display a graph that shows the touchdown, midpoint, and rollout values for the last hour. (This will provide the user with a much better situational awareness with respect to RVR.) 

## Functional Requirements for the RVR Hubsite Server  {#functional-requirements-for-the-rvr-hubsite-server .unnumbered}

### Req. 4.1: The RVR Hubsite Server shall have a configuration file that specifies the IP addresses from which clients are allowed to connect. (This configuration file allows Volpe to control who can make a socket connection and get the digital RVR data. The current thinking is that air carriers or vendors will need to sign an MOA before they will be allowed to connect to receive the digital data.) 

### Req. 4.2: The RVR Hubsite Server shall allow clients to connect over CDMnet and over ETMS communication lines. 

### Req. 4.3: The RVR Hubsite Server shall allow any client to connect that follows the protocol in the RVR Interface Control Document and whose IP address is included in the configuration file described in a previous requirement; it shall not let a client connect from any other IP address. (The RVR Interface Control Document, which Volpe will write, specifies the protocol that a client will need to follow in order to connect to the RVR Hubsite server; this document will also cover the format of the data and everything else that an air carrier or vendor would need to know to get and use the data.) 

### Req. 4.4: Whenever the RVR Hubsite Server receives an augmented ADU from the RVR Collector, it shall send the following data to every connected client.

a.  Airport ID.

```{=html}
<!-- -->
```
n.  Date and time of the augmented ADU.

o.  All additional data included in the augmented ADU as follows:

    1.  Runway ID for each runway

    2.  Touchdown, mid-point, and roll-out RVR product for each runway.

    3.  Touchdown, midpoint, and rollout RVR trend indicators for each
        runway.

    4.  Edge light setting for each runway.

    5.  Centerline light setting for each runway.

### Req. 4.5: If the RVR Hubsite Server is unable to write to a socket for a configurable interval of time, it shall close the socket. (For example, the RVR Hubsite Server might be configured so that if it is unable to write to a socket for thirty seconds, it will close that socket.) 

### Req. 4.6: The RVR Hubsite Server shall, for each connected client, buffer data that flows in faster than it can be written. This buffer shall be of a configurable size. If this buffer fills up, then the RVR Hubsite Server shall close the socket. (For example, the buffer for a client might be set to five kilobytes. If this buffer fills up, that is taken to be the signal that there is a problem with the client, so that client's socket is closed.)

###  

> **Req. 4.7: The RVR Hubsite Server shall provide as many as three
> ports to which clients can connect, where these three ports provide
> three different update rates. For the port that provides the fastest
> update rate, the client shall have the option of registering to
> receive all data or just to receive the data when it changes. For the
> other two ports, any client that registers shall receive all the data
> at the speed provided by that port.** (To allow users to control the
> amount of bandwidth that is needed, three ports with high, medium, and
> low update rates might be provided. The update rates will be
> determined later, but they might be 2, 10, and 60 seconds. Initially,
> it might be that only the slow port is offered; as experience with the
> data builds and as new uses arise, it might be that the faster update
> rates are then offered.)
>
> **Req. 4.8: The RVR Hubsite Server shall respond to ETMS statistics
> requests.**

######### Functional Requirements for the Traffic Situation Display {#functional-requirements-for-the-traffic-situation-display .unnumbered}

### Req. 5.1: The TSD shall allow a user to request the current RVR data for an airport. When the TSD receives this data, it shall display this data to the user. (The TSD will display the RVR data in a text box that does not update. If the user wants to see how the RVR data changes, then he or she will need to request the RVR data again.)

## Accuracy Requirements for the RVR TRACON Server {#accuracy-requirements-for-the-rvr-tracon-server .unnumbered}

### Req. 6.1: When the RVR TRACON Server sends an augmented ADU to a client, the RVR data in that augmented ADU shall be exactly the same as the data in the last valid ADU that the RVR TRACON Server received, assuming that a valid ADU has been received since the last augmented ADU was sent. ("RVR data" in this context includes everything in the ADU except the start of text character, the end of text character, the checksum, and the end of transmission character. If it is time to send an augmented ADU and if no valid ADU has been received since the last augmented ADU was sent, then no RVR data is sent in an augmented ADU.)

## Accuracy Requirements for the RVR Display Driver  {#accuracy-requirements-for-the-rvr-display-driver .unnumbered}

### Req. 7.1: The RVR Display Driver shall display exactly the values that were received in the most recently received valid augmented ADU for each airport, assuming that the stale data time-out period has not passed since the last valid ADU was received. There are two exceptions. First, the RVR Display Driver shall expand the data in the augmented ADU as needed to fill out fields. Second, for the trend indicators the following will be shown.

a.  RVR stationary or over 6000 feet : space.

```{=html}
<!-- -->
```
p.  RVR increasing: up arrow.

q.  RVR decreasing: down arrow.

r.  No sensor: space.

s.  Failed sensor or invalid data: 'F'

###  {#section-10 .unnumbered}

### (This requirement merely states that the values in the augmented ADU are what the user should see; that is, these values should not be changed by the RVR Collector or the RVR Display Driver. For example, if 'F's are shown in the ADU to indicate invalid or missing data, then 'F's should also be shown on the display. The second sentence requires that these values be expanded as necessary; for example, if an ADU has an RVR value of '50'; this should be displayed as 5000. The changes to the trend indicators are made so that the display seen by the air carriers mimics that seen by the controllers.)  {#this-requirement-merely-states-that-the-values-in-the-augmented-adu-are-what-the-user-should-see-that-is-these-values-should-not-be-changed-by-the-rvr-collector-or-the-rvr-display-driver.-for-example-if-fs-are-shown-in-the-adu-to-indicate-invalid-or-missing-data-then-fs-should-also-be-shown-on-the-display.-the-second-sentence-requires-that-these-values-be-expanded-as-necessary-for-example-if-an-adu-has-an-rvr-value-of-50-this-should-be-displayed-as-5000.-the-changes-to-the-trend-indicators-are-made-so-that-the-display-seen-by-the-air-carriers-mimics-that-seen-by-the-controllers. .unnumbered}

## Accuracy Requirements for the RVR Hubsite Server  {#accuracy-requirements-for-the-rvr-hubsite-server .unnumbered}

### Req. 8.1: Whenever the RVR Hubsite Server receives an augmented ADU, it shall send to all connected clients exactly the values that are contained in that ADU.

### 

######### Accuracy Requirements for the Traffic Situation Display {#accuracy-requirements-for-the-traffic-situation-display .unnumbered}

### Req. 9.1: The RVR data that the TSD displays shall be exactly what the RVR Collector sends.

## Speed Requirements for the RVR TRACON Server {#speed-requirements-for-the-rvr-tracon-server .unnumbered}

### Req. 10.1: When it is time for the RVR TRACON Server to send an augmented ADU, it shall complete the sending of that augmented ADU to all connected clients within a tenth of a second, assuming that there is no congestion on the communications line.

## Speed Requirements for the RVR Collector, Display Driver, and Hubsite Server  {#speed-requirements-for-the-rvr-collector-display-driver-and-hubsite-server .unnumbered}

### Req. 11.1: When the RVR Collector receives an augmented ADU, it shall complete its error-checking within a tenth of a second (100 milliseconds). 

### Req. 11.2: When the RVR Collector receives an augmented ADU that contains no errors, the RVR Display Driver shall be ready to send that ADU within a quarter of a second (250 milliseconds). (This requirement is somewhat tricky because the speed with which new data can be sent depends on the loading on the web server. Strictly speaking, the loading on the web server needs to be specified as part of this requirement. This requirement sets an upper limit on the elapsed time between when an augmented ADU is received at Volpe and when Volpe is ready to send it. No speed requirement is specified for the elapsed time between when an ADU is received at Volpe and when it is displayed on the screen of the user; this depends, e.g., on the bandwidth that an air carrier has chosen for its connection to CDMnet, and is, therefore, not under the control of Volpe.) 

### Req. 11.3: When the RVR Collector receives an augmented ADU that contains no errors, the RVR Hubsite Server shall be ready to send that ADU within a quarter of a second (250 milliseconds).

*Speed Requirements for the Traffic Situation Display*

### Req. 12.1: When the user issues the command to display RVR data, the TSD shall send the request for that data within one-tenth of a second.

### Req. 12.2: When the TSD receives requested RVR data from the RVR Collector, the TSD shall display this data within one-tenth of a second.

## Recoverability and Reliability Requirements for the RVR TRACON Server  {#recoverability-and-reliability-requirements-for-the-rvr-tracon-server .unnumbered}

### Req. 13.1: If the RVR TRACON Server crashes, it shall be restarted within one minute. (This restart would be automatic and would not require human intervention.)

## Recoverability and Reliability Requirements for the RVR Collector, Display Driver, and Hubsite Server {#recoverability-and-reliability-requirements-for-the-rvr-collector-display-driver-and-hubsite-server .unnumbered}

### Req. 14.1: If the RVR Collector stops receiving RVR data from any connected airport for five minutes, it shall send a message to the ETMS 24x7 operators alerting them to this failure. (Exactly what the nature of this message is remains to be worked out by ETMS personnel. Upon receiving this message, the ETMS operators will investigate this problem.)

### Req. 14.2: If the RVR Collector loses its connection to the RVR TRACON server, the RVR Collector shall within five seconds attempt to re-establish that connection; if it is unable to connect, it shall repeatedly attempt to make a connection, with an attempt being made at least once every thirty seconds. As the RVR Collector attempts to reconnect, it shall alternate between trying to connect to the servers on the ETMS Primary Fileserver and on the ETMS Back-up Fileserver. (If the RVR Collector loses its connection, it would in fact make an attempt to re-establish the connection in less than a second; if its attempt to reconnect was not successful in 30 seconds, it would time out and try again.) 

### Req. 14.3: If the RVR Collector crashes, it shall be restarted within one minute. (This restart would be automatic and would not require human intervention.) 

### Req. 14.4: If the RVR Display Driver crashes, it shall be restarted within one minute. (This restart would be automatic and would not require human intervention. Any browsers that are being used to look at the data would, however, need to reconnect. Ideally, we would notify the users that they needed to reconnect, but there does not seem to be any good way to do this. The user will need to notice that the display is not updating and then click the Reload button.) 

### Req. 14.5: If the RVR Hubsite Server crashes, it shall be restarted within one minute. (This restart would be automatic and would not require human intervention.) 

### Req. 14.6: A fully configured back-up of the box(es) on which the RVR Collector, the RVR Display Driver, and the RVR Hubsite Server run shall be available at Volpe. If there is a failure, an ETMS 24x7 operator shall be available to put the back-up box into service to replace the failed box. (The ideal would be that if the box running the RVR Collector failed, then there would be an automatic detection of the problem and switch-over to a back-up box. Because of the expense and complexity of automatically handling a failure in this context, and because reliable boxes will be used, this ideal does not seem to be warranted for this application. What does seem reasonable is to have a back-up box that is ready for service. If the box running the RVR Collector fails, then written procedures would exist that could be used by one of the ETMS 24x7 operators to switch operations over to the back-up. This approach provides an inexpensive and easy back-up that would result in minimal outage. Should it later be decided that the RVR data is so critical that automatic switch-over is needed, then this could be engineered.) 

### Req. 14.7: Back-up for all components of the network at Volpe (e.g., switches, routers, cables) shall be available on-site. If there is a failure, a system administrator shall be available to make the repair. (For some of the routers that are in the RVR path of communications, redundant routers are always in operation so that a failure of one router will result in no perceptible interruption of operation. For some components, e.g., the switch that the firewall and AOCnet connect to, a back-up is available; if the switch in use fails, then a Volpe system administrator would need to do the recabling to bring the new switch on-line to replace the failed switch. To summarize, these last two requirements say that there will be redundancy to deal with any failure. How these different types of failure differ is in how rapidly the replacement element can be brought into use. In some cases this will be immediately; in others it will take a few minutes while an ETMS operator executes a procedure; in still others it will take somewhat longer while a network engineer recables. If at any point it is decided that the RVR availability is sufficiently critical that the money should be spent to improve upon this approach, this can be done.) 

## Size Requirements for the RVR TRACON Server {#size-requirements-for-the-rvr-tracon-server .unnumbered}

For clarity, the size requirements at the TRACON are included in the
functional requirements above.

## Size Requirements for the RVR Collector, Display Driver, and Hubsite Server {#size-requirements-for-the-rvr-collector-display-driver-and-hubsite-server .unnumbered}

### Req. 15.1: The RVR Collector shall be able to connect to as many as 50 TRACON RVR Servers. 

### Req. 15.2: The RVR Display Driver shall allow a user to display the data for as many as sixteen airports simultaneously. (It seems likely that sixteen airports could be displayed at once on a high-quality monitor. If it turns out that users want more than sixteen at once, we will rethink this. If the user wants to view sixteen airports at once, it is up to the user to have a monitor with sufficient resolution.) 

### Req. 15.3: The RVR Display Driver and the RVR Hubsite Server shall each be able to handle the monitoring of at least 500 airports. (For example, if 20 clients each monitor 10 airports, then a total of 200 airports are being monitored. Initial analysis indicates that our planned initial set-up could handle at least a thousand airports. If this proves inadequate, then a more capable solution could be engineered, e.g., by mirroring our web site.) 

### Req. 15.4: Volpe shall have a connection to CDMnet with sufficient bandwidth to handle the monitoring of at least 250 airports. (Currently, Volpe has a T1 connection to AOCnet. Our current estimate is that 600 bytes per second is the bandwidth that would be required for each airport that a user is monitoring. About 321 airports would totally fill the T1. It might be that some of the vendors would need to increase the speed of their connection to Volpe.)

## Procedural Requirements {#procedural-requirements .unnumbered}

### Req. 16.1: Volpe shall train the ETMS 24x7 operators at Volpe on how to monitor the RVR system, on how to diagnose problems, and on what steps to take when a problem has been diagnosed. In addition to providing this training, Volpe shall also provide written procedures to the operators that cover these topics. 

### Req. 16.2: Volpe 24x7 operators shall inspect the RVR error log once a day and shall take whatever action is required by the written RVR procedures. 

### Req. 16.3: Volpe shall allow a client to receive RVR data over a socket connection only if it has received written notification from the FAA point of contact that that organization should receive this data. (While Volpe will control (e.g., with firewalls and/or configuration files) what clients can register to get the RVR data over a socket connection, it is the FAA that provides direction to Volpe on who should get the data. If an air carrier or vendor asks for the data, Volpe will not allow this organization to register and get the data until directed in writing to do so by the FAA. Volpe will consider an e-mail from the FAA point of contact to be authoritative. If the FAA point of contact later directs Volpe in writing that an organization should not get the data, then Volpe will cut off the flow of data to that air carrier. It is expected that the FAA will only allow an organization outside the FAA to get the RVR data over a socket connection if that organization has signed a memorandum of agreement.) 

### Req. 16.4: AOS-330 shall update the ETMS System Administration Manual and the TMS Maintenance Handbook. (This includes documentation for ETMS system administrators and also for AF technicians.) 

### Req. 16.5: All configurable parameters for the RVR system shall be contained in files that can be edited with a standard text editor.

## Requirements on the Users  {#requirements-on-the-users .unnumbered}

### Req. 17.1: A user shall have a connection to Volpe with sufficient bandwidth. (Our current estimate is that if a user is browsing an airport, then the needed bandwidth per update is 590 bytes plus 170 bytes per runway, plus TCP/IP overhead. If any graphs showing data over the last hour are displayed, this would increase the needed bandwidth. If a user connects to the RVR Hubsite server, an upper bound for the needed bandwidth would be 250 bytes per airport per update. An air carrier user can combine this information with knowledge of the number of airports that it would want to monitor to make a rough calculation of how much bandwidth it requires.) 

### Req. 17.2: A user shall use a browser that supports HTML 4.0 or higher. (Examples of browsers that could be used are Netscape running on UNIX or NT, or Internet Explorer running on NT.) 

### Req. 17.3: If a user wants to connect to the RVR Hubsite Server, the user is responsible for making a connection as specified in the RVR Interface Control Document.

# Issues {#issues .unnumbered}

None at this time.

**Appendix: Glossary**

ADU Application Data Unit

ALS Ambient Light Sensor

ATCSCC Air Traffic Control System Command Center

CD Controller Display

CDM Collaborative Decision Making

DPU Data Processing Unit

ETMS Enhanced Traffic Management System

FAA Federal Aviation Administration

ID Identification

IP Internet Protocol

LCD Local Controller Display

RCD Remote Controller Display

RLIM Runway Light Intensity Monitor

RVR Runway Visual Range

TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol/Internet Protocol

TSD Traffic Situation Display

TRACON Terminal Radar Approach Control

VS Visibility Sensor