application of axiomaticdesign and design structure matrix to thedecomposition ofengineering systems

8/7/2019 Application of AxiomaticDesign and Design Structure Matrix to theDecomposition ofEngineering Systems

1/12

Application of Axiomatic

Design 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 Design

Structure Matrices (DSM) provide structured representation of the system development

context. In COPE, the DM and the DSM co-evolve. Traversing between the two types of

matrices allows for some control in the application of the system knowledge which surrounds

the decision making process and the definition of the system architecture. It is argued that

this approach describes better the design process of complex products which is constrained

by the need to utilise existing manufacturing processes, to apply discrete technological

innovations and to accommodate work-share and supply chain agreements. Presented is an

industrial case study which demonstrated the feasibility of the model. 2004 Wiley Peri-

odicals, Inc. Syst Eng 8: 2940, 2005

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

integration

1. INTRODUCTION

Standards for the engineering of systems such as EIA

632 and ISO/IEC 15288 support a seamless process of

converting customer needs into systems/technical re-

quirements, which are subsequently transformed into

logical 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/R37067

under the Systems Integration Initiative.

Systems Engineering, Vol. 8, No. 1, 2005

2004 Wiley Periodicals, Inc.

29


2/12

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 the

large number of constraints involvedtechnical, eco-

nomic and even political. The systems approach of

tackling 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 will

consider, as early as possible, all relevant requirements

and constraints. IPTs are now a common practice in

industries such as the defense and aerospace. What

seems to be lacking, however, are high-level support

tools which could help the systems teams and architects

draw together consistently a vast amount of information

needed for the requirements and the design decompo-

sition of the system. Currently there exist a number of

requirements management tools, which fulfill only par-tially this need. For instance, Acclaro [Suh, 2001;

Axiomatic Design Software Inc. website] is designed

to evolve the systems design in accordance with the

rules of Axiomatic Design Theory (ADT). The software

allows the systems designer to enter the top-level Func-

tional Requirements (FRs) and Design Parameters

(DPs), and to decompose and map those in two tree

hierarchies and associated design matrices. However,

Acclaro is concerned primarily with functional decom-

position, and not with explicit constraint mitigation and

control. SLATE, on the other hand [Talbott et al., 1994a,

1994b], now part of the EDS Team Center suite of

software, is a good example of a powerful requirementsmanagement system. It provides constructs not only to

build requirements and product hierarchies, but also

allows the designer to attach constraints and text frag-

ments to each item within each layer of the system

decomposition, and also provides a good level of trace-

ability of nonfunctional requirements throughout the

design decomposition. SLATE, however, would only

produce results which reflect the experience of those

using it. Observations made during the industrial case

study suggest that, in practice, even experienced sys-

tems designers are too quick to follow a particular

solution path, relying heavily on existing knowledge

and 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 the

ability to group related design elements. There are

software tools available which are based on the DSM.

These include DeMAID [Rogers, 1999], which was

developed 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 construction

industry.

This paper presents work which has concentrated

particularly on the integration of ADT and DSM. The

conjecture is that ADT and DSM are complementary

parts of the decompositionintegration problem, where

the former is more concerned with mapping of func-

tional requirements to design parameters, while the

latter is better suited to modeling the interactions and

the integration of the design parameters. The mainobjective of the work is to investigate to what extent

those two methods can be integrated and to evaluate the

approach in a realistic industrial setting. The potential

value of this work is that it provides a means of relating

component integration to system functionality, which

otherwise is not available but is essential during the

early stages of the design process. The following two

sections present a brief summary of ADT and DSM,

respectively. Section 4 outlines the Methodology, while

Section 5 describes the industrial case study undertaken

to test and evaluate the approach. Finally conclusions

are 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 axioms

are:

Figure 1. High-level view of the systems engineering process

(adapted from ANSI/EIA-632-1998).

30 GUENOV AND BARKER


3/12

Axiom 1. Maintain the independence of the func-

tional requirements.1

Axiom 2. Minimize the information content of the

design.

Axiom 1 requires that Functional Requirements

(FRs) be independent of one another, which enables

each FR to be satisfiedwithoutaffecting any of the other

FRs. Thus there is no coupling of function where it can

be avoided, and the design remains as uncomplicated as

possible. Axiom 2 provides a quantitative measure of

the merits of a given design, and thus it is useful in

selecting the best among the designs which satisfy

axiom one [Suh, 2001]. Generally, the design that uses

the least information is superior. This is explained in

more 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 of

iterations, the design process converts customers needs

(CNs) into Functional Requirements (FRs) and con-

straints (Cs), which in turn are embodied into Design

Parameters (DPs). Functional Requirements can be de-

fined as a minimum set of independent requirements

that completely characterises the functional needs of the

product in the functional domain; Design Parameters

are the key physical variables in the physical domain

that 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 of

the overall functional requirementin practice this

should correspond to the top system requirement. Be-

fore decomposing a FR at a particular hierarchical level

in the functional domain, the corresponding DP must

be determined for the same hierarchical level in the

physical domain. This iterative process is called zigzag-

ging (see also Tate [1999] for a more thorough treatment

of the decomposition problem).Zigzagging also involves the other domains since

manufacturing considerations may constrain design de-

cisions, while over-specified requirements could vir-

tually prohibit the discovery of feasible design

solutions. At each level of the design hierarchy, the

relations (the dependencies) between the FRs and the

DPs can be represented in an equation of the form:

FR = [A]DP, (1)

where each element of the design matrix [A] can be

expressed 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 to

satisfy given FRs. This is required by Axiom 1 (Inde-

pendence). Each element Aij is represented as a partial

derivative to indicate dependency of a FRi on aDPj. For

simplicity the value of an element Aij can be expressed

as 0 (i.e., the functional requirement does not depend

on the particular design parameter), or otherwise X.

Depending on the type of resulting design matrix [A],

three types of designs exist: uncoupled, decoupled and

coupled (Fig. 3).

Uncoupled design occurs when each FR is satisfied

by exactly one DP. The resulting matrix is diagonal, and

the 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 a

sequence exists, where by adjusting DPs in a certain

order, the FRs can be satisfied. The design matrix of a

coupled design contains mostly nonzero elements, and

thus the FRs cannot be satisfied independently. A cou-

pled design can be decoupled, for example, by adding

components to carry out specific functionshowever,

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


4/12

One additional factor that affects coupling is the

number of FRs, m, relative to the number of DPs, n. If

m > n, then the design is either coupled or the FRs

cannot be satisfied. Ifm < n, then the design is redun-

dant. (Note that in both cases the design matrix [A] is

not square.)

In addition to the design axioms, ADT is governed

by a set of rules, which are formalized into theorems

and corollaries. Of particularly relevance to this re-

search are Corollary 3 and Theorem 5 which originate

from 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 by

selection of a completely different set of FRs, the

design solution given by the original DPs cannot

satisfy the new set of FRs. Consequently, a new

design solution must be sought.

The Second Design Axiom states that minimizing the

information contentof a DP increases the probability

of success of satisfying a function. The information

content is defined by the equation

I= log

systemrange

commonrange

. (2)

In Figure 4 design range is the tolerance within which

the DP can vary; system range is the capability of the

(manufacturing) system; common range is the overlap

between 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 computed

by summation of the individual information contents of

all DPs only if the latter are probabilistically inde-

pendent. Frey, Jahangir, and Engelhard [2000] proved

that simple summation cannot be performed for decou-

pled designs and offered a method for computing infor-

mation content. There is no exact method for computing

the 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 Systems

Engineering community, before the introduction of the

DSM. The DSM has become increasingly popular as a

means of planning product development, project plan-

ning and management, systems engineering, and organ-

izational development [Browning, 2001, 2002]. The

concept dates back to the 1960s and was not actually

published until 1981 [Steward, 1981]. The Design

Structure 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) are

required to start a certain activity and where does the

information generated by the activity feed intoi.e.,

which other tasks within the matrix utilize the output

information [Design Structure Matrix website]. There

are 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. The

solid line represents uniform distribution, the dotted line a

nonuniform distribution (adapted from Suh [1990]).



5/12

elements (e.g., design parameters or activities) are fully

independent of each other, the sequential, decoupled

configuration, in which the second parameter is de-

pendent upon the output of the first, and the fully

coupled configuration, in which parameters are interde-pendent upon each other. Figure 6 shows how a DSM

may be used. The crosses below the diagonal in figure

6a represent a forward flow of information, while those

above the diagonal depict a feedback loop. The DSM

can be used to reorder, or partition design elements,

to minimize feedback loops (Fig. 6b). This is achieved

by 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 matrixin practice this means

producing a set of assumptions for the (as yet) unknown

information. The DSM must then be repartitioned.DSMs can also be used to create and sequence modules

or clusters [Sharman and Yassine, 2004], which are

either 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 scheduling

and management of activities, over time

This research is concerned with the use of DSM to

model the integration and connectivity (logical and

physical) between design embodiments of system ar-

chitectures, and to trace the effects of this integration

on the functionality of the system.

While DSM provides a powerful technique for the

analysis 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] point

out, it is not possible to obtain a DSM for a new

product that has never been designed before. Addition-

ally, Dong and Whitney maintain that, although theDSM captures the interactions between elements within

a system, it fails to record explicitly the reasons for

these interactions.

4. DECOMPOSITION-INTEGRATIONPROCESS USING ADT AND DSM

ADT postulates that a zigzagging process for FR-DP

mapping that takes place in a solution neutral envi-

Figure 5. DSM configurations.

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



6/12

ronment ensures better design. This, however, can

rarely happen in practice, particularly in complex prod-

uct environments, where economic considerations dic-

tate maximum possible utilization of mature designs

and 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 physical

connectivity), and so forth. As discussed in the previous

section, DSM is a mature method capable of capturing

the interaction between design parameters, but by defi-

nition, it is fully known only for products that have

already been designed.

These considerations led us to the idea that the

decomposition integration problem would be better

modeled as a co-evolution of ADT matrices and DSMs.

The generic representation of the process which we

named COPE (decomposition-integration of COmplex

Product Environments) is depicted in Figure 7. InCOPE, ADT is used to map the decomposition of

functional requirements to design parameters (FR-DP).

At each decomposition level various knowledge

sources are consulted in order to take into consideration

constraints originating from all stakeholders. The

knowledge sources include unstructured ones (e.g., em-

ployees tacit knowledge and various unpublished

documents) as well as structured/coded sources. Exam-

ples of the latter include government regulations, DSMs

of past designs (also processes), companys own design

standards, synthetic and analytical models, knowledge

bases, and so forth. Technology bricks is a generic

term which encompasses chunks of new technology

which is mature enough to be applied in the new product

with potential competitive advantage.

As the decomposition progresses, essential design

studies must be performed, including spatial layout,

performance and capacity constraints checks, and/or

more detailed design of particular, riskier aspects of theproduct, resulting in more interactions between the

design parameters. As a consequence, Corollary 3 of

ADT may be violated or requirements may need to be

added or changed at a higher level, which would require

a repetition of the decomposition phase (see Theorem

5 of ADT).

The first step to linking ADT and DSM was made

by Dong and Whitney [2001], who showed that if the

Axiomatic design matrix (DM) can be expressed ana-

lytically and one design parameter (DP) is dominant in

satisfying a particular functional requirement (FR),

then the triangulated design matrix is equivalent to theDSM of the design parameters. The algorithm consists

of 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 the

main diagonal.

The authors show that choosing the dominant entries is

important as it ensures the convergence of the design

process.

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



7/12

Unfortunately, when designing complex (physical

or software) systems the FRs are satisfied by modules

or other (sub)systems or components and therefore the

design matrix cannot be represented analytically; and it

may not necessarily be square either. In order to over-

come this restriction, we have devised a decomposition

procedure (Fig. 8) in which the design and structurematrices co-evolve.

The procedure starts with the construction of the DM

of the FR-DP hierarchy. At this level the dominant DPs

are identified. The DM is manipulated [see Dong and

Whitney, 2001] so that it becomes lower triangular with

dominant entries, X, on the main diagonal. The result

is the Architectural DSM, that is, a DSM derived only

from the functional view of the product. At this stage a

certain amount of layout/spatial design may need to be

done, 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). The

resulting design may affect the functionality of the

systems, for example, grouping components together

may couple functions. If that is the case, requirements

may need to change or more design parameters may

need to be added. This means that the design decompo-

Figure 8. COPE decompositionintegration procedure.



8/12

sition has to be reconsidered from the highest level (see

Theorem 5). The decomposition ends when a leaf node

is encountered, that is, further decomposition will

change the subject of the requirement. In terms of

systems engineering standards (see, e.g., ANSI/EIA-

632), a leaf node can be approximately described as a

specified/assigned requirement.

Perhaps it is worth emphasising that the COPE pro-

cedure aims to retrace the AD-DSM connection at each

level of the decomposition rather than at reaching a leaf

node of the DP hierarchy. This is justified by the fact

that in practice one can be very restricted in performing

the entire decomposition in a solution neutral envi-

ronment (as advocated by ADT)there are, for exam-

ple, cost considerations at the outset of the project

which result in targets on reusability of components and

manufacturing processes from previous products and

/or targets on commonality of components with other

existing product lines. Furthermore, one sometimesneeds to decompose much deeper one branch of the

FR-DP hierarchy relative to other branches in order to

de-risk the solution. For example, one may need to

know if a particular material can be used before con-

tinuing further with the decomposition since this par-

ticular material may affect performance constraints or

interfaces with other components. Thus we see our

approach as compliant with the deeper localized studies

that need to be preformed in practice at the conceptual

and 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 in

conjunction with COPE Project sponsor BAE SYS-

TEMS. The chosen study concerns the upgrading of an

air defense system. The primary form taken by our

research was a series of interviews with key members

of the project. These ascertained the nature of the re-

quirements, and the structure of the design. This infor-

mation was then decomposed using axiomatic design

techniques to identify connectivity between require-

ments and design, and how each impacted the other.This was known as the As Is solution. Impacting

factors, or constraints, both within the system of design,

and of an organizational nature, were studied to model

their effect on the process of system design. This was

validated with the BAE SYSTEMS Project. A parallel

analysis was conducted to determine how the system

could have been designed, had ADT [Suh, 1990, 2001]

and engineering design standards been applied. This

became 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 design

could have been improved, thus confirming (or not) our

initial hypothesis. Additionally, we expected that the

comparison would identify a set of potentially useful

features that have not yet been addressed by the existing

systems engineering tools.

The findings of the study noted that possibly the key

constraint was that this was an update rather than a new

system, and that any design was therefore constrained

by what already existed. However, the analysis of re-

quirements by the BAE SYSTEMS Project appears to

have been relatively unstructuredand, 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 requirements

to design was not fully analyzed. This has the potential

for delay in the form of extended or unnecessary reworkor iterationthe need for which the Project admitted

was not accounted for. The work breakdown was de-

scribed as being intuitive, and based largely on previous

experience. Thus work appeared to be assigned to teams

without consideration of how all of the modules could

be integrated together successfully.

The design of the system was forced down specific

avenues. 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 regarding

the design being taken that were beyond the control of

the BAE SYSTEMS team. Furthermore, the fact that

certain data was provided much later than scheduled,

has also placed certain restraints upon the system design

process. The organizational need requiring the design,

initially at least, to be planned in conjunction with two

specific suppliers, also applied certain constraints.

The need to trace and analyze design decisions and

changes has been a central requirement in the design of

complex products for quite some time [Guenov, 1996].

In the context of this case study, the DSM offered a

potential solution to the problem of tracing the effect of

contextual issues such as project scheduling, and event

sequencing, upon the system design (Pimmler and Ep-

pinger, 1994; Ulrich and Eppinger, 1999). Through theapplication of ADT and DSM, our case study research

discovered elements of the system design and its con-

text which required integration to provide a successful

design solution. For example, given that the chosen

design utilized two sensors, one to track the position of

incoming targets, the other to track an outgoing missile,

with the outgoing missile potentially being able to be

seen by both sensors simultaneously, could be seen as

an integration issue which requires the application of



9/12

both ADT and DSM. An example of such an application

is described below.

The approach for deriving the DSM from the DM is

leveled so that each hierarchical level of the FR-DP

decomposition hierarchy is evaluated in turn. The first

step is to construct the Design Matrix (DM). For the

purposes of demonstrating the approach, a 2nd-level

abstraction of the ADT decomposition hierarchy will be

concentrated upon. A sample of the 2nd-level BAESYSTEMS DM is shown in Figure 9.

The design appears to be a redundant one as the

number of design parameters is greater than the number

of functional requirements. At this stage it is important

to identify the primary relationships between require-

ments and designi.e., if more than one design pa-

rameter is used to satisfy a requirement, identify the

dominant one, and where appropriate, secondary rela-

tionships if they exist (they do not in this example). This

is step two of the approach. The primary relationships

are marked with large Xs, while secondary relation-

ships could be depicted with small xs. The DM now

describes the functional linkages between the Func-tional Requirements (FRs) and the Design Parameters

(DPs). This serves to define the manner in which the

DPs will satisfy the FRs. However, the effects of deci-

sions relating to the system such as cost, capacity, and

physical 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 approach

concerns the derivation of an Architectural DSM.

This is illustrated in Figure 10. A dummy FR, denoted

by ?, is added to make the matrix square. Asterisks

are 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 columns

are permuted to produce a (predominantly) lower trian-

gular matrix. The vertical axis is renumbered according

to the DP order, and the Architectural DSM is the

result. 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 a

problem with the design solution. Figure 10 shows a

feedback 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 for

their appearance in the structural DSM was a leveling

issue: DP 2.2.4 verifies that the output of previous DPs

is correct. But the corresponding FR for this DP occurs

at a lower level of decomposition in the DM. This raised

an issue with the As Is model (this being the existing

solution, modeled in Figs. 9 and 10). A review of the

requirements then led to the creation of an As Could

Be 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 (the

original FR/DP nomenclature has been retained for ease

of comparison) are an additional FR, stating the need to

verify the output of processing tasks, and an additional

DP which enables a further verification task, that of

comparing 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.



10/12

missile/target detection, up from a lower level of the

decomposition.

This simplifies the FR-DP relationshipwhereas,

previously, FR 2.2.2 had been satisfied by three DPs

which embodied the verification algorithms at a lower

level of decomposition, the requirement can now be met

independently of processing operations. This may incur

a cost overhead, depending on the technology used to

implement it, but is representative of the ADT design

philosophy, being in accordance with corollary three of

axiomatic design [Suh, 1990, 2001]. Finally, FRs 2.2.1

and 2.3.1 of the As Is solution (Fig. 9) perform the

same operation. These have therefore been combined

into one. The design solution remains uncompromised

as the DPs can be scheduled to cater for the newly

compressed FR. It can be seen in Figure 11b that this

has resolved the feedback issue.

The effects of decision-making on the matrices now

need to be modeled. The decisions can regard a rangeof criteria, such as constraints, physical and logical

connectivity, and software or hardware integration. In

the BAE SYSTEMS case, the need exists to combine

software functionality onto processor cards. The physi-

cal connectivity of the design and the interaction of the

functions across the processors are therefore relevant.

Using the As Is solution as a basis, the creation of

these DSM can be demonstrated by Figures 12 and 13.

For the physical connectivity (denoted by 0s), it can

be seen that of the processing DPs (2.2.1, 2.2.2, and

2.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 operate

independently, with both passing information to the

output channel (DP 2.2.6) on completion of the verifi-

cation task. This completes an operational cycle.

The integration between software cards, shown in

Figure 13, is described by numbers. The numbers on the

diagonal indicate which of three processors the DP is

assigned to. Thereafter, numbers separated by a comma

indicates that two DPs communicate over separate

processors. The first number denotes the card from

which the communication is initiated, and the second

number 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 by

Figs. 12 and 13), to give the system engineer a filtered

view of how each of the design elements interacts with

each other in regard to a different design perspective.

This is illustrated in Figure 14.

So far, we have shown that the model can highlight

the effect of integration issues of a system design. This

is shown by the unbroken arrow in Figure 14. However,

it is also necessary to be able to understand how the

nature of the design is affected by these issues. This

necessitates backtracking from the layered DSM to the

DM, to understand changes which may have been

caused to the original FR-DP relationship. This is indi-

cated by the dotted arrow to the right hand side of Figure

14, illustrating how the effect of a constraint or decisionregarding integration may alter the balance between

FRs and DPs on the original DM.

To provide an example, currently, the processing is

verified prior to output. This involves two DPs (2.2.5

and 2.2.4), which currently appear on processor cards

two and three, as shown in Figure 13. If, however, the

capacity and speed constraints of the processor cards

dictated that they be positioned on the same card, then

new physical connectivity would appear on the appro-

priate DSM, as both DPs would now be linked via the

same processor card. This is denoted by the shaded area

upon the layered DSM in Figure 14. This in turn would

dictate a new sequence in which the two DPs could beexecuted, bringing about a coupling, and altering the

structural DSM/DM, as indicated by the dashed arrow

and letter A.

A further example of this is that an FR specified the

need to detect objects a, b, and c at range x in climate

condition y. To meet this requirement, a DP provides

the required capability. However, cost and capability

constraints applied to the DSM mean that it is not

possible to use the DP. The alternative is a DP which,Figure 12. 2nd-level physical connectivity between design

parameters.

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



11/12

unfortunately, can only detect objects a and c at range

x, and not in condition y. It can be seen that the processof deriving the DSM to study constraints etc. and their

effects has now revealed that the FR on the original DM

cannot 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 be

sought.

6. CONCLUSIONS

A novel design decomposition model for complex

product environments (COPE) is presented. It com-bines Axiomatic Design with Design Structure Matrix

to accommodate the iterative nature of the decomposi-

tion-integration process. The research to date has dem-

onstrated that this approach can bring significant

benefits. An industrial Case Study, conducted as part of

the research and reported here, has shown that the

DM-DSM arrangement can be used to identify the

existence of potential conflicts in the design solution,

and allows groups of design parameters to be explored

in greater detail. This approach also appears to provide

a level of control and transparency to the systems design

process, and gives the systems architect the opportunity

to study proposed changes before they are made, and tounderstand how any such change(s) may produce a

knock-on effect throughout the design solution.

Despite the potential which COPE has demonstrated

so far, we have not yet solved completely the problem

of mixing various levels of details during the decompo-

sition process. This is important since deeper localized

design studies cannot be avoided in practical situations,

it is a part of the de-risking process. Secondly, the

decomposition 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 for

engineering of systems, however, standards implemen-

tation is company dependent. In this view, further de-

velopment, evaluation and validation of the method, as

well 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 of

ADT, DSM, and Requirements Management tools

[Guenov and Barker, 2004].

ACKNOWLEDGMENTS

This work is funded by UK EPSRC Research Grant

GR/R37067 under the Systems Integration Initiative.

We are indebted to BAE SYSTEMS for their help with

the Case Study. We thank the anonymous referees for

their helpful comments.

REFERENCES

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

com/

ANSI/EIA-632-1998, Processes for engineering a system,

Electronic Industries Alliance, Government Electronics

and 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 for

system interface reduction using N2 charts, Syst Eng 3(1)

(2000), 2737.

T.R. Browning, Applying the design structure matrix to sys-

tem decomposition and integration problems: A review

and new directions, IEEE Trans Eng Management 48

(2001), 3, 292306.

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



12/12

T.R. Browning, Process integration using the design structure

matrix, Syst Eng 5(3) (2002), 180193.

Qi Dong and D. Whitney, Designing a requirement driven

product development process, Proc 13th Int Conf Des

Theory Methodol (DTM 2001), September 912, 2001,

1120, 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 Des

12 (2000), 90102.

M.D. Guenov and S. Barker, Requirements-driven design

decomposition: A method for exploring complex system

architecture, Proc ASME 2004 Int Des Eng Tech Conf

Comput Inform Eng Conf (DETC04), Salt Lake City, UT,

September 28October 2, 2004, to appear.

M.D. Guenov, Complexity and cost effectiveness measures

for systems design, Manufacturing Complexity Network

Conf, Downing College, Cambridge, UK, April 910,

2002, 455466.

M.D. Guenov, Modelling design change propagation in an

integrated design environment, Computer Model Simula-tion Eng 1 (1996), 353367.

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 integration

problem 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 of

product decompositions, ASME Des Theory Methodol

Conf, Minneapolis, MN, September 1994, 343351.

J.L. Rogers, Tools and techniques for decomposing and man-

aging complex design projects, J Aircraft 36(1) (1999),

266274.

D.M. Sharman and A. Yassine, Characterizing complex prod-

uct architectures, Syst Eng 7(1) (2004), 3560.

W.P. Stevens, G.J. Myers, and L.L. Constantine, Structured

design, IBM Syst J 13(2) (1974), 115139.D.V. Steward, The design structure system, Document

67APE6, General Electric, Schenectady, NY, September

1967.

D.V. Steward, The design structure system: A method for

managing the design of complex systems, IEEE Trans Eng

Management EM-28, 3 (August 1981), 7174.

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 for

System 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 for

Aiding System Design, U.S. Pat. No. 5,357,440, October

18, 1994(b).

D. Tate, A roadmap for decomposition: Activities, theories,

and tools for system design, Ph.D. Thesis, Department of

Mechanical 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 an

MEng 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 by

the European aerospace industry in the areas of design of complex systems, modeling and simulation for

synthetic environments, multidisciplinary design analysis and optimization, and infrastructures for

collaborative design. Dr. Guenov is a member of the Royal Aeronautical Society and The Association of

Cost Engineers and is a Charted Engineer.

Stephen G. Barker is a Research Officer in the School of Engineering, Department of Power Propulsion

and Aerospace Engineering at Cranfield University, UK. Dr. Barker holds a BSc. (Hons.) in Computer

Studies, and researched Applied Engineering Process Management for his Ph.D. Currently, Dr. Barker is

part of the COPE (COmplex Product Environment) research team, which investigates Decomposition-

Integration issues within Complex Product Development programs. Dr. Barker has previously worked

as a lecturer and tutor in the fields of Network Communications and Operations Management.


application of axiomaticdesign and design structure matrix to thedecomposition ofengineering systems

Documents