From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
The Resource-Based
Configuring
Technical
Paradigm:
Systems
from Modular
M. Heinrich
Components.
E.W. Jtingst
Daimler-Benz
Research Institute
Abstract
In the resource-basedparadigmthe interfaces through
which technical systems, their componentsand their
environment
interact are modeledas abstractresources,and
eachtechnical entity is characterizedby the types and
amountsof resourcesit supplies, consumes
and uses. This
intuitive model,derivedin oneapplicationarea,is shownto
be in concordancewith the design rationale of modular
componentsystems. A simple self-organizing configuring
inference procedure for the resource-basedparadigm,
resource-balancing,
with a description of the environment
of the technical systemas the requirementspecification,
is derived from the basic acceptance criterion for
configurations.Fourlevels of knowledge
are definedfor this
paradigm
and introducedin a simplerepresentationscheme
which,throughits inherentlocality andmutualisolation of
componentknowledge,allows efficient acquisition and
maintenanceof even large component
knowledgebases.
1. Introduction
Configuringis the construction of a technical system
accordingto the requirements
of a specificationbyselecting,
parametrizing
andpositioninginstancesof suitable existing
componenttypes from a given catalogue [24]. Thus,
configuringitself does not involvethe development
of new
componenttypes [13]. The developmentof newcomponent
types, e.g. for additionto the component
catalogue,rather is
a typical task in the domain
of design.
Configuring
of technicalsystemsis an ubiquitousindustrial
engineeringtask and has beena domainfor expert system
application ever since the longtimeparagonR1/XCON
[1].
Mostconfigurationexpert systemsagreein using framesor
objects for the representation of factual knowledge
about
component
types [2, 3]. For the knowledge
about howto use
the factual knowledge
andhowto fred a goodconfiguration
quickly, two approachesare used. Expert systemsin the
tradition of XCON
[1] represent the actions of a human
configurationexpert throughproductionrules andmimicthe
humanin a by-rote performance.Theother approachis to
find and represent the principles that guide the human
configurationexpert. Theprevalentconstraint-basedmodel
19
AG
Berlin
[4-10] treats the functional specificationof the technical
systemandthe relations betweencomponents
as constraints
on the components
andtheir attributes. Suchconstraintscan
be used to check hypothetical configurations in a
generate-and-testmethodology
[5, 11] or as guidelinesfor
selection of components
[7, 9, 12]. If "key components"
whichrepresentthe different functionalconstituentsof the
technical system can be identified [4, 13], and the
component
cataloguecan be organizedinto taxonomies
with
root classes correspondingto the "key components",the
configurationtask can be viewedas a classification problem
and implemented
with the taxonomy
as a decision tree [12,
14], with improvement
possible by makingpartial choices
[15].
When"key components"
themselvescan be configured, e.g.
by recursively applying the process of functional
specification, constraint propagation and component
selection [10, 13], a hierarchical decompositionof the
technical system is achieved. A mixed hierarchy of
"has-parts"
- relationsand"has- specialization"
- relationsis
an elegant and efficient representation schemefor such
knowledge
[7, 9, 14].
A morespecific principle, that components
in a technical
systemonly connectat specific interfaces or "ports", has
been recognizedas an implicit understanding[16], as a
primesourceof constraints on components
[17, 18, 19, 20]
andas a distinct "architectural"type of constraint [13].
Whenfor each component the knowledge about the
componenttypes that it maybe connected to and those
components
that maybe containedin it is kept as an attribute
of the component
[17, 18], maintainabilityof the knowledge
base is muchenhanced over purely rule-based expert
systems, where these constraints are mixed up with
sequencingknowledge,thereby increasing the very large
numberof rules that haveto be maintained[21]. However,
the direct referencesbetweenthe component
types [13, 22,
23] makeit necessarythat every component
description in
the knowledgebase is re-examinedand possibly changed
whenevera new componenttype is introduced to the
catalogueor deletedfromit. "INsre-examination
is a very
demandingand time-consuming
activity and could well be
responsible for the huge amount of work spent on
maintenanceof large knowledgebases for configuration
expert systems[21].
2. The resource-based
Ourownstudies of modularcomponent
systemsand of the
configuringof technical systemsfrommodularcomponents
led us to a verygeneralprinciple usedby human
expertsthat
subsumes
the connectability principle: the principle that
systemsand components
interact mainlythroughinterfaces
whichcan be thoughtof as resources,andthat the resources
demandedand the resources supplied by componentshave
to be balanced. This principle, whichwasindependently
recommended
as a consistencycheck [11], weproposedas a
basic modelfor the configuringof technical systems[24,
25]. A very similar paradigmof the demandand supply of
resources waspresented as a "computationalmarketmodel
for distributed configurationdesign"[26]
Theconceptof resourceis an intuitive abstractionof the
interactions betweencomponents
and betweena technical
systemandits environment.
Thenotionof resourceincludes
all kindsof extensive(accumulative)
physical,technicaland
commercial
entities, both real andvirtual, that mightbe
supplied by one componentof a system and consumed
(exclusively)or used(temporarilyor in common)
by another
component
(see fig. 1). Examples
of resourcetypes fromthe
realmof computer
systemsare electrical currentat a certain
voltage,coolingpower,floor space(physicalentities), card
slot space, input ports, memorycapacity, software
procedureinterfaces, bus connectors(technical entities),
purchasecapital, constructionwork-time,
softwarelicenses,
supervisorattention (commercial
entities).
Thefact that a majorindustrial designtask (configuring)
involvesonly components
selected fromcatalogueshas also
beenrecognizedin MechanicalEngineeringand has led to
researchon "CatalogueDesign",but with little information
interchangebetweenthe MechanicalEngineeringand the AI
communities.
Abasic idea is that cataloguedesigninvolves
twophases, the selection of a system structure and the
selection of real components
for the genericelementsin the
choosen system structure. The main research thrust,
however,currently is towardstechniquesfor the designof
the systemstructure. Geneticalgorithmsseemto do very
wellfor this task[27].
The Constructive ProblemSolving (CPS)approach [28],
with a rigorous formal treatment under an abductive
reasoningscheme,followsa similar idea. Asemanticmodel
of the systemstructureis incrementally
built upfromgeneric
components,
the permissibleattribute rangesof the generic
componentsare increasingly constrained through the
external specifications, the emergingstructure and the
emergingmutualdependenciesof the components,and the
final configurationis wonby choosinga conforming
set of
componentsfrom the given componenttype catalogue. A
logic-basedcalculuswith aboutforty constructionrules was
proven soundand complete[29]. Besides the complexity
issue throughthe lack of heuristic metalevelguidancerules,
however,a basic problemwith logic-based incremental
approaches is that logically consistent intermediate
configurationstates could be isolated by arbitrarily many
inconsistentstates.
Were-present here the Resource-Based
Paradigmbecauseit
gives importantinsight into the human
conceptualisationof
the configuringtask, opensa novelline of reasoningfor the
heuristic guidanceof configuring, discloses a type of
constraints basic for configuring problemsfor whichno
sophisticated algorithmsare known,and yet provesto be
quite efficient in importantpracticalapplicationareas.
~
model
component
~
~’?~
[component
~
Figure1 basic relationshipsof components
andresourcesin
the resource-based
modelof technicalsystems
A resource-basedmodelcharacterizes a technical object
mainlyby the types andamountsof resources it supplies,
consumesand uses. With a resource-based model, the
technicalsystem,its components
andits environment
can be
describedin a single common
paradigm.Thedescriptionof
the environment, stating those resources and amounts
demanded
of the technical systemand those resources and
amountsprovidedfor the technical system,obviouslycan
play the role of technicalspecificationsfor the technical
system(see fig. 2).
Figure2 resource-based
model
of a technical4-" supplies
-’~ consumes
systemandits environment
" ~ uses
2O
Wedeveloped the resource-based model first for the
configuring of modular computer systems, where
practically all constraints are resource-based. But
resource-based modelsapply as well to other modular
technicalandorganizationalsystems.This can be explained
fromthe fact that a technicalsystemis alwaysbuilt for a
purpose:to providesomeservice, i.e. somereal or abstract
resource or resources for use or consumptionby its
environment.Suchresourcesdo not arise by themselvesor
out of nothing, but are supplied by componentsof the
technicalsystem.This, after all, is the sole reasonfor a
component
to becomepart of the technical system. These
components
mayin turn themselvesrequire other resources
for their functioningwhichhaveto be suppliedby further
components.At the end of that "chain of supply", some
resources have to be supplied by the environmentto the
technical systemfor use or consumption
by its components
(seefig. 3).
therefore, are usuallydesignedto supplya certain optimized
amount
of ofily oneresourceor of a suitablecombination
of a
fewresources. Common
basis for the designof the modules
is the system design of that modularcomponentsystem
whichidentifies and specifies the physical and technical
interfaces and the resourcesthat are exchangedvia these
interfaces. This systemdesign stays virtually unchanged
during the lifetime of the modularcomponent
system and
spans several generations of modules.Evenin the case
where the system design is altered, the practical
considerationsof upward-compatibility
will only allowthe
addition of somenewtypes of interfaces and resources,
whichdoesnot affect anyof the older modulestypes. Thus,
for a modularcomponent
system, the component
types will
fit quite naturallyinto the resource-based
model.
3. Resource-Balancing
3.1 The Principle
Theidea behindthe resource-balancing
principle is simple:
Aconfigurationis not acceptableunless the resourceswhich
the environment and the componentsdemandare each
balanced by the resources whichthe componentsand the
environment
can maximally
supply[11, 24]. This suggestsa
basic configuringalgorithmwith the resourcemodel,which
mosthumznexperts employconsciouslyor subconsciously:
Starting fromthe resourcesdemanded
by the environment
as
stated in the requirementsspecification for the technical
system,focuson a resourcetype not yet balanced,determine
the list of component
types whichcan supplythat resource,
select one componenttype from the list, incorporate a
component
of that type into the technicalsystem,andrepeat
that process until for every resourcethe required amount
is balanced by the amountof resources supplied by
components
or by the environment,with backtrackingon the
decisionsas the simpleststrategyto copewith dead-ends
and
with the situation wheninsufficient resourcesare supplied
by the environment
[24].
iiiiiiiiiiiiiiiiiiiiiiiiiiiii
iiiiiiiiiiiiiiiiiiiiii
iiiiiiiiiiiiiiiiiiiiiii
! iiiii!i
iiiiiiiiiiiii
iiiiiiiiiiiiii!
iiii
Figure3 resource-based
modelof a technical4-- supplies
~ consumes
systemandits environment
-
~
uses
Thecomponents
availablefor buildingthe technical system
are not arbitrarily
designed but determined by
considerationsof cost-effectivenessin the trade-off between
universality, whichleads to lowcost throughhigh-volume
production, and adaptation, whichreduces the cost of
designing-in, manufacturing and assembling the
componentsinto a product. Most cost-efficient for
applicationareas wherethere are only fewandstandardized
resource types but large variations in the amountof
resourcesfromcase to case are modularcomponent
systems.
A modularcomponentsystemis a collection of types of
moduleseach designedwith the objectives of workingwell
together and of being easily configured into technical
systemsfor a widespectrumof reqmrements.
Themodules,
21
3.2 The levels of knowledge
This configurationprocesscorrespondsto "reasoningfrom
first principles".It requiresonly
¯ systemknowledge,i.e. knowledge
about the resources
in the systemdesignspecificationfor the modular
componentsystem, and
¯ catalogueknowledge,
i.e. the technical specifications
of each component
typically containedin the manufacturers catalogue,
to find a formallyviableconfigurationif oneexists.
The heuristic knowledgethat only humanexperts can
provide from their experience with the configuration
processis on twofurther levels:
¯ evaluation knowledge,e.g. knowledgeabout a measure
of quality of the configurationandabouthowto predict
it on the componentlevel during the configuration
process,that will help achievea goodconfiguration.
¯ performanceknowledge,e.g. knowledgeabout some
advantageous
sequencingof decisionsthat will lead to
an acceptableconfigurationquickly.
~
r~erformance
knowledge~
evaluation knowledge
catalogue knowledge
system knowledge
INN
I
Figure 4 Levels of knowledgein a resource-based model
Themeasureof quality of a correct configurationis usually
its cheapnessgiven that it satisfies the qualitative and
quantitative requirements. That a configuration is not
acceptableunless its price is belowa givenlimit can be
expressed simply by makingthe cost of a componenta
(commercial)resource that has to be provided by the
environment.Whenmorethan one component
is applicable,
a local decisionaboutthe component
with the least overall
cost is necessary:the list of suitable component
typesmust
be sortedin orderof decreasingcheapness,withthe quotient
of (units-of-resourcesprovided)and(price of component)
the figure-of-merit,andthe first component
typeof the list
must be selected. To account for the cost of further
components
entailed by the selection of a component
when
computingthe figure-of-merit, the cost of the resources
consumed
or used by that component
mustbe estimatedand
addedto its purchaseprice.
In the performanceknowledge,the humanexperts neednot
concern themselveswith the basic organization of the
configuration process like they must in mostrule-based
approaches,but only with the fine-tuningof an inherently
self-organizingconfigurationprocesswhichis alreadyquite
efficient dueto the supply-consumption-characteristics
of
the components.For simple modularcomponentsystems,
no free-tuningis necessaryat all, anda static sequencing
priorities assignedheuristically to the resourceshas yet
provedadequatefor optimizingthe sequenceof decisions
for others.
22
Additionally, exception knowledgemust be represented.
Instead of expressiongincompatibilityof components
(our
first approach),it has provenmosteffective to describe
hopelesssituations in termsof resourcebalancesituations.
For morecomplicatedsituations, simplerules whichchange
the priority of resourcesatisfaction or component
placement
haveprovenadequate.
3.3. Resource Quality
Thesimpleresourcemodeldescribedaboveis not sufficient
to adequatelyrepresent reality becauseoften resources
whichsuperficially seemthe same will in someaspects
really be slightly or significantlydifferent, e.g. elecrical
current is only equivalent whendelivered at the same
voltage andpolarity or frequency,or, moreaccuratelyyet,
withina specific voltageinterval. This fact weexpressby
associatingquality attributes with the resourcetypes, e.g.
voltage intervals or voltage and tolerance, polarity or
frequencywith electrical current, rotational speed with
torque, access time with memory
capacity, baudrates with
RS232-connections. Resource-Balancing becomesmuch
moreintricate then, as the qualities haveto be compared
in
order to determinewhichprovidedresourcesare compatible
with whichrequired resources.
3.4. Knowledgerepresentation
Withthe resource-basedmodeleach of these four distinct
levels of knowledge (see fig. 4) can be acquired
incrementally and quite independently and can be
representedin well-structuredknowledge
bases. This leads
to a decisiveimprovement
in the maintainabilityespecially
of the knowledge
base whichwiUscale-upwell for the large
knowledge
basesencounteredin practical applications:
Thesystem knowledge,i.e. knowledgeabout the types of
resourcesthat arise fromthe systemdesignof the modular
component
system,can be organizedin a resource taxonomy
basedon resource similarity, whichcan be exploited for
resourcesubstitution decisions.Thequality attributes are
representedin value-slotsof the resourcetype classes.
Thecatalogueknowledgeis the largest and mostvolatile
knowledge
base. It contains the knowledge
about the types
of component
that are availablefor configurations.Theideal
representation paradigmfor the componenttypes are the
classes of an object-oriented language, where the
similarities between componenttypes can be used to
construct a taxonomywith the catalogue componentsas
leaves of the class tree. The types of resources that a
componentmaytypically supply, consumeor use are
introducedas value-slotsat suitablesuperclassesof the class
tree togetherwith default valuesfor the amountof resource.
Thusthe catalogue components
can easily be entered into
the knowledgebase by specializing an appropriate
superclassandfilling in the specific valuesof the resource
amountsfor that type of component.
Theheuristic knowledge
of humanexperts, i.e. exception
knowledge, evaluation knowledge and performance
knowledge,
has natural places of attachmentin the classes of
the component
taxonomyor of the resource taxonomy:
The evaluation knowledgeis easily expressible by the
purchase-pricevalue for the component,
andby specifying
the per-unit-valueas a resourceattribute, whichcan be used
in a standardprocedure
as defaultfor the cost entailedbythe
component
in the computationof the figure-of-merit.
Theperformanceknowledgeabout quick waysto reach an
acceptableconfigurationis representedby a static priority
attributedto resourcetypes or superclassesin a value-slot.
Theexception knowledge,captured as rules on resource
¯ typesandamounts,is representedin value-slotsof resource
types and their superclasses as part of the performance
knowledge.
This knowledgerepresentation scheme,by describingeach
component
type only in termsof the resourceseachinstance
of that component
type supplies, consumes
anduses, avoids
all direct references to other components
and effectively
isolates the knowledge
about components
from each other.
All the knowledge,
includinganyheuristic knowledge,
even
in formof rules, is organizedlocally withinthe compact
and
efficient structure of the componentand resource
taxonomies,and can be found and accessed quickly and
predictably by a humanexpert. Anewcomponent
type thus
can be addedto the component
cataloguewithout reference
or changeto older component
type descriptions, and any
component
type description can be removed- together with
all the knowledge
pertainingto it - withoutconsequence
for
the rest of the component
knowledgebase. Combined
with
the effect of representing not "by-rote" performancebut
"principle-based" knowledge,even very large knowledge
bases can be expectednot to showany of the maintenance.
problemsrule-based configuration expert systems are
plaguedwith.
Theuniversality of this knowledge
representation scheme
for all kinds of modular technical systems makesit
economicallyfeasible to provide powerfulinteractive
standardtools for the acquisition and maintenance
of the
knowledge bases. The taxonomic structure of the
component
and resource type catalogues is exploited best
with the familiar browsers displaying the class tree
graphically and allowing access to the knowledge
interactivelyvia the class nodeicons.
23
4. A Configuration Shell for Modular Systems
The resource-based modeland the resource-balancing
principle wasdevelopedfromstudies for our configuration
expert system shell COSMOS
(COnfiguration Shell for
MOdularSystems).
4.1 The COSMOSArchitecture
Figure 5 showsthe systemstructure of COSMOS
with the
resource catalogue and the componentcatalogue. Both
resource types and componenttypes are represented as
classes in an object-orientedlanguage.Mostresearcheffort
wasspent towardsknowledgeacquisition and maintenance
tools and towardsdebugging
andexplanationfacilities that
supportthe domainexpert in the development
and tuningof
the application-dependent knowledge base for the
configuration shell. The resource types and component
types andtheir superclassesare visualizedin browsers,the
interactive tools are based on those browsersaugmented
with dynzmicallyconstructedfill-in-the-blanks masksand
menusfor value selection.
[ list of parts, [
System structure of the expert system shell COSMOS
The inference engine of the expert system shell COSMOS
uses a blackboardarchitecture (see fig. 6) with a decision
record, resourcemodelandbalancesheets, and the agenda.
Thedecisionrecordcontains,for eachdecisionstep, the list
of all viablecomponent
typesin orderof decreasingutility,
wherethe f~rst and highest-ranking componenttype is
considered
selected.Thebalancesheetstally for eachtypeof
resource the amountrequired by the selected components
against the amountsuppliedby the selected components.
Theenvironment,carrying the requrrementsspecification,
is enteredas the selectedcomponent
in the first decision.In
each inference step, from the columnof the selected
components
in the decision record, the balance sheet is
updated, fromthe balancesheets the unbalancedresources
are determinedandtheir treatmentput on the agenda,the
actionwiththe highestpriority is chosen,either the selection
of a component
or the positioning of a component.
For componentselection, all componenttypes from the
component
cataloguethat can supplythat resourcetype or a
compatibleresourcetype are evaluatedin their prospective
environment
andlisted in orderof decreasingutility andthis
list is takenas nextentry to the decisionrecord.
system specification
ii!i!iii!iiiii
ii!!’
’ iiiiiiiiii
i’,’,iiii’,iiii’
!ii
!!’,i’,
Iiil
i:ii?i?:i:ii!:!:!:!!!!!iiiiii:?:i:i:i:i:iiii!:iii!!!~iii?iii~ii:i
i:::::::::::::::::::::::::::::
component
catalogue
I
[ componentY
The COSMOSexperience
Thoughaware of manypossible improvementsto the
inferenceprocedure,in our ftrst implementation
of the basic
configuration expert system shell COSMOS
wewantedto
explorehowwell the simplebasic algorithmabstracted from
humanexpert behavior would serve in practical
applications. Wespeedily included an improvement
that
enables components
to balancecertain resources locally,
whichis a necessitye.g. for spatially distributed systems
with local powersupplies.
COSMOS
has since been successfully used for a numberof
prototype expert systems, e.g. for the configuring of
Programmable
Logic Controllers, ConveyorBelt Systems,
and Switchgear System Controllers. A commercial
re-implementationhas been successfully applied to the
configuring of PLCsystemsincluding software and also
including the configuring of the communication
network
hardware (Conquest, AEG/Schneider/MODICON).
I u, is-~-,vo~]
i ...............
4.2.
[
Figure6 basic architectureof the COSMOS
inferenceengine
After the resource throughwhicha component
is contained
in another componenthas been summarilyprovided, the
separatestep of positioningthe component
gives an identity
to that resourceandassociatesit with the component.
Backtracking
occurswhenthe list is empty.It is performed
by returningto the previousdecisionin the decisionrecord,
deletingthe first component
typeof that list, whichis added
to a list of all rejectedcomponents
for that decisionstep, and
proceedingfrom there. Backtrackingalso occurs whena
hopelessresourcebalancesituation (accordingto exception
knowledge)
is detected. Animpossibleconfigurationtask is
determinedif backtrackingreaches the first line which
contains the environment
as the selected component.
Theexplanation engine is yet simple. For each step, a
reconstructionof the balancesheet to the state prior to the
selection of a component,
together with knowledge
of the
resourceconsideredandthe evaluationresults for the list of
viablecomponents,
allowsto explainthe "whyselect ... ?" questions. Thelist of rejected componenttypes, which
includesthe attribute relevantfor the rejection,takes careof
the muchmoreinteresting "whynot select ... ?" - questions.
24
The acquisition and maintenanceof knowledgefor the
component
catalogues provedto be as easy as expectedof
our resource-basedknowledgerepresentation. Throughthe
COSMOS
tool set, knowledgecan be entered by an expert
without intercession of a knowledgeengineer. The
knowledge(including communicationsand structured
components)was acquired from paper catalogues and
entered with less than four person weekseffort. Some
training andexperience,of course, is neededfor the design
of the basic representation structure and the ftrst
representation of exceptions. The bulk of maintenance
work,i.e. the introductionof newcomponents,
the phasing
out of discontinuedcomponents
andthe updatingof prices,
can nowbe performedby marketingpersonnel alone. The
transfer of price informationfromEXCEL
databasesto the
COSMOS
knowledgebase is automated. Mostnotable from
the point of viewof marke~g
wasthat the informationin the
componentcatalogue, while organized locally like a
paper-based
catalogue,is free of its side-effectsand, withthe
tools provided,mucheasier to maintain.Someideas about
printing future paper catalogues directly from the
knowledge
base are entertained.
5. HierarchicalConfiguring
TheResource-Based
Paradigmis not limited to configuring
of classical modulartechnical systemslike PLCwherethe
components
are concreteandthe structure of the productis
simple. A very importantindustrial application area are
industrial plants and installations whichare constructed
froma large variety of different modularcomponent
family
systems. Suchapplications are well within the scope of
automatic configuring by a suitable expansion of the
resource-based approach to both the real and abstract
components
of such plants.
In our approach,the top modelinglevel consists of the
process elements as viewed by the project planning
engineers.In manyapplicationareas, these abstract process
elements exhibit a modular behaviour and functional
capabilities whichcan be easily capturedand adequately
expressedin a resource model.Theoverall task is then
solvedby selecting and connectingenoughof suitable such
process elements. However,each of the abstract process
elementsitself will usually needto be configuredfrom
smallerabstract or real components.
Theresourcesprovided
by the abstract component
determinethe resourcesrequired
of its parts. In manycases, the internal parts of the process
elementscan be treated like additional components
of the
wholesystem,as long as the implicationsfor the scopeof the
resource-balancing
are takeninto account.Alternatively,the
abstract component
can be thoughtof as the environment
for
its internal component,
andconfiguredin isolation.
In both cases, the configuringprocessshouldbe structured
into hierarchical layers, and the configuring done
sucessively with knowledgebases for resources and
compoennts
appropriatefor just onelevel.
An application domainwell suited to this hierarchical
configurationapproachis the constructionof conveyor-belt
systems.Figure7 sketchesthe multiplelayers andillustrates
the component
relationships typically encountered:
TransportTask
Belt
Segment
Belt
Segment
Mech.Power
2 kW@ 50rprn&MK2
Belt
Segment
1 B$Contro[@
200sps
BertS eg rnentControlTas
k.3
Gear1/24
Motor3.0kW
Electr.
Power
BSC3
Subroutine
LightBarrier
CPU
Bin arYB~o~lnlnput
3,0 kW@400V60Hz&C’ld
3,2 kW@
400V60Hz&Ctd
MCCUnit 7kW400V
utputBoard
Bin aB~grd
::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::
-::55:::::::-:::
::5~:-----:~
............................... . ..........<..-~.-.....-.-.-.-..-_~-.-.-.-...-.~-......:’:-~-~::~--!:
::::::::::::::::::::::::::
..-.-.-.-................
....................
:Z~_-"
.............
X’~,~-~
...........................................................
i,,,~,,o,
[
E nv~ron rn~t.
,nfrastruclu
re
Figure7. Resource-Based
Multi-Level
Hierarchical
Configuring
of a Conveyor
BeltSystem
startingwiththeProcess
Task
25
I
Therequirementspecification is given on the Process
Levelin formof a "TransportTask"Processandits partial
transportresourcerequirements,e.g. transportdistanceat a
certainvelocity, or changesin transportdirection.
Onthe ProcessLevel, the required resourcesare then
satisfied by selecting suitable cataloguecomponents,
e.g.
Belt Segments,until the required transport distance is
reached.Thesecomponents
maybe thoughtof as abstract or
real. EachBelt Segmentthen posts its required resources,
e.g. mechanicalpowerof certain amountand quality and
controlof certain type, whichis satisfied on the Technology
Level by selecting suitable motorsand gears or control
programs
andentailed sensors/actors,respectively.
Aquality attribute is often usedas a meansto express
mechanicalor geometricconstraints at the interface over
whichthe resource is exchanged.Atypical examplein
mechanicaldesign is the exchangeof mechanicalpower
between
a motorandload. Thequality attributes thenare the
rotationalspeedof the motoraxle, the standardfor the shaft
couplingand the standard for the flange mountingof the
motor.In the exampleof Fig. 7, the mechanical
interface is
represented
in the qualityattribute "Stub"at onelevel andas
the quality attribute "ShaftForm"
at another.
The motor needs a certain amount of switchable
electrical powerat a certain voltage,whichis satisfied by
selecting a MotorControl Center (MCC)
unit of suitable
powerhandlingcapability, andsubsequentlysatisfying the
requirements of the MCCby selecting a MCCFrameto
house the unit. The voltage and the frequency of the
electrical powerare affixed as quality attributes to the
exchanged
resource "electrical power".
Thecontrol program,on the other hand, requires the
resourcesof suitable subroutinesoftwareandsensors, which
in turn require memory,
sensor inputs andCPUpowerfroma
control system, e.g. a Programmable
LogicController. At
that level, the quality and powerof the resource-based
configurationtechniquehas alreadybeenestablished.
Withsuch a complexsystem, even a resource-based
configuration algorithm will get into trouble whenthe
numberof componenttypes to choose from gets large
enough,
A muchmoreprofoundproblem,however,is that this
conveyorbelt systemis not located at onepoint, whereit
doesn’t matterwhois suppliedby whom,but is distributed
over space and has a specific and necessary internal
structure, whereit is importantthat the right amountof
resourceis suppliedat the right place.
26
In systemswitha spatialextentor internalstructure,the
balancingof resourcesis usually muchmoreintricate than
the basic idea conveys.In suchsystems,it is necessary,but
not sufficient that resourcesare balancedwithinthe whole
system. Instead, most resources mustbe balancedwithin
somescope.
For resources which are involved in establishing
"part-of-" or "contained-in-"relationships, whichwecall
"containing" resources due to the role they play in the
placementof components,
the scopeis simplythe container
(the component
whichprovidesthe containingresources).
For someother resources,it is obviousthat theyare scoped
similarlyto containingresources,e.g. mass.
In manydomains, like the conveyor-belt transport
systems, the service of a technical systemdoes not only
dependon the numberof components
that constitute it but
also on the structure in whichthe components
are connected,
e.g. the questionof whichother belt segments
are controlled
by the control systeminstance depicted in Figure 7, and
whichother control systeminstancescontrol the other belt
segmentsand transport systemsubsystems.
For cataloguedesignof suchtechnicalsystems,the total
configurationtask has to be partitionedinto configurationon
multiplelevels. Foreachlevel, the refinement
can be donein
oneof three ways:
¯ the system/ subsystem
is configuredout of smaller
components
froma catalogue,with a fixed structure, as
for the "controlsystemlevel" in Figure7.
¯ the resourcesthat the system/ subsystemhas to provide
are decomposed
andcbon~redinto separate requirements
manually
or automatically,as in the "transport task",
¯ the system/ subsystemis replacedby or hierarchically
refined into a decomposition
of generic components
and
links, wherethe components
determinehowthe higher
level resourcesare transformedinto the lowerlevel
resourcesand the links determinewhichcomponent
has
to provide whichresources to whichcomponents.This
techniquewill be prevalenton the processlevel andthe
technologicallevel.
6. Conclusions
Theresource-based
paradigm
reflects the designrationale of
modularcomponent
systemsand captures a basic principle
that human expert configurators are guided by.
Resource-balancing
is reasoningfrom"ftrst principles"and
"deepknowledge",
but with a simpleself-organizing basic
inferenceprocess.
In the resource-based
model,knowledge
aboutconfiguring
technicalsystemsis layeredinto fourdistinct levels with
well-definedresponsibilities andintuitive appeal.These
knowledgelevels allow a well-structured knowledge
representation with compactand mutually isolated
knowledge
for each component
type.
This isolation of knowledge
aboutcomponents
fromeach
otheris the key to efficient maintenance
of evenlarge
componentknowledgebases. As first experiences
corroborate,the resource-basedparadigm
overcomesthe
maintenance
bottleneck
for the caseof configuring
technical
systemsfrommodularcomponents.
Theuniversality of the resource-basedparadigmmakes
elaboratetools economically
feasible. Through
the available
tools andthe inherentpowerof the resource-based
model,
the humanexperts can readily shun the services of
knowledge
engineersin knowledge
acquisitionandneednot
becomeinvolvedwith routine knowledge
maintenance.
Forresearch,the resource-balancing
principleholdsmuch
potential for moreadvanced
inferencetechniques,andthe
resource-based
modelcouldbe an interestingstartingpoint
for model-based
design.
References:
[10] Steinberg, L.I: Designas Ref-mementPlus Constraint Propagation. The
VEXED
Experience. Proc. AAAI’87, 830-835.
[11] Neumann,B.,, Weiner, L: AnlagenkonzoptmadBilanzverarbeittmg. 3.
Workshop Planen und Konfigurieren (1989), Arbeitpapiere der GMD
388(1989), 209-224.
[12]Cunis, R. et al.: PLAKON,EIN I.)BERGREIFENDESKONZEPT
ZUR WISSENSREPR)i~EN’I’ATION
UND PROBLEMLOSUNGBEI
PLANUNGS- UND KON~-’IGURIERUNGSAUFGABEN.
Prec.
Expertensysteme ’87: Konzepteund Werkzeuge,Niirnberg, 1987, 406-419.
[13] Mittal, S., Frayman,E : Towardsa generic modelof configuration tasks.
Proe. IJCAI ’89, 1395-1401.
[14]Baginsky,
W. et al.:
BASIC ARCHITECTURAL
FEATURESOF
CONFIGURATION
EXPERTSYSTEMS
FOR AUTOMATION
ENGINEERING.
Prec. IEEE/SICE AI’88, 603-607.
[15]Mittal, S., Frayman, F.: Making Partial Choioes in Constraint
Reasoning Problems. Prec. AAAI’87, 631-636.
[16]Hakkarainen,
K. et ah A KNOWLEDGE-BASED
CONFIGURER
FOR EaMBEDDEDCOMPUTERSYSTEMS SOFTWARE: REAL-LIFE
EXPERIENCE.
Prec. n~.h-~JSICE AI’88, 608-613.
[17]Eschefle, A., Sachs, S.: Ein interaktives Werkzeugmar Konfiguration
modularer Rechnersysteme. WIMPEL
’88, 322-328.
[18]Eich, E. et al: CONSTRUCT
- ein wissensbasierter
An.sam zur
Konfigurierung. 2. AnwendefforumExpertensysteme 1988, Duisburg.
[19]Vitins,
M.: KEN- eine Expertensystemumgebuag f/ir dis
Konfiguration teclmischer Systeme. Bulletin S.E.V. 80(1989)3, 118-122.
[20] Birmingham, W. et al.: MICON:A Single-Board ComputerSynthesis
Tools. ~ CIRCUITS ANDDEVICESMAGAZIN,4(1988)1, 37-46.
[1] McDermott,J.: RI: A Rule-Based Configurer of ComputerSystems.
Artificial Intelligence 19 (1982) 39-88.
[21] Soloway,F_. et al.: Assessing the Maintainability of XCON-In-RhME:
Coping with the Problems of a VERYLarge Rule-Base. Proe. AAAI’87,
824-829.
[2] Haugeneder,H. et al.: Knowledge-Based
Configuration of Operating
Systems - Problems in Modeling the Domain Knowledge. Prec.
GI-KongreB"W’tsseasbasierte Systeme" 1985, 121-134.
[22]Lehmann, E. et al.: SICONFEXein Expertensystem ftir die
Konfiguration eines Betriehssystems. 15. GI-Jahrestagung, 1985, 792-805.
[3] Borgida, A. et al.: KNOWLEDGE
REPRESENTATION
AS THE
BASIS FOR REQUIREMENTS
SPECIFICATION. Computer 18(1985)4,
82-91.
[23]Dias, P.d.C., B/istschli, M.: Der lq.lrt¢atz der frame-basierten
ExpertensystemShell KENfttr die Konfiguration nachriehtentechnischer
Produkte. 2. AnwenderforumExpertensysteme 1989, Duisburg.
[4] Mittal, S.,, Araya, A.: A Knowledge-BasedFrameworkfor Design.
Prec. AAAI’86, 856-864.
[24] Heinrich,
M.: EIN GENERISCI-IES
MODPJJ~ ZUR
KONFIGURATION TECHNISCHER SYSTEME AUS MODULAREN
KOMPONENTEN.
3. Workshop Planen und Konfigurieren
(1989),
Arbeitpapiere der GMD
388(1989), 49-57.
[5] Lan, M.S. et al.:
A KNOWLEDGE-BASED
APPROACHTO
PRINTINGPRESS CONFIGURATION.
Prec. CAIA ’87, 38-43.
[25]Heinrich, M.; Jtingst, W.E.: A Resource-Based Paradigm for the
Configuring of Technical Systems from Modular Components. Proo.
Seventh ~ Conf. on AI Applications (CAIA’91), Miami Beach, 1991,
257-264
[6] Frayrnan, E,, Mittal, S.: COSSACK:
A Constraint-Based Expert
System for Configuration Tasks. In: Sriram, D. and tLA. Adey (eds.),
Knowledge-BasedExpert Systems in Engineering: "Planning and Design,
1987.
[7] Wu, H. et al.: ISCS - A TOOLKIT FOR CONSTRUCThNG
SYSTEM
CONFIGURATORS.
Prec. AAAI’86, 1015-1021
.[8] Pierick,
J.: A KNOWLEDGE
REPRESENTATION
TECHNIQUE
FOR SYSTEMS DEALING WITH HARDWARECONFIGURATION.
Prec. AAAI’86, 991-995.
[9] Streeker, H.: Configuration Using PLAKON
- An Applications
Perspective. Prec. 3. Int. GI-KongreB"W’tssensbasierte Systeme"1989,
352-362.
[26] Wellma,, M.P., "A Computational Market Model for Distributed
Configuration Design", .Proc. AAAl"94, pp 401-407.
[27] Carlson, S.E.; Pegg, T.A.: GeneticOperators for Catalog Design. Prec.
Advances in Design Automation 1995, Boston, MA.
[28] Klein, 1L: Model Representation and Taxonomic Reasoning .in
Configuration Problem Solving, Prec. 15th GWAI,1991, 182-194.
[29] Klein, tL; Buchheit, M.; Nutt, W.: Configuration as Model
Construction: The Constructive Problem Solving Approach. in: Gero and
Sudweeks(eds):Artificial Intelligence in Design ’94, 201-218.
27