regular paper application of axiomatic design and design ... of papers for... · the foundation...

Application of AxiomaticDesign and DesignStructure Matrix to theDecomposition ofEngineering SystemsM. D. Guenov* and S. G. Barker

Department of Power, Propulsion and Aerospace Engineering, School of Engineering, Cranfield University, Wharley End,Bedfordshire, MK43 0AL, United Kingdom

DECOMPOSITION OF ENGINEERING SYSTEMS

Received 25 February 2004; Accepted 1 August 2004, after one or more revisionsPublished online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/sys.20015

ABSTRACT

A design decomposition-integration model, named COPE, is proposed in which AxiomaticDesign Matrices (DM) map Functional Requirements to Design Parameters while DesignStructure Matrices (DSM) provide structured representation of the system developmentcontext. In COPE, the DM and the DSM co-evolve. Traversing between the two types ofmatrices allows for some control in the application of the system knowledge which surroundsthe decision making process and the definition of the system architecture. It is argued thatthis approach describes better the design process of complex products which is constrainedby the need to utilise existing manufacturing processes, to apply discrete technologicalinnovations and to accommodate work-share and supply chain agreements. Presented is anindustrial case study which demonstrated the feasibility of the model. © 2004 Wiley Peri-odicals, Inc. Syst Eng 8: 29–40, 2005

Key words: axiomatic design, design structure matrix, systems decomposition, systemsintegration

1. INTRODUCTION

Standards for the engineering of systems such as EIA632 and ISO/IEC 15288 support a seamless process ofconverting customer needs into systems/technical re-quirements, which are subsequently transformed intological representations (architectural design) and fi-

Regular Paper

*Author to whom all correspondence should be addressed (e-mail:[email protected]).

Contract grant sponsor: UK EPSRC Research Grant GR/R37067under the Systems Integration Initiative.

Systems Engineering, Vol. 8, No. 1, 2005© 2004 Wiley Periodicals, Inc.

29

nally into physical solution representations. The proc-ess is iterative (see Fig. 1) due to the incomplete infor-mation available at the outset of the project and also thelarge number of constraints involved—technical, eco-nomic and even political. The systems approach oftackling the problem includes the deployment of Inte-grated Product Teams (IPT). These are composed of avariety of specialists from different functional disci-plines, ideally representing different phases of the prod-uct lifecycle to ensure that the design process willconsider, as early as possible, all relevant requirementsand constraints. IPTs are now a common practice inindustries such as the defense and aerospace. Whatseems to be lacking, however, are high-level supporttools which could help the systems teams and architectsdraw together consistently a vast amount of informationneeded for the requirements and the design decompo-sition of the system. Currently there exist a number ofrequirements management tools, which fulfill only par-tially this need. For instance, “Acclaro” [Suh, 2001;Axiomatic Design Software Inc. website] is designedto evolve the systems design in accordance with therules of Axiomatic Design Theory (ADT). The softwareallows the systems designer to enter the top-level Func-tional Requirements (FRs) and Design Parameters(DPs), and to decompose and map those in two treehierarchies and associated design matrices. However,Acclaro is concerned primarily with functional decom-position, and not with explicit constraint mitigation andcontrol. SLATE, on the other hand [Talbott et al., 1994a,1994b], now part of the EDS Team Center suite ofsoftware, is a good example of a powerful requirementsmanagement system. It provides constructs not only tobuild requirements and product hierarchies, but also

allows the designer to attach constraints and text frag-ments to each item within each layer of the systemdecomposition, and also provides a good level of trace-ability of nonfunctional requirements throughout thedesign decomposition. SLATE, however, would onlyproduce results which reflect the experience of thoseusing it. Observations made during the industrial casestudy suggest that, in practice, even experienced sys-tems designers are too quick to follow a particularsolution path, relying heavily on existing knowledgeand past concepts.

There are also other methods of structuring the de-sign process, such as the N2 chart [Lano, 1977, 1979],and the Design Structure Matrix (DSM) approach[Steward, 1967, 1981]. The latter approach provides theability to group related design elements. There aresoftware tools available which are based on the DSM.These include DeMAID [Rogers, 1999], which wasdeveloped by NASA to facilitate the decomposition andsequencing of design activities, and more recently,PlanWeaver (ADePT [Adept Management website])which has been applied mainly in the constructionindustry.

This paper presents work which has concentratedparticularly on the integration of ADT and DSM. Theconjecture is that ADT and DSM are complementaryparts of the decomposition–integration problem, wherethe former is more concerned with mapping of func-tional requirements to design parameters, while thelatter is better suited to modeling the interactions andthe integration of the design parameters. The mainobjective of the work is to investigate to what extentthose two methods can be integrated and to evaluate theapproach in a realistic industrial setting. The potentialvalue of this work is that it provides a means of relatingcomponent integration to system functionality, whichotherwise is not available but is essential during theearly stages of the design process. The following twosections present a brief summary of ADT and DSM,respectively. Section 4 outlines the Methodology, whileSection 5 describes the industrial case study undertakento test and evaluate the approach. Finally conclusionsare drawn and future work outlined.

2. AXIOMATIC DESIGN THEORY (ADT)

The underlying hypothesis of the Axiomatic Design[Suh, 1990, 2001] is that there exist fundamental prin-ciples that govern good design practice. The main dis-tinguishable components of the ADT are domains,hierarchies, and design axioms. The foundation axiomsare:

Figure 1. High-level view of the systems engineering process(adapted from ANSI/EIA-632-1998).

30 GUENOV AND BARKER

Axiom 1. Maintain the independence of the func-tional requirements.1

Axiom 2. Minimize the information content of thedesign.

Axiom 1 requires that Functional Requirements(FRs) be independent of one another, which enableseach FR to be satisfied without affecting any of the otherFRs. Thus there is no coupling of function where it canbe avoided, and the design remains as uncomplicated aspossible. Axiom 2 provides a quantitative measure ofthe merits of a given design, and thus it is useful inselecting the best among the designs which satisfyaxiom one [Suh, 2001]. Generally, the design that usesthe least information is superior. This is explained inmore detail later in this section. According to the ADT,the design process takes place in four domains (Fig. 2,adapted from Tate [1999] and Suh [2001]): Customer,Functional, Physical and Process. Through a series ofiterations, the design process converts customer’s needs(CNs) into Functional Requirements (FRs) and con-straints (Cs), which in turn are embodied into DesignParameters (DPs). Functional Requirements can be de-fined as “a minimum set of independent requirementsthat completely characterises the functional needs of theproduct in the functional domain”; Design Parametersare “the key physical variables in the physical domainthat characterise the design that specifies the FRs” [Suh,2001, p 14]. DPs determine (but also can be affected by)the manufacturing or Process Variables (PVs). The de-composition process starts with the decomposition ofthe overall functional requirement—in practice thisshould correspond to the top system requirement. Be-fore decomposing a FR at a particular hierarchical levelin the functional domain, the corresponding DP must

be determined for the same hierarchical level in thephysical domain. This iterative process is called zigzag-ging (see also Tate [1999] for a more thorough treatmentof the decomposition problem).

Zigzagging also involves the other domains sincemanufacturing considerations may constrain design de-cisions, while “over-specified” requirements could vir-tually prohibit the discovery of feasible designsolutions. At each level of the design hierarchy, therelations (the dependencies) between the FRs and theDPs can be represented in an equation of the form:

FR = [A]DP, (1)

where each element of the design matrix [A] can beexpressed as Aij = ∂FRi/∂DPj (i = 1,…, m and j = 1,…,n). Equation (1) is called the design equation and canbe interpreted as “choosing the right set of DPs tosatisfy given FRs.” This is required by Axiom 1 (Inde-pendence). Each element Aij is represented as a partialderivative to indicate dependency of a FRi on a DPj. Forsimplicity the value of an element Aij can be expressedas 0 (i.e., the functional requirement does not dependon the particular design parameter), or otherwise X.Depending on the type of resulting design matrix [A],three types of designs exist: uncoupled, decoupled andcoupled (Fig. 3).

Uncoupled design occurs when each FR is satisfiedby exactly one DP. The resulting matrix is diagonal, andthe design equation has an exact solution; i.e., Axiom 1is satisfied. When the design matrix is lower triangular,the resulting design is decoupled, which means that asequence exists, where by adjusting DPs in a certainorder, the FRs can be satisfied. The design matrix of acoupled design contains mostly nonzero elements, andthus the FRs cannot be satisfied independently. A cou-pled design can be decoupled, for example, by addingcomponents to carry out specific functions—however,this comes at a price.

Figure 2. Decomposition by zigzagging.

1It appears that software engineers realized this earlier, whilelearning from some bad designs in the automotive industry [seeStevens, Myers, and Constantine, 1974: 139].

DECOMPOSITION OF ENGINEERING SYSTEMS 31

One additional factor that affects coupling is thenumber of FRs, m, relative to the number of DPs, n. Ifm > n, then the design is either coupled or the FRscannot be satisfied. If m < n, then the design is redun-dant. (Note that in both cases the design matrix [A] isnot square.)

In addition to the design axioms, ADT is governedby a set of rules, which are formalized into theoremsand corollaries. Of particularly relevance to this re-search are Corollary 3 and Theorem 5 which originatefrom the first axiom (Independence):

• Corollary 3 states: “Integrate design features in asingle physical part if the functional requirements(FRs) can be independently satisfied in the pro-posed solution.”

• Theorem 5 states: “When a given set of FRs ischanged by the addition of a new FR, by substi-tuting one of the FRs with a new one, or byselection of a completely different set of FRs, thedesign solution given by the original DPs cannotsatisfy the new set of FRs. Consequently, a newdesign solution must be sought.”

The Second Design Axiom states that minimizing theinformation content of a DP increases the probabilityof success of satisfying a function. The informationcontent is defined by the equation

I = log

system rangecommon range

. (2)

In Figure 4 design range is the tolerance within whichthe DP can vary; system range is the capability of the

(manufacturing) system; common range is the overlapbetween design and system ranges, and specifies therange within which the FR(s) can be met [Suh, 2001].The information content of a system can be computedby summation of the individual information contents ofall DPs only if the latter are probabilistically inde-pendent. Frey, Jahangir, and Engelhard [2000] provedthat simple summation cannot be performed for decou-pled designs and offered a method for computing infor-mation content. There is no exact method for computingthe information content of coupled designs.

3. DESIGN STRUCTURE MATRIX (DSM)

The DSM can be seen as a successor to the N2 chart[Lano, 1977, 1979, Becker, Ben-Asher, and Ackerman,2000], which was used for some years by the SystemsEngineering community, before the introduction of theDSM. The DSM has become increasingly popular as ameans of planning product development, project plan-ning and management, systems engineering, and organ-izational development [Browning, 2001, 2002]. Theconcept dates back to the 1960s and was not actuallypublished until 1981 [Steward, 1981]. The DesignStructure Matrix (DSM) is a compact, matrix repre-sentation of a system/project. The matrix contains a listof all constituent subsystems/activities and the corre-sponding information exchange and dependency pat-terns. That is, what information pieces (parameters) arerequired to start a certain activity and where does theinformation generated by the activity feed into—i.e.,which other tasks within the matrix utilize the outputinformation [Design Structure Matrix website]. Thereare three different configurations of the matrix (Fig. 5).The simple, parallel configuration, in which the design

Figure 3. Examples of design types. From top to bottom:Uncoupled, Decoupled, and Coupled Design.

Figure 4. Probability distribution of a design parameter. Thesolid line represents uniform distribution, the dotted line anonuniform distribution (adapted from Suh [1990]).


elements (e.g., design parameters or activities) are fullyindependent of each other, the sequential, “decoupled”configuration, in which the second parameter is de-pendent upon the output of the first, and the fullycoupled configuration, in which parameters are interde-pendent upon each other. Figure 6 shows how a DSMmay be used. The crosses below the diagonal in figure6a represent a forward flow of information, while thoseabove the diagonal depict a feedback loop. The DSMcan be used to reorder, or “partition” design elements,to minimize feedback loops (Fig. 6b). This is achievedby a process of “triangularization” [Browning, 2002],to render the matrix as “lower-triangular” as possible.Sets of feedback loops can also be removed, by “tear-ing” them from the matrix—in practice this meansproducing a set of assumptions for the (as yet) unknowninformation. The DSM must then be repartitioned.DSMs can also be used to create and sequence modulesor clusters [Sharman and Yassine, 2004], which areeither mutually exclusive, or minimally interacting.This absorbs any (remaining) iteration within the sys-tem. This is shown in Figure 6c.

There are two types of DSM in terms of application:

• The static DSM, essentially a square matrix, usedfor the representation of systems design architec-ture interface, design decomposition and modu-

larization, and planning of organizational topolo-gies

• The temporal DSM, which is primarily used formapping of design processes and for schedulingand management of activities, over time

This research is concerned with the use of DSM tomodel the integration and connectivity (logical andphysical) between design embodiments of system ar-chitectures, and to trace the effects of this integrationon the functionality of the system.

While DSM provides a powerful technique for theanalysis of design interactions within a complex devel-opment program, it appears to be less effective in inno-vative design. As Dong and Whitney [2001, p 11] pointout, it is not possible to “obtain a DSM for a newproduct that has never been designed before.” Addition-ally, Dong and Whitney maintain that, although theDSM captures the interactions between elements withina system, it fails to record explicitly the reasons forthese interactions.

4. DECOMPOSITION-INTEGRATIONPROCESS USING ADT AND DSM

ADT postulates that a zigzagging process for FR-DPmapping that takes place in a “solution neutral” envi-

Figure 5. DSM configurations.

Figure 6. Examples of DSM forms: (a) Basic, (b) Partitioned, (c) Clustered.


ronment ensures better design. This, however, canrarely happen in practice, particularly in complex prod-uct environments, where economic considerations dic-tate maximum possible utilization of mature designsand existing manufacturing processes [Guenov, 2002].In addition, the design process must capture the inter-actions among the design parameters, including geome-try, spatial layout, interfaces (e.g., logical and physicalconnectivity), and so forth. As discussed in the previoussection, DSM is a mature method capable of capturingthe interaction between design parameters, but by defi-nition, it is fully known only for products that havealready been designed.

These considerations led us to the idea that thedecomposition integration problem would be bettermodeled as a co-evolution of ADT matrices and DSMs.The generic representation of the process which wenamed COPE (decomposition-integration of COmplexProduct Environments) is depicted in Figure 7. InCOPE, ADT is used to map the decomposition offunctional requirements to design parameters (FR-DP).At each decomposition level various knowledgesources are consulted in order to take into considerationconstraints originating from all stakeholders. Theknowledge sources include unstructured ones (e.g., em-ployees’ tacit knowledge and various unpublisheddocuments) as well as structured/coded sources. Exam-ples of the latter include government regulations, DSMsof past designs (also processes), company’s own designstandards, synthetic and analytical models, knowledgebases, and so forth. Technology “bricks” is a generic

term which encompasses chunks of new technologywhich is mature enough to be applied in the new productwith potential competitive advantage.

As the decomposition progresses, essential designstudies must be performed, including spatial layout,performance and capacity constraints checks, and/ormore detailed design of particular, riskier aspects of theproduct, resulting in more interactions between thedesign parameters. As a consequence, Corollary 3 ofADT may be violated or requirements may need to beadded or changed at a higher level, which would requirea repetition of the decomposition phase (see Theorem5 of ADT).

The first step to linking ADT and DSM was madeby Dong and Whitney [2001], who showed that if theAxiomatic design matrix (DM) can be expressed ana-lytically and one design parameter (DP) is dominant insatisfying a particular functional requirement (FR),then the triangulated design matrix is equivalent to theDSM of the design parameters. The algorithm consistsof three major steps:

1. Construct the Design Matrix (DM).2. In each row of the DM choose the dominant (the

largest) entry.3. Permute the matrix by exchanging rows and col-

umns so that all dominant entries appear on themain diagonal.

The authors show that choosing the dominant entries isimportant as it ensures the convergence of the designprocess.

Figure 7. Schematic representation of the COPE Decomposition-Integration process.


Unfortunately, when designing complex (physicalor software) systems the FRs are satisfied by modulesor other (sub)systems or components and therefore thedesign matrix cannot be represented analytically; and itmay not necessarily be square either. In order to over-come this restriction, we have devised a decompositionprocedure (Fig. 8) in which the design and structurematrices co-evolve.

The procedure starts with the construction of the DMof the FR-DP hierarchy. At this level the dominant DPsare identified. The DM is manipulated [see Dong andWhitney, 2001] so that it becomes lower triangular withdominant entries, “X,” on the main diagonal. The result

is the “Architectural” DSM, that is, a DSM derived onlyfrom the functional view of the product. At this stage acertain amount of layout/spatial design may need to bedone, including possible integration of components.This will be subjected to considerations regarding in-novation, cost, weight, capacity and other constraints,which are taken into account by applying the knowl-edge sources, as discussed above (see also Fig. 4). Theresulting design may affect the functionality of thesystems, for example, grouping components togethermay couple functions. If that is the case, requirementsmay need to change or more design parameters mayneed to be added. This means that the design decompo-

Figure 8. COPE decomposition–integration procedure.


sition has to be reconsidered from the highest level (seeTheorem 5). The decomposition ends when a leaf nodeis encountered, that is, further decomposition willchange the subject of the requirement. In terms ofsystems engineering standards (see, e.g., ANSI/EIA-632), a leaf node can be approximately described as aspecified/assigned requirement.

Perhaps it is worth emphasising that the COPE pro-cedure aims to retrace the AD-DSM connection at eachlevel of the decomposition rather than at reaching a leafnode of the DP hierarchy. This is justified by the factthat in practice one can be very restricted in performingthe entire decomposition in a “solution neutral” envi-ronment (as advocated by ADT)—there are, for exam-ple, cost considerations at the outset of the projectwhich result in targets on reusability of components andmanufacturing processes from previous products and/or targets on commonality of components with otherexisting product lines. Furthermore, one sometimesneeds to decompose much deeper one branch of theFR-DP hierarchy relative to other branches in order tode-risk the solution. For example, one may need toknow if a particular material can be used before con-tinuing further with the decomposition since this par-ticular material may affect performance constraints orinterfaces with other components. Thus we see ourapproach as compliant with the deeper localized studiesthat need to be preformed in practice at the conceptualand preliminary design stages before proceeding fur-ther with the development process.

5. CASE STUDY

In order to test our approach regarding ADT (and,subsequently, DSM), a case study was undertaken inconjunction with COPE Project sponsor BAE SYS-TEMS. The chosen study concerns the upgrading of anair defense system. The primary form taken by ourresearch was a series of interviews with key membersof the project. These ascertained the nature of the re-quirements, and the structure of the design. This infor-mation was then decomposed using axiomatic designtechniques to identify connectivity between require-ments and design, and how each impacted the other.This was known as the “As Is” solution. Impactingfactors, or constraints, both within the system of design,and of an organizational nature, were studied to modeltheir effect on the process of system design. This wasvalidated with the BAE SYSTEMS Project. A parallelanalysis was conducted to determine how the systemcould have been designed, had ADT [Suh, 1990, 2001]and engineering design standards been applied. Thisbecame the “As Could Be” solution. It was intended that

the comparison between “As Is” and “As Could Be”would indicate any areas where the existing designcould have been improved, thus confirming (or not) ourinitial hypothesis. Additionally, we expected that thecomparison would identify a set of potentially usefulfeatures that have not yet been addressed by the existingsystems engineering tools.

The findings of the study noted that possibly the keyconstraint was that this was an update rather than a newsystem, and that any design was therefore constrainedby what already existed. However, the analysis of re-quirements by the BAE SYSTEMS Project appears tohave been relatively unstructured—and, indeed, an on-going process. This, when coupled to a predominantly“bottom-up” rather than “top-down” analysis tech-nique, meant that the requirements were not decom-posed fully, and therefore the relation of requirementsto design was not fully analyzed. This has the potentialfor delay in the form of extended or unnecessary reworkor iteration—the need for which the Project admittedwas not accounted for. The work breakdown was de-scribed as being intuitive, and based largely on previousexperience. Thus work appeared to be assigned to teamswithout consideration of how all of the modules couldbe integrated together successfully.

The design of the system was forced down specificavenues. This was mainly because it was time con-strained and there was a history of rival bids, which,through the prime contractor, led to decisions regardingthe design being taken that were beyond the control ofthe BAE SYSTEMS team. Furthermore, the fact thatcertain data was provided much later than scheduled,has also placed certain restraints upon the system designprocess. The organizational need requiring the design,initially at least, to be planned in conjunction with twospecific suppliers, also applied certain constraints.

The need to trace and analyze design decisions andchanges has been a central requirement in the design ofcomplex products for quite some time [Guenov, 1996].In the context of this case study, the DSM offered apotential solution to the problem of tracing the effect ofcontextual issues such as project scheduling, and eventsequencing, upon the system design (Pimmler and Ep-pinger, 1994; Ulrich and Eppinger, 1999). Through theapplication of ADT and DSM, our case study researchdiscovered elements of the system design and its con-text which required integration to provide a successfuldesign solution. For example, given that the chosendesign utilized two sensors, one to track the position ofincoming targets, the other to track an outgoing missile,with the outgoing missile potentially being able to beseen by both sensors simultaneously, could be seen asan integration issue which requires the application of


both ADT and DSM. An example of such an applicationis described below.

The approach for deriving the DSM from the DM is“leveled” so that each hierarchical level of the FR-DPdecomposition hierarchy is evaluated in turn. The firststep is to construct the Design Matrix (DM). For thepurposes of demonstrating the approach, a 2nd-levelabstraction of the ADT decomposition hierarchy will beconcentrated upon. A sample of the 2nd-level BAESYSTEMS DM is shown in Figure 9.

The design appears to be a redundant one as thenumber of design parameters is greater than the numberof functional requirements. At this stage it is importantto identify the primary relationships between require-ments and design—i.e., if more than one design pa-rameter is used to satisfy a requirement, identify thedominant one, and where appropriate, secondary rela-tionships if they exist (they do not in this example). Thisis step two of the approach. The primary relationshipsare marked with large X’s, while secondary relation-ships could be depicted with small x’s. The DM nowdescribes the functional linkages between the Func-tional Requirements (FRs) and the Design Parameters(DPs). This serves to define the manner in which theDPs will satisfy the FRs. However, the effects of deci-sions relating to the system such as cost, capacity, andphysical integration are not dealt with particularly well.As a result, a DSM structure can be generated to accom-modate these issues. The next step of the approachconcerns the derivation of an “Architectural” DSM.This is illustrated in Figure 10. A “dummy” FR, denotedby “?,” is added to make the matrix square. Asterisksare used to denote blank cells on the diagonal.

The “Architectural” DSM is created through a com-bination of a method proposed by Dong and Whitney[2001], and triangulation. Thus the rows and columnsare permuted to produce a (predominantly) lower trian-gular matrix. The vertical axis is renumbered accordingto the DP order, and the “Architectural” DSM is theresult. This is the equivalent of the DM, in DSM form,and provides the interface between the DM and DSM.

This stage of the case study analysis revealed aproblem with the design solution. Figure 10 shows afeedback loop between DPs 2.2.3 and 2.2.2, and a

second between 2.2.4 and 2.2.3. However, these feed-back loops had not been anticipated in the design.Analysis of the model revealed that the likely reason fortheir appearance in the structural DSM was a levelingissue: DP 2.2.4 verifies that the output of previous DPsis correct. But the corresponding FR for this DP occursat a lower level of decomposition in the DM. This raisedan issue with the “As Is” model (this being the existingsolution, modeled in Figs. 9 and 10). A review of therequirements then led to the creation of an “As CouldBe” solution, which is shown in Figure 11a. This at-tempted to use axiomatic design method [Suh, 1990,2001] to create a design independently of the existing“As Is” model, to see if improvements were theoreti-cally possible to the design. The main changes (theoriginal FR/DP nomenclature has been retained for easeof comparison) are an additional FR, stating the need toverify the output of processing tasks, and an additionalDP which enables a further verification task, that ofcomparing successive outputs to enhance reliability of

Figure 9. 2nd-level Design Matrix (DM).

Figure 10. 2nd-level “Architectural” DSM.

Figure 11. (a) 2nd-level “As Could Be” Design Matrix; (b)2nd-level “As Could Be” “Architectural” DSM.


missile/target detection, up from a lower level of thedecomposition.

This simplifies the FR-DP relationship—whereas,previously, FR 2.2.2 had been satisfied by three DPswhich embodied the verification algorithms at a lowerlevel of decomposition, the requirement can now be metindependently of processing operations. This may incura cost overhead, depending on the technology used toimplement it, but is representative of the ADT designphilosophy, being in accordance with corollary three ofaxiomatic design [Suh, 1990, 2001]. Finally, FRs 2.2.1and 2.3.1 of the “As Is” solution (Fig. 9) perform thesame operation. These have therefore been combinedinto one. The design solution remains uncompromisedas the DPs can be scheduled to cater for the newly“compressed” FR. It can be seen in Figure 11b that thishas resolved the feedback issue.

The effects of decision-making on the matrices nowneed to be modeled. The decisions can regard a rangeof criteria, such as constraints, physical and logicalconnectivity, and software or hardware integration. Inthe BAE SYSTEMS case, the need exists to combinesoftware functionality onto processor cards. The physi-cal connectivity of the design and the interaction of thefunctions across the processors are therefore relevant.Using the “As Is” solution as a basis, the creation ofthese DSM can be demonstrated by Figures 12 and 13.

For the physical connectivity (denoted by 0’s), it canbe seen that of the “processing” DPs (2.2.1, 2.2.2, and2.2.3), 2.2.3 operates independently, while 2.2.2 pro-vides data to 2.2.1. DPs 2.2.1 and 2.2.3 then feed 2.2.5.The verification DPs (2.2.4 and 2.2.5) also operateindependently, with both passing information to theoutput channel (DP 2.2.6) on completion of the verifi-cation task. This completes an operational cycle.

The integration between software cards, shown inFigure 13, is described by numbers. The numbers on thediagonal indicate which of three processors the DP isassigned to. Thereafter, numbers separated by a commaindicates that two DPs communicate over separate

processors. The first number denotes the card fromwhich the communication is initiated, and the secondnumber indicates which card receives the communica-tion.

An example is that DP 2.2.1, stationed on card 3,communicates with DP 2.2.5, which appears on card 2.The DSM can be separated out into layers (shown byFigs. 12 and 13), to give the system engineer a filteredview of how each of the design elements interacts witheach other in regard to a different design perspective.This is illustrated in Figure 14.

So far, we have shown that the model can highlightthe effect of integration issues of a system design. Thisis shown by the unbroken arrow in Figure 14. However,it is also necessary to be able to understand how thenature of the design is affected by these issues. Thisnecessitates backtracking from the layered DSM to theDM, to understand changes which may have beencaused to the original FR-DP relationship. This is indi-cated by the dotted arrow to the right hand side of Figure14, illustrating how the effect of a constraint or decisionregarding integration may alter the balance betweenFRs and DPs on the original DM.

To provide an example, currently, the processing isverified prior to output. This involves two DPs (2.2.5and 2.2.4), which currently appear on processor cardstwo and three, as shown in Figure 13. If, however, thecapacity and speed constraints of the processor cardsdictated that they be positioned on the same card, thennew physical connectivity would appear on the appro-priate DSM, as both DPs would now be linked via thesame processor card. This is denoted by the shaded areaupon the layered DSM in Figure 14. This in turn woulddictate a new sequence in which the two DPs could beexecuted, bringing about a coupling, and altering thestructural DSM/DM, as indicated by the dashed arrowand letter A.

A further example of this is that an FR specified theneed to detect objects a, b, and c at range x in climatecondition y. To meet this requirement, a DP providesthe required capability. However, cost and capabilityconstraints applied to the DSM mean that it is notpossible to use the DP. The alternative is a DP which,

Figure 12. 2nd-level physical connectivity between designparameters.

Figure 13. 2nd-level interaction between processor cards.


unfortunately, can only detect objects a and c at rangex, and not in condition y. It can be seen that the processof deriving the DSM to study constraints etc. and theireffects has now revealed that the FR on the original DMcannot be met. Thus the FR must be changed to accom-modate the DSM constraints, and this changes the de-sign, as dictated by theorem five of ADT [Suh, 1990,2001]. Consequently, a new design solution must besought.

6. CONCLUSIONS

A novel design decomposition model for complexproduct environments (COPE) is presented. It com-bines Axiomatic Design with Design Structure Matrixto accommodate the iterative nature of the decomposi-tion-integration process. The research to date has dem-onstrated that this approach can bring significantbenefits. An industrial Case Study, conducted as part ofthe research and reported here, has shown that theDM-DSM arrangement can be used to identify theexistence of potential conflicts in the design solution,and allows groups of design parameters to be exploredin greater detail. This approach also appears to providea level of control and transparency to the systems designprocess, and gives the systems architect the opportunityto study proposed changes before they are made, and tounderstand how any such change(s) may produce aknock-on effect throughout the design solution.

Despite the potential which COPE has demonstratedso far, we have not yet solved completely the problemof mixing various levels of details during the decompo-sition process. This is important since deeper localizeddesign studies cannot be avoided in practical situations,it is a part of the de-risking process. Secondly, thedecomposition process forms only a subset of the engi-

neering life cycle and therefore COPE must be evalu-ated in a wider context. So far we have consulted andtried to take into account the established standards forengineering of systems, however, standards implemen-tation is company dependent. In this view, further de-velopment, evaluation and validation of the method, aswell as a specification of the requirements for a decom-position tool form the scope of our future work. Cur-rently we are experimenting with the integration ofADT, DSM, and Requirements Management tools[Guenov and Barker, 2004].

ACKNOWLEDGMENTS

This work is funded by UK EPSRC Research GrantGR/R37067 under the Systems Integration Initiative.We are indebted to BAE SYSTEMS for their help withthe Case Study. We thank the anonymous referees fortheir helpful comments.

REFERENCES

Adept Management website: http://www.adeptmanagement.com/

ANSI/EIA-632-1998, Processes for engineering a system,Electronic Industries Alliance, Government Electronicsand Information Technology Association, EngineeringDepartment, Arlington, VA (approved January 7, 1999).

Axiomatic Design Software Incorporated website:http://www.axiomaticdesign.com/index.cfm

O. Becker, J. Ben-Asher, and I. Ackerman, A method forsystem interface reduction using N2 charts, Syst Eng 3(1)(2000), 27–37.

T.R. Browning, Applying the design structure matrix to sys-tem decomposition and integration problems: A reviewand new directions, IEEE Trans Eng Management 48(2001), 3, 292–306.

Figure 14. Layered DSM and its effect upon the DM.


T.R. Browning, Process integration using the design structurematrix, Syst Eng 5(3) (2002), 180–193.

Qi Dong and D. Whitney, Designing a requirement drivenproduct development process, Proc 13th Int Conf DesTheory Methodol (DTM 2001), September 9–12, 2001,11–20, Pittsburgh, PA.

Design Structure Matrix website: http://www.dsmweb.org/D.D. Frey, E. Jahangir, and F. Engelhard, Computing the

information content of decoupled designs, Res Eng Des12 (2000), 90–102.

M.D. Guenov and S. Barker, Requirements-driven designdecomposition: A method for exploring complex systemarchitecture, Proc ASME 2004 Int Des Eng Tech ConfComput Inform Eng Conf (DETC’04), Salt Lake City, UT,September 28–October 2, 2004, to appear.

M.D. Guenov, Complexity and cost effectiveness measuresfor systems design, Manufacturing Complexity NetworkConf, Downing College, Cambridge, UK, April 9–10,2002, 455–466.

M.D. Guenov, Modelling design change propagation in anintegrated design environment, Computer Model Simula-tion Eng 1 (1996), 353–367.

ISO/IEC 15288 (System Life Cycle Processes), DPC:01/647707, Version 6.0, Bsi, London, 2001.

R.J. Lano, The N2 Chart, Informational Report, TRW, 1977,California.

R.J. Lano, A technique for software and systems design,North-Holland, Amsterdam, 1979.

K.R. McCord and S.D. Eppinger, Managing the integrationproblem in concurrent engineering, Working Paper 3594-93-MSA, MIT Sloan School of Management, Cambridge,MA, 1993.

T.U. Pimmler and S.D. Eppinger, Integration analysis ofproduct decompositions, ASME Des Theory MethodolConf, Minneapolis, MN, September 1994, 343–351.

J.L. Rogers, Tools and techniques for decomposing and man-aging complex design projects, J Aircraft 36(1) (1999),266–274.

D.M. Sharman and A. Yassine, Characterizing complex prod-uct architectures, Syst Eng 7(1) (2004), 35–60.

W.P. Stevens, G.J. Myers, and L.L. Constantine, Structureddesign, IBM Syst J 13(2) (1974), 115–139.

D.V. Steward, The design structure system, Document67APE6, General Electric, Schenectady, NY, September1967.

D.V. Steward, The design structure system: A method formanaging the design of complex systems, IEEE Trans EngManagement EM-28, 3 (August 1981), 71–74.

N.P. Suh, The principles of design, Oxford University Press,New York, 1990.

N.P. Suh, Axiomatic design: Advances and applications, Ox-ford University Press, New York, 2001.

M.T. Talbott, H.L. Burks, R.W. Shaw, M. Amundsen, K.K.Hutchison, and D.D. Strasburg, Method and Apparatus forSystem Design, U.S. Pat. No. 5,355,317, October 11,1994(a).

M.T. Talbott, H.L. Burks, R.W. Shaw, M. Amundsen, K.K.Hutchison, and D.D. Strasburg, Method and Apparatus forAiding System Design, U.S. Pat. No. 5,357,440, October18, 1994(b).

D. Tate, A roadmap for decomposition: Activities, theories,and tools for system design, Ph.D. Thesis, Department ofMechanical Engineering, Massachusetts Institute of Tech-nology, Cambridge, MA, February 1999.

K.T. Ulrich and S.D. Eppinger, Product design and develop-ment, 2nd edition, McGraw-Hill Education (ISE Edi-tions), New York, 1999.

Marin D. Guenov is a Senior Lecturer (Advanced Engineering Methods) in the School of Engineering,Department of Power Propulsion and Aerospace Engineering at Cranfield University, UK. He holds anMEng in Mechanical Engineering and a Ph.D. in Materials Handling Systems and Operational Research.Currently Dr. Guenov leads national and international multidisciplinary research projects supported bythe European aerospace industry in the areas of design of complex systems, modeling and simulation forsynthetic environments, multidisciplinary design analysis and optimization, and infrastructures forcollaborative design. Dr. Guenov is a member of the Royal Aeronautical Society and The Association ofCost Engineers and is a Charted Engineer.

Stephen G. Barker is a Research Officer in the School of Engineering, Department of Power Propulsionand Aerospace Engineering at Cranfield University, UK. Dr. Barker holds a BSc. (Hons.) in ComputerStudies, and researched Applied Engineering Process Management for his Ph.D. Currently, Dr. Barker ispart of the COPE (COmplex Product Environment) research team, which investigates “Decomposition-Integration” issues within Complex Product Development programs. Dr. Barker has previously workedas a lecturer and tutor in the fields of Network Communications and Operations Management.


regular paper application of axiomatic design and design ... of papers for... · the foundation...

Documents