Overview of the Radar Analysis Program (RAP)
The Radar Analysis Program (RAP) provides an integrated air picture based on reports from FAA radars, military radars, and direct downfeeds from aircraft equipped with ACMI pods. These data sources are integrated, providing an immediate and comprehensive current air situational awareness. RAP combines three tools to provide air surveillance monitoring and analysis. The first is an instantaneous view of the current air picture based on feeds from multiple radars including raw detections identifiable by source and type and a composite evaluation of air tracks. The second tool integrates this radar data with air information from other sources, including other sensor types and instrumented aircraft, to provide a more comprehensive real time view for air space control. The final tool includes analytic tools to understand standard air traffic patterns.
RAP was originally developed by Rome Air Labs in the 1990 and was subsequently entirely rewritten under the direction of the Wisconsin Air National Guard for the use of exercise range safety and control support. This redevelopment was performed in close collaboration with range officers to produce an interface that was simple to use and understand. Numerous interface features including clear map controls, continuous relative geometry readings between multiple user-specified points and aircraft, user-tailorable and savable interfaces, track fusion from multiple data sources, and user-defined track amplification information were incorporated into RAP to best suit these users. Moreover, RAP was redeveloped as a networked tool permitting operators at different locations to update a common track database and highlight tracks across the network for quick common reference by other operators in different locations.
While RAP is used heavily in a stand-alone mode to maintain a common civilian and military airpicture, RAP was designed to be part of a comprehensive system used both to form a robust composite situational understanding of joint operations and then to augment these operations with stimuli from simulated elements beyond the immediate exercise capabilities. This insertion of simulated elements serves two purposes. The first purpose is the expand the scope of training beyond systems commonly available for exercise purposes, for example to provide simulated inputs to Intelligence officers from space assets that 1) probably would not be made available for training and 2) would not correctly reflect the training scenario if tasked since the training scenario would quite possibly differ from the reality detected by this actual asset. These second purpose was to replace those exercise elements that dropped from planned exercises for various real-world reasons. For example, if an AWACS could not support an exercise when it’s presence was required, the composite system created at this facility would construct the required air tracks from RAP to replace the unavailable AWACS, reformatting them as required, to provide more a higher range availability and less exercise failures.
The data requirements for RAP in a standalone mode are very simple. The radar data from selected sites needs to be provided to a single PC-class computer. A laptop is adequate up to 5 sites. Today the data is received at a typical site using either RAID cards or Sensys-equipped computers. The radar data is then relayed from this interface as UDP broadcast on the facility Local Area Network (LAN). RAP then employs three background daemon processes to receive, process, and log this data. The first of these daemons is a communications client running in a tight loop that quickly retrieves the UDP packets from the LAN, logs them for later analysis and replay, and makes them available for the server. The server reformats the messages from each source separately as required by the tracker. The tracker forms an estimate of the true location of any aircraft based on the data provided by each site.
RAP can accept both tracks and detection data from reporting sites. When only detection data is provided, RAP’s tracker initiates tracks based on up to 6 frames of data from an individual site. A frame is defined as a single cycle of the sensor, so for a radar that has a 12 second sweep rate a frame is the data received within a 12 second window from the radar (adjusted to accommodate tracks flying in the opposite direction the radar’s scanning). This potentially involves resorting the incoming data in accordance with each site’s timestamp on each detection since significant communications latencies can occur that would otherwise invalidate cross-sensor correlations. Once a track is formed, detections from all sites are compared to this track in order to attempt correlation. The correlation is based on a dead-reckoning estimate of the track’s location over time and various error gates around the track estimate and the detection report. Those detections that correlate with the track are then considered together and used to determine a joint vote on the current true aircraft’s location. Factors considered for each of the candidate detections relative to that detection’s weight in determining the track location include:
1) history of the sensor’s inputs relative to this track
2) Distance of the sensor to the track
3) Timeliness of the report
4) Known sensor accuracy information (this is readily detemined by operators in the RAP by comparing the site-reported locations of ACMI-podded aircraft and the matching ACMI reports)
This figure demonstrates the detections that correspond to a single RAP track in an actual operation. In this case the detections are color-coded to reflect the site that made the report (this is a commonly-used operator option in RAP when raw detections are displayed). For reference it should be noted that usually the operator suppresses the raw detection reports and views only the final tracks because the operators tend to have confidence in the tracker and want de-cluttered screens. RAP also includes options to provide raw detections only for selected sites, or only in selected regions, or a combination of these filters. These options are examples of specific interface options developed to within RAP at operator direction to clarify the situation whenever possible but still provide the details operators need to do their jobs in atypical but important tasks (e.g. helping determine the probable location of a crashed small civilian aircraft).
An important benefit to RAP is that it operates in a networked mode to aid operators monitoring and controlling common airspace from different, potentially geographically distributed, workstations. The architecture is similar to the single-user (or standalone) mode of RAP except that only one computer serves at the master for data retrieval and tracking. This is done to support a central track database so any operator can enter information on tracks and that data becomes available to all other operators. Naturally, the user interfaces are independent, so each RAP instance can be tailored according to each user’s needs and desires. Moreover, RAP incorporates the ability for each user to save a custom set of views and filters that can be brought up upon request. This permits each user to immediately switch from the default interface to their preferred look and feel.
Not only can operators on the network update track information, but they can color-code or “flash” tracks of interest to call attention to these tracks by other operators. This helps coordinate activities among multiple operators working common problems in the same airspace.
Not shown in the networked-mode architecture is that client RAP interfaces have the ability to log in to only the central tracker. This dramatically reduces the communications requirements to maintain remote clients over limited communications lines, thereby supporting limited-access remote locations.
The true power of RAP becomes apparent when used in conjunction with JFORCES to integrate data from a wider variety of sources Figure 1 indicated this use at Volk Field for training and exercise support today. It is our believe that significant components of this system can be productized to support operations, thereby both increasing awareness in the field and reducing manpower requirements in the evolving battlespace. The approach used by the Wisconsin Air National Guard is illustrated here. JFORCES provides communications servers to a number of disparate sources, including AFATDS, USMTF, GCCS, and CCS. It maintains a common air, ground, sea and space picture and can broadcast components of that composite to other systems to maintain commonality. Great benefits can clearly be realized by this use in the field. The following figure reflects how this system benefits the training environment today by providing a single picture to orchestrate land and air activities in a typical mission. In this case ground data is piped into the situational display from a convoy on the road near the training facility. This information is displayed concurrently with information from radar sites and instrumented aircraft. Together this synergy of data permits the exercise director to coordinate air and land operations from a single computer. Without any one of these data sources this operation would have been impossible to coordinate easily; the combination makes this work simple, less error-prone, and requiring fewer operators with (potentially) less experience to succeed.
A final tool set in RAP is the ability to analyze historical radar data, looking for patterns. The benefit of determining these patterns is multifold include:
1) Identifying busy traffic lanes to help identify optimal non-interference areas for operations and associated approach corridors.
2) The potential future capability to flag aircraft deviating significantly from the norm so operators can focus on these actors instead of trying to pick unusual activity out of busy environments.
The results of these analyzes are used informally today, but could form the basis of traffic control and prediction models in the future.