Thomas Russ

Andre Valente

We describe the interface to a knowledge-based system for aiding Air Campaign Planning. An early part of this process involves the decomposition of high level objectives into more specific sub-objectives. We constructed a Strategy Development Assistant (SDA) which assists the user in this decomposition process. The SDA is a knowledge-based system, whose knowledge base was initially based on a theory of air warfare. The SDA provides suggested decompositions based on the current situation and high-level goals.

The interface we present is used to support military planners in an early phase of air campaign planning. The choice of decompositions is template-driven, based on a set of underlying assumptions. The interface details the assumptions, allows the user to modify the values of the assumptions and thus captures the assumptions underlying the plan. The SDA is a truly mixed-initiative planning system. All elements of the interface design are geared towards giving the user total control of the decisions taken in the decomposition process.

Knowledge-based interface, planning, explanation.

Air Campaign Plans are plans prepared by the US Military that describe the conduct of an air campaign: what objectives are going to be achieved, when, and how. These plans are represented as a hierarchy of objectives. Top-level strategic objectives are recursively decomposed into several layers of lower-level objectives, until each objective is associated with a specific aircraft flying one mission. Developing an air campaign plan is a complex task, in which several factors have to be weighed and many decisions have to be made. However, users are wary of automating the whole process, for example by using a generative planner such as SIPE [1]. Military planners feel they need to have control over each element of the plan and the planning process, and understand in detail the rationale for each objective decomposition. For this reason, mixed-initiative systems that keep the human "in the loop" seem to be the best option to provide computerized support to the planning process.

As part of DARPA-sponsored initiative in air campaign planning, we implemented a knowledge-based system for aiding in the decomposition of planning objectives. Our Strategy Development Assistant (SDA) proposes one or more decompositions for a user-selected objective. The SDA uses a library of decomposition templates derived from a theory of air campaign planning provided by an expert in the field. SDA aids users in making the necessary decisions in customizing these decompositions by examining situation information from available databases (see Figure 1). The SDA is implemented using Loom, a knowledge representation and reasoning system developed at ISI [2]. It works as an assistant that is invoked from a Java-based Air Campaign Plan Editor. The idea is that users should be free to plan with or without the SDA, as they prefer. This architecture also highlights the role of the SDA as an assistant, not a full planner.

Figure 1. SDA Software Architecture

The main goal of the SDA was to accelerate the pace of planning by providing sets of suggested decompositions. In this way we avoid the "blank sheet of paper" syndrome by providing guidance. The system can also speed up the planning process. For example, in emergency situations the user may prefer to provide minimal input and let the SDA decompose several levels of objectives in the plan, making all modifications in the end. Another important benefit is that the library of templates can be controlled to reflect best practices, as well as enabling the creation of a "permanent memory" by allowing planners to store interesting templates that can be used by other planners tomorrow. In this way, the SDA can be used to improve the quality of the plans produced.

The SDA works as follows (See Figure 1):

1. A planner (user) selects an existing objective in the plan, and requests the help of the SDA in decomposing it. The SDA then searches in its knowledge base for templates that are able to decompose the objective at hand. The templates are selected on the basis of their relevance to the current plan, and the current strategic situation. This information is obtained from several databases that contain situation-specific information that changes from one campaign to another.
2. The SDA shows the user all objective decompositions provided by the templates found. The user selects one of the proposed decompositions for further work. The user can come back to this point later and reselect any other decomposition.
3. Once a template has been selected, it is customized to better fit the specific problem facing the planner. In the customization process, the planner generally needs to add or remove objectives in the decomposition proposed. The key to this customization process (and the most important aspect in the system and interface design) is the use of assumptions to explain the rationale behind each sub-objective and help the user decide whether to keep or not keep the sub-objective. We will provide further detail on this in the rest of the paper.
4. When the user is satisfied with the customized decomposition, the system adds the new objectives to the current plan, and returns control to the plan editor. At this point, the user is again able to modify any part of the new objectives.

One of the important features of SDA that adds intelligence to the process is how it keeps track of the assumptions behind objectives added to the plan even after the addition has been made. For example, if the situation changes and it seems like one of the objectives that was omitted should now be included, the SDA can warn the user and recommend the decision be revised. If the new situation indicates one of the current objectives doesn’t make sense any longer, SDA can recommend its removal.

The customization provides a lot of the power of the system, but also poses a problem–how to communicate the information to the user in a way that is clear and succinct. In the remainder of this paper, we present our solution to this problem and describe some of the design principles behind the SDA interface.

The SDA is part of a larger mixed-initiative planner. Our design philosophy is to provide as much information as possible in a clear, succinct manner; provide suggested alternatives for the plan; and leave the user in ultimate control. We also wanted the interface to encourage the use of direct interaction, since that makes it easier to operate without extensive training.

The SDA interface shows the assumptions that underpin its recommendations. This allows the user to see why particular sub-objectives were included or not. An example is shown in Figure 2. Looking at the window, the user can see that the first objective ("defend SLOCs [Sea Lines of Communication] of Blue against enemy attack") is included because the enemy has the ability to damage these kinds of targets. The fourth objective ("Defend SLOCs of Blue against enemy sea attack") is not included because the enemy does not have any naval forces in range. Note that the system was able to evaluate whether these assumptions are true or not by importing information from databases and reasoning about the meaning of these assumptions using the SDA knowledge base and inference engine.

Figure 2. SDA Editor Interface.

Although the SDA has access to information about the situation, we wanted the user to be in control. Aside from the general desirability of this from a user-interaction standpoint, it was critical for this application, since we were not so arrogant as to imagine that we would always be able to get the right answer. There is nothing more frustrating for a user than to not be able to fix problems in the computer’s output.

Our task was complicated because there were two levels at which we allowed user interaction with the interface: Users could modify the value of the assumptions underlying the planning and have the effects propagate through to the recommendations. Users could also directly override the recommendations. The former course of action allows the system to be more useful as a whole, because it identifies the assumptions under which the user is changing the system output.

The identification of these assumption changes provides a hook for other parts of the system to monitor the resulting plan. If later information becomes available which indicates that the assumptions the user made in adding information to the plan was wrong, the system has a record of that dependency. The decision in question can be revisited. This ability to monitor more of the background of the plan

In designing the interface, there were a few particular challenges that we needed to address in order to produce a good, functional interface.

The first task was to show the user the recommended objectives for inclusion. Because we allow user overrides, we wanted the recommendation to be displayed as a distinct interface element from the actual choice of whether the objective was included or not. Since inclusion was a binary decision, the obvious element to use was a checkbox. We then chose to use a similar element to indicate the recommendation, since that provides a strong visual link between the two elements. We chose to use a check mark outside a box. This provided a visual link between the two checks, but by not having the box around the recommendation, the active element was differentiated from the system-controlled element.

Since this is a mixed-initiative system, either the SDA or the user could be ultimately responsible for a particular objective being in the plan or not. We needed a way to convey the information about "who made the decision" in an intuitive and compact way.

That is because (at different times) either the system or the user can control whether a particular objective should be included. In automatic mode, the recommendation and the state of the objective will always be the same, in other words the two interface elements are linked. In manual mode, the recommendation can still change, but the actual inclusion is under the control of the user rather than the system. In other words the recommendation indicator and the inclusion checkbox are not linked.

Our first design for indicating that the recommendation and the objective inclusion box were coupled was to use a graphic element (called a drawbridge) that either showed a connection () or no connection (). This design (see Figure 3) was compact and very clever, but was finally judged to be too obscure.

Figure 3. Mockup Indicating Control with a Drawbridge.

We sadly had to abandon the drawbridge. We replaced it with a pop-up menu that indicates the choice between automatic and manual control. (Figure 4). Although less compact, the extra clarity was deemed worth the cost in screen real estate. With the control on "Automatic", the system has control of the inclusion box and can change it if the user changes the values of the underlying assumptions.

Figure 4. Mockup Indicating Control with Menus.

In "Manual", the user has full control over the inclusion box. The recommendation may change, but the check box can only be modified by user interaction. By continuing to display the recommendation, it is clear at a glance where the user has made a different choice than the system would recommend.

To make the system work reasonable well, we needed to link the controls. For example, if the user wishes to override the system recommendation, a click in the inclusion checkbox will change the value of the checkbox. It will also shift the control from automatic to manual.

If the user wants to return control to the system, then automatic can be selected in the pop-up menu. The system then gains control of the inclusion checkbox and will immediately set the inclusion value to be the same as the recommendation.

The control linkage was done in order to make direct manipulation of the interface elements possible, and to minimize both the number of gestures demanded of the user, and to eliminate the need to go through a more involved procedure with error feedback.

In this paper we presented the Strategy Development Assistant, a mixed-initiative knowledge-based planning system for helping users develop air campaign plans. Some of the main features of the system are its use of assumptions to keep track of the rationale behind the decisions proposed by the system and ultimately made by the user. The interface of the SDA is able to dynamically adjust its contents to a particular situation. This required a flexible front-end. The contents are defined at run-time using the contents of the knowledge base as well as situation-specific information By understanding why each element is present, the SDA can provide intelligent support to the users’ decisions, while leaving them control over the final word over what is decided.

The research presented in this paper was funded by DARPA for the JFACC Program, under contract F30602-97-C-0068. The JOUST theory that populated the SDA library of templates was provided by Aegis Research; many thanks to John Thomas ([email protected]) for all the help. The Java interface was programmed by one of our graduate students, Dan Delsol.