Not Applicable.
Not Applicable.
As is known in the art, deliberative decision-making often relies on a plan: a sequence of parameterized actions that lead from an initial state to a desired goal state. The plan breaks high-level goals into smaller goals that are more easily attained, and that together achieve the overall goal. However, producing a plan may have a limited benefit if the plan cannot be judged relative to other plans that achieve the same goals in other ways. In addition, planners that offer limited ability to alter plans may also have limited utility.
The present invention provides methods and apparatus to generate a plan having a series of discrete actions that enhances the ability of a user to understand and/or alter the plan. With this arrangement, a user can view the plan and easily add new constraints from which a modified plan can be efficiently generated. While the invention is primarily shown and described in conjunction with generating a plan in a military environment, it is understood that the invention is applicable to a variety of domains in which it is desirable to generate a plan having actions to achieve stated goals.
In one aspect of the invention, a planner module includes a planner to sequence a series of actions to achieve stated goals based upon domain and problem definition information provided by a user. Rationale information for the actions can be stored and later accessed by a user.
In another aspect of the invention, a method of generating a plan includes parsing goal and constraint information from a user, generating a plan having a sequence of actions, storing rationales for each of the actions, and presenting the plan to the user.
In a further aspect of the invention, a system includes a planner to generate a plan having a series of actions from constraints, a plan rationale database coupled to the planner to store rationale information for the actions, and a plan store database to store zero, one, or more plans. The system further includes a decision support system coupled to the planner via an interface. The decision support system receives constraint information from which the plan is generated. The system can also include a presentation module to present the plan to the user.
The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
In an exemplary embodiment, the system 100 includes a planner module 102 coupled to a plan store database 104 and a plan rationale database 106. An interface module 108 provides an interface between the planner and a decision support system (DSS) 110. A user provides input to the DSS 110 via an input module 112. The DSS also receives input from a domain and problem reader 114. The DSS provides information to a presentation module 116 for generating a display from which a user can see and understand the plan. The user can use an editor 118 to modify domain and problem definition files 120, which are input to the domain and problem reader 114. A current relevant situation module 122 provides information to the domain and problem reader 114, such as the state of dynamically changing variables.
In an exemplary embodiment shown in
The interface module 108 performs data and command translation between the planner and DSS modules 102, 110 and can also buffer/connect if the modules are on different machines. The presentation module 116 generates display information to enable the plan to be represented on the user's display device. As described more fully below, the presentation module 116 can include mechanisms for enabling a user to explore the plan and ask for rationale on decisions made by the planner module 102.
The input module 112 interprets user interactions with the display as commands to the DSS module 110. The DSS 110 may in turn cause the presentation module 116 to alter the display to obtain or present more information from the user. The domain and problem definition files 120 are communicated to the DSS 110 initially by means of the domain and problem reader module 114, which may employ a variety of ways to get the information. In one embodiment, the user edits definition files in a structured format, such as the PDDL 2.1 format currently in use by the International Planning Competitions.
Current relevant situation information 122 is the current state of dynamically changing variables, such as the locations of objects relevant to the plan, current levels of numeric resources such as fuel, etc. This can be provided by analysts, filtered by some automated or human agent and used to update the system tasking.
The planner module 102 can be implemented in a variety of configurations. Various functional partitions between hardware and software will be readily apparent to one of ordinary skill in the art.
The inventive planner 102 records a rationale for each decision in the planning process. In one embodiment, upon request, the planner 102 can access the rationale for selecting or not selecting certain actions to be used in certain places in the plan. As described further below, in the interest of efficiency, in an illustrative embodiment, the planner can construct its rationale on the fly in response to a query by removing the actions indicated in the query and recording the rationale used while the planner repairs that section of the plan. In one particular embodiment, the system can operate in a second, complementary mode, in which it enables a user to modify an existing plan. The user indicates to the DSS that a part of the plan is to be changed, such as the addition, deletion, or modification of an action or fact in the plan, as described more fully below.
It is understood that the planner 102 may be tightly integrated with the DSS 110 as a module, or may be loosely connected, such by a web service. Interfaces to achieve the desired configuration are well known in the art.
Processing will be described in
In block 212, the user modifies the plan, such as via the input module 112 or using the editor 118 to modify the domain and problem definition files 120, to create new constraints. In block 214, the DSS module 110 removes the affected parts of the plan, creating a “broken” plan, and sends the broken plan with the new constraints to be parsed in block 204 by the planner and by the DSS. The planner treats the elements of the broken plan as constraints, so that actions in the broken plan are not modified, or are changed as little as possible. The planner searches for a new solution in block 206 and the updated plan is displayed in block 210. Intermediate representations of the modified plan can be saved in block 208. The user then may again modify the plan in block 212 and so on.
In block 216, a user queries the DSS regarding a particular action. The planner retrieves the data for the plan in block 218 and extracts an answer to the user query in block 220. The answer is then displayed to the user in block 222, as described more fully below.
Referring now to
In an exemplary embodiment, actions in the plan are textually listed in a column 302 on the side of the map. A timeline 304 for the plan is shown as a scrollbar at the bottom of the map. When the user clicks on an action in the list on the left, the plan is displayed on the map up to the time of the indicated action, and preconditions for the actions are displayed in the list. The timeline is likewise updated to reflect that time.
It is understood that a wide variety of user interfaces are possible and readily apparent to one of ordinary skill in the art. Mechanisms other than the action list and timeline can be used to provide similar information without departing from the present invention.
In the illustrated plan, the entire company moves across the northern bridge, which is indicated on the map in terms of its component parts: BRIDGE_WEST, BRIDGE_SPAN, and BRIDGE_EAST. The user prefers, however, that unit mechplt_b1 moves across the smaller southern bridge, in a flanking maneuver.
Note that there may be many types of changes the user might want to make to the plan. Examples include changing the field of fire of a unit, changing the munition or effect, or changing the position of a unit at some point in the plan. In the illustrative example, the user changes a movement action; however, mechanisms can be used to change any parameters of any action.
In the inventive system embodiment, to make a change, the user scrolls back the displayed simulation of the plan to the time, shown as time unit 5, where the unit mechplt_b1 was crossing the bridge, as shown in
When the user modifies a plan, it is not expected that the user will modify every other detail of the plan to ensure it is still consistent. This tedious work is best left to the planner. One way to do this is simply to replan ‘from scratch,’ giving the planner the new constraints so the new plan will conform to the user's wishes. However, there are several reasons for finding the minimal affected region, and replanning only that instead. For example, many planners are stochastic, and may output a different plan every time they are run with the same inputs. Second, planning is so complex that most planners are rather slow, so it makes sense not to replan parts of the plan that haven't changed.
When the user modifies the plan, the DSS gives the plan to an iterative refinement planner for repair, for example. Iterative refinement planning is known to one of ordinary skill in the art. For example, a planner known as LPG is an iterative refinement planner that can repair a plan: Gerevini, A., Saetti, A., and Serina, I. (2003). Planning through Stochastic Local Search and Temporal Action Graphs in LPG. Journal of Artificial Intelligence Research, 20, 239-290, which is incorporated herein by reference. This feature is useful since it can generate a complete plan from a partial plan. A planner such as the LPG planner operates by repeatedly selecting a plan element to improve. Broken elements like an action missing a required precondition get top priority, and the planner tries to find a way to supply that precondition. For example, looking to
A mechanism for finding affected actions and removing them is set forth below. It is understood that alternative mechanisms will be readily apparent to one of ordinary skill in the art. As is well known in the art, a predicate is an assertion with unbound variables. When its variables are bound for a specific situation, it is called a fact, or a literal. An operator also has unbound variables; when the variables are bound for a specific situation, it is called an action. The process of binding the variables is called grounding.
The user's modifications include a set of facts F={fi} that are added, deleted, or changed. If the user modifies an action, then any change in a post-condition of that action is added to F.
For example, in this case, the decision support system would remove the following actions from the plan shown in the format below as time unit: (action) [time unit differential]:
The decision support system also transforms the domain and problem into a new domain. and problem instance that contains the added constraint that mechplt_b1 must travel through the location bank_w. Specifically, the following new operator and predicate are added to the previous problem description:
Furthermore, the following new goal is appended to the previous goals:
(visited mechplt_b1 bank_w)
This effectively constrains the planner to produce a plan where mechplt_b1 must visit the location bank_w. The planner is then tasked with the new problem and the user is presented with the resultant graphical display of the new plan.
Due to the new constraint, mechplt_b1 passes through the desired waypoint, taking the appropriate southern route. As shown in
It is understood that the procedure for adding a new constraint may be different for different types of planners. One skilled in the art will see ways to implement this in the particular type of planner they are using. As an example, this can be implemented in an iterative refinement planner, which uses a stochastic local search strategy. Without limitation, three illustrative cases are set forth below:
1. When the user changes an action, the DSS revises the current plan to change the action. It does not need to edit the problem or domain description. It should be noted that most planners pre-compile the problem and domain into an efficient, grounded form, and perform reachability analysis to speed up the search when the planning begins. For this reason, the VISITED action and predicate is added to the domain file for the original plan, in case it will be needed. The planner replans to try to fix the broken plan. One possibility is that when planning the original plan, the planner never considered that action before, and now the planner finds that the new action either improves or does not reduce the evaluation metric. In that case it will incorporate the new action as required. On the other hand, the planner may find it cannot incorporate the new action, because of conflicts with other actions or results in a lower evaluation metric. In that case the planner will return the best plan it can, and report the justification for ignoring the user's request.
2. The user could insist that the action be added to the plan, possibly after trying case 1 above and despite the planner's justification for not including it. In that case, the DSS can add a goal to perform that action (as it did with the VISITED predicate above), and the planner would replan. However, it is possible that the planner will end up changing other actions the user didn't intend to change, and in that case the new action may no longer have the same importance. The DSS presents the new plan to the user and the user can accept it as is, edit it further, or go back to the old plan.
3. The user may want to ask for the new action but this time, require the planner to “lock down” other actions to prevent the planner from eliminating or changing them through replanning. This activity can be accomplished by adding a goal for each action that should be locked, as in case 2. Different types of planners may have other ways of treating actions in the broken plan as constraints while replanning.
As noted above, planning and replanning will give more reliable results if the planner does its pre-processing and grounding of the domain and problem, and its reachability analysis, once before the first plan is created and subsequently reuses it.
Provided below are two alternate approaches to adding a goal using a mechanism like the example above of the VISITED predicate:
A. A “delta reachability analysis” would do reachability analysis on any additional actions that are needed to satisfy new goals, incrementally grounding those actions that the preprocessor might have previously pruned out while optimizing. Since only a few goals are involved, this analysis should be very fast relative to a full analysis.
B. The problem file given to the system for the original plan would include the assertion of each of the new modification predicates as goal for every possible position, every possible unit, etc. This approach would prevent the preprocessor from pruning these actions. The planner can simply turn off those goals (an easy bit operation). Since the inventive planner does a goal-oriented search, these extra actions don't slow down the computation unless they are specifically asserted in the goals—especially if the planner employs a backward search from the goals to the initial conditions. This means that any possible modification the user might choose to make is already pre-processed; the DSS just tells the planner to turn on whatever new constraints the user wants. Preprocessing is a relatively fast operation, e.g., less than a second for a moderately complex problem.
In another embodiment, a compromise solution that uses both A and B is used to create a new “anonymous” predicate X with no unbound variables. This predicate would not be included as a fact in the original problem, but rather added by the DSS “on the fly” when the user added a new constraint, and compiled using a delta reachability analysis process as in A. The preconditions of a new “anonymous” action Y are drawn from the user specifications, and X is added as Y's single postcondition. X would be a new predicate, which would be added to the problem goal list. The delta reachability analysis for this approach would be straightforward. A new uniquely named action and predicate pair are added for each user constraint.
Suppose a user wants to ensure that the specific elements satellite0, Star0, instrument0, and spectrograph6 are used in a domain concerning satellite resource allocation. Each of these is of a certain type (in the restricted computer science sense of the word). One can create a new domain with these additional types:
This is only one set of initial facts that can instantiate the types for anonymousAction1 and thus add the postcondition (and top-level goal) anonymousPredicate1: satellite0, Star0, instrument0, and spectrograph6—just as the user indicated.
Referring again to the example shown and described in conjunction with
Since the planner logically searches for a plan, its internal data structures can provide a rationale for why certain decisions were made during planning. It is understood that planners can employ different ways of representing this reasoning; some have internal representations that make it easier to extract meaningful rationale for the user than others. The predicate logic representation contains the logical relationships between plan elements, needed to explain the plan to the user. Take as an example the GraphPlan planner: A. Blum and M. Furst (1997). “Fast Planning Through Planning Graph Analysis”, Artificial Intelligence, 90:281-300, which is incorporated herein by reference. GraphPlan creates a “planning graph” as a by-product of the planning process. The planning graph includes actions and propositions (literals) even if mutually contradictory. A side effect of planning is marking the conflicts using “MUTEX” links. As known in the art, MUTEX refers to Mutual Exclusion, a conflict between an action and another action or fact, or between facts. Such a conflict can be caused by conflicting preconditions (e.g., one requires a fact to be true, another requires it to be false), conflicting postconditions, etc. Two such MUTEX'd actions cannot be performed at the same time.
Exemplary embodiments of the invention rely on extracting from such an internal planner representation the rationale for why certain actions were included in the plan instead of others. Other internal data that can be saved and used for rationale is the results of the heuristic the planner uses for estimating the cost of supporting an action and the distance to the goals if the action is chosen.
In one aspect of the invention noted above, the DSS can answer user questions about the plan, such as “Why was the action MOVE (UNIT1, A, B) chosen?”. If the planner was set up to exhaustively record the rationale for every decision it made while planning, the rationale for that question can be simply retrieved. But for efficiency, in an exemplary embodiment the approach is to recover only what is needed, by recreating the conditions under which the planner planned the action. That action is removed along with (possibly) any dependent actions to the end from the plan and replan, asking the planner to keep track of its reasoning. The data returned to the DSS will include each action considered at that time and why the action in question was finally selected. It is possible that a stochastic planner, as used in an exemplary embodiment, will choose a different action. In this case, the planner is configured so that it will definitely reconsider the action in question, and choose it unless some other action is found that provides a better evaluation. Any action judged to be inferior can be accompanied by an explanation, such as any MUTEX that caused it to be dropped, or simply that the evaluation function returned a lower evaluation value. For example, the user might notice that the planner had not considered MOVE(UNIT1, M, N), and could then ask “Why was MOVE (UNIT1, A, B) chosen instead of MOVE (UNIT1, M, N)?” The DSS would answer this question by removing MOVE (UNIT1, A, B) and all related actions from the plan, adding MOVE(UNIT1, M, N), and sending the broken plan back to the planner to be fixed. The user could then be shown both plans side by side along with metrics and other explanations.
One skilled in the art will appreciate further features and advantages of the invention based on the above-described embodiments. Accordingly, the invention is not to be limited by what has been particularly shown and described, except as indicated by the appended claims. All publications and references cited herein are expressly incorporated herein by reference in their entirety.