From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
Thoughtson Partitioning
Large-Scale Configuration Problems
GerhardFleischanderl
Alois Haselb~ick
Siemens Austria, PSE EZE
Erdberger Laende 26
A-1030 Vienna, Austria
E-mail: gerhard.fleischanderl @siemens.at
alois.haselboeck @siemens.at
Abstract
Most’interesting’ configuration problemstend to be large-scale. Therefore, the
configuration networks growto remarkable sizes and techniques must be considered
to keep handling, solving and checkingof these networkspractically feasible. This
paper presents a techniqueweuse in our current configuration project: the partitioning of large problemsinto pieces of manageablesizes. The very basics of our
component-orientedframeworkfor representing configuration domainsare
presented. Partitioning a configuration problemmeansidentifying subproblemsin the
configuration graph and solving them separately. Beside the reduction in problem
size we provide the user with control mechanismsby displaying a sub-system-graph
to guide the user through the configuration process.
1 Introduction
Configuringlarge-scale systems entails problemswhichare irrelevant whenconfiguring small
systems. First of all, that is sheer size of the configurationproblem.Dueto interrelations, complexity and effort mayrise disproportionately along with problemsize. In this paper wewant to
describe another aspect found in large problems, identifying sub-problems. Sub-problemsare
moreeasily solved (at least, ought to). Constraint solving techniques(like backtracking)usually
are computationally expensive [5]. Often the problemas a whole could not be solved under
practical circumstances,thus the definition of sub-problemsis the preconditionto the feasibility
of the solution. The idea of breaking downa large probleminto pieces of manageablesizes is
also a well-knownmethodin constraint theory (see, e.g., [2] and [6]).
Thoughts on Partitioning Large-ScaleConfiguration Problems
45
Weare dealing with configuration problemsand tackle them with a constraint approach. Identifying a sub-problemmeansfinding a sub-set of componentsand constraints which form a selfcontained tasks. Theless connections there are to neighboringsub-problems,the better. Our
configuration domainis (as we call them) component-orientedsystems which are assembled
componentsfrom a predefined set, observing the rules laid downas constraints [8], [3]. Application domainsare systems constructed from modular components, for instance, telecommunication systems, audio systems or computers.
Thepaper is organized as follows: In the first part wegive a brief introduction into our component-oriented frameworkof representing configuration networks, where constraints represent
the different restrictions and relations betweenthe components.Wepresent a few numbersfrom
our current project, indicating the magnitudeof configuration and constraint networksmany
real-world configuration problemshave to deal with. After that we present our approachto
partitioning large-scale problemsand discuss it. Weargue that the maintwo advantagesare
reduced problemsizes (computation- and space-expensive methodsturn to be applicable) and
that the sub-systemswill control the configuration process and will therefore lead the user
through a usually highly complicatedtask.
2 Problem environment
2.1 The configuration framework
There are several theories of representing configuration problems,all of themhavingin
common
that componentsplay the central role in the description of the problemdomain(see,
e.g., [7], [1], [4]). This chapter sketches a simple but general frameworkfor representing technical systemsin a component-oriented
manner[8], [3]. Thefirst-class objects in this representation frameworkare components,which are connected via ports to a complexconfiguration
network. Additionally, each componenthas a type and a set of attributes describing individual
properties of that component.A configuration is a networkconsisting of componentsand their
ports assembled to a complexsystem.
Figure l(a) showsthe basic concept representing a connection between two components.This
must be done by connecting two ports, each belonging to a single component:portl of component complis connectedto port2 of componentcomp2.Of course, it is also possible that a port
remainsunconnectedin a configuration. Figure l(b) presents a small part of a configuration,
where frames are mountedon racks and, furthermore, are connectedto other frames via cables
(a cable is modelledsimplyby the connectionof twoplugs; of course, if further details in representing a cable are necessary, a componentrepresentation must be chosen). Wesee that the
different kinds of relations (the hierarchical mounted-onconnection, the cable connections
betweentwo componentsat the samelevel in the hierarchy) can all be described by the same
Thoughts on Partitioning Large-Scale Configuration Problems
46
principle of connectingtwo ports. In the case of the mounted-on
relation, an artificial port called
’mountedon’ of the frameis necessary to act as counterpart of port ’01’ of the rack.
compl t
Rack
I
name=’R:XU’ I
width=800
I [
attributedescr
portl
port2
mounted_on
~mLnted
comp2 !
name=’F’.XU-A’
width=798
max_load=20
attributedescr
(a) port-to-portconnection
FIGURE 1.
on
Frame
Frame
EEI----- name=’F’.XU-A’
width=798
plugP001 plugP078
max_load=30
(b) example
of a port-to-portconnection
Components
and Connections
Thebasic possibilities and structures of a configuration domainare defined in a component
catalog. The componentcatalog stores
* the componenttypes in a class hierarchy,
. for each component
type: the set of attributes, the set of ports, the set of constraints restricting the attribute values and port-to-port connections(see Section 2.2).
A configuration networkcontains a full description of the system to be configured. It depends
on the configuration application which tasks maybe performedto handle and manipulate a
configuration network, e.g.
. checkif all the constraints on the configurationare satisfied,
° changethe configuration by interactions via a user interface,
. completeor change(parts of) the configuration network with solving procedures (like backtrack search in a CSPor highly specific, application-dependentconfiguration routines).
2.2 Constraint
networks
In general terms, a constraint is a condition whichrules out inconsistent or unwantedconstellations. Thetypes of constraints typically range from such basic rules like
Thoughtson Partitioning Large-Scale Configuration Problems
47
"Slot ’01’ of a component
of type ’R:XU’
mayonly containcomponents
of type’F:XU-A’."
(C1)
to highly complexconditions reaching over several connection levels like
"All the modules
mounted
on a frame,whichitself is mounted
on a rackof type’PcXU’,
musthavethe samevalueof attributeservice."
(C2)
It is beyondthe scope of this paper to describe details of different types and properties of constraints. Aconstraint is extensionally represented as an object with links to all the components
and ports involved into the constraint condition. E.g. constraint (C1) is propagatedto the rack
component,its port ’01’ and the connectedframe, while constraint (C2) is linked to all modules
mountedon a frame, the frame itself, and the rack wherethe frame is mountedon.
Consequently,whengenerating and propagating all constraints in a configuration network, a
secondnetwork- the so-called constraint network- is built on top of the configuration network,
wherethe nodes are the individual constraints, connectedto the componentsand ports of the
system. Figure 2 showshowa configuration graph is augmentedby a constraint network. The
port objects and with them the connections betweentwo componentsare depicted as simple
lines here.
I--7
component
.........
port-to-portconnection
O constraint
FIGURE
2. ConfigurationNetworkandConstraintNetwork
Wedistinguish in our frameworkbetween configuration network and constraint network. By
handling these networksseparately, weare able to apply specialized proceduresto the constraint
network.
Thoughts on Partitioning Large-Scale Configuration Problems
48
A constraint network can be used in various ways. Themain tasks a user maycarry out on a
constraint networkare:
¯ Consistencycheck: checkif all the constraints of the confgurationor part of it are fulfilled.
° Solving: automatically extend a (possibly empty)configuration to achieve additional requirements, whichare formulated by special constraints.
¯ Explanation: explain whya given configuration is inconsistent by showingall the constraints
that havefailed.
2.3 Exemplaryapplication domain
Our configurator has to deal with system sizes whichlet "naive" representation and solving
methodsrun into serious performanceproblems (both with time and memory).Weuse a telecommunicationsystem to outline howmanyelements are there in a large configuration problem. (Weare presenting approximatenumberswhichwere slightly simplified for the sake of
clarity.)
There are 20 types of racks, 50 types of frames, 200 types of modules,50 types of cables, and
50 types of other ’organizational’ units. Eachcomponenthas 5 attributes. Eachrack has on
average 10 ports, a frame50 ports, a module1 port, a cable 2 ports, and each other unit 5 ports.
Eachport has a port domainwhichis a constraint on its own.Thereare 5 constraints at a typical
rack, 10 constraints at a frame, 1 constraint at a module,1 constraint at a cable, and 5 constraints
at an other unit. Onaverage, half of the constraints cover 5 componentsor ports, the other
constraints coveting typically 10 componentsor ports (thus, manyconstraints establish quite
complexrelationships).
A large configuration comprises 200 racks, 1000 frames, 30,000 modules, 10,000 cables and
2000 other units. Summing
it up, the configuration network comprises about 43,000 components with 215,000attributes and 112,000ports. At run-time, all the constraints associated with
a componentin the configuration wouldbe instantiated, thus yielding appr. 61,000 constraint
instances havingappr. 450,000references to componentsor ports. (In addition, there are lots of
internal data structures usedin the constraint solver.)
2.4 Difficulties foundin large-scale configuration problems
Building the full networks(for componentsas well constraints) to solve the problemmay
consumetoo muchmemory,thus preventing the application of configurators on smaller computers like typical PCs. Anotherwayto handle this problemis the usage of a database system.
But wehave learned in our project that it is not easily feasible to keep and maintain the
constraint networkas data in the database. Changesmademanuallyvia a user interface or tasks
like copyingparts of an other configuration into the project makeit impossible to maintain the
Thoughtson Partitioning Large-ScaleConfigurationProblems
49
constraint networkover the time. Onthe other hand, to build the wholeconstraint networkin
workingmemoryfor a large configuration is practically impossible.
¯ Whenthe computationof the solution to a large-scale problemlasts too long, users are left in
the dark about wherethe bulk of computationeffort arises.
In theory there are optimal solutions to configuration problems.In practice the task of writing
and testing the componentcatalogue (knowledgebase) often becomestoo complexto be carded
out with the wholesystem in mind. For the sake of feasibility, the knowledgeengineer has to
break downthe tasks into smaller portions.
Summing
it up, most ’interesting’ configuration problemstend to be large-scale. Therefore, the
configuration networks growto remarkable sizes and techniques must be considered to keep
handling, solving and checkingof these networkspractically feasible.
3 Ideas from our approach
3.1 Partitioning a configurationnetworkinto packages
To tackle large-scale configuration problems, we resort to ’divide and conquer’. Wepropose
dividing the configuration networkinto smaller pieces and solving these pieces one by one. We
call each piece a package, reflecting the assumptionthat solving a packageis an own,isolated
sub-process.
Thedefinition of the partitioning of a configuration networkand a constraint networkinto packages is simple: A package consists of a set of componentsand ports; each componentand each
port belongs to at least one package. Let P be the set of componentsand ports a constraint is
propagatedto. Theconstraint simultaneouslybelongs to all packagesof all objects of P.
Figure 3 showsthe partitioning of our exampleconfiguration network (Figure 2) into two packages. Package2 in this exampleincludes the configuration plus a constraint network, while for
package1 the constraint networkis not generatedin this situation.
To be effective, the partitioning into subproblemsas indicated aboverequires that the dependencies betweentwo packages are low. Thus, the numberof port-to-port relations betweentwo
packages and the numberof cross-package constraints should be near zero. The standard
constraint solving procedure has to be modified to join together the results from packagesand
deal with cross-packagerelationships. (Of course, these cross-packageconstraints maylead to
heavyre-configurations of early packages, wheninvalid decisions are madethere but considered not until the second packagehas been done. Weargue that it dependson the quality of the
partitioning and on goodsolving heuristics to makesuch inefficiencies Ul~likely.)
Thoughts on Partitioning Large-Scale Configuration Problems
5O
!i!i
iiiii
iiiiiiiiiii
ii!iiiii
iiii!
iiiii!i!
ii!iiii!iiiiiiiiiiiiiii
iiiiii
i !iiiiiiiiiiiiii!
!ii
!iiiiiiiiiii!iiiiiiiiiiiiiiiiiiiiiiii
iiiiii
iiiiiiiiiiii
!!!iiii
iiiiiiiiiiiii!iiiii
!iiii!iii
iiiiiiiiiiiii!!!
iiii
iiiiiiiiiiii
a!i
component
port to port connection
O constraint
¯ cross-packageconstraint
FIGURE3. Packages
Usually, the partitioning of a configuration probleminto packagescomesnaturally from the
structure of the system to be configured. A humanexpert whoconfigures a system by hand is
able to identify packagessuited for configuring step by step. Moreover,complexsystems must
be designed to be configurable. Andone such criterion is modularstructure, whichentails the
partitioning into packages. If a systemis not designedin a modularmanner,configuration is a
nightmareanyway.Oneof the key tasks during the developmentof a configurator is to find
packagessuitable for automatic check and solve routines accepted by the user.
It is also an interesting problemto find methodsfor automatically partitioning a configuration
network (described in a generic mannerby the componentcatalogue) using graph theory. Yet,
computationally optimal packages(if they can be found at all) need not coincide with packages
expected by the user, thus leading to problemsof understanding. Onthe other hand, the packages ought not to repeat the inefficiencies of existing guidelines carried out by hand.
3.2 Packages control
the configuration
process
After packageshave been identified, they should form a graph whichleads the user through the
configuration process step by step. Apackage graph is a networkwherethe nodes are the package identifiers. There is an arc betweentwo packages,if there is at least one cross-package
constraint connecting the packages. The package graph serves as action-plan. Each package
represents an action to be done to carry out the full task. Anexampleis presented in Figure 4.
Thoughts on Partitioning Large-Scale Configuration Problems
51
[ System Units [
I
I
, I i .... i o.......... ......
[ CablesXU-YG [
[Cables XU(intern)]
[CablesYG(intern)]
V’----qpackagefinished
E
packageto-be-checked(changed)
packageto-be-checked(neighborchanged)
FIGURE
4. Package Graph
A given package is in one of the following states: finished, to be checked due to changes in the
package itself, to be checked due to changes in a neighbor package. The state is presented in the
user interface.
Packages need not be configured in a predefined sequence, yet this is often the most convenient
and most efficient path through the package network.
Changesin one package can affect lots of other packages, thus requiring their re-check. Widerange effects of changes are propagating relatively slowly through the package network.
4 Outcomes and conclusions
4.1 Advantages
If packages are well designed, they break down the problem into manageable subproblems.
Packages lead the user through the configuration process and present intermediate states of the
solving process in a clear manner. If the packages match the user’s concepts of the solving
process, the user will have more trust in the results produced by the configurator. Users who
have expert knowledge in the domain often want to be more involved in the solving process.
Packages are one step forward to involve the user more closely in that.
Thoughtson Partitioning Large-Scale Configuration Problems
52
Theimportant task of maintaining a configuration is supported by packages. Local changes, i.e.
changes in a single package, do not require the consideration of the whole knowledgebase any
more.
In case of restricted computerresources, e.g. small main memory,the constraint networkmay
be generatedjust for the packagecurrently dealt with by the constraint solver. After having
finished and unloadedone package, the next one is loaded.
Manyfiltering, solving, and optimization methodsare computationallyexpensive, so their
applicability is restricted to problemsof reasonable size. To break downthe sizes of the portions
opens the door for a wide range of constraint satisfaction techniques whichwouldotherwise be
awfully overchargedon the full, huge networks.
4.2
Further
work
As packagesare closely related to the design conceptsof the system, criteria for a design to be
configurable promiseadvantages for a simpler configuration process.
Methodsfor finding a goodpartitioning automatically, e.g. based on graph theory, could support
the developmentof configurators.
Bringingtogether the users’ needs (what suits thembest for solving their tasks) while designing
a workingconfiguration system will be the greatest challenge in developingconfigurators.
References
[1] R.Cunis, A.Giinter, I.Syska, H.Bode,and H.Peters. PLAKONan approachto domain-independent
construction.In Proc. Intl. Conf.on Induslxial and EngineeringApplicationsof AIand ExpertSystems 0EA/AIE-89),
Tullahoma,Tenn., June 1989.
[2] RinaDechterand JudeaPearl. Treeclusteringfor constraintnetworks.Artificial Intelligence,
38:353-366,1989.
[3] GerhardFleischanderl, GerhardFriedrich, Alois Haselb6ck,and Marl<usStumptner.KnowledgebasedConfigurationof SwitchingSystems.In Proc. 15th Intl. SwitchingSymposium
(ISS-95),
pp.158-162,Berlin, April 1995.
[4] M.Heinrichand E.W.JiJngst.A resource-basedparadigmfor the configurationof technical systems
frommodularcomponents.In Proc. IEEEConf. on AI Applications (CAIA-91),pp.257-264,1991.
and EugeneC. Freuder. Thecomplexity of somepolynomialnetworkconsis[5] AlanK. Mackworth
tencyalgorithmsfor constraintsatisfaction problems.Artificial Intelligence,25:65-74,1985.
with applicationsto constraints pro[6] Itay Meiri, RinaDechter,and JudeaPearl. Tree decomposition
cessing. In Proc. 8th NationalConf.on AI(AAAI-90),
pp.10-16,Boston,Mass., Jul./Aug. 1990.
Thoughts on PartitioningLarge-Scale Configuration Problems
53
[7] Sanjay Mittal and Felix Frayman.Towardsa generic modelof configuration tasks. In Proc. llth Intl.
Joint Conf. on AI (IJCM-89), pp.1395-1401, Detroit, Mich., Aug. 1989.
- A Tool for Constraint-Based,
[8] MarkusStumptner, Alois Haselb6ck, and Gerhard Friedrich. COCOS
DynamicConfiguration. In Proc. IEI=.E Conf. on AI Applications (CAIA-94), pp.373-380, San Antonio, Tex., Mar. 1994.
Thoughts on Partitioning Large-Scale Configuration Problems
54