Simulation89 is an emulation of various SDI tasks (tracking, 

engagement management and ‘look ahead’) developed for the 

U. S. Air  Force. The simulation presently  deals with 

the boost, post-boost and early midcourse phases of 

a ’mass raid’ scenario, and is designed to process scenarios with a few thousand  targets. The simulation is run on 

the Mark-III hypercube, with individual tasks performed 

on subcubes of the full hypercube. In  general, the computations within  individual subcubes are done in 

a synchronous manner (i.e., CrOS), while communications between tasks/subcubes  are done asynchronously

Gottschalk, T. D.

Caltech Authors - Main

Concurrent Multi-Target Tracking 
T. D. Gottschalk 
California Institute of Technology 
Pasadena, CA 91125 
1 Overview 
Simulation89 is an emulation of various SDI tasks 
(tracking, engagement management and ‘look ahead’) 
developed for the U. S. Air Force. The simulation 
presently deals with the boost, post-boost and early 
midcourse phases of a ’mass raid’ scenario, and is de- 
signed to  process scenarios with a few thousand tar- 
gets. The simulation is run on the Mark-I11 hyper- 
cube, with individual tasks performed on subcubes 
of the full hypercube. In general, the computations 
within individual subcubes are done in a synchronous 
manner (i.e., CrOS), while communications between 
tasks/subcubes are done asynchronously. 
The nominal task for the tracking module is to pro- 
vide state information on individual targets, given 2D 
line of sight data from various sensors at regular time 
intervals. This task is complicated by means of a few 
relevant additional requirements: 
1. 
2. 
3. 
In the initial boost phase, the trajectories of in- 
dividual targets are not fully known. 
The overall system must scale in such a way that 
increases in the size of the underlying scenario 
are accomodated by (proportional) increases in 
the size of the tracking sub-cube. 
The tracker must meet ‘real time’ requirements. 
The first requirement in fact dictates the gross over- 
all structure of the tracking package, as illustrated 
in Fig.(l). A single tracking system is formed from 
two elementary 2D tracking subsystems. Each 2D 
tracking sub-system processes individual data from its 
own associated sensor, forming lists of plausible mono 
tracks through these data sets. These 2D tracks are 
then shared between the two 2D sub-system, and a 
single set of 3D tracks is formed. 
The tracking models used for the 2D and 3D sub- 
systems are quite different. According to the first re- 
quirement listed above, it must be assumed that the 
data from a single sensor are insuficient to  resolve 
all Track-Hit ambiguities. As a consequence, the 2D 
systems use a Multiple Hypothesis formalism in which 
Figure 1: Schematic Tracker Organization 
many candidate tracks through a single sensor datum 
are allowed. Such a model is subject to exponential 
explosions of the overall track file. This fundamental 
difficulty is resolved by a number of rules for pruning 
the size of the overall track file. In particular 
Two tracks ending on a given datum are said to 
be equivalent if they share the same 2D data over 
the last four scans. 
The number of inequivalent tracks per datum is 
limited by a cutoff parameter. 
The total number of 2D tracks is also limited by 
a global cutoff. 
If two tracks in the system are found to be equiva- 
lent according to point 1, one of the tracks is simply 
deleted. As is discussed below, the task of identifying 
equivalent tracks in the distributed 2D track file dic- 
tates the maner in which the 2D tracking problem is 
decomposed for concurrent execution. 
Unlike the 2D tracking system, the 3D tracker 
in Fig.(l) maintains (at most) one track per sen- 
sor data point, representing the best global interpre- 
tation of tracks through the data (this single ‘best 
guess’ answer is the output of the tracker expected 
by the other elements of Sim89). In place of the 
Multiple-Hypothesis model used for 2D tracking, the 
85 
0-8186-21 13-3/90/0000/0085$01 .OO Q 1990 IEEE 
3D tracker is based on Optimal Associations. These 
optimal associations in fact come in two distinct 
form: 
1. For track extensions, the predicted data positions 
of individual 3D tracks are associated with actual 
data from the two sensing subsystems of Fig.(l). 
2. For 3D track initiations, 2D tracks form the two 
subsystems of Fig.( 1) are associated according to 
values of projections onto an association refer- 
ence axis (so-called ‘Hinge Angle’ associations). 
The adoption of an Optimal Association formalism 
essentially trivializes the concurrent decomposition of 
the 3D tracker : the 3D tracks are distributed among 
the nodes of the subcube in such a way that the num- 
ber of tracks per node is constant. The challenge of 
concurrent 3D tracking comes entirely in performing 
the two types of optimal associations. 
A general concurrent algorithm for optimal associ- 
ations is described in Ref.[l]. However, the resource 
requirements for the general optimal association prob- 
lem (AT’ oc N 3  for N x N  association problems) is 
such that a straightforward use of the general associ- 
ation formalism is completely inappropriate. Instead, 
the concurrent association algorithm proceeds as fol- 
lows: 
Each node computes a list of associations keys 
(i.e., projections onto an appropriate reference 
axis), for all items in its local track list. 
The distributed lists of association keys are glob- 
ally sorted. 
The sorted lists are divided into a number of sub- 
blocks, determined by appropriately large gaps in 
the lists of keys. 
The sub-blocks are assigned to individual nodes 
and the assignment problems for sub-blocks are 
solved using a modified ‘sparse’ formalism of the 
general assignment problem. 
This procedure is efficient as long as the number of 
separate sub-blocks found in the third step is large 
compared to the number of nodes in the tracking sub- 
cubes (which is, empirically, almost always the case 
for the Sim89 problem). 
In addition to the central tasks of Track-Hit and 
Track-Track associations, the 3D tracker also evalu- 
ates trajectory fits for all 3D tracks in the system. Un- 
like the predecessors to Sim89, these trajectory fits are 
not essential elements of tracking p e r  se. All tracking 
is done using kinematic system models. The trajec- 
tory parameterizations are added to the tracking task 
103 
X : S D T X ? X h  
102 
0 60 100 160 200 
Scan 
Figure 2: Data Set and Track File Sizes Versus Sican 
for purposes of communications: The 3D track file 
structures according to the kinematic model are huge 
(more than 100 floating point numbers per track), 
and the model-dependent parameterizations greatly 
reduce the sizes of track file messages passed between 
subcubes of the full Sim89 simulation. The concur- 
rent estimation of track parameters is again trivial, 
with each node independently performing this task 
for its own subset of the global track file. 
2 Some Sample Results 
This section briefly examines some typical results of 
the Sim89 tracker for a standard input set. The threat 
scenario involves 200 primary targets, each of which 
ultimately spawns 10 daughter objects (RV’s). The 
targets are launched from six separated launch sites 
over a two minute time window. The primary threat 
is preceeded by a simultaneous launch of sixty sec- 
ondary targets ( ASAT’s). 
Sizes of the data sets and 2D and 3D track file,, ct are 
plotted versus scan number in Fig.(2). The peaks near 
scan 40 are due to interception of the ASAT’s, while 
the prolonged increase in object counts after scan  80 
is due to gradual deployment of RV’s from the sur- 
viving primary targets. As expected, the number of 
2D tracks greatly exceeds the actual number of tar- 
gets. The ‘kinks’ in the 2D track counts for large scan 
number are the result of the automatic reductions in 
tracks/datum cutoffs mentioned in Section 1. 
The number of 3D tracks is very close to the actual 
number of targets. The histogram in Fig.(3) shows 
86 
Track Purity (%) 
0, +, 0 : 1, 2, 9 soana 
0 60 100 160 200 
scan 
Figure 3: Track File Completeness, Purity Versus 
scan 
3D Step Times [sec] 
t - - - - I - . - - ' - ' - - I - - - ' i  
101 
100 
10-1 
0 60 100 160 200 
Scan 
Figure 4: CPU Step Times For 3D Tracking 
the percentage of targets in track, 
P[In Track] E N[3D Tracks]/N[Data] 
versus scan number. Once the primary targets are 
into second stage (about scan SO), the percentage in 
track is excellent. Also shown in Fig.(3) are the frac- 
tions of pure tracks 
Pj 3 Nb-Scans Correct]/N[3D Tracks] 
where the numerator is the number of 3D tracks which 
(correctly) incorporate data from a single underlying 
target through the past j scans. 
The mild degradations in both percentage in track 
and j-Scan correct tracks between scans 150 and 200 
are due to the successes of the engagement manage- 
ment component of Sim89 in intercepting the targets. 
The disappearence of expected targets causes some 
'confusion' for TrackttHit associations on subsequent 
tracking scans. 
The CPU times for various components of 3D track- 
ing are plotted versus scan number in Fig.(4). Most 
of the CPU resources are spent in the evaluation of 
TrackttHit associations. With the exception of the 
'confused' scans with disapperaing tracks, the CPU 
requirements for tracking generally scale as AT 0: 
NlogN for N active targets. 
3 Concurrent Aspects 
The task of multi-target tracking is well-suited for 
concurrent execution, with most of the 'tracking' p e r  
se done by way of CPU-intensive operations involv- 
ing individual trackttdata pairs (the filter update of a 
single 3D track involes more than one thousand float- 
ing point operations : an ideal use of the WEITEK 
coprocessor). In the entire tracking program (more 
than 35000 lines of code), there are really only three 
general concurrent operations/aspects, 
1. Global collection of data across the subcube. 
2. Distributed sorting. 
3. Track file redistributions. 
with each of these tasks occuring in a variety of guises. 
The sorting task is done using the basic algorithm of 
Ref.[2], with a trivial but important modification to 
allow empty local sublists (empty track files on some 
nodes occur during the first few scans of the tracking 
task). 
The global data collections are all done using a sim- 
ple loop on communication channels: 
0 Set Global Value To Local Value 
0 Loop On Communication Channels 
- Exchange Values Across Channel 
87 
- Update Global Value Using Input 
0 End O f  Channel Loop 
This simple paradigm is used throughout the code 
for a variety of purposes, such as assessment of global 
status (the ‘Update’ task is a logical and of individual 
status flags), determining global file sizes (‘Update’ is 
simple addition) or assessing global Track-Data as- 
signments (‘Update’ is a slightly more complicated 
merging of track assignment arrays generated on in- 
dividual nodes). 
For the 3D tracking task, concurrent efficiency re- 
quires only that the number of tracks per node be 
approximately constant. Accordingly, track file re- 
distribution for 3D tracking is done using a simple 
variant of the channel loop model: 
0 Loop On Communication Channels 
- Exchange Track F i l e  Sizes 
- Set 6 (NHERE - NTHERE)/~ 
- I f  6 > 0,  Send 6 Items Over Channel. 
- I f  6 < 0,  Receive 6 Items. 
0 End Of Loop On Channels. 
After the exchanges across a given channel, the 
number of items on each half of the subcube with 
respect to that channel is (approximately) the same, 
and subsequent loops on other channels do not mod- 
ify this equality. At the end of the channel loop, the 
tracks are equally divided across all  channels - mean- 
ing that the number of tracks per node must be ap- 
proximately the same. 
The only aspect of the full tracking program which 
involves concurrent ‘subtleties’ is the redistribution 
of the the global 2D track files. Wasteful cubcwide 
searches for equivalent tracks (same sensor data over 
the last four scans) can be avoided if the assignment of 
tracks to  nodes is done according to a single essential 
requirement. 
At the start of each 2D tracking scan, all 
tracks ending on a given sensor datum are 
to be assigned to a single node. 
If this condition is satisfied, then searches for equiv- 
alent tracks need only be done locally. The require- 
ment is enforced as follows: 
1. Assign each datum of the current data set to a 
specific node. 
2. Transfer all tracks in the system to that node 
which ‘owns’ the data point for the last scan in- 
cluded in the track. 
This redistribution is in fact done as the last step 
in 2D processing at each scan, so that the next scan 
begins with the basic track distribution requirement 
satisfied. 
Once data points (hence tracks) have been assigned 
to individual nodes, the actual redistribution of the 
tracks is a straightforward application of the basic 
Crystal-Router formalism of Ftef.[3]. The calculation 
of destinations for individual data is done using the 
following simple set of rules: 
1. Each datum is assigned a Weight, taken to be the 
total number of tracks in the system wich end at 
that datum. 
2. Data are assigned to nodes such that the total 
Weight per node is approximately constant. 
3. If, prior to the redistribution, a particular node 
already contains more than half of the total 
weight of an individual datum, then the datum is 
assigned to that node - provided that such an as- 
signment does not violate the total node weight 
restrictions of point 2. 
4. Unassigned data (i.e., data without tracks) are 
assigned to nodes in a simple ‘Card Dealing’ fash- 
ion. 
These rules are easily implemented by means of a few 
simple channel loops of the form discussed above. 
4 Conclusion 
The hard part of ‘Concurrent Tracking’ is the tracking 
iteslf, not the concurrency. 
References 
1. T. D. Gottschalk, ‘Concurrent Implementation of 
Munkres Algorithm’, there proceedings. 
2. G. C. Fox et al., Solving Problems on Concur- 
rent Processors, Englewood Cliffs, NJ: Prentice 
Ha11(1988), Chapter 18. 
3. Chapter 22 of Ref.[2]. 
88 


Concurrent Multi-Target Tracking

https://authors.library.caltech.edu/78700/1/00555366.pdf

Concurrent Multi-Target Tracking

Abstract

Similar works

Full text

Available Versions

Caltech Authors - Main