A RADAR-VALIDATION SERVER

Zhiyong Li, Peter Mills, Lars Nyland, Jan Prins, John Reif, Bill Yakowenko

- Revised: Sun Sep 25 19:02:58 1994 by nyland@cs.unc.edu

Function

The radar-validation server computes a "coverage map", showing the amount of coverage of the radar over a given doctrine. The coverage varies due to the limit in height of the radar and the horizon shadow (inability to see past the horizon) imposed on the radar. The coverage map indicates the amount of the doctrine covered by the radar, computed over a grid of a particular resolution.

An example problem is

The result of doctrine validation is
This image shows a spherical radar region in blue (intensity varies with height), and a spherical doctrine that is greenish where it is fully covered by the radar, yellow-orange where it is partially covered, and red where it is not covered at all. Any activity in the red area would go undectected by the radar shown.

Interfaces

The radar-validation server retrieves data from several sources in order to compute the coverage-map. It outputs only the coverage-map. All data aquisition and distribution is done over TCP sockets, communicating with other processes across a TCP/IP network.

Input

Input data comes from many sources. Initiation by a user or periodic process starts the radar-validation computation. Data required for the computation come from the doctrine-server (giving the geometry of a doctrine), the track-server (locating objects, such as the ship on which the radar is located, on the Earth), and the radar-parameter-server (yielding the geometry of the radar coverage). Each of these arrives as a textual lisp-like S-expression, and the format of each is described.

Initiation Request

The radar-validation server is waiting for a command to arrive to indicate what doctrine to validate against the radar. The arrival of a message on a specific port begins the coverage map computation. The format is 

VERSION 2, in use, 10/15/94
 (validate doctrine-name dam-timestamp track-server-timestamp)

VERSION 1, no longer in use.
 (validate doctrine-name (clip-region) (resolution)
	track-server-port
	doctrine-server-port
	display-server-port)
where the doctrine-name is the name of a doctrine in the current data, and the 2 timestamps that follow are timestamps to ask the doctrine-server and the track-server for data at a particular time. For version 1, the doctrine-name matches a name in the doctrine dataset; the clip-region is a list of 2 positions (lat/long) on the Earth that define a bounding region; the resolution is a pair of numbers, indicating the number of sample points in the rectangular coverage-map; and the three ports indicate where to get/send the data (ports have the form "(machine-id port-number)").

An example is 

For version 2
 (validate carrier 120006 120001)

or, for version 1 
 (validate carrier ((22.1 24.8) (49.5 54.0)) (64 64)
	(alpha.ship.navy.mil 9991)
	(beta.ship.navy.mil 9001)
	(gamma.ship.navy.mil 9500))

Doctrine Data

Given the initiation command, we need to acquire the region that the doctrine covers. This can be done by sending the doctrine-authoring-module (a prototype developed by NYU Griffin team) a "get_doctrine_at" command with the name of the doctrine and a time-stamp value. The DAM then returns the doctrine in a lisp-like format that has been well-specified by Malcolm Harrison.

Track Data

Track data is required to position the radar geometry at the ship's location and in the case of slaved doctrine validation, the position of the object on which the doctrine is slaved. The geometric information retrieved from the DAM may be in relative coordinates, thus a basis must be determined and reflected in the geometric information. Of course, there must be coordination of the identifiers used in the doctrine data with the identifiers used for each track datum so that the necessary track data can be extracted.

No specification of where we should get track-data was ever supplied. As an exercise, we developed a track-server in Proteus, and extended it to cover all of the scenarios given in the Scenario Descriptions. We provided this service for our own purposes, and also invited other ProtoTech teams to use it as well. Intermetrics used it extensively, as did the NSWC developers working on the graphical ouput system. As the project was coming to a close, Bob Balzer of ISI supplied an enhanced version, which all of us used since 9/26/94.

Radar Parameters

The last datum that needs to be obtained is the shape of the radar. This has not been specified (other than pictorially), thus we obtain this information by creating it in our own code. Since it is nothing more than a geometric region, we have asked that it be stored with the other geometric regions by the DAM, and thus can retrieve it in a manner similar to doctrine-retrieval.

Output

The output of the radar-validation server is called a coverage-map. It is a grid of values indicating the coverage of the radar at each point in the grid. This information is sent to a display-server, a process that will display it visually.

Currently, the format is a list of values, where each value is a pair consisting of a region and it's coverage value. More precisely, 

Version 2, since 10/24/94, flattened at Balzer's request
	coverage-map ::= (element ...)
	element ::= (region value)
	region ::= (min_lat min_long max_lat max_long)
	value ::= (radar_depth doctrine_depth intersection_depth)

Version 1
	coverage-map ::= (column ...)
	column ::= (element ...)
	element ::= (region value)
	region ::= (min_lat min_long max_lat max_long)
	value ::= (radar_depth doctrine_depth intersection_depth)

By sending data in this form (rather than a grid of pixel values), the display function can be tailored to find the best method of converting this information into a meaningful representation. Our current display-server stub generates a portable-pix-map (ppm) file that shows areas where the doctrine is covered in shades of one color (doctrine_depth > 0 and intersection_depth > 0), where it is not covered at all in an eye-catching color (doctrine_depth > 0 and intersection_depth = 0), and the rest of the radar coverage in shades of another color (radar_depth > 0 and intersection_depth = 0).

Implementations

There are two parts to prototyping the radar-validation server. One is the interface to the rest of the AEGIS Hiper-D system, providing the ability to communicate with other processes over TCP/IP sockets. The second part computes coverage-map, a task where many different algorithms can apply. To this end, we have developed three different strategies of computing the coverage-map, one uses a ray-casting method from the center of the Earth, while the others decompose the problem into hierarchical regions (an oct-tree) where the coverage is simpler to compute within one small sub-region. Either approach can be used within the communications framework we have established.

Conclusions

Metrics

Design Commentary

Two types of problems have plagued us throughout the development of this prototype. They both have to do with the data supplied, but in different ways. The first has to do with the myriad of meanings of geographic measurements (which is still in flux). We've had measurements in feet, yards, K-feet, miles and data-miles, sometimes mapped to a flat surface, sometimes a sphere. It seems that it is of the utmost importance to provide a consistent measurement system, along with a full set of translation mechanisms (such as longitude/latitude/altitude to radius/theta/phi spherical coordinates), and distance measurements as well (for a variety of position representations). If we had had such an interface, as well as clarity in the specification and scenarios, many of our design meetings would have been significantly shorter.

The other specification with which we have had difficulty is in actually receiving the data. No formats were provided for incoming data supplied by NSWC until 8/29/94, and when it was announced, it was in a form that did not interface well with the prototyping systems being used. It also had the serious drawback that one process failing to read the incoming data could lock up the entire system with overfull buffers. This situation has evidently uncovered many of the problems of interfacing typical prototyping language components into a production system (especially a system with real-time deadlines). Prototyping systems do not typically allow a programmer full access to the machine (there are no high-level models for expressing some of the low-level capabilities), and prototyping systems typically run slower than production systems. We provided NSWC with an intermediate server that would consume all data from the real-time system, and provide data as needed to the prototype modules.

In addition, there are two components in this prototyping scenario that both require absolute geographical information, yet both parts must receive relative information and track information and then convert that into absolute information. There may be good reason for acquiring the track and doctrine data from separate sources, but it seems that one repository for geographical information would allow a single centralized place for the manipulation of geographical data.

Integration in a Production Environment

As of 9/27/94, our integration is not yet complete. We are using servers provided by other ProtoTech members, but receive/supply no service to NSWC modules.

Log Data

7/14/94	(lsn) Added socket capabilities to Proteus interpreter (2 days)
7/15/94 Discussed several designs with Proteus group members
8/08/94	(lsn) Finished initial dist. framework w/stubs
8/09/94	(lsn) Asked questions about architecture, user-interface
8/10/94	(lsn) Built several stubs, set up my own architecture
8/12/94	(lsn) Inquired about "radar parameters"
8/17/94	(lsn) Revamped code structure s.t. servers could be restarted at will
8/18/94	(lsn) Inquired about what to do with generated coverage map
8/19/94	(lsn) Got radar parameters picture, required new geometries.
8/23/94	(lsn) Received NYU structure of system, talked with Harrison
8/23/94	(lsn) Sought/recv info on track-data service from INMET & NSWC
8/25/94	(lsn) Recv an Ada header of graphical interface package
8/25/94 (lsn) Revised architecture, in light of M. Harrison's DAM desc.
8/26/94	(lsn) Set up track-data server, for use by us and INMET
8/29/94	(lsn) Discussed the optionality of 3d info from my track-server
8/29/94	(lsn) Recv track-data spec from NSWC-- binary, periodic data
8/30/94	(lsn) Req ascii, on-demand track-data, consistent with NYU-DAM
8/30/94	(lsn) Explored track-data service problems (buffer o-flow, lock-up) 
8/30/94	(lsn) Requested our two compute engines to have the same interface
8/30/94	(lsn) Discussed who should take care of providing track-data svc
8/30/94	(lsn) Started discussion of process priority, concurrent i/o
8/31/94	(lsn) NSWC track-data format and values require clarification
9/01/94	(lsn) Provided NSWC with track-data conversion program
9/12/94 (lsn) Made commands case-insensitive