ORIGINAL PAPER

Offer Shai Æ Yoram Reich

Infused design. I. Theory

Received: 20 August 2002 / Revised: 15 July 2003 / Accepted: 24 March 2004 / Published online: 15 July 2004� Springer-Verlag London Limited 2004

Abstract The paper introduces infused design: anapproach for establishing effective collaboration betweendesigners from different engineering fields. In infuseddesign, the design problem representation is brought upto a mathematical meta-level, which is common to allengineering disciplines. The reasoning about the problemis then done by usingmathematical terminology and toolsthat, due to their generality, are the same for all engineers,disregarding their background. This gives engineers anopportunity to infuse their work with knowledge, meth-ods, and solutions shared by specialists from other engi-neering fields. When these knowledge, methods, andsolutions cross disciplinary boundaries, they are provablyrelevant to any problem in another domain towhich it canbe transformed. The suggested meta-level consists ofgeneral discrete mathematical models, called combina-torial representations (CR). Specific mathematical basisfor the combinatorial representations chosen in this paperis graph theory although other representations are pos-sible. We explain the theory of infused design and care-fully contrast it with other approaches. This comparisonclearly demonstrates the advantages of infused design andits potential. We conclude with several practical issuesrelated to the introduction of infused design into practiceand briefly discuss the role of information systems in in-fused design. A companion paper includes severalexamples that demonstrate the details of infused design.

Keywords Collaboration Æ Concurrent engineering ÆCreativity Æ Combinatorial representations Æ Graphtheory Æ Knowledge sharing Æ Knowledge infusion ÆProduct quality Æ Design process

1 Introduction

Design is a social, collaborative process. Customers,designers, and other professionals exchange informationabout the product objectives and their roles in itsdevelopment. They divide the design tasks, monitor theprocess, detect and resolve conflicts, and continuallynegotiate the meaning of information related to, as wellas generated in, the project (Finger et al.1995; Kondaet al.1992; Schrage 1991).

In most design projects, the initial process stages in-volve arriving at mutual understanding of terminologyand the scope of the work. When parts of the workbecome clear and agreed upon, work progresses byindividual problem solving. As design progresses, thenature of collaboration is directed to minimize and re-solve conflicts.

Since collaborative design is inevitable, the competi-tiveness of organizations depends on their ability toexercise quality collaborative design efficiently andeffectively. Concurrent engineering (CE) (Prasad 1996;Reich and Subrahmanian 1992; Walton 1991) is seen asa collection of techniques and development philosophythat could improve design once put in place to supportcollaboration. Concurrent design happens at the inter-face between designers and their design support systems(Finger et al. 1995). Concurrent design helps to consol-idate the different perspectives that are active in a designproject. It also engenders the creation of new knowledgewhen different perceptions meet, thus extending theboundaries of each with additional concepts, relations,and operations.

To date, this interface has been the focal point ofmany studies attempting to support the concurrent workof engineers on large projects. In practice, a well-defined,agreed upon interface could become the backbone ofsuccessful projects whereas its omission would be animpediment. Work on the interface can be subdividedinto technical and organizational perspectives (Reichand Subrahmanian 1992). In both perspectives, work

O. Shai (&) Æ Y. ReichSchool of Mechanical Engineering,Faculty of Engineering, Tel Aviv University,69978 Tel Aviv, IsraelE-mail: shai@eng.tau.ac.il

Research in Engineering Design (2004) 15: 93–107DOI 10.1007/s00163-004-0047-7

has dealt with issues at various levels. The technicalperspective, which has been the main focus of academicresearch, has dealt with topics such as:

1. Defining languages for specifying the design param-eters (McMahon and Xianyi 1996; Clarkson andHamilton 2000)

2. Creating product models (Eastman and Jeng 1999),including systems for configuration and productdata management (PDM) and electronic mock-ups(Bechkoum 1997)

3. Defining the interface in terms of shareable parame-ters (Clarkson and Hamilton 2000), constraints (Bo-wen and Bahler 1992), choices, and other knowledgeelements such as ontologies (Neches et al. 1991).These definitions could sometimes be augmented withmechanisms for automated detection of conflicts(Bowen and Bahler 1992) or with agents’ technologyfor automated execution of well-defined engineeringtasks (Park et al. 1994).

4. Developing synchronous communication channels(Subrahmanian et al. 1993b; Minneman and Leifer1993)

The organizational perspective, which has been theessence of most practical implementations of concurrentengineering, has dealt with issues such as:

1. Creating the context (e.g., structure and procedures)for the working of multifunctional teams

2. Developing mechanisms that operate on the interfacefor coordinating work (Whitfield et al. 2000) includ-ing ensuring effective communication between pro-fessionals and between them and customers (Akao1990; Reich 2000; Reich et al. 1996)

3. Structuring design projects such that the interfacebecomes small and manageable (small interfacemeans minimal interactions and minimal chances forconflicts) (Eppinger et al. 1994; Steward 1981)

Studies that touched both perspectives include toolsfor asynchronous communication channels (Subrahma-nian et al. 1993b), design rationale capture methods(Reich 2000), or more general infrastructures for infor-mation modeling (Reich et al. 1999).

The underlying assumption in all these studies wasthat engineers collaborate through an interface andotherwise conduct their work individually using thedomain methods and tools developed within their owndiscipline. In many situations, an interface exists evenwithin one discipline where professionals use differentterminologies to discuss their work (Sargent et al.1992). In CE, the interface is a hurdle to be minimized.

Our work revises this situation. We see the interfaceissue in CE as an opportunity. We see the opportunity ofcreating new design knowledge at the interface betweendesigners and thus work to extend the interface in orderto fuse design knowledge from diverse disciplines intocoherent usable knowledge that can solve disciplinary aswell as interdisciplinary problems. We not only support

‘‘transcending boundaries while retaining the technicalexpertise afforded by specialization’’ (Finger et al. 1995,p. 89); but also improve technical expertise by fusinginterdisciplinary expertise into one amalgam. Conse-quently, we address the call that ‘‘research should focuson the creation, maintenance, and extension of linksbetween the various participants’’ (Finger et al. 1995, p.90).

Our work presents a new way of doing design called‘‘infused design.’’ Infused design supports the exchangeof focused, high quality, critical knowledge betweenproject participants. In this practice, engineers not onlycollaborate through the traditional interface, but alsothrough new interfaces on conceptual as well as detaileddesign activities. They exchange knowledge aboutproblem modeling, analysis, and design proceduresthrough combinatorial representations (Shai 2001b),thus bootstrapping engineering work in ways not pre-viously conceived. In some cases, design is made possi-ble, and in others, its quality is improved due to fusingknowledge and methods from other disciplines. More-over, such benefits may also shorten the developmentprocesses.

Following an analysis of state-of-the-art work inconcurrent design (Sect. 2), we present the origin ofinfused design in a multidisciplinary combinatorialapproach (MCA) (Shai 2001b) (Sect. 3), and present theconcept of infused design in detail (Sect. 4). Subse-quently, we analyze infused design in relation to otherapproaches (Sect. 5). We carefully show how infuseddesign is more powerful due to its mathematical foun-dation. We also delineate the issues involved in theintroduction of infused design into design practice. Inthe sequel paper, we provide several examples of infuseddesign that demonstrate its strength.

2 Collaborative and Concurrent engineering

Design has always been done collaboratively unlessone designs and produces for oneself in a solitary act.Almost all products of interest require the involvementof teams of participants from diverse disciplines fortheir development and certainly for their manufacture.Concurrent engineering is a relatively new approach todeveloping products where interdependent tasks arecarried out simultaneously by different engineers orteams. Concurrent engineering involves the coopera-tion of people from multiple disciplines in a way thatincites sharing goals, methods, perspectives, needs, andother concerns related to the project. When customersor users are heavily involved in the developmentprocess, it is called participatory design (Reich et al.1996).

Whenever collaborative or concurrent engineeringtakes place, different people, or people and systems,interact. The interaction serves to exchange knowledgebetween all parties that need it for the progression of

94

work. There are two broad interdependent concernsrelated to this interaction:

1. How, when, and among whom is it performed?2. What is exchanged?

These issues could be studied from two perspectives:studying design activities and creating support tools toaddress these concerns. Empirical studies of design havebeen conducted in many settings and have attempted toanswer the above questions (e.g., Ahmed et al. in press;Dutoit 1996; Boujut and Tiger 2002; Subrahmanian1991). From the support perspective and following thefindings of the empirical studies, the first question dealswith issues such as mechanisms for effective communi-cation, selection of partners, and the organization ofworkto optimize the exchange (e.g., minimize interdependen-cies between tasks). The second question deals with thesole purpose of the communication: the knowledge beingcommunicated, its complexity, and value to participants.The dependency between these concerns is illustrated byissues such as: increased concurrency leads to designingwith increased amount of unknown information thatresults in future conflicts. Using coordination methods,the project structure and the interactions are designed forthe purpose of minimizing conflicts or knowledgeexchange.

A recent review dealt with two perspectives of coor-dination:

1. The strategic perspective dealing with coordinationtechniques, cooperation and collaboration tech-niques, organizational models, project management,workflow management, and task models (Whitfieldet al. 2000)

2. The operational perspective dealing with resourcemanagement, planning, and scheduling (Coates et al.2000)

Independent of the perspective or particular coordi-nation technique, the fundamental facilitator of com-munication is a common language. Without a commonlanguage, communication is meaningless or very lim-ited. By language, we mean the concepts and how theyare assembled (e.g., grammar) by an agent to deliver itsintent or even its state to the outside world. Inherently,no two agents, natural or artificial speak exactly thesame language. When addressing the same physicalobject, the two agents might refer to it by differentnames, and the same name might mean different objectsfor these two agents. In product development, conceptsmean different things for participants from verticallydifferent departments (e.g., customers, marketing peo-ple, designers, manufacturers, distributors, or main-tainers) and horizontally different disciplines (e.g.,mechanical, electrical, software, or biomedical engi-neering). Similar naming problems occur even within adiscipline (Sargent et al. 1992) and in research (e.g.,Messac and Chen 2000).

Automated or computational approaches to concur-rent engineering attempt to address the language

problem by creating a universal language with defini-tions of the meaning of terms that could be understoodby all interacting agents (Erkes et al. 1996; Neches et al.1991; Park et al. 1994). Such language is often referredto as ontology.

In real domains, terminology evolves continually(Coulter et al. 1998). Consequently, in such situations,fixing language a priori is impossible, while creatingdynamic environments conducive of language evolutionsincluding thesaurus and indexing mechanisms is the onlyoption. This observation is strengthened by the limitedsuccess that computational approaches to CE have hadsince their inception. Therefore, we focus on concurrentengineering performed by people.

Overcoming the language problem is part of design(Dutoit 1996). In the early stages of a project, or whenconfronted with new tasks, the development team must(and also has a tendency) to develop a vocabulary withwhich to interact about the project (Garrod 1998). Thisvocabulary gets refined as the project evolves whendiscrepancies between different peoples’ understandingof terms emerge and are being resolved. The earlier adesign team settles on a vocabulary and aligns all itsmembers, the better are the prospects of the project(Dutoit 1996).

Given the quintessential role of common language,the crucial issue is how could procedures and toolssupport the process of vocabulary formation or lan-guage alignment? Such support must address the initiallanguage formation as well as the subsequent languageevolution that is driven by design conflicts or variousmisunderstandings (Reich el al. 1993).

We can summarize the state-of-the-art of collabora-tion and concurrent engineering technology and practicethrough Fig. 1a. Project participants such as designersor teams of designers work apart using their own toolsand knowledge and interact by exchanging informationabout concepts, parameters, constraints, or other rele-vant information that constitutes their shared interface.The interaction or sharing acts can be done in design

Fig. 1 Confined versus extended communication and knowledgetransfer

95

reviews or in other formal or informal settings. Once anexchange takes place, the participants proceed with theirwork in isolation. Since this sharing makes use of aconfined interface of shared language, we term it ‘‘con-fined’’ communication and the infrastructure that sup-ports such language sharing and communication istermed a confined infrastructure.

Confined communication is narrow in scope, (onlyterminology and project parameters such as constraintsand issues are shared) and usually, is short in duration(confined to design reviews, detected conflicts, etc.). Thisis the nature of the interface between disciplines inpresent engineering practice.

We feel that much more sharing of knowledge be-tween design participants is possible. If we had betterunderstanding of diverse disciplinary knowledge, wecould form meta-knowledge about these disciplines thatwould allow us to:

1. Provide tighter integration between designers throughbetter and deeper understanding of disciplinary con-cepts. In doing so, reduce effort in, or make moreeffective, the informal exchange of informationbetween designers and others involved

2. Support the transfer of technical expertise includingthe transfer of solution methods and the creation ofnew knowledge

3. Provide a basis for disciplines remote from engi-neering to understand part of the engineering workand even contribute to it

4. Provide a basis for more efficient managing of pro-jects involving multidisciplinary integrated systems

These provisions are valuable for any collaborationbetween different designers or disciplines and are rep-resentative of the advantages of infused design. Wedemonstrate the first two provisions by the simpleexamples in this paper and through the more detailedexamples in the companion paper. Demonstrating thelast two provisions remains a future task. In Fig. 1b, theextended communication infrastructure would consist ofmechanisms for sharing language and managing meta-knowledge about diverse domains. The communicationcould therefore be much more intense than before, andwould last longer and occur more often during thedevelopment process. Knowledge could be shared be-tween disciplines and communication can become usefuleven for the purpose of executing tasks presently per-ceived as purely disciplinary.

Infused design deals precisely with such methods.Infused design fundamentally changes the nature of com-munication between design project participants. Morecommunication does not necessarily mean extra overalldesign time; communication and cooperation would bemore focused and intense and of higher quality. RecallDutoit’s ( 1996) study showing that extra effort spent inarriving at a common vocabulary reduced design com-plexity and improved its quality. Consequently, the timesaving due to resolving design difficulties or impasseswould outweigh the increased effort in communication.

Infused design could lead to solving problems withpresently unknown solution or could prevent the rein-vention of solutions from scratch when readily availablesolutions exist in other disciplines. As we see later,infused design rests on a firm formal foundation. Nev-ertheless, studying it requires about a 50 hr course, andexecuting it does not burden the process since the pro-cess steps are simple and can be executed quickly (seeexamples in the sequel paper, Shai and Reich 2004). Ofcourse, trying to use infused design on simple problemsor on each design issue might be unbeneficial and thuswaste unnecessary resources.

3 Foundation of ‘‘infused design’’

Infused design supports the exchange of focused, highquality, critical knowledge between project participantsby making use of the relationships between the repre-sentations of knowledge in these and other disciplines.If such quality exchange of design knowledge is doneacross projects, the benefit of infused design is ampli-fied. Even without infused design or the transfer ofdisciplinary knowledge across disciplinary boundaries,there is a wealth of information that needs to bemanaged for effective reuse. When new sharingopportunities such as infused design, are introduced, anew layer of possible knowledge transfer is added andneeds to be managed for its effective dissemination andreuse.

While we recognize immediately the important role ofcomputational support for such knowledge manage-ment, and even though we can offer good solutions forsuch management (e.g, n-dim) (Reich et al. 1999;Subrahmanian et al. 1997), infused design can be donemanually. Similar to CE that requires no computersupport (Prasad 1996; Reich and Subrahmanian 1992)infused design needs merely careful organizational sup-port. In this paper, we concentrate on the fundamentalconcept of infused design and leave the computationalsupport to future studies.

Infused design was made possible by multidisciplinarycombinatorial approach (MCA), an approach thatallows for exchanging disciplinary knowledge across dis-ciplines. Presently, it is seen as the facilitator of infuseddesign by providing the mechanisms for exchangingdetailed knowledge across disciplines. Nevertheless, wedo not restrict infused design to be dependent solely onMCA as long as alternative approaches for exchangingknowledge are made available.

The idea behind MCA begins with developing generaldiscrete mathematical representations, called combina-torial representations (CR). Then, each combinatorialrepresentation is thoroughly investigated for its embed-ded properties and relations with other CR. Afterwards,the CR are used to represent diverse engineering prob-lems. The mathematical foundation of the CR mainlycomprises three branches of discrete mathematics: graphtheory, matroid theory, and discrete linear program-

96

ming, while the examples in this and the sequel paperexclusively employ the graph representations. We pur-posefully chose graph theory examples due to the intu-itive nature of graphs for representing complex systemsbut infused design applies well to the other types ofrepresentations. Each representation offers additionalknowledge about concepts, solution methods, andsolutions to specific problems. Additional representa-tions could be added if they could be tied to the meta-level representation.

MCA has already been applied to different engi-neering fields, leading to significant results. Some ofthese results are listed in Table 1.

This section introduces the cooperation opportunitiesmade possible byMCA in the context of design activities.We focus on two general types: cooperation throughcommon combinatorial representation (CCCR), andcooperation based on the relations between the combi-natorial representations (CRCR). The former coopera-tion is demonstrated in the sequel paper throughcooperation between electrical and mechanical engineersand the latter through cooperation between mechanicaland civil engineers, where both are implemented toobtain solutions for design tasks.

3.1 Cooperation through common combinatorialrepresentation—CCCR

CCCR is made possible when designers from differentfields use the same combinatorial representation torepresent their engineering systems. Sharing the samecombinatorial representation opens a channel fortransferring knowledge, methods, and designs from onefield to the other through this common representation.Furthermore, this transfer of knowledge enables utili-zation of the knowledge embedded in the commonrepresentation.

By means of CCCR, engineers can introduce theircolleagues to a method, (either known or new) in thefield of the latter, of which their colleagues are unaware.Consider for example, electrical and mechanical engi-neers working for the same organization. Suppose, themechanical engineer is requested to analyze an indeter-minate truss, an issue that he1 has not dealt with for along time. Usually, he would look for help only from amechanical engineer, but CCCR opens up additionalopportunities, such as cooperating with an electricalengineer by means of resistance graph representation(RGR), as depicted in Fig. 2. Such cooperation is pos-sible since the RGR is the isomorphic representation ofboth electrical circuits and indeterminate trusses (Shai2001b). The electrical engineer may assist his colleagueby applying the ‘‘node method’’ (Balabanian and Bick-art1969) from electrical circuits to the RGR (Shai2001d), expanding it to a multidimensional case using

the knowledge embedded in the RGR. This expansionconcludes in a systematical manner the ‘‘displacementmethod’’ for trusses, which is a known method of solv-ing problems for the mechanical engineer (West 1993).This example demonstrates the first three provisions inSect. 2.

Finally, CCCR enables an electrical and mechanicalengineer to assist their colleagues by dealing with specificdesign tasks. This can be carried out by infusing anexisting design from one field into another through thecommon combinatorial representation. A case study forsuch an infusion is shown in the sequel paper by Shaiand Reich (2004) where a known electronic circuit wastransformed into a mechanical design through acommon combinatorial representation.

3.2 Cooperation through relations betweencombinatorial representations (CRCR)

As explained before, one of the main activities in MCAis to explore the relations between different representa-tions. CRCR suggests sharing knowledge and methodsbetween engineering fields that are represented byinterrelated (and not necessarily isomorphic) combina-torial representations.

One such relation is the duality between the twoCR—potential graph representation (PGR) and flowgraph representation (FGR) (Shai 2001a). Since theformer is used to represent mechanisms and the latter torepresent trusses, infused design employs this relation toestablish cooperation between structural and mechanicalengineers. This issue is outlined in Fig. 3 and will beemployed in the design case appearing in the secondpaper by Shai and Reich (2004).

One of the consequences of CRCR between struc-tural and mechanical engineers is the possibility toinfuse in one field ready-made designs from the other.In the sequel paper, Shai and Reich (2004) present anexample where a structural engineer is required todesign a static system, which amplifies a given exter-nally applied force. Suppose that he is unaware of howto solve the problem and is unable to retrieve theneeded information from the literature. When heemploys infused design a new possibility emerges, sincenow he may deal with the kinematical dual probleminstead by asking for help from his colleagues from themechanical engineering community. This dual kine-matical problem, on the other hand, has well knownand published solutions. What is now left for him is totransform the kinematical system provided by his col-leagues and leap back into the field of structures bybuilding the dual static system.

The above two cooperation doctrines—CCCR andCRCR—are only a part of a variety of ways of coop-eration that are being established on the basis of theproperties in and between combinatorial representa-tions. These types of cooperation together form aframework for convenient and systematic implementa-

1 The terms ‘‘he’’ and ‘‘his’’ may equally refer to ‘‘she’’ and ‘‘her’’or ‘‘they’’ and ‘‘their.’’

97

Table

1Listofachievem

ents

derived

throughMCA

Application

Theidea

behindtheapplication

Specificapplications

References

1.Representingandanalyzingintegrated

engineeringsystem

sSomeofthegraphic

representationswerefound

tobeapplicable

torepresentawidevarietyof

engineeringfields,andthuscapable

of

representingin

aunified

waysystem

sthat

comprise

elem

ents

belongingto

different

engineeringdomains

Analysisofintegratedengineeringsystem

sShai2001b;Shaiand

Rubin

2003

RepresentingandanalyzingMEMS

Shaiet

al.2002;Shai

andRubin

2003

2.System

aticdesignofengineering

system

sGraphrepresentationspavenew

channels

betweendiverse

engineeringdisciplines,

thusenablingtransfer

ofknowndesignsfrom

oneengineeringfieldto

another.In

manycases,

knowndesignsin

theoriginalfield,upon

transform

ation,becomenew

designsin

the

secondary

field.

Knownelectronic

circuitsweretransform

edto

yield

new

mechanism

andstaticsystem

designs

Shai2003b

New

staticsystem

sweredevised

from

known

mechanisms

Shai2002a

Anew

conceptofamicro-m

irrorscanningdevice

thatovercomes

theproblem

ofinter-axialcoupling

wasderived

inasystem

aticwayafter

applyingthe

designtechniques

partiallydescribed

inthepaper

Currentlybeingpatented

3.Findingrelationsbetweendifferent

engineeringfields

Dueto

themathem

aticalrelationsbetween

thegraphrepresentations,new

relationsbetween

engineeringfieldsrepresentedbythem

werederived

Duality

relationbetweentrusses

andmechanisms

Shai2001a;Shai2002a

Duality

relationbetweenStewart

platform

sand

serialrobots

Shai2002b;Shai2003b

Duality

relationbetweengearsystem

sandbeams

Shai2002b;

4.Derivingnew

theoremsandmethods

indifferentengineeringdomains

Engineeringtheoremsandmethodsweretransform

edfrom

oneengineeringfieldto

another

through

therelationsbetweenthegraphrepresentations,

thusyieldingnew

theoremsandmethods

Anew

graphicalmethodforanalyzingtrusses

was

derived

from

theknownvectorresolutionmethod

inmachinetheory

Shai2002a

Amethodfordecompositionoftrusses

tobasic

staticgroupsobtained

from

theAssur

groupmethod

Validitytheorem

intrusses

wasderived

based

ontheconceptofmechanism

mobility

Shai2002a

Anew

methodforanalyzingtrusses

was

derived

from

theWillismethod,

aknownmethodin

planetary

geartrains

ShaiandMohr2004

5.Revealinghidden

properties

of

engineeringsystem

sGraphrepresentationsenable

transform

ingim

plicit

knowledgeto

explicitknowledge.

Properties

that

are

unknown,or‘‘hidden’’,in

oneengineering

system

,becomeclearin

thetransform

edengineering

system

s.

New

typeofforcevariable

wasrevealedin

structures

throughtheduality

relation

ShaiandRubin

2003

Singularconfigurationsofengineeringsystem

s,such

astrusses

androbots

weredetectedbymeans

oftheirdualengineeringsystem

s

Shai2002b;Shai2003a

6.Checkingthevalidityof

engineeringsystem

sProblemswithcheckingthevalidityofengineering

system

sare

transform

edto

problemsofchecking

theform

ationofthecorrespondinggraph

representations

Thisissuehasbeenem

ployed

toestablish

validity

checkingmethodsforengineeringsystem

sbelonging

toanumber

ofengineeringfields,such

as:dynamical

system

s,trusses,planelinkages,planetary

gear

system

sandothers

ShaiandPreiss1999;

Shai2001b

98

tion of infused design principles. The effectiveness of thisframework mainly stems from the following three fac-tors:

1. It has a representation that is more general than otherspecial representations that it integrates

2. Duality or other relations between different repre-sentations are established formally

3. The general representation can be mapped (isomor-phically) into the special representations

4 Infused design

Infused design is a new way of designing. We describe itthrough a sequence of several activities (see Fig. 4):problem formulation, problem modeling and represen-tation, problem solving, and product analysis. Thisdescription is more abstract than specifying the processby design phases such as: need identification, conceptualdesign, and detailed design (e.g., Hubka and Eder 1988;Pahl and Beitz 1984). This sequence may vary and mayiterate in many ways, yet, the essence of using infused

Fig. 2 Implementing CCCR forestablishing new knowledgetransfer channels betweenanalysis methods for structuresand electrical

Fig. 3 Derivation of the dualism relation between static systemsand mechanisms through CRCR

99

design is invariant of the precise process configuration oractivity naming.

4.1 Notation

In order to explain the nature of problem representationin infused design we define a notation. In the notation,

- Capital letters denote sets or classes of problems ormodels

- Small letters denote single items or instances ofclasses

- Superscripts denote different types of models orrepresentations

- Subscripts denote different sub-parts of a system

Problem related notation includes:

- Initial problem information p- Product specification ps

The team possesses a particular disciplinary per-spective D consisting of:

T a set of alternative disciplinary terminologies(e.g., different ways to describe force, rod, con-nection, support, area that are used in structuralengineering)

M the type of the combinatorial representation thatgoverns the creation of a model (some of thesetypes are more common than others within theperspective D)

MP a set of alternative modeling primitives for con-structing systems available in M (e.g., alternativebuilding blocks for modeling a truss as a graphwith force definitions, constraints, etc.)

DK domain knowledge that assists practitioners indeducing properties of models (e.g., equilibriumequations, Hook’s law, compatibility equations,knowledge of truss behavior)

SM various solution methods that solve the models(e.g., stiffness method, flexibility method)

We define the disciplinary perspective to beD?T·MP·DK·SM. With the D perspective, the teamcan use a particular piece of knowledge dk and someprimitives mp to transform the initial probleminformation p into a model m described with a particularterminology t. The model and its terminology are de-noted by the pair (m, t). This pair is called the repre-sentation of the problem. The model of the problem mwould subsequently be solved by some method sm. Weproceed to describe the different infused design activitieswith this notation.

4.2 Problem formulation

Design starts with a written or verbal problem descrip-tion, an abstract idea, or in another unspecified manner.The initial information is limited, uncertain, and illdefined. Problem formulation is a process of creating aproduct specification ps from the initial problem infor-mation p. Problem formulation is quite informal andinvolves (1) making assumptions about the focus of theproblem and the importance of different aspects, (2)information consolidation from diverse structured andunstructured sources, and (3) authoring the specifica-tion.

The product specification ps might include, in addi-tion to its verbal description, drawings, computermodels, physical objects, and other available informa-tion. It could be incomplete or even inconsistent, thusrequiring future revisions.

At this stage, interaction is most valuable. Sharing ofinformation and knowledge emerges from communi-cating different product perspectives resulting fromsubjective viewpoints. A shared language is initiated asthe basis for future interactions. Disciplinary knowledgecan cross boundaries to ease understanding and theevolution of concepts.

In traditional concurrent engineering, problem for-mulation is done collaboratively. Ideally, the designteam creates the product specification together andsubdivides the problem into sub-problems to be handledby different multi-disciplinary teams. The subdivision isoften done to minimize interactions, thus potentialconflicts in subsequent design phases. Techniques suchas the design structure matrix (DSM) (Browning 2001,Eppinger et al. 1994) could be used to attain such a goal.

In addition to present practice and all its availabletools, infused design facilitates information exchange ata deeper level. For example, while discussing the conceptof a beam through a common shared representation,electrical engineers could easily recognize a control sys-tem (see Shai and Reich 2004). For mechanical engi-neers, a control system has a completely differentmeaning than a beam; therefore, such recognition en-riches understanding of concepts, establishing pathwaysfor further elaboration, understanding, and sharing ofproblem concepts. Infused design also provides ways toimprove the problem decomposition by not necessarilyminimizing interactions. We leave this provision to an-other study.

4.3 Problem representation

Problem representation involves creating formaldescriptions or models of problems or sub-problemsfrom the informal description in the product specifica-

Fig. 4 Design process

100

tion with further information elaboration. In traditionalconcurrent engineering, this process is done by practi-tioners working alone or in small groups on their as-signed tasks. Infused design changes this activityradically by allowing integrating rather than disinte-grating the activity, thus, juxtaposing knowledge fromdiverse disciplines to bear on the current problem.

The system being developed can be composed ofmany components j, where j=1,...,m, each with its ownpresent representation i, where i=1,...,n. We denote thecomponent j in its representation i with mi

j; tij

� �: These

indices are independent since one component might haveseveral representations at different times for differentpurposes; furthermore, several components might havethe same representation. Infused design can proceed byintegrating the different components representations

mij; t

ij

� �; j ¼ 1; . . . ;m into subsystems with a single rep-

resentation mnþ1j ; tnþ1

j

� �that could be assembled into

the complete system or product representation

mnþ1; tnþ1� �as shown in Fig. 5. In the figures, the dashed

boxes refer to representations such as RGR (Fig. 2),FGR or PGR (both in Fig. 3), and the solid boxes de-note specific models of the components. The integrationis accomplished by identifying a common representationcomposed of model type and terminology Mnþ1; tnþ1� �that can accommodate all the original representations(Fig. 6). Step (1) in Fig. 5 shows this move from theoriginal representations through intermediate represen-

tations e.g:; Ma; tað Þð Þ to the common representation.

Subsequently, the original models mij; t

ij

� �; j ¼ 1; . . . ;m

are transformed into the common representation

mnþ1j ; tnþ1

j

� �(step 2); and the models can be combined

into the complete system model mnþ1; tnþ1� �(step 3).

To better illustrate step (1), consider the followingexample. Members of the multidisciplinary team start byusing their customary disciplinary model and terminol-ogy for each discipline M1; t1

� �. . . Mn; tnð Þ; e.g., PGR for

mechanisms and FGR for static systems. In order tointegrate all the disciplinary representations they need tosearch for one common representation Mnþ1; tnþ1� �

thataccommodates all the original representations. This

Fig. 5 Transforming diverse representations into a commonrepresentation Fig. 6 Identifying common representation

101

representation must have a known mathematical rela-tion such as duality or generality with the original rep-resentations. This search could be done withoutconsidering the particular problem at hand. It is per-formed following relations found in previous studies.

Finding the path from each representation and ter-minology into the common representation and termi-nology e.g:; M1; t1

� �. . . Ma; tað Þ . . .! Mnþ1; tnþ1� �� �

isthe most critical step as it determines the plan of theprocess (see later in Fig. 7 and in the examples).

For example, consider solving a problem involvingthe integration of a Stewart platform and electrical cir-cuit. The search for a common representation followspreviously discovered relations between representations.Following Table 1 item 3, the Stewart platform partcould be transformed into a serial robots problem;subsequently, this representation could be transformedinto a truss problem represented in a resistance graphrepresentation (RGR), as shown in Fig. 2. At the sametime, the electrical circuit part could be transformed intoRGR as well. Consequently, the search has found RGRto be a suitable common representation that is dual tothe two original representations.

The search might not be trivial since alternative pathsexist and some of them could be promising while othersineffective in that they would not lead to finding onecommon representation. As more relations are discov-ered between different disciplines, the number of candi-dates for each transformation increases, thus creatingmore alternative paths that make it possible to choosethe most suitable path among the various candidates. Asin any domain where multiple paths exist for solving

problems, the solution would be based on expert judg-ment regarding the usefulness of choosing one path overanother.

Given the importance of searching and finding thecommon representation, it is clear that without suchrepresentation, infused design cannot be exercised on agiven problem. By continuing research on the founda-tions of infused design new properties between disci-plines are discovered, leading to many useful results assummarized in Table 1. In addition, while the examplesof transforming between representations discussed hereare based on their duality, there are others relations thatcould be used, for example, the line graph relation be-tween combinatorial representations, and the general-ization relation that exists, for instance, whengeneralizing RGR (resistance graph representation) toresistance matroid representation (Shai 2001c).

4.4 Problem solving and product analysis

In traditional concurrent engineering as in classical engi-neering, problem solving is done by professionals work-ing alone or in small disciplinary teams. In infuseddesign, problem solving could be a collaborative workbetween the engineers directly in charge of the solution toall others whose knowledge could be valuable as recog-nized by MCA. The problem representations or modelsare brought up to the common combinatorial level,where there exist known relations between the combi-natorial representations, such as duality. These relationsenable engineers from different disciplines to raise new

Fig. 7 An abstract model of themethod

102

ideas, solution methods, or known solutions from theirfields to solve the problem.

The common representation Mnþ1; tnþ1� �facilitates

extended communication between the team members.They can now borrow solution or solutions methodsfrom different disciplines.

For example, suppose one of the problems p of onepractitioner is found to be very difficult in his discipline(see Fig. 7). The problem is modeled in m0, a model ofthe model type M0. We can denote this process byp!D m0; clarifying that m0 is created from p by somedisciplinary perspective D. Through the previouslyconstructed common representation Mnþ1; tnþ1� �

(step1), the practitioner transforms the problem model fromm0 to m1 and onwards, while modifying the terminology(step 2), allowing other team members to translate it intothe model m3 described by their disciplinary terminologyt3 (step 3). The team members can now locate designsolutions S3 for the problem. This solution undergoesthe opposite transformation (step 4), resulting in solu-tions to the original problem S0.

4.5 Solution composition

Most real products are composed of parts designedseparately and integrated together. Therefore, solutionsfound to sub-problems must be assembled into acomplete system. In concurrent engineering, the inter-face between subsystems is maintained throughadministrative procedures (e.g., engineering changeprocedures), negotiations, and resolutions. Infused de-sign can change this practice since it also supports thecomplete modeling, design, and analysis of multidisci-plinary systems through the common representationsof the system (mentioned in Sect. 4.3 and Fig. 5)(Reich and Shai2000). This allows a clear under-standing of the influences between subsystems and canapply diverse methods brought from the different dis-ciplines into the common representation as well asmethods intrinsic to the representation to bear on theproblem.

5 Comparing infused design to other approaches

Several aspects underlying infused design relate to well-known topics of contemporary engineering designresearch. The following is a brief literature review onthese topics including ‘design by analogy,’ ‘systematicdesign,’ ‘schematic synthesis,’ and others, that enabledifferentiation of infused design from these approaches.

The new designs obtained by infused design aremathematically isomorphic to already known designs inother engineering fields. This is reminiscent of ‘design byanalogy’ that has attracted many researchers in theengineering design and AI communities.

Balazs and Brown (2000), for example, used analog-ical reasoning for simplifying a design so as to reduce the

computation complexity. A computational theory ofanalogy-based creative design called ‘model basedanalogy’ (MBA) was developed by Goel (1997); he usedmodels to represent explicitly the structural elements ofa device, its topology, and its function. Unlike infuseddesign, where the mathematical foundation of graphtheory and other properties of MCA underlie the pro-cess of deriving the design, the majority of the works ondesign by analogy attempt to simulate the process ofhow designers and engineers arrive at their solutions.Particularly, in this regard, one should mention the workof Gero dealing with situated analogy in design(Kulinski and Gero 2001).

Additional correspondence to infused design anddesign by analogy can be traced in works that also em-ploy topological diagrams and graphs. For example,Borner et al. (1996) created a library of design conceptsthat express topological patterns, and employed the bestmatching algorithm to retrieve an appropriate designcandidate. Another approach that used graphs to restoredesigns was developed by Qian and Gero (Qian 2002)who represented designs in the form of a function-behavior-structure model.

Infused design enables deriving systematically newengineering designs. This systematicity follows from themathematical basis underlying combinatorial represen-tations, which gives rise to deterministic rules for treat-ment of engineering systems. The systematic designapproaches, where the designer proceeds with well-defined steps during the design process, are not new inengineering design. Pahl and Beitz (1988) conducted athorough investigation of all the possible phases of theproduct design process, upon which they developed astructured methodology outlining the design steps to befollowed by an engineer.

Another approach, called TRIZ, for systematic cre-ative design was developed by Altshuller (1988). TRIZ isstudied by many scientists and practiced in industry. Theprinciples of TRIZ were developed upon investigatingthousands of existing inventions and patents.

As before, the difference between infused design andother systematic design methods is the firm mathemati-cal foundation that supports derivation with provableproperties compared to prescriptions that are based oninduction from significant engineering experience.

Infused design is by some means related to the worksemploying schematic description of engineering systemsfor design. Similar to graph representations used here,the schematic description can be seen as an abstractsubstitute of the design. Ulrich and Seering (2002)employed a schematic description describing the topol-ogy of engineering systems to produce new engineeringdesigns. Given a design problem in a form of a functionof input-output relation, they generated initial ‘candi-date’ systems, constructed the corresponding ‘compactdescriptions,’ and applied modifications upon them toadjust the system behavior to the problem requirements.

General design theory (GDT) assures that with suf-ficiently detailed knowledge, a specification can evolve

103

incrementally until it results in an approximate solution(Tomiyama and Yoshikawa 1987; Reich 1995). Thisevolution is performed using models constructed from ameta-model picked from a meta-model set (Tomiyamaet al.1989). However, the decision about which meta-model to choose remains outside the scope of GDT. Intheir subsequent work, Tomiyama and colleagues at-tempted to create a system that would perform or sup-port such an operation by employing logic formalismssuch as abduction; however, the results remained limited(Tomiyama et al.2002). In Braha and Reich (2003), amore general model of synthesis than GDT was pre-sented but it also left the particular knowledge thatdrives the synthesis steps outside the scope of the theory.

In order to allow the use of multiple models, Tom-iyama et al. (2002) proposed to use a common ontologythat also could support the consistency between themodels. This ontology is domain dependent, time con-suming to develop, and error prone. Infused designspecifically shows how methods and solutions could begenerated systematically from corresponding methodsand solutions in other disciplines. It guarantees thecorrectness of results not by using domain dependentontology but by relying on general ontology of systemsthat is embedded in the different representations.

6 Discussion and conclusions

Infused design is a new way of addressing multidisci-plinary product development projects. It allows mem-bers of the development team to exchange knowledge infundamentally different ways than is presently con-ceived. From the present state of sharing project docu-ments or parameters and common language, we expandthe scope of sharing to include a vital exchange ofknowledge consisting of disciplinary concepts, problemformulations, analysis methods, and solutions. Thisexchange crosses and breaks disciplinary boundaries.

Infused design is most beneficial in breakthroughdesign since it enables transferring concepts from onefield to another. It could apply also to variant design bychecking whether we stay with the present concept orlook for a better one in different disciplines. Whetherone chooses to use it depends on the difficulty of theproblem.

Infused design opens avenues for bootstrapping ourunderstanding and supporting various design practicessuch as creative design. The bootstrapping effect comesfrom an interesting and non-trivial phenomenon ofinfused design. When we used infused design to per-form design, we understand the underlying represen-tation better. We can also uncover more properties ofthe representation that, in turn, would improve ourability for analysis. Subsequently, this can lead to yetbetter design ability. We leave the illustration and amore detailed explanation of this phenomenon to afuture study due to its complexity and simply note itsexistence here.

Several questions arise with regard to attaininginfused design in practice. Their answers are stillpreliminary and require more experience with themethod:

1. Can infused design scale to handle large problems?In principle, as was explained in detail in the paper,the mathematical foundation of infused design ismainly graph theory. Graph theory is one of thebranches of discrete mathematics, which is themathematical foundation of computer science. Spe-cifically, the processes described in the paper areamenable for polynomial time computerizations,which would make employing the methodology pos-sible in large-scale systems.In practice, so far, we have experience with small sizeproblems. Practical scalability to larger problems re-quires several things:a. The use of support systems to do the transfor-

mation between representations.b. Exercising careful modeling in which large prob-

lems are decomposed into smaller components.Infused design can apply to the sub-problems aswell as to the integration.

2. How do we weigh the cost of utilizing infused designand its benefits?Engineers are quite adept at managing their resourcesand using them only when needed. Infused design canbe viewed as a resource for addressing complexproblems. These arise, for example, with the need tocompete with existing quality products, or when asolution to a new design problem is unavailable. Insuch circumstances, infused design could provide acompetitive edge whose utilization is inexpensive.

3. How can infused design be taught and at which stu-dent level?We have experience in teaching MCA—the founda-tion of infused design—to high school students withgreat success. High school students were able to usethe method to solve complex problems that wonproject prizes from the Israeli government, academia,and industry (see Shai 2001c). We certainly experi-enced teaching it to undergraduate mechanical engi-neering students. Therefore, we see no obstacle tointroducing infused design into design practice fromthis perspective.

4. How can infused design be embedded in an organi-zation?Even though it is not difficult to teach infused design,there is no need to introduce it into an organization ina comprehensive way. It seems that a reasonableapproach would be to introduce it as part of theinitial stages of a new product development project,when introducing new technologies such as MEMS,or when engaging in new collaborative efforts. Allthese circumstances present serious opportunities forexercising beneficial infused design. The success fromsuch uses would lead other organization members tostudy and use the method as well.

104

5. Does infused design undermine the need for disci-plinary expertise?This might have been a tough issue for infused designif the answer was positive. However, the value ofexpertise does not diminish since we can only transferthe aspects that can be formalized in MCA and notthe presently informalized practical experience that isrooted in context. The informal part of design is assignificant as its formal aspect (Subrahmanian et al.1993a). For example, while infused design cantransfer solutions between disciplines, their quality inone discipline does not guarantee their quality in thesecond discipline. Furthermore, some of the steps ininfused design involve searching in multiple paths orselecting between alternative translations betweenrepresentations. These choices are based on experi-ence and expertise. Moreover, infused design createsnew opportunities for becoming experts, e.g., in theuse of common representations to solve problems.

6. Might practitioners be reluctant to use infuseddesign?Some practitioners might feel that infused design istoo difficult due to the complex mathematical con-cepts involved. We have stated above that theseconcepts can be taught even at the high school level.Others might fear that infused design opens theirknowledge to further review—the introduction ofinfused design forces them also to compete forexcellence with other disciplines in their own field.This is only partially correct but unavoidable.Allowing deep knowledge transfer exposes deficien-cies of existing knowledge. On the positive side,infused design allows experts to demonstrate theirvalue in new disciplines.

7. What is the role of computational support in infuseddesign?The advent of infused design makes information fromseemingly irrelevant disciplines be highly appropriatefor addressing various problems. In order to utilize thisvaluable knowledge properly, information systemscould be used. Furthermore, real projects for whichthese technologies are rewarding are complex andinterdisciplinary, involving multiple teams or organi-zations. The complexity of these projects and the desireto recoup all the opportunities of infused design makeinformation infrastructures central to infused design.The task of the infrastructure is the managing of alltypes of information and knowledge and their com-munication between project participants.Infused design can be supported by informationsystems; however, it is independent of any suchimplementation. Infused design could be carried outin a similar way to CE, based solely on organizationalsupport. Section 4 discussed the process of infuseddesign independent of a support system although it isclear where such systems could fit in. Since thecomplexity of interdisciplinary projects can be over-whelming to handle manually, we regard a suitable

information infrastructure as one of the foundationsof infused design.

Infused design does not address the language problemdiscussed in Sect. 2 directly. It can even be argued that itexacerbates it with additional concepts (e.g., those relatedto MCA). Nevertheless, we have experience teaching theideas to high school and undergraduate students andthe results are promising. As we already mentioned, highschool students, and undergraduate students were able touse infused design successfully to solve engineeringproblems. In addition, although not shown, we feel thatinfused design could possibly bootstrap the creation andevolution of shared language. When interdisciplinaryteam members discuss the naming of concepts and theirmeaning, they could benefit from the wealth of disciplin-ary knowledge they can now share, hence improvingtheir shared basis and understanding.

References

Ahmed A, Wallace KM, Blessing LTM (2004) Understanding thedifferences between how novice and experienced designersapproach design tasks. Res Eng Des (in press)

Akao Y (ed) (1990) Quality function deployment. ProductivityPress, Cambridge, MA

Altshuller G (1988) Creativity as an exact science. (translated byAnthony Williams) Gordon and Breach, New York

Balabanian N, Bickart TA (1969) Electrical network theory. Wiley,New York

Bechkoum K (1997) Intelligent electronic mock-up for concurrentengineering. Expert Syst Appl 12(1):21–35

Balazs ME, Brown DC (2000) Design simplification by analogicalreasoning. In: Proceedings of the KIC-4: fourth IFIP WG 5.2workshop on knowledge intensive CAD, Parma, Italy

Borner K, Coulon CH, Pippig E, Tammer EC (1996) Structuralsimilarity and adaptation. Advances in case-based reasoning.In: Smith I, Faltings B (eds) Proceedings of the third Europeanworkshop on case-based reasoning (EWCBR-96), Springer,Berlin Heidelberg New York, pp 58–75

Boujut J-F, Tiger H (2002) A socio-technical research method foranalyzing and instrumenting the design. J Des Res 2(2)

Bowen J, Bahler D (1992) Frames, quantification, perspectives, andnegotiation in constraint networks for life-cycle engineering.Artif Intell Eng 7(4):199–226

Braha D, Reich Y (2003) Topological structures for modelingengineering design processes. Res Eng Des 14(4):185–199

Browning TR (2001) Applying the design structure matrix to sys-tem decomposition and integration problems: a review and newdirections. IEEE T Eng Manage 48(3):292–306

Clarkson PJ, Hamilton JR (2000) Signposting, a parameter-dri-ven task-based model of the design process. Res Eng Des12:18–38

Coates G, Whitfield RI, Duffy AHB, Hills B (2000) Coordinationapproaches and systems—Part II: an operational perspective.Res Eng Des 12:73–89

Coulter N, Monarch I, Konda S (1998) Software engineering asseen through its research literature: a study in co-word analysis.J Am Soc Inform Syst 49(13):1206–1223

Dutoit A (1996) The role of communication in team-based softwareengineering projects. PhD Thesis, Carnegie Mellon University,Pittsburgh, PA

Eastman C, Jeng TS (1999) A database supporting evolutionaryproduct model development for design. Automat Constr 8:305–323

105

Eppinger SD, Whitney DE, Smith RS, Gebala DA (1994) A model-based method for organizing tasks in product development. ResEng Des 6:1–13

Erkes JW, Kenny KB, Lewis JW, Sarachan BD, Soboiewski MW,Sun JRN (1996) Implementing shared manufacturing serviceson the world-wide web. Commun ACM 39(2):34–45

Finger S, Konda S, Subrahmanian E (1995) Concurrent designhappens at the interfaces. AI EDAM 9(2):89–99

Garrod S (1998) How groups co-ordinate their concepts and ter-minology: Implications for medical informatics. MethodInform Med 37(4–5):471–476

Goel A (1988) Design, analogy and creativity. IEEE Expert12(3):62–70

Hubka V, Eder WE (1988) Theory of technical systems: a totalconcept theory for engineering design. Springer, Berlin Hei-delberg New York

Konda S, Monarch I, Sargent P, Subrahmanian E (1992) Sharedmemory in design: a unifying theme for research and practice.Res Eng Des 4(1):23–42

Kulinski J, Gero JS (2001) Constructive representation in situatedanalogy in design. In: de Vries B, van Leeuwen J, Achten H(eds) CAADFutures 2001, Kluwer, Dordrecht, pp 507–520

Marcovici M (1999) Efficient mechanical rectifier. US PatentNumber 5,931,062

McMahon CA, Xianyi M (1996) A network approach to para-metric design integration. Res Eng Des 8:14–32

Messac A, Chen W (2000) The engineering design discipline: is itsconfounding lexicon hindering its evolution? J Eng Eval CostAnal 3:67–83

Minneman S, Leifer L (1993) Group engineering design practice:the social construction of a technical reality. Proceedings of theinternational conference on engineering design (ICED’93), TheHague, Netherlands, pp 301–310

Neches R, Fikes RE, Finin T, Gruber TR, Senator T, SwartoutWR (1991) Enabling technology for knowledge sharing. AIMag 12(3):36–56

Pahl G, Beitz W (1988) Engineering design: a systematic approach.In: Wallace K (ed) The design council. Springer, Berlin Hei-delberg New York

Park H, Cutkosky MR, Conru AB, Lee S-H (1994) An agent basedapproach to concurrent cable harness design. AI EDAM8(1):46–61

Prasad B (1996) Concurrent engineering fundamentals, vol I:integrated product and process organization. Prentice Hall,New Jersey

Qian L (2002) Creative design by analogy. In: Chakrabarti A (ed)Engineering design synthesis—– understanding, approachesand tools. Springer Berlin Heidelberg New York, pp 245–269

Reich Y (1995) A critical review of general design theory. Res EngDes 7:1–18

Reich Y (2000) Improving design rationale capture with QFD. EngComput 16(3–4):236–252

Reich Y, Shai O (2000) MEMSIS—A MEMS information system.In: Shpitalni M (ed) Proceedings of CIRP design seminar,Haifa, Israel, pp 193–197

Reich Y, Subrahmanian E (1992) Concurrent engineering: anextended view. Proceedings of the AID’92 workshop on con-current engineering, Kluwer, Netherlands

Reich Y, Konda S, Levy SN, Monarch I, Subrahmanian E (1993)New roles for machine learning in design. Artif Intell Eng8(3):165–181

Reich Y, Konda S, Levy SN, Monarch I, Subrahmanian E (1996)Varieties and issues of participation and design. Des Studies17(2):165–180

Reich Y, Subrahmanian E, Cunningham D, Dutoit A, Konda SL,Patrick R, Westerberg AW, The n-dim group (1999) Buildingagility for developing agile design information systems. Res EngDes 11(2):67–83

Sargent P, Subrahmanian E, Downs M, et al. (1992) Materials’information and conceptual data modeling. In: Barry TI,Reynard KW (eds) Computerization and networking of mate-

rials databases: third volume. ASTM STP 1140, AmericanSociety For Testing and Materials

Schrage M (1991) Shared minds: the new technologies of collabo-ration. Random House, New York

Shai O (2001a) The duality relation between mechanisms andtrusses. Mech Mach Theory 36(3):343–369

Shai O (2001b) The multidisciplinary combinatorial approach andits applications in engineering. AI EDAM 15(2):109–144

Shai O (2001c) Combinatorial representations in structural analy-sis. Comput Civil Eng 15(3):193–207

Shai O (2001d) Deriving structural theorems and methods usingTellegen’s theorem and combinatorial representations. IntJ Solids Struct 38:8037–8052

Shai O (2002a) Utilization of the dualism between determinatetrusses and mechanisms. Mechan Mach Theory 37(11):1307–1323

Shai O (2002b) Duality between statical and kinematical engi-neering systems. The sixth international conference on com-putational structures technology, Prague, Czech Republic, 4–6September

Shai O (2003a) Transforming engineering problems through graphrepresentations. Adv Eng Inf 17(2):77–93

Shai O (2003b) Design through common graph representations. In:ASME Design Engineering Technical Conferences, Chicago,2–6 September

Shai O, Mohr E (2004) Transforming engineering knowledgethrough graph representations: transferring the Willis methodto linkages and trusses. Eng Comput 20(1): 2–10

Shai O, Preiss K (1999) Isomorphic representations and well-formedness of engineering systems. Eng Comput 15:303–314

Shai O, Reich Y (2004) Infused design: practice. Res Eng Des (inpress)

Shai O, Rubin D (2003) Representing and analyzing integratedengineering systems through combinatorial representations.Eng Comput 19(4):221–232

Shai O, Eliahou-Niv S, Rubin D, Slavutin M, Andrusier A (2002)Multidimensional graph representations for MEMS and theirapplications. ISRAMEMS—the 1st national conference of theIsraeli MOEMS society, Haifa, Israel, 21 October

Steward DV (1981) The design structure system: a method formanaging the design of complex systems. IEEE T Eng Manage28:71–74

Subrahmanian E (1991) Notes on empirical studies of engineeringtasks and environments. Invited position paper in NSF work-shop on information capture and access in engineering envi-ronments., Ithaca, NY, pp 567–578

Subrahmanian E, Konda SL, Levy SN, Reich Y, Westerberg AW,Monarch IA (1993a) Equations aren’t enough: informal mod-eling in design. AI EDAM 7(4):257–274

Subrahmanian E, Coyne R, Konda SL, Levy SN, Martin R,Monarch IA, Reich Y, Westerberg AW (1993b) Support systemfor different-time different-place collaboration for concurrentengineering. Proceedings of the 2nd IEEE workshop on en-abling technologies infrastructure for collaborative enterprises(WET ICE), Los Alamitos, CA, IEEE Computer Society Press,pp 187–191

Subrahmanian E, Reich Y, Konda SL, Dutoit A, Cunnungham D,Patrick R, Thomas M, Westerberg AW (1997) The n-dimapproach to building design support systems. Proceedings ofASME design theory and methodology DTM ‘97, ASME, NewYork

Tomiyama T, Yoshikawa H (1987) Extended general design theory.In: Yoshikawa H, Warman EA (eds) Design theory for CAD.North-Holland, Amsterdam, pp 95–130

Tomiyama T, Kiriyama T, Takeda H, Xue D, Yoshikawa H (1989)Metamodel: a key to intelligent CAD systems. Res Eng Des1(1):19–34

Tomiyama T, Yoshioka M, Tsumaya A (2002) A knowledgeoperation model of synthesis. In: Chakrabarti A (ed) Engi-neering design synthesis—understanding, approaches and tools.Springer, Berlin Heidelberg New York, pp 67–90

106

Ulrich KT, Seering WP (2002) Synthesis of schematic descriptionsin mechanical design. In: Chakrabarti A (ed) Engineering de-sign synthesis—understanding, approaches and tools. Springer,Berlin Heidelberg New York, pp 153–177

Walton GF (1991) Concurrent engineering. Special feature of IEEEspectrum, July 1991

West HH (1993) Fundamentals of structural analysis. Wiley, NewYork

Whitfield RI, Coates G, Duffy AHB, Hills B (2000) Coordinationapproaches and systems—part I: a strategic perspective. ResEng Des 12:48–60

107