From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
SomeThoughtson.Configuration Processes
David C. Brown
ComputerScience Department, Worcester Polytechnic Institute,
dcb @cs. wpi.edu, http ://www. wpi.edu/~dcb/
Worcester, MA01609, USA.
1. Definition
The most commonlyused definition of the Configuration task was given by Mittal & Frayman[1989, p.
1396]:
"Given:(A) a fixed, pre-defmedset of components,
wherea component
is describedby a set of properties, ports for connectingit to other components,
constraintsat eachport that describethe components
that canbe connectedat that port, andother structural constraints; (B) somedescriptionof the desired
configuration;and (C) possiblysomecriteria for makingoptimalselections."
"Build:Oneor moreconfigurationsthat satisfy all the requirements,wherea configurationis a set of
components
and a description of the connectionsbetweenthe components
in the set, or, detect inconsistencies in the requirements."
For example, for problem of building a software system from modules, the componentsare a modules;
the ports are the variables whichneed values or provide values; the constraints are descriptions of the
numberand types of values needed, or constraints about the compatibility of one modulewith another;
and the description of the desired configuration is the user’s description of what the software system is
supposedto do.
Mittal & Frayman[1989] point out that three important aspects of configuration are that:
¯ one cannot design new componentsduring the configuration task;
¯ that each componentis restricted in advance to only be able to "connect" to other certain components in fixed ways(i.e., they can’t be modifiedto get arbitrary connectivity); and that
¯ the solution specifies both the componentsin the configuration as well as howthey are related.
2. Inadequacyof Definition
There are someproblemswith this definition. Eventhough it is not appropriate to completely discuss
the issues here, we will give someindication of the problems.
Mittal & Fraymanuse the word "connect" throughout, probably influenced by the computer configuration domainin which they were working. However,not every configuration has componentsthat connect. For example, the componentsmayinfluence each other with fields, or they maytouch but not in
any fixed position.
There is also an issue with "ports". It is hard to imaginewherethe ports are for somemechanicalproblems (e.g., gear pairs). This term is also very tied to the idea of configurations whoseparts are linked
becausesomethingdirectly flows betweenthem. It isn’t clear that must be true for all configurations.
Other important issues include at what level of abstraction the componentsare "predefined", and at
what level they must finish up, as well as whetherall or just someof the componentsneed to be used in
the configuration.
August24, 19968:03 pm
75
1 of 9
3. Designversus Configuration
Designis a complextask that meansdifferent things to different people. Most"AI in Design"researchers and "Design Theory & Methodology"researchers consider design to have several logical phases
[Brown1991]. These roughly correspond to the types of things that are being decided in that phase.
Thesetypes of decisions include the functionality, the type of device, the general types of components,
the configuration of types of components,the actual components,and the values of the attributes of
those components.
Thus Configuration is an ingredient of the completedesign task. The distinction whichis often madeis
that a design task produces (i.e., generates, or synthesizes) componentsand values for attributes,
whereasa configuration task does not. Suchdistinctions are controversial. For example,if one allows
abstract components,there appears to be a need to specify them completely before a configuration can
be produced.Someresearchers refer to the process of configuring and then fully specifying as "Configuration Design".
Someknowledge-based design systems claim to explicitly address configuration -- for example,
MICON
[Birmingham 1992]. Others do not, despite having a strong flavor of it [Brown & Chandrasekaran 1989] [Steinberg 1989].
4. Ingredientsof the ConfigurationTask
The configuration task can be "logically" divided into several subtasks. Componentshave to be
selected. Theyeach need to be able to play a part in satisfying the requirementsand must fit into the
(current partial) configuration. Onceselected, they have to be placed into that configuration. Wewill
refer to that subtask as Association. Anotherlogical subtask is Evaluation.
Thus:
Configuration= Selection + Association + Evaluation
where:
Selection = Choosing components
Association = Establishing logical relationships betweencomponents
Evaluation = Compatibility Testing + Goal Satisfaction Testing
The actual process used (i.e., the implementation) for a configuration system depends on howmuch
about each subtask is knownin advance, on howmuchknowledgeis used in each subtask, and on the
mixand order of these subtasks. This is exploredin the next subsection.
The actual process used for a configuration system also.depends on whether knowledgefrom later subtasks can be movedforward into earlier subtasks to prevent failures. For example:
Selection = Choosing Components+ Compatibility Testing
It maybe possible to ensure that orily compatible componentsare selected. This sort of "knowledge
compilation" process, whereone piece of knowledgeis compiledinto another, has even been applied to
the Generate and Test method,so that componentsgenerated do not need to be tested, as the generator
(with the test compiledinto it) only generates correct things [Mostow1991].
In somecases:
Configuration = Selection + Association + Arrangement+ Evaluation
where:
August24, 19968:03 pm
76
2 of 9
Arrangement
= Establishing specific relationshipsExamplesof "logical relationships", used in Association, might be "next to", or "connected to". These
do not specify the exact placementof one componentrelative to the other. Specific relationships, used
in Arrangement,will precisely locate one componentwith respect to another or with respect to some
reference location.
If there is any doubt that these are different, imaginethree pulleys placed in roughly a triangle, with a
rubber belt that fits over the outside of all three so that the belt is pulled tight. Whathas beendescribed
here is a configuration.
Precise description of the positions of all three pulleys will constitute an arrangement(Figure 1). Moving a pulley towards another pulley produces another arrangement(Figure 2).
Manytasks whichwe casually refer to as "configuration" also include Arrangement.It is hard to imagine Arrangementbeing done without at least an implicit Selection + Association. It maybe appropriate
to consider tasks which we casually refer to as "arrangement"as Configuration tasks with the Arrangement portion dominant. The Layout task can be thought of as Arrangementin 2D. Thus:
Layout = Arrangement-in-2D
Other authors have presented different analyses. For example, for a morefine-grained analysis, see
[Runkelet al 1992] and its references.
5. Approaches
to Configuration
5.1. Introduction:
Theissues that concernreuse in systemsthat use any sort of pre-existing unit (e.g., a software module)
are Indexing, Mapping,and Instantiating. Indexing is concerned with howto organize the modulesso
that the right ones can be selected. Mappingis concernedwith howto convert the task model(i.e., the
user’s requirements) to a configuration. Instantiating is concerned with howto produce a complete
description of a workingsystem from the final configuration. A variety of techniques that address these
issues are presented below.
Whenconsidering Mapping,we often describe it in a state-space fashion, where states are transformed
to other states by Operators. States are incomplete,or partial, configurations. This is a rather "bottomup" approach to configuration, adding one componentat a time. The mappingmaybe viewedin a "topdown"fashion, where abstract descriptions of the configuration or parts of the configuration are
"refined" into moreconcrete descriptions. This is knownas Refinement.
5.2. Modules/Components
For configuration to be a generally useful approach to building systems (of any kind), the modules/
componentsneed to be reusable, the numbernot too large, and we have to ensure that we don’t have to
create newmodules/components
for each application that is built.
For software, a moduleis "reusable if it can be employedfor several domainsand tasks" [Klinker et al
1990], whereas a moduleis "usable" if a person whohas limited programming
skills can use it to build
a programfor a task. Anexcellent survey of reuse in software engineering is given by Krueger[1989].
It is difficult to producegeneric, abstract modelsof tasks around whichlibraries of modulescould be
built. In somesituations, it is likely that the manymoduleswill be quite specific, and strongly fled to the
particular situations for whichthey were developed. This is a negative factor if systems to be configured are going to be used in a widevariety of situations.
August24, 19968:03 pm
77
3 of 9
Pulley
Figure 1: Configuration 1, Arrangement1
~lley
t
Figure 2: Configuration 1, Arrangement2
August24, 19968:03 pm
78
4 of 9
In general, the more knowledgeabout a particular domainis encoded in a module, the more contextdependentit is, and the less likely it is to be useful in someother domain[Brown1992]. In the DIDS
system, for example [Runkel et al 1992], high reuse is obtained by having domain-neutral modules
(mechanisms)which use externally defined domaininformation.
Thesize of the modules/components
used, i.e., grain size, is an important issue. The larger the module
the morelikely it is to have strong requirementsfor whichother modulesit requires to havewith it, and
the less flexible its use will be. However,large modulescan be considered to be preconfigured smaller
modules. Therefore, less configuration needs to be done. Small moduleswill probably provide more
flexibility, but will require moreconfiguration.
Anotherissue is the level of abstraction of the module.Obviously, an abstract modulecannot be "executed", as it will require "instantiating" -- i.e., being madespecific. This observation also applies to
Templatesas well (see below).
5.3. Experience and Knowledge
A key issue in the implementation of Configuration tasks is howmuchexperience and knowledgeis
available. Withoutthese, given only a set of descriptions of the individual modules,the problemis one
of searching for combinationsof modulesthat satisfy the requirements. Withno extra knowledgethere
is no wayto guide the search.
Knowledgeabout the modulesallows us to build structured descriptions about the configuration system’s library of available modules,so that search is reduced. Thestructure allows us to relate groupsof
modules,so that deciding that one isn’t suitable for inclusion in the configuration also decides that the
others, whichare related, also aren’t suitable (i.e., pruning).
Research on building configuration systems has shown that they should include explicit, separate
knowledgeabout modules/components,as opposed to having moduleknowledgeimplicit in the control
strategy (e.g., hiddenin search control rules).
Experienceallows us to build previously discovered sub-configurations into the system. As these do not
need to be configured, search is further reduced. It can also allow us to add heuristic knowledge,which
mayallow us to prefer one moduleover another in a particular situation (thus lowering the chance of
having to backtrack and remakethis decision), or could allow us to do things in an order which led to
success previously.
5.4. Search
Almost any basic AI search technique could be used. Generate and Test could be used to "generate"
configurations and test themfor satisfaction of the requirements. Means-endsanalysis could be used to
try to reduce the difference betweenhaving no configuration, and having one that satisfies the requirements. As modulesare added to the configuration, newdifferences emerge, and can be reduced. Heuristic searches, such as A*, could be used, whichsearch by using an evaluation function applied to partial
configurations, and use the best at every stage. Unfortunately, it isn’t always possible to evaluate the
quality of a partial configuration.
5.5. Constraints
It has been pointed out that design problems and configuration problems can be formulated as constraint reasoning problems. Howeasily this can be done depends on the exact nature of the problem.
If weknowthe pattern of connections, and have constraints on this pattern, but do not knowthe components, then this is equivalent to a crosswordpuzzle. This is a standard exampleused to explain Con-
¯ August24, 19968:03 pm
79
5 of 9
straint Satisfaction techniques. AConstraint Satisfaction Problem(CSP)occurs whenone tries to find
set of values for somevariables whichare related by constraints. CSPmethodscan be guided by knowledge and heuristics.
However,usually, we do not knowthe pattern of connections, and as Fraymanand Mittal point out
[1987], selection of componentsintroduces newvariables and newconstraints [Mittal & Falkenhainer
1990]. Thus, configuration is a dynamicsequence of CSPs, a DynamicCSP.
Constraints can also be used for checking compatibilities betweenchoices. This wouldallow the compatibility of the ports of two componentsto be tested.
In general, whenevera decision (choice) is made,this will imposerestrictions. Theserestrictions can
represented by constraints. Constraints can be "posted" to (i.e., attached to) the things they restrict,
that they can affect its subsequentuse, such as its refinement. In somecases constraints can be "propagated" through a configuration, so that it flows across relationships betweencomponentsto affect other
components.
Constraints can be used to record decisions madewhich do not correspond to objects in the system.
Theycan describe somethingwhich must be true of subsequent choices. This can be used to restrict the
set of currently considered components,without deciding which. Fraymanand Mittal refer to this as
partial choice [1987].
Partial choice, along with constraint posting, can be used to implementa least commitmentstrategy,
where choices are delayed, so that more information can be accumulated and premature decisions
(which maybe wrong) can be avoided.
5.6. Hierarchies
Hierarchies -- abstraction hierarchies, generalization hierarchies, or taxonomies-- record groupings
betweentypes of things that share common
properties. The relationship betweenan object lower in the
hierarchywith one higher is that it is less abstract, that it is a type of the higherone, and that it has all
the properties of the higher one.
Abstraction is useful in problem-solving to implementa least-commitmentstrategy, to allow a topdownstrategy, to allow refinement guided by constraints, and to avoid the combinatorics producedby
consideringexcessive detail too early.
Refinement can easily be implementedby movingdownthe hierarchy, making decisions about which
morespecific lower thing to choose. These choices can produceconstraints. Theseconstraints can lead
to morechoices: hence, constraint-guided. Constraints attached to a node in an abstraction hierarchy
will restrict all the subnodesof that node. This hierarchy can be viewedas an ORtree, with alternative
refinements at every node.
The first form of abstraction hierarchy useful for configuration is the Component
hierarchy. Specific
componentscan be groupedinto types, and those types into Subtypes.
Thesecond form of abstraction hierarchy useful for configuration is the Functionalhierarchy. This provides a wayof storing functions organized by type and abstractness.
In somesystems, for example[Lee et al 1992], the two types of hierarchies are linked into one, with the
functional hierarchy leading to abstract componenttypes, and eventually downto specific components.
This allows refinement to occur from function all the wayto specific component,using the sametechnique.
Other hierarchies can be used to record parts and subparts, with an implicit "part-of" relation. This hier-
August24, 19968:03 pm
80
6 of 9
archy showsthe "decomposition"of a thing. It is often used to showalternative subparts. This leads to
an AND/OR
tree, where the choice (OR) is between alternative decompositions (ANDs).
Part-subpart hierarchies can be used for both functions and for components.A particular decomposition, if selected, provides a preformedconfiguration.
This type of hierarchy can also be used to record the configuration, as each componentselected is partof the configuration. In somesystems, the resulting configuration is alwaysa portion of the tree built
into the system. Thusthe configuration can be recorded merely by markingthat tree.
5.7. Templates
Wewill use the term template to refer to any preformedpiece of configuration (i.e., from past experience). For convenience,wewill call the things in the template "items". A template mayassociate functional or structural items, or a blend. If the system uses hierarchies, these items will also appear as
nodes in the hierarchies. As with modules,templates can vary by size, by level of abstraction, and by
howdomainspecific they are.
Atemplate can also indicate the preferred the order of refinementof the items in it. Consequently,it can
also take on someof the aspects of aplan -- i.e., a sequenceof activities.
Systemsthat use templates vary in the wayin which they use indexing to organize them. Templatesare
usually associated with nodes in a hierarchy.
A template mayjust be an alternative representation for a decomposition. However,the template may
also include items which are not strictly part of the decomposition, but which are required by those
items.
Therelationships betweenthe items in a template dependon their level of abstraction and whetherthey
are of function or componenttype. Theycan include I/O relationships, connection, spatial relationships, constraints that relate them, and, for software, control sequencing information (e.g., While
loops).
Structural templates (such as those used in MICON
[Birminghamet al 1992]) can include abstract
specific componentsrelated to indicate the structure of that piece of configuration. For example,
abstract electrical componentsmight be wired together in the template. A functional template would
probably have muchweakerspatial relationships, but could have quite specific I/O relationships.
At any point during the configuration process there maybe alternative Templates available. Thus a
selection process is required. Preferences could be used to help select one over another [Frayman&
Mittal 1987]. Constraints mayalso be used to prune the set of alternatives. Incorrect selection maylead
to backtracking.
A more knowledge-intensive selection technique, such as that found in [Mittal & Araya 1989] or
[Brown& Chandrasekaran1989], might include an evaluation of the suitability of each template, and
then selection from amongthe most suitable.
In somesystems, the actual configuration task is controlled by a fixed sequence of tasks [McDermott
1982] [Birmingham& Siewiorek 1984]. Sometimesthese tasks correspond to the top-level functional
decompositionof the system to be configured. Whilestrictly these are Plans, they can be considered as
TaskTemplates.Skeletal plans are those whichare slightly abstract and that require refinement.
5.8. Key Components
Mittal & Frayman[1989] point out that even if a particular function has been selected, there maystill
be a variety of waysof putting together components(or even subfunctions) to achieve that functional-
August24, 19968:03 pm
81
7 of 9
ity. To reduce the search space, they introduce the idea of KeyComponents.Thus if a "mappingfrom
each function Fi to componentsCi that are key componentsin providing Fi" is available, then the search
for a configuration that provides Fi can be reduced.
The key componentcould correspond to a componentwhich is (almost) always required. A more heuristic interpretation is that a key componentis an item in a template on which manyother decisions
depend.This suggests that its correct choice should take priority.
7. Summary
Wehave discussed the definition of the configuration task, including someof its inadequacies; have
described the relationship betweendesign and configuration; have outlined one view of the problemsolving ingredients of configuration; and have presented an analysis of different approachesto implementingthe configuration task, such as hierarchies and templates.
8. References
W. P. Birmingham& D. P. Siewiorek, MICON:A KnowledgeBased Single Board Computer Designer,
2]st Design AutomationConference, Vol. 1, 1984, pp. 565-571.
W. Birmingham, A. Gupta & D. Siewiorek, Automating the Design of Computer Systems: The MICON
Project, Jones &Bartlett Publishers, 1992.
D. C. Brown,Design, Encyclopediaof Artificial Intelligence, 2rid edn., (Ed) S.C.Shapiro, Wiley-Interscience, May1991.
D. C. Brown, The Reusability of DSPLSystems, Proc. Workshopon Reusable Design Systems, Second
Int. Conf. on AI in Design, June 1992.
D. C. Brown& B. Chandrasekaran, Design Problem Solving: KnowledgeStructures and Control Strategies, ResearchNotes in Artificial Intelligence Series, PitmanPublishing, Ltd., London,England, May
1989.
F. Frayman& S. Mittal, COSSACK:
A Constraints-Based Expert System for Configuration, In: KBES
In Engineering: Planning and Design, (Eds.) D.Sriram & B.Adey, Computational Mechanics Publications, 1987, pp. 143-166.
G. Klinker, C. Bhola, G. Dallemagne, D. Marques& J. McDermott,Usable and Reusable Programming
Constructs, Proceedings of 5th KnowledgeAcquisition Workshop, AAAI, 1990. (Also in: KnowledgeAcquisition, Vol.3, No.2, pp. 117-135).
C. W. Kreuger, Models of Reuse in Software Engineering, CMU-CS-89-188,
1989.
C-L. Lee, G. Iyengar & S. Kota, AutomatedConfiguration Design of Hydraulic Systems, A/in Design
"92, ~_xl.) J.S.Gero, KluwerAcademic,1992, pp.61-82.
J. McDermott,RI: a rule-based configurer of computersystems, Artificial Intelligence, Vol. 19, 1982,
pp. 39-88.
S. Mittal & A. Maya, A Knowledge-BasedFrameworkfor Design, IJCAI, Vol.1, 1989, pp. 856-864.
S. Mittal & F. Frayman,Towardsa generic modelof configuration tasks, IJCAI, Vol. 2, 1989, pp. 13951401.
S. Mittal & B. Falkenhainer, DynamicConstraint Satisfaction Problems, Proc. 8th Nat. Conf. on AI,
AAAI-90, 1990, pp. 25-32.
August24, 19968:03 pm
82
8 of 9
J. Mostow,A Transformation Approach to KnowledgeCompilation, In: Automating Software Design,
(Eds) Lowry & McCartney, MITPress, 1991.
J. Runkel, W. Birmingham,T. Darr, B. Maxim& I. Tommelein, DomainIndependent Design System:
Environmentfor Rapid Developmentof Configuration Design Systems, In: Artificial Intelligence in
Design ’92, (Ed.) J.S.Gero, KluwerAcademicPublishers, 1992, pp. 21-40.
L. Steinberg, Design as Refinement Plus Constraint Propagation: The VEXED
Experience, IJCAI,
1989, pp. 830-834.
Thispaperis a revisedversionof part of a longerreport, originallywrittenin 1992,for Digital Equipment
Corporation.
August 24, 1996 8:03 pm
83
9 of 9