special issue paper 547 modelling an ongoing …...modelling an ongoing design process utilizing...

Modelling an ongoing design process utilizingtop-down and bottom-up design strategiesM Fathianathan1* and J H Panchal2

1Georgia Institute of Technology, Savannah, Georgia, USA2School of Mechanical and Materials Engineering, Washington State University, Pullman, Washington, USA

The manuscript was received on 24 April 2008 and was accepted after revision for publication on 26 September 2008.

DOI: 10.1243/09544054JEM1208

Abstract: The product design process plays a central role in ensuring that new products arerealized with improved quality, in a short lead-time and with costs kept to a minimum. It isidentified that making decisions dynamically on how the design process should proceed is nottrivial. A computational environment that aids dynamic decision making on the design processwould be useful in ensuring successful design of new products. A key component of analysingand making decisions on the progression of the design process is a model that captures anongoing design process. In this paper, an approach to modelling an ongoing design process isproposed based on the use of design nodes. The approach allows an ongoing design process tobe modelled that facilitates dynamic decision making on how the design process should pro-gress and accounts for the state of the design problem. The approach allows top-down andbottom-up design strategies to be modelled.

Keywords: design process modelling, design process design, design nodes, top-down,bottom-up

1 INTRODUCTION

The design and development of successful new pro-ducts is imperative to the economic well-being of aproduct development company. Intense global com-petition is forcing companies to design and developnew products with not only improved quality but alsoas rapidly as possible while keeping costs to a mini-mum. In this competitive environment, the productrealization process is of central importance. The pro-cess that companies adopt to realize new productsand how they manage this process plays a critical rolein the success of the company [1]. Simon [2] pointsout that ‘. . . design process strategies can affect notonly the efficiency with which resources for designingare used, but also the nature of final design as well’.Appropriately structured design processes not onlycan improve the performance of a single productbut also the evolution of the entire product line.

Hence, the design of design processes is an essentialingredient for the strategic development of productsto ensure sustained competitiveness of an organiza-tion. The design of design processes involves thesystematic analysis and synthesis of the process thata company adopts to design a product [3–5].

In working with companies from several industrialsectors, including medical devices and consumerproducts involved in the design of new products, ithas been found that making decisions on how thedesign process should proceed is not trivial even forfairly simple products. Examples of such design pro-cess decisions are given below.

1. Should the designers gather additional informa-tion about the problem?

2. Should the design problem be decomposedfurther [6]?

3. Should the designers pursue novel designs orutilize existing concepts to satisfy the designrequirements?

4. Should more alternatives be generated or shouldthe designer select from the available alternatives?

5. Should the design of a particular subsystem becarried out in-house or should it be outsourced?

*Corresponding author: Georgia Institute of Technology, 210

Technology Circle, Savannah, Georgia 31407, USA. email:

[email protected]

JEM1208 � IMechE 2009 Proc. IMechE Vol. 223 Part B: J. Engineering Manufacture

SPECIAL ISSUE PAPER 547

These decisions are referred to as the ‘design pro-cess related decisions’. These decisions on how thedesign process should proceed are different from thedecisions about the product parameters (such as thematerials, shapes, dimensions, etc.). The design pro-cess decisions have important consequences on theability of the final product to meet requirements, thelead time to design and manufacture the product,and the cost of the product. Further, the difficulty ofdeciding on the progression of the design processincreases with the increasing complexity of the pro-duct. Deciding on how the design process proceeds isalso difficult because these cannot be completelydescribed a priori. Downstream activities are sig-nificantly dependent on the information generatedby upstream activities and the associated level ofuncertainty is consistently high. This problem thatcompanies face in making decisions on how thedesign process should proceed has motivated thepresent work in developing a computational envir-onment for systematic analysis and decision makingon the design process. A key component of analysingand making decisions on the progression of thedesign process is a model that captures an ongoingdesign process and facilitates analysis of and decisionmaking about the design process. In this paper, anapproach to model ongoing design processes is pro-posed based on the use of what is referred to as‘design nodes’. It is proposed that a design node is ajuncture in the design process where it is determinedhow the design process should proceed, whileaccounting for the structure of the design problemand design process alternatives. Two design strate-gies, top-down and bottom-up, are modelled in theapproach. The approach is evaluated through theapplication of the approach to an industrial case

study. Initial efforts on modelling design processesusing design nodes are presented in reference [7].

The rest of this paper is organized as follows. Insection 2, a review of the literature on modellingdesign processes is provided. In section 3, the ele-mental constructs in defining design nodes arepresented. In section 4, design nodes for modellingdesign processes are discussed. The use of designnodes in modelling a design process is discussed insection 5. Finally, an example is presented in section 6and closing comments are presented in section 7.

2 RELATED RESEARCH

Approaches for modelling design processes can becategorized by the manner in which design is viewedas a process. Some of these views characterize designprocesses as series of activities, decisions, evolvingfunctions, sets of transformations, search processes,etc. The resulting representation of design processesis directly dependent on the view of the design pro-cess chosen. A summary of these approaches isprovided in Table 1 and a discussion follows.

2.1 Activity-based view of design processes

The design process, when viewed as a set of activities,can be subjected to organizational or schedulinganalysis. Graph-based andmatrix-basedmethods canbe used to represent these processes. The graph-based techniques use activity-net-based networks[15–17], which are the earliest and most widely usedtechniques for modelling processes. These activity-net-based models are instantiated in two distinctrepresentations, namely activity-on-node (AoN) andactivity-on-arc (AoA). AoN representations are more

Table 1 Process modelling efforts in the design literature

Process modelling effort View of design Modelling, analysis objective Basic units of a process

Design structure matrix [8] Activity/task based Organizational decisions, risk,complexity, probability ofrework, iterations, etc.

Tasks

Shimomura et al. [9] Functional evolution Capture design process,designers’ intentions, tracedesign processes

Functional realization, functionaloperation, functional evaluation

Ullman [10] Evolution of product states Process representation Abstraction, refinement,decomposition, patchingcombination, combination

Maimon and Braha [11] Knowledge manipulation throughanalysis–synthesis–evaluation

Development of a mathematicaltheory for design

Artefact space, specifications,analysis, synthesis, evaluation

Maher [12] Knowledge manipulation Development of knowledge-based systems

Decomposition, case-basedreasoning, transformation

Gorti et al. [13] Development of engineeringknowledge base

Goal, plan, specification, decisionand context

Decision supportproblem technique [14]

Decision-based design Modelling, analysing, debugging,finding inconsistencies in adesign process

Phases, events, decisions, tasks,information

Proc. IMechE Vol. 223 Part B: J. Engineering Manufacture JEM1208 � IMechE 2009

548 M Fathianathan and J H Panchal

applicable when the precedence of activities isknown, whereas AoA representations are used whengraphical identification and visualization of processevents is important. Each of these models is thus usedas a means of analysing and comparing the com-plexity of processes – performing risk-based analysison aspects such as the expected time required fordifferent tasks and obtaining a critical path.

The design structure matrix (DSM) [8, 18] is apopular means for representing both products andprocesses. Through the DSM, hierarchical structuresof both products and processes can be captured. Themain advantage of using the DSM is the ability toidentify both interactions and iterations in a designprocess. Browning and Eppinger [19] use the DSM tomodel process architectures as sets of activities andtheir patterns of interaction. The DSM is used for avariety of analyses including cost, schedule, risk,trade-off, probability of rework, level of interaction,complexity, iteration, and process improvement [20].

2.2 Functional-evolution-based view of designprocesses

Shimomura et al. [9] portray design as a process offunctional evolution. Function is an essential aspectof design process because design refers to achievingthe desired function of a product [21]. Design isrepresented as a process in which a representation ofa design object, which includes function, is graduallyrefined over time. The representation of the designobject is based on the function–behaviour–structure(FBS) [22] model. Each functional evolution involvesfunctional realization (i.e. converting the functioninto a structure), functional evaluation (i.e. confirm-ing a functional description with behaviour) andfunctional operation (i.e. adding functional elementsand functional relations to a functional description).The authors present functional content as a measureof functional satisfaction. One of the advantagesof this technique is the ability to model the product(as an FBS model) and process (as functional evolu-tion) in an integrated fashion. This model can beused to both trace the design process and capturedesign intent.

2.3 Product-state–evolution-based view of designprocesses

A view similar to the functional evolution is theevolution of product states [23]. In this view, adesign process is considered to be a problem solvingtechnique centred on dynamically moving around aso-called product state space. A product state repre-sents all the information describing the product at agiven point in the design process. Tomiyama and

Yoshikawa [24] and Takeda et al. [21] view design asa mapping of a point in the function space onto apoint in the attribute space. Ullman [10] also viewsthe process of design as the refinement of a designfrom its initial state to its final state. According toUllman, the essential components for aptly char-acterizing design processes are: the plan, the pro-cessing action, the effect, and the failure action. Thevarious effects of a design process on the artefact arecategorized as abstraction, refinement, decomposi-tion, combination, and patching.

Maimon and Braha [11] present the use of theanalysis–synthesis–evaluation (ASE) paradigm forrepresenting design processes in terms of knowledgemanipulation. Design processes are represented astuples containing the artefact space, specifications,and transformation operators: analysis, synthesis,and evaluation (ASE). Zeng and Gu [25] also usemodels similar to ASE for developing a mathematicalmodel of the design process. The authors develop abasic mathematical representation scheme to defineobjects involving the entire design process andinvestigate design processes via their mathematicalrepresentation. The elements of the design processproposed by Zeng and Gu include the following:synthesis, evaluation, problem redefinition, anddecomposition.

2.4 Knowledge-manipulation-based view ofdesign processes

Another effort focused on formalizing the represen-tation of design knowledge within the design proce-sses is purported byMaher [12]. Maher presents threemodels for knowledge representation: decomposi-tion, case-based reasoning, and transformation. Thefocus of this work is on design synthesis for develop-ing knowledge-based systems. Decomposition in-volves dividing large complex systems into smaller,less complex subsystems. Case-based reasoninginvolves generating design solutions from previousdesign problems. In transformation, available designknowledge is then expressed as a set of generaltransformational rules that can be used in a variety ofscenarios. Other approaches have been developed forknowledge based representation of design processes.For example, Kavakli [26] presents a knowledge-based modelling approach for detailed design pro-cesses and its software implementation. The details ofthe approaches are beyond the scope of this paper.

2.5 Decision-based view of design processes

Decision-based design (DBD) is a view of design thathas been widely adopted for modelling design pro-cesses. Mistree et al. [27] view design as a process of


Modelling an ongoing design process 549

converting information into knowledge about theproduct and decisions are the key markers used todetermine the progress of design. Design processescan thus be modelled as sets of decisions. The deci-sion support problem (DSP) technique [14, 27] is aframework for design, developed based on thismindset. The DSP technique palette contains entitiesfor modelling design processes, and allows for thearrangement and rearrangement of procedures oractivities essential to design. The entities in the pal-ette are used to build hierarchies and model designprocesses independent of the domain of the designunder consideration. The entities considered withinthe palette (i.e. tasks, decisions, events, and phases)are used to transform information from one state toanother. Key decision types in engineering defined inthe DSP technique include selection, compromise,and coupled decisions. These decisions serve as thebackbone for modelling design processes. In order togenerate information required for executing deci-sions, supporting tasks are performed.

2.6 Representation of design processes

The process specification language (PSL) [28] is aneffort pursued by the National Institute of Standardsand Technology (NIST) aimed at standardizing therepresentation of discrete processes (i.e. processesdescribed as individually distinct events such as pro-duction scheduling, process planning, workflow,business process re-engineering, project manage-ment, etc.). Gorti et al. [13] have developed object-oriented representations for design processes andproducts. The key elements of a design process, asidentified by the authors, are goals, plans, specifica-tions, decisions, and context. The design artefactincludes function, behaviour, structure, and causalknowledge, relating objects to physical phenomena.Since the primary objective of the authors was todevelop comprehensive engineering knowledgebases, they did not focus on design process analysis.

2.7 Critical evaluation of existing design processmodelling approaches

The design process models reviewed may be dividedinto two groups. One group focuses on modelling thedesign process to aid decision making on the productparameters. These efforts tend to focus on modellingthe evolution of the product. While these effortsprovide guidance to defining the design process, themodels tend not to capture design process issuessuch as the different design strategies. The othergroup focuses on modelling the design process to aiddecision making on design process decisions. Anexample of such a method is the design structurematrix [8], which models the various tasks of thedesign process and thus provides an approach to

organize design tasks. An important realization is thatefforts at modelling design processes to aid decisionmaking on design process decisions mainly focus onmodelling of existing processes and thus are mainlysuitable for improving existing design processes. Forexample, in the design structure matrix, the model-ling approach involves defining of tasks and therelationships between tasks. The model can then beutilized to improve the design process. The modellingeffort therefore requires knowledge of the varioustasks, the information flows, and interdependenciesprior to determining the best design process. How-ever, in many cases, the details of the tasks andinterdependencies are not known in advance anddepend on the information available during theexecution of the actual design process. These maydepend on the product information generated fromthe previous steps. These approaches therefore pro-vide little guidance to designers for defining anongoing design process. An approach to dynamicallymodel design processes is therefore necessary andwould be beneficial in helping companies makedynamic decisions on their design processes. It isnoted that several design process models that aiddecision making on product parameters do modelongoing processes and provide dynamic guidance onthe design process. For example, Suh’s design axioms[29] provide guidance on how the design processshould proceed.

Further, the design process modelling techniquesare largely based on the top-down, decomposition-based view of product design. Existing process mod-elling approaches do not account for the bottom-upnature of design. Traditionally, systems engineeringprocesses have been represented using the Veemodel [30, 31], which is centred on top-down func-tional decomposition of the system. Recently, bot-tom-up strategies have been shown as viable optionsthat designers could adopt in product development[32]. Section 4.3 discusses situations in which bot-tom-up design methods are useful. The primaryobjectives of process analyses supported by existingmodelling approaches include maximizing con-currency and minimizing interdependencies [20].The design of the design process is generally con-sidered to be independent of the design of the pro-duct. During the initial phases of design (when thedesign process is not entirely defined), the techni-ques do not explicitly account for trade-offs betweenobjectives related to design processes and theproduct’s related objectives. Since the design pro-cesses are highly interrelated with the products, therelationship between design process decisions (suchas how to decompose a design problem) and theproduct decisions (such as how to embody eachfunction) should be accounted for during the earlyphases of design.



In this paper, an approach is presented for model-ling design processes to overcome these limitations.The approach allows an ongoing design process to bemodelled dynamically. The approach also capturesboth top-down and bottom-up aspects of design pro-cesses. It further allows making decisions related todesign processes while accounting for the impact onthe achievement of a product’s functional require-ments in conjunction with the design process goalssuch as concurrency, time, and cost for design. Thescope of this paper is limited to themodelling of designprocesses. In future publications, the approach will beutilized for designing design processes.

3 DESIGN PROBLEM AND DESIGN TASKCONSTRUCTS

The approach for modelling design processes is basedon the use of design nodes. However, before definingand discussing design nodes, it is necessary to definethe constructs that constitute a design node. In thissection, these elemental constructs will be discussed.

In defining these constructs, it is necessary tounderstand what it is that engineers do when theydesign an artefact and arrive at representations thatcapture these actions. In this paper, the view thatactions of designers or design teams are dynamic andbased on the current state of solving the design pro-blem is adopted. Based on this view, constructs formodelling design processes should capture thedesign problem being solved and the possible actionsthat designers take in solving the problem. Two setsof constructs are therefore proposed in modellingdesign processes – design problem constructs anddesign task constructs.

3.1 Design problem constructs

A design problem can generally be defined as theneed to satisfy a set of requirements through thephysical embodiment of an artefact. Design pro-blems are also characterized by the fact that there isnot a single solution to a design problem. Hence,designers have various alternatives to solve a designproblem. Another important aspect of solving adesign problem is knowledge. Designers utilize var-ious forms of knowledge in performing the differentdesign tasks. Based on this discussion a designproblem can be defined as shown in Table 2, the

satisfaction of design requirements (DR1, DR2, . . .)through the definition of design parameters (DP1,DP2, . . .), the values of which are selected amongvarious alternatives (A11, A12, A21, A22, . . .) utilizingknowledge sources (K1, K2, . . .). The double subscriptsfor the alternatives refer to the different alternativesfor the different design parameters, the first subscriptreferring to the design parameter and the secondsubscript referring to the alternative. For example, inA11, the first subscript refers to DP1 and the secondsubscript refers to the first alternative for DP1.

From this definition, four elements can be definedas constructs of a design problem: (a) design re-quirements, (b) design parameters, (c) alternatives,and (d) knowledge. It is noted that design problemsinvolve a hierarchy; a complex design problem isoften decomposed into simpler problems. At thehigher levels of the hierarchy (i.e. the more complexproblems), the problem is dealt with in an abstract orconceptual manner, leading to the more detailedlevels. This is characterized by the design processtransitioning from conceptual design to embodimentto detailed design [33]. Design problem constructsare utilized to define the state of the problem. Hence,with this transitioning, the representations for theseconstructs change as the design process progresses.For example, the representations for the designparameter construct at the early stages of design mayadopt a ‘function’ representation and, consequently,the alternatives are various concepts that could fulfilthe function. At the detailed design stages, the designparameters are represented by specific attributes ofthe artefact and the alternatives are specific values forthe attributes. Comprehensive formal representa-tions for the construct for different stages of thedesign process are currently being developed.

3.2 Design task constructs

Design tasks are actions that designers take to solvethe design problem. Seven different actions are defi-ned that designers take in solving a design problem[29, 34]: (a) identification of design requirements,(b) decomposition of design requirements, (c) iden-tification of design parameters, (d) decompositionof design parameters, (e) generation of alternatives,(f) analysis of alternatives, and (g) decision/selection.Each of these design task constructs are briefly dis-cussed as follows.

(a) Identification of design requirements. Designersrequire a clear understanding of the design pro-blem that they are attempting to solve. One of thefirst steps in the design process is therefore toidentify, understand, and formalize the require-ments the artefact is supposed to fulfil. This alsoinvolves understanding the relative importance

Table 2 Design problem definition

Satisfy Design requirements (DR1, DR2, . . .)Define Design parameters (DP1, DP2, . . .)Among Alternatives (A11, A12, A21, A22, . . .)Utilizing Knowledge sources (K1, K2, . . .)



of the different requirements the artefact is tofulfil.

(b) Decomposition of design requirements. As manydesign problems are complex, they are oftendecomposed for ease of identifying appropriatesolutions. Decomposing a design problem in-volves decomposing the requirements into ap-propriate requirements for each subproblem.How requirements are decomposed has a signi-ficant impact on the design process. High inter-dependencies between subproblems could leadto a large number of iterations and convergenceproblems [35].

(c) Identification of design parameters. For eachdesign problem, designers need to identify thedesign parameters that need to be determined tofulfil the design requirements.

(d) Decomposition of design parameters. Most pro-ducts possess hierarchy in their structure; com-ponents are combined to form subsystems.Subsystems are combined to form a system.Designers define the structure through decom-position of the design parameters.

(e) Generation of alternatives. Designers generatevarious alternatives for the design parameters.The alternatives can be abstract (such as con-cepts for function fulfilment) or specific (such asattribute values).

(f) Analysis of alternatives. Each alternative is ana-lysed to determine how well it fulfils the designrequirements. Designers often need to developmodels for design analysis. Models could rangefrom computational models to physical modelsfor design analysis.

(g) Decision/selection. Among the alternatives gen-erated for the design parameters, designers needto select one or more alternatives.

Each of these design tasks have been identified at anabstract level. Each task can be implemented usingdifferent design methods. Formal representations fordesign process constructs are also being developed.Figure 1 summarizes the constructs for modelling thedesign process.

4 DESIGN NODES

A design node embodies the design problem anddesign task constructs and thus presents an approachto integrate design problem and design process fac-tors. Design nodes are therefore higher-level con-structs that are used to define a design process. Eachdesign node presents a subproblem of the overalldesign problem. Design nodes are different from thenodes used in AoA and AoN networks discussed insection 2.1 in that they refer to design-specific pro-blems as opposed to tasks to be performed in a gen-eral process. A general design node is depicted inFig. 2. It defines the design problem in terms of thedesign problem constructs: design requirements,alternatives, values of design parameters, andknowledge. It does not provide any informationabout how the design problem is to be solved. Ageneral design node is then instantiated to includethe design tasks constructs and thus will reveal howthe design problem is to be solved.

In his seminal paper on elaborating amodel of designas a process, Gero [34] states, ‘. . . design could be

Fig. 1 Constructs for modelling design processes



described as a goal-oriented, constrained decision-making activity. . . . Designing involves exploration. . . .In addition, designing involves learning: part of theexploration activity is learning; learning about emergingfeatures as a design proceeds.’ From Gero’s descriptionof design, it can be concluded that an approach formodelling a design process requires capturing both thedecision making and the exploration and learningaspects of design. It is therefore identified that designnodes can be instantiated in two main ways. Thesedesign nodes are referred to as the top-down designdecomposition node and the bottom-up design evolu-tion node. These are possible design strategies that adesign team could adopt in solving a design problem.

4.1 Top-down design decomposition node

The top-down design decomposition node is shownin Fig. 3. It defines the design problem and the tasksundertaken to decompose the design problem. In thetop-down design process, a transition is made fromabstract levels to detailed levels. Each level transitioninvolves a greater amount of detail. To transition tothe next level, decisions are made on the value of thedesign parameter. Based on this value of the designparameter, the design problem is decomposed intosubproblems. A top-down design decompositionnode is characterized through the following:

(a) the design parameters in consideration;(b) the requirements that the design parameters are

to satisfy;(c) the alternatives for the possible values that the

parameters could take;

(d) the information or knowledge that is available tomake the design decision;

(e) the decided-upon values for the parameters.

It should be noted that the parameter values deci-ded upon do not imply that a single value is decidedupon for each parameter. This depends on therequirements to be satisfied and the level of infor-mation or knowledge currently available to makethe decision. For example, a design parameter on thematerial to be utilized for a product could have theoptions of using metals, ceramics, plastics, or com-posites. The value of the parameter does not have tobe just one of these classes of materials, but couldtake plastics or ceramics for example. This is a meansof refining the large design space characteristic ofdesign problems to smaller spaces through elimina-tion of options. This also characterizes delayeddesign decisions.

4.2 Bottom-up design evolution node

The bottom-up design evolution node is shown inFig. 4. It defines the design problem and the designtasks undertaken to evolve the design solution. Incontrast to the top-down approach, the bottom-upapproach does not involve transitioning from anabstract level to a detailed level. The bottom-updesign process involves utilizing detailed solutions toidentify the values for design parameters. Further, incontrast to the top-down approach, the bottom-upapproach involves synthesis rather than decomposi-tion. Detailed solutions are combined to producenew solutions; thus systems are composed fromdetailed partial solutions.

The bottom-up design process is often character-ized by an iterative ‘generate-and-evaluate’ process.An initial set of detailed solutions are generated andevaluated to determine the appropriateness of thesolutions. Appropriate solutions are those solutionsthat meet the design requirements. Depending on theappropriateness of the solutions, new detailed solu-tions are generated to satisfy the design require-ments. In generating and testing complete solutions,knowledge is generated on the appropriateness of asolution as well as on the relationships between the

Fig. 4 Bottom-up design exploration and evolution node

Fig. 2 A general design node

Fig. 3 Top-down design decomposition node



various subparameters that constitute the solution.The generated knowledge could be used for solvingfuture design problems. A design problem that couldnot be solved through a top-down approach couldin the future be solved using the knowledge gener-ated in previous bottom-up attempts. The bottom-updesign evolution node is characterized through thefollowing:

(a) the design parameters in consideration;(b) a set of solutions/alternatives that could possibly

satisfy the design requirements;(c) the information or knowledge that is available to

evaluate solutions;(d) the information or knowledge that is generated

through the bottom-up process;(e) iterative generation of solutions to determine the

design parameter value.

4.3 Deciding between top-down and bottom-updesign

The differences between top-down and bottom-updesigns may be illustrated with a simple example.Consider the design of a vehicle. In the top-downapproach, the general requirements of the overallvehicle are first determined and the automobile issubsequently decomposed into its subsystems. Therequirements are accordingly decomposed anddetermined for each subsystem. For example, a gen-eral requirement for the vehicle could be a certainacceleration value. The acceleration could then bedecomposed into a specific power requirement forthe engine. Subsystems are then designed to meet thespecific requirements for each subsystem. In thisinstance, the engine will be designed to meet therequired power. The bottom-up approach also beginswith the general requirements for the overall vehicle.However, instead of decomposing the vehicle intosubsystems and determining the requirements foreach subsystem, the bottom-up approach tries tofulfil each general requirement through compositionof parts and testing. For example, an engine may beattached to an axle and wheels and tested to deter-mine the acceleration of the vehicle. The criterion inthis case is the general requirement of the vehicle (i.e.acceleration) rather than the specific requirement ofthe subsystem (e.g. power of engine). If the accel-eration of the vehicle is not satisfactory, then theparts are changed and tested again. Bottom-uptherefore involves early testing and gradual buildingup of the system.

One aspect of designing the design process isdetermining how the design node is to be instan-tiated. Should a design node be instantiated as a top-down design decomposition node or a bottom-updesign evolution node? A number of factors need tobe considered in determining how a design node is to

be instantiated. For example, is there sufficientknowledge or information to make a decision anddecompose the problem to the next level of thehierarchy? A design parameter at the higher levels ofthe hierarchy could possibly be decomposed intomultiple design parameters, each considered as aseparate problem. However, to decompose the pro-blem and identify requirements for the subproblemnecessitates knowing the relationships between thecomponent subproblems. When designers do nothave knowledge of the relationships, they adopt abottom-up design evolution approach, which resultsin knowledge generated about the relationships.

Another reason for adopting a bottom-up approachcould be in dealing with highly complex designproblems where the overall design problem iscomprised of a large number of interdependentdesign problems. A large number of interdependentdesign parameters are difficult to deal with. Severalresearchers have discussed the failure of large-scaleprojects as a result of being unable to anticipate theeffect of changes when a large number of inter-dependent design parameters are present [36, 37].Bar-Yam [36] recently proposed that in such situa-tions a bottom-up evolutionary approach could bemore appropriate. In developing a computationalenvironment for design process design, it is neces-sary to develop principles to aid design teams indeciding between top-down and bottom-up designapproaches. The authors are currently developingquantitative methods for effective decision makingon how the design process should proceed.

5 MODELLING DESIGN PROCESSES USINGDESIGN NODES

The approach to model design processes using designnodes is shown in Fig. 5. Using the design nodeapproach, a design process is modelled by defining adesign node (i.e. defining the design problem) andinstantiating the design node (i.e. defining how thedesign problem will be solved through the designtasks). As the design process progresses, design nodesare decomposed into subdesign nodes, each with its

Fig. 5 Design process modelling approach using designnodes



own instantiation. The combination of all designnodes reveals how the design problem is solved interms of the subproblems as well as the tasks under-taken to solve each subproblem. The designers canseparately view the problem-decomposition view andthe task-based view.

Figure 6 shows how the approach is carried out.It depicts a design process where a design node atlevel i (Design Node1) is defined by the need to satisfyrequirements DR1 and DR2 through a design para-meter DP1. The definition of the design probleminvolved the tasks of ‘identification of designrequirements’ and ‘identification of design para-meters’. The definition of the design problem in thedesign node could be utilized to answer several of thedesign process questions posed in section 1. Forexample, based on the design problem, the company

could decide to outsource the design problem ratherthan solving it in-house. Also, the design team coulddecide if more information needs to be gatheredabout the design problem. The design team couldalso decide if a top-down or bottom-up design strat-egy is adopted. These decisions would define the nexttasks in the design process. In Fig. 6, Design Node1 isinstantiated as a top-down design decompositionnode. In the top-down design decomposition node, adecision is made to select one or more values for thedesign parameter under consideration. The chosenvalue or values are then decomposed in the next levelof the hierarchy into subdesign nodes. In Fig. 6, this isdepicted as Design Node11, with the need to satisfyrequirements DR11 and DR21, and Design Node12, withthe need to satisfy requirements DR12 and DR22. Thedesign parameters DP11 and DP12 in Design Node11

Fig. 6 Design process modelling using design nodes



and Design Node12 respectively are more detailed innature than the design parameter DP1 at DesignNode1. This depicts a progression in the design pro-cess from abstract levels to more detailed levels.Instantiating the design node as a top-down designnode reveals how the design team has decided tosolve the design problem. The modelling approachtherefore allows a team to decide dynamically onthe next tasks and strategy to be adopted based onthe problem.

At a point in the progression of the design process,the design problem cannot or should not be decom-posed further. In that situation, a design node isinstantiated as a bottom-up design exploration andevolution node. In Fig. 6, DesignNode12 is instantiatedas a bottom-up design evolution node. As designevolution involves generating and testing a set ofsolutions for the design parameter, each new set ofsolutions being generated and tested is defined as aseparate bottom-up design evolution node. Theiterative process is carried out until an appropriatesolution is found to satisfy the design requirements.

One of the salient features of dynamically model-ling the design process considering both design tasksand the design problem is that it allows informeddecisions to be made on how the design processshould proceed. Various design principles can beimplemented to decide how the design processshould progress. For example, Suh [29] advocatesmaintaining the functional independence of require-ments. Therefore, if a design problem is decomposedinto subproblems, each subdesign problem should becharacterized by functionally independent require-ments. Finally, the design node view of the designprocess can be expanded to reveal a design task view

as shown in Fig. 7. The design task view is derived bydefining the sequence of the design task constructs.

The design task view allows for decision making ondesign process factors at a more detailed level. Asmentioned earlier, each design task can be imple-mented in different ways. Deciding on the method inwhich the design task is implemented also has abearing on the quality, lead-time, and cost of theproduct being designed. For example, in the task of‘generation of alternatives’, designers might need todecide on the number of alternatives that is practical.While in the conceptual design stages it is useful togenerate many concepts, in the detailed design stagesthe number of alternatives for a design parametermight be staggering and not practical for a designerto evaluate a large number of possible solutions. Thisis especially so if the designers adopt a physicalexperimental approach to evaluate each alternative.In such a case, the time taken to evaluate alternativesmight severely affect the number of alternatives thatcan be evaluated. Another example is in the task of‘evaluation of alternatives’, where designers need todevelop models for evaluating alternative solutions.

One decision that designers need to make is thelevel of refinement of the simulation model, devel-oping very detailed simulation models while provid-ing accurate analysis results in a longer computationtime. This could be a problem in situations wherethere are a large number of possible alternatives.Panchal et al. [38] have recently developed a methodfor deciding on the appropriate level of refinementfor a simulation model based on the use of a value-of-information approach. The task view of the designprocess allows these kinds of methods to be incor-porated into the design of the design process at adetailed level.

Fig. 7 Task view of design process



6 DESIGN PROCESS MODELLING EXAMPLE

6.1 Design problem

In this section, an example is presented to illustratehow design nodes are utilized to model a progressingdesign process. The design node approach is used tomodel the design process of an actual company inthe process of designing a new product. The name ofthe company involved in the example has beenwithheld because the product is yet to be released inthe market.

In this design problem, the objective is to develop atranslucent rod with a certain stiffness value. The rodalso needs to meet dimensional requirements due toassembly constraints. The design problem is depictedin Fig. 8. The design team identifies that this is amaterials design problem. This is because the mate-rial plays the biggest role in meeting the require-ments of translucency and stiffness. The design teamdefines the overall design problem and instantiates itas a top-down design decomposition node, as shownin Fig. 9.

6.2 Design node 1

As shown in Fig. 9, the design team has identifiedthree design requirements: DR1, translucent; DR2,stiffness of x GPa; and DR3, diameter to preventjamming. The design parameter has been defined atan abstract level simply as ‘class of material’. Thedifferent classes of materials (i.e. metals, polymers,ceramics, and composites) have been identified asthe alternatives. The design team then needs todecide on the alternative or alternatives that satisfythe requirements. In making the decision, the designteam utilizes knowledge of each class of material. Theknowledge that the design team utilizes in this case isas follows:

(a) metals are not translucent and therefore can beeliminated;

(b) polymers do not possess the necessary stiffnessfor this application and are therefore also elimi-nated;

(c) ceramics are too brittle for this application andare also eliminated.

As a result, the design team decides with confidencethat composites should be the class of materialsfor the rod. Further, the design team decides thatthe composite should be a glass fibre reinforcedpolymer composite to ensure that the rod is trans-lucent.

In instantiating design node 1, the design team hasan option of instantiating the node as a top-downdesign decomposition node or as a bottom-up designevolution node, indicating the choice of the approachin solving the design problem. The design teaminstantiated this design node as a design decom-position node because they could make a decisionwith confidence on the value of the design parameterat that level of abstraction of the design parameterand could decompose the design problem into twosubproblems that could be solved independently.The two subproblems are discussed in the followingsection. However, as discussed in section 4.3, ifthe design team was unable to decompose thedesign problem, then a bottom-up design evolutionapproach could have been adopted tomeet the designrequirements. This would have involved testing andimproving different materials and different diametersof the rod to meet the dimensional and stiffnessrequirements. Further, if the design team had beenunable to make a decision with confidence on thechoice of material class, two alternatives could havebeen selected to be included in the later stages ofthe design process. In modelling the design processusing design nodes, this would result in twosubsequent design nodes that could be solvedconcurrently. In a computational environment fordesigning design processes, the system could provideintelligent decision support during the design processon how sound their decisions are through the devel-opment of quantitative decision making models.From the design task constructs, the design team hasthus far performed the following series of sequentialtasks: identification of requirements, identification ofdesign parameters, generation of alternatives, analy-sis of alternatives and decisions. The task-based viewof design node 1 is shown in Fig. 10.

Fig. 8 Design problem example

Fig. 9 Design node 1 for example



6.3 Design nodes 2 and 3

Once the decision is made, the design team thendecomposes the design problem by decomposing therequirements. In this case, the design team was ableto decompose the design problem into two designproblems, as shown in Fig. 11: a design problem toidentify the diameter of the rod and a design problemto identify the polymer matrix and reinforcement ofthe composite material to satisfy translucency and astiffness value. It should be noted that in many cases,stiffness and diameter are interdependent properties.However, in this case, the team had access to aprocess that allowed diameter and stiffness to bedetermined independently, thus allowing them todecompose the design problem into two indepen-dent problems. Again, in a computational environ-ment the decomposition of the design problem couldbe validated and feedback provided to the designteam. Functionally independent problem decom-position allows subproblems to be performed con-currently without affecting other subproblems. Inthis example, the tasks of design node 2 and designnode 3 can be concurrently performed. Design nodestherefore also provide a means of identifying how theprocess can be coordinated.

In this example, design node 2 is a final node in theparticular trajectory of the design nodes as no furtherdecomposition is possible. The design parameter fordesign node 2 is the rod diameter and the alternativesare the various possible rod diameters. A final valuefor the rod diameter is then selected based on theanalysis if jamming would occur. Through solvingdesign node 2, one of the design requirements (DR3)of the original design problem has been fulfilled.Design node 3, on the other hand, has been instan-tiated as a bottom-up design evolution node. In the-ory, design node 3 could have been decomposed intotwo subproblems, one for identifying the polymermatrix and one for identifying the reinforcementmaterial. The stiffness requirement of design node 3could have been decomposed into two separatestiffness requirements for the polymer matrix and thereinforcement material through the identification ofa reinforcement–matrix volume ratio. However, thedesign team was aware that there are other depen-dencies between the polymer matrix and the rein-forcement in processing the material that will affect

the distribution of the reinforcement material andhence the uniformity of stiffness across the rod. Dueto the high interdependencies in the design para-meters (i.e. polymer matrix and reinforcement type)for achieving the design requirements, the designteam opted to adopt a bottom-up design evolutionapproach to solving the design problem. Further, thedesign team had access to a large number of possiblepolymer resins and several possible glass fibre types.The large design space also prompted the designteam to adopt a bottom-up design explorationapproach to evaluate the possible combinations ofpolymer resins and fibre types and gather knowledgeon the interrelationships. The knowledge generatedfrom the design exploration could aid in faster designconvergence through selection of appropriate com-binations for further refinement. It should be notedthat each set of solutions generated and tested in thebottom-up design evolution process could be repre-sented as a separate design node. This is depicted inFig. 12. The node on the right in Fig. 12 shows the firststage of design exploration, where various combina-tions of available polymer resins and fibre types areevaluated. The result of this stage is the selection ofpolymer resins and fibre types that can be refined inthe next stage. The node on the left in Fig. 12 showsthe second stage of design exploration. For thisexample, a solution was selected at this stage.

In this example, it was shown how design nodescan be used to model ongoing design processes. Itcan be seen from the example that modelling anongoing design process allows designers to makedecisions dynamically on how the design processshould proceed. This is evident in the example as thedesign team decided on top-down design decom-position and bottom-up design evolution processesunder different situations. This differs from methodsin which design activities are defined at the start ofthe design project and sequenced according to thenature of the predefined activities. The ability to

Fig. 11 Design nodes 2 and 3 for example

Fig. 10 Task-based view of design node 1



make decisions dynamically on the design processallows the design team to make design process deci-sions that account for the type of design problem.Hence, design methods that are appropriate can beselected rather than abstract design tasks defined.

7 CONCLUSIONS

In this paper, it was identified that there is a need tomodel an ongoing design process to facilitatedynamic decision making on how the design processshould proceed. An approach to model an ongoingdesign process was proposed through the use ofdesign nodes. A design node captures the designproblem and design tasks in an integrated manner,thus allowing design process decisions to be madeaccounting for the type of design problem to besolved. Design nodes are defined and instantiatedduring an ongoing design process, and thus facilitatedynamic decision making on how the design processprogresses. Design nodes also capture top-down andbottom-up design strategies. Therefore, design nodesalso allow the capture of the nature of how a designproblem is solved. Future work will address devel-oping formal representations for design problem anddesign task constructs in the pursuit of developing acomputational environment for modelling anddesigning ongoing design processes.

REFERENCES

1 Smith, R. P. and Morrow, J. A. Product developmentprocess modelling. Des. Studies, 1999, 20(3), 237–261.

2 Simon, H. A. The sciences of the artificial, 1996(The MIT Press, Cambridge, Massachusetts).

3 Kusiak, A., Wang, J., He, D., and Feng, C. A structuredapproach for analysis of design processes. IEEE Trans.on Components, Packaging, and Mfg Technol. – Part A,1995, 18(3), 664–673.

4 Bras, B. A. Designing design processes for decision-based concurrent engineering. In CERC’s First Work-shop on Product development, process modeling and

characterization, Morgantown, West Virginia, 1992,

Concurrent Engineering Research Center, 7–9.5 Panchal, J. H., Ferna�ndez, M. G., Paredis, C. J. J.,

Allen, J. K., and Mistree, F. Designing design processes

in product lifecycle management: research issues and

strategies. In ASME 2004 Computers and Information in

Engineering Conference, Salt Lake City, Utah, 2004,

paper DETC2004/CIE-57742.6 Kusiak, A. and Wang, J. Decomposition of the design

process. J. Mech. Des., 1993, 115, 687–694.7 Fathianathan, M. and Panchal, J. H. Design nodes: an

approach for modeling design processes. In 4th Inter-

national Conference on Digital enterprise technology,

Bath, United Kingdom, 2007.8 Eppinger, S., Whitney, D. E., Smith, R. P., and

Gebala, D. A. A model-based method for organizing

tasks in product development. Res. Engng Des., 1994,

6(1), 1–13.9 Shimomura, Y., Yoshioka, M., Takeda, H., Umeda, Y.,

and Tomiyama, T. Representation of design object

based on the functional evolution process model.

J. Mech. Des., 1998, 120(2), 221–229.10 Ullman, D. G. A taxonomy for mechanical design. Res.

Engng Des., 1992, 3(3), 179–189.11 Maimon, O. and Braha, D. On the complexity of the

design synthesis problem. IEEE Trans. on Systems, Man,

and Cybernetics – Part A: Systems and Humans, 1996,

26(1), 142–151.12 Maher, M. L. Process models for design synthesis.

AI Mag., 1990, 49–58.13 Gorti, S. R., Gupta, A., Kim, G. J., Sriram, R. D., and

Wong, A. An object-oriented representation for product

and design process. Computer Aided Des., 1998, 30(7),

489–501.14 Mistree, F., Smith, W. F., Bras, B. A., Allen, J. K., and

Muster, D. Decision-based design: a contemporary

paradigm in ship design. Trans. Soc. Naval Architects

and Marine Engrs, 1990, 98, 565–597.15 Elmaghraby, S. E. Activity nets: a guided tour through

some recent developments. Eur. J. Op. Res., 1995, 82(3),

383–408.16 Harrison, F. L. and Lock, D. Advanced project man-

agement – a structured approach, 2004 (Gower Pub-

lishing Limited).17 Lockyer, K. G. The application of the matrix to ‘activity-

on-node’ network systems. Ops Res. Q., 1967, 18(4),

470–472.

Fig. 12 Bottom-up design evolution in design node 3



18 Steward, D. V. The design structure system: a methodfor managing the design of complex systems. IEEETrans. Engng Mgmt, 1981, EM 78(3), 71–74.

19 Browning, T. R. and Eppinger, S. D. Modeling impactsof process architecture on cost and schedule risk inproduct development. IEEE Trans. Engng Mgmt, 2002,49(4), 428–442.

20 Browning, T. R. Applying the design structure matrixto system decomposition and integration problems:a review and new directions. IEEE Trans. Engng Mgmt,2001, 48(3), 292–306.

21 Takeda, H., Veerkamp, P., Tomiyama, T., andYoshikawa, H. Modeling design processes. AI Mag.,1990, 37–48.

22 Umeda, Y., Takeda, H., Tomiyama, T., and Yoshikawa,H. Function, behaviour, and structure. AIENG-90Applications of AI in Engng, 1990, pp. 177–193.

23 Hsu, Y.-L., Tai, C.-Y., and Chen, Y.-C. A design processmodel based on product states. J. Chin. Soc. Mech.Engrs, 2000, 21(4), 369–377.

24 Tomiyama, T. and Yoshikawa, H. Extended generaldesign theory. In Design theory for CAD, Proceedings ofthe IFIP WG5.2 working conference 1985, 1986,pp. 95–130 (Elsevier, North-Holland, Amsterdam).

25 Zeng, Y. and Gu, P. A science based approach to pro-duct design theory. Part II: formulation of designrequirements and products. Robotics and ComputerIntegrated Mfg, 1999, 15(6), 341–352.

26 Kavakli, M. NoDes: Knowledge based modeling fordetailed design process – from analysis to implementa-tion. J. Automn in Construction, 2001, 10(4), 399–416.

27 Mistree, F., Bras, B. A., Smith, W. F., and Allen, J. K.Modeling design processes: a conceptual, decision-basedperspective. Int. J. EngngDes. Automn, 1996, 1(4), 209–221.

28 Schlenoff, C., Knutilla, A., and Ray, S. Unified processspecification language: requirements for modeling

process. National Institute of Standards and Technol-ogy, 1996.

29 Suh, N. P. Principles of design, 1990 (Oxford UniversityPress, Oxford).

30 Buede, D. M. The engineering design of systems:models and methods, 2000 (John Wiley & Sons, Inc.,New York).

31 Forsberg, K. and Mooz, H. The relationship of systemsengineering to the project cycle. Engng Mgmt J., 1992,4(3), 36–43.

32 Braha, D., Minai, A., and Bar-Yam, Y. (Eds) Complexengineered systems: science meets technology, 2006(Springer Verlag, Berlin).

33 Pahl, G. and Beitz, W. Engineering design – a systematicapproach (Ed. K. Wallace) 1996 (Springer, Berlin,Heidelberg, and New York).

34 Gero, J. S. Design prototypes: a knowledge representa-tion schema for design. AI Mag., 1990, 26–36.

35 Yassine, A. and Braha, D. Complex concurrentengineering and the design structure matrix method.Concurrent Engng: Res. and Applics, 2003, 11(3),165–176.

36 Bar-Yam, Y. When systems engineering fails – towardcomplex systems engineering. In Proceedings ofInternational Conference on Systems, man and cyber-netics, Piscataway, New Jersey, 2003, pp. 2021–2028(IEEE Press).

37 Mihm, J. and Loch, C. H. Spiraling out of control:problem solving dynamics in complex distributedengineering projects. In Complex engineering systems(Eds D. Braha, A., Minai, and Y. Bar-Yam), 2006 (PerseusBooks, New York).

38 Panchal, J. H., Paredis, C. J. J., Allen, J. K., andMistree, F. A value-of-information based approach tosimulation model refinement. Engng Optimization,2008, 40(3), 223–251.



special issue paper 547 modelling an ongoing …...modelling an ongoing design process utilizing...

Documents