This document is Volume 9 of the "Software Programmer's Manual for the Air Defense Initiative Simulation for Command and Control (ADISC2)", delivered October 3, 1990 This section covered the sensor module, also known as a Computer Software Component (CSC).  The ADISC2 model was incorporated in whole into the JFORCES model, so this documentation addresses the core sensor representation found in JFORCES. Given the many changes made since the time this document was prepared, some updates have been required.  Still, the core of this document is valid and should be interesting both to programmers and analysts trying to understand the sensor algorithms.  To date there's been no funding to update this documentation, so it stands largely as originally written. But some comments have been made in the body where the original statements varied significantly from the current state.  These changes are:

1)     Where appropriate, the original program name (ADISC2) has been changed to JFORCES.

2)     There's been some minor rewording to reflect the formatting changes.

3)     Significant text updates are highlighted in non-bold italics.

Note that this documentation should be used in conjunction with the User's Manual documentation, found at  This documentation is regularly updated, although the focus is not as detailed as found here.

 A quick word on conventions is in order. A word in bold italics (e.g. prelimsensor) indicates the name of a subroutine.  Because this is a programmer's manual first, and an analyst's manual second, subroutine references are used heavily to aid the programmer in understanding the code. 

The use of pseudocode (as defined at is used to detail algorithms.  Please reference for the pseudocode conventions used in JFORCES.  The written documentation naturally can become outdated, but be aware that the JFORCES team tries to maintain the pseudocode actually incorporated in the operational code and this can be extracted for reference. See for information on how to extract the updated pseudocode from the current JFORCES code.


Please click on the hyperlink to go to the section.


Program Control





·       Sensor Message Creation

·       JSS Message Representation (Sample Simulation / Operation Message Conversion)

Sensor CSC Purpose

The purpose of the sensor CSC is to provide a realistic representation of the sensor assets employed in air defense. To do this the sensor CSC provides a list of an detections made by each simulated sensor site or center. This list of detections includes both real and spurious detections. The determination of whether a sensor site detects a particular target is made based upon the detection operations of the sensor type, the performance characteristics of 1the sensor, the projected threat signature, the effectiveness of threat countermeasures against the particular sensor type, and the local environment affecting the detection The environmental considerations affecting the detection of a target include the terrain, weather, and nuclear blast effects. If a real or false detection is made, the sensor module will packet the message to be sent and attempt to transmit this data. The data will packeted in a manner consistent with the message format specified for the sensor system by the analyst during presimlation data base definition. The sensor module will determine whether sending this message to the site within the propagation and transmission limits of the communications gear at the simulated sensor site as determined by the communications module. If so, the sensor module then simulates broadcasting these detections to the appropriate operations center. In the JFORCES simulation this results in transmitting the detection (or track) message to the destinations.  These destinations can include man-in-the-Ioop (MMI) nodes, the in-line tracker package, external targeting algorithm, automated air defense modules, or others.  Any, or all, of the modules can receive real and false sensor reports. When desired, a translation program at the receiving MMI nodes can broadcast messages in the actual format on any LAN to which they are connected.

Throughout the JFORCES sensor module design a differentiation made between sensor sites and sensor centers.. A site (e .g. a JSS site) sends all detection data to the SOCC or ROCC, but a sensor center (e.g. the OTH-B center) has adequate personnel to perform preliminary filtering and forwards data only on tracks interest to the to the SOCC or ROCC.   The type of data transmitted by these two types of sensor facilities are different, and generally the data from sensor sites will be higher volume and place more demands on the MMI display graphics, the tracking algorithm, and the C2 track evaluation routines.

JFORCES Sensor Design

As required by the ADISC2 contract, the JFORCES design presently incorporate the sensor systems listed in the above chart. But this list is incomplete because the flexible data-driven design permits an unlimited number of sensors to be defined and modeled within this framework The sensor design will accommodate 100's sensor systems, thereby allowing for future expansion and adaptability to future needs. The details of this design will be addressed later in this section and in the common block definitions. As described in later diagrams, in 1990ADISC2 modeled eight (8) different sensor phenomena's, or sensor categories, and each of these sensor systems must fit into one of these categories. (Since that time the list has extended to 17 different types of sensors). These categories are:

1) Standard Line of Sight (LOS) Radar. This representation uses the radar range equations based upon the signal to noise at the receiver.

2) Generic LOS Radar. This representation is a fourth root scaling representation of detection range versus Radar Cross Section (RCS)

3) Over the Horizon (OTH) radar

4) Passive antisubmarine warfare (ASW) sensors

5) Electronic surveillance Measures (ESM) sensors

6) Infrared (IR) sensors

7) Multi-static radar sensors (distributed transmitters and receivers)

8) ASW localization sensors. These are modeled in the Engagement module and are documented in that module as well.

An example of one of these categories of sensor representation is a signal-to-noise representation of typical radars. Both the FPS-117 and the TPS-43 radars might be modeled using this representation but with different radar performance parameters. JFORCES stores these parameters separately for each radar type, allowing the flexibility derived from a data-driven system. The performance parameters are uniquely defined for each sensor category and the maintenance of these parameters is performed by the sensor.cmn common block structure. These categories and parameters will be discussed In detail in the following sections.

It should be mentioned that the message formats output by sensors are modularly disconnected from the sensor detection algorithms. Thus the message formats used by each of these sensors s not hardwired but instead is as defined for the particular sensor subsystem by the user during data base prototyping. The message format options are addressed in the Processing section of this document.

List of Sensor Activities

Note:  This list represents sensor activities and operations in the original 1990 delivery.  This list has since been significantly expanded with options including cross-sensor cueing and multi-sensor correlation

This list of sensor activities outline the operations which may be performed by the sensors represented by the JFORCES. In addition to this list of operations, the basic sensor functions of detection and tracking are represented .The detection and tracking operations are modeled as being performed in an environment incorporating weather, nuclear effects, and threat countermeasures.. The moving target indicator (MTl) is modeled by limiting candidate sensor targets to only targets with speeds within defined specifications

Attribute Matrix

This matrix (”Modeled Sensor Attributes·).presents the attributes modeled for the contract-required sensor systems modeled in the JFORCES (circa 1990, expanded since). Because sensor systems are modeled by category (e.g. Line-of-sight radar, OTH radar, or sonar) with common parameters used to define the performance characteristics of various sensors in the same category, the same attributes are generally modeled for various sensors in the same category This exploits the use of the same code for a family of similar sensors by using data-driven sensor class representation, thereby permitting detailed sensor representation of a wide variety of sensors with minimal code.

Sensor Controller Operations

This figure presents the current (circa 1990) implementation of the sensor controller.  The functionality of the sensor controller is incorporated in the JFORCES simulation executive (EXEC).  The EXEC invokes the three major initialization elements. The first of these initialization elements defines the sensor class, the performance attributes,  and transmission protocols for each sensor type that will be used in the simulation. For example, this stage of initialization includes defining the performance of the APY-1 sensor system. In addition to reading in the sensor performance parameters, a message is stacked on the event stack to call the prelimsensor routine during the first simulation update. This message is identified as a “msgsensorko” message and incorporates the sensor type number.  Asdescribed below (in the processing section of this module's documentation), the sensor detections for all sensors of this type (e. g. for all APV-1 radars) will be determined at this time as a result of prelimsensor routine receiving this message. The second initialization element defines the objects classes that will carry each sensor subsystem and defines how many sensors of each type will be used on objects of a given class.. In the above example this part of the initialization process would specify that every E·3C has an APY-1. The final initialization element deploys the sensor assets as dictated by the scenario. This results in locating AWACS in flight and on bases with the option of having prescripted routes for selected aircraft. The runtime simulation initialization documentation includes more detail about this process.

After initialization, the sensor controller (EXEC) invokes the appropriate code to represent sensor systems. Two types of code controls are used to do this. The first type of code control invokes selected code periodically during simulation execution. An example of this is the code to determine JSS detections is called every 12 seconds for all JSS radars. This periodic type of control addresses most routine surveillance sensor operations. When operations are not logically performed periodically p the EXEC allows routines to be called upon prescripted or interactive command.  An example of this would be changing the OTH-B detection barrier or to cross-cue sensors The code to represent the changes occurring as a result of this type of command is executed immediately upon simulated receipt of the command from the operator  (or the automated control algorithm). Commands of this type will not be executed if the communications module determines the message was not successfully transmitted.

All sensor activities (both periodic and operator/event invoked) are initiated by messages to the sensor module passed to that module by the EXEC. The periodic determination of sensor detections is initiated by the receipt of a msgsensorko message by the prelimsensor routine in the sensor module.  During initialization one of these messages is created for each defined sensor type. The sensor type is identified in the message body. When one of these messages is received by theprelimsensor routine the sensor and environmental data for each of the sensor sites of this type are updated as described in the processing section of this documentation.   Thus, the sensor detections of all JSS radars are determined for one scan at the same time as a result of the receipt of one message. The receipt of another msgsensorko message would be required to command prelimsensor and its subroutines to update the detection status of all AWACs sensors, and so on. Prelimsensor not only executes the periodic processing associated with determining sensor detection status, but also stacks another msgsensorko event to be sent to this routine for the same sensor type after a time period based upon the sensor scan rate times the current simulation update granularity. This structure thus periodically updates the sensor detection states of all sensors of all active sensor types according to the sensor scan rate as adjusted by the update granularity. The processing documentation describes in more detail the actual processing that occurs during detection updates and command invocation.

The track update algorithm is also controlled by an autonomous self-calling loop with a delay like prelimsensor.   The tracker, however, is called only once per update cycle and all tracks, regardless of sensor origin, are updated at this time. In addition, the tracker is called on an immediate event basis as a result of user commands affecting tracks (e. g. initiating a track or changing the track information) or whenever a sensor message is received. This last event results in high volume communications between the sensor module and the tracker.

Sensor CSC Interfaces

The sensor CSC interfaces to the following other CSCs for the following reasons:




Pass commands and any data messages.  Also maintain any required control methods (e.g. periodic updates)


Access weather, nuclear detonations~ and chaff  data to determine effects on detection capabilitiesdetection capabilities

Scenario Generator

retrieve object states including locations, subsystem states, and operational tasks


Attempt to transmit data to operations center and other simulated elements that should receive sensor data in an operational environment

Operator Interfaces

1)     Transmit sensor detections

2)     Access and change sensor-related data (umpire only)

3)     Issue commands


retrieve object states including locations and subsystem status (this includes sensor, jammers, and communications suites)


The interface structures to these modules is described in the below (Note - these tables represent 1990 capabilities, but are kept here as indicative of the type of data that can be passed between CSCs. Note that current versions of all messages can be reviewed via the JFORCES interface under System Controls->Debug->Review ICDs) These tables describe sensor module interlaces through each common block (Note – The sensor module has been rewritten and is primarily in C today, so the common block approach has been replaced by other data-passing methods)  and via messages with the other code modules. Where more detail is required (e.g.. the type of data being passed and the routines involved) please see the header interface and the ICD documentation.


Sensor HW/DB Interfaces

This figure diagrams the hardware and software interfaces pertaining to the sensor CSC (circa 1990 –additional realtime sensor interfaces have been added since) The primary hardware interlace links the simulation host or hosts to the various operator workstations This interface is accomplished via the EXEC message passing utilities. The sensor reports and intelligence messages are passed between these hardware units. Intelligence is mentioned in this diagram because intelligence reports may be correlated with sensor reports at the operator workstation and is correlated as part of the track evaluation and situation monitoring processes by the C2 module.  All interfaces with other simulation functional modules and with the environment, objects, and relational data base described in the previous figure and tables occur at the simulation host. If a future version of the simulation is divided among multiple hosts, the EXEC would synchronize the various simulation software components via its message passing utilities. But, the current system is designed to run with one a single simulation host and the data interfaces between modules running on separate hosts would need to be replaced or supported by an underlying message passing structure to maintain the required data on all on the hardware nodes.

Sensor and Tracking Modules

The sensor module includes a tracking submodule (algorithm) that is populated with sensor reports that the simulation determines would reach the operational center. The interfaces between the sensor detection routines and this tracker are presented in this diagram. The tracking submodule maintains tracks on user-designated targets and models tracking operations at a SOCC or ROCC. As such, this tracking algorithm models JSS tracking and does not model the tracking of objects occurring at the various other sensor centers including the OTH-B center and AWACS. The differentiation between sensor sites and centers that is made in the JFORCES design is described in the first chart of the sensor module requirements documentation.  (Note – Additional trackers, both actual and simulated, have been added since the time this document was written for various applications and studies) The tracks maintained by this submodule are available to all operator workstations at that designated simulated operational center.  The user-input comments on the tracks are maintained in the same surveillance data base. In this diagram the sensor detection routines are represented in the upper left-hand comer, the tracking routines in the upper right-hand comer, and the MMI processes on the bottom center.  Currently, the tracking algorithm is assumed to be co-located with the sensor detection code (no longer true since the tracker has been separated to support real-world operations) and must be co-located with the C2 module. The design supports separation of the tracking function from rest of the sensor module for future application; this has been demonstrated by the incorporation of the JDT tracker into the JFORCES.  However, the functional dependence of the C2 module upon both the tracker and the other sensor data restricts the separation of these functions when the C2 module is invoked.

As indicated by this diagram, both plot and track data from simulated sensor sites and centers are broadcast to both the tracking routines and to the MMI display processes. This supports both the operator display of raw sensor data and the tracker requirement far raw sensor data. The tracker outputs additional track data to the MMI and makes this data available to the C2 module. The MMI node may act as a gateway for information flow from or to any external experiment. External sensor detection information received by the tracking algorithm would be handled the same as sensor reports from a simulated sensor provided that the tracker has the required sensor definition data.  Primarily this data is the sensor location and the scan rate.The MMI node is employed as a gateway for outgoing data in order to provide a filter for the sensor reports by sensor site or type. This is accomplished at the operation workstation by a selection of the reporting sensor, the region of interest for displaying detections (or tracks) and the type of reports to display. The MMI node can then packet and retransmit messages received from the simulation to non-JFORCES applications.

JFORCES / Real World Interfaces

(circa 1990 – expanded dramatically since)

This diagram, (“ADISCs / ReaJ World Data Interface (ADISC2 as a Sink)") presents the use of the JFORCES to accept and use real world data in a simulation run. In this example, the real world data being injected includes tracking data from actual tracking algorithms. It should be noted that injecting actual sensor reports into the JFORCES is done the same way. As messages are generated by the real world source, they are transmitted to a simulation host machine.  Therefore a machine in the same network as the rest of the simulation, and on which a copy of the EXEC is running in conjunction with the rest of the simulation, would be tasked with this interface This data would be sent to this machine by the standard communications used to transmit the data into the SOCC or ROCC or by standard modem communications (or other method as used for that data source in the real world, in this case the data was transmitted via modem) The data is then received by the destination machine by a modem program. This modem program is a separate process from the simulation, but communicates to another process hosted under the executive by interprocess socket communications. The transfer process running under the executive would receive the message from the socket, put it in the format used by the simulation, determine its destination, put the executive header on the message, and send the message to its destination using the executive communication utilities. This process produces a simulation message indistinguishable from messages generated by the simulation and thereby seamlessly integrates real world and simulated data into one consistent simulation .. The diagram presents the method of using the JFORCES as a data source to support external (or “Real World") experiments.

This figure, ("ADISC2 / Real World Data interface (ADISC2 as a Source)") presents the compliment of the previous figure, using the JFORCES as a data source to support external tests. Together, these two capabilities allow the JFORCES to be fully integrated with external experiments and, for example, provide sensor messages from the simulation to drive an alternate tracking algorithm and respond to the tracking results 

In this diagram, a message is generated by a the simulation and one of its destinations is an interface program to an external tracking algorithm"The message is sent to the ' interface program using standard executive communications utilities. The interface program extracts the data from the message and reformats it as necessary to support the external experiment. Examples of changes that might need to be made include changing the order of the message elements and adding any additional message data that the simulation does not require. These minor differences between the actual messages and the messages used by the JFORCES shorten the messages passed by the JFORCES, thus increasing the number of messages the JFORCES can pass and the number of nodes which can be supported. The message in the final format is then sent to a separate modem process running on the same machine.  This separate process then sends the message to the external experiment via standard communications. An initial application of this concept was performed in support of the PRDA workstation demonstrations at RACC. In this case the JFORCES MMI node was used as a gateway of information from the simulation to the PRDA workstations. This gateway amounted to relaying simulated detections and tracks received from the simulation by the JFORCES bW8 node workstation to the PRDA workstations.. The JFORCES workstation was equipped with a translation program (named pack.c) to convert sensor reports from JFORCES internal format to standard message format for particular sensor types. This data was then broadcast in UDP protocol on a second LAN attached to the JFORCES workstation. This approach was selected because by using separate JFORCES operator (blue) workstations with different sets of PRDA-type workstations connected on separate LANs, each workstation could tailor the set of sensors reporting to it and thereby simulate the different data available in different SOCC. This approach provided the flexibility to explore and evaluate distributed C2 concepts.

Typical Sensor Inputs

This figure presents the attributes modeled by the JFORCES (circa 1990). Many of the sensor performance parameters are common to all sensors of the same type. Additional attributes are listed for:

  1. Fixed site sensors (where appropriate)

  2. Airborne sensors,

  3. Naval mobile sensors (i.e. not including SOSUS), and

  4. Space surveillance sensors

These additional parametric requirements are driven by the object and communications representation of the platforms the various sensor suites are on. The objects/utilities and the communications module documentation describes these. The following section of the sensor design documentation describes the sensor attributes modeled for each sensor system presently in the JFORCES.

Sensor Data Structure

This figure presents the top-level view of the data structure supporting the JFORCES sensor representation. The basic data structure for the scenario players represented in the JFORCES is the object structure. This structure is used to describe each player in the scenario. Part of this structure includes a list of the subsystems used by each asset and the present status of each of these subsystems (see OBJECTS / UTILTIES module and the objects and platform structures, interactively reviewable under the JFORCES GUI by selecting System Controls->Debug->Public Structures).  By providing the list of subsystems on each asset, this structure points to the parameters describing the subsystem (ie. it points at the specifics of the AWACS radar for E-2s) .. Multiple pointers may exist from a single object to sensor subsystems, thereby allowing a single asset to have multiple sensors. The sensor attribute description includes a header and both the detailed performance data for the particular sensor and pointers to electronic countermeasures (ECM) susceptibility. All of the sensor performance parameters (both header data and sensor specific data) are maintained in the sensor structure. The contents and format of the data in the sensor subsystem attribute list and the ECM susceptibility list are described below.

Sensor Subsystem Header Parameters

Note:  This description pertains to ADISC2, circa 1990.  For an up-to-date listing of the parameters check out the sensor structure by starting the JFORCES interface and selecting System Controls->Debug->Public Structures

The figure describes the parameters common to the definition of allensor subsystems . These parameters are maintained in the sensor structure.  The actual formats and order of these parameters are documented in this common block.

The first parameter is the sensor subsystem name. This name is completely user definable within the restriction the first eight characters must uniquely indicate the sensor subsystem type. For example, while SNSRAB and SNSRABC are legal sensor subsystem names, SENSORAB and SENSORABC would not be legal sensor names in a single data base because the first eight characters of the names do not uniquely identify separate sensor subsystems..

The second parameter describes the sensor category, Le_ the detection phenomenon and modeling representation. The sensor types represented in the JFORCES in include (Note – this list was updated to reflect 2005 capabilities):

  1. LOS Radar - Standard radar representation where adequate data is available.  This rapresentation uses the radar range equations from Skolnik described later

  2. OTH Radar - Over-the Horizon Backscatter Radar

  3. Passive Sonar - Passive sonar sensor

  4. Space Based Radar - space-based radar

  5. Generic Radar - Standard radar representation when the available data is inadequate for the LOS radar representation.

  6. Bistatic / Multistatic Radar - Bi-static radar (transmitter and receiver not collocate)

  7. ASW Localize - ASW Localization gear (e.g. sonobouys)

  8. ESM Gear - Electronic Surveillance Measures sensor (radio receiver with SIGINT capabilities)

  9. IR Sensor - Infrared sensor

  10. Optical - Optical sensor, ranging from satellites with EO capabilities to human eyeballs

  11. E-3 Radar - special interface for a ESC-provided AWACS model

  12. Active Sonar - Active sonar systems for naval vessels (surface and submarine)

  13. Mobile Passive - mobile passive sonar systems for naval vessels (surface and submarine)

  14. Passive ASW - Other passive Anti-Submarine warfare models (e.g. SOSUS)

  15. Generic Ground Detection - generic ground surveillance sensor

  16. Fire Finder - Artillery fire finding radar

  17. SB IR - Specialized detailed space-based infrared sensor capable of emulating on-board focal plane

  18. RHAWS - Radar homing and warning system. Also used for tactical ESM Infrarometer.

Because the parameters defining sensor performance rely on the type of sensor being modeled this first piece of data indicates the data template that will be used to extract the performance parameters following the header.

The third parameter describes whether the sensor detects targets in air, sea, submarine, space, or on the ground. The fourth parameter defines the susceptibility of the sensor subsystem to electromagnetic pulses The fifth parameter defines the message formats that the sensor subsystem uses to communicate with the operations center. The sixth and seventh parameters provide a coarse-cut at the sensor range. These parameters are used to perform a coarse filter on the objects which might be seen by the sensor" The seventh parameter defines the false alarm rate in an ambient environment .. This rata will be modified by weather and other environmental factors according to sensor type and attributes

The final parameter in the header is a pointer to the ECM susceptibility tables. The simulation determines this pointer during initialization.

ECM Susceptibility Tables

The ECM susceptibility tables list the probability for the particular sensor that a particular ECM suite win jam it. This table is used only for smart jamming techniques; noise jamming effectiveness is determined directly based upon sensor and jammer performance.  These tables list the name of the smart jammer suite, the probability of successful jamming, and the effect of this suite on the sensor. Only spoofing is currently modeled~ It is modeled by denying sensor detection of the target and randomly creating zero to ten spurious detections in the vicinity of the jamming targetThe vicinity is defined as within 10 degrees of the actual target bearing from the sensor site and within 25% of the actual range

Sensor Representation

In 1990 ADISC2 included the following eight classes of sensor representations:

The above figure shows how the contract-required sensors presently incorporated in ADISC2 fit into these classes. It should be noted that the user is not entirely forced to use a specific class for any radar; his selection should be based upon the available data as well as the sensor type.  For this reason JFORCES includes multiple representations that can be used for modeling a radar.  For example, JFORCES incorporates both standard and generic representations of the JSS radars and either can be used in a simulation run simply by defining the sensor subsystem at a JSS site as having either representation according to his representational requirement and available data.  JFORCES does not force the user to use a standard representation when he has the data to support only the generic representation, or vice versa

Both the data representation of the JFORCES and the detection processing flow will be described separately for each of these sensor categories.  (Note – because this document was drafted in 1990, only the above 8 sensor types are described here.  Please see the User’s Manual for information on sensor types added since that time). Before reviewing the data or processing flow, however, a discussion of the different radar representations win be provided. This includes an outline of the procedure to be employed when incorporating new or different sensor representations into the current JFORCES framework.

JFORCES Framework

(Note – Since this was written the sensor module has been changed to C. In light of this please refer to the sensor structure instead of the sensor.cmn common block referenced in this description)

The JFORCES framework incorporates a series of readily modifiable case structures that allow the expansion of the current ADISC2 to incorporate both new sensor representations and different sensor representations of currently modeled sensor types. As indicated in this figure two line-of-sight (LOS) radar representations have been incorporated into the JFORCES in order to demonstrate how to do this. In addition, another radar representation was incorporated into the ESD version of ADISC2 as part of O&M activities. The facing chart lists the in the strengths and weaknesses of the two radar representations. These representations may be used interchangeably. As can be seen, the standard representation is generally better for well known and measured systems while the generic system is better for "blue sky” concepts. The disadvantage to the generic representation is that it can not accurately model noise sources, including persistent nuclear effects and noise jamming. It is as good as the standard representation, however, for smart jamming and chaff representation.

As stated above, the reason for including two radar representations is to provide a concrete example of the incorporation of new radar algorithms into the ADISC2 framework. In general, the process for incorporating new sensor representations is as follows:

  1. Determine the parameters required to define the sensor's performance during data base prototyping.

  2. Determine the number and characteristics of parameters to be supported for each sensor typeduring runtime. This list may be different from the list developed in step 1 for a number of reasons. In the currant JFORCES signal-to-noise radar representation, for example, the data base inputs include the antenna aperture, the antenna efficiency, and the system losses. These parameters are used in data base definition because they are familiar to radar analysts and the data is often available in this form. However, during simulation initialization these are combined into a single antenna factor used in the radar equation employed in routine losradardet. The reason for combining these is to reduce the number of floating point operations, thereby decreasing runtime without reducing the quality of the representation.

  3. Determine the data storage requirements particular for this sensor representation and incorporate this representation into the data overlay structure in the sensor.cmn common block. The particular overlays for the current eight sensor categories are described in the following section as examples of the sort of data that may be incorporated. Currently 880 bytes of data are stored for each type of sensor, and this may be divided into whatever division of data types required. But if a new representation requires more storage this is readily accommodated by changing the length of the sensordata and sensordta variables in this common block (Note – with the translation into C this has been simplified;  Now just add variables to the structure THROUGH THE AUTOGEN INTERFACES and both the C and Fortran data structures will automatically expand accordingly) . The length of these variables must be equal to the length of the longest data description required for any sensor type. The extra space in these variables for sensor types that do not require the full data definition will not affect their representation adversely.

  4. Write data base tables and menus to allow sensor definition during presimlation. The procedures for accomplishing this are included in the presimlation documentation.

  5. Write initialization procedures to retrieve the data stored in the data base and initialize the new sensor category. This data is read in as a result of a can to the Initsenssys routine, as described in the initialization documentation. This routine has a case statement calling different routines for the sensor category initialization. To add a new sensor category, this routine need only by modified to the extent of adding a new case and calling a new routine to retrieve the sensor category specific data. The new routine must access the new data base table containing the data on the new sensor category. In each of the two demonstrations of adding new sensors the current Inltlosrdr routine was used as a template for this data retrieval. The resulting routine is very simple and need only retrieve data from the data base and put it in the sensor.cmn common block, everything else associated with initializing new sensor types is handled by higher-level routines which will not need to be modified.

  6. Write the sensor category specific environmental effects and detection routines. The environmental effects routines are called from the snsrenv routine, as described below in the processing section of this documentation. A new case for the new sensor category will need to be added to this routine and the subroutine specific to modeling these environmental effects may be called from hare. Prelimsensor will need to be modified to incorporate an additional detection determination routine. In both at the previous demonstrations the losradardet routine was used as a template for the new detection routine.  The prelimsensor routine does all of the coarse bookkeeping for all sensor types and categories, and this will not generally need to be modified (Note – this is not the case for some specialized functions, including sensor cross-cueing and selected searches.  These must be addressed on a case-by-case basis). Prelimsensor then calls the category-specific detection routines for the detection determination of a specific sensor site versus a specific target. This will be described in detail in the processing section of this documentation.

Sensor Representation in ADISC2

These three charts list the parameters included in the 1990 ADISC2 sensor representation for each of the original sensor categories. 

Note - Just as new categories have been added .new parameters have been added (especially as related to operational tasks) and the user to refer both the current database prototyping interface for sensor subsystems and the Mission Planner operational task interface for up-to-date information.  This data is stored in the sensor structure and details for the data types, order, and reasonable values can be found using the on-line documentation found under System Controls -> Debug Options -> FORCES Public Structures.

Sensor Operations

Not all of the parameters required to describe sensor operations (as listed on earlier figures in this document) are contained in the sensor structure.  For example, defining the flight and orbit of an AWACS is the same as describing the motion of other airborne assets, so the data to define this is maintained in the objects database.  This figure lists the attributes required to define sensor operations in addition to those maintained in the sensor module.  It also describes where this data is maintained.  In addition to defining where external data is maintained, this chart also lists algorithms (e.g. tracking) that are external to the sensor module but critical to its performance.  The data structures and messages interfaces to these other modules are specified in the structure definitions and ICD, respectively.  Once again, the best way to review an update-to-date description of both the structures and the ICD is to start up the JFORCES interface and go to “System Controls-> Debug Options” and then go to the appropriate interface (e.g. public structures or ICD).

Sensor Limitations in ADISC2 (circa 1990)

Note: JFORCES has progressed well past most of these limitations and most limitations are now only restricted by your system’s memory.  This section is provided only for backwards reference.


This chart lists the 1990 limitations of ADISC2’s sensor representation.  These limitations (if any still exist) are flexible and the footnotes on this figure indicate how these limitations can be upgraded.

Sensor-Related Prescripted Events

Some prescripted events affecting sensors that can be loaded into JFORCES for runtime execution include:

How to load these events is described in both the runtime initialization documentation of this module (dated) or the online JFORCES’ User’s Manual.

In addition, user inputs can affect the sensor module by commanding information from the sensor or commanding a change of operations (e.g. shutdown).  The messages sent from the operation workstation to the sensor module to effect these changes are listed in the following chart.  The online ICD within the JFORCES interface describes the parameters sent for each of these messages.


Top Level Sensor Processing Chart

This chart begins the runtime processing section. The processing associated with initialization is addressed in the initialization documentation. There are three major components of runtime processing; the first component processes all user interactions including commands and coverage information.  The second component includes ail detection updates by all sensors.  And the third component maintains tracks on  the basis of sensor reports.  The first of these components is controlled by the simreceive routine.  This routine calls the appropriate subroutine based upon the case of the incoming message.   All of the top level routine calls are indicated in this diagram.  All of these routines are simple and a description of the functions of each routine is provided in the following paragraphs. The periodic detection update of all sensors is controlled by the prelimsensor routine. This update is not nearly as simple, and processing performed by this routine and its subroutines is described in the following processing diagram.  The tracker is controlled by the trackcntrllr routine, and like prelimsensor, this routine and its subroutines are relatively complex. They will be described after the sensor detection processing documentation.

All of the routines called by simreceive are called as a result of a user (or C2module, or now by cross-sensor cuing) interaction with two exceptions.

·       Sublocalization is called as a result of a successful ASW localization. The original ASW localization process is initiated as a result of a user (or C2) command that calls the startsearch routine. Because the ASW localization is intrinsically tied to submarine nullification, this entire process is a component of the engagement module and is described fully in that module’s documentation.

·       The othreport routine is called every 15 minutes for every active OTH center in the scenario.    The first call is generated as a result of a message stacked during initialization.  Subsequent calls are caused by this stacking a “wake-up” call to itself.  It does this by stacking an event to broadcast the OTH sites’ health every 15 minutes from the current time every time it completes this this routine. This procedure is similar to the calling cycle performed by the prelimsensor routine in order to periodically updatesensor detections, as described in the control section of this module’s documentation

The function of the user (or C2) activated routines called by simreceive are described below:

Othbarriercommand sets the minimum and minimum and maximum coverage range of an OTH-B radar site. The range restrictions are used for the entire azimuthal coverage of the specified OTH-B site. These values are stored in the specific site data area of the sensor structure. This data is then employed by the prelimsensor routine during detection updates to whether candidate targets are within the current sweep coverage of the sensor.

SBRcovcommand sets the right and left search limits of a specified Space-Based Radar. Like the previous routines, these limits stored in the specific site data area of the sensor structure. This data is then employed by the prelimsensor routine during detection updates to determine whether candidate targets are in the current sweep coverage of the sensor.

JSSheight commands a JSS-type sensor to perform a “height evaluation” of a specific area. The area is defined by range and bearing from the site. The report is modeled by providing a count of aircraft within 10 nautical miles of the indicated location (a maximum return value of 6 is enforced due to format limitations), an indication of whether any of them have ECM on, and a weather flag if the weather intensity if over 4 (indicating there might be more uncertainty than usual in the report)

Modsensorreport - changes the reporting for the indicated sensor relative to the requesting MMI node. The reporting from this sensor can be turned off or on for any node (that is, any operator workstation or tracking module.  The sensor detection determination will proceed normally regardless of the state of this flag for any, or all, nodes.  That is, a sensor will determine whether a target detection occurs even if it not reporting to any MMI node. The sensor/node reporting list is maintained in the snsrreport array ~ maintained in the sensor structure for each sensor site.

Mufreport reports the maximum usable frequency for specified OTH~B sites. The data is reported in Megahertz for every 7.5 degrees in azimuth coverage. For each bearing report 13 range reports are provided - one for each 100 nautical miles (NM) range from the site from 500 NM to 1 800 NM. This data is retrieved directly from the “mufdaia” array in the environment.cmn common block.

Adjustcoverage reports the coverage of specified types of sensors against nominal targets at specified altitudes and signatures. . The attitude coverage reported by this routine is based strictly “beachball” Earth calculations - that is the terrain (corona) restrictions are not reported. In order to get terrain reports for specific sensors the corona report menu must be used.  The resulting processing is then performed by the terrainreport routine, described next This routine does NOT in any way affect the detection routines, but instead provides coverage reports intended to aid the operator in visualizing holes in his sensor coverage for postulated threats.

Terrainreport  provides reports on the coverage of specific sensor sites against postulated targets at operator-specified altitudes. The resulting report lists the maximum detection range of the site against targets at different bearings. This is reported for 180 bearings, starting due north and progressing in two degree increments clockwise. The data is retrieved for sensors  and the terrain data resolution is limited to the locally available DTED data. (Note – the rest of the original was scrapped as no longer being pertinent with the current JFORCES system.  Please review the information in the User’s Manual for an up-to-date description.)


This figure outlines the periodic sensor processing that occurs when this module is called. The sensor module is called for each type of sensor subsystem modeled in the scenario. For each type of sensor the environment around the sensor is determined and the sensor detections are determined. Messages occurring as a result of either of these activities are queued for transmission to the appropriate manned station or automatic function immediately. The determination of whether the message could be sent over the designated media as appropriate for the sensor type, and the communications module accomplishes whether the message is successfully received at the destination. If communications are successful the message will be received by the indicated destination after appropriate delays.

The description of the periodic processing will be divided into first a description of the processing associated with determining the sensor environment followed by a description of the processing associated with determining sensor detections.

Sensor Module Environmental Representation

When the sensor module is called to update the detections of a specific type of sensor subsystem, the first process determines the environment around each sensor site hosting the designated subsystem, as indicated in this chart.  This sensor environment submodule has a single entry point, subroutine snsrenv, and this controlling routine calls the indicated subroutines to   model the environment as appropriate to the sensor type. The sensor types and associated routines are listed in this figure. As seen in this figure, there is no standalone environmental representation for the OTH-B, passive ASW, and IR models. Notes relative to these are provided below:


OTH-B - The environmental representation of the OTH~B model is incorporated into the following two functional areas:

Both the auroral CAP and MUF data are precomputed during scenario generation, so no runtime environmental  representation is required. Any nuclear blast eliminates  the capability of the OTH-B to detect anything for the rest of the simulation. This is based on the significant disruption to the ionosphere that would occur. Because both of these environmental determinations are single line checks, they are done in the othradardet routine.

Passive ASW (note: this does not include ASW localization gear) - A similar structure would be appropriate at this point in the code to update any underwater noise values that might be required as part of the NOSC interface. Because this interface is not done, the update stub is not currently written.

IR – The IR model only requires an interlace to the weather data (Note – and cloud background for the detailed SBIR). The data provided the environmental module is adequate to this module, so no additional environmental definition is required as part of sensor detection cycle initialization.

The following figures will describe the environmental representation for each of the remaining radar sensor types.

Standard Line of Sight Radar Environment

The first and most comprehensive environmental representation (as of 1990, other sensor environments, including space based IR, are now more detailed) for a sensor type is the standard line of sight radar environment representation. The environmental determination processing is outlined in this chart. Individual subroutines modularize the processing that occurs as a result at this routine being called. The processing functions are:

  1. Initialize the environment around every sensor site hosting a sensor subsystem of the specified type.

  2. Generate "normal” false alarms

  3. Generate additional false alarms in weather regions.

  4. Add noise (additional spurious detections) due to chaff in a manner consistent with chaff fall and dispersal.

  5. Add noise (additional received emissions) due  noise jammers in selected areas as defined by the radar antenna pattern}.

  6. Add noise (additional power in selected areas as defined by the radar antenna pattern) due to nuclear detonations.

  7. Determine and send any detectable noise/EW (i.e. strobe messages).

The following figures will describe selected aspects of the environment representation for the standard line-of-sight radar model.

False Alarm Representation

The false alarm representation in JFORCES is based upon random detections within the sensor's field of view. Highlights are covered in this chart. Each sensor system has a default number of false alarms within its field of view. These false alarms are distributed randomly within the sensor's field of view as defined by the site's object data relative to the sensor subsystem. This field of view data is stored in the Sensor_Site structure in the sensor header.. Additional false detections are added for weather, chaff, and smart jamming. Weather affects the sensor's entire field of view. As described later, the additional detections generated as a result of chaff and smart jamming are localized to the vicinity of the disturbance.  This false detections are passed to the tracker module, which in tern will generate spurious tracks based on this false stimuli (assuming the raw radar is being used to initiate tracks).

Gain Pattern

The gain pattern for this type of radar is defined by a look-up table of gain versus angle from boresight in azimuth. This pattern is used to determine the shape and extant of side- and back-lobe jamming. (Note- Sorry about the crude antenna pattern rendering; this was as good as we could get on a MacIntosh in the late 80’s)

Noise Modeling

The noise generated by multiple noise sources is aggregated for each affected sensor and this result is combined with the ambient background noise to determine the total noise impinging on the sensor and potentially denying detection. The modeled noise sources in JFORCES include nuclear detonations and noise jamming. The noise jammers are modeled as having a center frequency and a bandwidth. Scanning jammers are not discretely modeled

Radar Weather Representation

The radar weather includes false detections generated for each sensor in the area affected by weather and modifying the ducting factor for sensors within this region. The number false alarms is directly dependent upon the weather intensity (i.e. a weather intensity of 3 results in a mean of 3 additional false detections being generated for each sensor in the affected region). The weather ducting is determined by the weather effects table defined by the user during presimulation.


Chaff is modeled by a number of false detections in the region of the chaff drop, as indicated in the above figure. The extent of this region is defined by the time since the drop, the chaff dispersion rate, and the maximum chaff dispersion input by the user during pmsimulation. The fall rate of the chaff and the altitude at which it is dropped define the time until the effect of any given chaff drop ends. Aircraft dropping chaff are modeled as dropping one chaff canister every simulation time frame. The number of false detections created by each chaff drop each time frame is hardcoded in the   rdrchaff routine. Presently this number is set at three. Chaff does not deny detection of the dropping aircraft or subsequent aircraft the raid, but adds additional detections to make tracking of the aircraft in the chaff region (much) less likely and to preclude detailed raid analysis

Generic Radar Model Environmental Representation

 As described above, the 'generic' radar model is a fourth-root scaling approximation of radar coverage to be used only for 'quick and dirty' analysis of system capabilities or when the data to support the radar range calculation is not available. This simple model can not be as detailed in representation of the environment as the standard LO.S. radar representation.  The reduced environment processing diagrammed above reflects this. The 'normal' and weather-related false alarm representation identical to the representation used by the LOS radar representation, but the representation of nuclear and noise jamming effects are simpler. The effect of either nuclear or jamming activity is to produce a strobe message of noise in the direction of the noise source and to flag the area around the noise source to prevent detections in that direction during detection processing. This flag is a logical flag and thus, unlike the radar range LOS representation, does not model radar burnthough in a noisy or jamming environment.  Nor are side and backlobe jamming considered in this simple model; if you want that representation please use the LOS radar model.

Detection Processing

The second process included in sensor processing is the determination of sensor detections. The "Sensor Processing".is repeated here to indicate that the processing flow has returned to the top level routine. prelimsensor. Many of the results of the sensor environment determination are used in determining the detection success of each sensor. Primary inputs from the sensor environment determination are:

Terrain effects (e.g. Elevations derived from DTED) are considered in the sensor detection determination process

MultiLevel Candidate Target Filtering

Processing in the ADISC2 is significantly reduced from the processing required to perform the detection determination of every sensor versus every potential target

This is done by the employment of two data structures that identify:

  1. The sensors that can view any designated 1at/long point; and

  2. The objects within a given range of a specified point.

These structures maintain this information in the form of linked lists and provide this information on a coarse basis without performing any arithmetic operations (e.g. a range calculation). This approach is outlined in the above charts

(Note: This algorithm is currently disabled in JFORCES, but the reference is left here because the method is good and can often result in significant time-savings, so it might be reimplemented in the future.)

The first structure is maintained by the sensor module and is initialized for each sensor by routine sensorlatlong. It provides a linked list for each lat/long point of sensors whose field of view includes this latitude / longitude paint. The latitude / longitude pairs for a basis for the internally used location reference points.  To avoid missing possible detections of short-range sensors that might see an object near a location reference point but can not see any reference point, all sensors are listed at least one reference point. Lists of the sensors whose coverage includes any location reference point are created by the makesensorlist routine, and this list is composed of all sensors that can see any of the four location reference points surrounding any area of interest. This data is maintained in the sensorlist.cmn common block. While this list may include sensors that actually can not cover the indicated region, this approach guarantees that no sensor that could potentially observe the target is skipped. The list of sensors whose field of view actually includes the target location is then generated from this list by calculating the exact range, bearing, and elevation of the target relative to the sensor site. The list of locations that static sensor site can potentially observe is calculated only once per run; the list is updated every time frame for mobile sensors.

The objects module maintains the second structure. A linked list of all objects near every reference point is created at the conclusion of updating the position of all simulation elements in the objectmotion routine. This data is stored in the objedpos.cmn common. It is used by the makerangelist and makeselectrangelist routines to generate lists of simulation elements within specified ranges of speccified locations. This is done by looping through all reference points within range of the specified location and making a composite list of all objects meeting the input specifications to these routines (e.g. all target vs only moving targets) by going through the linked list of all objects near each of these location reference points.

The workload reduction by using this technique is significant. For example, in a scenario of 600 targets and 200 JSS sensors, if this (or a similar workload) reduction is not used 120000 detection calculations must be performed. Assuming that each of these targets is near the field of view only 2 sensors at any given time this technique reduces the workload to 1200 detection calculations, resulting in a 100 fold increase in runtime performance.

The runtime sensor definition includes a wide-area detection flag. The purpose of this flag is to bypass the course-filter/fine filter detection determination approach outlined above. This is done because when the number of targets in the field of view is very large (as is often the case with space-based sensors) the approach is less efficient than a brute force detection determination of all targets versus all sensors of this type.  The simulation determines which of these filters should be used for any sensor during initialization, so this should not affect users.

Sensor Detection Processing

Sensor detection determination is controlled by the prelimsensor routine, as indicated above. For every sensor type it creates a list of all possible sensor/target detection possibilities, prepares the data on the sensor and target for use by the detection routine, and then calls the appropriate detection routine. In the 1990 baseline, there were eight possible sensor detection cases modeled, as listed in this diagram. This structure is a case structure, making it simple to replace detection routines or to add new ones. The addition sensor detection options developed during that time follow the same case-based call structure. The detection processing for each of the original modeled cases is described in the following pages.

LOS Radar Detection Model

The radar detection model uses a radar range calculation to determine the success of detecting a given target. The processing flow is provided above. This algorithm is deterministic and depends upon:

  1. The sensor field of view;

  2. The sensor line of sight (with terrain restrictions):

  3. The sensor gain at a function of elevation

  4. The target RC.S. as a function of viewing geometry and radar frequency;

  5. Possible existence of velocity notch:

  6. Radar parameters (see equation in the above chart);

  7. Weather effects (duding);

  8. Noise from nudets and jamming; and

  9. The effects of smart jamming.

Because JFORCES does not incorporate the actual detection processing algorithms for all sensors, the smart jammer representation is necessarily a simplistic approximation. This representation is based upon the probability of jamming success for the particular jammer suite type versus the particular sensor type using the jamming susceptibility tables input during the sensor definition phase of presimlation. The smart jamming representation is described in the following chart.

This routine, like all other detection routines, calls the routine sensormsgs to output messages in the correct format for this radar. As described below, this routine is a case statement calling the appropriate formatting routines. Thus, it can readily accommodate the incorporation at new sensor message formats provided the required detail is available to the detection routine.

Smart Jamming Representation

This smart jamming representation is used for the standard radar representation, the generic (4th· root scaling) radar representation, and the bistatic radar representation. The smart jamming representation utilizes a Monte Carlo approach to determine jamming success. The probability of jamming success is based upon the jamming susceptibility tables input by the user for every sensor versus every jamming suite. If the jamming is successful, detection of the target is denied and false detections are generated in the rough vicinity of the target. These reports are generated via a call to the sensor message routine (see the previous chart).

InfraRed Detection

Infra-red detection is based upon a range-squared scaling of the characteristic detection range of the sensor and the signature of the target. The processing flow is presented in "IR Detection Processing", reference page 84. This routine is sensitive to:

  1. The sensor field of view;

  2. The sensor line of sight (with terrain restrictions);

  3. The target’s IR signature as a function of frequency (and in some cases viewing geometry)

  4. Sensor parameters (see equation in above chart); and

  5. Weather effects.

Like all other sensor detection routines, this routine calls the sensormsgs routine to control (or create) message formats, thus decoupling the detection process from the reporting process. This allows the user to salad the message format he wants from the options provided in data base prototyping.

Passive ASW Detection

The organic Passive ASW detection algorithm shown in this diagram is based upon a range-squared scaling of the characteristic detection range of the sensor and the signature of the target.   This is NOT the routine used tor ASW localization processing. The awslocalization routine, described and stored in the engagement module, performs ASW localization.  It is also unrelated to ASW detection routines provided by NOSC for incorporation into JFORCES; these are documented separately in the document “Regional ASW Models for ADISC2”, dated 1 Dec 1990, by the Naval Ocean Systems Center under contract N66001-89-D-0004-014.

The pasaswdet routine described in this chart is sensitive to:

  1. The target sonic signature as a function of target speed and depth;

  2. Sensor parameters (see equation); and

  3. Target proximity.

The hooks are in the routine for underwater background noise and local ducting should this data become available. The genesis of this equation was the passive ASW detection equation published in the RESA analyst's guide.

Like all other sensor detection routines, this routine calls the sensormsgs routine to control message formats, thus decoupling the detection process from the reporting process. This allows the user to employ and message format he wants from the options provided in data base prototyping. But it is strongly recommended that the ASW message format be used for this sensor because of the additional ID data available in this message is not supported by the other message formats.

Generic Radar Detection

The generic (i.e. fourth-root scaling approximation) detection is based upon a range scaling of the characteristic detection range to the sensor and the signature of the target. This routine is sensitive to:

  1. The sensor field of view;

  2. The sensor line of sight (with terrain restrictions);

  3. The target RCS as a function of viewing geometry and mdar frequency;

  4. Possible existence of velocity notch:

  5. Radar characteristic detection range;

  6. Noise from nudets and jamming; and

  7. The effects of smart jamming.

The effects of noise from jamming and nudets is simpler than the representation used in

the standard radar model in that jamming and nudets "blackout" the a region from the sensor to the noise source. Within this region no detections may occur (i.e. radar burn-through) is not modeled in this simple approach. As seen in this chart, the smart jamming representation and the sensor reporting is identical to the standard radar representation. Thus the neither the man in loop nor the automated C2 terminal will know by the message format or contents which representation is being used far each sensor. Nor will these destinations know which detections are true or false based on a single detection report independent of other information.

Like all other sensor detection routines, this routine calls the sensormsgs routine to control message formats, thereby decoupling the detection process from the reporting process. This allows the user to select the message format he wants from the options provided in data base prototyping.

Space Based Radar Detection Processing

The space-based radar representation is based upon a fourth-root scaling of the sensor's detection range based upon the target's presented R.C.S. The field of view of the sensor is modified by the commanded search volume based upon azimuthal limits and the minimum and maximum grazing angle of the sensor's line of sight to the target and the earth. The grazing angle limits are used to represent the nadir hole in the sensor's coverage and the atmospheric effects precluding detections near the earth's rim. No chart is provided for this algorithm because it is a near relative of the simple RF detection routine.

Like all other sensor detection routines, this routine calls the sensormsgs routine to control message formats, thus decoupling the detection process from the reporting process. This allows the user to select: the message format he wants from the options provided in data base prototyping.

ESM Detection Modeling

The Electronic Surveillance Measures (ESM) detection model is based upon the portion of the uses a radar range calculation referencing the receiver capabilities. Because this routine is based upon this approach it is very similar to the losradardet routine. This routine is totally deterministic and depends upon:

  1. The sensor field of view;

  2. The sensor line of sight (with terrain restrictions);

  3. The target emissions as a function of frequency;

  4. Radar parameters ( see equation );

  5. Weather effects (ducting); and

  6. Noise from nudets and jamming.

This routine, like all other detection routines, calls the routine sensormsgs to output messages in the correct format for this radar. As described below, this routine is a case statement calling the appropriate formatting routines. However, in this case the data output by the ESM message is unique and only the ESM report message format is recommended.

(Note: Since the 1990 the RHAW detection has been added with more detailed antenna and resolution specifications and can be used instead of this ESM model when appropriate for passive RF sensors)

OTH-B Detection Processing

The Over-the-Horizon Backscatter (OTH-B) radar model incorporated into ADISC2 is based upon an OTH-B model provided by Mr. Fischer or NORAD in 1987. The OTH-B will attempt to detect targets within its search volume but is restricted as follows:     -.


When a detection occurs, the data is stored for subsequent detections; the OTH-B algorithm DOES NOT report detections ~ only tracks. The tracker used in this algorithm is based upon empirical data derived from the GE operations at the Bangor site. The empirical data is provided in the two charts entitled "High SNR Algorithm Performance"' and "' low SNR Algorithm Performance', reproduced below. These charts indicate that a track can not be formed until at least six detections occur, and after this the probability of a track forming can be based upon a power series polynomial derived from performing a multiple regression using these data. The power series approximates a negative exponential distribution. This is a "'memoryless" distribution; that is the probability of a track occurring on a given detection does not depend upon the number of previous detections (provided the minimum six detections are satisfied). Therefore the probability that a track forms can be computed locally each update without considering compounding faders from previous possible detections to tracks. For example, using this approach with this data the probability of a track forming for each detection subsequent to the fifth detection in a law signal to noise ratio (SNR) case is

p(track) := .000472 + (.001*s2n) -.000393 *{s2n**2)+.00011*{s2n**3)  

where s2n is the computed signal to noise ratio in DB.

Tracking Module

Note – This document describes the original tracker incorporated into the ADISC2.  While this tracker still exists, for all practical purposes it has been supplanted for air defense tracking needs by the tracker incorporated in the JFORCES RAP application.  This tracker is described in separate documents on the website in the “Programmer’s Area”

This page outlines the major functions found in the tracker. The tracker is a relatively simple function, but is one with a large number simple subfunctions forced by the need to interface to a large number of message formats. The functions listed on this facing chart are NOT in the order executed; please see the pseudocode for the trackcntrllr routine to see the control structure. All of the data storage for these functions is in the trackdata.cmn common block. The functions of these routines are described below.

inittrack - This routine initiate a new track in the system, This adds the storage area for this track to the arrays in the trackdata.cmn and maintains the linked list pointing to the tracks. The current number tracks that can be maintained simultaneously by the system is sat by the maxtracks variable the commonblkpamms.cmn common block.

purgesurvdb - This routine purges detections from the surveillance data base that are more than 6 time frames old. A time frame is defined as the scan cycle of the reporting sensor. This data is purged because there is assumed to be no need for data older than this and it is necessary to keep the plot data storage area reasonably sized. The plot data is stored in the survdata in the trackdata.cmn common block. This data structure is a linked list indexed by the reporting sensor. The data in this structure is purged separately for each individual sensor. The maximum number of plot points kept at any one time is set by the maxsensorreports variable in this common block and is currently set to 50000. This variable should be set to a value comfortably larger than the total number of sensors reporting plot data times the expected number of reports per sensor scan times 6 (this factor accommodates the requirements to store 5 historical plot points as well as the current reports.)

adddettotrack – This routine adds a new plot point to the surveillance data structure described above.

maintpassivetrack - This routine is used only by the automatic C2 function. When invoked, this routine sorts through the passive (e.g. ECM reports) from JSS sensors and attempts to establish and maintain angle-based tracks on these reports. At most, one track will be established per sensor site and it will be centered on the widest strobe report, That is the area of greatest noise.   All other strobe are assumed to be untrackable due to noise from this primary source, or be the result of side and/or backlobe jamming. The track is based upon bearing to the track and an estimated range using the jammer range table defined in the C2 module (see that module for more data). This table is user input during presimulation and provides a rule-of-thumb estimate for the jammer's range based upon strobe report

trackupdate - This routine is the blood-and-guts for this function. The tracker itself is based upon the closest return to the projected location of the track. The projected location is based upon a limited second-order approximation based upon the last three detections that have been correlated to the track. Thus, it is based upon the last known location (the zero-th order approximation), the velocity (the first order approximation), and a limit on the acceleration (second order approximation). The acceleration is computed in both the linear (e.g. straight-line acceleration) and the crossing (e.g. turning) component Acceleration projection is tightly limited in order to limit tums to be within reason, e.g. most aircraft do not continue to turn indefinitely. If no detection is correlated to the track this projected track location is broadcast to the operator workstations and the C2 module. Otherwise the detection location (as adjusted by past track extimates) is broadcast and the detection data is stored In the trackdata.cmn common for later estimation of this track location.

deletetrack - Deletes a track from the track arrays and releases the storage area to be used for other, new, tracks.

newfreeecmtrack - Stores ECM reports from sensors that report using the default sensor message format.  This data is for use by the C2 module and has no effect on the operations or display of the operator workstations

newecmstrobe - Stores ECM reports from sensors that report using the JSS sensor message format  This data is for use by the C2 module and has no effect on the operations or display of the operator workstations

newothbecmtmck - Stores ECM reports from sensors that report using the OTH~B sensor message format. This data is for use by the C2 module and has no effect on the operations or display of the operator workstations

estabactivetracks - This routine automatically initiates tracks based upon a linear display of three plot messages within the speed parameters established by the user as a surveillance rule during presimulation.   This option can now be invoked separately from the C2 module during scenario configuration. WARNING -This routine approximately doubles the time to execute the trackupdate cycle. That is not too bad, indeed it is better than was originally expected, but it is still not recommended for extensive scenarios.

initstk - This routine is a utility routine, and as such is in the objutil documentation and directory instead of the sensor directory. This routine initializes the linked list structures. These are used for sensor report storage areas, track ID data, track data, and track action data (i.e. interceptors assigned).

newtrackdes - This routine changes the designation of a track as indicated by the MMt This changes it from one designation (e.g. unknown) to another (e.g. hostile). It does nor effect upon track maintenance, simply updating the user’s track evaluation for use by the operator workstations and the C2 module.

The next three routines are all very similar in that they store track data from a sensor in the track storage area so that it will be maintained and broadcast: like an operator initiated track. The only reason that there are three routines instead of one to do this is that each Incoming message has a different format

newexternaltrack - This routine accepts and decrypts tracks received in the default sensor message format

newothbtrack ~ This routine accepts and decrypts tracks received the OTH-B sensor message format

newaswdetection - This routine accepts, decrypts, and stores submarine detection data. Note that detection reports are not adequate for a submarine engagement; localization must precede engagement and localization reports are not received by this routine or even by the track controller.  Localization is an engagement function.

Surveillance / FAA / Intel Correlation

(Note: This algorithm is used only when not connected to live radar feeds)

This chart diagrams an interlace between the surveillance and the intelligence data bases. The purpose of this interlace is to correlate intel reports with current surveillance reports. In order to support this, the current track locations which do not correlate with FAA or military flight plans are checked for possible correlation to reported threat activity.  These threat location estimates are adjusted according to the likelihood that a threat could move to the indicated location within the time elapsed since the report. The C2 module, not by the sensor module, performs this function.  But this diagram is presented here to indicate a possible use of the local surveillance database at the operator workstations. The C2 module performs this function to evaluate tracks for possible target-weapon pairing.

Sensor Message Creation

As indicated in this chart a single entry point is used for the generation of all detection reports generated on a periodic basis by the sensors. This controlling routine in turn calls the appropriate subroutine to format the message in the appropriate manner. The purpose behind employing this scheme is to allow easy expansion of the sensor module to incorporate new sensor massage formats and to allow the use of common detection routines for sensors using the same detection phenomenology (e.g. line-of-sight radars) regardless of whether the detection reports have the same format. The user makes the determination of which routine will be employed during the data base prototyping process, while defining the sensor specifications. As mentioned in the processing descriptions above, these formats are often interchangeable, but not always.   In two cases the processing algorithm is too tightly coupled to the message formatting to permit seamless arbitrary pairing of the messages to the sensor algorithms.. These two cases are ASW detections and ESM detections. These are best handled by using only the registered message formats because the type of data reported differs significantly from the baseline message template.

(Note – since this time other sensors, notably the RHAW sensor, have been added that also require specific message formats for optimal execution.  Using other message formats won’t break anything, but if other message formats are used information will probably be lost).

JSS Message Representation

The next four charts specify the JFORCES representation of the JSS messages.  These charts are include to give the programmer some insight into how operational message formats are supported though the JFORCES system.  Since the time this was originally written many other operational message formats have been added, but since the approach is similar these are provided for a template to future work of the same type.

The first chart lists the JSS messages included in the JFORCES simulation and has comments on any implementation differences between the actual message format and the modeled implementation. Note that not all JSS messages are incorporated – only those required for the JFORCES mission, in this case maintaining the air picture.

The following chart specifies the source of all the message data, defining which message parameters are actually generated by JFORCES and which values are hard-coded. "JSS Detection Message Formats" provides a record-level description of the JFORCES internal message formats for maintenance support.

Finally. "'Differences Between JFORCES and Actual Message Streams" specifies differences between the JFORCES JSS messages and the real JSS messages. The basic reason that the JFORCES messages are different is that the JFORCES is a general-purpose message passer and the JSS message streams are a point-design communications design. Also, because the JSS messages are supported by custom-designed hardware many techniques are used that are inappropriate to the JFORCES. A case in point is the decision to saturate the real JSS message stream with idle messages. With the dedicated telephone lines employed in the actual interface this is a reasonable approach. However, there is no advantage to inserting these dead messages into the JFORCES and incurring the extra message-passing penalties that would be incurred.  When decisions like this are made the interface application provided with JFORCES forms a gateway between the JFORCES application and the external data.  This means that these gateway functions provide any extra functionality not provided by the JFORCES core, for example in this case generating idle messages to the external application that do not come from JFORCES to provide a data feed indistinguishable from reality.