A logic-based description of configuration: the Constructive Problem Solving approach. REIdiger Klein. Daimler-Benz AG - Research Dept. Knowledge Based ...
From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
Position paper - AAAI1996 Fall Symposium Workshopon Configuration, MIT, Cambridge,MA, Nov. 1996
A logic-baseddescription of configuration: the Constructive ProblemSolving approach
REIdigerKlein Daimler-Benz AG- ResearchDept. Knowledge Based Systems Group (F3/SW) AIt-Moabit 96a D- 10559Berlin TeL: (++49-30) 399 82 211 email: klein @DBresearch-Berlin.de
1. Introduction Configurationproblemshavebeenin the focus of AI for a long time. Different AI techniques havebeenapplied for configuration problemsolving: rule basedapproaches[McDermott82], object-oriented techniques[Plakon91], structural refinement [Tank90], various grammars [BMS94],resource basedtechniques [Heinrich89, SW92,HJ91+96], or constraint based ones[SH92,FW94]- just to mentiona few. Thoughthere are quite a lot of applications, the real successof theseapproaches has beenquite limited up to now. Themainreasonfor this seemsto be that eachof these approachesreflects only certain aspects of configuration (moreor less in an ad-hocmanner).Whatis missing is a comprehensive andwell-formalized Alparadigm of configurationwhichwouldprovide the foundationto integrate the different aspects in a well-defined way. This Alparadigmof configuration should reflect the essenceof knowledgebasedconfiguration: ¯ Configurationproblemsolving is essentially a generativeprocess:a solution hasto be generatedwhichfulfills the different goal andconsistencyrequirements.Thecentral point hereis to havea well-founded,logic basedformulationof generativeproblemsolving (in contrastto "traditional", proof-orientedformalizations). ¯ Configuration problemsneedan expressiveknowledgerepresentation allowing to describe the manydifferentknowledgeaspectsin an integratedway: generic versus casespecific knowledge,taxonomies,part-of hierarchies, structural and arithmetic constraints, etc., andwhichallow us to usethis knowledge in the configurationtypical way: as taxonomicreasoning,hierarchical refinement,constraint specification andsolving/ propagation, resource-basedreasoning, etc. Recently, a numberof approacheshavebeenformulatedallowing to integrate different formalismsin a well-defined way: the CLPscheme of Jaffar and Lassez[JL87] integrating logic and constraint programming,the H6hfeld-Smolkascheme[HS88], or Baaderand Hanschke’s concretedomains[BH91]integrating taxomonicand constraint reasoning-just to mention a few. Thepoint is, that all theseapproaches are deductiveones,i.e., they are proof oriented, not generationoriented(for an overviewseefor instance[Lloydg0]). Onthe other side,
constructiveor generativeaspectsplay a majorrole in a variety of problemclasses: design, configuration, planning, scheduling, etc. Thusresearchis underwayat manyplaces on such topics as abduction [O’Rorke90+91;Lloydg0], modelgeneration [MB88; DD92;FHKF92], modelelimination [Sticke185; BB91+93],dynamicconstraint techniques[MF89,FW94]etc., whichcould provide a suitable formal platform for these constructive problemclasses. Configurationproblemsprovide for a goodtest casefor a generalformalization of generative problemsbecauseof their inherent clear structures: wecan imagineconfiguration (maybein a certain approximation) as a problemclass with no indefinite goals, no unspecified constraints, with completelydescribedobjects, relations and constraints between them, etc. Theydo not suffer (so much)from uncertainty, vagueness,or incompletenessproblems other application classes do (for instance design and planning). Themainproblemsencountered in configuration tasks can be summarized as follows: ¯ Giventhe expressivenessrequirementsand the neededgenerative type of problemsolving - howto deal with the resulting complexity? ¯ Giventhe various types of inferencing (taxonomic,combinatorial, arithmetic constraints) - howto integrate them? Quiteoften configurationproblemsare underspecified - i.e., the real problemis not to find anysolution, but to find an optimal or a goodone(howthat ever maybe expressed).These optimality issuesas well as the complexityproblemsrequire sophisticatedcontrol facilities. The Constructive ProblemSolving [Klein91, KBN94]has beendevelopedas an expressive, well-formalizedapproach to configuration whichprovides the basis to solve these problems. This paperis organizedas follows: In the next chapterwe’ll describea very abstract view on configuration and howthis canbe usedto get a comprehensive formalization. In chapt. 3 the basic idea behindthe ConstructiveProblemSolvingformalization is outlined - the modelgeneration approach.In chapt. 4 the mainproperties of the CPScalculuswill be discussedin an informalway-in order to demonstratethe principles of modelgenerationandto characterize the mostessential requirementsto the CPSinferencesand their interplay. In chapter 5 we concludewith a discussion of the merits and problemsencounteredwith CPS,followed by a brief description of openresearchissues. 2. Constructive ProblemSolving: Configuration as ModelConstruction Thestarting point for a comprehensive formalization of configuration problemsolving is the determinationof the typical knowledge structures andhowthey are related in problemsolving. A comprehensive analysis of the typical knowledge structures in configuration problemsrevealed, that configuration knowledgecan be representedwithin the following mainknowledgecategories: ¯ First, wehavea clear distinction betweenobject-level knowledge,problemsolving knowledge,and control knowledge.Theobject knowledgeincludes an explicit representationof all the objectsandobject classes(or types, or sorts), their relevantproperties (attributes), relations, constraints, etc. Theproblemsolving knowledge reflects the configuration-typicalwaysto deal with the object-level knowledge (for instancethe ge2
nerative wayof problemsolving), and the control knowledgerepresents the various 1. strategies,heuristics, etc ¯ Dueto the clear structures typical in configuration, the object-level knowledge can be divided into two well-distinguished categories: general domainknowledge,and casespecific knowledge.Thecase-specific knowledge consists of knowledge about the concrete configurationproblemto be solved(a set of functional and/or structural goals or requirements)as well as of knowledge about the generatedsolution. In configuration problems,sucha solution normallyhasto be formedout of descriptionsof technical devices by whicha concretesystemis built up as well as their relationships.For instance, descriptions of the technical devicesas they showup in a cataloguecan be part of a solution2. In contrast, the goal specification cancontain moregeneralstatements(leaving certain degreesof freedomfor the overall solution generation). Thusthe general domainknowledgeshould contain expressions(called the definitional knowledge), whichrelate the moregeneralnotions in the domainto the morespecific vocabulary. ¯ Beside the definitional knowledge the general domaindescription should contain various formsof consistencyinformation(constraints). Theyfacilitate the explicit representation of knowledge about inconsistent solutions (negative constraints) as well knowledge about necessarypreconditions of any solution, especially knowledgeabout completeness of solutions. Themainforms of constraints relevant in configuration can be summarizedas follows: - taxonomicconstraints: expressingnecessarysort conditions of certain objects; - structural constraints: objects mustbe related somehow; including relations between compound objects and their components (abstraction hierarchies); - cardinality constraints:certain relations canonly exist in a certain number for a given object (or mustexist in a certain number); - logical constraints:if certainobjectsfulfill certainconditionstheyhaveto fulfill other constraints, too; - arithmetic constraints: real valuedattributes are related by arithmetic equations, disequations,and/or inequalities - A special form of constraints which play a prominentrole in manyconfiguration problemsare resource constraints [H J89, SH92,HJ91+96]. Theidentification of these configuration-typical knowledge structures hasbeenshownto be an essential preconditionfor the formulation of the CPScalculus, whichmakesuseexactly of these categories. Thebasic principles of configuration knowledge given havebeenillustrated with an example from programmable logic control (PLC) devices [KBN94]:The definitional knowledge,for instance, has to represent the fact that cpu boards, communication boards, powersupply units, etc. all are boards,or that crates canbe maincrates or additional crates. Constraints describingconsistencyinformationin the domainare, for instance,the needfor everyboardto 1. Thiswill not bedealtwith here.Weonly wantto pointout, that the explicit representation of the objectlevel knowledge as well as the formulation of the configuration-typical CPS inferencerules provide a necessary pre-requisitefor an adequate representation of the control knowledge. 2. Tohavea solutioncontainingassertionslike "anycpu"or "anycrate" makes no sense,because nobody will beableto insert "anycpu"or "anycrate" into the concreteconfiguration.Whatonecan sayis takea cpuof type"xyz-123" or a crateof type"abc". 3
be placed in anycrate, the needfor every maincrate to contain a cpu board(completeness constraints), or that various boardtypes as well as mainand additional crates are incompatible (negativeconstraints). A goal then contains,for instance,a set of boardsneeded in a specific configuration(eachdescribedby a set of attributes) andsomerelations they shouldpossess. 3. The Basic CPSIdea Wewill nowoutline the basic idea underlyingour formalizationof configuration: a configuration problemsolver gets as input a goalspecificationof the systemto be configured(a set Gof logical formulas) and producesas output a semantical mode/Cof this specification. Of course, this idea needssomerefinementin order to be useful. Wesuppose that weare givena logical language,with signatureT_., that allows us to talk about the systemsweare interested in. In addition weassume that there is a sublanguage, called the basiclanguage,-whosesignatureT..bas/cis a subsignature ofT_,- that givesus the vocabulary to name the technical devicesby whicha concretesystemis built up as well as their relationships. Onecanimagine, for instance, that the names of the technical devicesin a catalogue are part of ~-,basic. Weassume that the basic languageis rich enoughto describe concrete systems.Wedistinguish betweenthe two languagesbecausethe specification of a systemto be configured will be given using the overall language- thus providing moreexpressivenessthere (including abstractions and various degreesof freedom), whereasdescriptions of modelsthat satisfy the specification consist only of basic formulas. Therepresentationof the domainknowledge about technical systemswill consist of the two parts: the definitiona/knowledge, that relates the abstract notions, i.e., the elementsof T_.\ T_.basic, to the basic language,and the consistencyinformation. Thedefinitional knowledge will be represented by a set D of formulaein our language.Theconsistencyinformationwill be a set / of integrity constraints. Nowweare readyto outline the mainidea of ConstructiveProblemSolving[Klein94]: given a configuration domain(characterized by the definitional knowledgeD and the domain constraintsI), anda concreteconfigurationproblem(describedby a goal G), a solution will a finite mode/C fulfilling the followingconditions3: C I=D 3.G and
CI=DI
ThusConstructive ProblemSolving (CPS)representsin a well-formalized waywhat is actually happening in configuration: to a given configurationproblemG a solution C is generated whichis a model,i.e., whichhasto fulfil this goal andthe generalconstraintsin the domain. In this wayCPSmode/construction provides a well-foundedapproachto the synthetictype of configuration problemsolving. 4. An illustration
of CPS
After theseabstractdefinitions andspecificationsin a brief andinformal manner the key ideas of CPSshall be illustrated (using parts of the PLCexample[KBN94]). Definitional knowledge: 3. with 3.Gbeingthe existentialclosureof G
Thedefinitional knowledge D relates moreabstract notions (or concepts,or sorts) to more concreteones(andfinally to basicones). For instance,it allowsus to expresses that a board either a cpuboard, or a communication board, or a powersupplyunit (or someother here not mentioned): board := cpu v comm-boardv ... v power-supply. This means that eachcpuinstancewill be an instanceof board,too - thus this kind of definitional knowledge results in taxonomichierarchies. Vice versa, it also tells us that eachboard instance has to be either a cpu instance, or a comm-board instance, or ... a powersupply instance (and nothingelse). In the samewayabstract relations (like ’connected’) could be related to moreconcreteones (like ’left-connected’ or ’right-connceted’)whichcanbe realized in a concreteconfiguration. Wecan also express, for instance, that a certain concepthasonly a pre-defined numberof instances: voltage-values := {4.5,9,24,110,220}. Consistencyinformation: In configuration problems,consistencyinformation could havemanydifferent forms. Threeof themwill be mentionedhere: 1 .) implications: they have the general form Pl A P2A "" A Pn--’> ql A q2A "’" A qm with the meaning that if the preconditionsPl, P2..... Pnare fulfilled by the generated solution 4. the conclusionsql, q2 ..... qmhaveto be fulfilled, too In our example,for instance, wewantto representthe consistencycondition that everyboard hasto havea place in a crate: VBB:board--) 3C C:crate ^ placed(B,C) (with ’placed’ beinga binaryrelation). Anotherimportantformof consistencyinformationto expressedin manyconfiguration domainsare cardinality constraints: for instancewewantto say that there is only a limited number of placesin a certain crate. In CPS this means that the newgoalplaced(B,C) canonly be fulfilled in a certain modelif thesecardinality restrictions are fulfilled. Manyaspectsof configuration knowledge can be representedin this form of logical implications: that all instancesof a certainclass (sort) haveto havecertain propertiesandfulfill certain constraints, or that a compound object hasto consist of a set of parts andhowtheseparts mustbe related to the wholeandto eachother, etc. 2.) negativeinformation(denials): canbe represented by a special formof implications: their "conclusion"is the special expression ’false’ (written ’_L’). Thedenial that a cpuboardmustnot be placedin a smallcrate can expressedin this way: VBVC B:cpu^ C:small-crate ^ placed(B,C)--) with the meaning that the fulfillment of the preconditionssignals an inconsistentstate. 4. Variablesoccuringin pre-conditions (andmaybe conclusions) are all-quantified, variablesonly occuringin conclusions areexistentially quantified.Thislast caseresults in the generation of new variablesandmaybe objectsas part of the solutiongeneration. 5
3.) resourceconstraints: This is a formof constraintstypical for manyconfigurationproblems.For instance,wewantto guaranteethat in every crate the sumof the powerconsumed by the different boardsis less (or equal) than the powerprovidedby the supplyunits in the samecrate. Takingclassical constraint techniques, two points are worth mentioninghere: - the arithmeticconstraintsrun oversets of expressions whichat definition timeare not explicitly but only implicitly (or intensionally) specified. Onlyat run time it canbe decidedwhich terms haveto be included in the sum. - a violation of this constraintdoesnot necessarilyresult in a backtracking.Thetypical formof resourcebasedreasoningis that resourceconstraint violation triggers a kind of repair operation. In the example given here, for instance, an additional powersupplyunit could be generated and placed in the underbalanced crate. Formallythese resourceconstraints can be expressedas constraints on sumsover intesionally expressedterms: sum{CI p(C)} _> sum{C’I q(C’)} wherethe C andC’ are variableswhichwill be instantiatedon run timeto all termsfulfilling the logical expressionsp and q. In our PLCexamplethe mentionedpowerbalance constraint can be formulated in CPSas follows: VCC:crate --) sum{PI S:power-supplyA placed(S,C) A power(S,P)} sum{VI B:board A placed(B,C) A consumes(B,V)} Goalsand solutions: After this short discussionof definitional knowledge andconsistencyissues wecanshowhow a concreteconfiguration problemcan be representedand howit canbe solved within CPS.A concreteconfiguration problemwill be representedas a set G of goals, for instance: G = {bl :comm-board,b2:comm-board .....
cl :cpu.... }
with eachmaybe describedin moredetail by certain properties it should have. Generatinga solution for this problemmeans to construct a modelwhichfulfills this goal as well as the constraints characterizingthis domainin general.For instance, this includes ¯ to select basic conceptsfor the boardswhichagreewith the goal specification (i.e., which are subconceptsof comm-board); ¯ to generatenewgoalsin orderto fulfill the generalconsistencyconditions(for instance the placementconstraint whichresults in the generationof C:crate and placed(B,C) goals); ¯ to guarantee the resourceconstraints (whichmayresult in the generationof newgoals). A solution to the given examplegoal could be the model C=
{bl :comm-board12, cr0:crate3, placed(b1,cl), placed(b2,cl) ..... c1:cpu33,placed(c1,cr0) ....
b2:comm-board23,
This short discussion gives an impressionhowCPSincrementally generatesa solution as a model.This includes the generationof newobjects and constraints.
5. ProblemSolving In CPS Thevarious forms of knowledge relevant in configuration problemsresult in a corresponding manifold of problemsolving issues. Themainadvantageof CPSis that it provides a common formal frameworkof howthey are to be formulatedand of howthey mustinteract. A central issue in configuration is the relation betweenfunctional andstructural aspects. Manyrequirements(goals) are given as functional specification (thoughalso structural ones are common). Theyhaveto be "mapped"somehow to structures which fulfill them. Themain advantage of configurationis that this mapping is relative/y simp/e(in contrast,for instance,to designin general). In manycasesit simply results in sometaxonomicconstraints on componentsandin constraintson their attributes. Thetaxonomicknowledgeresults in taxonomicreasoning: having a goal bl :board meansto select an appropriatebasicsubsortof boardwhichfulfills all the other constraintsexisting or comming up for this object bl. Havinga goal B:boardalso could meanto select oneof the exsiting objectsin the (partial) modelto be unified with variableB (thus fulfilling this goal). Logicalconstraintsgeneratenewgoalsif their preconditionsare fulfilled, denialssignal inconsistent states. Cardinality constraintson relations andconstraints on finite sets mayresult in combinatorial andfinite domaininferences: knowingthat only n boardscan be placed in a crate meansto generatea sufficiently large number of crates andto find suchan assignment for eachplacementgoal of the mexisting boardsthat the cardinality as well as all the other (for instance powerbalance)constraints are fulfilled. Hereespecially importantis the aspectof symmetry: in manycases the problemspace is symmetricw.r.t, interchanges of components- such combinatorialsearchin suchsubspaces will not contribute to find really newsolutions. Hierarchical structures are quite common in manytechnical applications. Thushierarchical refinementis oneof the central problemsolving activities. Asmentioned in the previouschapter, formally it resembles to dealing with generallogical constraints. It shouldbe controlled carefully: a lot of efforts canbe wastedif donein aninappropriateway(for instancetoo early). 6. Discussion Themodelgenerationapproachof Constructive ProblemSolving provides a well-formalized framework for the description of configurationproblems.It canbe realized on expressiverepresentationlanguages including cardinality andresourceconstraints, andit reflects the generative type of configuration problemsolving basedon a standarddeclarative(Tarsky-style) semantics.For a given representationlanguagea CPScalculus canbe given including a set of inferencerules whichrealize the intendedsemanticsof modelgeneration.In this wayconfiguration problemscanbe solved incrementally, and they canbe solved makinguse of standard logic andconstraint solving techniques. Knowingthese advantagesof CPS-whichare the problems?There are mainly two which are closely related: optimality andcomplexity. Theoptimality problemsimplymeans that normallyoneis not interested to get anysolution to a given problem,but "the best" or at least a"good"one. Thusfrom the manymodelswhichcan normallybe generatedfor a configuration problem,only a small amountwill be consideredas real solution candidatesor solutions. Some of the optimality criteria canbe represented(or 7
approximated) as local constraints or local decision criteria ("take the smallest/cheapest" etc.). But that’s not generally possible, andsometimes it is evencontra-productive.In those casesonly an overall estimationof the total solution (or of larger parts of it) canhelp. Complexityissues are a mainissue in nearly every knowledge basedapplication. That’s true in proof or classification-orientedapproaches, andit is evenmorerelevantin generativeproblem solving (see for instance [EGg2]). Theoretically the numberof modelswhichcanbe generatedto solvea given configurationproblemis so large that there is no chanceto investigate only a small part of the searchspace(not to mentionthose parts of the problemspacewhich do not contain any solution but which mustbe searchedthrough). Both problemsare serious, andthey are not specific to the wayconfigurationproblemsolving is formalized in CPS:they are inherent to every adequateapproachto configuration. Three researchissues could be derived from these considerations: ¯ In order to avoid unnecessary efficiency problems,use the various available techniquesin the mostappropriate way: constraint solving on arithmetic constraints & la CLP(R),finite domainconstraint propagationtechniquesto deal with combinatorialand cardinality aspects, feature unification for taxonomicreasoning,etc. Themainpoint here is to find an adequate integration of thesetechniques... ¯ Controlis of central importance in orderto find anysolution andto find a goodor optimal solution. Not only the wayin whichdecisionsare madeis essential, also the sequence in whichthey are made.For instance, the attractiveness of resource-based configuration comes (at least in part) fromthe fact, that this type of problemsolving allows for intermediate inconsiststates (and provides appropriate repairs).- Whatneedsfurther researchis howcontrol knowledge (strategies, heuristics, etc.) could be represented, whichexpressivemeans are needed,andhowit is interrelated with the the object level knowledge and the various types of inferences. ¯ A possible consequence from theseconsiderationscould be that configurationin its full extendis still too hardfor current AI technologies.But whatcouldbe realistic todayis (besidesconfigurationchecking)an interactive configuration assistant, wherenot only the goal canbe specified interactively andincrementally,but also (the moreimportant) decisionscan be made interactively by a human user. Of course, they canalso be withdrawnand corrected interactively. This meansthat dependency maintenancetechnology hasto be integratedinto all the other (not evensimple)problemsolving techniques. A systemfollowing this approachis just underdevelopement at our researchlab. Later we hopefully can report someconcrete experiencestherefrom.
Acknowledgement Theauthor wantsto thank his colleagues Frank Feldkamp,Michael Heinrich, Ernst-Werner J(ingst, HelmutRitzer, and Klaus Schild from the Daimler-BenzKnowledgeBasedResearch Groupfor their steadyinterest andlifely discussions. References [BH91] F. Baader,Ph.Hanschke: "Ascheme for integrating concrete domains into concept languages", Proc. 8
12th IJCAI, Sydney,1991. [BB91] J. Bowen,D. Bahler: "Full First-Order Logic in Knowledge Representation- a Constraint-BasedApproach, TR-01-29,North Carolina State University, Raleigh, USA,1991. [BB93] J. Bowen,D. Bahler: "A Constraint BasedApproachto Supporting Human Negotiation in Concurrent Engineering",in: [Gero93]. [BMSg4] Brown,K.N., McMahon, C.A., SimsWilliams, J.H.: "Constraint Unification Grammars: specifying languagesof parametricdesigns", in: [Gero94], pp. 239-258. [DD92] M. Denecker,D. DeSchreye:"Onthe Duality of AbductionandModelGeneration",in: Proc. Int’l. Conf on FGCS,ICOT, Tokyo, 1992. [EG92] Th. Biter, G. Gottlob: ’’The Complexityof Logic-BasedAbduction", Report CD-TR92/35, TUWien, 1992. [FHKF92] M. Fujita et al.: ModelGeneration Theorem Proverson a Parallel InferenceMachine,in: Proc. Int’l. Conf on FGCS,ICOT, Tokyo, 1992. [FW94] Faltings, B., and Weigel, R.: Constraint BasedKnowledge Representationfor Configuration Systems, Techn. Report Tit 94/59, AI Lab., Dept. of CS, EPFL,Lausanne,CH, 1994. [Gero92] J. Gero,F. Sudweeks (eds.): Proc. AI in DesignConf., Pittsburgh, 1992,KluwerAcad.Publ. [Gero93] J. Gero,F. Sudweeks (eds.): Proc. I FIP WG5.2 Workshop on FormalDesignMethodsfor CAD,Tallinn, June 1993. [Gero94] J. Gero, F. Sudweeks (eds.): Proc. AI in DesignConf., Lausanne,1994, KluwerAcad. Publ. [Goebe192] Ft. Goebelet al.: "Theorist Docum.",AI Lab., Univ. of Alberta, Ca., 1991. [GR93] Gruber,T. R., and Runkel,J.: ’’The VTDomainOntology",StanfordUniv., 1993. [Heinrich89] M. Heinrich: "Ein generischesModell zur Konfigurierung technischer Systeme",GMD Arbeitspapier 388, St. Augustin, Mai 1989. [HJ91] M. Heinrich, E.-W.J+Jngst: "A Resource-Based Paradigmfor Configuration...", Proc. 7th Conf. on AI Applications, MiamiBeach,Florida, 1991. [HJ96] M. Heinrich, E.-W. J+Jngst: "The resource-based paradigm:configuring technical systemsfrom modular components", proc. of this workshop. [HS88] M. HShfeld, G. Smolka:"Definite relations over constraint languages",LILOGreport 53, IWBS,IBM Germany,Stuttgart, 1988. [JLS7] J. Jaffar, J.-L. Lassez:"Constraint Logic Programming", Proc. 14th ACM Syrup.on Principles of ProgrammingLanguages, Munich, 1987. [Klein91]
9
R. Klein: "ModelRepresentationand TaxonomicReasoningin Configuration ProblemSolving", Proc. 15th GWAI,Bonn,1991, Springer Informatik Fachberichte285, pp. 182-194. [Klein93] R. Klein: "SomeSuggestionsto Resource-based Modelling in Configuration ProblemSolving", Technical Report, DaimlerBenz ResearchDept., Berlin, 1993. [KBN94] R. Klein, M. Buchheit, W.Nutt: "Configuration as ModelConstruction:the ConstructiveProblemSolving Approach",in: J. Gero,E Sudweeks (eds.): Proceedings of "Artificial Intelligence in Design1994" (AID94) conference, Lausanne,1994, Kluwer AcademicPress. [Levesque89] Levesque,H.: A knowledge-levelaccountof abduction, Proc. IJCAI-89, pp.1061-1066,Detroit, 1989 [Lloyd 90] Lloyd, J.W.: ComputationalLogic, Proc. of the ESPRIT Basic Reasaerch Activities Symposium, Bruxels, Nov.1990,Springer, Berlin, 1990. [MB88] R. Manthey,F. Bry: Satchmo-a TheoremProver Implementedin Prolog", Proc. 9th CADE,Argonne, II1., SpringerLNCS 310, Berlin,1988. [McDermott82] McDermott, J.: "RI: A Rule-Based Configurer of Computersystems",Artificial Intelligence 19(1982)39-88. [MFS9] Mittal, S., andFrayman, F.: "Towards a genericmodelof configurationtasks, Proc. IJCAI-89,Los Angelos, 1989, MorganKaufman. [O’Rorke90] O’Rorke, P.: AutomatedAbduction, WorkingNotes, 1990 AAAISpring Symposium, Stanford-Univ., TR-90-32 [O’Rorke91] O’Rorke, P.: Reviewof AAAI-90 Spring Symposiumon Automated Abduction, SIGARTBulletin 1/3(1991), pp.12-17. [Owsnlcki 88] Owsnicki-Kleve, B.: Configuration as a consistency-maintenancetask, in: W. Hoeppner(Hrsg.): K0nstlicheIntelligenz, Informatik-Fachberichte 181, Springer, Berlin, 1988. [Plakon 91] R. Cunis et al: "DasPLAKON Buch", Springer Inform. FB, Berlin 1991. [PvH89] P. van Hentenryck:"Constraint Satisfaction in Logic Programming", MITPress, Carnbr., MA,1989. [RBB94] Runkel,J.T., Balkany,A., and Birmingham, W. P.: "GeneratingNon-Brittle Configuration-Design Tools", in: [Gero94], pp. 183-200. [SH92] Stumptner,M., and HaselbSck,A.: A generative constraint formalismfor configuration problems,TR 92/4, TUWien,Institut for Inforrnationssysteme,Wien,Austria, 1992. [SN 90] Searls, D.B. and Norton, L.M.: Logic-BasedConfiguration with a SemanticNetwork,Journal of Logic Progr. 8(1990)53-73. [Smolka 88] G. Smolka:"A feature logic with subsorts", LILOGreport 33, IWBS,IBMGermany,Stuttgart, 1988. [SSS 88] Schmidt-Schauss,M. and Smolka, G.: "Attributive ConceptDescription with Unions and Complements",SCKIReport88-21, Universitaet Kaiserslautern, Dec. 88
lOa
[SUcke185] M. Stickel: "Automated Deductionby TheoryResolution",J. of Artificial Int.1 (85)333. [SW91] B. Stein, J, Weiner:"MOKON - eine modellbasierteEntwicklungsplattformzur Konfigurierungtechnischer Anlagen", in Proc. 5. Workshop "Planen und Konfigurieren", LKI-report 1/91, Hamburg,1991. [Tankg0] Tank, W., et al.: AMOR - sine Wissensrepr~isentationssprachefor die technische Kid, rung yon Auftr~gen, in: H. Krallmann(Hrsg.): Innovative Anwendungen, Oldenburg-Verlag,MQnchen, 1990. [TN94] Takeda,H., and Nishida, T.: "Integration of aspectsin design processes",in: [Gero94], pp.309-326.
iOb
