From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
Case-BasedReasoning in the Configuration of
Telecooperation Systems
J6rg Rahmer+ and Angi VoB*
+ GMD
- German
NationalResearchCenterfor InformationTechnology
Rheinstr.75,
D-64295Darmstadt
Germany
joerg.rahmer@gmd.de
" GMD
- German
NationalResearchCenterfor InformationTechnology
SchloBBirlinghoven
D-53754
SanktAugustin,
Germany
angi.voss@gmd.de
have, the acquisition and indexingof our cases and howto
retrieve themmanually.Weconcludewith the presentation
of a general methodfrom CBRand resource-orientated
configurationfor configuringautomatically.
Abstract
Ourapplicationis the configurationof telecooperation
systems.Theneedfor newconfigurationsystemsin this
area matcheswell with the advancesin the AI domain.We
argue that case-basedreasoningis very useful in the
configurationof telecooperationsystemsandshowthe
extensionof an existingresource-oriented
configuratorto
reasonwithcases. Finallywepresenta generalmethod
from
case-basedreasoningandresource-oriented
configuration.
Thereby
specialconsideration
is givento the reuseof cases
whichis doneby adaptation.
Cases are useful in the configuration of
telecooperation systems
Introduction
Components
and Functionalities of telecooperationsystems
are evolving rapidly. The need for new configuration
systemsin this area matcheswell with advancesin the AI
domain,especiallyin the configurationarea. So in 1994the
DeutscheTelekomAGhas started a project in co-operation
with the GMD
to evaluate the need for a knowledge-based
configuration system (B0hm&Uellner1996). In 1995
different apporachesto configuration were evaluated. As
one result the resource-oriented approach was chosen
(Rahmer&Sprenger 1996) and its usefulness was
demonstrated for private customers and very small
companies.In 1996the domainis extendedto middle-sized
companies (Erode et al. 1996). Furthermore the
configuration system has to be enhancedwith case-based
reasoning (CBR).
In this paper wesuggest to exploit previously configured
telecooperationsystemsas cases for the configurationof a
newsystem. Therebyour approachis pragmatic. Wefirst
support manualcase retrieval and reuse. After that we
enrich it gradually by automatic methods. Westart the
paper with a very short introduction in the domainof
telecooperationsystemsand motivatewhycases are useful
in this domain. Then we describe the kind of cases we
93
World-widethere are millions of telecooperation systems
and a lot of them are documented, at least on paper
(Telekom1994). Wedo not haveto look very far, they are
part of our daily life. Almostevery reader will have a
telephone at home. This is the simplest exampleof a
telecooperationsystem. It allows you to communicate
with
other peopleby using the telephoneservice. Probably,you
will also havea PCwith specific communication
software
and a modem
connected to the public network. Thusyou
can also use fax-, ftp- or email-services.Moresophisticated
examplesare foundin the fields of industry, government
or
academia.There, all members
of an institution cooperate
using several services supplied by the telecooperation
systemof their institution, like the telephoneservice, the
file transfer serviceor the emailservice.
Simplifiedconfiguration of telecooperationsystemsmeans
to fulfill requiredfunctionalities by selecting components,
like a telephone, a personal computer or software,
arranging them in a layout and combining them via
networks.Afirst restriction is that the configuredsystem
shouldwork,other requirementsinvolvecosts, robustness,
extendibility,security,etc.
To answer the question why cases are useful in the
configurationof telecooperationsystemswefirst regard a
clearly specified configurationproblem.A private person
wants to use the telephone service and someinformation
services offered by the WWW.
So a compatible
combination of telephone, PC, modem,software, and
networkhaveto be selected. This is a daily configuration
problemin the shops of the GermanTelecomAG,and it
wouldbe moreefficient and also an improvement
to havea
standard configuration called "private person with PC"
which could be selected and adapted. So instead of
respecifiying andreconfiguringa simpleroutine task again
and again, cases can be used to avoid unnecessaryfrom
scratchsolvingin a natural way.
Butin practice, a clear specificationin termsof a complete
and consistent set of requirements is rare. Often, the
customerprefers to select somecomponentsrather than
specifying her/his needsexactly. Andinstead of a single
concretecomponent,
s/he mayselect a set of alternatives.
Becauselarge systemsconsist of hundredsof components,
the selection of elemenatrycomponentsis not feasible.
Here, complexcases of earlier systemsare goodstarting
points. Imagine a companywhichsells laser technique
products and wants to open branches at two newsites.
Theyneedservices like email, ftp, fax, T-Online,database
services, etc. Severalof these services shall be realized on
. a host. Theconfigurationproblembecomesmoredifficult.
But again there are someprototypical telecooperation
systems which would fit these demands. Nowadays,
customer consultants of DeutscheTelekomAGconfigure
large telecooperation systems for companiesby using
available plans of other, similar telecooperationsystems
and adapting themto the customer’s demands.So a casebased configuration system could assist them with this
work.
Another important aspect is the extension of existing
telecooperation systems. So for example if you have
already a telephone at home and now you want a fax
machine.Rather than respecifying the wholeconfiguration
problem, you wouldexpect to add a fax machineto your
existing telecooperation system and perhaps to exchange
the telephoneconnectionin the wall. Indeedthis is case
adaption. Weselect a standardconfigurationandadapt it to
the newrequirements.
To configure telecooperationsystemfrom scratch you need
heuristics to guidethe configuratorduringthe search. But
the acquisition of goodheuristics is nearly impossible.On
the other handcases can be seen as heuristics and they are
easy to acquire.
In short cases avoid from-scratch solving whereit is
unnecessary. Using cases is natural in this domainand
cases are easy acquirable heuristics. Further they are a
goodstarting point for the specification and configuration
of large systems. Andlast the extension of an existing
telecooperationsystemis case adaption.
A starting
point for CBR:Manual case
retrieval
Given the observation that cases are useful for the
configuration of telecooperation systems, weextend our
given from-scratchsolver (Erodeet al. 1996)(a resourceoriented configurator) with the facility to reason with
cases. CBRrequires a formal representation of the cases,
and the automatic reuse of cases requires adaptation
94
knowledge.Givena from-scratch configurator, cases can
formally be defined as configurations as producedby the
configurator or, anticipating an interactive system, as
intermediate states of the configurator. Moreover,
adaptationneednot be doneheuristically, the configurator
itself shouldbe applied.
To realize this baseline, wefollowa pragmaticapproach.
First enablingmanualcase retrieval andreuse (rest of this
chapter) and second an amalgamation of CBRand
resource-orientedconfigurationfor automaticconfiguration
(see nextchapter).
Whatare the cases?
Thesize of cases is a crucial point in the designof a casebasedreasoner(Voss1996a),(Voss1996b).In general,
cases retrieved shouldbe easy to reuse. Largeand easy to
reuse cases would be fine. But they would lead to a
combinatoryexplosionof the case base. Thereforewehave
not only previouslyconfiguredtelecooperationsystemsas
cases, but in additionwehavesmallercases that coveronly
a part of a telecooperationsystem.Goodcandidatesfor the
parts are the topological components,like individual
branchoffices, individual workplaces, computersystems
and pbx. Thesecases could be further decomposed
into the
horizontal layers definedby our domainmodel.For manual
retrieval, weonly offer topologically dissected cases
becausethey are moreintuitive to the user.
Case acquisition and indexing
Cases need to be acquired. This involves two steps. A
representative set of meaningfulconfigurations must be
elicited and it must be formalized. For developingthe
configurator,weweregivena set of fairly different cases.
It waselicited by a softwarecompany
and will be extended
further. Thecases shall characterizethe kindsof problems
to be solvedand later be used for validation. This wasan
ideal starting point for our case base. Byconfiguringthese
cases with our tool weobtain their formalrepresentations.
Wehave examples for lawers, midwives, tax adviser
offices, travel agencies, insuranceagencies, engineering
offices, software companies, medical practices,
construction companies,etc. Additionalcases can easily
be acquired when the configurator is being used:
interesting examples configured from scratch can be
retained as newcases.
For fast access, cases must be indexedsuitably. A good
indexwill dependon context, on whowill use the cases for
whichpurpose. For automaticCBR,configurations can be
characterized in terms of their componentsand by the
resourcesthey offer andneed, and thus implicitly by their
horizontal and topologicalstructure. This informationcan
be extracted automatically from the cases. For manual
retrieval, other aspects becomerelevant: profession,
numberof employees, a graphical presentation of the
configuration,a short verbal characteristic of the system,
telecommunicationnetworksused, spatial distribution,
numberof offices, numberand kind of networkaccesses,
computernetworksused, private branchexchanges(pbx),
used computer
architecture (client-server .... ), security,
robustness, reliability, extensibility, etc. Mostof these
characteristics of a case cannotbe elicited automatically
fromthe configurations. Theymust be given by the user.
Providingthis informationis optional.
Using tables to select cases manually
Among
the multiplecharacteristics of a case not all will be
relevant for a particular query. Especially for manual
retrieval, users must be able to select and changetheir
criteria easily. Therefore, weneed a flexible retrieval
mechanism. For this purpose we apply the selection
supportof our configurator.
For the selection of componentsour configurator uses a
dynamic table mechanismto specify the customer’s
demands(Spenkeet al. 1996). The rowsare for features
and the columns for components~ Features can be
compositeso that rowscan be unfolded(to subfeatures)
folded (to composite ones). The columns and rows
displayed are automatically adapted. Components
disappearwhenthey do not satisfy the selected features,
and they reappear otherwise. Vice versa, selecting
componentsmaychangethe features displayed, dropping
all non-discriminatingones. For example,for components
there are featureslike color, price, or offeredfunctionality.
If the customerwants a red telephones/he restricts the
feature "color" to "red" and the feature "offered
functionality" to "telephone service". Then several
components(represented as columnsof a table) will
deleted. The result is a table with only red telephone
providers.
Wereuse this table mechanism
to select cases, complete
telecooperation systems, infrastructures, workingplaces
etc. There is a rowfor each case characteristic (we have
compositecharacteristics, too) and there is a columnfor
every case. Since only relevant cases and features are
displayed, the table mechanismprovides a comparative
survey at a glance. For examplein the left hand side of
figure 1 wesee thirteen different telecooperationsystemsat
a glance,whodiffer at 60 attributes.
To select all systems, whouses an email-service wejust
have to restrict the feature functionality (in german
"Funktionalit~tten")to "Email".Theresult is a table with
three telecooperationsystemsleft. This is displayedin the
right of Figure1.
Whena newproblem has been solved from-scratch, the
resulting configuration can be addedto the cases and be
displayed in the table. Theuser can easily supply any
missingcharacteristics byediting emptyfields.
A manually retrieved case can be reused manually be
selecting parts and copying and pasting them to the
configuration at hand. For automatic reuse we need the
knowledgewhycomponentswere selected and combined
in this particular way. This is exactly the knowledge
providedby their resource needsand offers. Thereforewe
applyour from-scratchconfiguratorfor adaptation.
Figure1. Reusing
Focusfor caseselectionbyrestrictingfeatures
95
knowledge sources would be the resource-orientated
configuratorandthe case-basedreasoner. Additionaleffort
to define the blackboarddata structure and the control
moduleswouldbe needed.
Instead of such a loose coupling we propose a new
approachwhichexploits on an inherent similarity between
the two methods.The result is a simple, amalgamated
and
newmethodfor configuration.
This methodand one idea to adapt cases are described in
the rest of this paper. Wewill not introduce resourceoriented configuration (ROC)and CBR.The reader
referred to the literature (Heinrich&Jtingst
1991),(KleineBrining&Stein1994), (Kolodner1993).
Integration of CBRin the configuration
process
The question is howwecan combineour configurator with
automaticretrieval andadaptationof the cases elicited for
manualselection.
Onepossibility is the use of a blackboardarchitecture
(Engelmore& Morgan1988) consisting of the two basic
components:the knowledgesources and the blackboard
data structure. Often additional control modulesare
defined to monitorthe changeson the blackboardand to
decide which action to take next. In our case the
ROC
Input:
a list of balancesheets, open
resource offers and requests
Procedure:
while there is an open request
do:
1. a) choose
a resource
requirement to be balanced next;
b) search all componentsthat
could balance the resource
requirement;
c) choose the best amongthem;
2. include the componentand
balanceall its resource offers
and requirements;
enddo
Outout:
the solution
CBR
Input:
current situation
Procedure:
1. CaseRetrieval:
a) describe (index) situation:
b) search for cases with
matching index;
c) select best case;
2.Case adaption
O~tput:
the solution
Table 1. ROCand CBRjuxtaposed
Componentsas cases?
To motivate our newmethod,we start with a comparison
of ROCand CBRas juxtaposed in table 1 and try to
interpret ROCas CBR.That means we must assume
components
are a very simplekind of cases. Thenchoosing
the next resource requirement can be viewed as a
description (index) of the current situation, whichis the
resourcerequirement.Thenext step "search all components
that could balance the resource requirement"corresponds
to the retrieval of all cases with a matchingindex. Among
them, wehave to choose the best case. This is our best
component.
So wesee that ROC
steps 1 a) and b) are a simple form
case retrieval. ROC
step 2 is indeedthe adaptionstep. By
including the selected componentand balancing its
resourcesweare fitting it into the current situation. This
endsin a newsituation. Theenclosingloop in ROC
is just
an iteration of CBR.
Interpreting ROCas CBRdoes not help much, since we
already have the configurator but not the case-based
96
reasoner. If, vice versa, wecould interpret CBRas ROC
wecould use our configurator for case-basedreasoning. To
do this wehaveto interpret cases as components.
Cases as components?
To interpret cases as components,weuse a simple kind of
abstraction whichis described now.As weshowedbefore
our cases contain complete configurations or their
topological substructures. Eachof themsatisfies some
external resource requirements, and all except for the
completeconfigurations, have someresource demandsto
be satisfied externally. That means,wecan describe the
cases by their external resource balances. This is a key
observation, because all ROCknowsabout its components
is their (external) resource balance. To ROC
it makes
difference whethera computer,say, is in reality a complex
configuration of hard- and software. Therefore wecan
interpret our cases as (composite) components. More
generally,any partial configurationcan be describedby its
external resource demandsand offers. Therefore, weare
not restricted to topologically defined cases. Figure 2
shows howa case is turned into a complexcomponent.
Rectanglescorrespondto components,circles to resource
offers or needs.
Figure2. A case as a omplexcompositecomponent
precisionof retrieval. In principle, wecouldtake anyof the
case characteristics introduced for manualretrieval,
providedit can be generatedautomatically. Interpreting
componentas a compositecomponent(i.e. a case) or
elementarycomponent,
enables us to retrieve both of them.
Andat least twoapproachesto adaptationare visible.
Amalgamatedcase-based resource-oriented
configuration
Wenow present CBROC,our amalgamated method for
case-basedresource-orientedconfiguration.
CBROC
Input:
currentsituation
Procedure:
while(thereis an openbalance
sheet)
{
1. a) describe
(index)currentsituation
b) searchall components
with
matchingindex
c) select the bestamong
them
2. adaptthis component
}
Output:
the solution
If wereplace each occurrenceof "component"by "case",
we obtain iterated CBR.If we specialize "component"
to
"elementarycomponent","describe current situation" to
"select an open resource requirement", "matching"to
"satisfying resource requirement", "adapt’.’ to "add
component and balance it", we obtain ROC.But we
deliberately used the terminologyfrom CBR.It gives us
the chanceto think about other interpretations, whichmay
be less restrictive. Hereare some.
There maybe better ways to characterize the current
situation than througha single openresourcerequirement.
Wecould take several or all open resource demands,we
could eventake the resource offers and thus increase the
97
Approachesto adaptation
The easiest wayof doing adaption is to treat cases as
(composite)components.So wejust have to balance their
open resource demandsand offers as it is done in the
ordinary ROC.But this approachmaynot be optimal. The
case mayoffer moreresources than are needed,andthen it
maywell contain unnecessary components.ROCwill not
recognize them because ROCbuilds monotonically
increasing configurations. A special optimization step
wouldbe needed. Better, wecould avoid the addition of
redundant components.
In order to detect these redundanciesROC
must configure
a solution from scratch. So we can not use a case as a
prefabricated part. But wecan use cases to reduce the
searchspace or moreprecisely wecan use cases to guide in
the ROC
selecting its candidates. Therefore,wedo not add
the components
of the case directly to the current situation
but into a library of preferredcomponents.
This library was
originally introduced in order to prefer components
selected by the user to those in the components
library.
Nowwe interpret the case as a recommendation.
Adaptationwill consist of reconfiguringthe recommended
components
accordingto the needsof the current situation.
It stops whenno moreresourcerequests can be fulfilled by
the recommended
componentsor whenall of them have
been integrated. Since a preferred componentwill be
includedonly if it satisfies an opendemand,there will be
no redundant componentsand a subsequent optimization
step can be avoided.
Whena resource need cannot be satisfied by a preferred
component,
there are two possibilities. Wecan first satisfy
another need or we can retrieve a non-preferred
component.
Thefirst alternative meansthat adaptationwill
be finished before non-adaptiveconfigurationis continued,
the secondalternative allows interleaving adaptation with
non-adaptiveconfiguration.In particular the adaptationof
severalcases can be interleaved.
Ourfirst approachfor case adaptationis just plain copying
andpasting. Thereis no real adaptation,just integration by
balancing. The second approach could be comparedto
adaptationby replay wherethe waya solution wasfoundis
replayed (Haig&Veloso1995). But indeed it is just
recommendationfor the configuration process. Even
thoughit is so simple,it has the potentialto fit casesnearly
perfectly into the actual situation and also to interleave
cases.
Heinrich M. and Jfingst E. 1991. A resource-based
paradigmfor the configuring of technical systems from
modularcomponents.In Proc. CAIA91, pp257-264.
Kleine-Bfining H. and Stein B. 1994. Knowledge-Based
SupportWithin Configurationand DesignTasks. In Proc.
ESDA’94,London,pp 435-441.
Kolodner J. 1993. Case-Based Reassoning, Morgan
Kaufmann
Publishers, ISBN-1-55860-237-2,1993
Rahmer J, and Sprenger,
M. 1996. Vom
strukturorientierten
zum ressourcenorientierten
Konfigurieren. In Proceedingsof 10th Workshop
"Planen
und Konfigurieren"1996
SpenkeM., Beilken C., and T.Berlage1996. FOCUS
- the
FeatureOrientedCatalogueUserinterface. Forthcoming.
Voss A. 1996a. Howto solve complex problems with
cases. To appearin EngineeringApplicationsof Artificial
Intelligence, SpecialIssue AI in Design,1996.
Voss A. 1996b: Towards a methodology for case
adaptation. In Proc. ECAI’96
W.Wahlster(ed), Chichester,
John Wileyand Sons, 1996.
Conclusions
In this paper we motivated the use of CBRfor
configuration problem solving. As a consequence our
from-scratch solver was extendedto reason with cases.
Enablingmanualcase retrieval waspossible by reusing our
existing user interface. Furthermoreweshowedthat CBR
andROC
can be seen as instances of a single, moregeneral
method.This wasthe key observation to amalgamatethem.
For this new amalgametedapproach several adaption
mechanism
are thinkable. Oneidea is to consider a case as
a set of recommendedcomponentsfor configuration.
Takenas such, cases of different size and quality can be
reused and their adaption be interleaved with each other
and with normalconfiguration.
References
Aamodt A. and Veloso M. (eds) 1995. Case-Based
Reasoning Research and Development. Proceedings of
ICCBR-95.
Lecture Notes in AI 1010, Springer Verlag.
BOhmA. and Ullner S. 1996. Application-Specific
Configuration of Telecommunication Systems..In
Proceedings of the Ninth International Conferenceon
Industrial & Engineering Applications of Artificial
Intelligence &Expert Systems.
ErodeW., BeilkenC., Btirding J., Orth W., Petersen U.,
RahmerJ., Spenke M., Vo13A., and Wrobel S. 1996.
Configurationof Telecommunication
Systems. Acceptedat
the AAAI1996 Fall Symposium
Workshop:Configuration.
EngelmoreR. and MorganT. 1988. Blackboard Systems.
Addison-WesleyPublishing Company.
Gfinter A. 1995: Wissensbasiertes Konfigurieren:
Ergebnisse aus dem Projekt PROKON.
ISBN3-92903796-3, Infix-Verlag,SanktAugustin.
Haig K.Z. and Veloso M. 1995: Route Planning by
Analogy. In (Aamodt&Veloso
1995)
98