Embed Size (px)
Citation preview
Reducing the Representational Distance Between Application DomainExperts and AI Planning Technology: a compilation approach
Peter JarvisArtificial Intelligence Applications Institute
The University of Edinburgh80 South Bridge, Edinburgh, EH1 1HN, UK
Graham WinstanleySchool of Computing and Mathematical Sciences
The University of BrightonLewes Road, Brighton, BN2 4G J, UK
Abstract
We present a compilation-based approach to reducingthe representational distance between application do-main experts and AI planning technology. The ap-proach combines a representation designed to matchthe structure of human expertise in the constructionindustry with an established planning technique. Thedesign of this representation is derived from a studycarried out with experts in the industry. This studyshows that expertise in the industry is centred on thecomponents of a building and organised into a subcom-ponent structure. We demonstrate by encoding the re-sults of this study into a HTN formalism that such for-malisms fragment expert knowledge. This fragmenta-tion leads to a large representational distance betweenexpert and formalism, making the task of encoding andmaintaining a planner knowledge base a complex one.Our solution is to provide a representation designedaround the modelling requirements of the constructionindustry and then to compile HTN schemata from thatrepresentation. We argue that this union reduces therepresentational distance between expert and formal-ism, thus lowering the complexity of the knowledgeencoding and maintenance tasks, whilst still exploit-ing powerful AI planning techniques. We concludeby proposing further investigations of this type withthe aim of providing a library of domain-oriented for-malisms from which a knowledge engineer may choosean appropriate representation for a given domain.
Introduction
Knowledge engineering issues must be addressed if AIplanning technologies are to move successfully from thelaboratory to the "real world" [Chien 1996]. Signifi-cant progress has been made in this area over recentyears. Planning methods, for example, have been cat-egorised within a framework appropriate for guidingknowledge engineers [Valente 1995, de Barros et al 1996,Benjamins et al. 1996, Kingston et al. 1996] and toolsupport for verifying and debugging planner knowledgebases is emerging [Chien 1996].
In this paper, we address the issue of the representa-tional distance between the application domain knowl-edge and planner formalism. Our approach is centredupon the compilation of a Hierarchical Task Network
(HTN) planner [Tate 1977] formalism from a represen-tation designed to match the structure of human ex-pertise in the construction industry. We argue thatcurrent HTN formalisms, like previous planner methodcharacterisations (e.g. [Kambhampati 1995]), are moreoriented to the needs of the technology than the knowl-edge engineer. By providing a representation designedaround the structure of human expertise, the represen-tational distance that must be negotiated by the knowl-edge engineer is reduced.
Our motivation and approach are described in a num-ber of stages. First, the results of a study that exam-ined the structure of expertise in the construction in-dustry are presented. The difficulties encountered whenmapping the results of this study to HTN formalismsare then described. Second, we outline our Dynam-ically Assessed and Reasoned Task (DART) Networkapproach to the compilation of HTN schemata from aformalism designed around the expertise structure iden-tified in the study. Finally, we discuss the contributionof our approach and suggest how it may be combinedwith related work to form a promising research direc-tion for addressing knowledge engineering issues in AIplanning.
Modelling Requirements of theConstruction Industry
The modelling requirements presented in this sectionwere derived from a knowledge elicitation and mod-elling process performed in the construction industryover twelve months. This process included meetingswith experts and observations at construction sites.It was driven and conceptualised with the support ofthe KADS methodology [Schreiber et al. 1993]. Wealso drew on previous case studies carried out at TheUniversity of Brighton, UK and the Center for Inte-grated Facility Engineering (CIFE) at Stanford Univer-sity, USA. These studies examined the human expertiseapplied during the planning of flight simulator construc-tion [Marshall 1988, Winstanley et al. 1990] and theorganisation of construction plans around work areas[Winstanley and Hoshi 1993].
The modelling requirements derived from this workare presented below in the stages: action modelling, and
14
From: AAAI Technical Report WS-98-03. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.
dependency modelling. These requirements are thenplaced into the context of the construction planningprocess through a KADS application model.
Action ModellingIn the construction industry, expert knowledge aboutactions is organised around the components of build-ings. Actions are defined by their relationship withthese components. It is from this observation that wedefine an activity as the union of an object and an ac-tion. Consider the example in Figure 1. The activ-ity Set Out Position (of a) Beam is the union of theclasses BEAM and SET-OUT-POSITION, where classBEAM is a subclass (triangle notation) of the class OB-JECT, and class SET-OUT-POSITION is a subclass ofthe class ACTION.
Must Association ]Object InferAssoclation Action ]
II
I ~ J
.........................................................................................................................................................................................
} Beam Set Out Position !
! ’ ..........................................’ ............Activity .................’ .....................................i......!
Figure 1: An Activity Defined as the Union of an Objectand an Action
Experts use two types of relationship to associate ac-tions with an object. The Must association means thatan action must always exist as a result of its relatedobject’s presence. An Infer association means that in-ference is required to determine if an action is required.Figure 1 includes a graphical representation of the Inferrelationship. The criteria for determining if a particu-lar action should be associated with an object is repre-sented by an Inference Package. The package evaluatesto either yes (the action should be associated) or no(the action should not be associated).
To support reasoning at different levels of abstrac-tion, experts organise objects into a structure of com-ponents and subcomponents. An example of this or-ganisation is shown in Figure 2. In this figure, theclass BUILDING has the subcomponents (diamond no-tation) class FOUNDATIONSthrough to class PLANT.Class FOUNDATIONS is further decomposed into theclass BEAM. An expert reasoning at the level of theFOUNDATIONS would expect decisions made at thislevel to also affect all the subcomponents of the FOUN-DA TIONS.
The subcomponent relationship between objects in-troduces two types of relationship between actions andobjects. Every component always has an Abstract Ac-tion associated with it (i.e. abstract actions always ofthe association type must). Abstract actions map tothe different levels at which experts reason. When con-sidering a building at the foundations level, an expert
Figure 2: Subcomponent Structure with Abstract andPrimitive Actions
may place the constraint that the foundations must belaid before the drains. This constraint is placed on theabstract LAYaction of class FOUNDATIONS, but it isto be followed by all the actions of the FOUNDATIONSsubcomponents. Primitive Actions are only associatedwith components that do not have subcomponents andthey correspond to the actions that will appear in thefinal construction plan for a building. Primitive actionsmay be related to components through both the Mustand Infer relationship types.
Dependency Modelling
Like action knowledge, expert knowledge about depen-dency is organised around components. Figure 3 showsthe relationship Under existing between the classesBEAM and DRAIN. The semantics are that an in-stance of class DRAIN will pass under an instanceof class BEAM. Thus, the actions that lay the drainmust be completed before work commences on thebeam. This relationship can be expressed by placingthe temporal ordering constraint Drain.abstract-action< Beam.abstract-action, where "<" means before.
A~k~n Bm ~ Dr~nAm~k~
) ) L:.( "-" i o=-=o- " ==lFigure 3: Temporal Dependency Causing RelationshipBetween Components
Dependency relationships are typed as eitherDependency-Must or Dependency-Infer. The semanticsare similar to the Must and Infer directives that occurbetween objects and actions. In the Dependency-Mustcase, an ordering constraint must always be placed be-tween the abstract actions of the components joinedby this directive. In the Dependency-Infer case, infer-ence is required to determine if a constraint is required.There are, for example, occasions when a beam mustbe laid before a drain. This occurs when the equip-
15
ment used to lay a beam will damage the drain if itis already in place. The inference attached to this re-lationship is responsible for determining if an orderingconstraint is required.
Application Context
Figure 4 uses a KADS application model [Schreiberet al. 1993] to show the context of the constructionplanning process. The Component Knowledge inputdescribes the set of components that may exist in abuilding together with their action and dependency as-sessment knowledge. This is the knowledge described insections 2.1 and 2.2. Component knowledge is presentlylocated within engineers’ experiences, component man-uals, and regulation documents.
The Building Design input is the design of a specificbuilding. A design is a combination of components.It specifies the components in a specific building, theirrelationships, and the values of their properties. Thebuilding design input is currently represented in theform of design diagrams.
Component Knowledge
_~ .~ Construction PlanBuilding Design
Figure 4: KADS Application Model of the ConstructionPlanning Process
The Construction Planning process maps the build-ing design to the component knowledge to generate theactual actions and dependency constraints required ina plan. The result of this reasoning is output as a Con-struction Plan.
Previous Applications of HTNTechniques in the Construction Industry
This section determines the extent to which past appli-cations of HTN techniques in the construction industryhave addressed the requirements established in Section2.
The construction industry has been used in the formof Tate’s House Building Domain [Tate 1976] to demon-stration the capabilities of HTN planning systems sincethe technique’s inception, e.g. [Tate 1977] and [Kartamet al. 1991]. A portion of the domain specification pro-duced for the O-Plan system [Currie and Tare 1991] inthe system’s Task Formalism [Tate et al. 1994] is shownin Figure 5.
In Tate’s House Building domain, planning is initi-ated by the user specifying that the task build houseis to be planned. The planner searches its library ofpossible activities (listed in part in Figure 5) to find method for achieving this initial task. Figure 5 con-tains only one suitable method, schema build. With amethod identified, the planner follows the constraints
encoded in that method by constructing a plan con-taining four actions; one for each of the nodes in schemabuild. These actions are constrained in accordance withthe orderings and conditions statements in the schema.
The actions inserted into the plan from schema buildare all non-primitives. That is, each is at a higher levelof abstraction than the planner is required to reach.The planner therefore searches for methods that achieveeach of these non-primitive actions. In the case of theaction lay brickwork, the schema brickwork will be se-lected. This process continues until the plan containsonly primitive actions. For a complete description ofHTN planning, see [Erol 1995] or [Jarvis 1997].
Planning problems in the construction industry re-quire the capability to reason at different levels ofabstraction. The encoding of Tate’s House Buildingdemonstrates that HTN planners have this capability.This observation confirms Drummond’s [1994] thesisthat it is this capability that has enabled the indus-trial success of HTN technology. Knoblock [1996] alsonotes that HTN techniques underpin almost all indus-trial applications of planning technology.
schema buUd;expands {build house};nodes 1 action {excavate and pour footers},
2 action {pour concrete foundations},3 action {erect frame and roof},4 action {lay brickwork},
ordedngs 1 --> 2, 2 --> 3, 3 --> 4;conditions supervised {footers poured}at 2 from [1],
supervised {foundations laid}at 3 from [2],supervised {frame and roof erected}at 4 from [3];
end_schema;
schema bdckwod<;expands {lay brickwork};
end_schema;
Figure 5: Task Formalism Representation of Tate’sHouse Building Domain
The representation of Tate’s House Building Do-main does not meet the application requirements ofthe construction industry specified in Section 2.3. Tosupport construction planning, a representation mustdistinguish between the generic component knowledgeand a specific design. The planner’s task is to applythe generic component knowledge to a specific design.Tate’s House Building Domain does not make this dis-tinction. Instead, it encodes a specific design inter-twined with the knowledge relevant to the componentsin that design. Such a representation would be of lim-ited commercial utility in the construction industry. Inorder to plan a different design, a new encoding wouldhave to be produced.
The following sections consider the issues encoun-tered when attempting to provide an encoding of theconstruction industry that meets the application andrepresentational requirements defined in Section 2.
16
Mapping the Modelling Requirements
of the Construction Industry to HTN
Representational Devices
The section provides a HTN encoding designed to meetthe modelling requirements of the construction indus-try and draws conclusions about the suitability of thetechnique in this domain. It is the conclusions drawnfrom this analysis that motivate our DART-Networkapproach defined in Section 5.
Encoding Action Knowledge
This section outlines an encoding of the action knowl-edge identified in Section 2.1 in two stages. The firstconsiders the issues surrounding objects, the subcom-ponent relationship, and abstract actions. The secondconsiders primitive actions.
Figure 6 shows a HTN encoding of the building de-sign and component knowledge inputs to the construc-tion planning process. The building design input, at thetop of the figure, states the components in a building,how they are related, and the values of their attributes.When writing the component knowledge input shown inthe second part of the figure, the first issue is the provi-sion of schema that will refine the top-level task of anydesign. Within the construction domain, all top-leveltask specifications will be of the form build ?Building.Class BUILDING is the highest level component in thesense that all other components are subcomponents ofit, and it is not the subcomponent of any other compo-nent. We term the highest level component in a designas being the Project component. Schema build in Fig-ure 6 will refine the initial task, build ?Building. Theschema contains a node corresponding to the object -action pairing of all possible subcomponents of classBUILDING. From the building design specification inthe example, class FOUNDATIONS is the only possi-ble subcomponent of a building. Hence, schema buildcontains one node.
The second issue to consider is the provision of aschema that refines the action lay ?FOUNDATIONSthat will be generated by schema build to include thesubcomponents of class FOUNDATIONS. The onlysubcomponent of this class in Figure 6 is the classBEAM. Looking back at Figure 2, the subcomponentrelationship between the classes BEAM and FO UNDA-TIONS is not as simple as that between the classesBUILDING and FOUNDATIONS. In this case, the re-lationship contains a multiplicity ball (black circle no-tation) at the beam end of the relationship. The ballnotation indicates that any number of instances of classBEAM may be associated with a single instance of classFOUNDATIONS. The encoding of this second transfor-mation is shown in the lay_foundations schema withinFigure 6. To account for the multiplicity of the re-lationship, the Task Formalism’s foreach construct isused. This construct will generate a lay ?BEAM ac-tion for each instance of class BEAM associated withan instance of class FO UNDA TIONS.
;;; Building Instance Specification;;; as the Building Design Input to the;;; Construction Planning Process
supermarket: Buildingthe-foundations: FOUNDATIONSbeam1, beam2, beam3: BEAM
sub.supermarket = {the-foundations}sub.the-foundations = {beam1, beam2, beam3}
formwork.beaml = {custom}formwork.beam2 = {prefabricated}
;;; Component Knowledge;;; input to the Construction Planning Process
schema build;expands {build ?BUILDING};nodes 1 action {lay ?FOUNDATIONS},
end_schema;
schema lay_foundations;expands {lay ?FOUNDATIONS};nodes N foreach action {lay ?BEAM} for ?BEAM over
set of Beams related as sub components of?FOUNDATIONS;
end_schema;
Figure 6: Encoding of the Component Knowledge andBuilding Design Inputs to the Planning Process in aHTN Formalism
The encoding scheme described above is formalisedinto a set of guidelines in Figure 7.
1. For each component C that may have subcompononts,write a schema with the name "C.abstract-actlonC.component-name"
2. For each possible subcomponont SC of C write ¯ nodestatement within that schema of the form "SC.abstract-actJonSC.component-name"
3. If the cardlnality between C and SC is not 1:1, use ̄ foreachstatement to generate the correct number of’SC.abstract-actlonSC.compoenent-name" actions.
Figure 7: Guidelines for Translating a SubcomponentHierarchy into a HTN Formalism
The second stage of the encoding process must ad-dress the primitive actions that are associated withcomponents at the bottom of the subcomponent hier-archy, accounting for the infer and must relationshiptypes. We define the components at the bottom of thehierarchy as primitive components because they do nothave subcomponents.
Each combination of primitive actions that can beused to construct a primitive component can be viewedas a possible construction method for that component.With this definition, each construction method can bemapped to a HTN formalism as a schema, and the con-ditions under which each method should be applied ex-
17
pressed as only_use_if filter conditions. The top part ofFigure 8 sketches the semantics of this encoding for themethods that may be used to accomplish the task oflaying a beam. Each of the methods contains a numberof primitive actions. If condition is equal to vl, then theactions in method-a should be used to accomplish thetask of laying the beam. Otherwise, method-b shouldbe used.
Semantics:to aCcomplish task of laying a beam
if condition -- vl thenuse method-a
elseuse method-b
end if
Encoding:schema method-a
only-use-if condition = vl ;;; if condition
end:schema;
schema method-bonly_use_if condition i--v1 ;;; negation of the if condition for the else method
end-schema;
Figure 8: Semantics and Template for the Translationfrom Construction Methods to HTN Schemata
When encoding if-then-else structures, HTN filterconditions require the redundant specification of thecondition under which the else branch should be ex-ercised. In a HTN system, if the constraint condition= vl is placed on method-a, then that method cannotbe used if this constraint does not hold. However, be-cause of the way HTN planners operate, method-b mayalso be selected if condition = vl. For the semanticsof the if-then-else structure to correctly hold, the do-main writer must add the negation of the if conditioninto method-b. The lower part of Figure 8 provides atemplate for encoding of if-then-else structures into anHTN formalism.
Encoding Dependency Knowledge
Figure 9 shows two classes related through the Supportrelationship. The implication of this relationship is thatthe actions relating to class PILE must be performedbefore those of class BEAM, as the PILE supports theBEAM. Following the encoding guidelines in Section 4.1will produce a schema lay-foundations that will includethe nodes lay ?beam and drive ?pile. The Support de-pendency constraint may be expressed as an orderingconstraint between these two nodes. This encoding isalso shown in Figure 9.
The translation of the component structure shown inFigure 9 to the schema in that figure was possible be-cause both components are subcomponents of the samecomponent, class FOUNDATIONS. We term this situa-tion as two classes sharing the same immediate parent.Figure 10 presents a case where two related componentsdo not share the same immediate parent. When compo-
Foundations
?I I
Beamt-~
Pile
schema lay_foundationsexpands {lay ?FOUNDATIONS}nodes 1 action {lay ?beam},
2 action {lay ?pile};orderings 2->1;
end_schema;
Figure 9: Dependency Encoding Example, SameParentage Case
nents share the same immediate parent, actions relatingto those components will be reside in the same schema.Hence, it is possible to place an ordering condition be-tween them. In the example in Figure 9, however, theactions for class BEAM will reside in the schema lay-foundations and the actions for class DRAINAGE inthe schema lay-drainage. The encapsulation unit of theschema in HTN planning prohibits the placement ofconstraints directly between schemata. To specify anordering constraint outside the encapsulation unit of aschema, the domain writer may specify a condition forthe planning system to achieve. This encoding is shownin the bottom part of Figure 10.
Bundlng
I I
Foundations I Ddsnage
schema lay_drain;expands {lay ?drain }nodes 1 action {pdmitive-lay ?drain};only_use for effects
{stata_of drain) = laid at 1;end_schema;
schema lay_beam;expands {lay ?BEAM }nodes 1 action {primitive-lay ?BEAM};conditions unsupervised {stata of drain} = laid at 1;
end_schema;
Figure 10: Dependency Encoding Example, DifferentParentage Case
The encoding in Figure 10 distributes the dependency
18
knowledge between the schemata and requires the plan-ning system to establish a condition that can be com-pletely specified by the domain knowledge available.
HTN Encoding Conclusion
Encoding the construction domain within a HTN for-malism is a non-trivial task. A critical contributionto this complexity is that HTN formalisms force theknowledge engineer to think in terms of the planningtechnology rather than the application domain. For ex-ample, the engineer must identify schema refinementas the appropriate HTN mapping of the domain’s sub-component relationship. When encoding dependencyknowledge, the engineer must identify the relationshipbetween the HTN schema unit of encapsulation, themapping of the subcomponent relationship to schemata,and the resulting immediate parentage issue as the fac-tors that determine how dependency is encoded.
An important secondary effect of this translation isthe masking of a schema’s rationale. Providing knowl-edge engineers with the rationale behind an encodingis essential to the efficient maintenance of a knowledgebase. Without this information, it is difficult for theknowledge engineer to identify how the elements in aknowledge base are related, and therefore which aspectsneed to be updated to reflect changes in the applicationdomain.
DART-Network Approach
The architecture of our Dynamically Assessed and Rea-soned Task (DART)-Network approach is shown in Fig-ure 11. In existing systems, the domain writer mustencode a domain within the Library of Possible Ac-tivities using a formalism akin to the Task Formalism[Tate et al. 1994]. Section 4 identified the difficultiesinvolved in mapping the construction domain to for-malisms of this type. The DART-Network approachregards the Library of Possible Activities as the resultof a compilation process. The innovation is that thecompilation process takes as its input a representationthat maps closely to the domain under consideration.Using a domain-oriented formalism simplifies both theencoding and maintenance tasks. By then compiling adomain representation in a Library of Possible Activi-ties, the powerful techniques developed by AI planningresearch may be deployed.
Existing RepmsentaUonal DevicesDART RepresentaUonal Devices (e.g. Task Formalism, etc.)
I DART-DomainSpeclflcatl°n I [ Ubrary of Possible ]Activites (noCUrrent Plan Statelssues unresolved)
Figure 11: DART-Network Architecture
The following sections outline the DART representa-
tional devices and the stages in the compilation process.For a description of the standard HTN planning com-ponent of the architecture, see [Kingston et al. 1996].
DART- Network Representational Devices
The DART-Network representational devices are cen-tred on the pattern derived from the modelling require-ments of the construction industry that is shown in Fig-ure 12. The domain writers task is to specialise this pat-tern to capture knowledge in an application domain. Asthe template is designed to matches the structure hu-man expertise, this encoding process is simplified.
I Model ]
Supplied Dependency Reis6onships |Under ~ f ’Enclosed-By I I IM,de-ln,ccecslble~y
~.
Object ~"~ Action
?, T ~__T ? TSub component ,Sub oompon*nt Sub ~n.ooe~nt
Figure 12: DART-Network Representational Pattern
Class MODEL is abstract and will therefore never beinstantiated. The class assigns all other classes that areused to model a domain as being of type MODEL. Itspurpose is to permit operators to be written that workover an entire model.
The abstract class OBJECT defines the relationshipabstract action that is common to all classes that maybe used to model the objects within a domain. Ob-jects may be related to other objects through a set ofrelationships that determine the temporal ordering con-straints between actions. The pattern includes a set ofpredefined relationships that the modeller may extendwhen tailoring the pattern to an application domain.
The pattern accounts for the different types of ob-ject that were identified in the construction domain.Classes PROJECT, COMPOSITE-OBJECT, PRIMI-TIVE OBJECT, and ACTION may be refined by thedomain writer. Class PROJECT makes explicit a spe-cial type of class within a DART-Network domain rep-resentation. This class may not be the subcomponentof any other class, and is used to represent the overallproblem. It the construction domain examples earlier,class BUILDING is of this type. Class COMPOSITE-OBJECT may be decomposed into other instances ofclass COMPOSITE-OBJECT and class PRIMITIVE-OBJECT through the subcomponent relationship. In-stances of class PRIMITIVE-OBJECT can not havesubcomponents but unlike the classes PROJECT andCOMPOSITE-OBJECT, they must be associated withprimitive actions.
The representation of action and dependency knowl-edge is described within the action synthesis and de-pendency synthesis stages in the following sections.
19
Action Synthesis
The stages within DART-Network Compilation processare shown in Figure 13.The action synthesis stage de-scribed in this section takes a DART problem specifi-cation, reasons with that specification, and returns theoriginal specification augmented with actions. This sec-tion describes the specification of actions and the actionsynthesis process.
DART-Donmln8pedtlcation
Library of PolmibleActlviUes
Figure 13:" DART-Network Compilation Process
In the case of abstract-actions, the domain writermust specify the name of the action class to be asso-ciated with each refinement of the class OBJECT. Theaction synthesis algorithm generates a new instance ofthis action and adds it in the source object’s abstract-action attribute. For the primitive-actions, the domainwriter must specify the action class and the directivethat is to be is used to determine when each actionshould be associated with each primitive object.
Class BEAMabstract-action = must(a, lay)pdmltive-acUon = must(a, test)
infer(a, set-out-position,DETERMINE-SET-OUT-POSITION)
Figure 14: Encoding of class BEAM’s Actions
The encoding of class BEAM is shown in Figure 14.In the case of the action set-out-position, inference isrequired to determine if the action should be associ-ated. The infer directive includes the name of theinference package that must be invoked to performthis evaluation. An outline of the inference packageDETERMINE-SET-OUT-POSITION is shown in Fig-ure 15. The package will return true if the action shouldbe associated, and false otherwise. This modelling ap-proach meets the requirements of the construction do-main set out in Figure 1.
The task of the action synthesis algorithm definedin Figure 16 is to visit each instance of a class derivedfrom class OBJECT and instantiate the actions definedby the domain writer.
Dependency SynthesisThe dependency synthesis process, shown in context inFigure 13, takes the problem specification augmented
Inference Package DETERMINE-SET-OUT-POSITIONgoal (Known-Value (SET-OUT-POSITON))backward chain
Rule1 cost 0if cdterJa holds then
SET-OUT-POSITON = Trueend rule1
Rule2 cost 0if cdtefla holds then
SET-OUT-POSITON = Falseend rule2
Figure 15: Example Inference Package
Generate-actionsFor Each object O in a design
Create (O, abstract-action)if O is a primitive-objectCreate (O, primitive-actions)
end ifend Generate-actions
Figure 16: Action Synthesis Algorithm
with actions and adds the dependency constraints be-tween them.
The domain writer must provide a determine depen-dency method for each refinementof the classes PROJECT, COMPOSITE-OBJECT, andPRIMITIVE-OBJECT. Figure 17 shows the determinedependency method for the class BEAM. A set of di-rectives are supplied akin to those for action synthesis.The infer-abstract-action directive will cause the ab-stract actions of all the instances related to an instanceof class BEAM through a support relationship to be con-strained as occurring before the class’ abstract action.This constraint will only be placed if the DETERMINE-SUPPORT-DEPENDENCY directive returns true.
Class BEAMabstract-action = must(a, lay)pdmitive~action = must(a, te=t)
infer(a, set-out-posUon,DETERMINE-SET-OUT-POSITION)
Determine DependencyInfer-abstract-action(support,DETERMINE-SUPPORT-DEPENDENCY)
Figure 17: Class BEAM’s Determine DependencyMethod
The dependency synthesis algorithm visits each in-stance that is refinement of class OBJECT in a model,and invokes their determine dependency methods. Thisalgorithm is outlined in Figure 18.
2O
Determine DependencyFor each 0 that is a refinement of class OBJECT
invoke O.determtne-dependencyEnd
End
Figure 18: Dependency Synthesis Algorithm
Schema Compilation
The schema compilation process, shown in context inFigure 13, takes the problem specification augmentedwith actions and dependency constraints and compilesthe Library of Possible Activities input to the HTNplanning process.
Figure 19 shows an example input to the compilationprocess. Dependency constraints are ignored for themoment for clarity. The compilation process navigatesthe instantiated model, generating the HTN schematathat are required to describe the construction of eachcomponent. The algorithm works in three stages: taskdefinition, project and composite component definition,and primitive component definition. Each stage is out-lined before the overall algorithm is presented.
Abstract iI Action [
I Lay2 ~ the-Foundations ]
Abstract (~
[L.. 1Primitive
J[SetOutPosi~onltActi°n
J A°s"°’Acti°"Iso.=a o,]?
task build-supermarket;nodes 1 action {build1 supermarket};
end_task;
schema build-supermarket;expands{build1 supermarket};nodes 1 action {lay2 the-foundations},
2...;end_schema;
schema lay2-foundations;expands{lay2 the-foundations};nodes 1 action {lay3 beam1};
end_schema;
schema lay3-beamlexpands{lay3 beam1}nodes1 primitive {set-out-pos beam1};
end_schema;
Figure 20: Compiled Task Definition and Schemata
applied to the component the-foundations, is also showin Figure 20.
With in-stances of the class PRIMITIVE-COMPONENT, thecompilation process generates a schema with a node foreach of the primitive actions attached these instances.The schema generated for the instance Beam1 is shownin Figure 20.
The complete compilation algorithm is shown in Fig-ure 21.
Figure 19: Instance Model with Action Synthesis Com-pleted
The definition of the task the HTN planner isto achieve is derived from the union of a model’sPROJECT class and that class’ abstract action. Fig-ure 20 shows the install task definition that will be com-piled from the example in Figure 19.
With the HTN task compilation completed, thecompilation process generates the schemata that de-scribe the construction of each instance of the classCOMPOSITE-OBJECT. The process starts with thesingle instance of class PROJECT in a model and thengenerates a schema that refines the initial task defini-tion. The schema is generated by including the unionof each subcomponent of the project instance and theabstract actions associated with them. In the case ofthe Supermarket component, the schema generated willinclude the union of each subcomponent and the ab-stract actions associated with those components. Thecompleted build supermarket schema is shown in Fig-ure 20. The results produced when the same process is
schema-compilation (p : PROJECT)/* Task Definition *1create a new schema s with the name "p,"-",p.abstmct-action"insert node into s "p.abstrect-actlon," ",p)
/* Schema Compilation *1for each component c in a model that is either p or subcomponent of pif c Is of type composite or project thencreate a new schema s with the name "c.abstrect-actlon,"-",c"for each subcomponent so of c
insert node into s "sc.abstract-ection," ",sc"end for each
else ;;; c is of type pdmiflvecreate a new schema s with the name "c.abstract-acUon,’-",c"for each primitive action pa of o
insert node into s "pa," ",c"end for each
end ifend for
end schema-compilation
Figure 21: DART-Network Compilation Algorithm
Dependency constraints are handled in one of twoways. Ordering constraints between two componentsthat share the same immediate parents are specified inthe schema compiled for their parent as an ordering
21
constraint. This encoding matches that shown in Fig-ure 9. The handling of constraints between componentsthat do not share the same parent requires a modifica-tion to the HTN planning process in order to relax theencapsulation unit of a schema. Ordering constraintsof this type are recorded in the schemata generatedfor each of the participating components. In the de-pendent schema, a known-dependent ?node constraintis placed, where the ?node parameter is instantiated tothe name of the action object pair on which the actionis dependent. In the producing schema, the constraintprovides-condition-for ?node is placed, where the ?nodeparameter is instantiated to the name of the action ob-ject pair which is dependent upon this action. Figure 22shows an example of these constraints. In the example,drain1 passes under beam~, hence the drain must belaid before the beam.
schema lay-drain1;expands {lay drain1 };nodes1 action {primitive-lay1 drain1 };conditions provides- condition-for primitive-lay2 beam4 at 1
end_schema;
schema lay-beam4;expands {lay beam4};nodes 1 action {primitive-lay2 beam4};conditions known-dependent primitive-lay1 drain1 at 1
end_schema;
Figure 22: Example known-dependent and provides-condition Pair
The HTN planning process is modified so that whenit encounters a node with a provides-condition-for ora known-dependent constraint it first examines its planto see if the other side of the pair is present. If it is,the planner adds an ordering constraint between thetwo nodes and proceeds as normal. If the other sideof the pair is not present, it suspends the processing ofthe node until the other half is inserted into the plan.When the other half of the pair is included in the plan,the planner adds an ordering constraint between thetwo nodes and marks the suspended pair as ready forfurther refinement.
Implementation StatusThe DART-Network approach has been implemented inIntellicorp’s KAPPA-PC and applied to constructionproblems containing in the order of 200 components.The knowledge representation and the plans producedhave been evaluated and verified by domain experts[Jarvis 1997].
Discussion
We have presented a compilation-based approach thatcombines a formalism designed to match the structureof human expertise in the construction industry withan established planning technique. This union reduces
the representational distance between a knowledge en-gineer or domain expert and the planning formalism,thus lowering the complexity of the knowledge encodingand maintenance tasks, whilst still exploiting powerfulAI planning techniques.
Other approaches to the knowledge engineering issuecentre upon the development of a framework for de-scribing planning methods in a format that accountsfor the requirements of a knowledge engineer. Whenviewed in isolation, the contribution of this character-isation framework is a clear understanding of planningmethods in terms of the types of knowledge about aproblem they must be provided with. Whilst this un-derstanding will assist in the mapping of expert knowl-edge to planning methods, the knowledge engineer muststill encode domain knowledge within representationsthat, as is demonstrated in this paper, fragment do-main knowledge. When viewed in partnership withthe DART-Network approach, a potentially more prof-itable research direction emerges. We view the DART-Network architecture as a demonstration of conceptthat is intended to motivate further research. By ex-amining other domains, a library of representations de-signed to match the modelling requirements of knowl-edge engineers could be constructed. From such a li-brary, it will be possible to identify emergent represen-tations that are applicable to a number of domains. Ifthese domain oriented representations are then mappedto the planning methods through a compilation ap-proach, the resultant architecture would provide a gen-eral approach to reducing the representational distancebetween domain expert and planner formalisms. Thus,reducing the complexity of the knowledge encoding andmaintenance tasks.
This paper refines our initial ideas published in[Jarvis and Winstanley 1996a, 1996b]. Complete de-tails of the case study, encoding issues with HTN for-malisms, and the compilation process are available overthe web in [Jarvis 1997]. Our experiences with theTask Formalism Method obtained whilst encoding con-struction problems in the Task Formalism are reported[Jarvis and Winstanley 1998], whilst the impact of theseconclusions on the development of the Task FormalismMethod are reported in [Tate et al. 1998].
References
de Barros, L., Valente, A., and Benjamins, R. 1996.Modelling Planning Tasks. In Proceedings of TheThird International Conference on Artificial Intelli-gence Planning Systems, ll-18, Edinburgh UK: AAAIPress, ISBN 0-929280-97-0.
Benjamins, R., de Barros, L,. and Valente, A. 1996.Constructing Planners Through Problem Solving Meth-ods. In Proceedings of the lOth Knowledge Acquisitionfor Knowledge-Based Systems Workshop (KAW 96):Banff.
Chien, S. 1996 Static and Completion Analysis for Plan-
22
ning Knowledge Base Development and Verification. InProceedings of The Third International Conference onArtificial Intelligence Planning Systems, 53-61, Edin-burgh UK: AAAI Press, ISBN 0-929280-97-0.
Currie, K., and Tate, A. 1991. O-Plan: the Open Plan-ning Architecture. Artificial Intelligence 51(1): North-Holland.
Drummond, M. 1994. On Precondition Achievementand the Computational Economic of Automatic Plan-ning. In: C. Backstrom and E. Sandewall, eds, CurrentTrends in AI Planning, 6-13: IOS press, ISBN 905199153 3.
Erol, K. 1995. Hierarchical Task Network Planning:Formalisation, Analysis, and Implementation. Ph.DThesis, Dept. of Computer Science, University of Mary-land, USA.
Jarvis, P., and Winstanley, G. 1996a, Dynamically As-sessed and Reasoned Task (DART) Networks. In Pro-ceedings of the Sixteenth International Conference ofthe British Computer Society Specialist Group on Ex-pert Systems, Cambridge, UK, ISBN 1 899621 15 6.
Jarvis, P., and Winstanley, G. 1996b. Objects and Ob-jectives: the merging of object and planning technolo-gies. In Proceedings of the 15th Workshop of the UKPlanning and Scheduling Special Interest Group, Liver-pool, UK.
Jarvis. P. 1997. Integration of Classical and Model-Based Planning. Ph.D Thesis, School of Comput-ing and Mathematical Sciences, The University ofBrighton, UK. http://www.aiai.ed.ac.uk/-paj/thesis/
Jarvis, P., and Winstanley, G. 1998. Using the TaskFormalism Method to Guide the Development of aPrincipled HTN Planning Solution for the Construc-tion Industry. Submitted to the 17th Workshop of theUK Planning and Scheduling Special Interest Group,to be held during September at the University ofHuddersfield, UK. http://www.aiai.ed.ac.ul~/~paj/paj-pubs.html
Kambhampati, S. 1995. Planning as refinement Search:a unified framework for evaluating design trade-offs inpartial-order planning. Artificial Intelligence, 76, Spe-cial Issue on Planning and Scheduling.
Kartam, N., Levitt, R., and Wilkins, D. 1991. Extend-ing Artificial Intelligence Techniques for HierarchicalPlanning, ASCE Journal of Computing in Civil Engi-neering.
Kingston, J., Shadbolt, N., and Tate, A. 1996. Com-monKADS Models for Knowledge Based Planning. InProceedings of the l~th National Conference on Artifi-cial Intelligence (AAAI-96), Portland, Oregon, USA:AAAIPress. http://www.aiai.ed.ac.uk/~oplan/oplan/oplan-
doc.html
Knoblock, C. 1996. Editors Introduction. IEEE ExpertIntelligent Systems and Their Applications, 11(6).
Marshall, G., 1988, PIPPA: The Professional Intelli-gent Project Planning Assistant. Ph.D Thesis, Infor-mation Technology Research Institute, The Universityof Brighton, UK.
Reece, G., Tate, A., Brown, D., I-Ioffman, M.,and Burnard, R. 1993. The PRECIS Environ-ment. In the ARPA-RL Planning Initiative Work-shop, held during the 11th National Conference on Ar-tificial Intelligence (AAAI-93), Washington DC, USA.http://www.alai.ed.ac.uk/-oplan/oplan/oplan-doc.html
Schreiber, G., Wielinga, B., and Breuker. J. eds. 1993.KADS A Principled Approach to Knowledge-Based Sys-tem Development. Academic Press, ISBN 0 12 6290407.
Tate, A. 1976. Project Planning Using A HierarchicNon-linear Planner, Department of Artificial Intelli-gence Research Report No. 25, Artificial IntelligenceLibrary, University of Edinburgh, 80 South Bridge, Ed-inburgh, EH1 1HN, UK. House building domain encod-ing available from http://www.alai.ed.ac.uk/-oplan/
Tate, A. 1977. Generating Project Networks. In Pro-ceedings of the International Joint Conferences on Ar-tificial Intelligence, 888-893.
Tate, A., Drabble, B., and Dalton, J. 1994. O-Plan Version 2.2 Task Formalism Manual. O-PlanProject Documentation, Artificial Intelligence Appli-cations Institute, The University of Edinburgh, UK.http://www.aiai.ed.ac.uk/~oplan/oplan/oplan-doc.html
Tare, A., Polyak, P., and Jarvis, P. 1998. TFMethod: An Initial Framework for Modelling andAnalysing Planning Domains, In Proceedings of theAIPS-98 Workshop on Knowledge Engineering and Ac-quisition for Planning: Bridging Theory and Practice,held during the Fourth International Conference on AIPlanning Systems, Carnegie-Mellon University, USA.http://www.aiai.ed.ac.uk/-oplan/oplan/oplan-doc.html
Winstanley, G., Boardman, J., and Kellett, J. 1990.An Intelligent Planning Assistant in the Manufactureof Flight Simulators. In Proceedings of the ACME Re-search Conference, University of Birmingham, UK.
Winstanley, G., and Hoshi, K. 1993. Activity Aggre-gation in Model-Based AI Planning Systems. AI inEngineering Design and Manufacture, 7(3), AcademicPress, 209-228.
Valente, A. 1995. Knowledge Level Analysis of Plan-ning Systems. SIGART Bulletin, 6(1), 33-41.
Acknowledgements
The authors would like to thank Stuart Aitken, JohnKingston, and Austin Tate for their comments on thispaper, and Nigel Shadbolt for his comments on thework that is described in this paper. The modelling re-
quirements were developed with the assistance of TheLlewellyn Group of Companies, UK. We also thank theanonymous reviewers for their insightful comments. Er-rors and omissions remain our own.
24
