Using Mixed Initiative to Support Force Deployment and Execution
Alice M. Mulvehill
Michael T. Cox
BBN Technologies Cambridge MA 02138
Department of Computer Science and Engineering Wright State University Dayton, OH 45435-0001
[email protected]
[email protected]
Background The Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Lab (AFRL) cosponsor the DARPA/AFRL-Rome Planning Initiative (ARPI), which focuses academic research and studies into the area of military operational planning and scheduling to address tomorrow’s technology. One of ARPI’s Technology Integration Experiments has produced JADE (Joint Assistant for Deployment and Execution) a casebased force deployment planning system. JADE is an integration of ForMAT21 (a case-based force deployment planner developed by BBN Technologies); Prodigy/CBMIP2 (a combined case-based and generative planner developed by Carnegie Mellon University); and PARKA (a highly-indexed knowledge based management system developed by the University of Maryland). ForMAT2 [6, 7] is a case-based planning tool that supports military deployment planning through the acquisition of user-built deployment cases (plans), querydriven browsing of past plans, and functional analysis primitives for evaluating new plans. The Prodigy/CBMIP component of JADE is built on top of the Prodigy/Analogy case-based planner. It is a mixed-initiative version of the planner that has both domain-specific knowledge of the JADE scenario and task-specific processes that interface with the ForMAT2 force deployment planner. JADE demonstrates technology that enables a military planner to build a force deployment plan in less than one hour (the current method can take hours to days). The deployment plan identifies what forces will be used to support mission goals and specifies the time phasing of how military force elements will be deployed into the mission area (the Time Phased Force Deployment Data or TPFDD). 1 2
Force Management and Analysis Tool Case-Based Mixed-Initiative Planner
Providing for a Mixed-Initiative Environment JADE supports the user in the development of the force deployment plan through it's graphical interface, it's case indexing mechanisms, and through the plan generation and modification support that is provided to the user by Prodigy/CBMIP during plan development. Although a force deployment plan can be developed by experienced users with the ForMAT2 portion of JADE independently of the support that is provided by Prodigy/CBMIP, feedback from the user community to date indicates that users in general (both experienced and less experienced) find the suggestions provided by Prodigy/CBMIP to be useful. A force deployment planner is responsible for determining how to move the forces selected for use in a mission from where they currently are located to where they need to be in order to support the mission. The experienced planner will know how to determine where to deploy the forces and will also know how to provide the support structure necessary for enabling those forces. But, mistakes are made by even the most experienced planner. For example, a series of four letter geographical codes are used in specifying the geographical locations associated with force deployment. When the user incorrectly enters a geographical location code in the current operational environment, the error may remain until force deployment execution, where it is found by the person who is actually assigning the airlift to move the force. When there are hundreds or thousands of force deployment movements required to support a mission, the introduction of these types of errors tends to increase and their detection is much more difficult. In JADE there are two mechanisms available to support the user in the detection of an incorrect geographical code
assignment. One is a ForMAT2 report that identifies the geographical locations for a set of forces, however it is up to the user to determine whether these locations are correct or not. The other mechanism was developed during the ARPI technology integration experiment (TIE) between ForMAT2 and Prodigy/CBMIP. Prodigy/CBMIP inputs a stream of JADE user-actions provided by an internet interface agent called the Watchdog. From this stream it filters a subset of ForMAT2 commands and responds to those actions by providing as output two general types of advice to the user: retrieval suggestions and adaptation (modification) suggestions. This method uses data acquired during the automated planning process to check, guide, and modify force deployment planning.
change in guidance can result in another “save-goals” operation. This signals that the following “copy-fm” operations will probably be made into a plan that is already “partially” created. This introduces one of the mixedinitiative issues encountered during the TIE -- humans can typically be engaged in multiple activities in the course of a given day, and one or more of the activities can span over several days. The human can work on a problem on one day, seemingly forget about it for several days, then return to it at a later time…in other words the human user can work on multiple plans interchangeably and concurrently, weaving from goal to goal. For the system providing mixed initiative support, keeping track of the changes in the planning contexts and priorities of the human user becomes a major challenge.
The Technology Integration Experiment
Table 1 Prodigy/CBMIP to ForMAT2 Intercommunication Methodology
As a way to demonstrate the integration of ARPI technology, ForMAT2 and Prodigy/CBMIP were paired in a TIE where Prodigy/CBMIP would be used to support the ForMAT2 user in the detection and correction of problems as they were encountered during the development of a force deployment plan. In the TIE, the user interacts with ForMAT2 and Prodigy/CBMIP monitors this work and at particular times offers suggestions to the user for modifying the plan. A number of engineering problems were encountered during the TIE. First, in order to narrow the scope of the “type” of modification support Prodigy/CBMIP would provide to the ForMAT2 user, and in order to set up a “context” for providing this support, a set of triggers were defined. Table 1 lists some of the triggers that were used in the TIE. The triggers are associated with actions taken by the ForMAT2 user while a deployment plan is being developed or modified. For example, when a ForMAT2 user chooses to copy a force module (FM) from the casebase, a command called “copy-fm” is used. This same ForMAT2 command serves as a signal to Prodigy/CBMIP that some force module has been selected by the user and is being copied from the case repository into the new plan. Some of the contextual information about the force module being copied, (e.g., it's parent, the mission it was deployed to support, the goals it supported in it's original mission, and where it was deployed to in support of the previous mission) is also provided to Prodigy/CBMIP. Prodigy/CBMIP is also provided with any default information that the ForMAT2 user specifies for all forces in the new plan, such as the general geographical location of the new mission. Prodigy/CBMIP uses all of this state information in order to provide suggestions to the user (See Figure 4 for examples). Some triggers have a defined temporal sequence. For example, a ForMAT2 user will typically “save-goals” associated with some new mission guidance before they start to copy force modules (copy-fm) into the new plan. However, guidance can change from day to day and a
ForMAT2 Action
Trigger
Prodigy Suggestion
Specification of goals for a mission
:save-goal
Prodigy provides reminders that some FM be associated with each goal
Copy FM into a new plan
:copy-fm
Prodigy reminds the user that the geographical location for the new FM must match the geographical locations associated with the mission.
Save defaults for new Plan
:savedefaults
Prodigy uses this information to maintain mission consistency for all created or copied FMs in the new plan.
The current approach in JADE to this problem is to reduce the numbers of plans that a user can actively work on at any given time to one. In this way, all operations that a user takes are associated with the deployment plan that is being developed (is loaded). In addition, JADE provides mechanisms that incrementally collect data from ForMAT2, filter the data, and pass what is seemingly relevant data to Prodigy/CBMIP. At any time, Prodigy/CBMIP can request additional and/or specific information from ForMAT2.
Building the Force Deployment Plan Figure 1 is an example of the mission guidance that drives the initial development of a force deployment plan. In this figure, the guidance text can be annotated with colors (not shown) when the user selects the "analyze" button. Colors highlight terms that ForMAT2 has in it's casebase. The user can then click on colored items in the guidance to form mission goals. In this example, the user builds a goal to "send security police" and to "suppress terrorism".
Figure 1. Commander’s Guidance from the Web Planner When a series of goal statements are created, like those listed at the bottom of Figure 1, the user can select the "dump analysis" option to pass this information on to another window called the Goal Editor window (Figure 2). The goal editor was initially built to enable a user to compose a series of queries about mission tasks/goals and possibly specify the force preference and desired location. In the example in Figure 2, the only known information is the name of the goals, therefore a query is executed against the casebase to find force modules from previous plans that supported both or one of these goals.
Figure 2. Goal editor The results of the queries are posted to the main window, which is displayed in Figure 3. On the left side of the screen is a list of "retrieved force modules". The user
can easily construct a new deployment plan, such as NEWPL, and populate it with forces by selecting a force module from the list of retrieved force modules and dragging that force module into the new plan or directly onto a geographical map location, using the map that is in the right of Figure 3. When the user copies a force module from the retrieved force module list into the new plan, Prodigy/CBMIP will check to make sure that the selected location is related to the geographical location as specified by the mission statement or in any default mission values. An example of Prodigy Suggestions is provided in Figure 4. Here there is a "reminder" that the geographical locations associated with force deployment need to be filled with geographical location codes that in or near Bosnia-and Herzegovina. This information was derived from initial default mission data provided by the user for use in all of the force modules of the newly developing deployment plan. The user can accept, reject, ignore, or postpone suggestions from Prodigy/CBMIP. In this example, the user accepts a suggestion to set several parameters of a force module to be in or near Bosnia-and-Herzegovina. When the user accepts a suggestion and selects the "execute" button, ForMAT2 will attempt to perform the suggestion and will place the "accepted" suggestion in a "accepted Prodigy Suggestions" list. Tracking what suggestions the user does on his/her own is still an unresolved issue in the system. In some cases, data that Prodigy/CBMIP receives from ForMAT2 allows Prodigy/CBMIP to remove a suggestion that has already been satisfied into the "accepted" list. However, much of this suggestion selection remains in the hands of the user.
Future Directions While the casebase and user interface of JADE work together to support military planners in the creation or modification of force deployment plans there are many issues that are still unsolved. For example, the more interesting type of force module modification occurs when the current situation is similar to a past situation, but the intensity of the current situation is “less than” or “more than” the previous situation. In this case, the human planner will need to “increase” force support or “decrease” it. For example, in a previous situation, 24 squadrons of aircraft may have been deployed to support a combat mission, but in the new situation, there is only the requirement for a show of force --- which will require less aircraft. Or, the situation may be very similar, but the geographical situation warrants that a different type of force deploy. For example, in a previous situation, a naval unit may have been combined with an army unit to satisfy the mission, but in a new situation, there may be no water available to warrant a naval force, therefore the naval force will need to be removed and some other force, e.g., Marines provided. Prodigy/CBMIP has some ability to make force substitution suggestions, but only when there is sufficient domain knowledge available.
Figure 3. JADE interface
Figure 4. Prodigy/CBMIP suggestion window
The Prodigy Suggestion Window is often viewed as “checklist” by users. As the user selects items from the list, they are moved from the “new” list onto one of the other lists which the user can view at leisure. However, not all suggestions from Prodigy/CBMIP should be taken, and we have not sufficiently investigated how to handle those suggestions that the experienced user chooses to reject. Using this type of feedback to enable Prodigy/CBMIP to improve on the types of suggestions it provides is part of our current research. Another challenge area is associated with goal/sub-goal decomposition, or task/sub-task decomposition because a “goal” in one context can become one of many sub-goals in another context. Furthermore, because force deployment plans are oriented toward supporting the “deployment” of the forces, there can be many forces that combine to support any given goal. The forces for two somewhat “unrelated” goals can be deployed at the same time and to the same location. In the deployment arena, these forces are only sharing the deployment carrier and route. Furthermore, because of the structure of certain forces, some forces associated with a goal (A) will need to be deployed a month ahead of time so that they can be assembled, while other forces associated with goal (A) will be deployed one day before they are needed because they are deployed “combat ready”. To date, we have not addressed how we might represent and reason about such concepts in Prodigy. Currently it is up to the experience of the user to handle these issues. Prodigy/CBMIP reasons about goals while the operational user build plans that contain specified, implied, and essential tasks. The mapping from goals and sub-goals to implied, specified and essential tasks is a challenge because the category of a task changes as a function of it’s context. Finally, in our demonstration of the JADE system, Prodigy/CBMIP has been well received because it provides suggestions for modifications that need to be made but that are sometimes overlooked because of the magnitude of some deployment plans. However we are actively in the process of determining methods that can be used by the ForMAT2 user to train Prodigy/CBMIP about new force element and about new goals.
Conclusion JADE is currently being modified to operate within a distributed client-server environment where information will be available from multiple sources to the force deployment planner. The easy to use map-oriented drag and drop interface enables the user to drag a force composition from the library directly to the location that the force is intended to be deployed to. The Prodigy/CBMIP system is running in the background and is used in JADE to provide suggestions to the users about
previous plans that might be useful in quickly responding to a new mission and reminders to the users about how to modify the developing plan so that it is consistent with the context of the new mission. In this environment Prodigy/CBMIP has the potential of receiving state information from many systems other than JADE. How this data is used by the user during force deployment planning is yet to be determined.
Acknowledgements This research is partially supported by the Dayton Area Graduate Studies Institute (DAGSI) under grant #HEWSU-99-09, by the Information Technology Research Institute, and by Wright State University.
Bibliography
Hendler, J. and Mulvehill, A. "High Performance Support for Case-Based Planning Applications" Israeli Conference on Artificial Intelligence, Tel Aviv, Israel, Jan. 1996. Mulvehill, Alice M., "Building, Remembering, and Revising Force Deployment Plans", Advanced Planning Technology - Technological Achievements of the ARPA, Rome Laboratory Planning Initiative Abstract, AAAI Press, May 1996. Mulvehill, Alice M., "Reusing Force Deployment Plans", AAAI 1995 Fall Symposium on Adaptation of Knowledge for Reuse, MIT, Cambridge Mass, November 10 - 12, 1995. Rager, Dave, Hendler James, and Mulvehill Alice M.; "ForMAT2 and Parka: A Technology Integration Experiment and Beyond", Case Based Reasoning Conference Proceedings, Providence RI, 1997. Veloso, M. M, Mulvehill, Alice M., Cox, Michael; "Rationale-Supported Mixed-Initiative Case-Based Planning", IAAI Conference Proceedings, August 1997. Veloso, M. 1992. Learning by Analogical Reasoning and General Problem Solving. PhD thesis, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA, August 1992. Technical Report CMU-CS92-174.
