WSF_COMPOSITE_SENSOR

sensor WSF_COMPOSITE_SENSOR

sensor <name> WSF_COMPOSITE_SENSOR
   ... Platform Part Commands ...
   ... Common sensor Commands ... (See Note in Commands )

   operating_mode ...
   sensor ...
   filter ... end_filter
   track_quality ...
end_sensor

Overview

WSF_COMPOSITE_SENSOR provides the means to create a sensor that is a ‘composite’ of one or more ‘constituent’ sensors.

Within WSF it is sometimes difficult to model a complex sensor with a single sensor definition. For example, real systems that contain multiple apertures are often modeled in WSF using multiple sensors. This creates the following problems: * Each of the sensors reports its tracks independently. * Conducting tracking across the sensors is difficult. The motivation behind WSF_COMPOSITE_SENSOR is to address these issues. The net result is that for a given target, the potentially multiple reports will be merged into a single track.

The composite sensor can operate in one of two operating_mode : independent or synchronous. These are described individually in the following sections.

Independent Operating Mode

When the operating_mode is independent, the constituent sensors act totally independently. That is, each of the constituent sensors must be turned on or off, cued or requested to track through its respective interface(s), not through the composite sensor. Note, however, the composite sensor must be ‘on’ for it to be effective. It must be ‘on’ to receive the track reports from the constituents. This mode is generally used when the frame rates of the constituents are not the same, the modes are not the same, or the user desires more control over the constituents.

While operating, each of the constituent sensors send its track reports to the composite sensor where the track reports are ‘merged’ into a single stream of reports for reporting. The composite track report is formed using the track reports generated by the constituent sensors. The composite sensor will report a track when it receives an ‘acceptable’ track report from one of its constituents. A track report is acceptable if it is of equal or greater track quality (as defined by the producing sensors track_quality attribute) than any other constituent sensor that is actively detecting the object. Note that a sensor that is ‘coasting’ (failed its last detection chance but still hasn’t dropped the track) is not considered as actively detecting the object. The composite track may also be ‘filtered’ (see filter below) to produce a smoother estimate of the target’s position and velocity, as well as producing a covariance. Note that if a filter is employed then measurement errors much be defined on each of the constituent sensors.

The composite sensor will send a ‘track drop’ message for a target when either of the following is true: * A ‘track drop’ message is received from all constituent sensors that were reporting on the target. * All of the constituent sensors that were reporting on the target are turned off.

Synchronous Operating Mode

When the operating_mode is synchronous, the constituent sensors are completely controlled by the composite sensor. That is, all requests to turn on or off, cue or track must be directed to the composite sensor and not the constituent sensors. In addition, any passive sensor controlled via a composite sensor in synchronous mode will not be notified immediately of any intermittent signal changes, such as a frequency or mode selection, in an interacting transmitter (e.g. a comm, sensor, or interferer), as it would as a stand-alone sensor or as part of composite sensor operating in independent mode. To mitigate this effect, the frame_time of the passive sensor can be decreased to allow detections to be reported more frequently.

This operating mode provides the most cohesive view, but there are several conditions that must be observed to use this mode:

• The constituent sensors must appear after the composite sensor on the platform.

• All of the constituent sensors must have the same collection of modes. They must have the same names and must appear in the same order within their respective definitions. Note, however, that attributes of the modes may be different.

• The mode-specific scheduling and tracking parameters for the composite sensor are copied from the first constituent sensor (i.e., the first sensor mentioned in the sensor commands). For example:

  • frame_time

  • maximum_request_count

  • revisit_time

  • dwell_time

  • search_while_track

  • disables_search

  • hits_to_establish_track

  • hits_to_maintain_track

  • reports_ <x> commands

  • track_quality

  • filter

• The commands to ignore detection chances for certain types of objects (i.e., ignore, ignore_domain, ignore_side, ignore_same_side) must be specified in the composite sensor.

Commands

Note

Even though this sensor is documented as accepting common sensor commands, they will be ignored and should not be specified for future compatibility. The attributes of the composite sensor are derived from its constituent sensors.

operating_mode independent

Defines how the constituent sensors are managed.

independent

The constituent sensors operate independently.

synchronous

The constituent sensors operate synchronously with the composite sensor.

Default: None - this must be provided.

sensor <sensor-name>

Defines the name of a constituent sensor. This command must be repeated one or more times specifying the names of the ‘constituent’ sensors that make up the ‘composite’ sensor. In general, all of the constituent sensors should be of the same general type. At the current time the sensors should be a type that reports tracks (WSF_RADAR_SENSOR, WSF_IRST_SENSOR, WSF_PASSIVE_SENSOR).

Note

The sensor definitions of the composite sensor should not include ‘internal_link’ commands. The constituent sensors will be automatically linked to the composite sensor as required.

filter <filter-type> … end_filter

Defines a filter to be applied to the stream of tracks for a target when the operating_mode is independent.

Default: none

Note

If a filter is employed then measurement errors must be defined on each of the constituent sensors.

Note

This command must appear after the operating_mode command.

track_quality [ 0 .. 1 ]

Specifies the track quality to be assigned to the composite tracks produced by this sensor when the operating_mode is independent. This value is used only if it is greater than zero. If the value is zero then the track quality for the constituent tracks will be used.

Default: 0.0 (Use the track quality from the constituent tracks.)

Example

sensor SENSOR-TYPE-1 ...
   ...
end_sensor

sensor SENSOR-TYPE-2 ...
   ...
end_sensor

platform_type ...
   processor track_proc WSF_TRACK_PROCESSOR
   end_processor

   sensor composite WSF_COMPOSITE_SENSOR
      operating_mode independent
      sensor         sensor-1
      sensor         sensor-2
      internal_link  track_proc
      on
   end_sensor

   sensor sensor-1 SENSOR-TYPE-1
      on
   end_sensor

   sensor sensor-2 SENSOR-TYPE-2
      on
   end_sensor

end_platform_type