concurrent engineering · concurrent engineering doi: 10.1177/1063293x09102251 concurrent...
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