Multibeam Radar for Adaptive Search and Track

Since R2022b

This example uses:

This example shows how to use radarDataGenerator for a closed-loop simulation of a multifunction phased array radar (MPAR). The example starts by defining MPAR system parameters and parameters of three radar tasks: volume search, cued search, and tracking. The example then sets up a scenario with multiple maneuvering targets. At each update interval the tasks request resources from the MPAR to search for targets and revisit existing tracks. The example shows how different radar tasks that share the radar bandwidth and aperture can be executed in parallel. The simulation loop is closed by passing target detections back to the radar tasks to update their internal state and generate new look requests.

MPAR Simulation Set Up

The MPAR in this example can carry out three tasks: volume search, cued search, and tracking. The goal of the volume search is to repeatedly scan a large volume of space searching for targets. The volume search task uses a wide beam and a narrow band waveform to reduce the total search time. The detections obtained by the volume search provide only approximate target locations. These detections are passed to the cued search task. The cued search allows the MPAR to perform surveillance in an adaptive fashion by scanning a small volume around a detection produced by the volume search. It uses a narrower beam and a wider bandwidth to provide better accuracy. The detections produced by the cued search are passed to the tracking task. If the tracking task confirms these detections, it initiates new target tracks. The goal of the tracking task is to accurately track all targets inside the search volume. The tracking task performs adaptive tracking by deciding when to update the tracks based on the estimated target dynamics such that the maneuvering targets are updated more frequently than non-maneuvering.

The MPAR can partition its phased array into several subarrays to create multiple simultaneous beams. This allows MPAR to perform multiple tasks in parallel and transmit different waveforms that are the most appropriate for each task. Each radar task requires access to some amount of bandwidth, power-aperture product, and time resources of the MPAR system. Since these resources are limited, the radar tasks must compete with each other for the access to them. At each update interval a radar task produces look requests asking the MPAR for resources required to achieve the task goals given the current operational situation (that is, the scenario, the number of targets, their positions, and dynamics). A radar look contains information about when, where, and for how long the MPAR should steer a beam, the parameters of the steered beam, and the parameters of the transmitted waveform. The look scheduler arranges a subset of the generated looks into a transmittable timeline such that the system resource constraints are satisfied [1]. The radar sensor model then executes the selected looks and produces target detections. The generated detections are passed back to either the cued search task or the tracking task based on the look that produced the detections. Each radar task has its own idea about the current operational situation and uses the generated detections to update its parameters and to request new looks at the next update interval. The looks that were not selected at the current update interval are considered again at the next update interval.

MPAR Parameters

Set the peak transmit power of the MPAR to 100 kW, the wavelength to 0.09 m, and the noise figure to 5 dB. Let the azimuth and the elevation beamwidths of the phased array, when pointed to boresight, be 2 and 3 degrees, respectively. Set the bandwidth of the system to 10 MHz.

mparPrms.PeakPower = 100e3;                     % Peak power (W)
mparPrms.Wavelength = 0.09;                     % Wavelength (m)
mparPrms.NoiseFigure = 5;                       % Noise figure (dB)
mparPrms.Beamwidth = [2; 3];                    % Min possible beamwidth [Az; El] (deg)
mparPrms.Bandwidth = 10e6;                      % Max available bandwidth (Hz)

System Resources

MPAR can control the individual elements of the phased array antenna on a dwell-to-dwell basis. This allows it to change the transmitted waveform parameters and to partition the phased array into multiple subarrays, possibly creating several simultaneous beams transmitting different waveforms [2].

In this example the tracking task uses the entire available bandwidth and power-aperture product of the system to produce accurate detections needed for tracking. At the same time, the volume search and the cued search tasks use only a portion of the available bandwidth and the array aperture such that the looks from these two tasks can be executed simultaneously. Each radar task requires a different amount of bandwidth, power-aperture, and time resources.

Bandwidth

Set the bandwidth of the volume search waveform to 0.5 MHz and the cued search waveform to 3 MHz.

volumeSearchPrms.Bandwidth = 0.5e6;             % Volume search bandwidth (Hz)
cuedSearchPrms.Bandwidth = 3e6;                 % Cued search bandwidth (Hz)

Verify that the total bandwidth needed to transmit the volume and the cued search waveforms at the same time is less than the total available bandwidth allowing the looks from these tasks to be executed in parallel.

volumeSearchPrms.Bandwidth + cuedSearchPrms.Bandwidth <= mparPrms.Bandwidth

ans = logical
   1

Set the tracking task to use the entire system bandwidth of 10 MHz.

trackingPrms.Bandwidth = mparPrms.Bandwidth;    % Tracking bandwidth (Hz)

This means that other tasks cannot be executed in parallel with the tracking task because all the available bandwidth is occupied by the tracking waveform.

Power-Aperture Product

The MPAR performs the volume and the cued search simultaneously by partitioning its array into two subarrays. The first subarray transmits the volume search waveform. Its beamwidth is equal to the beamwidth required by the volume search task. The second subarray transmits the cued search waveform and has a beamwidth equal to the cued search task beamwidth. Thus, in addition to the frequency bandwidth, the MPAR must also have a sufficient array aperture and transmit power. The power-aperture product used by the volume and the cued search tasks together must be less than or equal to the total power-aperture product of the MPAR.

The power-aperture product $P A P$ is a product of the average transmitted power $P_{a v}$ and the subarray aperture size $A$ [3]. It also can be expressed in terms of the peak power $P_{t}$ the pulse width $τ$ and the pulse repetition frequency $P R F$

$P A P = P_{a v} A (b w_{a z}, b w_{e l}) = P_{t} τ \cdot P R F \cdot A (b w_{a z}, b w_{e l})$

where

and $A (b w_{a z}, b w_{e l})$ is the aperture size of a subarray with the azimuth and the elevation beamwidths of $b w_{a z}$ and $b w_{e l}$ respectively.

Since the tracking task uses the entire aperture of the radar, compute its required power-aperture product first. Assume that this is also the total power-aperture product of the entire MPAR system. For that, set the tracking task beamwidth to the minimum beamwidth achieved by the MPAR.

trackingPrms.Beamwidth = mparPrms.Beamwidth;    % Tracking beamwidth

Let the tracking waveform have pulse width of 2.5 $μ$ s and PRF of 1500 Hz.

trackingPrms.Pulsewidth = 2.5e-6;               % Tracking pulse width (sec)
trackingPrms.PRF = 1500;                        % Tracking PRF (Hz)

Use helperPowerApertureProduct function to find the power-aperture product (in W·m²) needed for the tracking task.

trackingAperture = beamwidth2ap(trackingPrms.Beamwidth, mparPrms.Wavelength);
trackingPAP = helperPowerApertureProduct(mparPrms.PeakPower, trackingPrms.Pulsewidth, ...
     trackingPrms.PRF, trackingAperture)

trackingPAP = 
1.6619e+03

Now set the corresponding volume search and cued search parameters.

volumeSearchPrms.Beamwidth = [8; 10];           % Volume search beamwidth [Az; El] (deg)
volumeSearchPrms.Pulsewidth = 10e-6;            % Volume search pulse width (sec)
volumeSearchPrms.PRF = 1500;                    % Volume search PRF (Hz)

cuedSearchPrms.Beamwidth = [4; 5];              % Cued search beamwidth [Az; El] (deg)
cuedSearchPrms.Pulsewidth = 5e-6;               % Cued search pulse width (sec)
cuedSearchPrms.PRF = 1500;                      % Cued search PRF (Hz)

The volume search uses a much wider beam and a much narrower bandwidth compared to the tracking task. This allows it to quickly traverse the search volume. The resultant detections will have poor accuracies and should not be used for tracking. The MPAR cues a local search around the produced detections with a narrower beam and a wider bandwidth waveform to improve accuracy of the initial detection.

Compute the power-aperture products needed for the volume and the cued search tasks.

volumeSearchAperture = beamwidth2ap(volumeSearchPrms.Beamwidth, mparPrms.Wavelength);
volumeSearchPAP = helperPowerApertureProduct(mparPrms.PeakPower, volumeSearchPrms.Pulsewidth, ...
     volumeSearchPrms.PRF, volumeSearchAperture)

volumeSearchPAP = 
498.5762

cuedSearchAperture = beamwidth2ap(cuedSearchPrms.Beamwidth, mparPrms.Wavelength);
cuedSearchPAP = helperPowerApertureProduct(mparPrms.PeakPower, cuedSearchPrms.Pulsewidth, ...
    cuedSearchPrms.PRF, cuedSearchAperture)

cuedSearchPAP = 
997.1524

Check that the sum of the volume search and the cued search power-aperture products is no more than the total available power-aperture product.

volumeSearchPAP+cuedSearchPAP <= trackingPAP

ans = logical
   1

Thus, the MPAR has enough power-aperture product and bandwidth for the volume and cued search radar looks to be executed in parallel.

Time

If two or more looks are not sharing the total aperture and bandwidth, they must be executed successively in time. Prior to the execution, the MPAR arranges the looks into a time window of a fixed duration. Hence, the radar looks must compete for time slots within this window [1]. The execution time required by each look is determined by the dwell time, which in turn is determined by the detection requirements, the PRF, and the number of transmitted pulses. The number of transmitted pulses for a radar look that points a beam at a target located at a range $R$ , azimuth $a z$ , and elevation $e l$ , can be computed using the radar equation [3]

$n = \frac{(4 π)^{3} k T_{s} D_{x} (P_{d}, P_{f a}) R^{4} L (a z, e l)}{P_{t} τ G^{2} (b w_{a z}, b w_{e l}) λ^{2} σ}$

where

$λ$ is the wavelength;

$σ$ is the target radar cross section (RCS);

$G (b w_{a z}, b w_{e l})$ is the gain of a subarray with the azimuth and the elevation beamwidths of $b w_{a z}$ and $b w_{e l}$ respectively;

$D_{x} (P_{d}, P_{f a})$ is the radar detectability factor that determines the received signal energy needed to achieve the desired probability of detection of $P_{d}$ given that the required probability of false alarm is $P_{f a}$ ;

$L (a z, e l) = \cos^{- 3} (a z) c o s^{- 6} (e l)$ is the array scan loss due to scanning off boresight to the angles $[a z, e l]$ ;

$T_{s}$ is the system noise temperature;

and $k$ is the Boltzmann constant.

It is evident from the above equation that to maintain the same detection performance, the radar looks that point the beam at off-boresight angles would have to transmit more pulses because of the array scan loss. Similarly, the volume and the cued search tasks, which use wider beams compared to the tracking task, must generate looks with more pulses to achieve the same probability of detection because of the smaller antenna gain.

Set the desired probability of detection for all tasks to 0.9 and the required probability of false alarm to 1e-6. Assume that the radar tasks do not have any knowledge of the target RCS and the number of pulses is computed for a reference non-fluctuating target with a 1 m² RCS.

% The desired probability of detection is the same for all tasks
volumeSearchPrms.DetectionProbability = 0.9;
cuedSearchPrms.DetectionProbability = 0.9;
trackingPrms.DetectionProbability = 0.9;

% The required probability of false alarm is the same for all tasks
volumeSearchPrms.FalseAlarmProbability = 1e-6;
cuedSearchPrms.FalseAlarmProbability = 1e-6;
trackingPrms.FalseAlarmProbability = 1e-6;

% The reference target RCS is the same for all tasks
volumeSearchPrms.ReferenceRCS = 1;
cuedSearchPrms.ReferenceRCS = 1;
trackingPrms.ReferenceRCS = 1;

Radar Tasks

The radar tasks are iterative processes that at each update interval can request a varying amount of looks depending on the current operational situation. A radar look is an object containing information about when, where, and for how long a radar task wants the MPAR to point a beam.

% A radar look generated by the volume search task. The starting time is 0
% seconds, the look angle is -20 deg in azimuth and -12 deg in elevation,
% and the number of transmitted pulses is set to 10.
helperRadarLook("VolumeSearch", 0, [-20; -12], 10, volumeSearchPrms)

ans = 
  helperRadarLook with properties:

                     Type: VolumeSearch
                StartTime: 0
                LookAngle: [2x1 double]
                NumPulses: 10
        DetectableTrackID: [0x1 uint32]
                 Priority: 1
                DwellTime: 0.0067
                Bandwidth: 500000
                Beamwidth: [2x1 double]
               Pulsewidth: 1.0000e-05
                      PRF: 1500
     DetectionProbability: 0.9000
    FalseAlarmProbability: 1.0000e-06
             ReferenceRCS: 1

Volume Search

The volume search task places beams at the predetermined beam positions that tile the entire search volume. Set the search volume range limit to 75 km and set the angular limits to -60 and 60 degrees in azimuth and to 0 and -30 degrees in elevation.

volumeSearchPrms.RangeLimit = 75e3;             % Search volume range limit (km)
volumeSearchPrms.ScanLimits = [-60 60; 0 -30];  % Search volume angular limits [Az; El] (deg)

To improve the chances of detecting targets positioned away from the beam centers let the adjacent beams overlap slightly by making the spacing between them less than the beamwidth.

volumeSearchPrms.BeamSpace = [0.85; 0.85];      % Spacing between the adjacent beams specified in terms of [Az; El] beamwidth fraction

Create the volume search task using helperVolumeSearchTask class.

volumeSearchTask = helperVolumeSearchTask(volumeSearchPrms, mparPrms)

volumeSearchTask = 
  helperVolumeSearchTask with properties:

            BeamPositions: [2x56 double]
                BeamSpace: [2x1 double]
               RangeLimit: 75000
               ScanLimits: [2x2 double]
                Bandwidth: 500000
                Beamwidth: [2x1 double]
                      PRF: 1500
               Pulsewidth: 1.0000e-05
     DetectionProbability: 0.9000
    FalseAlarmProbability: 1.0000e-06
             ReferenceRCS: 1
                 Priority: 1

Use the helperPlotSearchGrid function to visualize the beam positions of the volume search task together with the corresponding 3 dB contours of the volume search beams.

figure;
helperPlotSearchGrid(volumeSearchTask.BeamPositions, volumeSearchPrms.Beamwidth, ...
    'ScanLimits', volumeSearchPrms.ScanLimits, 'SearchTaskName', 'Volume search', 'Color', [0 0.4470 0.7410]);
legend('location', 'best')
title("Search Grid")

Figure contains an axes object. The axes object with title Search Grid, xlabel Azimuth (deg), ylabel Elevation (deg) contains 3 objects of type line. One or more of the lines displays its values using only markers These objects represent Scan limits (Volume search), Beam positions (Volume search), 3dB beam contours (Volume search).

Notice the beam broadening effect when the beam points at off-boresight angles.

Cued Search

A separate cued search task allows the MPAR to adapt to the scenario and the operational conditions when searching for targets. The cued search scans a small volume around a detection produced during a volume search look. This means that the cued search task creates look requests at the current update interval only if the volume search task produced detections at the previous update interval. Otherwise, the cued search task is idle and does not create any look requests. Create the cued search task using helperCuedSearchTask class.

cuedSearchTask = helperCuedSearchTask(cuedSearchPrms, mparPrms, volumeSearchPrms)

cuedSearchTask = 
  helperCuedSearchTask with properties:

             SearchGridUV: [2x7 double]
                Bandwidth: 3000000
                Beamwidth: [2x1 double]
                      PRF: 1500
               Pulsewidth: 5.0000e-06
     DetectionProbability: 0.9000
    FalseAlarmProbability: 1.0000e-06
             ReferenceRCS: 1
                 Priority: 1

Assuming the volume search produced a detection at -20 degrees in azimuth and -12 degrees in elevation, show the beam positions of the cued search task using the helperPlotSearchGrid function.

az = -20;
el = -12;
plot(az, el, 'o', 'Color', 'k', 'MarkerSize', 5, 'DisplayName', 'Detection');
helperPlotSearchGrid(cuedSearchTask.beamPositions([-20; -12]), cuedSearchPrms.Beamwidth,...
    'SearchTaskName', 'Cued search', 'Color', [0.8500 0.3250 0.0980]);

Tracking

The tracking task confirms detections produced by the cued search, and initiates and updates target tracks. The tracking task can request two types of looks: track confirmation and track update. A confirmation look is produced when the tracking task processes a detection that has not been associated with any existing tracks. In this case the tracking task initiates an unconfirmed track and requests a confirmation look. The confirmation looks revisit the track at the highest possible rate and have the highest priority among all look requests. Set the track confirmation rate to 20 Hz.

trackingPrms.ConfirmRate = 20;

Once the track has been confirmed by passing an M-of-N threshold, the tracking task performs adaptive tracking [1, 2] (for more information on adaptive tracking please see the Adaptive Tracking of Maneuvering Targets with Managed Radar (Sensor Fusion and Tracking Toolbox) example). Adaptive tracking updates non-maneuvering targets less frequently than maneuvering, thus optimizing the number of requested looks to efficiently utilize the available radar system resources. When the tracking task requests a track update look it finds the lowest track revisit rate at which the predicted azimuthal track accuracy does not exceed a specified threshold. This threshold is defined in terms of a fraction of the azimuth beamwidth known as the track sharpness. A maneuvering target will exceed this threshold sooner than a non-maneuvering thus requiring more frequent updates. Set the track sharpness to 0.05.

trackingPrms.TrackSharpness = 0.05;

Since the azimuth beamwidth of the tracking task is 2 degrees, a track will be revisited at the lowest rate at which the predicted azimuth standard deviation does not exceed 2*0.05 = 0.1 degrees. Set the highest track update rate to 5 Hz and the lowest track update rate to 0.5 Hz.

trackingPrms.HighRevisitRate = 5;
trackingPrms.LowRevisitRate = 0.5;

Create the tracking task using helperTrackingTask class.

trackingTask = helperTrackingTask(trackingPrms, mparPrms, volumeSearchPrms.ScanLimits)

trackingTask = 
  helperTrackingTask with properties:

                  Tracker: [1x1 trackerGNN]
           TrackSharpness: 0.0500
              ConfirmRate: 20
          HighRevisitRate: 5
           LowRevisitRate: 0.5000
                Bandwidth: 10000000
                Beamwidth: [2x1 double]
                      PRF: 1500
               Pulsewidth: 2.5000e-06
     DetectionProbability: 0.9000
    FalseAlarmProbability: 1.0000e-06
             ReferenceRCS: 1
                 Priority: [1 1]

Look Scheduler

The look objects generated by the radar tasks have a StartTime property and a Priority property. StartTime indicates when, from a task's point of view, it would be best to execute that radar look. Priority indicates the priority level of the look, such that the looks with the same StartTime but higher priority are scheduled first. At the start of each update interval the radar tasks produce look requests that have StartTime within this update interval. But not all of these looks can be executed within this update interval because of the resource constraints. A simple frame-based scheduler selects a subset of looks that can be executed within this update interval without violating any resource constraints and arranges them in time based on their priorities [2].

Set the system update rate to 20 Hz.

updateRate = 20;

This update rate defines a 1/20=50 ms update interval and a 50 ms window used for look scheduling.

This example assumes that the track confirmation looks have the highest priority level of 4, the track update looks have the priority level of 3, the priority level of the cued search looks is 2, and the volume search looks have the lowest priority of 1.

volumeSearchTask.Priority = 1;
cuedSearchTask.Priority = 2;
trackingTask.Priority = [3, 4];      % [Track update, Track confirm];

Since the volume and the cued search can be executed at the same time, the scheduler schedules the volume and the cued search looks in parallel. The looks that were scheduled for the current update interval but do not fit into the 50 ms window are considered for scheduling at the next update interval.

Scenario 1: Maneuvering Targets

Use the radarScenario object to simulate radar targets and trajectories. Set the update rate of the scenario to updateRate.

% Simulate the first 20 seconds of the scenario. To simulate the entire
% scenario set stopTime1 to 200
stopTime1 = 20;
scenario1 = radarScenario('UpdateRate', updateRate, 'StopTime', stopTime1);

Load a set of waypoint trajectories.

trajectories = struct2cell(load('modifiedBenchmarkTrajectories.mat', '-mat'));
numTrajectories = numel(trajectories);

These are the benchmark trajectories used in the Benchmark Trajectories for Multi-Object Tracking (Sensor Fusion and Tracking Toolbox) example modified such that they are more distributed in altitude. Add targets that follow these trajectories to the scenario assuming all targets are Swerling 1 with 3 m² RCS.

targetRCSSignature = rcsSignature('Pattern', 3, 'FluctuationModel', 'Swerling1');
for trajIdx = 1:numTrajectories
    platform(scenario1, 'Trajectory', trajectories{trajIdx}, 'Signature', targetRCSSignature);
end

Use radarDataGenerator class to create a detection-level radar sensor model.

targetProfiles.Signatures = {targetRCSSignature};
radar = radarDataGenerator(1, ...
    'ScanMode', 'Custom', ...
    'UpdateRate', updateRate, ...
    'HasElevation', true, ...
    'HasFalseAlarms', true, ...
    'HasScanLoss', true, ...
    'DetectionCoordinates', 'Sensor spherical', ...
    'Profiles', targetProfiles);

The radarDataGenerator is set up to operate in the Custom scan mode. Notice that none of the properties that specify the detection performance or the measurement accuracy are set at this point. The Custom mode allows for changing these properties dynamically during a simulation based on the properties of the executed radar looks.

% Object to store simulation data for later visualization of the results
scenario1Data = helperScenarioData(updateRate, stopTime1);

% Radar looks that were deferred by the scheduler
deferredLooks = helperRadarLook.empty;

% For repeatable results, set the random seed and revert it when done
s = rng(2022, 'twister');
oc = onCleanup(@() rng(s));

% Reset the objects to be able to rerun this section
reset(volumeSearchTask);
reset(cuedSearchTask);
reset(trackingTask);
reset(radar);
restart(scenario1);

while advance(scenario1)
    time = scenario1.SimulationTime;

    % Get look requests that are due during this update interval
    volumeSearchLooks = lookRequests(volumeSearchTask, time, updateRate);
    cuedSearchLooks   = lookRequests(cuedSearchTask, time, updateRate);
    trackingLooks     = lookRequests(trackingTask, time, updateRate);

    % Combine all requested looks adding any looks remaining from the previous
    % update interval
    allLookRequests = [deferredLooks volumeSearchLooks cuedSearchLooks trackingLooks];

    % Generate a timeline of looks that can be executed within one
    % update interval based on the task priorities
    [scheduledLooks, deferredLooks] = helperScheduler(allLookRequests, time, updateRate);

    % Get target platforms from the scenario
    targets = platformPoses(scenario1);

    allDetections = [];
    trackPositions = [];
    trackIDs = [];

    % Execute each scheduled look one at a time
    for lookIdx = 1:numel(scheduledLooks)
        look = scheduledLooks(lookIdx);

        % Set radarDataGenerator properties
        radar.LookAngle            = look.LookAngle;
        radar.DetectionProbability = look.DetectionProbability;
        radar.FalseAlarmRate       = look.FalseAlarmProbability;
        radar.ReferenceRCS         = look.ReferenceRCS;

        % Set the reference range - the range at which a Swerling 0 target
        % with the Reference RCS is detected with the set
        % DetectionProbability and FalseAlarmRate - using the
        % helperReferenceRange function
        radar.ReferenceRange       = helperReferenceRange(look, mparPrms);

        radar.AzimuthResolution    = look.Beamwidth(1);
        radar.ElevationResolution  = look.Beamwidth(2);
        radar.RangeResolution      = bw2rangeres(look.Bandwidth);

        % Linearly interpolate the target positions from the last scenario
        % update time to the StartTime of the look 
        dt = look.StartTime - time;
        for targetIdx = 1:numel(targets)
            targets(targetIdx).Position = targets(targetIdx).Position + dt * targets(targetIdx).Velocity;
        end

        % Generate detections
        detections = radar(targets, time);

        % Set the detection time property to the look StartTime
        for detIdx = 1:numel(detections)
            detections{detIdx}.Time = look.StartTime;
        end

        % If this is a volume search look, the generated detections are
        % processed by the cued search
        if ~isempty(detections) && look.Type == helperRadarLookType.VolumeSearch
            cuedSearchTask.processDetections(detections);
        end        

        % If this is a track confirmation or a track update look, or if
        % this a cued search look that resulted in detections, process the
        % detections with the trackingTask
        if (~isempty(detections) && look.Type == helperRadarLookType.CuedSearch) ...
                || look.Type == helperRadarLookType.ConfirmTrack ...
                || look.Type == helperRadarLookType.UpdateTrack
            [trackPositions, trackIDs] = trackingTask.processDetections(look.StartTime, detections, look.DetectableTrackID);
        end        

        allDetections = [allDetections; detections];
    end

    % Cued search task maintenance
    cuedSearchTask.maintenance();

    % Tracking task maintenance
    trackingTask.maintenance(time);

    % Log simulation data
    truePositions = reshape([targets.Position], 3, [])';
    measuredPositions = helperGetCartesianMeasurement(allDetections);
    scenario1Data.log(truePositions, scheduledLooks, measuredPositions, trackPositions, trackIDs);
end

After running the simulation, the true target positions, the scheduled looks, the detections, and the tracks are stored in scenario1Data. You can use the recorded data to visualize the positions of the radar beams together with the true target locations, detections, and tracks.

% Produce scenario visualizations
generateVisualizations = false;
if generateVisualizations
    % Use helperScenarioPlotter class to visualize:
    %   - targets, trajectories, detections, and tracks
    %   - resulting beams placed by the radar
    % for the last 2 seconds of the scenario
    scenarioPlotter1 = helperScenarioPlotter(scenario1, volumeSearchTask.BeamPositions,...
        volumeSearchPrms.Beamwidth, volumeSearchPrms.ScanLimits);
    scenarioPlotter1.plot(scenario1Data, stopTime1-2, stopTime1);
end

Use the helperResourcesPlotter function to visualize the use of the MPAR resources over the time of the scenario.

helperResourcesPlotter(scenario1Data);

$Figure contains 3 axes objects. Axes object 1 with title Bandwidth, ylabel (MHz) contains 2 objects of type line. These objects represent Instantaneous, Average (update interval). Axes object 2 with title Power-Aperture Product, ylabel (W\cdot m^2) contains 2 objects of type line. These objects represent Instantaneous, Average (update interval). Axes object 3 with title Time Fraction, xlabel Time (s), ylabel (%) contains 4 objects of type line. These objects represent Volume search, Cued search, Track confirm, Track update.$

Although the instantaneous bandwidth used by the MPAR varies significantly over time, the average bandwidth in each update interval remains close to 0.5 Hz, which is the bandwidth required by the volume search task. Similarly, the power-aperture product averaged over the update intervals stays close to 500 W·m². This indicates that, despite spending some resources on the cued search and target tracking, the MPAR is mostly performing the volume search. This is also confirmed by the radar time fraction plotted against the simulation time. It shows that the scheduler almost always fills 90% or more of its time window with the volume search looks. The fluctuations in the volume search time fraction are due to 1) triggering a cued search task every time the volume search produces a detection even if it is a detection from a target that is already being tracked, and 2) using a simplistic scheduling logic based on the task priorities that does not optimize the use of the MPAR resources.

Overall, this result shows that tracking six targets in addition to performing volume and cued search does not significantly strain the radar system resources. However, if the number of targets in the search volume would grow, more and more resources would be diverted from the search task to the tracking task.

Scenario 2: High Probability of False Alarm

Higher values of the probability of false alarm can result in additional stress on the resource management system since false detections require scheduling of additional cued search and track confirmation beams. Create a new radarScenario object without any targets, set the probability of false alarm to 1.2e-5 for all tasks, and run the simulation.

stopTime2 = 8;
scenario2 = radarScenario('UpdateRate', updateRate, 'StopTime', stopTime2);
volumeSearchPrms.FalseAlarmProbability = 1.2e-5;
cuedSearchPrms.FalseAlarmProbability = 1.2e-5;
trackingPrms.FalseAlarmProbability = 1.2e-5;

updateTaskParameters(volumeSearchTask, volumeSearchPrms);
updateTaskParameters(cuedSearchTask, cuedSearchPrms);
updateTaskParameters(trackingTask, trackingPrms);

% Run the simulation. For convenience, the scenario simulation loop is moved
% to the helperSimulateMPARScenario function
scenario2Data = helperSimulateMPARScenario(scenario2, radar, volumeSearchTask, cuedSearchTask, trackingTask, mparPrms);

Visualize the scheduled beams, the detections, and the tracks for the update intervals between the 5th and the 7th second of the scenario.

% Produce scenario visualizations
generateVisualizations = false;
if generateVisualizations
    % Use helperScenarioPlotter class to visualize:
    %   - targets, trajectories, detections, and tracks
    %   - resulting beams placed by the radar
    scenarioPlotter2 = helperScenarioPlotter(scenario2, volumeSearchTask.BeamPositions,...
        volumeSearchPrms.Beamwidth, volumeSearchPrms.ScanLimits);
    scenarioPlotter2.plot(scenario2Data, 5, 7);
end

Plot the bandwidth, the power-aperture product, and the radar time fraction over time.

helperResourcesPlotter(scenario2Data);

Starting at around 5 seconds into the simulation the bandwidth and the power-aperture used by the MPAR start to grow. The time fraction plot shows that the track confirmation looks occupy about 50% of the radar time at around 7 seconds. For some update intervals after the 7th second the confirmation looks fill 100% of the scheduler time window. This is the consequence of the high probability of false alarm, which leads to a high volume of false detections and a high number of confirmation looks. The volume search task starts to slow down starting at the 5 second mark because the track task and the confirmation looks have higher priority than the volume search looks. Thus, the system resources are being diverted from the volume search to the tracking task. This result shows how sensitive the resource management performance could be to the probability of false alarm.

Conclusions

This example shows how to use radarDataGenerator to simulate an MPAR that can perform volume search, cued search, and target tracking. The volume and the cued search tasks can be executed at the same time by sharing the frequency bandwidth and the phased array aperture. On the other hand, the target tracking task uses the entire available bandwidth and aperture and thus cannot be multiplexed with other tasks. The example simulates two scenarios. It uses a frame-based radar look scheduler to arrange looks generated by the radar tasks into a timeline that must be executed within one scenario update interval. In the first scenario the MPAR searches and tracks six maneuvering targets. The computed radar time fraction indicates that tracking a small number of targets does not take away a lot of resource from the search functions. In the second scenario no targets are present in the search volume, but the probability of false alarm is set to a high value resulting in a spontaneous increase in the track confirmation looks that end up consuming more than 50% of the radar time. This scenario shows how such MPAR simulations can be used to study sensitivity of a resource management system to various parameters.

References

Moo, Peter, and Zhen Ding. Adaptive radar resource management. Academic Press, 2015.
Charlish, Alexander, Fotios Katsilieris, R. Klemm, U. Nickel, and C. Gierull. "Array radar resource management." Novel radar techniques and applications volume 1: real aperture array radar, imaging radar, and passive and multistatic radar (2017): 135-171.
Richards, M.A., Scheer, J. A. & Holm, W. A. Principle of Modern Radar: Basic Principles (SciTech Publishing, 2010).

Supporting Functions

type('helperRadarLook.m')

classdef helperRadarLook
    
    properties
        Type    
        StartTime        
        LookAngle
        NumPulses
        
        DetectableTrackID
        Priority
    end

    properties (Hidden)
        PowerApertureProduct
        StartFrequency
    end

    properties (Dependent)
        DwellTime
        Bandwidth
        Beamwidth
        Pulsewidth
        PRF
        DetectionProbability
        FalseAlarmProbability
        ReferenceRCS
    end

    properties (Access = private)
        TaskPrms
    end    
    
    methods
        function obj = helperRadarLook(type, startTime, lookAngle, numPulses, taskPrms)
            obj.Type = helperRadarLookType(type);
            obj.StartTime = startTime;            
            obj.LookAngle = lookAngle;           
            obj.NumPulses = numPulses;
            obj.TaskPrms = taskPrms;

            obj.DetectableTrackID = zeros(0, 1, 'uint32');
            obj.Priority = uint32(obj.Type);

            obj.PowerApertureProduct = 0;
            obj.StartFrequency = 0;
        end

        function value = get.DwellTime(obj)
            value = obj.NumPulses / obj.PRF;
        end

        function value = get.Bandwidth(obj)
            value = obj.TaskPrms.Bandwidth;
        end

        function value = get.Beamwidth(obj)
            value = obj.TaskPrms.Beamwidth;
        end

        function value = get.Pulsewidth(obj)
            value = obj.TaskPrms.Pulsewidth;
        end
        
        function value = get.PRF(obj)
            value = obj.TaskPrms.PRF;
        end

        function value = get.DetectionProbability(obj)
            value = obj.TaskPrms.DetectionProbability;
        end

        function value = get.FalseAlarmProbability(obj)
            value = obj.TaskPrms.FalseAlarmProbability;
        end
        
        function value = get.ReferenceRCS(obj)
            value = obj.TaskPrms.ReferenceRCS;
        end        
    end
end

type('helperRadarLookType.m')

classdef helperRadarLookType < uint32
   enumeration
      VolumeSearch (1)
      CuedSearch   (2)
      ConfirmTrack (3)
      UpdateTrack  (4)
   end
end

type('helperPlotSearchGrid.m')

function helperPlotSearchGrid(varargin)
    [ax, beamPositions, beamwidth, scanLimits, taskName, color] = parseInputs(varargin{:});

    hold(ax, "on");
    scanLimitsDisplayName = "Scan limits";
    beamPositionsDisplayName = "Beam positions";
    beamContoursDisplayName = "3dB beam contours";
    

    if ~isempty(taskName)
        scanLimitsDisplayName = sprintf("%s (%s)", scanLimitsDisplayName, taskName);
        beamPositionsDisplayName = sprintf("%s (%s)", beamPositionsDisplayName, taskName);
        beamContoursDisplayName = sprintf("%s (%s)", beamContoursDisplayName, taskName);
    else
    end

    if ~isempty(scanLimits)
        plot(ax, [scanLimits(1, 1) scanLimits(1, 1)], scanLimits(2, :), 'r', 'DisplayName', scanLimitsDisplayName);
        plot(ax, scanLimits(1, :), [scanLimits(2, 2) scanLimits(2, 2)], 'r', 'HandleVisibility', 'off');
        plot(ax, [scanLimits(1, 2) scanLimits(1, 2)], scanLimits(2, :), 'r', 'HandleVisibility', 'off');
        plot(ax, scanLimits(1, :), [scanLimits(2, 1) scanLimits(2, 1)], 'r', 'HandleVisibility', 'off');
    end

    plot(ax, beamPositions(1, :), beamPositions(2, :), '.', 'Color', color, 'DisplayName', beamPositionsDisplayName);

    p = helperBeamwidthContour(beamPositions(:, 1), beamwidth);
    plot(ax, p(1,:), p(2,:), 'Color', color, 'DisplayName', beamContoursDisplayName);

    for i = 2:size(beamPositions, 2)
        p = helperBeamwidthContour(beamPositions(:, i), beamwidth);
        plot(ax, p(1,:), p(2,:), 'Color', color, 'HandleVisibility', 'off');
    end
    
    grid(ax, "on");
    box(ax, "on");
        
    xlabel(ax, 'Azimuth (deg)');
    ylabel(ax, 'Elevation (deg)');
    axis(ax, "equal");
    ax.YDir = 'reverse';
end

function [ax, beamPositions, beamwidth, scanLimits, taskName, color] = parseInputs(varargin)
    args = varargin;
    
    k = 1;
    if isgraphics(args{1}, 'axes')
        ax = args{1};
        k = 2;
    else
        ax = gca();
    end
    
    defaultScanLimits = [];
    defaultTaskName = [];
    defaultColor = [0.45 0.45 0.45];

    p = inputParser;
    p.addRequired('beamPositions');
    p.addRequired('beamwidth');
    p.addParameter('ScanLimits', defaultScanLimits);
    p.addParameter('SearchTaskName', defaultTaskName)
    p.addParameter('Color', defaultColor)

    p.parse(args{k:end});
    beamPositions = p.Results.beamPositions;
    beamwidth = p.Results.beamwidth;
    scanLimits = p.Results.ScanLimits;
    taskName = p.Results.SearchTaskName;
    color = p.Results.Color;
end

type('helperPowerApertureProduct')

function pap = helperPowerApertureProduct(peakPower, pulsewidth, PRF, A)
    pap = peakPower .* pulsewidth .* PRF * prod(A);
end

type('helperNumPulses')

function n = helperNumPulses(lookAngle, range, taskPrms, mparPrms)
    % Detectability factor 
    Dx = detectability(taskPrms.DetectionProbability, taskPrms.FalseAlarmProbability);

    % Reference range
    referenceRange = radareqrng(mparPrms.Wavelength, Dx, mparPrms.PeakPower, 1/mparPrms.Bandwidth,...
        'Gain', beamwidth2gain(mparPrms.Beamwidth), 'RCS', taskPrms.ReferenceRCS, 'Ts', systemp(mparPrms.NoiseFigure));

    % Array scan loss
    Ls = abs(cosd(lookAngle(1, :))).^(-3) .* abs(cosd(lookAngle(2, :))).^(-6);   

    % Number of pulses
    deltaAntennaGain = beamwidth2gain(mparPrms.Beamwidth) - beamwidth2gain(taskPrms.Beamwidth);
    n = (range/referenceRange)^4 * db2pow(2*deltaAntennaGain) * Ls/taskPrms.Pulsewidth/mparPrms.Bandwidth;

    n = ceil(n);
end

type('helperReferenceRange')

function R = helperReferenceRange(radarLook, mparPrms)
    % Detectability factor 
    Dx = detectability(radarLook.DetectionProbability, radarLook.FalseAlarmProbability);

    % Reference range
    R = radareqrng(mparPrms.Wavelength, Dx, mparPrms.PeakPower, radarLook.NumPulses * radarLook.Pulsewidth,...
        'Gain', beamwidth2gain(radarLook.Beamwidth), 'RCS', radarLook.ReferenceRCS, 'Ts', systemp(mparPrms.NoiseFigure));  
end