For the monitoring in the MLAA, we have adapted our approach developed for plan and threat monitoring for small unit operations (SUO)[20]. The monitoring is accomplished by two PRS modules, the Watchman and the Manager (which is part of the MLAA process manager), each running asynchronously. The inputs to the Manager are plans to execute, policy declarations, status reports (including location, speed and orientation) from its own sensor suite, and messages from other agents. These messages include status reports of other agents, reports on mission success or failure, shared information, and requests for help.
The Watchman module monitors incoming message traffic. It filters irrelevant or insignificantly changed reports, and sends a message to the Manager when any report or message requires its attention. The Manager module, after receiving a plan, computes sentinels for the plan and begins plan execution. It compares reports from the Watchman module to the plan and sentinels, and generates high-value alerts without overwhelming the system with too many low-value alerts (a significant challenge). The Manager continually applies its Acts to respond to new goals and facts posted in its database. The Acts correspond to algorithms for monitoring requirements at each layer in the MLAA architecture. Some implement user alerts and others implement autonomous control.
Depending on communication conditions or policy restrictions, an agent may, or may not, receive from team members status reports (up-to-date locations) of all friendly agents and other entities within visual range. Sentinels are extracted from plans and policy declarations, are evaluated when status reports are received, and may produce alerts. The alerts produced are designed to serve both the autonomous control via the strategic planner, and the user, although the needs of each vary considerably.
Our initial monitoring implementation detects the following types of alerts. We plan to implement additional monitoring.
We use the techniques developed for the DARPA SUO program for estimating the value of alerts and reducing the number of low-value alerts. In particular, we keep report and alert histories for each team member being monitored. These histories are used to determine the value of information and alerts, and to detect Stuck, Divergent, and No-status alerts. The value of issuing an alert takes into consideration customizable parameters associated with both the automated agent and the user. Some of the agent parameters are customized to improve performance, while others are a function of the behavior of the robot.
An example of how monitoring is used to facilitate autonomous control is illustrated by the situation where an agent is patrolling a designated area. When an evader becomes visible, the agent receives a Target-visible alert. Reacting to either a high-priority preference to pursue evaders or an explicit plan step, the agent commits to a new goal Pursue named-evader. This goal is achieved by the activation and blending of three tasks: Follow named-evader, Relocate named-evader and Search-for named-evader. Thus, the robot will maintain pursuit even when the evader slips in and out of its field of vision.
The user's preferred strategy might be to report the first sighting of the evader or to track its position, noting whenever it disappears from view. However, the autonomous control requires notification only if the likelihood of recovering visual contact is deteriorating and the robot is searching aimlessly. At this point, a Target-Lost alert will be sent to the agent's Manager (and possibly the user). In this example, a policy exists for reacting to this type of alert. It will cause the pursuit goal to be dropped and the original Patrol plan to be resumed.
No-status alerts have proven useful to the human user, as they indicate a hardware or software problem on a robot or the network. Monitoring allows such problems to be recognized immediately. These problems took considerably longer to detect and diagnose before monitoring was implemented. At-goal, Stuck, and Divergent are essential alerts for the autonomous-control agent-navigation system, as well as being useful to a human user who wants to closely monitor the progress of a robot. Subtleties of the domain must be considered to avoid false alarms. For example, the robot may be paused because of GPS uncertainty and the GPS should be given time to establish connection with satellites. Also, a robot takes time to turn and thus should not be regarded as stuck or divergent until turns and steering adjustments have had time to complete.
Target-visible, Target-lost, and Handoff are useful to both the user and the autonomous controller, particularly when the task is to monitor or pursue a target. The autonomous controller requires immediate awareness of loss of sensor contact, so it can adjust its lower-level behavior or sensor parameters to find the evader. However, such immediate alerts would be unproductive for the human user or the plan-level controller, and alerting is controlled by a customizable interval. This interval gives the controller time to relocate the evader, possibly avoiding an alert. These types of alerts are the most time critical in our evaluation domain.