Final Technical Report
Download 0.55 Mb.
|
- Navigate this page:
- Constraint Managers and Critical Constraints
Example 2: I-P2I-X Process Panels are a more complex case than they may appear to be, because the panel is an agent carrying out the process represented by its list of activities, a planner developing that process, and a simulation engine determining when activities are ready to execute by comparing their preconditions against the known state of the world. These aspects all meet in the panel’s model manager; however, the planning and simulation aspects are relatively undeveloped and will not be described in any detail. Since a process panel is for the most part controlled by the user, most handlers to not directly or automatically handle issues or activities. Instead, they produce “handler actions” that are attached such items. These actions provide short descriptions of their function which are displayed in menus by the issue and activity viewers. It’s only when the user selects an action that anything actually happens. Since new actions may become possible (for instance when the panel discovers a new capability of another agent, so that an activity might be delegated to that agent when it couldn’t be before, or when the user defines a new way to expand an activity into subactivities), and existing actions may become impossible (as when the user deletes an expansion possibility), handlers must be able to revise the action lists in response to changing circumstances. In addition, many ways of handing - such as delegating to another agent - may apply to a wide range of issues and activities. It therefore makes no sense to have a simple mapping from verbs to handlers as in O-Plan. Instead, all handlers get a chance to look at items and decide what, if any, handler actions they want to provide. Nor are handler actions passive entities. They are able to determine whether they are still valid (or should be removed) and whether they are ready to be selected or are waiting for some condition to become true. When an action is selected by the user, it’s “handle” method is called. It may perform the action itself, or it may ask the issue or activity handler to do it. While those aspects of the system are more complex than in O-Plan, the model manager is at present much simpler. There is no constraint associator and no separate constraint managers; the model manager handles all of that itself. Moreover, the manager does not maintain multiple versions of the model and does have to support search and backtracking. Constraint Managers and Critical ConstraintsA constraint manager can return one of three results: yes, no, and maybe. A yes means that the constraint can be added; a no means that it cannot, because it would be inconsistent with one or more constraints already there. The maybe response is more complex. It essentially means that the constraint can be added, but certain other constraints must be added as well. Those additional constraints may not be a simple list; they may instead be a tree, with the planner required to find a path through the tree to a leaf, adding all the constraints it finds along the way. If an inconsistency is found, it must switch to another path. If it does find a viable path, the other paths that have not yet been tried must be saved in a backtracking “alternative” as described in the O-Plan section above. Since only issue handlers, not constraint managers, are allowed to create alternatives, any tree received from a constraint manager must be placed in an issue for later processing if the handler that received the tree cannot process it itself.) The operation of a constraint manager and the function of “critical constraints” will be described with the aid of an example. In O-Plan, one of the constraint managers handles a simple kind of resource constraint that has the syntax “use Suppose the constraint manager for “use” constraints were given the constraint C1: use drill from begin_of action_1 to end_of action_1 If that was its only constraint, it would return “yes”. Now suppose it then received C2: use bandsaw from begin_of action_2 to end_of action_2 That does not conflict with C1 and so also gets a “yes”. The next constraint might be C3 use drill from begin_of action_2 to end_of action_2 Now there is a potential conflict. There are two ways to resolve it. Either action_1 must end before action_2 begins, or action_2 must end before action_1 begins. The result is a “maybe” with a two-branch, one-level tree. Note how it is natural to express this conflict-resolving result in terms of temporal “before” constraints. Constraints that have this role are called “critical constraints”. Different types of synthesis tasks may have different types of critical constraints. Now consider the constraint C4: use ?tool from begin of action_3 to end_of action_3 This does not specify any particular tool, but in O-Plan variables have enumerated domains, and so the possible values of that variable are known. Presumably they include “drill” and “bandsaw”. Thus, there might be a conflict with any of the earlier constraints. If “before” constraints are the only sort of temporal constraint available, the tree for resolving such conflicts will be rather complex, because there must be a path for each different way of resolving all the conflicts, and for each conflict there two ways to resolve it with “before”. If, on the other hand, a “does not overlap” constraint is available, the tree can be simpler. There is also another way of resolving the conflicts: if ?tool has a value other than “drill”, it cannot conflict with C1 or C3; and if it has a value other than “bandsaw”, it cannot conflict with C2. This the second type of critical constraint for planning: constraints about the values of variables. Having more ways to resolve conflicts is good in some ways but bad in another, because it can make the trees in “maybe” responses larger. However, clever constraint managers can take steps to simplify the trees. For instance, some temporal constraints already in the model may eliminate some conflicts, perhaps even allowing a plain “yes” response. Or the constraint manager might notice that C2 and C3 are both about action_2, or that whatever value ?tool is given is bound to be different from one of drill or bandsaw. Directory: project -> documents project -> Terminal Decision Support Tool Systems Engineering Graduate Capstone Course Aiman Al Gingihy Danielle Murray Sara Ataya project -> Rajinder Sachar Committee project -> Cape Lookout National Seashore Historic Resource Study By project -> Cape Lookout National Seashore Historic Resource Study By project -> Chesterfield fire department response to severe storm emergencies executive analysis of fire department operations in emergency management project -> Revolutionizing Climate Modeling – Project Athena: a multi-Institutional, International Collaboration project -> What is a Hurricane? project -> Southampton Station History and Significance History Newtown Branch documents -> Atlantic Region Climate Change Conference Sept. 14 -16, 2010 documents -> Dense Traffic these documents, drawings and specifications are the property of roadeye flr general partnership, and shall not be reproduced or used without written permission from roadeye flr general partnership. RoadEye Download 0.55 Mb. Share with your friends:
|