The architecture of the EA and its interactions with the SAIM system are shown in Figure 3. We developed two major modules, the Planning Assistant (PA) and the Execution Assistant (EA), which assist the user in generating and executing plans, respectively. We implemented only a skeletal PA to produce machine-understandable plans, using the SIPE-2 hierarchical task network planner . Both the PA and EA use Acts and a common knowledge base, ontology, and mission model that is object-based and easily extended. Knowledge about actions is represented in the mission model, and knowledge of plans, strategies, and procedures is represented as Acts.
The inputs to the EA are plans to execute, location reports, sensor tracks, and messages from other agents (e.g., reporting mission success and failure, and ordering execution of new plans). SAIM broadcasts up-to-date locations of all friendly agents, and broadcasts tracks that represent the results of fusing sensor hits on nonfriendly entities. SAIM provides and the EA supports rates of more than a dozen such inputs per second.
The EA monitors the current mission for every immediate subordinate of the EA owner, and alerts on threats to subordinates (subordinate depth is customizable). If events threaten successful execution of the plan, threaten the user or subordinate units, or trigger planned contingencies, the EA issues an alert to the user, depending on the value of such an alert as determined by applying our VOA algorithms. The user must decide how to respond. Our design and technology can also suggest responses and/or plan modifications , but this was left for future work. In addition to giving alerts, the SUO EA can dynamically change the command hierarchy, abort execution of one plan and switch to monitoring a new plan, and reduce unwanted alerts to avoid inundating the user.
EAs for every unit at every echelon process reports and give alerts locally. SAIM provides the same tactical picture to all EAs (modulo an EA's registration in SAIM multicast groups). Therefore, it is not necessary for an EA to report a new threat to its superior, as the superior's EA (as well as the EA of other affected team members) has the same information and would already have issued a similar alert. This architecture is fault tolerant because EAs do not rely on reports from subordinates to determine most alerts. Thus, each EA maintains most of its functionality even if it is not in contact with other EAs, as long as it gets SAIM position reports from one node.
As shown in Figure 3, the EA is implemented as multiple asynchronous PRS agents (defined below) to alleviate the computational burden on the central EA Manager agent. Asynchronous agents provide faster response and better alerts than would a synchronous architecture, because the agents are always using the latest information available to them without having to wait to synchronize with other agents. To implement the EA, we extended PRS to monitor temporal constraints and to batch incoming facts so it could handle much higher data rates.
Internal EA agents (as opposed to external team members) use the Belief-Desire-Intention (BDI) model of agency . Each agent has beliefs about the state of the world, desires to be achieved, and intentions representing actions that the agent has adopted to achieve its desires. Each EA agent has its own controller process, which operates on its own database of beliefs, its own set of intentions, its own monitors, its own set of Acts that encode procedural knowledge about how to accomplish goals, and its own LISP functions that implement the primitive actions of the agent. An EA agent continually applies its Acts to accomplish its current intentions (tasks). The EA appears as a single agent to SAIM and the outside world. The following are the internal EA agents.
Plan Initializer. This agent gets a plan from the PA and sends messages to the EA Manager agent after performing all initializations necessary to begin monitoring of plan execution. Primarily, this involves creating and loading plan monitors, and posting facts in the EA Manager database.
Watchman. This agent monitors incoming message traffic on the SAIM network, mainly by querying for tracks and other information. It filters irrelevant or insignificantly changed reports, and sends a message to the EA Manager when any report or message requires its attention. It simultaneously monitors files of scripted events when such monitoring is requested. The Watchman inserts events from scripts at appropriate times, interleaving them with live messages.
EA Manager. This agent begins plan execution immediately after receiving a plan from the Plan Initializer. The agent implements the core EA functionality -- it compares reports from the Watchman agent to the plan and plan monitors, and generates high-value alerts.
SimFlex. This agent provides a powerful and flexible way to define the execution semantics of an action using Acts (and thus the full power of PRS). SimFlex (simulated, flexible execution) enables mission-specific execution monitoring (by having an Act for each mission) and makes the system easily extendible. For example, if certain missions were to automatically command robotic vehicles or send messages to other EAs, those actions could be easily implemented in SimFlex. Most of the actions in our plans are executed by external human agents, in which case this agent does little except perhaps prompt the user. Some actions, such as reorganizations, are automatically executed in SimFlex by invoking the Execute-Mission method defined in the mission model.