next up previous
Next: 6.7.1 Proximity alerts Up: 6 Implementing Execution Monitors Previous: 6.6.6 Other features and


6.7 Alert Detection and VOI/VOA

The central task of the EA is to notify the user of important changes to the situation that may demand attention. The EA must also avoid excessive alerting; otherwise, the user would abandon the EA as a nuisance. A model of the user's cognitive state with respect to awareness of threats would be ideal, but is unavailable. As described in Section 5, we developed algorithms that heuristically estimate VOI and VOA using domain knowledge. The inputs to these algorithms are described in Section 5.3. We avoid excessive alerts by issuing only high-VOA alerts. Our techniques include

The event histories are currently our only model of the user's cognitive state, except for global properties of the situation, such as operational tempo. Our VOA calculations take into account the frequency and timing of alerts that have already been given. The histories include all alerts that were issued to the object of the history, and may include additional events, as described in Section 7.4. We assume that the user is aware of information about which he or she has recently been alerted. The idea behind having alerts ``expire'' is that the user may have forgotten information provided too far in the past. Thus, the EA will not use alerts older than a specified threshold to reduce its estimate of the value of giving an alert now.

The EA's behavior must be easily customizable, both by users and by the plan, because users have different preferences and situations impose different requirements. The EA can be customized in many different ways. Our VOA algorithms, which recommend alerts and classify them by priority level, are controlled by thresholds and repetition parameters, which allow alerting behavior to be customized to the user or situation. Examples of customizable VOA parameters are the alert expiration periods described above (default 12 minutes) and alert suppression intervals (90 seconds for hostile alerts, 120 seconds for alerts about friendly team members) during which alerts of the same type about the same objects are suppressed for the given interval. In terms of VOA, another fratricide alert has no value for the first 120 seconds after the user has been alerted about a fratricide risk from the same team member.

Examples of customizable VOI parameters are the out-of-position distance threshold (150 m), thresholds on the strength of adversarial threats, and the time threshold for schedule alerts (30 seconds). The time threshold, for example, would be smaller for tightly coordinated operations, and larger for more loosely coordinated plans. In terms of VOI, detecting that a team member is late has no significant value until the tardiness reaches the given 30-second threshold. If certain missions in the plan change this threshold, say to 10 seconds, it indicates that information about tardiness of 10 to 30 seconds has more value in the context of these missions.

The problem of avoiding unnecessary repetition of similar alerts occurs with every type of alert. Schedule deviations can become progressively more off schedule, position deviations can become progressively more out of position, threats can move progressively closer or become progressively stronger, and fratricide threats can persist over time. An EA must avoid cascading alerts in each of these cases. In our framework, customizable thresholds are often paired with either customizable ratios or a customizable sequence of thresholds, which control how often to repeat the alert if the mission deviates progressively more from expectations. Repeated alerts generally have a lower VOA and are given lower priorities.

Our evaluation showed that two types of alerts in the SUO domain pose particular problems for avoiding inundation of the user. These are proximity alerts about adversarial activity and alerts about fratricide risks among team members. We developed VOI/VOA algorithms especially for these two types of alerts.



Subsections
next up previous
Next: 6.7.1 Proximity alerts Up: 6 Implementing Execution Monitors Previous: 6.6.6 Other features and
Pauline Berry 2003-03-18