RAP Tracker Parameters



Tracker Overview

JFORCES incorporates the Alpha Beta Tracker from the Radar Analysis Program (RAP). The tracker is used to integrate low-level air detections (Search, beacon mode 4 and similar reports) into ongoing reports on flights. The alpha-beta tracker does this by establishing new tracks whenever detections from three sequential sensor frames appear to form a straight line consistent with with an aircraft moving at a legal speed for tracking (as defined by the min and max speed parameters). A sensor frame is a list of all detections made by a sensor in one sweep. After establishing the track the the tracker will try to maintain it by correlating subsequent detections with estimates for where the aircraft should be according to it's last known location, velocity and acceleration “Alpha” in the alpha-beta tracker's name refers to the tracker's use of an estimated velocity vector based upon prior detections to predict updates and “beta” refers to the matching acceleration vector from these detections. In this tracker the beta component includes both linear acceleration (speeding up or slowing down) and curvilinear acceleration (turning).


In its simplest form, the alpha-beta tracker estimates where the aircraft that is represented by a track will be after “t” seconds according to the following formula:


New Location = Old Location + t*(velocity vector + .5*t2*(Acceleration Vector)

where the velocity vector is approximated as follows:

Velocity = (Old Location – Previous Location) / (time between observations)

and Acceleration is approximated:

Acceleration = (Current Vel Estimate – Previous Vel Estimate)/(time between observations)


Note that tracks are formed on detections sequences without knowledge of whether the detections are actually derived from actual aircraft; they could be caused by unrelated events, including atmospheric conditions or near-ground phenomena. This would be a source of “false tracks”. For this reason a tracker continually attempts to correlate new detections with known tracks. The intent is to eliminate these false tracks as soon as possible since it's unlikely that subsequent detections would correspond to this track. However, to confuse matters, reaquistion of tracks corresponding to actual aircraft do not always occur on every sensor frame. For this reason the tracker must be robust enough to accommodate a limited number of missing detections in a track but drop the track when it's not confirmed for a significant amount of time. During the period the track is unconfirmed by new detections the tracker must still output track location estimates. The estimates are called “Dead Reckoning” estimates because they're based on the a simple estimate of where the track would be for forward-chaining from the last known location based upon last estimated velocity with a limited acceleration factor.


As mentioned above, the location formula given above only refers to the simplest case. Unfortunately, this equation is unusable with real data. The reasons for this include:


  1. The real data is very noisy

  2. Locations are notoriously inexact in actual observations. Part of the reason for this is the reported range resolution from the sensor to the target is very granular.

  3. Atmospheric effects can distort location reports

  4. False detections can occur near real ones and might be interpretted as the actual detection. This is particularly (and annoyingly) common when maintaining a track based on search reports on a maneuvering aircraft.


For these and related reasons a tracker requires a number of rules on “smoothing” data and discarding noise. In addition, these rules often need to be “tweaked” in specific regions with unusual activities or noised, and therefore this tracker supports the use of global rules and regional rulesets that override all or specific parameters of the default (global) rules within the specified region. The noise suppression approaches employed in this tracker are described in a following section identifying these parameters.


In addition to the correlation problems described above, this tracker combines the data from multiple air sensors into a single integrated air picture. This leads to additional error sources for false tracks, in part because



Recognizing multple-site correlation error, this tracker attempts to first maintain each track using the reported detections one master sensor and then correlate detections from other sensors to that track in order to improve the integrated air picture. However, be itself this approach would not significantly improve the air picture available from a single sensor, so an algorithm maintains the sensor control of each track according to the relative proximity of sensors reporting on a single track and evaluting handoffs when the master sensor reports no correlating detections for one or more frames but an alternate does. User parameters are provided for specifying these rules. It's expected that this algorithm might later be improved to recognize the quality of detection capabilities for various sensor types (e.g. IR versus RADAR or single versus multi-spectral) in the future.


File versus Database Inputs


This tracker is used both by the JFORCES simulation and the RAP program and in each case the user is provided a method for inputting both global and regional tracker rules. In both cases the parameters are identical and are describd in the next section. But there was a desire not to require a database be required to support RAP, so a flat-file input is used instead.


Note that in either case these inputs can be skipped. In this case the default parameter values will be used.


To define the tracker rules in JFORCES start the standard interface and go the the Mission Planner for the scenario. Then go to “Scenario Defn”->Employ Automated Rules->Air Defense C2 Options. The interface shown here will appear. To specify tracker parameters click on the line in the upper frame that says either “Default Tracker Correlation Data Will Be Used” or “Tracker Correlation Data Defined – Please Verify Reasonableness”. In either case a dialog will appear providing the option to Review the parameters. Pick the Review option and this interface will appear. Edit the global parameters on this interface or click on the “Regional Rule Specific” to review, edit, create and delete regional rules to override the global rules in specified areas.


The file input system is naturally clumsier, but more robust for varied RAP installations. A file named TRACKER_RULES must be created in the directory specified by the RAP_DATA_DIR environmental variable set in the user account. The normal setting for this directory is /data/rap. Click here to see a sample of this input file. The parameters are listed with equal signs and values on the same line behind the variable. The first section defines the global variables; subsequent sections are identified by regional names in square brackets (e.g. [Region 1] in the example). Parameters defined after a region header will apply only to detections and tracks within the region. Not all parameters need to be specified in any section – the default paramters (listed below) will be used for any unspecified variables. An exception to this comment is the regional limits (North, East, South and West) for Regional rules. Each of these values must be specified or the regional rules will be considered invalid. These parameters are ignored if specified in the global rules section.


Comments are permitted in this file. Comment lines must start with a “#”. Empty lines are also permitted to enhance the file's legibility. Also note that capitalization is NOT important; the system converts all of the names to all capitals before evaulation so feel free to use any capitalization scheme that looks good to you.


Finally, check the diagnostic outputs from the tracker application after you change this file. Any non-understood parameter specifications will be identified near the top of these diagnostics.


Tracker Rule Parameters


Name

Description & Comments

Legal Range

Default

Min_Speed

Minimum speed (knots) to consider for creating or maintaining a track

Any positve value

50

Max_Speed

Maximum speed (knots) to consider for creating or maintaining a track

Nay value greater than min_speed

2000

Max_Accel

Maximum acceleration (knots/seconds) to consider for correlation a candidate detection with an established track

Any positive value

1000

Alpha_Factors

Weighting factors (5 values) for defining the value of previous detections to the current track location estimate. For example, if this is set to (.3, .2, .2, .2, .1) the latest detection will be given a weight of 30% in determining current track location, the previous 3 detections 20% each, and the oldest recorded detection a 10% weight. This is used to smooth out track irregularities caused by detection reporting errors.

Note that all five values are defined on the same line without commas or other separation when file input is used.

Any real values. It's easiest to understand when the sum of the absolute these values sum to 1, but this is not required (if not the system will do this for you during initialization).

.2, .2, .,2 .2, .2

Beta_Factor

This is the power factor applied to acceleration in the alpha-beta location estimate. According to simple phisices the new lcoation should = (old) + vel*dT+.5*dT*dT*acceleration. In this case the Beta_Factor is 2. But the user is permitted to modify this value in recognition that acceralation is not generally unlimited, even between sensor scans (e.g. Aircarft will not necessarily continue turning indefinitely)

.5 to 3.

1

Missed_Scans_for_Alternate_Mode

This is the number of frames that the master sensor will make without correlating a detection to an existing track before the algorithm starts considering detections from this same sensor with different reported modes. This is employed in case the aircraft changes it's squak.

Any real value >= 1

2.1

Missed_Scans_for_Alt_Sensor

This is the number of frames that the master sensor will make without correlating a detection to an existing track before the algorithm starts considering detections from alternate sensors reporting detections that might correlate in the same area. If another sensor is deteremined to have a correlating report it will be deignated the master sensor for this track..

Any real value >1

4.1

Correlation_Range_With_Mode_Match

Range (NM) from the estimated track location to consider the detection as correlated to the track both when attempting to confirm an ongoing track or when correlating reports from other sensors than the track master sensor to a track. This value is used if the transponder modes match.

Any positive value

4.0


Correlation_Range_Without_Mode_Match

Range (NM) from the estimated track location to consider the detection as correlated to the track both when attempting to confirm an ongoing track or when correlating reports from other sensors than the track master sensor to a track. This value is used if the transponder modes match OR either of the reports do not have transponder information (e.g. Search reports)

Any positive value

2.0


Min_Range_Ratio_For_Sensor_Change

Range limit at which we'd consider changing the master sensor between two sensors reporting on the same track. This value is the ratio of (range to new candidate sensor) / (range to current master sensor). This value is usually set to less than 1 to avoid the track control “ping-ponging” between the sensors as an aircraft flies between them.

Real values >0 and <=1.

0.8

Max_Dead_Reckoning_Time

Maximum time (in sensor sweeps for the track master sensor) that a track will be maintained without reconfirmation. Since this value is in sensor sweeps a value of 10 represents 120 seconds of time if the sensor scans once every 12 seconds.

Real values >=1.

10

Max_Heading_Diff

Maximum heading difference (in degrees) for a track from one sensor to be considered as equivalent to a track from another sensor.

Real values > 0.

30

Max_Returns_In_Region

This is a noise reduction paramter intended to prevent the tracker from generating an unreasonable number of false detections in an area of enemy detections. This is the number of detections in a region equivalent to the area represented by 5 degrees of sweep by 5% of the sensor's rated maximum range at the sensor's maximum range. The azimuth bounds are expanded as ranges closer to the sensor are considered.

Integer values > 1

10

Nuke_Range_Check

This is used only for maintaining passive (angle-only) tracks versus emitters (usually jammers). It specifies (in NM) the max range of recent neclear explosions to consider when tracking emitters. The tracker will not form passive tracks when a known nuclear event has occurred within this range and within the track_bearing_check parameter of the bearing to the explosion

Positive values

400

Track_Range_Check

Used to evaluate the possibility that an active track might correlate to a passiver track, this is the range in NM for a correlation based upon where the track is expected to be and the estimated location (note the Track_Bearing_Check paramter is used in conjunction with this variable to correlate the two types of track). The intent is to attempt to preserve information on the original active track when the target starts jamming

Positive values

100

Track_Bearing_Check

This is used only for maintaining passive (angle-only) tracks versus emitters (usually jammers). It specifies (in degrees) the minimum separation between distinct passiver tracks from a site.

Positive values

2

RDET_SEARCH

Flag for whether the tracker should try to use searc reports to new create tracks. This is the most common type of detection to tell the tracker to ignors in areas generating lots of clutter (e.g. Ridgetops). Note that the tracker WILL use these detections to maintain preexisting tracks that were based on this type of report (e.g. Tracks employing search reports that enter a region with this flag turned off).

Either 0 or NO for no, 1 or YES otherwise

1

RDET_BEACON

Flag for whether the tracker should try to use beacon reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_SBEACON

Flag for whether the tracker should try to use beacon reports reinforced with search reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_IDBEACON

Flag for whether the tracker should try to use ID beacon reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_MODE4

Flag for whether the tracker should try to use Mode 4 reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_SMODE4

Flag for whether the tracker should try to use Mode 4 search reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_BMODE4

Flag for whether the tracker should try to use Mode 4 beacon reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_SRRSCH

Flag for whether the tracker should try to use Short Range Radar (SRR) 3D search reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

RDET_SRRSTB

Flag for whether the tracker should try to use other reports Short Range Radar (SRR) reports to maintain or create tracks.

Either 0 or NO for no, 1 or YES otherwise

1

North

Northern region limit (in decimal degrees). Used only for regional rules.

Real values between -90. and 90.

N/A

East

Eastern region limit (in decimal degrees). Used only for regional rules.

Real values between -180 and 180

N/A

South

Southern region limit (in decimal degrees). Used only for regional rules.

Real values between -90 and North

N/A

West

Western region limit (in decimal degrees). Used only for regional rules.

Real values between -180 and East

N/A