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