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:
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.