(navigation image)
Home American Libraries | Canadian Libraries | Universal Library | Community Texts | Project Gutenberg | Children's Library | Biodiversity Heritage Library | Additional Collections
Search: Advanced Search
Anonymous User (login or join us)
Upload
See other formats

Full text of "Development of tools to represent deisgn procedures"

HD28 

.M414 

no. 



91 



gevEv 




- -.t5-« 



-..::9' 



WORKING PAPER 
ALFRED P. SLOAN SCHOOL OF MANAGEMENT 



Development of Tools to 
Represent Design Procedures 

David A. Gebala 
Steven D. Eppinger 
Daniel E. Whitney 



WP# 3281-91-MS 



April 1991 



MASSACHUSETTS 

INSTITUTE OF TECHNOLOGY 

50 MEMORIAL DRIVE 

CAMBRIDGE, MASSACHUSETTS 02139 



Development of Tools to 
Represent Design Procedures 

David A. Gebala 
Steven D. Eppinger 
Daniel E. Whitney 

WP# 3281-91-MS April 1991 



Development of Tools 
to Represent Design Procedures 

David A. Gebala 

Steven D. Eppinger 

Daniel E. Whitney 

Massachussetts Institute of Technology 
Cambridge, MA 02139 

Abstract 

This paper is based upon the premise that in practice, design 
procedures are rather methodical and can therefore be studied and 
improved. We present model-based approaches toward understanding 
such design activities in order to improve design practices. Several 
modeling methodologies are presented and compared on their ability to 
capture relevant information about design activities and their ability to 
provide insight into the performance of design processes. A detailed 
description of these models and examples of each are provided for 
comparison. These models contribute significantly to our understanding of 
current design practice and yield to analytical tools which facilitate 
formulation and implementation of improved procedures. In the course of 
the discussion, limitations of the currently used models are identified, and 
an enhanced representation is proposed to overcome these limitations. 

Introduction 

International competition has heightened the need to develop high 
quality products which can compete in the global marketplace. As a result 
of this increased competition, the pace of product development has 
quickened, forcing manufacturers into an era in which continuous quality 
improvement is a matter of survival, not simply competitive advantage. As 
the time scale of the product life cycle decreases and the demand for quality 
increases, one area of attention has been improving products through better 
designs. The integrative and definitive nature of the design activity is 
responsible for determining as much as 80% of a product's functionality 
and cost [4]. The high leverage available during the design activity can 
completely determine a product's success or failure. Design's central role 
as an important engineering and business concern has recently gained 
attention in companies and universities around the world. 

In the past, many researchers may have dismissed design because it 
lacks the scientific rigor of some other disciplines. However, as academia 
and industry invest more effort into improving the design process, there is 
an increased need for a better understanding of the activity to facilitate the 
formulation of new design paradigms. We believe that while most design 



2 

activities performed in industry are well established, they are, nevertheless, 
poorly understood. 

We seek improved understanding of both new and established design 
procedures to provide at least two distinct opportunities: (1) to allow 
engineers to execute the design activity with more insight into difficulties 
encountered during design, and (2) to provide an opportunity for better 
management of the design activity, including implementation of new 
design strategies. Specifically, this work addresses design process 
improvement questions which engineers and their managers should be 
asking: 

1) Why does it take so long to develop each new generation of our 

product? 

2) Wh'-^h engineering functions might be combined to accelerate 

design progress? 

3) Where is communication most important in design? 

4) What are the driving factors in our design problem? 

5) How can we implement concurrent engineering? 

The approach in this work is to facilitate the improvement of product 
design procedures through formulating and testing models of the design 
activity. Models are constructed by first observing the design process and 
formulating representations which capture the aspects considered 
important. A model serves its purpose if it is able to answer important 
questions about the subject it represents. If the model's behavior reflects 
the system's behavior, the model can be used in some predictive capacity to 
explore the effects which altering the system can produce. If the 
representation is not able to answer such questions, another model must be 
formulated and tested. The models sui'veyed below will be judged on their 
ability to accurately represent design activities and their ability to facilitate 
exploration of new design strategies. 

In choosing a model of the design process, it is important to keep 
some objectives in mind. Winston proposes several requirements which 
problem representations should attempt to satisfy [24]. Good 
representations 

•make the important things explicit; 

•expose natural constraints, facilitating computations; 

•are complete; 

•are concise; 

•are transparent to its users; and 

•suppress detail when it is not required. 



These criteria can serve as guidelines for representations which can 
advance our undei'standing of the complex activities which are collectively 
known as design. 

The first section of this paper presents three models of the design 
activity commonly used in practice. We review the historical development 
of the Program Evaluation and Review Technique (PERT), Structured 
Analysis and Design Technique (SADT or IDEF), and the use of Design 
Structure Matrices (DSM). We also present examples of their use in design 
modeling and survey them critically to identify any shortcomings. In 
particular, we examine their ability to reveal the difficult iterations 
encountered in execution of the design activity. 

In the following section, we compare the representational capacity of 
the two techniques best able to capture the iterative flow of design 
information. Using precedence data describing the design of an automotive 
component, alternate representations of a design process were constructed. 
We then use the precedence matrices to model several other design 
activities, and to provide valuable insight into how information flows 
during these design procedures. We close the section with an overview of 
analysis tools which are able to suggest improved design procedures. 

Finally, we will address the issues which the representations are not 
able to model. Our work in modeling and analyzing design has identified 
important aspects of the design process which are not incorporated into any 
of the present models. For example, the existing models only represent 
interdependence, but do not specify the extent of interdependence. A 
possible solution is proposed to incorporate much more information into the 
models to enhance their utility. One type of quantitative model based on the 
precedence matrix is presented in an example. 



Existing Representations 

As the importance of product design in manufacturing competition 
becomes widely recognized, the need to understand and improve the design 
activities also becomes evident. The first attempts to model and answer 
questions about design procedures used simple project planning techniques 
(PERT) which had proven useful in the scheduling and management of 
large research and development projects. However, these simple tool did 
not contribute to understanding design iteration because they failed to 
represent such flows. This need to represent iteration explicitly was met by 
techniques such as SADT. Finally, we have found that precedence 
matrices such as DSM allow complex interactions to be shown more easily. 
These three most commonly used representations are discussed below. 

1. Program Evaluation and Review Technique 

The Program Evaluation and Review Technique (PERT) is one of the 
most widely used project management tools. PERT was developed in the 
late 1950's to plan and manage the development of the Polaris missile [23]. 
A project is represented as a series of activities, each with a set of 
predecessors whose results are required before the new activity can be 
started. The PERT chart which documents the project is a network of nodes 
interconnected by arcs. Although there is some flexibility in defining the 
nodes and arcs, it is most common to associate one activity with each node 
and to denote precedence using a directed arc between nodes. To add the 
time to the PERT chart, we ca label the arcs with the task durations. 
Uncertainties in these time estimates can be considered in the calculation 
of the overall project completion time. An example of a PERT chart with 
deterministic time estimates is presented in Figure 1. 




Figure 1. PERT Chart 

If the time required for each of the activities has a small variability, 
the PERT chart can be subjected directly to Critical Path Method (CPM) 
analysis. CPM allows the manager to identify which activities affect the 
completion date (activities on the critical path) and which activities are 
irrelevant to accelerating project completion (activities with slack). By 



analyzing the critical path, the manager can perform cost vs. time trade-off 
analysis [12]. The cost of applying more resources to an activity can be 
evaluated by the effect on the project completion date. The critical path is 
the one marked by heavy arcs in Figure 1. 

The PERT methodology is well suited for certain processes which 
involve sequential flows of well characterized steps. For example, PERT is 
a popular planning tool for construction and assembly operations which 
typically involve little flexibility in their precedence relations. In order to 
make a particular subassembly, one needs all of its components. The 
strong dependency which is found in the assembly and construction 
activities is easily represented by the series of arcs and nodes in a PERT 
chart. 

PERT charts have also found widespread application in large scale 
research and development projects requiring coordination of numerous 
activities. Again, the projects flow sequentially: before a certain task is 
activated, the previous task must be completed. The success of this 
technique in the development of the Polaris missile prompted the U.S. 
Government to require its use on all major government projects [23]. Using 
PERT to model the design activity seems to be a logical choice since design, 
too, is a large project requiring coordination of many efforts and many 
different activities. 

Using PERT to Model Design Activities 

Using PERT charts to model the design process seems a 
straightforward application of this technique. The design activity must be 
decomposed into smaller activities and their precedences noted. The 
duration of each activity can be used to enhance the chart's information 
content. However, the technique is not able to capture the complexities of 
the design activity; PERT is limited by the implicit requirement that all 
activities are sequentially dependent. Once an activity has been performed, 
it is not performed again. In a PERT chart, such an occurrence would 
create a cycle in the path. Such cycles in the PERT chart represent logical 
inconsistencies which must be removed before any critical path 
calculations can be made. 

In practice design is often an iterative activity. Design tasks may not 
have strict start and stop dates. Rather, a design decision made 
downstream of an activity may force this upstream activity to be re- 
activated. The iterative nature of the design process also means that 
incomplete information may be used to perform an activity which will be 
performed again when more complete information becomes available. 
These cycles are common in most design activities and should not be 
ignored in our models. In fact, it is this iteration using incomplete 



information which presents the challenge in design. If we choose to "force- 
fit" the design process into the PERT representation, we are forced to ignore 
these cycles, and instead of making the important things explicit, we have 
simplified design into a trivial sequence of straightforward activities. 
Clearly, any useful representation must be able to represent cycles in the 
design process explicitly. 

2. Structiired Analysis and Design Technique 

Another popular technique which is used extensively in practice is 
the Structured Analysis and Design Technique (SADT). This method is a 
graphical means of describing large systems of interacting units. SADT 
shares some common background with PERT. Both were motivated by the 
need to coordinate a large number of activities which may occur at different 
times and at different locations. The derivative of SADT which is widely 
used today is one promoted by the U.S. Air Force in the early 1970's in an 
attempt to standardize manufacturing process descriptions across many 
different aerospace contractors [13]. The Integrated Computer-Aided 
Manufacturing Definition Method (IDEFO) is an automated, graphical 
adaptation of SADT aimed at standardizing contractor communications 
and reviews [17]. 

The SADT/IDEFO technique is based on a basic unit, the Structured 
Analysis (SA) box, and a fundamental descriptive language which dictates 
how these boxes can be interrelated [16]. Figure 2 presents the SA building 
block of the IDEFO models. Each box in the model represents an activity. 
An activity is defined as an act which, under control, transforms input into 
output using a mechanism. Each box can have any number of arrows 
leading into and out of it, following the convention pictured. Arrows 
directed into the box from the right represent input. Arrows directed out of 
the box represent output. The arrows entering the top of the activity box 
represent control. Those entering from the bottom represent mechanisms 
used, but not changed during the activity. Any SA box may be a component 
of another, higher-level SA box, and may itself be decomposable into more 
component boxes. The approach is to model from the top down, specifying 
as much detail, and creating as much depth as necessary to completely 
define the system being modeled. 



Control 



Input 




Mechanism 
Figure 2. Structured Analysis (SA) Box 

The interview is the main means of data collection, and is 
supplemented by reading documents and observing activities . Once the 
data has been collected, it is formatted and presented according to the 
IDEFO modeling guidelines. To construct an IDEFO document, the author 
applies the scripting language which guides the layout of the document 
[13]. This adherence to convention is the common language that allows 
communication between different parties. The reader of the document 
should be able to understand the interaction between activities based solely 
on the graphical content and SA labels (although text documents can be 
added for clarification). An example of an IDEFO document is presented in 
Figure 3. 













B 












1 


A 


1 




^ Y 




^ 




r 












1 












I 






2 


y ^ V 1 










1 
















n 






3 


^7 1 



























Figure 3. SADT/ IDEFO Document 

Experts in the IDEFO methodology stress that the representation is a 
living document which is iteratively updated and proofed until all parties 
have reached a consensus. Before a model is complete, it must be checked 
for omissions and validity. The people close to the activities being modeled 
are asked to verify the relationships represented in the document. 



8 

Necessary modifications are made and the cycle proceeds through a 
number of iterations before a model is approved. 

Using SADT to Model Design Activities 

Models of numerous design procedures have been constructed using 
the IDEFO technique. To do so, the design activity to be modeled is 
hierarchically decomposed and documented on as many different levels as 
required. There is a strict limit to the amount of information that can be 
placed on each page of the IDEFO document. This restriction is an attempt 
to limit the degree of complexity which the reader of the document is 
exposed to at any one time. The documents themselves consist of multiple 
sheets, with each page documenting all the inputs, outputs, controls and 
mechanisms which affect a particular set of activities. Note that these 
interrelations are often not from boxes at the same level of decomposition 
and are not necessarily on the same sheet of the IDEFO document. 

Most large manufacturing firms we know of, including Boeing, 
General Motors, Kodak and Motorola, have used the IDEFO software and 
methodology to create models of existing design procedures. Often the tasks 
to be modeled are enormous and must be decomposed into functional areas. 
Each area is made responsible for collecting information and creating a 
valid IDEFO document which can be used to study its existing design 
practice. 

At General Motors, the complete process model for automobile design 
is still being constructed, but some parts have been completed. The 
resulting documents represent huge investments in resources, and are 
rich in information; however, in practice, the size of these documents has 
proven to be one of the most significant drawbacks. Because the software 
does not perform it automatically, verification of interrelations between 
activities requires much effort tracing arrows backwards and forwards 
through multiple levels of decomposition. Because the overall design 
activity is large and complex, the documents themselves become a tangled 
network which is laborious to read. 

The IDEFO procedure is indeed able to capture the complex 
requirements of the design process, but the result does not lend insight into 
the design process. This representation of the design activity serves as a 
documentation of the design process, but because of its complexity and 
unwieldy size, it is not particularly good at suggesting improvements. The 
IDEFO document does not facilitate computation nor does it make 
difficulties explicit. This shortcoming renders it inadequate for improving 
the design process. A useful model must be able to answer questions with 
much less efi'ort than IDEFO models require. 



3. Matrix Representations 

Beginning in the 1960's, some researchers have used matrix 
representations in place of graphs to display systems of equations and 
precedences. Adjacency matrices are square matrices whose elements, aij, 
are unity if nodej is a precedent of node i, and blank otherwise [22]. The 
matrix is easily constructed from the network diagrams or directly from 
precedence information. The size of the matrix depends upon the number 
of activities or tasks into which the system is broken. The number of non- 
blank elements reflects the number of precedences in the system. Figure 4 
depicts a typical adjacency matrix. One would read the precedence 
relations from the matrix by reading across the rows of the matrix. For 
example, in Figure 4, Task D is dependent upon input from Tasks A and E. 
The name, adjacency matrix, reflects the fact that the non-blank elements 
identify which nodes are adjacent (connected) to each other [8]. No special 
language is required to construct the matrix, and the results are easily 
understood by both the creator and the user. 

ABCDEFGH I JKL 




Figure 4. Adjacency Matrix 

The matrix representation has been used to model many different 
processes and systems. Mathematicians have used this matrix form to 
solve simultaneous equations [11, 22]. Chemical engineers have used the 
matrix representation to model process flow sheets [9]. Engineers have 
documented the interdependence to examine the most efficient order in 
which to determine system parameters [2, 3, 15, 20]. 

Using Precedence Matrices to Model Design Activities 

In a similar manner, matrix representations have been used to 
model the information flow in the design process. The same precedence 



10 

information used in the other techniques is collected for each component 
task. If one interprets the task ordering as a time sequence, the timing of 
information flow becomes explicit: marks below the diagonal represent 
information transferred to later tasks; marks above the diagonal depict 
information fed back to earlier tasks. The matrix embodies the structure of 
the underlying design activity by mapping the relations between tasks in a 
precise order which makes interdependence explicit. Steward refers to a 
matrix model of design activities as a Design Structure Matrix (DSM) [20]. 

This representation has been used in a number of design projects to 
successfully map dependencies between functional areas of the design 
endeavor. The work done by Black exposes, on a parameter level, the 
information requirements of brake system design [2]. This work allows the 
designers to see the entire design activity from a global perspective. The 
order in which parameters are determined can have a significant effect on 
the execution of the design and these features are revealed in the matrix. 
The details of this work are presented in the next section. 

Most recently we have used the matrix representation as a 
management aid to analyze the organizational structure of design projects 
usin? the individual information requirements of the engineering tasks [6, 
19]. As an aid to better design management, we have used the matrix to 
identify tasks which are constrained to be serial by nature of the 
information flow connecting them. Conversely, the matrix also allows 
quick identification of tasks which can be performed in parallel. This 
representation has proven useful in studying the changes required in the 
implementation of concurrent engineering strategies [5]. These results are 
discussed further in the final section of this paper. 



11 



Comparison of Representations 

To compare the design models constructed by the different 
techniques, we modeled design activities using the IDEFO and matrix 
methods presented above. We found that the IDEFO methodology has been 
applied extensively to represent the design and manufacturing activities at 
General Motors. The C4 program at GM has formed Lead Groups which 
are responsible for documenting the design procedures for each of the seven 
major functional areas of the automobile: 1) Powertrain, 2) Chassis, 3) 
Electrical, 4) Body-in-White, 5) Paint, 6) Assembly and 7) Interior. The aim 
of this endeavor is to understand the design and production activities as 
they are currently performed and to then suggest improvements for future 
performance. 

The precedence information gathered while studying and 
documenting the production of these components is valuable information 
which could, if represented and analyzed correctly, aid in improving and 
accelerating the design activity. At present, all of this precedence 
information for the activities is contained in IDEFO charts. These charts 
are constructed by authors who interview engineers in the organizations, 
are reviewed for completeness and validity, and are eventually approved as 
an accurate representation of the current design practice at General 
Motors. 

These IDEFO models are large and complex, reflecting the processes 
they model. However, the large size of the models is a disadvantage of the 
representation. The size and complexity of the documents are barriers to 
their use in facilitating improvements of the processes they represent. 
Although the description is complete, it is not concise enough to serve as a 
beneficial overview tool. This representation fails to suppresses enough 
detail to render it transparent to users. The vast amount of information 
presented only one page at a time provides only limited glimpses into the 
global interactions of design and manufacturing which are often crucial. 

The same precedence data used in the IDEFO charts can be mapped 
into the matrix format and compared to the SA box notation. Figure 5 is a 
schematic of the translation of IDEFO data into its equivalent matrix 



12 



format. 











■ > 


- 1 


F f 


] 









A 

r— 


^ / '■ 


*► I 


L C -*L ■ 

I — h 


1 





ABCDEFGH I JKL 

X X 

X . X 
X • 

• X X X 

• X X X 

X 
X 
X X 
• X 
• X X 



X 
X X 

XX X 

X 

X 



XXX' 



Figure 5. Translation from IDEFO Format to Matrix Format 

Each lowest level SA activity box becomes a row in the matrix. We 
have performed this transformation for only two design problems in the 
power train lead group (a crankshaft and a camshaft), but the results have 
provided interesting comparisons to the IDEFO format. The matrix is also 
large, but it is an orderly array in which precedent information is obvious 
for each of the tasks included in the model. We found the matrix 
representation much easier to construct and read. Because the matrix 
representation is easier to verify, it is better suited to accurately represent 
current practice as well as provide suggestions for improvements. 

Three different models were constructed based on data from General 
Motors. The first activity presented below is the brake system design. In 
this study parameter level data was collected to document the interaction 
between physical design parameters such as energetic, geometric, and 
material properties. This is a model of the engineering interactions which 
must be considered in the design of a brake system. In contrast, the second 
model presents data at a task level. The precedence data for this model 
reveals how the separate tasks of the crankshaft design activity must 
interact with one another during the design process. A more 
comprehensive view is offered in the third model which is based upon the 
entire camshaft development process including activities from design 
through production. Each of these models has contributed to our 
understanding of the methodology of design and will be discussed 
individually in the following section. 

Brake System Design 

The first study was performed by Tom Black on brake system design 
[2]. The model was constructed from data collected during interviews and 
discussions with the designers. Designers were asked to identify what 
information was required to perform the specific jobs. The jobs were 



13 

detailed down to the parameter level to include measurable quantities such 
as pressure, diameter, and torque. The model was constructed and verified 
in the matrix form pictured in Figure 6A. 

Notice that the design task is decomposable into three distinct 
phases. The information flow in the early design stage is a mixture of 
sequential and parallel activities. In the second phase of the design 
activity, the information flow becomes iterative as represented by the large 
block of tasks which are coupled. Following this block is final group of 
sequential and parallel tasks. The decisions which are resolved iteratively 
in the middle of the design process are presented in Figure 6B. These tasks 
could be analyzed in further detail using the methods described in [7, 20]. 
Some of these were performed and the results are reported in [2, 21]. 

Certain aspects of this model should be noted. The information flow 
during certain stages of design is critical while during much of the activity, 
it is a simple sequence. The coupled block of iterative information flow in 
the middle of the design matrix is what we consider the challenge of the 
design activity. We expect that all but the most trivial design activities will 
have some degree of iteration. We investigate below whether this overall 
structure is common to other design activities. 



14 



\ ^\ '^- 






:' :. ■' 










■■ " '^- 



Figure 6A. Brake System Matrix Model 



15 



Knuckle envelope & attach pis 33 

Pressure at rear wheel locK up 34 

Brake lorque vs. skidpoint 35 

Drum male rial 36 

Line pressure vs. brake lorque 37 

Dnjm maleriaJ — composiie/cast 38 

Drum — thermal aspecis 39 

Splash shield geometry — Ironi 40 

Bearing — rear — heat inio 4i 

Bearing — (ronl — heat inIo 42 

Dnjm brake size 43 

Drum errvelope & attach pts 44 

Bearing envelope & attach pis 45 

Splash shield geometry — rear 46 

ABS sensor location 47 

Air flow under car/wheel space 48 

Wheel material 49 

Wheel design 50 

Tire lype/material 51 

Vehicle deceleration rate 52 

Temperature at components 53 

Rotor cooling coedcient 54 

Lining — rear vol and area 55 

Floior width 56 

Pedal anach pts 57 

Dash deflection 58 

Pedal force (required) 59 

Lining coeMicient — rear 60 

Pedal mechanical advantage 6i 

Lining — (ront vol & swept area 62 

Lining coellicient — front 63 

Booster reaction ratio 64 

Rotor diameter 65 

Rotor envelope & attach pts 66 



33 3435 3637 


2i 


3940 


4142 4344 45 4647 


4849 


5051 


5553 54 5556 


5758 5960 6162 


63 


6465 


6« 




' 












X 








X 




33 


■• X 














X 


X 




X 




34 


X 




X 


X 








X 
X 


X 
X 




X 
X 




35 

36 
37 
38 


X 


X 




X 


X X 






X 










39 


X 




X 


X X 

•• X 




X 


X X 
X 

X X 








X 


X 


40 
41 
42 
43 


X 






•• 


















44 


X 






•• 






X 








X 




45 


X 






X •• X 




X 


X 












46 


X 




X 
X 


XX XX" 
X 


X 
X 


X 

X 


X 

X 
X 












47 
48 

49 
SO 

51 


XX X 








X 

X 


X X 


X 


X 
X 


X 
X 




X 
X 




52 
53 
54 


X 








X 




X 
X 

X 


X 

••XX 

X •• X 
X •• X X 
•• X 

X 


X 


X 
X 
X 


X 

X 
X 
X 


X 


55 
56 
57 

58 
59 
60 
61 


X 












X 


X X 
X X 
X X 


X 

X 
X 


X 
X 


X 
X 


X 


62 
63 
64 
65 


X 






















•' 


66 



33 3435 3637 38 3940 4142 4344 45 4647 4849 5051 5253 54 5556 5758 5960 6162 63 6465 66 

Figure 6B. Iterative Block of Brake System Matrix Model 



Crankshaft Design 

A second design process model was produced from the study of 
crankshaft design. This model was developed by GM's C4 Power Train 
Lead Group using the IDEFO methodology. The information they gathered 
was subsequently translated into the matrix format. The original IDEFO 
document consists of more than 20 pages and is too large to reproduce here. 
However, the matrix representation is provided in Figure 7. The relation 
assigned during the IDEFO modelling has been preserved: Input/Output, 
Control, and Mechanism are denoted in the matrix as I, C, and M, 
respectively. Translating the precedence relations from the IDEFO 
document into the matrix provided a good overview of the design activity as 
captured by the IDEFO authors. 



16 



IS 18W ■! liTO ?' 77?3 ?* 25?* 37 JKfl 30 3i3! 33 3*3* n 37 int 



Conceptual. Crankshaft - 

Supervise Shaft Des. ; 

Ran for Design i 

Perforrn Design Process * 

Detail Pans & 

Check Detail • 

Plan Analysis m 

Transform 2D data to 3D j 

Trans lale Data i 

BuiW 3D FEM Model ■ 

Solve Stress, Deflec.. Vib. >o 

Display Results " 

Evaluate arid Report >; 

Modify Design u 

Est. Process Sequence -* 

Coordinate Engine Builds <& 

Coordinate with Sources n 

Eval. Purchase Req's t? 

Obtain Vendor Quotes n 

EvaJ. and Select Vendors <9 

Issue Purchase Order jo 

Estimate Cost artd Timing r^ 

Review Information j? 

Establish Sequence 23 

Select Machines 2* 

kJent. Supp. Resources i& 

Evaluate Process Sheet 2* 

Develop Schedules 7' 

Order Resources 21 

Prep. Supp. Resources 7s 

Set-up Machine 30 

Execute Operation 31 

Inspect Prototype Crank w 

Test Prototype Crank 33 

Re!. Crankshdl Design 3* 

Anal, and Concept. Proc. as 

Design Process sa 

Validate Process 37 

Release Process 3i 

Prep. Tools and Equip. 39 

Prepare Facility *o 

Setup Prod. Resources *> 

Venfy Prod. Resources *? 

Produce Crankshaft o 



X 1 ■■ 1 1 
X c 

1 C X 

1 X 1 1 1 
1 X 1 
C 1 X 

xccccccc 

1 C X 

1 CIX 1 
CIX 1 
C 1 X 
C 1 X 
C 1 1 X 1 

1 c 1 ex 


1 

1 

t- MAJOR TASK A' 

DES»3N CRANKSHAFT 

1 


1 


C 
C 

1 
c 

c 

c 
c 
c 
1 


XIII 1 1 
C X 1 1 II 1 1 
C C X 1 II 1 1 
1 X 
1 X 
1 X 
C X 

X III 
X 

ex c 
ex c 

C X 

e e c X 1 

C X 1 

ceo X 

1 C C C XII 

e c c e CIX 
ceo c M 1 
1 1 X 

1 X 
X 


1- MAJOR TASK B 
VERIFY DESIGN 




c 
c 
e 
c 

MAXJfl TASK C -> 
DEVELOP MANUFACTURING PROCESS 


X 1 1 
1 X 1 1 
1 X 
1 X 

C X 1 1 1 
C 1 X 1 
C 1 1 X 1 
C 1 X 
C MX 



■ Bjo ?\ nn 1* 7tn 21 ;«» 3o 3131 33 3435 m 37 stai 



Figure 7. Crankshaft Design Matrix 



The matrix allowed us to make some observations about the 
crankshaft design activity and about its modeling effort. Primarily, the 
matrix revealed some inconsistencies in the IDEFO models. In 
constructing the matrix, certain precedences were inconsistently 
documented. This confirms the assertion that IDEFO models are difficult to 
verify and cross check. Furthermore, application of some simple re- 
sequencing rules demonstrated that the precedence sets were incomplete. 
For example. Task 34, Release Crankshaft Design, can be scheduled 
immediately following Task 6, Check Detail. The precedence shown allows 
the design to be released before modifications or verifications occur. 

The information set contained in the documents was complete 
enough to allow us to identify *^he three major activities of the design 
process and these have been marked as blocks in the matrix. It is of 
particular interest that the three major tasks of this design activity can 
proceed almost in parallel with only a few marks linking them at certain 
stages. These few marks can be considered design drivers which play a 
critical role in the implementation of improved design procedures such as 



17 

design for manufacturing. The implications of this structure and the 
strategies for managing them are discussed in detail in [5], and are 
summarized at the end of this section. 

Camshaft Design 

In a final exercise, complete design and production activities for 
camshaft development were documented down to similar levels of detail. 
The previous model for the crankshaft included only the design components 
of the process, whereas this model expands the steps both before and after 
design. This camshaft matrix was constructed from the IDEFO charts 
exactly as described previously for the crankshaft model. In this more 
complete model, it was possible to make many more observations and 
comments regarding the representation and about the process it reflected. 
The matrix is reproduced in Figure 8A. 




Figure 8A. Camshaft Development Matrix 



18 



First, notice that the design activity (Tasks 4-37) is by far the most 
iterative of the major tasks. Much more communication is required in this 
stage of the activity than in the production stages which appear to proceed 
with more sequential tasks (the band of marks just below the diagonal 
represents a sequential flow). The design activity from this matrix is 
enlarged in Figure 8B. 



4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 g1 22 23 Z't 25 26 e7 38 29 X 31 3g 33 34 35 36 



Dev. Camshaft Des. Concept 4 

Dev. Camshaft Proc. Concept 5 

Dev. Camshaft Prod. Concept 6 

Del. Primary Characteristics 7 

Det. Physical Requirements 8 

Initiate/Monitor Build/Test 9 

Rev. Eng Change Reqs lO 

Coord. Des. 11 

Schedule Work 12 

Dis. with PFT 13 

Create Layout 14 

Check Geometry Markup 15 

Write Detail Ticket 16 

Write Speaficaiion 17 

Detail/Check Camshaft is 

Dev. Mockup & Illustrations 19 

Store and Distribute Drawings 20 

Review Product Des. 21 

Dev. Proc. Concept 22 

Anal, and Build/Test Results 23 

Del. Key Qual Characteristics 24 

Det. FMEA for Proc 25 

Dev. Equip. Concept 26 

Det. FMEA for Sys. and Equip'! 27 

Dev. Qual. Plan 28 

Verify (Proc?) Des. 29 

Anal. Manufacturability 30 

Anal. Structure 31 

Coord. Analysis 32 

Outsource Analysis 33 

Inhouse Analysis 34 

Verify Analysis Results 35 

Anal. Tolerance (VSM) 36 

Resolve Problems 37 




9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 X 31 32 33 34 35 36 : 



Figure 8B. Design Block of Camshaft Development Matrix 

Again, the precedence information was discovered to be incomplete, 
but in this case, we ventured to classify some of the errors. We identified 
precedences which should have existed, but were not present in the IDEFO 
model. These were conjectured based on the task descriptions and the flow 
of information expected to be required. For example, task 21 Review 
Product Design should have input from several Product Design tasks. A 
number of these possible omissions are denoted in the matrix using the '?' 
symbol. 

We also identified extraneous precedences which seemed 
superfluous and labeled these as marks with a strikeout. Although these 
were based on a limited exposure to the details of the process being 



19 

modeled, they were based on an engineering interpretation of the task 
definitions and the expected sources of inputs and destinations of outputs. 
For example, we question whether determination of primary 
characteristics and physical requirements of the camshaft (Tasks 7 and 8) 
require the development of the design and production concepts (Tasks 4, 5, 
and 6). We suspect that the relation should be modeled in reverse. That is, 
the determination of the primary characteristics and physical 
requirements should drive the design of the product and the process. 

The remaining marks in the matrix are suggestions for additional 
feedback. In contrast to the '?' labels which represent a logical relation 
which may have been overlooked in the modelling, the '%' marks represent 
opportunities where strategic feedback does not yet exist, but could be 
implemented. These include suggestions such as including 
manufacturability analysis (Task 30) in the review of the product design 
(Task 21). 

The most significant shortcoming exposed in constructing these 
models was the degree of the interdependence between tasks. In many 
cases, the IDEFO model denoted an interdependence which seemed more 
appropriately termed a feedback or verification dependence rather than a 
tight interdependence which is resolved in an iterative process of 
negotiation. For example, in the crankshaft model, we expect to 
conceptualize the manufacturing process, design it, and then validate it 
(Tasks 35-37). However, their precedence relation indicates that they are 
executed simultaneously. It makes sense to do it in the present order, but 
not the other way around. What is needed is an explicit means of 
differentiating between the various types of interdependent relationships. 
In this case, we expect that there is some feedback from the design tasks to 
the conceptualization tasks, but not complete precedence. This type of 
information is important to capture in the design model and a means for 
doing so is suggested below. 

These matrix models of actual design and manufacturing activities 
display the critical dependencies explicitly. When information is required 
before it is available, the precedence appears as an above-diagonal element. 
The insight provided in these matrix models allow the design manager to 
choose which dependencies to address based on the potential for overall 
improvement. It may be possible to eliminate some iteration by re-ordering 
the activities or by building coordination into the early steps of the process. 
These and other strategies are discussed in detail in [6], and are 
summarized below. 



20 



Matrix Analysis Tools 

The tools available for analyzing design matrices are detailed in [7], 
but are summarized here. One of the first analysis techniques which the 
matrix representation facilitates is a re-sequencing of design activities 
using precedence relations as a guide. This is referred to as partitioning 
[18]. This procedure attempts to maximize the availability of requisite 
infc mation and identifies cases in which not all requisite information can 
be made available. When this occurs, there is a cycle of information flow 
which appears as a block centered about the diagonal of the matrix. This 
procedure identifies which tasks are involved in cycles and are performed 
iteratively. In exposing the structure of dependence, it also makes explicit 
the relation between the activities. For example, tasks which must be 
performed in series are differentiated from from tasks which can occur in 
parallel. Figure 9 depicts a precedence matrix both before and after 
partitioning. 



ABCDEFGHIJKL 



BCAKLJF lEDHG 



A 


X 

• 

X • 

• 


X X 
• X 


X 


X 
X 


B 

c 

A 

K 

L 


• 




1 




Series 


Parallel 






B 


X 
X 


• 


J 


>^ 


C 

D 


X 
X 


• 


• 


) 


E 


X 


X 


• 


X X 


F 
G 


X 
X 


• 
< 


» 


X 
X 


J 

F 


X 
X 


X X 


X 
X 


• X 

• 


y Coupled 


H 


X X 
X 


X 


• X 

• 


X 
X 


I 

E 




X 




X X • 


J 




I 


X 




X 


X 




J 


X X 


X 




• X X 


D 




X 


X 


X • 




K 


X X 
X 




X 


• 

X X • 


H 
G 


X 


X X 


X 


X • 




L 








X 






• 



Figure 9. Original and Partitioned Precedence Matrix 

Extending the engineering insight can also lead to some design 
strategies with managerial applications. Task interdependencies within 
the blocks can be examined to help order activities. Knowing that an 
activity is in a cycle and will be performed without all of its information, the 
engineer can evaluate the nature of the interdependence to decide which 
inputs will best serve to initialize the iterative cycle. This detailed analysis 
of particular dependencies within iterative cycles is referred to as tearing 
[10]. The name implies the removal of an arc or dependence to initialize the 
cycle. For example, in the matrix in Figure 9 above, the engineer might 
evaluate the relationship between activities E, D, and H to determine which 
dependence to tear. 



21 



The matrix representation easily identifies opportunities for 
accelerating the design process using a concurrent engineering approach. 
The precedence information contained in the matrix immediately exposes 
the earliest start times for each of the activities relative to one another. 
Certain dependencies may be eliminated by upstream coordination in 
which the interface between two activities is agreed upon. We call this 
artificial decoupling [6] which is intended to reduce long iterations found in 
design activities. For example, if the nature of the dependence between 
activities E and H above is such that it can be coordinated upstream, the 
iterative block is reduced to three serial tasks. Strategically decoupling the 
design into smaller sub-tasks can reduce the size of the working design 
groups, and can have a dramatic impact on development performance [1, 
14]. 

A related issue involves putting more feedback into the matrix, 
resulting in more inputs and coupling. An increased coupling strategy is 
the essential basis of simultaneous engineering and design for 
manufacture (DFM). In the traditional (sequential) design process, 
depicted by the matrix in Figure 10a, the product designers would perform 
their design tasks somewhat independently from the manufacturing 
engineers. In the modern (concurrent) design process. Figure 10b, the 
practice of DFM mandates that these two activities be performed 
simultaneously. This is beneficial because the production expertise is 
brought into the early design stages (often causing much iteration), 
resulting in designs which are simpler to manufacture. However, the 
added coupling in the design process in fact slows product development 
considerably. Advocates of this philosophy would argue that overall design 
time can still be reduced because the need for later (more lengthy) iteration 
is therefore lessened. This is particularly true if the feedback from 
manufacturing engineering to design was indeed present in the original 
design procedure. This feedback is shown in Figure 10a by the + marks 
which depict redesign activity addressing the production problems which 
inevitably arise. 



Design Valve Train 
Design Cylinder Head 



Manufacturing Analysis 
Production Engineering 



\ 
\ 

• + + 

\ 
\ 
\ 

X X pi 

XX X • 

\ 



Design Valve Train 
Design Cylinder Head 
Manufacturing Analysis 
Production EIngineering 



I ' '■ 

\ 
\ 

X • X X 
X X • 

I X X X ♦ I 

\ 
\ 
\ 
% 

\ 
\ 
% 



(a) (b) 

Figure 10. Sequential and Concurrent Design Procedures 



22 
Matrix Improvements and Applications 

One shortcoming of the representations and techniques presented 
above is the assumption that all task relations are equal. No attempt is 
made to quantify amounts of information transferred between tasks in the 
matrix. It is reasonable to expect that certain dependencies will be stronger 
than others, or that certain transfers of information will be critical. In the 
design precedence matrix, task interactions are not differentiated from one 
another. 

We aim to embody some information about the tasks' 
interdependencies into the matrix itself and to incorporate this dimension 
into the analysis techniques applied to the design process. The binary 
design structure matrix can be vastly improved by having the matrix 
elements reflect any of a number of different measures about the relation 
between tasks or the task's relation to the entire design process. These 
numerical measures can reflect quantity of information transferred 
between tasks, sensitivity of tasks to incomplete data, or other quantities. 

One such numerical scoring is based on an estimate of the quantity of 
information transferred between tasks. This would allow us to differentiate 
between different degrees of interdependence and would significantly 
clarify the models. Simple verifications and feedbacks can be differentiated 
from strict precedence which requires iteration and negotiation. By 
attaching numerical data to the precedence data, the matrix can represent 
more information than it presently does. The additional advantage to this 
quantitative model is the number of analysis tools which can be applied to 
it. With the enhanced representation comes additional capability to suggest 
improvements. 

For example, a sequence can be scored based on the quantity of 
information that must be approximated because it is not available when it is 
required. If a particular ordering requires too much information to be 
assumed, other sequences can be generated and scored. These scores allow 
comparisons of different design structures using a common metric. A 
numerical algorithm can be aimed at minimizing a certain score. The 
score can be tailored to use a particular metric most appropriately. For 
example, if one were to measure the certainty with which a particular piece 
of information could be approximated (perhaps based on previous 
experience), it would be best to maximize the minimum above diagonal 
element. These heuristics can easily be changed to accommodate various 
measures of task interdependence. 

An example of a numerical design structure matrix is presented in 
Figure 11. In this example, a matrix has been constructed to demonstrate 
the power of numerical analysis techniques. A twelve by twelve precedence 



23 



matrix has been converted from binary dependencies to numerical metrics 
of interdependence. Analysis was performed on the matrix using two 
methods: (1) standard algorithms which consider all dependencies equal 
and (2) numerical algorithms which rely upon an enhanced information 
content. 



Standard 
Partitioning 

Algorittims 




■•^ 




ABCDEFGHI JKL 



J ACFKLGBEDH 




Numerical 

Partitioning 

Algorithms 




Figure 11. Numerical Design Structure Matrix 

In this example, the numerical goal was to minimize the sum of the 
above diagonal elements weighted by the distance from the diagonal. 
Compare the results from standard partitioning to the output from the 
numerical algorithms. The results are significantly different and lead to 
different conclusions. 

The different results suggest different design management 
strategies. In the binary matrix, Task G's dependence on Task E would not 
be considered a strategic one which could impact the execution of the 
design activity. However, the numerical matrix provides additional insight 
which could lead to a design organization pictured in Figure 12. 
Recognizing this tear in the binary matrix would have required much 



24 

insight or experimentation, while in the numerical matrix, the leverage of 
this tear is more apparent. 



JACFKLGBEDH 




Figure 12. Tear Suggested by Numerical Matrix 

The enhanced matrix representation will capture significantly more 
information in an easily usable form. The enhanced representation 
capable of handling measures of task interdependence provides enough 
flexibility to be used in many scenarios and at different levels. A parameter 
level matrix might measure sensitivity of a parameter to its input. These 
numerical matrix representations can be analyzed using any number of 
numerically based tools which utilize the information appropriately to 
identify both engineering and management improvements. 



25 

Conclusion 

The work reported here is a comparison of existing design 
representation techniques. The need for good models has been prompted by 
an increasing interest in executing and managing the design activity in the 
most effective manner. As different representations of design have been 
utiHzed, limitations with existing techniques have been exposed. Using a 
precedence matrix to model design activities at General Motors has aided 
our understanding of the complex interactions which occur during the 
design process. As the study of the design has become more sophisticated, 
we have found that enhancements to this representation are necessary. 
The proposed representation based on a numerical precedence matrix 
incorporates the qualities of a good representation outlined above. The 
flexibility and clarity of the numerical matrix format provide a platform 
from which to address questions which are relevant to improving the 
design process. 



Acknowledgements 

This research is funded jointly by several sources including the 
National Science Foundation, the General Motors Corporation, and the 
MIT Leaders for Manufacturing Program, a partnership involving eleven 
major US manufacturing firms and MIT's engineering and management 
schools. 



26 



References 

[I] D. G. Ancona and D. E. Caldwell. "Demography and Design: 
Predictors of New Product Team Performance", Working Paper, MIT 
Sloan School of Management, no. 3078-89, September 1989. 

[2] T. A. Black. A Systems Design Methodology Applied to Automotive 
Brake Design, S.M. Thesis, MIT, 1990. 

[3] T. A. Black, C. H. Fine and E. M. Sachs. "A Method for Systems 
Design Using Precedence Relationships: An Application to 
Automotive Brake Systems", Working Paper, MIT Sloan School of 
Management, no. 3208-90, October 1990. 

[4] J. Corbett. "Design for Economic Manufacture", Annals of C.I.R.P. 
vol. 35, no. 1, pp. 93, 1986. 

[5] S. D. Eppinger. Model-Based Approaches to Managing Concurrent 
Engineering. International Conference on Engineering Design, 
Zurich, 1991. 

[6] S. D. Eppinger, D. E. Whitney, R. P. Smith and D. A. Gebala. 

Organizing the Tasks in Complex Design Projects. ASME Design 
Theory and Methodology Conference, Chicago, IL, 1990. 

[7] D. A. Gebala and S. D. Eppinger. 'Methods for Analyzing Design 

Procedures", Working Paper, MIT Sloan School of Management, no. 
3280-91, April 1991. 

[8] F. Harary. Graph Theory. Addison-Wesley, Reading, Mass., 1969. 

[9] D. M. Himmelblau. "Decomposition of Large Scale Systems, Part 1: 
Systems Composed of Lumped Parameter Elements", Chemical 
Engineering Science, vol. 21, pp. 425-438, 1966. 

[10] G. Kron. 'Diakoptics', Piecewise Solution of Large Scale Systems of 
Equations, Ph.D. Thesis, University of Texas, Austin, 1963. 

[II] W. P. Ledet and D. M. Himmelblau. "Decomposition Procedures for 
the Solving of Large Scale Systems", Advances in Chemical 
Engineering, vol. 8, pp. 185-254, 1970. 

[12] F. K. Levy, G. L. Thompson and J. D. Wiest. "The ABC's of the 

Critical Path Method", Harvard Business Review, vol. 41, 5, pp. 98 - 
108, 1963. 

[13] D. A. Marca and C. L. McGowan. SADT: Structured Analysis and 
Design Technique. McGraw Hill, New York, 1988. 



27 

[14] J. B. Quinn. "Managing Innovation: Controlled Chaos", Harvard 
Business Review, pp. 73-84, May-June 1985. 

[15] J. L. Rogers. DeMAID: A Design Manager's Aide for Intelligent 
Decomposition User's Guide. NASA Technical Memorandum 
101575, March, 1989. 

[16] D. T. Ross. "Structured Analysis (SA): A Language for 
Communicating Ideas", IEEE Transactions on Software 
Engineering, vol. SE-3, no. 1, January, pp. 16-34, 1977. 

[17] D. T. Ross. "Douglass Ross Talks about Structured Analysis", IEEE 
Computer Magazine. 1985. 

[18] R. W. H. Sargent and A. W. Westerberg. "'Speed-Up' in Chemical 

Engineering Design", Trans. Instn. Chem. Engrs. vol. 42, T190-T197, 
1964. 

[19] M. Sequeira. Use of the Design Structure Matrix in the Improvement 
of a Vehicle Development Process, Master's Thesis, MIT, 1991. 

[20] D. V. Steward. Systems Analysis and Management: Structure, 
Strategy, and Design. Petrocelli Books, New York, 1981. 

[21] D. V. Steward. Using Information Flow to Manage the Design of 
Systems. Portland International Conference on Management of 
Engineering and Technology, Portland, Oregon, October, 1991. 

[22] J. N. Warfield. "Binary Matrices in System Modeling", IEEE 

Transactions on Systems, Man, and Cybernetics, vol. SMC-3, no. 5, 
September, pp. 441-449, 1973. 

[23] J. D. Wiest and F. K. Levy. A Management Guide to PERT/CPM. 
Prentice-Hall, Englewood CHffs, New Jersey, 2nd Edition, 1977. 

[24] P. H. Winston. Artificial Intelligence. Addison-Wesley, Reading, 
Mass., 1984. 



6809 077 



Date Due 



w^ 



(Vll*^ ' 



oO 



NOV. 1 9 1992 



' APR. 08 IS 93 
f^DV 1 8 200! 



Lib-26-67 



MIT LIBRARIES DUPl 



3 TDflO DDbflb2M3 4