You are asking three different questions:
How to generate an alert when a fused track is lost?
Suppose the following function takes as an input the fused tracks from the previous step. It then sees whether the fused tracks in the current tracks are missing any of the fused tracks in the previous step, simply by matching IDs.
function [shouldAlert, missingIDs] = alertIfMissingTracks(currentTracks)
persistent lastTrackIDs
currentTrackIDs = [currentTracks.TrackID];
missingIDs = setdiff(lastTrackIDs, currentTrackIDs);
shouldAlert = ~isempty(missingIDs);
lastTrackIDs = currentTrackIDs;
end
Remember to clear the function at the end every scenario run otherwise the presistent lastTrackIDs variable will keep the last run values.
How to identify when ADS-B is missing?
That depends on how you set up your tracking architecture, but you can replicate a similar function to the above - just use a different name for it - to keep track (pun intended, but isn't great) of which ADS-B IDs are reported.
How to identify when there are large differences between ADS-B and Radar tracks?
This is one of the many million dollar questions that people frequently ask and I think it's still a research question. There are many reasons why an ADS-B track might diverge from radar tracks, e.g., low GPS positioning accuracy, spoofing, jamming, etc. I don't know if there are reliable ways to recognize each of these.
A very crude way to check if radar tracks and ADS-B tracks are "too far" is to look at the 4th output of the trackFuser update. Here is a link to the explanation of that:
You will have to do some digging into the CostMatrix, Assignments, UnassignedCentralTracks, and UnassignedLocalTracks. "Local tracks" mean tracks coming as inputs to the fuser, like ADS-B and radar tracks. "Central tracks" are tracks managed by the fuser. Assignments will show you two columns - of local (input) tracks on the left and their associated central tracks on the right. Between these lists and the CostMatrix, you can figure out when an ADS-B track could not be assigned to a central track, when a radar track could not be assigned to a central track and then you can investigate whether either one of them was too far to be assigned.
The problem is that the fused track, if mainained by both radar and ADS-B for a while will likely follow more closely the ADS-B track, because of its lower reported uncertainty. The radar tracks are more likely to fail to assign than the ADS-B ones. Nevertheless, if the ADS-B "steals" a fused track from the radar track, at some point the radar track will initialize and confirm a fused track, which means that the same true object is now tracked by two fused tracks. This is the eventual phenomenon you are likely to see when the ADS-B deviates from radar tracks.
There is no easy solution other than writing a function that looks for these cases.
