concurrent engineering · concurrent engineering doi: 10.1177/1063293x09102251 concurrent...

16
http://cer.sagepub.com Concurrent Engineering DOI: 10.1177/1063293X09102251 2009; 17; 5 Concurrent Engineering Jitesh H. Panchal, Marco Gero Fernández, Christiaan J. J. Paredis, Janet K. Allen and Farrokh Mistree A Modular Decision-centric Approach for Reusable Design Processes http://cer.sagepub.com/cgi/content/abstract/17/1/5 The online version of this article can be found at: Published by: http://www.sagepublications.com can be found at: Concurrent Engineering Additional services and information for http://cer.sagepub.com/cgi/alerts Email Alerts: http://cer.sagepub.com/subscriptions Subscriptions: http://www.sagepub.com/journalsReprints.nav Reprints: http://www.sagepub.co.uk/journalsPermissions.nav Permissions: http://cer.sagepub.com/cgi/content/refs/17/1/5 Citations at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.com Downloaded from

Upload: others

Post on 22-Mar-2020

21 views

Category:

Documents


0 download

TRANSCRIPT

http://cer.sagepub.com

Concurrent Engineering

DOI: 10.1177/1063293X09102251 2009; 17; 5 Concurrent Engineering

Jitesh H. Panchal, Marco Gero Fernández, Christiaan J. J. Paredis, Janet K. Allen and Farrokh Mistree A Modular Decision-centric Approach for Reusable Design Processes

http://cer.sagepub.com/cgi/content/abstract/17/1/5 The online version of this article can be found at:

Published by:

http://www.sagepublications.com

can be found at:Concurrent Engineering Additional services and information for

http://cer.sagepub.com/cgi/alerts Email Alerts:

http://cer.sagepub.com/subscriptions Subscriptions:

http://www.sagepub.com/journalsReprints.navReprints:

http://www.sagepub.co.uk/journalsPermissions.navPermissions:

http://cer.sagepub.com/cgi/content/refs/17/1/5 Citations

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

CONCURRENT ENGINEERING: Research and Applications

A Modular Decision-centric Approach for Reusable Design Processes

Jitesh H. Panchal, Marco Gero Fernandez, Christiaan J. J. Paredis,Janet K. Allen and Farrokh Mistree*

Systems Realization Laboratory, Woodruff School of Mechanical Engineering

Georgia Institute of Technology, Atlanta, GA 31322, USA

Abstract: The reusability of design processes modeled in existing Product Lifecycle Management (PLM) and Computer Aided Engineering

(CAE) frameworks has been limited to the level of flow charts or activity-based diagrams that serve as planning and organizational aids. Current

simulation-based design frameworks provide limited support for reuse of design processes at a level where design processes are networks of

computational operations, specifically the capabilities to reuse (a) design processes for different products, and (b) collaborative design

strategies. In this article, we address these limitations by providing a modeling approach for simulation-based design processes so that they

can be archived in a generic modular fashion and reused for collaborative design of different products. The proposed approach is based on four

foundations: (a) modeling design processes as hierarchical systems, (b) separation of declarative and procedural information, (c) modeling

design processes as decision-centric activities, and (d) modeling interactions between decision makers using game theoretic protocols. These

four fundamentals of the approach are instantiated in the form of generic computational templates for products, processes, decisions, and

pertinent interfaces. The approach is illustrated using a proof of concept implementation in ModelCenter. The implementation is validated by

showing the reusability of design processes for two different products, a spring and a pressure vessel, in individual and collaborative design

scenarios. The approach has potential for supporting reusability of broader PLM processes.

Key Words: design processes, templates, reusability, decision-centric design, modularity, collaboration.

1. Frame of Reference – Reusability of DesignProcesses

As engineering enterprises become increasingly con-cerned with meeting the dynamic requirements of aglobal marketplace, closer attention must necessarily bepaid to reusing the knowledge associated with themechanisms underlying product development. Perhapsthe most crucial of these mechanisms is the designprocess. In terms of an engineering enterprise, thistranslates to the need for a systematic means of reusingdesign processes and the associated design knowledge.It has been argued that design processes play animportant role in Product Lifecycle Management(PLM), which is defined as ‘a strategic approachto creating and managing a company’s product-relatedintellectual capital, from its initial conception toretirement’ [1]. Although much attention has been paidto addressing this issue by exploiting the reusability andscalability of products through product platform andproduct family design, not much attention has been paidto the reusability of an engineering enterprise’s primaryintellectual capital – the design process [2].

The extent of reusability of design processes dependssignificantly on the level of abstraction at which it isdefined. To understand the reusability of designprocesses, it is important to identify different levels ofdesign processes. Design processes are categorized byPanchal and co-authors [3] into various levels (Figure 1)– business process level, inter-organizational designlevel, design methodology level, analysis executionlevel, and computing resource management level.At the highest level of abstraction (Level 5), businessprocesses are essentially defined as informationexchanges between different business units. PLMapplications such as TeamCenter [4], SMARTEAM [5],and Windchill [6] capture design processes at this levelas exchanges of files between different entities. At thelowest level of abstraction (Level 1), processes arecomposed of information processing steps as requiredto execute any single analysis.

At the intermediate levels (Levels 2–4) design pro-cesses consist of strategies for exploring the designspace in order to achieve desired product functionality.The emphasis at these levels is on utilizing simulation-based tools to analyze the product’s behavior inconjunction with design exploration tools such asdesign of experiments, response surface modeling,optimization, etc. Processes at these levels arecaptured in terms of parameter flows by applicationssuch as FIPER [7], ModelCenter [8], and iSIGHT [9].

*Author to whom correspondence should be addressed.E-mail: [email protected] 1–3 and 6–8 appear in color online: http://cer.sagepub.com

Volume 17 Number 1 March 2009 51063-293X/09/01 0005–15 $10.00/0 DOI: 10.1177/1063293X09102251

� SAGE Publications 2009

Los Angeles, London, New Delhi and Singapore

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

These applications allow for modeling design processesin terms of various simulation codes and the requiredparameter flows between them. These parameter flowsare generally specific to the problem at hand and theproduct to be designed. These tools do not supportmodeling design processes in a generic form that can beapplied to diverse design scenarios. Hence, at a designmethodology and analysis execution level, the reusa-bility of design processes modeled using currentlyavailable tools is rather limited. In this paper, we focuson reusability at the design methodology and analysisexecution level, specifically the reusability of(a) computational design processes across differentproducts and (b) collaborative multidisciplinary designstrategies.Reusability of design processes across different

products: Consider a simple example involving thedesign of two commonly employed mechanical compo-nents, namely, a pressure vessel and a spring. Bothproducts are different with regard to design parameters,requirements, and design constraints. Nevertheless, ageneral design process that is equally applicable to boththese products can still be defined at a computationallevel. An example of such a generic process involvesconstraint evaluation, analysis, goal evaluationand objective function evaluation. A common drivergoverns the optimization process, yet the process shownin the figure is sufficiently generic to be utilized fora parametric design of both a helical spring and apressure vessel.Such a design processes can currently be modeled in

applications such as FIPER, iSIGHT, and ModelCenterpredominantly as a progression of parameter flows

between successive tasks, as exemplified by theModelCenter implementation of the design process forthe pressure vessel in Figure 2. These parameter flows areinherently defined in terms of product-specific informa-tion such as design variables, parameters, responsevariables, etc. In the pressure vessel example, thesevariables are length, radius, thickness, etc. While chan-ging numeric values required for parametric design of asingle product is supported in current design processes,changing variables, underlying information flows, andtools, for a different product’s design (such as that ofa spring) is not possible without remodeling the processas a whole. Designers are forced to model the designprocesses in both a product-specific and tool-specificmanner and hence, these underlying processes cannot bereused directly from one problem to another. In otherwords modular reuse of design process components is notfeasible. This is the first requirement for a design processmodeling approach – the ability to reuse genericcomputational processes across different products.

Reusability of collaborative design strategies: Variouscomputational design strategies have been developed inthe multi-disciplinary design and optimization literature.Examples of such strategies include collaborativeoptimization [10], target cascading [11], Bi-LevelIntegrated System Synthesis (BLISS) [12], decentralizedsequential iterative decision-making [13], etc. Thefocus in these strategies is on efficient exploration ofdesign spaces via the decomposition of a complexdesign problem into sub-problems that are handled bydifferent designers. Each of these strategies advocates aspecific flow of information between the sub-problems.It is important to note that these strategies are

Georgia Institute of Technology Woodruff School of Mech. Engineering1

Levels of Abstraction in Design Processes

1. Computing Resources Management Level

2. Analysis Execution Level

3. Design Methodology Level

4. Inter-Organizational Design Level

5. Business Process Level

Applications

Figure 1. Applications addressing different levels of abstraction of design processes [3].

6 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

applicable to a general design problem and designersshould be able to capture these strategies as reusableprocesses at a computational level. However as men-tioned before, due to the rigid link between the processesand the product information, these strategies cannot bestored and reused as generic processes within currentlyavailable frameworks. This highlights the secondrequirement for a design process modeling approach –ability to reuse collaborative design strategies.

In this paper, we propose an approach to address theserequirements by adopting a systems-based view of designprocesses and modeling design problems and solutionprocedures independently. The approach is discussed indetail in Section 2. The design problems are modeledfrom a decision-centric perspective wherein each designprocess can be considered to be a network of decisions;it is in terms of decisions that we model the problem-solving aspect of design. The required generic aspects ofthe solution procedure are captured by defining tem-plates that can be executed, analyzed, stored, and reused,regardless of context, engineering domain, or scale of theproduct considered. Collaborative design processes aresimilarly modeled using decisions made by multipleinteracting designers. The interactions between designersare modeled by specific interface protocols. An instan-tiation of the proposed approach in the form ofcomputational templates is presented in Section 3 anda proof-of-concept implementation in the ModelCenterframework is presented in Section 4. The reusabilityof generic design processes is shown using simpledesign examples, that despite being rather simplein nature, nevertheless constitute a convenient meansof illustrating the approach. Closing thoughts arepresented in Section 5.

2. Systems-based Modeling of Decision-centricDesign Processes

The proposed approach to support design processreuse at a computational level is based on fourfoundations: (a) Modeling design processes as hierarch-ical systems, (b) Separation of declarative from proce-dural information to enhance reusability of designprocesses, (c) Viewing design as a decision-centricactivity, and (d) Modeling interactions between deci-sion-makers using game theoretic protocols. Thesefoundations are discussed next.

2.1 The Hierarchical Systems View of DesignProcesses

Our design process modeling strategy is based onthe premise that processes are hierarchical systems thatcan be progressively decomposed into sub-processes,which in turn can be represented in terms of basic designprocess building blocks, i.e., information transforma-tions. Hence, design processes are viewed as networksof said information transformations. These informationtransformations include decisions, abstraction, composi-tion, decomposition, mapping, evaluation, and refine-ment, which are discussed in more detail in Ref. [14].Each of these transformations is associated withan input product state, an output product state, anda design sub-process (which again is a network ofinformation transformations) for its execution. Theseinputs, outputs, transformations, and design processesare related as shown in Figure 3 and represent coreelements to this perspective. As shown in the figure,information related to formulating the transformations

Pressure vessel weight goal

Pressure vessel constraints

Constraint values

Z

d1−

Combined deviation functiond2−

Pressure vessel volume goal

Pressure vessel analysis

Optimizer

Radiuslengththickness

Lengthradiusthickness

Volume

Weight

Figure 2. Design process for pressure vessel in model center.

Modular Decision-centric Approach 7

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

(declarative information) and solving them (proceduralinformation) is clearly separated. The details of thisseparation are discussed in Section 2.2.The design-related information is captured in the

form of computational templates. Separate templatesare developed for design processes, transformations(e.g., decisions), product information, and interfacesbetween transformations. The details of these fourtemplate types are provided in Section 3. Each ofthese templates is defined generically. The product-specific templates only contain information regardingproduct parameters, constraints, relationships betweenform and behavior, etc. A design process template isdefined in terms of a network of information flowsamong tasks. The generic (product independent) processtemplates can be instantiated by populating product-specific information (such as product-specific para-meters, constraints, analysis codes, etc) from the producttemplate into the design process template. The designprocess templates can be executed only after theirinstantiation using the product information. Thus,a single generic process template can be instantiatedfor different products. It is the product-specific informa-tion that serves as the only differentiator amonginstantiated templates for designing different products;the underlying structure remains the same. Havingoutlined the modular systems-based perspectiveespoused in this research, we proceed to discuss theconcept of separating declarative and procedural infor-mation in Section 2.2.

2.2 Separation of Declarative from ProceduralInformation

As discussed in Section 1, the primary reason for thelack of support for design process reuse in ComputerAided Engineering (CAE) and PLM frameworks isthat current tools such as FIPER, ModelCenter, andiSIGHT capture process information in a manner that istightly integrated with the information, specific to theproduct at hand. Hence, it is not possible to reusedifferent process definitions in product design. Currentlyavailable information models and design support toolsforce designers to think in terms of the underlyingprocedure for solving a particular problem rather thanconceptualizing and declaring the problem itself. Hence,in developing the computational templates, we separatethe representation of problem formulation related(declarative) information and process execution specific(procedural) information. The information associatedwith design transformations and the product states isdeclarative information because it refers to what isdone by the designer via that transformation.Declarative information thus captures all the pieces ofinformation/knowledge and the associated relationshipsamong them that represent the transformation to becarried out. Hence, the templates associated with (a)design transformations, and (b) product information arereferred to as declarative templates. The mechanics ofhow that information transformation is carried outconstitutes the procedural information; transformation

Product state (i) Product state (i+1)

Design transformation

Design process

Product template(declarative)

Transformation template(declarative)

Process template (Procedural)

Hie

rarc

hH

iera

rchy

Product state Product state

Designtransformation

Design process

Product state Product state

Designtransformation

Design process

Time

Figure 3. Hierarchical view of design processes.

8 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

details are rendered and executed via a network of tasks.After the designers have declared their design problem,it can be executed using many different processes.The templates associated with design processes andinterfaces between decisions are procedural templates.Declarative templates capture information and relation-ships between information. There is no informationabout the sequence in which information is eithergenerated or used. On the contrary, proceduraltemplates define the sequence of steps through whichinformation is processed.

The idea of separating declarative from proceduralinformation is analogous to understanding the behaviorof a system that is represented by a set of linearequations. The first step for understanding the systembehavior is formulating (declaring) all the equations thatcorrespond to the information/knowledge availableto designers. In our approach, these equations areanalogous to the problem formulation and are modeledusing declarative templates. Once the equations havebeen formulated, the next step is to select a process to beused for solving those equations simultaneously.Various algorithms (that correspond to the processesfor solving the equations) such as Cramer’s rule,Gaussian elimination, LU decomposition, the Jacobimethod, etc are available for solving such a set of linearequations. These algorithms for solving systems ofequations are analogous to design processes and arecaptured using procedural templates. One of theadvantages inherent in separating declarative andprocedural information is that this scheme forcesdesigners to focus on design problem formulationbefore considering the details of the solution. This isimportant because without appropriately formulatingthe design problem, the designers are likely to incurpenalties associated with inefficient iteration and costlyredesign. A further advantage is that the reusability ofdesign processes for solving different kinds of designproblems is enhanced. The separation of declarative andprocedural information is based on the assumptionthat models for design transformations are available.The design transformations can be developed fromvarious different views of design. In this paper, weadvocate adopting a decision-centric view of design as abasis to model key design transformations. The detailsof this view are discussed in Section 2.3.

2.3 Decision-centric View of Design Processes

The decision-centric view of design addresses thelimitations of the model-centric and tool-centricviews discussed in Section 1. From a decision-centricperspective, the emphasis is on modeling designprocesses as networks of decisions. According tomany researchers such as Hazelrigg [15], Muster andMistree [16], and Thurston [17] the fundamental premise

of decision-based design is that engineering designis primarily a decision-making process. Specificadvantages of adopting a decision-centric perspectiveinclude the ease with which both model-centric and tool-centric views are generated. Furthermore, domainindependent representation of design processes becomesfeasible. Hazelrigg describes decision-based design asomni-disciplinary, ‘the seed that glues together theheretofore disparate engineering disciplines as well aseconomics, marketing, business, operations research,probability theory, optimization and others’ [15].Herrmann and Schmidt [18] describe a complete productdevelopment organization as a network of decision-makers who use and create information to develop aproduct. Although principles of decision-based designhave been accepted in design theory research, theyhave not been implemented in design frameworks.Current tools do not capture information related todesigners’ decisions; the decision-related information iscaptured in the form of meta-data (if at all). In thisarticle, we use decision-centric design to model thebuilding blocks of design processes in the form ofdecision problems.

The underlying need for reusability of informationrelated to design processes necessitates representinginformation in a domain neutral form that supportsdesigners in providing and structuring required inform-ation content in a reusable fashion. This in turn calls fora domain independent means of capturing designinformation. In order to facilitate designer interactions,required for effective collaboration from a decision-based perspective, expression of information related todesign decisions in a standardized format is alsorequired. Such a standardized form for representinginformation is provided by the Decision SupportProblem (DSP) technique proposed by Mistree andco-authors [19–22], specifically the compromiseDecision Support Problem (cDSP) [23]. In the DSPtechnique, support for human judgment in designingis offered through the formulation and solution ofDSPs, which provide a means for modeling decisionsencountered in design. The cDSP formulation consistsof four key steps – (a) given, (b) find, (c) satisfy, and(d) minimize. In the ‘given’ step the informationavailable to designers for decision-making, whichincludes the available simulation models that generateinformation about the system’s behavior and adesigners’ preferences, is captured. In the ‘find’ step ofthe cDSP, information about the design variables thatdesigners can control in order to satisfy the designobjectives is captured. The information about boundson design variables, any problem constraints, and thedesign goals is captured in the ‘satisfy’ step of the cDSP.The overall objective function, framed in terms ofdeviation from target, to be minimized is captured inthe final step.

Modular Decision-centric Approach 9

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

Since the keywords and descriptors are domainindependent, they represent a common structure (or aconceptual schema) for DSPs from any domain. Thisis one of the most important characteristics of theDSP technique that enables reuse of design informationacross domains. In summary, decision-based design ischosen as a framework here because of its (a) domainindependence (decisions are common across differentengineering domains), (b) design phase independence(the structure of decisions remain the same during anyphase of the design process), and (c) ability to be usedfor modeling processes at other levels defined in Figure 1in terms of design decisions. Having discussed theconstructs for modeling individual design decisions,we present the game theoretic protocols for modelinginteractions between decision-makers in Section 2.4.

2.4 Game Theoretic Protocols for CollaborativeDesign

In this article, we have chosen to embody bothcooperative and noncooperative game theoretic proto-cols in the pursuit of conflicting objectives, subject to acommon set of constraints. Game theory is defined as atheory of competition stated in terms of gains and lossesamong opposing players or a mathematical method ofdecision-making in which a competitive situation isanalyzed to determine the optimal course of action foran interested party [24]. Von Neumann and Morgensternare credited with introducing the subject of game theoryin their book The Theory of Games and EconomicBehavior [25] in which they also provide theirtreatment on the subject of decision theory in terms ofutility.Lewis and Mistree [26] model the strategic relation-

ships among designers sharing a common design spaceusing game theoretic principles and identify ParetoCooperation, Nash Non-Cooperation, and StackelbergLeader/Follower as the three game theoretic protocolsmost representative of the interactions required fordecentralized design.

(a) Pareto Cooperation is employed to represent cen-tralized decision-making, where all required infor-mation is available to every collaborating designer.A Pareto optimal solution is achieved when nosingle designer can improve his or her performancewithout negatively affecting that of another.In this scenario, designers have full accessto the information about each other’s decision-making process including their cDSPs, andassociated engineering tools. The Pareto coopera-tion scenario is solved by combining all designers’cDSPs.

(b) Nash Non-Cooperation refers to decentralized deci-sion processes where designers have to make

decisions in isolation due to organizational barriers,time schedules, and geographical constraints.Its mathematical models are suitable for formulatingdecisions in collaborative design [27]. In NashNon-Cooperative protocols, decision-makers formu-late Rational Reaction Sets (RRS) or Best ReplyCorrespondences (BRC). A RRS is a mapping(either a mathematical or a fitted function) thatrelates the values of design variables under adesigner’s control to values of design variablescontrolled by other stakeholders. The NashNoncooperative solution to the coupled, decentra-lized decision-making problem is the point ofintersection of the RRSs pertaining to the differentdesigners. The resulting Nash equilibrium to thedesign problem has the characteristic that nodesigner can unilaterally improve his/her objectivefunction [28].

(c) Stackelberg Leader/Follower protocols are imple-mented to model sequential decision-making pro-cesses where the ‘leader’ makes his or her decision,based on the assumption that the ‘follower’ willbehave rationally. The follower then makes his orher decision within the constraints emanating fromthe leader’s choice. In this scenario, the leaderconstructs a RRS by predicting the follower’sreactions and makes decisions by using this RRSinto the leader’s cDSP. This is an effective way tosolve the collaboration problems in the case wherethere is a dominant design objective that must besatisfied.

Having discussed the game-theoretic protocolsas means for modeling interactions between designdecisions, we now present the templates for modelingdesign information.

3. Templates for Modeling Design Information

In this section, we present the templates for (a)Product information (Section 3.1), (b) Decision probleminformation (Section 3.2), (c) Process information(Section 3.3), and (d) Interface information (Section3.4). The templates for products and decision problemsare declarative templates, whereas the process andinterface templates are procedural templates.

3.1 Templates for Product Information

The information specific to the product beingdesigned includes aspects related to the product’sform, function, and behavior and the relationshipsbetween them. Since this information is treated in aprocess independent manner, it can be used forpopulating any design process template. The product

10 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

template is derived from the Core Product Model(CPM) proposed by Fenves [29]. The key aspect ofthis information model is an entity. A product iscomposed of many such entities. Each entity, in turn,is composed of various sub-entities and is defined by anumber of attributes. Each attribute can be either oftype form or type behavior. Form attributes combinetogether to represent the form of an entity, whereasbehavioral entities taken together represent the behaviorof that entity.

Entities are abstractions of reality. These can beabstract concepts such as elements in Finite ElementModels, boundary conditions, etc. Hence, the producthierarchy does not necessarily correspond to the part/subpart (assembly) hierarchy. The hierarchy representsa design perspective that the designer is interested in.The abstract nature of the entities allows us to viewattributes as special types of entities. Since the productinformation is defined by the designers based on theirrespective perspectives of design, different designers maymodel the same product in an entirely different manner.Relations can be of two types – entity-inherent relation-ships and external relationships. Entity inherentrelationships are the relationships between the sub-entities of the entity under consideration. Externalrelationships are the relationships of an entity withother entities. The behavioral model is a special type ofentity-inherent relationship. The relationships maybe given by simple mathematical equations or complexsoftware codes. For example, the relationshipbetween form and behavior is often captured by analysiscodes.

3.2 Templates for Decision Information

The templates for design decisions are based on thecDSP construct presented in Section 2.3. The keycomponents of decision templates include information

about design variables, responses, parameters, con-straints, goals, preferences, and objectives. An informa-tion model for Decision Support Problems is shown inFigure 4. The topmost entity is the Decision Problem.This decision problem contains all the declarativeinformation related to a Decision Support Problem.The decision problem consists of four importantelements – design space, response space, problemconstraints, and preferences. Design space is definedby all the design variables that can be controlledby designers. Response space is defined by all theparameters that constitute the behavior space; theseparameters have targets based on the mapping betweencustomer requirements and engineering specificationsassociated with them. Both the design variables andresponse variables are special types of attributes,described in the schema for the product model inSection 3.1. It is important to note that the relationshipbetween design variables and response variables is notdefined in the problem description, but is defined inthe product-specific information model. This separationof information is important for reusability as discussedin Section 1.

The constraint component of the problem definitiononly captures the constraints that are due to the mannerin which the problem is defined. Product-specificconstraints are captured as relationships in the productmodel. The preference part of the information modelcaptures how much a designer values different outcomesin a manner that can be mathematically evaluated.These preferences can be captured in different mathe-matical forms – Archimedean, pre-emptive, or usingutility functions. In the Archimedean formulation,different goals are assigned weights and the overallobjective function value is evaluated by taking theweighted sum of individual goals. In the pre-emptiveformulation, different levels of objective functions aredefined and satisfied in order from highest to lowest.

Driver

Decision problem

Design space Response space Problem constraints Preference Utility based preference

Attribute

Design variable Response variable

Constraint

Archemedian preference

Preemptive preference

Goal

Inequality constraint Equality constraint

Figure 4. Information model for decision problems.

Modular Decision-centric Approach 11

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

Using the utility-based preference representation,preference values can be defined to vary with thevalue of each goal. In addition to these entities, thereis a driver that captures the information about theoptimization algorithm used for executing the decisionproblem.The information associated with the decision

problems for the design of a helical spring and apressure vessel is shown in Figure 5. Notice thesimilarity in structure between the design problems.This similarity is due to the standardization of decisiontemplates, independent of product templates.Furthermore, in this formulation, nothing is coupledto a process for execution.

3.3 Templates for Process Information

In the context of simulation-based design, theactivities in a design process are computational tasks.Each activity has a set of inputs and outputs.The manner in which outputs of one activity aremodified to serve as inputs to another activity is referredto as an interface between the two activities. Interfacesare used to perform functions such as the formatting andparsing of data. The process model also capturesinformation regarding the sequence in which activitiesare performed. The information model used for captur-ing process information is discussed by Panchal andco-authors [14].We recognize that the information models presented

in this paper are relatively simple and defined at a high

level of abstraction. However, the focus in this article ison the overall approach. More comprehensive informa-tion models can be substituted to enrich the semantics ofthe information models presented.

3.4 Templates for Interface Information

Interface templates serve as domain-independentcommunications protocols for regulating the way inwhich experts (operating in different functionaldomains) share information for effective collaboration.An interface in a design process separates or partitionsmultiple dependent or interdependent designers andtheir respective design activities. Interface templatesserve as means for connecting decision templates to oneanother in a computer interpretable manner. The natureof the collaboration between designers determines theform of the interface. Appropriate interface templatesare developed based upon the underlying infor-mational dependencies between the decision-makers.Consequently, the interactions between decision-makerscan be easily adapted by changing the interface tem-plate, while reusing the same problem formulations.Since the decision templates and their instantiationremains the same, the designers still control the for-mulation of their own decisions. The required level ofmodularity is maintained via the developmentof domain-independent interface templates thatare distinct from the decision templates being linked.The information flow between the design decisionsis computationally modeled and executed by an

Inputs

Minimize volume

Maximize volume

Weight

Volume weighting factor = 0.5

Weight weighting factor = 0.5

Volume target = 500,000 m^3

Weight target = 300 kg

Density, strength, pressure

Radius, length, thickness

Stress:

SpringPressure vesselcDSP “Chips”

W(R,T,L)= pr (R +T )3 (R +T )2L+ −43–

8D3Nd4G

k =

14

V p 2Dd2 (N + 2) =

8 ≥1.1d FD3Nd 4G

=

H = Ngd ≤ 0.5

PR−St ≤ 0T5T−R ≤ 0

R +T− 40 ≤ 0 L + 2R + 2T − 150 ≤ 0

Goal

Preferences

Variables

Parameters

Constraints

Response

Objective

Analysis

Driver

OutputsOutputs Inputs

Maximize stiffness

Minimize

Stiffness weighting factor = 0.5Volume weighting factor = 0.5

Stiffness target = lbf/inVolume target = in^3

Applied force, coil diameter, shearmodulus

Number of coils, wire diameter

Minimum deflection:

Maximum solid height:

Thickness:

Radius:

Length:

Stiffness,volume

Wire diameter,coil diameter,shear modulus,number of coils

Volume, weightRadius, length, thickness,density, strength, pressure

Design variable values – radius,length, thicknessobjective function value - Z

Design variable values – radius, length, thicknessobjective function value - Z

Optimization algorithm – exhaustivesearch, SQP, etc.

Optimization algorithm – exhaustive search, SQP, etc.

43–V(R,L) = p R3+ R2L

43–R3+ R2L

Figure 5. Declarative information associated with cDSPs for pressure vessel and spring design.

12 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

interface template that captures the chosen gametheoretic protocols, such as the iterative noncooperativetechniques and other noncooperative as well as coop-erative instantiations discussed in Section 2.4.

Noncooperative games represent a type of interface,where there is no communication between the stake-holders during the decision-making process. They areemployed to model the solution of strongly coupleddecisions, characterized by interdependent informationflows, and are characteristic of decentralized designprocesses where designers are required to tackle designsub-problems in isolation, due to organizational barriers,time schedules, and geographical constraints. The non-cooperative protocol is represented as an interfacetemplate between decision templates (Figure 6).Decision-makers generate a strategy or Best ReplyCorrespondence (BRC), which represents how theywould respond given a range of possible responses fromanother stakeholder. Response Surface Methodology isused to construct the BRCs. An intersection is soughtbetween these designers’ respective BRCs, and a solutioncan be selected from the resulting intersection.

Cooperative games, on the other hand, are idealscenarios in which either stakeholders, or players, havefull access to the information about each other’sdecision-making process. They are employed to repre-sent centralized decision-making, where all requiredinformation is available to every collaborating designer.The interface template for a cooperative gametheoretic protocol essentially combines informationabout design variables, constraints, parameters, goals,preferences and objective functions into a single cDSPwithout altering the form of the templates being joined.

In addition to the decision formulation, the analysismodels are combined accordingly. This combined cDSPis solved to result in a Pareto optimal solution. Notethat the interface template is procedural in nature.The approach presented in Section 2 and the templatesdiscussed in this section are generally applicable to anyCAE and PLM design framework. We illustratethe fundamental ideas behind this approach usinga proof-of-concept implementation in ModelCenter.Even though the implementation is simple, it providesinsight into the advantages of the key principlesembodied in this approach. The implementation isdiscussed in Section 4.

4. Implementation of the Proposed Approach inthe ModelCenter Framework

The approach presented in Section 2 is implementedfor two scenarios: (a) single decision and (b) multipledecisions. The first scenario is based on the assumptionthat a single designer formulates the design problem asa compromise decision and executes a process formaking this decision. In the second scenario, multipledesigners are involved in making design decisions abouta product. Each designer formulates his/her decisionusing the cDSP construct; the required interactionbetween these decisions is modeled using game theoreticprotocols as discussed in Section 2.4. The first scenariois used to illustrate the approach for reusability of designprocesses for different products (Section 1), whereas thesecond example is used to demonstrate the reusability oftemplates in collaborative design scenarios.

Interface

Goals

Preferences

Variables

Parameters

Constraints

Response

Objective

Analysis

Driver

Response

Goals

Preferences

Variables

Parameters

Constraints

ResponseResponse

Objective

Analysis

Driver

cDSP A

cDSP B

ResponseResponse

ResponseResponse

BRC(ResponseSurface)

VariablesVariables

VariablesVariables

BRC(Response

surface)

IntersectionInterection SolutionSolution

Figure 6. The noncooperative game protocol modeled as a set of decision templates and an interface template.

Modular Decision-centric Approach 13

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

4.1 Single Decision Scenario – Reusability ofDesign Processes for Different Products

In order to increase reusability of information,we separate the information pertaining to design problem(decision), product, and generic design processin ModelCenter [8], developed by Phoenix IntegrationInc. These three components are captured separatelyas templates. The declarative templates for problem-decision- and product-specific information are modeledin XML. The procedural templates for the elements ofgeneric design processes are modeled using JavaBeansand the design process is defined via generic informationflows between these elements. The design problemis defined in terms of the cDSP construct. The elementsof cDSP and the design processes defined as informationflows between these elements remain the same forthe design of either a spring or a pressure vessel asshown in Figure 7. Furthermore, required informationflows between these elements are generic and indepen-dent of the product being designed. Examplesof information flows between the analysis module andconstraints evaluation include the problem name,an array of input names (i.e., design variables), and anarray of input values. The flows remain the sameregardless of the product for which the process is used.Here, the information flows relevant for the solution ofa cDSP, remain invariant, regardless of whether theproduct being designed is a pressure vessel or a spring.Each of the process elements defined in JavaBeans

interacts with the product information templates

discussed in Section 3.1 and decision templates discussedin Section 3.2. Notice that the product and decisiontemplates presented in Section 3 can be used forreasonably complex design scenarios. However, inorder to maintain the simplicity of the implementation,the templates are embodied as a set of XML schemas.XML is used in this paper because it offers aconvenient means of capturing information and issupported by ModelCenter. The JavaBeans associatedwith process elements, discussed earlier in thissection, parse required information from appropriateXML files corresponding to product and decisioninformation and subsequently make this informationavailable for processing in ModelCenter. Hence, theactual variable names, constraints, their values etc. areall extracted from the product and decision templates.

For the simple example problem of designing botha pressure vessel and a helical spring through the use ofa common design process, the problem informationis stored in four XML files: the problem definition XML,the constraints XML, the goals and preferences XML,and the analysis code XML. These templates correspondto the declarative (problem-specific) information.The XML files associated with these templates areprovided in Figure 8. For brevity, the XML filerepresentation associated with the problem definitiontemplate is not shown in this paper. The sum total ofthese XML files constitutes the decision template.In the current implementation, the analysis codes forsimulating the behavior of both the spring and thepressure vessel are written in Visual Basic, although any

Declarative decision representation

Executable procedures

Util

izat

ion

of in

form

atio

n in

gen

eric

pro

cessXML definition of decision

XML definition of variables

XML definition of preferences

XML definition of constraints

XML definition of analysis

XML definition of driver

XML definition of response

Generic process

Process element definedin JavaBeans

Variable nameslower and upper bounds

Pro

blem

nam

eva

riabl

e na

mes

Problem nameinput namesinput values

Evaluated constraint

values

Problem nameoutput namesoutput values

cls problem definition Generic optimizer

Cls constraint model center

cDSP analysis model center

cls goals and preferences model center

Figure 7. Proof-of-concept implementation in ModelCenter.

14 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

other model wrapped as a ModelCenter componentcould be employed instead.

Note that the structure of the XML files isindependent of the problem (spring or pressurevessel) being addressed. The generic XML files areinstantiated using the product-specific information(see Figure 8 for XML files corresponding to thepressure vessel). As shown in Figure 7, the informa-tion from XML files is extracted by the generic designprocess elements (developed as JavaBeans) to result inan executable design process. In order to changethe product from a pressure vessel to a spring, thedesigners only need to change the XML files thatdeclare the specific variables, constraints, goals,analysis, etc. In fact, it is via XML file replacementthat the generic processes can be instantiated readilyfor different products. The process defined inModelCenter remains the same because it parsesthe XML files to extract problem-specific information.This is a primary advantage of the proposedapproach. The proposed architecture separatesthe design process definition from the problem-specific information, and hence ensures reusability of

the design processes being modeled for differentproducts, satisfying the first requirement discussedSection 1.

4.2 Execution of Multiple Decisions – Reusabilityof Collaboration Strategies using GameTheory

It is assumed here for demonstration purposes thattwo designers (e.g., Designers A and B) are collaborat-ing in the design of a pressure vessel. In this effort,Designer A’s goal is to minimize the overall weightof the vessel, while Designer B is in pursuit ofthe maximum attainable volume. Both designers aresubjected to the same set of constraints, but are incontrol of a different set of design variables. Specifically,Designer A has control over radius R and length L,while Designer B controls thickness T. The gametheoretic interface templates discussed in Section 3.4are used as domain-independent communicationsprotocols for regulating the way in which experts(operating in different functional domains) shareinformation for effective collaboration. The individual

<Constraints><Constraint>

<Name>Length Constraint</Name><Definition>Strngth-

(Pressure*Radius)/Thick</Definition></Constraint><Constraint>

<Name>Radius Constraint</Name><Definition>Radius-5*Thick</Definition>

</Constraint><Constraint>

<Name>ThickConstraint</Name><Definition>40-Radius-Thick</Definition>

</Constraint><Constraint>

<Name>Stress Constraint </Name><Definition>150-Length-2*Radius-

2*Thick</Definition></Constraint>

</Constraints>

<GoalsAndPreferences><Goal>

<Name>Volume</Name><Weight>0.5</Weight><Target>500000</Target><Monotonicity>Increasing</Monotonicity>

</Goal><Goal>

<Name>Weight</Name><Weight>0.5</Weight><Target>300</Target><Monotonicity>Decreasing</Monotonicity>

</Goal></GoalsAndPreference>

(a) Constraints (b) Goals and preferences<Analysis>

<Inputs><Input><Name>Radius </Name><Type>double</Type><Unit>m</Unit><Value>1.0</Value></Input><Input><Name>Length</Name><Type>double</Type><Unit>m</Unit><Value>2.0</Value></Input><Input><Name>Thick </Name><Type>double</Type><Unit>m</Unit><Value>3.0</Value></Input><Input><Name>Density</Name><Type>double</Type><Unit>kg/m3</Unit><Value>4.0</Value></Input><Input><Name>Strngth</Name><Type>double</Type><Unit>kN/m2</Unit><Value>3.9</Value></Input><Input><Name>Pressure</Name><Type>double</Type><Unit>N/m2</Unit><Value>100</Value></Input>

</Inputs><Outputs>

<Output><Name>Volume </Name><Type>double</Type><Unit>m3</Unit><Value>765054.72</Value></Output><Output><Name>Weight </Name><Type>double</Type><Unit>kg</Unit><Value>6845.18796333332</Value>

</Outputs><Execute>E:\PressureVesselAnalysisCommandLine.exe</Execute>

</Analysis>

(c) Analysis

</Output>

Figure 8. XML files for elements of a design decision modeled using cDSP.

Modular Decision-centric Approach 15

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

decisions are modeled using the compromise DSPtemplates as discussed in Section 4.1 for single decisionscenarios. Since the process defined in ModelCenter isgeneric, the process definition is directly reused fordefining the individual design processes of designersA and B. Only the XML files associated with theproblem definitions of the two designers are replaced.The information flow between decisions is genericallymodeled using the interface templates. The proceduralinterface templates between designers are embodied asJavaBeans in ModelCenter.Since the interface templates are also generic and can

be instantiated for any product, they can be replacedwhile keeping the same formulation of design decisions.Hence, the designers can explore the impact of differentinterfaces on the final design. This also allows designersto change control of design variables. This flexibilityis a significant advantage from the standpoint ofreconfiguring design processes and addresses thesecond requirement presented in Section 1, namely theability to reuse collaborative design strategies.The communication or interaction protocols currently

instantiated within the interface template are thoseof cooperative and noncooperative behavior. Asevidenced in Table 1, the nature of the interactionprotocol used to structure the collaboration amongthe interacting decision-makers has a significant effecton the outcome attained. The best outcome (i.e.,objective function, Z¼ 0.4958) is obtained for fullcooperation, while there is a significant spread inobjective values obtained for noncooperative behavior,ranging from Z¼ 0.4976 to Z¼ 0.9077. In fact, thefully cooperative outcome among the two interactingdecision-makers, each in pursuit of their own objectives,matches that obtained for a single decision-maker.In the case of noncooperative behavior it is clearthat the results obtained are directly affected bydecision-maker precedence and design variable control.While in this particular case, the average effect of

precedence and control on the objective value obtainedis almost the same (i.e., Z¼ 0.2446 and Z¼ 0.2396,respectively), the comparative significance of theseeffects is problem-specific and depends directly on thespecifics of the particular problem at hand – constraints,design variable sensitivities, etc.

As illustrated at the hand of the pressure vessel designproblem, explored for two collaborating decision-makers with regard to (1) use of interaction protocol,(2) order of precedence, and (3) control over designvariables in this section, the design process can havea significant effect on the outcome obtained. This isespecially true in light of continuously evolving informa-tion content. It is our objective to provide a consistentmeans of interfacing collaborating decision-makers,whose design sub-problems are modeled in a consistentfashion. Using the modeling approach presented in thispaper, it becomes possible to explore different designprocess scenarios and effectively leverage an engineeringenterprise’s intellectual capital [30].

5. Conclusions

In this article, we address two aspects of lack ofreusability of the current CAE and PLM frameworks:(a) reusability of computational design processes acrossdifferent products, and (b) reusability of collaborativedesign strategies. To mitigate these limitations, wepresent a modular, decision-centric, template-basedapproach for modeling design information. The funda-mental differences between the proposed approach andother commonly available approaches are that in theproposed approach: (a) design processes are modeledas hierarchical systems; (b) declarative and proceduralmodels are effectively separated in the form oftemplates; (c) design processes are viewed as decision-making processes; and (d) interactions betweendesigners are modeled using game theoretic protocols.

Table 1. Effects of (1) interaction protocol, (2) order of precedence, and (3) design variable control on design processoutcome.

Cooperative Noncooperative

SingledesignercontrolsR, L, T

A(WGT) controls T;B(VOL) controls R,LA(WGT) precedingB(VOL)

A(WGT) controls R, L;B(VOL) controls TA(WGT) precedingB(VOL)

A(WGT) controls R, L;B(VOL) controls T,B(VOL) precedingA(WGT)

A(WGT) controls T;B(VOL) controls R, L;B(VOL) precedingA(WGT)

Radius 4.45 10.40 2.50 9.95 4.45Length 62.40 126.80 117.20 0.10 140.00Thickness 0.50 1.16 0.50 1.99 0.50Weight 299.91 3367.85 299.88 851.01 624.01Volume 4249.00 47773.55 2345.47 4155.27 9074.11Z (Weight) – 0.9109 0.0000 0.6475 0.5192Z (Volume) – 0.9045 0.9953 0.9917 0.9819Objective

value (Z)0.4958 0.9077 0.4976 0.8196 0.7505

16 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

These four fundamentals of the approach are instan-tiated in the form of generic computational templatesfor products, processes, decisions, and interfaces. Theproposed templates are computer interpretable, allowingfor the execution, and reuse/reconfiguration of designprocesses and any of their components. A modular,generic formulation of the process required for thesolution of design decisions defined as compromiseDSPs is conceived and presented. Consequently, itis possible to effectively model design processes andsub-processes, regardless of functional domain orcomplexity. The approach has been formalized and theresulting approach implemented in ModelCenter, asshown in Section 4. The instantiation is validated fortwo examples (i.e., pressure vessel and spring design) inorder to show the reusability of the generic process(Section 4.1). This addresses the first limitation of theexisting frameworks. Finally, to address the secondlimitation, game theoretic collaborative design strategiesare implemented as interaction templates and shown viathe integration of interacting decision-makers sharingresponsibility for the design of the pressure vessel(Section 4.2).

The principal advantage of this modeling technique isthe enhanced reusability of information and knowledgeachieved via the separation of information pertaining toproblem formulation, process, product, and interfacesbetween decision-makers. In this article, the proposedapproach is only demonstrated for computationaldesign processes in the later stages of design. While itis possible to formulate templates, at least structurally,even in the early stages of design, the information, andknowledge gained by exercising the resulting modelsbecomes more concrete as the design matures.The advantage of relying on completely modulartemplates is the provision of a consistent meansof capturing and exploiting knowledge that reflectsevolving information content throughout the designprocess. We believe that the proposed approach is astepping-stone towards top–down design of designprocesses based upon and aided by reliance on existingdesign process knowledge. The ability to rely upon arepository of design process building blocks will greatlyfacilitate the original, adaptive, derivative, and variantdesign of products and serve as a springboard for theeffective evolution of product portfolios by engineeringenterprise.

Acknowledgments

We acknowledge the support from National ScienceFoundation grants DMI-0085136 and DMI-0100123,as well as, Air Force Office of Scientific Researchgrant F49620-03-1-0348. During this research, MarcoGero Fernandez was sponsored by a National

Science Foundation IGERT Fellowship through theTI:GER Program (NSF IGERT-0221600) at theGeorgia Tech College of Management and aPresident’s Fellowship from the Georgia Institute ofTechnology.

References

1. IBM (2004). IBM Solutions, http://www-1.ibm.com/businesscenter/us/solutions/solutionarea.jsp?id¼9351.

2. Panchal, J.H., Fernandez, M.G., Paredis, C.J.J., Allen,J.K. and Mistree, F. (2004). Designing Design Processes inProduct Lifecycle Management: Research Issues andStrategies, In: ASME 2004 Computers and Information inEngineering Conference, Salt Lake City, Utah, No.DETC2004/CIE-57742.

3. Panchal, J.H., Vrinat, M. and Brown, D.H. (2004). Designand Simulation Frameworks, Collaborative ProductDevelopment Associates, LLC, Report No: 041001.

4. UGS (2006). Teamcenter 2005, http://www.ugs.com/products/teamcenter/.

5. IBM (2006). ENOVIA SmarTeam, http://www-306.ibm.com/software/applications/plm/smarteam/.

6. PTC (2003). PTC Windchill, http://www.ptc.com/products/windchill/.

7. Engineous Inc. (2005). FIPER Infrastructure, http://www.engineous.com/product_FIPERInfrastructure.htm.

8. Phoenix Integration Inc. (2004). ModelCenter�,Version 5.0, http://www.phoenix-int.com/products/ModelCenter.html.

9. Engineous Inc. (2004). iSIGHT, Version 8.0, http://www.engineous.com/product_iSIGHT.htm.

10. Kroo, I. and Manning, V. (2000). CollaborativeOptimization: Status and Directions, In: 8th AIAA/NASA/ISSMO Symposium on Multidisciplinary Analysisand Optimization, Long Beach CA, No. AIAA-2000-4721.

11. Kim, H.M., Michelena, N.F., Papalambros, P.Y. andJiang, T. (2003). Target Cascading in Optimal SystemDesign, Journal of Mechanical Design, 125: 481–489.

12. Sobieszczanski-Sobieski, J., Agte, J. and Sandusky, J.R.R.(1998). Bi-level Integrated System Synthesis (BLISS),NASA, Report No: NASA-98-tm208715.

13. Androulakis, I.P. and Reklaitis, G.V. (1999). Approachesto Asynchronous Decentralized Decision Making,Computers and Chemical Engineering, 23(3): 341–355.

14. Panchal, J.H., Fernandez, M.G., Allen, J.K., Paredis,C.J.J. and Mistree, F. (2005). Facilitating Meta-design viaSeparation of Problem, Product, and Process Information,In: 2005 ASME International Mechanical EngineeringCongress and Exposition, Orlando, Florida, USA, No.IMECE2005-80013.

15. Hazelrigg, G.A. (1998). A Framework for Decision-basedEngineering Design, Journal of Mechanical Design, 120(4):653–658.

16. Muster, D. and Mistree, F. (1988). The Decision SupportProblem Technique in Engineering Design, InternationalJournal of Applied Engineering Education, 4(1): 23–33.

17. Thurston, D.L. (1999). Real and Perceived Limitations toDecision Based Design, In: ASME DETC, Design Theoryand Methodology, Las Vegas, NV, USA, No. DETC99/DTM-8750.

Modular Decision-centric Approach 17

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

18. Herrmann, J.W. and Schmidt, L.C. (2002). ViewingProduct Development as a Decision Production System,In: ASME 2002 Design Theory and MethodologyConference, Montreal, Canada, No. DETC2002-DTM34030.

19. Mistree, F., Muster, D., Shupe, J.A. and Allen, J.K.(1989). A Decision-based Perspective for the Design ofMethods for Systems Design, In: Recent Experiences inMultidisciplinary Analysis and Optimization, Hampton,Virginia, No. NASA CP 3031.

20. Bras, B.A. and Mistree, F. (1991). Designing DesignProcesses in Decision-based Concurrent Engineering,SAE Transactions, Journal of Materials & Manufacturing(SAE Paper 912209), SAE International, Warrendale,Pennsylvania, 100: 451–458.

21. Kamal, S.Z., Karandikar, H.M., Mistree, F.and Muster, D. (1987). Knowledge Representationfor Discipline-independent Decision Making,In: Gero, J. (ed.), Expert Systems in Computer-aidedDesign, pp. 289–321, Amsterdam: Elsevier SciencePublishers 2B.V.

22. Mistree, F., Smith, W.F., Bras, B.A., Allen, J.K. andMuster, D. (1990). Decision-based Design: AContemporary Paradigm in Ship Design, Transactions,Society of Naval Architects and Marine Engineers, 98:565–597.

23. Mistree, F., Hughes, O.F. and Bras, B.A. (1993).The Compromise Decision Support Problem andthe Adaptive Linear Programming Algorithm,In: Kamat, M.P. (ed.), Structural Optimization: Statusand Promise, pp. 247–286, Washington, DC: AIAA.

24. The American Heritage Dictionary (1994). HoughtonMifflin Co (Trd).

25. Von Neumann, J. and Morgenstern, O. (1947). The Theoryof Games and Economic Behavior, Princeton, NJ: PrincetonUniversity Press.

26. Lewis, K. and Mistree, F. (1997). Modeling Interaction inMultidisciplinary Design: A Game Theoretic Approach,AIAA Journal, 35(8): 1387–1392.

27. Hernandez, G., Seepersad, C.C., Allen, J. and Mistree, F.(2002). A Method for Interactive Decision-making inCollaborative, Distributed Engineering Design,International Journal of Agile Manufacturing Systems,5(2): 47–65.

28. Thompson, G.L. (1953). Signaling Strategies in n-PersonGames, In: Kuhn, H.W. and Tucker, A.W. (eds),Contributions to the Theory of Games, Vol. II (Annals ofMathematics Studies, 28), pp. 267–277, Princeton:Princeton University Press.

29. Fenves, S.J. (2001). A Core Product Model forRepresenting Design Information, NIST. Report No:NISTIR Report 6736.

30. Panchal, J.H., Fernandez, M.G., Paredis, C.J.J.,Allen, J.K. and Mistree, F. (2007). LeveragingDesign Process Related Intellectual Capital – A Keyto Enhancing Enterprise Agility, In: Li, W., Ong, S.,Nee, A. and McMahon, C. (eds), CollaborativeProduct Design & Manufacturing Methodologies andApplications, pp. 211–244, Springer-Verlag, London.

Christiaan J. J. Paredis

Dr Paredis is an AssociateProfessor in the G.W.Woodruff School ofMechanical Engineering atGeorgia Tech. He received hisMS degree in MechanicalEngineering from the CatholicUniversity of Leuven(Belgium) in 1988, and hisMS and PhD in Electricaland Computer Engineeringfrom Carnegie Mellon

University in 1990 and 1996, respectively. From 1996to 2002, he was a Research Scientist at the Institute forComplex Engineered Systems at Carnegie MellonUniversity. Dr. Paredis has a broad, multidisciplinarybackground. In his research, he combines aspects ofinformation technology, simulation, and systems theoryto support the design of mechatronic systems, focusingin particular on decision-making under uncertainty inconceptual design. In these areas, he has published morethan 80 refereed journal articles and conference papers.Dr. Paredis received the 2007 CETL/BP Junior FacultyTeaching Excellence Award and the 2007 SAE Ralph R.Teetor Educational Award. In 2007–2008, he was theChair of the ASME Computers and Information inEngineering (CIE) Division.

Jitesh H. Panchal

Dr Jitesh H. Panchal is anAssistant Professor at theSchool of Mechanical andMaterials Engineering atWashington State University.He received his Bachelor ofTechnology from IndianInstitute of Technology atGuwahati, and MS and PhDin Mechanical Engineeringfrom Georgia Institute ofTechnology. His research

interests are in the field of Engineering SystemsDesign. Specifically, his current research focus is onsimulation-based distributed design methodologies andtechnologies for multiscale systems. Dr. Panchal is amember of American Society of Mechanical Engineers(ASME) and American Institute of Aeronautics andAstronautics (AIAA).

18 J. H. PANCHAL ET AL.

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from

Marco Gero Fernandez

Marco Gero Fernandezreceived his PhD in MechanicalEngineering from theGeorgeW.Woodruff School of MechanicalEngineering at the GeorgiaInstitute of Technology in2005. As a graduate student,he was a National ScienceFoundation Research Fellow,a National Science FoundationIntegrative GraduateEducation and Research

Traineeship Program Fellow, and a Georgia TechPresidential Fellow. He received a BSE from DukeUniversity in 1999, an MS from the Georgia Instituteof Technology in 2002, and an MBA from theCollege of Management at the Georgia Institute ofTechnology in 2006. He was a member of theSystems Realization Laboratory from 1999 to 2006 andcurrently works in Business Transformation Consultingfor the Consulting Services Practice of CapgeminiConsulting.

Farrokh Mistree

Professor Farrokh Mistree’sdesign experience spansmechan-ical, aeronautical, structural,and industrial engineering. Histeaching experience spanscourses in engineering design,naval architecture, solidmechanics, operations research,and computer science. His cur-rent research focus is on learn-ing how to manage designfreedom in multiscale design

(from molecular to reduced order models) to facilitatethe integrated design of materials, product, and design

process chains. And what does Farrokh Mistree want todo in the future? He wants to have fun–fun in defining theemerging science-based discipline of design. Fun inproviding an opportunity for highly motivated andtalented people to learn how to achieve their dreams.

Janet K. Allen

Professor Allen’s research is inthe area of systems design ofcomplex, multiscale productsespecially the design of inte-grated products and materials.She has a long-standing inter-est in robust design and under-standing the effects ofuncertainty in simulation-based design. Dr Allen is aprofessor in the George W.Woodruff School of

Mechanical Engineering at Georgia Tech and a Fellowof ASME. Dr Allen received her PhD from theUniversity of California, Berkeley and her SB from theMassachusetts Institute of Technology, she hasauthored more than 200 technical publications.

Modular Decision-centric Approach 19

at WASHINGTON STATE UNIVERSITY on March 5, 2009 http://cer.sagepub.comDownloaded from