From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
View to Product Configuration Knowledge
Modelling and Evolution
Tomi M/innis~,
Hannu Peltonen and Reijo Sulonen
Helsinki University of Technology
HAResearchCentre and Laboratoryof InformationProcessing Science
Otakaari 1, FIN--02150Espoo, FINLAND
{Tomi.Mannisto,
Hannu.Peltonen,Reijo.Sulonen}@hut.fi
Abstract
Knowledgemanagementhas been a major problem
in the implemented
configurationsystems. Onereason for the difficulties is the complexityof the
product descriptions in these systems. Theproduct
experts can no longer understandproductthe wayit
is described.Theproblemis addressedin the objectoriented spirit by looking for waysof makingthe
configuration product structure modelsmorecomprehensible. A data modelfor describing generic
productstructures is defined. It formsa basis for
modellingthe evolution of both product configuration knowledge
and deliveredproducts.
Introduction
Manyknowledgeintensive systems have had problems
with knowledgemaintenance. Product configuration
systems are no exception in this respect, e.g., XCON
(Barker & O’Connor1989, McDermott1993). There
no universal agreement on the knowledgeneeded in
productconfigurators,let alone on the representationof
this knowledge.Wetherefore find it impossibleto discuss configuration knowledgemanagement
without reference to whatkind of knowledgeis being managed.
The basic issue in configuration modelling is a
mechanism
for describingstructures of multiple product
variants within a single data model. Manydifferent
methodshavebeenused for modellingthis generality in
product descriptions (Scht~nsleben& Oldenkott 1992,
van Veen 1991, Cunis et al. 1989, Mittal & Frayman
1989and Heinrich & Jungst 1991). Weidentify two basic product structure modellingmethodsin these approaches, whichwe refer to as explicit and implicit
methods. Wethen define a data modelwhichuses both
these methodsin combination.
There is no single wayof looking at products of a
company.
Productscan be classified accordingto various
criteria. Aclassification criterion suitable for onepurpose mayturn out to be awkwardin another context. We
try specifically to avoid this kind of problemby constructing our modelexplicitly for productconfiguration
purposes.
After definition of the modelwediscuss the configuration knowledgemanagementproblemin the environmentwherethe modelwouldbe used. Finally weoutline
our vision for a researchagendafor the evolutionof configuration models.
This paper reports ongoingworkof the Product Data
Management
Groupat Helsinki University of Technology.
Short Definitions of Basic Terms
A physical product is manufacturedaccording to a specific productstructure. A specific productstructure is a
collection of component
descriptionsorganisedin a partof hierarchy. Eachcomponentdescription contains the
necessary information for makingor ordering a component. Aspecific productstructure is sometimescalled a
bill-of-materials (BOM)
or configuration.
In manycompaniesa product can be varied according
to customerrequirementsandtherefore actually refers to
a set of similar products.This set can be describedwith a
generic productstructure, whichcorrespondsto a number of different specific productstructures. In a generic
productstructure a genericcomponent
referencerefers to
a set of alternative components.
A configurationprocess starts with a generic product
structure and customerrequirements.Customerrequirements are mappedto a technical specification, which
describes the customerneeds in the languageunderstood
in the configurationprocess. Thegoal of the configuration process is to fred a suitable (valid, completeand
possibly optimal) specific product structure that is
amongthe alternatives described by the generic product
structure. Wedo not assumeany particular kind of configuration process, it maybe fully automatic or rely
partly or entirely on decisionsmadeby a human.
A product can be described from many different
points of view, each potentially defining a different
product structure. In this paper, the generic product
structure, or configuration modelas it is sometimes
called, describes only those aspects of the productthat
are relevant duringa configurationprocess.
iii
Modelling Generic Product Structures
Thereare several possible waysof modellinggenerality
in product structures. Wedivide themhere roughly in
explicit and implicit productstructure descriptionmethods. Thetermsexplicit andimplicit indicate howdirectly
the generic product smactureidentifies the components
used. Weuse terms explicit or implicit modelfor a data
modelthat is based on an explicit or implicit product
structure description method,respectively. A single genetic product structure can also employboth -kinds of
methods.
Weuse the term ’productstructure’ here, althoughall
implicit methodsdo not aim at describingthe organisafion of the components
in a part-of hierarchy. Theymay
connect the componentsin someother way than in a
part-of hierarchy or perhapsdescribe only the component
set andassumethe structure to be well knownor fixed.
In an explicit methodthe generic productstructure is
describedby stating the components,their organisation
in the part-of hierarchy and possible choices for them.
For example, a MountainBikeX
has part frame which is
either MBFrameX
or MBFrameY.
In an implicit method,the description consists of
knowledgeabout the compatibility of components,connectivity of components
or other constraints. For example, in description of a display unit, the component
’monitor’maystate that it needsa high resolution video
signal, anda particular graphicscard maystate that it
providesexactly that kind of signal. AT-connectormay
state that it takes onevideoinput signal andprovidestwo
outputs of the samesignal. Thereis no explicit description of the components
of a workingdisplay unit. If two
monitorsare neededfor a certain system, one graphics
card and a T-connectorwith two monitors will do the
job.
It is also possible to use both explicit and implicit
methodsin a single model.For example,on the explicit
side one maystate that a product P has componentsa
and b, wherea is either A1or A2and b is either B1or
B2. Implicit knowledge
in B2maythen say that it is incompatiblewith A1and they should, therefore, not be
usedin the sameproduct.
In explicit modelsit is typically straightforwardto
enumerateall possible specific productstructures. Finding the desired structure maystill take too muchtime if
all the possibilitiesneedto be investigated.
In a purelyexplicit modela selection betweenalternative componentscan be madewithout considering other
component
selections. In practice, however,the alternafives in somecomponentsdependon each other. Sometimes these dependenciescan be solved with a global
context, whichis establishedat the beginningof the configurationprocess.
For example, suppose a product has component
’motor’ with alternatives ’220V’and ’ 110V’,and component’powerswitch’ with analogousalternatives. The
global context for this product could include attribute
112
’operating voltage’. After the context has been established, the motorand the switch can be chosenwith explicit rules. Alternatively one could use implicit rules
such as:/f the producthas a llOV (220V)motor, it must
have a 110V (220V) switch, or alternatively a 110V
(220V) motor cannot be combinedwith a 220V(110V)
switch.
Explicit modelthus more directly tells what components must be chosen for a valid configuration whereas
implicit modeldefines conditionsthat mustbe satisfied
by valid configurations.
Webelievethat explicit productstructures are in many
cases easier to construct and understandthan implicit
ones. Nevertheless, manyproducts include validity conditions that require implicit methods.Thedata model
that is outlinedlater in the paperthereforehas an explicit
basis that is extendedwith implicit constraints.
In the following we give someexamplesof both explicit andimplicit productstructure descriptionmethods.
Sample Explicit
Methods
Set of BOMs.
This is a trivial case andnot actually a real
generic product structure model. The methodis, however, widely used in the industry for modelling even
large numbersof variants.
Generic, Variant and ParametricBOMs.These define
alternatives for certain components
of a BOM
and possibly global variables for determining the choice.
(Sch~nsleben& Oldenkott 1992, van Veen1991)
AND-OR
Graphs. At each level of an AND-OR
graph a
node breaks downto either its components(AND)or
one selection between choices (OR). The ANDand
levels alternate, so that an AND
level is followedby an
ORlevel and vice versa.
Combined
Classification and Component
Hierarchies.
This is a sophisticated version of an AND-OR
graph as a
combinationof component
and classification hierarchies.
There each non-leavenodecan be either divided into its
components
(just like AND)
or it can be specialisedto its
subclass (a kind of an OR).This approachis used in SAP
Configurator(SAP1994) and is a close relative of the
PLAKON
model (Cunis et al. 1989).
Composite
InstanceVariable.Compositeinstance variables are usedin object-orientedmodelsfor representing
components(Kim, Bertino, & Garza1989). Such a variable representsactually a set of components
ff its domain
is a class that has subclasses;anyof its subclassbeingan
eligible component.
Sample Implicit Methods
If-then Rules. In manyexpert systemsif-then rules can
be used for implicitly describing productstructure. For
example, IF component A OR B is in configuration
THENcomponentX must be included, too.
"7
/
t
c-classification]
,
N
1
.........
!
!
........
\
[Configuration-[
componentdescriptions /
t
compm< { S }
compn -< {Y, Z}
ResSum(ResX~
prtrauct .
data base ,
main
,. ¯
,
, J
, ,
,
/
I
I
!
¯
",
mS{Sl} nS {Y, Z2}
n_<{Y,Zl}
-"
"’
¯ "\
compI < {A}
’ : /\,"
I
I
ResX:int
I
I
"--’~
--
[
~
//////II
..
..
,’
I
/
~’/
mediator
I .
I related
I c°mp°nent
data
/,//
/ I
/ 1
I
~ l
I< {A2!.
" /
~’"
I "11
ResJ(:=-160~F~_7
I
~
Rosx:=-18o
Resx:=-no
ResX:= 200 ResX:= 150
Figure 1. Examplegeneric product structure in the model.
out the invalid cases. In the following we ftrst give an
example of a generic product structure using the model
and then explain the conceptsin detail.
Incompatibility and Compatibility Constraints. One
wayof stating the possible uses of componentsis to state
which components can or cannot be with other components in a configuration. These facts can be recorded as
n-ary tuples.
Interfaces,
Ports and Connectors. These provide
deeper modelling for compatibility of components. The
basic idea is that in a configuration certain components
need, can or cannot be connected. This is modelled, for
example, by ports and connectors that must fit together
in a valid configuration (Mittal &Frayman1989).
Resource-based Modelling. In resource based generic
product structure modelling the idea is that somecomponents consumesomething, such as, power, fuel, ventilation, etc., while certain components supply these resources. In a valid specific product structure all resources
need to be in balance. For example, the total produced
net power must be more than maximumconsumption.
(Heinrich & Jungst 1991)
Generic
Product
Structure
An Example of a Generic Product Structure in
the Model
Generic product structure description of P in Figure 1
declares that P has two componentsm and n. Component
mshould be an S, while n should be either Y or Z. This
is an explicit product structure description. Thesedefinitions are refined in subclasses P1 and P2. ComponentS
is a generic product structure of its own;it has one component I. Finally, Y and subclasses of A and Z have no
components.In the figure, solid line represents is-a relationship; componentrelationships are not represented
graphically.
As an exampleof implicit constraints we use here resources. In Figure 1 there is an exampleresource ResX.
It is a resource that is supplied by A1 and A2and consumed by Y, Z1 and Z2. Suppliers and consumers are
linked to the resource by dashedlines. These classes may
assign a value to ResX; a negative value meaningconsumption. A balance constraint for the resource is defined in product P; it states that the componentsof P
cannot consumeresource ResXmore than they supply.
The explicit product structure limits the possible component combinations, no other components but the declared ones are allowed. Therefore, one can enumerate
Model
This section gives an overview description of the properties of a data model. It is based on our earlier work
(Peltonen et ai. 1994). The modelincludes both implicit
and explicit product structure description methods. The
explicit description defines a superset of all valid specific
product structures and implicit methodsare used to prune
113
all the possible components
for the tuple (m, n, l) in P2
accordingto the explicit productstructure:
(S1, Y, A1),(S1, Y, A2),(S1, Y,
(SI, Z2, A1),(S1, Z2, A2), (S1, Z2,
(S2, Y, A2),
($2, Z2, A2).
Theimplicit resourceconstraint then prunesout the ones
whereResXconsumptionis greater than production. We
assumethat ResSumin P returns zero if ResXis not
found in a component.The only valid combinationsin
P2 for the component
3-tuple (m, n,/) are:
(S1, Y, A1),
($1, Z2, A1),(S1, Z2, A2),
(S2, Z2, A2).
After enumeration,each possible specific productstructure of a configuration modelcan be checkedagainst
applicableconstraints, includingtechnicalspecification.
This providesa trivial methodfor finding a solution for
particular customerrequirements.Theexistence of the
trivial methodonly showsthat a solu~on,if one exists,
can be found;the methodis hardlyuseful for a real con.figuration process.Moreefficient heuristics is neededin
a practicalapplication.
Main Concepts of Data Model
Classification Hierarchy. Our model is based on
classes. Theyare organisedinto a classification hierarchy. Theproperties of a class are inherited along the
classificationhierarchy.
A large set of componentscannot be managedwithout
organisingit somehow.
Classification is a useful tool in
productmodelling;it providesmeansfor organising, but
one mustdecide on the classification criteria. Components can be classified, for example,according to the
functionsthey performor the types of the manufacturing
processes producingthem.
Wetherefore require that a classification of component descriptionsis createdspecificallyfor configuration
modelling. Wecall this classification hierarchy cclassification.
Although,wehere discuss only one c-classification, a
company
mayrequire different c-classifications for different product families. This meansthat same components mayhavedifferent classification and evendifferent
properties in different product families. Thesecomponents should perhaps be somehow
related or shared betweenthe classifications. This is, however,an issue we
will not addressin this paper.
Thec-classification has oneparticular propertythat we
call componentsubtyping. Component
subtyping states
that subclassesof a class C mayalwaysbe used in place
of C in componentdescriptions of a generic product
structure. For example,if class MBFrame
has subclasses
MBFrameX
and MBFrameY,
a generic componentreference ’MountalnBikeXhas part MBFrame’
meansthat a
MountainBikeX may have either MBFrameXor
MBFrameY
as its frame.
114
Generic ComponentReferences. In basic objectoriented product modelscomponentsare represented by
instance variables, whichare used for referring to the
components.The domainof an instance variable is a
class. If the class has subclasses, the instancevariable
mayalso take as its valuean instanceof any of the subclasses (Banerjeeet al. 1987). This is a propertyknown
as subtyping.
Subtyping is a generic concept and, as such, has
nothing to do with components.For example,if A1and
A2are subtypesof A, this alone doesnot implythat they
are valid as componentrepresentations in place of A.
Thereforewehavea morespecific subtypingconceptfor
a classification whereclasses represent components.
That
is what wecall componentsubtyping. Component
subtypingis not a propertyof anyclassification by accident.
Aclassification hierarchy, the c-classification in this
case, mustbe specifically constructed, with the help of
productexperts, so that it is valid withrespect to component subtyping.
Component
subtypingdefines a one formof generality
for componentdescriptions--a componentis not necessarily fromthe domainclass, since also the subclasses
providevalid choices. Genericproductstructure descriptions, however,also needa moregeneral mechanism
for
defining component
alternatives. For example,assumea
class Athat has three subclassesA1, .4.2 andA3.For one
product A1and A2 are valid componentalternatives,
while for another A2and A3are the ones. There are no
classes that could directly be usedas component
domains
for these products, nor is there a simplewayof defining
them.
In our modela generic componentreference is described as an instance variable and its domainas a nonemptyset of classes. This meansthat the value of the
variable mustbe a referenceto oneof the listed classes
or their descendants.If an ancestorof a class is also in
the domain,the class itself is redundantandcan therefore
be removed.For these domainswe use a special notation: c ~ {A,B}.This is a short for a constraint{c ~Av c
B}, wherec ~ Ameansthat c is a component
instance
fromclass Aor its decsendant.
Oneparticular property wewant to have for generic
component
references is refinement. A subclass can refine a componentattribute by makingits domainmore
specific than in the superclass.Moreprecisely, there are
two operations: 1) domainset maybe replaced by its
propersubset and2) in place of a class onecan write its
subclasses. Both operations maybe applied multiple
times. This allows definition of an abstract component
reference whichmaybe refined in subclasses into more
concretedescriptions.
For example,component
c in class C mayhave set {A,
B} as its componentdomain.This meansthat c must be
either an A or a B. If A has subclasses A1, A2and A3,
the possible refinementsfor the domainof c in the subclasses of C include {A}and {A1, A2, B }. Refinement
of generic component
references is present in only some
generic product structure models, e.g., in PLAKON
In the balanceconstraint sumof resourcesin the com(Cuniset al. 1989).
ponentsof a particular specific productstructure is used.
The sumis calculated by a special function ResSum,
Other Component Data
whichgoes through all the components
starting fromthe
one
for
which
the
balance
constraint
is
defined. For each
Thec-classification is not be suitable for modellingall
component
it
checks
whether
the
resource
is visible in
the properties neededin configuration.Twoclasses that
the
component
and
a
value
is
assigned
to
it.
If so, it adds
share common
properties maybe placed far apart from
the assignedvalue to the sumand otherwisenothing.
each other and cannot therefore inherit the common
Evaluationof a balance constraint involves recursive
properties along the c-classification. This is a consetransversal of all componentsof a specific product
quenceof strictly enforcingcomponent
subtypingin the
structure. Evaluationas such is easy for a known
specific
constructionof the c-classification. Thereis also another,
perhaps even moreimportant, reason whyall component product structure. Computationalproblemsmay, howthat tries to fred an appropridata cannotbe definedin the c-classification. Component ever, arise for a mechanism
ate
structure
with
a
given
initial
constraints,i.e., a techdata is usedwidelyin a company,
andin this picture connical specification. Wedo not address here the problem
figuration is only one player. Onecannotassumethat all
of satisfying a balance constraint or fixing it wereit
component
data neededin a configuration process would
false. In fact we assume the same as for the whole
also be primarily modelledand maintained in the cmodel;
the modelonly describes a set of valid specific
classification.
product
structures, not howto find a particular one in a
For these reasons weinclude in the modeltwo other
configuration
process.
sources for component
data: mainproductdata base and
additionalconfigurationrelated data.
Amainproductdata base represents here all the comEvolution in Generic ProductStructuresn
igonentdata that is maintainedelsewherein a company.
It
A Research Agenda
neednot be a single data baseandits detailedstructure is
not of great importancehere. Themainissue is that cerThis section gives someguidelines for our future work
tain data items can be importedfrom the mainproduct
on configuration knowledgemanagement.
data baseto the c-classification. In Figure1 importingof
Ourspecial interest is to understandconceptsneeded
propertiesfromthe mainproductdata base is illustrated
to describe the evolution of products and related combydottedlines.
puter representations. In principle, wecan distinguish
For coupling the mainproduct data base and the cbetweentwo different kinds of changeprocess. Onone
classification a mediatoris introducedbetweenthe two.
hand,duringtheir life-time the physical productsas real
Thismediatorprovidespropertiesfor the classes in the cworldobjects are modifiedfor a numberof reasons: they
classification;a class mayrefer to a propertythat is visiare being serviced, their functionality maybe upgraded,
ble in the mediator. Suchreference is effectively the
faulty componentsare being replaced by correct ones,
sameas if the property wasdeclared in the class. As a
etc.
difference, however,the relation to the origin of the
Modificationsare in manycases madenot by the orpropertyin the mainproductdata base is maintained.
ganisation that madethe products but by the customer
Additionalconfigurationrelated data defines properitself or by somemoreor less independentservice or
ties that are tightly connectedwith the c-classification,
maintenancecompany.Dueto the increasing importance
but do not have a single place there. As an examplea
of after sales activities andlong life-cyclesof productsit
resource is an implicit product structure modelling
has becomeincreasingly more important to maintain
methodthat cannotalwaysbe easily expressedas a propconsistent representationof productsomewhere.
erty of a single class in the c-classification. Thisis beOnthe other hand, the generic productstructures have
causesuppliers andconsumers
of a resourceare not typilife of their own. The ownercompanyintroduces new
cally subclasses of the same parent class in the cproducts, enhances existing models, replaces compoclassification; for instance,components
that either supply
nents with newerones clue to the numberof different
or consume
electric current maybe quite different.
reasons. Onsomeindustries, such as electronics andinResourcesserve here only as an exampleof additional
formationtechnology,these renewalprocesses are quite
configurationrelated data that cannotbe nicely inherited
hectic.
in the c-classification, they shouldnot be takenas a key
Boththese changeprocessesare difficult as such. We
characteristic of the model.Resourcesmaybe modelled
have seen only few examples of systems capable of
on top of the explicit productstructure as additionaldata
maintainingaccurate representationsof deliveredone-ofitems that can be importedin the c-classification. This
a-kind products. Themaintenanceof the generic product
waya resource can be defined in single place and then
structures without exploding their complexity needs
related to arbitrary component
descriptions in the cpowerfultools and policies whichguarantee that they
classification. In Figure1 this is shownbydashedlines.
remainmanageable
duringtheir life-cycle. Unfortunately
these two processesare not, at least in theory, always
115
!
I
It1
prod I
I .st.~cture
21
I prod II
I structgre
nI
I[structure
P 2’ {I
/
{ProductII
m’rJ
I
~c~p~o~
phy~
Of~
~1
f
/ ~
~
l
~
rodu~s
lP
\v ~~
("<"2<._
) di:ciplined"--~~
/
/
/_maintenance
independentmaintenance
~
modernisation
upgrade
~ rad~oTf~ration
~ .......
Figure2. Evolutionof GenericProductStructureandPhysical Products.
independent.A product designed and manufacturedlong
time ago under the presumptionsof the generic product
structure effective at that time maybe broughtbackto
the factory years later for functional upgrade. Howto
relate the old productstructures, i.e., physicaland generic, to the currently used generic productstructure?
Wewouldlike to look for conceptual frameworkwhich
mightcopewith problemsof this nature at least in certain conditions.
Evolution of Physical Products
Byphysical products we meanthe products that have
beenmanufactured
and deliveredto the customers.In the
following wediscuss different kinds of modification
operationson physicalproducts.
Figure 2 showsgeneric product structure, i.e., a cclassification, at times T and T’. At the bottomof the
figure there is a roundedboxfor descriptionsof physical
products. Therea dot in a roughlyshapedcircle represents a physical product delivered to a customer.Each
"circle" encloses descriptions of physical productsrelated to onespecific productstructure. Modifications
that
changethe structure of a physicalproductare illustrated
by arrowswhichmovea description awayfromits original specific product structure, Somemodifieddescriptions are still close to a "circle". Thissuggestssimilarity,
116
e.g., functional equivalence,to the productsof the related specific productstructure.
Independent Maintenance. These include typical onfield operations. Onemodifiesthe product accordingto
the need without considering the relation to generic
productstructure or other information.It is very difficult
for a product management
systemto support this kind of
operations in any other waythan by recordingmodifications andcurrent state of physicalproducts.At anyrate,
the description of a physical product shouldbe updated
to reflect the modifiedphysicalproduct.
Disciplined Maintenance. A company may define
service kits that do not modifythe functionality of the
productsbut replace, for example,certain parts that may
suffer from ageing. If individual components are
changed, a companymay, for example,have the policy
that each new componentversion must be compatible
with older ones, i.e., any old component
version can be
replaced by a newerversion. Theresulting newspecific
product structure is close to the original with a known
difference.
Upgrade
or Modernisation.
These are true reconfiguration operations,wherethe functionality of the productis
changed. Anupgrade enhances the functionality of a
product, for example, by increasing certain maximum
capacity. A modernisationbrings an old physical product
to the level of functionality of a newerproductgeneration. One problem is that upgraded and modernised
products are different from the newconfigured ones,
evenif they havethe samefunctionality. Thatis because
the modifiedproducts consist of a mixture of old and
new components, while new products are madefrom
new componentsonly. An upgraded product becomes
typically close to anotherproductthat offers higher capacity and a modernisedproducthas the fimctionality of
a productof a later generation,typically the currentgeneration at the timeof the modernisation.
AdvancedReconfiguration. A configuration process
creates a specific productstructure for a customerspecification. Similarly, an advancedreconflgurationprocess
can producea newspecific product structure starting
froman old physical product. In general, advancedreconfigurationcan producean entirely different product
from any previouslydesignedone.
Evolution of Generic Product Structures
Wedistinguish betweenthree maturity levels for configuration managementenvironments on the road towards a dreamenvironment. A ftrst level environment
has the capability of describingconfigurationknowledge
in a waythat it can be maintained.Asecondlevel environmentstores, in addition, the full history of both generic product structures and descriptions of physical
products. Then,a third level environment,i.e., a dream
environment,also includes knowledgeabout the nature
of modifications. Onewould knowin detail howtwo
generic productstructures differ andbe able to operate
with productstructures of different times, e.g., upgrade
old physical products using newcomponents.
Currently most configuration systems struggle with
the problemsrelated to the first level. Knowledge
managementis still a real problemin configurationsystems.
Muchof the problemstems from the complexityof the
configuration models--they are "programmed"by computer specialists and not understoodby the product experts. Oneof the goals wehopeto achieveis a structured
and understandablemethodfor describing configuration
knowledge.
Modificationsto the generic product structure result
from various sources. These include market situation,
customer demands,different regulations in different
marketareas, advancesin technology,corrections of old
designs, just to mention few. A companymust have a
clear policy howthese changesare incorporated to the
configurationknowledge.Definition of goodpractices is
a panof the overall solution.
Management
of changes is essentially based on decisions, typically madeby humans.Thesedecisions need
to be recorded and they can be used for describing the
relevant history of the wholemodel.
It is not clear whichconceptsare neededfor storing
the evolutionof generic productstructures. Astraightforwardwayis to create a copyof the wholeconfiguration modelafter each modification.In this muchof the
informationon changesis lost. For a better modellingof
the evolution one should record the changesof smaller
pieces of information. Classes, for example,could be
changedby creating newversions of them. Theproblems
arise thenhowclass versionsrelate in classificationhierarchy and howto incorporateversions in generic product
structures.
In addition, the history of changesto the descriptions
of physical productsneedsto be retained. Thereal challenge is to incorporate the evolution of generic and
physicalproductstructures in a useful manner.
For example,imaginethe followingscenario. A customer has two products fromthe company:one three and
the other five years old. Last year a capacity upgrade
wasmadefor the newerone. Nowthe customerwantsto
knowwhether a similar upgradewouldbe possible for
the olderoneas well.
Giventhe full historical data, one can find out the
product configuration environment,e.g., configuration
modeland components,at the time the upgrade of the
newerproduct took place, and naturally the current
situation. In addition, there wouldalso be a full history
of service modifications.
Typically, the answerto the customerinquiry would
be positive, but usuallyan engineeris requiredto design
the neededmodifications almost fromscratch. Withan
ideal environmentthe engineermightfind the following
possibility: There is an modernisationpackagefor the
old productto the level X and fromthere a modernisation packageto the current level wherethe requested
capacity upgradeis directly possible with newestcomponents. These two modernisationscan be combined,but
one mustmanuallycheckthe versions of components
q, s
andI for compatibility.
Conclusions
Productconfigurationmodellingis essentially based on
description of generality in productstructures. Wedivided the used methodstwocategories: explicit and implicit and discussed briefly howprevious approaches
relate to these. Our ownapproachuses both methods:a
generic product structure description has an explicit
structure as basis andimplicit rules are usedfor pruning
out invalid structures. Webelieve that this wouldmake
the generic productdescriptions moreclearer andtherefore easier to constructandmaintain.
Themanagement
of evolution of configuration knowledgeis a critical longtermgoal for a configurationmodelling environment.Weapproachedthe problemby describing the keyelementsin the state of the practice and
then painteda vision for the future work.This is an area
117
with plenty of open questions; manyof themfundamentally difficult. Wetry to emphasisthe needsof the industry as criterion for selecting the courseof future research in the field of product data modellingand management.
Acknowledgements
This research has beenpartly funded by the Academy
of
Finland.
References
Banerjee, J.; Kim,W.; Kim, H.-J.; and Henry, F. K.
1987. Semantics and implementationof schemaevolution in object-oriented databases.In Proceedingsof the
International Conference on Managementof Data
(SIGMOD).
Barker, V. E., and O’Connor,D.E. 1989. Expert systems for configuration at Digital: XCON
and beyond.
Communications
of the ACM32(3):298-318.
Curtis, R.; Gtinter, A.; Syska,I.; Peters, H.; andBode,
H. 1989. PLAKON--an approach to domainindependentconstruction. In Proceedingsof the Second
International Conferenceon Industrial & Engineering
Applicationsof Artificial Intelligence &ExpertSystems
IEA/AIE-89.
Heinrich, M., and Jungst, E. W. 1991. A resourcebasedparadigmfor the configuringof technical systems
from modularcomponents.In Proceedingsof the seventh
~I~.Econferenceon Artificial IntelligenceApplications.
Kim,W.; Bertino, E.; and Garza, J. F. 1989.Composite objects revisited. In Proceedings
of the International
Conference on Managementof Data (SIGMOD).
McDermott,J. 1993. R1("XCON")
at age 12: Lessons
floman elementaryschoolachiever. Artificial Intelligence, 59(1-2):241-247.
Mittal, S., and Frayman,F. 1989. Towardsa generic
modelof configuration tasks. In Proceedingsof IJCAI
89.
Peltonen,H.; Mannistt~,T.; Alho,K.; and Sulonen,R.
1994. Productconfiguration--anapplication for prototype object approach. In MarioTokoroand RemoPareschi, editors, Object Oriented Programming,
8th European Conference,ECOOP’94.
Springer-Verlag.
SAP1994. Der SAPKonfigurator (Reference Manual).
Sch0nsleben,P., and Oldenkott, H. 1992. Enlarging
CADand interfaces between PPCand CADto respond
to productconfigurationrequirements.In Pels H. L, and
Wortmann,
J. C., eds., Integration in ProductionManagementSystems.:Elsevier SciencePublishersB.V.
van Veen,E. A., 1991. ModellingProduct Structures
by generic Bills-of-Material. Ph.D. diss., Technische
Universiteit Eindhoven.
118