Scalable GMTI Tracker

Transcription

1 Scalable GMTI Tracker Thomas Kurien Mercury Computer Systems 199 Riverneck Road Chelmsford, Massachusetts Abstract - This paper describes the design and preliminary implementation of a scalable multiple hypothesis tracker on a distributed memory multiprocessor computer. The throughput requirements of the tracker strongly depend on the desired performance and can amount to several giga floating point operations per second. We show that individual track processing tasks constitute more than 80% of the overall processing, and the tasks for any one track can be performed independently of other tracks. This inherent parallelism allows the tracker to be partitioned into data parallel tasks that can then be processed on different processors. Distributed memory multiprocessor computers allow a user to increase the number of processors, the amount of input/output bandwidth, memory, and inter-processor bandwidth to support increasing processing needs of an application. We combine the inherent parallelism in the tracker and the flexibility of a distributed memory computer to construct a scalable tracker. The user can scale either the tracker s performance or the number of targets tracked by adding more hardware (processor boards, I/O boards) and without making any changes to the tracker software. Keywords: GMTI Radar, Multiple Hypothesis Tracking, Distributed Memory Multiprocessor Computers, Scalable Mapping, Middleware. 1 GMTI Tracker 1.1 GMTI Radar Tracking Airborne and spaceborne Ground Moving Target Indicator (GMTI) radars provide a powerful capability to detect and track moving ground targets over large geographic areas. During a typical surveillance mission, the radar will produce a continuous stream of radar signal data. GMTI signal processing algorithms (e.g., STAP) will process the signal data to generate an associated stream of GMTI reports for moving targets. Individual target reports contain range, azimuth, and range-rate measurements for the target. Because the surveillance coverage region is typically much larger than the radar beam footprint, the radar scans the coverage region. As a result, the radar generates GMTI reports for targets in each region only on a periodic basis. The function of a GMTI Tracker is to correlate GMTI reports for each moving target, estimate the position and velocity of individual targets, and suppress false reports due to clutter. An example set of tracks produced from GMTI reports is shown in Figure Multiple Hypothesis Tracker (MHT) The source of each GMTI report is unknown. A report could originate from either clutter or a target. If it is from a target, then it could originate from one of many targets in the radar beam. Because of errors in radar measurements, uncertainty in the target kinematic model, and uncertainty about the source of each radar report, it is difficult to track targets accurately. One approach for improving the tracking accuracy is to postulate multiple hypotheses for the target kinematic model and the feasible correlations of reports for the target, and to then select the most likely hypotheses based on the observed measurements. In principle, the best tracking accuracy is achieved by formulating all feasible hypotheses. The number of feasible hypotheses, however, grows exponentially with the number of processed frames. Consequently, in practice, only a subset of these is formed. The user can control the number of hypotheses formed and the user can set this number based on the available computer processing power. 1.3 Tracker Functional Modules Figure 2 shows the major functional modules of a multiple hypothesis GMTI Target Tracking algorithm. Brief descriptions of these modules and the steps for processing a frame of GMTI reports are provided below. Preprocess Reports: The Preprocess Reports module constrains the measurements in each GMTI report to lie on the surface of the earth. Digital terrain elevation data (DTED) is used to account for terrain height variation above the mean sea level. For reasons discussed below, the Preprocess Reports module also constrains GMTI reports to lie along roads. Digital road information is available from NIMA databases and other Geographical Information System sources (e.g., Tiger data provided by the Census Bureau). Assume that a road following target is operating in a region with multiple road links (e.g., near a road intersection). Because of uncertainty in GMTI measurements, it is difficult to decide the correct road link on which the target is moving. Consequently, the Multiple Hypothesis Tracker will hypothesize multiple roadconstrained reports, each on a different road link contained in the report uncertainty region. The number of roadconstrained GMTI reports will be a function of the uncertainty in the range and azimuth measurements, and the density of the roads. GMTI reports constrained to roads will be referred to as road reports and these will be 1062

2 maintained as alternate interpretations (or hypotheses) of the GMTI report. Predict Tracks: As mentioned earlier, the Tracker processes GMTI reports on a frame-by-frame basis. Target tracks generated in earlier frames are predicted ahead from the time of the last update to the time of the current GMTI frame by the Predict Tracks module. For each existing track, the Predict Tracks module will create multiple track hypotheses. This will include tracks for constant velocity target model, maneuvering target models, off-road (unconstrained) target movement model, and on-road (constrained to move on road) target movement model. Gate Reports with Tracks: Uncertainty in the track position and velocity state is used to construct a gate in measurement space within which the true GMTI report for the track could potentially lie. The gate is padded to account for GMTI report measurement errors. All GMTI reports that fall within the gate of an existing track are paired with that track. Each such pairing is used to construct a different track hypothesis. The procedure is repeated for all existing tracks: unconstrained GMTI reports are gated with off-road tracks; road reports are gated with road following tracks. Note that the same GMTI report may gate with more than one track. The idea of pairing more than one track with the same GMTI report may seem counter-intuitive because a report can originate from only one target 1. As mentioned earlier, alternate pairings for a report are only potential hypotheses created by the Tracker at most, only one pairing is ultimately selected for each report. Update Tracks: The Update Tracks module takes each track-report pair and updates the kinematic state vector of the track with measurements in the GMTI report. A Kalman Filter is used to update the track. Note that each off-road track will be updated with a four-state extended Kalman filter (EKF), and each on-road track will be updated with a two-state linear Kalman filter. The Update Tracks module also computes the likelihood for each updated track based on the filter innovations. Note that both off-road and on-road track likelihoods are computed based on the GMTI report measurements. Manage Track Hypotheses: The Manage Track Hypotheses module performs two functions. It first selects the best updated track for each target. In the selection process, it ensures that each report is assigned to at most one target. As we have indicated earlier, the MHT approach uses more than one frame of data to determine the best match of reports to tracks. This feature waiting to finalize assignment decisions until more data can be examined is why multiple hypothesis algorithms are able to provide better performance in more complex scenarios. The resolution of the multiple track hypotheses occurs over 1 We assume that no more than one target lies within the same radar GMTI measurement resolution cell. a fixed length sliding window. That is, at the current frame, the algorithm chooses the most likely report-totarget association nscan frames in the past. The value of nscan represents the depth of the target hypothesis tree. Choosing the most likely association involves more than just comparing the track likelihoods, as there is the assumed global consistency constraint that a single report can be related to at most one target. The resolution of the track hypotheses is the selection of at most one track per target such that the sum of the selected track likelihoods is maximized while satisfying the global consistency constraint [1]. After assigning reports to existing targets, the Manage Track Hypotheses module then creates new target tracks for each report that was not assigned to any existing track hypotheses. Updated tracks and new tracks are then passed to the Predict Tracks module. The processing sequence then repeats for the next frame of radar GMTI data. 2 Tracker Processing Requirements Processing requirements of the front-end GMTI report generation algorithm (e.g., space-time adaptive processing (STAP)) are primarily a function of the radar data input rate. In contrast, processing requirements for the backend GMTI MHT depend not only on the GMTI report rate, but also on the desired performance. Parameters that have an impact on the GMTI report rate include radar revisit period, radar coverage area, radar detection characteristics, target density, and clutter density. Parameters that have an impact the Tracker performance include hypothesis management parameters (e.g., the target hypothesis tree depth), and the terrain characteristics (e.g., road link density, average road link length, and terrain elevation characteristics). A detailed description of these parameters and how they impact the throughput requirements of each module in the GMTI Tracker are discussed in [2]. Although increasing the radar revisit rate will increase the rate at which tracks are updated, it will also decrease the track gate size and thus reduce the number of report associations for each track. Consequently, the radar revisit does not have a big impact on Tracker throughput requirements. A parameter that has a bigger impact on the Tracker throughput requirements is the target hypothesis tree depth. Figure 3 shows the Tracker processing requirements as a function of the target hypothesis tree depth. These requirements were computed for processing 10,000 targets with nominal values of sensor parameters. The figure indicates that the throughput is of the order of 10 giga floating point operations per second (GFLOPS). Improvements in GMTI radars will lead to increases in coverage areas, higher sensitivities, and better resolutions. Improvements in sensitivity and resolution will cause many more objects (e.g., smaller civilian traffic) to be detected and reported by the radar. GMTI radar improvements will therefore create larger amounts of GMTI report data that 1063

3 will have to be processed to extract information on the targets of interest. The improved radar resolution will also require the GMTI Tracker to processes larger amounts of data. Increasing the sensitivity and resolution of the radar will therefore cause an increase in GMTI Tracker processing requirements. A breakdown of the processing requirements for each major task in the GMTI Tracker is shown in Figure 4. What is clear from the figure is that Track Prediction, Report Gating, and Track Update constitute more than 80% of the processing requirements. Each of these tasks can be performed independently for individual tracks. In other words, most of the processing of individual tracks can be performed in parallel on separate processors without the need for inter-processor coordination. 3 Distributed Memory Multiprocessor Computers A Mercury computer is an example of a distributed memory multiprocessor computer. The system architecture of a Mercury computer provides the capability to cluster processors dedicated to a specific application, perform efficient inter-processor communication, and scale the processing capacity (by adding processors, memory, I/O bandwidth, and interprocessor bandwidth). Efficient interprocessor communication is enabled by a high-bandwidth interconnect fabric and easy access to special purpose hardware for inter-process data transfers (e.g., direct memory access (DMA)). 3.1 Hardware The basic hardware building blocks in a Mercury multiprocessor computer are shown in Figure 5. Each Mercury compute node (CN) consists of a single central processing unit (CPU) chip, up to 512 MB of synchronous dynamic random access memory (SDRAM), and a CNapplication specific integrated circuit (CN-ASIC). The CN consists of an MPC7410 microprocessor with AltiVec TM technology that has a peak throughput of 4 GFLOPS. The CN-ASIC provides a three-way data switch between the processor, the processor s SDRAM, and the RACEway interlink fabric. Each CN-ASIC also contains a DMA controller that allows the CN to directly access remote processor SDRAM. Two compute nodes are placed on a daughtercard. Daughtercards can also contain memory, or I/O devices that provide an interface to an external data source or sink. Daughtercards, in turn, are placed on motherboards. Motherboards also contain RACEway 8- port crossbar switches and bridges to the system bus. The RACEway crossbar switch provides the link between processors on the same motherboard, and the RACEway interconnect fabric (made up of crossbar switches) provides the link between processors on different motherboards. The RACEway interconnect fabric support bandwidths of up to 600 MB/s, with switching times are generally less than 1 microsecond. Such a network of compute and I/O nodes is currently capable of providing up to 500 GFLOPS of processing power and up to 2GB/s of input data bandwidth. 3.2 System Software A copy of Mercury s real-time operating system MCOS runs on each CN. In addition to MCOS, Mercury provides the following three sets of optimized libraries: SAL (Scientific Application Library) contains over 400 signal processing routines supporting both real and complex data types; PixL (Pixel Library) contains over 140 image processing routines supporting a variety of fixed-point data types; PAS (Parallel Acceleration System) contains routines for synchronization and data movement among the multiple processors. Applications based on these libraries can be run on any other Mercury system without requiring any changes to the application software. 3.3 Compute Density Compute density is defined as processing throughput (GFLOPS) per unit volume (cubic foot). Distributed memory computers have a distinct compute density advantage over shared-memory computers (e.g., workstations and servers). The primary reason for this is because of differences in the types of processors: processors in a Mercury computer utilize their transistor budget to maximize throughput and they place constraints on the power level; server and workstation processors utilize their transistor budget to maximize the number of instructions per clock cycle and they impose few constraints on the power level. For example, the PowerPC processor, used in a Mercury computer, contains about 30 million transistors and consumes only 5 watts of power. In contrast, the Itanium processor (used in many servers and workstations) contains about 130 million transistors and consumes 60 watts of power. The larger power required for a workstation or server processor results in the need for bigger and bulkier power supplies and associated cooling devices to dissipate the excess heat. In a distributed memory computer, the lowpower processor chips are spatially distributed and so they do not require the bigger cooling devices. Distributed memory computers also use better packaging techniques and they use more compact processor interconnect systems resulting in better compute densities. 4 Scalable GMTI Tracker 4.1 Mapping Approaches There are three general approaches for mapping an algorithm to a multiprocessor computer. As described below, the approaches are based on how the algorithm tasks and input data stream can be partitioned. Process Replication: This approach is applicable to the case where the input data stream can be partitioned in time, 1064

4 and the processing for each time interval is independent of the others. For this case, the entire algorithm (or process) is replicated on each available processor, and the input data stream is partitioned in time and distributed to each processor using a scheduling (e.g., round-robin) approach. This approach leads to higher throughput rate, but no reduction in processing latency. Process Partitioning: This approach is applicable to the case where the algorithm can be partitioned into a series of tasks, where the input data for one task is the output of the previous task. For this case, the processors are set up as a pipeline, where one or more processors perform each task in the algorithm. This approach also leads to higher throughput rate, but it increases the latency. Process Replication with Partitioned : This approach is applicable to the case where the algorithm input data stream can be partitioned into subsets, and the same task or group of tasks can be performed in parallel on each subset of the input data. Note that this approach leads to higher throughput rate and a reduction in processing latency. This approach is also referred to as a data parallel mapping approach. 4.2 Mapping Tracker to Mercury Computer Because of the inherent data parallelism in the Tracker algorithm, we use the data parallel mapping approach. The mapping approach is shown in Figure 6. The radar coverage area is partitioned into N regions, and a Tracker processor is assigned to each region. The Controller processor distributes GMTI reports in each region to the appropriate Tracker processor. Each Tracker processor processes the tracks contained in its region. Specifically, each Tracker processor performs the tasks of creating multiple interpretations of each GMTI report, predicting existing tracks, gating reports with tracks, updating existing tracks, and creating new tracks for its region. After updating tracks, each Tracker processor will examine the updated location of each track, and transfer those that cross its region boundary to the Tracker processor responsible for the region into which the track entered. Because of uncertainty in track motion models and measurements, some targets operating near the region boundaries may need to be processed by more than one Tracker processor. The Track Coordinator processor resolves the ambiguities arising for such tracks. The Controller processor also handles the initialization and shutdown of the Tracker processors. Based on the number of regions defined by the user, the Controller processor initially assigns regions to Tracker processors and initializes the Trackers for each region. As each frame of GMTI report data is received, the Controller processor distributes the GMTI reports to the appropriate Tracker processor. When all frames of report data are processed, the Controller processor shuts down the individual Trackers running on each Tracker processor. An important feature of above mapping approach is that the resulting GMTI Tracker is scalable. This means that increasing the number of Tracker processors can reduce the latency for processing each frame of data. It also means that we can improve Tracker performance, handle more targets, and handle increasing input data resulting from improved radar resolutions by adding more Tracker processors to the Mercury computer. Furthermore, the mapping strategy ensures that this scaling can be affected by user parameters defined at run time and without changing the GMTI Tracker software. 4.3 Preliminary Results We have implemented a preliminary version of the Scalable Tracker on a Mercury computer and analyzed the throughput times as a function of the number of Tracker processors. We constructed a simulation of a scenario containing10,000 targets distributed uniformly in the radar coverage region. Figure 7a shows the throughput times for the data parallel tasks in the Tracker. The Kalman Predict, the Setup Gate, and the Kalman Update tasks scale linearly with the number of processors. The Gate Reports task has better than linear scalability because of the built-in clustering of the reports performed by the Controller processor. Figure 7b shows the total throughput times for these four functions. An analysis of the throughput times for all functions in the Tracker for a more realistic scenario is ongoing. 4.4 Tracker Service for Ground Stations We have also shown how a Mercury-based scalable GMTI multiple hypothesis tracker service can be integrated within General Dynamics Openwings architecture for the Distributed Common Ground Station (DCGS) [3]. Openwings is a network-centric service-oriented architecture developed by General Dynamics for a distributed processing system [4]. Figure 8 shows the Openwings architecture applied to DCGS. A user can plug-in to the DCGS system, services such as sensor data sources, digital maps, and processing algorithms. For example, the left side of Figure 8 shows servers providing radar GMTI, infrared (IR), and video sensor data services derived from airborne platforms such as Joint STARS, U- 2, and ARL. The figure also shows servers providing digital map services such as VMaps and DTED. A list of processing services such as SAR Image Formation, GMTI Detection, Target Tracking, etc., is shown on the right side of the figure. These processing services are typically implemented on different types of computer platforms such as workstations, digital signal processors (DSPs), and high performance distributed memory multiprocessor computers. The Openwings network and service infrastructure enables each of these computer platforms and associated services to be plugged into the DCGS system. As each computer platform is plugged in, it will advertise that fact to the user. The user is therefore aware of services available on all platforms 1065

5 connected to the DCGS system. The user can configure and launch scalable services to perform required DCGS tasks. 5 Summary and Future Work We have described the implementation of a scalable GMTI Tracker on a distributed memory multiprocessor computer. We showed that the throughput requirements of the Tracker strongly depend on the desired performance and can amount to several GFLOPS. We combined the inherent parallelism in the Tracker and the flexibility of a distributed memory computer to construct the scalable Tracker. Preliminary results show that we get close to linear reduction in throughput time by increasing the number of processors. The user can scale either the Tracker s performance or the number of targets tracked by adding more hardware (processor boards, I/O boards) and without making any change to the Tracker software. Other data exploitation algorithms such as Geo-registration and Automatic Target Recognition have also been implemented on a Mercury computer. Because these algorithms are highly data parallel, their implementations on a Mercury computer can be scaled to support larger sensor data rates, improved sensor resolutions, and improved algorithm performance. An integrated set of Processing algorithms will be able to monitor both stationary and moving targets in the region of interest: stationary targets are identified and monitored by the Image Processing functions; moving targets are tracked and monitored by the Report Processing functions; and stop-and-go targets are identified, tracked, and monitored by the integrated system. Non-real-time prototypes of such systems have been demonstrated in several DARPAfunded efforts (e.g., [5]). Integrating these functions on the Mercury will enable real-time demonstrations of this capability. processing application developers can benefit from middleware that maps the data parallel tasks on multiprocessor computers. Mercury has written the draft specification for Parallel CORBA which combines the capabilities of traditional parallel programming middleware (e.g., MPI) and object-oriented middleware (CORBA) [6]. We are currently investigating implementation of these specifications to support the rapid development of scalable data exploitation algorithms on Mercury computers. References 1. T. Kurien, Issues in the Design of Practical Multitarget Tracking Algorithms, In Multitarget- Multisensor Tracking: Advanced Applications, Y. Bar-Shalom (ed.), Artech House, Norwood, MA, 1990, pp T. Kurien, Multiple Hypothesis Tracker Implementation on a Mercury Computer, Internal White Paper, Mercury Computer Systems, 199 Riverneck Road, Chelmsford, MA, March 27, J. Carpenter and G. Bieber, Openwings Overview Alpha Ver. 0.71, April 10, Scalable GMTI Tracker Service for Openwings-Based DCGS System, Mercury Computer Systems Final Report, Prepared for General Dynamics Decision Systems, January T. Kurien, A. Chao, S. Streltsov, and D. Castanon, Continuous Tracking of High-Value Targets Using Multi-Mode Radar, ALPHATECH Technical Report TR-883, ALPHATECH Inc., 50 Mall Road, Burlington, MA, July Parallel Draft Adopted Specification 28. Parallel CORBA, Object Management Group, October

6 MTI REPORTS TRACKS Figure 1. Function of GMTI Tracker. Time Road PREDICT TRACKS Retained Track Hypotheses Predicted Track Hypotheses Report/Track Pairs Updated Track Hypotheses MTI Reports GATE REPORTS WITH TRACKS PREPROCESS REPORTS Constrained MTI Reports UPDATE TRACKS DTED MANAGE TRACK HYPOTHESES Target Tracks DTED Road Figure 2. Major Functional Modules in the GMTI Tracker. 1067

7 No. Targets = 10,000 Throughput Percentage by Function Throughput (GFLOPS) Target Hypothesis Tree Depth 100% 80% 60% 40% 20% 0% Hyp. Mgmnt. Track Update Gate Track Predict Rpt. Preproc. No. Targets Figure 3. Processing Requirements of Tracker. Figure 4. Breakdown of Tracker Processing Requirements. MOTHERBOARD CN-ASIC DAUGHTERCARD Figure 5. Mercury Computer Building Blocks. 1068

8 Task Setup Processors Input Reports Synchronize Geolocate Reports Generate Road Reports Predict Tracks Gate Reports Update Tracks Create Tracks Manage Hypotheses Output Tracks Processor Controller Tracker 1 Tracker 2.. Tracker n Track Coordinator Basis for Mapping Region 1 Region 2.. Region n Figure 6. Mapping of GMTI Tracker Tasks to Processors. Scalability (Individual Functions) Scalability (All Functions) Normalized Throughput Time Predict Setup Gate Gate Update Normalized Throughput Time No. Processors No. Processors (a) Figure 7. Normalized Throughput Requirements as a Function of Number of Tracker Processors. (b) Services Joint STARS Map Services VMAP Processing Services Image Formation, STAP Tracking, Geo-Registration, ATR base Queries U-2 DTED Sensors ARL Server ADRG Server Workstations DSPs HPEC Common Operational Picture Network and Service Infrastructure Figure 8. Openwings Architecture for Ground Stations. 1069