next up previous
Next: 6.6 SUO Execution Monitoring Up: 6 Implementing Execution Monitors Previous: 6.4 SUO Alert Types


6.5 SUO Plans and Mission Model

Our hierarchical mission model specifies an ontology for the primitive actions, and has methods that encode most of the domain knowledge about constraints and expected behaviors. Tailoring monitoring to each mission is crucial because most behaviors, even something as simple as denoting the location of a unit, are mission specific. The plan representation is a novel combination of the mission model and an extended version of the Act formalism [46].1

The Act formalism is a domain-independent AI language for representing the kinds of knowledge about activity used by both plan generation and reactive execution systems. It provides a rich set of goal modalities for encoding activity, including notions of achievement, maintenance, testing, conclusion, and waiting. This expressiveness is necessary for representing SUO plans, which must coordinate distributed units, trigger preplanned contingencies, and enforce a variety of execution constraints. The basic unit of representation is an Act, which can be used to encode plans, strategies, and standard operating procedures (SOPs).

The EA can monitor any plan that is composed of missions from the mission model. The mission model is derived from Army field manuals and elaboration by domain experts. It includes a set of mission templates (with associated parameters) that units at various echelons could be ordered to perform, in either a written or verbal order. Since the mission model is grounded in field manuals, it is a first step toward formalizing a plan representation that is meaningful to end users yet amenable for execution monitoring and other AI-related capabilities (e.g., plan generation, replanning, course of action evaluation).

The mission model is a class hierarchy (implemented in LISP and CLOS, the Common Lisp Object System), with inherited methods that encode knowledge about how to monitor a particular mission. Each leaf class corresponds to a monitorable action that may occur in a plan; each nonleaf class encapsulates common parameters and behaviors for its subclasses. The mission model allows most aspects of system behavior to be tailored in a mission-specific manner. Thus, specialized methods in the mission model can, for example, use mission-specific algorithms for monitoring progress of a movement. Methods are invoked by the EA Manager but can in turn invoke processing in the EA Manager by posting mission-specific facts that invoke capabilities of the EA Manager (there is an API of such facts, important facts are described later).

Each mission in the model contains a name and parameters that describe the mission. For example, the mission model contains the nonleaf movement-mission class, which contains a destination parameter and a method for checking that the executing unit has arrived at its destination. Five different movement missions inherit this behavior. The root class in the model is the mission class, which encapsulates all parameters and behaviors that are shared by all missions. All missions inherit start-time and end-time scheduling constraints and methods from this superclass.

Coverage. The mission model formalizes a substantial subset of the missions mentioned in Army field manuals. We have enumerated 62 mission classes, and have implemented 37 of these, a superset of those required by our scenarios. The mission model covers multiple echelons, with emphasis on battalion, company, and platoon. It does not model all aspects of missions, only those for which SAIM can provide monitoring data, that is, those related to time and location. For example, it does not alert on potential mission failure due to casualties incurred.

Contingencies. The mission model contains the nonleaf contingent-mission class. This class and its leaf children classes are used to implement a mission sequence that is part of the plan but is to be executed only when certain conditions are fulfilled. Domain experts term these portions of the plan branches and sequels. The missions under contingent-mission contain parameters to describe the condition, specified in the plan, that activates the contingency.

Dynamic resubordination. Army operations orders allow the command hierarchy (termed the task organization) to be changed during the operation, although existing command and control software does not support dynamic changes to the command hierarchy. The reorganization-mission class provides this capability in the EA. When a reorganization mission is executed, it causes the EA to update its representation of the command hierarchy accordingly. This has a substantial effect on EA behavior, because many EA algorithms use the command hierarchy.

Methods. Each mission provides several methods that are invoked at appropriate times by the EA to monitor execution of the mission. This set of methods serves as an API for mission-specific execution monitoring semantics. The following methods comprise the bulk of the API:

Post-Execution-Constraints
is the main API method invoked by the EA for monitoring a mission. It invokes methods that post and enforce various constraints.
Check-Initial-Location, Check-Final-Location
confirm that unit(s) are positioned correctly at the start and end of their mission respectively.
Start-Time-Constraints, End-Time-Constraints
check that a mission is beginning and ending execution as scheduled. These methods usually post facts in the EA Manager to invoke its Timed Monitor mechanisms.
Location-Constraints
enforces location checking of friendly units and hostile tracks for a variety of missions.
Contingency-Satisfied
determines whether a contingent mission sequence should be executed.
Respond-To-Monitored-Red-Activity
is the algorithm for responding to hostile activity in places where the plan calls for monitoring such activity.
Execute-Mission
invokes any processing required to execute a mission. It is invoked by posting a goal in the SimFlex agent, and all internal agents continue PRS execution while Execute-Mission is running.
Compute-Priority
computes the priority of an alert.
Desired-Strength-Ratio
is a heuristic that expresses a desired friendly:hostile ratio of combat power.
Red-Alert-Priority
computes the priority of a proximity alert, or whether an alert should be issued at all, based on recent changes to reported strengths of a friendly unit and nearby hostile tracks.
Wait-Until-Mission-Start, Wait-Until-Mission-End
control interaction with the EA GUI with regard to mission start and end times.

Specialization of methods is useful for expressing desired behavior by the EA. For example, the Location-Constraints method is specialized on movement-mission, coordination-mission, and several other missions. For movement missions, the EA checks whether the centroid of the moving unit is at its destination. For coordination missions, the EA checks whether any elements of two coordinating units are at the specified coordination point.


next up previous
Next: 6.6 SUO Execution Monitoring Up: 6 Implementing Execution Monitors Previous: 6.4 SUO Alert Types
Pauline Berry 2003-03-18