Situation Assessment

Requirements Summary

The Situation Assessment (SA) module, like the Systems Status module, underwent significant change to its contribution to the operation of the PA.  In the early stages, it we seen as a grab bag of technologies being thrown at an enormous problem.  Once scoped down to the essentials, however, it became a dynamic front-end to the operation of the rest of the PA. The SA module was responsible for:

• receiving "raw" sensor input data,
• adding value to the raw data by inference from other available knowledge,
• interpreting that data in terms of the mission of this aircraft and the members of its flight,
• maintaining a stable, dynamic view of the external world, 
• responding to specific requests for information, and
• ensuring that the planning and PVI modules were aware of the current situation.  

Phase 1 Implementation

The SA module implementation evolved dramatically during the development of the Phase 1 system.  Initially, it was perceived as a massive data filter using both a Reasoning with Uncertainty Methodology (RUM), and Truth Maintenance to maintain a global tracks data base, and then to respond to specific information requests from the other major subsystems.  The RUM machinery required the use of a commercial, Prolog-based inference system called KEE (Knowledge Engineering Environment).  However, by the 6th prototype, the appropriate rules had been codified and implemented as a set of forward-chaining rules using ART from Inference Corporation.

While the implementation was migrating, the PA system architecture was also evolving.  The PGG approach and the emphasis on maintaining the health of plans by using monitors radically impacted the SA implementation.  Rather than passively responding to queries, the processing model was to receive static requests to detect events of interest in the environment.  For example, the following might by typical requests:

• report all new air objects (in order to establish basic tracking plans),
• report if a hostile aircraft comes within a given range,
• report if a hostile aircraft turns towards us, or
• report if a hostile aircraft is destroyed (to remove plans and monitors associated with that track)

These static requests, of course, changed slowly over time as the planners drove plan instances through their plan life cycles. The need for unsolicited data streams also emerged for dealing with, for example, incoming air-to-air missiles or any hostile threat on our target list.  This enabled the tactics planner to continually refine its response or attack plans without having to request data updates.

Tool migration continued as the SA design matured.  The tracks and monitors databases and the associated attributes, originally implemented in  KEE specific structures were re-written in Lisp, hence facilitating the migration to ART.  As the design matured further, the ART rules were stabilized and re-written in Lisp, so that by the end of Phase 1, the system wasa written entireloy in raw Lisp, free of any commercial inference products, and ready for the transition to real-time operation.

Phase 2 Implementation

In Phase 2, the SA subsystem was recoded in C++.  Its responsibility remained unchanged from the conclusion of Phase 1.  However, the scope of the system knowledge to support the more realistic combat environment of Phase 2 increased the size of the SA knowledge base.  

last updated 1/26/2003 by David Smith