Configuration
Papers from the Workshop at ECAI 2002
Workshop n°4
Michel Aldanondo, Chair
22-23 July 2002
15th European Conference on Artificial Intelligence
University Claude Bernard of Lyon 1 (UCBL)
National Institute of Applied Sciences (INSA)
Lyon - France
i
ECAI 2002 Configuration Workshop
Organizing Committee
Michel Aldanondo. Ecole des Mines d'Albi Carmaux, France
Gerhard Friedrich. University Klagenfurt, Austria
Eugene Freuder. University Col ege Cork, Ireland
Markus Stumptner. University of South Australia, Australia
Timo Soininen. Helsinki University of Technology, Finland
Program Committee
Michel Aldanondo, Ecole des Mines d'Albi Carmaux, France
Claire Bagley, Oracle, USA
Boi Faltings, Swiss Federal Institute of Technology, Switzerland
David Franke, Trilogy, USA
Felix Frayman, Felix Frayman Consulting, USA
Gerhard Friedrich, University Klagenfurt, Austria
Esther Gelle, ABB Corporate Research Ltd., Switzerland
Laurent Geneste, Ecole Nationale d'Ingénieurs de Tarbes, France
Albert Haag, SAP AG, Germany
Daniel Mailharro, ILOG SA, France
Klas Orsvarn, Tacton AB, Sweden
Barry O'Sullivan, University College Cork, Ireland
Carsten Sinz, University of Tuebingen, Germany
Timo Soininen, Helsinki University of Technology Finland
Markus Stumptner, University of South Australia, Australia
Bei Yu, Baan/Invensys, Denmark
Special thanks
Paul Gaborit, Ecole des Mines d'Albi Carmaux, France.
ii
ECAI 2002 Configuration Workshop
Contents
E-Configuration Enterprise, A New Generation of Product Configuration System /1-4
Bei Yu
Configuring Software Products with Traditional Methods-Case Linux Familiar /5-10
Katari na Ylinen, Tomi Mannisto and Timo Soininen
Configuration for mass-customisation and e-business /11-16
Ying-Lie O
Empirical Testing of a Weight Constraint Rule Based Configurator /17-22
Juha Tiihonen, Timo Soininen, Ilkka Niemela and Reijo Sulonen
Knowledge Compilation for Product Configuration /23-26
Carsten Sinz
Ideas for Removing Constraint Violations with Heuristic Repair /27-29
Gottfried Schenner and Andreas Falkner
Configuration Tools and Methods for Mass Customization of Mechatronical Products /30-32
Udo Pulm
Optimal Configuration of Logical y Partitioned Computer Products /33-34
Kevin R. Plain
Vehicle Sales Configuration: the Cluster Tree Approach /35-40
Bernard Pargamin
Constraint-based Product Structuring for Configuration /41-46
Barry O'Sul ivan
A Student Advisory System: a configuration problem for constraint programming /47-49
Kevin McDonald and Patrick Prosser
Problem Decomposition in Configuration /50-55
Diego Magro, Pietro Torasso and Luca Anselma
A multi-perspective approach for the design of configuration systems /56-62
Lars Hvam, Jesper.Riis and Martin Malis
Using Knowledge-Based Configuration for Configuring Software ? /63-65
Lothar Hotz and Andreas Gunter
iii
Experiences with a procedure for modeling product knowledge and building product
configurators - at an American manufacturer of air conditioning equipment /66-70
Benjamin Hansen and Lars Hvam
Fuzzy Case Based Configuration /71-76
Laurent Geneste and Magali Ruet.
Distributed generative CSP framework for multi-site product configuration /77-81
Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach and Markus Zanker
Semantic Configuration Web Services in the CAWICOMS Project /82-88
Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach and Markus Zanker
A joint Foundation for Configuration in the Semantic Web /89-94
Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach, Markus Stumptner and Markus
Zanker
A Subsumption-Based Configuration Tool for Architectural Design /95-100
Dan Corbett
TCP-Nets for Preference-based Product Configuration /101-106
Ronen I. Brafman and Carmel Domshlak
Neural networks to approximate data collection or computer code in constraint based design
applications /107-112
Eric Bensana and Taufiq Mulyanto
Representing Software Product Family Architectures Using a Configuration Ontology /113-118
Timo asikainen,Timo Soininen and Tomi Mannisto
Customizing the Interaction with the User in On-Line Configuration Systems /119-124
Liliana Ardissono, Alexander Felfernig, Gerhard Friedrich, A. Goy, Dietmar Jannach, M.Meyer,
G.Petrone, R.Schafer, W.Schutz and Markus Zanker
Deployment of Configuration in Industry: Towards a load estimation 125-130
Michel Aldanondo and Guillaume Moynard
iv
ECAI 2002 Configuration Workshop
Preface
Configuration tasks can be defined as designing a product individual using a set
of pre-defined component types while taking into account a set of well-defined
restrictions on how the component types can be combined. Product configuration
problems are present in many domains: manufactured product (machine,
computer, furniture...), networks (telecommunication, transportation systems...),
service (banking, travel...) and software (ERP, CRM...). Computer programs called
configurators, using AI techniques such as constraint satisfaction, its
extensions, description logic, logic programs, rule-based systems and different
specialized problem solving methods, can support it.
The ECAI 2002 workshop on configuration is the fifth in a series of workshops
started at the AAAI 1996 Fall Symposium and continued at the AAAI 1999
Orlando USA, ECAI 2000 Berlin Germany and IJCAI 2001 Seattle USA. The
goals of these workshops are to promote high-quality research in configuration
and strengthen the interaction between industry and academia. The industrial
interest in the field is indicated by the increasing number of configurator
vendors. The importance of configuration has expanded as more companies use
configurators to efficiently customize their products for individual customers.
Combined with e-business solutions they have a high market impact and generate
new business opportunities in many industries for new products and new ways to
interact with customers.
However, efficient development and maintenance of configurators require
sophisticated software development techniques. AI methods, more than ever,
are central to designing powerful configuration tools and to extending the
functionality of configurators. The working notes of this workshop gather
contributions dealing with various topics closely related with configuration
problem modeling and solving. The 25 papers demonstrate both the wide range
of applicable AI techniques and the diversity of the problems and issues that
need to be studied and solved to construct and adopt effective configurators.
Michel Aldanondo
Ecole des Mines d'Albi Carmaux
v
E-Configuration Enterprise
A New Generation of Product Configuration System
Bei Yu *
1 CONFIGURATION TECHNOLOGY
The need is to have a configurator that combines more ways of
Configuration technology (see Figure 1) is first and foremost the
stating relations, calculations and constraints into one modeling
underlying concept for representing a product or a service that has
environment with infinite solution space. It should be 100% de-
features or parts to be configured. This structured representation is
clarative allowing for the handling of very big and complex prob-
called a product model. Configuration technology is the modeling
lems without programming. This is the only viable way for the
language and maintenance environments that simplify the creation
product to stay maintainable when handling more complex con-
and maintenance of a product model.
figuration issues.
Second, configuration technology is the runtime inference en-
Supporting general business needs in today's environment en-
gine/solver that enables the end user to make correct configura-
compass supporting the globalization both from a modeling and a
tions based on the model in an ingenious and intuitive fashion.
deployment point of view. Specific points that support the global-
ization are object-oriented modeling, concurrent modeling, table-
Available parts
Parts and features
Final product to
based constraints, and separate UI data.
and features
organized in model
be sold
In the configuration process, the system guides the user to the
selections that can be made in order to get a solution at the end
based on the principle of "complete deduction". This allows an
interactive real-time guided configuration processes with no
rework and a deliverable solution. For the customer or the sales
rep this means instantaneous feedback on any selection made,
even in complex product and pricing environments. This accurate
overview and guidance is particularly important when a customer
is ordering in an unassisted mode e.g. via the web.
Mode
ling Configuration
Figure 1. Visualization of the Modeling and Configuration processes.
The overall strategy is to produce 100% shrink-wrapped soft-
ware for a large variety of configuration problems, mainly in
CRM applications using the same modeling methodology.
This paper describes a new approach to product configuration
methodology.
2 THE BUSINESS CHALLENGE
One of the most critical challenges for companies that implement
configuration and web-enabled products is to address both the
usability and maintenance issues at the same time.
When talking configuration as part of the business processes
there are three main issues to consider:
1. Can I implement a configurator that can be maintained in a
way that fits my organizational structure, without having the
update process to be a bottleneck?
2. Can I deploy a solution that supports customers needs and
my general business needs (interactive and fast response
time) - and will it be able to scale to fit future needs?
3. Will the tool provide 100% correct configuration - always?
---------------------------------------------------------------------------------
*Baan CRM, Hřrkćr 12A, DK-2730 Herlev, Denmark.
E-mail: byu@baan.com
1
3 MASS CUSTOMISATION
This section only highlights the system kernel features.
The user-friendly interface for modeling and configuration
The philosophy around mass customization is to sell custom-
could be shown through the demo session.
ized solutions to customers who are willing to pay extra to get
a custom-made order. At the same time, the batch size in the
production process shall be optimized, by producing standard
4.1 CAVA
items and assembling these components to make the unique
product for the customer. By using this business philosophy
To encompass all configuration problems - especially those
the companies can optimize the turnover and at the same time
that are very large and dynamic - a new modeling technology
minimize the production cost maximizing the profit to the
called CAVA has been designed and constructed. CAVA is a
benefit of both the company and the customers.
configuration modeling language. The CAVA language is
This means that some Engineer-to-order companies can
aiming at a standard configuration modeling language that is
move into made-to-order, and thereby minimize production
able to encompass all configuration problem domains [3].
costs. Also, some standard-components manufactures can
This unique language is certainly the first step towards the
offer their customers special solutions, moving into assemble-
ambitious goal. It is able to describe almost all configuration
to-order to maximize their turnover.
problems within very complex products in large companies.
The configuration component is a very important part of
The CAVA modeling language is declarative and con-
this Mass Customization philosophy, where the customer
straints based. The expressiveness of constraints is able to
needs can be linked to the available offerings - and thereby
perform reasoning about identifiers, booleans, integers, reals,
generate the foundation for the fulfillment process (Customer
strings, databases, and functions.
needs -> List of components + component dependencies ->
Typically, different configuration domains require differ-
Production routes/schedule -> Delivering the products).
ent tools and technologies. Today's commercial applications
are strongly focused on tools and technologies that address
the specific problems of these specific configuration domains
4 E-CONFIGURATION ENTERPRISE
[3]. For a growing number of businesses, this is not where the
added value of configuration is found. CAVA outlines the
E-Configuration Enterprise is the solution for configuration
foundation for common modeling approach through all
problems in real life. It fulfills the user interaction require-
applications.
ments given by [1]. E-Configuration Enterprise, as the new
The main issue with all configuration solutions is to get
generation of our configuration system, has unique features
enough expressiveness so that the real world products can be
compared with the previous systems [2], such as:
expressed in a model. However, there is a tradeoff issue with
all existing methodologies, which either makes it easy to
1. A brand new configuration modeling language;
maintain and limit the expressiveness or have a large expres-
2. Object-oriented modeling approach;
siveness but nevertheless will make the maintenance a hard
3. More intuitive product description/modeling;
task.
4. Wide-range covered constraint expressions;
5. More powerful inference engine.
High
E-Configuration Enterprise consists of product modeling
environment (Modeler) and configuration environment (Con-
No known efficient en-
figurator) both PC-based and Web-based. In the Modeler, the
gine exists
user can make a product model and a User Interface (UI)
Database
model, and tables, if necessary. These are wrapped into a
M
package, which can be loaded into the Configurator for con-
ai
Spreadsheet
E-Configuration
figuration processing(see Figure 2).
ntai
Enterprise
nabi
lity
Configurator
Modeler
VB C++
Product
User
Model
Confi
High
Tables
Low
Model
Interface
package
guration
Language expressiveness
Figure 3. Compromised position E-Configuration Enterprise
Figure 2. E-Configuration Enterprise product configuration concept.
The Model Package holds all information generated by the Modeler
CAVA is a compromise between maintainability and lan-
and used by the Configurator.
guage expressiveness (see Figure 3). CAVA sets out to cross
the boarderline that has prevented tools from overcoming this
tradeoff. The tradeoff is mainly due to limitations on the
2
computational aspect of configuration problems namely that
The advantage is to be able to maintain parts of a model
they by nature are very difficult (NP-Hard). However, recent
without risk of overwriting other changes made at the same
progress within new algorithms and hardware performance
time in other parts of the model.
has made it possible, combined with a set of unique patented
technology, to cross this line.
4.6 Separation of product data and UI
4.2 Object-oriented modeling
The product data describes the features and options and the
relations between them, where the UI data describes how the
Object-oriented modeling means that the product model data
product data is being shown to the user at run time. By sepa-
is made of components (classes), which can be reused by hav-
rating the product data and the UI data, it is possible to make
ing several copies (instances) of this component (class) in
several UIs for the same product data. This can be beneficial
another component (class). For example, in a bookcase (a
if the same product data is used in different environments, for
class) there can be a number of shelves (copies of a shelf
example, a UI for the direct sales force and another UI for the
component class). In the product model, the shelf component
partners/dealers in an indirect channel.
is only defined once, and then used in the bookcase compo-
nent n times.
Another concept in object-oriented modeling is "inheri-
4.7 Web standard based and Web-enabling
tance". This means that a component (class) can inherit fea-
tures from another class so that it appears as if the class in fact
When the UI is created, a UI Builder transforms the user in-
has these features. This is a very powerful feature when creat-
terface definitions into HTML. If needed the HTML page can
ing a product family hierarchy. For example, a bookcase can
then be modified using any HTML editor.
be either a classic bookcase or a modern bookcase, where
The integration is based on industry standard XML both
some special features are added to the specific kind of book-
when exchanging model information and when exchanging
case, while still having the basic bookcase components de-
data.
fined only once. The inheritance principle is very useful in
E-Configuration Enterprise is a web-based thin client
order to reduce model data redundancy and thereby increase
product, and the only application needed to make a configura-
the maintainability of the model.
tion is a web-browser. On the server side, using the extensive
XML-interface or the COM-interface can make integration to
business solutions.
4.3 Table based constraints
The product model can use data in relational tables/databases
4.8 Activations - user and situation dependent
to define product feature relationships. These tables can be
models/UI
either internal (defined in the model) or external (defined in
an external database), from where data is read by the Configu-
Activations can be used to enable or disable features and con-
rator. This will allow the owner of the product model to have
straints. These activations can be based on time (Time activa-
product relations/constraints defined in a database that can be
tions), for example price offer period, or situation (Group
applied to the user environment without having to re-compile
activations), such as country availability. This can be used to
the product model.
hide or deselect features that some users are not allowed to
From a maintenance perspective, this is a good example for
see, or features that are unavailable at the time of configura-
CAVA to show how easy it is to maintain constraints. Rather
tion. Hiding means that the option does not show up in the UI,
than writing hundreds of constraints, a table structure with
where deselect means that this option is not available
one binding will make these constraints redundant.
(dimmed at the UI).
4.4 Hard and soft constraints
4.9 Trace and Alternatives
Hard constraints are relations that have to be fulfilled in order
to have a consistent model and/or configuration, where soft
The Trace mechanism is supposed to help a modeler to under-
constraints are relations that can be violated or changed. Soft
stand the "why" questions, such as, why a value was moved
constraints are prioritized so that it is possible to apply differ-
from a variable; why a variable was bound to a value; why an
ent soft constraints for the same feature. A soft constraint can
instance was created as well as why a contradiction exist. This
be used as pre-defined defaults. For example, when a user
information is intended to assist the model engineer during
selects the color of a car, the color of the interior is set to
modeling.
match the color of the car. However, this can be overruled if
The Alternatives is a service which 1) helps the end-user to
the user wants another color.
make a selection that otherwise would lead to a contradiction,
and 2) helps the end-user solve a contradiction.
The information given to the end-user is the same in both
4.5 Support for concurrent modeling
cases, i.e., user selections that need to be released.
The product model, including the UI, can be maintained by a
number of people, where the ownership for the different parts
of the model is assigned to more than one person.
3
4.10 Scalability for large models
tion problems across whole business processes from engineer-
ing, manufacturing to sales and marketing.
Due to the principle of "Field of Interest" the Configurator
has good runtime response time and performance for large
models.
5 SUMMARY
The Field of Interest concept means that the Configurator
will first verify or deduct selections in the pages or instances
Issues like usability, maintainability, and optimal time to mar-
that are shown to the user, and second verify or deduct on the
ket are often considered contradictions when the business
rest of the model. In this way, the Solver can maximize the
solution involves a configuration component. The demand for
support given to the user should it be interrupted before it has
providing fast, correct, and complete information to custom-
searched all features in the model.
ers and channel partners while keeping costs under control is
just one of the contradictions. If companies want to effec-
tively solve this dilemma, they need to be using new tech-
4.11 Complete deduction
nologies to solve these problems.
E-Configuration Enterprise contains a unique and patented
Complete deduction in the Solver/Inference Engine is based
technology that effectively addresses all issues of configura-
on a patented method [5], which is the foundation for the
tion. The separation of the product data and the UI makes it
uniqueness of our configuration technology. Complete deduc-
possible to link the configuration model to other user interface
tion allows the people doing the modeling to focus on indi-
components, including third party web controls, that address
vidual constraints for each object in the model. The system
the UI needs for the company.
will then secure the complete solution overview, i.e. make
E-Configuration Enterprise is a compelling software com-
sure that the model is consistent. This brings down both im-
ponent that easily integrates into business solutions.
plementation and maintenance times by reducing the number
The open architecture will provide integration with web-
of constraints you have to implement by a factor of 10 to100,
based solutions, as well as APIs for other integration pur-
compared to other technologies.
poses.
E-Configuration Enterprise is the first step into a new
world of configuration, while not burning any bridges to pre-
4.12 Deduction levels
vious solutions.
In the Configurator, the user can set maximum response time
before the Solver is interrupted and the result is presented to
the user. Depending on the size and complexity of the model
ACKNOWLEDGEMENTS
the Solver will not have time to reach the highest level of
Although I am solely responsible for the paper, all developers
accuracy, but will stop at some lower level at timeout.
who are involved in the project contributed to the success of
There are six deduction levels that the solver can reach:
the E-Configuration Enterprise. I would also like to thank
Accepted, Propagate, Look-ahead, Solution, Unbound, and
Mette Nyberg and Beverly Poulsen from the Documentation
Complete. The Solver works sequentially at one level at a
department for their help with formatting and reviewing the
time starting with Propagate and ending with Complete. This
paper.
means that if a certain level has been achieved then the deduc-
tion levels below have also been achieved.
Because of the nature of reals however, using reals in the
model does not necessarily remove every invalid value from
REFERENCES
the model.
[1] F. Frayman, User-interaction Requirements and its implications
for efficient implementations of interactive constraint satisfaction
4.13 Infinite solution space
systems, Workshop Proceedings on User-Interaction in Con-
straint Satisfaction, International Conference on Constraint Pro-
The user can dynamically add components and/or parts at run
gramming and Logic Programming (ICLP'01), p31-41, 2001.
time, and the selections around these are validated as an inte-
[2] B. Yu and H.J.Skovgaard, A configuration tool to increase prod-
uct competitiveness, IEEE Intelligent Systems and Their Appli-
grated part of the product model. For example, the users can
cations. July/August 1998.
at run time select the number of shelves in a bookcase, and
[3] S. Mittal and F. Frayman, Towards a generic model of configura-
subsequently configure each shelf individually. This dynamic
tion tasks, in Proceeding of the 11th International Joint Confer-
extension of the components in the solution often leads to a
ence on Artificial Intelligence (IJCAI), 1395-1401, 1989.
multilevel configuration solution.
[4] D. Sabin and R. Weigel, Product configuration frameworks a
survey. IEEE Intelligent Systems and Their Applications,
July/August 1998.
4.14 Integration to entire business solution
[5] G. Mřller, Signal Processing Apparatus and Method. Patent WO
90/9001.
E-Configuration Enterprise, as one key component, has been
integrated into company business solution offerings. Con-
figuration issues nowadays cannot be considered independ-
ently, but will have to relate to other business issues in a
company. Such integration capabilities make the configura-
tion system more powerful in terms of solving all configura-
4
Configuring Software Products with Traditional Methods
Case Linux Familiar
Katariina Ylinen1, Tomi Männistö1 and Timo Soininen1
Abstract. Recently, the software industry has begun to adopt a
configuration problem and present an analysis of the configuration
product family approach. Support tools for tailoring configurable
knowledge for the product in section 3. We present a way to model
product families have been developed for some time for mechanical
the configuration knowledge of the case product using a language
and electronics products. However, it is not clear that the modeling
for modeling traditional products in section 4. The findings of our
languages designed for these configurators are suitable for software
case study are presented and discussed in section 5. Finally, in sec-
product configuration. In this paper, we investigate this problem by
modeling a Linux Familiar operating system distribution with a
tion 6 we present our conclusions and identify some topics for fur-
configuration modeling language aimed at representing the structure
ther research.
of physical products. Findings from this case study suggest that the
language is largely suitable for software product configuration.
2 BACKGROUND
However, some phenomena in the product strongly suggest that
modeling them as functions, features or resources and optimality
This section briefly describes the domains of product configuration
criteria familiar from the configuration domain would be useful. In
in both traditional industry and in the software industry and then
addition, there is some evidence that deeper modeling of versions of
compares the frameworks used in them to find their similarities and
components and reconfiguration knowledge, not usually covered by
differences.
configuration models, should be supported.
2.1 Physical Product Configuration
1 INTRODUCTION
For a configurable product family, each product individual is
Configurable product families have been an important phenomenon
adapted to the requirements of a particular customer order on the
in the mechanical and electronics product domains for some time.
basis of a predefined configuration model, which describes the set
In these domains, called traditional products for short, it has been
of legal product variants [6,7]. A configuration, that is, a specifica-
noted that it is possible to satisfy a wide range of customer require-
tion of a product individual is produced from the configuration
ments with relatively low costs by designing the products to be
model and particular customer requirements in a configuration task.
routinely configurable. Systems that support tailoring such prod-
Knowledge based systems for configuration tasks, product con-
ucts, configurators, have been extensively developed and studied
figurators, are an important application area of artificial intelligence
[4]. Recently, the software industry has to some extent adopted the
techniques for companies selling products adapted to customer
point of view that designing software product families and deliver-
needs [9,10]. Product configuration tasks and configurators have
ing variations of them rather than customizing individual products
been investigated for at least two decades [11].
can be far more cost-effective [1]. However, it is not clear that
Conceptualization of configuration knowledge synthesizing
configurators supporting traditional products are suitable for soft-
these approaches is reported in detail in [7,17].
ware product configuration. The software community has ap-
proached product families from a different perspective and
developed its own modeling methods and methods for tailoring the
2.2 Software Product Configuration
products [15,16] .
In this paper, we investigate whether there are any differences
The software professionals often claim that the methods and proc-
between the two domains of traditional products and software by
esses of traditional industry do not apply to software development
means of a concrete case study. We try to model a Linux Familiar
and products. It has been suggested that the product configuration
operating system distribution [13] with a configuration modeling
concepts and methods used for the physical products are not directly
language aimed at representing the structure of physical products
applicable in the software industry [2]. According to Brooks [6],
[11, 14]. The three research questions we ask are: Is the configura-
software has four special features that make it special: complexity,
tion modeling language adequate for representing the Familiar
conformity, changeability and invisibility.
configuration knowledge? If not, what are the most important miss-
Even though modern physical products may also be complex and
ing elements? And finally, which of the common concepts used for
invisible in nature, they are constructed of a limited number of parts
modeling configurable traditional products [5] could be used to
that are replicated. In a software product variant, there are usually
make the models more useful?
no two parts equal to another.
The rest of the paper is organized as follows: We first briefly review
In the past, much of the configuration-related software manage-
and compare the two domains of product configuration and soft-
ment research has focused on the software configuration manage-
ware families and analyze their similarities and differences in sec-
ment (SCM). In SCM, the focus has primarily, although not
tion 2. We then present the case product and the related
completely, been on managing the evolution of the source code files
1 Helsinki University of Technology, Software Business and Engineering
Institute SoberIT, P.O. Box 9600, FIN-02015 HUT, Finland. Email:
{Katariina.Ylinen, Tomi.Mannisto, Timo.Soininen}@hut.fi
5
[7]. Most SCM systems today only manage the software systems as
packages in the system. In Debian, this program is called dpkg and
a set of files instead of as configurable product components [7].
it manages configuration constraints like dependencies and conflicts
The research of configuring final software products has only re-
between packages, virtual packages and installation order. It can
cently become an increasingly important challenge while the indus-
also be used to create and purge packages.
try has slowly adopted a goal of producing product families instead
Due to the size constraints dpkg is not a part of Familiar but a
of single products. A related field, which aims at modeling product
lighter version of it called ipkg has been developed. Ipkg shares the
families, is the research on architectural descriptions [17]. Even
basic functionality in package installation and removal but lacks
though the primary goal of ADLs has not been the product configu-
most of the configuration validity functions. Therefore, the com-
ration task, it can be noted that they have adopted significantly
parison with the traditional configurator is made against dpkg fea-
similar concepts as the traditional configuration research.
tures. Familiar packages are equipped with configuration
While formal methods for software product configuration have
information of the same syntax, and they can still be used as an
been absent, there has been separate efforts for configuring single
example of the input data.
products. Most of the software companies implement configurabil-
The configuration language of Familiar / Debian is fairly simple.
ity by producing one big product with all variants included. The
It is a list of the package information in pure text format. There are
configuration task is then done using, for example, preprocessor
two fields attached to all packages: version and the package name.
directives or makefiles to define the specific product variant [2].
In addition, it lists all constraints known for the package. The con-
Another result of software invisibility is that in software prod-
straint clauses also refer to a package name and optionally to its
ucts, it is often impossible to know the correct order of installation,
version. An example of the fields concerning configuration in a
if there are limitations to this. This may often be as complex in the
Familiar package description:
physical products as well. The difference lays in the usage soft-
ware products are often installed at the same time as they are con-
Package: xlibs
figured. The installation and configuration process is, especially in
Priority: optional
consumer products, assumed to happen at the same time and at least
Version: 4.0.2-13
semi-automatically. This has led to a situation where installation
Replaces: xlib, xbase (<< 3.3.2.3a-2), xlib6 (<< 3.3.2.3-2)
programs do the configuration and vice versa.
Provides: libxpm4
The adequacy of the configuration knowledge present in the
Depends: xfree86-common (>> 4.0), libc6 (>= 2.2.1-2)
packages of Debian distribution has been a subject for study before
Conflicts: xlib, xlib6 (<< 3.3.2.3-2), xlib6g (<< 4.0)
[3, 12]. The approach has been developing a new rule-based lan-
Figure 1
guage for modeling the packages and dependencies, and then im-
plementing this using a logic-program-like rule based system. We,
The different types of these packages is explained in more detail
on the other hand, aim at applying the high-level modeling concepts
in section 3.1. The nature of the different relationships between the
of physical product configuration to modeling Linux Familiar.
packages is analyzed in section 3.2.
3 FAMILIAR CONFIGURATION PROBLEM
3.1 Package
Types
Linux Familiar was chosen as the case since it is developed for a
Currently, three types of packages can be identified in the system.
handheld computer, Compaq iPAQ, and therefore faces resource
The package types are virtual, concrete and task packages.
limitations, such as the amount of memory available. Whereas op-
A virtual package is an abstract package that does not actually
erating systems on PCs can be installed with all bells and whistles
exist and, the functionality of which can be provided with one or
included, the handheld devices make prioritization of installed
more concrete packages. The virtual packages do not appear on the
components necessary. There are currently about 1700 Familiar
package lists as package definitions and therefore cannot have rela-
packages available in the distribution, only a subset of which fits
tionships to other packages. Instead, some of the concrete packages
into a device at the same time. The packages vary in nature from
refer to a virtual package as they provide its functionality.
necessary Linux kernel packages to application packages. Linux
In Debian, the developer community strictly controls the virtual
was chosen instead of other handheld operating systems due to its
package names and the full list of available virtual packages can be
openness, as it was easier to study.
found at the developer web site [10]. The same virtual package
Linux is a monolithic operating system. The part implementing
names are used in Familiar, although it seems that the control is a
the core functionality of the operating system such as the thread
bit lighter and there are some additional, non-documented ones as
management, file system etc. is called the Linux kernel [9]. The
well. An example of a typical definition of virtual package (x-
kernel itself is an interesting entity from the configuration perspec-
terminal-emulator) in a Familiar package description looks like this:
tive, since it has built-in support for dynamic reconfiguration. How-
The concrete packages are the actual packages that can be in-
ever, this feature has been implemented for mainly memory
stalled or uninstalled on the device and that have relationships to
management use and is left out of the scope of this paper. We focus
other packages on the system. The concrete packages consist of one
our attention on package management, that is, a higher-level con-
or more files to be saved on the file system. These files can be ei-
figuration management of the whole distribution.
ther executables or other files, for example text files.
The Familiar Distribution is derived from the Debian distribu-
The third package type, task package, is a package that consists
tion, which means the configuration attributes share the same con-
of several other packages. It has no own separate functionality but
cepts. Both distributions consist of a large amount of software
just the collection of the packages it contains. The package does not
components, called packages. Packages consist of several files,
withhold any important functionality itself but has several depend-
which can be either executables or other files as well. In Debian, as
encies to other packages, so that installing the package requires then
well as in most widespread Linux distributions, there is a package
installing the whole set. The task packages seem to consist of a set
management system, which manages the installation and removal of
of different packages that together implement certain functionality.
The task packages in Familiar are separated from concrete packages
6
with a naming convention. The package names have prefix "task-".
ticed, it is highly probable that it only has been declared in the de-
The task packages are made to make basic installations easier for
scription of one of the packages but not in both. This means that
the end user by collecting a potentially important set of related
either the conflict information must be duplicated to both of the
packages into one package.
package descriptions or the functionality of dpkg should be changed
so that it would check all package descriptions of the packages
3.2 Relationships
installed on the system to check the configuration validity.
Provides has been designed for managing packages, which in
As mentioned earlier, the package descriptions include constraint
some way implement functionality available in some other package.
Unlike the other configuration clauses, the provides has been used
clauses. Every package has a listing of these as presented in exam-
ple in figure 1. The clause first describes the nature of the relation-
quite systematically but it has two different tasks. One of them is
ship and then a list of package names and their versions.
the usage for version control when package naming has changed
during versions. The newer version provides the older one, and it
There are seven different kinds of constraint types:
seems that the potential dependencies from other packages to the
· Depends <package B> - this package requires package B to
older version will not get broken. Provides allows the coexistence
be installed on the device to function correctly.
of the provided and the providing package in a configuration. In the
· Pre-depends <package B> - it is required that package B is
case of renaming an existing package when making a new version,
installed on the device before this package can be installed.
it must be separately specified with a conflict clause that the ver-
sions should not be present in a configuration at the same time.
· Conflicts <package B> - this package should not be present
Provides is also used for virtual packages several concrete
in the same configuration with package B.
packages can provide some virtual package functionality, and many
· Provides <package B> - this package provides all the func-
of them can coexist on the configuration [3]. For example, a con-
tionality and files present in package B.
crete package rxvt, which is an emulator program emulating the x-
terminal, has a row: "Provides: x-terminal-emulator" in its package
· Replaces <package B> - the installation of this package re-
definition. The x-terminal-emulator is a virtual package, and pack-
moves or overwrites files of package B.
ages like rxvt (a basic x-terminal emulator) or rxvt-aa (an x-terminal
· Recommends <package B> - the package B is recommended
emulator with anti-aliased fonts support) could coexist on the sys-
tem both implementing the virtual x-terminal emulator package.
when it is presumable that the users would like to have it in
the configuration with this package.
An example of the virtual package use of Provides in Familiar
package description is presented in picture 2.
· Suggests <package B> - the package B is suggested to get
better use of the package.
Package: rxvt
Of these, the constraints recommends and suggests are not
Version: 1:2.6.3-8-fam6
relevant for checking the configuration validity but only useful hints
Provides: x-terminal-emulator
for the user for configuration optimization. It can be also noted that
Depends: libc6 (>= 2.1.97), xlibs (>= 4.0.1-11)
the pre-depends clause is used to gain correct installation order
Conflicts: suidmanager (<< 0.50)
but does not differ from depends when used to check the configu-
ration validity.
Package: rxvt-aa
For all the different relationships, there can be many packages
Version: 1:2.6.3-8-fam6
listed and in that case the relationship holds for all the packages in
Provides: x-terminal-emulator
the list. That is, the commas between the package names can be
Depends: libc6 (>= 2.1.97), xlibs (>= 4.0.1-11), libxft, libxrender
interpreted as Boolean AND. For depends, there can also be a
Conflicts: suidmanager (<< 0.50)
Boolean OR, which is indicated by " | " in the list. The precedence
Figure 2
rules are not very clear and we are not sure for which elements the
OR statement refers to in some occasions. It is not, however, a big
Replaces is quite ambiguous and is therefore used in various
problem since there are not many OR statements currently in the
ways, some of which can be clearly interpreted as designer errors. It
package descriptions.
is also the most dangerous one in use, since there is no such system
Depends is a simple relationship. When a package depends on
functionality that would remove the replaced package beforehand.
another, the other must also be installed on the system. When
As there is no proper information on which way the replacement
checking the configuration validity, pre-depends is also treated the
exactly takes place, there is no guarantee on what will happen to the
same way.
files installed originally with the package being replaced. In prac-
There are also some interesting exceptions in the use of "De-
tice, the replacement is therefore only used in some cases when user
pends" relation, which we consider more or less misuse and not
tries to install two conflicting packages. In these cases, when one of
usage rules. For example, the package xlibs depends on its own
these packages is marked as replacing the other, the installer in
older version. This means there are also some incremental packages
Debian prefers the replacing one [3].
the newer version is not actually a new version of the package but
Replaces is used, as already stated, very differently in different
some additional features for it.
packages. In some packages, it is used similarly as provision clause.
Conflicts is just as simple. When a package is in conflict with
As the replacing package should replace, by definition, some of the
another, they should not be installed on the same system. There is,
files of the replaced package, it is also dangerous that there is no
however, a minor problem in the language and the configurator,
solution so far for the case when a user would try installing the
dpkg, considering this. As a package is installed in the system, only
replaced package back to the system. The replacement clause is
the relationships of the installed package are checked. In case there
again only written in the other package and thus overwriting the
is a package in the system conflicting this new package, it may not
same files back again would most probably break the system. This
get noticed. This is due to the fact that as the conflict has been no-
may be one reason for the fact that the replacement has not been
7
often used in actual replacing of packages. One example of an un-
one supertype package, of which all packages are subtypes. Pack-
explainable use of this relationship is the package set util-linux
age is an abstract component type with one property, version,
(2.11b-2-fam2), fileutils (4.0.43-1) and shellutils (2.0.11-5). Both
which is of value type string. Both concrete and virtual packages are
fileutils and shellutils replace an older version of util-linux. Still,
subtypes of this component type. It is a subtype of the root compo-
they seem not to provide the functionality specified in the util-linux
nent type of the language, Component.
description. There are no other relationships between these pack-
The virtual component types are defined as abstract, as there
ages.
should be no occurrences of component individuals of them in a
We conclude that the most common use for replacement is that
valid configuration. The conceptual meaning of the abstract compo-
the replacing package provides at least some of the functionality of
nent is seen as the same as that of the virtual package. All the vir-
the replaced one, but it is not promised that it works the same way.
tual packages are modeled as subtypes of the Package component
This means the dependencies from other packages to the replaced
type. The concrete packages implementing a virtual package, are
package will get broken when it gets replaced, unlike in the case of
subtypes of the virtual package in question. Other concrete pack-
provision. This cannot, however, be generalized for all packages
ages will all be subtypes of the component type Package.
due to the very varying use of the concept.
Some of the data on the packages that is needed on configuration
time are modeled as properties for concrete packages. These are
priority, size, installed-size, and version. Priority will be modeled
4 FAMILIAR
AFTER MAPPING
with the concept of cardinality. When a package is obligatory (pri-
In this section, the new configuration model for Linux Familiar is
ority: required), its cardinality is 1 and when optional, it is 0 to 1.
introduced. The syntax of the used language is presented in section
Virtual packages will not have these properties since this informa-
4.1 and the mapping of components and relationships are presented
tion is not available for them.
in sections 4.2 and 4.3, respectively.
4.3 Relationships
4.1 Modeling
Language
Relationships between the packages are modeled as constraints in
We use a language based on a subset of a general configuration
the configuration model. The relationships are translated as follows:
ontology [5] to try to model the Familiar configuration information
to gain understanding of how suitable the concepts of the language
A Depends B
constraint <constraint_name> A implies B
are for modeling software.
A Pre-Depends B constraint <constraint_name> A implies B
The used language, called PCML, is introduced in [11]. The
A Conflicts B
constraint < constraint_name> not (A and
main concepts of PCML are component types, their compositional
B)
structure, properties of components, and constraints. Component
A Provides B subtyping, A is a subtype of an abstract
types define intensionally the characteristics (such as parts) of their
(virtual packages) component type B
individuals that can appear in a configuration. A component type is
A Provides B subtyping and conflict, A is a subtype of B
either abstract or concrete. Only an individual directly of a concrete
(change of name and constraint <constraint_name> not (A
type is specific enough to be used in an unambiguous configuration.
between versions) and B)
A component type defines its direct parts through a set of part defi-
nitions. A part definition specifies a part name, a set of possible
As many of the relationships also involve version numbers, they
part types and a cardinality. A component type may define proper-
must be taken into account in the constraints. Constraints involving
ties that parameterize or otherwise characterize the type. A property
version numbers are modeled as the following example demon-
definition consists of a property name, a property value type and a
strates (conflict):
necessity definition. Component types are organized in a taxonomy
A Conflicts B (>= 2.2.1)
or class hierarchy where a subtype inherits the property and part
constraint <constraint name>
definitions of its supertypes in the usual manner.
not(A and B and
Constraints associated with component types define conditions
<part name for B>.B:version >= "2.2.1")
that a correct configuration must satisfy. The first level building
blocks of the constraint language are references to access parts and
4.4 A
Sample
properties of components, and constants such as integers. Refer-
ences can be used in succession, e.g. to access a property of a part.
Figure 3 presents a sample of the model created with PCML:
Boolean returning tests are constructed out of references, constants,
and arithmetic expressions. Tests also include predicates that allow
checking if a particular referenced individual exists or is of a given
configuration model TestModel
type. Property references can be used with constants in arithmetic
expressions that can be compared with the usual relational operators
# The concrete package type
to create a test. Test can be further combined into arbitrarily com-
component type Package
plex Boolean expressions using the standard Boolean connectives.
abstract
subtype of component
property version value type string
4.2 Components
# The virtual package x_terminal_emulator
The component types we define for Linux Familiar configuration
component type x_terminal_emulator
are the package types we identified in section 3.1. In addition, we
abstract
define a component type defining the whole system, of which the
subtype of Package
packages are parts. We define a type hierarchy, in which there is
8
# Package rxvt implementing x-terminal-emulator
really is big for software products in general and what sort of chal-
component type rxvt
lenges this may present for the modeling task. In our case, there
subtype of x_terminal_emulator
were no complex and large version spaces, which means that no
property version
conclusions could be done of the issue.
value type string constrained by $
Modeling conflicts was easier using PCML. For example, the
in list ("1:2.6.1", "1:2.6.3-8-fam6")
modeling of conflicts was simplified. The model then became more
. . .
manageable as the problems presented in section 3.2 ceased to exist.
component type OSystem
The usefulness of cardinality of packages in software configura-
tion was questioned when the mapping of the concepts was made.
part x_terminal_emulator
In this case, there were only optional and required packages and
allowed types x_terminal_emulator
therefore a concept of optionality could be used instead of cardinal-
cardinality 0 to 1
ities. On the other hand, modeling distributed systems may require a
more elaborate cardinality, as a component type may be instantiated
constraint only_one_version_rxvt
(i.e., installed) on several different devices. Thus, we cannot con-
present(x_terminal_emulator) and
clude that cardinality would be useless for software configuration
x_terminal_emulator individual of rxvt
modeling.
and x_terminal_emulator.rxvt:version
In the case of a handheld device, a concept for modeling the con-
= "1:2.6.1"
figuration size would have been useful. In PCML, Such a concept is
Figure 3
not present and some problems can be expected when the disk of
the device becomes full. The size information was available for all
In this example, we use the same virtual package as in figure 2,
the packages but there were no means used to calculate the configu-
`x_terminal_emulator. Two concrete packages, rxvt and rxvt-aa,
ration size in this case study. However, the resource balancing
implement its functionality. There are two versions of each avail-
based approach to modeling incorporated into the ontology of Soin-
able, but for a valid configuration, only the older version of rxvt is
inen et al [5] could be useful to capture this phenomenon.
accepted.
5.1 Problems and Challenges Raised in Our
5 DISCUSSION
AND FUTURE
WORK
Mapping
Linux Familiar does not represent the configuration aspects of all
We faced a few challenges when modeling Linux Familiar package
software products. However, it is an easily studied real-world ex-
descriptions with PCML. We next discuss the challenges with the
ample of configurable software. On the basis of the modeling ap-
modeling and the challenges with the input data in more detail.
proach defined earlier, it seems that the methods of physical product
Dangling references and reconfiguration. In the package de-
configuration are at least partially applicable to software products as
scriptions of Linux Familiar, there were a remarkable number of
well. The differences between these domains are not so remarkable
references to packages, which were not present in the package list.
that entirely new methods and modeling languages need to be de-
PCML does no allow references to non-existent parts, and thus,
veloped for software configuration.
such constraints were simply removed. This did not produce a prob-
Using a modeling language like PCML seemed adequate for
lem for the configuration task, as the relationships were mainly
modeling the most important aspects of Linux configuration. The
conflicts and the conflicting, lacking package was not available to
ability to model virtual packages as entities on their own with rela-
be installed to the device. However, this becomes a problem for the
tionships to one another can be considered a good additional fea-
reconfiguration task. The package list of Familiar distribution is on
ture, as long as we have correctly understood the concept. If,
the Internet and it only lists the packages currently available. Pack-
however, the virtual package concept has been developed for de-
ages that are no longer available are removed from the list. When
scribing the functionality offered by different packages, modeling
reconfiguring the system, the new package to be installed may have
them as features or functions [5] could be more useful. Those con-
a conflict with a package already installed on the device but no
cepts correspond semantically better to what seems to be modeled
longer listed in the model. In this case, the conflict would be ig-
with virtual packages and provide more flexibility in defining rela-
nored according to our model and it would be possible to install an
tionships between virtual and concrete packages. For now, as each
invalid configuration. This is an issue that needs further studies.
virtual package is implemented by one package only (although there
Feature modeling. There were some packages included in Fa-
are several alternatives), it can be stated that the use of abstract
miliar, whose names started with "task-". These packages consisted
component types and subtyping is a reasonable choice. This should,
of a set of different packages to make some basic installations easier
however, be studied further.
for the end user. For example, package task-x includes all the pack-
On the basis of this case study, there is no indication that the dif-
ages that together implement the Linux graphical user interface
ferences between the traditional industry and software domains,
called X. They should be studied further, as it seems that they pro-
referred to by Brooks [6], are of big relevance with respect to prod-
vide a form of feature or function modeling.
uct configuration. Invisibility, conformity and complexity did not
Installation order. There were no means to model this informa-
have an impact in the case product. On the basis of this single case
tion using PCML. When modeling the Familiar package listing with
study, it seems that changeability may be more important and a
PCML, the installation order part of the information of disappeared.
difference between the domains. A single software component can
It can be argued that the installation process is separate from the
easily have quite a large number of versions. However, Linux is
configuration process and that the information should not be in the
somewhat a special case in this respect as more functional versions
model in the first place. However, in the case of software, it can be
are released for users than in a typical commercial software product.
claimed that these processes are commonly intertwined and the
Therefore, it should be studied further if the number of versions
separation should not be done. In addition, modeling the informa-
9
tion on installation order seems to be closely connected to recon-
from the configuration domain, would increase the understandabil-
figuration, as it is essential to capture the configurations and the
ity and usefulness of the models. In addition, there is some evidence
transitions from one configuration to another. This topic requires
that deeper models of versions of components and reconfiguration
further work.
knowledge, not usually covered by configuration models, should be
Configuration optimization. In section 3.2, the package rela-
supported. In addition to researching these modeling questions, the
tionships recommends and suggests were briefly mentioned. These
case study should be continued by completing the model and by
can be seen as related to configuration optimization. One solution
empirically testing its validity and the efficiency of the configurator
[12] would be to install the packages recommended and suggested
support. In order to investigate whether the findings of this case
every time a package recommending them is installed. This strategy
study can be generalized, more software products from different
of maximizing the configuration is not the best solution when con-
application domains should also be investigated.
figuring software for handheld devices. The limited size of the
device does not encourage installing all recommended and sug-
gested packages automatically without consulting the user. On the
ACKNOWLEDGEMENTS
other hand, simply ignoring these relationships and thus minimizing
We gratefully acknowledge the financial support of Technology
the configuration, as was done in our approach, leaves this informa-
Development Centre of Finland and Academy of Finland (grant
tion totally unused. It should be studied further in which way the
number 51394). In addition, we thank Juha Tiihonen and Andreas
information should be used appropriately.
Anderson for providing the configurator used in this research and
Replacement, reconfiguration. We also left out the concept of
for their help in using it.
replacement from our model. The input data varied so wildly with
regard to this respect and we could not reliably conclude what
meaning the replaces relationship should be given. The main inter-
REFERENCES
pretations is, as explained in section 3.2, that the replacing package
[1] J.Bosch, Design and use of software architectures - adopting and evolv-
provides the functionality of the mentioned package but also over-
ing a product-line approsch, Addison-Wesley, 2000.
writes it at least partially. This operation then may break existing
[2] T.Männistö, T.Soininen, and R.Sulonen, `Modelling configurable prod-
dependencies from other packages. In addition, if the user wants to
ucts and software product families', in: IJCAI'01 Workshop on con-
install the replaced package back on the system, again rewriting
figuration, 2001.
some files, she may break the whole system as the replaces relation-
[3] T.Syrjänen, A rule-based formal model for software configuration.
ship is only defined in one direction. In this case study, we did not
Master's thesis.(2000). Helsinki University of Technology:
research this problem further and we see this as a reconfiguration
[4] D.Sabin and R.Weigel, `Product configuration Frameworks--A survey',
problem to be studied.
IEEE intelligent systems & their applications, 13, 42-49, (1998).
Implication and reconfiguration. Using classical implication to
[5] T.Soininen, J.Tiihonen, T.Männistö, and R.Sulonen, `Towards a General
model the depends relationship does not seem to correspond to the
Ontology of Configuration', AI EDAM, 12, 357-372, (1998).
[6] F.P.Brooks, No silver bullet -- Essence and accident in software devel-
way dpkg operates. When user removes a package from the system,
opment, IFIP, 1986.
dpkg checks that the removal does not break any existing depend-
[7] J.Estublier, `Software configuration management: A roadmap', in: Pro-
encies. However, the packages installed initially just to satisfy the
ceedings of 22nd International Conference on Software Engineering
constraints of this package, normally due to depends- relationships,
(ICSE00), The future of software engineering, ACM Press, 2000.
remain on the system. After a while, it is possible that the system
[8] T.Syrjänen, `Version spaces and rule-based configuration management',
consists of a large amount of packages, which have no justification
in: IJCAI'01 Workshop on configuration, 2001.
for their existence. In a system with limited size, they easily waste
[9] I.T.Bowman, R.C.Holt, and N.V.Brewster, `Linux as a case study: Its
resources. In order to capture this justification aspect, a new
extracted software architecture', in: Proceedings of ICSE'99, 1999.
connective is needed in the constraint language that has similar
[10] http://www.debian.org/doc/packaging-manuals/virtual-package-names-
properties as the rules in the weight constraint language used for
list.txt
[11] J.Tiihonen, T. Soininen, I. Niemelä and R. Sulonen, `Empirical testing
formalizing configuration knowledge in [14].
of a weight constraint rule based configurator' In Proceedings of the
Input version numbers. The version numbering of Familiar is
ECAI Workshop W02 on Configuration, 2002
quite versatile and due to the many different conventions in use, it is
[12] T. Syrjänen: `Optimizing Configurations' In Proceedings of the ECAI
possible that in some cases a simple string comparison of version
Workshop W02 on Configuration, 2000
numbers may produce false results. This is, however, a problem that
[13] http://handhelds.org/familiar/
can only be solved by changing the version numbering conventions
[14] T. Soininen, I. Niemelä, J. Tiihonen and R. Sulonen. `Representing
and cannot be simply solved by a modeling language.
Configuration Knowledge With Weight Constraint Rules'. In Proceed-
ings of the AAAI Spring 2001 Symposium on Answer Set Program-
ming: Towards Efficient and Scalable Knowledge Representation and
6 CONCLUSIONS
Reasoning, 2001.
[15] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee, 'The
We have presented a case study of modeling a configurable soft-
Koala Component Model for Consumer Electronics Software', IEEE
ware product family, Linux Familiar, with a configuration modeling
Computer, 33, 78-85, 2000
language designed for representing the structure of a physical prod-
[16] K. Czarnecki and U. W. Eisenecker, Generative Programming, Addi-
uct. Findings from this case study suggest that configuration model-
son-Wesley, 2000
ing of a software product can be carried out to large extent using
[17] N.Medvidovic and R.N.Taylor. `A classification and comparison frame-
such a language. Thus it can be used as a basis for modeling and
work for software architecture description languages', IEEE Transac-
configuring software product families without a need to develop a
tions on software engineering, 26, 70-93, 2000
radically new language for this purpose. However, there remain
some important areas where further research is needed. In the case
product, some phenomena strongly suggested that modeling them as
functions or features, resources and optimality criteria, familiar
10
Configuration for mass-customisation and e-business
Ying-Lie O
Abstract. Mass-customisation and e-business impose new require-
E-business should provide additional value by employing AI. In-
ments on trading. In mass-customisation, products are variations of
stead of directly selecting the parts, the customer should be able to
configurations in a product family. Model-based configuration can be
specify characteristics of the intended product. In reply, a quote with
seen as a combination of product modelling and solving the configu-
several top-most approximately matching products are offered. The
ration problem.
products are ordered according to their "goodness of match", indicat-
The product model can be presented using modelling constructs.
ing the non-matching characteristics. This approach requires a suit-
Different constructs allow different kinds of selection. Instead of re-
able product modelling, and a suitable problem solving method.
quiring the customer to choose from technical specifications, under-
standable characteristics are used.
2
PRODUCT AND CONFIGURATION MODELS
The problem solving part is finding the configuration by a com-
bination of selection and approximate matching. An incremental ap-
Product modelling and configuration have been around for some time
proach allows customer interaction. At each step, the customer may
to support manufacturing. It is used for design, production, and ser-
select components and characteristics. In the resulting matching, the
vice of the product during its life-time. Product data management
list of components and non-matching characteristics are indicated.
and product models describe the product at certain stages "as is". The
The proposed approach is attempted to be simple, such that cus-
configuration problem is finding the combination of product compo-
tomers can understand the proposed solutions of the specified char-
nents such that it matches the product requirements.
acteristics.
2.1
Product models
1
INTRODUCTION
There are many product modelling methods, some are specifically
Nowadays, there is an increasing demand on products to customers
tailored for a certain industry or family of products. Most product
order. These products are not fully tailored in the conventional way,
models represent the hierarchical composition of the product. The
but are "variants". This is called mass customisation, involving vari-
bill of materials (BOM) gives the composition of an individual prod-
ations in a product family. There are three types of compositions:
uct. Each component is represented by a code or serial number. Asso-
ˇ
Pick-to-order is providing the components selected by the cus-
ciating the components of the BOM with its functional descriptions
tomer. The customer is responsible for making the product ready
[9] gives a more detailed description. The BOM can be extended to
to use. Example: Home AV (audio-video) systems are sound sys-
support choices in assemble-to-order products [3] by including the
tems, television sets, and combinations of these intended for non-
list of possible components.
professional use in an average size living room.
STEP (Standard for the Exchange of Product Model Data) is a
ˇ
Assemble-to-order is assembling of products according to cus-
conceptual standard for representing the configuration of individual
tomers configuration from components. Example: Office comput-
products based on standard data. The STEP method and the specifica-
ers are computer systems for one or more persons for office work
tion language EXPRESS is useful for the definition of general mod-
in an office or at home.
els of products [2], including product variants [8]. The EXPRESS
ˇ
Make-to-order is the production to customers specification ac-
language can be mapped to the object-oriented UML (Unified Mod-
cording to existing product type definitions. Example: digital
eling Language) [1].
printworks are the preparation, printing, and postprocessing of a
document or artwork to a printed product using professional digi-
2.2
Configuration models
tal printing equipment.
Configuration systems are mainly intended for supporting the man-
Mass-customisation and e-business impose new requirements on
ufacturing process, in particular product design. These systems are
trading. Customers must be able to specify their requirements on-
mainly focussed on problem solving [5]. There are many product
line without knowing details of product design and technical speci-
configurations methods [10]. Early systems were rule-based systems,
fications. Mostly, the customer has to select a specific product type
but the number of rules tend to explode, and the relation between
first, and then select the desired parts from lists. In reply, a quote
rules and components of the product are not as clear.
with the matching product is offered. This situation is far from being
In model-based systems, there is a separation between knowledge
customer-friendly. It is even difficult to compare a number of simi-
about components and the way it is used. Commonly used logic-
lar products. In a shop, products are on display along with the most
based methods are description logics and the constraint-based sat-
important specifications.
isfaction problem. A combination of these methods is a rule-based
˘
University of Twente, Enschede, email: ying@cs.utwente.nl
language equipped with description logics [11].
11
Model-based configuration can be seen as a combination of prod-
product family
uct modelling and reasoning to solve the configuration problem. A
structured modelling procedure [4] by decomposition and analysis
of assembly relations allow detailed specification.
product type
A conceptual model for the configuration of mass-customisable
products employing the UML notation has been proposed by [6].
It includes consistency and validity checks and can be automatically
translated to an executable logic representation for a knowledge base.
part
subassembly
3
CONFIGURATION MODEL FOR
MASS-CUSTOMISATION
ready part
produced part
Product configuration is a combination of product modelling and
solving the configuration problem. In most configuration systems,
machine
production
design
customers must enter product specifications and select components
from detailed lists. This requires sufficient knowledge about the
material
tool
product. Instead, customers should be able to specify their require-
ments. To get more precise, a terminology is employed. The termi-
Figure 1.
General model of the configuration of a product family
nology, or more general ontology can be extracted from existing e-
consisting of metaclasses
business data [7] such as online catalogs. Unfortunately, most of the
results regard terminology for component names, component brands,
and technical specification.
8
A rectangle represents an object class by its name. A class consists
The product characteristics is an intermediate between the cus-
of objects, while a metaclass indicated by the
signs
9
9
@
@
tomer requirements and product specification
consists of classes. Metaclasses are used to represent the product
Ł
¤
¦
¨
¨
"
$
¨
&
'
¨
¦
'
Ł
¨
Ł
)
"
'
¦
3
4
'
¦
5
¦
Ł
7
and component families. Product and component models are given
Each component has a number of characteristics. The characteristics
by classes, the products are the object instances.
specified by the customer are matched to that of the components. The
8
The second compartment in a divided rectangle gives the at-
resulting configuration is an instance of a product type.
tributes of the class. The product characteristics are represented
This model is specifically intended for mass-customisation, thus
by attributes.
limited to variations of a product family. In most product configu-
8
The hollow triangle
and circle
on the connecting line rep-
B
C
rators, the complete set of characteristics must be specified before-
resent shared generalisation. Child components inherit properties
hand. Here, an incremental approach at selection level is proposed.
from the parent component. The letter "d" (disjoint) in the circle
This approach allows customer interaction and update of the require-
indicates that there may be only one child in an instance. In the top
ments. At each step, the customer may select components and char-
layers of a product model, a product family is divided into product
acteristics. The proposed approach is attempted to be simple, such
types using disjoint generalisation. A product type may consists of
that customers can understand the proposed solutions of the speci-
other product types.
fied characteristics.
Selection components of a part is represented by generalisation. A
part may be ready parts or produced parts.
8
The hollow diamond
and bullet 8 on the connecting line de-
3.1
General model of product families
D
fine aggregation. An expandable composition of components is
Product families are modelled in a hierarchical way. Each product
given by aggregation. A product type consists of subassemblies
family consists of several clearly identifiable product types. This
and parts. A subassembly may consist of subassemblies and parts.
8
should limit the number of possible variations, and thus reducing the
The solid diamond
and bullet 8 on the connecting line represent
E
complexity. The properties of the general model are:
composition, a strong form of aggregation into a composite class.
In product models a composite component is built of subcompo-
8
A product family consists of mutually independent product types
nents that solely belong to that component and the composition
that may consist of other product types.
yields its functionality as a whole. This specific property may be
8
The structure of a product type is a composition of subassemblies
valid for some subassemblies, and is therefore not indicated as
and parts. These components may be ready parts or produced ac-
metaclass in the general model.
cording to specification.
8
A large diamond connected with lines to rectangles represent an
8
Matching of the user requirements to the product specification is
association. The association class is given by a rectangle con-
performed through an intermediate terminology, the product char-
nected with a dashed line. The production of a produced part is
acteristics.
represented by an association of components required in the pro-
8
Each component has characteristics associated to its functionality
duction.
and technical specification.
8
The permitted number of components is specified by the multi-
7
7
8
The customisation is in the selection of components and charac-
plicity as a range of natural numbers. Thus,
means 1 to n,
F
teristics. A component may be mandatory or optional.
7
7
means exactly 1, 7 7
means at most 1.
F
F
G
F
The general model of product families as depicted in Figure 1 em-
The general product model in Figure 1 consists of metaclasses only,
ploys the UML notation for static structure diagrams. The modelling
therefore the
signs are left out. Specific composition
9
9
@
@
constructs are described below.
properties that apply on classes are therefore not visible.
12
3.2
Product characteristics
M
8
J
?
9
?
;
E
;
6
T
J
A
3
G
B
M
V
V
V
M
8
J
?
9
?
;
E
;
6
X
J
A
3
G
B
P
F
C
F
C
On the other hand, the selection of characteristics gives the matching
As an attribute, a characteristic has an identifying generally mean-
components and non-matching characteristics.
ingful name and a domain of possible values as a user-friendly trans-
]
selected characteristics
8
6
?
6
3
4
J
A
3
G
B
K
M
8
6
?
6
3
4
J
A
3
G
B
C
C
lation of the technical specification.
M
8
J
A
3
G
T
B
M
V
V
V
M
8
J
A
3
G
X
B
P
Characteristics are
preferably
objective, and the
domain
Given the
8
6
?
6
3
4
J
A
3
G
B
g
matching components with
C
consists of
comparative terms.
This
makes the
character-
8
J
?
9
?
;
E
;
6
J
A
3
G
B
8
6
?
6
3
4
J
A
3
G
B
K
h
j
P
Non-matching
F
C
`
C
istics invariant to rapid changes, for instance in technology.
characteristics are not present in the set of selected characteristics
1
2
3
4
5
6
7
8
9
4
3
5
;
<
>
?
?
@
<
A
5
>
A
B
in printing gives the resolution of the
l
8
;
?
;
3
6
J
A
J
A
3
G
B
: 8 J ?
9
?
;
E
;
6
J
A
3
G
B
k
8
6
?
6
3
4
J
A
3
G
B
P
F
C
F
C
C
printer and grain size of the paper; 5 D E 8
3
4
4
<
E
@
5
2
<
4
3
G
>
E
B
C
C
F
F
F
This process is alternately repeated on components that have a path
related to a PC disk gives the storage size with respect to current
to the selected product type.
technology; 9 E E @ 8
E
@
5
2
<
I
3
6
<
2
9
E
G
B
specifies the PC com-
C
F
F
C
C
The selection starts with choosing from an index of product fami-
puting power, and is related to the technical specification of the CPU
lies and product types. As in a large department store, customers are
frequency and internal memory.
usually able to find the department of a particular product family.
Inheritance and association of the characteristics are determined
by the modelling constructs. Child components in a generalisation
1. Class-level top-down matching to determine the product types.
inherit properties from the parent component and may have addi-
The requirements of the product types generally regard the in-
tional specialisation characteristics
tended use of the product.
8
J
A
5
4
@
J
A
3
G
B
K
8
9
3
G
E
;
6
J
A
3
G
B
M
8
9
E
J
5
3
4
5
E
@
J
A
3
G
B
P
2. Class-level characteristics from the selected product types are re-
C
C
C
C
C
A composite component has all the characteristics of its subcompo-
trieved and presented for selection. Product types may be dese-
nents
8
J
?
9
?
5
6
E
J
A
3
G
B
K
8
J
?
9
?
;
E
;
6
T
J
A
3
G
B
M
V
V
V
M
lected.
F
C
C
F
C
8
J
?
9
?
;
E
;
6
X
J
A
3
G
B
P
3. Then for each selected product type, advance downwards on class-
F
C
Similar to the composite component, a composition of components
level. This involves tracing the connected paths to the product
has all the characteristics of its selected components. Also similar to
types. The selection procedure is carried out for aggregation con-
the composite component, the produced part has all the characteris-
structs and generalisation constructs.
tics of its associated components.
4. Class-level bottom-up analysis of association classes and compo-
Except for inheritance properties, the scope of the characteristics
sition classes that are connected to the selected classes.
may be global, or local. In the global mode, all characteristics of the
5. Class-level characteristics from the selected components are re-
same name get the same value
trieved and presented for selection. At this stage, characteristics
J
A
3
G
Y
K
3
[
]
components
J
?
9
?
;
E
;
6
J
A
3
G
Y
K
3
P
may be altered locally only for a particular component.
F
In the local mode, it is limited to the selected component. In a gener-
6. Object-level selection from the list of matching objects of all re-
alisation, characteristics regarding the specialisation are always lo-
maining classes.
cal. The mode may be changed during the selection process. For
7. Determine a list of matching product compositions.
instance, the desired colour of a product may be set global at the
beginning, and set to local regarding a specific part.
In the above, in the first three steps, the characteristics are global, and
may become local in the last four steps.
3.3
Selection and matching
3.4
Reconfiguration
The problem solving part is finding the configuration of the desired
Reconfiguration is altering an existing product configuration for re-
product by a combination of selection and approximate matching.
placement, upgrading, or changing the functionality. There are two
The approximate matching problem is formulated as finding the
modes of reconfiguration:
components with the most matching characteristics to the user re-
Addition or replacement of components that does not change the
quirements. This will result in a list of products, that may have sev-
remaining of the existing configuration such as addition of a com-
eral non-matching characteristics. Customisation by selection occurs
ponent in an aggregated class, replacement of a child component in
at three levels:
a generalisation class, or replacement of an object instance. Most of
1. Class-level in aggregation constructs by selection of a combina-
the functionality and global characteristics remain the same.
tion of desired components.
Changes that affect the configuration such as upgrades of an ear-
2. Class-level in generalisation constructs by selection from a list of
lier version of a product type typically regard composition classes
possible components.
and aggregation classes. This can be considered as a change of the
3. Object-level in all classes by selection of an object instance in
product type. Therefore, an "upgrade model" containing the possible
each class.
replacements is required.
Matching the user requirements to the product characteristics are set-
4
EXAMPLES
based operations. Set union M
gives all the characteristics, and set
intersection
gives the matching characteristics.
Each of the composition type is illustrated by a familiar example. To
`
The incremental approach allows (de)selection of both compo-
avoid cluttered diagrams, the models are only partly presented and
nents and characteristics at each step. Non-matching characteristics
detailed. For the same reason, the characteristics that mostly yield
are indicated, allowing the customer to modify the selections.
the "customisation" are indicated by empty compartments. Also, the
The selection of components yields the associated characteristics
multiplicities are left out.
and their value range.
To illustrate the matching process, the most relevant characteris-
]
selected components
8
6
?
6
3
4
J
A
3
G
B
K
M
8
6
?
6
3
4
J
A
3
G
B
tics are presented in tables. In the first table, the characteristics are
C
C
13
described. In the next table, the selection process is illustrated by
2. The choice of AV = audio yields 2 choices, one with a non-
showing the requirements characteristics entered by the customer,
matching characteristic.
the matching product type and associated characteristics.
3. Advancing downwards is rather straight-forward, allowing the se-
lection in "amplifier and loudspeakers" and "CD/DVD players".
4. There are no association classes and composition classes.
4.1
Home AV systems
5. Selection of characteristics, for instance a local value is selected:
"Home AV systems" is an example of pick-to-order products. It is
loudspeaker.quality = good.
6. Selection of stereo amplifiers, loudspeakers, and CD players with
<< product type >>
the selected characteristics.
hom e AV system s
7. The matching products are stereo amplifiers, "loudspeakers (2)",
d
"audio cables (2)", and "CD players" with matching connectors.
<< product type >>
<< product type >>
<< product type >>
audio system s
com bined AV system s
video system s
Table 2.
Example of the selection and matching of home AV systems
am plifier and
requirements
class
characteristics
C D /D VD player
TV m onitor
VC R
loudspeakers
characteristics
of components
AV = audio
audio systems
AV = audio
d
AV systems
AV = audio
stereo
am plifier
quadro
deselect
AV systems
type = CD
CD/DVD player
type = CD
d
type = stereo
amplifier and
type = stereo
loudspeakers
power low, med, high
m
n
loudspeakers
type = stereo
stereo
type = stereo
stereo am plifier
quadro am plifier
quality = good
loudspeaker
quality = good
power = med
power = med
audiocable
connector = RL pin
quality = high
stereo amplifier
quality = high
Figure 2.
Part of the configuration model of home AV systems
power = med
connector = RL pin
audiocable
connector1 = RL pin
connector2 = RL pin
a product type of the product family "AV systems". Usually, com-
ponents have matching connectors. In Figure 2 part of this model is
presented, along with the most relevant part of the characteristics in
Table 1.
4.2
Office computers
A familiar example of assemble-to-order products are "office com-
Table 1.
Part of the characteristics of home AV systems
puters" a product type of the product family "Computers". This prod-
class
construct
characteristics
<< product type >>
multiplicity
constraints
office com puters
home AV systems
product type
use = non-professional
audio systems
product type
AV = audio
AV systems
product type
AV = (audio, video)
<< product type >>
<< product type >>
<< product type >>
peripherals
com puter unit
devices
audio systems
aggregate
AV = audio
CD/DVD player
part
type CD, DVD
m
n
television
part
AV = video
amplifier and
generalisation
type stereo, quadro
m onitors
keyboard
m ouse
printer
scanner
m
n
loudspeakers
1..1
power low, med, high
m
n
stereo
aggregate 0..1
type = stereo
d
quadro
aggregate 0..1
type = quadro
<< product type >>
<< product type >>
<< prodcut type >>
laptop
w orkstation
server
amplifier
generalisation
quality plain, good, high
m
n
power low, med, high
m
n
loudspeaker
part 2..2
quality plain, good
m
n
power low, med
built-in devices
m otherboard
harddisk
housing
m
n
connector = RL pin
stereo amplifier
part 1..1
quality plain, good, high
m
n
d
power low, med, high
m
n
connector = RL pin
board
C PU
m em ory
tow er
desktop
audiocable
part 2..2
connector RL pin, coax
m
n
connector1, connector2
floppy
C D /D VD
ZIP
m ain H D
second H D
In pick-to-order, there usually is an abundance of choices on
Figure 3.
Part of the configuration model of office computers
object-level. Therefore, additional characteristics such as brand, and
colour may help to restrict the choices.
1. The selection starts at the level of home AV systems.
uct type is further divided into specific product types. In addition to
14
the assemble-to-order part, there are pick-to-order parts to combine
5. In the selection of characteristics, the "second HD" has less char-
the configured system with other devices. It is partly represented in
acteristics than the "main HD".
Figure 3, with the most relevant characteristics in Table 3.
6. Object-level selection from all remaining classes. There may be
additional constraints, such as the number of slots for "built-in
devices" and "hard disks" that fit in the "housing".
Table 3.
Part of the characteristics of office computers
7. Find matching "workstations" with fast performance, 2 "hard-
class
construct
characteristics
disks", "tower housing", and the desired "built-in devices".
multiplicity
constraints
office computers
product type
use = office work
computer unit
product type
main unit
4.3
Digital printworks
peripherals
product type
addition
devices
product type
addition
laptop
product type
type = client
<< product type >>
workstation
product type
place = fixed, type = client
digital printw orks
server
product type
place = fixed, type = server
d
workstation
composition
type
built-in devices
generalisation
type flop, CD/DVD, ZIP
<< product type >>
<< product type >>
<< product type >>
cards
book
brochure
o
p
0..*
slot
housing.slot
q
motherboard
composition
type
1..1
insert
cover
board
part 1..1
CPU
part 1..1
speed med, fast, super
bound
o
p
memory
part 1..4
speed med, fast, super
d
o
p
harddisk
generalisation
main HD = 1..1
colour pages
bw pages
hardcover
paperback
1..2
second HD = 0..1
main HD
child 1..1
size small, med, large
o
p
speed med, fast
<< m achine >>
<< design >>
o
p
bw
bw printing
second HD
child 0..1
size small, med
print file
digital printer
o
p
speed med, fast
o
p
<< m achine >>
housing
generalisation
type tower, desktop
<< m aterial >>
<< m aterial >>
<< design >>
colour
o
p
paper
black ink
colour printing
artw ork file
1..1
slot 1..*
digital printer
tower
child
second HD = 0..1, slot = 5
desktop
child
second HD = 0, slot = 2
<< m aterail >>
<< m aterail >>
cover paper
colour ink
Figure 4.
Part of the configuration model of digital printworks
Table 4.
Example of the selection and matching of office computers
requirements
class
characteristics
characteristics
of components
Table 5.
Part of the characteristics of digital printworks
main unit
computer unit
main unit
place = fixed
workstation
place = fixed
class
construct
characteristics
type = client
type = client
multiplicity
constraints
built-in devices
slot = 2
digital
product type
printing = digital
type = CD/DVD
type = CD/DVD
printworks
ink = cartridge
type = ZIP
type = ZIP
book
product type
workstation
type
card
product type
motherboard
type
brochure
product type
board
book
composition
quality plain, good, high
o
p
speed = fast
CPU
speed = fast
insert
generalisation
colour colour, bw
o
p
speed = fast
memory
speed = fast
1..2
quality plain, good, high
o
p
second HD
harddisk
second HD = 1
cover
generalisation
type hard, paperback
o
p
size = large
main HD
size = large
1..1
quality plain, good, high
o
p
speed = fast
speed = fast
bound
part 1..1
if cover.type = paperback
size = med
second HD
size = med
then bound = adhesive
speed = med
speed = med
if cover.type = hard
housing
type = tower
then bound = stitch, sew
o
p
tower
second HD = 1, slot = 5
bw pages
association 1..*
colour = bw
printfile
design
quality = good
paper size A3, A4, A5
o
p
paper
material
quality plain, good, high
o
p
In this example, only the assemble-to-order part is tracked.
paper size A3, A4, A5
o
p
black ink
material
1. The selection starts with "computer unit".
digital printer
machine
colour = bw
2. The choice of place = fixed, type = client yields the only product
cover
association 1..1
colour = colour
type "workstation".
artworks
design
quality = good
paper size A3, A4, A5
3. Advancing downwards only regards the "built-in devices". The
o
p
cover paper
material
quality plain, good, high
o
p
choices of "floppy", "CD/DVD", and "ZIP" require 2 slots.
colour ink
material
colour 3-colour, 6-colour
o
p
4. Composition classes that are connected to "workstation" are
digital printer
machine
colour = colour
"motherboard", "harddisk", and "housing".
15
"Digital printworks" is an example of make-to-order products. It is
A possible improvement of the matching process, is by ranking
a product type of the product family "Press works". Printed pages are
the characteristics in a sequence of importance as a partial order of
generated by printing machines from the file delivered by the user. As
sets t u v w x y z { | } ~
~
t
u
v
w
x
y
z
{
}
partly presented in Figure 4, the product type is further divided into
The selection and matching then becomes a combination of track-
different types. The most relevant characteristics associated to the
ing the paths of selected and associated components, ordering of the
figure are given in Table 5.
characteristics, and matching these ordered characteristics.
Further research should also include consistency analysis of the
Table 6.
Example of the selection and matching of digital printworks
proposed solutions. The method should then be improved to handle
conflicting situations. It should also be investigated, whether addi-
requirements
class
characteristics
tional constraints or rules are needed to maintain consistency in con-
characteristics
of components
flicting situations.
book
book
Another important aspect in the application of this method is
quality = good
book
quality = good
model management. It is expected that if the modelling constructs
colour = bw
insert
colour = bw
quality = good
are applied consistently, then the model definition part will not pose
type = hard
cover
type = hard
any problems. However, problems are expected in the definition of
quality = good
the characteristics. Even using a proper ontology, maintenance is still
bound
bound = stitch, sew
r
s
elaborate. Updates of ontologies, and merging different ontologies is
bw pages
colour = bw
printfile
quality = good
still a research topic at this very moment.
paper size = A5
paper size = A5
It is also of interest to include different ways of representing the
quality = good
paper
quality = good
modelling constructs for specification and implementation. Also, the
paper size = A5
possibilities to extend this simple model to a full product design
black
black ink
model should be considered.
digital printer
colour = bw
hard
colour = colour
artworks
quality = good
ACKNOWLEDGEMENTS
paper size = A5
quality = high
cover paper
quality = high
The author is indebted to Rob van de Weg for his valuable detailed
colour= 3-colour
colour ink
colour= 3-colour
comments, and colleagues of the group of Information Systems for
digital printer
colour = colour
their inspiring discussions.
bound = sew
bound
bound = sew
The UML figures were drawn using TCM (Toolkit for Con-
ceptual Modelling) partly developed by this group, available at
under the GNU General Public License.
The product type "book" is taken as an example to illustrate the se-
u
y
{
z
{
z
{
u
lection and matching in a composite component and produced parts.
REFERENCES
1. The selection of the product type "digital printworks" has been
[1] F. Arnold and G. Podehl, `Best of both worlds - A mapping from
made.
EXPRESS-G to UML', in The Unified Modeling Language, UML'98
2. The product type "book" is selected.
- Beyond the Notation. First International Workshop, Selected Papers,
3. Going downwards only regards this product type.
eds., J. B´ezivin and P.-A. Muller, volume 1618 of LNCS, pp. 4963.
Springer Verlag, (1999).
4. The components in the composite component "book" are related
[2] M. Ashworth, M.S. Bloor, A. McKay, and J. Owen, `Adopting STEP for
by the way it is produced. The associated components in the "bw
in-service configuration control', Computers in Industry, 31, 235253,
pages" and "cover" represent material and settings of the printing
(1996).
process.
[3] J.W.M. Bertrand, M. Zuijderwijk, and H.M.H. Hegge, `Using hierar-
5. Selection of the characteristics of the "bound" is limited by the
chical pseudo bills of material for customer order acceptance and opti-
mal material replenishment in assemble to order manufacturing of non-
choice of the "cover".
modular products', Int. J. Production Economics, 66, 171184, (2000).
6. Object-level selection basically is the selection of the "paper".
[4] P.Y. Chao and T.T. Chen, `Analysis of assembly through product con-
7. Matching products mainly regard the choices in the printing pro-
figuration', Computers in Industry, 44, 189203, (2001).
cess and the use of paper and ink. There may be some matching
[5] B. Faltings and E.C. Freuder, `Special issue on configuration', IEEE
Intelligent Systems, 13(4), 2985, (1998).
between the printing machines and paper type and size.
[6] A. Felfernig, G.E. Friedrich, and D. Jannach, `Conceptual modeling for
configuration of mass-customizable products', Artificial Intelligence in
Engineering, 15, 165176, (2001).
5
CONCLUSION
[7] A. Kayed and R.M. Colomb, `Extracting ontological concepts for ten-
dering conceptual structures', Data & Knowledge Engineering, 40, 71
A simple incremental product configuration method for mass-
89, (2002).
customisation has been proposed. The product model consists of
[8] T. M¨annist¨o, H. Peltonen, A. Martio, and R. Sulonen, `Modelling
modelling constructs for each configuration feature. For customer
generic product structures in STEP', Computer-Aided Design, 30(14),
requirements, characteristics are used instead of technical specifica-
11111118, (1998).
[9] T. M¨annist¨o, H. Peltonen, T. Soininen, and R. Sulonen, `Multiple ab-
tion. The characteristics selected by the customer are then used to
straction levels in modelling product structures', Data & Knowledge
find matching components that have a connection path to the selected
Engineering, 36, 5578, (2001).
product type. The approximate matching is performed using simple
[10] D. Sabin and R. Weigel, `Product configuration frameworks a survey',
set-based methods. The method allows non-matching characteristics.
IEEE Intelligent Systems, 13(4), 4249, (1998).
[11] T. Soininen and I. Niemel¨a, `Developing a declarative rule language
From the examples it is found that in some cases business rules are
for applications in product configuration', in PADL'99 Practical As-
still needed. It should be further investigated how such rules can be
pects of Declarative Languages Proc. First International Workshop,
replaced by a set construct.
ed., G. Gupta, volume 1551 of LNCS, pp. 305319. Springer, (1998).
16
Empirical Testing of a Weight Constraint Rule Based
Configurator
Juha Tiihonen1, Timo Soininen1, Ilkka Niemelä2, and Reijo Sulonen1
Abstract. In this paper we first describe a configurator imple-
rator is empirically tested on batch-mode configuration of these
mentation based on a practically important subset of a synthesized
products. We define a relatively modeling-language-independent
ontology of configuration knowledge. The underlying configuration
method for testing configurators based on the idea of simulating a
modeling language has been provided with a declarative semantics
naďve user inputting random requirements to a configurator. This is
by mapping it to weight constraint rules, a form of logic programs.
accomplished by randomly generating progressively larger and thus
Three issues important for efficiency of the implementation are
addressed: off-line compilation of configuration models, limiting a
more restricting sets of user requirements that are not locally con-
configuration to a finite size in a semantically justified way, and
flicting. Results are given on the number of correct configurations
breaking symmetries in the set of configurations. The second part of
found and the time it takes to find the first and all configurations
the paper takes a step in the direction of thorough empirical testing
satisfying a set of random requirements, or to show that no such
of configurators. We define a relatively modeling-language-
configuration exists.
independent method for testing configurators based on the idea of
The rest of the paper is structured as follows: In section 2 the
simulating a naďve user inputting random requirements to a configu-
modeling language and its semantics are outlined and in section 3
rator. We test the configurator empirically on batch-mode sales
the configurator implementation based on the language is described.
configuration of four real products with progressively larger and
In section 4 the testing method and the case products are described
thus more restricting sets of random user requirements. The results
and the test results are provided. Finally, in section 5 we discuss and
indicate that our configurator is efficient enough for practical use.
compare our implementation and results with related work and in
section 6 we present conclusions and topics for further work.
1 INTRODUCTION
Several formal models of configuration knowledge and tasks based
2 MODELING LANGUAGE
on, e.g., constraint satisfaction problems (CSP) and different logical
formalisms have been proposed, e.g., [1,2,3,4] and implemented,
In this section we briefly describe PCML, the product configuration
modeling language of our configurator, and outline its semantics.
e.g., [4,5,6,7,8]. For several of these, the configuration problem has
been shown to be at least NP-hard [2,4,9,10]. In other words, the
For more information on the modeling language and its implemen-
configuration task requires in the worst case at least an exponential
tation, see http://www.soberit.hut.fi/pdmg/empirical_cfg/ and [2].
The main concepts of PCML are component types, their compo-
amount of time in the size of the problem. However, conventional
wisdom in the configuration community is that solving configura-
sitional structure, properties of components, and constraints. Com-
tion problems is relatively easy and does not exhibit this kind of
ponent types define intensionally the characteristics (such as parts)
of their individuals that can appear in a configuration. A component
behavior. There are some documented results on the efficiency of
configurators [4,6,7,8], but systematic and wide range empirical
type is either abstract or concrete. Only an individual directly of a
testing of configurators on real products that would show whether
concrete type is specific enough to be used in an unambiguous
configuration. A component type defines its direct parts through a
the wisdom is, indeed, wisdom, is still lacking.
In this paper we take a step in the direction of thorough empirical
set of part definitions. A part definition specifies a part name, a
testing of configurators. We briefly describe a configurator imple-
non-empty set of possible part types (allowed types for brevity) and
a cardinality. A component type may define properties that param-
mentation, define a general test methodology for configurators, and
provide results on the efficiency of our implementation.
eterize or otherwise characterize the type. A property definition
Our configurator uses a modeling language based on a practi-
consists of a property name, a property value type and a necessity
definition. Component types are organized in a taxonomy or class
cally important subset of a synthesized ontology of configuration
knowledge [11]. The language has a declarative semantics provided
hierarchy where a subtype inherits the property and part definitions
by mapping it to weight constraint rules, a form of logic programs
of its supertypes in the usual manner.
Figure 1 illustrates the concepts through an example. A server
[2,12]. The configurator uses this mapping to translate the modeling
language to weight constraint rules. It then uses a state-of-the-art
PC has 1 to 2 storage subsystems. There are two kinds of storage
implementation of weight constraint rules, Smodels [12], for com-
subsystems, SSA and SSB. A storage subsystem has 1 to 4 hard
disks. The hard disk types in use are HDA and HDB. This is mod-
puting configurations satisfying user requirements. Three issues
important for efficiency of the configurator are addressed: off-line
eled as follows (the upper part of Figure 1): Concrete component
compilation of configuration models, limiting a configuration to a
type PC has a part definition with part name sto, cardinality 1..2
and allowed type
finite size in a semantically justified way, and symmetry breaking.
SS. Component type SS is abstract and has two
concrete subtypes
We have modeled four real products from a sales configuration
SSA and SSB. SS has a part definition msu (mass
storage units) with cardinality 1 to 4 and allowed type
point of view. The case products are characterized and the configu-
HD. Type HD
1&2 Helsinki University of Technology, Dept of Computer Science and Eng.,
1 Software Business and Engineering Institute, P.O.B. 9600, FI-02015 HUT
2 Lab. for Theoretical Computer Science, P.O.Box 5400, FI-02015 HUT
1&2 {Juha.Tiihonen, Timo.Soininen, Ilkka.Niemela, Reijo.Sulonen}@hut.fi
17
is abstract and has two concrete subtypes HDA and HDB. The lower
in the Model manager loads a PCML configuration model and
part of Figure 1 shows a configuration where individual pc-1 of
checks it for consistency. This includes parsing the PCML file, type
type PC has as a part with part name sto two storage subsystems of
checking expressions and checking the configuration model for
type SSA (ssa-1 and ssa-2). The individual ssa-1 has as a part
validity with respect to the language specification. The Smodels
with part name msu one hard disk of type HDA (hda-1), while ssa-
interface in Model manager translates the configuration model to a
2 has as a part with part name msu one hard disk of type HDA (hda-
WCRL program. Data structures representing the PCML configura-
5) and one hard disk of type HDB (hdb-5).
tion model are saved for later use. The generated WCRL program
includes sentences for ontological definitions, component type
sto [1..2]
SS
msu[1..4]
PC
HD
hierarchy, compositional structure, properties, and constraints as
Legend
described in [2]. In addition, rules for component individuals and
A
abstract (A) and
SSA
SSB
concrete (C)
symmetry breaking are included, described in Sections 3.2 and 3.3.
HDA
HDB
C
component type
Finally, the WCRL program is translated to BCRL.
pc-1
component
sto
Pn
parts b-1 and
c-1
individual
b-2 with
Model manager
ssa-1
ssa-2
part name Pn
Pn
PCML Configuration
WCRL program
b-1
b-2
msu
[n..m]
part defintion Pn
msu
PCML
Smodels
lparse
specialization:
model (*.cfg)
(*.lpi)
cardinality n to m,
core
interface
B is subtype
allowed types
A
B
hda-1
B
C
hda-5
hdb-5
of A
B and C
Figure 1. Example
product
Internal PCML data
Configurator server
structures (*.cfc)
Constraints associated with component types define conditions
BCRL program
JNI
that a correct configuration must satisfy. The first level building
PCML
Smodels
smodels
(*.lpo)
core
interface
blocks of the constraint language are references to access parts and
properties of components, and constants such as integers. Refer-
Figure 2. Configurator
architecture
ences can be used in succession, e.g. to access a property of a part.
Tests returning Boolean values are constructed using references,
The configurator uses as the configuration engine an implemen-
constants, and arithmetic expressions. Tests include predicates for
tation of the weight constraint rule language called Smodels[12].
checking if a particular referenced individual exists or is of a given
The main functionality of the Smodels system is to compute a de-
type. Property references can be used with constants in arithmetic
sired number of stable models for a WCRL program. The system
expressions that can be compared with the usual relational operators
allows a user to give further requirements (through so-called com-
to create a test. Test can be further combined into arbitrarily com-
pute statements) to constrain the stable models to be computed.
plex Boolean expressions using the standard Boolean connectives.
The Smodels system is based on a two-level architecture where
The semantics of the modeling language is provided by mapping
in the first phase a front-end, lparse, compiles a WCRL program
it to weight constraint rules [2]. The basic idea is to treat the sen-
into a BCRL program. Lparse exploits efficient database techniques
tences of the modeling language as short hand notations for a set of
but does not resort to search. The search for models of BCRL pro-
sentences in the weight constraint rule language (WCRL) [11]. A
grams is handled using a special purpose search procedure, smodels,
configuration model thus corresponds to a set of weight constraint
taking advantage of special features of BCRL. The search procedure
rules consisting of ontological definitions defining the semantics of
works in linear space and employs efficient search space pruning
the modeling concepts and a set rules representing the configuration
techniques and a powerful dynamic application-independent search
model. A configuration with respect to a configuration model is
heuristic. Smodels is implemented in C++ and offers APIs through
defined as a subset of the Herbrand base of the configuration model.
which it can be directly integrated into other software. Smodels is
A requirement is for simplicity defined as an atomic fact. A correct
publicly available at http://www.tcs.hut.fi/Software/smodels/.
configuration is a stable model of the set of rules representing the
The BCRL form of the configuration model is used to repeti-
configuration model and a suitable configuration is a correct con-
tively configure a product. The configurator server loads the data
figuration that also satisfies the set of requirements.
structures representing the PCML configuration model into PCML
core and the BCRL program into smodels. A compute statement
representing requirements is set through smodels API.
3 IMPLEMENTATION
This section first describes relevant parts of our prototype configu-
3.2 Individual generation
rator and off-line compilation of configuration models. Then we
discuss individual generation that limits a configuration to a finite
In this work, we take the approach that the set of individuals out of
size in a semantically justified way. Finally we discuss symmetry
which the configuration can be constructed is pre-defined. This
breaking that is important for the performance of the configurator.
limits the configuration to a finite size. We decide in advance in a
semantically justified way the number of individuals of each con-
crete type available for use in a configuration. The available indi-
3.1 Overview and implementation scope
viduals are represented as a set of facts stating for each individual
which type it is an individual of. These facts are added to the
The configurator architecture is outlined in Figure 2. The configu-
WCRL rules representing the configuration model.
rator is implemented in Java programming language except compo-
There is exactly one component type that can serve as the root of
nents smodels and lparse of the Smodels system, described below.
the compositional structure, referred to as the configuration type.
The configurator compiles a PCML program to a general WCRL
An individual of this type, the configuration individual, serves as
program with variables and further to simple basic rules (BCRL)
the root of the compositional structure. Because a maximum cardi-
that contain no variables. This potentially costly two-phase compi-
nality is defined for every part definition, we can calculate an upper
lation process is performed off-line. In the compilation, PCML core
bound of the number of needed individuals. First the configuration
18
individual is generated. For each part definition of the configuration
describe a general test methodology for configurators and continue
type, the number of individuals defined by maximum cardinality of
by describing and characterizing the products used as test cases. We
the part definition is generated for each allowed concrete part type.
then specify our test setup. Finally, we provide results on the effi-
This is performed recursively to generate part individuals for all
ciency of our configurator.
part definitions of the types of the newly generated individuals.
The number of needed individuals can grow exponentially. For
4.1 Testing method
example, increasing the number of levels in the part hierarchy leads
to exponential growth in the number of generated individuals when
In principle, one could test a configurator by using real configura-
maximum cardinality at each level is at least 2. The implementation
tion models or by using randomly generated configuration models.
does not try to optimize the number of individuals on the basis of
Random configuration model generation could be synthetic or use
constraints or mutually exclusive branches of the part structure.
real products as a seed. Another dimension is the selection between
fixed and randomly generated requirements. We chose for this work
3.3 Symmetry breaking
real configuration models with random requirements.
There is a risk that random models without a large set of real
Individuals of a concrete type are equivalent except for their names.
products as a seed do not reflect the structured and modular nature
Equivalent configurations, i.e. configurations identical except for
of products designed by engineers. In addition, it is hard to attain a
naming, can be created by selecting different individual(s) of a
level of difficulty representative of real problems. Knowledge ac-
concrete type as a part. This freedom of selection creates unwanted
quisition and modeling for a sufficient seed of real models for ran-
symmetries. Next, we describe two forms of symmetries and pres-
dom model generation in a justified way would be a major task.
ent a method used in our configurator that allocates individuals to
Random requirement generation with progressively larger and
specific part names of specific individuals in a way that breaks
thus more restrictive sets of requirements allows one to investigate
these symmetries.
how well the configurator performs with varying sizes of require-
The first form of symmetry arises when several individuals di-
ment sets. A dramatic increase in time to find a configuration with
rectly of a type are possible parts with a part name for an individual.
some requirement size indicates that the problem becomes critically
For example, in Figure 3(a) type A has part definition P with cardi-
constrained at that point. The existence of hard configuration prob-
nality 1 to 2 with type B as the only allowed type. There are two
lems would then be revealed.
individuals b-1 and b-2 of type B that can be as a part with part
For generating random sets of requirements, we consider how
name P in a-1. The configurations in Figures 3(b) and 3(c) are
the configuration model appears to the user configuring a product.
equivalent. In general, individuals can be picked in a combinatorial
There are menus (possibly multi-choice), radio buttons or check
number of ways creating a potentially huge number of symmetries.
boxes to select between different alternatives. Guided with these, it
The idea of symmetry breaking is that the possible part individuals
is probable that the user will not break the "local" rules of the con-
directly of the same type are always used in a fixed order. The indi-
figuration model, e.g. by requiring alternatives that do not exist or
viduals are ordered by giving them priority rankings. A lower pri-
by selecting a wrong number of alternatives. However, a naďve user
ority individual is not allowed in the configuration if all the higher
can easily break the rules of the configuration model that refer to
priority individuals are not in the configuration. Symmetry breaking
the dependencies of several selections.
would thus allow only the configuration in Figure 3(b).
We follow this idea by considering the configuration model as
consisting of a set of "local" requirement groups. A requirement
a-1
a-1
A
group (group for brevity) represents a set of potential requirements
P
P
P
that a user could state. For example, a group could represent the
[1..2]
selection of a value for the power property of an engine, or the
B
b-1
b-2
selection of the cooling system in a compressor out of the allowed
(a)
(b)
(c)
component types. Each group has a number of requirement items
each representing a potential requirement. The number of require-
A
a-1
a-1
ments that can be generated from a group is defined by minimum
P1
P2
P1
P2
P1
P2
[1]
[1]
and maximum cardinality. Note that cardinality applies only if the
group is selected to generate requirements.
b-1
b-2
b-2
b-1
B
In our tests, a requirement group is created for each property and
(d)
(e)
(f)
part definition of the type of each individual. For each property
Figure 3. Symmetry
breaking
definition a group with maximum and minimum cardinality of one
is created. A value in the domain of the property corresponds to one
The second form of symmetry is shown in Figures 3(d) to 3(f).
requirement item. If the property is optional, a requirement item that
Without symmetry breaking any individual of type B could be as a
denies a value for the property is included. A part definition corre-
part with any part name in any individual whose type has a part
sponds to one group with maximum cardinality of the part defini-
definition that has B as an allowed type. For example, individuals
tion. Minimum cardinality is the maximum of one and the minimum
b-1 and b-2 of type B could both be as a part with part name P1 or
cardinality of the part definition. Each potential part individual
P2 in individual a-1. Our solution for breaking this form of sym-
corresponds to one requirement item. If the cardinality of the part
metry is to allocate each individual to a specific individual and part
definition includes 0, a requirement item that denies all part indi-
name. After allocation either (e) or (f) is allowed, but not both.
viduals is included.
A test case contains a number of requirement items related to a
4 EMPIRICAL TESTING
configuration model. When generating a test case, a group is ran-
domly selected to generate the number of requirements specified by
In this section we discuss empirical testing of configurators in gen-
the minimum cardinality. A group can be selected again to generate
eral and our configurator implementation in particular. We first
one new requirement. Group selection is repeated until the desired
19
number of requirements has been generated. A group cannot be
4.3 Test setup
selected to generate requirements, if the desired number of require-
ments or maximum cardinality would be exceeded, or if all re-
Test setup is illustrated in Figure 4. A WCRL program was gener-
quirement items are already in the generated requirements.
ated off-line for each PCML configuration model. For each test
A requirement is generated from a group representing a property
case, a new process was created to execute a batch file that executed
by choosing randomly one requirement item. Generating a require-
lparse (version 1.0.4) to generate a BCRL program with a compute
ment for a part is slightly more complex. In our implementation, the
statement with the requirements of the test case. The output of
order in which the individuals of a given type may be chosen as
lparse was piped to smodels version 2.26 with modifications that
requirements is important due to the symmetry breaking. Therefore,
suppressed the output of found configurations. Suppressing the
a requirement is generated by randomly selecting the direct type of
output was needed to avoid the configuration task to become I/O
the part or the requirement item that denies all part individuals. If a
bound due to a large number of atoms printed for each configura-
type is chosen, the highest priority individual of that type that has
tion. Instead, just the number of found configurations was reported.
not been required yet is set as the requirement. For example, hda-1
Model manager
of Figure 1 would be required before hda-2, as they are allocated to
PCML Configuration
WCRL program
the same part name (msu) of a component individual (ssa-1).
PCML
Smodels
model (*.cfg)
(*.lpi)
core
interface
4.2 Case products
Test case compute
We have modeled four real product families using PCML. Three
lparse
statement (*.tst)
smodels
products are screw compressors manufactured by Gardner Denver
Oy. Each configuration model represents a complete sales configu-
Figure 4. Test
setup
ration view of a compressor family. The models are detailed to
For each configuration model, we generated 100 test cases with 2
production quality, except for some constant values. The fourth
requirements, 100 test cases with 4 requirements, etc, for each even
product is a 4-wheel vehicle anonymized by renaming. It was mod-
number of requirements up to the total number of groups. The ran-
eled for demonstration purposes and represents about half of the
dom requirements in a test case were expressed as a smodels com-
sales view of the product. Numerous optional parts and some con-
pute statement. If a configuration was found with the requirements
straints were excluded. Despite inaccuracies the model reflects quite
of the test case, the test case was considered satisfiable, otherwise it
well the nature of sales configuration of this configurable product.
was considered unsatisfiable.
The configuration models are characterized in Table 1. Row
The tests were run on a laptop PC with 1 GHz Mobile Pentium
"Comp. types" gives the number of concrete, abstract and all com-
III processor, 512 MB RAM, and Windows 2000 Professional. All
ponent types. "Properties" specifies the total number of properties
timings were performed using the test system's built-in clock. All
and the number of component types that specify at least one prop-
times are reported in seconds. A Java based test generator and
erty. "Domain size" indicates minimum, maximum and average
driver was used to generate and execute the test cases.
domain size of the defined properties. It also gives the number of
The configuration models, test cases, test case run logs, full re-
properties with "small" domain size of 2 or 3, as the average do-
sults as well as the modified Smodels source files and the Windows
main sizes are strongly affected by the few large domain properties.
executable are available at http://soberit.hut.fi/pdmg/empirical_cfg/.
"Part defs" specifies the total number of part definitions, the num-
ber of component types with part definitions, and the average num-
ber of allowed concrete component types. "Cardinality" specifies
4.4 Results
the number of part definitions with different cardinalities: 0 to 1,
exactly 1, and others. "Constraints" specifies the number of con-
We briefly explain the measurements before proceeding to the re-
straints and the average number of parts or properties referenced by
sults. Time to translate PCML to WCRL includes the time needed
a constraint. In every compressor model all constraints except one
by a running Model Manager process to load and translate a PCML
had 2 or 3 references. The exceptional constraints had 262 to 347
configuration model to WCLR and to save the output.
references to enumerate allowed combinations of four to five prop-
Total duration of a test case includes creating the smodels proc-
erties. These huge constraints dominate the averages. In all configu-
ess for the test case, extracting the number of found answers and the
ration models, the configuration type defined all the constraints and
duration reported by smodels, and writing the output log. Smodels
most properties.
duration includes the time the smodels executable uses for reading
Compressor configuration models use almost solely properties.
the BCRL program and the time used for computation. Non smodels
The most complex of these, ESVS, has 3 part definitions. Optional
time includes the time to start a test case, run lparse and start smod-
components without properties were modeled as properties.
els, and to gather the results from smodels output (= total duration
smodels duration).
Configuration model
ESVS
FS
FX
Vehicle
Run time characteristics of the configuration models without the
Comp. types c / a / tot
7 / 2 / 9 3 / 0 / 3 1 / 0 / 1
25 / 4 / 29
effect of test cases are given in Table 2. The results start with the
Properties tot / ct
24 / 5
22 / 3
18 / 1
8 /3
time to translate PCML to WCRL ("PCML WCRL"), the result is
Domain size min max
2 61
2 51
2 44
2 - 22
the average of 100 executions. In addition, all configuration models
avg / 2-3
5.9 / 17 5.5 / 14 5.7 / 10
5.8 / 5
were run once on smodels to find all configurations of each model
Part defs tot / ct / allow
3 / 2 / 2 1 / 1 / 2 0 / 0 / -
16 / 3 / 1˝
without any requirements. Table 2 lists the number of configura-
Card. 0-1 / 1 / max >1
0 / 3 / 0 0 / 1 / 0
0 / 0
12 / 4 / 0
tions ("#Configs") after symmetry breaking, the smodels duration
Constraints tot / refs
17 / 20
14 / 25
21 / 12
7 / 2.0
("Smodels"), as well as the rate of configurations found per second
Table 1.
Properties of the configuration models
(#Configs/s). "Non smodels" is averaged non smodels time from
running the test cases.
20
Cfg. Model
ESVS
FS
FX
Vehicle
sat" gives the average smodels duration to determine unsatisfiabil-
PCML WCRL
8,2 s
8.0 s
5.0 s
1.3 s
ity, taken from the second run. "Find all" gives the average number
#Configs
1,841,356,800 36,106,560 1,136,160 268,800,000
of configurations per satisfiable case ("#cfgs /case") and the aver-
Smodels (s)
18401.4 s
377.1 s
17.0 s
2537.2 s
age rate of configurations found per second ("#cfgs / s"). Non
Configs / s
100066
95748
66833
105944
smodels time from Table 2 can be added to the results to get the
Non smodels
0,12 s
0,13 s
0,14 s
0,12 s
average total duration of finding the first configuration or deter-
mining unstatisfiability.
Table 2.
Run time characteristics of configuration models
The test arrangement caused occasional random delays of ap-
ESVS
Find first
Find all
proximately ˝ second, possibly due to garbage collection in the
#req
#sat
(s)
#cfgs / case
#cfgs /s
Unsat (s)
Java environment, the functions of the operating system or the virus
2
89
0,37
189441067
88238
0,30
scanner. Therefore maximum durations are not repeatable and only
4
61
0,35
18987439
76849
0,28
average results are shown. The maximum non-repeatable smodels
6
25
0,34
2234799
72687
0,29
time for finding one configuration or determining unsatisfiability
8
9
0,33
211432
19957
0,28
was still below 0.7 s. Repeatable times were close to the average,
10
4
0,31
1920
263
0,29
typically approximately within 20% of the average, except for the
12
1
0,32
15552
526
0,29
vehicle model, where average duration was always less than 0.1s
14-28
0
-
-
-
0,30
causing small absolute errors to show major relative differences.
Table 3.
ESVS compressor results with test cases
FS
Find first
Find all
5 DISCUSSION AND PREVIOUS WORK
#req
#sat
(s)
#cfgs / case
#cfgs /s
Unsat (s)
2
97
0,33
3583976
84436
0,27
In this section we first discuss our implementation and empirical
4
76
0,31
706695
74793
0,29
results and compare our empirical results to previous work.
6
55
0,30
90602
55829
0,28
Our results indicate performance adequate both for batch mode
8
26
0,29
10985
20411
0,28
configuration and interactive configuration with the simple case
10
15
0,30
1512
4269
0,28
products. There were no test cases with repeatable significantly
12
10
0,33
719
2173
0,28
inferior performance. Also, there was no significant change of per-
14
4
0,30
29
109
0,28
formance as a function of the number of requirements. The average
16-22
0
-
-
-
0,28
configurations per second results show weakening with increasing
Table 4.
FS compressor results with test cases
number of requirements. However, this seems to be mostly illusory:
FX
Find first
Find all
because the number of configurations with many requirements is
#req
#sat
(s)
#cfgs / case
#cfgs /s
Unsat (s)
small, Smodels duration comes mostly from reading the BCRL
2
93
0,23
116646
42200
0,20
program and from setting up the computation.
4
69
0,22
12558
20116
0,25
Our case products were small but we feel that they are represen-
6
43
0,21
2537
8552
0,19
tative of what is needed in sales configuration. We expect that the
8
18
0,21
307
1439
0,19
good performance of our configurator can be generalized to many
10
9
0,23
47
181
0,22
products suitable for web based sales configuration.
12
2
0,27
14
50
0,26
No critically constrained problems were found and no phase
14
1
0,19
5
28
0,20
transition behavior was apparent. As expected, the number of con-
16
0
-
-
-
0,20
figurations seems to decrease exponentially as the number of re-
Table 5.
FX compressor results with test cases
quirements increases. Minor exceptions due to random requirements
were encountered in the Vehicle and ESVS configuration models.
Vehicle
Find first
Find all
#req
#sat
(s)
#cfgs / case
#cfgs /s
The case models had no maximum cardinalities larger than one
Unsat (s)
2
95
0,05
37317928
98238
0,04
and a component type was usually used as an allowed type only in
4
85
0,05
5855831
88913
0,04
one part definition. Therefore the significance of symmetry break-
6
59
0,05
747205
84642
0,05
ing for performance was low. However, it is evident that several
8
33
0,05
108638
71394
0,05
forms of symmetries remain unbroken and new important forms
10
22
0,09
29136
54358
0,07
arise when implementing the full ontology, e.g. port and connection
12
8
0,07
9526
42361
0,08
oriented concepts.
14
4
0,06
289
3853
0,08
Our approach in individual generation may create more indi-
16
0
-
-
-
0,08
viduals than needed resulting in unnecessarily large compiled mod-
18
2
0,06
9
140
0,07
els. On the other hand knowing all individuals can make
20-24
0
-
-
-
0,06
propagation more efficient in smodels and thus enhance perform-
Table 6.
Vehicle results with test cases
ance. This kind of individual generation was also straightforward to
implement in conjunction with our compilation strategy.
Tables 3 to 6 show our main results from running the generated
Running lparse for each test case conflicts with the knowledge
random test cases. The first run of the test cases evaluated the per-
compilation principle and our normal way of using the configurator.
formance of finding one configuration that satisfies the require-
As the results indicate, running time of lparse for the case products
ments. The second run evaluated the performance of finding all the
was small. According to our experiences, the time required by
configurations that satisfy the requirements. Each row lists the
lparse to translate a WCRL program increases significantly with
number of requirements ("#req") and the number of satisfiable
large cardinalities.
cases ("#sat"). Note that the sum of satisfiable and unsatisfiable
We measure performance using execution time due to its practi-
cases is 100. "Find first" gives the average smodels duration of
cal importance for users and its suitability to searching for phase
finding one configuration that satisfies the requirements, and "Un-
transition behavior. It would be useful to use metrics that are inde-
21
pendent of processor power, efficiency of implementation tools and
ing. We defined a relatively modeling-language-independent
the technology used. Unfortunately such metrics are difficult to
method for testing configurators based on the idea of simulating a
define. For example, the number of consistency checks is not com-
naďve user inputting random requirements to a configurator. The
mensurate between different technologies such as CSP and logic
methodology enables systematic testing using a small set of prod-
based approaches. Compromises between propagation and search
ucts.
also significantly affect the number of needed consistency checks.
We modeled four products taken from two domains from a sales
According to our experiences, the timing result averages are re-
configuration point of view. The modeling language of the configu-
peatable only to 1/10th of a second. For example, the average time to
rator was found adequate for modeling these products.
show unsatisfiability with the Vehicle model differed up to 16 ms
The empirical results indicate that our configurator is efficient
between 2 runs making the 1/100th second reading inaccurate. Aver-
enough for sales configuration use. The results also support the
age times with the FX model varied in one case even by 60 ms
common wisdom that configuration problems are relatively easy to
between two runs. The repeatability of the results would be im-
solve. However, our small sample of relatively small sales configu-
proved and maximum durations would become more reliable by
ration models originates from two domains only. Thus, more tests
executing the test cases several times, excluding the worst results to
are needed with larger and potentially more difficult to configure
eliminate the effect of random delays. Fully automatic generation of
products taken from different domains (e.g. telecommunications
the test cases from configuration models would make testing easier.
and electronics), and modeled from engineering point of view.
We note that our test methodology can be applied relatively eas-
ily to other formalisms like CSP. In CSP, a requirement group could
correspond to a CSP variable and a requirement item to one possi-
ACKNOWLEDGEMENTS
ble assignment for that variable.
We gratefully acknowledge the financial support from Technology
We now compare our work briefly with other similar work.
Development Centre of Finland (Tekes). The work of the third
Syrjänen configured the main distribution of Debian GNU/Linux
author has been supported by the Academy of Finland (project
using configuration models expressed using an extension of normal
53695). We thank Hannu Peltonen for authoring most of the first
logic programs. The configuration task was to select a maximum set
version of the PCML specification. We thank him, Andreas Ander-
of mutually compatible software packages satisfying random user
son and Jan Elfström for implementing significant parts of the con-
requirements that exclude or include some packages. Average
figurator. We also thank Tommi Syrjänen and Patrik Simons for
Smodels time for configuration was 1.06 s for Debian 2.0 with 1526
developing Smodels with configuration in mind. Finally, we wish to
packages and 1.46 s for Debian 2.1 with 2260 packages. The tests
thank Gardner Denver Oy for sharing the configuration knowledge.
were run on a 233 Mhz Intel Pentium II on Linux [4]. The configu-
ration duration was approximately the same as in our largest ESVS
model (adjusted for our roughly four times faster processor).
REFERENCES
Syrjänen's approach seems to perform better than ours as the De-
[1] A. Felfernig, G. Friedrich and D. Jannach, `UML as Domain Specific
bian configuration models are substantially larger.
Language for the Construction of Knowledge-Based Configuration
Sharma and Colomb developed a constraint logic programming
Systems', International Journal of Software Engineering and Knowl-
(CLP) based language for configuration and diagnosis tasks. Ex-
edge Engineering, 10, 449-469, 2000.
perimental results stem from thin ethernet cabling configuration.
[2] T. Soininen, I. Niemelä, J. Tiihonen and R. Sulonen, Representing
The largest 12 node configuration included 126 port connections
Configuration Knowledge With Weight Constraint Rules. In Proc. of
and required 12 seconds of CPU time on a dual 60 Mhz SuperSparc
the AAAI Spring 2001 Symposium on Answer Set Programming, 2001.
processor based system to find a configuration [5]. Direct perform-
[3] S. Mittal and B. Falkenhainer, Dynamic Constraint Satisfaction Prob-
ance comparison to our work is difficult due to port and connection
lems, in Proc. of the 8th National Conf. on AI (AAAI-90), 25-32, 1990.
oriented domain, different processor power, and missing details.
[4] T. Syrjänen, Including Diagnostic Information in Configuration Mod-
Mailharro used the Ilog system to configure the instrumentation
els, in Proc. of the First International Conference on Computational
Logic, (Volume 1861 of Lecture Notes in Artificial Intelligence), 2000.
and control hardware and software of nuclear power plants. Several
[5] N. Sharma and R. Colomb, Mechanising Shared Configuration and
thousand component individuals were created and interconnected in
Diagnosis Theories Through Constraint Logic Programming, Journal
about an hour of execution time on a Sun Sparc 20 [8]. The case
of Logic Programming 37, 255-283, 1998.
product is larger and more complex than ours. Direct performance
[6] M. Stumptner, G. Friedrich, A. Haselböck, Generative constraint-based
comparison is not possible due to limited details available.
configuration of large technical systems. AI EDAM, 12, 307-320, 1998.
[7] D. McGuinness and J. Wright, An Industrial-strength Description
Logic-Based Configurator Platform, IEEE Intelligent Systems & Their
6 CONCLUSIONS AND FUTURE WORK
Applications, 13, 69-77, 1998.
[8] D. Mailharro, A classification and constraint-based framework for
In this paper we have briefly described a configurator implementa-
Configuration, AI EDAM, 12, 1998.
tion based on mapping its modeling language to weight constraint
[9] Mackworth A.K. Consistency in Networks of Relations. Artificial
rules, a form of logic programs. The configurator uses a state-of-
Intelligence, 8, 99-118, 1977.
the-art general implementation of weight constraint rules for com-
[10] T. Soininen, E. Gelle, and I. Niemelä, A Fixpoint Definition of Dy-
puting configurations satisfying user requirements. Our configurator
namic Constraint Satisfaction. In Principles and Practice of Constraint
implementation addressed three issues important for efficiency: off-
Programming - CP'99 (LNCS 1713), 419-433, 1999.
line compilation of configuration models, limiting the size of a
[11] T. Soininen, J. Tiihonen, T. Männistö, and R. Sulonen, Towards a
configuration to be finite in a semantically justified way, and
General Ontology of Configuration, AI EDAM, 12, 357372, 1998.
breaking symmetries in the set of configurations. However, im-
[12] P. Simons, I. Niemelä, and T. Soininen, Extending and implementing
the stable model semantics. To appear in Artificial Intelligence, Special
proved symmetry breaking and generative or more optimal individ-
Issue of Knowledge Representation and Logic Programming.
ual generation are subjects for further work.
We then aimed to assess the difficulty of configuration problems
as well as the efficiency of our configurator through empirical test-
22
Knowledge Compilation for
Product Configuration
Carsten Sinz
Abstract.
In this paper we address the application of knowledge
In Felfernig's system, a configuration problem consists of a do-
compilation techniques to product configuration problems. We ar-
main description
and a system requirements specification
, from
˘
Ł
gument that both the process of generating valid configurations, as
which a consistent (valid) configuration has to be constructed2. The
¤
well as validation of product configuration knowledge bases, can po-
domain description is a set of predicate logic sentences expressing
tentially be accelerated by compiling the instance independent part
compatibility constraints on the product's parts, and additional ax-
of the knowledge base. Besides giving transformations of both tasks
ioms describing and restricting the constraints language; the system
into logical entailment problems, we give a short summary on knowl-
requirements specification states customer demands on the desired
edge compilation techniques, and present a new algorithm for com-
product, again in the form of a set of predicate logic sentences. Then,
puting unit-resolution complete knowledge bases.
a conjunction
of ground literals is a solution to the configuration
¤
problem
, or a valid configuration, when it is logically consis-
Ą¦˘¨§©Ł
tent with the domain description and the requirements specification,
1
Introduction
#
$&%
i.e.,
. For our purpose we consider the propo-
˘Ł¤ "!
Configuration of complex products is a computation intensive task.
sitional variant of this formalism. We assume a finite universe, or a
In most formalisms proposed in the literature [5, 10, 11], generating
universe with a finite number of equivalence classes with respect to
a consistent configuration can be intractable in the worst case, and
the domain description and the requirements specification. Now the
is at best an NP-hard problem. Moreover, in a typical setting, huge
propositional case can be obtained from the first-order case by re-
series of configuration runs have to be performed for the same kind
placing all sentences of
and
by a conjunction of their ground
˘
Ł
of product, but different customer demands. The closely related task
instances, similar to a Herbrand expansion.
of checking a product configuration knowledge-base for consistency
The second formalism we consider consists of a set of propo-
[7] exhibits similar characteristics. Here a large number of validation
sitional constraint rules that make up a knowledge-base describing
properties have to be checked for a given knowledge-base.
valid products [7]. The semantics of the whole knowledge-base can
These conditions make it attractive to investigate the application
be interpreted as a propositional formula
whose models are the
'
of knowledge compilation techniques (see Cadoli and Donini's arti-
valid configurations. To check its consistency, we generate a set
of
(
cle for a survey on knowledge compilation [2]). For a set of common
validation properties
and test whether or not the knowledge-base
)10
#
$
problem instances, knowledge compilation separates the computa-
satisfies them. Therefore, we have to determine whether
for
'
)10
tional task into an instance dependent and an instance independent
all
.
)10324(
part. The latter can be solved in advance during a preprocessing step,
which can potentially lead to a speedup in the overall run time.
3
Logical Entailment and Knowledge Compilation
A significant advantage of pre-compiled knowledge-bases is that
in the lucky case of successful compilation into a knowledge base of
Problem instances of both formalisms can be formulated as propo-
reasonable size, short runtimes can be guaranteed for all individual
sitional entailment problems, where the question is to find the de-
configuration processes.
ducible consequences
of a theory
(a set of propositional sen-
5
6
tences). For the purpose of knowledge compilation, we partition the
theory
into a constant part
and a varying part
. The con-
6
687
6@9
2
Formalisms for Product Configuration
stant part
is then replaced by an equivalent, but computationally
687
In this paper, we consider two formalisms for product configuration.
preferable, compiled theory
, and the varying part of the theory is
6BA
7
We use them as representatives for demonstrating applicability of
moved to the consequence by means of the deduction theorem. Thus,
knowledge compilation for both generating valid configurations and
the general entailment problem
checking consistency of knowledge bases.
#
$
6@7CD6E9
5
The first formalism is a slight variant of the logical theory of con-
figuration presented by Felfernig et al. [5], which complies with Mit-
is restated in the compiled theory as
tal and Frayman's component-port representation for configuration
#
$
(1)
knowledge [11]. The second is a simplified version of the formalism
A
6
5GFIH
7
PRQTSVUXW3Y`
used for the validation of DaimlerChrysler's engineering and produc-
a
tion configuration system [7].
Ferfernig et al. [5] distinguish between consistent and valid configurations,
where valid configurations have to fulfill additional completeness axioms.
ˇ
Symbolic Computation Group, WSI for Computer Science, University of
In this article we always refer to the augmented version with completeness
T¨ubingen, Sand 13, 72076 T¨ubingen, Germany
axioms added when talking about valid or consistent configurations.
23
This transformation especially offers advantages when (a) the con-
of best approximations is NP-hard). Selman and Kautz [13] present
stant part of the theory is large compared to the variable part of the
different algorithms for their computation.
theory and the consequence to be checked, (b) the compilation of
theory
into
is efficient, and (c) there is a large number of en-
ALGORITHM THEORY-APPROX
6@7
6BA
7
#
$
#
$
tailment checks to be performed.
INPUT:
with
6
§z6k§z6
§{¤
6
6
6
x
w
vw
x
w
vw
#
$
In transforming the first formalism, the fixed part
is the domain
OUTPUT:
if
,
otherwise
|~}
6
¤
5
6cb
description
, and the varying part is the systems requirement spec-
Y
BEGIN
˘
#
$
ification
. The task now is to find a valid configuration consistent
IF
THEN return
6
¤
|~}r
vw
Ł
#
$
with
and
by a series of entailment checks. When we consider
ELSE IF
THEN return
6
!
¤
5
x
w
˘
Ł
#
$
$fe
the inverted requirements specification
being repre-
Y
ELSE return 6
¤
d
PRQhg
$pi
i©u
W3Y
sented in conjunctive normal form (CNF), i.e.
ˇrqtsVsVs@q
,
END
d
#
$xiy
we can perform
entailment checks
for
v
˘wA
Iv
within the compiled theory
to find configurations conforming
˘
A
iy
#
$iy
with the domain description: For each
with
the con-
˘wA!
Figure 1.
Theory Approximation Algorithm.
i
$
y
junction of literals
ˇqsVssq
is a minimal valid con-
W
figuration. This can be verified by observing that the configuration
$
iyD$
#
$iy
ˇ
qsVsVsEq
is consistent with
. As
,
¤
˘Ł
˘wAB!
iy
#
$e%
W
and
is logically equivalent to
, we have
,
Exact compilation methods, as opposed to approximations, try to
˘wA
˘
˘
d!
i
igu
#
$%
W
hence a fortiori
ˇ
s sVs
. Now as
is equiv-
find a theory
that is equivalent to
, for which the entailment
˘f
F
F
h!
i
6
6
A
$
i
i©u
$
iy
W
W
alent to
ˇ
sVsVs
and
for some , we obtain
problem is tractable, i.e., decidable in polynomial time. The predomi-
d
F
F
¤
#
$j%
W
W
W
W
.
nant method for computing such compilations is by generating prime
˘jkŁl¤ k!
Further non-minimal valid configurations can be generated using
implicants or prime implicates of the original theory.
iy
the following scheme: for each literal
not occurring in
we test
In the following, we consider a compilation by the computation
#
$"iy
whether
. If this is the case, we can safely add to the
of prime implicates. The source theory then usually also is in con-
˘wA!
F
W
configuration without violating validity.
junctive normal form (CNF)--a common incidence in practice. An
In summary, to treat the transformation of the first formalism, we
implicate of a theory
is a non-trivial clause (without complemen-
¤
6
$j%
#
$
set
in Formula 1, and consider a special representation (DNF)
tary literals) such that
; moreover,
is a prime implicate if no
5
6
¤
¤
of the variable part of the theory
.
proper sub-clause4 of
is also an implicate of
.
mon
¤
6
For transformation of the second formalism (checking validation
Computing the set
of all prime implicates of a theory
q6w
6
properties) we assume the validation properties
to be in conjunc-
yields a theory
that is equivalent to
and has the following im-
)
0
6BA
6
$
u
#
$
tive normal form, i.e.
ˇ
qfsVsVshq
. Then, after setting the
portant property: a clause
is a consequence of
, i.e.
, iff
)10
)10p
)
0qp
¤
6
6
¤
$
constant part
of the theory to
, and noting that there is
there is a clause
that is a sub-clause of . Thus, using
6
6
r's
7
7
"2"q6u
¤
$jt
$
no variable part, i.e.
, the test for property
decomposes into
as a compiled version of the theory
, clausal entail-
6E9
)10
6uA
q6u
6
#
$
y
entailment checks
in the compiled theory
.
ment for a clause
can be decided in linear time in the size of
v
6BA
)10qp
6uA
5
6BA
7
7
In both formalisms we only have a restricted form of entailment
and the query .
5
#
$
checks, namely only tests
, where
is a clause. Therefore
Different algorithms have been proposed to compute the set of
6BA
5
5
we restrict our attention to propositional clausal entailment in the
prime implicates of a theory [3, 12, 15]. However, the number of
following. Knowledge compilation aims at generating theories for
prime implicates may be exponential in the size of the theory
, and
6
which the entailment problem is tractable--decidable in polynomial
therefore different strategies have been developed to compute more
time--whereas the general propositional clausal entailment problem
compact exact compilations. Among the extensions are computations
is coNP-complete [2].
of prime implicates from no-merge resolvents [4], theory prime im-
plicates [8], and tractable cover compilations [1]. In the following,
we will describe del Val's work [4] in more detail.
4
Knowledge Compilation Techniques
The prime implicate computation from no-merge resolvents is
sometimes also referred to as unit-resolution (UR) complete com-
Knowledge compilation and concequence finding are active areas of
pilation, and the idea is to delete those prime implicates from q6u
research [2, 9, 13]. The methods proposed in the literature are usu-
that can be derived by a UR refutation proof from the remaining the-
ally separated into two main categories: approximate and exact com-
ory. As UR refutations can be computed in linear time, this means a
pilations. Approximate compilation mostly appears in the form of
shift from precompiled knowledge to deduction by a calculus that is
theory approximation, where a theory
is approximated by a com-
6
still tractable. In the following we denote UR derivations by
, and
v
putationally more tractable theory
. Selman and Kautz [13] use
$
u
6uA
use the convention that for a clause
ˇ
sVss
the notation
¤
F
F
two approximating Horn theories, one approximating from above
qu
stands for the set of units
ˇ
obtained by negating .
¤
§
§
¤
#
$
#
$
(
) and the other from below (
).3 To decide en-
6
6@vw
6@x
w
6
W
`V``
W
Our goal now is to compute a set
of clauses that is equivalent to
6
tailment for a clause , algorithm THEORY-APPROX, as shown in
¤
, and for which
6
Figure 1, is employed. Entailment for Horn theories, i.e. for
and
%
6
vw
, can be decided in linear time, so algorithm
6
¤t
v
THEORY-APPROX is
6
x
w
supposed to decide many cases efficiently: the better the approxima-
#
$
holds for all clauses
with
. Then all consequences of
¤
6
¤
6
tion, the more cases are computationally tractable. However, compu-
$
can be derived by UR refutations from
. Of course, setting
6
6
tation of good Horn approximations can be quite hard (computation
would be a solution, but this is often not practical and does not
q6w
y
The bounds are defined in terms of models: the lower bound has fewer, the
Clause
is a (proper) sub-clause of
if the set of literals of
is a (proper)
upper bound more models than the given theory.
subset of the literals of .
24
deliver the best, i.e. minimal, theory. Del Val [4] suggests different
15), and the whole process is repeated until no further changes result,
candidates for theory
.
and thus a fixed point is reached.
6
We now want to derive a precise characterization of an optimal
The main loop of the algorithm may be interrupted after each
, expressed by means of a fixed-point equation. Therefore, we
round, and still returns a UR complete theory equivalent to the in-
6
define
, an optimal solution for UR complete compilation, as a
put theory, yet not necessarily minimal.
{
6
smallest (regarding set inclusion) solution
of the formula
To further illustrate the effects of our algorithm let us consider an
6
example5. Let
%G˘
(2)
¤2lq6uh¤2
6
¤3
6 ˇ¤Vk!
v
$
`
6
§c¨
§
¨}§
c¨|R§
¨©§
|gŞ1«¬§
Ş1D
Then a clause
from the set of prime implicates of theory
is in the
Y
`
¤
6
solution theory
iff it cannot be derived by a UR refutation from
Computation of the set of prime implicates in line 5 of the algorithm
6
without .
then yields
6
¤
$
6
Ł¨
§
¨}§
¨r|R§
¨r©§
|~Ş1«B§
Ş1¦§{¨
|R§
¨}¦§8}
§
5
An Alternative Algorithm to Compute UR
Y
Y
Y
c|~¦§{}
|~©§
¨rŞ1«B§z¨
Ş1«¬§
8Ş1«B§z}
Ş1«¬§
|g«ˇ¦§
Complete Knowledge-Bases
Y
Y
Y
¨r«ˇ©§{¨
«ˇ¦§
c«ˇ©§©}
«D
Y
Y
`
Based on Formula 2 we now give an algorithm for UR complete
$
Suppose we first choose
in line 6. Then we have
knowledge compilation. Our algorithm, as well as all of del Val's
¤
}
«
Y
algorithms for computation of UR complete compilations, is based
%
}E§
§
©§
«¬§
s¨6
ˇr}
«ˇG
§
v
on prime implicate generation. This has the advantage that advances
Y
Y
in prime implicate computation can also improve knowledge compi-
and we thus remove
from
. A minimal justification
for
¤
6
(¤¤V
lation, but suffers from the drawback that in the worst case an expo-
deleting
is
¤
nential number of clauses has to be generated, even if the final result
$
(¤V
§¨
§
¨}§
cc«D
does not show this exponential blow-up. Our alternative algorithm,
Y
`
$
as shown in Figure 2, computes a different, in some cases smaller,
Selecting
next, we obtain
¤
8«ˇ
Ro§
©§
«¬§
ˇ6
o
8«ˇoGv
%
compiled knowledge-base than del Vals algorithms.
, and therefore we also remove this clause and compute
for
(¤V
$
it. But now we have for
that
and
¤A
r}
«ˇ
¤A2®q6uCˇ6
%
(1) ALGORITHM UR-COMPILATION
Y
. As
still holds, we just have to
¤24(¤¤
}1§
§
X§
«B§
¨6r
A
v
$
Y
(2) INPUT:
update the justification, e.g.
. Repeating the
(¤¤A¦
r}
Ş1«¬§
Ş1
6
Y
(3) OUTPUT:
, which is a solution to Formula 2
algorithm's steps over and over we reach the fix-point
6
(4) BEGIN
$
(5)
:= PI( );
6
§c¨
§q
¨}§
c¨r|R§
¨r©§
|gŞ1«¬§
Ş1¦§
¨r}©§8}
§
|~Ǭ
6
6
Y
Y
`
(6)
FOR EACH
DO
¤246
The complexity of our algorithm is dominated by the prime impli-
%
(7)
IF
THEN
¤3¨6Łr¤VG
v
cate computation step in line 5, which--as is well known--may in
(8)
:=
;
6
6
rh¤V
the worst case require exponential space (and thus time) (see, e.g.,
(9)
compute minimal
with
(¤¤Ąt6
[9]). It remains an interesting task to find an algorithm for UR com-
%
(10)
;
¤3¨(¤¤V3v
plete knowledge-base compilation that is not based on prime impli-
(11)
FOR EACH
with
DO
¤A¦2lq6wo§6
¤24(¤A¦
cate computation.
%
(12)
IF
THEN
¤AE¨6
v
(13)
update (¤¤A¦
(14)
ELSE
6
Preliminary Experimental Results
(15)
:=
;
6
6
l¤A
We are currently starting experiments with our algorithm on data-
(16) END
bases from automotive product configuration. First results obtained
from a prototypical implementation of our algorithm are shown in
Table 1.
Figure 2.
Algorithm for UR Complete Knowledge Compilation.
problem
PS
Ż
Ż
Ż
°BŻ
Ż
±¦˛zł¦°´RŻ
Ż
°
Ż
Adder
21
50
9,700
1,183
C250FV
1,465
2,356
2,492
1,837
C210FVF
1,934
3,985
496,050,800
Starting with the whole set of prime implicates, clauses are suc-
cessively temporarily removed (line 8) from the result set
, if the
6
entailment of a clause
can also be obtained from
without
by a
Table 1.
Experimental Results
¤
6
¤
UR refutation (line 7). Then a justification
of why the deletion
(¤¤
of was possible is computed (lines 9/10). This justification contains
¤
the clauses involved in a shortest UR refutation of . By removing
¤
The first example is taken from Forbus and de Kleer's book [6],
clause , UR refutation proofs of other, already removed clauses,
¤
which contains databases that are often used as benchmarks in the
may break. So for each previously removed clause
it is checked
¤A
knowledge compilation community. The following two examples are
whether a UR refutation proof of
is still possible (lines 11/12). If
¤A
knowledge bases describing valid model lines of DaimlerChrysler's
this is the case, the proof, i.e. the justification
, is updated (line
A
(¤
13) analogous to the computation in lines 9/10. Otherwise the for-
µ
This is Example 1 from del Val [4]. We also use his abbreviated notation
merly removed clause
is re-added to the working theory
(line
for clauses, e.g. writing
ą
instead of
ą
.
¶1·T¸
¶ˇşB·3şu»
A
¤
6
25
Mercedes cars. These databases are used by K¨uchlin and Sinz [7] for
[5] A. Felfernig, G.E. Friedrich, D. Jannach, and M. Stumptner, `Consist-
validation checks.
ency-based diagnosis of configuration knowledge bases', in Proc. of the
14th European Conf. on Artificial Intelligence (ECAI 2000), pp. 146
The columns of Table 1 show in turn the number of propositional
150, Berlin, Germany, (August 2000).
variables, the size of the database in number of clauses, the number
[6] K.D. Forbus and J. de Kleer, Building Problem Solvers, MIT Press,
of prime implicates of the theory, and the number of prime implicates
1993.
that remain after application of our algorithm.
[7] W. K¨uchlin and C. Sinz, `Proving consistency assertions for automo-
tive product data management', J. Automated Reasoning, 24(12), 145
problem
163, (February 2000).
Ľ˝Eľ
Ľż¦Ŕ~Á
Ŕ
Ľ~ÂĂ
v7
Adder
0.38
2683.10
2683.48
[8] P. Marquis, `Knowledge compilation using theory prime implicates', in
C250FV
93.46
220.42
313.88
Proc. of the 14th Intl. Joint Conf. on Artificial Intelligence (IJCAI'95),
C210FVF
426.55
pp. 837845, Montr´eal, Canada, (August 1995).
[9] P. Marquis, `Consequence finding algorithms', in Handbook of De-
feasable Reasoning and Uncertainty Management Systems, eds., D.M.
Table 2.
Compilation Times
Gabbay and Ph. Smets, volume 5, 41145, Kluwer, (2000).
[10] D.L. McGuinness and J.R. Wright, `Conceptual modelling for configu-
ration: A description logic-based approach', AIEDAM, 12(4), 333344,
(1998).
[11] S. Mittal and F. Frayman, `Towards a generic model of configuration
In Table 2 we present runtimes for our UR complete knowledge
tasks', in Proc. of the 11th Intl. Joint Conf. on Artificial Intelligence,
compilation algorithm. The last column shows the total runtime
,
ÂĂ
pp. 13951401, Detroit, MI, (August 1989).
|
which is split into the time for prime implicate computation (
) and
[12] I. Rish and R. Dechter, `Resolution versus search: Two strategies for
˝Eľ
|
reduction of the prime implicate set in algorithm lines 6-14 (
).
SAT', J. Automated Reasoning, 24(12), 225275, (February 2000).
żŔÁ
Ŕ
|
vV7
We used Simon and del Val's BDD-based implementation zres as a
[13] B. Selman and H. Kautz, `Knowledge compilation and theory approxi-
mation', JACM, 43(2), 193224, (1994).
prime implicate generator [14], and ran it on a Pentium III running
[14] L. Simon and A. del Val, `Efficient consequence finding', in Proc. of the
at 733 MHz. For the reduction part we used an experimental imple-
17th Intl. Joint Conf. on Artificial Intelligence (IJCAI'01), pp. 359365,
mentation written in Haskell, compiled with the Glasgow Haskell
Seattle, WA, (August 2001).
Compiler, version 4.04. Our implementation failed on reducing the
[15] P. Tison, `Generalized consensus theory and application to the mini-
mization of boolean functions', IEEE Transactions on Electronic Com-
prime implicates for the C210FVF data set, which is indicated by a
puters, EC-16(4), (August 1967).
dash in the tables. We are currently working on an implementation in
C++ using more efficient data structures.
7
Conclusion and Future Work
We presented a method to compile the fixed part of product configu-
ration databases, and proposed a new algorithm for the computation
of UR complete compilations. First experiments indicate that, at least
for validation of configuration database properties, our method is ap-
plicable.
Besides conducting further experiments, we consider improve-
ment of knowledge compilation algorithms, e.g. by developing exact
algorithms that do not require a prior computation of all prime im-
plicates, as a promising area of future research. Moreover, it could
be of interest to evaluate the performance of knowledge compilation
on other product documentation formalisms and for other practical
application areas of configuration.
ACKNOWLEDGEMENTS
I am indebted to Laurent Simon for providing me his zres implemen-
tation for prime implicate generation.
REFERENCES
[1] Y. Boufkhad, G. ´
Eric, P. Marquis, B. Mazure, and S. Lakhdar,
`Tractable cover compilations', in Proc. of the 15th Intl. Joint Conf. on
Artificial Intelligence (IJCAI'97), pp. 122127, Nagoya, Japan, (August
1997).
[2] M. Cadoli and F.M. Donini, `A survey on knowledge compilation', AI
Communications, 10(34), 137150, (1997).
[3] O. Coudert and J.C. Madre, `Implicit and incremental computation of
primes and essential primes of boolean functions', in Proc. of the 29th
Design Automation Conf. (DAC 1992), pp. 3639, Anaheim, CA, (June
1992).
[4] A. del Val, `Tractable databases: How to make propositional unit propa-
gation complete through compilation', in Proc. of the 4th Intl. Conf. on
Principles of Knowledge Representation and Reasoning (KR'94), pp.
551561, Bonn, Germany, (May 1994).
26
Ideas for Removing Constraint Violations
with Heuristic Repair
Gottfried Schenner1 and Andreas Falkner2
Abstract. This short paper describes our current results with using
A different situation arises when the user manually creates a
heuristic repair methods in combination with an object-oriented
configuration which still works in practice, but does violate some
constraint based configurator. There are many sources of constraint
constraints of the knowledge base, either because the knowledge
violations in constraint based configuration applications. They can
base is faulty or this configuration is a very special case not
be caused by an unfinished configuration process, a new (stricter)
supported by the knowledge base. Here the user should be able to
version of the knowledge base which makes existing
"allow" the violated constraints, thus telling the solver not to
configurations inconsistent, or a manual modification which is not
attempt to repair these constraint violations.
supported by the knowledge base, but still works in practice. While
some configurators force the user to remove inconsistencies
The next sections describe the architecture of the configurator, our
manually or prohibit contradictions in the first place, we use
heuristic strategies for repair, experimental results, and
heuristic repair methods to support the user by suggesting possible
conclusions.
repair steps to resolve the inconsistencies. Whether this approach is
also suitable for standalone solving, i.e. resolving constraint
2
SYSTEM OVERVIEW
violations without user interactions, is a topic for ongoing research.
The configurator for which we are developing our heuristic repair
method has been in operation for over a year, and we also have
experience with a project engineering tool for the same customer,
1
INTRODUCTION
which has been in everyday use for over 10 years.
In real world configurator applications, product definitions and
The application domain is configuration of the hardware (racks,
user requirements change frequently. For example, new
frames, modules, cables, wrapping etc.) and the software (logical
components become available, parts run out of production, new
view of the topology, configuration of the runtime software) of
features are required, or constraints for building the product
railway interlocking stations. Typically the configuration tasks are
change. The knowledge base of the configurator has to change
complex, configuration products are in operation for many years
accordingly [1]. If the configurator loads an old configuration with
and configurator knowledge bases change during that time due to
the new version of the knowledge base, it may detect constraint
new or changed features and component types. [2] gives a short
violations because new constraints were added to the knowledge
description of the domain.
base. Typically, there are different ways to resolve a contradiction
Our configurator system is based on a Java implementation of the
and in most cases only the user knows which one is the best.
COCOS [3] configuration framework. We use an object-oriented
A similar situation occurs if we see the configuration process as a
database for storing configurations, however this is not a
sequence of user actions and configurator solving steps: The
precondition for the ideas in this paper. The knowledge base (class
constraint solver is switched off, i.e. it only reports constraint
model, constraints) is implemented in Java as well. This approach
violations but does not try to repair them. The user manually
allows a seamless integration of the configuration engine (COCOS)
changes the configuration. If the task he wants to accomplish
into the configurator (a standard Java application). For the
involves several steps, he will not be able to finish it with one
configurator application the constraint solver is just another
interaction. The configuration is somehow incomplete, thus
process that manipulates the configuration that is an instantiation of
violating some constraint.
the knowledge base.
In both situations a configuration violates some constraints and the
The set of possible configurations is determined by the possible
user may need assistance for treating the violations, i.e. repairing
instantiations of the class model. Each possible configuration can
the configuration. This can be done by a solver component that
be manually configured by the user with a generic GUI. A
suggests possible solution steps to the user and sorts the solutions
consistent configuration is a possible configuration (based on the
by their probability for solving the contradictions.
class model) that does not violate any constraint.
1 Siemens AG Oesterreich, Program and System Engineering,
Erdberger Laende 26, A-1030 Vienna, Austria,
email: gottfried.schenner@siemens.com
2 Siemens AG Oesterreich, Program and System Engineering,
Erdberger Laende 26, A-1030 Vienna, Austria,
email: andreas.a.falkner@siemens.com
27
One key feature of the system, which is also essential for the repair
Suppose that a new constraint was introduced for Points (railroad
process, is the ability to track the variables (attributes, associations)
switches) - see UML diagram Figure 1- which states that the
that are referenced in constraints. With these dependencies it is
number of Drives associated with a Point equals the value of the
possible to identify the parts of the configuration that need
attribute numberOfDrives.
reconfiguration.
Constraint:
jcosEq(p.getVar(numberOfDrives),jcosCard(getVar(drives))
3
HEURISTIC REPAIR
Assume that there has been an existing configuration with one
Given an inconsistent configuration our basic heuristic repair
Point, with numberOfDrives set to 2, and one associated Drive.
method repeats the following operations:
1) Based on the currently violated constraints choose a set of
Point1
Point1
possible repair steps. (They can be simple repair steps
numberOfDrives: 2
numberOfDrives: 2
affecting only one attribute/association or domain specific
steps which change larger portions of the configuration.)
2) From these steps, select the most promising one based on the
repair
current heuristic. (This can involve a one step lookahead or
Drive1
letting the user decide which step to take.)
Drive1
Drive2
3) If an end criterion is met, then stop.
This method can be controlled by various strategies which are
often influenced by the domain the solver is operating in. Hardware
Figure 2
configuration needs other strategies than software configuration.
In this situation the newly introduced constraint is violated. There
Typically, hardware components and their replacement are much
are two possible repair steps to resolve the inconsistency.
more expensive in the real world than software changes.
Possible heuristics are among others choosing the repair-steps
1) Associate an additional drive with the given Point. Afterwards
which minimize the overall number of violated constraint
the cardinality of the point-drive association equals the
expressions or maximize the number of repaired constraint
numberOfDrives (Figure 2)
expressions.
2) Set the numberOfDrive attribute to 1, i.e. to the number of
Simple repair steps
currently associated Drives.
Intuitively a repair step is a change to the configuration which
In the case of 1) there are further choices. Shall a new Drive be
removes at least one inconsistency. For boolean expressions this
created or an existing one reused ? The second repair step is
may consist in "flipping" the truth value of a boolean variable in
obviously the cheapest one, but is only available if the value of the
order to satisfy the affected boolean expression. I.e. in the case of
numberOfDrives attribute was not set by the user.
clauses this corresponds to local hill-climbing procedures [4].
This example shows some of the repair-steps possible for
Repairing other types of attributes is a similar procedure. To satisfy
associations. If a cardinality constraint for associations is violated
the expression preferredBranch.isFrom("LEFT","RIGHT"),
then add or remove an element from the association until the
preferredBranch being a String variable with the Value "L",
cardinality constraint is satisfied. When adding an element, we
preferredBranch has to be set to one of {"LEFT","RIGHT"}.
must decide if there are elements in the configuration which can be
used (less costly) or if a new object should be created (more costly)
Attributes also have a state which indicates "who" set the attribute.
and associated. Note that an Object o1 can only be assigned to an
Attributes with state "USERDEF" were set manually by the user
Object o2, if associating it with o2 does not violate the cardinality
and must not be changed by the solver.
constraints of its associations.
Repairing expressions that involve associations is more complex.
Since single repair steps only change small parts of the
The following example shows how a solver can repair an
configuration, this approach is especially useful for
inconsistent configuration by changing associations.
reconfiguration, i.e. when an already existing system has to be
changed to fulfill new requirements.
So far these repair steps where independent of the domain where
Point
they are used. To use them in practice the solver has to use a
- numberOfDrives
domain dependent solving/repair strategy that defines the costs for
1
removing/creating certain parts and the parts that must not be
changed. This reflects the knowledge of a human expert doing the
drives
1..3
reconfiguration.
Drive
Domain specific repair steps
There are some domains where very specific constraints exist. For
these domains it may be useful to specify special repairs steps. The
Figure 1
following example comes from the domain of configuring a
topological view of the interlocking system.
28
We found that if we let the user choose which repair step to take
next, he is often capable to finish a configuration without taking
back an earlier decision. This is because his decisions are guided
Track2
by his common sense knowledge about the involved physical
objects. For example in HW configuration there are often soft
constraints like the demand to fill a frame with modules from left
Signal1
Point1
Track1
to right. Although any other order would also lead to a working
system, this user demand should be fulfilled by the solver. One of
Figure 3
the challenges we are facing is to capture that kind of knowledge
by providing the right heuristics to the solving process.
The situation in Figure 3 shows a simple configuration. Assume the
user has created this configuration without considering the
5
CONCLUSION
constraint that after a signal there must be an element of type EOR
(end of route). This is expressed with the domain specific
Heuristic repair methods can be successfully used for the task of
constraint expression afterElement(Signal1,EOR).
configuration. They provide a means to treat constraint violations
To repair that inconsistency a number of domain specific actions
in a uniform manner, independent of the different source of the
must be taken. First a new element of type EOR must be created
constraint violations (e.g. changes in the knowledge base, changes
and it must be connected to the appropriate connectors. The result
of the configuration).
of the repair process is shown in Figure 4.
Our main motivation for this work was to support the user during
the configuration process. We also introduced domain specific
repair steps in order to reduce the number of manual user
Track2
interactions.
We are now trying to develop a full stand alone solving framework
based upon this approach, which is less important than repairing
Signal1
EOR1
Point1
Track1
contradictions. Especially when the user changes configurations
which have already been deployed to the real world, there is
always the need to query the user whether he really wants to
Figure 4
change certain parts of the configuration.
The repair action for the constraint is realized by a method of the
This heuristic repair framework can be useful for non-
constraint class. By this it is encapsulated inside the constraint and
configuration software projects as well. Since we are not using
can be tested together with the constraint. Knowledge engineers
configuration specific extensions in our class model, any systems
can use these domain specific constraints like any other constraint.
which use a standard class model [6] can benefit from using
It is usually hard to achieve this kind of behavior without using
constraints for checking valid instances of this class model and
domain specific extensions.
using repair methods for fixing invalid ones.
User guided repair
6
REFERENCES
To integrate the repair process into the user interface, the user can
select a violated constraint on the GUI and choose an action from a
[1] Andreas Falkner, Versioning of Knowledge Bases and Configurations,
list of possible repair actions. This way the user not only gets an
AAAI 1999 Workshop on Configuration, Orlando, FL, July 1999.
explanation for the constraint violation (the list of dependent
[2] Andreas Falkner, Gerhard Fleischanderl, Configuration requirements
from railway interlocking stations, IJCAI 2001 Workshop on
variables) but also different possibilities to remove the violation.
Configuration, Seattle, WA, Aug. 2001.
The user actions are then driven by the set of violated constraints.
[3] Gerhard Fleischanderl, Gerhard E. Friedrich, Alois Haselböck, Herwig
This also reduces the demand for the implementation of domain
Schreiner, and Markus Stumptner. Configuring large systems using
specific user interfaces.
generative constraint satisfaction. IEEE Intelligent Systems & their
The same mechanisms used to repair configurations can also be
applications, 13(4):59-68, July/Aug. 1998.
[4] Steven Minton, Mark D. Johnston, Andrew B. Philips, Philip Laird
used to build configurations from scratch. The solving process is
Minimizing Conflicts: A Heuristic Repair Method for Constraint-
then guided by the constraints yet to be satisfied.
Satisfaction and Scheduling Problems, Artificial Intelligence vol.58,
pp.161-205, 1992
4
EXPERIMENTAL RESULTS
[5] Bart Selman, Henry A. Kautz. An Empirical Study of Greedy Local
Search for Satisfiability Testing. National Conference on AI
We are currently experimenting with various repair strategies. Our
(AAAI'93), pp.46-51, Washington, D.C., July 1993.
goal is to use the repair approach also for stand-alone solving. As
[6] James Rumbaugh, Ivar Jacobsen and Grady Booch, The Unified
our approach is a greedy local search strategy, we experienced all
Modeling Language Reference Manual, Addison-Wesley, 1999.
the problems involved with nonsystematic approaches [5]
(termination, local maximum, etc.) Often this can be handled by
using the appropriate solving strategy or querying the user.
Unfortunately the development of a suitable solving strategy is not
straight-forward. This is a topic for further research.
29
Configuration Tools and Methods for
Mass Customization of Mechatronical Products
Udo Pulm1
Abstract.1 This short paper presents the problems concerning
defines all the possibilities and degrees of freedom of the product
modularization and configuration of functionally complex products
and defines it as far as possible. The new aspect is that not only a
with high requirements and a large amount of variants in mecha-
specific amount of variants is offered, from which the customer can
nical engineering. By that we are searching for a software tool that
configure his products, but that also completely new components
focuses on the product development rather than sales and market-
are developed, produced and integrated. The advance development
ing or the customer. We would like to present requirements to a
mainly consists of the structure planning and the evaluation of
configuration tool or method from this point of view and where
product properties, next to the modular, parametric, or principle
configuration may has to go. These approaches are embedded in a
development of components. The difference becomes clear in a
comprehensive research project on mass customization.
comparison with traditional design processes. Usually, there is a
quite short (months) structure planning process, i. e. the conceptual
1 INTRODUCTION
design, which is mostly based on a long-term grown product
Increasing market demands, both concerning higher customer
architecture with only little changes. After that the actual
requirements and pressure from competitors, force enterprises to
development takes place. This design takes most of the time (years)
diversify their product range. Almost each company has to deal
and results in one product with a defined amount of derived
with the problems of offering more variants and the implicit
variants. As last step, there is the configuration of the final product,
complexity of products and processes. There are many strategies
which ideally just takes a few minutes when not regarding the
and methods in mechanical engineering such as building blocks,
decision process. The development process in mass customization
platform strategies, modularization, standardization, complexity
consists of two phases, the development of the product spectrum,
management, etc. The logical consequence of this growing variety
which can take months to years, and which not inevitably contains
seems to be mass customization, that every customer gets his own
the derivation of one concrete variant (except e. g. for evaluation).
individual or at least individualized product (e. g. [1]). This strate-
This process may take longer than usual conceptual design or even
gy implicates disadvantages such as the uncertainty of customer
than the complete development. The use of the product spectrum's
wishes as well as advantages by shifting paradigms, i. e. to get
potential, the adaptation to the final product definition then takes
away from classical organizations, structures, and companies.
about one day, so that there is still the possibility of individualizing
and developing many not predefined aspects. Another difference is
2 MASS CUSTOMIZATION
that in mass customization the potential is always growing, i. e. the
experiences of the single product adaptations feed back to the
Mass customization is the answer to the demand for more indivi-
product spectrum and following adaptation processes.
dual and diverse products. It is also the offer that each customer
gets his individual product in conditions that are comparable to
3 EXISTING TOOLS AND METHODS
those of mass produced products. The product does not need to be
completely individual, it just has to be individualized so far that
Though mass customization is a new approach, there are similari-
each customer wish is fulfilled and the product fits perfectly. The
ties to other methods which are recommended to be used and
degree of this individualization depends on the product and still has
adapted (see [2]). The basis of existing tools and methods is the
to be defined. Mass customization in mechanical engineering im-
general product structure that consists of a hierarchical, "vertical"
plies completely new production and logistic technologies and pro-
composition structure (AND-relations), and a hierarchical,
cesses, company structures such as miniature plants near to the
"horizontal" generalization structure (OR-relations), which are both
market, and integration of services. The very central aspect is the
interconnected on different levels of detail. Next to this already
integration of the customer in interactive processes. Our focus is on
very complex system, there are cross connections, i. e. relations
the very different product development processes. The derivation
such as constraints, configuration rules, or the like. At least these
of the individualized product has to take place in short time, e. g.
three relations appear and have to appear in each product model
one day. To achieve this, a so called product spectrum has to be
concerning configuration or variants. Most design tools based on a
developed in advance, so that the final product definition is adapted
product structure offer these relations somehow, e. g. product data
on basis of the concrete customer wishes. The product spectrum
management (PDM) systems (e. g. [3]), document management
systems, content management systems, ontology editors (e. g. [4]),
CAE systems, configuration systems (e. g. [5]), or also bills of
1
material. But the possibilities of these tools are not adequate to
Institute of Product Development, Technische Universitaet Muenchen,
build up a respective product structure. This is the same for CAD
Boltzmannstr. 15, 85748 Garching, Germany, email: pulm@pe.mw.tum.de
30
tools, which have to be also integrated due to their significant
Connections are possible between any of these elements. In other
position in product development as well as to achieve a words, each elements "consists" of all the other elements on a
comprehensive tool for the whole development process. A major
higher level of detail. Other general requirements on a software
problem may be that those systems have to be very flexibly but
tool are the consistency of the data, stability and economy of the
precise in representing the product's architecture and logical
tool, connections to other applications, documentation of
structure. Some of the consequences and problems of this are
experiences, support of information flow, distributed use, etc.
addressed and discussed in the following.
4.2
General questions
4 STRUCTURE PLANNING TOOLS
We would like to address some general questions or problems
The following chapter specifies requirements as well as problems
concerning the modularization of a product in order to enable a
and first solutions for structure planning tools.
configuration as well as existing tools and methods. They also
reflect further requirements to such a system.
4.1
Requirements
4.2.1
Emphasis of early phases instead of focus is on
Next to the above mentioned basic elements, other elements are to
sales and marketing
be represented in mass customization. These are altogether
Most configuration tools or similar products are based on an exist-
- components, i. e. products, modules, assemblies or parts, here in
ing product structure and serve to handle or manage this structure
the meaning of "masters", i. e. an abstract formulation (= class),
in later phases. The "filling" of the data base is not in the centre of
e. g. body or engine of a car
the regard. From our point of view, there has to be an emphasis of
- variants, i. e. a specification of a master component, e. g. 100 hp
the early phases, where the basic product structure, which shall be
engine or 150 hp engine
oriented to variants and configuration, is defined. By that, the
configuration system also becomes a tool for the engineer.
- requirements, i. e. any postulated property of the product and the
starting basis for the development process, e. g. cost or safety
4.2.2
Representation of a product spectrum in contrast to
predefined variants and flexibility of the product structure
- functions, i. e. the abstract formulation of a component's purpose
next to a predefined frame
in order to not being bound to a specific solution or to have a
placeholder for customer wishes (possibly with input and
In mass customization we do not want to just offer a specific
output), e. g. transport person, transport material
amount of variants. Each customer wish shall be fulfilled. This
means that in the structure degrees of freedom are to be
- degrees of freedom, i. e. the prognosticated customer wishes and
represented, which may be fuzzy and cannot be totally foreseen, so
the possibilities of the product spectrum, e. g. color, size, engine
that the product model has to be extensible. This is also important
since the potential of the product spectrum grows with each
- realization possibilities, i. e. the link between the customer
adaptation process. It implies a certain flexibility of the product
wishes or degrees of freedom and the concerned components,
e. g. modular, parametric, completely individualized
structure and the configuration tool, i. e. it should be able to repre-
sent arbitrary elements, and above all the overall structure should
- properties, i. e. the actual properties of the components described
be easily changeable, i. e. the whole structure and not only single
by criterion and specification, e. g. color red, size 5 m
elements. This point represents the main demand in our approach.
- groups as a combination of different elements to support the
4.2.3
Continuous use throughout the design process
configuration, e. g. sports gear and sports seats
The integration of specific elements is necessary in order to sup-
- geometry, i. e. a logical decomposed description of a part on a
port standard procedures and techniques of design methodology
more detailed level, e. g. surface, line, point
(see [6]). A combination of these elements (requirements, func-
tions, principles, drawings, etc.) has not been realized in commer-
- all relations between the elements, as there are
cial tools yet. In addition to point 4.2.1 the single phases of the
đ logical relations (is_part_of, is_a), e. g. engine is part of car
product creation process have to be connected, so that there is a
path from customer wishes to technical characteristics. It belongs
đ configuration relations (not_with, must_with, can_with), e. g.
to this point that there is not another isolated application but that
red body not with green seats
the tool can be integrated into the existing applications.
đ semantic relations between different elements (has), e. g. car
has function transport person
4.2.4
Complexity and level of detail
One of the major problems is how to deal with complexity itself.
đ technical relations, i. e. different kinds interfaces between
Most methods and tools somehow help managing complexity, but
components, which can again consists of other components,
how to handle systems with thousands or millions of parts and a
e. g. interface between body and engine.
respective amount of relations is not answered yet. Together with
All these elements can be represented in separate hierarchical
this there is the question for the right level of detail, i. e. how
structures, but have to be connected in order to get a comprehen-
detailed the product is described. A hierarchical structure can help
sive product model. There may be overlaps between these elements
this problem; it also allows to combine customer views (on a low
as well as further elements such as versions, technologies,
level of detail) and technical aspects (on a high level of detail). The
structures, customer wishes, or documents. But those elements are
most effective way of handling complexity seems to be systems
the substantial components of engineering design methodology.
engineering, i. e. among other things a strict systematical and
31
modularized regard of the product. Regarding a software tool, this
became visible. The object oriented data model could be extended
implies the possibility of user-specific views.
in runtime. The semantic network should be represented either in a
graphical network or in matrices between any two also the same
4.2.5
Modularization and standardization vs. integration
of the above listed elements, combined with a hierarchical
Another major problem is the contradiction between modulariza-
structure of the single elements.
tion und standardization. Increasing requirements, e. g. concerning
safety, space, comfort, and functionalities, force engineers to
4.3.2
Combination of standard applications
design highly integrated products. This only technical solution
Another tool combined standard applications (MS Office) in order
prevents an easy modularization and by that standardization of the
to get graphical representations as well as an underlying complex
product. An evaluation of these contrasts is still missing.
data base. This approach is also recommended in our topic since
4.2.6
Usability and implementation
- we need to represent the product structure graphically, store the
model in an database, and have to use matrices for the relations
The usability of the system is important for both the efficiency of
between the objects
the work and the acceptance of the tool. An essential aspect is the
self-explanatory use. This counts for the engineer as well as for the
- the use of standard applications is easy for each user, so that the
customer. A guideline for good usability may be given by the ISO
acceptance is high and there is not another isolated application,
9241. Related to this is the implementation within a company (see
which can become obsolete. Furthermore, the existing data can
[7]). A tool will just be accepted if either the pressure of superiors
be easily used in another context.
or the benefit in the use of it is big enough. The problem with
Next to a combination of these two approaches, we try to adapt
implementation is that many tools show their benefits mainly in a
existing tools to our requirements.
company wide, large scale (e. g. PDM systems), so that enormous
efforts are necessary before they can be used.
5 SUMMARY AND CONCLUSION
4.2.7
Design process support
We have presented the main requirements on configuration or
It is desirable that the design process itself is supported. Since
structure planning tools coming from mass customization in mech-
design processes cannot be automated in general, the intention is
anical engineering. The main aspect is to manage complexity with
on the presentation of experiences, the estimation of effects and
computer support. The antagonisms of integration vs. modulariz-
logical networks, as well as the condensation of relevant data in
ation, or between flexibility and methodical support are problems
order to support controlling and decisions.
and contradictions that are not solved by existing methods or
applications yet. Main questions are, which application helps this
4.2.8
Technical implementation
situation best, how can it be used, where are its borders and how
Next to the implementation of a system within a company, the
has an engineer to proceed behind these borders. The described
technical implementation poses some questions. These are the
topic is part of an project within the interdisciplinary collaborative
same in an object oriented, relational, or similar approach (e. g.
research centre (SFB 582) "Near to the market production of indi-
ontologies), and are exemplarily:
vidualized products", which is founded by the DFG. The problems
show that the collaboration between (mechanical) engineers and
- Are properties within objects or are they objects themselves (with
software designers has to be heightened since on one side there are
criterion and specification)?
the problems and on the other side there are the solutions. Often
- Are different object types really different objects or is there a
enough software does not fit the problems adequately, or much
general object with the object type as an property?
efforts are spend for the search for and development of reasonably
usable applications on side of mechanical engineers.
- Are there relations (v. above) between objects, are relations
objects themselves, or are relations properties of objects?
REFERENCES
These questions belong to the topic of how sophisticated, how
[1] B. Pine, Mass Customization, The New Frontier in Business
fixed, or how flexible the system shall be, and they are very central
Competition, Harvard Business School Press, Boston, 1993.
from a pragmatic point of view.
[2] U. Lindemann and U. Pulm, Enhanced Product Structuring and
Evaluation of Product Properties for Mass Customization. HKUST;
4.3
Approaches
TUM (Eds.): MCP'01, World Congress on Mass Customization and
Personalization, Hong Kong, 2001. (CD-ROM)
We have developed some tools, which now have to be adapted to
[3] J. Schoettner, Produktdatenmanagement in der Fertigungsindustrie,
the requirements of mass customization in mechanical engineering.
Prinzip Konzepte Strategien, Hanser, Munich, 1999.
They show approaches that help to manage the previous described
[4] N. F. Noy and M. A. Musen, Algorithm and Tool for Automated
problems in a first step.
Ontology Merging and Alignment, Seventeenth National Conference
on Artificial Intelligence (AAAI-2000), Austin, TX, 2000.
4.3.1
Semantic network and systems engineering
[5] A. Guenter and C. Kuehn, Knowledge-Based Configuration - Survey
and Future Trends, F. Puppe, Expertensysteme '99, Lecture Notes,
Many tools base on a representation of the product, the respective
Springer, Berlin, 1999.
process, and the underlying organization according to systems
[6] K. Ehrlenspiel, Integrierte Produktentwicklung, Hanser, Muncih, 1995.
engineering, i. e. a both hierarchical and networked structure of
[7] R. Stetter, Method Implementation in Integrated Product Development,
elements and their relations. A previous developed tool (see [8])
Dr. Hut, Munich, 2000.
offered an semantic network, where the elements could be arranged
[8] S. Ambrosy, Methoden und Werkzeuge für die integrierte Produkt-
according to design methodology and where the process logic
entwicklung, Shaker, Aachen, 1997.
32
Optimal Configuration of Logically Partitioned
Computer Products
Kevin R. Plain˝
1
CONFIGURATION GOALS
of the system overview's tree structure can present worksheets for
the selection of items within the narrow scope of the node.
An established corporate sales tool uses Trilogy's SalesBUILDER R
technology to configure a wide range of hardware and software prod-
ucts. The tool has evolved over time from an application capable of
3
OPTIMIZING ON SIX DIMENSIONS
configuring single server systems to an application capable of con-
1. System Boards (cells): The position of system boards involving
figuring storage clusters involving multiple servers. In this demon-
multiple partitions across multiple system cabinets with consider-
stration, we examine a configuration solution for a commercially
ation for bus structure and bandwidth. System boards are ranked
available server. This server employs a new partitioning scheme that
according to the nature of their partition. Partitions with more sys-
provides hardware and software isolation. Product experts provided
tem boards are given priority.
specifications for the configuration model. The specifications de-
2. Memory: Balancing across multiple system boards within a single
mand optimal configurations that address the characteristics of an
partition. This optimization will not conflict with other optimiza-
entire system and at the same time consider the requirements of in-
tions.
dividual logical partitions. The server must be configured as a single
3. Processors: Balancing across multiple system boards within a sin-
machine from a system- wide, physical level, and each logical parti-
gle partition. This optimization will not conflict with other opti-
tion must to be handled as if it were a separate server. Each partition
mizations.
has its own system boards, processors, memory, operating system,
4. I/O Boards (card cages): The position of I/O boards involving
software, PCI cards, and external storage. The partitions compete for
multiple partitions with consideration for the proximity of con-
shared resources such as the system board slots, I/O card cage spaces,
nected system boards. Optimized across multiple system cabinets
and I/O expansion cabinets. A single server may span multiple cab-
and multiple expansion cabinets. A card cages may move to a less
inets and multiple cases within cabinets. The logical partitioning is
optimal position in deference to other card cages when the prox-
independent from the physical configuration, but the optimization of
imity of a connected cell presents a conflict.
the hardware's physical placement is greatly influenced by the logical
5. Chassis (cases): Location within cabinets showing consideration
partitioning. Features of the sales tool increase the complexity of the
for ergonomics, weight, and factory processes. Expansion cabi-
configurator because the tool provides users with several powerful
nets are added as the need for them appears. If the number of
views of the same configuration and offers incremental/interactive
card cages exceeds the number allowed in the system cabinets,
functionality within each view. Product experts also specified that
the configurator will add expansion cabinets. The maximum num-
the model should support the configuration of multiple servers that
ber of system cabinets and expansion cabinets may be limited by
potentially share common resources such as storage cabinets.
marketing, factory, or engineering restrictions.
6. PCI Cards: The position of PCI cards within and across I/O boards
2
CONFIGURATION VIEWS SUPPORTED
of single partitions with consideration for card speed, card volt-
age, and I/O board designations. Some cards may be given spe-
1. Diagram: The diagram view provides an abstracted representation
cial treatment due to the minimal requirements of the partitions.
of the physical system including information about the contain-
These special cards may move to a card cage connected to a spe-
ment and connectivity of various components. The server's dia-
cially designated cell. Explicit placement of these special cards by
gram needed to simplify the complex representation of partitions
a user of the configuration tool may cause card cages to rearrange
across multiple server systems. This was achieved by color cod-
and reconnect to different cells.
ing the configuration. Users are able to move/add/delete/replace
components via the diagram.
2. Overview: The system overview provides a hierarchical represen-
4
COMPLEXITIES OF OPTIMIZATION WITH
tation of the configuration with a mixture of physical and logical
INCREMENTAL CONFIGURATION AND
concepts. This view allows users to add/remove/copy partitions
LOGICAL PARTITIONING
and to move physical components from one partition to another.
3. Worksheet: The worksheet view allows users to make specific se-
Optimal configuration is complicated by the incremental/interactive
lections about how they want the system configured. The work-
features of the sales tool interface, and by the interaction of opti-
sheet view is directly supported by the system overview. Nodes
mization criteria. Users can add items in any order and at any time
during the configuration process. For example, the addition of a new
˝
Trilogy, Austin, Texas, email: kevin.plain@trilogy.com
I/O board to a partition may cause optimization to position the new
33
board within a system cabinet to keep it in close proximity to its con-
nected system board. Optimal configuration may require relocation
of an existing I/O board in order to provide space for the new I/O
board. The seemingly trivial movement of a single PCI card demon-
strates how simple user requirements can have a large impact on a
configuration due to dependencies between optimized components.
In this example, each partition requires a specialized PCI card and
the configurator tries to keep the I/O board containing the specialized
card in close proximity to the first system board of the partition. Op-
timization tries to balance the needs of all partitions and at the same
time maintain this close proximity rule with limited I/O board spaces.
The organization of the I/O boards is affected if the user drags/drops
the specialized card from one location to another or adds redundant
specialized cards to a partition. Interaction between optimization cri-
teria can be seen when the user decides to add/remove system boards
to/from a partition. Optimal configuration can require complete re-
arrangement of system boards to maximize bus characteristics. I/O
boards have their own optimization characteristics with regards to
system boards, and may need complete rearrangement as well. This
may require some I/O boards with ideal positioning to be moved into
spaces that are less ideal.
5
ADDITIONAL MODEL FEATURES
1. Upgrade scenarios
2. Save and restore of configured products in an evolving knowledge
base
Figure 2.
Reference for some of the various types of hardware that are
combined to configure the server
3. Bundling and quote of the configured product
Figure 1.
Logical partitioning
Figure 3.
Example of logical partitioning and optimization across physical
enclosures
34
Vehicle Sales Configuration : the Cluster Tree Approach
Bernard Pargamin1
Abstract. Most current commercial configurators, mainly based
C2G was an outcome of a `Product Diversity Modelling' Project
on constraint propagation, are known, among other limitations, to
initiated six years ago. In this framework, Product Diversity is
be unable to guarantee complete deduction in free order interactive
represented by a compiled data structure on which operates a
configuration. Yet, on specific ranges of products, completeness of
deductively complete configuration (inference) engine whose
inference can be achieved. New approaches, based on the
response time is linear on the size of the compiled structure.
compilation of the system of constraints defining the diversity of
Basically, the set of boolean variables used in the constraints
the product to configure, are making their way. We present such a
restricting diversity is split into clusters by converting a graphical
complete configuration engine, C2G, developed internally by
representation of the problem into a tree structured representation
Renault, with a list of basic functional requirements that we
where each node in the tree represents a tightly-connected sub-
couldn't find together in any commercial configurator. The
problem, and the arcs represent the loose coupling between sub-
compiled approach we describe made their implementation
problems. Inference is done locally at each node and the updated
possible, especially the much needed `filtering on the price' and
state of the node is propagated between nodes to provide a global
`user driven conflict resolution'.
solution. Inference proves to be linear in the tree structure.
Basically, compilation splits the configuration variables into
clusters organised in a tree. Variables in a cluster are in high
This paper is structured as follows: We will first outline
interaction, while variables of different clusters are in low
Renault's basic requirements for configuration in section 2, then
interaction. Inference is done locally in each cluster and the
we will discuss Vehicle Diversity Specification and modelling in
updated state of the node is propagated between nodes to provide a
section 3. In section 4, we will present the principles of Diversity
global solution. Inference proves to be linear in the tree structure,
Compilation we used in C2G, and we will show how very fast
allowing short and predictable run-times. This representation is
complete deductive inference can be obtained by state propagation
especially efficient for low treewidth domains, which is the case
on a cluster tree. Section 5 will focus on the problem of price
for the automotive industry.
representation, the only non boolean part of our data, and we will
present a propagation algorithm that finds the cheapest vehicle
1 INTRODUCTION
consistent with the current state of the configuration in linear time,
thus enabling fast exact filtering by a customer's constraint on the
Web enabled sales configurators are widely used in the automotive
maximum price. Section 6 will outline consistency restoration in
industry, but the level of functionality offered by these
C2G, a very basic feature for a commercial configurator, and we
implementations is deceptively low. A basic customer's question
will present some concluding remarks in section 7.
such as: `I have $15,000. What is the cheapest vehicle I can buy
with a diesel engine and an automatic gearbox ?' won't generate
2 RENAULT'S BASIC CONFIGURATION
any direct answer from the online configurators of the major
REQUIREMENTS
vehicle builders world-wide. You will have to study the
documentation first, choose a model outside the configuration
The functional configuration requirements we discuss here come
process, configure your vehicle with possibly inadequate cost
from our experience with the shortcomings of the mainstream
information, eventually iterate on this process and backtrack if you
commercial configurator we used previously. They reflect the
are unlucky until you get what you are looking for.
views of both Renault Marketing managers and configuration
Customers don't like to iterate: they want responsiveness,
specialists.
accuracy, full information on the consequences of their choices,
free order and full freedom of choice. They want effective filtering
on their budget. They don't like backtracking. If your on-line
2.1 Completeness of inference should be guaranteed. This
configurator can't give that, they will zap.
means that all that can be logically inferred at a given state of the
process is actually inferred. No dead end, no backtracking for the
Renault, a major vehicle manufacturer, was bothered by this
user. This is absolutely the number one item on top of the
situation and articulated its configuration vision in an internal
requirements list. Configurator vendors say it is impossible to
white paper (2001, unpublished). It then arrived at the conclusion
obtain, because of the NP-Completeness of the problem. Actually,
that the current mainstream commercial configurators, because of
we arrived at another conclusion, as far as automotive sales
their general purpose, were unable to offer this kind of rich
configuration is concerned.
functionalities on Renault range of vehicles, and it decided to
The importance of this point is better seen if we realize that the
switch to an internal configuration project: C2G (2nd Generation
diversity specification could be inconsistent, and the configurator
Configurator) in order to provide them on the web by Q3 2002.
wouldn't even detect it. The failure rate of the configuration
_____________________________________________________
would then be 100%.
1 Renault S.A., Direction des Technologies et Systčmes d'Information
92109 Boulogne, France.
e-mail: bernard.pargamin@renault.com
35
2.2 Full information on the consequences of a
2.6 Freedom of choice
choice should be provided (may be optionally in some cases) :
· Free configuration order: Configuration is a completely
excluded or implied features must be exhibited because they may
user driven process: the user chooses the specification order that
cause the customer to change his choice when he sees the
best fits his priorities. There is no compulsory "natural order", but
undesirable consequences of his projected choice. This feature is a
of course, when the user has expressed his priorities, the
dynamic way to inform the user of the logical constraints, at the
configurator can choose the order that best optimizes its
moment they will trigger inference. Without it, the user would
computational task. There is a suggested order that optimizes
discover the effect of the constraints too late, and would have to
configuration, and if the user is pleased with it, we use it.
force a conflicting choice, which would cause computational
· Negative choice: A feature can be either chosen or excluded
overhead to the configurator to restore consistency, and a real
by the customer. Excluding a feature is a valid choice. Allowing
nuisance for the user. Full information includes also:
only the selection of a feature can't prevent an undesired feature to
appear inadvertently by having been implied by a constraint.
2.2.1 Pricing information: in the real life, no one makes
· Permissiveness: The user can change his mind without any
choices without any cost consideration. You wouldn't fill your cart
restriction during the process: an inconsistent choice can be forced
in a supermarket where you only discover the final price at the
at any step by the customer, and it is the configuration engine's
pay-desk. Moreover this pricing information must be accurate and
task to restore consistency, by proposing changes to some previous
guaranteed. At every step, we need the minimum price to be shown
choices. This situation may arise routinely simply because the user
for each choice, i.e. the price of the cheapest vehicle fulfilling the
doesn't know the logical constraints concerning features, so he
partial configuration. This is very different to simply showing the
may be surprised by their effect. It will happen less often if he
price of an option, often irrelevant in order to show the real
enters his choices by decreasing priority order.
financial impact of a choice: if option A implies option B or option
Consistency restoration must be completely user driven: there
C ( a very common type of constraint), in front of A you should
are usually several ways to do it, and it is the user's choice to
put: Previous Min Price + price option A + min(price option B,
determine which one is best for him, not the system's choice.
price option C). Adding only the price of option A would be
· No obligation to choose: Any choice at a given state can be
misleading.
delayed by the user: "I don't know yet" or "I don't bother" are
perfectly acceptable answers to a proposed choice. So, the user is
2.2.2 Delivery timing information is also needed. This is not
never stuck because he has no answer to give. The configurator
trivial, because you need a way to evaluate the best possible
will come back later on these choices, and sometimes it will not
delivery date on a partially configured vehicle. This is the only
even be necessary because the answers will be automatically
way to show which specific choice makes the delay grow. An
deduced from other user's choices. This applies of course to the
evaluation at the end of the configuration would be too late and
model's choice, and it means that we need unrestricted
would not say what to change in the vehicle features to improve its
transversality in the configuration process.
delivery date. In the most sophisticated implementation, this
requirement is a real challenge: a centralized application must
2.7 No prerequisite knowledge of the product should be
manage capacity constraints and manufacturing schedules to give
expected from the customer. Any choice should have an associated
accurate estimates. As a first step, an approximation based on
help giving extensively the pro's and the con's of each alternative.
manufacturing eligibility dates and marketing dates would
This requirement introduces some form of recursive configuration
probably be sufficient.
inside the primary configuration. For instance the choice of a radio
Existing stocks of readily available vehicles should be taken into
set is itself a second level configuration based on features such as:
account in the configuration process.
number of channels, power per channel, CD with charger, traffic
information , ...Just showing the list of the various possible radio
2.3 Filtering on a maximum budget and/or a maximum
types with their price is clearly not enough to let the user make an
delivery lead time must be possible. In certain cases (fleet
informed choice.
configuration) they are strict constraints that can't be bypassed.
2.8 Tranversality of the configuration process is required:
2.4 Financing possibilities (loan) should be integrated in
first generation configurators require that the process can only
the process in the same way as the price. The user is not expected
begin when the customer has already chosen a vehicle Model. This
to learn at the end of a 10 minutes configuration that this vehicle
seems a reasonable assumption, but it is not. The customer is thus
exceeds its financing capability: we need a filtering capability
expected to have previously collected paper information about
similar to price filtering. This is much more difficult to achieve
models and versions, studied it carefully by himself and to have
because there are several types of loan and the rate of the loan
made his choice alone. This means that a whole important part of
may depend on the final price of the vehicle, which is not known
the configuration process is left aside, without any assistance.
until the end of the configuration.
We think that Model and Version choices are obviously part of
the configuration process, and that in this case, these choices might
2.5 Adequate treatment of option packs must be
be the consequence of other features choices. Note that this
provided. Packs generate implicit constraints that must be
reverses the traditional view that the natural order is to begin with
explicited (for instance, two packs with a common feature are
Model/Version, and then to choose options whose availability is
exclusive, so as not to make the customer pay twice that feature).
the consequence of the version's choice.
In the configuration process, they should be treated just like any
other features.
2.9 Automatic completion of a partial configuration must
be available, with several alternate optimization criteria: cheapest,
most quickly available or mixed, such as `the cheapest vehicle
under $15,000 available in less than 3 weeks'.
36
2.10 Assisted conflict resolution
Our model of vehicle diversity is thus a pure boolean CDNF,
The main configurator's task is to prevent the appearance of
equivalent to a propositional theory, and in this first step, we have
conflicts by automatically excluding all choices that wouldn't be
transformed Renault PDS into a propositional knowledge base
consistent with the user's former choices. If the configuration
(PKB) able to feed a configuration engine. In this model, most
engine guarantees completeness of inference, a conflict should
interesting tasks become reasoning tasks, involving logical
never appear. But even in this case, the user may change his mind.
inference [21, 19, 20] , such as satisfiability tests and clausal
He can force an inconsistent choice, and the configurator must
entailment.
analyze the inconsistency so as to find the minimal sets of former
This first modelling step is necessary but is not sufficient,
choices that have to be revised to restore consistency. Without this
because as it turns out, most available complete algorithms for
feature, the user would have to start a new configuration session
those tasks are exponential in the number of variables or in the
and to repeat most of his previous choices.
number of constraints. Brute force, even with gigahertz computers,
leads us instantly to exponential blow-up.
2.11 Response time must be compatible with an interactive
A typical Renault Model is described by a lexicon of 100
web usage: at most a few (< 2 ) seconds in the worst case.
spec_cat containing about 400 specs. The CDNF has about 2 to
3000 conjunctive terms and commercial diversity (size of the
3 RENAULT VEHICLE DIVERSITY
search space for the configurator) ranges from 103 to 1010 . At the
engineering stage, diversity is much higher, reaching 1020.
SPECIFICATION AND MODELLING
An example of translated PDS for a Renault X64 model can be
found for benchmarking purpose at :
Vehicle diversity (i.e. the number of distinct possible customer's
http://www.irit.fr/ACTIVITES/RPDMP/CSPconfig.html
choice, can be huge, reaching at Renault 1020 at the engineering
A cnf sample file is also available on demand (10813 clauses on
stage and up to 1010 at the showroom. Moreover, this diversity is a
658 variables)
source of major industrial complexity because of technical,
commercial and legal constraints resulting in numerous
4 PRINCIPLES OF RENAULT
implications and/or exclusions of features and options.
CONFIGURATION ENGINE C2G
In the automotive industry, Product Diversity Specification
(PDS) is addressed by an ISO norm: STEP-AP214 (ISO 10303-
We have to deal with the well known NP-completeness of the
214:2001). In STEP terminology, vehicle descriptive features or
propositional satisfiability problem, and consequently of boolean
attributes are known as specifications (abbrev. specs), grouped in
configuration. But NP-completeness doesn't prevent polynomial or
specifications_categories (abbrev. spec_cat).
even linear solutions in specific domains. While a general
A spec_cat is a variable whose discrete possible values are the
polynomial time configurator is impossible, a linear time vehicle
specs. For example we have a spec_cat `gearbox type' with 2
configurator proves possible if you can exploit the structure of the
specs: `manual' and `automatic'. A spec is an instantiation of a
domain.
spec_cat, and we will attach a boolean variable (abbrev. bvar) to
C2G is fully based on the standard compiled representation of
each spec, among which we will find our configuration variables.
Renault vehicle diversity in the form of a cluster tree that has been
The set of spec_cat, called lexicon, is globally common to all
used in various applications since 1995 . Compiled approaches for
models of the constructor's range, with some exceptions. A
propositional theories, increasingly popular, consist in investing
specific vehicle is uniquely defined by a tuple of specs, one and
once in a heavy off-line compilation whose computational
only one for each spec_cat of the lexicon.
overhead can be amortised with many fast on-line queries. The size
A subset of the vehicle range is intentionally defined by a
of the compiled structure is not directly related to the number of
boolean formula on specs, called a specification_expression
models of the theory and can be exponentially smaller. BDD
(abbrev. spec_expr).
(binary decision diagrams [5]), finite automata (a variant of BDD
Vehicle diversity is usually not practically enumerable, and this
[9, 18]), DNNF (Deterministic negation normal form [7]), prime
prevents an extensional definition such as a simple enumeration.
implicates [15] are mainly used to this effect. See also [13] for a
Diversity must be intentionally specified, by spec_expr.
classification of compiled approaches. We must stress that there is
no best compilation, because it depends on the structure of your
The basic idea is that the entire combination of specs is allowed,
problem and on what you intend to do with your data. We, at
except those that are explicitly excluded by boolean constraints
Renault, decided to use cluster tree compilation, as the most
expressed by spec_expr. The task of PDS is to build, control, store
effective and efficient representation of vehicle diversity, seen as a
and retrieve these constraints.
propositional theory, for deductive and probabilistic inference.
Actually, for ergonomic and convenience reasons, engineering
Cluster trees are well known in the field of probabilistic
staff in charge of PDS do not usually directly manipulate
inference, especially in the Bayesian Network area. A main
spec_expr, but instead they complete compatibility tables of
advance was given by Lauritzen and Spiegelhalter [6, 11] with the
various shapes and size, they explicitly enumerate valid tuples of
use of a secondary structure, the cluster tree (also called join tree,
specs on selected subset of the lexicon, and sometimes they write
junction tree, clique tree) and an exact probabilistic inference
spec_expr in a simplified syntax.
algorithm based on Probability Propagation in the Cluster Tree
The main point is that PDS of any form can be translated into
(PPCT). See [10] for a procedural description of PPCT. We are
boolean constraints in linear time, giving a CDNF (Conjunction of
not aware of any significant use of cluster trees in deterministic
Disjunctive Normal Form). Alternatively, a CSP (Constraint
inference problems, except by Darwiche [7, 8] and Dechter [22].
Satisfaction Problem) formalism can be used, but it is known to be
equivalent.
Implicit constraints due to the spec_cat/spec structure must be
4.1 Construction of the cluster tree
explicitly added: inside a spec_cat, any 2 specs are exclusive and
the disjunction of the specs is TRUE.
A cluster tree is a tree whose nodes are clusters of variables,
satisfying the running-intersection property: if a variable is shared
by 2 nodes, it must be present in every node on the path between
37
the 2 nodes. This property is needed for the completeness of
usually much lower. This cluster implementation has two nice
inference algorithms operating on the cluster tree. The treewidth of
properties:
the cluster tree is the number of variables in the largest cluster. The
· the more we add constraints to the cluster, the smaller its size
best cluster tree is the one with minimal treewidth w* (the size of
is.
the cluster tree is exponential in w*). In a sense, the treewidth is a
· All operations are vector boolean operations, taking
measure of the connectivity of the constraints graph.
advantage of internal register parallelism on 32 or 64 bit
We are looking for the minimal treewidth cluster tree in which
words.
every constraint fits in at least one cluster (i.e. all the bvars of the
constraint belong to this cluster).
4.3 Propagation on the cluster tree
We first build the interaction graph of the boolean constraints in
the following way: we create a node for each boolean variable, and
We choose an arbitrary cluster as the root of the tree.
put an edge between node i and j if vi and vj appear simultaneously
Two adjacent nodes of the cluster tree share variables. We can
into a constraint. This graph shows graphically the structure of the
treat these variables as a cluster, named the sepset, that we
problem.
introduce on the graph as a new node between the two clusters.
We then built the cluster tree with the smallest possible
Propagation of state from cluster i to parent cluster j involves 2
treewidth. This is a NP-hard problem, but a number of algorithms
phases:
are available in the literature for computing a close to optimal
· Marginalisation: propagation from cluster i to sepset ij: we
cluster tree from an acyclic undirected graph. [2, 3]. Moreover, a
set to FALSE all positions of the CSV of the sepset whose
linear time algorithm for finding tree decompositions of small
compatible positions in the CSV of cluster i are all FALSE.
treewidth was presented by Bodlaender [4]
· Dispatching: propagation from sepset ij to cluster j: For
4.2 Cluster implementation
every position k of the sepset with a FALSE value, we set to
FALSE all compatible positions of the CSV of the cluster j.
Whenever the state of a cluster changes, we make a global
Clusters are supposed to be small enough so that brute force can
propagation on the whole structure, by propagating the change up
solve any inference problem inside the cluster. Yet, a clever
to the root following the path of the cluster tree, and then
implementation is still of utmost importance to improve speed and
propagating down to the leaves. During this process, whenever a
allow for bigger clusters. First we build the set of all boolean
cluster's state changes, it propagates the change to all the variables
variables instantiations consistent with the constraints that fit in the
in the cluster.
cluster (logical models). We associate to each bvar xi a boolean
In this way all bvar truth values that can be deduced from a state
vector (VBV) whose ith position is set to TRUE if xi is TRUE in
change are deduced, and we have a deductively complete truth
the ith model, FALSE otherwise.
maintenance system.
Root
000000001001100100 CSV
Clusters
Variables
ABCJ
FALSE
a 111111110000000000
Dispatch
Sepset
b 010001000100010010
VBV
A B
of bvar d
A B C
Marginalize
c 111100001111000000
ABDP
d 111011101110111000
ABCHK
TRUE
e 100110011001100100
BD
A D
Set of models (in columns)
ADE
BDF
for the constraint C: (a*b=>c+d)*(e=>-b)*(a+c=>d+e)
Figure 2. A cluster tree with its sepsets
Figure 1. A cluster implementation
4.4 Main benefits of the cluster tree
We then build a cluster state vector (CSV) a boolean vector
whose ith position is set to TRUE if the ith model is consistent with
Cluster tree compilation is efficient and compact because logical
the current state of knowledge on the values of the bvar of the
independence is built in the structure: The compiled structure fully
cluster, FALSE otherwise.
exploits the factorisation resulting from the logical conditional
During the configuration process, when a bvar is instantiated by
independence relations expressed graphically by the cluster tree:
the user, the CSV is re-evaluated by a boolean AND operation
any two nodes and their descendants are logically independent
between the prior CSV and the VBV or its negation. The effect of
given an instantiation of their shared variables.
the change is then propagated to all other bvar of the cluster that
are deduced to TRUE (resp. FALSE) if its VBV (resp. the negation
4.5 Characteristics of Renault's cluster trees
of its VBV) is compatible with the CSV.
Local inference in the cluster is sound and complete in linear
The cluster tree structure is not related in any way to the physical
time in the number of models. In the worst case, this size is
structure of the car. The treewidth is around 40 to 50 for our
exponential in the number of variables, but as a cluster groups a
model's cluster tree representation, depending on the model. But,
small number of variables with high interaction, the real size is
38
as noted above, the constraints application strongly reduces the
5.2 Price List internal representation
size of the biggest cluster, usually around a few hundreds columns.
Constraints can change every week, so a full offline compilation
We assume that every spec_expr fits in at least one cluster. If it
has to be done 4 to 6 times a month for each country: 10 to 15
were not the case, we would rebuild the cluster tree to satisfy this
cluster trees are compiled in about 2 minutes, with a total storage
condition. We associate a numerical Price Vector to the (boolean)
requirement of 300 to 400 KB for the logical structures.
state vector of each node and sepset of the cluster tree.
The ith position is set to the sum of all the prices associated with
4.6 Other uses of the cluster tree
spec_expr satisfied with the partial instantiation i of specs in the
cluster. In this way, the price vector stores the contribution of each
The cluster tree is a highly tractable compiled representation of
partial instantiation of the bvars of the cluster to the global price.
diversity for Renault vehicles: a number of different NP-complete
Propagation of price vector from cluster i to parent cluster j
real life problems involving diversity can be solved with it in
involves 2 phases:
polynomial time, and often in linear time.
· Marginalisation: propagation from cluster i to sepset ij: set
· Probabilistic applications: Probabilistic constraints used to
every position k of the price vector of sepset ij to the min of
express vehicle forecast fit in the cluster tree, and by solving a
its compatible positions in the price vector of cluster i.
linear problem, we can compute a factorised joint probability
· Dispatching: propagation from sepset ij to cluster j: For
distribution (JPD) consistent with the forecast. The global
every position k of the sepset, set all compatible positions of
JPD is split into local JPD, expressed at the cluster level by a
the price vector of the cluster j to the kth value of the price
probability vector for each model of the cluster.
vector of the sepset.
· Propagation algorithms: the same scheme of propagation up
We are now ready to describe our algorithm MPP (Minimal price
and down allows for rapid calculus of the
by Propagation):
o cardinality of the solutions space
o maximum entropy distribution by iterating
5.3 Algorithm MPP
propagations
o entropy of a factorised jpd, cross entropy between 2
JPD's
1
Initialise each cluster's Price Vector
o probability of a variable under evidence on other
2
For each node, from the leaves up to the root:
variables
-
Combine the direct descendant messages by adding their
propagated price vector
-
Propagate up:
Within Renault Information Systems, they are used routinely in
-
Marginalize min price on the sepset
various applications, with about 60,000 queries per day:
-
Dispatch up
3
Select the min price on the price vector of the root
· Consistency of Product Diversity Specification
· Consistency of parts documentation with diversity
specification
6 RESTORING CONSISTENCY
· Consistency of vehicle forecast with diversity specification
· Vehicle forecasting with Maximum Entropy completion of
This is a major feature for a commercial configurator, as it has
incomplete forecast
been discussed in a earlier section.
· Engineering and Commercial vehicle configuration
Whenever a contradiction is deliberately entered by the user,
C2G finds a minimal subset of inconsistent former choices, in
5 FILTERING ON A MAXIMUM PRICE
linear time in the number of former choices. The user then has to
change at least one of these choices. This change may in turn
In theory, we could handle the price in a pure boolean way:
create a new contradiction, so the process is recursive. The
We add a new spec_cat `Price' with specs ranging from $5,000 to,
maximum price given by the user is treated like any other vehicle
say, $50,000 (by increments of $1), and calculate the price of
feature's choice. Very commonly, there will be an inconsistency
every vehicle configuration, then, for every value x we build the
between the maximum price and the set of n options chosen,
boolean constraints expressing the equivalence between spec $x
showing a n+1 choices inconsistency, that can be eliminated by
and the DNF of all vehicle configurations costing $x.
changing the maximum price or dropping any subset of options, at
Practically, it would be intractable, and we will of course
the user's request. In any case, restoring consistency is a fully user-
proceed in another way: The idea is to represent the cost function
driven process.
as a utility function that can be factorised on the cluster tree, and to
Finding a minimal subset of inconsistent former choices is
use a propagation algorithm that finds the cheapest vehicle
performed in this way:
compatible with the current state of the configuration in linear
We maintain an ordered list of user choices. The completeness of
time, thus enabling fast exact filtering by a customer's constraint
inference of G2G guarantees that the contradiction is detected
on a maximum price.
when it happens, on the last choice. We then reorder the list by
putting this last choice in first position, we make a full roll-back in
5.1 Price List external specification
the configuration session, and a roll-forward with the reordered
list, reintroducing one by one each former choice. We will
The total cost of a vehicle is the sum of pricing elements that apply
necessarily encounter a new contradiction, that will give us the 2nd
only for certain vehicles. There is a price for a version, and prices
term of the contradiction, and so on until all terms of the
for the various options available on this version.
contradiction are grouped in the beginning of the list.
A Price List is a list of pricing elements, each consisting of a set
of 2 elements: a spec_expr and a price.
39
7 SUMMARY AND CONCLUSION
[9] Fargier, H and Amilhastre, J (2000) Handling interactivity in a
constraint based approach of configuration ECAI 2000
[10] Huang C. , Darwiche A. (1996) Inference in belief networks: A
Modelling vehicle diversity by a system of boolean constraints is a
procedural guide.
first necessary step, but it is insufficient to solve efficiently NP-
International Journal of Approximate Reasoning, 15(3):225-263.
Complete problems of interest such as clausal entailment, and
http://www.cs.ucla.edu/~darwiche/ijar95.pdf
especially to feed a complete configurator.
[11] Lauritzen, S. L. and Spiegelhalter, D. J.(1988) Local computations
Renault C2G configurator does not make inferences by
with probabilities on graphical structures and their application to
constraint propagation, but adds a second crucial step by compiling
experts systems. In journal of the Royal Statistics Society, B, 50,157-
the constraints into a secondary structure, a cluster tree on which
224 1988
complete deductive inference by state propagation is linear on the
[12] Mathieu, P and Delahaye, J.P. (1994) A kind of logical compilation for
knowledge bases.
size of the compiled structure (which in turn happens to be
Theoretical Computer Science 131 (1994) 197-218
exponential in the treewidth w* of the interaction graph). Provided
ftp://ftp.lifl.fr/pub/projects/achievement/tcs94.ps.gz
that w* is small, we can perform complete inference with a
[13] Marquis, P and Darwiche, A (2000), A Perspective in Knowledge
bounded response time guarantee.
Compilation In IJCAI-01.
As it happens, small treewidth is the general case for vehicles
http://www.cs.ucla.edu/~darwiche/ijcai-01.ps
diversity, as well as many other industrial domains, and our
[14] Marquis, P (1995) Knowledge Compilation Using Theory Prime
approach has a certain generality.
Implicates. IJCAI 1995
The key step to transforming a NP-Complete general problem
[15] Pearl, J. (1988) Probabilistic Reasoning in Intelligent Systems:
Networks of Plausible Inference
into a linear time algorithm is thus to exploit the structure of the
Morgan Kaufmann, San Mateo, California, 1988.
problem, as expressed by the connectivity of the interaction graph.
[16] Roussel, O (1997)
The small treewidth of this graph allows for fast dynamic
L'achčvement des bases de connaissance en calcul propositionnel et
construction of the cluster tree from the boolean constraints and for
en calcul des prédicats.
compact representation of the nodes of the cluster tree.
Thčse de doctorat. Lille 1997
This off-line compilation allows for very fast predictable on-line
ftp://ftp.lifl.fr/pub/projects/achievement/these_roussel.ps.gz
queries, and the computational overhead of the compilation can be
[17] Schrag, R and Miranker, D. (1996) Compilation for critically
easily amortised with thousands of queries. Compilation pays for
constrained Knowledge Bases.
submitted to the Journal of Artificial Intelligence Research.
itself.
http://www.iet.com/users/schrag/my-papers.html
Propagation algorithms we developed are closely related to
[18] Veron, M Fargier, H and Aldanondo, M (1999) From CSP to
probability propagation (see [6, 10, 11, 15]).
configuration problems
These ideas were implemented at Renault in a new configuration
AAAI-99 Workshop on Configuration
engine, C2G, that will be used by Q3 2002 for commercial
http://wwwold.ifi.uni-klu.ac.at/~alf/aaai99/08Veron.doc
configuration applications, proving their robustness in real life
[19] C. Sinz, A. Kaiser, W. Küchlin (2000) SAT-Based Consistency
industrial-strength problems.
Checking of Automotive Electronic Product Data. Presented at the
ECAI 2000 Configuration Workshop, Berlin.
http://www-sr.informatik.uni-tuebingen.de/projects/pdm/ecai2000.ps
[20] C. Sinz, A. Kaiser, W. Küchlin (2001) Detection of Inconsistencies in
REFERENCES
Complex Product Configuration Data Using Extended Propositional
SAT-Checking. Proceedings of the 14th International FLAIRS
[1] Amir, E and McIlraith, S (2001) Theorem proving with structured
Conference, AAAI Press
theories,
[21] Kaiser, A. and Küchlin, W (2001) Automotive Product
17th Intl' Joint Conference on Artificial Intelligence (IJCAI'01), 2001
Documentation. Proceedings of the 14th International IEA/AIE
http://www-formal.stanford.edu/eyal/papers/oor-theory-1.0-ijcai-final.ps
Conference, Springer, 2001.
[2] Amir, E (2001) Efficient Approximation for Triangulation of
[22] Dechter, R and Pearl, J (1989) Tree Clustering for Constraint
Minimum Treewidth, 17th Conference on Uncertainty in Artificial
Networks, Artificial Intelligence pp. 353-356 1989
Intelligence (UAI '01), 2001.
http://www.ics.uci.edu/~csp/r06.pdf
http://www-formal.stanford.edu/eyal/papers/decomp-uai01-final-1.0.ps
[3] Becker, A and Geiger, D. A Sufficiently Fast Algorithm for Finding
Close to Optimal Junction Trees
In Proceedings of the 12th Annual Conference on Uncertainty in
Artificial Intelligence 1996
[4] Bodlaender, H. L. (1992) A linear time algorithm for finding tree-
decompositions of small treewidth.
ftp://ftp.cs.uu.nl/pub/RUU/CS/techreps/CS-1992/1992-27.pdf
[5] Bryant, R. (1992) Symbolic Boolean Manipulation with Ordered
Binary-Decision Diagrams.
In ACM Computing Surveys Vol. 24 n° 3.
http://www.cs.cmu.edu/~bryant/pubdir/acmcs92.ps
[6] Cowell, Dawid, Lauritzen, Spiegelhalter. (1999) Probabilistic
Networks and Expert Systems, Springer Verlag .
[7] Darwiche, A. (1999) Compiling knowledge into decomposable
negation normal form.
In Proceedings of International Joint Conference on Artificial
Intelligence (IJCAI), 1999
http://singapore.cs.ucla.edu/darwiche/dnnf.ps
[8] Darwiche, A. (2000) On the Tractable Counting of Theory Models and
its Applications to Belief Revision and Truth Maintenance. in
International Workshop on Belief Change & Journal of Applied Non-
Classical Logics, 2000
http://www.cs.ucla.edu/~darwiche/count.ps
40
Constraint-based Product Structuring for Configuration
Barry O'Sullivan
Abstract. Traditionally, applications of Artificial Intelligence have
and product configurations, but due to space reasons this issue is not
regarded configuration as the problem of arranging parts, from pre-
discussed here (see [7] for a detailed discussion).
defined sets of alternatives, in a manner consistent with a predefined
The remainder of the paper is organized as follows. Section 2
product structure. While such work is valuable, and represents a sig-
presents a brief overview of the theory of conceptual design for
nificant portion of the AI body of research, real-world configuration
configuration upon which the research presented in this paper is
is a more complex task. In real-world configuration, the development
based. Section 3 discusses how this theory can be modeled in a
and maintenance of the initial product structure is a core activity.
constraint programming language. Section 4 presents a simple case-
Alternative product structures provide a basis for developing prod-
study which highlights some pertinent details of approach presented
uct families and variants, desirable for satisfying market demands
here. In Section 5 a number of concluding remarks are made.
for customized product delivery. In addition, the availability of prod-
uct structuring rationale can be exploited when attempting to support
2
A THEORY OF CONCEPTUAL DESIGN
product re-configuration in the field and recognizing redundancies
The model of conceptual design adopted in this research is based
in product configurations. This paper presents a constraint-based ap-
on the hypothesis that during the conceptual design process a de-
proach to supporting the synthesis of alternative product structures
signer works from an informal statement of the requirements that
for configuration. The approach is based upon an expressive and gen-
the product must satisfy and generates alternative configurations of
eral technique for modeling: the design knowledge which a designer
physical elements which satisfy them. These physical elements, re-
can exploit during a design project; the life-cycle environment which
ferred to in this research as "design entities", can be regarded as
the final product faces; the design specification which defines the
proto-components, between which are defined a set of context re-
set of requirements that the product must satisfy; and the alternative
lationships restricting the nature of the interfaces between the design
structures that are developed by the designer.
entities. During a configuration session with a human user, these
proto-components are extended into parts. In addition, as parts are
1
INTRODUCTION
being introduced into the scheme the precise meaning of the appro-
priate context relationships becomes known and define the interfaces
Configuration is becoming a well studied design activity. In partic-
between them.
ular, there has been a growing interest in issues such as diagnosis
Central to the process of product structuring is an understanding
of knowledge-bases for configuration [4], explanation generation [5]
of function and how it can be provided. The process involves the
and tradeoff generation for interactive configuration [6].
development of a function decomposition which provides the basis
While such work is valuable, and represents a significant portion
for a configuration of physical elements that form a scheme. The
of the AI body of research, real-world configuration is a more com-
configuration of physical elements with partially specified interface
plex task. In real-world configuration, the development and mainte-
definitions between them can be regarded as a scheme for a set of
nance of the initial product structure is a core activity and warrants
product structures. Depending on the degree of detail that the de-
further study. Alternative product structures provide a basis for devel-
signer has specified, each product structure will either be very gen-
oping product families and variants, desirable for satisfying market
eral or specific. Since, in the configuration domain, we are generally
demands for customized product delivery. In addition, the availabil-
only concerned with problems where the sets of parts and interfaces
ity of product structuring rationale can be exploited when attempting
are known. The product structuring problem is concerned with de-
to support product re-configuration in the field and recognizing re-
veloping a sufficiently detailed scheme from which the customer can
dundancies in product configurations.
configure the product of choice.
This paper presents a constraint-based approach to supporting the
In the remainder of this section a brief overview of the theory of
synthesis of product structures for configuration. This synthesis pro-
conceptual design of product structures used in this research will be
cess can be regarded as an instance of conceptual design [7]. The ap-
presented. It will be shown how the approach presented here can sup-
proach is based upon an expressive and general technique for mod-
port design for configurability by supporting the synthesis of product
eling: the design knowledge which a designer can exploit during a
structures which contain all of the necessary constraints required to
design project; the life-cycle environment which the final product
define a particular configuration problem. For a more complete dis-
faces; the design specification which defines the set of requirements
cussion of the theory the reader is encouraged to refer to the more
that the product must satisfy; and the alternatives structures that are
detailed literature available [7].
developed by the designer. The approach also facilitates the devel-
opment, evaluation and comparison of alternative product structures
2.1
The Design Specification
ˇ
Cork Constraint Computation Centre, Department of Computer Science,
The conceptual design process is initiated by the recognition of a
University College Cork, Ireland (b.osullivan@cs.ucc.ie)
need or customer requirement. This need is analyzed and translated
41
into a statement which defines the function that the product should
function: provide transport
provide (referred to as a functional requirement) and the physical
requirements that the product must satisfy. This statement is known
bicycle
as a design specification.
A design specification will always contain a single functional re-
support
change
provide
quirement, since this represents the highest level of abstraction which
faciitate
provide
movement
energy
passenger
direction
support
defines the purpose of a product.
drives
supports
In addition, two classes of physical requirement can be identified:
supports
product requirements and life-cycle requirements. A product require-
supports
ment can be either a categorical requirement that defines a relation-
supports
ship between attributes of the product or it can be a preference related
to some subset of these attributes. A life-cycle requirement can be
Design Principle
Physical Instance
either a categorical requirement that defines a relationship between
handlebar assembly
attributes of the product and its life-cycle, or it can be a preference
saddle
related to some subset of these attributes.
frame
wheel assembly
2.2
Conceptual Design Knowledge
pedal assembly
During conceptual design, the designer must synthesize a product
structure defined in terms of physical elements which satisfies each
of the functional and physical requirements in the design specifica-
tion. To do so, the designer needs considerable knowledge of how
function can be provided by physical means. Often, this knowledge
exists in a variety of forms; a designer may not only know of partic-
Figure 1.
Abstracting an example design principle from a bicycle.
ular parts and technologies that can provide particular functionality,
but may be aware of abstract concepts which could also be used. For
abstraction which can be used to encourage creativity and analogical
example, a designer may know that an electric light-bulb can gener-
reasoning during design.
ate heat or, alternatively, that heat can be generated by rubbing two
A design entity, on the other hand, is a physical, tangible means
surfaces together. The latter concept is more abstract that the former.
for providing function. A design entity is defined by a set of param-
In order to effectively support the human designer during concep-
eters and the relationships that exist between these parameters. For
tual design, these alternative types of design knowledge need to be
example, an electronic resistor would be modeled as a design entity
defined and modeled in a formal way.
which is defined by three parameters, resistance, voltage and current,
between which Ohm's Law would hold.
2.2.1
The Function-Means Map
2.2.2
Embodiment of Function
The notion of the function-means tree has been proposed by re-
searchers from the design science community as an approach to cat-
As the designer develops a scheme for a product structure every func-
aloging how function can be provided by means [1]. The use of
tion in the scheme is embodied by a means. Each means that is avail-
function-means trees in supporting conceptual design has attracted
able to the designer has an associated set of behaviors. Each behavior
considerable attention from a number of researchers [3].
is defined as a set of functions that the means can be used to pro-
Here a generalization of the function-means tree, called a function-
vide simultaneously. Each behavior associated with a design princi-
means map, is used to model functional design knowledge [7]. In a
ple will contain only one function to reflect the fact that it is used to
function-means map two different types of means can be identified:
decompose a single function. However, a behavior associated with a
a design principle or a design entity.
design entity may contain many functions to reflect the fact the there
A design principle is a means which is defined in terms of
are many combinations of functions that the entity can provide at
functions that must be embodied in a design in order to provide
the same time. For example, the bulb design entity mentioned above
some higher-level functionality. Design principles are abstractions of
may be able to fulfill the functions provide light and generate heat
known approaches to providing function. By utilizing a design prin-
simultaneously. However, when a design entity is incorporated into a
ciple during product structuring, the designer can decompose higher-
scheme (for the purpose of supporting functionality provided by one
level functions without committing to a physical solution too early
of its behaviors), it is not necessary that every function in this be-
in the design process. The functions that are required by a particu-
havior be used in the scheme. In this respect redundant functionality
lar design principle collectively replace the function being embodied
may be introduced into a scheme which may become useful at a later
by the principle. The functions which define a design principle will,
stage when trying to incorporate new functionality into the scheme
generally, have a number of context relations defined between them.
during a re-configuration exercise.
These context relations describe how the parts in the scheme, which
provide these functions, should be configured in abstract terms so
that the design principle is used in a valid way. An example design
2.3
Scheme Configuration using Interfaces
principle based on the abstraction of a bicycle is show in Figure 1.
In this figure functions are illustrated as round-edged boxes, context
When a designer begins to configure a scheme for a product struc-
relations are represented in dashed lines. Note that the design princi-
ture, the process is initiated by the need to provide some functional-
ple is not just a model of a known physical design solution, but is an
ity. The designer considers the various means that she has available
42
in her design knowledge-base. Generally, the first means that a de-
The same type of functionality is frequently needed in different
signer will select will be a design principle. This design principle
parts of a scheme. Thus, we must represent, not a function, but an
will substitute the required (parent) functionality with a set of child
instance of a function. The definition of an instances of a function,
functions. Ultimately the designer will embody all leaf-node func-
referred to here as a func, is presented in Figure 4.
tions in the scheme with design entities. During this embodiment
domain func
process the context relations, from the design principles used in the
=::= ( verb : string,
scheme, will be used as a basis for defining the interfaces between
noun : string,
id
: func_id ).
the design entities used in the scheme. The precise nature of these in-
terfaces cannot be known with certainty until the designer embodies
Figure 4.
Modeling a function instance in Galileo.
functions with design entities; this is because the link between func-
tions and design entities is generally not known with certainty during
The final field in the definition of an embodiment (Fig-
the development of the function decomposition for the scheme. Once
ure 3) is called reasons. The reasons field associated with
the set of design entities, and the interfaces between them, are known
an embodiment records the motivation for the existence of the
the resultant scheme can be regarded as a product structure which de-
embodiment. It does so by recording the identity numbers of the
fines the configuration problem. Until the precise nature of a particu-
function instances whose provision introduced the need for the em-
lar interface is known, they are modeled as relations between design
bodiment. The reasons field of an embodiment provides the ba-
entities which can be used to reason about the product structure; for
sis for identifying those design entities between which context rela-
example, interfaces may represent simple spatial relationships which
tions must be considered.
can inform an evaluation related to the relative position of parts in a
product. In Section 3.2.4 a detailed example will be discussed.
3.1.1
A Generic Model of Means
The types of interfaces that may be used to synthesis a product
structure will be specific to the engineering domain within which the
Figure 5 illustrates how the generic notion of a means can be mod-
designer is working. Indeed, these interfaces may also be specific
eled. Note that there are two kinds of means: principles and en-
to the particular company to which the designer belongs in order to
tities. The final field in the definition of the generic notion of a
ensure the configurability of the product.
means, called funcs provided, is used to store which function
instances within a scheme the means is being used to provide. Of
course, a means should be used to provide only those function in-
3
CONSTRAINT-BASED IMPLEMENTATION
stances which it is capable of providing; this requirement is captured
by a universally quantified constraint. The definition of the relation
The implementation language used in this research was an extended
is a possible behaviour of is an application-specific con-
form of Galileo [2], a frame-based constraint programming language
cept.
based on the First-Order Predicate Calculus.
It is believed that the approach to product structuring presented
domain means
here has wide applicability; it has been already tested in a vari-
=::= ( hidden scheme_name : string,
type
: means_type,
ety of real-world domains. Consequently, its implementation can
funcs_provided
: set of func_id ).
distinguish between those features which are generic to all ap-
domain means_type
=::= { a_principle, an_entity }.
plications and those features which are specific to individual de-
all means(M):
sign/configuration domains. In the following sections important as-
is_a_possible_behaviour_of( M.funcs_provided, M ).
pects of the details of the constraint-based implementation of the de-
sign theory presented in Section 2 will be presented. For a more de-
Figure 5.
Modeling a design means in Galileo.
tailed treatment, the reader is encouraged to refer to the literature [7].
Based on the generic notion of a means, generic definitions for
design principles and design entities can be defined. The generic no-
3.1
Implementing Generic Concepts
tion of a principle and an entity are defined in Figure 6 as
specializations of the generic notion of a means.
In Figure 2 the Galileo model of a generic scheme is presented.
domain principle
domain scheme
=::= { P: means(P) and
=::= ( scheme_name : string,
P.type = a_principle }.
structure
: embodiment ).
domain entity
=::= { E: means(E) and
Figure 2.
The representation of a generic scheme.
E.type = an_entity }.
Figure 6.
Generic design principle and design entity models.
Since a scheme exists solely to provide the functionality required
in the design specification, its structure should be the embodiment of
that functionality. This model is based of the fact that the designer
is mostly concerned with producing embodiments for intended func-
3.1.2
Context Relationships and Entity Interfaces
tions by choosing, from among the known means, those which will
Eventually, each embodiment is realized by the introduction of de-
provide the required functionality (Figure 3).
sign entity instances. Thus, to ensure that design entities are config-
domain embodiment
ured appropriately, the context relationships between embodiments,
=::= ( hidden scheme_name : string,
due to any design principles used during the function decomposition,
intended_function
: func,
chosen_means
: known_means,
will have to be realized by interfacing appropriately the entity in-
reasons
: set of func_id ).
stances which realize the embodiments. The generic definition of an
Figure 3.
Modeling the embodiment of a function.
interface is is provided in Figure 7.
43
domain interface
domain bicycle
=::= ( hidden scheme_name : string,
=::= { B: principle(B) and
entity_1 : entity_id,
exists( B.e1 : embodiment ) and
entity_2 : entity_id ).
exists( B.e2 : embodiment ) and
exists( B.e3 : embodiment ) and
all interface(I):
exists( B.e4 : embodiment ) and
exists entity(E1), entity(E2):
exists( B.e5 : embodiment ) and
I.entity_1 = E1.id and
provides_the_function( B.e1.intended_function,
I.entity_2 = E2.id and
'facilitate', 'movement' ) and
is_in_the_same_scheme_as( I, E1 ) and
provides_the_function( B.e2.intended_function,
is_in_the_same_scheme_as( I, E2 ).
'provide', 'energy' ) and
provides_the_function( B.e3.intended_function,
'support', 'passenger' ) and
Figure 7.
Modeling generic interfaces between design entities.
provides_the_function( B.e4.intended_function,
'change', 'direction' ) and
provides_the_function( B.e5.intended_function,
It can be seen that an interface is defined between a pair of
'provide', 'support' ) and
drives( B.e2, B.e1 ) and
entities. We shall see later how this generic definition of an interface
supports( B.e5, B.e1) and
supports( B.e5, B.e2) and
can be used to define application-specific interfaces for embodying
supports( B.e5, B.e3) and
supports( B.e5, B.e4) }.
context-relations.
Figure 9.
Definition of a company-specific design principle.
3.2
Implementing Application-Specific Concepts
3.2.3
Defining Application-Specific Design Entities
The generic concepts introduced above serve as the basis for defining
Company-specific design entities are defined as specializations of the
the application-specific concepts that are needed to support product
generic model of a design entity which was presented in Figure 6.
structuring. The definition of these application-specific concepts in
In every company there are particular properties of parts that are of
terms of the generic concepts will now be considered briefly.
general interest. Thus, Figure 10, presents a definition of a company-
specific design entity called a raleigh entity which has these
3.2.1
Defining Known Means
properties.
The various design principles and design entities that are ap-
domain raleigh_entity
=::= { E: entity(E) and
proved for use by designers working for the company constitute a
exists( E.width
: real ) and
exists( E.mass
: real ) and
set of known means. The functionality that is offered by these
exists( E.material : raleigh_material ) and
E.mass = mass_of( E ) }.
known means must be known in advance. In addition, each of these
domain raleigh_material
principles and entities must be described in detail by defining them
=::= { cfrp, titanium, aluminium, steel }.
as specializations of the generic representation of a means.
function mass_of( raleigh_entity ) -> real
=::= { E -> 2:
E.material = cfrp,
E -> 3:
E.material = titanium,
domain known_means
E -> 5:
E.material = aluminium,
=::= { an_axle, a_bicycle, a_wheel_assembly, ... }.
E -> 10: E.material = steel }.
relation can_simultaneously_provide( known_means,
set of func )
Figure 10.
The implementation of a company-specific design entity called
=::= { ... }.
raleigh entity.
Figure 8.
Defining of known means available to designers.
In this figure it
can be seen that
the concept of
a
raleigh entity is defined to be a specialization of the generic
In Figure 8 an example of a small collection of means which
notion of an entity. The specialization consists of an additional
are available to a designer working for Raleigh Leisure Vehi-
three fields, representing width, mass and material, with an
cles Limited is presented. As well as listing the known means
equational constraint for estimating the mass. When a company
that are available to designers working for a company, the
has defined its own pseudo-generic concept of a design entity, it
company knowledge-base must specify the functions that each
can define a repertoire of company-specific design entities. These
known means can provide. This is done by declaring the relation
company-specific design entities may be specializations, with further
called can simultaneously provide. This relation describes
additional fields, of the company's pseudo-generic concept of design
the functionality that can be simultaneously provided by the various
entity or they may be merely synonyms of it. A set of primitive eval-
known means available to engineers working for a particular com-
uation functions can be defined in terms of the properties of design
pany.
entities.
3.2.2
Defining Company-specific Design Principles
3.2.4
Defining Application-Specific Context Relationships
Application-specific design principles can be defined as specializa-
If a design principle specifies a context relationship between some
tions of the generic design principle (Figure 6). Consider, for exam-
of its embodiments, that relationship must, ultimately, be realized
ple, a principle based on a bicycle is defined in Figure 9.
by some analogous relationship between the sets of design entity in-
This application-specific principle is defined to be a specialization
stances which realize the embodiments so that the product is config-
of the generic notion of a principle. It was seen in Figure 1 that a
ured in a valid way and can be properly evaluated.
bicycle principle involves five embodiments. The context re-
For example, the bicycle principle defined in Figure 9 specifies
lationships between the embodiments which are shown in Figure 1
that a drives relationship must hold between the first two embodi-
are also defined. For example, a drives relationship must exist be-
ments introduced by the principle, those which embody the functions
tween the embodiment e2 and embodiment e1. These context
provide energy and facilitate movement.
relationships constrain the manner in which the design entities in the
The drives relationship between two embodiments is defined
final product structure are configured.
in Figure 11. This definition specifies that the drives relationship
44
relation drives( embodiment, embodiment )
=::= { (E1,E2): drives( { X | exists entity( X ):
bicycle
derives_from( X, E1 ) },
faciitate
provide
support
change
provide
movement
energy
passenger
direction
support
{ Y | exists entity( Y ):
wheel assembly
pedal assembly
saddle
drives
supports
supports
derives_from( Y, E2 ) } ) }.
supports
supports
relation drives( set of entity, set of entity )
=::= { (E1s,E2s): exists E1 in E1s, E2 in E2s:
behaviours = { { provide transport } }
behaviours = { { faciliate movement } }
behaviours = { { provide energy } }
behaviours = { { support passenger } }
drives( E1, E2 ) }.
relation drives( entity, entity )
=::= { (P,W): pedal_assembly(P) and wheel_assembly(W) and
molded frame
handlebar assembly
frame
chain
is_in_the_same_scheme_as( P, W ) and
!exists chain(C):
is_in_the_same_scheme_as( P, C ) and
!exists mechanical_interface(M1):
behaviours = { { provide support,
behaviours = { { change direction } }
behaviours = { { provide support } }
behaviours = { { transmit energy } }
M1.entity1 = P.id and
support passenger } }
M1.entity2 = C.id and
M1.relationship = drives and
!exists mechanical_interface(M2):
air cushion
engine
chassis
harness
M2.entity1 = W.id and
M2.entity2 = C.id and
M2.relationship = drives }.
behaviours = { { faciliate movement } }
behaviours = { { provide energy } }
behaviours = { { provide support } }
behaviours = { { support passenger } }
Figure 11.
The meaning of the drives context relation between
embodiments.
holds between two embodiments if and only if an analogous rela-
skateboard
steering assembly
axle
tionship, also called drives, holds between the two sets of entity
instances that derive from these embodiments. The drives rela-
behaviours = { { provide transport } }
behaviours = { { change direction } }
behaviours = { { support wheel, faciliate rotation },
{ punch holes } }
tionship between sets of derived entity instances is defined in terms
of yet another analogous relationship, this time between individual
Figure 13.
The means contained in an example design knowledge-base
and their possible functionalities.
entity instances.
The precise realization of the context relationship specified in a
provide
principle depends on which design entities are used to realize the em-
transport
bodiments that must satisfy the context relationship. Suppose that a
pedal assembly is the design entity used to provide energy
bicycle 1
and a wheel assembly is the design entity used to facilitate
movement, we can see in Figure 11 the relationship that would have
to be satisfied between these two entity instances in order to properly
embody the drives context relation.
faciitate
provide
support
change
provide
movement
energy
passenger
direction
support
A mechanical interface (Figure 12) is simply a special-
ization of the generic notion of an interface. It can be seen to be
drives
supports
a specialization of a application-specific notion of interface, called
supports
a raleigh interface, which is a specialization of the generic
supports
notion of interface.
supports
domain mechanical_interface
Figure 14.
Using a design principle to embody the functional requirement.
=::= { S: raleigh_interface(S) and S.type = mechanical and
exists( S.relationship : mechanical_relationship ) }.
domain mechanical_relationship
=::= { controls, drives, supports }.
design principle introduces the need for five more functions to be em-
domain raleigh_interface
=::= { I: interface(I) and
bodied. The designer must now select means for embodying each of
exists( I.type : raleigh_interface_type ) }.
these functions. The presence of these additional embodiments is due
domain raleigh_interface_type
to the constraint-based description of the bicycle design principle.
=::= { spatial, mechanical }.
In Figure 15 the designer selects the wheel assembly design entity
Figure 12.
Modeling company-specific interfaces.
to embody the function facilitate movement. This introduces an in-
stance of this means, called wheel assembly 1, into the scheme. As
4
CASE-STUDY
the designer introduces design entities into the scheme the context
relations that exist between the function embodiments must be con-
In this section an example of how product structures can be synthe-
sidered. However, since there is only one design entity in the scheme
sized as schemes will be presented. The example illustrates a very
presented in Figure 15 no context relations are considered at this
simplified instance of product structuring for configuration. How-
point in the scheme's development.
ever, the approach presented in this paper has been validated in real-
In Figure 16 the designer has chosen to embody the function pro-
world design domains such as mechatronics, optical systems and
vide energy with the pedal assembly design entity. This introduces
electronics design.
an instance of this means, called pedal assembly 1, into the scheme.
In Figure 13 an illustration of the various means contained in an
Since the drives context relation must exist between the embodi-
example design knowledge-base is presented. This knowledge-base
ments of the functions facilitate movement and provide energy, this
comprises one design principle, called bicycle, and a number of de-
caused, in addition to the existence of the design entities wheel as-
sign entities, such as a wheel assembly and a saddle. The set of be-
sembly 1 and pedal assembly 1, the introduction of an instance of the
haviors for each means in the knowledge-base are presented under
chain design entity, called chain 1. Both of these interfaces are used,
the icon representing the means.
along with chain 1, to embody the drives relation that should exist
In Figure 14 an instance of the design principle bicycle, called bi-
between wheel assembly 1 and pedal assembly 1.
cycle 1, has been used to embody the function provide transport. This
Figure 17 shows the state of the scheme after the designer has cho-
45
provide
provide
transport
transport
bicycle 1
bicycle 1
faciitate
provide
support
change
provide
faciitate
provide
support
change
provide
movement
energy
passenger
direction
support
movement
energy
passenger
direction
support
drives
supports
drives
supports
supports
supports
supports
supports
supports
supports
wheel assembly 1
wheel assembly 1
pedal assembly 1
saddle 1
handlebar assembly 1
frame 1
chain 1
mechanical interface 6
Figure 15.
Using a design entity to embody a function in the scheme.
supports
mechanical interface 5
mechanical interface 1
mechanical interface 2
supports
drives
drives
mechanical interface 4
supports
mechanical interface 3
provide
transport
supports
Figure 17.
An example scheme configuration.
bicycle 1
knowledge-base must be satisfied.
faciitate
provide
support
change
provide
movement
energy
passenger
direction
support
5
CONCLUSION
drives
supports
This paper presents a constraint-based approach to supporting the
supports
synthesis of alternative product structures for configuration. The ap-
supports
proach is based upon an expressive and general technique for mod-
supports
eling: the design knowledge which a designer can exploit during a
design project; the life-cycle environment which the final product
wheel assembly 1
pedal assembly 1
faces; the design specification which defines the set of requirements
that the product must satisfy; and the alternatives structures that are
chain 1
developed by the designer.
mechanical interface 1
mechanical interface 2
drives
drives
REFERENCES
Figure 16.
The effect of a context relation on the configuration of design
[1] Mogens Myrup Andreasen. The Theory of Domains. In Proceedings of
entities.
Workshop on Understanding Function and Function-to-Form Evolution,
Cambridge University, 1992.
[2] James Bowen and Dennis Bahler. Frames, quantification, perspectives
sen to embody the function support passenger with the design entity
and negotiation in constraint networks in life-cycle engineering. Artifi-
cial Intelligence in Engineering, 7:199226, 1992.
saddle, the function change direction with the design entity handle-
[3] Amaresh Chakrabarti and Lucienne Blessing. Guest editorial: Repre-
bar assembly and the function provide support with the design entity
senting functionality in design. Artificial Intelligence for Engineering
frame. Due to the bicycle design principle, a context relation called
Design and Manufacture, 10(4):251253, 1996.
supports must exist between the embodiment of the function pro-
[4] Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach, and Markus
vide support and the embodiments of each of the functions facilitate
Stumpter.
Consistency-based diagnosis of configuration knowledge-
bases. In Proceedings of the 14h European Conference on Artificial
movement, provide energy, support passenger and change direction.
Intelligence (ECAI'2000), pages 146150, 2000.
Each of these context relations is embodied by a mechanical inter-
[5] Eugene C. Freuder, Chavalit Likitvivatanavong, and Richard J. Wallace.
face that defines a supports relationship. The details of these mechan-
A case study in explanation and implication. In In CP2000 Workshop on
ical interfaces that define a supports relationship will be specified in
Analysis and Visualization of Constraint Programs and Solvers, 2000.
[6] Eugene C. Freuder and Barry O'Sullivan. Generating tradeoffs for in-
detail during configuration. Since all the functions have been em-
terative constraint-based configuration. In Proceedings of the Seventh
bodied in the scheme presented in Figure 17, it can be regarded as a
International Conference on Principles and Practice of Constraint Pro-
product structure which can be be used as the basis for supporting in-
gramming CP-2001, November 2001.
teractive configuration through which a human user will detail parts
[7] Barry O'Sullivan. Constraint-Aided Conceptual Design. PhD thesis, De-
for the design entities and the interfaces between them. In making
partment of Computer Science, University College Cork, Ireland, July
1999. (Also published by Professional Engineering Publishers, Engi-
these decisions the designer must ensure that the various constraints
neering Research Series, 2001).
that are imposed on her due to the design specification or the design
46
A Student Advisory System: a configuration problem for
constraint programming
Kevin McDonald and Patrick Prosser ˇ
Abstract.
Today, many universities are opting for modular degree
to study, and explaining why certain modules cannot be taken i.e. the
programmes. Such modular courses provide greater flexibility for
advisors help the students design their course. Although all this in-
students, allowing them to learn about subjects previously inacces-
formation is available in the university handbook, it may require an
sible to them. Such a system is naturally complex. Modules may fea-
expert to interpret it.
ture pre and co-requisites and may run over differently periods of
What we have attempted here, is to demonstrate that the task of
times (and have different credit values). General university require-
advising a course of study is essentially a problem of design, and
ments will need to be met by students to continue their studies.
that a constraint based model is most appropriate. We demonstrate
Students themselves may further complex the process by explic-
this by presenting the 4th year curriculum from our department, an
itly wanting to take or avoid modules. They may require a general
encoding of this in the Choco constraint programming toolkit, and
overview to see what options are available to them, such as the dif-
sample queries that a student may ask of such a model.
ferent routes to a particular degree. The University of Glasgow cur-
rently has no automated process to help with this. To find answers
2
A Fourth Year Problem
students may need to visit several different faculties to investigate
possible module selections. Students may have to spend large periods
The 4th year of study is split across two semesters. All students must
of time with their adviser manually working through the university
do an individual final year project (proj) and complete the module on
course catalogue finding what modules are and are not available to
professional issues (pi). Students have then to take 8 other modules,
them. This paper describes our initial efforts in applying constraint
selected from the following options:
programming to this problem.
1. Formal Methods (fm) semester 1
2. Information Retrieval (ir) semester 1
1
Introduction
3. Security & Cryptography (sc) semester 1
4. Advanced Communications (ac) semester 2
Students design their own degrees. A university degree (for example
5. Artificial Intelligence (ai) semester 2
Computer Science) is typically composed of a set of modules, each
6. Algorithmics (al) semester 2
corresponding to a specific subject, such as databases, algorithms and
7. Computer Architecture (ca) semester 1
data structures, communications, etc. Each of these modules is worth
8. Databases & Information Systems (dbis) semester 1
a certain amount of credits. To progress from one year to the next
9. Design & Evaluation of Multimedia Systems (dems) semester 2
a student must accumulate a minimum amount of credits. In a year
10. Issues in Collaborative & Distributed Systems (hci) semester 1
of study there will be a set of modules. Typically, a subset of these
11. Modelling Reactive Systems (mrs) semester 2
will be core modules that must be taken. Additional modules must
12. Neural Computing (nc) semester 2
then be selected to achieve the minimum number of credits. This se-
13. Network Communications Technology (nct) semester 1
lection may then influence subsequent modules that can, and cannot,
14. Requirements Engineering & Re-engineering (rer) semester 2
be taken in later years. For example, a student cannot take a third
15. Safety Critical Systems (scs) semester 1
year course on algorithms if she has not taken a second year course
16. Synthetic Graphics (sg) semester 2
on discrete mathematics i.e. discrete mathematics is a pre-requisite.
Similarly, certain modules must be taken together i.e. they are co-
In the first semester a student must take 4 or 5 modules. The
requisites. Added to this, there is a limit to the number of modules a
semester 1 module Network Communications Technology (nct) is
student can take in any year, and sometimes in any term.
a pre-requisite for the Advanced Communications (ac) module in
Students are then faced with a daunting task. They may decide
semester 2.
that they want a certain degree, say Software Engineering, yet there
We represent the above curriculum as a constraint satisfaction
are certain modules that they do and do not want to take, and some
problem [4] using the Choco toolkit [1]. This is shown in Figure 1.
terms that they want to minimise the number of modules that they
The Choco function, level4(), delivers an object representing a con-
take (maybe so that they can complete a year's project). What mod-
straint satisfaction problem composed of integer variables and con-
ules should they take, and what are the consequences? Much time
straints. Each module is a 0/1 variable, with a value of 1 if taken,
can be spent by advisors of study assisting students in deciding what
0 otherwise. The two compulsory modules, Professional Issues (pi)
˘
and Individual Project (proj), are represented for completeness so
This work was supported by EPSRC research grant GR/M90641.
Ł
Computing Science, Glasgow University,17 Lilybank Gardens, Glasgow
that a student is aware that they must be taken (i.e. assigned a value
G12 8RZ, Scotland, email: pat@dcs.gla.ac.uk
of 1). The constraint on line B represents the pre-requisite: Network
47
[level4() : Problem
nology is a pre-requisite for Advanced Communication (ac) the vari-
¤
-> let pb
:= makeProblem("Level 4",20),
able ac is set to 0 via propagation. Consequently, student X now has
proj := makeIntVar(pb,"proj",0,1),
pi
:= makeIntVar(pb,"pi",0,1),
a reduced set of options in the second semester.
fm
:= makeIntVar(pb,"fm",0,1),
The above steps can be performed quite easily within the Choco
dbis := makeIntVar(pb,"dbis",0,1),
interpreter with just a handful of functions, for selecting and setting
hci
:= makeIntVar(pb,"hci",0,1),
variables. That is, as a proof of concept we need not develop a user
scs
:= makeIntVar(pb,"scs",0,1),
ca
:= makeIntVar(pb,"ca",0,1),
interface, but merely interact via the interpreter. This might not be
ir
:= makeIntVar(pb,"ir",0,1),
unreasonable considering that this model would only be used by 4th
nct
:= makeIntVar(pb,"nct",0,1),
year Computer Scientists. However, if and when we move to a more
sc
:= makeIntVar(pb,"sc",0,1),
complex environment with more naive users, we expect that a good
al
:= makeIntVar(pb,"al",0,1),
rer
:= makeIntVar(pb,"rer",0,1),
user interface will be essential.
mrs
:= makeIntVar(pb,"mrs",0,1),
We could have encoded the above problem differently. In par-
ai
:= makeIntVar(pb,"ai",0,1),
ticular, we could have had a constraint stating that 4 or 5 modules
nc
:= makeIntVar(pb,"nc",0,1),
sg
:= makeIntVar(pb,"sg",0,1),
must be taken in the first semester i.e. sumVars(sem1) == 4 OR sum-
dems := makeIntVar(pb,"dems",0,1),
Vars(sem1) == 5, and similarly that 3 or 4 modules must be taken in
ac
:= makeIntVar(pb,"ac",0,1),
the second semester i.e. sumVars(sem2) == 3 OR sumVars(sem2) ==
must := list(proj,pi),
4. However, this would not have allowed student X to make the de-
sum1 := makeIntVar(pb,"sum1",list(4,5)),
sum2 := makeIntVar(pb,"sum2",list(3,4)),
cision that he will take 4 modules in semester 1. By doing away with
sem1 := list(fm,dbis,hci,scs,ca,ir,nct,sc),
the variable sum1, we no longer allow the student to make the strate-
sem2 := list(al,rer,mrs,ai,nc,sg,dems,ac)
gic decision to spread his study load evenly over the two semesters.
in (post(pb, sumVars(must) == 2),
// A
post(pb, implies((ac == 1),(nct == 1))), // B
Clearly, our choice of model influences the kinds of decisions that a
post(pb,sumVars(sem1) == sum1),
// C
user can make.
post(pb,sumVars(sem2) == sum2),
// D
post(pb,sum1 + sum2 == 8),
// E
pb)]
4
Giving Explanations
In [2] Junker presents a simple and elegant method for delivering
Figure 1.
level4(), a constraint programming encoding of the curriculum
explanations for conflicts. Assume we have a sequence of decisions
#"
#"
design problem for
year Computer Science at Glasgow University
˘
Ł !!
, where
is our last decision before we detect
Ą§¦©¨
#"
a conflict. Therefore we know that
must be one of the culprits.
But what other decisions might be involved? Junker proposes that
Communications Technology (nct) is a pre-requisite for Advanced
#"
we retract all our decisions and then enforce
. If this results in a
Communications (ac). The constraint on line C guarantees that either
#"
contradiction we have an explanation, i.e.
on its own. If this is not
4 or 5 modules are taken in the first semester, and the constraint on
%$#"
the case we then attempt to make the sequence of decisions
, up
line D guarantees that either 3 or 4 modules are taken from the sec-
#&
to conflict. Assume that on making decisions
˘
!
we again have
ond semester. The final constraint E ensures that 8 modules are taken
#"
&
a conflict. We can then be sure that decisions
and
together are
in total. Some of these constraints might initially appear superflu-
a subset of the culprit decisions. We then repeat this process, making
ous, but as we will soon see, they are there to allow more interesting
"
"
#&
'$)(§
#&10
decisions
and
, and then the sequence of decisions
,
queries by the user.
again up to conflict, always adding the last decision that fails to the
set of culprits. This set of culprits is then a sound and minimal expla-
3
Making Choices: an example
nation3.
Junker's technique can be easily extended to cover the situation
The above problem is not solved in the conventional sense; instead
where we want to determine why propagation sets a specific variable
a user interact with it. The interaction involves enforcing a decision
to a specific value i.e. why student X must take a given module or
and then seeing the consequences of this, asking for an explanation
cannot take a given module. We modify the above procedure such
as to why certain choices are forced upon the user, or why certain
that rather than stopping when a contradiction is detected, we stop
choices are not available. We now present a typical sequence of de-
when a specified variable is set to a specified value. In fact, we can
cisions and queries.
generalise even further, producing an explanation for the removal of
Assume we have created the problem (i.e. p:Problem := level4()),
a value, a set of values, the setting of a variable, etc.
and that we have (male) student X. X wants to get started on his
We use this procedure to deliver explanations. We record all de-
project and reckons that he might do well to lighten his load in the
cisions made by the user in a history list
. When a user asks for
2
first semester. In Choco, we create a new world (i.e. world+()), set
an explanation, we return to our initial problem via the Choco func-
sum1 to 4 (i.e. setVal(sum1,4)), and propagate this through the prob-
tion call world=(0). This returns us to the first world, where no deci-
lem (i.e. propagate(p)). This will set sum2 to 4, forcing the student
sions have been made. We then use the above procedure on the list
to take 4 modules in the second semester. Note that in creating a new
building up the list of culprits.
2
world, we can manually retract the most recent decision by back-
tracking via the function call world-(), and in the extreme we can
5
Future Work and Conclusion
return to our initial problem state via the call world=(0).
Student X does not want to take the first semester module Network
Within this department, there have been an number of failed attempts
Communication Technology (nct). Again, we create a new world,
at producing a system that can be used to advise students on a course
now moving to world 2. We set variable nct to 0 (i.e. setVal(nct,0))
3
and propagate this decision. Since Network Communication Tech-
However, there may be many other explanations.
48
of study. These failed systems tend to be dominated by attempts to
capture the student handbook in a data base and allow access to it via
a user interface. Essentially, such systems fail because they do not
capture the dynamic effects of decision making. In this project4 our
goal has been to produce a convincing demonstration of constraint
programming as a solution to this problem. Our goal was not to pro-
duce a fully fledged system, but rather to produce a proof of concept.
We believe that we have done that.
Clearly, the above test case (4th year Computer Science) is very
small. Attempting to extend this to cover a faculty, let alone an entire
university, is a huge task (for example, see van der Linden's PhD the-
sis [5]). However, we should expect that some day it will become a
necessity, especially so as universities become more involved in dis-
tance learning. One current example is lifelong learning in the Open
University. It is our intention to tackle a larger problem and develop a
user interface. We should then be in a position to field the system and
evaluate it. In addition, we might also consider higer levels of consis-
tency. At present, only arc-consistency is established when making a
decision. It might be interesting to investigate problems where higher
levels of consistency are required, i.e. problems where illegal deci-
sions are less obvious.
So far, we have not needed to use techniques from dynamic con-
straint satisfaction [3]. However, as the model becomes larger and
richer we expect this will be a necessity. We are pleasantly surprised
at the simplicity and effectiveness of Junker's explanation technique;
this fits well with the above problem.
ACKNOWLEDGEMENTS
We would like to thank the Computing Science department of Glas-
gow University for supporting this final year student project, and in
particular Alison Mitchell for patiently explaining the problem to us.
We would also like to thank the OCRE project team for their help
with Choco.
REFERENCES
[1] CHOCO.
http://www.choco-constraints.net/ home of the choco con-
straint programming system.
[2] Ulrich Junker, `Quickxplain: Conflict detection for arbitrary constraint
propagation algorithms', in IJCA'01 workshop on Modelling and Solving
Problems with Constraints, pp. 8188, (2001).
[3] S. Mittal and B. Falkenhainer, `Dynamic constraint satisfaction prob-
lems', in Proceedings of AAAI-90, pp. 2532, (1990).
[4] Edward Tsang, Foundations of Constraint Satisfaction, Academic Press,
1993.
[5] Janet van der Linden. An approach to dealing with non-standard con-
straint satisfaction problems. PhD Thesis, Oxford Brookes, 2000.
4
... a final year project carried out by the first author and supervised by the
second.
49
Problem Decomposition in Configuration
Diego Magro, Pietro Torasso and Luca Anselma
Abstract.
language). Partonomic relations provide the basic knowledge for de-
In the present work the issue of decomposing a configuration prob-
composing the configuration problem. In fact, two subparts involved
lem is approached in a framework where the domain knowledge is
into two partonomic relations can not be independently configured if
represented in a structured way by using a KL-One like language
there is at least a constraint that links them together. For this reason
and whole-part relations play a major role in defining the structure
we have introduced a notion of boundness among constraints (sec-
of the configurable objects. The representation formalism provides
tion 3) which assures that two components not involved in a same set
also a constraint language for expressing complex relations among
of bound constraints can be independently configured.
components and subcomponents.
Section 4 provides a high-level description of the configuration
The paper presents a notion of boundness among constraints
algorithm and of the decomposition strategy, while an example of an
which assures that two components not involved in a same set of
application of the algorithm is shown in section 5. Section 6 reports a
bound constraints can be independently configured. The computa-
preliminary experiment showing encouraging results as concerns the
tion of boundness among constraints is the basis for partitioning con-
computational effort. A discussion is reported in section 7.
straints associated with each component to be configured. Such a par-
titioning induces a decomposition of the configuration problem into
independent subproblems.
2 The Conceptual Language
Both a recursive and a non recursive decomposition strategies are
presented and the savings in computational time and reduction in
In the present paper the language
[5] is adopted to build the
¤¦Ą¨§
search space are shown in the domain of PC configuration.
conceptual model of the configuration domains. In
(Frames,
¤¦Ą¨§
Parts and Constraints), there is a basic distinction between atomic
and complex components. Atomic components are described by
1 Introduction
means of set of features characterizing the component itself, while
complex components can be viewed as structured entities whose char-
In recent years configuration has attracted a significant amount of
acterization is given in term of subparts which can be complex com-
attention not only from the application point of view but also from
ponents in their turn or atomic ones.
offers the possibility of
the methodological one [11]. In particular, logical approaches such
¤¦Ą¨§
organizing classes of (both atomic and complex) components in tax-
as [12, 4] and approaches based on CSP have emerged [8, 2, 10, 13].
onomies as well as the facility of building partonomies that (recur-
In CSP approaches, configuration can exploit powerful constraint
sively) express the whole-part relations between each complex com-
problem solvers for solving complex problems. From the other hand,
ponent and any one of its subcomponents. Configuration of an atomic
logical approaches make use of a more explicit and structured rep-
component involves the selection of appropriate values for each fea-
resentation of the entities to be configured (e.g. [7]). Logical ap-
ture characterizing the component, while the configuration of a com-
proaches seem to offer significant benefits when interaction with the
plex component involves a proper assembly of its subparts by using
user (e.g. [6]) and explainability of the result (or failure) are major
both atomic and complex components. The configuration process has
requirements.
to take into account the constraints restricting the set of valid com-
Configuration, as many other tasks, can be computationally ex-
binations of components and subcomponents. These constraints can
pensive; therefore, the idea of problem decomposition looks attrac-
be either specific to the modeled domain or derived from the user's
tive since, from the early days of AI, problem decomposition has
requirements.
emerged as one of the most powerful mechanisms for controlling
Frames and Parts. Each frame represents a class of components (ei-
complexity. Ideally, the solution of a complex problem should be
ther atomic or complex) and it has a set of member slots associated
easily assembled by combining the solutions of the subproblems the
with it. Each slot represents a property of the components belonging
initial problem has been decomposed into. Unfortunately, in many
to the class and it can be of type either partonomic or (alternatively)
cases it is not obvious at all how to decompose the problem into a set
descriptive. Any slot of a class
is described via a value restric-
of non-interacting subproblems.
©
tion
(that can be another class or a set of values of a predefined
In the present work the issue of decomposing a configuration prob-
kind) and a number restriction (i.e. an integer interval [ , ] with
lem is approached in a framework where knowledge about the enti-
), as usual in the KL-One like representation formalisms.
ties is represented in a structured way by using a KL-One like lan-
A slot of a class
with value restriction
and number restriction
guage augmented with a constraint language for expressing complex
©
[ , ] captures the fact that the property for any component of type
inter-role relations (see section 2 for a summary of the representation
©
is expressed by a (multi)set of values of type
whose cardinality
belongs to the interval [ , ].
ˇ
Dipartimento di Informatica, Universit`a di Torino. Corso Svizzera 185;
10149 Torino; Italy.
Partonomic slots are used for capturing the whole-part relation
e-mail: magro,torasso @di.unito.it
between a complex component and a part of its. In
this relation
˘
Ł
¤¦Ą¨§
50
is assumed to be asymmetric and transitive.Formally, any partonomic
always hold, while if
, then, for each
, can never
Q$d8@
#F%g
slot
of a class
is interpreted as a relation from
to its value
hold.
restriction
such that
, being [ , ]
In the following we present only a simplified version of some pred-
"!$#&%')(0 214365
7 8#9(@573BAC(D(
1
A
its number restriction; the meaning is straightforward: any complex
icates available in
. For a more complete description of them
¦¨
component of type
has from a minimum of
up to a maximum
see [5].
1
of parts of type
via a whole-part relation named .
Let
, where each
is a slot
pdQdqhPsT@V@W@W@W@V@Pdt¨u
PdvbQ6S
Cv"e9V@W@W@W"Cv"f$Y
A
In the following we restrict our attention to partonomic slots since
chain starting in a class of
complex components. For any
,
#f%
they represent the basic knowledge for problem decomposition.
denotes the values of the relation
computed for .
p) 8#9(
p
#
Figure 1 contains a toy conceptual model that we use here as an
1)
.
satisfies the predicate iff
, where
2p¨(0 8g7h0i$(
#¨%j
gj35
p) 8#9(@5h3'i
example. Each rectangle represents a class of complex components,
, are non negative integers with
.
g
i
gj3'i
each oval represents a class of atomic components and any thin solid
2)
.
satisfies the predicate iff
, where is a
2p¨(0 2y8ACkd(
#)%j
p) 8#9(mlk
k
arrow corresponds to a partonomic slot. In the figure, it is stated,
union of classes in the conceptual model.
for instance, that
is a class of complex components and the parto-
3)
.
satisfies the predicate iff
2p¨(0 2y8ACks 8g7hDi$(D(
#¨%g
g&35
p) 8#9(hn)k$5h3
nomic slot
specifies that each instance of
has to contain one
, where , are non negative integers with
and is a union
i
g
i
gg3'i
k
7E
or two (complex) components of type
; while the partonomic slot
of classes in the conceptual model.
FE
states that any instance of
has to contain one or two (atomic)
For example, the constraint
states that if only one component
#@odp
$G
components of type
.
playing the partonomic role
is present in a configuration of an
$G
H)I
In any conceptual model, a slot chain
, start-
object of type , then this component must be of type
. The
H)IdE
PRQS
UT9V@W@W@W@V"CX$Y
ing in a class
and ending in a class
is interpreted as the re-
constraint
states that there must be from 1 up to 4 subcomponents
#@ohq
lation composition
from
to
. The chain
of type
in each instance of
(through the partonomic slots
HFEhE
7E
`X&abCXdc7TeafW@W@W$ab7T
represents the subcomponents of a complex component
via
and
).
idE
#g%R
the whole-part relations named
. In figure 1, for example,
UT@V@W@W@W9V"CX
denotes the subcomponents (of type
) of each instance
S
7EhV0idE9Y
HFE
3 Bound and Unbound Constraints
of
through the partonomic slots
and
. Similarly, a set of slot
7E
idE
chains
(where each
starts in
and ends in
Given this framework, configuring a complex object of type means
p6QrqhPsT9V@W@W@W@V0Pdt¨u
Pdv
) is interpreted as the relation union
t
from
to t
.
to completely determine an instance of
in which all the parto-
fv
w
Pdv
w
fv
#
v
x7T
v
x7T
Besides the partonomies, also the taxonomies are useful in the
nomic slots of
are instantiated and each direct component of
#
conceptual models. In figure 1 the subclass links are represented by
is completely configured too. has to respect both the conceptual
#
thick solid arrows. In that toy domain we assume that each class of
model (number and value restrictions imposed by the taxonomy and
atomic components
is partitioned into two subclasses
and
the partonomy as well as the constraints associated with the classes
H)y
H)y2E
. Only the partitioning of
into
and
is reported in
of components involved in ) and the user's requirements.
H)y8
HFE
HFEhE
HFE9
#
figure.
Configuring a complex component by taking into consideration
Constraints. A set (possibly empty) of constraints is associated to
only its taxo-partonomical description would be a straightforward
each class of complex components. These constraints allow one to
activity. In fact, for any well formed model expressed in
in
¦¨
express those restrictions on the components and the subcomponents
which no constraints are associated with any class, a configuration
of the complex objects that can't be expressed by using only the
respecting that model would always exist. A simple algorithm could
frame portion of
, in particular the inter-slot constraints that
find it without any search and by simply starting from the class of the
¦¨
cannot be modeled via the number restrictions or the value restric-
target object, considering each slot of that class and, for it, choosing
tions.
its cardinality, i.e. choosing the number of components playing the
Each constraint
associated to
is of the form
, where
partonomic role to introduce into the configuration, and the type
#@#
is a conjunction of predicates or the boolean constant true and
for each such component. This process must be recursively repeated
is a predicate or the boolean constant false. The meaning is that for
for each complex component introduced in the configuration, until
every complex component
, if satisfies then it must satisfy
all the atomic ones are reached. In this process the algorithm needs
#¨%g
#
. It should be clear that if
, then, for each
, must
only to respect the number and the value restrictions of the slots,
Q29s
#F%
since the choices made for one partonomic slot do not interfere with
q1(1;2)
A1
the choices for another partonomic slot.
C1
q2(1;2)
Unfortunately, this is not realistic. The conceptual model usually
A2
p1(1;2)
q6(1;2)
A11
A12
contains complex constraints that link together different slots. In this
A6
C
p2(1;2)
more realistic situation a solution can not be found generally without
C2
q3(1;2)
A3
p3(1;2)
q4(1;1)
q5(1;2)
any search and by making only a set of local choices.
A4
Moreover, the requirements usually imposed by the user to the tar-
A7
A5
get artifact further restrict the set of legal configurations. This means
CONSTRAINTS
that the search for a configuration is not guaranteed to be fruitful
Associated with C:
[co1]({<p1,q1>})(1;1) ==> ({<p2,q5>})(1;1)
any more. In fact, even assuming the consistency of the conceptual
[co2]({<p1,q2>})(1;1) ==> ({<p2,q3>})(1;1)
[co3]({<p2,q3>})(1;1) ==> ({<p2,q4>})(2;2)
model, the user's requirements could be inconsistent w.r.t. it and in
[co4]true ==> ({<p1,q1>})(in A11 (1;4))
such a case no configuration following the model and satisfying the
[co5]({<p3>})(1;1) ==> ({<p3>})(in A71)
Associated with C1:
requirements exists.
[co6]({<q1>})(1;1) ==> ({<q6>})(in A61)
Therefore, in general, the task of solving a configuration prob-
Figure 1. A toy conceptual model
lem can be rather expensive from a computational point of view. As
we have mentioned above, in
framework this is mainly due
¦¨
to the constraints (both those that are part of the conceptual model
51
and those imposed as user's requirements) that link together different
object (recursive decomposition). 2
components and subcomponents. In these situations a choice made
for a component during the configuration process might restrict the
choices actually available for another one, possibly preventing the
4 Problem Decomposition
latter to be fully configured. In such cases the configurator needs to
At any stage the current configuration is represented as a tree. The
y
revise some decision that it previously took and to explore a different
root
represents the target object and each node represents a com-
yev
path in the search space. Usually, in real cases the search space is
ponent (either complex or atomic). Each child of a node represents
rather huge and many paths in it do not lead to any solution.
a direct component of it. Given a node of , with r@"s9 C| we
y
{
However, in many cases it does not happen that every constraint
indicate the most specific class (w.r.t. the taxonomy) to which be-
interacts with each other and the capability of recognizing the sets
longs. The configuration tree
contains also pieces of information
y
of (potentially) interacting constraints can constitute the basis for de-
useful for the control strategy. In particular: the current component
composing a problem into independent subproblems.
r
r@d
|
(i.e. the one that is being considered currently); the cur-
7{8y
In principle, once a problem has been decomposed into a set of in-
rent queue r
|
containing the direct complex components
}sh}sd{8y
dependent subproblems, these could be solved concurrently and with
of r r@d
|
that still need to be expanded; the information rele-
7{8y
a certain degree of parallelism, potentially reducing the overall com-
vant to the constraints holding for r r@d
|
, that is the classes of
7{8y
putational time. However, also a sequential configuration process can
constraints r@"s9
dC9
|
that still need to be considered and
u
{8y
take advantage of the decomposition. In fact, at least for large config-
the class of constraints r r@"s9
dC9
|
that is being considered
u
{8y
uration problems, solving a set of smaller subproblems is expected to
currently.
be easier than solving the original one. Moreover, if two subproblems
Each call to r@dCC
|
corresponds to the request
}$@d{8C~Dyb~@u)
are recognized to be independent, the configurator is aware that no
of extending the configuration
by configuring the component
y
choice made during the configuration process of the first one needs
r
r@d
|
given the constraints in r r@"s9
dC9
|
.
is
7{8y
u
{8y
u)
to be revised if it enters a failure path while solving the second one.
the conceptual model (i.e. the
knowledge base) and defines
¦ ¨ˇ
To be effective, the task of recognizing the decomposability of a
the decomposition policy. r@dCC
returns the pair
CŁ
,
}$@
˘2ze
~0vm$
problem (and of actually decomposing it) should not take too much
where
can be either the extended configuration tree or the
ze
time w.r.t. the time requested by the whole resolution process.
$s"
message and
is a stack containing the open choices
}$@
vm$
In our approach, the partonomic knowledge can be straightfor-
for the configuration of r r@d
|
. At the beginning, r@dCC
is
7{8y
}$@
wardly used in recognizing the interaction among constraints (with
invoked (by a main) with
containing only the root
and with
y
yev
an acceptable precision) and in defining a way of decomposing a
r
r@d
|
(r@"s9
dC9
|
and r r@"s9
dC9
|
7{8y
Byev
u
{8y
u
{8y
configuration problem into independent subproblems.
are properly initialized as well).
With this aim, we introduce the bound relation among constraints,
which is based on the exclusivenessassumption on parts, stating that,
PROCEDURE configure(k,T,CM){
in any configuration, a component can not be a direct part of two dif-
Open := <>;
WHILE(TRUE){//WHILE-1
ferent (complex) components, neither a direct part of a same compo-
<Expanded_T, L_Open> :=
nent through two different whole-part relations.
insertDirectComponents(T,CM);
Intuitively, two constraints are bound iff the choices made during
Open := append(Open,L_Open);
the configuration process in order to satisfy one of them can interact
IF(Expanded_T == failure){//IF-1
with those actually available for the satisfaction of the second one. If
IF(Open == <>){RETURN <failure, <> >;
r
is a complex component in a configuration, the bound relation
}ELSE{T := pop(Open);}
smt
is defined in the set
r9|
of the constraints that r must
u)v)wjx7yez¨xm{
}ELSE{/*Expanded_T =/= failure*/
satisfy, as follows: let
r9|
. If and contain
T := Expanded_T;
}C~0s~0ju)v)wjx7yez¨xm{
}
both a same partonomic slot of r@"s9 r9| then
(i.e. if and
c := c_comp(T);
{
}$smt0
}
refer to a same part of r , they are directly bound in r ); if
and
}$smt@
then
(i.e. and
are bound by transitivity in
WHILE(c_queue(T) =/= <>){//WHILE-2
r
).
dst@
}$st@
}
c_comp(T) := extract(c_queue(T));
It is easy to see that
is an equivalence relation. If
is an equiv-
IF(k == 1){
st
alence class in the quotient set
r9|D
, every constraint
classesConstrs(T) := NoDecompose(T,CM);
u)v)wjx7yez¨xm{
st
in
could interact with any other constraint in the same class during
}ELSE{classesConstrs(T) := decompose(T,CM);}
the configuration process of
WHILE(classesConstrs(T) =/= <>)
r
. While, if
r9|D
u)v)wjx7yez¨xm{
smt
{//WHILE-3
is different from , it means that in r the constraints in
do not
c_classConstrs(T) :=
interact in any way with those in , since the exclusiveness assump-
extract(classesConstrs(T));
tion on parts assures that the components and subcomponents of
<Extended_T, L_Open> := configure(k,T,CM);
r
IF(Extended_T == failure){//IF-2
involved in the constraints in
are different from those referred to
- delete from Open all the elements
by the constraints in . This means that the problem of configuring
labelled with the indentifier of
c_comp(T);
r
by taking into consideration
r9|
can be split into the
u)v)wjx7yez¨xm{
set of independent subproblems of configuring
IF(Open == <>){//IF-3
r
by considering the
RETURN <failure, <> >;
set
of constraints, for each
r9|D
.
}ELSE{
g
ju)v)wjx7yez¨xm{
st
In the next section, we sketch a configuration algorithm that be-
- Try to complete the configuration
haves differently on the basis of the value of the parameter in the
by properly revising the past
choices on the basis of Open;
procedure r@dCC
. If
no decomposition is performed,
- RETURN the result;
}$@
d
while if
the algorithm tries to recursively decompose the prob-
¦R
¤
lem of configuring each complex component, starting with the target
In the first case a much simpler algorithm could be written. Due to space
constraints, we describe the two different approaches within a single algo-
rithm.
52
}//IF-3
lems have been entailed by the partitioning of the constraints
}ELSE{/*Extended_T =/= failure*/
into a set of classes. Since any two
IF(L_Open =/= <>){
¸)·)şjŃ7±eҨŃm°8Ą
Ą@¦d®)Ż7°8±e˛D˛
- label L_Open with the
constraints of two different classes are unbound, the configuration
c_comp(T) identifier;
choices made while taking into consideration one of them are inde-
push(L_Open,Open);}
pendent from those relevant to the second one. Of course, whenever
T := Extended_T;}//IF-2
contains a single class, no decomposition is
}//WHILE-3
Ą@ł"´sµ9µ@hµ9¸¨¦d§Cµ9ą2¬9µh°8±e˛
c_comp(T) := c;
performed. If the called
procedure succeeds in config-
Ą@¦d§C¨C©
Şs«$¬@
}//WHILE-2
uring the component
w.r.t.
(ELSE
Ą
Ą@¦d®)Ż7°8±e˛
Ą
Ą@ł"´sµ9µ9¸¨¦d§Cµ9ą2¬9µh°8±e˛
RETURN <T, Open>;
branch of IF-2), the calling one (whose task is to configure the parent
}//IF-1
}//WHILE-1
component of
) stores the returned stack
of
Ą
Ą@¦d®)Ż7°8±e˛
Ä
·mŻ$h§
}//configure
(local) open choices for
by pushing it in its
stack.
Ą
Ą@¦d®)Ż7°8±e˛
·mŻ$h§
Thus, the elements stored in
can either be configuration trees
·mŻ$h§
The first step performed by
is the introduction of the
or stacks in their turn. In the first case they (explicitly) represent the
Ą@¦d§C¨C©
Şs«$¬@
direct components of the current component
. This is
open choices relevant to the insertion of the direct components. In
Ą
Ą@¦d®)Ż7°8±e˛
done by considering each (not yet considered) slot
of the class
the second one, they (implicitly) represent the open choices relevant
Ż
and by choosing both the number of the compo-
to the configuration of the complex direct components. Each stack
Ą@ł"´sµ9µh°8Ą
Ą@¦d®)Ż7°8±e˛D˛
nents playing the partonomic role to be inserted in the configuration
pushed in
is labeled with the identifier of the complex direct
·mŻ$h§
Ż
and the type for each of them. 3 Any time a direct complex component
component to which it refers. In this way, if the configuration of
of
is introduced, it is inserted in
.
any direct component w.r.t. a given class of constraints fails (THEN
Ą
Ą@¦d®)Ż7°8±e˛
Ą
¶h«sh«sd°8Ą
Ą@¦d®)Ż7°8±e˛D˛
All the open choices are stored in
. 4 It can happen that in this
branch of IF-2), all the open choices relevant to the configuration
·mŻ$h§
phase there is no way to insert the direct components of
of the same component w.r.t. each previously considered class
Ą
Ą@¦d®)Ż7°8±e˛
into the configuration without violating any constraint. In this case, if
of constraints can be removed easily. Therefore, some useless
no alternative is available in
the
message is returned,
backtrackings are avoided.
·mŻ$h§
¨$´s©"ł8«$¬@
otherwise an alternative is considered.
If a failure occurs while configuring a direct component and ·mŻ$h§
The WHILE-2 loop considers each complex direct component of
contains some alternatives (ELSE branch of IF-3), a revision of the
that has not been expanded (i.e. configured) yet. Such a
configuration takes place. If the top of the stack
contains a
·mŻ$h§
Ą
Ą@¦d®)Ż7°8±e˛
component becomes the new current component in . The way in
configuration tree, this is analogous to the the case of failure while
±
which the set
is computed for this new current
introducing the direct components. If the top of
is a stack in its
·mŻ$h§
Ą@ł"´sµ9µ@hµ9¸¨¦d§Cµ9ą2¬9µh°8±e˛
component defines the behaviour of the configuration process w.r.t.
turn, the nesting of stacks is used it order to maintain the correspon-
the decomposition.
dence between the recursive calls of
and the partonomic
Ą@¦d§C¨C©
Şs«$¬@
If it is computed by the
function (i.e.
structure of the configuration. We do not enter into the details of such
ş&¦d»f9Ą@¦d®)Ż$¦dµ@d°8±bĽ2¸)˝R˛
ľ¦żŔ
), all the constraints relevant to the current component are con-
a revision because of space limits.
sidered in a unique chunk and no decomposition is performed, since
Before presenting a simple example, we outline that a third decom-
żÁhÂ
; where
position policy can be defined in which only the constraints relevant
ş&¦d»f9Ą@¦d®)Ż$¦dµ@d°8±bĽD¸)˝R˛
¸¨¦d§Cµ9ą2¬9µFĂÄ
¸¨¦d§Cµ9ą2¬9µ9Ĺ
Â
is the set containing all the current constraints of the
to the target object
are partitioned. This can be done by using
±e·
¸¨¦d§Cµ9ą2¬9µ
parent component of
(if any) that mention some slot of
the Ç
function (in the main) before calling
for
9Ą@¦d®)Ż$¦dµ@
Ą@¦d§C¨C©
Şs«$¬@
Ą
Ą@¦d®)Ż7°8±e˛
, and
is the set of constraints asso-
the first time and then by calling it with ľż4Ŕ . In this way, only
Ą@ł"´sµ9µh°8Ą
Ą@¦d®)Ż7°8±e˛D˛
Ä
¸¨¦d§Cµ9ą2¬9µ
ciated with
and those expressing the user's re-
the main problem can be decomposed, but the decomposition does
Ą@ł"´sµ9µh°8Ą
Ą@¦d®)Ż7°8±e˛D˛
quirements for that component. If ľżĆFÇ
ż
not take place in the components and subcomponents of
(non
±e·
9Ą@¦d®)Ż$¦dµ@d°8±bĽD¸)˝R˛
Â
function is invoked.
recursive decomposition).
°
¸¨¦d§Cµ9ą2¬9µmĂ&Ä
¸¨¦d§Cµ9ą2¬9µ9˛DČhÉĘ
Ę2ËDĚÍhÎ
ĎsĐ
By making use of the bound relation
among constraints (see
Ę
É
section 3), Ç
partitions the constraints into classes of
9Ą@¦d®)Ż$¦dµ@
5 An Example
bound constraints and returns these classes (i.e. it returns the quo-
tient set
).
Figure 2 reports five snapshots of a possible configuration process
¸)·)şjŃ7±eҨŃm°8Ą
Ą@¦d®)Ż7°8±e˛D˛DČhÉĘ
Ę2ËDĚÍhÎ
ĎsĐ
One such computed class of constraints is considered at
for configuring an object of type
(fig. 1) 6. In figure 2, each
¸
Ą
©
a time (WHILE-3 loop), i.e. a current class of constraints
identifies the
component of type . The numbers preceding the
©ěë"í
¸
is repeatedly extracted from the set
identifiers express the order in which the components have been in-
Ą
Ą@ł"´sµ9µ9¸¨¦d§Cµ9ą2¬9µh°8±e˛
and the
procedure is invoked
troduced into the configuration. We consider the recursive decompo-
Ą@ł"´sµ9µ@hµ9¸¨¦d§Cµ9ą2¬9µh°8±e˛
Ą@¦d§C¨C©
Şs«$¬@
to configure the current component
w.r.t. the current
sition policy.
Ą
Ą@¦d®)Ż7°8±e˛
class of constraints 5. This means that the problem of configuring the
At the beginning, only the root
Ŕ
is inserted (by the main)
Ą
current component w.r.t. the constraints
into the configuration (as current component). The main invokes the
¸)·)şjŃ7±eҨŃm°8Ą
Ą@¦d®)Ż7°8±e˛D˛
has been split into a set of subproblems, one for each class of
Ç
that partitions the set of constraints for Ŕ into the two
9Ą@¦d®)Ż$¦dµ@
Ą
constraints contained in
. These subprob-
different classes of bound constraints
żRÁ
Ŕ
Ć
and
î7ď
Ą@¦
Ľ2Ą@¦
ĽDĄ@¦hđsĽ2Ą@¦hńdĹ
Ą@ł"´sµ9µ@hµ9¸¨¦d§Cµ9ą2¬9µh°8±e˛
żdÁ
. The main problem is thus decomposed into two inde-
îsň
Ą@¦dóhĹ
Ó
When we speak about choices made while configuring a component we
pendent subproblems (one relevant to
and the other relevant to
î7ď
refer exactly to these two kinds of choices.
).
is invoked (with ľgżdĆ ) to solve the first subprob-
Ô
For simplicity, we can assume that at this point, each time one or more
îsň
Ą@¦d§C¨C©
Şs«$¬@
Ŕ
Ŕ
Ć
Ŕ
alternatives are available and before actually modifying the configuration,
lem. The direct components
and
are inserted and the open
Ą
Ą
Ŕ
Ć
such alternatives are stored in the current configuration tree which is then
choices (i.e. the alternative cardinality Ć for both the slots
and
)
Ż
Ż
pushed into
.
are saved in
.
Ő
Öb×dŘDŮ
·mŻ$h§
Ú
It is worth noting that the procedure
considers at each
ŰDÜ0Ů$ÝdŢ
ßhŕdá9Ř
time only the slots of
appearing in the constraints
ô
For simplicity, we do not distinguish between the constraints present in the
ŰDâ
ăhä0ä@ĺ8Ű
ŰDÜ0ć)×sĺ"çbč2č
.
conceptual model and those representing the user's requirements.
Ű
ŰDâ
ăhä0ä0ébÜ0Ů$äDę8á9ä@ĺ"çbč
53
(4)a11_1
(2)c1_1
(4)a11_1
(2)c1_1
(4)a11_1
(2)c1_1
(4)a11_1
(2)c1_1
(2)c1_1
(4)a11_1
(1)c_1
(1)c_1
q1
(1)c_1
q1
(1)c_1
q1
q1
p1
(1)c_1
q1
p1
p1
p1
(5)a61_1
q6 (5)a61_1
q6 (5)a61_1
q6
q6 (5)a61_1
p1
q2
q2
q2
q2
q6 (5)a61_1
p2
p2
p2
(3)c2_1
(3)c2_1
p2 (3)c2_1
q2
q2
(6)a21_1
(6)a21_1
(6)a21_1
(6)a21_1
p2
q2
(6)a21_1
p3 (3)c2_1
q5
(7)a51_1
q5
(7)a51_1
(3)c2_1
(7)a21_2
a)
b)
c)
q3
(7)a21_2
q5
(8)a51_1
(8)a31_1
d)
e)
q3
q4 q3
(12)a71_1
(9)a31_1
(10)a31_2
(11)a41_1
Figure 2. A configuration example
Then, the configuration of the component
is split into other
ing JDK 1.3 and the experiment has been performed on a Duron
őhö
ö
÷
subproblems, since its constraints (those inherited from
and the
700/Windows 2000 PC with 128 Mbytes RAM. A problem is con-
ő
ö
local one
) are partitioned into the classes
sidered solved iff the configurator provides a solution for it within
ő@řhů
÷
ú$ű¨üRý9ő@řsöhţDő@řh˙sţ2ő@řhůˇ
and
. It is worth noting that in
the constraint
be-
the time threshold of
sec. or if it detects (within the same time-
ú
Ł˘)üý9ő@řd÷¤
ő
ö
ő@řd÷
©
hů¤)
longs to the same class as the constraints
and
, while in the
out) that the problem does not admit any solution.
ő@řsö
ő@řh˙
component
the constraint
belongs to a class different from
Strategies and both solved the same
problems (i.e. their
őhö
ö
ő@řd÷
ö
÷
ö
§'§)
that containing
and
. In fact, the constraint
can interact
competence was of
), while strategy solved all the
cases.
ő@řsö
ő@řh˙
ő@řd÷
0¤1ˇ2
©
ö
§'§©
with the constraints
and
during the configuration process of
As regards the computational effort, for the
problems solved by
ő@řsö
ő@řh˙
ö
§'§)
; but,
does not interact with
or
while configuring the
all the three strategies, the average computation time was (in msec.)
ő
ö
ő@řd÷
ő@řsö
ő@řh˙
component
. It is worth noting that at least in the case under ex-
for strategy ;
for strategy (i.e.
w.r.t. strategy )
őhö
ö
&¤&§©ˇ'
ö
&
9˙hůˇ'
÷
34©Ł5
'¤2
ö
amination, the recursive decomposition policy was able to recognize
and
for strategy (i.e.
w.r.t. strategy ); the average
÷h÷¤'¤&
©
3
eů¤0Ł5
1ˇ2
÷
that a set of constraints that are bound in the larger context of the con-
number of backtrackings was
for strategy ;
for strategy
&¤&§)
ö
&¤'dö
÷
figuration of the target object
can actually be split in the (smaller)
(i.e.
w.r.t. strategy ) and
for strategy
(i.e.
ő
ö
3
¨÷ˇ5
'¤2
ö
'
9ůˇ&
©
3
¨÷9˙Ł5
'¤2
context relevant to the configuration of the component
.
w.r.t. strategy ). The benefits of strategy w.r.t. strategy become
őhö
ö
÷
÷
ö
The solutions of the two subproblems corresponding to
and
more evident if we consider the
solved problems that were actu-
ú$ű
ú
Ł˘
˙
¤0
lead to the situation depicted in fig. 2 a (the thick arrow points to the
ally decomposable with strategy . For these problems, the average
÷
current component: in this case,
). Then (fig. 2 b) the problem of
CPU time was (in msec.)
for strategy and
(i.e.
)
őhö
ö
©
h˙hů¤1
ö
÷
¤&¤'9˙
3
¨÷§)Ł5
ů
ˇ2
configuring
is decomposed into subproblems associated with
for strategy ; the average number of backtrackings was
for strat-
ő9÷
ö
÷
÷
'¤'§0
the two classes
and
. After consider-
egy and
for strategy (i.e.
).
ú
¦Ą¦ü
ý9ő@řsö§
ú
Ł¨¦ü
ý9ő@řd÷dţDő@ř¤©ˇ
ö
'§)sö
÷
3
)ö!)Ł5
˙
ˇ2
ing
, the problem associated with
is taken into consideration
ú
ŁĄ
ú
¦¨
(fig. 2 b). It should be clear that the configuration in fig. 2 c can not
be extended in any way satisfying
. Choosing a different type (i.e.
7 Discussion and Future Work
ő@ř¤©
) for the eighth component would not solve the problem. Since
©
d÷
The present paper addresses the problem of partitioning a config-
this was the only open alternative in the configuration of
w.r.t.
ő9÷
ö
uration problem into simpler subproblems by exploiting as much as
(in fact, due to
, no alternative cardinality could be chosen for
ú
Ł¨
ő@řd÷
possible the implicit decomposition provided by the partonomic rela-
) the resolution of the subproblem associated with
fails. It is
©
ú
¨
tions of complex components. The adoption of a structured approach
worth noting that the alternatives for the subproblem associated with
based on a logical formalism plays a major role since the criterion
are not considered (see the THEN branch of IF-2 in
)
ú
ŁĄ
ő@řˇ
Ł!
for singling out "unbound" constraints is based on an analysis of the
and a revision of the configuration of
takes place (fig. 2 d). In
őhö
ö
partonomic slots mentioned in the constraints. Moreover, the con-
this way,
can be completely configured and thus the subprob-
ő9÷
ö
straints are associated with each complex component. The config-
lem associated with
is successfully solved. The resolution of the
ú
#"
uration algorithm tries to recursively decompose the configuration
problem associated with
adds the
component to the config-
ú
¦$
%Ł&dö
ö
problem each time it is invoked to configure a component or a sub-
uration (fig. 2 e).
component.
The paper presents a centralized version of the configuration strat-
6 Preliminary Results
egy in which the subproblems resulting from a decomposition are
sequentially solved. An alternative configuration strategy based on a
The domain of PC configuration has been used for testing the im-
distributed approach could be conceived: each time a configuration
pact of the decomposition strategies. We have generated a test set of
problem is split into a set of independent subproblems, these could
configuration problems: for each of them we have specified the
be sent to a pool of configurators running in parallel.
ö
§'§©
type of the target object (e.g. a PC for graphical applications) and the
Our main motivation for decomposing configuration problems is
requirements that it must satisfy (e.g. it must have a CD writer of a
saving in computational effort. Preliminary results are encouragingin
certain kind, it must be fast enough and so on).
this respect since benefits are present even with a sequential approach
The goal of the experiment is to compare (w.r.t. the computational
to configuration. The preliminary experiments have also shown that
effort) among them a configuration strategy without decomposition
the results are influenced by the order in which the partonomic slots
(i.e. no constraints partitioning in the main that calls
pro-
are considered. Therefore, it is worth investigating strategies able to
ő@řˇ
Ł!
cedure with
) (Strategy ), the non-recursive strategy that at-
suggest convenient order in instantiating partonomic slots. In the fol-
(
ü6ö
ö
tempts to decompose only the main configuration problem (see sec-
lowing, we will sketch one of such strategies, based on hypergraph
tion 4) (Strategy ) and the recursive one (Strategy ).
cut techniques similar to the one proposed for decomposing the prob-
÷
©
The configuration system has been implemented in Java us-
lem of satisfiability testing on large propositional CNF formulas, pre-
54
<p2>
<p1>
increase the number of connected components (figure 3.b), i.e. it
would increase the number of equivalence classes in the quotient set
GIHIPRQDS4TUQEVXW
`§Yih
co1
co1
. This means that, after having introduced
fp@
A
into the configuration the direct components of W ` through ` and
<p2,q3>
<p2,q3>
v
co3
co4
co3
co4
b
, the subproblem of configuring the target object W ` by consid-
v
<p1,q1>
<p1,q1>
W!aŁ`¤xiW!aˇbˇxW!a¤cŁxiW!a¤dˇ
co2
co2
ering the constraints
(see section 5) can
9#A
co5
be further split into two other subproblems corresponding to the two
co5
W!aŁ`¤xW!a¤dˇ
W!aˇbˇxiW!a¤cˇ
a)
b)
sets of constraints
and
. In fact, these two sub-
problems can be solved independently, since the only choices that
Figure 3. Hypergraphs associated with the constraints for
`
b
6
7
can interact with them are those made for
and
.
v
v
Therefore, as in the case of satisfiability testing of CNF proposi-
tional formulas, hypergraph cut techniques can be used to find an ap-
sented in [9]. 7 In that approach, a hypergraph is associated with a
propriate set of hyperedges (i.e. of slot chains) whose deletion from
CNF formula
such that each variable of
corresponds to a hy-
the hypergraph would increase the number of connected components.
8
8
peredge connecting all the clauses in which it occurs. Then, such a
Such set of slot chains can then be used by the configuration algo-
hypergraph is used to find an appropriate set
of variables allow-
rithm in order to guide the selection of the slots to be considered at
9@
ing two subformulas
and
of
to be individuated such that the
each time and to dynamically split the configuration problems.
8BA
8DC
8
problem of testing the satisfiability of
corresponds to the problem
Besides the reduction in computational effort, there are other good
8
of verifying if there is some compatible truth assignment to the vari-
reasons for investigating decomposition. First of all, in some do-
ables in
that makes
and
satisfiable. For each assignement
mains, the configuration problems are distributed by their nature [1].
9@
8EA
8DC
to the variables in
,
and
simplify into two formulas that can
Moreover, one of the serious problems in configuration is the expla-
9F@
8EA
8DC
be tested independently (see [9] for details).
nation task [3]. The adoption of a structured approach for modeling
Following this framework, we can associate a hypergraph to the set
the domain knowledge and the introduction of a decomposition mod-
ule able to specify which constraints involved in the configuration of
GIHIPRQDS4TUQEVXW§Y
that any complex component W in a configuration
must satisfy. For example, in figure 3.a the hypergraph associated
a given component can interact with each other is a first step for mak-
with the constraints for target object
ing progresses in the explanation of failure in configuration.
W
`
is depicted. In such a hy-
pergraph, each constraint corresponds to a vertex and two constraints
are connected by a same hyperedge iff they are directly bound. In
REFERENCES
figure 3.a, for instance, the constraints W!aŁ` and W!aˇb belong to a same
[1] A. Felfernig, G. Friedrich, D. Jannach, and M. Zanker, `Distributed con-
hyperedge, since they are directly bound, while there is no hyper-
figuring', in Proc. IJCAI-01 Configuration WS, pp. 1824, (2001).
edge containing both W!a¤c and W!a¤d , since they are not directly bound.
[2] G. Fleischanderl, G. E. Friedrich, A. Haselb¨ock, H. Schreiner, and
Moreover, two constraints are bound iff they belong to a same con-
M. Stumptner, `Configuring large systems using generative constraint
nected component in the hypergraph. For example, in figure 3.a, W!a¤c
satisfaction', IEEE Intelligent Systems, (July/August 1998), 5968,
and
(1998).
W!a¤d
are bound (even if not directly), since they belong to a same
[3] E. Freuder, C. Likitvivatanavong, and R. Wallace, `Explanation and im-
connected component. Instead, the constraint W!aˇe belongs to a con-
plication for configuration problems', in Proc. IJCAI-01 Configuration
nected component different from the one containing all the other con-
WS, pp. 3137, (2001).
straints, therefore W!aˇe is not bound to any other constraint. It should
[4] G. Friedrich and M. Stumptner, `Consistency-based configuration', in
be clear that each connected component of the hypergraph associated
AAAI-99, Workshop on Configuration, (1999).
[5] D. Magro and P. Torasso, `Description and configuration of complex
with the constraints GIHIPRQDS4TUQEVXW§Y corresponds to an equivalence
technical products in a virtual store', in Proc. ECAI 2000 Configuration
class w.r.t. the bound relation
. Thus, computing the quotient set
WS, pp. 5055, (2000).
fg@
GIHIPRQDS4TUQEVXW§Yih
means computing the set of connected compo-
[6] D. Magro and P. Torasso, `Supporting product configuration in a virtual
fp@
nents of the hypergraph associated with GIHIPRQDS4TUQEVXW§Y .
store', LNAI, 2175, 176188, (2001).
Differently from the hypergraphs introduced in [9], the hyperedges
[7] D. L. McGuinness and J. R. Wright, `An industrial-strength de-
scription logic-based configurator platform', IEEE Intelligent Systems,
of a hypergraph associated with a set of component constraints in the
(July/August 1998), 6977, (1998).
qsrUt
framework do not represent simple variables. Instead, each hy-
[8] S. Mittal and B. Falkenhainer, `Dynamic constraint satisfaction prob-
peredge represents a structured entity, namely a slot chain providing
lems', in Proc. of the AAAI 90, pp. 2532, (1990).
an explanation of the fact that the constraints belonging to the hyper-
[9] T. Joon Park and A. Van Gelder, `Partitioning methods for satisfiability
testing on large formulas', Information and Computation, (162), 179
edge are directly bound. For example, the hyperedge labelled b¤w in
u
v
184, (2000).
the hypergraph of figure 3.a states that the constraints W!aŁ` , W!aˇb and
[10] D. Sabin and E.C. Freuder, `Configuration as composite constraint sat-
W!a¤c
are directly bound in W ` by means of the slot chain b¤w . More-
isfaction', in Proc. Artificial Intelligence and Manufacturing. Research
u
v
over, the hyperedge labelled
bˇxy§cˇw
states that the constraints W!aˇb
Planning Workshop, pp. 153161, (1996).
u
v
and
[11] D. Sabin and R. Weigel, `Product configuration frameworks - a survey',
W!a¤c
are directly bound in W ` by means of the slot b and that
v
IEEE Intelligent Systems, (July/August 1998), 4249, (1998).
they still remain directly bound (by means of the the slot y§c ) in each
[12] T. Soininen, I. Niemel¨a, J. Tiihonen, and R. Sulonen, `Unified configu-
direct component of W ` playing the partonomic role b .
ration knowledge representation using weight constraint rules', in Proc.
v
Despite this difference, the decomposition methods presented
ECAI 2000 Configuration WS, pp. 7984, (2000).
in [9] suggest the opportunity of investigating a possible improve-
[13] M. Veron and M. Aldanondo, `Yet another approach to ccsp for con-
figuration problem', in Proc. ECAI 2000 Configuration WS, pp. 5962,
ment of our decomposition technique. Let's consider again the hyper-
(2000).
graph in figure 3.a. Removing the hyperedges
`§w
and
b¤w
would
u
v
u
v
The potential similarity between our approach and the one presented in [9]
has been suggested by an anonymous reviewer.
55
A multi-perspective approach for the design of
configuration systems
L. Hvam, J. Riis & M. Malis1
ABSTRACT
solutions as a contrast to product development, which is a
This article presents a procedure for building product
more creative process.
models to support the specification processes dealing with
sales, design of product variants and production
The Development process (Long term)
preparation in manufacturing companies. The procedure
Market
Product
Production
includes, as the first phase, an analysis and redesign of the
development
development
development
business processes that are to be supported by the use of
The Specification process (customized product variants)
product models. The next phase includes an analysis of
Request for
additional
the product assortment and the set up of a so-called
Request for
customer
additional
info.
Sales
customer info.
product master. Finally the product model is designed by
Customer
Customer
Request for
using object-oriented modelling.
order
Order
Product
additional
specification
customization
product info.
Production
Product
requirements
Process
specification
Production
customization
The procedure has been tested in several companies. This
Production
specification
article includes the experiences gained from the most
recent project that was carried out at Demex-electric a
Figure 1. The specification process
Danish company, which manufactures electronic
switchboards. The research has been carried out at the
Typical goals for the specification process are the ability
Centre for Product Modelling, Department of
to find an optimal solution according to the customer's
Manufacturing Engineering at the Technical University of
needs, high quality of the specifications, short lead time
Denmark.
and a high productivity of the work carried out in the
specification process. The typical critical goals for the
1. INTRODUCTION
development process are to derive new original concepts
This article presents a procedure for building product- and
of product designs with improved functionality and life
product-related models that support the specification
cycle properties, and to reduce time to market for the new
process (figure 1).
product designs. The diversification of tasks and goals in
the specification and development processes leads to a
The activities in the "specification process" includes an
separation of the two processes as suggested in figure 1
analysis of the customer's needs, design and specification
above.
of a product which full-fill the customer's needs and
specification of e.g. the products manufacturing,
Today we see numerous examples of projects aiming at
transportation, erection on site and service (specification
implementing product- and product-related models to
of the product's life cycle properties). The activities in the
support the specification processes. Experiences from a
specification process are characterised by having a
considerable number of Danish and international
relatively well-defined space of (maybe complex)
companies show that often these models are constructed
without the use of a strict procedure or modelling
1 Centre for Product Modelling, www.productmodels.org
Department of Manufacturing and Management, Technical
University of Denmark, Building 423, DK-2800 Lyngby,
Denmark.
56
techniques. As a result of this, the systems are
that will be affected by the product- and product-related
unstructured and undocumented, and therefore difficult or
models (phase 1). In phase 2 the products are analysed
impossible to maintain or develop further.
and described in a so-called product master [3]. Phase 3
includes the final design of the product- and product-
Thus there is a need for developing a procedure and the
related models by using the object-oriented modelling
associated modelling techniques, which can ensure a
techniques. Phases 4 to 7 deals with design,
proper structure and documentation, so that the systems
programming, implementation and maintenance of the
can be maintained continually and developed further.
product models. Phases 3 to 7 are based on the general
Experiences also show that the product- and product-
object-oriented project life cycle.
related models are not always designed to fit the business
processes that they are meant to support. Finally an
There may be some overlap and iterations between the
important precondition for building product models is the
individual phases. The procedure is shown in figure 3.
fact that products must be designed and structured in a
way, which makes it possible to define a general master
Phase Description
of the product, from which the customer specific products
can be derived.
1
Process Analysis
Analysis of the existing specification process (AS-IS),
statement of the functional requirements to the process.
Consequently, in order to cope with these challenges a
Design of the future specification process (TO BE). Overall
procedure for building product models should include: An
definition of the product- and product-related models to
analysis and redesign of the specification processes in
support the process. [6],[7].
Tools: IDEF0, flow charts, Activity Chain, Model, key
focus, an analysis and eventually redesign/ restructuring
numbers, problem matrix, SWOT, list of functional
of the products to be modelled, and finally, a structured
describing characteristics and gap analysis.
"language" - or modelling technique - which makes it
2
Product Analysis
possible to document the product- and product-related
Analysing products and eventually life cycle systems.
Redesigning/ restructuring of products. Structuring and
models in a structured way.
formalizing knowledge about the products and related life
cycle systems in a product master.
The procedure suggested here or part of the procedure -
Tools: List of features and product master [3].
has been tested in several companies, e.g. F.L.Smidth,
3
Object-oriented Analysis (OOA)
American Power Conversion (APC), Aalborg industries,
Creation of object classes and structures. Description of
object classes on CRC-cards. Definition of user interface.
NEG-Micon, GEA-Niro and IBM-SMS. The article
Other requirements to the IT solution.
includes the experiences acquired from the latest project
Tools: Use cases, screen layouts, class diagrams and CRC-
at Demex-electric a Danish manufacturer of electronic
cards.
switchboards. The procedure is based on four aspects
4
Object-oriented Design
Defining and further developing the OOA-model for a
(figure 2).
specific programming tool.
5
Programming
Programming the system. Own development or use of
Modelling concepts
Product analysis
standard software.
6
Implementation
Implementation of the product- and product-related models
in the organization. Training users of the system, and
further training of the people responsible for maintaining
Organisational aspects
Developement of
business processes
the product- and product-related models.
7
Maintenance
Figure 2. Four aspects incorporated in the procedure.
Maintenance and further development of the product- and
product-related models.
1. Modelling concepts based on object-oriented
Figure 3. A procedure for building product models, [1].
modelling.
2. Product analysis concerning the transformation
3. CASE STUDY
of product knowledge into structured and visual
The procedure has been used for building and
information.
implementing a sales configurator in the Danish company
3. Organizational aspects how to organize the
Demex-electric. The experiences gained from the process
development of product- and product-related
are described in the following sections.
models and the subsequent use of the models.
4. Development of business processes how to
identify and redesign new business processes
supported by product- and product-related
models.
3. 1 CASE COMPANY: DEMEX-ELECTRIC
2. A PROCEDURE FOR BUILDING PRODUCT
Demex-electric is a Danish manufacturer of electronic
MODELS
switchboards. It has more than 100 employees and a
The procedure contains 7 phases. The starting point of the
work is an analysis and redesign of the business processes
57
turnover of approx. 15 million Euro. An example of a
Opportunities
Treats
switchboard is showed in figure 4.
Sale, quotations and configuration
Many competitors (35)
of switchboards on the Internet
All switchboards are identical seen
Improved quality of specifications
from a customer point of view
Reduction of costs of assembly
Not possible to differentiate
Logistics will be improved
Low net profit ratio within this
Market size DKK 1.5 billion
business sector
Strengths
Weakness
Knowledge and experience of
SC-utilisation
employees
Size in the market
Good image and branding
Broad product range
Figure 5. SWOT-analysis.
In the alliance between Demex-electric and Solar A/S,
Solar A/S hosts the system for configuring an electronic
switchboard as an integrated part of their homepage for
selling electronic equipment. When a customer configures
and orders an electronic switchboard, Solar A/S ships the
parts needed for building a switchboard to Demex. The
switchboards are then assembled and shipped. The future
process focuses on ensuring efficient quotations by using
Figure 4. An example of an assembled unit manufactured
the Internet. The lead-time and the consumption of
at Demex.
resources, from the generation of quotations until the
specifications lie in the production department, are
3. 2 PHASE 1: PROCESS ANALYSIS
considerably reduced. In connection with the analysis of
As the process is now, the customer indicates, among
the existing process at Demex, a number of flow diagrams
other things, the power required, the electricity companies
were made.
that can supply the power, the demands for protection, the
switchboard outlets etc. Then Demex starts specifying the
With the new product model the company gets a much
switchboard and prepares a list of parts, makes a sketch,
more structured process flow where the knowledge of
calculates the price and writes a quotation letter. When
Demex regarding construction of switchboards is made
the customer has accepted the offer, the list of parts and
available to the customers, and complex calculations can
the sketch are detailed, and can now form the basis of
be made very quickly. This is illustrated in figure 6.
purchasing and production.
er
e
Order
om
Quotation
Placing of
Th
Requirements
Switchboard
st
orders
confirmation
The lead-time for generating quotations is 3 to 5 days.
cu
Demex uses 2 to 4 man-hours for each quotation. The
con
www.
Order info
process may lead to frequent errors, and often the time
E
Configuration
mexecon.dk
are entered
mex
necessary for the optimisation of the boards cannot be
found. When the future process requirements at Demex
r
i
c
www.demex-
Customer files
Order
Switchboard
mex
ect
electric.dk
Product files
processing
is constructed
were to be set, a SWOT analysis was also made, as shown
de
el
in figure 5.
r
EDI-
Search for
Components
la
www.solar.dk
requisition
components via
pickup
So
Solarlink
As a consequence of this Demex has made an alliance
with Solar A/S a company selling electronic equipment.
Figure 6. The Future process flow when applying a con-
In Denmark Solar A/S has a turnover of 250 million, 50
figurator.
% of the products are sold directly via Solar's homepage.
The configurator is named mexEcon. The effects of
mexEcon are identified as:
1. Customers can make a quotation in 10 minutes
24 hours a day.
2. Reduction of lead time from 3-4 days to 10
minutes when generating quotes.
3. Possible to optimise a configuration in relation to
e.g. materials used and performance of the
switchboard.
58
4. The time used for the specification of
Switchboard
switchboards is reduced from 2-4 hours to 10
minutes.
15. Intrance section
3. 3 PHASE 2: PRODUCT ANALYSIS
16. Intrance field
In this phase the products to be modeled are analyzed in
order to gain an overview of the product families and their
Length
Width
17. Inlet switch
structure. The analysis covers the function, structure,
Number
Max
properties and variations of the product and the related
17. Inlet switch
interrupter
Fuse
Max
w. ground
Amperage
Switch
switch
interrupter
fault
systems in the product's life cycle. Figure 7 shows a
[63, 125, 160, 250, 400,
630, 1000]
Type-OT
Type -
general architecture for describing products including the
Poles
Type-NS
Type-OT
3 (Norway)
63
Holec
100
RC2121
4 (Denmark)
125
QSA
160
RC2122
above-mentioned views.
160
125
250
RC2123
250
250
400
RC2124
400
400
630
630
630
125A
1000
160A
250A
Property
400A
views
Figure 8. A part of the product master.
Control
Kinematics
Thermodynamics
The left side of the product master (the part of structure)
Man/ Machine
Etc
includes the modules or parts used in the entire product
family. This is due to the aggregation structure in object-
Production
Product
oriented modelling. The left side of the product master
Process
Generic
Sales
product
Functions
Product
Use
life
(kind of structure) includes the parts, which can be
Organs
views
Structure
Maintenance
views
Parts
Disposal
exchanged in the product. This is due to the specialisation
structure in object-oriented modelling.
Variant
s
Commonality
3. 4 PHASE 3 & 4: OBJECT ORIENTED ANALYSIS
AND DESIGN
Product
OOA is a method used for analysing a given problem
assortsment
views
domain and the field of application in which the IT
system will be used. The purpose of the OOA is to
Figure 7. An architecture for describing products
analyse the problem domain and the field of application in
[2], [3].
such a way that relevant knowledge can be modelled in an
IT system. The problem domain is the part of reality
A formal way of describing the product assortment is a
outside the system that needs to be administrated,
so-called product master [3]. A product master consists of
surveyed or controlled. The field of application is the
two main elements: a generic part-of structure and a
organization (person, department) that is going to use the
generic kind-of structure. Experiences from this case
system to administer, survey or control the problem
showed that the product master was a very good tool for
domain.
discussing the product assortment, i.e. where to start
modelling in the configuration system, which variants to
The OOA model can be made through the activities
include, which technologies are stable and which
described in figure 9 which describes the OOA as
technologies will change etc. The product master is
consisting of five phases or layers. These layers can be
described on a big piece of paper around 3 x 1meters.
seen as different viewpoints, which together make up the
Once a week (in several months) a meeting was held in
OOA model. Normally the five activities are carried out
order to discuss the products. All the domain experts were
through a top down approach, but there are no restrictions
present at these meetings. This was mainly to ensure
in that sense. Typically the OOA model will be the result
commitment and agreement. A part of the product master
of a number of iterations of the analysis process.
is illustrated in figure 8.
Subject layer
Class & object
layer
Structure layer
Attribute layer
Method layer
Figure 9. The five layers of OOA modelling [13].
59
The subject layer contains a sub-division of the complete
In order to model the switchboards at Demex an object-
domain, which is to be modelled in different subject
oriented model has been made. The model is based on the
areas. In relation to the use of product models, a subject
product master. It consists of a class diagram and CRC-
area can for example be a product model or a factory
cards. A part of the model is illustrated in Figure 11 and
model.
12.
Switch board surroundings
The class and object layer contains a list of the classes
and objects, which have been identified in the individual
subject areas.
Switch
Switch board
The structure layer contains the relationships between the
objects, i.e. a specification of generalization and
Transport
aggregation.
Fuse switch
Maximum switch
Switchboard encapsulation
The attribute layer contains a specification of the
Entry switch
information associated with the individual objects, i. e
what the objects know about themselves.
Cubic-encapsulation
Tabula-encapsulation
The method layer contains a description of the individual
Figure 11. Class diagram.
objects methods (procedures), i. e. what the objects can
perform.
Number: 18
Name: Entry switch
Date: 22.12.2000
Version: 2
The static structure is mirrored in the layers of theme,
classes and objects, structure and attributes, while the
Responsible person: JS
more dynamic aspects in the model mainly are related to
Responsibilities:
the method layer. The result of the OOA can be illustrated
Specification of height and width of the encapsulation, BOM no., loss
in a class diagram and on CRC-cards (Class-,
of heat, power and time for assembly.
Responsibility and Collaboration Cards) [4], [11], [12].
The notation used in the class diagram is illustrated in
figure 10, which shows a class and four different
Attributes:
structures. The notation is part of the Unified Modelling
Encapsulation [Tabula, Cubic]
Dim [3x1, 2x1, 3x2]
Language (UML), which has been chosen since it is the
BOM no. [OT*]
preferred standard worldwide and is used in many
Price [DKr.]
development tools [14].
Time for assembly [min.]
Sketch:
Class
-attribute1
-attribute2
+method1()
+method2()
Class with attributes
and method
Superclass
Class1
Class1
-attribute1
-attribute1
-attribute1
+method1()
+method1()
+method1()
Methods:
*
*
Name
Space
BOM no.
Price
Time for assembly
1
1
Subclass1
Subclass2
(b x
[Kr]
[min]
h)
-attribute1
-attribute1
Class2
Class2
-attribute2
-attribute3
OT 63
3 x 1
OT63T1
98,38
35
+method1()
+method1()
-attribute2
-attribute1
OT 63
2 x 1
OT64T1
132,86
35
+method2()
+method3()
+method2()
+method2()
OT 100
3 x 1
OT65T1
194,88
35
Generalization
Aggregation
OT 100
2 x 1
OT66T1
229,36
35
Association
QA 125
3 x 2
OT67T1
541,03
45
Figure 10. Notation for Class Diagram (UML) [4]
QA 125
3 x 2
OT68T1
580,33
45
QA 125
2 x 1
OT69T1
548,77
45
QA 200
3 x 2
OT610T1
562,66
45
The second part of the OOA consists of an analysis of the
QA200
2 x 1
OT611T1
554,50
45
field of application. Here the interaction between man and
QA 200
3 x 2
OT612T1
601,96
45
machine is analyzed in order to determine the
functionality of the system, the user interface, and
software integration to other IT-systems etc. Other
Collaboration:
elements that need to be determined are also requirements
With class 4, 8 and 11
to response time, flexibility and so on. The result of this is
Figure 12. Example of a CRC Card.
a description of the user interface and a requirement
specification for the product and product related models.
60
The software from Invensys CRM / Baan was selected for
4. CONCLUSION
the programming phase.
The proposed procedure is based on well-known and
proved theory elements. The aim of the procedure is to
3. 5 PHASE 5: PROGRAMMING
serve as guidance for engineers, working with product
When programming a standard system the concepts for
modelling. The procedure has been tested at several
programming are sat by the supplier. The Baan
manufacturing companies in Denmark and abroad with
Configurator is logic and constraint based [5], [6]. The
positive results.
product attributes and constraints are programmed based
on the attributes and methods listed on the CRC-cards
The proposed procedure includes several fields of
from the OOA-model.
expertise:
The constraints are constructed with Boolean constraints,
1. Business process reengineering, and business
arithmetic constraints and warning constraints. Boolean
strategy
constraints use logical operators like AND, OR, NOT,
2. Product design and manufacturing technology
TRUE, FALSE etc. As an example a constraint
3. Theory for structuring mechanical systems, and
concerning the Cubic module is showed below:
structuring product- and product-related models
Cubic_module_CV AND
4. Object-oriented modelling
H_input_large_plus_Cubic_Y_DIN2M_CV3x2x1[0..2]
5. IT, Artificial intelligence and knowledge
--> Cubic_CV[CV3x2x1]
representation
6. Organizational aspects of application of product
The main part of the constraints in the system is of this
modelling
type. Arithmetic constraints use operators like +, -, *, /, <,
> etc. The last type is warning constraints that give a
The wide range of theory is included in the procedure in
message if some criteria are broken.
order to cope with the questions raised in the introduction
of the paper. I.e. how to deal with the business processes
There are approx. 12.000 Boolean variables and 7.000
affected by the models, how to analyse and structure
constraints in the configurator, which is close to the
products and how to implement the models in IT-systems.
maximum no. of variables and constraints the Baan
Configurator can handle.
The project described in this article has shown how to
build a configurator with automatic dimensioning and the
An example of a user interface is illustrated in figure 13.
specification of complex switchboards. The customers
save time, money and energy when using the
configurator. The users can now specify the demands to a
switchboard system and then use the configurator as
guidance when an optimal configuration is to be selected.
Different parameters such as loss of heat and price
summarisation of the system can be easily displayed. In
this way corrections to a configuration will be shown
immediately.
The effects of introducing a configurator in Demex
electric/Solar A/S can be summarised as follows:
1. Reduction of lead time from 3-4 days to 10
minutes when generating quotes.
2. Possible to optimise a configuration in relation to
e.g. resource consumption. This means up to 10
% reduction of materials.
3. Huge reduction in specification hours.
The configurator will be implemented in full scale at
Solar A/S homepage in summer 2002.
Figure 13. Example of user interface from the
configurator.
61
6. REFERENCES
[1]
Hvam, L., Riis, J., Malis, M. & Hansen, B., 2000, A
procedure for building product models, Product Models
2000-SIG PM, Linköping, Sweden.
[2]
Hubka, V. & Eder, W.E.: Theory of Technical Systems,
Springer-Verlag. Berlin, 1988.
[3]
Mortensen, N. H., Yu, B., Skovgaard, H. and Harlou, U.:
Conceptual modeling of product families in configuration
projects, 2000.
[4]
Booch, G., Rumbaugh, J. & Jacobson, I., 1999, The Unified
Modeling Language User Guide, Addison-Wesley.
[5]
[Sabin et. al., 1998]: Daniel Sabin, Rainer Weigel; Product
Configuration Frameworks A Survey, University of New
Hampshire and Swiss Institute of Technology, IEEE
Intelligent systems, 1998.
[6]
[Jackson, 1999]: Peter Jackson; Introduction to expert
systems, third edition, Addison-Wesley, 1999.
[7]
[Hammer, 1990]: Michael Hammmer; Re-engineering work:
Don't automate, obliterate, Harvard Business Review, July-
August, 1990.
[8] [Hammer et al., 1993]: Michael Hammer, James Champy;
Reengineering the Corporation, Harper Collins Publishers,
1993.
[9]
[Schwarze, 1996]: Stephan Schwarze; Configuration of
Multiple-variant Products, BWI, Zürich, 1996.
[10] [Schwarze & Burke,1994]: Stephen Schwarze, L. Burke; The
procedure of Product Configuration and Handling the
Configuration Knowledge, Proceeding of the Third IERC,
Atlanta, May 1994.
[11] [Tiihonen et. al., 1996]: Tiihonen, J., Soininen, T.,
Männistö, T., Sulonen, R.; State-of-the Practice in Product
Configuration a Survey of 10 Cases in the Finnish
Industry, Helsinki University of Technology, 1996
[12] Hvam, L. & Riis, J.: CRC Cards for Product Modelling,
Department of Manufacturing Engineering, Technical
University of Denmark, 1999. Antonio, Texas, November
17-20 1999.
[13] [Coad et al., 1991a]: Peter Coad, Edward Yourdon;
Object-oriented analysis, Prentice-Hall, Inc., Second
edition, 1991.
[14] Alexander Felfernig, Gerhard E. Friedrich And Dietmar
Jannach; UML as domain specific language for the
construction of knowledge-based configuration systems
International Journal of Software Engineering and
Knowledge Engineering, 2000.
62
Using Knowledge-Based Configuration for Configuring
Software?
ˇ
Lothar Hotz and Andreas G ¨unter
Abstract. In this paper, we present a short survey on research topics
From the developers point of view, important modeling aspects are:
which come into play when applying knowledge-based configuration
modeling of evolution, concise representation of variability, option-
techniques known in Artificial Intelligence (CAI) to the field of Soft-
ality, dependencies/relations between components, non-complicated,
ware Configuration Management (SCM). Knowledge-based configu-
non-chaotic modeling, architectural descriptions [3].
ration deals with generic, logic-based methods for configuring com-
Knowledge-based configuration known in Artificial Intelligence
ponents of a given domain. Typically these domains are hardware-
provides a generic way for configuring technical artefacts. A model
based, like PCs, electrical drives, but in principle the methods are
of a domain represented in a well-defined declarative configura-
not restricted to those domains. Because the methods are well under-
tion language is the basis of the configuration methodology. The
stood and configuration systems implementing those methods exist,
configured results can be shown to have properties like correctness
it is natural to examine them in an upcoming project for configuring
and completeness according to the specified model. Because of the
industrial products. Thus, this paper describes work that will be done
generic approach, construction of software can be examined as a fur-
based on work that was already done by us. As such, it is a position
ther application domain for CAI. In SCM a deep understanding of the
paper.
domain of software configuration has been obtained, where in CAI,
experiences in representing domain models and inferencing config-
1
Introduction
urations from a model are available. Hence, a combination of both
approaches might be promising [13].
Software is an important basis of most technical systems. Growing
This paper is structured as follows: First, we give a short presen-
complexity and variability of technical systems replace the develop-
tation of basics of SCM methods and systems (Section 2) and a short
ment of single software products with the development of product
overview of the methodologies developed in CAI (Section 3). In Sec-
families. Furthermore, the increasing use of embedded systems com-
tion 4, we discuss the research challenges of SCM and their possible
bining hardware and software make the process of software devel-
solutions in CAI. While these sections mainly deal with general as-
opment to a difficult task. To get started, we will analyse software
pects of combining CAI and SCM, in Section 5, we sketch a more
product development processes of industrial companies, restricting
restricted approach which we will follow in a new upcoming project.
us to industrial product lines with hardware and software compo-
nents. As industrial products, we will focus on the car periphery su-
2
Short view on SCM
pervision domain, which includes services like pre-crash detection,
parking assistance, parking spot detection, blind-spot-supervision,
Software Configuration Management systems focus on controlling
and adaptive-cruise-control. Besides considering software and hard-
the whole evolutionary process of software system development.
ware components, also requirement templates, feature models, and
This process is seen as a continuous process which does not stop
intermediate representations will be examined.
while the software is in use. To support this constantly changing
To handle this task, configuration management systems have been
process, SCM systems have been developed. There are a number
developed. Properties of configurations, which are computed by such
of SCM systems which support the main concepts of SCM systems
systems, should be:
more or less (for surveys in SCM see e.g. [2, 3, 6, 16]). These con-
cepts are: The representation of software objects as atoms by giving
˘
consistency, i.e. the components stacked together can be used to-
them a rudimentary name and a not further specified content "de-
gether;
scription" (e.g. "program code", "documentation", "test result" etc.),
˘
correctness, i.e. not the wrong components (in respect to specific
or as configurations by enumerating independently changing atoms
application needs) are selected;
or other configurations. Version control examines how interim prod-
˘
completeness, i.e. all necessary components are selected;
ucts are produced in the course of product development and how de-
˘
feasability, i.e. a possibly good (not necessarily optimal) solution
velopment of different aspects of the product can proceed in paral-
out of the big number of possible solutions is selected;
lel. Change control examines how changes to the software objects
˘
transparency, i.e. controlling the process of configuration should
are more or less formally described by giving information about the
be possible.
change like the objective of the change, the state of the change (e.g.
A prerequisite for such a support is a modeling method for the soft-
open, rejected) etc. Process control supports the whole software de-
ware to be constructed and a support for the configuration process.
velopment process, by describing the process in terms of "comple-
Ł
tion, acceptance, integration & test, take over". Distribution is re-
HITeC,
Fachbereich
Informatik,
Universit¨at
Hamburg,
email:
hotz@informatik.uni-hamburg.de
lated to distributed development of software by locally distributed
¤
dito, email: guenter@informatik.uni-hamburg.de
developers.
63
Besides these basic concepts of SCM, there are further approaches
CS the consistency of the hierarchy is well-defined (namely a strict
especially in the research community in development but not in-
specialization hierarchy) and will be checked by a specific module
cluded in commercial systems. The system Adele [4], (see also the
of a CS. Constraint solving uses methods that have been proven cor-
discussion in [2]) is based on an entity-relationship database with
rect, and property values of components can be inferred. The control
more elaborate data modeling capabilities than those offered by file
mechanism determines that all open issues (e.g. properties, parts) of
lists. However, drawbacks of such a system are: non strict object-
the configuration are handled by the configuration process [7]. All
orientedness, lack of sophisticated structured representations, incom-
these modules of a CS are general and thus, domain independent.
plete support of attributes (the user has to manage some declared
A domain specific configuration system can be obtained by imple-
attributes instead of the system), no system independent semantics.
menting a domain specific application user interface over the domain
Also the inference methods (which are based on so-called interfaces)
specific configuration model. In CAI, this has been done tradition-
are only centered around attributes and relations, not around software
ally for domains where hardware components are configured. For
objects as a whole. However, with Adele it is possible to capture the
software, the main challenge is to understand the specific concepts
evolution of all architectural elements in a single system model.
of the software development process in terms of the general concepts
Summarising, conventional configuration management tools are
of the logic-based configuration terminology.
intended to aid the production of single products, or products with
limited variability. Although they offer some support for configura-
4
Where are challenges/ problems in the field of
tion, using them for families of products, which developers are cur-
SCM and their possible solutions with CAI
rently forced to do, quickly leads to considerable adaptation effort
through support utilities. Over and above this, there is little support
In this section, we discuss problems mentioned in the SCM commu-
for checking the consistency of configurations or for using inference
nity and their potential solutions with methodologies coming from
to generate parts of the configuration.
CAI. We focus on software product representation, versioning, and
representing distinct kinds of knowledge. Other aspects like evolution
are presented in similar approaches like [12] and [5].
3
Knowledge-based configuration known in
Artificial Intelligence (CAI)
Software product representation In current commercial SCM sys-
The configuration of technical systems is one of the most successful
tems files and file handling are the basic components, thus, oper-
application areas of knowledge-based systems. [8] made a general
ations like merging, revision etc. are based on files not on objects
analysis of configuration problems in which four central aspects (or
[3]. Models and software products (instances) are roughly seen
knowledge types) concerned with configuration tasks were identi-
as the same kind of entities namely software programs [5]. These
fied:
facts demonstrate a main problem: there is no abstract, declara-
tive model of the source code being configured [12]. Each task
˘
A set of domain objects (concepts) in the application domain and
is done directly on source code and files. In CAI a configuration
their properties (parameters). By instantiating a domain object
language is given which provides the means for defining the four
concept instances are created. Thus, a domain object describes its
central aspects of configuration tasks (see Section 3). With such
instances.
a model, software products could be defined on a concept level,
˘
A set of relations between domain objects. Taxonomical and com-
and the instances (e.g. files, source code), which realize a specific
positional relations with alternatives, number restrictions, and op-
application, can be computed by the configuration system. An ex-
tionality are of particular importance for configuration. But further
ample for modeling a software system with CAI is given below.
relations can be expressed between arbitrary domain objects.
In this example, we describe parts of a tool box with the (here
˘
A task specification (configuration objective) that specifies the de-
simplified) language used in EngCon. The example specifies the
mands, which a created configuration must fulfil.
situation: "our-tool-box is a kind of software-system where
˘
Control knowledge for specifying the configuration process.
the parameters are specialized to the indicated, alternative values
(between {}) and its diverse relations are specialized to diverse
For all those kinds of knowledge not only a model can be declara-
obligate or optional concept types (indicated by concept names
tively defined but also an inference machinery is given, which inter-
and numbers)":
prets the knowledge. Thus, CAI provides not only a modeling facility
def-concept
like STEP or UML but operational, processable models. In the so-
:name our-tool-box
:superconcept software-system
called structure-based approach a compositional, hierarchical struc-
:parameters
system-purpose {configuration consistent-test layout-planning}
ture of the domain objects serves as a guideline for controlling the so-
procedure {not-fixed heuristic case-based}
requirement-for-the-solution {no optimal}
lution process, and as a logical basis for configuring. That means, that
requirement-for-efficiency {no efficient very-efficient}
:relations
the constructs used for modeling can be mapped to a logical language
has-userinterface [userinterface 1 1]
has-supporting-module
[interface 1 1] [obk 1 1] [slot-contexts 0 1]
where the semantics are well-defined [14]. The constraint-based ap-
has-basic-module
[ontology 0 1] [constraints 0 1] [task-description 0 1] [control 0 1]
proach consists of representing restrictions between objects or their
has-extension-module [multiple-inheritance 0 1] [fuzzy-ontology 0 1]
[fuzzy-constraints 0 1] [measurements 0 1] [requirement-modeling 0 1]
properties by means of constraints, and evaluating these by constraint
[case-based-configuration 0 1] [optimal-configuration 0 1]
[formulars 0 1] [taxonomical-inferencing 0 1] [backtracking 0 1]
propagation. This approach is not in conflict with the structure-based
An example for describing a relation between multiple compo-
approach but is frequently combined with it. Other approaches are
nents using constraints is given below. It is specified: "An our-
resource-based and case-based configuration.
tool-box with an interactive-strategy as extension-
Concepts used in the area of configuration have well-defined, sys-
module has to have exact one basic-module of the type
tem independent semantics which are manifested in implementations
control and exact one userinterface of type graphical-
userinterface". The "?" is used to mask local variables:
termed configuration systems (CS) like EngCon [1]. Such systems
def-conceptual-constraint
provide a more formal notion of consistency and completion than
:name interactive-strategy-requirements
:selected-components
Software Configuration Management systems [13]. For instance, in
?system :name our-tool-box
?sub-module :name interactive-strategy
64
:relations extension-module-of ?system
The project is a three year EU-Project and is composed of two indus-
:constraint-calls
number-restriction
trial partners: Robert Bosch GmbH, and Thales Nederland B.V. and
(?system has-basic-module) [control 1 1]
number-restriction
(?system has-userinterface) [graphical-userinterface 1 1]
two university partners: University of Groningen and University of
Versioning In [16] it is mentioned that versioning is mainly based
Hamburg/HITeC.
on a directed acyclic graph by using the is-version-of relation.
In CAI one could represent this aspect in the framework of spe-
6
Summary
cialization hierarchies. Here, versions can be described in terms
SCM provides a clear view of the software construction domain, and
of subconcepts with specializing properties or relations. Thus, also
of the main configuration aspects of that domain like evolution, ver-
version management of structures, relationships and interfaces can
sioning. CAI provides a generic kernel technology for configuring
be modeled, which is a further requirement mentioned in [6]. As
diverse types of knowledge. The logic-based representation and in-
described in Section 3, not only a model but also an inference ma-
ferencing methods of CAI provide the basis for a new step in the di-
chinery is given by CAI, hence, consistent configurations selected
rection of "modeling instead of programming", which is in our opin-
from multiple versions can be computed. Thus, the selection of
ion the main challenge for software construction. By combining the
appropriate components is dynamically supervised by the config-
already developed tools of SCM with the kernel technology of CAI,
uration system.
we see even further possibilities.
Representing distinct kinds of knowledge The CAI methodology
is general and generic. Hence, distinct aspects like features, re-
quirements, designs, test cases, task agenda, standard code arte-
REFERENCES
facts and their relations, etc. could be represented (see [16]). These
[1] V. Arlt, A. G ¨unter, O. Hollmann, T. Wagner, and L. Hotz, `Engcon -
diverse aspects of a domain can be modeled in distinct knowledge
engineering & configuration', in Proc. of AAAI-99 Workshop on Con-
basis and can be combined, e.g. by using strategies [7], in an inte-
figuration, Orlando, Florida, (1999).
grated system. As an example, in [10] a feature model is described,
[2] S. Dart, `Concepts in configuration management systems', in Proc. of
the 3rd. Intl. Workshop on Software Configuration Management, Trond-
which includes common and variable aspects of the capabilities of
heim, Norway, (1991).
software products. Such a feature model could be used by a con-
[3] J. Estublier, `Software configuration management: a roadmap', in ICSE
figuration system for identifying suitable software and hardware
- Future of SE Track, pp. 279289, (2000).
components.
[4] J. Estublier and R. Casallas, `The Adele configuration manager', in
Configuration Management, ed., Walter Tichy, 99133, John Wiley and
There are some issues, which do not have an obvious solution
Sons, Ltd., Baffins Lane, Chichester, West Sussex PO19 1UD, England,
and are still research aspects in both fields, CAI and SCM: com-
(1994).
[5] J. Estublier, J.M. Favre, and Morat P., `Toward PDM / SCM: inte-
bining CAI methods and SCM techniques, representing functional-
gration?', in Proc. of the 8. Intl. Workshop on Software Configuration
ity of software modules [11], product variability [6], and distributed,
Management, LNCS 1439, pp. 7595, Bruxelles, Belgium, (July 1998).
concurrent work [6]. Aspects, which are more related to SCM, are
Springer Verlag.
discussed in [3, 6, 16]: Automated change integration and merging
[6] K. Fr ¨uhauf and A. Zeller, `Software configuration management: State
of the art, state of the practice', in 9th International Symposium on Sys-
of changes; interoperability among configuration management sys-
tem Configuration Management (SCM-9), Toulouse, France, (1999).
tems; relationship between software architecture and configuration
[7] A. G ¨unter and R. Cunis, `Flexible control in expert systems for con-
management systems; constructing executable object modules; rep-
struction tasks', Journal Applied Intelligence, 2(4), 369385, (1992).
resenting data flow among modules; representing control flow among
[8] A. G ¨unter and C. K ¨uhn, `Knowledge-based configuration - survey and
modules; deployment issues and post deployment phase; distributing
future directions', in XPS-99: Knowledge Based Systems, Proceedings
5th Biannual German Conference on Knowledge Based Systems, ed.,
software into the field and maintaining it. How these problems can
F. Puppe, Springer Lecture Notes in Artificial Intelligence 1570, (1999).
be handled if CAI is used as a kernel technology, is still open.
[9] V. Haarslev and R. M ¨oller, `Consistency testing: The race experience',
in Proceedings TABLEAUX'2000. Springer-Verlag, (2000).
[10] A. Hein, M. Schlick, and R. Vinga-Marting, `Applying feature models
5
Configuration of Industrial Product Families
in industrial settings', in Software product lines - Experience and re-
search directions, ed., Donohoe P., pp. 4770. Kluwer Academic Pub-
In the new project Configuration of Industrial Product Families
lishers, (2000).
(ConIPF) following issues are examined:
[11] C. K ¨uhn, `Modeling structure and behaviour for knowledge based
software configuration', in 14th Workshop, New Results in Planning,
˘
In order to support realistic industrial applications, guidelines will
Scheduling and Design (PuK2000), ed., http://www-is.informatik.uni
be described for facilitating domain modeling (see [13, 15] for
oldenburg.de/sauer/puk2000/paper.html, (2000).
similar approaches).
[12] T. M¨annist ¨o, Towards Management of Evolution in Product Configura-
tion Data Models, Ph.D. dissertation, University Helsinki, 1998.
˘
A further focus is set to products that can be developed quickly
[13] T. M¨annist ¨o, T. Soininen, and R. Sulonen, `Product configuration view
and with little effort. On the one hand an early result can be pro-
to software product families', in Software Configuration Workshop
duced and on the other hand, for those components libraries can
(SCM-19), Toronto, Canada, (2001).
be developed for reusing generic software components.
[14] R. M ¨oller, C. Schr ¨oder, and C. Lutz, `Analyzing configuration
˘
For modeling, known configuration description languages will be
systems with description logics: A case study', in http://kogs-
used and possibly further developed for describing specific aspects
www.informatik.uni-hamburg.de/~moeller/publications, (1997).
[15] J. Tiihonen, T. Lehtonen, T. Soininen, A. Pulkkinen, R. Sulonen, and
of software modules, like functionality and state descriptions.
A. Riitahuhta, `Modelling configurable product families', in Proc. of
˘
A technology used for modeling will be Description Logics (DL),
the 4th WDK Workshop on Product Structuring, Delft, The Netherlands,
which provides a well-defined semantics for basic concept and
(October 1998).
role (=relation) definitions (for a description of a DL system see
[16] A. van der Hoek, D. Heimbigner, and L.W. Wolf, `Does configuration
management research have a future?', in Proceedings of the 5th In-
[9]). The combination of a DL with CAI will be examined to sup-
ter. Conf. on Software Configuration Management, LNCS 1005, Berlin,
port inferencing on the concept level, for e.g. automatically clas-
(1995). Springer-Verlag.
sifing new component models in a specialization hierarchy.
65
Experiences with a procedure for
modeling product knowledge and building product configurators
- at an American manufacturer of air conditioning equipment
Benjamin Hansen1 & Lars Hvam
Abstract
The objective of the acquisition is to transform the former
This paper presents experiences with a procedure for
small engineering company into a highly modern division
building configurators. The procedure has been used in an
that can mass-customize products on a large scale. An
American company producing custom-made precision air
important part of this is to automate the customer related
conditioning equipment. The paper describes experiences
configuration process with IT. This led to an initiative of
with the use of the procedure and experiences with the
building a configurator for the most suited air product
project in general.
family.
Introduction
At the Department of Manufacturing Engineering and
Management at the Technical University of Denmark there
have been several research projects involving the
application of expert systems/configurators in
manufacturing and engineering companies. Configurators
have been built to support the creation of customer specific
quotes, bill-of-materials, drawings, diagrams, routings, etc,
i.e. specifications created in the customer-related business
Figure 1: A picture of the air configuration equipment
processes.
Since most mass-producing companies do not really have
The project
complex configuration tasks in the customer-related
The project followed the procedure used in projects
processes, most research projects have been carried out in
connected to research at DTU. The project procedure is
engineering companies. These companies are typically
illustrated in Figure 2. The main experiences with the use
small and medium-sized companies that customize
of the procedure are discussed for each phase.
products to fit specific customer needs. Often these
companies have not been highly industrialized because it
has not been possible to automate knowledge work. All
Object
Implementing
over the western world such companies exist and they
Business
orientated
Programming
Maintenance
Pre-project
Process
Product
the
Analysis
analysis and
the
configurator in
of the
need to cut costs and reduce lead times to survive in the
Analysis
design of the
configurator
configurator
product model
the organization
global economy. Different IT systems such as CAD, PDM
and configurators may help to reach this goal.
6 month project time line, (Phases were iterative!)
This paper presents experiences with the use of the DTU
Figure 2: The general procedure with indication of
[Hvam et. al, 2000] procedure during a configuration
specific project activities.
project in such a company.
Pre-project initiatives
The case company
Before the actual project started there had been a rough
The case company is an American company with 200
analysis of the business process and the product to be
employees, manufacturing custom-made precision air
configured in it. This analysis indicated that an IT-based
conditioning equipment. The company was recently
configuration of a quote and of a bill-of-material was
acquired by a much larger company and is now a division
possible, but that it a simplification of the product
in that company. The customers are primarily companies
structure was necessary to be able to do it efficiently. The
in need of precision cooling to maintain the right inner
main arguments for doing so were the following:
climate in rooms with electronic equipment.
· There were too many low level part numbers
being involved in the configuration process.
1 Ph.D. student at Department of Manufacturing Engineering
and Management, Technical University of Denmark.
e-mail: blh@ipl.dtu.dk
66
· The mother company requires all configure-to-
order products to be structured in subassemblies
and designed for easy assembly.
This resulted in a new assembly structure of the product in
Characteristics
Analysis result
Future
manufacturing. All low-level components were grouped
requirement
into sub-assemblies that were classified in module classes.
Input/Output
The customer specifies a
The configurator
The final product now consists of a model with 12 classes,
list of 20-40 standard
must generate 80%
with 1 or more sub-assemblies/modules in each class. Each
features. Based upon
of
quotes,
this a priced quote is
manufacturing
sub-assembly consists of 1-50 low-level part numbers.
given. Then a detailed
BOM's and shipping
Thus the assemble-to-order model is no more than 3 levels
proposal/submittal
is
BOM's.
deep, consisting of a top level product variant, a list of
made. Internally the
sub-assemblies and a list of parts in each sub-assembly.
specifications:
manufacturing BOM,
arrangement diagram,
As stated often under Business Process Re-engineering
drawings,
electrical
projects it is important to simplify a process before
wiring and a shipping
automating it [Hammer, 1990]. This was exactly what was
BOM are made.
Frequency
10-15 orders are
The configurator
done through the modularization efforts [O'Grady 1999].
processes each week.
must be able to
It made the configuration task a whole lot simpler, which
The number of quotes is
support a frequency
meant that the basic structure of the configuration process
3-5 times higher.
10 times higher than
was simplified dramatically. This simplification of the
today.
Throughput
time
"clean orders" ship
The market requires
product structure was not an easy task. In fact it was not at
within 5 weeks. 2-6
a significant
all finished when the configuration project was started,
weeks are used during
reduction of lead
which meant that rules where changing during the
specification activities.
times.
modeling phase, and that a lot of time was spent waiting
Few orders are "clean
orders"
for updated lists of the assembly "super" BOM.
Resource
1-3 hours are spent on
Resource
consumption
each quote. 1-3 hours on
consumption should
Thus, one of the main experiences from this project is:
BOM creation.
be decreased, but is
· Redesigning the product structure and defining
not critical.
Quality
The quality of
Quality must be
sub-assemblies was the biggest single task
specifications is poor. A
improved.
related to the configurator project.
very manual process
with a lot of paper work
Business Process Analysis
result in
misunderstandings. This
The business process analysis is made to get an overview
may led to wrong items
of the specifications created in the process, and to define
being shipped.
what the requirements are for the configurator to be built.
Availability
The availability of
Quotes must be
To support this the procedure presents some analysis tools
specifications is poor. A
made available to all
high degree of paper
sales partners on the
(IDEF0, flowcharts, and a list of characteristics to be
makes it difficult to
internet.
analyzed to understand the task of the
access documents and
engineering/configuration process).
information when it is
needed
Through interviews with the people involved a flowchart
Learning curves
The learning curves are
Knowledge must be
1-2 years. This causes
put in a configurator.
of the process was drawn, and examples of specifications
big problems when new
created in the process were collected. This gave an
people are assigned.
impression of the flow and the information/specifications
Table 1: An analysis of specific characteristics of the
in the process.
business process
Some typical characteristics of configuration processes
were analyzed as illustrated in table 1.
67
[Hvam&Riis, 1999], which are used to model attributes
The main experiences with the business analysis were:
and methods for product models. Positive experiences at
· The analysis tools helped but,
another company [Hvam&Malis, 2001] with Lotus Notes
· Many decisions were actually based on "guts-
as a document database, led to the design of a specific
feelings" from top management.
Lotus Notes database to handle the knowledge acquisition
· The learning process was seen as more important
process Figure 3.
than short-term economical cost/benefit
evaluations.
The Lotus Notes database with CRC-card documents now
serves as a link between the domain expert and the
Product Analysis
programmer. Here there is a written "agreement" on all the
The structuring matrix [Andreasen, 1996] and the
knowledge used in the configurator. A rule must be
principles of building a product variant master [Mortensen,
documented and maintained here before it is modeled in
2000] were used to analyze the product. These tools are
the actual configurator. When in doubt about what rules
presented in the procedure as a means to analyzing the
were given from the domain expert to the programmer,
product.
these CRC-cards served as written proofs of what was
agreed upon. Using Lotus Notes makes it possible to work
A very important aspect that came to light during the
together over long distances, which is everyday life in the
analysis was the fact that the air-conditioning product did
company.
in fact have different structures in sales, manufacturing
and shipping (also illustrated in Figure 4). This was hard
for some top-level managers to accept, they kept
demanding one single structure. These three viewing
1
1
angles did have to be modeled separately, each getting
Sales
...
Sales
...
their own superstructure model (Product Variant Master),
n
n
just as the specifications generated from the configurator
Knowledge
Top
Mfg
Top
Mfg
level
BOM
level
BOM
would be different for sales, manufacturing and shipping.
1
1
This separation of the product model into 3 sub-models
Databases
Documents
Ship.
Ship.
BOM
...
BOM
...
made it a lot simpler to model the knowledge. The product
n
n
analysis resulted in 3 rough sketches of "product variant
Product model representation
Product model representation
Real world representation
(in Lotus Notes)
(in Cincom Knowledge Builder)
masters ".
Object orientated Analysis and Design
Programming
Real world language
Cincom Knowledge Builder Syntax
The most important experiences were:
· It was very helpful to have a clear understanding
Figure 3: The modeling process
of the product before the actual design of the
detailed product model was carried out. This
The model in Lotus Notes is grouped into 3 sub-models: a
made it possible to make a better overall structure
feature model used in sales, an assemble-to-order model
of the product model. It also supported the
used in manufacturing, and finally a shipping model.
planning of the knowledge acquisition process
needed for the detailed object-oriented design of
The main experiences with this phase were:
the product knowledge (next phase).
· Object-orientated modeling and the CRC-cards
· The product was seen from very different angles
made it easier to structure the knowledge. Exact
in sales and manufacturing. It was hard for some
syntax and semantics as used in software
people to understand that a product may actually
development were not used, since this was too
have different structures depending on the point
complex for the domain experts.
of view.
· Data redundancy occurred: The knowledge
· Using the theory of "product structuring"
documented in the model did refer to data and
[Andreasen, 1996] helped people without product
knowledge used and stored in other systems in the
design knowledge to understand the product
organization. Part numbers (sub-assemblies) were
better.
documented in a central part specification
database, and in the ERP system. Now they had
Object-oriented analysis and design of the product
to be documented in the knowledge model as well
model
(and later in the actual configurator software).
Based upon the analysis of the business process and the
This data redundancy was a problem that was
product, a model of the acquired knowledge was built.
well understood, and it led to an integration of
Principles from object-oriented design were used to model
integrating the CRC-cards in the Lotus Notes
the knowledge [Booch et. al 1999]. These principles are
database with the corporate part spec. database
basically to structure the knowledge in classes following
(which was also a Lotus Notes database).
an aggregation structure similar to the products "super-
Regarding the knowledge there were as many
BOM", and to attach attributes and rules to each class.
levels of redundancy as people in the
This encapsulates the knowledge in objects that are easy to
organization. Having an easily accessible
maintain and reuse. The actual tools used were so-called
knowledge representation on documents in Lotus
"Class-Responsibility-Collaboration" cards (CRC-cards)
Notes made it possible to reduce this knowledge
68
redundancy. In principle there would be no
be modified and maintained in one part of the code, while
redundancy since there is only one documented
UI, sales features and the constraining (Figure 5) of these
knowledge model. In reality it has been difficult
can be maintained in other separated parts of the code.
to make people understand the importance of
updating knowledge in this single repository, still
making errors of not having the latest knowledge
in the database possible.
· Using Lotus Notes to store the CRC-cards with
attributes and rules, made it a lot easier to collect
and document knowledge.
Programming in Cincom Knowledge Builder
Cincom's configurator software called Knowledge Builder
(KB2K) [www.cincom.com] was used as configurator
software. This software has been used with success in the
mother company for several of the projects and therefore it
was decided to use this tool again.
The structure of the product model in the program is very
similar to the structure of the product model in Lotus
Notes. For each CRC-card there is a corresponding group
of programming code in KB2K. Part of the code is directly
representing the product model, while another part
Figure 5: Constraints (top) and rules (buttom) in
represents system specific code used for UI navigation,
Cincom Knowledgebuilder
web integration etc. The model part of the code is
structured into three main categories: sales, mfg. BOM,
and Shipping BOM Figure 3.
Generating output data is done after all features are
selected. When pressing "done" on the last feature
To ease maintenance it has been decided to follow a strict
selection page, the configurator starts running over all
pattern using Boolean constraints to validate the selection
rule-trees on the superstructures (Figure 5). This results in
of features (representing the sales view on the product) on
several data-strings, representing the configuration in a
the user interface. After the features have been selected,
sales view (quote), a manufacturing view (manufacturing
IF-THEN rules are used to pick the right BOM-numbers
BOM) and shipping view (Manufactured unit + BOM for
on the respective "Super BOM structures" for assembly
shipped standard items). These data strings are then
and shipping. This is illustrated in Figure 4 .
exported to a database, from where the data can be used in
various applications. In this case they are used for
generating 3 types of reports: a quote, a manufacturing
TRUE / FALSE
Constraints
Sales
BOM, and a shipping BOM.
feature A
Sales
feature D
Sales
feature C
The main experiences were:
Sales
feature B
· Having a product model on "paper" (Lotus Notes)
THEN
Sales:
made the programming a whole lot faster. Having
Feature structure
IF
Sub-
data and knowledge written down in the Notes
assembly "A"
IF
database made it possible to utilize programming
Assembly:
Sub-
Sales
Product
assembly "B"
feature B
Top level
Sub-
resources better.
Sales
life
module structure
assembly "C"
feature A
Sub-
· Without giving a detailed evaluation of Cincom's
cycle
assembly "D"
Knowledge Builder it can be concluded that the
Shipping:
Finished goods
experiences with this tool were all positive.
structure
Especially the flexibility of the tool to represent
THEN
etc.
different kinds of knowledge in different ways
IF
Model "A"
was helpful. When standard-modeling techniques
IF
SKU "B"
Sales
were not enough, a high-level programming
feature D
SKU "C"
Sales
language could be used which also gave a great
feature B
SKU "D"
flexibility.
· It was possible to represent the programming in
Cincom in the same object-oriented aggregation
Figure 4: How constraints and IF-THEN rules are used
structure as in the product model (using
in the 3 different parts of the configurator
"Categories"), which made maintenance much
easier.
The separation between sales features (represented on the
UI) and BOM numbers makes it easier to maintain the
Implementation and description of the solution
configurator. BOM numbers and their selection rules can
The final solution is very similar to other configurators
generating a quote and a BOM. It runs on the web on an
69
intranet server. Data are stored in a central SQL database.
The case shows that transforming specification processes
Currently the configurator is mainly used internally to
from manual engineering processes to automated
validate quotes and to generate BOM's. It does fulfill the
configuration processes is a very complex task. The IT
requirements set up for it during the business process
aspect is only a smaller part of the development process,
analysis.
even when the goal is to build an IT system. The company
must have a good understanding of areas such as product
The most important experiences with the implementation
structuring, knowledge acquisition, business process
were:
reengineering, project management, configuration and
· It took more time than expected to implement the
database technology etc.
configurator in the organisation. Several details
and requirements were not defined until the users
The mother company that bought the little engineering
actually experienced the configurator through a
company was aware of this complexity. Therefore this
first hand experience.
configuration project, the first of many has been regarded
· Due to the object oriented product model which
as a learning project. Presenting a clear vision, motivating
was well documented in Lotus Notes and due to a
people, and being willing to spend a lot of resources on
similar object oriented modeling in Cincom it was
learning by doing, is believed to make it possible for the
relatively easy to make the necessary changes in
organization to cope better with the complexity of the
the configurator during the implementation.
transition towards mass-customization.
Conclusion
References
Using the procedure helped to structure the project better.
1: [Andreassen, 1996] Andreasen M.M. , Hansen C.T. ,
The specific tools presented in the procedure helped in the
N.H. Mortensen: "The structuring of products and product
different activities where they were applied. But a well-
programmes", Proceedings of the 2nd workshop on product
structured project framework with specific tools did not
structuring, 3-4th of June 1996, Delft University of
make up the success on it's own. In fact other factors were
Technology 1996.
even more important:
2: [Booch et. al 1999] Booch G., Rumbaugh J. & Jacobsen
· The strategic focus on mass customization in the
I.:"The Unified Modeling Language User Guide",
mother company and a vision to support it
Addison-Wesley, 1999.
ensured the necessary commitment and drive
3: [Hammer, 1990] Hammer M. "Re-engineering work:
from the people involved in the project. Without
don't automate, obliterate", Harvard Business Review,
this it would have been much harder to get
July-August 1990.
through with the project
4: [Hvam et. al 2000] Hvam L. , Riis J., Hansen B. , Malis
· Experiences with other configurator projects did
M. "A procedure for building product models",
exist. It was well known that the product would
Proceedings from the conference: "Product models 2000",
have to be modularized, and that people would
Linkoeping, Sweden, 7-8th November 2000.
have to be motivated in order for the project to
5: [Hvam & Riis, 1999] Hvam L. Riis J. "CRC cards for
become successful. Furthermore Cincom had
product modeling", The 4th Annual International
been used in the mother company for several
Conference on Industrial Engineering Theory, San
projects, which meant that there were "experts"
Antonio, Texas, November 17-20, 1999.
available to guide through technical issues. Thus
6: [Hvam&Malis, 2001] Hvam L. , Malis M. , "A
experiences with this type of projects are just as
knowledge based documentation tool for configuration
important as a structured procedure.
projects", World Congress on mass customization and
· A network to other companies doing configurator
personalization, October 1-2, Hong Kong 2001
projects was more or less established before the
7: [Mortensen 2000] Mortensen, Yu, Skovgaard and
project started. This meant that some typical
Harlou: "Conceptual modeling of product families in
problems could be avoided, and that inspiration
configuration projects", 2000.
for specific solutions could be found.
8: [O'Grady, 1999] O'Grady Peter. "The age of
modularity", Adams and Steele Publishers, October 1999.
70
Fuzzy Case Based Configuration
Laurent Geneste1 and Magali Ruet1
Abstract. We propose in this paper to define a configuration
Different applications propose to use Case Based Reasoning
process based on past configuration experiences. Similar techniques for configuration. For instance, in order to configure a
configuration problems are in this framework expected to have
Personal Computer, past pre-configured PC cases are reused and
similar configuration solutions. An integration of Case Based
adapted according to user requirements [1]. Another example
Reasoning and Constraint Satisfaction techniques (CSP) to support
concerns the elaboration of personal Electronic TV Programme
the configuration process is suggested. Since the manipulated
Guide (EPG): past similar programmes chosen by a user are
information is complex and imprecise, we propose to use a fuzzy
reused and combined with items recommended by similar users for
object oriented representation and to define appropriate algorithms
configuring a personal user guide [3].
for CBR and CSP integration. We illustrate our proposition by an
In order to solve a problem, several steps compose the Case
example about the configuration of a machining operation.
Based Reasoning process:
- model the problem,
Keywords. Configuration reuse, fuzzy knowledge base, FCSP,
- retrieve past problems,
CBR1
- reuse the most similar past problem by adapting its solution,
- revise the proposed solution,
1 INTRODUCTION
- and eventually retain this new case (the problem and its
solution) for future use.
Many configuration methods propose to use CSP techniques in
All along this process, the user can intervene in order to guide
order to deal with the complexity of configuration problems. These
the process and to control it.
techniques do not take into account past configuration problems
We introduce in section 2.1 mechanisms we use in order to
that may guide a new configuration. Our aim is to propose a
retrieve past configuration problem. Then in section 3 we present
configuration process taking into account past configuration
our work in combining CSP techniques with the adaptation step of
experiences. We suggest to search the solution of a configuration
the CBR process for configuration.
problem in the neighbourhood of a similar past configuration. That
is why the use of case based reasoning (CBR) paradigm is
proposed. Moreover, in order to support the reuse and adaptation
2.1 Search of past similar configuration
of a relevant past configuration, constraint satisfaction techniques
The aim of the search step is to provide the past configuration
are integrated in the CBR process.
experience which is most similar to the current problem. A
An object oriented modelling is used for representing similarity measure is applied between each possibly similar source
configuration cases. A case is modelled by an object composed of
cases (resulting from a rough filtering process which is not
characteristics (attributes). An attribute can be described by
developed here) and the target problem. This similarity measure
another object (composition). The possibility to manipulate takes into account the object oriented structure of cases and
imprecise characteristics of cases is integrated. Indeed, the
enables the use of possibility distribution in order to represent the
imprecision on the values of the characteristics is represented by
imprecision on the values of characteristics of cases [9]. The result
possibility distributions [5]. A characteristic A is defined on a
of the similarity measure is divided into two degrees of similarity:
reference domain R by a possibility distribution which express the
is the degree of necessity of resemblance of two cases and is
membership of each value of R to the characteristic A. A
the degre of possibility of resemblance of these cases ( and are
possibility distribution is a function of a reference domain R to
in [0,1]).
[0,1] such that sup (x) = 1, x R.
We distinguish the local similarity which is computed at
In this paper we propose to develop the way we reuse past
attributes (characteristics) level and the global similarity which is
configuration experiences. In section 2, we first shortly describe
an aggregation of local similarities and is computed at object level.
how the search process of past configuration experiences is carried
The local similarity is computed thanks to a similarity
out. Then we propose, in section 3, to use techniques of CSP for
membership function that enables a user to associate to an attribute
the adaptation of past configuration experience. Finally, we
a specific way to compute the similarity (e.g. the membership
illustrate our proposal on an example about the configuration of a
function near to, defined by µ
machining operation.
L(x,y) = 1-|x-y|/ where is a
constant). The user also controls the global similarity (at object
level) by weighting each attribute in the aggregation.
2 CASE BASED REASONING FOR
The similarity measure is computed as fallow:
Notations:
CONFIGURATION PROBLEM
- R denotes the reference case and S the source case
Case based reasoning is a paradigm that proposes to use past
- attR,L the name of attribute L of case R; valR,L its value
experiences in order to solve a current problem, when "similar
- DL the domain of attribute L and U = DL x DL
problems have similar solutions" [11]. In the CBR process, a past
- wL the weight associated to attribute L for the search
experience (source case) similar to the current problem (reference
- µL the membership function describing the local similarity for
case) is retrieved and its solution is adapted to the current problem.
attribute L
-
R the possibility distribution describing valR,L
- S the possibility distribution describing valS,L
1 Equipe PA - LGP - ENIT - Avenue Azereix, 65000 Tarbes,
- D the possibility distribution defined by
France, email: laurent@enit.fr, ruet@enit.fr
71
D(x,y) = min(R(x),S(y)) (1)
preferences on the design and on the combination of cases. Past
design cases are stored and when an architect designs a new
At the level of each attribute L, the possibility and necessity
building, he selects past cases and may add preferences on them if
degrees corresponding to a local similarity are computed as
necessary. Along with past cases, constraint on cases combination
follows:
are also stored. The past cases are combined to form a new design.
L(valR,L,valS,L) = supuU min(µL(u),D(u)) (2) Cases are then adapted with CSP algorithm according to
L(valR,L,valS,L) = infuU max(µL(u), 1-D(u))
knowledge they hold and to preferences.
The necessity and possibility degrees represent to which level
The approach defined in [20] for testing the interoperability of
two cases are similar. They respectively correspond to the lower
networking protocols suggests to represent the knowledge base
and upper bound of the similarity degree.
(Interoperability tests) as a set of CSPs. When a CSP fails
After the evaluation of each local similarity the evaluation of the
according to monitored observations, CBR is used to enhance the
global similarity is achieved, taking into account the weights
CSP according to previous similar cases.
associated to each characteristic of the target problem:
In the field of configuration, the authors of [21] introduce the
idea of starting from a previous configuration close to the customer
(R,S) = mini=1,n max(1-wi,si) (3)
requirements (instead of starting from scratch) and to adapt it. In
(R,S) = mini=1,n max(1-wi,si')
this system, cases are modelled according to the CSP
with :
representation and adapted thanks to neighbourhood, context
(val , val )
if
,...,
1
.
dependent and meta interchangeability concepts
L
R,i
S , j
j {
}
n attR,i = att
s
,
i =
S j
0
else
All these works are based on a CSP model of cases. This
(val , val )
if
,...,
1
.
modelling seems to be not sufficient to represent expert
L
R,i
S , j
j {
}
n attR,i = att
s'
,
i =
S j
knowledge. We propose to use an object oriented modelling of
0
else
cases which allows to model expert and complex knowledge.
In addition to the similarity measure we use an adaptability
Moreover the model we use permits to represent constraints
measure that reflects how easy past experiences can be reused. See
between objects. Hence, cases are not constructed in the form of a
[10] for more details.
problem of CSP.
The result of both similarity and adaptability measures allow to
In next section, we develop the way we integrate CSP
select an appropriate past configuration experience to continue the
techniques in a CBR process for configuration.
process. The solution of this past experience has to be adapted. We
propose to use constraint satisfaction techniques during this
adaptation process. We develop this point in the next section after
3.2 CSP for CBR adaptation
a brief literature overview.
CSP techniques can be used for guiding the adaptation of the past
solution to the current problem. In fact, when a case is retrieved in
3
INTEGRATION OF CBR AND CSP the case base, we propose to find a solution in the neighbourhood
TECHNIQUES FOR CONFIGURATION
of this case by constraining this neighbourhood. We need first to
define this area called adaptation domain. We expose our method
A lot of works propose to combine CSP and CBR techniques as
to determine it in section 3.2.1. Once the adaptation domains are
stated in [19]. We are mainly interested in works where constraint
found, the propagation of the constraints can begin. We describe
satisfaction techniques and configuration techniques are used in the
our proposition in section 3.2.2.
adaptation process of case based reasoning paradigm. We describe
these works in section 3.1 before presenting our proposition in
section 3.2.
3.2.1 Adaptation
domain
In order to determine an area all around the retrieved case, we
3.1 Related works
propose to calculate adaptation domain with three parameters: the
values of the retrieved case (values of its attributes), the similarity
In the COMPOSER system [16] CSP techniques are used to
membership function of each attributes of the retrieved case and a
support the adaptation process of CBR in the field of engineering
value that represent a similarity threshold.
design. The proposed methodology uses cases represented as a
The similarity membership function of an attribute (µL) and the
discrete CSP. A matching process is applied between old cases and
value of this attribute (µ
the new problem; several cases emerge of this matching. These
S) are used to determine a new membership
function (µ
cases, their solutions and their constraints form a new problem: the
R). This one is calculated by the projection on X axis of
the intersection of µ
new CSP which can be solved with CSP algorithms. In
L and µS (Fig 1). Then the -cut is computed in
the new membership function µ
COMPOSER all cases must be modelled as a CSP in order to
R (Fig 2). The result of this
calculation gives the adaptation domain of the attribute.
apply constraint satisfaction algorithm to adapt found cases.
In [14] the authors propose to use the CBR paradigm on
x
constraint satisfaction problems in product configuration. The case
x
based reasoning process is used to help the customer in the
expression of his needs. Past cases represent past sales and
µL(x,y)
X0
describe past buyers and the product they bought. The adaptation
X0
1
process is achieved thanks to interchangeability [15] [21]. In fact,
1
in a CSP, in some situations, a value can be replaced by another
µS(x,y)
value. Here the problem is to know which variables can be
X'0
y
X'0
y
replaced by which other variable(s), and to use this knowledge in
Figure 1. Intersection between µS(x, y) and µL(x, y)
order to solve the CSP. This is what is done in the CBR adaptation
process.
The IDIOM system [12] aims at promoting interactive design of
building by reusing past designs and adapting them according to
72
µ
Procedure Revise (i, j, Cons-P-sup)
1
Changed false
Height 0
0
for each d
x
i of Support(Ri) do
[inf,sup]
cons
0
Figure 2. -cut of the membership function µR(x,y)
for each dj of Support(Rj) do
cons
max ( cons, min ( µRi(di), µRij(di,dj), µRj(dj)))
3.2.2 Fuzzy constraint propagation
Height
max (cons, Height)
if cons µRi(di), do
In order to propose a good solution to the user, we suggest to use
Changed
true
CSP techniques to guide the adaptation process. We propose to
µRi(di) cons.
propagate domain constraints on the adaptation domain previously
Cons-P-sup min (Cons-P-sup, Height)
determined.
return Changed
The various domains of the constraints (discrete, continuous,
both), the arity of the constraints (binary, n-ary), and the dynamic
Based on this filtering algorithm and associated with a search
of the constraint application enable to select between several
algorithm such as Branch and Bound, we can propagate domain
propagation techniques such as [2], [4], [8], [18] as suggested in
constraints on the adaptation domains [6]. In the next section we
[13].
propose an example showing such use of CSP algorithms.
But we expect to use more of the CSP techniques possibilities.
In fact, we propose to use fuzzy CSP as described in [6]. First, the
use of soft constraints is in accordance with our proposition that
4 EXAMPLE
allows to model imprecise and uncertain knowledge and data.
We illustrate our propositions by an example on the
Second, prioritized constraints and prioritized soft constraints
configuration of a machining operation. A machining operation is
allow to personalize the constraints description.
made of a part, a tool and a machine. In this exemple, some
Before developing our proposition, we first remind notions on
attributes are described thanks to fuzzy number (Fig 3). A
soft constraint.
machining operation is represented by an object diagram (Fig 4).
As defined in [6] a soft constraint C is described by a fuzzy
relation R so that:
Fuzzy number
Let D
-a : double
1 x...x Dn be a fuzzy set of values that more or less satisfy C
1
-b : double
(D1,...,Dn are the respective domains of the variables {x1,...,xn} of
-c : double
the constraint C),
-d : double
0
then the fuzzy relation R is defined by a membership function µR
c a
b d
which associates to each tuple (d
1,...,dn) D = D1 x...x Dn a
Figure 3. Fuzzy class model
degree of satisfaction µR(d1,...,dn) in [0,1]. This degree expresses
to what level the solution d = (d
An instance of the class diagram is described in figure 6, in
1,...,dn) is compatible with the
constraint C:
which we can see four different operations recorded in the
µ
knowledge base (please note that to be make the schema easier to
R(d1,...,dn) = 1
means that (d1,...,dn) totally satisfies C
µ
read, attributes are written with abbreviations detailed in figure 3).
R(d1,...,dn) = 0
means that (d1,...,dn) totally violates C
0<µ
The operation to configure, called OpX, is represented in figure 5.
R(d1,...,dn)<1
means that (d1,...,dn) partially satisfies C
This target operation has some attributes known and others that are
Hence, a soft constraint expresses preferences among solutions.
not valued. In this example we present the search step of similar
A solution satisfies a constraint with a degree of satisfaction. Hard
operation (section 4.1) and the adaptation process (section 4.2).
constraint are particular soft constraint which degree of satisfaction
is 1 or 0 only.
The author of [7] proposes an extension of AC3 filtering
4.1 Search of the most similar operation
algorithm integrating fuzzy constraints called FAC-3 defined as
follow:
Based on the four operations of the knowledge base and on the
works previously presented, we can describe the search of the most
Let P be a fuzzy CSP defined by : P = (X, D, C, R), so that:
similar and adaptable past configuration.
- X is the set of variables
In order to compute the similarity and adaptability measures of
- D is the set of domains of the variables
each past cases we have to weight attributes of OpX and to select
- C is the set of constraints
similarity membership functions which have to be used.
- R is the set of fuzzy relations defining each constraint. R
In this example, importance is given to attributes "cutting
i is
defined by a fuzzy set. R
direction" and "relief angle", attributes of the tool: their weight are
i is the set of values that satisfy more or
less the constraint C
of 1. Numbers placed in front of the characteristics in figure 5
i.
Let Cons-P-sup be the upper approximation of the overall
correspond to the weight of characteristics of the operation to
consistency degree, and V(R) be the set of variables related by R,
configure.
then:
The similarity function membership used in this example are as
fallow:
Procedure FAC-3 (P = (X, D, C, R), = 0)
- similarity "close to" defined by
Cons-P-sup 1
x - y
Q { (i,j) / C
µ (x, y) = 1-
if 0 x - y = 1
h C s.t. V(Ch) = {Xi, Xj}, i j }
while Q not empty and Cons-P-sup > , do
µ (x, y) = 0 else
select and delete (i,j) from Q
- similarity "true/false" defined by
if Revise (i, j, Cons-P-sup) do
µ (x, y) =1if x = y
µ (x, y) = 0else
Q
Q {(k,i) / Ch C s.t. V(Ch)={Xi, Xk},ki,kj}
return Cons-P-sup.
73
Part
Material
name : string
name : string
roughness r : fuzzy number
breaking toughness Rm (da N/mm˛) : fuzzy number
diameter Dp (cm) : fuzzy number
melting temperature t° : fuzzy number
material :
Operation
Tool
name : string
Continuous Cutting Tool
cutting speed Vc : fuzzy number
name : string
height H (mm) : fuzzy number
Conventional CCT
part length Lg (cm) : fuzzy number
cutting direction : char
width W (mm) : fuzzy number
relief angle : fuzzy number
machined depth Ep (mm) : fuzzy number
line angle xr : fuzzy number
material :
cut depth Ap (mm) : fuzzy number
nomber of cog nb : int
lead a (mm/tr) : fuzzy number
Made of
part :
Plate
tool :
Discontinuous Cutting Tool
machine :
Machine
Plate CCT
shape : string
helix angle : fuzzy number
relief angle : fuzzy number
name : string
plate attachment : char
material :
available energy P (kW) : fuzzy number
plate :
Figure 4. Partial schema of the knowledge base
tX : Conventional CC Tool
m'X : Material
maX : Machine
opX : Operation
0 - name : string
0 - name : string
1 - cutting direction : char = L
0 - name : string
0 - Rm : fuzzy nbr
0 - name : string
0 - nb : int
0 - P : fuzzy nbr
0 - t° : fuzzy nbr
0 - Vc : fuzzy nbr
0 - xr : fuzzy nbr = 80, 80, 2, 2
0.5 - Lg : fuzzy nbr = 19, 21, 2, 2
0 - H : fuzzy nbr
0.75 - Ep : fuzzy nbr = 3, 3, 1, 1
0 - W : fuzzy nbr
0 - Ap : fuzzy nbr
0.75 - relief angle : fuzzy nbr = 7, 7, 1, 1
mX : Material
0 - a : fuzzy nbr
pX : Part
0 - material :
0.5 - part :
0.25 - name : string = XC 48
1 - tool :
0 - name : string
0 - Rm : fuzzy nbr
0 - machine :
0.75 - r : fuzzy nbr = 2, 2, 2, 2
0 - t° : fuzzy nbr
0.5 - Dp : fuzzy nbr = 8, 10, 2, 2
0.25 - material :
Figure 5. Operation to configure
- "ad hoc" similarity for instance for the comparison of material
example are given for each attribute on figure 7. Constraints of the
defined as follows:
domain have now to be propagated on the adaptation domains to
µ
XC18 XC25
XC38
XC48
XC60 produce a solution for the configuration problem. Three binary
XC48 0.7
0.8
0.9
1
0.3
constraints are taken into account in this example:
- an attachment constraint between a machine and a tool: C
- similarity between objects defined as follows for objects o and o':
M-T,
- a compatibility constraint between a tool and its material: CT-TM,
µ ( ,
o o')
= .( ,
o o') + 1
( - ).N( ,
o o')
- a machining constraint between the name of a tool material and
where enables to tune the strongness of required similarity.
the name of a part material: CTM-PM.
=1 corresponds to a loose requirement on the similarity
The fuzzy relation RTM-PM defining the constraint CTM-PM is as
whereas =0 corresponds to a strong requirement on the
follows:
similarity. In the following, we use this similarity function with
µR TM-PM (NTM,NPM) = 1
if
NTM = N2, N3, N4, N10
=1.
and
NPM = XC48
µR TM-PM (NTM,NPM) = 0.9 if
NTM = N1 and NPM = XC48
Results of the similarity and adaptability of each operation of
µR TM-PM (NTM,NPM) = 0.5
if
NTM = N13 and NPM = XC48
the knowledge base are given in table 1.
µR NTM-NPM(NTM,NPM) = 0.4 if
NTM = N11 and NPM = XC48
Table 1. Similarity and adaptability measures results
The fuzzy relations defining constraints CM-T and CT-TM are
described in table 2.
Op1
Op2
Op3
Op4
Similarity with
=0.5
=0.5
=0.33
=0.33
Table 2. Description of constraints CM-T and CT-TM
OpX
N=0.25
N=0.25
N=0.25
=0.25
C
Adaptability 0.734
0.748
0.752
0.744
M-T
µ
t2
t3
t4 other
N1 1 1 0 0
We can observe that from a similarity point of view, operation
N11 0 0 1 0
Op1 and operation Op2 have the same similarity degrees with
other 0 0 0 0
operation OpX. Nevertheless operation Op1 can not be easily
adapted to configure operation OpX (since its adaptability is equal
CT-TM
µ
t1
t2
t3
t4
to 0.734: the worst adaptability), when operation Op2 is more
ma1
1 0.7 0.6 0
adaptable and therefore is an interesting target for our
ma2
0 1 0.7 1
configuration process. Operation Op3 is more adaptable but is less
ma3
0 1 1 0
similar and should therefore not be privileged. The same remark
In order to construct the search tree of solutions we choose an
can be done for operation Op4.
order for the instantiation of the variables. The first variable to
instantiate is the name of the part material of OpX (PM=XC48).
4.2 Adaptation
Then we choose to instantiate respectively: the name of the tool
material (TM), the tool (T) and the machine (M). At each node of
When operation Op2 is chosen, we determine the adaptation
the tree, a value for the variable is chosen and the filtering fuzzy
domains for the operation at level = 0.5. The values for the
algorithm FAC-3 is applied for reducing variables domains.
74
op1 : Operation
t1 : Conventional CC Tool
name : string = carriaging
m3 : Material
name : string = o1
Vc : fuzzy nbr = 32, 36, 2, 2
ma1 : Machine
cutting direction : char = L
name : string = high speed steel (ARS)
Lg : fuzzy nbr = 28, 30, 1, 1
name : string = m1
nb : int = 1
Rm : fuzzy nbr
Ep : fuzzy nbr = 4, 4, 1, 1
P : fuzzy nbr = 25, 25, 2, 2
xr : fuzzy nbr
t° : fuzzy nbr
Ap : fuzzy nbr = 1, 1, 0.5, 0.5
H : fuzzy nbr = 190, 201, 1, 1
a : fuzzy nbr = 0.2, 0.2, 0.1, 0.1
W : fuzzy nbr = 24, 26, 1, 1
part :
relief angle : fuzzy nbr = 6, 6, 1, 1
tool :
material :
machine :
p1 : Part
m1 : Material
name : string = p1
name : string = XC 48
r : fuzzy nbr = 3, 3, 2, 2
Rm : fuzzy nbr = 80, 90, 5, 5
Dp : fuzzy nbr = 8, 10, 2, 2
t° : fuzzy nbr
material :
op2 : Operation
t2 : Conventional CC Tool
name : string = carriaging
name : string = o2
Vc : fuzzy nbr = 220, 230, 5, 5
cutting direction : char = N
Lg : fuzzy nbr = 30, 31, 0.5, 1
nb : int = 1
p2 : Part
Ep : fuzzy nbr = 4, 4, 1, 1
xr : fuzzy nbr
m4 : Material
Ap : fuzzy nbr = 1, 1, 0.5, 0.5
name : string = p2
H : fuzzy nbr = 145, 155, 4, 4
a : fuzzy nbr = 0.3, 0.3, 0.1, 0.1
r : fuzzy nbr = 2, 2, 1, 1
W : fuzzy nbr = 24, 26, 4, 4
name : string = carbide N1
part :
Dp : fuzzy nbr = 10, 12, 1, 1
relief angle : fuzzy nbr = 6, 6, 2, 2
Rm : fuzzy nbr
tool :
material :
material :
t° : fuzzy nbr
machine :
m2 : Material
ma2 : Machine
name : string = XC 38
t4 : Conventional CC Tool
Rm : fuzzy nbr = 75, 85, 5, 5
name : string = m2
name : string = o4
t° : fuzzy nbr
P : fuzzy nbr = 24, 24, 2, 1
cutting direction : char = N
op4 : Operation
nb : int = 1
xr : fuzzy nbr = 75, 75, 1, 1
name : string = carriaging
H : fuzzy nbr = 100, 120, 2, 2
Vc : fuzzy nbr = 225, 230, 4, 4
W : fuzzy nbr = 24, 26, 2, 2
m6 : Material
Lg : fuzzy nbr = 13, 14, 1, 1
relief angle : fuzzy nbr = 6, 6, 1, 1
name : string = carbide N11
Ep : fuzzy nbr = 5, 5, 1, 1
p4 : Part
material :
Rm : fuzzy nbr
Ap : fuzzy nbr = 3, 3, 0.5, 0.5
t° : fuzzy nbr
a : fuzzy nbr = 0.3, 0.3, 0.1, 0.1
name : string = p4
part :
r : fuzzy nbr = 3, 3, 2, 2
tool :
Dp : fuzzy nbr = 9, 11, 0.5, 0.5
m5 : Material
machine :
material :
name : string = XC 18
Rm : fuzzy nbr
t° : fuzzy nbr
p3 : Part
name : string = p3
op3 : Operation
r : fuzzy nbr = 2, 2, 0.5, 0.5
name : string = carriaging
Dp : fuzzy nbr = 12, 13, 1, 1
Vc : fuzzy nbr = 260, 280, 5, 5
material :
t3 : Plate CC Tool
Lg : fuzzy nbr = 9, 10, 0.5, 1
Ep : fuzzy nbr = 5, 5, 1, 1
name : string = o3
p1 : Plate
Ap : fuzzy nbr = 3, 3, 0.5, 0.5
cutting direction : char = N
shape : string = square
a : fuzzy nbr = 0.4, 0.4, 0.1, 0.1
nb : int
relief angle : fuzzy nbr
part :
ma3 : Machine
xr : fuzzy nbr = 75, 75, 1, 1
material :
tool :
name : string = m3
H : fuzzy nbr = 105, 110, 1, 1
machine :
P : fuzzy nbr = 25, 25, 1, 1
W : fuzzy nbr = 24, 26, 1, 1
plate attachment : char
plate :
Figure 6. Knowledge base
Before beginning the constraint propagation process, variables
DTM = {N11, N1}, with
µTM (N11) = 0.4
domains are as fallow:
µTM (N1) = 0.9
DM = {ma1, ma2, ma3} DT = {t2, t3, t4}
DTM = {N1, N2, N3, N4, N10, N11, N13}
The estimated local consistency has a value of 1. The next
DPM = {XC18, XC25, XC38, XC48}
variable to instantiate is TM. We choose the value TM = N1 with
All the variable values belong initially to their domain with a
the membership degree of 0.9. After applying the FAC-3
membership degree to 1.
algorithm, we obtain the partial search tree represented in figure 8
The first step of the constraint propagation is to choose a value
(values in brackets correspond to the upper bound of local
for the name of the part material: PM = XC48 and to apply the
consistency).
FAC-3 algorithm. After that, domain will be modified and also
membership degree. FAC-3 algorithm runs to the following
PM =
PM
XC
X 4
C 8
4 (CL
(C =1)
L=1
domains with membership degrees for the variables:
D
TM =
TM N
= 1
N (C = 0,9)
PM = {XC48}, with
µPM (XC48) = 0.9
L= 0
L
,9
D
Figure 8. Partial search tree
M = {ma1, ma2, ma3}, with µM (ma1) = 0.7
µ
The complete search tree is shown in figure 9 (intermediate
M (ma2) = 0.9
µ
search steps are not developed, the process is the same as
M (ma3) = 0.9
D
previously stated).
T = {t2, t3, t4}, with
µT (t2) = 0.9
µ
T (t3) = 0.9
µT (t4) = 0.4
75
ma2 : Machine
name : string = {m2}
t2 : Conventional CC Tool
P : fuzzy nbr = [22.5, 25]
name : string = {o2}
cutting direction : char = {N, L, R}
nb : int = {1}
op2 : Operation
xr : fuzzy nbr
m4 : Material
H : fuzzy nbr = [142.5, 157.5]
name : string = {carriaging}
name : string = {N1, N2, N3, N4, N10, N11, N13}
W : fuzzy nbr = [21.5, 28.5]
Vc (m/min) : fuzzy nbr = [217, 233]
Rm : fuzzy nbr
relief angle : fuzzy nbr = [4.5, 7.5]
Lg (cm) : fuzzy nbr = [29, 32]
t° : fuzzy nbr
material : = {m4}
Ep : fuzzy nbr = [3, 5]
Ap : fuzzy nbr = [0.25, 1.75]
a : fuzzy nbr = [0, 0.85]
part : = {p1, p2, p3}
p2 : Part
m2 : Material
tool : = {t2, t3, t4}
machine : = {ma1, ma2, ma3}
name : string = {p2}
name : string = {XC18, XC25, XC38, XC48}
roughness : fuzzy nbr = [1, 3]
Rm : fuzzy nbr = [72, 88]
diameter Dp (cm) : fuzzy nbr = [9, 13]
t° : fuzzy nbr
material : = {m1, m2}
Figure 7. Adaptation domains
[5] D. Dubois and H. Prade, Fuzzy Sets and Systems. Eds: Academic
Press. New York, Fuzzy Logic CDROM Library, 1996.
PM =
PM
= XC48
X
(CL
(C =1)
L=1
[6] D. Dubois, H. Fargier and H. Prade, Possibility theory in constraint
satisfaction problems: Handling priority, preference and uncertainty,
TM = N1 (CL= 0,9)
TM = N11 (C = 0,4)
Applied Intelligence (6) pp 287-309, 1996.
L= 0,9)
L=
L 0,4)
[7] H. Fargier, Problčmes de satisfaction de contraintes flexiles,
application ŕ l'ordonnancement de production, PhD Thesis, IRIT,
T = t2
t (C
2
L=
L 0,9 )
=
Toulouse, France, 1994.
[8] E. Gelle, On the generation of locally consistent solution spaces
M =
M = ma3 (C
3
L= 0,9 )
L=
inmixed dynamic contraint problems, PhD Thesis, Swiss Federal
Figure 9. Complete search tree
Institute of Technology (EPFL), Lausanne, 1998.
Thanks to FAC-3 algorithm and CSP propagation techniques,
[9] L. Geneste, M. Ruet and T. Monteiro, Configuration of a machining
domain constraints are applied on restricted domains and values for
operation, 14th European Conference on Artificial Intelligence, ECAI
2000, Configuration Workshop, Berlin, August 2000.
some variables are found. We can propose the user a machining
[10] L. Geneste and M. Ruet, Experience based configuration, 17th
operation based on Op2 with some valued characteristics.
International Conference on Artificial Intelligence, IJCAI'01,
Configuration Workshop, Seattle, Washington, USA, August 2001.
[11] J. Kolodner, Case Based Reasoning, Morgan Kaufmann Publishers,
5 CONCLUSION
Inc., 1993.
[12] C. Lottaz, Constraint solving, preference activation and solution
In this paper we describe our work and propositions to base
adaptation in IDIOM, Technical report, Artificial Intelligence
configuration process on past configuration experiences. First of all
Laboratory, Swiss Federal Institute of Technology, May/June, 1996.
we propose similarity and adaptability measures for searching
[13] T. Monteiro, J.L. Perpen, L. Geneste, Configuring a machining
among past configuration problems the most similar and adaptable
operation as a constraint satisfaction problem, CIMCA'99, Austria,
problem to the current problem to solve. Based on this retrieved
17-19 February 1999.
problem we can reuse its solution and adapt it to the current
[14] N. Neagu and B. Faltings, Constraint satisfaction for case adaptation,
problem. We define a search space near the retrieved configuration
Workshop on Case Adaptation of the International Conference on
Case-based Reasoning, ICCBR'99, Kaiserslautern, Germany, 1999.
case. Then we suggest to propagate domain constraints on this
[15] N. Neagu and B. Faltings, Exploiting Interchangeability Algorithms
search space in order to solve the target configuration problem and
over Discrete CSPs, Artificial Intelligence Laboratory (LIA),
propose the user an admissible solution.
Computer Science Department, Swiss Federal Institute of Technology
We illustrate our propositions by an example on the
(EPFL), 2001.
configuration of a machining operation. This kind of configuration
[16] L. Purvis and P. Pu, An approach to case combination, Workshop on
is complex and in many cases, experts solve machining
adaptation in case-based reasoning, ECAI 96, Budapest, Hungary,
configuration problem thanks to their past configuration
1996.
experiences. So we propose to combine case based reasoning
[17] L. Purvis, Synergy and commonality in case-based and constraint
process and CSP techniques for configuration.
based reasoning, Proceedings of the AAAI Spring Symposium on
Multimodal Reasoning, Stanford CA, 1998.
[18] D. Sam, Constraint consistency techniques for continuous domains,
REFERENCES
PhD Thesis, Swiss Federal Institute of Technology (EPFL), Lausanne,
1995.
[1] R. Bergmann and W. Wilke, Towards a new formal model of
[19] M. H. Sqalli, L. Purvis and E.C. Freuder, Survey of applications
transformational adaptation in case-based reasoning, Proceedings of
integrating constraint satisfaction and case-based reasoning,
the 13th European Conference on Artificial Intelligence, ECAI 98,
PACLP99: The First International Conference and Exhibition on The
Brighton, United Kingdom, ed. H. Prade, pp. 53-57, 1998.
Practical Application of Constraint Technologies and Logic
[2] C. Bessičre, Arc-consistency in dynamic constraint satisfaction
Programming, London, UK, 1999.
problems. Proceedings of the 10th AAAI, California, pp. 221-226,
[20] M. H. Sqalli and E.C. Freuder, CBR support for CSP modeling of
1991.
InterOperability testing, AAAI-98 Workshop on Case-Based
[3] P. Cotter and B. Smyth, Personalisation technologies for the Digital
Reasoning Integrations , Technical Report WS-98-15, pp. 155-160.
TV World, 14th European Conference on Artificial Intelligence,
July 27, 1998, Madison, Wisconsin, USA, 1998.
ECAI 2000, edited by Werner Horn, IOS Press, 2000.
[21] R. Weigel, B. Faltings and M. Torrens, Interchangeability for Case
[4] R. Dechter, , and A. Dechter, Structure driven algorithms for truth
Adaptation in Configuration Problems. Workshop on Case-Based
maintenance, Artificial Intelligence Journal, 82, pp. 1-20, 1996.
Reasoning Integrations (AAAI-98), Madison, Wisconsin, USA, 1998.
76
Distributed generative CSP framework for multi-site
product configuration
Alexander Felfernig, Gerhard Friedrich , Dietmar Jannach , and Markus Zanker
Abstract.
Today's configurators are centralized systems and do
todays digital markets implies that software systems supporting the
not allow manufacturers to cooperate on-line for offer-generation
selling and configuration task must no longer be conceived as stan-
or sales-configuration. However, supply chain integration of config-
dalone systems. A product configurator can be therefore seen as an
urable products requires the cooperation of the configuration systems
agent with private knowledge that acts on behalf of its company and
from the different manufacturers that jointly offer solutions to cus-
cooperates with other agents to solve a configuration task. This paper
tomers. As a consequence, there is a high potential for methods that
abstracts the centralized definition of a configuration task in [16] to
enable the computation of such configurations by independent spe-
a more general definition of a generative CSP that is also applicable
cialized agents. Several approaches to centralized configuration tasks
to the wider range of synthesis problems. Furthermore, we propose
are based on constraint satisfaction problem (CSP) solving. Most of
a framework that allows to address distributed configuration tasks by
them extend the traditional CSP approach in order to comply to the
extending DisCSPs with the innovative aspects of local generative
specific expressivity and dynamism requirements for configuration
CSPs:
and similar synthesis tasks.
The distributed generative CSP (DisGCSP) framework proposed
1. The constraints (and nogoods) are generalized to a form where
here builds on a CSP formalism that encompasses the generative
they can depend on types rather than on identities of variables.
aspect of variable creation and extensible domains of problem vari-
This also enables an elegant treatment of the next aspects.
ables. It also builds on the distributed CSP (DisCSP) framework, al-
2. The number of variables of certain types that are active in the local
lowing for approaches to configuration tasks where the knowledge is
CSP of an agent, may vary depending on the state of the search
distributed over a set of agents. Notably, the notions of constraint and
process. In the DisCSP framework, the external variables exist-
nogood are generalized to an additional level of abstraction, extend-
ing in the system are predetermined, but here the set of variables
ing inferences to types of variables. The usage of the new framework
defining the problem is determined dynamically.
is exemplified by describing modifications to some complete algo-
3. The domain of the variables may vary dynamically. Some vari-
rithms for DisCSP when targeting DisGCSPs.
ables model possible connections and they depend on the exis-
tence of components that could become connected.
1
Introduction/Background
We also describe the interesting impact of the previously men-
The paradigm of mass-customization allows customers to tailor (con-
tioned changes on asynchronous algorithms. In the following we mo-
figure) a product or service according to their specific needs, i.e. the
tivate our approach with an example, Section 3 defines a generative
customer can select between several features and options that should
CSP and in Section 4 distributed generative CSP is formalized and
be included in the configured product and can determine the physical
extensions to current DisCSP frameworks are presented.
component structure of the personalized product variant. Typically,
there are several technical and marketing restrictions on the legal pa-
2
Motivating example
rameter constellations and the physical layout. This led manufactur-
For the purpose of illustration of our approach we chose as exam-
ers to develop support for checking the feasibility of user require-
ple domain the well known N-queens problem. The characteristics
ments and for computing a consistent solution. This functionality is
of a distributed configuration problem or similar distributed synthe-
provided by product configuration systems (configurators), whereby
sis tasks are integrated into our N-queens scenario: (a) parts of the
they have shown to be a successful application area for different AI
problem (i.e., variables) are shared among agents and (b) the prob-
techniques [15] such as description logics [8], or rule-based [1] and
lem is dynamically extended (i.e., N is increased), if no solution can
constraint-based solving algorithms. [4] describes the industrial use
be found. Adding additional problem variables leads to domain ex-
of constraint techniques for the configuration of large and complex
tensions and thus to a larger search- and solution space. The goal is
systems such as telecommunication switches and [7] is an example
to place
queens on distinct squares in an
chess board,
¤
¤¦Ą§¤
of a powerful tool based on Constraint Satisfaction available on the
where no two queens threaten each other [17]. We formalize the
market.
problem by making each row of the board a problem variable
,
¨©
However, companies find themselves in dynamically determined
where the subscript ensures unique variable names. In a distributed
coalitions with other highly specialized solution providers that
setting we employ three agents, each owning a fraction of the con-
jointly offer customized solutions. This high integration aspect of
straints necessary to solve the N-queens problem. Furthermore, we
ˇ
want to show the generative aspect of problem solving in the exam-
Computer Science and Manufacturing, Universit¨at Klagenfurt, Univer-
sit¨atsstrasse 65-67, 9020 Klagenfurt, Austria. e-mail: felfernig, friedrich,
ple, where agents start with a representation of a 0-queens problem
˘
jannach, zanker @ifit.uni-klu.ac.at
and specific requirements on the final solution coming from outside.
Ł
77
Once the agents determine that a solution cannot be found, they ex-
model for the local configurators and we detail extensions to DisCSP
tend the problem space by adding an additional row which in conse-
algorithms.
quence enlarges the domain of row variables by one. Since the ex-
act number of problem variables is not known from the beginning,
constraints cannot be directly formulated on concrete variables. In-
stead, comparable to programming languages, variable types exist
that allow to associate a newly created variable with a domain and
~
Agent a
we can specify relationships in terms of generic constraints. [16]
)
1
link(x
tu
}
,x
xt
xt
x
tc
te
tu
define a generic constraint
as a constraint schema, where meta-
te
}
,x
tc y ,x
tc
te
z
y
,x
tu )
variables
act as placeholders for concrete variables of a specific
link(x
Agent a
Agent a
2
3
type 2. In our example three types of problem variables exist, repre-
x
x
xt
x
t
x
xt
tc
te
tu
t
tc
te
tu
senting the even ( ) and the uneven rows (
) as well as a type ( )
Agent a
"!
1
x x x
tc te ttu
of counter variables (
) for the number of instantiations of each
¨
) x
link(x
$#&%
type, which allows us to distribute the N-queens constraints among
1
tu
,x
te|
x
the agents. Therefore, each agent
posesses a set of private con-
t
2
u
link(x
,x
)
,x
c
'(©
3
tc
{
,x
x
straints
, i.e.,
3
t
,x
e
ˇ3A
A
A
A
,
A
A
A
1
)1032
)406587@93
CB
(D
(E
(FHG
)403IP7@93(Q
CR
(E
(FHG
x
v
2
t
u )
w
,x
and
link(x
A
A
A
, that are defined as follows:
4
4 x )
)103SP7T9U(V
CW
G
E
F
link(x
g
gHp
g
gHqsr
g
ˇYXa`
`
`
`
, where `
Agent a
Agent a
'(b"cd¨
7
'Cbhcd¨
'(b"cd¨
7
'(b"cd¨
'(b"cd¨
2
3
fe
di
$e
di
is a predicate that gives the assigned value of variable .
¨
x
x
1
2
Informally, the number of uneven rows may exceed the number of
x
x
3
4
even rows by one.
x
x
x
x
x
x
t
t
t
gvu
g
tc
te
tu
tc
te
tu
Xa`
`
'(b"ct
7
'(b"ct
B
e
i
No two queens on an even and an uneven row are allowed to take the
same column value.
Figure 1.
Motivating example
gC
g gCrHgu
gC
X
`
'xw3yctĄcdtx3¨ct
tx3¨ct
7'xw3yc
'(b"ct
D
$e
di
$e
g g
g
`
, where
returns a number
indicating that
is
'(b"ct
xH¨cd¨
¨
i
g
the
variable of its type and
is a predicate that returns the
3
Generative Constraint Satisfaction
d
'xw3ycd
absolute value of .
In many applications, solving is a generative process, where the num-
No two queens on an even and an uneven row are allowed to be on
ber of involved components (i.e., variables) is not known from the
the same diagonal.
beginning. To represent these problems we employ an extended for-
u
gvu
g
X
`
`
.
ˇ
ˇ
$e
$e
$e
$e
malism that complies to the specifics of configuration and other syn-
(Q
7
'(b"ct
7
'(b"ct
B
B
No two queens on uneven rows are allowed to take the same column
thesis tasks where problem variables representing components of the
value.
final system are generated dynamically as part of the solution pro-
u
gY
g g ghu
X
ˇ
ˇ
$e
$e
$e
$e
cess because their total number cannot be determined beforehand.
7d
'xwUyfctsĄgcd1x3¨ct
tx3¨ct
7
R
Be
B
g
g g
`
`
.
ˇ
The framework is called generative CSP (GCSP) [5, 16]. This kind
e
e
'xw3yc
'(b"ct
'(b"ct
B
No two queens on uneven rows are allowed to be on the same diago-
of dynamicity extends the approach of dynamic CSP (DCSP) for-
nal.
malized by Mittal and Falkenhainer [9], where all possibly involved
u
gu
g
X
`
`
.
ˇ
ˇ
di
di
di
di
variables are known from the beginning. This is needed because the
V
7
'(b"ct
7
'(b"ct
B
B
No two queens on even rows are allowed to take the same column
activation constraints reason on the variable's activity state. [10] pro-
value.
pose a conditional CSP to model a configuration task, where struc-
u
gv
g gu
X
ˇ
ˇ
tural dependencies in the configuration model are exploited to trig-
di
di
di
di
CW
7i
'xw3yctjĄcdx3¨ct
tx3¨ct
7
B
B
gk
g g
`
`
.
ˇ
di
di
ger the activation of subproblems. Another class of DCSP was first
'xw3yc
'(b"ct
'(b"ct
B
No two queens on even rows are allowed to be on the same diagonal.
introduced by [3] where constraints can be added or removed inde-
gnm
q
gpm
q
Xa`
Xa`
pendently of the initial problem statement. The dynamicity occuring
'(b"ctl$e
¨
¨
'Cbhctl$i
¨
¨
E
F
di
$eo
di
$e1o
The latter two constraints delimit the domain of row variables to the
in a GCSP differentiates from the one described in [3] in the sense
total number of rows.
that a GCSP is extended in order to find a consistent solution and the
Figure 1 depicts the initial situation, with a 0-queens problem. The
latter has already a solution and is extended due to influence from the
customer requests agent ˇ to satisfy the requirement of finding a so-
outside world (e.g., additional constraints) that necessitates finding a
'
lution containing at least two uneven rows:
new solution. Here we give a definition of a GCSP that abstracts from
X
the configuration task specific formulation in [16] and applies to the
x!6q
¨
esr
o
Having added
to the set of private constraints of agent
ˇ
, the
wider range of synthesis problems.
'
!6q
search process starts and the solution space is continuously extended
by the instantiation of additional problem variables, until a solution
Definition 1 (Generative constraint satisfaction problem (GCSP))
is found for a 4-queens problem that satisfies all local constraints
A generative constraint satisfaction problem is a tuple GCSP(
,
,
)
of the agents. The links between two agents indicate that they share
,
), where:
variables, which is described in more detail later on. Thus, a solu-
is the set of problem variables of the GCSP and
is the
tion to a generative constraint satisfaction problem requires not only
set of initially given variables.
finding valid assignments to variables, but also determining the ex-
is the set of generic constraints.
)
act size of the problem itself. In the sequel of the paper we define a
g
A
A
ˇ
is the set of variable types
, where
793
G
©
fc$ ©
oUoUo
B
The exact semantics of generic constraints is given in Definition 2 in Sec-
associates the same domain to each variable of type
, where the
©
tion 3.
domain is a set of atomic values.
78
r3g g
r3g g
g g
For every type
exists a counter variable
that
A
and
ˇUA
A
A
A
A
A
A
A
, the
©
¨
0H5
9U
3G
7Ă9xcd¨
c$
cd¨B
c$
cd¨D
c$
G
$2
holds the number of variable instantiations for type
. Thus, ex-
satisfiability of the generic constraint
is checked by testing the
©
B
gvu
g
gu
g
plicit constraints involving the total number of variables of spe-
following conditions: `
ˇ
`
`
`
'(b"cd¨
7
'(b"cd¨
'(b"cd¨
7
'(b"cd¨
B
D
B
cific types and reasoning on the size of the CSP becomes possible.
o
o
Definition 4 (Solution for a generative CSP) Given a generative
g
is a total relation on
A
, where
is the set of positive
Ąc
¤
¤
constraint satisfaction problem GCSP(
,
,
,
), then its solu-
g g
integer numbers. Each tuple
)
A
A
associates a variable
cd¨
c$
¨
tion encompasses the finding of a set of variables
, type and index
with a unique type
and an index , that indicates
is
¨
assignments
and an assignment tuple
for the variables in
, s.t.
g
the
variable of type . The function
accesses
and
·
d
Hfcd¨
g
returns the type
for
and the function
returns
1. for every variable
an assignment
`
is contained in ,
¨
¨s7
·
¨
1x3¨cd¨
g g
the index of .
s.t. `
and
f6hc$Hfcd¨
¨
2. every constraint
is satisfied under
and
)
·
By generating additional variables, a previously unsolvable CSP can
ş
3.
.
µ
become solvable, which is explained by the existence of variables
that hold the number of variables.
Note, that we do not impose a minimality criterium on the number
When modeling a configuration problem, variables representing
of variables in our solution, because in practical applications differ-
named connection points between components, i.e., ports, will have
ent optimization criteria exist, such as total cost or flexibility of the
references to other ports as their domain. Consequently, we need
solution, thus non-minimal solutions can be preferred over minimal
variables whose domain varies depending on the size of a set of spe-
ones.
cific variables [16].
The calculated solution (excluding counter variables) for the lo-
A
A
A
ˇ
ˇ
Example Given
as the type of variables representing ports
cal GCSP of agent
consists of
,
'
7
9H¨
¨
¨
¨
G
065
B
D
Q
n
rHg g
r3g g
g g
g g
ˇ3A
A
A
A
A
A
A
A
A
A
A
of modules and
as the type of port variables that are al-
and
065
7Ä9fcd¨
c$
cd¨B
c$
cd¨D
c$
cd¨Q
c$
G
&
r
ˇ
°
%
lowed to connect to modules, then the domain of the port variables
the assignment tuple
,
,
and
. Thus,
¨
7Ĺ
¨BĆ7Ç
¨DĆ7
¨¶Q7
A
A
ˇ
g
must contain references to modules. This is specified by
are the names of generated variables.
¨
¨
Q
fc$
&
oUoUo
g
r
%
defining
Note, that names for generated variables are unique and can be ran-
A
A Ł
, where Ł
is an upperbound on
&
fc$
7ˇ9
w3G
w
%
oUo˘o
the number of variables of type
, and formulating an additional
domly chosen by the GCSP solver implementation and therefore con-
n
generic constraint that restricts all variables of type
using the
straints must not formulate restrictions on the variable names of gen-
&
%
counter variable for the total number of variables having type
,
erated variables. Consequently, substitution of any generated variable
n
gsm
g
i.e.,
(i.e.,
) by a newly generated variable with equal type, in-
¨
Č
`
. With the help of the
function
Ą¤U¦h§¨
'Cbhct
¨
tx3¨c
$©
dex and value assignment has no effect on the consistency of generic
¦Ş
concrete variables can then be referenced.
Referring to our introductory example we can formalize the lo-
constraints. Our GCSP definition extends the definition from [16] in
cal GCSP of agent
the sense that a finite set of variable types
is given and during
ˇ
(initially consisting only of counter vari-
'
ables
, their type
, and the types of row variables) as
problem solving variables having any of these types can be gener-
¨
"!
«0657
2
ated, whereas in [16] only variables of a single type, i.e., component
A
A
,
A
A
A
A
A
A
ˇ
,
and
9H¨
¨
¨
G
)4065793
G
065v793
G
B
D
E
F
!
r3g g
g g
g g
$¬
di
fe
variables, can be created. Current CSP implementations of configu-
A
A
A
A
A
A
A
A°
. The domain for
®06537Ż9fcd¨
c$
cd¨
c$
cd¨
c$
G
!
!
!
g
d¬
di
$e
even and uneven row variables is consequently defined as
ration systems (e.g., [7] [4]) use a type system for problem variables,
fc$
7
g
g
r
where new variable instances, having one of the predefined types, are
A
A Ł
, where the domains for the row
fc$
7fc$!
7T9
w3G
oUo˘o
variables are limited by the domain constraints (i.e.,
dynamically created. This is only indirectly reflected in the definition
A
).
E
F
of [16] by the domain definition of component variables, which we
Definition 2 (Generic constraint) A generic constraint
for-
explicity represent as a set of types. Furthermore, the definition of
)
mulates a restriction on the meta-variables
A
A
. A meta-
generic constraints does not enforce the use of a specific constraint
±
±ł˛
g
0
oUoUo
variable
is associated a variable type
and must
language for the formulation of restrictions. Examples are the LCON
©
©
±
Hfct±
be interpreted as a placeholder for all concrete variables
, where
language used in the COCOS project [16], or the configuration lan-
¨f´
g
g
.
guage of the ILOG Configurator [7].
Hfcd¨x´
7µHfct±h©
Note, that the set of variables
can be theoretically infinite, lead-
Note, that generic constraints can also formulate restrictions on spe-
ing to an infinite solution space. For practical reasons, solver imple-
g
cific initial variables from
by employing the
function.
xH¨c
mentations for a GCSP put a limit on the total number of problem
Consider the GCSP(
,
,
,
) and let
restrict the meta-
)
)
variables to ensure decidability and finiteness of the search space.
g
variables
A
A
, where
is the defined variable
±
±
"6¶xct±©
˛
This way a GCSP is reduced to a dynamic CSP and in further conse-
0
o˘oUo
type of the meta variable
.
©
±
quence to a CSP. A DCSP models each search state as a static CSP,
Definition 3 (Consistency of generic constraints) Given an as-
where complex activation constraints are required to ensure the alter-
signment tuple
for the variables
, then
is said to be satisfied
nate activation of variables depending on the search state. These con-
·
under , iff
straints need to be formulated for every possible state of the GCSP,
·
g
g»ş
ş
g
¸
which leads to combinatorial explosion of concrete constraints. Fur-
A
A
X
¨
¨˛
Hfcd¨
7ąHfct±
Hfcd¨˛
7
g
˝
ľHż
˝
ľHŔaÁ
0
0
0
oUo˘o
oUoUo
thermore, the formulation of large configuration problems as a DCSP
A
A
is satisfied unter
, where
Hfct±
kĽ
±
±
·
˛
˛
˝
ľ
0
o˘oUo
indicates that the meta-variable
is substituted by the con-
is merely impractical from the perspective of knowledge representa-
±h©
±h©
2
crete variable
.
tion, which is crucial for knowledge-based applications such as con-
¨©
figuration systems.
Thus a generic constraint must be seen as a constraint scheme that is
4
DisCSP Framework
expanded into a set of constraints after a preprocessing step, where
meta-variables are replaced by all possible combinations of con-
In our framework, we are interested only in algorithms that guarantee
crete variables having the same type, e.g., given a GCSP of agent
a good/optimal solution. The first asynchronous complete search al-
ˇ
(excluding counter variables) with
ˇUA
A
,
gorithm is Asynchronous Backtracking (ABT) [18]. [2] shows how
065
065
'
7Â9H¨
¨B
¨¶DHG
7
79
ABT can be adapted to networks where not all agents can directly
6. A system agent is a special agent that receives the subscriptions
communicate to one another. [6] makes the observation that ver-
of the agents for the search. Its task is to decide the order of the
sions of ABT with polynomial space complexity can be designed.
agents, initialize the links and announce the termination of the
The extension of ABT with asynchronous maintenance of consisten-
search.
cies, and asynchronous dynamic reordering is described in [12, 14].
4.2
Framework for DisGCSP
[11] achieves an increased level of abstraction in DisCSPs by letting
nogoods (i.e. certain constraints) consist of aggregates (i.e. sets of
A distributed configuration problem is a multi-agent scenario, where
variable assignments), instead of simple assignments.
each agent wants to satisfy a local GCSP and agents keep their
We show how the basic DisCSP framework for ABT with exten-
constraints private for security and privacy reasons, but share all
sions for private constraints [11] can be applied to a scenario of
variables which they are interested in. As constraints employ meta-
distributed product configuration. Therefore, improving the perfor-
variables, the interest of an agent in variables needs to be redefined:
mance of ABT with extensions as referenced above is straightfor-
Definition 5 (Interest in variables) An agent
owning a local
ward. We summarize in the following the properties of the ABT al-
'a´
ĐŃŇkÓ
(
,
,
,
) is said to be interested in a variable
gorithm that guarantee its correctness and completeness [18]. Then
0UÔ
s0UÔ
)40˘Ô
0UÔ
0UÔ
of an agent
, if there exists a generic constraint
we apply this DisCSP framework to a scenario where each agent lo-
¨
«0HŐ
'
)10
Ô
formulating a restriction on the meta-variables
A
A
, where
cally solves a generative constraint satisfaction task. Each time an
±
±
˛
g
0
o˘o3o
is the defined variable type of the meta variable
agent extends the solution space of his local GCSP by creating an
"Hfct±h©
0UÔ
g
g
, and
A
A
X
.
additional variable, the DisCSP setting is transformed into a new
±©
Ö±h©
±
±
Hfcd¨
7µHfct±h©
˛
0
oUoUo
DisCSP setting, which again has all properties required by asyn-
Definition 6 (Distributed generative CSP) A distributed genera-
chronous search to correctly function.
tive constraint satisfaction problem has the following characteris-
tics:
4.1
Asynchronous Search
A
A
ˇ
is a set of
agents, whereby each agent
É×7d93'
'CG
'(©
We summarize the characteristics of asynchronous search algorithms
ĐŃŇŘÓ
o3oUo
owns a local
(
,
,
,
).
0U2
«032
)40U2
032
®0U2
like ABT [18] and its extensions [11] for private constraints:
All variables in
and all type denominators in
ˇ
ˇ
2
2
Ů
«0
Ů
0
©fÚ
©ŰÚ
share a common namespace, ensuring that a symbol denotes the
1.
A
ˇ
is a set of
totally ordered agents, where
same variable, resp. the same type, with every agent.
ÉĂ7Ę93'
'(¶G
'(©
oUoUo
has priority over
if
.
For every pair of agents
A
and for every variable
'´
»ËhĚ
©
´
'
'
É
¨
2. Each agent
owns a set of local constraints
and
is interested
, where agent
is interested in , must hold
.
0
'
)
'
2
«0UÔ
'(©
¨
¨
«0
in those variables that are contained in its local constraints, called
For every pair of agents
A
and for every shared variable
'(©
'´
É
local variables. A link exists between two agents if they share a
the same type and index must be associated to
2Ü
0
0UÔ
¨
¨
variable, that is directed from the agent with higher priority to
g
gş
in the local GCSPs of the agents, i.e.,
0U2
0
"6¶
cd¨
7TH
Ôacd¨
the agent with lower priority. A link from agent
g
g
ˇ
to agent
is
.
'
'B
1x3¨
2˘cd¨
7tx3¨
cd¨
0
0UÔ
refered to as an outgoing link of ˇ and an incoming link of
.
'
'CB
For every pair of agents
A
and for every shared variable
g
©
´
'
'
É
¨
3. An aggregate is a triplet
A
AÍ
, where
is a variable,
cd¨x´
y3U´
´
¨x´
a link must exist that indicates that they share variable .
g
Ü
2
¨
0
0UÔ
a set of values for
and Í
is a history of the pair
A
,
y3U´
¨f´
´
cd¨f´
y3U´
The link must be directed from the agent with higher priority to the
where the history marks the aggregate with the information re-
agent with lower priority.
quired for a correct message ordering (a counter in ABT).
4. The view of an agent
is a set of the aggregates for those variables
Definition 7 Given a distributed generative constraint satisfaction
'
agent
is interested in.
problem among a set of
agents then its solution encompasses the
'
5. The agents communicate using the following types of messages,
finding of a set of variables
, type and index assign-
ˇ
2
Ę7Ů
«0
©fÚ
where channels without communication loss are assumed:
ments
and an assignment tuple
for
ˇ
ˇ
Ý7Ů
2
·«7Ů
·
2
0
0
©ŰÚ
©fÚ
every variable in
, s.t. for all agents
A
X
and
are a
2
2
2
©
0
0
0
'
·
ok? message. Agents with higher priorities communicate via
ĐŃŇkÓ
solution for the local
of agent
.
ok? messages a proposal for a set of variables to lower priority
032
©
'
agents. Each proposal is associated with a history, that allows
Remark A solution to a distributed generative CSP is also a
the recipient to identify the most recent message.
solution to a centralized GCSP(
,
,
,
ˇ
ˇ
ˇ
2
2
2
Ů
«0
Ů
)10
Ů
0
©ŰÚ
©fÚ
©fÚ
nogood message. In case an agent cannot find a proposal that
).
ˇ
2
Ů
0
©fÚ
does not violate its own constraints and its stored nogoods, it
Definition 8 (Generic aggregate) A generic aggregate is a unary
generates an explanation under the form of an explicit nogood
generic constraint. It takes the form:
A
A
AÍß
, where
is a meta-
Ţt±
y
±
Î
. A nogood can be interpreted as a constraint that forbids
¤
variable, is a set of index values for which the constraint applies,
a combination of value assignments to a set of variables. It is
y
is a set of values and Í is a history of the aggregate.
announced via a nogood message to the lowest priority agent
that has proposed an assignment3 in
.
¤
Definition 9 (Generic nogood) A generic nogood takes the form
addlink message. It transports a set of variables `
, where
Î
, where
is a set of generic aggregates for distinct meta-
'xĎy
¤
¤
the receiver agent is informed that the sender is interested in
variables.
the variables `
and for every variable in `
a link is es-
'(Ďay
'(Ďay
tablished from the higher priority agent to the agent with lower
Given the characteristics of a DisGCSP (see Definition 6) the links
priority.
can be initialized before the start of the algorithm, due to the common
naming space for type denominators and the condition of a unique
D
aggregate in the Asynchronous Aggregation Search (AAS) algorithm [11]
type and index assignment to variables over all agents.
80
Value assignments to variables are communicated to agents via
5
Conclusions
ok? messages that transport generic aggregates in our DisGCSP
Building on the definition of a centralized configuration task from
framework, which represent domain restrictions on variables by
[16], we formally defined a new class of CSP, termed generative CSP
unary constraints. Each of these unary constraints in our DisGCSP
(GCSP), that generalizes the approaches of constraint-based configu-
has attached an unique identifier called constraint reference (
) [13].
ŕ˘Ď
rator applications in use [4, 7]. The innovative aspects include an ad-
Any inference has to attach the
s associated to arguments into the
ŕáĎ
ditional level of abstraction for constraints and nogoods. Constraints
obtained nogood. We treat the extension of the domains of the vari-
and nogoods can refer to types of variables. Furthermore, we ex-
ables as a constraint relaxation [13]. For this reason we introduce the
tended GCSP to a distributed scenario, where this abstraction adapts
next features for algorithm extensions:
well DisCSP frameworks for dynamic configuration problems (but it
can be used in static models as well). We have described how this
g
announce message broadcasts a tuple
A
A
, where
is a newly
cd¨
¨
enhancement can be naturally integrated in a large family of existing
created variable of type and with index to all other agents. The
asynchronous algorithms for DisCSPs.
receiving agents determine their interest in variable
and react
¨
depending on their interest and priority in one of the following
REFERENCES
ways (a) send an addlink message transporting the variable set
(b) add the sending agent to its outgoing links or (c) discard
[1] V.E. Barker, D.E. O'Connor, J.D. Bachant, and E. Soloway, `Expert
93¨1G
the message.
systems for configuration at Digital: XCON and beyond', Communica-
Ńâ
tions of the ACM, 32(3), 298318, (1989).
domain message broadcasts a set
of obsolete constraint ref-
[2] C. Bessi`ere, A. Maestre, and P. Meseguer, `Distributed dynamic back-
erences. Any receiving agent removes all the nogoods having at-
tracking', in Proc. of 7th Int. Conf. on Principles and Practice of Con-
Ńâ
tached to them a constraint reference
. The receiver of
straint Programming (CP), p. 772, Paphos, Cyprus, (2001).
ŕ˘Ď
the message calls then the function check agent view() detailed
[3] R. Dechter and A. Dechter, `Belief Maintenance in Dynamic Con-
in [18], making sure that it has a consistent proposal or that it gen-
straint Networks', in Proc. 7th National Conf. on Artificial Intelligence
(AAAI), pp. 3742, St. Paul, MN, (1988).
erates nogoods.
[4] G. Fleischanderl, G. Friedrich, A. Haselb¨ock, H. Schreiner, and
nogood messages transport generic nogoods Î
that contain as-
M. Stumptner, `Configuring Large Systems Using Generative Con-
¤
signments for meta-variable instances. These messages are mul-
straint Satisfaction', in IEEE Intelligent Systems, Special Issue on Con-
ticasted to all agents interested in
figuration, ed., E. Freuder B. Faltings, volume 13(4), 5968, (1998).
Î
. An agent
is interested
¤
Év©
[5] A. Haselb¨ock, Knowledge-based configuration and advanced con-
in a generic nogood Î
if it has interest in any meta-variable in
¤
straint technologies, Ph.D. dissertation, Technische Universit¨at Wien,
Î
.
¤
1993.
When an agent needs to revoke the creation of a new variable
[6] W. Havens, `Nogood caching for multiagent backtrack search', in Proc.
due to backtracking in his local solving algorithm, he assigns it
of 14th National Conf. on Artificial Intelligence (AAAI), Agents Work-
a specific value from its domain indicating the deactivation of the
shop, Providence, Rhode Island, (1997).
[7] D. Mailharro, `A classification and constraint-based framework for con-
variable and communicates it via an ok? message to all interested
figuration', Artificial Intelligence for Engineering Design, Analysis and
agents.
Manufacturing, 12(4), 383397, (1998).
[8] D.L. McGuiness and J.R. Wright, `Conceptual Modeling for Config-
uration: A Description Logic-based Approach.', Artificial Intelligence
In order to avoid too many messages a broker agent can be in-
for Engineering Design, Analysis and Manufacturing, 12(4), 333344,
troduced that maintains a static list of agents and their interest in
(1998).
variables of specific types comparable to a yellow pages service. In
[9] S. Mittal and B. Falkenhainer, `Dynamic Constraint Satisfaction Prob-
this case the agent that created a new variables only needs to request
lems', in Proc. of 8th National Conf. on Artificial Intelligence (AAAI),
pp. 2532, Boston, MA, (1990).
the broker agent for a list of interested agents and does not need to
[10] D. Sabin and E.C. Freuder, `Configuration as Composite Constraint
broadcast an announce message to all agents.
Satisfaction', in Proc. of AAAI Fall Symposium on Configuration, Cam-
bridge, MA, (1996). AAAI Press.
[11] M.-C. Silaghi, D. Sam-Haroud, and B. Faltings, `Asynchronous search
with aggregations', in Proc. of 17th National Conf. on Artificial Intelli-
Theorem 1 Whenever an existing extension of ABT is extended with
gence (AAAI), pp. 917922, Austin, TX, (2000).
the previous messages and is applied to DisGCSPs, the obtained pro-
[12] M.-C. Silaghi, D. Sam-Haroud, and B. Faltings, `ABT with asyn-
tocols are correct, complete and terminate.
chronous reordering', in Proc. of Intelligent Agent Technology (IAT),
pp. 5463, Maebashi, Japan, (October 2001).
[13] M.-C. Silaghi, D. Sam-Haroud, and B.V. Faltings, `Maintaining hierar-
Ó
Proof: Let us consider that we extend a protocol called
.
chically distributed consistency', in Proc. of 7th Int. Conf. on Principles
and Practice of Constraint Programming (CP), DCS Workshop, pp. 15
Completeness: All the generated information results by inference.
24, Singapore, (2000).
If failure is inferred (when no new component is available), then
[14] M.-C. Silaghi, D. Sam-Haroud, and B.V. Faltings, `Consistency mainte-
indeed no solution exists.
nance for ABT', in Proc. of 7th Int. Conf. on Principles and Practice of
Termination: Without introducing new variables, the algorithm
Constraint Programming (CP), pp. 271285, Paphos, Cyprus, (2001).
terminates. Since the number of variables that can be generated is
[15] M. Stumptner, `An overview of knowledge-based configuration', AI
Communications, 10(2), (June, 1997).
finite, termination is ensured.
[16] M. Stumptner, G. Friedrich, and A. Haselb¨ock, `Generative constraint-
Ó
Correctness: The resulting overall protocol is an instance of
,
based configuration.', Artificial Intelligence for Engineering Design,
where the delays of the system agent initializing the search equals
Analysis and Manufacturing, 12(4), 307320, (1998).
the time needed to insert all the variables generated before termina-
[17] E. Tsang, Foundations of Constraint Satisfaction, Academic Press,
tion. Therefore the result satisfies all the agents and the solution is
1993.
[18] M. Yokoo, E. H. Durfee, T. Ishida, and K. Kuwabara, `Distributed
correct ă
constraint satisfaction for formalizing distributed problem solving', in
Proc. of 12th Int. Conf. on Distributed Computing Systems (ICDCS),
pp. 614621, Yokohama, Japan, (1992).
81
Semantic Configuration Web Services in the
CAWICOMS Project
Alexander Felfernig, Gerhard Friedrich , Dietmar Jannach , and Markus Zanker
Abstract. Product configuration is a key technology in today's
characterizing attributes that offer a range of different choices. Cus-
highly specialized economy. Within the scope of state-of-the-art B2B
tomers are enabled to configure goods and services according to their
frameworks and eProcurement solutions, various initiatives take into
individual needs at no extra cost following the paradigm of mass cus-
account the provision of configuration services. However, they all are
tomization [23]. Product configuration systems (configurators) sup-
based on the idea of defining quasi-standards2 for many-to-many re-
port sales engineers and customers in coping with the large number
lationships between customers and vendors. When moving towards
of possible product variants.
networked markets, where suppliers dynamically form supply-side
The goal of the research project CAWICOMS is to enable configu-
consortia, more flexible approaches to B2B integration become nec-
ration systems to deal simultaneously with configurators of multiple
essary. The emerging paradigm of Web services has therefore a huge
suppliers over the Web. This allows for end-to-end selection, order-
potential in business application integration. This paper presents
ing and provisioning of complex products and services supplied by
an application scenario for configuration Web services, that is cur-
an extended value chain. We employ an ontology-based approach
rently under development in the research project CAWICOMS3. An
that builds on the flexible integration of these configuration Web ser-
ontology-based approach allows the advertisement of services and
vices. Furthermore, it can be shown how the capability of each con-
a configuration specific protocol defines the operational processes.
figuration system can be described on the semantic level using an
However, the lack of widely adopted standards for the semantic an-
application scenario from the telecommunication domain. For repre-
notation of Web services is still a major shortcoming of current Web
sentation of the semantic descriptions the evolving language standard
technology.
of the 'Semantic Web' initiative [3], [12], OIL resp. DAML+OIL [9]
is employed.
In Section 2 we start by giving an overview on the application do-
1
Introduction
main. In Section 3 we describe the Web service architecture and in
Section 4 a multi-layer ontology definition for our application do-
The easy access to vast information resources offered by the World
main is given. The interaction processes between the Web service
Wide Web (WWW) opens new perspectives for conducting business.
providers and requestors are discussed in Section 5.
State-of-the-art electronic marketplaces enable many-to-many rela-
tionships between customers and suppliers, thus replacing inflexible
one-to-one relations dating to the pre-internet era of EDI (electronic
2
Application scenario
data interchange). The problem of heterogeneity of product and cat-
alogue descriptions as well as inter-company process definitions is
Easy access to the corporate network and secure connections to busi-
potentially resolved by imposing a common standard on all market
ness partners is crucial in today's economy. Virtual Private Networks
participants, although this can be costly to achieve. In this regard,
(VPN) extend the intranet of a possibly multi-national company and
the non-existence of a single standard for conducting B2B electronic
are capable of meeting the access requirements at reduced cost using
commerce constitutes a major obstacle towards innovation. Exam-
the worldwide IP network services and dedicated service provider IP
ples for competing and partly incompatible B2B frameworks are
backbones. VPN infrastructures are designed to be flexible and con-
OBI, RosettaNet, cXML or BizTalk [25]. They all employ XML4 as a
figurable in order to be able to cope with a rich variety of possible
flexible data format definition language, that allows to communicate
customer requirements. Therefore, the establishment of some con-
tree structures with a linear syntax; however, content transformation
crete VPN involves different steps after determination of customer
between those catalog and document standards is far from being a
requirements like locations to be connected or specification of re-
trivial task [8]. The issue of marketplace integration mechanisms for
quired bandwidth: selection of adequate access facilities from the
customizable products is far more complex, because products have
customer site to some entry point to the VPN backbone, reservation
of bandwidth within the backbone, as well as configuration of rout-
ˇ
Computer Science and Manufacturing, Universit¨at Klagenfurt, Univer-
ing hardware and additional services like installation support.
sit¨atsstrasse 65-67, 9020 Klagenfurt, Austria. e-mail: felfernig, friedrich,
˘
jannach, zanker @ifit.uni-klu.ac.at
Note, that it is very unlikely that all these products and services
Ł
¤
Due to a high number of competing standardization efforts, none of them
needed for the provision of such a VPN can be supplied by one sin-
appears to be a de-facto industry standard.
gle organization, but are in general made available by different spe-
Ą
CAWICOMS is the acronym for "Customer-Adaptive Web Interface for
cialized solution providers, e.g., Internet Service Providers, telecom-
the Configuration of Products and Services with Multiple Suppliers". This
munication companies or hardware manufacturers (see Figure 1).
work was partly funded by the EC through the IST Programme under con-
tract IST-1999-10688 (http://www.cawicoms.org).
Therefore, VPNs are typically marketed by specialized resellers (or
¦
See http://www.w3c.org/xml for reference.
telecommunication companies like two of our application partners)
82
that integrate the services of individual suppliers and offer complete
to be defined in such a way that automated identification of this
VPN solutions to their customers.
service is possible.
Service identification - the requestor of a service imposes a set of
requirements which serve as the basis for identifying a suitable
Internet
service. In our case, we have to identify those suppliers, that are
capable of supplying goods or services that match the specific cus-
tomer requirements.
G
Service execution - once a suitable service has been identified
AG
the requirements need to be communicated to the service agent
that can be correctly interpreted and executed. UDDI, WSDL, and
SOAP are the evolving technological standards that allow the in-
PE
M
PI
vocation of remote application logic based on XML syntax.
CE
Customer Edge Router
CE
Following the vision behind the Semantic Web effort [3, 12], the
PI
P
Provider Interconnect
sharing of semantics is crucial to enable the WWW for applications.
AG
Access Gateway
PE
Provider Edge Router
In order to have agents automatically searching, selecting and exe-
IP LAN
P
Provider Core Router
cuting remote services, representation standards are needed that al-
M
Modem Rack
low the annotation of meaning of a Web service which can then be
G
Internet Gateway
interpreted by agents with the help of ontologies.
3.2
Ontologies
Figure 1.
IP-VPN sketch
In order to define a common language for representing capabilities of
configurable products and services we use a hierarchical approach of
related ontologies [11, 4]. Ontologies are employed to set a seman-
The integrator/reseller company contracts with the customer and
tic framework that enables the semantic description of Web services
determines - according to the geographic location of the different
in the domain of product configuration. Furthermore, we follow the
sites and the qualitative requirements with regards to bandwidth,
proposal of [10] to structure the ontological commitments into three
quality of service or cost limits - the layout of the network service.
hierarchy levels (see Figure 2), namely the generic ontology level,
This configuration task includes the selection of adequate access fa-
the intermediate level and the domain level.
cilities from the customer site to some entry point of a VPN back-
bone, reservation of bandwidth within the backbone, as well as pa-
Generic ontology level - Most modeling languages include some
rameter setting for routing hardware and configuration of additional
kind of meta-model for representing classes and their relationships
services like installation support. Considerable parts of this service
(e.g. the frame ontology of Ontolingua [11], the UML meta-model
package will then be sourced from the specialized solution providers
[24] or the representation elements of ontology languages such as
[7].
OIL or DAML+OIL). Such a meta-model can be interpreted as
a generic level ontology. Example modeling concepts included in
those ontologies are frame, class, relation, association, generaliza-
3
CAWICOMS environment
tion, etc.
In the given application scenario, problem solving capabilities are
Intermediate ontology level - the basic modeling concepts formu-
distributed over several business entities that need to cooperate on a
lated on the generic ontology level can be refined and used in or-
customer request for joint service provision. This Peer-to-Peer (P2P)
der to construct an intermediate ontology which includes wide-
interaction approach among a dynamic set of participants without
spread modeling concepts used in the domain. Such an ontology
a clear assignment of client and server roles asks for applying the
for the configuration domain is discussed in [26] who introduce
paradigm of Web services [17]. It stands for encapsulated application
component types, function types, port types, resources and dif-
logic that is open to accept requests from any peer over the Web.
ferent kinds of constraints as basic configuration domain specific
modeling concepts.
Domain ontology level - finally, using the modeling concepts of
3.1
Web services
the intermediate level, we are able to construct application do-
Basically, a Web Service can be defined as an interface that describes
main specific ontologies (e.g. network services), which can also
a collection of provided operations. In the following we interpret the
be denoted as a configuration models.
application logic that configures a product as a standardized Web
service. It can be utilized by interface agents interacting with human
Note, that similar approaches to structure ontologies are already im-
users in a Web shop as well as by agents that outsource configuration
plemented in a set of ontology construction environments (e.g. [11]).
services as part of their problem solving capabilities. When imple-
Our contribution in this context is to illustrate their application for
menting a Web Service the following issues need to be addressed
integrating configuration systems.
[17]:
3.3
Interaction scenario
Service publishing - the provider of a service publishes the de-
scription of the service to a service registry which in our case are
In the following we sketch our Web service scenario that focuses on
configuration agents with mediating capabilities. Within this reg-
enabling automated procurement processes for customisable items
istry the basic properties of the offered configuration service have
(see Figure 2). Basically there exist two different types of agents,
83
those that only offer configuration services (L) and those that act
as suppliers as well as requestors for these services (I). The deno-
tation of agent types derives from viewing the informational supply
chain of product configuration as a tree5, where a configuration sys-
tem constitutes either an inner node (I) or a leaf node (L). Agents of 4
Multi-layer Ontology Definition
type I have therefore the mediating functionality incorporated, that As sketched in Figure 2 the semantic descriptions of the offered con-
allows the offering agents to advertise their configuration services. figuration services are based on the three layer approach of [10]. The
Matchmaking for service identification is performed by the mediat- creation of service profiles for each involved configuration system
ing capability that is internal to each configurator at an inner node. is supported by a set of knowledge acquisition tools, that allow the
It is done on the semantic level that is eased by multi-layered on- definition of the product structure with a graphical UML-based no-
tological commitments (as discussed in the preceding subsection) tation with precise semantics [5]. Using translators these implemen-
among participants. It is assumed that suppliers share application tation independent models are translated into proprietary knowledge
domain ontologies that allow them to describe the capabilities of bases of problem solving engines such as the Java-based JConfigu-
their offered products and services on the semantic level. An ap- rator from ILOG7 [14].
proach that abstracts from syntactical specifics and proposes a rea- However, in the following we will describe our approach employ-
soning on the semantic level also exists for transforming standard- ing DAML+OIL as a language for the Semantic Web with precise
ized catalog representations in [8]. Abstract service descriptions can model theoretic semantics. The correspondence between represen-
be interpreted as physical sub-structures of the product or as a kind tation concepts needed for modeling configuration knowledge bases
of standardized functional description of the product6. Furthermore, and DAML+OIL is shown in [6]. The uppermost layer of our ontol-
agents in the role of customers (service requestors) can impose re- ogy is the generic ontology level. At this level the basic represen-
quirements on a desired product; these requirements can be matched tation concepts and ontological modeling primitives are introduced.
These are inherent to the concepts of the modeling language such
against the functional product description provided by the suppliers as class and slot definitions in OIL. Therefore, it meets the expec-
(service providers). If one or more supplier descriptions match with tations towards the uppermost layer and in the following subsection
the imposed requirements, the corresponding configuration service we move on to show which configuration domain specific modeling
providers can be contacted in order to finally check the feasibility of primitives are to be provided on the intermediate ontology level. For
the requirements and generate a customized product/service solution. reasons of readability OIL text [1] is used for representation, i.e. no
RDFS-based representation of DAML+OIL is used.
<<ComponentType>>
Features
<<ComponentType>>
basicSystem : enum{"G9","G19","G29"}
TeCOM
ipVoice : Boolean
analog_subscribers : 1..1000
xPressions : Boolean
4.1
Basic Configuration Ontology
digital_subscribers : 1..1000
monitoringSW : Boolean
ISDN_subscribers : 1..1000
<<ComponentType>>
support : Boolean
1..1
Features
1..1
trunk_lines : 1..10
<<ComponentType>>
additionalServerPC : Boolean
<<ComponentType>>
<<ComponentType>>
max_load_peaks : 1..1000
Features
basicSystem : enum{"G9","G19","G29"}
TeCOM
manual : Boolean
TeCOM
<<ComponentType>>
ipVoice : Boolean
end_user_devices : 1..3000
ioInterface : Boolean
analog_subscribers : 1..1000
basicSystem : enum{"G9","G19","G29"}
analog_subscribers : 1..1000
Manual
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
xPressions : Boolean
switchingSW : Boolean
ipVoice : Boolean
digital_subscribers : 1..1000
digital_subscribers : 1..1000
numberOfManuals : 0..1000
version : enum{"2.0","3.0"}
monitoringSW : Boolean
rackCapacity : 1..5
xPressions : Boolean
ISDN_subscribers : 1..1000
ISDN_subscribers : 1..1000
support : Boolean
currency : enum{"EURO","USD"}
1..1
version : enum{"2.0","3.0"}
1..1
trunk_lines : 1..10
monitoringSW : Boolean
trunk_lines : 1..10
1..1
0..1
additionalServerPC : Boolean
0..1
max_load_peaks : 1..1000
support : Boolean
semantic
max_load_peaks : 1..1000
manual : Boolean
end_user_devices : 1..3000
end_user_devices : 1..3000
additionalServerPC : Boolean
<<ComponentType>>
ioInterface : Boolean
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
manual : Boolean
Manual
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
<<ComponentType>>
switchingSW : Boolean
version : enum{"2.0","3.0"}
ioInterface : Boolean
Manual
version : enum{"2.0","3.0"}
0..1
<<ComponentType>>
rackCapacity : 1..5
0..1
numberOfManuals : 0..1000
currency : enum{"EURO","USD"}
switchingSW : Boolean
currency : enum{"EURO","USD"}
IPVoice
0..1
version : enum{"2.0","3.0"}
numberOfManuals : 0..1000
rackCapacity : 1..5
0..1
0..1
version : enum{"2.0","3.0"}
version : enum{"1.0","2.0"}
max_users : 10..1000
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
0..1
<<ComponentType>>
<<ComponentType>>
0..1
0..1
IPVoice
0..1
<<ComponentType>>
EnglishManual
0..1
<<ComponentType>>
0..1
<<ComponentType>>
0..1
IPVoice
version : enum{"2.0"}
IPVServerPC
version : enum{"1.0","2.0"}
XPressions
version : enum{"1.0","2.0"}
max_users : 10..1000
keyboard : Boolean
version : enum{"2.0","3.0"}
max_users : 10..1000
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
monitor : Boolean
<<ComponentType>>
0..1
<<ComponentType>>
max_users : 10..1000
0..1
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
GermanManual
0..1
EnglishManual
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
<<ComponentType>>
<<ComponentType>>
XPressions
service
version : enum{"3.0"}
version : enum{"2.0"}
0..1
0..1
<<ComponentType>>
IPVServerPC
<<ComponentType>>
0..1
0..1
0..1
EnglishManual
Support
version : enum{"2.0","3.0"}
<<ComponentType>>
keyboard : Boolean
<<ComponentType>>
<<ComponentType>>
XPressions
max_users : 10..1000
IPVServerPC
monitor : Boolean
version : enum{"2.0"}
service : enum{"phone","remote","local","premium"}
GermanManual
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
1..1
1..1
1..1
1..1
version : enum{"2.0","3.0"}
0..1
0..1
keyboard : Boolean
0..1
<<ComponentType>>
version : enum{"3.0"}
max_users : 10..1000
<<ComponentType>>
monitor : Boolean
IPVFeatures
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
<<ComponentType>>
GermanManual
Support
LDAPConnector : Boolean
version : enum{"3.0"}
1..1
<<ComponentType>>
voiceMail : Boolean
<<ComponentType>>
service : enum{"phone","remote","local","premium"}
1..1
Support
1..1
whiteboard : Boolean
XPFeatures
<<ComponentType>>
service : enum{"phone","remote","local","premium"}
1..1
protocol : enum{"T.120","H.320","H.323"}
1..1
smsPackage : Boolean
IPVFeatures
1..1
0..1
0..1
conferenceFunction : Boolean
smsBox : Boolean
LDAPConnector : Boolean
gatewayH320toH323 : Boolean
<<ComponentType>>
faxOnDemand : Boolean
<<ComponentType>>
<<ComponentType>>
voiceMail : Boolean
pc2PhoneConn : Boolean
IPVFeatures
XPServerPC
text2Speech : Boolean whiteboard : Boolean
XPFeatures
A general ontology for the configuration domain is important in or-
startPackage : enum{"standard","deluxe","comfort"}
0..1
LDAPConnector : Boolean
<<ComponentType>>
faxMail : Boolean
performanceLevel : 1..3
protocol : enum{"T.120","H.320","H.323"}
smsPackage : Boolean
manual : Boolean
XPFeatures
isdnServices : Boolean
winNtServer : enum{"NT4.0","NT5.0"}
voiceMail : Boolean
descriptions
conferenceFunction : Boolean
smsBox : Boolean
<<ComponentType>>
whiteboard : Boolean
unifiedMessaging : Boolean
gatewayH320toH323 : Boolean
keyboard : Boolean
smsPackage : Boolean
faxOnDemand : Boolean
XPServerPC
protocol : enum{"T.120","H.320","H.323"}
voiceMail : Boolean
smsBox : Boolean
pc2PhoneConn : Boolean
monitor : Boolean
text2Speech : Boolean
performanceLevel : 1..3
0..1
conferenceFunction : Boolean
faxOnDemand : Boolean
0..1
startPackage : enum{"XPStartUp1","XPStartUp2","XPStartUp3"}
startPackage : enum{"standard","deluxe","comfort"}
faxMail : Boolean
winNtServer : enum{"NT4.0","NT5.0"}
gatewayH320toH323 : Boolean
text2Speech : Boolean
<<ComponentType>>
manual : Boolean
manual : Boolean
isdnServices : Boolean
keyboard : Boolean
XPServerPC
pc2PhoneConn : Boolean
faxMail : Boolean
unifiedMessaging : Boolean
monitor : Boolean
startPackage : enum{"standard","deluxe","comfort"}
isdnServices : Boolean
performanceLevel : 1..3
voiceMail : Boolean
manual : Boolean
unifiedMessaging : Boolean
winNtServer : enum{"NT4.0","NT5.0"}
startPackage : enum{"XPStartUp1","XPStartUp2","XPStartUp3"}
voiceMail : Boolean
keyboard : Boolean
manual : Boolean
startPackage : enum{"XPStartUp1","XPStartUp2","XPStartUp3"}
monitor : Boolean
manual : Boolean
der to allow easy configuration knowledge reuse and the integration
advertises
of complex configurable products within marketplace environments.
advertises
I
The ontologies proposed by [26] and [5] serve as a basis for the con-
advertises
L
struction of application domain specific ontologies which allow the
description of configuration services on a semantic level. Refined
L
concepts of classes such as component types, resource types, port
I
types, or function types are the basic modeling concepts useful for
<<ComponentType>>
Features
<<ComponentType>>
TeCOM
basicSystem : enum{"G9","G19","G29"}
ipVoice : Boolean
analog_subscribers : 1..1000
xPressions : Boolean
digital_subscribers : 1..1000
monitoringSW : Boolean
ISDN_subscribers : 1..1000
advertises
1..1
1..1
support : Boolean
trunk_lines : 1..10
additionalServerPC : Boolean
max_load_peaks : 1..1000
manual : Boolean
L
<<ComponentType>>
end_user_devices : 1..3000
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
ioInterface : Boolean
Manual
version : enum{"2.0","3.0"}
switchingSW : Boolean
numberOfManuals : 0..1000
currency : enum{"EURO","USD"}
rackCapacity : 1..5
version : enum{"2.0","3.0"}
0..1
0..1
0..1
0..1
<<ComponentType>>
IPVoice
building the basic product structure. The ontology defined in [26]
version : enum{"1.0","2.0"}
max_users : 10..1000
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
<<ComponentType>>
0..1
0..1
EnglishManual
<<ComponentType>>
<<ComponentType>>
0..1
0..1
version : enum{"2.0"}
XPressions
IPVServerPC
version : enum{"2.0","3.0"}
keyboard : Boolean
<<ComponentType>>
max_users : 10..1000
monitor : Boolean
GermanManual
0..1
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
0..1
version : enum{"3.0"}
<<ComponentType>>
Support
1..1
1..1
service : enum{"phone","remote","local","premium"}
1..1
<<ComponentType>>
1..1
Features
<<ComponentType>>
basicSystem : enum{"G9","G19","G29"}
<<ComponentType>>
IPVFeatures
TeCOM
ipVoice : Boolean
LDAPConnector : Boolean
xPressions : Boolean
analog_subscribers : 1..1000
<<ComponentType>>
voiceMail : Boolean
monitoringSW : Boolean
XPFeatures
digital_subscribers : 1..1000
advertises
whiteboard : Boolean
support : Boolean
ISDN_subscribers : 1..1000
is based on the frame ontology of Ontolingua [11] and represents a
smsPackage : Boolean
0..1
protocol : enum{"T.120","H.320","H.323"}
additionalServerPC : Boolean
trunk_lines : 1..10
1..1
1..1
smsBox : Boolean
conferenceFunction : Boolean
manual : Boolean
<<ComponentType>>
max_load_peaks : 1..1000
faxOnDemand : Boolean
gatewayH320toH323 : Boolean
ioInterface : Boolean
XPServerPC
<<ComponentType>>
end_user_devices : 1..3000
text2Speech : Boolean
Manual pc2PhoneConn : Boolean
switchingSW : Boolean
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
faxMail : Boolean
performanceLevel : 1..3
startPackage : enum{"standard","deluxe","comfort"}
rackCapacity : 1..5
numberOfManuals : 0..1000
version : enum{"2.0","3.0"}
isdnServices : Boolean
winNtServer : enum{"NT4.0","NT5.0"}
manual : Boolean
version : enum{"2.0","3.0"}
currency : enum{"EURO","USD"}
unifiedMessaging : Boolean
keyboard : Boolean
0..1
0..1
voiceMail : Boolean
monitor : Boolean
startPackage : enum{"XPStartUp1","XPStartUp2","XPStartUp3"}
manual : Boolean
<<ComponentType>>
0..1
IPVoice
0..1
version : enum{"1.0","2.0"}
max_users : 10..1000
<<ComponentType>>
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
EnglishManual
<<ComponentType>>
version : enum{"2.0"}
IPVServerPC
0..1
0..1
0..1
0..1
<<ComponentType>>
keyboard : Boolean
<<ComponentType>>
GermanManual
monitor : Boolean
XPressions
synthesis of resource-based, function- based, connection-based, and
version : enum{"3.0"}
version : enum{"2.0","3.0"}
0..1
0..1
max_users : 10..1000
country : enum{"AUT","GB","FRA","USA","GER","ITA"}
<<ComponentType>>
Support
service : enum{"phone","remote","local","premium"}
1..1
<<ComponentType>>
1..1
IPVFeatures
1..1
1..1
Legend:
LDAPConnector : Boolean
voiceMail : Boolean
whiteboard : Boolean
protocol : enum{"T.120","H.320","H.323"}
<<ComponentType>>
XPFeatures
conferenceFunction : Boolean
gatewayH320toH323 : Boolean
smsPackage : Boolean
pc2PhoneConn : Boolean
smsBox : Boolean
0..1
0..1
startPackage : enum{"standard","deluxe","comfort"}
faxOnDemand : Boolean
<<ComponentType>>
manual : Boolean
text2Speech : Boolean
XPServerPC
semantic
faxMail : Boolean
performanceLevel : 1..3
isdnServices : Boolean
winNtServer : enum{"NT4.0","NT5.0"}
unifiedMessaging : Boolean
keyboard : Boolean
voiceMail : Boolean
monitor : Boolean
structure-based approaches for representing configuration problems.
startPackage : enum{"XPStartUp1","XPStartUp2","XPStartUp3"}
manual : Boolean
Configuration Web
service
use
service, including
descriptions
A similar set of concepts is discussed in [5], where the configuration
mediating capability
ontology is represented as a UML profile with additional first or-
Domain
I
der formalizations guaranteeing a precise semantics for the provided
ontology level
Basic configuration
modeling concepts.
Web service
L
Intermediate ontology level
4.2
Product Domain Ontology for Network
Generic ontology level
Services
While the intermediate configuration ontology contains only the ba-
sic concepts for modeling product structures, it allows the construc-
tion of more specialized ontologies for specific application domains.
Figure 2.
Web service scenario
Furthermore, axioms and slot constraints provided in OIL can be
employed to formulate constraints on the configuration model. Ex-
actly these concepts will be refined in the following for representing
(application) domain specific ontologies that can be interpreted as
a kind of physical or functional product description [18], which is
Note, that only the required configuration services are organized in a tree
used as a basic framework for formulating capabilities of suppliers
structure, which must not hold for the involved companies in the value chain
of a product.
and requirements of customers. Figure 3 represents fragments of an
ˇ
In [18] this kind of description is denoted as a functional architecture of the
˘
configured product.
See http://www.ilog.com for reference.
84
ontology for defining configuration services for IP-based Virtual Pri-
5
Web service scenario
vate Networks (IP-VPN)8. For our example we will concentrate on
The interaction between service providing agents can be differenti-
ated into the three areas service publishing, identification and exe-
begin -ontology
ontology -container
cution. As depicted in the scenario in Figure 2, only those agents
title Product Domain Ontology
can request a service that have the mediating capabilities to receive
description IP -based Virtual Private Networks
service advertisements and perform service identification.
language "OIL"
ontology -definitions
slot -def protocol
subslot -of
5.1
Service publishing
HasPart //defined in Configuration Ontology
class -def AccessProtocol
sub class -of
Now we will show how the ontologies defined in Section 4 are used
Function //defined in Configuration Ontology
to semantically describe the offered configuration services. Semantic
class -def RouterAccess
description of the demanded services allows us to implement efficient
subclass -of
AccessProtocol
matchmaking between supply and demand. Within these semantic
class -def ModemAccess
annotations, restrictions on the domain and cardinality of slots, con-
subclass -of
AccessProtocol
straints on connections and structure, as well as the possible types
class -def InternetAccess
of classes are possible. Furthermore, offered component instances
subclass -of
AccessProtocol
can be represented as subconcepts (e.g. read from a catalog) of the
class -def defined Country
classes of the service domain-specific configuration ontology. Addi-
cla ss -def defined Town
tional supplier-specific constraints are introduced. Consequently, for
slot -constraint town_of cardinality 1 Country
the semantic description of the capability of a configuration service
class -def LineService
subclass -of
of a specific supplier the product domain ontology level provides the
Function //defined in Configuration Ontology
slot -constraint bandwidth cardinality 1 integer
necessary base concepts that can be further refined. Figure 4 contains
slot -constraint latency cardinality 1 integer
the semantic definition of the AccessLine services that are offered by
slot -constraint identifier has -value integer
class -def BackBoneSection
the fictitious telecommunication service providers BTT and Luton.
subclass -of
BTT serves customers located in the UK and Ireland (constraint on
LineService
slot -constraint access_from has -value AccessLine
the slot pop) and can provide access to BackBoneSections 1 through
10 with a maximum bandwidth of 2000. In contrast Luton offers con-
class -def defined AccessLine
subclass -of
nections from towns in France and the UK. Only modem or inter-
LineService
slot -constraint protocol cardinality 1 AccessProt ocol
net are offered protocol choices, a lower bandwidth is supported and
slot -constraint access_to cardinality 1 BackBoneSection
fewer BackBoneSections are accessible. For tailoring the application
slot -constraint pop cardinality 1 Town
instance -of UK Country
class -def defined BTT_AccessLine
instance -of Manchester Town
subclass -of
related town_of Manchester UK
AccessLine
end -ontology
slot-constraint access_to value-type
((slot -constraint identifier value -type (min 1)) and
(slot -constraint identifier value -type (max 10)))
slot -constraint pop value -type ((slot -const raint town_of value -type (one -of UK))
or (slot -constraint town_of value -type (one -of Ireland )))
slot -constraint bandwidth value -type (max 2000 )
class -def defined Luton_AccessLine
Figure 3.
Domain ontology for IP-VPN services
subclass -of
AccessLine
slot -constraint pop value -type ((slot -constraint town_of value -type (one -of France ))
or (slot -constraint town_of value -type (one -of UK)))
slot -constraint access_to value -type
((slot -constraint identifier value -type (min 5)) and
(slot -constraint identifier value -type (max 8)))
sl ot-constraint bandwidth value -type (max 1200 )
the provision of AccessLines that connect a customer location (slot
slot -constraint protocol has -value ( ModemAccess or InternetAccess )
pop - 'point of presence') to a BackBoneSection. The chosen pro-
tocol (a refinement of the HasPart decomposition relationship in the
configuration domain) can be either performed via a router, via a mo-
Figure 4.
Semantic description of offered services
dem or via an internet connection to some access gateway (Router-
Access, ModemAccess and InternetAccess are therefore specialized
AccessProtocols). In addition, an AccessLine is characterized by a
bandwidth and latency property that it inherits from its superclass
domain specific configuration ontology to supplier-specific circum-
LineService, which is in turn a refinement of the Function concept
stances tool support for acquisition and maintenance of configuration
(abstract characteristic of a product or service) from the basic con-
models is needed. Within the CAWICOMS project a Knowledge Ac-
figuration ontology (intermediate ontology level). The instances con-
quisition Workbench is developed that provides the required tools for
tained in the ontology shown in Figure 3 can be interpreted as basic
designing the service descriptions with a graphical UML-based nota-
catalog entries representing common knowledge (e.g., British towns
tion. The generic and the intermediate ontology level as described in
or zip codes), which are assigned to base classes of the application
Section 4 are inherent to the modeling primitives offered by the tool
domain ontology (in this case Manchester is provided as basic in-
suite and therefore static in our approach. The tool environment sup-
stance of the class Town).
ports human experts in defining and maintaining the application do-
main specific ontological descriptions as well as in integrating them.
The complete example ontology in DAML+OIL can be downloaded from
The advertisement of the offered configuration services of different
http://www.cawicoms.org/ontology/ipvpn.rdfs.
suppliers is therefore part of an offline setup process. The functional
85
descriptions of the configurable products and services are commu-
nicated to all Web configurators that may act as customers for their
class-def defined Required_AccessLine_1
subclass-of
configuration service and integrated into their domain ontologies by
AccessLine
the human experts.
slot-constraint pop value-type ((one-of Manchester) or (one-of Munich))
5.2
Service Identification
Having described service publication, we will now focus on the
identification of relevant Web service providers for a concrete
Figure 6.
Modified service requirement
demand. This task has similarities with the surgical or parametric
search problem [16], e.g. "a laptop with at least 20GB hard-disk,
800MHz Pentium III processor or better, manufactured either by
ˇ
and
.
$#
Dell or Compaq and costing less than 2000 USD". However, for
the configuration domain we require even more enhanced search
ˇ%
Definition (appropriate service):
A service
is an appro-
capabilities for identifying the appropriate supply. The reason is,
ˇ'&
priate service for
, iff
are consistent.
that requirements cannot only be expressed as simple restrictions
on product attributes, but also as constraints on the structure. The
Note, that this definition diverges from the approaches taken
following example is based on the product domain ontology (Figure
for matchmaking among heterogenous agents [27] or for Web
3), requestors are enabled to semantically describe the requested
service identification [17]. For a detailed elaboration on the rela-
service as can be seen in Figure 5. Let us assume that we search
tionship between description logic and configuration knowledge
for an AccessLine provider that connects us from Manchester via
representation see [6].
InternetAccess protocol to BackBoneSection '3' with a bandwidth
As already mentioned in the previous subsection, the configuration
of 1200. Here the bandwidth slot-constraint is a simple attribute
service models are defined within a knowledge acquisition environ-
restriction, but the constraint on the slot access to navigates to the
ment and automatically translated into the proprietary knowledge
related class BackBoneSection and restricts the structure. For this
representation formalism of a configuration agent. In our imple-
mentation this matchmaking task is therefore performed as part of
class -def defined Required_AccessLine
the search process for a configuration solution of a constraint-based
subclass -of
AccessLine
configurator engine. For the internal representation of the advertised
slot -constraint bandwidth value -type (equal 1200 )
service models as well as the service requests an object-oriented
slot -constraint pop value -type (one -of Manchester )
slot -constraint protocol value -type InternetAccess
framework for constraint variables is employed [14]. Reasoning
slot -constraint access_to has -value
(slot -constraint identifier has -value (equal 3))
on service requirements as well as on service decomposition is
performed by the underlying Java-based constraint solver. The
formulation of service requests and their replies is enabled by a
Figure 5.
Semantic description of required service
WebConnector component that owns an object model layer that
accesses the internal constraint representation of the constraint en-
gine. This object model layer represents the advertised configuration
service descriptions. A service requestor agent imposes its service
example we can intuitively determine that BTT is an appropriate
request via an edit-query onto the object-model layer and retrieves
supplier for the requested service, as the Required AccessLine
the configuration service result via a publish-query.
qualifies as a subclass to BTT AccessLine. However, for the general
As will be also pointed out in the next subsection, the creation
case identification of subsumption relationships between offered
of standards for the definition of semantics of Web services will
and required concepts is too restrictive. Consider the case where we
allow application independent mediating agents to accept service
would need this AccessLine either from Manchester or from Munich.
advertisements and to perform the service identification task, which
Assuming all other restrictions remain unchanged, the modified
is not the case in the current situation.
constraint on the slot pop is given in Figure 69. Although BTT still
provides an appropriate service, the constraint relaxation makes the
subsumption of Required AccessLine by BTT AccessLine impossi-
5.3
Service Execution
ble. So formally a description logic definition of the matchmaking
Requests for service execution must conform to an XML-based com-
task for identification of an appropriate configuration service can be
munication protocol (WebConnector protocol) developed for the con-
defined as follows.
figuration domain in accordance with the SOAP messaging standard.
This protocol defines
Given:
A consistent description logic theory
that represents
the three ontological layers of our marketplace, a set of concepts
a fixed set of methods with defined semantics for the configuration
ˇŁ˘Ą¤¦ˇ
ˇ
ˇ
¨§©©©§
that describe supply from
different suppliers
domain, like creating components, setting values for parameters,
(i.e., service providers), and a set of concepts
representing the
initiation of the search process, or retrieving results,
requested service.
a mechanism to exchange complex data structures like configu-
ration results and a language for expressing navigation expres-
Task:
Identify the set of concepts
, that contains all con-
sions within these data structures (compare to XML-Schema and
ˇ
ˇ!
ˇ
cepts
with
, where
is an appropriate service for
XPath), and
"
Note, that the inherited cardinality constraint restricts slot pop to exactly
extensibility mechanisms for special domains and support for a
one Town, which gives this constraint an exclusive or semantics.
session concept in HTTP-based transactions.
86
This way the semantics of the process model of the configuration
The STEP standard [13] takes into account all aspects of a product
Web service is defined by a proprietary protocol. This assumption
including geometry and organisational data [19]. The idea of STEP is
works for our specific requirement of realizing collaborative config-
to provide means for defining application specific concepts for mod-
uration systems, but is only half way towards the vision of Web ser-
eling products in a particular application domain. These application
vices in the Semantic Web. Therefore, markup languages are required
specific concepts are standardised into parts of STEP called Applica-
that enable a standardized representation of service profiles for adver-
tion Protocols which are defined using the EXPRESS data definition
tisement of services as well as definitions of the process model. This
language (Application Protocols are EXPRESS schemas). EXPRESS
way, the task of identifying appropriate services and the decompo-
itself includes a set of modeling concepts useful for representing con-
sition of a service request into several separate requests can be per-
figurable products, however the language can not be used to define
formed by domain independent mediators. Due to the lack of these
an enterprise specific configuration model without leaving the STEP
standards, this mediating functionality is in our case performed by
standard. Similarities to our approach can be seen in the role of ap-
application logic integrated into the configuration systems. DAML-
plication protocols in STEP which are very similar to the domain
S10 is an example for an effort underway that aims at providing such
ontology level discussed in this paper.
a standardized semantic markup for Web services that builds on top
of DAML+OIL.
7
Conclusions
6
Related Work
The Semantic Web [3] is the vision of developing enabling technolo-
Beside standards for representing product catalogs [8], there exists a
gies for the Web which supports access to its resources not only to
number of approaches for standardizing electronic commerce com-
humans but as well to applications often denoted as agent-based sys-
munication (e.g. Commerce XML - cXML or Common Business Li-
tems providing services such as information brokering, information
brary - CBL) - these are XML-based communication standards for
filtering, intelligent search or synthesis of services [20]. This paper
B2B applications11, which also include basic mechanisms for prod-
describes an application scenario for semantic Web services in the
uct data interchange and can be interpreted as ontologies supporting
domain of configuring telecommunication services. It demonstrates
standardized communication between e-Business applications. How-
how to apply Semantic Web technologies in order to support the inte-
ever, these standards are restricted to the representation of standard-
gration of configurable products and services in an environment for
ized products, i.e. the basic properties of complex products, espe-
distributed problem solving. DAML+OIL-based configuration ser-
cially configurable products are not considered. Basic mechanisms
vice descriptions can be used in order to match them with given cus-
for product data integration are already supported by a number of
tomer requirements and the matchmaking task to determine the ade-
state-of-the-art B2B applications. However, the integration of con-
quacy of a service is defined. DAML+OIL formalisms are well suited
figuration systems into electronic marketplace environments is still
for representing the component structure of configurable products,
an open issue, i.e. not supported by todays systems. Problem Solving
i.e. part-of associations and simple associations between component
Methods (PSMs) [2] support the decomposition of reasoning tasks of
types and corresponding basic constraints. However, technologies
knowledge-based systems into sets of subtasks and inference actions
supporting the vision of the Semantic Web are still under develop-
that are interconnected by knowledge roles. The goal of the IBROW
ment. In order to support a full scenario of distributed configuration
project [20] is the semiautomatic reuse of available problem solving
Web services, languages like DAML+OIL have to be extended with
methods, where a software broker supports the knowledge engineer
language elements supporting the formulation of service advertise-
in configuring a reasoning system by combining different PSMs. A
ments as well as process definitions for the interaction.
similarity to the work of [20] exists in the sense that the selection of
suppliers (and corresponding configuration systems) is a basic con-
figuration task, where configurators must be selected which are ca-
REFERENCES
pable of cooperatively solving a distributed configuration task. The
[1] S. Bechhofer, I. Horrocks, C. Goble, and R. Stevens, `OilEd: A Reason-
approach is different in the sense that the major focus is on providing
able Ontology Editor for the Semantic Web', in Proceedings of Joint
an environment which generally supports a semi-automated reuse of
Austrian/German Conference on Artificial Intelligence (KI), pp. 396
problem solving methods, whereas our approach concentrates on the
408, Vienna, Austria, (2001).
automated integration of configuration services in an e-business en-
[2] R. Benjamins and D. Fensel, `', Special issue on problem-solving meth-
ods of the International Journal of Human-Computer Studies, 49(4),
vironment. The Infomaster system [15] provides basic mechanisms
(1998).
for integrating heterogeneous information sources in order to provide
[3] T. Berners-Lee, Weaving the Web, Harper Business, 2000.
a unique entry point for the users of the system. Compared to our ap-
[4] B. Chandrasekaran, J. Josephson, and R. Benjamins, `What Are On-
proach there is no support for the integration of configurable products
tologies, and Why do we Need Them?', IEEE Intelligent Systems, 14,1,
and the underlying configuration systems. The design of large scale
2026, (1999).
[5] A. Felfernig, G. Friedrich, and D. Jannach, `UML as domain specific
products requires the cooperation of a number of different experts. In
language for the construction of knowledge-based configuration sys-
the SHADE (Shared Dependency Engineering) project [22] a KIF-
tems', International Journal of Software Engineering and Knowledge
based representation [21] was used for representing engineering on-
Engineering (IJSEKE), 10(4), 449469, (2000).
tologies. This approach differs from the approach presented in this
[6] A. Felfernig, G. Friedrich, D. Jannach, M. Stumptner, and M. Zanker,
`A Joint Foundation for Configuration in the Semantic Web', In Pro-
paper in the sense that the provided ontology is majorly employed as
ceedings of the Workshop on Configuration, in conjunction with the
a basis for the communication between the different engaged agents,
Ł˘Ą¤§¦
European Conference on Artificial Intelligence (ECAI-2002),
but is not used as a means for describing the capabilities of agents.
(2002).
[7] A. Felfernig, G. Friedrich, D. Jannach, and M. Zanker, `Web-based con-
ˇ
ˇ
See http://www.daml.org/services for reference.
figuration of Virtual Private Networks with Multiple Suppliers', in Pro-
ˇ
ˇ
An overview on existing e-Commerce frameworks for business to business
ceedings of the ¤©¦ International Conference on Artificial Intelligence
¨
communication can be found in [25].
in Design (AID), Cambridge, UK, (2002).
87
[8] D. Fensel, Y. Ding, B. Omelayenko, E. Schulten, G. Botquin,
M. Brown, and A. Flett, `Product Data Integration in B2B E-
Commerce', IEEE Intelligent Systems, 16(4), 5459, (2001).
[9] D. Fensel, F. vanHarmelen, I. Horrocks, D. McGuinness, and P.F. Patel-
Schneider, `OIL: An Ontology Infrastructure for the Semantic Web',
IEEE Intelligent Systems, 16(2), 3845, (2001).
[10] A. Gangemi, D. M. Pisanelli, and G. Steve, `An Overview of the
ONIONS Project: Applying Ontologies to the Integration of Medical
Terminologies', Data and Knowledge Engineering, 31(2), 183220,
(1999).
[11] T. Gruber, `A translation approach to portable ontology specifications',
Knowledge Acquisition, 5, 199220, (1993).
[12] J. Hendler, `Agents and the Semantic Web', IEEE Intelligent Systems,
16(2), 3037, (2001).
[13] ISO, `ISO Standard 10303-1: Industrial automation systems and inte-
gration - Product data representation and exchange - Part 1: Overview
and fundamental principles', (1994).
[14] U. Junker, `Preference-programming for Configuration', in Proceed-
ings of IJCAI, Configuration Workshop, Seattle, (2001).
[15] A. M. Keller and M. R. Genesereth, `Multivendor Catalogs: Smart Cat-
alogs and Virtual Catalogs', The Journal of Electronic Commerce, 9(3),
(1996).
[16] D.L. McGuinness, `Ontologies and Online Commerce', IEEE Intelli-
gent Systems, 16(2), 910, (2001).
[17] Sh. McIlraith, T.C. Son, and H. Zeng, `Mobilizing the Semantic Web
with DAML-Enabled Web Services', in Proceedings of the IJCAI 2001
Workshop on E-Business and the Intelligent Web, pp. 2939, Seattle,
WA, (2001).
[18] S. Mittal and F. Frayman, `Towards a Generic Model of Configuration
Tasks', in Proceedings ¤§¦ International Joint Conf. on Artificial In-
telligence, pp. 13951401, Detroit, MI, (1989).
[19] T. Mnnist, A. Martio, and R. Sulonen, `Modelling generic prod-
uct structures in STEP', Computer-Aided Design, 30,14, 11111118,
(1999).
[20] E. Motta, D. Fensel, M. Gaspari, and V.R. Benjamins, `Specifications
of Knowledge Components for Reuse', in Proceedings of ¤©¦ Interna-
tional Conference on Software Engineering and Knowledge Engineer-
ing, pp. 3643, Kaiserslautern, Germany, (1999).
[21] R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator, and
W. Swartout, `Enabling technology for knowledge sharing', AI Mag-
azine, 12,3, 3656, (1991).
[22] G.R. Olsen, M. Cutkosky, J.M. Tenenbaum, and T.R. Gruber, `Collabo-
rative Engineering based on Knowledge Sharing Agreements', in Pro-
ceedings of the ACME Database Symposium, pp. 1114, Minneapolis,
MN, USA, (1994).
[23] B.J. PineII, B. Victor, and A.C. Boynton, `Making Mass Customization
Work', Harvard Business Review, Sep./Oct. 1993, 109119, (1993).
[24] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Lan-
guage Reference Manual, Addison-Wesley, 1998.
[25] S.S.Y. Shim, V.S. Pendyala, M. Sundaram, and J.Z. Gao, `E-Commerce
Frameworks', IEEE Computer, Oct. 2000, 4047, (2000).
[26] T. Soininen, J. Tiihonen, T. Mnnist, and R. Sulonen, `Towards a General
Ontology of Configuration', AI Engineering Design Analysis and Man-
ufacturing Journal, Special Issue: Configuration Design, 12(4), 357
372, (1998).
[27] K. Sycara, M. Klusch, and S. Widoff, `Dynamic Service Matchmak-
ing among Agents in Open Information Environments', ACM SIGMOD
Record, Special Issue on Semantic Interoperability in Global Informa-
tion Systems, (1999).
88
A Joint Foundation for Configuration
in the Semantic Web
ˇ
Alexander Felfernig , Gerhard Friedrich , Dietmar Jannach , Markus Stumptner , and Markus Zanker
Abstract.
Product configuration is a major commercial applica-
lems, the first approach is based on predicate logic or various simpli-
tion of knowledge-based systems, and joint configuration by multiple
fied variants thereof, specifically constraint-based systems (including
business partners is becoming a key application in today's highly spe-
their dynamic and generative variants, e.g., [10, 13, 14]) and resource
cialized economy. The required integration of configuration knowl-
balancing methods (e.g., [12]). The second approach uses description
edge is a challenging task due to the variety of knowledge represen-
logics as knowledge representation and reasoning mechanism (e.g.,
tation formalisms used in commercial configurators. Ontology lan-
[19]). Clearly, an integration of these approaches is a major milestone
guages such as DAML+OIL provide an infrastructure for the Seman-
for configurator integration.
tic Web with the goal of intelligent information integration. The aim
A solution for the exchange of knowledge is the provision of
of this paper is to show the applicability of such languages for build-
a standardized configuration knowledge representation language
ing configuration knowledge bases. We join the two major streams in
which is based on state-of-the-art Web technologies allowing easy
knowledge-based configuration (description logics on one hand and
integration of existing proprietary configuration environments. On-
predicate logic, including constraint-based and resource-balancing
tology representation languages such as OIL [9] or DAML+OIL [18]
techniques on the other) by giving a description logic based defini-
developed in the context of the Semantic Web [4] are well suited for
tion of a configuration task and showing its equivalence with existing
designing and sharing ontologies. These languages are strongly in-
consistency-based definitions. We show that Semantic Web ontology
fluenced by description logics and therefore possess clear declarative
languages can be applied to configuration by formalizing language
semantics, providing one important precondition for the exchange of
elements relevant for building configuration knowledge bases and
knowledge. Nonetheless, their roots in description logics reinforces
discuss extensions needed in order to provide full fledged configu-
the need for the definition of a common view of a configuration task,
ration knowledge representation. The result is a common basis for
so that predicate logic based representations can be mapped to them.
current configuration approaches on the Semantic Web that is neces-
The practical consequence of a commonly accepted problem def-
sary for the provision of joint configuration services.
inition and knowledge semantics in joint provisioning of configura-
tion services is a well defined interface between configurator imple-
mentations. Proprietary configuration systems can be independently
1
Introduction
implemented following different approaches and are still able to in-
teroperate. We only require that cooperating configurators deliver
Knowledge-based configuration has a long history as a successful
valid solutions w.r.t. the common definition of the problem, the solu-
AI application area (e.g., [3, 10, 12, 13, 15, 19]). Starting with rule-
tion, and the semantics of the exchanged knowledge.
based systems such as R1/XCON [3], various higher level represen-
In this paper we give a description logics based definition of a
tation formalisms were developed to exploit the advantages of more
configuration task and show the equivalence of this definition with
concise representation, faster application development, higher main-
a consistency-based definition given in [8] - the major result of this
tainability and more flexible reasoning. Although these representa-
equivalence is that configuration tasks defined in terms of descrip-
tions have proven their applicability in various real world applica-
tion logics and predicate logic can easily be transformed into each
tions, the heterogeneity of configuration knowledge representation
other and consequently be represented in ontology representation
is the major obstacle to incorporating configuration technology in
languages such as DAML+OIL. Using concepts of OIL3, we present
eCommerce environments. The trend towards highly specialized so-
the constituting elements of a configuration knowledge representa-
lution providers results in a situation where different configurators of
tion language by formalizing modeling concepts of de facto stan-
complex products and services must be integrated in order to trans-
dard configuration ontologies [7, 17] employed in industrial appli-
parently support distributed configuration problem solving.
cations4. In addition, we point out extensions needed to apply OIL
For this integration, configurators must have a clear common un-
and DAML+OIL for full fledged configuration knowledge represen-
derstanding of the problem definition and the semantics of the ex-
tation. As a result, we provide a common basis for knowledge rep-
changed knowledge. Consequently, it is necessary to agree on the
resentation in configuration problem solving, thus enhancing the ap-
definition of a configuration problem and its solution. Of the two
plicability of configuration technology to Web-based environments.
current main streams in representing and solving configuration prob-
The rest of the paper is organized as follows. In Section 2 we intro-
˘
Institut für Wirtschaftsinformatik und Anwendungssysteme, Produktion-
¤
sinformatik, Universitätsstrasse 65-67, A-9020 Klagenfurt, Austria, email:
For presentation purposes we employ OIL text - this representation can
{felfernig,friedrich,jannach,zanker}@ifit.uni-klu.ac.at.
easily be transformed into a corresponding DAML+OIL representation.
Ą
Ł
University of South Australia, Advanced Computing Research Centre, 5095
Note that these differ somewhat from the configuration ontology that was
Mawson Lakes (Adelaide), SA, Australia, email: mst@cs.unisa.edu.au.
described for demonstration purposes in [11].
89
duce an example that provides an overview of the modeling concepts
required for building configuration knowledge bases. In Section 3 we
<<Component>>
<<Component>>
0..100
0..100
Computer
0..1
0..1
<<Component>>
give a description logics based definition of a configuration task and
Software
Screen
swcapacity : 1..100
show its equivalence to the consistency-based definition given in [8].
1..6
1..6
1..2
1..2
<<Component>>
<<Component>>
In Section 4 we describe an OIL-based formalization of the modeling
HDUnit
MB
1
1
concepts presented in Section 2 and summarize the results. Section 5
hdcapacity : 25000..30000
<<Component>>
1..2
1..2
closes with conclusions.
Videocard
<<Component>>
CPU
2
2
<<Component>>
2
2
IDEUnit
<<Component>>
clockrate : 300..500
<<Port>>
<<Port>>
MB1
conn
2
Configuration domain specific modeling concepts
hdcapacity : 25000
videoport
screenport
1 0..1
<<Component>>
<<Component>>
<<Component>>
In the following we discuss a set of relevant modeling concepts
SCSIUnit
<<Component>>
CPU1
CPU2
MB2
hdcapacity : 30000
clockrate : 300
clockrate : 500
for building configuration knowledge bases. These concepts are ex-
tracted from the configuration ontologies defined in [7, 17]. Figure
1 shows the simplified structure of a configurable Computer system
which is composed of the following representation concepts.
Figure 1.
Example configuration model
Component types represent the parts, a final product is built of -
they are characterized by attributes (e.g., the component type CPU
is characterized by the attribute clockrate). Component types with a
'0)
description of the configurable product and
specifies the
similar structure are arranged in a generalization hierarchy and rep-
¦324¦
particular system requirements defining an individual configura-
resent choices for the configurable product (e.g., in the final con-
58709A@CB
'0)
tion problem instance.
comprises a set of concepts
figuration an instance of CPU can be either a CPU1 or a CPU2).
5GFIHQPSRUTWVYX`
FIHaPbRUTWV(Xc
and a set of roles
which serve as a
Part-whole relationships can be considered as bill-of-material repre-
2
configuration language for the description of actual configurations
sentations semantically enriched with multiplicities, stating a range
'0)
$&$('0)!f
(solutions). A configuration knowledge base
of how many subparts an aggregate can consist of (e.g., a MB must
dCe
§
'0)
is constituted of sentences in a description language.
contain at least one CPU and at most two CPUs). In addition to the
¦324¦
g
In the following we will define a solution of a configuration prob-
number and types of different components, the product topology may
lem based on the interpretation of concepts and roles. In addition
be important in a final configuration as well, i.e., how the components
58709A@CB4'0)
we require that roles in
are defined over the domains
are interconnected to each other (e.g., which videoport is used in the
T`p
5GFhHQPSRUTiV
FIHaPbRUTWV
given in
, i.e., we add for each
the role
configuration to connect the Videocard with the Screen).
2
2
T
T
©
"
58$(y
y©
"
58$(y
descriptions
and
for
Additionally, a set of constraints specifies allowed combinations
qsrutwvx
2
§
2
§
T
58$(y¨
5
')
to the knowledge base
if such
of component- and attribute settings in the final configuration. Some
§SIIS
dCe
component types cannot be used in the same final configuration (they
descriptions are not subsumed by other descriptions already con-
are incompatible). E.g., we can impose the constraint on the product
tained in the knowledge base.
structure of Figure 1 that a CPU1 is incompatible with a mother-
Example 1: In this example we use a part of our Computer on-
tology (see Figure 1) that comprises CPUs and MBs. On each MB
board MB2. In some cases, the existence of a component of a certain
at least one but at most two CPUs are plugged in (constraint ˘ ). A
type requires the existence of an instance of another specific type.
d
CPU must always be mounted on a MB (constraint Ł ). A CPU of
Regarding the product structure of Figure 1, we can impose the con-
d
type CPU2 must be mounted on a MB of type MB2 (constraint ¤ ).
straint that the existence of a CPU2 requires the existence of a MB2.
d
$&$('0)
The domain description
={
Finally, parts of a configuration problem can be interpreted as a re-
class-def
subclass-of (
or
)
source balancing task, where some of the components are producers
efe
ege&h
efeYi
58jlk
slot-constraint cpu-of-mb min-cardinality 1
and others are consumers. In the final configuration, consumers and
58jlk
slot-constraint cpu-of-mb max-cardinality 2
. [ ˘ ]
producers must be balanced w.r.t. some resource balancing criteria -
d
class-def
subclass-of
.
efemh
efe
e.g., the amount of installed hard-disk capacity is the upper bound
class-def
subclass-of
.
efeni
efe
for the capacity requirements of the installed software. In Section 4
disjoint
.
ege&h6efeni
58jlk
58jlk
58jlk
we will show how to represent these concepts in extended OIL [9].
class-def
subclass-of (
or
)
h
i
slot-constraint mb-of-cpu cardinality 1
. [ Ł ]
ege
d
58jlk
58jlk
class-def
subclass-of
.
h
3
Defining configuration tasks
58jlk
58jlk
class-def
subclass-of
i
slot-constraint mb-of-cpu cardinality 1
. [ ¤ ]
egeYi
d
58jlk
58jlk
For the description of a configuration task we employ a descrip-
disjoint
.
h
i
58jlk
tion logic language (e.g., OIL) starting from a schema
disjoint
.
¦¨§
ege
© !#"
of disjoint sets of names for concepts, roles, and
slot-def mb-of-cpu
58jlk
individuals [5]. Concepts can be seen as unary predicates defining
inverse cpu-of-mb domain
range
.
ege
slot-def cpu-of-mb
classes (component types). Roles are used to express relationships
58jlk
inverse mb-of-cpu domain
range
.}
between different elements of a domain. Finally, individuals are spe-
efe
g
The customer requirement "two CPUs of type CPU1 and one CPU
cific named elements of the domain5.
'0)
of type CPU2" is expressed by
(instance-of c1 CPU1),
Definition 1 (Configuration problem in description logic): In
¦324¦
§o
(instance-of c2 CPU1), (instance-of c3 CPU2) . The configuration
general we assume a configuration problem is described by a triple
p
5879q@CB
5GFIHaPbRUTWV
58jlk
58jlk
')
language
is defined by
©%$&$('0)1
'0)1658709A@CB4'0)D"
$&$('0)
.
represents the domain
§ro
h
i
FIHaPbRUTWV
¦324¦
and
mb-of-cpu .
efe&h
efenibp
2
§o
p
58jlk
E
In the following we assume that the reader is familiar with the concepts of
In our example we do not include the concepts
and
and
efe
5879q@CB
'0)
OIL. See [9] for an introductory text.
the role cpu-of-mb in
since we are only interested in the
90
leaf concepts of a generalization hierarchy and specific relationships
8
Č
Č
´
´
01s§oszĆÇ
Ç
{
szƶÇQÉ
ÇQÉQ{¤pbp
(e.g., to manufacture the final system we only need to know the most
specific type for each component and its connections).
58}4@~
fĘ9q¨
f
'0)
'0)
is a valid configuration iff
!©1Şn¬|
dCe
The semantics of description terms are usually given denotation-
9¨&·
)¸
©
is satisfiable.g
x©zy
"
ally using an interpretation
, where
is a domain
§tsvulw
w{
ulw
Note that we use the above notation for defining the complete ex-
©zy
"
(non-empty universe) of values, and
a mapping from concept de-
w
tension of roles in order to apply the translation function from de-
scriptions to subsets of the domain, and from role descriptions to sets
scription logics to predicate logic defined in [5]. An alternative to the
of 2-tuples over the domain. The mapping also associates with every
product constructor would be a constructor that (in a similar manner
|
individual name in
some distinct value in
. The reason for
uw
to the one-of constructor for concepts) permits the enumeration of
this distinctness is the unique name assumption (UNA) we employ
permissible entries for a role. However, the usual complexity prob-
in our formalism. We require the UNA for concepts and roles which
lems with the product constructor do not actually arise since we only
describe configurations in order to make sure that different identifiers
apply product to singleton arguments.
for individuals (e.g., modules of a system) refer to different individu-
Example 3: In order to verify that a given configura-
als. This UNA can be lifted if necessary for concepts and roles which
'0)
tion is valid w.r.t. our example
, we need to add the
dCe
are not used to describe configurations. In the following we give a de-
58jlk
58jlk
axioms
one-of
Ż
,
one-of
Ż
,
h
§
®
dsh
di
i
§
®
d¦
scription logic based definition of a configuration problem and show
one-of
Ż
,
one-of
Ż
, mb-of-cpu
efe&h
§
®
h
efeni
§
®
i
§
its equivalence with consistency-based definitions given in the litera-
product one-of
Ż
one-of
ŻiŻDË
product one-of
Ż
one-of
ŻiŻ Ë
®
®
dsh
®
h
®
®
dUi
®
h
ture [8]. This definition serves as a joint foundation of configuration
product one-of
Ż
one-of
ŻiŻ
®
®
d¦
®
i
g
knowledge representation in the Semantic Web.
We now give a consistency-based definition of a configuration
Definition 2 (Valid configuration in description logic): Let
§
problem using predicate logic (this definition corresponds to the def-
U©zy
"
')
be a model of a configuration knowledge base
,
svu
{
dCe
w
w
inition given in [8]) and show the equivalence with the description
5879q@CB
5GFIHQPSRUTWVqf
FIHaPbRUTWV
'0)
a configuration language, and
§
2
logic based definition given before.
58}4@~
fn
'0)
a description of a configuration.
§
01
Definition 3 (Configuration problem in predicate logic): In
T
T
p
5
aA
5
5GFIHaPbRUTWV
is a set of tuples
for every
,
s
Gsv{
general we assume a configuration problem is described by a
P
qq
5
where
T
©%$&$n)
)
¤5879q@CB4)
"
$&$n)
˘
is the set of individu-
U
§oxda
da
p§
w
triple
©«Ě
©1Ě
©1Ě
where
©1Ě
and
¦324¦
T
5
als of concept
. These individuals identify components in an ac-
58709A@CB
)
)
©«Ě
are logical sentences and
©«Ě
is a set of
¦324¦
8
tual configuration.
is a set of tuples
$&$
)
01
s%2
!3b{
predicate symbols.
©1Ě
represents the domain description and
p
FhHQPSRUTiV
8
Qˇ
for every
where
)
˘
˘
2G
2
01s§os q
{
©«Ě
specifies the particular system requirements. A configu-
¦324¦
Qˇ
is the set of tuples of role
defining the
58}4@~3)
s q U˘GŁ
U˘GŁs{¤pc§Ą2
2
©1Ě
w
ration
is described by a set of positive ground literals
relation of components in an actual configuration.
5879q@CB
)
g
whose predicate symbols are in the set of
©1Ě
. g
Example 2: A valid configuration for our example knowl-
$&$
)
Example 4: For our example,
©1Ě
can be expressed by using
58}4@~3'0)
58jlk
58jlk
edge base is
= ous
h
oxdsh
dUibps{
s
i
oUd¦p{
monadic and dyadic predicates and numerical quantifiers, i.e.,
¤
z
mb-of-cpu
$&$()
svege&h
o
hxps{
svefeni
o
iSps{
s
os dsh
hx{
s dUi
hx{
©«Ě
§o
¤
.
¨ĎÎ
© ¨Đ"0Ń
© ¨Đ"1Ň
© ¨C"
Í
s d¦
ib{¤p{¤p
g
ege
efemh
egeYi
We also have to describe component parameter settings in addi-
¨ĎÎSÓ
© ¨Đ"!ŇÓ
© ¨C"
Í
ege&h
egeYi
tion to components and their connections. Using description logics,
Ł
¨ĎÎ
© ¨Đ"0ÔÖŐ
Î
© ¨
"
Í
˘×
mb-of-cpu
×
ege
parameter settings of components are modeled by special functional
¨ĎÎS58jlkY© ¨Đ"0ŃÖ58jlk
© ¨C"1Ň58jlk
© ¨Đ"
Í
h
i
roles (also called features) expressing the relation between the com-
¨ĎÎSÓ58jlk
© ¨Đ"!ŇÓ58jlk
© ¨Đ"
Í
h
i
ponent and the data value assigned to a particular attribute. There-
˘
¨ĎÎS58jlkY© ¨Đ"0ÔÖŐ
Î
©
¨Đ"
Í
×
×
˘
mb-of-cpu
fore, component structure and parameter settings can be treated in a
˘
¨ĎÎS58jlk
© ¨Đ"0ÔÖŐ
Î
©
h¨Đ"1Ř
©
"
Í
˘
×
mb-of-cpu ×
×
i
egeYi
uniform manner except that the parameter values come from some
¨ĎÎsÓ
© ¨Đ"1ŇCÓ058jlkY© ¨C"
Í
.
efe
ys§©%$m"
data value domain
[16] disjunct from the individuals in
¨
Î
© ¨
"Ń
©
¨Đ"
Í
×
×
×
mb-of-cpu
cpu-of-mb
.
58}
j
.
¨
Î
© ¨
"ÔŮÚs© ¨Đ"|Ř
©
"
Í
e
¦
×
mb-of-cpu
×
×
.
dhŰÜ
p
In addition to the definition of a valid configuration given above,
)
58jlk
©
"
58jlk
©
"
58jlk
©
"
©«Ě
.
¦324¦
§go
h
dh
h
di
i
d¦
p
we can provide an equivalent characterization based on checking the
5879q@CB
58jlk
a58jlk
)
©«Ě
§go
h
i
efe&h
consistency of a set of axioms.
mb-of-cpu
efeYi
p
g
'0)
Remark 1: Let
be a configuration knowledge base,
dCe
Definition
4
(Consistent
configuration
in
predicate
5879q@CB
5GFhHQPbRxTiV4f
FIHaPbRUTWV
'0)
a configuration language, and
©%$&$()
)
§
2
logic): Given a configuration problem
©«Ě
,
©«Ě
,
¦324¦
58}4@~
f
'0)
a description of a configuration.
58709A@B
"
58}4@~
)
)
§
1
©«Ě
, a configuration
©1Ě
is consistent iff
T
5
The concepts
are defined by the component axioms
$&$
f
f58}4@~
)
)
)
©1Ě
©1Ě
©1Ě
is satisfiable.
¦324¦
g
9q¨
!©«ŞY¬!
§
This definition allows determining the consistency of partial con-
figurations, but does not guarantee the completeness of configu-
T
P
T
p
5
5
aA
one-of
˘
zŻI°
where
o
§
®
d
da
s
Gsv{
±
rations [8]. It is necessary that a configuration explicitly includes
qq
all needed components (and their connections and attribute val-
§go˛ł ´
˛ł¶µ
psp
ues), in order to assemble a correctly functioning system. We
9q¨&·
)¸
The roles
are defined by the role axioms
©
need to introduce an explicit formula for each predicate symbol in
2
§
58709A@B
)
©«Ě
to enforce its completeness property. In order to stay
ˇ
product one-of
Ż
one-of
ŻiŻh°
within first order logic, we model the property by first order for-
ox2
§
ą
®
®
q
®
şW»
DżŔÁbÂsĂSÄSĹ
mulae. For our example we have to add the completeness axiom
aĽ
˝ aľ
¨ÝÎA58jlk
© ¨Đ"Ţß©Iŕá
58jlk
© ¨Đ"
"
Í
for the
h
S!©1âGăSäĺć
h
§čç
p
8
with
58jlk
58jlk
predicate
and similar axioms for
and mb-of-cpu.
s%2
!
{
0!
s
h
i
91
ŕá
58jlk
© ¨C"
Note that
serves as a macro which
nent types are transformed into corresponding concepts, attributes
äĺć
S!©«âă
h
§gç
58}4@~3)
is expanded based on the elements in
into role definitions constraining datatype and cardinality (the cardi-
©«Ě
. We refer to
58}4@~
58}4@~
)
nality of attribute roles is set to 1). Attributes as well as abstract roles
©«Ě
extended by completeness axioms as
é
LOG.
58}4@~3)
58jlk
©
"
58jlk
©
"
Example
5:
are inherited by the defined subconcepts. In most configuration envi-
©«Ě
§
o
h
dh
h
dUi
58jlk
©
"
©
"
©
"
©
¤
"
mb-of-cpu
ronments the semantics of a generalization hierarchy are disjunctive
i
d¦
ege&h
h
egeYi
i
dsh
h
©
z
"
©
¤
"
mb-of-cpu
mb-of-cpu
(disjoint concept) and complete by default (each instance of a super-
dUi
h
d¦
i
p
58jlk
¨¨Î58jlk
© ¨C"`Ţ
Í
The completeness axiom for
is
type is also an instance of exactly one of its subtypes).
h
h
58jlk
© ¨Đ"
58jlk
©
"3Ň58jlk
© ¨C"
58jlk
©
"
, where un-
Part-whole relationships. Part-whole relationships play an im-
h
§
h
dsh
h
§
h
dUi
satisfiable literals are deleted.
portant role in many application domains having quite different se-
g
Definition 5 (Valid configuration in predicate logic): Let
mantics (see [1], [16]). Basically, a part-whole relationship can be
©%$&$
5879q@CB
"
)
)
)
expressed using the two roles PartOf and HasPart, where PartOf
©«Ě
,
©«Ě
,
©«Ě
be a configuration problem.
¦28¦
58}4@~3)
$&$()
f
)
f
A configuration
is the inverse role of HasPart. In OIL or DAML+OIL we can de-
©«Ě
is valid iff
©«Ě
©«Ě
¦28¦
58}4@~
fine - depending on the application domain - different semantics for
é
LOG is satisfiable. g
58}4@~
)
Note that
part-whole relationships by imposing restrictions on the usage of the
©«Ě
in Example 5 is a valid configuration.
In order to show the equivalence of valid configurations for de-
corresponding roles. Sattler [16] presents an extension of the basic
scription logic and predicate logic we apply a translation function
description logic
with concepts for adequate representation of
÷lř
y
ę
that maps description logics to predicate logic, i.e., axioms to
part-whole relationships - in this context a categorization of different
s
{
formulas with no free variables, concepts to formulas with one free
facets of part-whole relationships is given. In our working example
variable , and roles to formulas with two free variables
and .
(Figure 1) we only allow part-whole relationships where a compo-
ë
ë
ě
y
ę
Borgida [5] provides such a translation function
such that
nent is part-of exactly one other component (this is also denoted
s
{
concepts, roles, terms, and axioms are translated into equivalent for-
as exclusive part-whole relationship). Such exclusivity restrictions
)
'0)
)
ę
mulas in predicate logic.
can be introduced by restricting the cardinality of the corresponding
©1Ě
where
©1Ě
is
dCe
§
s%dCe
{
dCe
')
satisfiable iff
is satisfiable.
role to 1, e.g., slot-constraint mb-of-cpu cardinality 1 MB, where the
dCe
Remark 2 (Equivalence of configuration problems):
role mb-of-cpu must be interpreted as a subslot of the role PartOf.
58709A@CB
58709A@B
)
')
Let
Furthermore, restrictions concerning the cardinality of parts must be
©«Ě
where each concept is in-
§
terpreted as monadic and each role is interpreted as dyadic predi-
added to the concept definition of the whole, e.g., slot-constraint cpu-
58}4@~«)
cate.
of-mb min-cardinality 1 CPU (max-cardinality 2 CPU).
©«Ě
describes the actual configuration by two sets of
58}4@~3)
f
facts
Port connections. As mentioned above, certain predicate logic
©«Ě
COMP-facts
ROLE-facts. The construction
§
58}4@~
58}4@~
f`
)
')
of
constructs must be simulated by more complex description logic ar-
©«Ě
is based on
§í
01
T
p
p
5
©
"
qq
where COMP-facts
rangements [5]. In terms of predicate logic, port connections can be
°
§îo
d
d
1ď
3đń
p
µIňSó
5
¤j
Q5
¤j
p
p
©
Qˇ
"
aˇ
8
Qő
˘
˘
Ł
Ł
and ROLE-facts
represented using a predicate conn(
), i.e., component
°
§ôox2
q
s q
{
!3b
5
j
5
j
$&$n)
$&$n')
)
'0)
˘
˘
Ł
Ł
ę
ę
.
is connected via port
with component
via port
- e.g.,
©«Ě
, and
©1Ě
.
đń
p
§
s
{
¦324¦
§
sv¦324¦
{
µIňSó
y
y
y
¤ˇ
Qˇ
y
58}4@~
)
conn(
) describes a
ůvux
druqh
ů%ux
Ű
qxú¤i
daqbxxxUt3h
daqbxxxUtuŰ
qxúh
©1Ě
is
a
valid
configuration
for
y
y
y
ˇ
y
©%$&$
Q58709A@B
"
58}4@~
)
)
)
'0)
connection between
of
and
ů%ux
Ű
qxú¤i
ů%ux
druqh
daqbxxxUtuŰ
qxúh
©«Ě
©«Ě
©«Ě
iff
is a valid
¦324¦
ˇ
©%$&$n')1
')1Q58709A@B4')D"
configuration for
.
of
. In order to represent port-based connections, we have
dqsxxUt3h
¦324¦
g
Remark 2 follows from Remark 1 and the equivalence property
to introduce a Port concept, which is characterized by a role indi-
of the translation function. Note that the completeness axioms cor-
cating the related component concept (role compnt) and a role which
9¨
respond exactly to the translation of the axioms
indicates the used portname of the connection (role portname) - addi-
|©«Şn¬|
and
·
9q¨
)ö¸
tionally, a role conn indicates the connection to the second involved
©
by applying the translation function proposed in [5].
From the equivalence of configuration problems follow two impor-
Port concept. Although a representation of port connections is pos-
tant consequences. First, the two main streams in solving configura-
sible with OIL or DAML+OIL, the original knowledge of domain
tion problems based on description logics on the one hand and first
experts is split into multiple pieces of knowledge which are hard for
order predicate or propositional logic on the other hand can be eas-
these domain experts to understand. Also, note that the connections
ily transformed to each other. Second, since description logics with-
via such a connection object must be unique and therefore the roles
out transitive closure are equally expressive to dyadic predicate logic
must be bidirectionally defined using the inverse role constructor.
y
y
with at most three (counting) quantifiers [5] it follows that the predi-
The constraint that a Videocard must be connected via ůvux Ű
qúi
ˇ
y
cate logic based approach is strictly more expressive than the descrip-
with a Screen via
can be formulated as
dqsxxxxtuŰ
qxúh
tion logics based approach, implying that certain logic constructions
Example 6: Videocard:(slot-constraint videoport has-value((slot-
have to be simulated by more complex description logic construc-
constraint portname has-value (one-of videoport2)) and (slot-
tions, and also that certain complex structural restrictions [6] will not
constraint conn has-value ((slot-constraint compnt has-value
be expressible in the language directly but will have to be incorpo-
Screen) and (slot-constraint portname has-value (one-of screen-
rated using a more expressive assertional language.
port1)))))). g
The constituting elements of such port constraints are navigations
representing role compositions between connected concepts.
4
Building configuration knowledge bases for the
Navigation in product structure. In the following we discuss a
Semantic Web
set of representative constraint concepts which are frequently used
in the configuration domain [7, 17]. The constraints consist of navi-
In the following we show how to represent the configuration domain
gation expressions over concepts which are represented by complex
specific modeling concepts discussed in Section 2 using OIL.
paths over abstract roles.
5
˘
Component types. The representation of component types is
Definition 6 (Navigation expression): Given two concepts
5
5
5
Ł
˘
Ł
straightforward and has already been shown in Section 3. Compo-
and
, a navigation expression from
to
is formulated as a
92
sequence of existential role quantifications
description logics based languages makes them one of the natural
(slot-constraint ˘ has-value(slot-constraint Ł has-value ... (slot-
choice for configuration representation, certain demands on expres-
q
q
P
5
constraint
has-value
Ł
))),
siveness must be met. The current versions of OIL and DAML+OIL
q
P
where < ˘ , Ł , ...,
> denotes a sequence of roles along the nav-
do not support aggregation functions which are fundamental repre-
q
q
q
5
5
5
5
igation path from
˘
to
Ł
( ˘ is a role of
˘
and
Ł
is in the range
sentation concepts frequently used in the configuration domain. Sat-
q
P
5
5
of
). In the following we use the expression navpath( ˘ ,
Ł
) as
tler and Baader [2] provided concrete domains and aggregation func-
q
5
5
short hand notation for a navigation path concept from
˘
to
Ł
.
tions over them as extensions to the basic description logic
.
g
÷lř
·
5
Definition 7 (Common root): A concept
is denoted as com-
In addition to aggregation functions, built-in predicates must be al-
P
5
5
a5
mon root of a set of concepts
˘
, if there exists a
lowed in order to support comparisons on the results of aggregation
ii
§űo
p
navigation path from CR to each concept of C.
functions as well as on local features. Since trivial structural condi-
g
Incompatibilities. An incompatibility constraint between con-
tions lead to definitional overhead (e.g., when defining restrictions
P
·
·
5
5
5
5
5
5
cepts
˘
,
Ł
, ...,
can be expressed as
: not(navpath(
,
˘
)
on port connections), additional concepts must be provided allow-
P
·
·
·
5
5
5
5
5
and navpath(
,
Ł
) ... and navpath (
,
)), where
is the
ing the definition of roles with arity greater than two; the description
P
5
5
5
$&$
'0)
common root of
˘
,
Ł
, ...,
in
.
of more complex structural properties (see [6]) would be supported
Example 7 (IDEUnit incompatible with MB2): Computer:
by permitting the usage of variables. As far as the definition of rule
not((slot-constraint hdunit-of-computer has-value IDEUnit) and
languages for expressing detailed configuration knowledge on top
(slot-constraint mb-of-computer has-value MB2))
of DAML+OIL is concerned, we must stress that such a language
g
5
Requirements. A requires dependency between concepts
˘
and
must allow disjuncts of positive literals when writing the constraint
5
5
5
5·
5·
5
Ł
( ˘ requires
Ł
) can be expressed as
: not(navpath(
,
˘
))
in clausal form, e.g., to express alternative port connections.
·
·
5
5
5
5
5
$&$n')
or navpath(
,
Ł
) with the common root
of
˘
,
Ł
in
.
Happily, most of the required means of expression are already
Similar to incompatibilities, requirements can be extended by intro-
available in the Description Logic designer's toolbox; however, the
ducing further navigation paths on the LHS and RHS of a requires
degree of expressivity required also leads to problems w.r.t. to decid-
5
ŘC5
5
ŇC5
dependency, e.g.
Ą
˘
¤
requires
Ł
.
ability of basic properties such as satisfiability or subsumption [2].
Example 8 (SCSIUnit requires MB1): Computer:((not(slot-
State-of-the-art configurators achieve decidability by putting a pre-
constraint hdunit-of-computer has-value SCSIUnit)) or (slot-
defined limit on the number of individuals and allowing only finite
constraint mb-of-computer has-value MB1))
domains of values for features (constraint variables). Furthermore,
g
Resource balancing. Resource constraints can be formulated us-
only fixed concept hierarchies are allowed (as part catalogues are
ing aggregation functions as proposed in [2]. We assume the exis-
typically considered unchangeable), which reduces the importance
T
ys§©%$m"
j
tence of a value domain
, a set of predicate symbols
asso-
of subsumption versus that of A-Box reasoning.
y©%$m"
ciated with binary relations (typically
,
, =,
,
) over
,
ü
ý
ţ
˙
©%$m"
ˇ
and a set of aggregation functions
(typically
,
rvv
Ü
ruůSv
y
,
; the last being identity in the case where we want to com-
5
Conclusions
d
Ütwú
%
pare to a single fixed value instead of to an aggregate). Concerning
the path leading to the concept whose feature values are aggregated,
In this paper we have shown how to apply Semantic Web ontology
the definition of [2] requires that all but the last one of the roles in
representation languages for configuration knowledge representation
this path must
and integration. We gave a description logic based definition of a con-
F
F
be features.
F
F
˘
˘
˘
˘
P
P
ˇ
Let <
figuration problem and showed its equivalence with corresponding
˘
, Ł , ...,
˘
,
> and <
,
, ...,
,
> be navi-
˘
Ł
˘
q
q
q
q
q
q
q
q
˘
˘
5·
gation expressions with
as common root leading to the consumer
consistency-based definitions. A consequence of this equivalence is
F
F
5
5
Ł
Ł
(producer) concepts
(
). Furthermore, let
,
be features of
that configuration problems represented in description logics can eas-
˘
˘
F
p
5
5
©%$m"
and
and
be an aggre
ily be transformed into configuration problems represented in pred-
F
gation
F
F
function.
F
We can
˘
¤
rvv
˘
F
5·
j(©
©
"a
Ł
P
§¦
P
Ą
express a resource constraint as
:
icate logic or simplified variants thereof (and vice-versa). Conse-
˘
Ł
...
˘
˘
q
q
q
¤
q
q
˘
˘
©
""
˘
Ł
¦
...
according to [2].
quently, we provide a common foundation that enables joint research
Ł
˘
˘
q
q
¤
q
˘
˘
Generally, if two aggregates are compared, one interprets the set
activities and exploration of results. With respect to ongoing efforts
that has to produce a smaller value as the set of consumers, and the
to extend DAML+OIL our paper contributes a set of criteria which
set that has to produce a larger value as the set of producers.
must be fulfilled in order to use such a language for full-fledged con-
Now we can define a concept Computer that comes equipped with
figuration knowledge representation. Thus DAML+OIL has the op-
a set of HDUnits that provide a corresponding hard-disk capacity and
portunity for being a standard knowledge representation language for
a set of software components that need hard-disk capacity. We ex-
the configuration domain.
press the requirement that the total hard-disk capacity consumed by
software cannot exceed the installed hard-disk capacity. In this case
navigation expressions only consist of two elements, consequently
References
hdcapacity must be a feature, while hdunit-of-computer is a general
[1] A. Artale, E. Franconi, N. Guarino, and L. Pazzi. Part-Whole Rela-
role. The last line is the actual resource constraint.
tions in Object-Centered Systems: An Overview. Data & Knowledge
Example 9 (
swcapacity
hdcapacity):
Engineering, 20(3):347383, 1996.
¤
ý
¨¤
Software: slot-def swcapacity range (min 0) properties functional
[2] F. Baader and U. Sattler. Description Logics with Concrete Domains
and Aggregation. In Proceedings of the © European Conference on
HDUnit: slot-def hdcapacity range (min 0) properties functional
Artificial Intelligence (ECAI '98), pages 336340, Brighton, UK, 1998.
Computer: slot-def hdunit-of-computer range HDUnit
[3] V.E. Barker, D.E. O'Connor, J.D. Bachant, and E. Soloway. Expert sys-
slot-def sw-of-computer range Software
tems for configuration at Digital: XCON and beyond. Communications
¦
lesseq (sum(sw-of-computer swcapacity),
of the ACM, 32(3):298318, 1989.
¦
sum(hdunit-of-computer hdcapacity))
[4] T. Berners-Lee. Weaving the Web. Harper Business, 2000.
g
[5] A. Borgida. On the relative expressive power of description logics and
Analysis. While the basic frame structure and formal basis of
predicate calculus. Artificial Intelligence, 82:353367, 1996.
93
[6] J. Cai, M. Furer, and N. Immerman. An optimal lower bound on the
number of variables for graph identification. In Proceedings of ©
IEEE Symposium on FOCS, pages 612617, 1989.
[7] A. Felfernig, G. Friedrich, and D. Jannach. UML as domain specific
language for the construction of knowledge-based configuration sys-
tems. International Journal of Software Engineering and Knowledge
Engineering (IJSEKE), 10(4):449469, 2000.
[8] A. Felfernig, G. Friedrich, D. Jannach, and M. Stumptner. Consistency-
Based Diagnosis of Configuration Knowledge Bases. In Proceedings of
the European Conference on Artificial Intelligence (ECAI 2000),
pages 146150, Berlin, Germany, 2000.
[9] D. Fensel, F. vanHarmelen, I. Horrocks, D. McGuinness, and P.F. Patel-
Schneider. OIL: An Ontology Infrastructure for the Semantic Web.
IEEE Intelligent Systems, 16(2):3845, 2001.
[10] G. Fleischanderl, G. Friedrich, A. Haselböck, H. Schreiner, and
M. Stumptner. Configuring Large Systems Using Generative Constraint
Satisfaction. IEEE Intelligent Systems, 13(4):5968, 1998.
[11] T. Gruber, R. Olsen, and J. Runkel. The configuration design ontologies
and the VT elevator domain theory. International Journal of Human-
Computer Studies, 44(3/4):569598, 1996.
[12] E.W. Jüngst M. Heinrich. A resource-based paradigm for the configur-
ing of technical systems from modular components. In Proceedings of
the ! IEEE Conference on AI applciations (CAIA), pages 257264,
Miami, FL, USA, 1991.
[13] D. Mailharro. A classification and constraint-based framework for con-
figuration. AI Engineering Design Analysis and Manufacturing Jour-
nal, Special Issue: Configuration Design, 12(4):383397, 1998.
[14] S. Mittal and B. Falkenhainer. Dynamic Constraint Satisfaction Prob-
lems. In Proceedings of the National Conference on Artificial Intelli-
gence (AAAI 90), pages 2532, Boston, MA, 1990.
[15] S. Mittal and F. Frayman. Towards a Generic Model of Configuration
Tasks. In Proceedings U International Joint Conf. on Artificial In-
telligence, pages 13951401, Detroit, MI, 1989.
[16] U. Sattler. Description Logics for the Representation of Aggregated
Objects. In Proceedings of the European Conference on Artificial
Intelligence (ECAI 2000), pages 239243, Berlin, Germany, 2000.
[17] T. Soininen, J. Tiihonen, T. Männistö, and R. Sulonen.
Towards a
General Ontology of Configuration. AI Engineering Design Analy-
sis and Manufacturing Journal, Special Issue: Configuration Design,
12(4):357372, 1998.
[18] F. vanHarmelen, P.F. Patel-Schneider, and I. Horrocks.
A Model-
Theoretic Semantics for DAML+OIL. www.daml.org, March 2001.
[19] J.R. Wright, E. Weixelbaum, G.T. Vesonder, K.E. Brown, S.R. Palmer,
J.I. Berman, and H.H. Moore. A Knowledge-Based Configurator that
supports Sales, Engineering, and Manufacturing at AT&T Network
Systems. AI Magazine, 14(3):6980, 1993.
94
A Subsumption-Based Configuration Tool for
Architectural Design
Dan Corbett1
Abstract. This paper discusses research in bringing formal
when it comes to combinatorial algorithms, and that a graph (as a
structured knowledge representation to computational design in
mathematical object) allows a natural representation (and therefore
building architecture. Specifically, we demonstrate that the
permits the construction of effective algorithms). There have been
techniques of type subsumption, join and unification can be used as
many attempts to formalize and standardize these graphical
tools to turn a general design into a complete design. We have
knowledge representation schemes, but probably none has been as
developed a software tool which uses these techniques to assist in
extensive and comprehensive in recent times as Conceptual
the exploration of designs. The significance of this work is that we
Structures.
demonstrate that the merging of designs represented as Conceptual
Conceptual Structures (or Conceptual Graphs, or "CGs") are a
Graphs is efficient and useful to the designer.
knowledge representation scheme, inspired by the existential
graphs of Charles Sanders Peirce and further extended and defined
by John Sowa [Sowa 1984]. Informally, CGs can be thought of as
1
SEARCH AND DESIGN
a formalization and extension of Semantic Networks, although the
origins are different. They are labeled graphs with two types of
Designers have borrowed Artificial Intelligence techniques to
nodes: concepts (which represent objects, entities or ideas) and
explore design possibilities and models. While AI researchers may
relation nodes, which represent relations between the concepts.
know these techniques as state space search, designers see them as
Every concept or relation has an associated type. A concept
discovery, or as guided movement through design possibilities
may also have a specific referent or individual. A concept in a CG
[Woodbury et al. 2000] . The point of automated search for the
may represent a specific instance of that type (eg, Felix is a specific
designer is to use computer media that engage designers in
instance, or individual, of type "cat") or we may choose only to
exploring design modifications. The design user may want to
specify the type of the concept. In the standard canonical
create new designs, or index, compare or adapt existing designs.
formation rules for Conceptual Graphs, unbound concepts are
This type of user requires efficient representations for the designs
existentially quantified. A relation may have zero or one incoming
and states (of designs) in a symbol system. The designer needs to
arcs, and any number of outgoing arcs. The type of the relation
be able to represent spaces of possibilities which are both relevant
determines the number of arcs allowed on the relation. The arcs
to the discovery process and lend themselves to tractable
always connect a concept to a relation. Arcs cannot exist between
computations. It is necessary for the design process that the
concepts, or between relations.
information in the system can be ordered by specificity, since
A canon in the sense discussed here is the set of all CGs which
design exploration usually means starting from an under-specified
are well-formed, and meaningful in their domain. Canonical
design and proceeding to a more specialized state.
formation rules specify how CGs can be legally built and guarantee
This constraint has led us to consider state spaces structured by
that resulting CGs satisfy "sensibility constraints." The sensibility
information specificity. Type hierarchies, subsumption and
constraints are rules in the domain which specify how a CG can be
conceptual relations are used to realize these concepts. Using
built, for example that the concept eats must have a theme which is
techniques and theory that we developed as part of a knowledge
representation project, we developed software which will allow the
food. Note that canonicity does not guarantee validity. A CG may
design user to construct specific designs from generic designs (or
be well-formed in the canonical formation rules for the domain, but
new designs from old) while preserving all constraints on the
still be false.
process. We employ the techniques of Conceptual Graphs to
A type hierarchy is established for both the concepts and the
represent and manipulate the design.
relations within a canon. A type hierarchy is based on the intuition
that some types subsume other types, for example, every instance
of "cat" would also have all the properties of "mammal." This
2
CONCEPTUAL GRAPHS
hierarchy is expressed by a subsumption or generalization-order on
types.
It has been demonstrated many times that graphs are a powerful
Formally, we define Conceptual Graphs as follows:
and efficient knowledge representation technique. Mugnier and
Chein [Mugnier and Chein 1996] illustrate quite effectively why
Definition 1. Conceptual Graph. A Conceptual Graph with
labeled graphs are useful for knowledge representation in general.
respect to a canon is a tuple G = (C, q, R, type, referent, arg1, . . .,
Among the main advantages that they list are a solid grounding
argm) where
______________________________________________________
Advanced Computing Research Centre, School of Computer and
C is the set of concepts, type : C T indicates the type of a
Information Science, University of South Australia, Adelaide, South
concept, and referent : C I indicates the referent marker of a
Australia 5095, email: corbett@cs.UniSA.edu.au
95
concept. The referent marker is either a pointer to an individual or
Müller demonstrates in his work [Müller 1997] that it is not
a generic marker, which indicates that the individual is of the type
always possible to find a common specialization for two arbitrary
indicated, but is existentially quantified.
graphs in the same canon, and therefore it is not possible to
T is the set of types. We will further assume that T contains two
guarantee that two graphs can be unified. If a subset of CGs is
disjunctive subsets TC and TR containing types for concepts and
defined which is all graphs that have a designated head node, and
relations.
the head nodes are of compatible types, then unification of these
I is the set of individuals.
graphs will at least be tractable. We define q, the head node of a
q is a distinguished member of C, the head or root node of the
graph, in order to be able to guarantee unification of the graphs
under Müller's algorithms. This method allows us to combine the
graph.
graphs while preserving the knowledge in both graphs, and still be
R is the set of conceptual relations, type : R T indicates the
able to use efficient unification methods as defined by Willems,
type of a relation, and each argi : R C is a partial function where
Müller, and others [Willems 1995; Müller 1997].
arg
The definitions of unification, consistency and type
i(r) indicates the i-th argument of the relation r. The argument
subsumption in this paper are based on formal concepts of
functions are partial as they are undefined for arguments higher
projection and lower bounds. Carpenter [Carpenter 1992] defines
than the relation's arity.
each of these operators as a morphism. We have modified
The set of types discussed in Definition 1 is arranged into a type
Carpenter's definitions to work with the properties of Conceptual
hierarchy, ordered according to the specificity of each type. A type
Graphs. A morphism is then a mapping from the set of nodes of
hierarchy is established for both the concepts and the relations
one Conceptual Graph to the set of nodes of another that preserves
within a canon. A type hierarchy is based on the intuition that
the order of relation arguments and the values of those arguments.
some types subsume other types, for example, every instance of cat
In a morphism, all of the connections and arguments are preserved.
would also have all the properties of mammal. This hierarchy is
The following definition of projection is the standard definition
expressed by a subsumption or generalization order on types. A
used in recent Conceptual Graph literature [Willems 1995;
type t is said to be more specific than a type s if t specializes some
Mugnier and Chein 1996; Leclčre 1997; Müller 1997; Corbett
of the concepts from s.
2001].
An example of a relation type hierarchy is shown in Figure 1.
In our domain of building architecture, we may wish to represent
Definition 2. Projection.
that one structure supports another structure. We may further want
G = (C, R, type, referent, arg1, . . . , argm) subsumes G´ = (C´,
to represent that any type of support structure which supports a
R´, type´, referent´, arg´
heavy load will also support a light load. This relationship is
1, . . . , arg´m) , G G´, if and only if there
expressed in the hierarchy. In this manner, some constraints on the
is a pair of functions hC : C C´ and hR : R R´, called
relations between concepts can be represented.
morphisms, such that:
Similarly, an example type hierarchy for concepts is shown in
Figure 2. The universal type is shown at the top of the hierarchy,
and is represented by T. The absurd type is shown at the bottom of
the graph, and is represented by . Here we see that a support
structure is a specialization of a structure, and that a bay structure
specializes support structure. Using these type hierarchies, it is
T
possible to show, for example, that the multiple-bay structure will
support a heavy load, by using concepts for multiple-bay structure,
and a relation of the type supports-heavy.
str uct ure
T
support s
support st ruct ure
support s-light
bay s t ruct ure
...
...
single
mult iple
support s-heavy
T
T
Figure 1. A relation type hierarchy.
Figure 2. A concept type hierarchy.
96
c C and c´ C´, hC(c) = c´ only if type(c) type´(c´), and
formalized much more recently [Wermelinger and Lopes 1994;
Müller 1997]. We present here rules based on the work of Müller
referent(c) = * or referent(c) = referent(c´)
[Müller 1997].
r R and r´ R´, hR(r) = r´ only if type(r) type´(r´)
r R , arg´
1. Join. Given two CGs G = (C, R, type, referent, arg
i(hR(r)) = hC(argi(r)),
1, .
. . , argm) and G´ = (C´, R´, type´, referent´, arg´1, . . . ,
Willems also includes the following non-emptiness condition in
arg´m) (without loss of generality we assume C and C´ to be
his definition of projection in [Willems 1995]:
disjoint) c C , and c´ C´ where c = c´ (that is, they
have identical types and referents) or c c´ (ie, the type of c
c C there is a concept c´ C´, such that hC(c) = c´
subsumes the type of c´) the external join of C and C´ is the
CG G´´ = (C (C´ - {c´}), R (R´c´:=c), type´´, referent´´).
This non-emptiness condition guarantees that all the concepts
present in the more general graph are also present in the more
The subscript c´:=c denotes the replacement of every
specific graph, although they may be in a more specific state.
occurrence of c´ by c.
Willems' definition allows for the more specific graph to have
concepts of a more specific type, or for a generic referent to be
2. Restrict. Given a CG G = (C, R, type, referent, arg1, .
replaced by a specific individual. The definition used here also
. . , argm) and a node c C with type t which has a
allows admits the non-emptiness condition.
Conceptual Graphs were chosen for this research because they
subtype s the restrict type is the CG G´ = (C, R, type´,
can represent partial knowledge in a domain. It is possible for a
referent) such that type´(c) = s, d c: type´(d) = type(d).
designer to specify an object (or design) at some intermediate
stage, with only very general types for the concepts and relations.
Sowa [Sowa 1984] (and others) also define a copy rule, which
When more specific knowledge becomes available, or when the
allows a new graph G´ to be created as an exact duplicate of a
designer chooses to fill in the details of a design, the operators of
graph G, and a simplify rule which allows the deletion of duplicate
specialization, unification and join are employed.
(and presumably redundant) relations.
In our work, partialness means that a structure need not contain
We are able, then, to represent architectural designs as
all information that is implied about it by its structure and types. A
Conceptual Graphs. The architect can start with a general
partial representation is used here as a generalized, or higher-level
description of a design, and work through successive
description of an object in the domain. Whether a structure is
specializations to explore the design. Each specialization is
partial or not depends on the context of the knowledge, and the
subsumed by more general designs, and it is therefore guaranteed
domain. In domain terms, a model might be partial against one set
that each specialization conforms to all the constraints of the
of knowledge but complete with respect to a subset of the
original, generic specification.
knowledge. For example, if our current domain knowledge of a
We now show that subsumption is just another form of the
building is limited to its spatial organization, a complete model of
projection operator on Conceptual Graphs, defined previously.
it would assign functions to physical spaces. Such a model would
be partial with respect to a larger set of knowledge, containing for
Definition 3. Subsumption. We say that a Conceptual Graph G
example, knowledge of how to construct the building.
subsumes another Conceptual Graph G´, or G
The main thrust of the research described in this paper is the
CG G´, iff G´ can
unification of Conceptual Graphs in terms of conjoining the
be obtained by applying a finite number of canonical formation
knowledge contained in two different graphs. While this may
rules to G.
involve term substitution (or the Conceptual Graphs equivalent -
instantiation, subsumption, variable binding, etc.) and constraint
Since any application of the canonical formation rules to a graph
solving, our work is more concerned with knowledge conjunction
s will always produce a graph t which is more specific than the
as discussed in [Carpenter 1992]. Carpenter defines unification as
original, s will necessarily have a projection into the new graph t.
a system in which two pieces of partial information can be
Chein and Mugnier formalize this idea, and demonstrate that s t
combined into a single unified whole. In our case, these pieces of
iff there exists a projection from s to t [Chein and Mugnier 1992].
partial information are represented by Conceptual Graphs.
The unification of two conceptual graphs with constraints now
Carpenter refers to this idea as information conjunction, but in our
becomes the combination of two graphs which are compatible in
work, it is knowledge conjunction that is more important. We want
corresponding concepts and relations, as defined by our definition
to be able to combine the expert knowledge of a system, not merely
of the projection operator and join. Any constraints on the values
gather additional information. Unification here is the combining of
in the concepts of the graph are preserved through the unification
pieces of knowledge in a domain, represented as Conceptual
process by the projection operator.
Graphs. We want to define unification as an operation that
Mugnier and Chein convincingly demonstrate that any
simultaneously determines the consistency of two pieces of partial
Constraint Satisfaction problem (CSP) can be represented as a
or incomplete knowledge, and if they are consistent, combines
mathematical morphism [Mugnier and Chein 1996]. Their proof of
them into a single result.
the strong correspondence between CSP and the general problem
of morphism (or projection) also demonstrates that a type
hierarchy, such as used in Conceptual Graphs, can be effective in
3
SPECIALIZATION OF DESIGNS
representing and solving a CSP problem. They develop, and prove
the soundness of, algorithms for transferring CSP problems to a
The standard techniques for creating more specialized concepts
projection problem, and for transferring projections back to a CSP
from general concepts are collectively known as the Canonical
representation.
Formation Rules. The following definitions are standard, classical
Mugnier and Chein demonstrate that the algorithmic techniques
definitions of CG formation, which date back to Sowa's original
that they develop for resolving the problem of the existence of a
1984 work on Conceptual Graphs [Sowa 1984], but which were
solution to a Constraint Satisfaction Problem also can enumerate
97
the solutions. Further, these are transferable from one
domain to another [Mugnier and Chein 1996].
Formal definitions and algorithms for unification are
discussed in detail in [Willems 1995; Corbett and
Room 1
Room 2
Dining Room
Woodbury 1999; Corbett 2001]. A complete discussion
Skillion
and formal treatment of our unification algorithm is
presented in [Corbett 2001]. Rather than repeat these
Porch
here, we proceed to the discussion of the use of the
Hallway
configuration tool in the Architecture domain.
4
DESIGN EXAMPLES
Figure 3. Basic floor plan of a single-fronted cottage.
experience captured in the historical pattern of explored and stored
For our example domain, we detail the SEED project. The intent
design states.
of the SEED project is to create software which will support
As SEED explores the design space, each of the retrieved
preliminary design of buildings [Heisserman 1991; Heisserman
designs must be compared to the requirements to find whether the
1995; Chang and Woodbury 1996; Corbett and Burrow 1996;
design meets each of the specifications and constraints. The
Woodbury et al. 1999; Woodbury et al. 2000] . This includes using
problem then, is to find a previous design which will unify with the
the computer as an active tool which helps to generate designs
specification currently being worked on. This unification process
[Flemming and Woodbury 1995] . The SEED project architects
must attempt to identify each attribute of the specification with the
were willing to test the software that was produced from our work.
same attribute in the retrieved design. If all the attributes can be
SEED is an acronym for Software Environment to support the
unified while satisfying all of the constraints, then the two
Early phases in building Design. Specifically, SEED will help
structures are said to unify, producing a new structure which is a
with recurring building types (designs which are used again
combination of the knowledge in the two previous structures. The
frequently). The SEED system is intended to be an aid to
new structure is a new design, which can be used to satisfy the
architects in creating building designs by reusing design
current design requirements.
knowledge. In order to store and reuse the design cases in an
Appealing to our example domain, Figure 3 shows the basic
efficient manner, it is necessary to use a representation scheme
floor plan of a single-fronted cottage, a design which is very
which can handle real-value constraints and unification.
common in many parts of Australia. Figure 4 shows the
The SEED system is built around the idea of a design space.
corresponding Conceptual Graph. The graph represents the general
The design space is a set of partial or complete solutions to an
structure of the cottage (and some adjacency relations) but with
architectural design problem. In this sense, it is roughly equivalent
none of the details that will make this design into a realized
to the AI term "search space", in that the design space is defined by
cottage. (The ellipses indicate further parts of the graph which we
starting states and operators which allow the derivation of one state
do not have space to elaborate here.) A designer may retrieve a
from another, including some acceptable goal states.
previous design from a library of designs to provide some of the
SEED works by exploring the design space during the
details. An example of such a previous design is shown in Figure
elaboration of a design. To achieve the goal of design experience
5. Here, a design for a dining room adjacent to a living room is
reuse, SEED allows for the storage of "interesting" design states,
selected as a partial match for the general design. Many of the
where "interesting" is decided either by the user, or by the
details of the rooms have already been specified. This partial
interaction of the user's search path and heuristics in SEED. The
design can be unified with the graph in Figure 4, using the methods
difficulty, then, is in identifying and retrieving stored design states
described in this paper. There are four possible locations for
containing design decisions most applicable to the current state,
attaching the partial design to the general design. Our intent is that
that is, retrieving useful information corresponding to design
the system will not make the choice of which nodes to unify,
leaving the choice to the designer.
Since SEED works on the principle of constructive design, it is
house: *
important to be able to create small units in the design, and then
link them together. The mechanism we use to link these units is
unification. For example, the partial design illustrated in Figure 6
contains the concept kitchen. This may initially be used as a single
contains
concept, or as a link to the standard or template attributes of a
kitchen. These generic concepts would be specialized later. Figure
7 shows a design for a kitchen, with some of the usual relations.
porch: *
rm-row: *
hall: *
skillion: *
The area relation indicates that the value of the area is an
rm: dining
adj
rm: living
contains
. . .
. . .
. . .
access
rm: *
rm: *
rm: *
door: door1
door: door2
adj
adj
Figure 4. Conceptual Graph representation of Figure 3.
Figure 5. A specialization of two rooms.
98
rm : laundry
rm: *
color
rm: kitc hen
adjacent
rm: kit chen
adjacent
area
ar ea
hue: blue47
r m: dining-rm
rm: dining -rm
[ 13, 17] : *
[1 5 , 2 0] : *
Figure 6. A Conceptual Graph representation of a kitchen.
interval, which constrains the values that the area may have. Other
Figure 7. Another kitchen Conceptual Graph.
attributes may include insulation, illumination, support structure
and other factors which concern the design of a building structure.
nothing specified which could be incompatible with it.
We assume that these types and their respective type hierarchies
have already been defined, with their obvious meanings.
The unification of two design Conceptual Graphs is another
5
DISCUSSION
graph representing neither more nor less information than is
contained in the two graphs being unified. Unification only fails
In discussions with the architects who helped to test the system,
when it is applied to designs that, when taken together, provide
several issues of unification, constraints and matching were
inconsistent information. In the case of the design domain,
identified. The three main areas where the architectural designer
inconsistency can only arise from attempting to unify two
needs the contribution of Conceptual Graph unification are in type
structures that assign incompatible values (in either literal
subsumption, knowledge-level reasoning, and pattern matching.
information, or in the lattices defined for that type of information)
Each of these three areas is discussed below, along with a
to the same attribute.
qualitative judgment of how well Conceptual Graphs and
Figure 7 is an example of a kitchen SU specified by the user to
unification deal with these concerns.
have one adjacent room and a floor area constrained to be between
The architects want to be able to use type subsumption to make
fifteen and twenty square meters, represented by the interval [15,
statements such as, "An office (or kitchen, or corridor) is a kind of
20]. When we try to find a match for the specified partial design
room. All the properties which apply to one should apply to its
among the previous designs, we retrieve the Conceptual Graph
specializations." This is distinct from the object-oriented objective
shown in Figure 6 as a previously-designed kitchen from the
of objects inheriting all the properties of a class of objects. The
knowledge base. This is unified with the graph shown in Figure 7,
essential difference is in treating a kitchen as you would any
and the result is as shown in Figure 8.
generic room. A generic room can be placed, occupy space, and
The adjacent relations unify by taking on the values of both
have attributes such as insulation and number of doors. A class of
"dining-rm" and "laundry", since these two values are compatible
rooms will have attributes, but cannot be said to occupy a space or
(ie there is nothing to exclude the kitchen from being adjacent to
have specific dimensions, or have a specific count or placement of
both the laundry and the dining room). The area relation unifies,
doors. The generic room can have constraints placed on its
because the intervals specified in the two original graphs have a
attributes, and finally can be specialized into a kitchen.
join on the interval lattice. The join becomes the value of the
Fundamentally, a generic room can take the place of a
unified area relation. The color relation unifies trivially, as there is
specialized room, unlike a class of objects. The room can stay
generic for as long as the user needs it to be generic, and then
specialized. Further, the room could be specialized wholly or in
rm: laundry
part. If partly specified, it can be matched against other
specifications to find appropriate matches.
Conceptual Graphs and the unification algorithm give this
ability to the architects. The software allows the user to specialize
designs by matching (unifying) previous designs with the current
design problem. Since all characteristics, attributes and constraints
color
rm: kitc hen
adjacent
are carried along in the unification, the specialization represents all
of the design concepts included in the more generic design.
Further, and more importantly, there is no real separation between
generic and specific, since all points in between can be represented.
area
Conceptual Graphs combined with the ability to specialize using
unification are the ideal tool for the knowledge combination
hue: blue47
rm: dining-rm
approach and the constructive nature of architectural design.
The second major concern of the architectural designers was the
[1 5, 17] : *
ability to have knowledge-level reasoning. That is, they want to be
able to speak in the language of the architect, not the language of
Figure 8. The unified design.
the computer (or CAD system). The user wants to be able to refer
99
to the "north wall" or "door" without resorting to discussing
The significance of our work is that a simple unification
geometric coordinates in space. The user wants to depart from
operation, using join and type subsumption (implemented as
previous CAD-based data-level processing, and work at the
projection on Conceptual Graphs), is defined which can be used to
knowledge level in the architecture domain.
validate the constraints over an entire unified graph. Such a graph
This is certainly another area where Conceptual Graphs and
can be used to efficiently represent building designs.
unification combine to bring a solution to this domain. While
spatial coordinates (and their constraints) can be stored in a
graphical representation of a room, there is no need for the user to
7
ACKNOWLEDGEMENT
bother with using them. The graph can be manipulated as a whole,
The author expresses his sincere gratitude to the architects in the
and treated as a room, rather than a square in a diagram. The
SEED project who participated in discussions on, and assisted in
software system does not deal with lines and boxes, but rather with
the testing of the Conceptual Graph unification software: Rob
specializing entire designs for rooms (or houses, or office
Woodbury, Andrew Burrow, Sambit Datta and Teng-Wen Chang.
buildings). This approach frees the architect from dealing with
data-level concerns of numbers and coordinates, and allows the
architect instead to deal with the architectural design.
REFERENCES
The third major concern of the architectural testing team is in
the area of pattern matching. The users want to be able to start
with a high-level, generic description of a building, perhaps
Benn, D. and D. Corbett (2001). "An Implementation of the Process
Mechanism and an Extensible CG Programming Language". In
represented as a hierarchy of design units. Then they want to be
Proc. Workshop on Conceptual Graph Tools, International
able to make queries such as, "Can this bay structure be used in the
Conference on Conceptual Structures, Palo Alto, California,
support structure?" or, "Do the constraints match up adequately for
USA, August, 2001.
a particular technology to be used? If yes, tell me the constraints
Carpenter, B. (1992). The Logic of Typed Feature Structures. Cambridge,
Cambridge University Press, 1992.
under which it is usable."
Chang, T.-W. and R. F. Woodbury (1996). "Sufficiency of the SEED
Once again, the work presented here meets the requirements of
Knowledge-Level Representation for Grammatical Design". In
the architects. A query can be represented as a Conceptual Graph.
Proc. Australian New Zealand Conference on Intelligent
The user can specify a type of structure for support, and make the
Information Systems, Adelaide, Australia, IEEE Press,
November, 1996.
query by attempting to unify the structure with the more generic
Chein, M. and M.-L. Mugnier (1992). "Conceptual Graphs: Fundamental
design. If the unification fails, then the user knows that the
Notions." Revue d'Intelligence Artificielle 6(4): 365-406.
proposed structure does not meet the constraints of the design
Corbett, D. R. (2001). "Conceptual Graphs with Constrained Reasoning."
problem. If the graphs unify, then the resulting graph will contain
Revue d'Intelligence Artificielle 15(1): 87-116.
Corbett, D. R. and A. L. Burrow (1996). "Knowledge Reuse in SEED
the constraints which must be met in order to make the design
Exploiting Conceptual Graphs". In Proc. Supplemental
work.
Proceedings of the Fourth International Conference on
Overall, the system of unification over constraints on
Conceptual Structures, Sydney, NSW, Australia, UNSW Press,
Conceptual Graphs presented here gives a set of tools to the
August, 1996.
Corbett, D. R. and R. F. Woodbury (1999). "Unification over Constraints in
designer. The ability to use knowledge combination with
Conceptual Graphs". In Proc. Seventh International Conference
constraints to handle objects at the knowledge level greatly
on Conceptual Structures, Blacksburg, Virginia, USA, Springer-
leverages the ability of the designer to work efficiently.
Verlag, July, 1999.
The software which implements this system is far from being
Flemming, U. and R. F. Woodbury (1995). "Software Environment to
Support Early Phases in Building Design (SEED) Overview."
complete, but the results are consistently as good as those
Architectural Engineering 1(1).
presented in this paper. Several constraints on real values,
Heisserman, J. A. (1991). Generative Geometric Design and Boundary
structure and type can be resolved simultaneously in a system. The
Solid Grammars. PhD Thesis, Department of Architecture,
software will also allow variables in the place of constraints (such
Carnegie Mellon University, Pittsburgh, Penn, USA, 1991.
Heisserman, J. A. (1995). "Generative Geometric Design." IEEE Computer
as [10, n]) and will allow a relaxation of constraints (for example,
Graphics and Applications 14(2): 37-45.
if the interval is only out by 10%). We have not examined the
Leclčre, M. (1997). "Reasoning with Type Definitions". In Proc. Fifth
issue of the compounding of problems caused by relaxing multiple
International Conference on Conceptual Structures, Seattle,
constraints simultaneously.
Washington, USA, Springer-Verlag, August, 1997.
Mugnier, M.-L. and M. Chein (1996). "Représenter des Connaissances et
The software currently has a rough user interface, accepting and
Raisonner avec des Graphes." Revue d'Intelligence Artificielle
displaying Lisp lists. However, note our work with a new CG
10(6): 7-56.
language which has a very friendly user interface in [Benn and
Müller, T. (1997). Conceptual Graphs as Terms: Prospects for Resolution
Corbett 2001]. The pCG system, used as a front-end to the tools
Theorem Proving. Masters Thesis, Department of Computer
Science, Vrije Universiteit Amsterdam, Amsterdam,
described in this paper, will provide an easy user access.
Netherlands, 1997.
Sowa, J. F. (1984). Conceptual Structures: Information Processing in Mind
and Machine. Reading, Mass, Addison-Wesley, 1984.
6
CONCLUSIONS
Wermelinger, M. and J. G. Lopes (1994). "Basic Conceptual Structures
Theory". In Proc. Second International Conference on
We have demonstrated a method for the formal representation of
Conceptual Structures, Maryland, Springer-Verlag, August,
1994.
general architectural designs. The use of Conceptual Graphs is an
Willems, M. (1995). "Projection and Unification for Conceptual Graphs".
efficient method for representing not only the designs, but also
In Proc. Third International Conference on Conceptual
constraints on the designs and knowledge conjunction of designs.
Structures, Santa Cruz, California, USA, Springer-Verlag,
Type hierarchies and the canonical formation rules efficiently
August, 1995.
Woodbury, R., S. Datta and A. L. Burrow (2000). "Erasure in Design Space
specialize the graphs into concrete designs.
Exploration". In Proc. Artificial Intelligence in Design,
The system described in this paper allows general designs to be
Worcester, Massachusetts, USA, June, 2000.
represented as concepts, and also allows those values to be
Woodbury, R. F., A. L. Burrow, S. Datta and T. W. Chang (1999). "Typed
constrained by specifying valid intervals and type hierarchies. In
Feature Structures in Design Space Exploration." Journal of
Artificial Intelligence in Engineering, Design and
our software, we also use inequality relations and allow variables
Manufacturing 13(4): 287-302.
in the constraint specifications. The experiments with this software
have shown these techniques to be useful and efficient.
100
TCP-Nets for Preference-based Product Configuration
Ronen I. Brafman and Carmel Domshlak
Abstract. A good configuration not only satisfies all imposed con-
tainable from the user by non-intrusive means. That is, we should
straints, but does so in the manner most desirable by the user. Thus,
be able to generate it from natural and relatively simple statements
to make good configuration choices, we must have some information
about preferences obtained from the user, and this elicitation process
about the potential user's preferences on alternative designs. In many
should be amenable to automation. In addition, automated reasoning
applications, preference elicitation is a serious bottleneck. The user
with this representation should be feasible and efficient.
either does not have the time, the knowledge, or the expert support
One relatively recent framework for preference representation that
required to specify complex multi-attribute utility functions. In such
addresses these concerns is that of Conditional Preference Networks
cases, a method that is based on intuitive, yet expressive, preference
(CP-nets) [4]. In CP-nets, the decision maker is asked to describe
statements is required. In this paper we suggest the use of TCP-nets,
how her preference over the values of one variable depends on the
an enhancement of CP-nets, as a tool for representing, structuring,
value of other variables. For example, she may state that her prefer-
and reasoning about qualitative preference statements. We present
ence for a dessert depends on the value of the main-course as well
and motivate this framework, define its semantics, and show why it
as whether or not she had an alcoholic beverage. Her choice of an
is particularly suitable for the task of configuration.
alcoholic beverage depends on the main course and the time of day.
This information is described by a graphical structure in which the
nodes represent variables of interest and the edges represent depen-
1
INTRODUCTION
dence relations between the variables. Each node is annotated with a
The ability to make decisions and to assess potential courses of ac-
conditional preference table (CPT) describing the user's preference
tion is a corner-stone of many AI applications in general, and of
over alternative values of this node given different values of the par-
configuration problems in particular. To make good decisions, we
ent nodes.
must be able to assess and compare different alternatives. Some-
CP-nets capture a class of intuitive and useful natural language
times, this comparison is performed implicitly, as in many recom-
statements of the form "I prefer the value
for variable
given
¤¦Ą
§
mender systems. However, in many cases explicit information about
that
and
". Such statements do not require com-
Ą
Ą
¨©
©
the decision-maker's preferences is required.
plex introspection nor a quantitative assessment. However, there is
In classical decision theory and decision analysis a utility func-
another class of statements that is no less intuitive or important. They
tion is used to represent the decision-maker's preferences. Utility
have the following form: "It is more important to me that the value
functions are a powerful form of knowledge representation. They
of
be high than that the value of
be high." We call these relative
§
¨
provide a quantitative measure of the desirability of different out-
importance statements. For instance, one might say "The length of
comes, capture attitude toward risk, and support decision making un-
the journey is more important to me than the choice of airline". A
der uncertainty. However, the process of obtaining the type of infor-
more refined notion, though still intuitive and easy to communicate,
mation required to generate a good utility function is involved and
is that of conditional relative importance: "The length of the journey
time-consuming and requires non-negligible effort on the part of the
is more important to me than the choice of airline provided that I am
user. In some application, this effort is necessary and/or possible,
lecturing the following day. Otherwise, the choice of airline is more
e.g., when either uncertainty plays a key role, or the stakes involved
important." This latter statement is of the form: "A better assignment
are high, and when the decision-maker and the decision analyst are
for
is more important than a better assignment for
given that
§
¨
able and willing to engage in the required preference elicitation pro-
." Notice that information about relative importance is dif-
©Ą
cess. One would expect to see such effort invested when, for exam-
ferent from information about independence. In the example above,
ple, medical decisions are involved. However, there are many appli-
my preference for an airline does not depend on the duration of the
cations where either uncertainty is not a crucial factor, or the user
journey because, e.g., I compare airlines based on their service and
cannot be engaged for a lengthy period of time (e.g., in on-line prod-
security levels and the quality of their frequent flyer program.
uct recommendation systems), or the preference elicitation process
In this paper we present an extension of CP-nets, which we call
cannot be supported by a human decision analyst and must be per-
TCP-nets (for tradeoffs-enhanced CP-nets), show how they can be
formed by a software system (e.g., because of replicability or mass
used to compute optimal outcomes given constraints, and discuss
marketing aims). In such cases, elicitation of a good utility function
their applicability to the process of product configuration. TCP-nets
is not a realistic option.
capture both information about conditional independence and about
When a utility function cannot be or need not be obtained, one
conditional relative importance. Thus, they provide a richer frame-
should resort to other, more qualitative forms of preference repre-
work for representing user preferences, allowing stronger conclu-
sentation. Ideally, this qualitative information should be easily ob-
sions to be drawn, yet remain committed to the use of intuitive, quali-
tative information as their source. Naturally, one can consider relative
ˇ
Both
authors
are
from
Computer
Science
Dept.,
Ben-Gurion
importance assessments among more than two variables. However,
University,Beer-Sheva, Israel, email: brafman,dcarmel @cs.bgu.ac.il
˘
Ł
101
we feel that such statements are somewhat artificial and less natural
independence. Intuitively,
and 7
are conditionally preferentially
6
to articulate.
independent given
if for every fixed assignment to
, the ranking
Y
Y
This paper is organized as follows. Section 2 describes the no-
7
of
elements is independent of the value of the
elements. For-
6
tions underlying TCP-nets: preference relations, preferential inde-
mally, let
7
and
be a partition of
and let
D
%
.
and
6`ˇ
Y
a
"$#bY
6
pendence, and relative importance. In Section 3 we define TCP-nets,
7
are conditionally preferentially independent given
iff, for all A ˇ ,
a
and provide a number of examples. Section 4 shows how TCP-nets
AUB
,
B
ˇ
,
we have that
P
P
can be used to perform constrained optimization. Section 5 provides
Ą
Ą
B
B
B
B
A
A
A
A
a discussion of using TCP-nets in product configuration. In this short
ˇ
ˇ
ˇ
ˇ
VXW
P
a
P
a
P
a
P
a
version, we emphasize intuitions and motivation. The technically full
7
and
are conditionally preferentially independent given
if they
version of this paper [5] contains the formal semantics of TCP-nets,
6
Y
are conditionally preferentially independent given any assignment
discussion of consistency analysis for various TCP-nets, and a fuller
D
%
. Returning to our PC example, the user may assess op-
discussion of the optimization problem.
a
"$#bY
erating system to be independent of all other features given proces-
sor type. That is, it always prefers LINUX given an AMD processor
2
PREFERENCE ORDERS, INDEPENDENCE,
and Windows98 given an Intel processor (e.g., because he might be-
AND RELATIVE IMPORTANCE
lieve that Windows98 is optimized for the Intel processor, whereas
LINUX is otherwise better).
In this section we describe the ideas underlying TCP-nets: prefer-
ence orders, preferential independence and conditional preferential
independence, as well as relative importance and conditional relative
2.2
Relative Importance
importance.
Although statements of preferential independence are natural and
useful, the orderings obtained by relying on them alone are relatively
2.1
Preferences and Independence
weak. To understand this, consider two preferentially independent
boolean attributes
and
with values
B
B
ˇ
and
ˇ
, respec-
A preference relation is a total pre-order (a ranking) over some set
c
d
e
ˇQe
f
ˇQf
¤
¤
tively. If
and
are preferentially independent, then we can specify
of outcomes. Given two outcomes
, we write
Ą
to denote
c
d
˘ˇŁ
B
ˇ
¤
¤
a preference order over
values, say
, independently of the
that
is at least as preferred as
and we write
to denote that
c
e
¦3e
§¦¨
B
ˇ
¤
¤
value of
. Similarly, our preference over
values, say
, is
is strictly more preferred than
. Finally, if
and
are equally
d
d
f
¦gf
ˇ
ˇ
¤
independent of the value of
. From this we can deduce that
is
preferred, we write
.
c
e
f
©
the most preferred outcome and B
B
is the least preferred outcome.
The types of outcomes we are concerned with consist of possi-
e
f
However, we do not know the relative order of
B
B
ˇ
and
ˇ
. This is
ble assignments to some set of variables. More formally, we assume
e
f
e
f
typically the case when we consider independent variables. We can
some given set
ˇ
of variables with corresponding
©
§
ˇˇ
§
!
rank each one given a fixed value of the other, but often, we cannot
domains
ˇ
&%
%
. The set of possible outcomes is then
"$#
§
ˇ'ˇ(")#
§
compare outcomes in which both values are different. One type of
ˇ
&%10322240
%
. For example, in the context of the prob-
"$#
§
"$#
§
information that can address some (though not necessarily all) such
lem of configuring a personal computer (PC), the variables may be
comparisons is information about relative importance. For instance,
processor type, screen size, operating system etc., where screen size
if we say that
is more important than
then this means that we
has the domain 17in, 19in, 21in , operating system has the domain
c
d
prefer to reduce the value of
rather than reduce the value of
. In
LINUX, Windows98, WindowsXP , etc. Each assignment to the set
d
c
that case, we know that
B
B
ˇ
ˇ
, and we can (totally) order the
of variables specifies an outcome a particular PC configuration.
e
f
¦e
f
set of outcomes as follows
Thus, an ordering over these outcomes specifies a ranking over pos-
sible PC configurations.
B
B
B
B
ˇ
ˇ
ˇ
ˇ
e
f
¦¨e
f
¦¨e
f
¦¨e
f
The number of possible outcomes is exponential in
, while the
5
set of possible total orders on them is doubly exponential in
.
Returning to our PC configuration example, suppose that operating
5
Therefore, an explicit representation and an explicit specification of
system and processor type are independent attributes. We might say
a ranking are not realistic. We must find implicit means of describ-
that processor type is more important than operating system, e.g, be-
ing this preference relation. Often, the notion of preferential inde-
cause we believe that the effect of the processor's type on system
pendence plays a key role in such representations. Intuitively,
and
performance is much more important than the effect of the operating
6
7
are preferentially independent if for all assignments
system.
©
8@96
to 7 , our preference over
values are identical. More formally, let
Formally, let
and
be preferentially independent given
6
§
¨
h
©
A
ACBED
%
2
%
ˇ
for some
(where we use
to denote the
. We say that
is more important than
, denoted
ˇ
"$#F6
6HGI
"$#
i9R§pˇ
¨
q
§
¨
7
domain of a set of variables as well), and let
BED
D
%
ˇ
, where
by
, if for every assignment
%
and for every
P
ˇQP
"$#
§
sr
¨
t
"$#uh
7
. We say that
is preferentially independent of 7
iff,
such that
given
and
given
,
©
RS9T6
6
¤
!vQˇ
¤
˘wxˇ
y˘ˇ
¤
v¦
¤
˘w
t
¦y
t
for all
B
B
A
ˇ
, A
,
ˇ
,
we have that
we have that:
P
P
¤
t8¦
¤
Qtp
v
y
w
Ą
Ą
A
AUB
A
B
ACB
B
ˇ
ˇ
ˇ
UVXW
ˇ
P
P
P
P
Notice that this is a strict notion of importance any reduction in ¨
For example, in our PC configuration example, the user may assess
is preferred to any reduction in
.2 When both
and
are binary
§
§
¨
screen size to be preferentially independent of processor type and
variables and
B
B
ˇ
and ˇ
hold given
then
iff we
¤
¦
¤
¦
t
§
r
¨
operating system. This could be the case if, for instance, the user
have
B
B
D
%
ˇ
ˇ
for all
.
¤
t8¦
¤
t
t
"$#uh
always prefers a larger screen to a smaller screen, no matter what the
B
We note that this idea can be refined by providing an actual ordering over
processor or the OS are.
elements of
. We have decided not to pursue this option farther
§
Preferential independence is a strong property, and therefore, less
because it is less natural to specify. However, our results generalize to such
common. A more refined notion is that of conditional preferential
specifications as well.
102
Relative importance information is a natural enhancement of in-
preferences over the values of
depend on the actual value of
§
w
dependence information. It retains the property we value so much:
.
§
v
it corresponds to statements that a naive user would find simple and
3.
is a set of directed -arcs
ˇ
(where stands for impor-
0
ˇ'ˇ021F
clear to evaluate and articulate. Moreover, it can be generalized nat-
9b9
9
9
3'
tance). An -arc
%
belongs to
iff
.
#
§
ˇ
§
§
§
r
§
v
w
v
w
urally to a notion of conditional relative importance. For instance,
4.
is a set of undirected
-arcs
ˇ
(where
stands for
4
ˇˇ465
suppose that the relative importance of processor type and operating
conditional importance). A
-arc
%
belongs to
iff we
#
§
ˇ
§
§
v
w
system depends on the primary usage of the PC. For example, when
have
%
for some
.
¤¦Ą
#
§
ˇ
§
ˇ&Y
Y3G¨
9
§
ˇ
§
v
w
v
w
the PC is used primarily for graphical applications, then the choice
5.
associates a CPT with every node
D
. A CPT is from
§
of an operating system is more important than that of a processor be-
¨
%Q%
(i.e., assignment's to
's parent nodes) to total pre-
"$#
e
#
§
§
cause certain important software packages for graphic design are not
orders over
%
.
"$#
§
available on LINUX. However, for other applications, the processor
6.
associates with every
edge (
) a subset
of
§
ˇ
§
Y
9
v
w
type is more important because applications for both Windows and
and a mapping from a subset of
%
to total orders
§§vŁˇ
§
Ew
"$#bY
LINUX exist. Thus, we say that
is more important than
given
over the set
. We call
the selector set of
%
and
§
¨
a
§
vŁˇ
§
w
Y
#
§
vŁˇ
§
Ew
if we always prefer to reduce the value of
rather than the value of
denote it by
%
.3
¨
7
E#
§
ˇ
§
v
w
when
holds.
§
a
Formally, let
be as above, and let
. We say that
We note that the following holds for every node
in the graph:
§
§
pˇ
¨
ˇQh
Y
G
h
is more important then
given an assignment
D
%
%
(ceteris
is independent of all other nodes given ¨
.
§
e
#
§
§
¨
a
"$#bY
paribus) iff, for any assignment
ˇ
D
%
we
In the rest of this section we provide examples of TCP-net. We
t
h
©
S9#b
§
pˇ
¨
q
Y
have:
start with an example of a CP-net shown in Figure 1. A CP-net is a
TCP-net in which the sets and
(and therefore
) are empty.
¤
v
y
atS¦
¤
xw
at
whenever
given
and
given
. We denote this
¤
v
¦
¤
˘w
at
¦
y
at
'&%$
!"#
8
'&%$
!"#
9
D
E
E
B
H
relation by
.
ˇ
GF
§
8rŁ˘
¨
D
I
I
%P
P
P
Ő
B
H
F
ˇ
Finally, if for some
D
E
I
E
I
@
D
%
we have that either
, or
B
B
B
V
a
"$#bY
§
ir
¨
˘
'&
!%$"#
ˇ
QP
ˇ
P
ˇ
GF
SRq
QTU
U
, then we say that the relative importance of
and
is
E
I
E
I
B
B
B
H
ˇ
QP
P
ˇ
F
ˇ
¨
r
§
§
¨
˘
SRq
QTU
U
D
conditioned on
, and write
B
V
B
B
H
ˇ
ˇ
XF
F
ˇ
A
%
.
'&
!%$"#
U
T#W
W
U
T W
W
Y
¤¦Ą
#
§
pˇ
¨
ˇ&Y
D
B
#V
B
B
H
ˇ
ˇ
GF
F
ˇ
W
T Y
Y
W
T Y
Y
%P
P
P
Ő
D
B
B
B
V
H
ˇ
ˇ
ˇ
F
F
F
F
W
T`
`
`a
W
T`ba
`
`
3
TCP-NETS
'&%$
!"#
B
'&%$
!"#
C
TCP-nets (for conditional preference networks with tradeoffs) are a
Figure 1.
An example CP-net
graph-based representation that encodes statements of (conditional)
preferential independence and (conditional) relative importance. We
Example 1 The CP-net in Figure 1 is defined over the variables
use this graph-based representation for two reasons: First, it is an in-
; all variables are binary except for the three-
c1ˇŁdqˇ!cˇdˇeˇf1
tuitive visual representation of preference independence and relative
valued
. The decision maker specifies unconditional preference
f
importance statements. Second, the structure of the graph has im-
over the values of
(denoted in figure by
B
ˇ
). However, if
e
e
¦
e
portant consequences to issues such as consistency and complexity
B
B
ˇ
and
the decision maker prefers
to ˇ (denoted by
c
©
ge
d
©
f
g
g
of reasoning. For instance, one of the basic results we present in [5]
B
B
%
Xp
ˇ
ih
ˇ
).
#ue
f
g
¦
qg
shows that when this structure is "acyclic," (for a suitable definition
Now consider the CP-net above and the following three outcomes:
of this notion) then the preference statements contained in the graph
B
bs
B
ut
B
B
B
bs
B
t
B
B
s
B
t
B
ˇ
ˇ
ˇ
r
,
ˇ
ˇ
r
, and
ˇ
ˇ
r
ˇ
.
$
©
He
f
g
0
©
He
f
g
4
©
He
f
g
are consistent that is, there is a total pre-order that satisfies them.
and
assign the same values to all variables except
.
assigns
$
0
c
$
TCP-nets are annotated graphs with three types of edges. The
to
a value that is preferred to the value
assigns to see given the
c
0
¨
nodes of a TCP-net
correspond to the problem variables
. The
assignment to the parents of
(denoted
%
). Therefore,
c
e
#
3c
$
3¦v0
§
first type of (directed) edges signifies preferential dependence. The
is a consequence of this CP-net. The same argument applies to
and
0
existence of such an edge from
to
implies that the user has
, with respect to the variable
, and thus,
is a consequence
4
d
0
¨¦w4
§
¨
different preferences over values of
given different values of
.
of this CP-net as well.
cannot be derived directly from the
$
¦
x4
§
¨
The second type of (directed) edges captures relative importance re-
CP-net above. However, this relation can be inferred via transitivity
lations. The existence of such an edge from
to
implies that
is
from
and
.
$
¦
y0
0
¦y4
§
¨
§
more important than
. Finally, the third, undirected, edge type sig-
¨
In the following examples all variables are binary, although the
nifies conditional importance relations. Nodes
and
are linked if
§
¨
semantics of both CP-net and TCP-net is defined with respect to ar-
there exists some
for which
%
holds.
Y
¤¦Ą
#
§
pˇ
¨
ˇ&Y
bitrary finite domains.
Each node
in a TCP-net is annotated with a conditional pref-
§
erence table (CPT). This table associates a preferences over
%
"$#
§
Example 2 Figure 2(a) illustrates a simple CP-net over three vari-
for every possible value assignment to the parents of
(denoted
§
ables
,
, and
;
is unconditionally preferred over , and
is
¨
c
d
c
e
e
f
%
). Each undirected arc is annotated with a conditional impor-
e
#
§
unconditional preferred over , while the preference relation over the
tance table (CIT). The CIT associated with the arc between
and
f
§
¨
values of
is conditioned on both
and
. The solid lines in Fig-
describe the relative importance of
and
given the possible value
c
c
d
§
¨
ure 2(c) show the preference relation over outcomes that this CP-net
of the conditioning variables.
induces. The top element is the worst outcome while the bottom ele-
Formally, a TCP-net
is a tuple
, where
§
©
u
ˇ
xˇ
ˇ
ˇ
ˇ
!
"
ment is the best one. Arrows are directed from less preferred to more
1.
is a set of nodes, corresponding to the problem variables.
preferred outcomes.
2.
is a set of directed
-arcs
ˇ
(where
stands for
a
#
$
ˇ'ˇ$&%
Naturally we expect this set
to be the minimal context upon which the
conditional preference). A
-arc 9 9 9 9('
belongs to
iff the
relative importance between
and
depends.
v
w
©
§
v(ˇ
§
Ew)"
§
103
4
PREFERENTIAL CONSTRAINT-BASED
Ł
˘ˇ¤Ł
Ą¦ˇ
Ą
OPTIMIZATION
'&%$
!"#
'&
!
9
%$
"#
8
We now discuss the problem of constraint-based optimization given
'V
V
V
V
V
Ň
ÖÖÖÖÖ
'&%$
!"#
a TCP-net and a set of constraints. We restrict ourselves to a class of
@
'
o
conditionally acyclic TCP-nets. This class is formally defined in the
§Ą
¨©ˇ¤Ł
¨
full paper. Inituitively, conditional acyclicity is an extension of the
Ł
Ą
Ł
¨©ˇ¨
Ł
§Ą
Ł
¨©ˇ¨
notion of acyclicity to a graph in which the direction of an edge is
G
t
iiiiiiiiiiiiii
Ł
Ł
Ą
¨©ˇ¤Ł
¨
conditional on the value of some of the nodes as in TCP-nets.
(a)
Given a TCP-net
and a partial assignment to its variables, it
§
'&%$
!"#
G
7
u
u
u
u
u
u
0
'&
!
9
%$
"#
8
is simple to determine an outcome consistent with this assignment
that is preferentially optimal with respect to
, as shown in [4]. We
'V
V
V
V
V
Ň
§
ÖÖÖÖÖ
'&%$
!"#
Ó |
@
traverse the variables in some topological order induced by the CP-
net part of
and set each unassigned variable to its most preferred
(b)
§
(c)
value given its parents' values. The relative importance relations do
Figure 2.
Illustrations for Example 2.
not play a role in this case.
If some of the TCP-net variables are mutually constrained by a set
5
of hard constraints,
, then determining the set of Pareto-optimal 4
Figure 2(b) displays a TCP-net that extends the CP-net above by
feasible outcomes is not trivial. A branch and bound algorithm for
adding an -arc from
to
. Thus,
is absolutely more important
c
d
c
determining such the set of optimal feasible outcomes with respect
than the
. This induces additional relations among outcomes, cap-
d
to an acyclic CP-net was introduced in [3]. This algorithm has the
tured by the dashed lines in Figure 2(c).
important anytime property once an outcome is added to the cur-
rent set of non-dominated outcomes, it is never removed. Figure 4
presents a modified version of this algorithm that works with condi-
tionally acyclic TCP-nets and retains the anytime property.
˘ˇ¤Ł
'&%$
!"#
8
The algorithm in Figure 4 uses the topology of the TCP-net to
Ł
order the variables during the search process. More important vari-
Ą¦ˇ
Ą
Ł
Ł
Ą¦ˇĄ
'&%$
!"#
G
8
'&%$
!"#
'&
!B%$"#
9
ables, i.e., variables that are "higher-up" in the network, are assigned
Ą
¨ˇŁ
¨
values first. Each variable is assigned the most preferred value in the
Ł
Ą
Ł
¨ˇ¨
% &
'
'&%$
!"#
Ó
×××××
'U
U
U
U
U
current context that does not violate the constraints. Thus, by care-
A
9
'&%$
!"#
B
'&%$
!"#
@
$
'&
!%$"#
ˇ!Ł
ful selection of variables and values, we ensure that new solutions
Ą(
)1032
cannot dominate solutions that were found earlier.
Ł
Ô
Ł
Ą
"#ˇ
"
&S
S
S
S
S
Ą(
2!03)
Ł
Ł
An important element of the algorithm is the test performed in the
Ą
"#ˇ"
'&%$
!"#
@
'&
!A%$"#
Ą4Ł
2!03)
line before last in the
routine. There, candidate solutions are
687@9BA
DC
compared against the set of current solutions. In [4], this compari-
Figure 3.
Illustrations for Example 3.
son is referred to as dominance testing. We discuss the algorithm in
more detail, and dominance testing in particular, in the full paper.
However, it is important to stress that this element of the algorithm
is where constrained optimization and constraint satisfaction differ.
Example 3 Figure 3(a) illustrates a CP-net over five variables
,
,
c
d
However, this difference shows up only when (1) more than a sin-
,
, and
. Figure 3(b) presents a TCP-net that extends this CP-net
c
d
e
gle optimal solution is required (because dominance testing is not
by adding an -arc from
to
and a
-arc between
and
. The
d
e
c
d
applied until we generate the first solution), and (2) dominance test-
relative importance of
and
depends on the assignment to
and
c
d
d
ing is hard. In CP-nets, [6] shows that when the graph is a polytree,
. When
and
are assigned s , then
. When
and
are
e
d
e
f
c
3r
d
d
e
dominance testing is polynomial. In that case, the complexity of the
assigned s or s , then
. Finally, when
and
are assigned
f
f
d
r
c
d
e
procedure is analogous to that of generating all feasible so-
687@9BA
DC
s
, the relative importance between
and
is unspecified. The CIT
f
)
c
d
lutions. However, in more complex networks, dominance testing in
of this
-arc is also presented in Figure 3(b).
CP-nets, and therefore, in TCP-nets, is NP-hard.
Depending on the application, a typical process of constructing a
5
TCP-NETS FOR PRODUCT
TCP-net would commence by asking the decision maker to identify
CONFIGURATION
the variables of interest, or by presenting them to the user, if they are
fixed. For example, in the application of CP-net to web-page config-
During the last decade, the configuration problem received consider-
uration presented in [7], the web-page designer chooses a set of con-
able attention both in academia and industry. Informally, a configu-
tent elements, which correspond to the set of variables. In the case
ration problem is characterized by two key features [19]:
of an online shopper-assistent agent, the variables (e.g., the possible
components of a PC) are likely to be fixed. Next, the user is asked
1. The artifact being configured is assembled from instances of a
to consider for each variable, the value of which other variable influ-
fixed set of well-defined component types, and
ences her preferences over the values of this variable. At this point
2. Components interact with each other in predefined ways.
cp-edges and CPTs will be introduced. Next, the user will be asked
to consider relative importance relations, and the and
edges will
E
An outcome
is said to be Pareto-optimal with respect to some preference
F
¤
¤
be added. For each
edge, the corresponding CIT will be filled.
order F
and a set of outcomes
if there is no other
such that
F
.
G
F
F
F
104
Search ( , ,
)
constrained problems that should be relaxed. They incorporate pref-
ˇ
˘
Input: Conditionally acyclic TCP-net
, Constraints
,
erence information by attaching truth values to constraints, not to
ˇ
Context
(partial assignment on some variables of the original TCP-net)
˘
the variables or variable values. Therefore, this area is mainly about
Output: Set of all solutions for
that are Pareto-optimal w.r.t.
ˇ
optimization of partial constraint satisfaction, and not about solution
Choose any variable
s.t. there is no
-arc
,
optimization in face of constraint satisfaction.
ŁĄ¤
¦¨§©§
b
no -arc
, and no
in
.
We believe that the TCP-net model provides a good, and in many
§©§
bq
Let
ˇ
GF! "
F
be the preference ordering of
respects unique, basis for a preference-based configuration frame-
1
q
%
given the assignment on
in
.
#
q
˘
work because of the following reasons:
Initialize the set of local results by $&%!'
for
V
V
do
)(0%
(2143
(6575
1. The development of the CP-net, and subsequently of the TCP-net
8%9
v
Strengthen the constraints
by
to obtain
models, was guided by the naturalness of the represented state-
ˇ
@%9
ˇ
v
v
if
for some
or
is inconsistent then
ments. Therefore, the preferential statements that are captured by
ˇ
ˇ
CED7(
ˇ
w
BA
v
v
continue with the next iteration
TCP-nets are likely to be found intuitive for users at all levels. In
else
¤
particular, we argue that all the preferential statements that were
Let
be the partial assignment induced by
and
˘
@%F
ˇ
v
v
¤
= Reduce (
,
)
discussed in [15] can be captured by a TCP-net.
˘
v
ˇ
Let
5
G "
be the components of
that are connected
2. The TCP-net model is graphical, and its structure is induced by the
H
v
v
v
either by the edges of
or by the constraints
.
ˇ
v
v
assumptions of preferential independence between the problem
for
V
V
do
CI%
CE17P
CQ575
variables. This structure can be utilized in developing specialized
¤
w
= Search (
w
)
$
R˘4ST˘
Rˇ
v
v
v
algorithms that exploits various properties of this structure [6].
if
w
for all
then
$
%!'
CB1VP
v
EU
ˇ
¤
0`
`baaac`
Note that exploiting advantages of graphical, independence-based
foreach
5
do
F
XWY˘
$
$
v
v
¤
¤
a
a
if for each
holds
representation models is widely accepted in AI, and in particular
F
then Add
to
F
W$
˘
F
˘
F
F
$
U
return
in utility representation [1, 17], constraint satisfaction [22], and
$
¤
Reduce (
,
)
probabilistic reasoning [18].
˘
¤
foreach
do
3. The TCP-net model has a well-defined semantics in terms of qual-
˘
&8%F
Ł
IW˘
v
foreach
-arc
do
itative decision theory. This allows for a clear and clean analysis
§c§e
Łd¤
¦
IfWg
Restrict the CPT of
to the rows dictated by
.
8%9
v
of its expressiveness and its computational properties with respect
foreach
-arc
B
ˇ
s.t.
do
ŁG
hi%¨
fWg
pWq
)h
Restrict the CIT of
to the rows dictated by
.
to inference, consistency, etc.
h
8%F
v
if, given the restricted CIT of , relative importance
4. The branch and bound CSP algorithm that is guided by a TCP-
h
between
B
ˇ
and
is independent of
, then
q
rh
net has two important properties: First, this algorithm is anytime,
if CIT of
is not empty then
h
i.e., once a solution is added to the generated set of Pareto-optimal
Replace
by the corresponding -arc.
h
else Remove .
solutions, it is never removed from this set. Second, if we can be
h
Remove from
all the edges involving
. return
.
satisfied by one Pareto-optimal solution, then its generation is not
harder than the generation of a single feasible solution. In general,
Figure 4.
Search Algorithm for Non-dominated Outcomes
these properties are rare in the world of constraint optimization.
In what follows, we address some additional issues that may be found
Therefore, selecting and arranging combinations of parts that sat-
important in the context of preference-based configuration.
isfy given specifications form a core of the configuration task. While
First, in decision theory, the preference order reflects the prefer-
there has been a wide and growing research in modeling configu-
ences of a decision maker. The typical decision maker in preference-
ration problem, and efficient problem solving methods, there is still
based product configuration is the consumer. However, in some do-
a need for more work on modeling and learning user preferences,
mains, the product vendor may decide that customer's preference
and using these to achieve configurations that are not only feasi-
elicitation is inappropriate, or simply impossible. In this case, the
ble, but also satisfactory from the user point of view. The necessity
role of the decision maker may be relegated to a product expert, since
of these issues is emphasized by almost every paper on configura-
she is likely to have considerable knowledge about appropriate com-
tion, e.g. [10, 11, 13, 15, 21], especially when high-level configura-
ponent combinations. Given some information about the customer,
tors [11] for particular, real-life domains are discussed. The impor-
such a product expert can argue about the expected preferences of
tance of seeing user preferences as a part of the configuration prob-
this customer. Following an example in [15], in case of a car config-
lem mostly entailed from the fact that it is often the case that many
uration, the expert may determine that if the customer is young and
configuration problems, e.g. product configuration, are weakly con-
a male then he is likely to prefer white cars on red cars, or that the
strained and have numerous solutions. The value of these solutions,
fashioned look is a more important parameter than reliability. In this
from the subjective point of view of a particular user, may vary sig-
case, the product expert may specify a TCP-net over the variables
nificantly between the solutions.
that stand for parameters of both the product and the customer. The
Recently, the issue of user preferences as a part of the configura-
latter variables will serve as network parameters, and will be instan-
tion problem has received considerable attention in the configuration
tiated at the beginning of each session of personalized configuration,
community. Modeling tradeoffs as additional constraints on the con-
given some personal information about the customer. Clearly, each
figuration problem was addressed in [10]. Preference-based search
such variable will be a root variable in the TCP-net it will not par-
that is guided to preferred solutions was introduced in [14]. A prefer-
ticipate neither in
-arcs nor in -arcs, and it will have only outgoing
ence programming framework which is based on a logical approach
-arcs. However, it may serve as a selector variable in some
-arcs
#
for treating preferences was proposed in [15]. In addition, various ap-
of the network.
proaches for modeling and dealing with soft constraints as a part of
Note that relegation of the role of the decision maker from the
the constraint satisfaction process have been closely examined in the
customer may be done because of various reasons. For example, [7]
CSP community [2]. However, the latter approaches address over-
presents a CP-net based approach for configuration of presentations,
105
which is illustrated on web pages. In this approach, the process of
very special manner. This may allow us to develop specialized tech-
interactive document presentation is viewed as a configuration prob-
niques and tools for understanding the corresponding language. Fi-
lem whose goal is to determine the optimal document appearance
nally, both offline and online language understanding should be con-
while taking into account the preferences of the document's author,
sidered, since a user can either describe her preferences offline, as a
e.g. an editor of an online newspaper, and viewer interaction with the
self-contained text, or can be asked online, as a part of interactive
document.
process of (possibly mixed) preference elicitation and preference-
An additional issue that, at least in some cases, can be addressed
based constraint optimization [3].
naturally using the TCP-net model, is non-rigidness of the variable
set [16, 19, 20, 23]. As it is argued in [19], different components
REFERENCES
for the same functional role may need nonidentical sets of additional
components, or functional roles. In this case, the set of variables in
[1] F. Bacchus and A. Grove, `Graphical Models for Preference and Util-
a solution changes dynamically on the basis of assignments of val-
ity', in Proc. of UAI-95, pp. 310, (1995).
[2] S. Bistarelli, H.Fargier, U. Montanari, F. Rossi, Thomas Schiex, and
ues to other variables. Now, consider a variable
that, for instance,
§
Gerard Verfaillie, `Semiring-Based CSPs and Valued CSPs: Frame-
stands for a particular functional role. Observe that nothing in the se-
works, Properties, and Comparison', Constraints, 4(3), 275316,
mantics of the TCP-net prevents one of the values in the domain of
(September 1999).
to stand for the absence of
. This way, the presence/absence of
[3] C. Boutilier, R. Brafman, C. Geib, and D. Poole, `A Constraint-Based
§
§
Approach to Preference Elicitation and Decision Making', in AAAI
some variables may condition the presence of some other variables,
Spring Symposium on Qualitative Decision Theory, Stanford, (1997).
their relative importance, and the preference on their values. Note,
[4] C. Boutilier, R. Brafman, H. Hoos, and D. Poole, `Reasoning with Con-
that the former conditionings are entailed by the activity constraints
ditional Ceteris Paribus Preference Statements', in Proc. of UAI-99, pp.
on the variables, which are defined by the core configuration prob-
7180, (1999).
lem, and not by the preferences of a user. In this case, they can be
[5] R. Brafman and C. Domshlak, `Introducing Variable Importance Trade-
offs into CP-Nets', in Proc. of UAI-02, (2002).
added into the TCP-net automatically, after the preference elicitation
[6] C. Domshlak and R. Brafman, `CP-nets - Reasoning and Consistency
stage, by a straightforward extension of the specified TCP-net. Such
Testing', in Proc. of KR-02, (2002).
an approach of automatic extension of CP-nets was exploited in [8]
[7] C. Domshlak, R. Brafman, and S. E. Shimony, `Preference-based Con-
for preference-based presentation of tree-structured multimedia doc-
figuration of Web Page Content', in Proc. of IJCAI-01, pp. 14511456,
(2001).
uments. In this domain, (i) the preferences on the value (= option of
[8] C. Domshlak and S. E. Shimony, `Predicting Likely Components in CP-
content appearance) of a document's component may be conditioned
net based Multimedia Systems', Technical Report CS-01-09, Dept. of
by the value of some other components, and (ii) whether it should be
Computer Science, Ben-Gurion Univ., (2001).
shown or hiden depends directly on which of its ancestors are shown
[9] E. Freuder, C. Likitvivatanavong, and R. Wallace, `Explanation and Im-
and which are hidden.
plication for Configuration Problems', in Proceedings of 4th Workshop
on Configuration (IJCAI-01), pp. 3137, Seattle, US, (August 2001).
Note that we are not claiming that this approach will be feasible
[10] E. Freuder and B. O'Sullivan, `Modeling and Generating Tradeoffs
and/or natural for any dynamic preference-based configuration task.
for Constraint-Based Configuration', in Workshop on Configuration
However, if it will, then one of the benefits seems to be the fact that
(IJCAI-01), (2001).
this task could be treated exactly as it was static, using the
[11] A. Haag, `Sales Configuration in Business Processes', IEEE Intelligent
6
7
9BA
C
Systems and their Appl., 13(4), 7885, (1998).
algorithm (see Figure 4). Of course, if the variable set of the problem
[12] G. James, `Challenges for Spoken Dialogue Systems', in Proceedings
is very dynamic, then the complexity of an automatically extended
of the IEEE ASRU Workshop, (1999).
TCP-net may be high, and thus efficient consistency verification of
[13] U. Junker, `A Cumulative-Model Semantics for Dynamic Preferences
the specified preference relation is important. For discussions and
on Assumptions', in Proc. of IJCAI-97, pp. 162167, Nagoya, Japan,
results on this issue we refer our reader to [6, 5].
(August 1997).
[14] U. Junker, `Preference-based Search for Scheduling', in Proceedings
Another issue of the configuration process in which the TCP-net
of Seventeenth National Conference on Artificial Intelligence, pp. 904
model seems to be beneficial, is explanation generation for users [9].
909. AAAI Press, (August 2000).
The goal of an explanation for a generated configuration is to help
[15] U. Junker, `Preference Programming for Configuration', in Workshop
the user understand the decisions that were taken during the search
on Configuration (IJCAI-01), pp. 5056, Seattle, US, (August 2001).
[16] S. Mittal and B. Falkenhainer, `Dynamic Constraint Satisfaction Prob-
process, e.g. why this particular configuration was chosen. The im-
lem', in Proceedings of the Eighth National Conference on Artificial
portance of explanation is even more significant if the configuration
Intelligence, pp. 2532. AAAI Press, (1990).
task is preference-based, i.e., it is about optimization, not only satis-
[17] P. La Mura and Y. Shoham, `Expected Utility Networks', in Proc. of
faction. It seems reasonable to build an explanation in respect to the
UAI-99, (1999).
values of the variables in the accepted solution according to the same
[18] J. Pearl, Probabilistic Reasoning in Intelligent Systems: Networks of
Plausible Inference, Morgan Kaufmann, San Mateo, CA, 1988.
order that these variables were examined during the search. Recall
[19] D. Sabin and R. Weigel, `Product Conguration Frameworks - A Sur-
that the flow of the
algorithm in Figure 4 is guided by the
vey', IEEE Intelligent Systems and their Appl., 13(4), 4249, (1998).
6
7
9BA
C
structure of the TCP-net. If so, then this structure may be exploited
[20] T. Soininen and E. M. Gelle, `Dynamic Constraint Satisfaction in
during the explanation generation. However, this issue is not in the
Conguration', in Proceedings of AAAI Workshop on Conguration,
(1999).
scope of this paper, and we leave it as a possible direction for future
[21] T. Soininen and I. Niemel¨a, `Formalizing Configuration Knowledge Us-
research.
ing Rules with Choices', in Int. Workshop on Nonmonotonic Reasoning,
One of the interesting applicative issue in the framework of elicita-
(1998).
tion of qualitative preferences is model acquisition from speech/text
[22] E. Tsang, Foundations of Constraint Satisfaction, Academic Press,
in natural language [12]. Observe that the intuitiveness of the qual-
1993.
[23] M. Veron and Aldanondo, `Yet Another Approach to CCSP for Con-
itative preferential statements is highly related to the fact that, at
figuration Problem', in Proceedings of 3rd Workshop on Configuration
least most of them, have a straightforward representation in natu-
(ECAI-00), Berlin, Germany, (August 2000).
ral language of everyday life. In addition, collections of preferential
statements seems to form a domain that is apriori constrained in a
106
Neural networks to approximate data collection or
computer code in constraint based design applications
Eric Bensana and Taufiq Mulyanto1
Abstract.
During a design or configuration process, some knowl-
a set of existing items, which are assumed to be extrapolated. For
edge cannot directly be provided as analytical relations between de-
instance, in an aircraft, the repartition of weights for each subsystems
sign variables. In such cases, an analytical approximated relation has
is often computed by considering existing similar aircrafts.
to be built.
The work is focused on the approximation capabilities of different
2.2
Computer object code
kind of neural networks and the integration of the corresponding ap-
proximations into a constraint based system, such as constraint logic
In this case, knowledge about the relation between variables is pro-
programming.
vided as an existing computer object code (procedure). Several rea-
sons may explain why translating this procedure into a set of basic
constraints is not possible :
1
INTRODUCTION
· confidentiality : when design requires cooperation between differ-
Building an application on top of constraint programming requires
ent entities, sometimes you are allowed to use a function, but not
that all constraints of the problem have to be made explicit using a set
to know how it is built. In this case typically, an object code like
of basic constraints provided by the language. But, in some cases, the
a shared object library and a description of the basic call for the
analytic relation between the variables is not available. The reasons
different functions are the only knowledge source;
for that unavailability can be the complexity of the underlying model,
· translation : even by assuming that the source code is available,
or the experimental nature of the relation or even confidentiality.
the lack of documentation or the inherent complexity of the pro-
In such situations, embedding these relations within a constraint
cedure like simulation-based procedures for instance, makes the
programming environment is not straightforward. The work under
translation into constraints hard.
progress is aimed at studying how approximation schemes coming
· duration : in some cases, the difficulty arise from procedure run-
from neural networks may be used to build constraints when the an-
ning time execution; the approximation is needed to reduce com-
alytical formulation of the underlying relation is not available. The
puting time and to allow the integration of the knowledge within
first part of the paper precises the type of relations we intend to deal
a constraint propagation mechanism.
with. The second part is centered on neural networks approximation
capability. And the third part presents some preliminary results.
2.3
Proposed framework
2
NON ANALYTIC KNOWLEDGE
When dealing with design applications, such situations are frequent.
In aeronautic design applications based on optimization techniques
When dealing with the design of complex systems, such as aircrafts,
[16], approaches based on approximation techniques have been pro-
two types of knowledge, not available as analytical relations, may be
posed. A distinction is made between inputs and ouputs and the ap-
encountered : collections of data and existing computer code.
proximation is always to compute outputs when the inputs are given.
As the use of constraint programming for design is more recent,
2.1
Data collection
these situations have received less attention. Contrary to classical
programming techniques, in constraint programming the user only
In this case, basic knowledge about the relation is made of sets of
express the relation between variables (constraints) and do not im-
points where the relation is satisfied. Typically, these points repre-
pose a particular data flow. A computation procedure (constraints
sent a family of curves expressing the relation between several vari-
propagation), embedded in the constraint programming language
ables. For instance, relations between altitude, speed and thrust for
computes domains reduction for the variables and decides, at each
a given turbojet engine are available under this form. They are pro-
propagation step, of the data flow within a constraint.
vided by the engine manufacturer and result from thermodynamics
theory, simulation and experimental validation. When trying to take
2.3.1
Generalization
into account engine performances into a design process, you have to
find a way to integrate such data.
Although different in nature, both situations are very close from the
Another example of such knowledge is the use of statistical data :
approximation point of view. The distinction relies in the definition
the data set represents in fact the value of different parameters for
of the learning space which can be used to build the approximation :
1 ONERA-DCSD, BP 4025, 2 av E. Belin, 31055 Toulouse CEDEX 4, France
· In the data collection case, the space is given explicitly (the given
{eric.bensana,taufiq.mulyanto@cert.fr}
set of points);
107
· In the computer code case the limits of the space for the variables
square regression techniques which minimize the sum of squares
are given and thus every point in this subspace can be used to build
of deviation between predicted values and actual values.
the approximation.
Kriging methods : these methods, named from Krige, were orig-
inally defined to cope with stochastic aspects in data analysis in
The study is focused on the approximation of real functions of
the mining domain. Kriging approximation [14, 5, 8], introduces
the type : Y = f (X1, X2, ..., Xn). Actually, we consider only functions
also a stochastic component in the approximating function. g is
where the Xi and Y are reals (but in the future, integers should also be
defined as g(x) = p(x) + Z(x) where p is usually a polynomial
considered). The aim is to build a constraint of arity n + 1, approxi-
function (very often restricted to a constant term) which takes into
mating f : AC f (X1, X2, ..., Xn,Y ). To allow the reuse of this approxi-
account the global approximation of f and Z is the realization of a
mating constraint in the design application, AC f should be expressed
stochastic process of mean 0, variance 2 and non-zero covariance
using a set of basic constraints available in the constraint program-
which approximates the local deviation. Depending on the choice
ming environment.
of the correlation function kriging methods can be used to build
In case of multiple outputs, like for example in computer code,
interpolations or approximations.
a relation {Y1, ..,Yk} = f (X1, ..., Xn) can be split into k basic rela-
Neural networks : multi-layered perceptron [20, 18, 11, 12], radial
tions Yi = fi(X1, ..., Xn), leading to the building of k approximations.
basis functions neural nets [10], self-organizing maps [2] or neural
By doing this, we limit possible interferences in the approximation
gas [21] are known to have good approximating properties and
building process. But this decomposition is only a possibility, if re-
will be discussed in section 3.
lations between outputs are required the full relation should be taken
Genetic algorithms : chromosoms represent trees of computations
into account.
where each gene represents a basic unary or binary arithmetic
functions. By applying crossing and mutation, new functions can
2.3.2
Knowledge characterization
be built which are matched again the learning set to evaluate their
In order to characterize the initial knowledge, we will assume that
fitness [1, 3].
the following information about the relation is provided :
Fuzzy rules : the function f is approximated by a set of fuzzy rules
like i f X1 is A1 and...and Xn is An then Y is B, where Ai and B
· a characterization of the variables Xi and Y : type (input or output)
are fuzzy sets [7, 13]. For example, in [9], rules can be derived
and domain of values;
from the analytical knowledge of f and its first derivative. This
· the definition of the computation support : either a set of data
approach is well adapted for example to introduce analytical rules
points where the relation is known (X i , X i , ..., X i ,Y i) or an ex-
1
2
K
into fuzzy controllers.
ecutable computer code F implementing f .
Design of experiments
: Although the definition of experimental
We assume also that the approximating constraint building pro-
plans is not an approximation technique, it is often associated to
cess is done before the use of the resulting constraint in the design
an approximation scheme in order to limit the identification, train-
application.
ing or learning preliminary phase by avoiding extensive compu-
tations. These approaches have first been defined by the english
statistician Fisher in the 20s and they have been highlighted in the
2.4
Approximation background
80s by Taguchi in the domain of production quality [17].
Approximation is widely used in engineering and specially in design
applications. Starting from a set of data representing an unknown
function f , the aim is to determine a function g which is as close as
2.5
Work orientation
possible to the training data set, according to a criteria.
The goal is to define a generic approach for embedding both data col-
Interpolation is a special case of approximation where the function
lection and computer code compatible with constraint programming
g must go through all the data points of the training set. Several in-
and which does not require too much user interaction. By consider-
terpolation methods exists like Lagrange, Neville-Aitken, Newton or
ing some of the specificities of the foreseen applications, the domain
cubic spline. They differ mainly by the type of basic functions used
of investigation can be restricted :
to build the interpolating function.
Different approaches have been developped for building approxi-
· stochastic aspects are not present in the case of computer code, so
mations :
Response Surface, including stochastic aspects will be discarded;
Least Square : approximations according to least-square optimiza-
· kriging methods, also including stochastic aspects, can be used
tion like polynomial, exponential, power, trigonometric logarith-
in computer code case, like for instance in Design and Analysis
mic approximation [4, 19] are, because of their simplicity, cer-
of Computer Experiments (DACE) [15], but they have not been
tainly the most widely used techniques. Once a general form for
considered here because of their complexity;
the approximation is selected, a least-square optimization process
· interpolation is not required because we consider design applica-
finds the parameters of the function g.
tions at a high level of description, which imply imprecision and
Response Surface : originally developped to analyze the results of
because it is incompatible within the computer code case.
physical experiments, this method postulates that f can be approx-
· before using least-square approximation, you need to look at data
imated by g(x) = h(x) + where h is a polynomial function (usu-
before selecting the type of approximation to use or build different
ally linear or quadratic) and a random error of mean 0, indepen-
approximations before selecting the one which matches best : this
dent of observations. The parameters of h are computed using least
point does not match our goal of low level interactivity
108
· fuzzy approximation does not match the fact that the approxima-
3.3
Neural nets for approximation
tion should be directly translated into a set of basic arithmetic con-
straints;
In this paper, only MLPs and RBFNNs are considered. Other NN
· genetic approximation allows to build complex functions by com-
architectures like SOMs or NGs should be considered later in the
bining a set of basic functions but this approach seems to be quite
study.
complex to implement;
· design of experiments methods will be needed when adressing the
computer code case to help to generate an explicit training set.
3.3.1
Multi-Layers Perceptron
These reasons lead us to focus on neural networks, even if other
The multi-layers perceptron (MLP) [20, 18, 11, 12] is one of the most
methods like those derived from kriging methods could be used.
simple network to build. Their basic characteristics are :
· they are structured by layers : one input layer, several hidden lay-
3
NEURAL NETWORKS
ers and an output layer;
· inside a layer a neuron is not connected to any other neuron of the
3.1
Mathematical formulation for neural nets
layer but connected to all neurons of previous and next layer;
Because of the numerous types of neural networks (NN), we will
· the input layer has one neuron for each input and can be forgotten
limit our presentation to the feed-forward types, which are those used
by considering that each input is connected to all neurons of the
for approximation. A neuron model is given in figure 1. Information
first hidden layer : the number of layers is the number on hidden
is propagated through it according to the arrows.
layers + 1
Inputs are represented by the vector E = {e
· the activation function g is common to all neurons of the hidden
1, e2, . . . , en} and W =
{w
layers.;
1, w2, . . . , wn} is the vector of the weights of the vertices linking
inputs to the neuron. The neuron is modelled by an input integra-
· for each neuron of a hidden layer :
tion function g(.) and a transfer function f (.). These functions allow
the integration function g should be a summation i ei.wi + b,
to compute the output of the neuron s. The output vertex allows to
the transfer function f must be monotonic increasing like for
propagate the output to others neurons. The bias parameter b helps
instance the sigmoid function 1/(1 + exp(-.u)) or the hyper-
to improve the model.
bolic tangent tanh(.u)
e1
w
· for each neuron of the output layer :
e
1
2
w2
the integration function is also a summation;
w
a
e3
3
g(.)
f(.)
s
the transfer function is linear;
w...
e
w
...
n
Consequently, when two layers MLP are considered (one hidden
e
layer and the output layer), each output neuron computes the follow-
n
b
ing function :
Figure 1.
Mathematical model of a neuron
p
q
y = b
a
The function a = g(W, E, b) combines the inputs, the weights and
j .g(
j,k.xk + c j )
j=1
k=1
the bias in a single value. The transfer function (also called activation
function) takes into account non-linear aspect.
where :
· p is the number or neurons of the hidden layer and q is the number
3.2
Definition of a neural network
of inputs;
The definition of a given neural network is usually made in two
· g is the activation function associated to the neurons of the hidden
steps :
layer;
· the b j are the weights of the links between the neurons of the
1. the definition of the general architecture of the network : number
hidden layer and the neuron of the output layer considered;
of layers, number of neurons, types of the functions f and g;
· the ai, j are the weights of the links connecting the inputs to the
2. the training of the network, in order to compute the values of the
neurons of the hidden layer;
different parameters : weights and biases.
· c j is the bias associated to the jth neuron of the hidden layer;
· the xk are the inputs and y is the output.
There is no real methodology for deciding of the general archi-
tecture of a network for a given problem. Thus intuition or experi-
The training is supervised, meaning that a training set has to be
ence are often the only rules. As far as approximation is considered,
determined. The learning algorithms which allows to compute the
several types of neural networks architectures are known to be effi-
weights of the network are generally error backpropagation algo-
cient : multi-layered perceptron (MPL), radial basis function neural
rithms and the modification of the weights is based on the quadratic
nets (RBFNN), self-organizing maps (SOM) or neural-gas (NG).
error.
109
3.3.2
Radial Basis Functions Neural Nets
4.1
Evaluating neural-based approximation
Radial Basis Function Neural Nets [10] are very close to the multi-
The training of neural networks is usually done using to set of ex-
layered perceptron. Their structure is also layered, but there is only
amples : a training set which is used by the learning algorithm to
one hidden layer. The neurons of the hidden layer use a regular and
computes weights and biases and an evaluation set, different from
radial symetric activation function, which is assumed to deal with
the training set, which is used to evaluate how the neural network
proximity between data. A regular, radial symetric function is of the
really performs.
form : g(x) = K( x - c ) where :
To evaluate, the pertinence of a neural-based approximation, two
aspects must be balanced :
· c is the class center
·
is a norm : for instance euclidian distance
· the approximation quality which measures the intrinsic perfor-
i(xi - ci)2)
· K is a Green function like for example the e-ax2 with a > 0;
mance of the approximation built w.r.t the initial knowledge; this
evaluation is done by computing both approximation error for the
For instance, gaussians are regular radial symetric functions.
points in the training set and the generalization error for the points
The neurons of the output layer, as in the MLP case, perform a
of the evaluation set; both errors are related to the size of the net-
linear combination of the output of the neuron of the hidden layer.
work in term of number of neurons, the approximation error de-
The approximation performed by each neuron of the output layer is
creases when the size increases, but if the size becomes too high
then :
the generalization error may increases;
p
· the propagation effectiveness which measures how constraint
bj.g( x-ci ,i)
propagation performs on the approximating constraint built from
j=1
the neural net; propagation effectiveness usually decreases when
the number of neurons increases.
Three types of training are available for this type of network :
To improve propagation effectiveness and avoid tow large gener-
· a one step algorithm which computes directly the networks pa-
alization error, it seems interesting to build neural networks as small
rameters by minimizing the approximation error;
as possible.
· two steps algorithm :
Another aspect, which can taken into account, is related to running
1. the learning of the characteristics of the radial basis functions :
time : learning time or propagation time.
one neuron for each training point or one neuron for each class
of input (which may require a preliminary classification of the
4.2
First experimentations
training set);
Preliminary experimentations have been conducted, using the Neural
2. learning with some kind of backpropagation algorithms of the
Network Toolbox of Matlab.
weights b j of the links between the neurons of the hidden layer
and those of the output layer.
4.2.1
Example
· a training of the output layer only : the hidden layer is fixed by
the user or randomly and the learning reduces to the solving of an
An example has been built from the following function (see figure 2) :
linear optimization problem.
y(1 + x)2
z = [y · exp-(0.5x-1)2 · sin(2y)] +
Generally this type of network is easier to build than the MLP.
20
3.3.3
Adequation
8
These two types of neural networks, have a priori interesting prop-
6
erties :
4
Z
·
2
their approximating capabilities are known;
·
0
they have a rather simple structure : simpler for the RBFNNs than
-2
for the MLPs;
4
5
· the approximation formulation can be easily and directly trans-
3
2
1
-1
lated as a set of basic arithmetic constraints : sum, square, expo-
-3
0
-5
Y
X
nentiation, product etc.
· they can deal with multiple outputs models.
Figure 2.
Surface for z=f(x,y)
A training set of 55 points has been built by varying x from -5
4
EXPERIMENTATION
to 5 (step 1) and y from 0 to 4 (step 1) and an evaluation set of 14
The purpose of the ongoing experimentations is to test different neu-
points have been built by varying x from -4.5 to 4.5 (step 1) and y
ral networks architectures to evaluate their pertinence for building
from 0.5 to 3.5 (step 1). Consequently, z = f (x, y) belongs to the in-
approximating constraints. In order to evaluate and compare differ-
terval [-0.7788, 7.6171]. Globally the data set is formed of 69 triples
ent architecture, evaluation criteria and test cases must be stated.
corresponding to the values (x, y, z).
110
4.2.2
Architecture of networks
· for networks with only one hidden layer (MLP1 or RFBNN),
propagation effectiveness is similar but the MLP formulation is
The following architectures have been tested and compared :
slower.
· one hidden layer MLP (MLP1) with 3,5,7 or 9 neurons in the hid-
To summarize, simplest architectures must be preferred like MLP
den layer
with one hidden layer or RBFNN. At this point a final choice is
· two hidden layers MLP (MLP2) with a neuron repartition 2-1, 2-
difficult : on one hand, the building of RBFNN is simpler and can
3, 2-5, 2-7, 1-2, 3-2, 5-2, and 7-2 (x-y meaning that there are x
be done automatically, but on the other hand MLP need less neu-
neurons in the first layer and y in the second layer)
rons than RBFNN to achieve the same quality and thus are better
· RBFNN with 3,5,7 or 9 neurons in the only hidden layer;
for constraint programming translation. Further experiments are re-
quired before deciding of the best architecture.
All architectures have two inputs and one output.
5
CONCLUSION
4.2.3
Learning algorithms
This work, partially supported by SPAE, is under progress and thus
As sixteens different learning algorithms are available in the Matlab
only limited and partial results are presently available. Several re-
ToolBox with their own parameters, the testing has been limited.
maining points can be addressed :
Three backpropagation algorithms have been selected for MLPs :
Levenberg-Marquardt, Bayesian Regularization and Gradient De-
· more extensive validation to compare MLP1 and RBFNN archi-
scent with momentum and adaptative learning rate.
tectures;
For RBFNNs, the only algorithms available are of type one-step :
· determination of the training and evaluating sets specially in the
there is no real learning algorithm, in fact the building procedures
case of computer code;
directly computes the architecture and the values of the parameters
· limitations of the approach in terms of total number of variables
from the training set. As inputs are read, neurons are added to the
(inputs and outputs) which can be handled efficiently;
hidden layer and parameters adjusted to limit the error to a maximal
· improvement propagation for the approximating constraint by us-
value. The only parameters are the maximal error and a spread value,
ing more powerfull consistency techniques like box-consistency
which allows to control the smoothness of the approximation built.
[6] or defining specific ones;
The bias for the neurons is computed from the spread.
· impact of considering variables restricted to be integer;
· testing other types of neural networks such as SOMs or NGs or
4.2.4
Testing
other approximation schemes like DACE and comparison of re-
sults;
As learning implies random aspects, for each couple (network ar-
· applicabilition to real-life design application in the aeronautic area
chitecture, learning algorithm), hundred runs have made in order to
such as radar characteristics or engine performances where alti-
compute mean and variance for the different criteria.
tude, mach number and thrust or consumption are linked.
Propagation effectiveness tests have been done using the constraint
logic programming language Prolog IV. For a trained network, the
formulation of the computation it performs is translated into predi-
REFERENCES
cates using basic constraints of the language.
[1] L. F. Alvarez, V. V. Toporov, D. C. Hughes, and A. F. Ashour, `Ap-
proximation model building using genetic programming methodology :
applications', in 2nd ISSMO/AIAA Internet Conference on Approxima-
4.2.5
Preliminary results
tions and Fast Reanalysis in engineering optimization, (2000).
[2] M. Aupetit, P. Couturier, and P. Massotte, `Function approximation
On the simple example, both approximation quality and propagation
with continuous self-organizing maps using neighboring influence in-
effectiveness have been measured for the sixteen different configu-
terpolation', in Neural Computation B, (May 2000).
rations of NNs and with the learning algorithms selected. Detailed
[3] J. Frohlich and C. Hafner. Extended and generalized genetic program-
results will not be presented here, but only the main lessons learned :
ming for function analysis. Internet.
[4] A. A. Giunta, `Aircraft multidisciplinary design optimization using
design of experiments theory and response surface modelling meth-
· to get a same approximation quality, an MLP needs a smaller num-
ods', Technical Report 97-05-01, Multidisciplinary Analysis and De-
ber of neurons than a RBFNN;
sign Center, Virginia, (1997).
· the most appropriate algorithm for MLP is Bayesian Regulariza-
[5] A. A. Giunta and L. T. Watson, `A comparison of approxima-
tion;
tion modeling techniques : polynomial versus interpolating models',
·
in 7th Symposium on multidiscplinary Analysis and Optimization.
for two hidden layers MLPs, architectures of type N-2 give better
AIAA/NASA/UASF/ISSMO, (sep 1998).
results than those of type 2-N;
[6] Pascal V. Hentenryck, David McAllester, and Deepak Kapur, `Solving
· for MLP and for a same number of neuron, the one hidden layer
Polynomial Systems using a Branch and Prune Approach', SIAM J. Nu-
architecture gives better results than the two hidden layers one;
merical Analysis, 34, 797827, (avr 1997).
· for one hidden layer architectures and for a same number of neu-
[7] B. Kosko, `Fuzzy systems as universal approximators', IEEE transac-
tions on computers, 43(11), 13291333, (1994).
rons, MLPs with one hidden layer perform better than RBFNNs;
[8] A. Limaiem and H. A. ElMaraghy, `Curve and surface modelling with
· propagation effectiveness degrades in quality and running time
uncertainties using dual Kriging', Journal of Mechanical Design, 121,
when the number of neurons increases;
249255, (jun 1999).
111
[9] D. Lisin and M. A. Gennert, `Optimal function approximation using
fuzzy rules', in International Conference of the North American Fuzzy
Information Processing Socier, (1999).
[10] C. G. Looney, `Radial basis functional link nets as learning fuzzy sys-
tems', Cs479, University of Nevada, Department of Computer Science,
(1996).
[11] P. G. Maghami and D. W. Sparks, `Design of neural networks for fast
convergence and accuracy', in 39th Conference on Structures, Struc-
tural Dynamics and Materials. AIAA/ASME/ASCE/AHS/ASC, (sep
1998).
[12] V. Maiorov and A. Pinkus, `Lower bounds for approximation by MLP
neural networks', Neurocomputing, 25, 8191, (1999).
[13] S. Mitaim and B. Kosko, `What is the best shape for a fuzzy set in func-
tion approximation', in 5th IEEE International Conference on Fuzzy
Systemes, (sep 1996).
[14] T. W. Simpson, J. J. Korte, T. M. Mauery, and F. Mistree, `Compari-
son of response surface and kriging models for multidisciplinary de-
sign optimization', in 7th Symposium on multidiscplinary Analysis and
Optimization. AIAA/NASA/UASF/ISSMO, (sep 1998).
[15] T. W. Simpson, J. Peplinski, P. N. Koch, and J. K. Allen, `On the use
of statistics in design and the implications for deterministic computer
experiments', in ASME Design Engineering Technical Conference, (sep
1997).
[16] J. Sobieszczanski-Sobieski and R. T. Haftka, `Multidisciplinary
aerospace design optimization ; survey of recent developments', in 34th
Aerospace Sciences Meeting and Exhibit, (jan 1996).
[17] P. Souvay, Les plans d'exp´erience : m´ethode Taguchi, AFNOR, 1995.
[18] D. W. Sparks and P. G. Maghami, `Neural networks for rapid design
and analysis', in 39th Conference on Structures, Structural Dynamics
and Materials. AIAA/ASME/ASCE/AHS/ASC, (sep 1998).
[19] R. Unal, R. A. Lepsch, and M. L. McMillin, `Response surface model
building and multidisciplinary optimization using D-optimal design',
in 7th Symposium on multidiscplinary Analysis and Optimization.
AIAA/NASA/UASF/ISSMO, (sep 1998).
[20] V. Vysniauskas, C. A. Groen, and B. J. A. Krose, `The optimal number
of learning samples and hidden units in function approximation with a
feedforward network', Technical Report CS-93-15, University of Ams-
terdam, Faculty of computer science and mathematics, (1993).
[21] M. Winter, G. Metta, and G. Sandini, `Neural-gas for function approx-
imation : a heuristic for minimizing the local estimation error', IEEE,
(2000).
112
! "
#
$
%
3 3
3
4
33
*
-
4
4
3
5
3
-
3
*
"
-
-
3
4
*
" 6
7
-3
-
6
-3
-
<= " C
--
3
3
!
3
-
"
<=
-
3 "
4
--
33
-3
$ -3
3
-
3
3
<= "
-
3 "
3
33
3
-3
-3
*
$
5
3
*
3
4
" 8 9"
*
3
"
-
7
3
3
7
"
5
$
3
7
0
-
7
3
3
5
"
3
4
(
" 8+9"
-
-
33
-
3
3
"
&'
(
& '
-
3 3
7
.
*
4
*
<=
4
+"
3
4
-
?
-
7
-3
"
-
<=
-
-3
<= "
-
3
"
-
-
@
-3
4
<=
3
3
-
4
-
-3
3
"
- 33
-
-
89"
-
-
-
-3
3
<=
3
-4
4
3
-3
*
,
3
$
*
*
4
3
89"
- *
&" 6
3
*
:
3
-
A
3
4
3
3
3
B"
; <= >
3
*
4
*
"
3
-
<=
3
)
*
+
,& +
+
'(
-
4
3
,& +
+ (+
&
& '
-
"
-
<=
4
- 8+?9"
- '.
.+
3 3
3
4
33
5
*
- 3 3
4
*
3
-
-
-"
3
"
3
5
-
3
-
"
3 4 -
- 33
-
3
-
*
3
7
-
3
7
4
"
-3
-
"
7
$
4 $*
*
-
3 -
<=
3
-3
-
-
4
7
4
5
- :
3
-
"
8?9"
4
-
"
-3
3
-
3
; <= >
3 -
*
3
<=
-
3 "
3
3 4 -" =
3
$
*
<=
-
*
-
-
3
<=
3 "
3 -
3 3
3
(
3 3
3 3
-3
- "
-4
<=
4
3 3
"
<=
<= .
- 8@,&9 6
8AB9
C
8% '9" #
--
3
-3
<=
-
4
<=
-
-
3 8?9"
"
-
<=
-
"
-
3 -
4
-
-
3
33
-
<= " 6
<=
3
8?9"
<=
-3
!"#"
$ %&'' ()*'+' ,
( *
" -
./ - "
- "
- "0
12
"
113
-
-
3
-
"
3
$
-
"
$
3
3
"
-
-
-
3
*
3
-
-
- 3
8?@ ?9"
4
<=
"
-3
3
-
-3
-
-"
3
4 $
/%
)
4 $*
*
- "
$ -3
-3
"
-
-3
-
-
4
3
-
$
4
-
4
" 8@9
"
-
-
-
" #
-3
33
3 *
- "
-3
- "
3
*
-3
3
4
-3
"
4 $*
*
-
-3
"
3
4
4 $ " $ -3
-3
3
"
-3
*
-
3 3
4
" 8@9
4
4
3
-3
4
-
*
-3
" #
-
*
"
-
-
- 8@9
-
3
-3
"
-3
4
*
8?9"
-
<=
-3
4
*
D $3
4
" 8@9
3 3
<= 8?9"
3
-*
-3
4
3
"
3 3
- " ! 3
3
" "
<
<=
3
-
-
"
" " 3
"
-
4
-
<=
-3
"
3
"
4
.
-3
3 *
-
-
4
-
" 6
-3
4
-
-"
4
-3
-3
4
4
3
3
$3
3
-
- . " "
$
-3
-3
"
3 3
3
-" 8,9
4 4
3
-3
-
-3
3
3
"
4
4
4
-3
-
3
-3
-3
"
3
-
-3
-*
4
3
3
4
3
*
3
-3
"
-
"
-
3
<=
33
4
3
3*- 3 " #
3
4
-"
33
3
3 3
3
-3
-3 *
7
-
"
4
3
4
3
33
$
4
-
-3
-3
-3
" 8@9"
3
<= 8?9"
3
-
4
-
"
3
- .
-
3
- "
3
-
3
-
*
5
" "
-
" )
/
' -0 &
, ++
,& +
+
3
4
-
- $
3
4 3
"
-
(+
&
& ' - '.
.+
3
"
-
-
3
-
7
-*
"
4 3
-
4
-
3
3
<=
"
*
-
3
"
-
4
4
- -4
-
<= .
-
8@,&9
-
-
3 " 8&9
6
8AB9
C
8% '9"
6
-
3
3
-
-
-
3
4
- -4
-
3
"
-
4
3 -
/%
-3
-
3
*
-
3
-
4
4
*
4
3 "
-
-
- 4
- -4
3
8+9
. $
-
3
-
3
-
3
"
4
*
-
"
3
-
-
-
3
-
4
-
$3
-
-"
$
-
-
-
*
"
-
- 33
3
"
-
-
4
-
-
"
3
"
6
-
-
-
4
-
4
4
*
"
4
3
3
-
<=
-3
-
-3
4
- " (
-
4
3
"
3
3
<=
-
"
-
*
4
-"
*
-3 -
-
3
-
*
3
-
3
3
-
3 3
"
"
*
114
/%
/ *
3
C
"
4
-3
--
.
-
4
-
" =
-3
3
*
6
-
-
4
-
-3
-
-*
"
4
" 6
3
"
-
5
6
-
-
-
3
-
<=
4
5
4
-3
-
-
-3
"
3
4
3
C
-
#0
F
" 8'9
-3
3
4
4
3
*
-
-
4
" 6
! ; --
5
!
>
.
5
3
-
3
8@9
-
33
3 3
.;> 3
*
3
4
5
3
6
-
;+>
*
-
4
3
" #
-
*
!3
"
!
-
3
4
-4
-
3
7
4
4:
5
7
"
-
5
"
3
3
4
3
4
4:
-
" 8AB9
3
"
3
3
!3
"
"
C
-
-3
3
-3 *
3
"
3
3
"
C
3
-.
-
4
4
*
3
"
-3
3
"
3
3
" !
$
-
-3
3 "
-
- " 6
3
4
-3
-3
4
$3
-3
-
4
3
3
"
4
C
" "
-3
4
3
4
3
4
-3
"
-3
-3
4 4
4
4
"
!
*
4
-3
"
-3
4
4
3
"
C
-3
*
!
6
-
*
" 0
-3
! 3
3
!
-3
"
33
$ -3
4
3 3
-
4
4
*
-
-3
-3
-3
7*
6
"
-3
33
4
4
4
-3
" <
4
*
4
-
6
"
4 3
4
4
6
4
4
-3 *
-3
-3
"
"
4
-
3
-
.
7
3
3
"
-
- 3
-3
-3
4
4
3
-
-
-
7
3
-
4
3
"
-3
"
6
4
-3
3
-
C
3
"
-3
$
-
-
4
-3
3 "
$
-
3 "
"
-3
3
6
-
-3
3
-
"
-
4
"
3
3
4
3
-
. 3
-
-
-3
"
$3
3
3
-
"
3 *
4
-
-
-
4
3
5
. " "
4
"
-3
3
-
4 -
3
-3
3
-
"
3
*
5
4
-3
"
4
3
4
3
"
-
4
-*
3
4 3
-
7 "
3
3
-
-
5
4
3
4
3
4
-
- "
3
" )
4
-
$
*
6
-
4
C
-
*
4 3
.
-
3
*
$
-
"
3
-
3
"
E
-
-
6
-
-
1
!
&
'
' +
,+
(-
-
-
-
-
6
* & ,
,+
' &.
& '
'
- .0
"
33 -
-
4
4
$3
4
"
-
3
*
-3
3
<=
"
/%
1 2
4
4
C
-
1% 2
$
-
-
"
3
C
-
3
"
C
-3
3
-
6
C
"
"
-3
3
-
- "
-3
-
-
.
-3
3
3
-
-
"
*
115
-
-
6
1%
) (
$
&
C
3
-
"
<=
-
4
3
*
3
--
"
-
3
-
-
-
"
-
6
3
4
-3
-
$3
-
-" )
-3
3
"
C
*
$
- 4
-
3 "
3
-
3
"
-
6
. 3
4
-
"
-
3
-
3
.
3
-
4
-
-
"
3
"
C
3
*
7
-
6
"
*
-
3
4
"
C *
$
-
3 "
-3
3
"
- :
3
-
4
G
-3
4
<=
-3
"
-3
3
-
4
"
3
-
6
"
6
-
4
3
H6
4
3
-3 *
4
-3
-
-
6
4
*
"
3
7
$
-
"
-3
-
<=
3 3 . - :
4
1%
/ 3
!
$
-3
" (
-
4
4
--
*
5
3
*
-3
4
.6
4
-
3
3
-
"
--
-
-
-
-
3
-
"
"
4
<=
-
--
3 3
-3
"
-
- -4
"
-
-
3
"
C
. -3
*
-
6
4
*
-
-
4
3 4 -
-
4
3
-
33
-
4 *
" "
"
C
-
.
$3
-
-
4
-4
6
C
"
-
3
-
4
4
$3
--
3
4
4
3
"
<=
-
3
C
-
4
--
3 3
5
3
C
4
3
. -3
* --
" 6
-
3
*
-3
3
--
*
-
4
-3
:
3
5
"
-
4
8'9"
3
4
3
-
5
*
3
$
- 3
-
4
- -
$3
3
-3
3
4
-
-
4
3
5
"
6
"
-3 -
3
-
3
5
*
C
33
3
4 C
4
4
-
5
"
5
*
-
6
"
- -
3
3
3
3 "
3
C
-
4
--
-
"
-
-3
8,9"
4
-3
4
4
C
3
33
*
-
4
-
6
H6
-
"
-
4
"
4
-
0
*
6
4
3
3
-
-
<= 3
3 3
" (
3
-
" #
-3
3
-
-
-
C
-
-
4
*
-
8&9" 6 4
4
-4
3
3
. " "
-
"
4
3
- 3
-
" #
<=
- -
-
-
"
4
$ -3
3
-
3
-
" )
-
-
-
- .
3
4
$ -3
3
-
"
-
- " (
-
-3
4
3
-
-3
-
4 !
(+--&'.
*
+
,& +
+
3
4
<= "
* & ,
,+
' &.
& '
'
- .0
3
$ 3 C
$3
-
-
$3
" (
3
7
$
$3
4
*4
3 3*
-
" 6
4 - 33
- -
3
"
3
<=
-
3
3
*
33
"
-3
3
3 3
- "
33
-
3
3
4
-
*
3 - 7
4
-3
3
3
-
3
"
3 4 -
"
3
- 33
116
-3
3
5
3
-
3
*
3
3
"
-3
3
4
4
3
"
- -
4
*
C
3
"
4% !
-4
3
4
3
3
-
-
6
"
-
C
4
3
3
4
"
33
- : 3 4*
-3
-
- " (
3
*
"
4 3
"
33
33
-3
3
-
"
*
-3 $
-
3
.
4
4 3
-3
4
$3
3
-3
"
-
" (
-
33
4
-3
*
4 3
* 3
-3 *
3
"
33
3 4 -
"
4
3
3
3
3
3
. " "
6
3
3
"
33
33
*
4
-3
. -
4
"
3
"
3*
4 3
4
3
*
3
5
- :
"
5
-
"
--
3
3
9
3
5
3
4
-
3
C
3
3
3
3
"
-
5
"
3
4
4
$
-
3
-
"
3
5
3
" (
C
5
-
4
: (&
& ' '(
!
&
' * & ,
$
3
-
3
4
3
"
+3&
*
2
33
3
4%
)
5
-
3
"
-
3
-
4
3
C
4
3
4
3
-
" #
3
4
-3
" < 3
4
3 *
*
3
-
4
3
4
4
8A9" #
4
C
-3
3 "
33
--
3
"
C
3
-
3
-
- 4
-
3
4
"
4
3
3 3
3
3
-
3
C
"
-
--
4
-
8%9"
3
3
5
*
-
<= -
-
-
3
3
3
3
4
-
"
3
"
3
*
3
- 33
4
3
4
D
*
4
4
C
" #
3
4
4
-
"
3
-
3 4 -
3 4 -
"
3
<=
3
-3
*
6 +7 +' & ' '++(+(
!
(+--&'.
4
-
*
*
+
,& +
+
-
3
"
4
3
- : 3
3
5
.
<=
4 -
*
<=
-
-
-
"
5
4
4
-3
*
5
$
"
3
-
"
3
4
-
3 3
4
"
-
5
-
-
3
3 - 7
6
-3
-3
3
3
"
3
-
*
-
-
8
"
-
4
3 3 "
$
5
-
!
6
"
0 J
K
"
3
$
4
3
*
4
-
"
4
4
5
*
8B9"
*
4
$
3
<=
3 3
- 33
-
*
4
3
3
-
-
"
4
$
-
-
"
#
8%93
-
7
*
C
-
$
-
-
; 0 >
"
3
0
-
8'9"
"
-
3
-
C
" I
C
3
3
4
"
117
2' * -+(.+! +'
4
-3
-"
(
"
3 3
-
*
6
33
-
-
4
0 =
3
8+9"
(
;3 :
, ?%@>
)
33
4
(
;
>"
3
"
33
-
33
.
4
3
+ + +' +
0 =
33
4
-
3
3
"
89F"
!
"!
8+'9 CL
3
33
*
#
$
%
!
*6
+'''"
4
4
"
-
8+9 " E
!
&
'
!
-
-
3
4
%
"
3
"
- M
*
-
"
33
-
6
4
4
%%?
4
" 6
4
*
8?9)" 0
" 0 "
N
-3
-
3
( -
<
3
=
O (###
)6 A'*%? ;
+'''>"
33
-
"
8@9<" I
" " 0
<" 6
N - .
<
3*
=
O "$
! &)*
+, %%A"
;
' -
& '
'(
+ *
2
8,9<" I
" " 0
<" 6
N - .
<
3
-3
*
- O
"'
-
4
3
<=
-3
-4
!
+'''"
3
3
7
"
8&9 "
" 0
<" I
<" 6
" !
.
"
*
-
4
- 33
-
3
<=
4
P 3.
Q
Q
*+" " - "
Q Q Q
3 : Q4 Q
Q - 6 4Q
0 R+'
0
" - S"
0
+''+
" #
8A9 "
<" I
N ( -
O
33
"
! .
#
;%%A>
"
6
3
3
*
8B9 "
( -
33
" <
*
-
-
<=
%%A"
4
3 3
- 33
4
-
8%9 "
#--
N
0
-
-3
4
3
!
! 3
O "$
(
/
" (
4
.
0 . 123 +'' "
-3
" (
-
-3
-
-
8'9 "
#--
("
=
F" C -
F" 0
N
-3
3
-
3
C
-3
0
-
O (###
4
3
"
-
3
*
// AB*B, ;
+'''>"
8 9 "
F"
"0 J
K
"
N
4
-
3
"
*
I
#
O!(# !.
) ?,A*?A+ ;%%B>
"
3
-
3
<=
-
5
$
8+9 " (
I" (
<" F
N 0 =
< -
3
"
3
4
=
C
*
4
3
-3
-3
- O (
4
#
5
3
3
"
-3
3
#
< @@%*@&% ;
+'''>"
-
4
" #
<=
6
-
4
"
8?9<" I
N
O "#
#
33
3
4
CL
-3
7
F" F" 0
" F
6
M
+'' "
4
8+'9"
5
4
3
8@9 "
"
"
$
!
*
-3
4 -
3
*
%B,"
-
4
-3
"
$ *
8,9<" I
<" " !
N
3
*
O (###
C
--
<=
4
-
;%%,>
"
-
4
4
"
8&9C"
7
" 6 "
6
$
*
3
5
"
*6
+'''"
- 33
<=
3
*
8A9F"
" =
"
N0
4
-
" 0
!
( -
O
"$
17
(
3
4
"
#
0( # *
++3 %%%"
3 4 4
5
-
8B9 " 0 J
K
"
"
N!
<=
3
7
3
0
*
E
!
( -
O "$
(
4
3
--
8&+ 9
/
.
0
. 123
3-
0 =
--
+'' "
8%9 "
:
J
N
<
-
0
*
3
-
"
-3
O
"$
'
(
33
4
%
+'''"
-
"
4
-3 *
8+'9C" CL
N
0
C
*
-3 $
3
"
O .$
# !(7222/
-3 $
3
4
)
$
8
8
+'''"
$3
-
3
-
8+ 9 " !
N(
*#
!
--
.
(
=
#4*
3
4
-
3
" 6
-
:
O "$
# &&$*+, %%A"
-3
$
*
-
4
33
*
-
"
118
Customizing the Interaction with the User in On-Line
Configuration Systems
L. Ardissono1 and A. Felfernig2 and G. Friedrich2 and A. Goy1 and D. Jannach2 and
M. Meyer3 and G. Petrone1 and R. Sch ¨afer3 and W. Sch ¨utz3 and M. Zanker2
Abstract.
The provision of services on the Web is challenged by
which can be reduced to exploring a pre-determined set of already
its heterogeneous customer base: Web catalogs are accessed by users
configured solutions; for instance, see [8] and [9].
differing in interests and knowledge about the products and services
This paper presents the personalisation facilities offered by the
they search for. Moreover, in the companies selling complex con-
CAWICOMS5 framework for the personalised configuration of prod-
figurable products and services, configuration systems are used by
ucts and services [2, 3]. This framework is based on the idea that al-
employees playing different roles: e.g., technical engineers and man-
though, during the configuration of an item, technical details have to
agers. For some of these people, the configuration task is problem-
be addressed, an intelligent user interface can fill the gap between the
atic, as it exposes them to a large number of technical details to be
system's point of view, focused on the implementation of the solu-
specified. Effective personalisation strategies are thus critical to the
tions, and the customer's one, focused on the usage of the product, or
development of successful Web-based configuration systems.
on the service fruition. This approach supports the use of the system
This paper presents the personalisation techniques applied in
by heterogeneous users such as inexperienced customers and tech-
CAWICOMS, a prototype toolkit for the development of Web-based
nicians configuring items for third parties. CAWICOMS customises
configuration systems that personalise the interaction with their
the following aspects of the interaction:
users, supporting individual needs during the configuration task and
the presentation of the solutions. The overall goal is that of assist-
Configuration process: during the selection of the features of the
ing the user during the configuration process by suggesting suitable
product/service, the system assists the user by suggesting, when-
choices and providing her4 with the information she needs for mak-
ever possible, the values best fitting her requirements. Moreover,
ing informed decisions. To this purpose, our framework integrates
it provides information about such features, to help the user make
user modelling and personalisation techniques with constraint-based
informed decisions.
configuration techniques.
Presentation of solutions: when a configuration solution is pro-
duced, the system presents it by focusing on the most interesting
features, given the user's role. In this way, different perspectives
1
INTRODUCTION
on the product/service are offered (e.g., consider the presentation
of technical details, with respect to the provision of information
The provision of services on the Web is challenged by its heteroge-
about the price and the main functions offered by the solution).
neous customer base: as the popularity of Web shopping has dramat-
ically increased, electronic catalogs are visited by users differing in
In order to achieve these two types of personalisation, the system ap-
interests and knowledge about the products and services they search
plies user modelling strategies, aimed at identifying the user's indi-
for. The one-to-one recommendation of items, based on the recog-
vidual interests and expertise, as well as the company's requirements.
nition of the customer's preferences, has been introduced in several
In several application domains, configuration systems are used by
Web-based systems to help users find the goods best satisfying their
specific categories of users, identified by their roles in the organisa-
needs [4, 5, 6, 11, 14, 17, 19]. However, this facility does not support
tions: e.g., sales engineers and managers. Our framework uses this
the creation of personalised solutions on the fly: only pre-configured
type of information by applying stereotypical user modelling tech-
items can be managed by the traditional recommender systems. As
niques [18], aimed at estimating the user's interests and domain ex-
the configuration of items is essential to comply with the customer's
pertise since the beginning of the interaction with the system. More-
requirements when purchasing complex products, or registering for
over, to take into account individual characteristics, dynamic user
services, the need for assistance in this task is emerging as an im-
modelling techniques are applied to update such estimates, accord-
portant requirement. At the current stage, this type of activity can be
ing to the user's behaviour.
performed by using non-personalised configuration systems offering
The system also employs probabilistic inference techniques to rea-
a single type of interface. Moreover, as the configuration of com-
son about the user's requirements and customise the configuration
plex items would challenge the user with technical details, the sys-
process. Furthermore, it uses personalisation strategies that, on the
tems available on the Web typically solve simple configuration tasks,
basis of the recognised interests, skills and requirements, prescribe
the configuration and presentation actions to be performed: e.g., sug-
1 Universit`a di Torino, Italy.
2 Computer Science and Manufacturing Research Group, University of Kla-
5 CAWICOMS is the acronym for "Customer-Adaptive Web Interface for
genfurt, Austria.
the Configuration of Products and Services with Multiple Suppliers"
3 DFKI, Saarbruecken, Germany.
(www.cawicoms.org). This work was funded by the EU through the IST
4 We refer to the user in a unique gender for readability purposes.
Programme under contract IST-1999-10688.
119
gesting a value for a feature of the item to be configured, or focusing
In CAWICOMS, we addressed the requirements of these user
the presentation of a solution on a of its features. A rule-based ap-
classes, which are represented by stereotypes providing information
proach is employed to tailor the interaction to the user's requirements
about their skills and interests.
and to integrate business rules in the configuration process.
The CAWICOMS framework has been applied to the develop-
3
PERSONALISATION REQUIREMENTS OF
ment of a Web-based system supporting the configuration of high-
CONFIGURATION TASKS
technology products (telecommunication switches) and services (IP-
VPN, Internet Protocol Virtual Private Networks) on the Web. In
In order to take the user's interests and knowledge requirements into
the present paper, we describe the user modeling and personalisa-
account, a configuration system should fill the gap between the un-
tion techniques applied in the system by referring to the prototype
derlying representation of the product/service and the user's percep-
supporting the configuration of telecommunication switches.
tion of such an entity. While an expert user is assumed to have precise
This paper, which represents an extension of [1], is organised as
knowledge about the features of a product/service and its structure, a
follows: Section 2 outlines one of the application scenarios guiding
novice one only perceives its most "external" aspects. For instance, a
the development of our framework and Section 3 summarises the
telecommunication switch is characterised by a large set of features,
main personalisation requirements on configuration we identified.
some of which are very technical, such as the number of trunk lines
Section 4 describes the CAWICOMS framework for the personalised
to be exploited. However, the novice user's view of the product may
configuration of items by specifying the typical flow of the interac-
only concern a subset of all the features: e.g., she may want to spec-
tion with the user (4.1), the graphical interface used to elicit informa-
ify whether a Voice-mail function is needed, or how many terminals
tion about the product/service features needed by the user (4.2), the
will be connected to the switch.
knowledge representation for describing users and products/services
We have identified a set of requirements concerning the person-
(4.3), the personalisation strategies for customising the configuration
alisation of the interaction by interviewing people regularly using
task (4.4) and the inference techniques for reasoning about the user's
the configuration systems available to a telecommunication company
interests and expertise (4.5). Section 5 sketches the system architec-
and occasional users of on-line configuration systems. The most rel-
ture and Section 6 concludes the presentation.
evant issues follow.
1. The configuration process may require the specification of a large
2
TELECOMMUNICATION SWITCHES
set of data.
DOMAIN
2. Depending on the user's knowledge, the specification of the pa-
rameter values may be difficult, if not impossible, as the user
The development of the CAWICOMS framework was guided by ap-
might not know the impact of her selections on the configuration
plication scenarios from the telecommunication domain. One of them
solution.
is the configuration of large telecommunication switches for next-
3. Most users are only interested in the cost and the usage charac-
generation public telephony. The core of the product consists of a
teristics of the solution, while they do not care about how it is
switching network that can be decomposed into a set of building
implemented (and therefore about the values to be set during the
blocks called racks, frames and modules. The number of these build-
configuration process).
ing blocks and their structure depends on the required performance
4. Some configuration parameters depend on the customer's features
characteristics and features specified by the customer. Therefore, the
and should be automatically set: e.g., the customer's nationality
core of the switching system is complemented by routing compo-
determines the currency for payments.
nents to conform future IP-based telephony requirements or software
5. Other configuration parameters are so critical that the user must
packages that offer control and maintenance functionality. In order to
take the responsibility to set them. At least in these cases, she
completely specify such a product, up to several hundreds of param-
should be supported with extra-helpful information about the pa-
eters and questions may be posed to the sales person interacting with
rameter.
the configuration system. Users can easily become overstrained and
6. The user should be enabled to postpone some configuration deci-
are unable to overview the configuration process. This is especially a
sions, when she is uncertain about the preferred value for a param-
problem when sales personnel is not well trained or lacks deep tech-
eter, and carry on the configuration of the other aspects of the item
nical knowledge. In those cases, configuration systems play a crucial
under definition.
role as a corporate knowledge management tool, where user specific
knowledge presentation requires an intelligent interface.
We have also identified requirements on the presentation of configu-
In our application domain we identified four user groups differing
ration solutions, but we only sketch them, as this paper is focused on
in the level of product knowledge and the frequency of system inter-
the adaptation of the configuration task.
action: Sales engineers have deep technical knowledge. These users
want to be able to drill down to configuration details and are able
The features of the configuration solution should be presented by
to interact with a non-personalised configuration system without any
taking the structure of the product/service into account. For in-
assistance. Senior sales representatives typically have good knowl-
stance, the structure of a telecommunication switch could be used
edge about the products and services to be configured and reasonable
to present the solution component by component, instead of show-
experience in the usage of configuration systems. Junior sales repre-
ing a flat list of features (as most configuration systems do).
sentative: this category encompasses sales personnel with almost no
Very critical information should be presented, regardless of the
experience, and/or low level of technical understanding. Customers:
user's interests. However, if the information is too complex for
the system is not allowed to assume any training on the product and
the user, additional information should be available in order to
must be prepared to give several explanations. This type of user is
help her understand the presentation.
particularly important, when the configuration system is used as a
The presentation of solutions should be focused on the features
medium to deliver product information.
most relevant to the user's interests: different types of information
120
Figure 1.
A personalised question page generated during a configuration step.
about the configured product/service should be presented, depend-
submits such values to the configuration engine. As in our framework
ing on the user's role. For instance, a technical engineer should get
this engine is based on a constraint satisfaction system, the values are
technical information about the solution, while a manager could
propagated in a constraint network representing a partial solution.
benefit from a presentation focused on its performance and eco-
The propagation may trigger domain reductions on other parameters.
nomic aspects.
After each propagation step, the user is shown another set of pa-
The presentation should be tailored to the user's knowledge about
rameters to be set and their current domains, until the phase is over.
the product/service: for instance, technical details should be hid-
Then, another configuration phase is started, until the whole prod-
den, if they are too complex for the user (and do not represent
uct/service is specified. When the constraint network evolves to a so-
particularly critical information).
lution where each parameter is set to one value, the system presents
As a general rule of Adaptive Hypermedia systems, the user must
the solution. In contrast, if the user's choices generate a failure in the
always be able to access the complete information about the solu-
constraint propagation process, the configuration fails.
tion. This means that details considered irrelevant, or too complex
for the user, should be made available as additional information
about the product/service. In this way, they can be reached on de-
4.2
Management of a Configuration Step
mand (by following "more info" links).
The selection of parameter values within a configuration step is per-
formed by filling in a form that shows the parameters to be set, to-
4
MANAGEMENT OF PERSONALISED
gether with their domain. The form may also include questions about
CONFIGURATION TASKS
the user's preferences for high-level properties of the product/service,
4.1
Interaction Flow
such as its reliability. After having selected the values for the various
questions, the user can submit the form to the configuration system
In the CAWICOMS system, the configuration process is organised in
by clicking on a "go on" button.
phases corresponding to the logical structure of the item to be config-
For instance, Figure 1 shows a typical page generated by our
ured: in each phase, a different component of the product/service is
system during the configuration of a telecommunication switch
configured. Moreover, as each phase may consist of a possibly com-
(TeCOM). The leftmost part of the page displays the list of questions
plex task, the interaction with the user within a phase is managed ac-
the user is asked about and includes configuration parameters (e.g.,
cording to a dynamically generated sequence of configuration steps.
version of the switch, number of analog subscribers) and information
At each step, the user selects values for a subset of the product
about the customer's requirements: her interest in the economy of the
features: these features are represented by configuration parameters,
product, i.e., on how costly the solution will be.
each one associated with the set of its possible values (the domain of
As shown in the figure, a help button ("what does it mean?" link)
the parameter). After the selection of the parameter values, the user
is available behind each parameter to retrieve detailed information
121
property of
The user model also describes the user's interests in different as-
Reliability
product/service
pects of the product, such as its reliability and economy, corre-
configuration
Trunk Lines
Additional
parameter
........
sponding to the properties defined in the Frontend Model. These
number
Server PC
(feature of
product/service)
interests are represented as probability distributions on the values
evaluation of
(levels) of variables associated to such properties. For each vari-
y
y
y
property (y) given
the parameter
able, three level of interest are considered: low, medium and high.
x
x
x
values (x)
The user model stores information about individual defaults, rep-
resenting preferences for particular parameter values. This type of
Figure 2.
Relations between parameters and properties in the Frontend
Model.
preference may be available because the system enables the user
to set "long-lasting" preferences about product features.
about its meaning: for instance, Figure 1 shows the explanation win-
The estimates about the user's interests and expertise are initialised
dow for the "version" of the TeCOM. Notice also that, at each config-
by means of stereotypical information [18] about the most relevant
uration step, the system may set some parameters, by applying per-
classes of users interacting with the configuration system (private
sonalisation techniques. When this happens, the system shows these
customers, sales representatives and technical engineers). Moreover,
settings below the list of questions. For instance, in Figure 1, the sys-
to take individual properties into account, the system's estimates are
tem has set country and currency for the switch.
dynamically updated on the basis of an interpretation of the user's
observable behaviour. (see Section 4.5).
4.3
Knowledge about Products/Services and Users
4.3.1
Introduction
4.4
Personalisation Strategies
The satisfaction of the requirements in Section 3 is based on the inte-
The conceptual representation of products and services stored in the
gration of user modelling, personalisation and flexible dialogue man-
Frontend Model guides the system in the management of a struc-
agement techniques, and on the use of a domain ontology describing
tured configuration session, suggesting the configuration of the prod-
personalisation oriented information about products and services.
uct/service one component after the other, in a possibly hierarchical
order. However, the system enables the user to postpone the setting
4.3.2
Representation of information about products and
of parameters and to select the components that she wants to config-
services
ure first. In this way, mixed-initiative dialogues are managed, where
both the system and the user can take the initiative during the con-
The technical knowledge about products and services is described
figuration process (requirement 6 in Section 3). The Frontend Model
in a Product Model supporting a conceptual, structured description
also supports the user during the setting of parameter values by pro-
of entities with features, components and constraints among com-
viding her with with explanations of the meaning of the parameters
ponents; see [10] and [7]. This model specifies the technical infor-
to be filled in (requirement 5).
mation needed by the configuration engine to generate solutions,
Finally, the assessment of the user's interests and expertise, to-
but does not include high-level information typically addressed dur-
gether with the exploitation of the information stored in the Frontend
ing the interaction with the user. This further type of information is
Model, supports the satisfaction of the first four requirements, as it
stored in the Frontend Model, that extends the Product Model with
enables the system to automatically set parameters and to personalise
data such as the explanation of the meaning of configuration param-
the formulation of questions. Given a configuration parameter to be
eters and an estimate of their technicality and of their criticality de-
filled in, alternative strategies can be used to identify the value(s) to
grees. The Frontend Model also stores the impact of parameters on
be set and a personalisation module evaluates the alternatives, search-
the utility of the solution regarding different aspects and the difficulty
ing for the most promising one:
of knowing such information. For example, Figure 2 shows the rep-
resentation of the impact of some product features (number of trunk
1. If the criticality of the parameter is over a threshold, then ask the
lines, additional server PC) on the reliability of a switch. As shown
user about the value to be set.
in the figure, the number of trunk lines has positive impact on the
2. If the user model contains an individual default value for the pa-
reliability of a switch. Similarly, the number of additional servers
rameter and the value is included in the current domain of the
enhances this product property.
parameter, then set the parameter accordingly.
3. If a personalised default matching the user is available for the pa-
4.3.3
Representation of information about users
rameter and the intersection between the suggested values and the
current domain of the parameter is not null, then set the parame-
The system manages an individual user model storing information
ter to the intersection.
about the user: this model is stored in the system's database, so that
Personalised defaults represent business rules suggesting param-
it is available after the first interaction, and includes various types of
eter settings based on customer's characteristics and are repre-
information:
sented as production rules. The head of the rule specifies a pos-
The user's personal characteristics, such as nationality and enter-
sibly complex and/or condition on the user data. The consequent
prise type, are represented as feature-value
pairs;
suggests a set of values for the requested parameter, together with
ˇ
The user's knowledge about each product/service feature, corre-
the result of the evaluation of the head on the user model. For in-
sponding to a configuration parameter, is represented as a proba-
stance, in the interaction of Figure 1, a simple personalised default
bility distribution on the values of a binary variable, associated to
is applied that sets the "currency" parameter of a telecommuni-
the feature; this variable represents the system's estimates that the
cation switch to the appropriate currency (USD vs. Euro) on the
user knows/does not know the meaning of the feature.
basis of the user's nationality.
122
4. If the parameter is related to some properties for which the user's
services. In an idealisation, we use Multi-Attribute Utility Theory
estimated interest is low, then set a standard (non personalised)
(MAUT [21]) for this purpose. MAUT is a general evaluation scheme
default value consistent with the current domain.
which is applied or at least compatible to the schemes applied by
5. If the user's estimated expertise is sufficient to choose a value for
many user modelling approaches for estimating the user's interests
the parameter, then ask her to set the preferred value, given the
[20]. Many users are also already familiar with MAUT, because it
current domain.
is used by consumer organisations for evaluating products. For ex-
This strategy relies on a comparison between the user's expertise
ample, in Germany, Stiftung Warentest uses MAUT for evaluating
and the difficulty of the parameter in order to estimate the likeli-
consumer products (e.g., digital cameras [22]). According to MAUT,
hood that the user will be able to answer the question [12].
the overall evaluation of an object determines its utility for the user.
6. Given the parameter domain, select the best value and set it, given
Usually, many aspects of an object can be evaluated and not all the
the user's interests in the product/service properties.
users are interested in the same aspects to the same degree. These as-
This strategy exploits the information in the user model to pre-
pects are called value dimensions. For example, a telecommunication
dict the preferred values for the parameter. The properties related
switch can be evaluated on the performance, reliability, and economy
to the parameter in the Frontend Model are used to focus on the
dimensions. In this example, some users are more interested in per-
corresponding user interests, which are analysed to check if a suf-
formance and reliability and less in economy.
ficiently substantiated prediction of the best value can be made.
The overall evaluation is expressed on a numerical scale, e.g., from
Section 4.5 describes the evaluation model ascribed to the user in
0 to 10 and the overall evaluation is defined as a weighted addition
our system.
of the object's evaluation on its relevant value dimensions [21].6 A
7. Elicit (if not yet done) information from the user about her inter-
weight is associated with each dimension to describe the user's inter-
est in properties of the product/service that are influenced by the
ests. The more interested the user is, the bigger the weight is.
parameter to be set. Then, apply strategy 6 to possibly set the pa-
In the same way as for the overall evaluation, the evaluation of the
rameter values.
object on each dimension is based on a weighted addition of the eval-
This strategy is applied to let the user self-assess her interests,
uation of the attributes relevant for this dimension. In order to evalu-
when the information in the user model is not sufficient to per-
ate attributes (in our configuration task, corresponding to parameters
form any prediction.
to be set), a numerical scale is constructed which represents the prop-
8. Postpone the parameter setting to a later stage of the configuration
erties of the levels of an attribute (levels correspond to the parameter
process (last resort).
values). Then, an evaluation function maps evaluation values onto
the attribute levels. For example, regarding reliability a guaranteed
These strategies are sorted by priority because, whenever safe, au-
uptime of 99% yields 10, whereas an uptime of 50% yields 2. For
tomatic parameter settings are favoured over questions to the user.
simplicity, we assume that the evaluation functions of the attributes
However, the selection of the strategy to be applied is a little more
and their weights are fixed. The described weights and the evaluation
complex: while the evaluation of the first three strategies is binary
functions are defined in the Frontend Model. See bottom of Figure 2
(either they suit the current situation, or they do not), the other strate-
in Section 4.3.
gies rely on uncertain information. For instance, strategy 4 depends
For fulfilling the goal of estimating the user's interests, the weights
on the estimation of the user's interest for the properties related to
associated with the dimensions have to be determined. In CAW-
the parameter in focus; similarly, strategy 5 is based on the probabil-
ICOMS, this is done by means of a probabilistic approach and the
ity that the user knows the meaning of the parameter. In order to take
weights are represented as a probability distribution. Initially, a first
this uncertainty into account, the suitability of a strategy is evaluated,
estimate is obtained by using stereotypical knowledge about users. A
in the [0..1] range, and applicability thresholds are defined to rule out
set of stereotypes define categories of users, such as representatives
weak strategies.
of a small company. These stereotypes are activated based on the
For each parameter to be filled in, the personalisation module
user's personal characteristics. Then, the user's observed behaviour
evaluates the strategies, according to their priority, and selects the
in typical situations is interpreted in order to update these estimates.
first one exceeding the application threshold. The selected strategy
The following situations can be processed:
is applied to continue the interaction with the user, either by elicit-
ing information from her, or by autonomously setting the value. The
Self assessment: especially at the beginning of the interaction, the
question pages submitted to the user reflect the fact that the various
system may ask the user about her interests. The user's answer
parameters may be filled in according to alternative strategies. For
reflects her self-assessment, which is very likely related to her in-
instance, in Figure 1, the user is questioned about parameters and
terests, but this fact should not be taken for granted because the
interests; moreover, some parameters are set by the system.
user might misunderstand the meaning of the terminology used
by the system.
4.5
Reasoning About the User's Knowledge and
The user can also change the parameter values that the system pro-
Interests
posed as defaults by applying personalisation strategies. This type
of action provides evidence that the user believes that the change
For applying the personalisation strategies described in Section 4.4,
has a positive impact on the overall evaluation of the configuration
the user's interests and the user's expertise have to be estimated based
solution. In other words, the user believes that the new parameter
on her observable behaviour. The inference mechanism used for this
settings cause a positive shift in the evaluation of the item to be
estimation process has to take into account the uncertainty associated
configured, with respect to the evaluation with the values proposed
with the interpretation of the observations. This is the reason why we
by the system.
use a probabilistic inference mechanism, namely Bayesian networks
After generating a configuration solution, the system presents it.
[16], for this purpose.
Then, the user has to decide whether accepting the solution and
For estimating the user's interests, we have to ascribe the user an
evaluation process which she employs for assessing products and
6 Other possibilities for aggregation are described by [21].
123
ending the configuration process, or not. If she accepts the solu-
The users also appreciated the system's explanation capabilities,
tion, her overall evaluation of the solution is probably quite good.
although only partially developed, because they shed light on the
comples underlying configuration process.
For each of these situations, a Bayesian network has been specified
Moreover, the users asked for more flexibility in the management
which reflects the above described dependencies. These specifica-
of the dialogue between system and user. For instance, they sug-
tions are domain independent. At runtime, the actual network for
gested that the user should be enabled to notify the system that she
processing the situation with the parameters involved is created and
does not care about a value, therefore the system should set it au-
used for the interpretation of the user's behaviour. This interpretation
tonomously. We have incorporated these facilities in our prototype.
results in an update of the probability distributions representing the
Finally, requests for a more flexible management of the overall
weights of the dimensions corresponding to the user's interests.
configuration task came. For instance, the management of reconfig-
For estimating the user's expertise we use an approach based on
uration, with its implications (corrections of previous parameter set-
[12]. For example, if a user is observed to click on a help button,
tings, revision of a configuration solution, recovery from a configura-
she probably does not know the implications of the parameter and
tion failure), was considered essential and is part of our future work.
therefore her expertise is probably low. If we observe that the user
knows the implications of a parameter (e.g., because she specifies a
parameter value), her expertise is probably high.
REFERENCES
[1] L. Ardissono, A. Felfernig, G. Friedrich, A. Goy, D. Jannach,
M. Meyer, G. Petrone, R. Schaefer, W. Schuetz, and M. Zanker. Per-
5
SYSTEM ARCHITECTURE
sonalising on-line configuration of products and services. In Proc. 15th
Conf. ECAI, to appear, Lyon, 2002.
The CAWICOMS system is based on a modular, distributed architec-
[2] L. Ardissono, A. Felfernig, G. Friedrich, A. Goy, D. Jannach, R. Schae-
ture, where a specialised module is associated with each main task to
fer, and M. Zanker. Web-based commerce of complex products and
be carried out during the interaction with the user: e.g., configuration,
services with multiple suppliers. In Thoben, editor, E-Business Appli-
cations, to appear. Springer Verlag, Berlin.
user modelling, personalisation and generation of the Web pages.
[3] L. Ardissono, A. Felfernig, G. Friedrich, D. Jannach, R. Schaefer, and
The system is implemented in Java and exploits standard software
M. Zanker. A framework for rapid development of advanced web-based
development environments. The user interface consist of a sequence
configurator. In Proc. 15th Conf. ECAI, to appear, Lyon, 2002.
of Web pages, implemented as JSPs, whose content is dynamically
[4] L. Ardissono and A. Goy. Tailoring the interaction with users in Web
stores. User Modeling and User-Adapted Interaction, 10(4):251303,
generated on the basis of the interaction context and the application
2000.
of the personalisation strategies. The JSPs run within an Apache Web
[5] L. Ardissono, A. Goy, G. Petrone, and M. Segnan. Personalization in
Server. Specialised, commercial engines are used within the system
business-to-consumer interaction. Communications of the ACM, Spe-
to perform complex tasks: for instance, the ILOG's JConfigurator en-
cial Issue "The Adaptive Web", 45(5):5253, 2002.
gine [10, 15, 13] is used to generate configuration solutions.
[6] BroadVision. Broadvision. http://www.broadvision.com.
[7] A. Felfernig, G. Friedrich, and D. Jannach. UML as domain specific
language for the construction of knowledge-based configuration sys-
6
DISCUSSION
tems. Int. Journal of Software Engineering and Knowledge Engineer-
ing (IJSEKE), 10(4):449469, 2000.
[8] FIAT. buy@fiat: la tua prossima auto. http://www.buy@fiat.com, 2001.
We have presented the personalisation facilities offered by CAW-
[9] Fidelity
Investments.
Insurance
center
@fidelity.
ICOMS, a framework for the Web-based configuration of products
http://www400.fidelity.com:80/, 2001.
and services. These facilities allow tailoring the interaction style to
[10] ILOG. ILOG JConfigurator. http://www.ilog.com/products/jconfigurator/,
the individual user and also support her in the configuration of the
2002.
[11] Net Perceptions Inc. Net perceptions. http://www.netperceptions.com.
product/service which suits her needs best. The personalisation of the
[12] A. Jameson. Knowing What Others Know: Studies in Intuitive Psycho-
interaction is based on the integration of a user-oriented view of the
metrics. PhD thesis, University of Amsterdam, 1990.
configuration task with the technical level at which configuration sys-
[13] U. Junker. Preference-programming for configuration. In IJCAI Con-
tems usually work. This result is achieved by integrating constraint-
figuration Workshop, pages 5056, Seattle, 2001.
based configuration techniques with user modelling, personalisation
[14] A. Kobsa, J. Koenemann, and W. Pohl. Personalized hypermedia pre-
sentation techniques for improving online customer relationships. The
and dialogue management techniques. Our approach also uses a do-
Knowledge Engineering Review, 16(2):111155, 2001.
main ontology describing personalisation-oriented information about
[15] D. Mailharro. A classification and constraint-based framework for con-
the items to be configured. We have applied this framework to the
figuration. AI in Engineering, Design and Manucturing, 12:383397,
development of a prototype system for the configuration of telecom-
1998.
[16] J. Pearl. Probabilistic Reasoning in Intelligent Systems: Networks of
munication switches; moreover, a second prototype, supporting the
Plausible Inference. Morgan Kaufmann Publishers, San Mateo, CA,
configuration of IP-VPNs, is under development.
1988.
We have performed a first test of the personalisation facilities of-
[17] P. Resnick and H.R. Varian, editors. Special Issue on Recommender
fered by the telecommunication switches prototype, with a limited
Systems, volume 40. Communications of the ACM, 1997.
number of users having different background and playing different
[18] E. Rich. Stereotypes and user modeling. In A. Kobsa and W. Wahlster,
editors, User Models in Dialog Systems, pages 3551. Springer Verlag,
roles in their organisations (managers, technicians, etc.). The results
Berlin, 1989.
show that such facilities are appreciated, especially as far as the au-
[19] D. Riecken, editor. Special Issue on Personalization, volume 43. Com-
tomatic setting of parameters is concerned, because it speeds up the
munications of the ACM, 2000.
configuration process, leveraging the selection of the values for the
[20] R. Sch¨afer. Rules for using multi-attribute utility theory for estimat-
ing a user's interests. In Proc. 9. GI-Workshops: ABIS-Adaptivit¨at und
parameters to be set. However, they want to control the system's de-
Benutzermodellierung in interaktiven Softwaresystemen, 2001.
cisions, possibly overriding them. For this reason, we have modified
[21] D. von Winterfeldt and W. Edwards. Decision Analysis and Behavioral
the user interface, to produce editable personalised suggestions: these
Research. Cambridge University Press, Cambridge, UK, 1986.
suggestions should respect the user's preferences, but if they do not,
[22] Stiftung Warentest. Digitalkameras: Pixeljagd. test, (6), 2000.
she can correct the settings.
124
Deployment of Configurator in Industry :
Towards a Load Estimation
Michel Aldanondo1 - Guillaume Moynard1,2
Abstract: Our communication deals with configurator deployment
2 THE CONFIGURATOR DEPLOYMENT
in industry. Our goal is to define an estimation function that permit
LOAD ESTIMATION PROBLEM
to quantify the workload necessary for deploying a configuration
software in industry. As this work is in progress, we mainly focus
on the configurator deployment problem and relevant estimation
2.1 Configurator deployment, a two step problem
factor definitions. At the end of the paper, we provide some ideas
about the estimation function.
Deploying a configurator can be decomposed in two steps : (i)
modeling the product and (ii) coding the model in the configurator.
I INTRODUCTION
The purpose of the modeling step is "to put on the paper" the
Configuration software is becoming more and more frequently used
configurable product.
by companies fighting in the mass-customization market. Almost
Normally, this activity should be conducted without taking into
all the ERP software proposes now configuration modules fully
account the configurator that will be deployed. But in fact, most of
integrated in their offer as reported in [1]. The Lapeyre group, a
the configurator vendors propose some modeling tools that fit their
European leader in industrial carpentry (windows, door, kitchen
software. Some scientific modeling approaches can be found
furniture...),
has
been
being
a
relying on various frameworks can be found in [5] for constraint
significant user of configuration for
satisfaction problem approaches or [6] for oriented object
almost 10 years. For the Lapeyre group
Configurator
modeling.
and for many companies deploying
Need
As we target selling and manufacturing aspects, modeling is, most
configuration software, an important
of the time, achieved by people from product marketing, product
issue deals with the following questions
design and product manufacturing teams. The variety of persons
Configurator
(figure 1) : "for each configurator
Deployment
and product knowledge involved in modeling makes this modeling
deployment, how many man-months of
- work load
phase very delicate. People from design and manufacturing
- cycle time ?
deployment capacity should I forecast ?
"discover" what the marketing team thinks in terms of product offer
what would be the resulting deployment
and, at the opposite, marketing and selling persons "discover" that
Figure 1 The problem
cycle time ?".
some new customization possibilities that they would never dare to
ask are in fact very easy to handle. Sometimes getting these people
If some scientific works have been achieved for this question for
around a modeling table generates conflict and withholding
ERP deployment in terms of method and approaches, as far as we
information is frequently observed. Thus, human factors and
know, deployment load estimation for configuration software is not
company organization are important factors for a smooth
very frequent in the open scientific literature. Many configurator
deployment achievement.
vendors have got their own method and approaches, but very few of
In our wok, modeling is decomposed in product configuration
them have been presented or discussed, some ideas can be found in
model design and bill-of-materials configuration model design. In
[2]. Some rare estimation works in the field of product design are
order to discuss load deployment factors, we rely for (i) product
closer to our estimation goal, see [3] and [4].
model on a CSP based modeling approach (variable, domain,
constraint) as shown explain in [5] and for (ii) bill-of-materials
Our goal is therefore to determine a quantitative estimation
model on a generic bill of materials inspired form the work
function for configurator deployment load ; the problem of the
presented in [6]. Of course these two models are related in order to
deployment cycle time will not be studied. This work, conducted by
derive the configured bill-of-materials from the configured product.
a Ph.D. student, is taking place in the Lapeyre group and gathers
both selling aspect (product configuration) and manufacturing
The purpose of coding step is "to enter the product model" in the
aspects (bill-of-materials configuration). This work is in progress
configurator.
and the presented results deal mainly with factors identification.
In a perfect world, this activity should be conducted by somebody
Some ideas about the estimation function establishment will be
that knows only about configuration and configurator utilization
provided.
without any product specific knowledge. As the product knowledge
is gathered in the model on the "paper", the person in charge of
The communication is divided in three parts. We first address the
modeling should just translate the model into the coding entities
configuration deployment problem and underline the need for some
existing in the configurator.
estimation calculus. Then, we propose and discuss load estimation
As it has already been pointed out, most of the time, modeling is a
function factors. In the last part, we present the work that we intend
little bit dependant of the configurator. Therefore it happens
to do concerning the load estimation function set up.
sometimes, that model designing and coding are achieved by a
same person. Nevertheless, we think that the load estimation
function has to be considered for the two different steps, and we
assume that the coding team members receive a valid model form
1 DRGI - Ecole des Mines d'Albi - Campus Jarlard - Route de Teillet -
the modeling team members. Once coding is done, an important
81013 Albi CT Cedex 09 - France
sub-step is to check if the resulting configurator is valid. This is an
2 Lapeyre-GME - 2-4 Rue André Karman - 93200 Aubervilliers
important and hard issue (elements about this problem can be found
France
in [7] or [8]) and such validation is most of the time done by the
coding person with some help from model designers.
125
As a conclusion, the following aspects :
Finally, an important point not already mentioned is relevant to the
·
many people involved from various company teams,
deployed configuration software. For this study, only one
·
organization of modeling and coding,
configuration software (provided by a configuration software
·
information sharing problem,
company) is used, therefore the estimation function is valid for this
·
product and configurator knowledge distribution,
single software. But each software has good and bad deployment
tend to generate long and difficult configurator deployment
capabilities and therefore we can assume that the results can be
projects. Many companies measure configurator set-up workload in
extended for other configurators.
man-years of modeling, coding and maintenance. Thus, before
The next section presents and discusses the estimation factors.
deploying a configurator in a company or extending an existing
configurator to a new facility or a new product family, being able to
estimate the effort that will be done is of great interest. In order to
3 LOAD DEPLOYMENT FACTORS
do so, next sub-sections introduce the load estimation function.
The identified factors are the result of various configuration
2.2 Load estimation function set-up elements
deployment case analysis. They must be considered as a first set
that has been validated by configuration deployment experts. This
The objective of the estimation function is to calculate the
set will be improved when the first estimation function will be
deployment work amount in load units "man-months" with respect
tested.
to factors. Our goal is therefore to propose a function as :
3.1 Industrial situation estimation factors
Load = F ({factors})
These factors can be gathered in two sub-groups characterizing (i)
In order to establish F, we will first identify factors characterizing :
the company know-how in terms of industrial organization and (ii)
·
the industrial situation and organization in front of the
the organization of the persons involved in the deployment project.
deployment project,
Once the factors of each sub-group are quantified, they can be
·
the product size and complexity.
aggregated in a single factor that will be used in the estimation
Then, configuration deployment cases will be investigated in order
function.
to gather data provided by configurator deployment experts who are
either project managers or consultants. The data can result :
3.1.1 Company industrial organization factors
·
from effective deployment : quantitative values for factors and
measured load,
These factors characterize the general behavior of the company in
·
from quantitative estimation : factor values are provided to the
front of any software deployment. These factors can be taken into
expert who gives in return load estimation.
account when estimating the load deployment of ERP or PDM
We will then have a set of cases ({factor value}, Load }, that
systems for example. Four factors have been identified.
should permit us to derive the estimation function.
F1.1 : Management capabilities factor.
2.3 Two levels of load estimation
F1.1 characterizes :
·
the existence of company projects dealing with : quality
assurance, process reengineering, total quality control...
One of the problems of project load estimation is to decide when
·
and with what kind of information load estimation can be
the existence of regular utilization of project management
undertaken. Discussions with various configurator deployment
techniques,
experts allow concluding that two levels are interesting.
Factor quantification :
·
if both exist : F1.1 = 1
The first one corresponds with an order of magnitude estimation.
·
if none exists: F1.1 = -1
This estimation must be conducted in around a single day of work
·
if one of the two exists : F1.1 = 0
involving a specialist of each company team (marketing, design,
manufacturing and presumed project leader). The accuracy of the
F1.2 : Sub-contracting factor
load estimation can be quantified around +/- 50%. Therefore this
F1.2 characterizes if
kind of load estimation is done before the configurator deployment
·
product manufacturing,
final decision. We call this one : "rough estimation".
·
analysis before software deployment,
·
coding or customizing the software,
The second one is more detailed and can need up to ten days of
are subcontracted.
work and requires some product modeling work. The idea is to
Factor quantification :
estimate the load with some formalized elements concerning the
·
if nothing is subcontracted : F1.2 = 1
configurable product. This allows reducing estimation inaccuracy
·
if one activity is subcontracted : F1.2 = 0
down to +/- 20%. This kind of estimation is, most of the time, done
·
if more than one activity is subcontracted : F1.2 = -1
once the configurator deployment is decided in order to plan the
resouce deployment. We call this estimation : "detailed estimation".
F1.3 : Multi-lingual factor
F1.3 characterizes if the people involved in the deployment speak
2.4 Conclusions
the same language and if the software will use more than one
language.
The need for configurator deployment load estimation function has
Factor quantification :
been shown. Two estimation levels, rough and detailed, have been
·
one language : F1.3 = 1
introduced. Our estimation targets to cover selling purpose (product
·
more than one language : F1.3 = -1
configuration)
and
production
purpose
(bill-of-materials
configuration). Estimation factors are split in two groups :
F1.4 : Multi-location layout factor
industrial situation factors and product factors.
F1.4
characterizes
if
sale,
design
and
manufacturing
are
implemented in different physical locations.
126
Factor quantification :
Factor quantification :
·
one location : F1.4 = 1
Figure 3, equivalent to figure 2 plus ellipses representing persons
·
more than one location : F1.4 = -1
shows typical cases of knowledge and know-how distribution
among the persons involved in the project.
The company industrial organization factor, F1, aggregates these
four factors through a sum. Therefore FI ranges from 4 to +4
corresponding with very low and very good situation for software
deployment.
Case - 1
Case - 3
3.1.2 : Configurator deployment involved person factors
These factors characterize the general organization and knowledge
of the persons that could be involved in the configurator
Case - 2
Case - 4
deployment. They are more specific to configurator deployment
that the previous factors. Four factors have been identified.
Figure 3 Examples of Skills and knowledge distribution
F2.1 : Product knowledge existence factor
Case 1 and 4 represents project organization with highly
F2.1 characterizes if a single person with a good global knowledge
specialized person requiring strong and frequent information
level can be easily identified for each of the major following
exchanges that will tend to slow the deployment.
knowledge field :
Case 2 and 3 represents some kind of good complementary skill
·
marketing and/or selling process,
and know-how with some interesting overlapping in case 3.
·
product design,
Therefore, for organization close to :
·
product manufacturing.
·
case 3 and 2 : F2.4 = 1,
Factor quantification :
·
case 1 and 4 : F2.4 = -1.
·
if the three knowledge fields are covered : F2.1 = 1
·
if two of the knowledge fields are covered : F2.1 = 0
As for factor F1, the configurator deployment involved person
·
if only one knowledge field is covered : F2.1 = -1
factor, F2, aggregates these four factors through a sum. F2 ranges
from 4 to +4 corresponding with very low and very good project
F2.2 : Modeling knowledge existence factor
resource organization for configurator deployment.
F2.2 characterizes if a person in the company has already made
some generic modeling, or if some models (whatever the formalism
3.1.3 : Conclusion on Industrial situation estimation factors.
is) already exist for :
·
product configuration, (for sale and design)
Eight factors are used to characterize the industrial situation. These
·
bill-of-materials configuration. (for manufacturing)
eight factors are aggregated in two factors ranging from [-4, +4] :
Factor quantification :
·
F1 : Company industrial organization factor,
·
if both are covered : F2.2 = 1
·
F2 : Configurator deployment project involved person factor.
·
if one kind of model is covered : F2.2 = 0
These two factors will be used to determine the estimation function.
·
if nothing has been done in modeling : F2.2 = -1
If gathered data coming from deployment cases is sufficient, it will
be possible lately to consider the eight factors in the estimation
F2.3 : Configuration model coding knowledge existence factor
function.
F2.3 characterizes if a person in the company has already
In terms of estimation level, rough and detailed estimation use
implemented in a configurator, a spreadsheet or in any computer
exactly the same factors. Of course, for detailed estimation, as more
language :
time can be used to study the case, the industrial situation analysis
·
product configuration model,
provides much accurate value for these factors.
·
bill-of-materials configuration model.
Factor quantification :
3.2 Product estimation factors
·
if both have been coded : F2.3 = 1
·
if one kind of model has been coded : F2.3 = 0
These factors target to take into account the product size and
·
if no coding has been done : F2.3 = -1
complexity in configurator deployment. By "size" we want to
characterize the amount of characteristics needed for product and
F2.4 : Project organization factor
bill-of-materials configuration modeling and coding. Complexity
F2.4 characterizes a possible distribution of knowledge and know-
tends to modulate this amount with the conceptual effort relevant to
how of the people that could be involved in deployment. Product
the interdependencies of characteristics.
knowledge can deal with selling, designing and manufacturing,
We discuss rough estimation then detailed estimation. For each of
while know-how is relevant to modeling and coding of product and
them we will sequentially analyze product configuration and bill-
bill-of-materials. This can be summarized in the table of figure 2.
of-materials configuration factors.
Sale
Product
Product
For these two estimations, the load estimation is conducted for a
design
manufacturing
product family that has been identified as representative of all the
company configurable products. Then this "product family load" is
Product
extrapolated to all products of the company. Therefore, families are
Knowledge
identified with an extrapolation factor providing the family
Modeling
extrapolation factor set.
Know_how
Coding
F3-4.1 : Family extrapolation factor
Know_how
Factor quantification: F3-4.1: { (family_ref , extrapolation_factor) }
Product
Bill-of-mats.
For example if two product families have been identified :
configuration
configuration
family_ref_1 and family_ref_2. If :
Figure 2 Skills and knowledge distribution
127
·
family_ref_1 has been chosen as representative
·
increases the amount of basic modeling and coding due to the
·
F3-4.1 = { (family_ref_2, 0.6) },
total number of variables
Therefore : Load(family_ref_2) = 0.6 * Load(family_ref_1)
·
increases maintenance effort by having two models and
relevant pieces of code to maintain instead of one.
3.2.1 Product rough estimation factors
Interesting elements concerning this hard problem of family
identification can be found in [10].
For this estimation, there is no modeling work just some rough
analysis made through discussions with some people from
3.2.1.2 Bill-of-materials configuration factors
marketing, design, and manufacturing.
As bill-of-materials generic modeling consist of a hierarchical
3.2.1.2 Product configuration factors
physical decomposition of the product. The resulting model shows :
·
standard components (with frozen characteristics) at the
As we rely on CSP modeling approaches for product configurable
lowest level of the bill-of-materials,
modeling, the factors will deal with variable number, variable
·
generic sub-assemblies for the intermediate levels,
definition domain size and constraints. The three following factors
·
father-child links with some conditional existence rule
have been identified and must be quantified for the representative
between :
product family.
·
upper
level
configured
product
and
generic
sub-
assemblies,
FR3.1 corresponds with an estimation of the number of
·
generic sub-assemblies of different levels,
configuration variables. We mean by configuration variables,
·
generic sub-assembly and standard components.
variables that would be present in a CSP based model.
For rough estimation, factors just deal with standard components
Factor quantification : FR3.1 : number of variables
and bill-or-materials decomposition levels.
FR3.2 corresponds with an estimation of an average variable value
FR4.1 corresponds with an estimation of the number of different
number.
standard components that can be present at the lowest level of the
Factor quantification : FR3.2 : average number of variable values
generic model bill-of-materials.
Factor quantification : FR4.1 : number of standard components
FR3.3 corresponds with an estimation of complexity. For us
complexity means the degree of interdependence existing between
FR4.2 corresponds with an estimation of the number of
the variables. In a CSP based model, this could represent some kind
decomposition levels that should be present in the generic model of
of ratio taking into account : variable quantity and number of
the hierarchical bill-of-materials of the family.
constraints (gathering compatibility and activity constraints in the
Factor quantification : FR4.2 : number of bill-of-materials level
sense of DCSP approach of Mittal et al [9]). As no modeling is
done for the rough estimation, complexity is estimated with the
These two factors permit in fact to get an order of magnitude of the
selection in figure 4 of one of the four cases representing different
number of generic sub-assemblies and relevant bill-of-materials
level of variable interdependence. Each small cross represents a
links, which correspond to the modeling and coding workload.
configuration variable and each line a constraint between the two
As constraints are mainly taken into account in the CSP based
variables.
product model, we do not take into account a complexity factor for
generic bill-of-materials modeling and coding.
3.2.1.3 Conclusion about product rough estimation factors
The proposed factors have been discussed with different people
who are familiar with configurator deployment problems. We think
very low
low
high
very high
that three points might be subject to discussion and may need
further investigation :
Figure 4 Product complexity estimation
·
FR3.2 : when the configuration variable definition domain is
Factor quantification :
continuous (for example when dealing with parametric or
·
very low complexity : FR3.3 = -2
tailored components) the meaning of "average number of
·
low complexity : FR3.3 = -1
variable values" should be different.
·
high complexity : FR3.3 = 1
·
FR3.3 : the discretization of product complexity in four levels,
·
very high complexity : FR3.3 = 2
·
FR4 factors : the fact that bill-of-material complexity is not
taken into account.
With the proposed factors, it is to be noticed that identification of
the number of product families is of importance and has an
3.2.2 Product detailed estimation factors
important impact on the estimation.
Let us consider, for example, a case where the configurable
When this estimation is processed, the generic modeling of the
products are windows and doors. It is possible to consider :
representative family has been done for both product and bill-of
·
either 2 families with for each family :
materials configuration. Therefore, the estimations of some factors
·
number of variables, FR3.1 = 15
are replaced by measurement achieved on the models.
·
complexity : low
·
3.2.2.2 Product configuration factors
or one family
·
number of variables, FR3.1 = 20
·
As the CSP based model is on the "paper", the factors F3.1 and
complexity : very high.
F3.2 are the same except that the numbers are counted on the
It is not easy to decide what is the best solution. The two family
model. For F3.3, the estimated complexity is replaced by the
case :
·
number of constraints that are present in the model.
limits modeling and coding complexity during deployment,
128
Factor quantification : FD3.1 : number of variables
·
F3-4.2 = { (family_ref_1, family_ref_2, 0.1) },
Factor quantification : FD3.2 : average number of variable values
Therefore : Load(family_ref_2) = (1-0.1)*0.6*Load(family_ref_1)
Factor quantification : FD3.3 : number of constraints
4 LOAD ESTIMATION FUNCTION
At this time of the study, in order to be consistent with the
complexity factor FR3.3, we consider product complexity close to
At the present time, we are working on the determination of the
the ratio : number of variables / number of constraints.
load estimation function and this section presents our current ideas
about :
3.2.2.2 Bill-of-materials configuration factors
·
the estimation function shape we hope to get,
·
As in the previous sub-section factor values are not estimation
the deployment load data collection,
·
anymore but rely on the bill-of-materials model analysis. The
cases gathering.
definition of FD4.1 is unchanged. But for FD4.2, instead of the
number of hierarchical levels of the generic bill-of-materials, we
4.1 Estimation function
consider the number of generic sub-assemblies that are present in
the model.
The estimated function will be characterize by the following
elements :
Factor quantification : FD4.1 : number of standard components
·
The estimated deployment load for product configuration
Factor quantification : FD4.2 : number of generic sub-assemblies
(Load_3) and bill-of-materials configuration (Load_4) are
additive. This mean that two independent load estimation
At this time of the study, we do not take into account the number of
function, f_3 and f_4, respectively for product and bill-of-
generic links of the bill-of-materials and the number of constraints
materials should be identified :
or rules modulating links existence. This might be necessary in a
·
Load_3 = f_3(F3.1, F3.2, F3.3)
very close future.
·
Load_4 = f_4(F4.1, F4.2)
·
These two deployment loads are added and modulated, with a
3.2.2.3 Conclusion about product detailed estimation factors
function f_1, according to industrial situation estimation
factors introduced in
section
3.1.
Company industrial
As for the rough estimation factors, these factors have been
organization
factors
(section
3.1.1)
and
configurator
discussed. The main improvement that have been proposed is to
deployment project involved person factors (section 3.1.2) are
take into account the fact that pieces of product and pieces of bill-
first aggregated in a function f_2.
of-materials (or sub-assemblies) might be used several times for a
same product family.
These assumptions permit to present the shape of the estimation
For product modeling and coding, this means that some
function we target :
configuration variables grouping is possible. For example, a
F ({factors}) =
configurable fastening device may be configured more than one
f_1 [ f_2 (F1, F2) , f_3(F3.1, F3.2, F3.3) + f_4(F4.1, F4.2) ]
time during the configuration of a single window. In order to avoid
multiple modeling and coding of a same device many configurators
The major drawback of the estimation function shape is that
and some modeling approaches [11] or [12] propose a notion of
industrial situation estimation factors modulate in a same way
"group of configuration variables" with re-use possibilities.
product and bill-of-materials deployment load. This could be of
For bill-of-materials modeling and coding, it is obvious that a
course decomposed, but the number of investigated cases would be
single generic sub-assembly can be re-used in different branches of
necessary much larger.
the generic hierarchical bill-of-materials. For example, considering
the configurable fastening device as a generic sub-assembly, it is
4.2 Deployment load data collection
clear that this sub-assembly will be modeled one time and the
corresponding piece of code re-used in the configurator when
As explain in section 2.2, data can result from effective deployment
necessary.
measurements or quantitative estimation of theoretical deployment
cases.
3.2.3 Conclusions about product estimation factors
For both data sources, once factor values are identified the
deployment load is gathered in a table as shown in figure 5. This
The proposed set of factors must be considered like a first
table allows collecting data in various ways :
proposition. We are, at that time, far from the final validation, but
·
detailed data collection, with load corresponding with (1)
we think that the proposed elements permit to establish a good first
combinations, that allows the most detailed statistical analysis,
approach of the estimation problem.
·
semi-detailed data collection, with load corresponding with (2)
For the family load extrapolation mechanism introduced in the
or (3) combination allowing some differentiation according to
beginning of section 3.2 that permits to determine, from the
product/bill-of-materials or modeling/coding in the statistical
analysis of a single product family, the deployment load of all
analysis,
product families, it is obvious that the re-use problem presented in
·
global
data
collection,
corresponding
with
the
total
section 3.2.2.3 is to be considered. This must provide a re-use
deployment load (4) that does not permit any differentiation.
factor between families for both modeling and coding of both
product and bill-of-materials.
Bill-of-
Product
material
F3-4.2 : Family re-use factor
Modeling
(1)
(1)
(3)
Factor quantification: F3-4.2:
{ (family_ref_x, family_ref_y, re-use_factor) }
Coding
(1)
(1)
(3)
For example if two product families have been identified :
family_ref_1 and family_ref_2. If :
·
(2)
(2)
(4)
family_ref_1 has been chosen as representative,
·
F3-4.1 = { (family_ref_2, 0.6) },
Figure 5 Data collection possibilities
129
This way to collect data is interesting mainly for completed
[11] D. Sabin and E.C. Freuder, Configuration as Composite Constraint
effective deployment, where project decomposition can vary and
Satisfaction,
Proceedings
of
the
Artificial
Intelligent
and
load measurements can not provide detailed data. Most of the time
Manufacturing Research Planning Workshop, AAAI Press, pp. 153-
project decomposition is done according to the product/bill-of-
16, 1996.
materials deployment criterion and relevant set of data (2) is most
[12] M. Véron and M. Aldanondo, Yet another approach to CCSP for
configuration problem, ECAI Workshop on Configuration, Berlin
often collected.
Germany, pp 59-62, 2000.
4.3 Cases gathering.
We try to gather cases according to common experimental design
rules that permit to avoid that some factor level disturb the
estimation function while taking into account some factors
correlation possible existences.
5 CONCLUSION
We have presented in this communication elements trying to
calculate a load estimation function for configurator deployment.
This work is in progress and we are currently gathering data. We
hope to be able very soon to show some quantitative results in
terms of functions.
The proposed set of factors need a strong validation and some
improvements will be necessary. Nevertheless, they can be
considered as a first basis for discussion.
During this factor identification work, all the discussions we have
been having in industry with people involved in configuration
software deployment, permit to conclude that load deployment
estimation is a main issue for companies that either provide or use
configuration software.
REFERENCES
[1] Gartner Group. Supercharge the Sales Effort: Sales Application for
Large Enterprise, Strategic Report Analysis n° R-14-4280, Gartner
Research, September 2001.
[2] M. Aldanondo, S. Rougé and M. Veron, Expert Configurator for
Concurrent Engineering: Cameleon Software and Model, Special
Issue: Production Systems Design and Control, Journal of Intelligent
Manufacturing, Vol. 11, n° 2, pp. 127-134, April 2000.
[3] H.A. Bashir and V. Thomson, A quantitative estimation methodology
for design project. IEPM 1999 conference, Vol 2 pp 198-506,
Glasgow UK, july 1999.
[4] A.T. Bahill and W.L. Chapman. Case studies in system design.
Workshop on system engineering and computer based system. pp 43-
50, Picataway NewJersey USA 1995.
[5] M. Aldanondo M., G. Moynard and K. Hadj-Hamou., General
configurator requirements and modeling elements, ECAI Workshop
on Configuration, Berlin, Germany, pp. 1-6, 2000.
[6] A. Felfering, G. Friedrich and D. Jannach, UML as domain specific
language for the construction of knowledge base configuration
system, 11th Int Software Engineering and Knowledge Engineering
conference, Kaserlautern, Germany, pp 337-345, 1999.
[7] A. Felfering, G.Friedrich, J. Dietmar and M. Stumptner, Exploiting
structural abstraction for consistency based diagnosis of large
configurator knowledge bases, ECAI Workshop on Configuration,
Berlin, Germany, pp 23-28, 2000.
[8] M. Sabin, M. and E.C. Freuder, Detecting and resolving
inconsistenciy and redundancy in conditional constraint satisfaction
problems, AAAI Workshop on Configuration, Orlando, USA, pp 90-
94, 1999.
[9] S. Mittal and B. Falkenhainer, Dynamic Constraint Satisfaction
Problems , 9th National Conference on Artificial Intelligence AAAI,
Boston, USA, pp 25-32, 1990.
[10] N. H. Mortensen, B. Yu, H.S. Skovgaard and U. Harlou, Conceputal
modeling of product families in configuration projects, ECAI
Workshop on Configuration, Berlin, Germany, pp. 68-73, 2000.
130
Document Outline
- 09p02-Pargamin.pdf
- 09p02-Pargamin.pdf
- 1 INTRODUCTION
- ţ˙
- RENAULT VEHICLE DIVERSITY SPECIFICATION AND MODELLING
- PRINCIPLES OF RENAULT CONFIGURATION ENGINE C2G
- FILTERING ON A MAXIMUM PRICE
- SUMMARY AND CONCLUSION
- 22p14-Bensana.pdf
- INTRODUCTION
- NON ANALYTIC KNOWLEDGE
- Data collection
- Computer object code
- Proposed framework
- Generalization
- Knowledge characterization
- Approximation background
- Work orientation
- NEURAL NETWORKS
- Mathematical formulation for neural nets
- Definition of a neural network
- Neural nets for approximation
- Multi-Layers Perceptron
- Radial Basis Functions Neural Nets
- Adequation
- EXPERIMENTATION
- Evaluating neural-based approximation
- First experimentations
- Example
- Architecture of networks
- Learning algorithms
- Testing
- Preliminary results
- CONCLUSION