I. Definition of Problem and Terms

The best (or at least most relevant) definition for "Tracking" can be given in terms of high-level inputs and outputs:

Inputs:

Collections of detections from sets of sensors viewing some "interesting" but otherwise unknown underlying scenario.

Outputs:

An interpretation of the underlying scenario with sufficient detail and specificity to enable actions by appropriate decision makers.

Contents

I. Definition of Problem and Terms (This Section)
II. High-Level Task Decomposition
III: Schematic With "State of the Art"
IV: High Level System Requirements
V: Getting From Here To There
VI: Some Supporting Documentation

II. High-Level Task Decomposition

1. Scenario Simulation: Modeling of the underlying "truth" with suitable fidelity to provide realistic inputs to simulated sensing subsystems. This includes not only the underlying "target entities", but a whole host of additional inputs, such as weather.

2. Sensor Simulation: Modeling of individual sensor responses to the underlying scenario.

3. Single-Sensor Tracking: Association of individual data returns over time into subsets identified with individual perceived targets, providing estimated state information on the targets.

4. Multi-Sensor Tracking:
   1. Track Fusion: Correlating/combining tracks from a variety of Single-Sensor systems into a high-level, single set of perceived system tracks.
   2. Track Updates: Adding to data content of individual system tracks directly from detections, without requiring the "intermediary" of a Single-Sensor track. (This is particularly important for certain "sporadic sensor" classes, such as HUMINT.)

5. System Track File Management
   1. Simple Management: For example, identifying/deleting "dead tracks".
   2. Typing: Interpreting individual tracks and assigning "interest levels" (e.g., probable grocery clerk versus Osama).
   3. System Level Fusion: Combining perceived states from possible disjoint Multi-Sensor Tracking components within an overall larger system.

6. Sensor Tasking: Directing subsequent viewing attempts by some/all of the available sensor assets to targets or regions that have been identified as "interesting". Tasking comes in two varieties:
   1. Automatic: Single-sensor trackers direct associated sensor viewing strategies according to (locally) perceived truth.
   2. HITL: Operators make policy/assessment-driven decisions, possibly overriding the automatic tasking strategies.

7. Data Management Component
   1. Event Data Base: Management and access to data associated with the ongoing perceived truth at a variety of levels (e.g., sensor returns to tagged tracks).
   2. Historical Data Base: Management and access to appropriate fiews to, for lack of a better name, "life as normal".
   3. Data Mining and Exploitation: A suite (likely extensive) of sophisticated tools to identify useful end-user information from the likely very massive two database components.

8. Operations Center(s): An appropriate suite of displays and database exploitation tools to allow "mere humans" at all levels (e.g., operators to decision makers) to actually use the overwhelmingly large available raw data in a useful manner (remember the Vincennes!).

III: Schematic With "State of the Art"

Figure 1: Schematic Track Task with Current JSAF/JUO Realization.

This picture provides a crude, admittedly biased, description of the current "state of the art" within the JSAF/JUO/SLAMEM operations. The individual boxes represent components withinn the general Tracking Task decomposition of Section II. The shaded areas indicate portions of the high-level task objectives that are incorporated within the existing model at some reasonable level. Relevant observations are as follows:

1. Scenario simulation is done using the existing JSAF/RTI-s distributed simulation system.

2. The (largely) single-sensor tasks (sensing and tracking) are done using Toyon's existing capabilities, as implememnted in the SLAMEM package.

3. A clever solution to the Entity-to-Sensor viewing problem has been achieved by shifting lowest-level "Detectability/Visibility" computations from the sensors (conceptually logical) to the viewed entities (computationally feasible).

IV: High Level System Requirements

A simulation framework for the schematic task in Fig.(1) must satisfy a number of high-level requirements. Obvious entries on the list of "desired goodies" include:

1. Scalability: The simulation must extend and support increases in the complexity of the underlying scnario in at least two dimensions:
   1. Number of simulated entities.
   2. Fidelity/complexity of individual simulated entities.

   These are obvious requirements. Think of "TEL = Firestation" in training simulations after Gulf War I.

   Perhaps more importantly, the underlying system components (e.g., Single-Sensor tracking) must not impose constraints on the size/complexity of the simulation scenario.

2. Variable Fidelity: The overall simulation framework must support different fidelities of modeling for all the components within Fig.(1), depending on specific questions being addressed when exercising the simulation. A focal plane simulation of an IR sensor, for example, is generally not needed for typical JSAF/JUO applications, but it could be relevant when assessing system capabilies for interesting classes of barely-detectable dim targets.

3. Modularity and Data Exchange Interfaces: In the ideal end-state, individual components in Fig.(1) would be designed and implemented by area-specific subject matter experts. This road was travelled in ASCII - with the obvious lesson that "common language" for data exchanges between components is essential.

   A careful, object-oriented design for Fig.(1) provides a starting point, isolating ambiguities within the content of exchanged data objects. Object content will be a difficult/ongoing issue, as one would hope to avoid performance issues that arise when interface specifications become too general (think "HLA" here).

4. Support for Live Data Feeds: In an ideal system, the first two entries in the Section II list could be replaced (in part or in whole) by real data from real sensors viewing realtargets. This is, in fact, a strong additional argument in favor of the Variable Fidelity and Modularity requirements. For example, real space surveillance implies a real, non-spherical earth model - a "straightforward" though tedious complication (and cost) that can generally be ignored in higher level CONOPS investigations.

   Note that Live Data Feed considerations oppose additional conditions/requirements on any/all of the feedback paths (Sensor Tasking) in Fig.(1).

5. Extensibility: The overall simulation package must be responsive to changing end-user needs, meaning not only straightforward requirements like Variable Fidelity and Live Data, but more radical departures like unexpected "additional blobs" in Fig.(1) associated with novel CONOPS proposals.

   This is particularly important for the data management and operator interaction componets of the Section II outline. Indeed, it can be argued that a primary raison d'etre for the full simulation program lies precisely in the careful design and development of control mechanisms for fileded operations systems of the future. The simulation architecture/design must not preclude explorations of "the unknown".

6. Validation and Verification Support It is altogether too easy (and tempting) to construct a simulation that "looks good" without seriously/honestly asking which results are "real" and which are, in fact, merely simulation artifacts. The design of the overall system must support honest explorations (real-time and after the fact) of underlying cause-effect sequences within the simulation operations. It is not suffieient to say "Well, the machines didn't fall over and the screens looked OK".

   There are at least two requirements for V-and-V support:

   1. Adequate instrumentation and database support within individual components of Fig.(1).
   2. Monte Carlo capabilities.

   Concerning this last point, we contend that a more important input in high-level decisions ("what to field and how to use it") comes not from average behavior but from low probability (5%, 2%, ???) failure modes.

V: Getting From Here To There

The tentative proposal is phrased in terms of JSAF/SLAMEM/JUO as a convenient starting point. Similar development paths could be constructed using other large-scale simulation efforts as the launching point.

Phase 1: Refactorization Of Existing Simulation

This involves reformulating existing software in the more explicit object/data-exchange model of Fig.(1) and adapting/extending these components to support truly scalable (i.e., distributed) operations.

Phase 2: Incorporation Of New Components/Capabilities

Given tentative data object designs and communications procedures from Phase 1, this phase focuses on the unshaded areas of Fig.(1). Various models and even software for the Tasking, Fusion, and Assessment/Discrimination components exist throught the DoD simulation community. The challenge is to collect, adapt, and extend this components in line with all the high-level objectives of Section IV.

Phase 3: Working Backwards From The End Game.

The importance of end-user's need cannot be minimized! There is, unfortunately, a huge generic conflict in the simulation world between what the user really wants and what developers can deliver according to some schedule. This tendency must be reversed if the Data Management and Operational Component aspects of Section II are to have any real, long-term utility.

These phases are expanded a bit in the following subsections.

V.1: Phase 1

The essential "incremental development" products of Phase 1 are two-fold

1. Insights into and initial prototypes for the data objects required/assumed within the grand scheme of Fig.(1). At a minimum, the fundamental objects "Sensor Detection" and "Single-Sensor Track" need to be fleshed out within the usual competing goals of "specific, yet flexible". (This has been, in fact, a truly key step in the development of the SPET system for space/ground-based missle surveilance modeling at Aerospace).

   Put bluntly, the high-level "motherhood" of Section II and Fig.(1) is doomed without very careful considerations of the information that is to be transferred among the components. The importance of this step (and the likely slow path towards extensible solutions) should not be minimized!

2. Replacement of the existing, single-CPU Single-Sensor tracking components of the present software by explicitly scalable, parallelized versions. This is a key initial step in addressing the "Scalability" requirement of Section II. Incorporation of a prototype distributed tracker will, in particular, clarify a number of under-appreciated issues associated with data exchange mechanisms among the components of Fig.(1).

   In order to explore/demonstrate the "Modularity" and "Extensibility" issues of Section II, it is desirable that at least two distinct versions of the tracking component be developed. The likely candidates include:

   1. "Realistic:" Trackers based on some variant of realistic Track-Hit association algorithms (e.g., straightforward extensions of the associators used within SPET). This would provide a realistic component for use of "extended JSAF/SLAMEM" within ongoing JSAF studies, with the immediate benefit of removing/relaxing constraints on the size of the underlying simulation scenario.

   2. "Truth-Based (i.e., Cheating)" A second tracker sofware package will be developed with Track-Hit associations done according to the actual identities of the detected targets.

   It should be stressed that the "Truth-Tracker" provides more than a mere demonstration of "modularity". Implementation of this traker will provide additional insights into how "simulated reality" and "simulation perception" could/should be maintained within exchanged data objects. This is essential in order to support the Validation and Verification objectives of Section III.

It is intended/required that the products of Phase 1 be immediately applicable to mainstream JSAF applications. This is essential within the overall incremental development goals. Moreover, feedback from real operations as soon as possible is essential in ongoing validations and verifications (or, at least "plausibility demonstrations") of the high-level model of Fig.(1). Put differently, the sooner little nits are uncovered, the better the chance that they can, in fact, be eliminated.

V.2: Phase 2

Given, in particular, working models for data object and (distributed) data exchange from Phase 1, the primary objective for Phase 2 is the insertion of initial versions for the many unshaded components of Fig.(1).

As possible, the objects and associated algorithms could/should be based on existing procedures now in place throughout the DoD research community. In an ideal world, some prototype versions might again be constructed using C++ wrappers around existing chunks of software.

The essential new component of Phase 2 is actually the database. Existing models (e.g., those within JSAF/JUO-2004) simply do not scale to the problem size that is required for full exploitation of the Fig.(1) model. There are a number of essential database elements that would be explored in this phase:

1. Overall Structure: The "Database(s)" in Fig.(2) will clearly be distributed and hierarchical. Beyond this obvious motherhood, details are best left unspecified and instead discovered during the implementation process. There is a huge trade-space (efficiency, generality, long-term archives, yada, yada, yada ...) that needs to be explored.

2. Run-Time Configuration and Flexibility: The standard analyst suggestion ("Save everything. I'll sort it out later") is simply not tenable. Particularly as the size and fidelity of the underlying simulation is increased, the ability to limit saved data to some relevant subset of the available data is essential - an obvious concession to the practical realities of limited CPUs, storage, and bandwidth.

   It is essential that these issues drive the fundamental design and implementation of the architecture itself and not be "back-engineered" at some unspecified point down the road.

3. Validation and Verification Support: The database components of Fig.(1) are the obvious starting points for any realistic validation and verification, particularly for integrated operations of a multi-component realization of the general Fig.(1) model. Validation and Verification objectives impose a number of requirements on data that must be available for at least some set of possible run-time configurations. It is important that thed requirement be understood early on during database considerations.

V.3: Phase 3

The high-level thrust of this phase is really a "Top-Down" reassessment of the entire end-user needs within the schematic of Fig.(1). The relevant question is not so much "What new features can be provided?" but rather "What substantial components are needed to support the ultimate objectives of the decision maker?". Think "Fogel, the Elder" - early and often.

While considerable work on this general problem has been done within the DoD simulation community, it is often the case that the "eye candy" - the pretty displays - are the driving end products. This is not a useful perspective (again, remember the Vincennes!). The simulation system developed within Phase 1 and Phase 2 will be capable of providing an overwhelming array of "numbers", most of which have zero or even negative value to a poor human being stuck in front of a console.

The sub-tasks for Phase 3 are necessarily a bit ill-defined at this time - in large part since data utilization at this scale is truly in the realm of cutting-edge research. Likely central issues for this phase include:

1. Movement towards realistic, Top-Down requirements as a driver for simulation design and operations, with particular attention to automated support for flexible, realistic Measures of Performance (MOPs) and Measures of Effectiveness (MOEs).

2. Development of a suite of general, data exploitation "middle ware" to support user interpretation and exploitation of database contents. "Pattern Recognizers" of all types are clearly essential. At a minimum, the overall simulation architecture must not limit the types of knowledge extraction tools available to decision makers.

3. Human-intelligable, multi-resolution visualization of large databases.

4. Capabilities for Monte Carlo excursions (real-time "what if" studies) based on current perceived reality.

5. Overall system design that accounts for and accommodates "real time" constraints that result from the inherent conflict of user needs and limited computational resources.

The first item is a bit "cultural" - again think Larry Fogel - but is actually quite important. It is far too common to reduce high-level real requirements (keep nukes off Cleaveland) to simpler, artifical "equivalents" (e.g., velociy error of at most 2m/sec within some specified time after launch). The development of appropriate real MOPs is beyond the scope of this work. The point here is generality/flexibility. The constructed system must, in fact, support a wide range of very high-level MOPs and MOEs without imposing constraints on the nature of these measures. To do this, Phase 3 would include/require a significant "high level musings" component.

The remaining items on the Phase 3 task list are all active research areas, with ample opportunities for "take and adapt" incremental development within the contect of Fig.(1). The work already done within the general High Performance Computing arena (e.g., HEP/LHC, DigitalSky, TeraGrid, ...) can be leveraged for many of the high-level objectives on the Phase 3 task list.

VI: Some Supporting Documentation

Some of the items mentioned above are treated in a bit more detail in the following documements.

• Musings "Beyond Slamem
• General Discussions On "Variable Fidelity"
• More Detail On Possible Slamem Generalizations
• Overfiew/Issues within HEP/LHC Data Management