art%3A10.1007%2Fs00163-003-0035-3

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

1/15

Topological structures for modeling engineering design processesDan Braha, Yoram Reich

Abstract In this paper, a mathematical framework fordescribing a variety of complex and practical design pro-cesses is developed. We demonstrate that our model hasthe desirable quality of representing several, seeminglydistinct, approaches as instances of the same framework.In addition, General Design Theory is shown to be aspecial case of the proposed framework. Using simpleexamples throughout the paper, we also hint at thepotential for the framework to serve as a basis for adescriptive study of design. Various design phenomena

such as design failure, identification of design knowledgebottlenecks, and benefits of collaborative design could beunderstood using the proposed model.

Keywords Design process, Design analysis and synthesis,Design methodologies, Formal Design Theory (FDT),General topology

1IntroductionMathematical formalisms of design have been of greatinterest to many researchers over the years. The ability to

formalize a complex problem such as design, and solve itusing algorithms whose results could be proven and per-formance guaranteed, have been a major attracting force.This interest has been equally received with skepticismsince these ideas have made limited-scope impact on realdesign. For example, General Design Theory (GDT)(Yoshikawa 1981; Tomiyama and Yoshikawa 1987; Reich1995) models design as an immediate result obtained onceall specifications are provided. The extended version ofGDT models design as an evolution of models (Tomiyamaand Yoshikawa 1987). However, the theory does not detailthe nature or process of this evolution.

Most researchers and practitioners recognize thatdesign processes cannot be fully formalized mathemati-cally. Nevertheless, casting design in mathematical termsserves several goals. First, by developing increasinglybetter mathematical models of design we improve ourunderstanding about the limit of formalizing design andthe limit of automating it. Second, studying mathematicalmodels of design could produce practical guidelines orideas for implementing design support procedures orsystems.

Consider the following design scenario. A designerobtains general specifications from a customer. She has inmind several general ideas about addressing the specifi-cations. She studies the specifications in relation to thegeneral ideas and refines them. She selects two of the ideasand details them. The analysis that follows uncovers con-straints not previously anticipated. These are added to thespecifications. The analysis results are contrasted withdesign codes and requirements. New laws for recyclingtake effect and need to be considered as part of theevolving specification list. Therefore, an extended designprocess commences and terminates when an acceptablesolution is found.

Our goal is to develop a mathematical framework thatis broad enough to describe a variety of complex andpractical design processes. For example, the frameworkhas to account for the following properties of designprocesses:

1. Design starts from some abstract specifications andterminates with a description of a product.

2. In design, the product specifications are graduallyrefined. Better understanding of the specifications is aby-product of design.

3. Design is an iterative, exploratory, and sometimeschaotic process.

4. Intermediate states of the design process might includeconflicting specifications and product description.5. Design progresses by context-dependent activities:

thinking, alternatives, and decisions emerge from thesituation as it unfolds by bringing diverse knowledge tobear on the present context.

6. Designers make use of diverse knowledge whether theywork alone or collaboratively.

7. Design is about finding solutions, not (globally) optimalsolutions. Designers generally do not receive theknowledge or resources needed to achieve optimality.

Our mathematical framework should also be detailedenough (1) to allow theoretical statements about design

Original paper Res Eng Design 14 (2003) 185199DOI 10.1007/s00163-003-0035-3

Received: 11 April 2001 / Revised: 7 January 2002Accepted: 13 November 2002 / Published online: 6 November 2003 Springer-Verlag London Limited 2003

D. Braha (&)Department of Industrial Engineering, Ben-Gurion University,PO Box 653, 84105 Beer-Sheva, IsraelE-mail: [email protected]

Y. ReichDepartment of Solid Mechanics, Materials and Systems,Tel Aviv University, 69978 Ramat Aviv, Israel

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

2/15

procedures to be made, and (2) to provide ideas forimproving practical processes and insight regarding theiroutcome. In line with the descriptive focus of the frame-work, we do not suggest that we can automate design pro-cesses,nor is it our goal. Moreover, some of the constructs inthe framework are computationally expensive to create ormanipulate; therefore, our framework suggests that it is lessthan likely for design automation to be realized.

We present our framework in two steps in order toimprove its clarity. Initially, we present a basic modelthat introduces several key concepts, even though it isunrealistic. Subsequently, we introduce an extendedmodel that addresses the aforementioned properties ofdesign processes. Due to space limitation, we illustrateonly several concerns and leave the rest to subsequentpapers.

The remainder of the paper is organized as follows:Section 2 provides an overview of the models; Section 3describes the framework in more detail; and Section 4illustrates the benefits of the framework. First, we showthat GDT is a special case of our framework. Second, weshow how a simple rule-based design system can be cast asan instance of the framework. Third, we briefly demon-strate how the learning system ECOBWEB (Reich andFenves 1992) can be interpreted in our framework. Section5 concludes the paper.

2Overview of the modelsThis section presents an overview of the various prox-imity models for engineering design processes. Theproposed models clarify and extend previous work (Brahaand Maimon 1998), motivated by empirical observationson how engineers design (e.g., Akin 1979; Blessing 1995;Ullman et al 1986; Hales 1987) and the nature of complexproduct design activities (Blessing 1995; Hales 1987; Reichet al 1999). In the following, a basic model for designsynthesis is described, and several key concepts such asproximityand process are introduced. Subsequently, anextended model for design synthesis is presented thatreflects scenarios that are more realistic.

2.1Basic modelThe basic model formulates design as a process that startsfrom abstract specifications such as customer needs orfunctional requirements in the function space. Thesespecifications are iteratively refined by moving to a better

proximal specification list. At some point, the designeris able to match partial structural information, in thestructure space, with the current refined specifications.Then, the process continues in the structure space byrefining the partial structural information until a designsolution is obtained. This process is depicted in Fig. 1.

Roughly speaking, this process is viewed as a localexploration procedure that finds a design solution (terminalstate) with respect to the proximal structure. That is, iffiisthe current (tentative at stage i) specification list, thenfi+1 is a proximal refined specification list if it does not differsubstantially fromfi. Given a tentative specification listfi,the local exploration looks for a proximal refinement offi.

When no further refinement is possible1, the refinementphase stops, the synthesis mapping begins, and a similarrefinement process is carried out in the structural domain.We call this process the basic model.

To support local exploration of a specific design problemwe need a method for finding the initial description at eachphase of refinement (i.e.,f0ord0), and a proximal structureof any feasible description. We also need to know how toselect among several proximal items at each refinement stepso as to arrive at better solutions.

In this paper, we propose a formalism that captures theabove considerations. This is done by introducing aproximal structure called closure space (or proximityspace, see Cech 1966). For each functional description f(orstructural descriptiond) in the function space F (or in thestructure spaceD), aclosure UF(f) (orUD(d)) is identified.Given two functional descriptions fand g, ifg2UF(f) wesay thatggeneratesf, orfis generated byg. We also definethe closure of any set of functions. In a logical framework,the closure operation may be associated with abduction(see Takeda et al. 1990 for discussion on abductive infer-ence in design). That is, for any two expressions a andb, ifb2U(a) thenb fia (see Sect. 4.2). Obviously, the closureoperation can be realized in many other ways (seeSect. 4) depending on the refinement strategies used tocreate the proximal structure. In view of the local explo-ration presented above, the model in Fig. 1 is elaborated inFig. 2.

Fig. 1.

Fig. 2.

1 For instance, when the designer reaches a specification fn thatcannot be refined due to limited knowledge, or when sufficientinformation is gathered that enables the synthesis mapping totake place.

Res Eng Design 14 (2003)

6

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

3/15

Each circle in Fig. 2 represents the closure of thecurrent description (functional or structural). In general,the closure of a description contains more than a singleelement. A unique design process is obtained by selectingat each refinement stage a single generating element out of

many possible ones.The creation of the closure and the selection of a

generating element are knowledge driven. Therefore, theavailability, richness, and coherence of knowledge stronglyinfluence the ability to obtain quality design solutions.Missing, partial, or otherwise poor quality knowledge willlead to familiarity with only part of the closure, potentiallyexploring only inferior parts of the closure, leaving out themore promising solutions.

We denote thesynthesis operation as a mapping ! fromafunctional description to a set of structural descriptions,where each selected structural description may be describedin terms of partial information only. The selected structural

descriptions correspond to theoutputof the particularsynthesis method the designer uses. Our formalism providesthe means for representing several possible design pro-cesses.For instance, theset of all designsolutions(structuraldescriptions) that can be obtained from the initial specifi-cation listf0 by applying two steps of functional refinements,synthesis, and two steps of structural refinements can beformally described as follows:

UD UD ! UF UF f0 1

Equation 1 encapsulates the set ofall trajectoriesthat areobtained starting fromf0and ending with a design solutionwith the same given number of steps. More generally,

different design solutions or trajectories might require adifferent number of design steps as shown in Fig. 3. A singletrajectory, which defines only one possible candidatedevelopment, is a list of visited functional and structuraldescriptions. A single trajectory can be described byselecting, at each stage, one description from the closure ofthe current description. In reality there are sometimes fewparallel candidate developments as shown in Fig. 3.

2.2Limitations of the basic modelThe basic process model has several limitations. First, it istoo linear. The designer carries out an extensive phase of

specification refinement, followed by a synthesis jumpand an extensive phase of solution refinement (see Fig. 1).This model is basic in the sense that some aspects ofreal design are not captured by the model, including (1)repeated interplay and multifold contextual mappings

between the function and structure spaces, (2) the asso-ciation-intensive search and feedback loops involved, and(3) the continuing learning that refines the requirementseven during synthesis. To overcome these and other sim-plifications, we propose an extended topological modelcalledcoupled design process.

2.3Real design modelThe extended model captures the interplay betweendesign descriptions (or process states), each of which isrepresented by a pair2 of functional and structuraldescriptions . This extension, which simultaneously

handles the function and structure spaces, could be furtherexpanded to explicitly incorporate and deal with morecomplex models that have functional, structural, behav-ioral (e.g., ), or other design aspects such as theenvironment, organization, and design processes em-ployed by designers (Blessing 1995). The nature of theinterplay is not built into the framework (similarly to notinsisting on a particular form of proximal structure asdiscussed above). Therefore, the framework could modeldifferent views of design such as design as exploration(Smithers 2000), or empirical findings about design suchas the diffused distinction between different design stagesas seen in real projects (Dasgupta 1994; Hales 1987).

Formally, design descriptions are elements of theCartesian product of the function and structure spacesFD, which is called the design space. A coupled designprocess is performed as follows. The designer starts withthe initial design description . Thef0are the initialspecifications andd0is the initial context description, e.g.,a product during redesign or improvement or an abstractidea. In general, during the transition from the current

Fig. 3.

2 This natural type of representation has been utilized, explicitlyor implicitly, as a means for describing the design process byother researchers (e.g., Pahl and Beitz 1984; Gero 1990; Takedaet al. 1990; Dasgupta 1994; Simon 1996; Suh 2001). Here, we use itas a basis for modeling the underlying topological spaces.

D. Braha, Y. Reich: Topological structures for modeling engineering design processes

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

4/15

design description to the new design description

, both structural and functional descriptionscan be refined. This transition can explain complex pro-cesses involving simultaneous refinement of the structuraland functional descriptions. It can also capture puresynthesis, which maps part of the functional description fito a structural description that augments the currentstructural description di. In this case, the new functionaldescription fi+1 incorporates specifications that havealready been satisfied as well as those that remain to besatisfied.

The refinement and synthesis operations arecontextdependent; that is, both fi anddi are needed in order tocarry out the operations. In addition, may be re-fined in case some design constraints are violated (seeexample in Sect. 4.2).

To capture the transition operation using our formal-ism, we simply introduce a proximity structure for thespaceFD. That is, for each design description , aclosure operation UFD() is identified. Every designdescription in UFD() generates the design descrip-tion . The coupled design process is illustrated inFig. 4. Each circle in Fig. 4 represents the design descrip-tions obtained by applying the closure operation. In gen-eral, the closure of the current description includes morethan a single element. In real design, it could contain aninfinite number of elements. Thus, a uniquedesign process

is obtained by selecting at each stage a single element outof the many possible ones without necessarily creating thecomplete closure. A design process ends with a designdescription of the form , where fn are the detailedspecifications manifesting a deeper understanding of theproblem, anddnis a design description that satisfies thesespecifications and can be realized. Given , dn maysatisfy fn though it may not be realized, in which case is not a final state. This intermediate favorablesituation can happen particularly during conceptual ordetailed design stages. In these situations, designers con-tinue to refine the specifications knowing they are stillincomplete. We might be able to say that in such a

situation conceptual design terminates and another stagebegins in a new space.

2.4Relating the basic model to the real design modelIf the closure operation UFD can be decoupled into twoindependent closure operations UF and UD, such thatUFD()=UF(f)UD(d), then can be refined to anew design description by first refiningfiusingUF and then refining di using UD. (When d0=/, we needthe synthesis operation to obtain d1.) The effect of theclosure operationUF(similarlyUD) can also be viewed asapplyingUF to the projection of the pair onto itsf-coordinate (similarlyd-coordinate).

The basic design process presented in Fig. 2 is a specialcase of the real design model presented above. Indeed, thebasic design process can be described as a sequence ofdesign descriptions , ... followed by a syn-thesis mapping that leads to , and a sequence ofdesign descriptions , , ... . Forexample, is generated from , where fn+1isselected from the closure UF(fi). This description is illus-trated in Fig. 5, where it is shown that a basic designprocess (solid line) follows a specific pattern, i.e., a se-quence of operations in the function space, and is followedby synthesis and a sequence of operations in the structurespace. In general, however, we cannot perform such de-coupling because design decisions are context dependent,i.e., both the current specifications and the product

description affect refinement decisions. For expositionalpurposes (and without loss of generality), we introduce themodel assuming the basic process presented in Fig. 3.

3Topological structures for designIn this section, we present a model that attempts tocast design more formally in the framework of generaltopology, in particular closure spaces (Cech 1966). In thispaper, we have considered general topology as a mathe-matical base for our discussion. By placing richer struc-tures on a topological space, additional spaces may beobtained (e.g., especially metric spaces). Here we follow a

Fig. 4.

Fig. 5.


8

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

5/15

least committed research approach, where some of theseextended spaces will warrant continued attention overtime, and will be introduced as they arise naturally inapplications. For brevity and clarity, some of the formaldefinitions and theorems are excluded (they are presentedin Braha and Maimon 1998), and concepts are presentedintuitively.

3.1Structure and function spacesThe structure and function spaces are defined as follows:3

Definition 1A structural description dis defined by its observable orotherwise measurable attributes. The attributes may be ofseveral types, e.g., physical or geometrical. A structuraldescription has respective values for its attributes. Fordesigners, the structure space is the set ofallstructuraldescriptions they can generate with their present knowl-edge; this is denoted byD.

Definition 2A functional property is the behavior that an artifact dis-plays when it is subjected to a situation. The collection ofall functional properties observed in different situations isthe functional description of the artifact. The functionspace is the set ofallfunctional descriptions, and is de-noted byF. A functional descriptionf2Fis also referred toas adesign specification list since it designates the sought-for functionality of the artifact.

In a similar way, we could introduce into the formu-lation additional aspects beyond D and F, such as behav-ior, as desired by a particular design approach. The nextdefinition formalizes the intuitive notion of proximity inthe structure and function spaces. The definitions areprovided for the related function space. Similar definitionscan be provided for a structure space or coupled space(discussed in Sect. 2.3).

3.2Closure spaces

Definition 3 (Closure operation and function space)IfUF is a function that maps a set of functional descrip-tions to a new set of functional descriptions (i.e., UFis a setfunction that maps elements of 2F, denoting the power setofF, into 2F), then we say thatUFis aclosure operation(orclosure) for F, provided that the following conditions are

satisfied:

1. UF()=(),2. FUF(F) for each F F, and3. UF(F[G)=UF(F) [UF(G), for each F F and G F.

The structure is called a closure function space.A closure operationUDfor the structure space Dis definedin a similar manner. The structure is called a

closure structure space; in real design, the closure would

originate from the designers knowledge or other sources.

DiscussionIfF={f}, then every functional description g in the closureof f(i.e., such that g2UF(f)) is termed as a generator of f(see Figure 6). Alternatively, we say that ggenerates f, orthat fis generated byg. In general, for any subset FF,any functional description f in the closure ofF(i.e., suchthat f2UF(F)) is termed as a generator ofF.

4 Intuitively,fis a generator ofF if fgenerates some functionaldescription in Fas illustrated in Fig. 7.

Generally speaking, the relation generated by isassociated with the relation refined by. That is, as related

to the process presented in Fig. 2, the progression from aspecification listfito a refined specification listfi+1impliesthat the specification list fi is generated by the refinedspecification list fi+1, or that fi+1 generates fi. In formalterms, the refined specification list fi+1 is included in theclosure of fi.

As discussed in Sect. 2.1, in reality there are sometimesseveral parallel candidate developments starting from theinitial specification list f0 (see Fig. 3). Applying Definition3, this situation may be described as follows. The designer

Fig. 6.

Fig. 7.

3 Some definitions may resemble GDT terminology (Yoshikawa1981); nevertheless, as already discussed, GDT is only a specialcase of our framework.

4 Note that we use the term fis a generator ofF althoughfmayonly generate part ofF.


8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

6/15

starts by creating the closure of f0, UF(f0)=F. Creating theentire closure may be an expensive operation. Therefore,the designer may create part of the closure, and make adecision based on the partial knowledge regarding thecomplete closure. Each specification list in Fgenerates f0.While creating the closure, the designer may select andproceed with any refined specification list in the part ofFthus far created. The next refinement step involves finding

the closure of the selected refined specification list. Thisstep is repeated until no further refinements are possible(more detail regarding this later). Thus, Fdenotes the setofallpossible refined specification lists off0. Similarly, theclosure ofF, UF F

S

f2F

UF f , denotes the set ofall

possible refined specification lists in the second and sub-sequent stages. A trajectory of a refinement process iscreated by selecting a single specification list from eachclosure in each refinement stage (see Fig. 3). In real design,one or several trajectories are explored, and the completeFor UF(F) are not exhaustively created due to limited re-sources such as time, money, or knowledge.

Having examined the meaning of the closure concept,

let us explore its structure. First, it is clear that Fis in-cluded in its closure. The closure ofFmay be composed ofthe following three categories:

1. Specification lists that are included inFsuch that eachone does not generate any other specification lists in F(except for themselves).

2. Specification lists that are included inFsuch that eachone generates specification lists in F (other thanthemselves).

3. Specification lists that are not included in F, and suchthat each one generates specification lists in F.

Each specification list that falls within the second andthird categories above is called a clusterpoint, and the setof all cluster points is called the derivative ofFas illus-trated in Fig. 7. The specification lists that are included inthe derivative ofF, and that are not included inF(class 3),represent the new explicit information that is gained byapplying diverse knowledge during the refinement process.Thus, the closure of a setFis the union ofFwith its set ofcluster points. The formal definition of a cluster point andderivative of a set is presented in Appendix 1.

Often, solving a design problem is a collaborative effortcarried out by several designers, each possessing differentknowledge. The notion of a closure may be useful ininterpreting some aspects of collaborative design. The

following example illustrates a simple collaborative sce-nario. Assume that there are two designers, Alice and Bob,working collaboratively on a certain problem. Bob andAlice each carry out (independently) few parallel candidatedevelopments based on his/her private knowledge. Atsome point in the refinement process, Bob and Alice sharetheir intermediate results FBobn andF

Alicem , respectively. Each

set represents a set of possible refined specification lists(starting from f0). IfF

Bobn andF

Alicem intersect, they can

continue together to refine the intersection; otherwise,they will have to collaborate together to find refinementswithin a closure created by their mutual knowledge. Insome cases, the collaboration means creating shared

terminology, effectively realizing that their closure struc-tures overlap. In other cases, there are true gaps in theirknowledge that mandate collaborative learning. Theintersection of sets or the closure created by mutualknowledge is more focused than each of the sets or clo-sures separately. The usefulness of collaborative designmay be seen through the above topological illustration.

Definition 4 (Closed sets)A subset Fof a closure function space is calledclosedifUF(F)=F. Closed sets in a closure structure spaceare defined in a similar manner.

DiscussionIntuitively, a set Fis closed if every element in Fis gen-erated only by elements in Fas shown in Fig. 8. As ex-plained above, the set of all possible refined specificationlists (starting from f0) in a particular stage of refinementcan be defined recursively as follows:5

1. F0={f0}

2. F1=UF(F0)3. Fi+1=UF(Fi)

If, at some stage, the derived set of refined specificationlists Fn is a closedset

6, then we are assured that everyspecification list in Fn is generated only by specificationlists in Fn. Thus, no further refinement stage that yieldsnew refined specification lists (or new information) ispossible. Formally, it means that UF(Fn)=Fn. In a real sit-uation, this means that there is not enough information tofurther continue design exploration in the function space.Therefore, the refinement process stops andsynthesismustbegin (see Fig. 1). Prior to performing the synthesisoperation, the designer searches withinFn for a suitablerefined specification list that can be mapped to structuraldescriptions in the structure space. The refinement processin the structure space then begins (see Fig. 1). It isimportant to note that not every refinement process willend with a closed set in a finite number of steps. However,if at some point a closed set is found, then the refinementprocess stops.

Fig. 8.

5 It could be prohibitively expensive to generate this set in realdesign.6 It may be impossible to verify this property in real design;however, engineering intuition, experience, or lack of knowledgemight imply it.


0

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

7/15

As stated above, the set of all possible refined specifi-cation lists (starting from f0), at any particular stage ofrefinement, can be defined recursively as Fi+1=UF(Fi). Itcan be shown that, after a long time (even an infinitenumber of steps), repeated application of the closureoperationUFwill result in a closed set. That is, lim

i!1Fi is a

closed set. Therefore, every refinement process mustter-

minate at some point (though not necessarily at a usableor good specification).

3.3Interior, neighborhood, and the analysis processFor any set F, the interiorofF is defined as the set ofdescriptions inF that generate descriptions only in F. Forexample, the set {f1,f2,f3} in Fig. 9 is the interior ofF. Thedescription f4 is not included in the interior ofFsince itgenerates some description that is not inF. If we verifythat the functional description fis included in the interiorof a set G, thenG is aneighborhoodN(f) of the functionaldescription f. In general, if a set Fis included in theinterior of a set G, thenG is a neighborhood ofF. Theformal definitions are provided in Appendix 1.

DiscussionThe definitions of interior and neighborhood are useful forinterpreting certain analysis activities as follows. Thedesigner starts with a candidate design solution d0thatneeds to be analyzed. Sometimes,d0cannot be analyzeddirectly (e.g., by performing finite-element analysis), sinceits structural description is not provided in a form suitablefor analysis. To overcome this problem, the designercreates a series of successive design descriptions, such thateach design description in this implication7 chain isimplied by the design description that precedes it. After asuitable structural descriptiondmis obtained, the designer

is able to analyze the object. This analysis operation, G, isexpected to result in the behavior of the productf0. Asimilar implication process is followed for the functionspace until a comprehendible behavior for the product isobtained. For example, in finite element analysis, the initialdesign description is broken down into an analysis modeldm. This includes a series of abstraction steps as well asdetailing steps for preprocessing the product information,

which is required by the underlying analysis procedure.The design description dm is analyzed in order to extractthe detailed design behavior f0, which undergoes postpro-cessing to result in a compressed, user-friendly result fn.

How can the above analysis process be described usingour topological concepts? This is done by equating therelation di+1 is implied bydi with di+1is generated bydi or di generatesdi+1.8 Therefore, if N(d) is a neigh-

borhood of structural description d, then by the neigh-borhood definition every structural description that isimplied byd(or is generated byd) must be in N(d). Byassociating a neighborhood with each structural descrip-tion d (similarly functional description f), the analysisprocess can be described as shown in Fig. 10. Each circlein Fig. 10 represents a neighborhood of the currentdescription (functional or structural). In general, theneighborhood of a description can contain more than oneelement. In this case, the designer explores the neighbor-hood for descriptions that the current description gener-ates. Since every description that is generated byfisguaranteed to be in its neighborhood, the designer can

focus her exploration efforts on the neighborhood of thecurrent description (whose cardinality is much smallerthan all possible descriptions). A unique analysis processis obtained by selecting, at each stage, a single descriptionout of the many possible neighborhood descriptions.

3.4The relationship between neighborhoods and closuresTwo main topological concepts have been introduced thusfar. The closure operation serves as the underlying conceptfor design synthesis, while the neighborhood concept isused for modeling design analysis. We anticipate that theyhave a relationship given the similarity between Figs. 10and 2. However, design analysis is supported by employingneighborhood processes (Fig. 10), whereas designsynthesis is driven by closure procedures (Fig. 2). Thefollowing simple but important theorem shows thatclosures are completely determined by neighborhoods(see also Fig. 11).

Theorem 1A functional propertyf2F belongs to the closure of asubset Fof a space if and only if each neighbor-hood offin intersects F.

Fig. 9.

Fig. 10.

7 Note that our use of the term implication is not necessarilyidentical to logical implication. In a logical framework, theimplication relation is associated with deduction. Consequently,bymodus ponens, every description in the implication chain isimplied by the initial candidate solution d0.

8 Recall that di+1is generated bydi or digeneratesdi+1 ifdi2UF(di+1).


8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

8/15

DiscussionAs shown above, a closure space can be constructed bydirectly providing the closure operation (see Definition 3).This requires that for each description, the designer hasknowledge regarding the set of descriptions that generateit. Theorem 1 suggests an alternative way of constructing aclosure space by using neighborhoods. In reality, creatingthe entire neighborhood system for each description maybe an expensive operation, in which case the followingapproximate procedure may be employed:

Algorithm Approximate Closure

Input: functionalpropertyf; collection of neighborhoods

Output: Theapproximateclosure off

begin

for severalg2 Fdo

begin

ifmost neighborhoods ofgcontainf then

addgto the closure offend

return approximateclosure off

end

An approximate closure accounts for real, imperfect,partial, or incorrect knowledge; thus, it may help to ex-plain design failures. In contrast, limited resources canexplain suboptimal designs. Studying the nature ofapproximate closures is a subject for future work.

It is also possible to construct the neighborhood of anydesign description by utilizing the closure operation. In-deed, neighborhoods have been defined using the interiorconcept (see Appendix 1). The interior of a set, in turn, hasbeen defined using the closure operation (see Appendix 1).This quality, together with Theorem 1, renders theneighborhood and closure concepts dual.

3.5Open sets

Definition 5 (Open sets)A subset Fof a closure function space is calledopen if its complement (relative to F) is closed, i.e., ifUF(F)F)=F)F. Open sets in a closure structure space are defined in a similar manner.

DiscussionA set is called open if every description in the setgenerates only descriptions that exist within the set. Itwas shown that closed sets play an important role insynthesis processes. Specifically, if at some point aclosed set is found, no further stage of refinement thatyields new refined specification lists (or new informa-tion) is possible, and the refinement process stops. This

situation can trigger knowledge acquisition in an at-tempt to continue the refinement or synthesis processes.The open set concept has a similar role in the context ofanalysis processes. That is, if at some stage of impli-cation, the set of all structural descriptions Dn that canbe generated from d0 is an open set, then we are assuredthat every description in this set generates descriptionsthat already exist within the set. In this case, theimplication process stops and the analysis operationmay be applied as shown in Fig. 10. This is the ultimateanalysis that uncovers the underlying behavior of theproduct. Prior to performing the analysis operation, thedesigner explores within Dn for a suitable structural

description that can be mapped into functionaldescriptions in the function space. This is followed by aderivation process in the function space. It is importantto note that not every derivation process will end withan open set. However, such an occurrence will guaranteethe termination of the derivation process.

4Putting the framework to useIn order to illustrate the usefulness of the frameworkand explain the various concepts, three examples arepresented. The first example shows that General DesignTheory (GDT, see Yoshikawa 1981; Tomiyama andYoshikawa 1987; Reich, 1995) is a special case of our

framework. The second example clarifies the variousconcepts through a simple knowledge-based designsystem. The third example demonstrates how the ma-chine learning system ECOBWEB (Reich and Fenves1992) can be elucidated in our framework.

These three examples follow the same structure:

1. Given a particular context, interpret the closure andneighborhood concepts in a way suitable to the context.

2. Collect the knowledge to realize the interpretation.3. Execute design situations.

The three examples are very different, demonstratingthe diversity of situations that can be understood with the

framework. These examples certainly are not indicative ofthe scope of the framework.

4.1General Design Theory (GDT ) as a special case

4.1.1.Topological closure spacesGDT is defined in terms of the set of all real artifacts thatdid exist, do exist, and will exist S; and a collection ofsubsets (calledabstract concepts) of the spaceSthat satisfythe axioms of point-set topology (Croom 1989). Forexample, in the domain of chairs (Reich 1995) S includes

Fig. 11.


2

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

9/15

eight chairs as depicted in Fig. 12. One abstract conceptcould be chairs that constrain back defined as the set{B,C,F,G}. Another concept could be a movable chairconsisting of {A,E,F,G,H}.

Let us call the YoshikawaTomiyama space (YTspace). According to GDT, a design process is a mappingbetween a YT function space and a YT structure space(see Reich 19959). For example, the specification of a chair

that will be movable and constrain back leads to two po-tential designs, F and G. These designs can be generated intwo ways. The first way starts with {A,E,F,G,H} as themovable designs and refines them (by set intersection)with the constrain back property. The second way startswith {B,C,F,G} as the constrain back designs and refinesthem with the movable property. Note that the refinementprocess was made easier by the use of the eight repre-sentative chairs as mediators between the specification andthe design description. In the absence of these chairs, theprocess might have been more difficult.

In the following, we show that the GDTs mainassumption regarding design knowledge being a point-settopology is a special case of our main concept of closurespaces. To this end, we show that for everyYT spacethere corresponds a unique closure space, and that theYTspace can be derived from this unique closure space.We also demonstrate how to construct the unique closurespace. This can be done without knowing all the entities inadvance.

First, it can be shown that the open sets (Definition 5)of any closure space satisfy three conditions, whichare the axioms defining a point-set topology for S (Brahaand Maimon 1998). Next, we ask the following question:given aYT space, is there a uniqueclosure space ,such that the open sets of coincide with the sets intheYTspace? In general, the answer to this question isnegative. That is, for anyYTspace, there may correspondmany closure spaces where the open sets of each closurespace coincide with the YT space. However, if we focuson a special class of closure spaces (called topologicalclosure spaces, see below), then it can be shown that foranyYT space there corresponds a unique topologicalclosure space (Braha and Maimon 1998). In other words, ifthe open sets of two topological closure spaces coincidewith the sets of some YT space, then the two topologicalclosure spaces are identical(in the sense that both havethe same closure operation). Therefore, YTspaces

correspond to a subsetof closure spaces. This qualitymakes closure spaces more general thanYT spaces. How,then, is a topological closure space defined?

A topological closure space is a closure space where eachUF(F) is a closed set (see Definition 4). That is,if we apply a refinement process starting from the initialspecification list f0 (see Fig. 2), then any refinement pro-cess ends in a single step! The reasoning is as follows:

starting fromf0, we create the closureUF(f0) off0. Next, wefind the closure UF(UF(f0)) ofUF(f0). However, since is a topological closure space, UF(f0) is a closed set,and thus UF(UF(f0))=UF(f0). Consequently, no furtherrefinement is possible and the refinement process termi-nates. This type of design process is rather unrealistic;nevertheless, it is also a consequence of GDT axioms(Reich 1995). Next, we show how to construct the topo-logical closure space out of a YT space.

4.1.2Constructing a topological closure space from a YT spaceFirst, we need to define two concepts related to YTspaces(not to closure spaces): (1)

limit point (also called cluster

point) of a subsetS; and (2)closureof a subsetS (not to beconfused with the closure operation of a closure space).

Definition 6Let be aYT space. An entitys* (real artifact) in Sis a limit point of a set S S if every abstract concept incontainings* contains a point ofS distinct from s* (seeFig. 13). The set of limit points ofS, S, is called the derivedset ofS. Theclosure S ofS is the union ofS with its set oflimit points, i.e., S = S[S.

DiscussionAn entity s* is a limit point of a set S={s} if everyproperty of s* is also a property of s (recall that in GDTproperties are abstract concepts). In general, an entity s*

is a limit point of a set S if every property of s* is also aproperty of some entity in S. Having defined the closureof a set in a YT space, the closure operation UF in thecorresponding topological closure space is defined simplyas UF(S)=S. The structure space is defined similarly. Itcan be shown that the above construction satisfies threeconditions, which are the axioms defining a closureoperation (Braha and Maimon 1998). The closure oper-ation can be used in design execution. For instance,starting with the specification a chair that will bemovable and constrain back, the designer starts with a

Scandinavian chair (chair E in Fig. 12) that is known tobe movable (but not to constrain back), and explores

Fig. 12.

Fig. 13.

9 We use this source rather than the original papers since itsummarizes GDT with simple intuitive examples.


8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

10/15

similar chairs in the closure of E, UF({ScandinavianChair}). This step will obtain all the chairs that sharesimilar functional properties with E. In particular, if thereis a chair that is both movable and constrain back, it willbe included in the closure of E (e.g., office chair andwheel chair). The designer searches within the closure UF({Scandinavian Chair}) for a suitable design solution(e.g., wheel chair) and then performs the synthesis

operation that uncovers the structural description of thewheel chair in the structure space.To summarize: (1) the closure of a subset in a point-set

topology is the particular interpretation of the closureoperation in a related topological closure space; (2) entitiesare the knowledge elements; and (3) design processesare executed as described above as a consequence of theclosure interpretation.

4.2Rule-based designThis section presents a simple rule-based design examplein order to illustrate the topological concepts presented inthis paper. Rule-based systems are useful for this illus-trative purpose since their two methods of controlfor-ward chaining and backward chainingcan be construedas forms of analysis and synthesis.

Using forward chaining, we start with the known factsin the knowledge base and generate new conclusions thatin turn can allow more inferences to be made (Russell andNorvig 1995). This kind of deductive inference is useful indesign analysis, where the task is to uncover the behaviordisplayed by the artifact when it is subjected to varioussituations.

Alternatively, the strategy of backward chaining is tobegin with the functional requirements we want toachieve, and then attempt to accomplish their conditions(new functional requirements). In backward chaining, thesearch process is repeated recursively when there is agoal (functional requirement) to be achieved. This isdone by selecting and applying transformation rules to acandidate unsatisfied goal. The search process terminateswhenever a set of functional requirements is identified,which can be matched to known structural attributes. Ifincompatibilities (e.g., violated constraints) happen inlater design phases, then backtracking is applied and theinference engine generates another set of unsatisfiedgoals. Design synthesis, which is the task of finding astructure given a functional requirement, is likely toutilize backward chaining rather than forward chaining

(e.g., Takeda et al 1990). In order to automate a back-ward chaining inference engine, it is important to gen-erate effective subgoals in a controlled manner as wellas employing efficient backtracking methods in order todeal with the enormous search space of possible goals(Chandrasekaran 1990).

4.2.1Rule-based design and closure spacesLet be all the information (at any stage of thesolution process) about the problem being solved,where fi and di are the current functional andstructural descriptions, respectively. By utilizing a

backward chaining inference mechanism (also calledabduction), a new design description is ob-tained. The descriptions and are re-lated via the logical formula fi, where is referred to as the antecedentand asthe consequent10. The above logical implication is per-formed with respect to the underlying designersknowledge.

Backward chaining can be interpreted using our topo-logical concepts as follows. For any two expressions a andb, ifb2U(a) then b fia. That is, the closure of anyexpressiona includes expressions that logically derive theexpressiona. By applying the above construction, rule-based design can be cast into our design process frame-work. The designer starts by creating part of the closure ofthe initial design description . This is performed byapplying one or more production rules in the knowledgebase (see example below). The designer selects anydescription inUFD(), finds part of the closure ofthe selected design description, etc.

The interpretation of abduction in terms of closuresmay be extended to other topological notions. For exam-ple, a set A is closed if every logical expression in A islogically derived11 only by expressions inA. The interior ofa setA includes expressions inA that logically derive onlyexpressions inA. A set A is a neighborhood of anexpressionaif the expressions that are logically derived bya are included in A . Thus, ifa is a known fact (e.g., thestretched area is 57 cm), then any expression that isdeduced bya (e.g., the tensile stress is high) is includedin a neighborhood ofa. This kind of deductive inference isuseful in analysis. A set A is open if every expression inAlogically derives only expressions inA. Thus, if an open setA includes known facts, no new fact can be derived fromthe known facts in A .

In the following, the problem of designing an auto-mobile using a rule-based system is used to explain theconcepts of the topological model.

4.2.2Automobile design exampleLet the structural and functional descriptions be specifiedin terms of a list of properties. The structural propertiesthat specify the configuration of actual cars as well as thefunctional properties that are manifested by actual cars arepresented in Table 1a and Table 1b, respectively. A smallsample of the domain-specific knowledge relevant to the

car design domain is expressed in terms of the productionrules presented in Appendix 2.Assume that the designer is faced with the problem of

designing a car that is able to achieve the following func-tional attributes as requirements:

1. The car creates minimal pollution (f3).2. The car is capable of high driving speed (f10).3. The car has low fuel consumption (f12).4. The car is safe (f18).

10 Here, in any formula of the formA fi B,A is referred to as theantecedentandB as the consequent(Russell and Norvig 1995).11By applying a specific knowledge base.


4

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

11/15

The following facts are assumed: (1) the car is used forfamily driving, (2) the external conditions are good, (3) themaximum allowed speed is 160 km/h, and (4) the car isused for urban driving.

The following constraints12 are further considered: (1)the structural attributes tire with 205 width symbol (d41)and tire with 155 width symbol (d42) cannot be includedtogether in a design description, and (2) the structural

attribute the car is electric-powered (d15) cannot be in-cluded in a design description if the functional attributethe car has DIESEL ENGINE (f2) is satisfied.

The rule-based design system needs to search throughthe problem space for a path from the initial requirementsto some state of the cars structural description such thatthe requirements f18, f10, f12, f3 are achieved, and whileadhering to the compatibility constraints.

In attempting to achieve the initial requirements, abackward chaining inference with depth-first controlstrategy is used by the rule-based system. In addition, ifany of the above constraints are violated during the search,dependency-directedbacktracking13 (Brown and Chandr-asekaran 1989) is utilized and an alternative rule is chosenfrom the list of available finite choices.

In the example, the design description is a conjunctionof structural and functional attributes (if a functionalattribute appears in a process state it means that it remainsto be satisfied). Table 2 shows the trace of processdescriptions generated in the course of searchingfor a solution to the automobile design problem. Asmentioned above, is a description in the clo-

sure of . At each step of the search the consequentparts of the production rules (listed in Appendix 2) arematched against the current unsatisfied functional attri-butes and known facts. The current unsatisfied functionalattributes in the design description are given byfias shown in the second column of Table 2. Since manyproduction rules may match the current description, thepreferred rule is the one that matches the first leftmostunsatisfied functional attribute (a depth-first controlstrategy). Topologically speaking, the designer selects arefined description in the closure of according tothe above matching heuristic procedure.

To summarize: (1) the concept of logical abduction isused as an interpretation of the closure operation; (2) arule base constitutes the knowledge; and (3) design andanalysis processes are executed as backward and forwardinferences, respectively.

4.3ECOBWEBECOBWEB (Reich and Fenves 1992) is a machine learningsystem that creates a classification hierarchy from designexamples that are represented by lists of property-valuepairs including functional and structural properties. Givena partial design description (which could include only apart of the functional specifications) and a previously

learned classification hierarchy, ECOBWEB can synthesizea number of candidate designs from the hierarchy. Thecandidates are complete descriptions of designs consistingof all functional and structural descriptions. ECOBWEBhas several design strategies. It has been previously shownthat ECOBWEB approximates the topological structure ofGDT (Reich 1990). Now we illustrate how ECOBWEBs

Table 1a. Structural attributes for the automobile design example

Structural attributes

(d1) 4-wheel drive (d23) High transmission ratio(d2) 4-wheel steering (d24) Horn(d3) 68 cylinders (d25) Hydraulic disk brakes(d4) Absorbent front end (d26) Large pistons & cylinders(d5) Air bag (d27) Light weight(d6) Air-cooled engine (d28) Liquid cooling system

(d7) Air deflector (d29) Low & small structure(d8) An engine thatdeflects down

(d30) Muffler

(d9) Antilock brakingsystem (ABS)

(d31) Power brakes

(d10) Automatic belts (d32) Powerful starter(d11) Catalytic converter (d33) Radial tire(d12) Deep thread patterns (d34) Richer mixture fuel(d13) Disconnecting

fan system(d35) Rigid passenger

compartment(d14) Drum brakes (d36) Stabilizers in the front(d15) Electric powered (d37) Suspension system(d16) Electronic ignition (d38) Tubeless tire(d17) Extra differential (d39) Windshield defroster(d18) Extra strong door (d40) Windshield washer & wiper(d19) Extra-strong roof (d41) Tire with 205 width symbol

(d20) Fog lights (d42) Tire with 155 width symbol(d21) Fuel injection (d43) Tire with 60 aspect ratiosymbol

(d22) High groundclearance

(d44) Tire with U speed symbol

Table 1b. Functional attributes for the automobile designexample

Functional attributes

(f1) Aerodynamic design (f16) Passable in difficult terrain(f2) Diesel engine (f17) Reliable tire(f3) Creates minimal pollution (f18) Safe car(f4) Easy parking (f19) Safe in accidents

(f5) Efficient engine (f20) Safe in bad weather(f6) Economical (f21) Safe in flipping over(f7) Reliable brakes (f22) Safe in head-on collisions(f8) Heavy car (f23) Safe at high driving speed(f9) High power output (f24) Safe in off-highway road(f10) High driving speed (f25) Safe in poor external

conditions(f11) High-volume

combustion chamber(f26) Safe in poor visibility

(f12) Low fuel consumption (f27) Safe in side collisions(f13) Low maintenance costs (f28) Small car(f14) Mechanically

dependable and durable(f29) Small engine

(f15) Off-highway tire (f30) High-powered engine

12 Constraints indiscrete domains can be expressed as compati-bility relations between attributes, stating that certain combina-tions are allowed or not.

13 Dependency-directed backtracking provides a way of takinginto account the information about which pieces of knowledgecontribute to the failure. This information is used in the decisionof how far to backtrack.


8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

12/15

Table2.Acoupleddesignprocessfortheautomobiledesignproblem

(completetablemaybefoundinBrahaandMaimon1998)

Process

step

Designdescription

CandidaterulesSelected

rule

Structuraldescriptionandopen

functionalattributes

Satisfiedfunctionalattributes

1

f18

and

f10

and

f12

and

f3

Rule4

Rule4isfiredto

decomposef18:thecar

isSAFE

2

f19

and

f10

and

f12

and

f3

f18

Rule6

Rule6isfiredto

decomposef19:thecar

isSAFEINACCIDENTS

3

f22

and

f27

and

f21

and

d10

and

f10

and

f12

and

f3

f19andf18

Rule11

Rule11

isfiredto

decomposef22:thecar

isSAFEINHEAD-ON

COLLISIONS

4

d4

and

d5

and

d8

and

f27

and

f21

and

d10

and

f10

and

f12

and

f3

f22

and

f19

and

f18

Rule12

Rule12

isfiredto

decomposef27:the

carisS

AFEINSIDE

COLLISIONS

11

d4

and

d5

and

d8

and

d18

and

d19

and

d35

and

d10

and

d29

and

d7

and

d26

and

d3

and

d32a

nd

d28

and

d34

and

d30

and

d23

and

d41

and

d43

and

d44

and

f12

and

f3

f2and

f11

and

f30

and

f1and

f10a

nd

f21

and

f27

and

f22

and

f19

and

f18

Rule21,

Rule38

Rule38

isusedto

decomposef12:thecar

hasLO

W

FUEL

CONSU

MPTION

12

d4

and

d5

and

d8

and

d18

and

d19

and

d35

and

d10

and

d29

and

d7a

nd

d26

and

d3

and

d32

and

d28a

nd

d34

and

d30

and

d23

and

d41

and

d43

and

d44

and

f5and

d13and

d42

and

f3

f12

and

f2and

f11

and

f30

and

f1a

nd

f10

and

f21

and

f27

and

f22

and

f19

and

f18

Backtracking

Thestru

ctural

attributesd41

(tirewith

205widthsymbol)andd42

(tirew

ith155width

symbol)cannotbe

include

dtogetherina

design

description

13

d4

and

d5

and

d8

and

d18

and

d19

and

d35

and

d10

and

d29

and

d7

and

d26

and

d3

and

d32

and

d28

and

d34

and

d30

and

d23

and

d41

and

d43

and

d44

and

f12

and

f3

f2and

f11

and

f30

and

f1and

f10a

nd

f21

and

f27

and

f22

and

f19

and

f18

Rule21,

Rule38

Rule21

isusedto

decomposef12:thecar

hasLO

W

FUEL

CONSU

MPTION

18

d4

and

d5

and

d8

and

d18

and

d19

and

d35

and

d10

and

d29

and

d7

and

d26

and

d3

and

d32

and

d28

and

d34

and

d30

and

d23

and

d41

and

d43

and

d44

and

d16

and

d21

and

d13

and

d27

andd11

f3and

f5and

f12

and

f2and

f11

an

d

f30

and

f1and

f10

and

f21

and

f27

and

f22a

nd

f19

and

f18

STOP

Consiste

ntsolutionis

obtained


6

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

13/15

prototype-based synthesis strategy works in our frame-work.

Given an initial that could contain some func-tional specifications and a partial design description, suchas design a highway bridge where vertical clearance (Clear-G) governs (see Fig. 14), ECOBWEB gradually refines ituntil it becomes a description containing all property-value pairs . The refinement is done in stages. First, is pushed down the hierarchy until a node is foundthat has a characteristic value for functional or designdescription properties (characteristics T-or-D and Lanesin Node 1). These characteristics (if not part of the presentdescription ) are assigned to the current designdescription. If it is a characteristic function, istransformed into whered1=d0. If the characteristic

is a structural property, is transformed into where f1=f0. If the node included a mix of func-tional and structural characteristics, the description is transformed into (that is, ).

Subsequently, the design is pushed down to Nodes 2and 5 and its design description is augmented with TypeSimple-T and Material Steel while its initial specificationsare matched by the functions in these nodes. The designcould end here with an abstract description or, given di-verse knowledge expressed in a deep hierarchy, the pushdown operation would terminate when all the missingdesign description properties have been matched with andassigned characteristic values. Limited knowledge, exem-plified by a shallow hierarchy, will lead to pushing thedescription to a leaf node and completing the missingvalues from that leaf.

Implicitly, the hierarchy created by learning fromexamples can be interpreted as a sequence of closures. Theclosure operation could be defined as: if is thepresent description then its closure includesthe properties in with several additional properties.ECOBWEB only approximates this closure (see Sect. 3.4);therefore, its synthesis is not guaranteed to be successful atall times. In particular, when the hierarchy is shallow, the

closure approximation is coarse and failures areunavoidable. In contrast, when the hierarchy is deep, the

chances of getting successful results increase (Reich 1995),even though the hierarchy is still an approximation of aclosure. ECOBWEB push down operation implements agreedy search algorithm for reducing computationalcomplexity; therefore, no optimal designs are expected.

To summarize: (1) the hierarchical structure created bylearning is an approximation of closure; (2) the examplesare the source of knowledge; and (3) design processes areexecuted according to the aforementioned procedure.

5DiscussionWe have described a mathematical framework of design

processes based on closure spaces. This framework is shownto be more general than GDT. In addition, the frameworkhas been utilized to describe the operation of rule-basedsystems, and a particular learning system. These resultsdemonstrate that our model has the desirable quality ofrepresenting several, seemingly distinct, approaches as in-stances of the same framework. It is important to note thatour framework is not suggested as a means for supporting orproving theorems for automated design.

Using simple examples throughout the paper, we alsohinted at the potential for the framework to serve as abasis for a descriptive study of design. Various designphenomena such as design failure, identification of designknowledge bottlenecks, and benefits of collaborative de-sign could be described and understood using the frame-work. This potential needs to be explored further.

Another consequence of the proposed model is relatedto design sensitivity and design robustness. More specifi-cally, the topological concept of continuity can be devel-oped in order to address the important issues of productand process robustness (Braha and Maimon 1998; Brahaand Reich 2001). By process robustness we mean thedesirable property of a design process by which a smallchange in the input (i.e., specifications expressed in termsof the products functionality) results in a slightmodification in the design process output (i.e., artifacts

Fig. 14.


8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

14/15

structural description). Process robustness supports de-sign synthesis since a new problem, whose specifications

differ slightly from the specifications of a known product,may be solved by slightly modifying the structure of theknown solution (similar to case-based reasoning). Thismay not yield a creative design but, nevertheless, a betterdesign. Product robustness refers to the positive aspectof the product where only a small change in the productsbehavior occurs when the products structure (e.g.,geometry) is slightly perturbed. The robustness propertyof a product also guarantees that a sequence of incre-mental refinements to its structure (e.g., due to temporaldrift, deterioration, or failure) will cause only smallincremental changes to its functionality.

In the future, we intend to address several additional

issues. (1) Demonstrating the utility of the proposedframework in classifying and analyzing different designmethodologies, such as the conceptual design with afunction structure (Pahl and Beitz 1984), or the sys-tematic concept generation for technical products (Hubkaand Eder 1988); (2) showing the utility of our frameworkin describing collaborative design, and elaborating on theconsequences of design robustness as discussed above;and (3) exploiting the computational aspects (consideringrealistic approximation procedures) and considering theunderlying topological concepts (e.g., closure and neigh-borhood).

Appendix 1

Cluster point, interior, and neighborhood

Definition A.1 (Cluster point of a set)A cluster pointof a set Fin a closure function space is apoint fbelonging to the closure ofF){f} The set of allcluster points of a set Fis denoted byF and called thederivative ofFin the closure function space. Clearly, theclosure of a set F is the union of the set Fwith its set ofcluster points.

Definition A.2 (Interior of a set)With any closure UF for a set F there is associated theinterior operation intUF, denoted briefly byint. The

operationint is a function that maps elements of 2

F

into2F, such that for each FF, int(F)=F)UF(F)F). The set

int(F) is called the interior of F in .

Definition A.3 (Neighborhood)A neighborhoodof a subset Fof a closure function spaceN(F) is any subset G ofF containingFin its interior. By aneighborhood, N(f), of a functional description fofF, wemean a neighborhood of the one-point set {f}. Theneighborhood system of a set F F (a point f2F) in thespace is the collection of all neighborhoods of theset F(the point f).

Table 3. A sample of rules for the car example

RULE 1 If the car has OFF-HIGHWAY TIRESand 4-wheel driveand extra differentialand high ground clearance and is light weight

Then the car is PASSABLE IN DIFFICULT TERRAINRULE 2 If the car is SAFE IN POOR EXTERNAL CONDITIONS

Then the car is SAFE and the external conditions arenot goodRULE 3 If the car is SAFE AT HIGH DRIVING SPEED

Then the car is SAFE and the maximum allowed speed is 200 km/hRULE 4 If the car is SAFE IN ACCIDENTS

Then the car is SAFE and the car is used for family driving andthe external conditions are goodand the maximum allowedspeed is 160 km/h

RULE 5 If the car is SAFE IN POOR VISIBILITY and SAFE IN BADWEATHERand SAFE IN OFF-HIGHWAY ROADS

Then the car is SAFE IN POOR EXTERNAL CONDITIONSRULE 6 If the car is SAFE IN HEAD-ON COLLISIONS andSAFE

IN SIDE COLLISIONS and SAFE IN FLIPPING OVERandhas automatic belts

Then the car is SAFE IN ACCIDENTSRULE 11 If the car has an absorbent front endandair bagsandan

engine that deflects downThen the car is SAFE IN HEAD-ON COLLISIONS

RULE 12 If the car has extra strong doorsThen the car is SAFE IN SIDE COLLISIONS

RULE 21 If the car has AERODYNAMIC DESIGN andan EFFICIENT

ENGINEand a DIESEL ENGINE anda disconnecting fansystem and is light weight

Then the car has LOW FUEL CONSUMPTIONRULE 22 If the car has tubeless tiresand radial tires

Then the car has RELIABLE TIRESRULE 38 If the car has AERODYNAMIC DESIGN andan EFFICIENT

ENGINEand a DIESEL ENGINE anda disconnecting fansystem and tires with 155 width symbol andtires with 60 aspect ratio symbol

Then the car has LOW FUEL CONSUMPTION


8

8/10/2019 art%3A10.1007%2Fs00163-003-0035-3

15/15

Appendix 2

production rulesA small sample of the domain-specific knowledge relevantto the car design domain is expressed in terms of theproduction rules presented in Table 3.

ReferencesAkin O (1979) An exploration of the design process. Design Methods

and Theory 13(34):115119Blessing LTM (1995) A process-based approach to computer-sup-

ported engineering design. In: Proceedings of the workshop onknowledge sharing environment for creative design of higherquality and knowledge inventiveness, RACE-Institute, Universityof Tokyo

Braha D, Maimon O (1998) A mathematical theory of design: foun-dations, algorithms, and applications. Kluwer, Boston

Braha D, Reich Y (2001) Topological structures for modeling engi-neering design processes. International conference on engineeringdesign (ICED 01), Glasgow

Brown, D, Chandrasekaran, B (1989) Design problem solving:knowledge structures and control strategies. Morgan Kaufmann,San Francisco

Cech, E (1966) Topological spaces. Wiley, LondonChandrasekaran, B (1990) Design problem solving: a task analysis. AI

Mag 11:5971Croom, F (1989) Principles of topology. Sounders College, ChicagoDasgupta S (1994) Testing the hypothesis law of design: the case of the

Britannia bridge. Res Eng Des 6:3857Gero JS (1990) Design prototypes: a knowledge representation schema

for design. AI Mag 11:2636Hales C (1987) Analysis of the engineering design process in an

industrial context. Dissertation, University of Cambridge, GantsHill, Hampshire

Hubka V, Eder WE (1988) Theory of technical systems: a total concepttheory for engineering design. Springer, Berlin HeidelbergNew York

Pahl G, Beitz W (1984) Engineering design. The Design Council,London

Reich Y, Fenves SJ (1992) Inductive learning of synthesis knowledge.Int J Expert Syst 5:275297

Reich Y, Subrahmanian E, Cunningham D, Dutoit A, Konda S, PatrickR, Westerberg A, the n-dim group (1999) Building agility fordeveloping agile design information systems. Res Eng Des11:6783

Reich Y (1990) Converging to ideal design knowledge by learning.In: Fitzhorn PA (ed) Proceedings of the first international work-

shop on formal methods in engineering design, Colorado Springs,pp 330349Reich Y (1995) Measuring the value of knowledge. Int J Hum Comput

Stud 42:330Reich Y (1995) A critical review of General Design Theory. Res Eng

Des 7:118Russell S, Norvig P (1995) Artificial intelligence: a modern approach.

Prentice Hall, New JerseySimon HA (1996) The sciences of the artificial, 3rd edn. MIT Press,

CambridgeSmithers T (2000) Synthesis in designing as exploration. In: Pro-

ceedings of the 2000 international symposium on modeling ofsynthesis, Tokyo, pp 89110

Suh NP (2001) Axiomatic design: advances and applications. OxfordUniversity Press, New York

Takeda H, Veerkamp P, Tomiyama T, Yoshikawa H, (1990) Modelingdesign processes. AI Mag 11:3748

Tomiyama T, Yoshikawa H (1987) Extended General Design Theory.In: Design theory for CAD, Proceedings from IFIP WG 5.2,Amsterdam

Ullman D, Stauffer L, Dietterich T (1986) Preliminary results ofexperimental study of the mechanical design process. TechnicalReport 86309, Oregon State University

Yoshikawa H (1981) General design theory and a CAD system.In: Sata E, Warman E (eds) Manmachine communication inCAD/CAM, NorthHolland, Amsterdam, pp 3558


art%3A10.1007%2Fs00163-003-0035-3

Documents