Exploring Integration of
Four Information-based Product Development Tools
by
Tze Ho Lee
B.S., Mechanical Engineering (1997)
Massachusetts Institute of Technology
Submitted to the Department of Mechanical Engineering
in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Mechanical Engineering
at the
Massachusetts Institute of Technology
June 2000
2000 Massachusetts Institute of Technology
All rights reserved
S ig natu re of A utho r ................................................... . . . . . . . . . . . . . . . . . .
DepartmerPf Mechanical Engineering
May 08, 2000
C e rtified b y ..............................................
William W. Finch
Research Scientist
Thesis Supervisor
Accepted by .....................
Ain A. Sonin
Chairman, Department Committee on Graduate Students
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
SEP 2 0 ZOOQ
LIBRARIES
EXPLORING INTEGRATION OF
FOUR INFORMATION-BASED PRODUCT DEVELOPMENT TOOLS
by
TZE HO LEE
Submitted to the Department of Mechanical Engineering
On May 19, 2000 in partial fulfillment of the
Requirements for the Degree of Master of Science in
Mechanical Engineering
ABSTRACT
An experimental study was carried out on the applications of four information-based product
development tools supported by the MIT Center of Innovation in Product Development (CIPD).
The names of these tools are Assembly Designer, Distributed Object-based Modeling
Environment (DOME), Design Structure Matrix (DSM) and KCTool. Sample applications of
these currently independent software programs were constructed based on data from a
product development case provided jointly by the Naval Research Laboratory and the
Lockheed Martin Tactical Defense Systems. Possible tool interactions were investigated and
potential integration opportunities were explored utilizing an integration framework commonly
employed in the software development industry.
The result of the study suggests that the tools can be integrated according to four
relationships: Presentation, Data, Control, and Process. Some of the proposed integration
opportunities include the implementation of a common user interface and a service exchange
system through DOME, the consolidation of data format between Assembly Designer and
KCTool, and the support of a program execution order starts with DSM, DOME, Assembly
Designer, and ends with KCTool.
Future opportunities in this tool integration research include the exploration of tool capabilities
with different sets of industrial data and the addition of other tools into the research, such as
portfolio management and customer data collection tools.
Thesis Supervisor: William Finch
Title: Research Scientist
3
4
Acknowledgments
First, I would like to thank Dr. William Finch who has been a knowledgeable and motivating
thesis advisor. I would like to thank Thomas Sebok at the Lockheed Martin Tactical Defense
Systems, John Reintjes at the Naval Research Laboratory, and Richard Rein for making this
project possible by providing the research data. I would also like to thank Professor Maurice
Holmes and Sandy Campbell for their valuable advice, and Jeffrey Lyons, Gaurav Shukla, Ali
Yassine, Juan Deniz, Tony Chen, and Stephen Rhee for their consulting on the tools. And I
would like to thank the staffs at the Center for Innovation in Product Development for their
support and assistance.
I would like to express my appreciation to Jason Liang, Michael Kim, Yiu Tak Leung, and
Kenneth Kwok for their wonderful friendship. Special thanks to my roommates Danny Yim for
making all the good food, and Darci Wong for keeping our apartment a clean and comfortable
place to go back to after each long day of work. I am especially grateful to Sammi Truong for
providing me with the desk and the laptop for writing this thesis, and for giving me her support
and encouragement in the past two years.
Finally, I would like to thank my family for always being there for me. None of these could
have been possible without them.
This research is supported in part by the by the MIT Center for Innovation in Product
Development under NSF Cooperative Agreement Number EEC-9529140.
5
6
Table of Contents
CHAPTER 1: INTRODUCTION............................................................................13
13
.......................................
1.1 Background.................
13
..........................
1.2 Research Motivations.......................
1.3 Research Sponsors and Participants................................................... 14
. .. 15
1.4 O utline of T he sis ...........................................................................
CHAPTER 2: THRUST 2 TOOLS......................................................................
17
17
2.1 Assembly Designer..........................................................................
. 17
2 .1.1 T ool D escription .................................................................
24
2 .1 .2 B e n e fits ................................................................................
24
2.1.3 Installation Requirements.....................................................
2.2 Distributed Object-based Modeling Environment (DOME)......................... 25
2.2.1 Tool Description..................................................................25
. ..32
2 .2 .2 B e n e fits ...........................................................................
33
2.2.3 Installation Requirements.....................................................
2.3 Design Structure Matrix (DSM).............................................................. 34
2.3.1 Tool Description..................................................................34
. ..3 8
2 .3 .2 B e n e fits ...........................................................................
39
2.3.3 Installation Requirements.....................................................
2 .4 K C T o o l........................................................................................ . . 3 9
2.4.1 Tool Description..................................................................39
43
2 .4 .2 B e n e fits ................................................................................
44
2.4.3 Installation Requirements.....................................................
CHAPTER 3: THE LASERNET FINES CASE.......................................................45
45
3 .1 T h e T e ch n o lo g y .................................................................................
47
3.2 Thrust 2 Tool Applications................................................................
3.2.1 Assembly Sequence Assessment Using Assembly Designer........47
3.2.2 Component Selection and Optimization Using DOME................. 53
3.2.3 Module Formation Using Design Structure Matrices................... 57
3.2.4 Inspection Strategy Design Using KCTool................................ 61
3.3 Case Conclusion............................................................................. 67
CHAPTER 4: TOOL USAGE LOGS..................................................................
69
4.1 Assembly Designer Logs.................................................................. 69
. 70
4 .2 D O M E Lo g s ..................................................................................
. ..76
4 .3 D S M L o g s ....................................................................................
. 76
4 .4 K C T o o l Lo g s ..................................................................................
7
CHAPTER 5: TOOL INTEGRATION.....................................................................78
5.1 The Integration Framework................................................................78
5.2 Implication on Thrust 2 Tool Integration................................................ 80
5.2.1 Presentation Integration........................................................80
82
5.2.2 D ata Integration.................................................................
84
..................................................................
5 .2 .3 C o ntro l Integ ratio n
5.2.4 Process Integration..............................................................85
5.3 C hapter S um m ary........................................................................... 90
CHAPTER 6: CONCLUSION...........................................................................
91
6 .1 C o n clu sio n s .................................................................................. ..91
6 .2 F utu re R e se a rch ................................................................................. 91
6 .3 F in a l C o m m e nts ................................................................................. 9 3
APPENDIX 1: MODELING DATA FOR THE THRUST 2 TOOL APPLICATIONS...........95
Al.1 Part Definitions for Assembly Designer Application................................ 95
A1.2 Liaison Definitions for Assembly Designer Application............................ 96
A1.3 SPAS Precedence Relationship for Assembly Designer Application.........98
Al.4 Excel Model (on Local LMTDS Server) for DOME Application ................ 99
A1.5 Excel Model (on Remote Vendor Server) for DOME Application................. 100
A1.6 LMSolidWorks.txt (on Remote Vendor Server) File for DOME Application.... 101
A1.7 LMMatlab.m Files (on Remote Fluid Server) for DOME Application.............102
A1.8 LMMatlab.txt Files (on Remote Fluid Server) for DOME Application.............103
A1.9 LMMatlab.mtxt Files (on Remote Fluid Server) for DOME Application..........104
A1.10 Combined Dependency Matrix for DSM Application............................... 105
A1. 11 Key Characteristic Definitions for KCTool Application............................. 106
A1.12 System/Subsystem/Part Definitions for KCTool Application..................... 107
Al.13 Error Propagation Definitions for KCTool Application..............................108
APPENDIX 2: THRUST 2 APPLICATION DEMO SCRIPTS.......................................109
8
List of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
2.1:
2.2:
2.3:
2.4:
2.5:
2.6:
2.7:
2.8:
2.9:
2.10:
2.11:
2.12:
2.13:
2.14:
2.15:
2.16:
2.17:
2.18:
3.1:
3.2:
3.3
3.4:
3.5:
3.6:
3.7:
3.8:
3.9:
3.10:
3.11:
3.12:
3.13:
3.14:
5.1:
5.2:
5.3:
Assembly W indow Interface...........................................................18
Part Data Input W indow..............................................................
20
Feature Data Input W indow........................................................... 21
S PA S W ind ow ...........................................................................
. 22
EDIT Sequence Graph W indow..................................................... 23
27
DOME Server W indows..............................................................
DOME Client Login W indow...........................................................28
29
DOME Client W indow.....................................
30
DOME Relation W indow..............................................................
DOME Preference Function W indow...............................................31
DOME Optimizer W indow................................................................32
36
DSM Input Interface....................................................................
. 37
C luste ring Inte rfa ce .....................................................................
38
Clustering Result........................................
40
KCTool Main W indow..................................................................
KC Data Input Interface................................................................ 41
Inspection Simulation Interface.......................................................42
Inspection Optimization Result....................................................... 43
46
LaserNet Fines System Diagram...................................................
CAD Model of Optical Subassembly............................................... 46
DFC Model of Gen1 Optical Sub-assembly...................................... 49
Assembly Sequence Tree for Gen1 Optical Sub-assembly.................. 51
52
Edited Assembly Sequence Tree...................................................
Design Evaluation Criteria............................................................... 55
Spatial Dependency Matrix........................................................... 58
Energy Dependency Matrix...........................................................58
Information Dependency Matrix..................................................... 59
59
Material Dependency Matrix.........................................................
KC Flowdown Model of Optical Sub-assembly.................................. 64
Inspection Simulation Result......................................................... 65
Inspection Optimization Result....................................................... 67
Thrust 2 Application Map..............................................................68
Integration Definition by Thomas and Nejmeh.................................. 79
DFC-based Data Representation for KCTool.................................... 83
One Possible Integrated Development Process................................ 88
9
10
List of Tables
Table
Table
Table
Table
Table
Table
Table
2.1:
3.1:
3.2:
3.3:
3.4:
3.5:
3.6:
Feature Types in Assembly Designer............................................. 22
DFC Part Abbreviations................................................................ 48
Coordinate Definition for Micro-adjuster.......................................... 50
Definition for Liaison between Optical Plate and Micro-adjuster............ 50
Characteristic Variable Abbreviations for DOME Product Catalog......... 54
DSM Clustering Result................................................................ 60
KC Abbreviations........................................................................63
11
12
CHAPTER 1: INTRODUCTION
1.1 Background
The MIT Center for Innovation in Product Development (CIPD) is a National Science
Foundation Engineering Research Center. It is dedicated to "lay the conceptual groundwork
for, and contribute core components to, a product development infrastructure that will help
America's companies survive in a service marketplace" [1]. The vision of the center is defined
as follows:
VISION OF THE CIPD
New products will be developed byjust-in-time collaborations of globallydistributed teams linked seamlessly by Web-based tools and processes.
The collaborations will be formed by means of a "services marketplace"
where lead firms will find the world's best "knowledge purveyors" suppliers of information, components, and support services [1].
As one of the four research thrusts created to assist the center in realizing its vision, the
Information-based Product Development group (Thrust 2) has developed a portfolio of
software for supporting various product development activities.
The group foresees the
eventual goal of introducing a set of integrated tools to the industry, one that can be utilized
to effectively facilitate work and information flow across multidiscipline development
environment. This thesis project is a first step towards achieving that goal. Through the
development of a concurrent application with four Thrust 2 tools, the project brings together
research work produced by a number of professors and scientists at MIT. Demonstrating
and evaluating these tools in concurrence establishes a common ground on which tool
interactions can be studied, and issues surrounding integration opportunities can be
explored.
1.2 Research Motivations
Until the inception of this project, presentation of Thrust 2 research is mainly being done
through the specific examples developed within each group. For instance, one professor
13
would talk about how her tool can be applied to manage product variation in a commercial
airplane application, while another research faculty would explain how his tool is utilized for
the design of a throttle body assembly system at an automotive company. Due to the
differences in nature and scale of these design problems, comparison of tools cannot be
made in any convenient way, nor can interactions among tools be demonstrated and studied.
There have been on-going research efforts in exploring the possibilities of pair-wise
integration involving some of the tools, but integration of an end-to-end product development
system is yet to be seen.
Although the actual integration work does not fall into the realm of this research project,
valuable insights on such can be obtained through the exercise of developing a concurrent
application with the four Thrust 2 tools. The main objective of this thesis work is to investigate
the interactions among these tools. Since these tools have never been used concurrently in
the past, not many studies have been done on the compatibility and the mapping of their
functionality with each other. By having as many tools running under the same computing
environment as possible, problems related to integration can be highlighted, and
recommendations can thereby be made on how these obstacles can be removed through
future research at the center.
Another outcome of this research is a presentable application demo of the Thrust 2 tools.
This demo is showcased in the newly established Product Development Integration
Laboratory, a facility where students and industrial visitors can learn about the research being
done at the center.
1.3 Research Sponsors and Participants
The research covered in this thesis is sponsored by the MIT Center for Innovation in Product
Development (CIPD) under the National Science Foundation (NSF) funding. The project falls
within the Information-based Product Development group (Thrust 2) leaded by Professor
Steven Eppinger. The goal of Thrust 2 research is two-fold, to improve the understanding on
the information-intensive product development process, and to create effective tools and
methodologies to support these activities.
14
The Naval Research Laboratory (NRL) and the Lockheed Martin Tactical Defense Systems
(LMTDS) are the two industrial partners in this project. LMTDS is currently commercializing
an optical machine-condition monitoring technology developed by the NRL. Together the two
industrial partners provide the data and the consulting time of their researchers and engineers
necessary for building the application demo of the Thrust 2 tools.
Four Thrust 2 research groups are involved in this project, representing four tools designed to
address challenges faced by product managers, manufacturing engineers, and other product
developers everyday. Listed below are the names of the tools and their leading researchers:
"
Distributed Object-based Modeling Environment (DOME) by Professor Dave Wallace and
the CADLAB
*
Design Structure Matrix (DSM) by Professor Steven Eppinger and Dr. Ali Yassine
*
KCTool by Professor Anna Thornton and Tony Chen
" Assembly Designer by Dr. Dan Whitney and Gaurav Shukla
The author of this thesis is working under the supervision of Dr. William Finch, a research
scientist at the CIPD. He is the manager of the Product Development Integration Laboratory.
1.4 Outline of Thesis
This thesis paper explores the integration of four Thrust 2 tools - Assembly Designer, DOME,
DSM, and KCTool. This research, motivated by the need to create a common ground on
which the interaction of the tools can be studied and discussed, is presented in the remaining
chapters as follows:
Chapter 2, "Thrust 2 Tools", introduces the four Thrust 2 tools, their benefits, and their
installation instructions.
Chapter 3, "The LaserNet Fines Case", presents the product development case provided by
the Naval Research Laboratory and the Lockheed Martin Tactical Defense Systems. The
technology behind the LaserNet Fines system is disclosed, and sample applications for the
Thrust 2 tools are discussed.
15
Chapter 4, "Tool Usage Logs", serves as a trouble-shooting guide of the tools.
This is
intended to expedite the tool learning process of students and researchers who want to
participate in the Thrust 2 integration efforts in the future.
Chapter 5, "Tool Integration", describes a framework for defining integration.
Integration
opportunities of the Thrust 2 tools are proposed based on such framework.
Chapter 6, "Conclusion", summarizes the thesis project and discusses research opportunities
for the Product Development Integration Laboratory in the future.
16
CHAPTER 2: THRUST 2 TOOLS
Presented in this chapter are four information-based product development tools. These tools
are developed independently by a number of Thrust 2 faculty members and research
scientists aiming to address challenges of various natures throughout the product
development process. A description of each tool is provided, along with a list of benefits and
their installation requirements.
Note that the descriptions provided in this thesis represent
only the snapshots of the tools at the current stage. Some of these tools are going through
rapid revisions and modifications on a continuous basis.
2.1 Assembly Designer
2.1.1 Tool Description
Assembly Designer is an integrated suite of computational tools for assessing the
manufacturability of mechanical systems. Using Assembly Designer, product developers are
able to create assembly models in the form of Datum Flow Chain (DFC), a directed graph
containing geometric information of a mechanical design, such as coordination, mating feature
definition, and degree-of-freedom constraint. Together with the precedence relation input on
how the components in the assembly can be disassembled in different ways, the DFC models
can be used to generate all feasible assembly sequences associated with the mechanical
design, enabling the product developers to explore the assembly design space systematically.
The following are the embedded software modules in Assembly Designer and their
functionality listed in the order of execution [2]:
" SPAS - SPAS derives precedence relations associated with the DFC models through a
series of yes/no questions posted to the users on how system components can be
disassembled from each other.
*
DFCPR - DFCPR derives precedence relations based on geometric and feature
information contained in the DFC.
*
Constraint Checker - Constraint Checker performs constraint analysis on geometric
information contained in the DFC models defined through the Assembly Designer
graphical user interface.
17
*
PRED - PRED combines the independent results obtained from the SPAS and the
DFCPR, then translates the relations into C code.
*
LSG - LSG accepts the codes from PRED and generates all feasible assembly
sequences.
* EDIT - EDIT enables interactive editing of the sequences, assisting the user to obtain the
optimal set of sequences by the process of elimination.
The following screenshots illustrate the graphical user interface of Assembly Designer.
bc
Figure 2.1: Assembly Window Interface.
18
Shown in Figure 2.1 are the three embedded windows in the assembly window interface: the
Assembly Window, the Part Window, and the Text Window. The Assembly Window contains
the Datum Flow Chain (DFC) assembly model and the model creation/editing buttons. The
Part Window displays available drawing of an element selected in the DFC model, while the
Text Window shows all related information of the selected element.
Displayed in the example is an assembly model composed of the three parts represented by
the dots labeled a, b, and c. The lines designate assembly liaisons, with the arrows pointing
to the direction of reference, and the numbers on the arrows indicating the degree-of-freedom
(DOF) constraint.
The balloons represent the number of features associated with each
liaison. For example, part a is defining all 6 DOFs of part b with 1 feature, while it is defining
only 4 DOFs of part c using 2 features. Displayed in the Text Window is the information of the
mating liaison between part a and b. Note that there is no associated drawing displayed in the
Part Window, as the graphical bitmaps are not available in this example.
Note that this screenshot only demonstrates the mate type of liaison. Mates are defined as
assembly liaisons that are capable of delivering DOF constraints. Contact is another type of
liaison, which are represented in the Assembly Designer interface by dotted lines. Contacts
by definition are supportive liaisons that do not convey actual DOF constraints.
19
Figure 2.2: Part Data Input Window
Shown in Figure 2.2 is the data input window for part element. This window is triggered when
a part is created using the "Part" button, or when the "Edit" button is applied on an existing
part element in the model. The window contains input boxes for the name of the part, as well
as the part coordinate definition in reference to the global coordinate. For example, the local
coordinate system of part a is 1 unit away from the global origin in the x direction, 0.5 units
away in the y direction, and -2 units away in the z direction. The local coordinate is not
rotated about any axis in reference to the global coordinate.
20
1 J
iL
w
riD~
zz
AM
JL
Ix
user
defined
Figure 2.3: Feature Data Input Window
Shown in Figure 2.3 is the data input window for feature element. This window is triggered
when a feature is added to a liaison using the "Feature" button. The feature matrix indicates
the available feature types in Assembly Designer. Name and DOF constraint of the selected
feature are displayed on the top, and the coordinate definition is displayed on the right.
Illustared in Table 2.1 below are the names and the DOF constraints of the all features listed
in Figure 2.3, ordered from left to right, and from the first row down.
21
Feature Type
Prismatic Peg / Prismatic Hole
Plate Pin in Through Hole
Prismatic Peg / Prismatic Slot
Plate Pin in Slotted Hole
Round Peg / Prismatic Slot
Round Peg / Through or Blind Hole
Threaded Joint
Elliptical Ball and Socket
Plate-Plate Lap Joint
Spherical Joint
Plate Pin in Oversize Hole
Elliptical Ball in Cylindrical Trough
Thin Rib / Plane Surface
Ellipsoid on Plane Surface
Spherical Ball in Cylindrical Trough
Peg in Slotted Hole
Spheroid on Plane Surface
6
5
5
4
4
4
4
4
3
3
3
3
2
2
2
2
1
Degree-of-Freedom Contraint
X Y Z Tx Ty Tz
X Y Z Tx Ty
X Z Tx Ty Tz
X Z Tx Ty
X Z Tx Ty
X Y Tx Ty
X Y Tx Ty
X Y Z Tx
Z Tx Ty
XYZ
Z Tx Ty
X Z Ty
Z Ty
Z Tx
XZ
X Ty
Z
Table 2.1: Feature Types in Assembly Designer [2]
Figure 2.4: SPAS Window
22
Shown in Figure 2.4 is the SPAS window. This window is triggered by clicking "Modules">"SPAS" on the menu bar of the Assembly Window Interface. The SPAS software module
attempts to derive precedence relationships of parts in a DFC model by prompting the user
with a series of yes-no questions on how the parts can be disassemled. For example, by
answering "y" on question number 1, the user is telling the software that it is possible to take
away part a without affecting part b and c, or in other words, the escape path of part a is not
blocked by features of part b and c.
Figure 2.5: EDIT Sequence Graph Window
23
Shown in Figure 2.5 is the EDIT sequence graph window interface. This window is triggered
by clicking "Modules" ->"EDIT"->"Complete" on the menu bar of the Assembly Window.
Assembly sequences are represented in this window by connected assembly states, and the
states are in turn represented by the squares in the liaison matrix, with white squares
indicating uncompleted liaisons and black squares indicating completed ones. For example,
displayed in this screenshot are two possible assembly sequences associated with the DFC
model illustrated in Figure 2.1. The first assembly sequence, the one on the left, starts with
the completion of liaison 2 and finishes with the concurrent completion of liaison 1 and 3. The
alternative sequence on the right starts with liaison 3 and ends with the simultaneous
completion of liaison 1 and 2. The options on the menu bar of the EDIT window enable the
user to assess and eliminate undesirable assembly sequences.
This section is intended to provide some basic familiarities of Assembly Designer. Please
refer to [2] for further information regarding the tool.
2.1.2 Benefits
Assembly Designer offers the following benefits as an engineering tool:
*
It provides a platform for exploring assembly design space in a systematic manner.
*
It enables the practice of Assembly Orientated Design by allowing product developers to
consider manufacturing issues at an early stage of the design process.
" It shortens development cycles by limiting the design alternatives to only those that are
geometrically feasible.
*
It serves as a visualization tool for capturing and presenting assembly models, providing
useful insights on geometric dependencies among system components.
2.1.3 Installation Requirements
Assembly Designer runs primarily on Unix-based operation systems. It can also run remotely
on PCs that are installed with the Linux operation system and Secure SHell (SSH), a secured
telneting program for UNIX machines.
Please refer to the Linux and SSH product
documentation for information on installation [3].
24
2.2 Distributed Object-based Modeling Environment (DOME)
2.2.1 Tool Description
DOME is an object-based modeling environment intended for linking heterogeneous design
models and tools. It enables members in a product development team to share knowledge by
publishing design models in a wide range of formats.
The following is a list of external
programs that are compatible with the current version of DOME:
"
Spreadsheet: Excel
"
Database: MICROSOFT Access
"
CAD: SolidWorks, Ideas
*
Numeric Simulation: MATLAB
To illustrate the linking capability of DOME, let us look at an example in which a purchasing
manager and a design engineer are collaborating in a design project.
The purchasing
manager maintains a spreadsheet containing the cost model of a certain material, while the
engineer uses a numeric simulation to determine the amount of the material required for
achieving certain product performance. These two team members can publish their models
onto a networked system through DOME, and the two models can be linked together to create
an integrated model.
This combined model can then be used for determining the optimal
material requirement based on cost and performance consideration.
When publishing their work onto the network, the user has full control over which parts of the
models are to be shared by others and which are to be protected. Such controlling power is
essential for protecting proprietary design information, especially when multiple companies
are involved in the design effort.
DOME offers design evaluation functions intended to assist product developers in analyzing
and making complicated design tradeoffs. When a member in a development team proposes
a design change in the DOME environment, the change is automatically propagated to other
linked models maintained by his/her team members. Real-time feedback on the effects of the
change to the overall product system can therefore be obtained without having to go through
traditional, and often less efficient communication channels, such as meetings and phone
25
calls. Together with the design preference visualization and evaluation features embedded in
DOME, the real-time feedback capability offers product developers with a mechanism for
evaluating design alternatives in a timely manner. This makes DOME a valuable tool for
reducing design cycle time and improving communication efficiency, especially in situations
when large and geographically distributed development teams are involved.
Lastly, DOME has an optimizer that automatically evaluates design parameters and
determines optimal design configurations based on design preferences defined by the users.
This optimization capability, which is based on genetic algorithm, provides an efficient and
systematic way to explore large design spaces in which a significant number of design
parameters and design alternatives are involved.
The following screenshots illustrate the graphical user interface of DOME.
26
Figure 2.6: DOME Server Windows
Shown in Figure 2.6 are the two DOME server windows. The User Manager Window on the
top allows the assignment of login names and passwords to authorized users of the DOME
service. As illustrated in the screenshot, "Thrust2" is the only authorized user in this particular
example. The DOME Server Manager on the bottom initiates the DOME service and activates
the user login capability. For example, the screenshot indicates that the server "bubbe" is
ready to accept login connections.
27
Figure 2.7: DOME Client Login Window
Shown in Figure 2.7 is the DOME client login window. When user "Thrust2" is ready to login
to the DOME server, he/she opens this client login interface with a web browser, types in the
login name and password, then specifies the server to be connected to. In the situation when
the user is logging in from the same computer on which the server resides, "bubbe" in this
case, the server can be specified as "localhost" as illustrated in the screenshot.
28
Figure 2.8: DOME Client Window
Shown in Figure 2.8 is the DOME client window. The user is able to define variables, attach
external programs, and perform design analysis and optimization on this window interface.
For example, this screenshot illustrates a DOME model defined with the following
components:
29
*
Three variables a, b, c
" Three external program attachments corresponding to Excel, Matlab, and SolidWorks
" A preference function
*
A design criterion
*
A genetic algorithm optimizer
Figure 2.9: DOME Relation Window
Shown in Figure 2.9 is the DOME relation window. The user can define relations among
variables in the DOME model by writing simple C-codes in the "Relation text" box (note that all
statements should therefore end with a semi-colon). In this example, the output / dependent
variable c is set to be equal to the quotient of the input / independent variable a divided by
another input variable b.
30
Figure 2.10 DOME Preference Function Window
Shown in Figure 2.10 is the DOME preference function window. The user can define through
this interface the design preference of a variable. In this example, the preference function is
denoted by the curve on the right hand side, indicating that the acceptance range of the
variable is between 0 and 1 m/s, with the most preferred value falls around 0.8 m/s.
31
Figure 2.11: DOME Optimizer Window
Shown in Figure 2.11 is the DOME Optimizer window. This interface allows the user to define
the search variables and their searching ranges, the objective variable to be optimized, and
the number of generations and the population size associated with the optimization. In this
example, the two search variables are set to be a and b with the searching ranges indicated
on the screenshot.
This section is intended to provide some basic familiarities of DOME. Please refer to [4] and
[5] for further information regarding the tool.
2.2.2 Benefits
DOME offers the following benefits as an engineering tool:
32
It facilitates product development process across organization and geographic boundaries.
It breaks apart complex modeling and distributes the pieces among specialized groups.
*
It provides information-sharing control so that proprietary models and data can be
protected.
*
It enables linkage of different data formats so developers can create their product models
using programs that they are most familiar with.
.
It reduces time for iteration through the real-time feedback mechanism, and thereby
shortens design cycle time.
2.2.3 Installation Requirements
DOME runs on PCs installed with Windows 95, Windows NT or newer version of the two
Windows operation systems. The computers are also required to have Visual Studio, Visual
J++ and MSDN Library with service pack 6.0 or above, along with all the desirable external
programs listed in section 2.2.1.
An automatic installation program is available on the DOME CD for guiding the standard
installation process.
Mentioned below are special installation procedures associated with
some of the external programs:
Java Plug-in
*
After the standard DOME installation is completed, click on the DOME Client icon on
Desktop to open up either Netscape Navigator or MICROSOFT Explorer
*
Click on the download link for Java Plug-in 1.2.1 to go to the SUN website
" Follow the instruction to install the Java Plug-in onto the computer
MATLAB
*
After the standard MATLAB installation is completed, right click the "My Computer" icon on
the Desktop to select "Properties"
*
Choose the "Environment" tab
33
" Add a User Variable "path" by first clicking on one of the existing User Variables, then go
to the "Variable" textbox and type in the name "path"
In the "Value" textbox, enter "%path%; C:\MATLAB\bin".
*
Note there is a semi-colon
separating the two paths. Also note that the directory in which MATLAB is installed on
your computer may not be "MATLAB". In that case just replace "MATLAB" in the path by
the MATLAB directory name on your computer
SolidWorks
*
After the regular installation is completed, go to the directory in which DOME is installed
on your computer
*
Go to the bin directory and open the environment.txt file
*
Add the statement "include SWDimModule.h" to the list of include statements in the file
Note that the current version of DOME can only work with SolidWorks 97 Plus, but not with
the later releases of the software.
2.3 Design Structure Matrix (DSM)
2.3.1 Tool Description
Design Structure Matrix (DSM) is a management tool for systems with complex dependencies.
By presenting system elements and their interactions in a simple matrix format, DSM provides
a compact and clear visual representation of the system structures. DSM also offers a
number of analytical algorithms for manipulating the elements and interactions, and thereby
Two major algorithms are clustering, which
groups system elements with strong dependencies into modules, and partitioning, which
reorders system elements to eliminate feedback loops. There are four types of DSM for
improving the characteristic of the systems.
handling systems of various natures, they are:
34
*
Component-Based DSM - A component-based DSM documents interactions among
components in a system. These interactions include spatial, energy, information, and
material. Utilizing the clustering algorithm, this type of DSM can be applied on system
architecture engineering and designing.
*
Team-Based DSM - A team-based DSM records information flow among various
organizational entities. Utilizing the clustering algorithm, this type of DSM can be applied
on organizational design, interface management, and team integration.
*
Activity-Based (Task-Based) DSM - An activity-based DSM depicts ordering of activities in
a process and their input/output relationships. Utilizing the partitioning algorithm, this type
of DSM can be applied on project scheduling, activity sequencing, and cycle time
reduction.
*
Parameter-Based DSM - A parameter-based DSM models system architecture based on
parameter interrelationships. Utilizing the partitioning algorithm, this type of DSM can be
applied on process construction and decision point assignment.
This thesis project only focuses on the component-based DSM.
An Excel spreadsheet is
created to facilitate the process of component clustering and system architecture designing.
This spreadsheet takes in a component-based DSM of any size, runs it through a C++
clustering program, then proposes a module configuration for the system with minimal
interdependencies.
35
The following screenshots illustrate the graphical user interface of the DSM spreadsheet:
Figure 2.12: DSM Input Interface
Shown in Figure 2.12 is the DSM input interface. The user can record through this interface
the dependencies and interactions among components in a system.
For example, in the
three-component system illustrated in the screenshot above, component a has no interaction
with component b and is therefore assigned with a value of 0 in the corresponding square in
column 1 row 2. Component a however has very strong interaction with c and this
dependencies is indicated by the value of 3 in the square in column 1 row 3. In a componentbased DSM, a high dependency value usually translates to a high desire for the clustering of
the two components, while a low value suggests that components should be kept separated if
possible.
36
Figure 2.13: Clustering Interface
Shown in Figure 2.13 is the clustering interface. This is where the C++ clustering program is
applied to determine how the components can be clustered in order to capture the maximum
amount of system interactions within the clusters. The best clustering formation therefore
supports the lowest amount of inter-cluster interaction, which is indicated by the coordination
cost. In this example, the algorithm is proposing a two-cluster formation, one with component
a and c, and the other with component b and c.
37
Figure 2.14: Clustering Result
Shown in Figure 2.14 is the interface for presenting the DSM clustering result. Same as the
formation illustrated in Figure 2.13, there are two clusters in this example, one with component
a and c, and the other with component b and c. Note that there is no system element
suggested in this formation. System elements are components that they cannot be clustered
into one particular group due to strong interaction with multiple components.
This section is intended to provide some basic familiarities of DSM.
Please refer to [6] for
further information regarding the tool.
2.3.2 Benefits
Component-based DSM offers the following benefits as an engineering tool:
*
It enables the evaluation of a large number of module configurations at a low cost.
*
It reduces time for dependency-based architecture designing, and thereby shortens design
cycle time.
38
*
It offers visualization of the system dependencies, and promotes better understanding and
communication of products.
2.3.3 Installation Requirements
The DSM spreadsheet runs on PCs installed with Windows 95, Windows NT or newer version
of the two Windows operation systems.
MICROSOFT Office, in particular the Excel
spreadsheet program, is another software requirement for this tool.
Please note that the
current version of the DSM spreadsheet is only compatible with Office 97, but not with Office
2000.
The following are special DLL installation procedures of KCTool:
*
Create a DSM directory under the C drive of the computer
*
Copy the two DLL files CCost.dll and Clusterdl.dll into the DSM directory
2.4 KCTool
2.4.1 Tool Description
KCTool is a prototype software for managing manufacturing variations associated with Key
Characteristics (KCs) of a product. Key Characteristics are defined as product features that
have a significant impact on product requirements when there is a variation. Through its
modeling, simulation, and optimization capabilities, KCTool offers a quantitative method for
determining the optimal inspection plan that supports highest product quality at the lowest
cost.
KCTool can be used as a visual tool for generating KC Flowdown models of a product. Such
models contain hierarchical relationships of Key Characteristics from product and sub-system
level down to part and process level, along with the mathematical representations of variation
stack-ups at each level. Also included in the models are manufacturing process data related
to each Key Characteristic, such as variation distribution, cost of assembly, and cost of
inspection, etc. Implementation of these Flowdown models in KCTool provides a mechanism
39
for predicting production cost based on the variations introduced by the manufacturing
process, the inspection strategy, and the final product requirements.
KCTool is also a powerful tool for evaluating inspection plans. Utilizing the cost prediction
function mentioned above, Monte Carlo simulation can be run in KCTool to calculate the
expected cost of specific inspection plans. Assessment of a large number of inspection plans
can therefore be done at minimal cost.
Lastly, stochastic optimization algorithm can be carried out in KCTool to determine the best
inspection strategy for a manufacturing process based on quality and cost consideration.
Details such as inspection limits, location of inspection, and corrective actions are proposed in
a closed form solution.
The following screenshots illustrate the graphical user interface of KCTool.
I
-b
part 1
i c
-I-
system
part2
~at
Figure 2.15: KCTool Main Window
40
Shown in Figure 2.15 is the main interface window for KCTool.
The user can create the
Flowdown model using the various buttons on the top toolbar. The system in the example is
composed of two components, part 1 and part 2. There is one KC in each component,
namely b and c for part 1 and part 2 respectively. Together they deliver the system KC a.
Figure 2.16: KC Data Input Interface
Shown in Figure 2.16 is the KC data input interface. The user can input process capability,
inspection plan, corrective action, and other related information by navigating through the tabs
on the top. Illustrated in this example is the data input interface for KC b.
41
Figure 2.17: Inspection Simulation Interface
Shown in Figure 2.17 is the result of an inspection simulation.
It presents the simulated
production statistics under each of the three KC, a, b, and c. There is no cost associated with
inspection and other failure preventive actions in this example. The failure rate of the
production is at the level of 51/100, and the total cost of production is calculated to be 19500
units, or 195 units per product manufactured.
42
- b
2.71 SD
patt1
1.72 SD
systemM
I
part 2
I
Figure 2.18: Inspection Optimization Result
Shown in Figure 2.18 is the result of an inspection simulation. It indicates that in order to
achieve the optimal production result at the lowest cost, inspection should be performed for
KC a and c at 2.71 and 1.72 standard deviations respectively. And in case of out-of-spec, the
parts should be reworked until they satisfy the inspection limits. Although not illustrated in this
black and white screenshot, suggestions for corrective actions are indicated on the KCTool
user interface by the highlights on the KC labels, with green representing rework, and blue
representing scrap.
This section is intended to provide some basic familiarities of KCTool. Please refer to [7] for
further information regarding the tool.
2.4.2 Benefits
KCTool offers the following benefits as an engineering tool:
43
It identifies optimal inspection strategies of manufacturing systems in a quantitative
manner
*
It facilitates constant improvement of the risk management and quality control process
It provides a platform for experimenting different risk management strategies with minimal
time and capital investment
.
It serves as mechanism for capturing and sharing product architectures, variation models,
and inspection models
2.4.3 Installation Requirements
KCTool runs on Windows 95, Windows NT or newer version of the two Windows operation
systems. The only external program required for running KCTool is MICROSOFT Access.
The following are special installation procedures of KCTool:
DLL Files Setting
*
Copy four KCTool specific Dynamic Link Library (DLL) files into the System32 directory
under the C drive. Names of the four files are Mfc42d.dll, Mfcd42d.dll, Mfco42d.dll, and
Msvcrtd.dll
Database File Setting
*
Go to the Control Panel
*
Click on the ODBC Data Sources (32bit) icon to open the ODBC Administrator
*
Click on the System DSN tab on the top of the administrator window
*
Click the "Add" button, then select to set up a Microsoft Access Driver
*
Enter Data Source Name as "kctree"
*
Select the driving database file for KCTool
Note that the current version of KCTool is not yet Office 2000 compatible. Please make sure
that the Access component of the Office 97 suite is installed on the computer on which
KCTool is to be run.
44
CHAPTER 3: THE LASERNET FINES CASE
A product development case is introduced in this chapter, after which sample applications for
each of the four Thrust 2 Tools are presented to illustrate how the tools can be utilized to
address development challenges associated with the case. Data for the development of these
tool applications are provided jointly by the Naval Research Laboratory (NRL) and the
Lockheed Martin Tactical Defense Systems (LMTDS).
3.1 The Technology
LASERNET FINES is an optical oil debris monitor designed to measure the size distributions
and shape characteristics of particles in machine fluids.
It provides information on type,
severity, and rate of progression of specific failure and wearing conditions in mechanical
systems based on particle shapes and size trends observed in fluid samples over time. The
device also provides information on particulate contamination in hydraulic, fuel, and other fluid
systems [8].
The basic concept of LaserNet Fines is show in Figure 3.1.
Fluid from a sample bottle is
pumped through a transparent flow cell. Coherent light from a pulsed laser diode is then used
to back-illuminate the fluid sample, while a CCD camera captures the images through macro
focusing optics.
The images are handled by an electronic processing system capable of
classifying particle images into mechanical wear classes such as cutting, sliding, and fatigue
[8].
45
Oil flow from
Sample bottle
Laser Diode
Flow Cell
Macro Lens
Camera / Image
Processor
Figure 3.1: LaserNet Fines System Diagram
Figure 3.2 is a CAD model of the optical subassembly, which contains most of the core
components in the LaserNet Fines system.
Camera Adjustment Plate
Lens Support
Laser Diode
Flow Cell
Fiber
Optic
CameraMacro Lens
Camera Cover
FIbL
Optical
Plate
Opld
M
Fiber Optic Mount-
9
Figure 3.2 CAD Model of Optical Subassembly
46
The LASERNET FINES is developed under the Condition-Based Maintenance Program of the
Office of Naval Research (ONR). The basic technology capabilities are derived from research
conducted at the NRL, while the product development works are being done at the LMTDS
site under the ONR contract.
The product, coded Gen1, is a portable batch processor
designed for shipboard applications. There are a number of Gen1 machines currently being
evaluated under different operational environments, and the Lockheed Martin development
team is collecting the evaluation data for the development of Gen2, a device suitable for
commercial production.
3.2 Thrust 2 Tool Applications
Described in this section are sample applications of the four Thrust 2 tools based on the
LaserNet Fines case. These are independent applications designed to demonstrate a number
of selected capabilities of each tool on addressing specific development challenges. The
decision on which tool capabilities to be presented in the applications is made based on the
availability of data, as well as the ease of demonstration and discussion. Application script for
each of the tool can be found in Appendix 2.
3.2.1 Assembly Sequence Assessment Using Assembly Designer
Application Scenario
LMTDS has traditionally been a major government contractor, with a product portfolio that
biases towards the high quality and low volume category. The LaserNet Fines is one of the
few exceptions. Targeted for the commercial market, the Gen2 system is designed primarily
for high volume production.
For that reason the engineers are committing a significant
amount of effort on defining a manufacturing system that warrants high efficiency and low
production cost. As a development exercise, the engineers are interested in exploring the
manufacturability of the Gen1 design, hoping that it will provide useful insights on how the
Gen2 design can be improved based on Assembly Oriented Design (AOD) practices [2].
47
Technical Details
This sample application illustrates how Assembly Designer can assist the engineers in
exploring the assembly design space in a systematic manner. Datum Flow Chain (DFC)
model of the Gen1 optical subassembly is created as shown in Figure 3.3. Note that the
model is simplified to contain only 9 components, with their names and abbreviations listed in
Table 3.1.
Abbreviation
Camera
CA plt
CM blks
CS blk
F cell
Lsprt
M lens
Madjstr
OpIt
Part Name
Camera
Camera Adjustment Plate
Cell Mounting Blocks
Cell Support Block
Flow Cell
Lens Support
Macro Lens
Micro-adjuster
Optical Plate
Table 3.1: DFC Part Abbreviations
48
M_lens
F_cell
_bIks
camera
LKsprt
A-pIt
CSblk
M-adj str
Figure 3.3: DFC Model of Gen1 Optical Sub-assembly
Each component is assigned a coordinate definition, which describes its location in reference
to the global coordinate of the assembly. The global coordinate in this sample application is
set to coincide with that of the Optical Plate component.
For example, the coordinate
definition for the Micro-adjuster in the six-degree framework is illustrated in Table 3.2,
indicating that it is 5.41 units (inches in this case) away from the x-axis, 2.5 units from the yaxis, and 3.375 units from the z-axis. There is no rotation of the component coordinate about
any axis.
49
Angular Coordinate Transform
Tx: 0.000000
Ty: 0.000000
Tz: 0.000000
Linear Coordinate Transform
X: 5.413000
Y: 2.500000
Z: 3.375000
Table 3.2: Coordinate Definition for Micro-adjuster
Every assembly liaison, both mates and contacts, is defined in Assembly Designer by an
attribute set representing their types, the parts involved, the associated features, and the
Shown below in Table 3.3 is the definition of the mate connecting
between the Optical Plate and the Micro-adjuster. Note that the complete component and
liaison definition of the optical subassembly can be found in Appendix 1.
feature coordination.
Liaison Attribute
Type of Liaison
Parts
Feature(s)
Feature Coordination
Value
Mate (6 DOF)
Oplt
M_adjstr
Prismatic Peg / Prismatic Hole (6 DOF)
Y: 0.000000
X: 0.000000
Ty: 0.000000
Tx: 90.000000
Z: 0.000000
Tz: 0.000000
Table 3.3: Definition for Liaison between Optical Plate and Micro-adjuster
Once the DFC model is built, the engineers can step through SPAS, DFCPR, Constraint
Checker, and eventually get to the EDIT window where the complete assembly sequence tree
is displayed as shown in Figure 3.4.
50
Figure 3.4: Assembly Sequence Tree for Gen1 Optical Sub-assembly
The engineers can look at all feasible assembly sequences on the EDIT interface, pinpoint
and then eliminate those that are not desirable based on specific engineering criteria. For
example, one engineering criterion suggests that mating of the Camera Adjustment Plate to
the Optical Plate and the Micro-adjuster should be postponed as one of the last assembly
steps. This is due to the fact that the Micro-adjuster is used to calibrate the distance between
the Flow Cell and the Macro Lens, and the calibration process cannot be proceeded until all
the components have been assembled in place. Utilizing criteria such as the one mentioned
above, engineers are able to effectively reduce the number of assembly sequences under
consideration to a manageable amount.
More detailed assessment, such as production
testing, can then be conducted on the remaining sequences to determine the optimal
assembly process. Shown in Figure 3.5 is the assembly tree after just one step of eliminating
all the sequences that do not have liaison 2 and 3 as the last two liaisons to be completed.
Liaison 2, which is indicated by the square in row 1 column 2 of the liaison matrix, represents
the mate between the Camera Adjustment Plate and the Optical Plate, whereas liaison 3 in
51
row 1 column 3 represents the mate between the Camera Adjustment Plate and the Microadjuster. Note the size reduction compare to the original sequence tree in Figure 3.4:
Figure 3.5: Edited Assembly Sequence Tree
Usaqe Key Points
A successful operation of the Assembly Designer relies on a fair amount of human interaction.
Careful engineering judgements are required during the feature assignment process due to
the fact that Assembly Designer can only work with partially and fully constrained assembly in
the six degree-of-freedom framework, whereas in reality many systems are overly constrained
either for specific engineering purposes or by bad designing practices. Therefore, users are
often required to model and simplify the actual engineering problems in order to obtain
meaningful results from the program. During the sequence editing process, knowledge on the
design preferences and assembly constraints is necessary for the elimination of the
52
undesirable assembly sequences and the reduction in effort on determining the optimal
assembly process.
3.2.2 Component Selection and Optimization Using DOME
Application Scenario
The product development team at LMTDS has been working on creating the Bill of Materials
(BOM) for the Gen2 system. At the current stage the focus is mainly on the components
carried over from the Gen1 design. For a typical component, a number of vendors are invited
to give product presentations to the development team, which is composed of managers and
engineers representing different functional groups within the LMTDS.
After all the vendors
have presented their product solutions, the team works together to evaluate the alternatives
and decide upon one to be listed on the BOM. Since the process requires the cooperation of
a number of people inside and outside of LMTDS, communication can be a challenge.
Currently information is being handled through traditional channels such as meetings, phone
calls, and emails.
Technical Details
This sample application illustrates how DOME can assist the development team in
streamlining the BOM creation process. Three DOME models are created on three different
machines, representing the workstations maintained by an in-house system engineer located
at the local LMTDS site, an NRL fluid mechanics specialist residing in Washington D.C., and
an overseas vendor.
The local LMTDS model has the following modules:
*
A catalog of 5 vendors created by the purchasing department. Each entry in the catalog
depicts a laser-attached flow cell unit with the characteristic variables listed in Table 3.4.
53
Variable Name
Abbreviation
Laser Beam Diameter (m)
Laser Wave Length (m)
Laser Power (W)
BeamDia
WaveLength
Power
Pulse Width (s)
Depth of Field (m)
PW
ReqDepth
Supported Flow Velocity (m/s)
Cost of unit ($)
FlowV
Cost
Table 3.4: Characteristic Variable Abbreviations for DOME Product Catalog
*
An Excel spreadsheet containing performance calculations such as flow rate limits,
pressure change, and Reynold's number for the fluid flow, etc.
*
A DOME Design Analysis container with definitions of two design evaluation criteria and a
genetic algorithm optimizer. The two evaluation criteria are described by the geometricbased Height of Cell preference function and the performance-based Reynold's Number
preference function as illustrated in Figure 3.6.
*
A relationship container with references to the remote fluid mechanics model
*
Another relationship container with references to the remote vendor component model
54
Figure 3.6: Design Evaluation Criteria
The remote NRL model contains a MATLAB model that displays the fluid flow profile across a
range of viscosity and pressure drops when given the output from the LMTDS Excel model.
Another remote model, the one maintained by the vendor, contains a SolidWorks CAD model
of the proposed product solution, along with an Excel model that calculates the cost of the
55
product based on the dimensional information from the CAD model. Note that the complete
set of data files for the three interconnected DOME models can be found in Appendix 1.
With these three interconnected models in place, the development team can plug in the
different alternatives of the laser-attached flow cell unit and observe the effects on the fluid
flow profile and other product performances. In other words, preliminary product assessment
can be conducted right at the LMTDS local site, without any significant vendor involvement
except the providing of the product models through DOME. According to the assessment
result, the product from Vendor1 provides the evaluation score of 0.71 out of the total of 1,
which is the highest out of the five proposed product solutions. Therefore, Vendor1 is to be
selected as the supplier for the laser-attached flow cell unit.
Once the vendor selection has been finalized, the team can also explore the possibility of
customizing the component specifically for the LaserNet Fines system, given that the vendor
has the manufacturing capability to support such kind of design customization. In this sample
application, the optimizer is set to have the Depth of Field of the laser diode (ReqDepth) and
the supported Flow Velocity (FlowV) as the two search variables. The objective of the
optimization is an evaluation score calculated based on the Height of Cell and the Reynold's
Number design criteria. In this sample application, the optimization is set to run for 5
generations with the population size of 3 in each generation. The result converges to the
ReqDepth of 2.38E-4 m and the FlowV of 0.05 m/s, with the evaluation score of 0.73. Note
that designs with even higher evaluation scores can be expected when a more thorough
optimization operation is performed, i.e. with a higher number of generations and a higher
population size is used.
However, the time it takes for such operation to converge is
significantly higher than what is illustrated in this sample application.
Usage Key Points
In order to take full advantage of the DOME evaluation and optimization capabilities, it is
preferable to have a system model composed of a fair number of modules. Creation of such
model can be a time and labor intensive process, but this initial investment is offset by the
design iteration and evaluation with minimal communication
requirements. DOME does not completely eliminate the need of meetings and phone calls
ability of doing rapid
56
per se. What it offers is a way to bypass some of the less efficient communication processes,
of which the associated cost and time saving can be tremendous.
3.2.3 Module Formation Using Design Structure Matrices
Application Scenario
Engineers at LMTDS are working on defining the Gen2 system architecture. The existing
Gen1 design has excessive amount of cables running across the interior of the device.
According to the engineers, these cables complicate the assembly process by reducing
accessibility to some of the system components. Furthermore, the weight of the cables exerts
a downward force on the electronic connectors, a situation determined to cause component
displacement and various other manufacturing problems experienced at the production site.
The engineers believe that by rearranging the locations of the system components and
grouping those with strong interactions in close proximity, they can achieve the reduction of
wiring and manufacturing difficulties in the system.
Technical Details
This sample application illustrates how component-based DSM can assist the LMTDS
engineers in determining the appropriate module formation for the Gen2 system architecture.
Data for this application were collected through a detailed survey conducted at the LMTDS
site. Engineers were asked in the survey to assign dependency value to every pair of the 19
major components in the system. The dependency value of 1 indicates strong interaction and
therefore high preference for close proximity between the pairs, 0 represents indifference,
while -1 suggests that the two components should be separated as far as possible. Shown
below is the survey data captured in four DSMs corresponding to the spatial, energy,
information, and material dependencies:
57
SPATIAL DSM
COMPONENTS
SBC, LCD, Touch
Frame Grabber
Pump, Peristaltic
A
B
C
Camera
D
Focus Optics
Laser & Optics
Laser Power Supply
Interface Board
Flow Cell
Ultrasonic Cleaner
LS-120 Floppy
150W Power Supply
Power Switch
Power Connector
Power Line Filter
Power Relay
AC Fan
Input Sample Bottle
Discharge Bottle
E
F
G
H
1
J
K
L
M
N
0
P
Q
R
s
I
I I
I
A B C D E F G H I J K L
1 -1
1
-1 -1
1
-1
-1
-1
-1
-1 -1
1 1
1
-1 -1 -1
1
1
-11-1 -1
-1 -1
1
-1-1-1
-1-1-1
1
11
-1 -1
1
1
1
-1 -1
-1
-1 -1 -1 -1 -1
-1 -1 -1 -1 -1
-1 -1 -1 -1 -1
-1
-_-_-
1-___
_-_-_-
1
-1
M N OP Q R S
1 -1 -1
-1 -1 -1
-1
-1 - -1
-1 -
-1 -1 -1 -1 -1
-1 -1 -1 -1 -1
-1 -1 -1 -1 -1
1 -1
-1 -1
-1 -1
-1 -1 -1
1 1
-1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1
1
-1 -1
-1 -1
-1 -1
-
-1
-1
-1
1 1
1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1
Figure 3.7 Spatial Dependency Matrix
ENERGY DSM
COMPONENTS
A
SBC, LCD, Touch
Frame Grabber
B
Pump, Peristaltic
C
Camera
D
Focus Optics
E
Laser & Optics
F
Laser Power Supply G
Interface Board
H
Flow Cell
_
J
Ultrasonic Cleaner
LS-120 Floppy
K
150W Power Supply L
Power Switch
M
Power Connector
N
Power Line Filter
0
Power Relay
P
AC Fan
Q
Input Sample Bottle R
Discharge Bottle
S
A B C D E F G H I
1
1
.
J
M N O P Q R S
K L
1
-
1.
1
1
1
1
1I
1
1
--
-
1
1
Figure 3.8 Energy Dependency Matrix
58
INFORMATION DSM
COMPONENTS
SBC, LCD, Touch
Frame Grabber
Pump, Peristaltic
Camera
Focus Optics
Laser & Optics
Laser Power Supply
Interface Board
Flow Cell
Ultrasonic Cleaner
LS-120 Floppy
150W Power Supply
Power Switch
Power Connector
Power Line Filter
Power Relay
AC Fan
Input Sample Bottle
Discharge Bottle
A
B
C
D
E
F
G
H
I
J
K
L
M
N
0
P
Q
R
S
A B C D E F G H I J
1
1
1
1
1
1
1
1
-|1
1
1
K LM N 1
1
P Q R S
1
1
1
Figure 3.9 Information Dependency Matrix
MATERIAL DSM
COMPONENTS
SBC, LCD, Touch
Frame Grabber
Pump, Peristaltic
Camera
Focus Optics
Laser & Optics
Laser Power Supply
Interface Board
Flow Cell
Ultrasonic Cleaner
LS-120 Floppy
150W Power Supply
Power Switch
Power Connector
Power Line Filter
Power Relay
AC Fan
Input Sample Bottle
Discharge Bottle
II
A B C D E F G H I
A
B
C1
D
E
F
G
H
I
J
K L M N O P Q R S
1
-1
-1
-1
1
-1 1
J
K
L
M
N
0
P
Q
R
S
Figure 3.10 Material Dependency Matrix
59
A combined DSM is created by summing the four dependency matrices.
Since the DSM
clustering algorithm cannot work with negative dependency values, an adjustment factor of 1
is added to each entry to reset the lowest dependency value to 0 before the combined DSM is
inputted into the DSM spreadsheet.
Through the embedded clustering algorithm, the
spreadsheet is capable of proposing a number of alternative module formations with minimal
coordination cost. The coordination cost for each module formation is calculated based on the
size of the modules, the number of modules, and the effectiveness of the module
configuration in containing system dependencies. The proposed alternatives are evaluated,
and promising ones are selected based on experience of the engineers and other design
criteria not captured by the DSMs. Shown below is one of the proposed module formations:
System
Elements
150W Power
Supply
Cluster 1
Ultrasonic
Cleaner
Input Sample
Bottle
Discharge
Cluster 2
Cluster 3
150W Power
Supply
Power Switch
Pump,
Peristaltic
Camera
Power
Focus Optics
Power Line
Filter
Power Relay
AC Fan
SBC, LCD,
Touch Screen
Frame Grabber
Pump,
Peristaltic
Connector
Bottle
Cluster 4
Laser & Optics
Interface Board
Laser Power
Supply
Flow Cell
LS-120 Floppy
150W Power
Supply
AC Fan
150W Power
Supply
Table 3.5: DSM Clustering Result
This particular clustering result indicates that the Gen2 architecture should be composed of
four modules:
*
Cluster 1 - the fluid sample handling system
*
Cluster 2 - the power system
*
Cluster 3 - the optic system
60
0
Cluster 4 - the control and signal processing system
The shared components of AC Fan between Cluster 2 & 4 and Peristaltic Pump between
Cluster 3 & 4 also indicate there are interactions existing among the modules. The 150W
Power Supply is listed as System Element because it has strong interactions with multiple
modules and therefore cannot be grouped into any particular module.
Usage Key Points
It may appear to the reader that the engineers can probably come up with such a module
configuration without the assistance of DSM, that the clustering result is merely stating the
obvious. This is because we are working on a simplified system with only 19 components.
Imagine we are to determine the module formation of a system with hundreds or thousands of
components, engineers without a systematic tool such as DSM can only manage to explore
the vast design space through a trial-and-error process, which can be time and capital
intensive.
3.2.4 Inspection Strategy Design Using KCTooI
Application Scenario
The manufacturing engineers at LMTDS are currently facing a challenge on production
variation control. They discover that when the Gen1 machines are assembled, the distance
and the alignment between the Flow Cell and the Camera often fall out of the specification
limits. Since this dimension governs the focal characteristic of the system, variation of such
cannot be tolerated. In order to fix this problem, assembly workers have to spend hours of
extra time reworking and realigning the components, which causes the production cost to
increase significantly. The development team is working on eliminating this variation problem
from the Gen2 design, but while the Gen1 machine is still in production, the manufacturing
engineers want to develop an inspection strategy that guarantees the delivery of satisfactory
products at minimal cost addition to the overall production process.
Technical Details
61
In this sample application a Key Characteristic Flowdown model of the optical subassembly
has been created as shown in Figure 3.11. The model is simplified to contain only 5 parts,
which make up 2 subassembly and 1 system. Listed in Table 3.6 are the names of the
system/subsystem/part, their associated KCs, and the KC abbreviations. Note that all
coordinates in the table are defined in reference to the global coordinate of the Optical
Assembly.
62
System/Subsystem/Part
OtclAsml(sse)Flow
Optical Assembly (system)
Key Characteristics
Distance between the Lens and the
Cell window___________
Angular
alignment
between
the
Lens and the Flow Cell Window
Horizontal coordinate of the Flow
Cell window
Cell Unit (subsystem)
Optic Unit (subsystem)
Angle between the Flow Cell
window and the vertical reference
plane
Horizontal coordinate of the Lens
Angle between the Lens and the
vertical reference plane
Optical Plate (part)
Size of
Optical
Size of
Optical
Size of
screw hole #1 for mating the
Plate to the Mounting Base
screw hole #2 for mating the
Plate to the Mounting Base
screw hole #1 for mating the
Optical Plate to the Camera
Flow Cell (part)
Size of screw hole #2 for mating the
Optical Plate to the Camera
Thickness of the Flow Cell
Horizontal coordinate of screw hole
#1 and #2 for mating the Mounting
KC Abbreviation
Distance
Alignment
Alignment
Window X Location
Angle Tilted
Lens X Location
Angle Tilted
Screw1 Hole Size (MB)
Screw2 Hole Size (MB)
Screw1 Hole Size (C)
Screw2 Hole Size (C)
Cell Thickness
Screwl +2 X Location
Base to the Optical Plate
Mounting Base (part)
Lens (part)
Camera (part)
Vertical coordinate of screw hole #1
for mating the Mounting Base to the
Optical Plate
Vertical coordinate of screw hole #2
for mating the Mounting Base to the
Optical Plate
Thread tolerance of mating interface
to the Camera
Horizontal coordinate of screw hole
#1 and #2 for mating the Camera to
the Optical Plate
Vertical coordinate of screw hole #1
for mating the Camera to the Optical
Plate
Vertical coordinate of screw hole #2
for mating the Camera to the Optical
Plate
Table 3.6: KC Abbreviations
63
Screw1 Y Location
Screw2 Y Location
Thread Tolerance
Screw1 +2 X Location
Screw1 Y Location
Screw2 Y Location
-Cell Thickness
Distance
-Window X Location
Flow Cell
-Screwl +2 X Location
-Angle Tilted
-Screw1
Y Location
Screw2 Y Location
Cell Unit
-Lens X Location
Lens
-Angle Tilted
Alignment
Mountinci Base
-Thread Tolerance
-Screwi +2 X Location
-Screw1 Y Location
-Screw2 Y Location
Optic Unit
Camera
-Screw1 Hole Size (MB)
-Screw2 Hole Size (MB)
Screw1 Hole Size (C)
Screw2 Hole Size (C)
___________Optical Assembly
.......... c al Plate________
Figure 3.11: KC Flowdown Model of Optical Sub-assembly
Two product KCs to be managed in this model are the distance and the alignment between
the camera and the flow cell. Note that this is a special case in that LMTDS does not have
enough data to support the creation of the KC model. Since less than 10 units of the Gen1
system have been built since the introduction of the product, the manufacturing data,
especially the statistical data on production process capability, is simply not available. The
author therefore had to create an estimated set of manufacturing data based on the actual
64
nominal values of each KCs.
An inspection simulation is performed to verify that the
production variation problem is represented in the estimated data, i.e. that most of the reworks
are done for the alignment and the distance KCs. The result of the simulation is presented in
Figure 3.12, illustrating that out of a hundred units produced, 10 units would require rework for
the distance KC, and 81 units for the alignment KC.
Figure 3.12: Inspection Simulation Result
An inspection optimization is then performed on the data at 100 generations with 100 units
built per generation. The result, as shown in Figure 3.13, suggests that inspection should be
done for the following three KCs with the indicated inspection specifications:
*
Screwl Y Location of the Mount Base - representing the vertical position of the screw hole
on the Mounting Base. The screw hole is a mating feature to the Optical Plate.
" inspect at 3.23 Standard Deviations
-
rework when out-of-spec
65
*
*
Screw1 +2 X Location of the Camera - representing the horizontal positions of the two
screw holes on the Camera. The screw holes are mating features to the Optical Plate.
-
inspect at 2.79 Standard Deviations
-
rework when out-of-spec
Screw1 Hole Size (C) of the Optical Plate - representing the size of screw hole on the
Optical Plate. The screw hole is a mating feature to the Camera.
-
inspect at 3.07 Standard Deviations
-
scrap when out-of-specs
The expected production cost associated with this inspection strategy, including assembly and
inspection, is calculated to be 3730 labor minutes.
In actual practice, manufacturing engineers can modify their existing production system based
on such optimization results to achieve better product outcomes. In case the proposed
strategy is not feasible, it is a good indication that there may exist some fundamental
problems in the design of the product. The development team can be alerted in that situation
and design changes can be proposed based on the highlights of the KCTool analysis.
66
-Cell Thickness
Distance
-WindowX Location
Flow Cell
Screwl +2 X Location
- Angle Tilted
3.23
SD
- Screw2 Y Location
Mounting Base
Cell Unit
Thread Tolerance
-Lens X Location
Lens
- Angle Tilted
Alignment
-----
2.79 SID
Screwi Y Location
Screw2 Y Location
Optic Unit
-Camera
Screwl Hole Size (MB)
Screw2 Hole Size (MB)
3.07
SD
-Screw2 Hole Size (C)
Optical Assembly
Optical Plate
Figure 3.13: Inspection Optimization Result
Usage Key Points
In reality, KCTool is not applied until fairly late in the development process. Presumably at the
time when the manufacturing process has been finalized and trial production testing has been
carried out. Data availability should no longer be an issue by that time.
3.3 Case Conclusion
67
Figure 3.14 serves as a summary of the four sample applications presented in this chapter. In
chapter 5 a process integration opportunity is proposed based on the sample applications
developed here. The author intends to illustrate there how these four currently independent
tools can be combined in a systematic point of view to provide support for a multi-stage
product development process.
PROJECT APPLICATION MAP
4
Inter-component prox imity
" spatial
- energy
- mating geometry
- feature definitions
- assembly constraints
- information
- material
Assembly
Designer
DSM
- suggested module
formation
- performance req's
- part catalogs
- geometry
4
Flow Model
(Matlab)
CAD Model
(Solidworks)
DOME
- feasible assembly
sequences
Cost Model
(Excel)
I
- performance req's
- KC flowdown
- process capability
- inspection and
rework costs
KCTool
- inspect I rework
strategies
- trade-off studies
- optimization
- vendor selection
Figure 3.14: Thrust 2 Application Map (figure by W. Finch)
68
CHAPTER 4: TOOL USAGE LOGS
Usage logs of the Thrust 2 tools are created to expedite the learning process of students and
researchers interested in participating in the future activities of the Product Development
Integration Laboratory. The logs contain problems encountered by the author during the
course of this research, instructions on how to get around those problems, and in general
know-hows that are helpful to new users of the tools. As mentioned in Chapter 2, this thesis
research is able to capture only the snapshots of the tools at their current stage. Please be
aware that as the tools are being modified constantly. Problems described in this chapter may
no longer exist in the new versions of the tools.
Similar to the rest of this thesis, the logs are divided into four sections corresponding to the
four Thrust 2 tools.
Section 4.1 Assembly Designer Logs
Assembly Designer System
*
The "&" Operator - Attempting to use the "&" operator when initiating Assembly Designer
at the UNIX prompt, i.e. by typing "AD
&",
will cause malfunctioning of the EDIT software
module. The program will have problem opening the EDIT windows when the operation is
triggered in such manner. To avoid problems the user is advised to always initiate the
Assembly Designer with only the "AD" command at the prompt.
Assembly Designer Operations (In the Assembly Window)
*
The "Delete" Button - The program has problem reopening a model in which elements
have been deleted in a previous session using the "Delete" button. Before this bug is
fixed, it is advised that the user should plan carefully when constructing the DFC model
and avoid deleting of any element as much as possible. Also, it is a good idea to save
multiple copies of a working model. This is to avoid having to start everything from scratch
in case the most current model cannot be retrieved.
69
*
Double Clicking - The Triggering of all operations in Assembly Designer require single
mouse clicking. When an operation is triggered by double clicks, multiple input windows
will be opened which may cause input discrepancies. To avoid problems the user is
advised to always check for the correctness of the inputs on the last open window.
"
Part Naming - Assembly Designer cannot accept part names that are longer than 8
characters. Also the names cannot contain blank spaces. The program does not have an
error checking mechanism in place; violation of this naming convention will cause
malfunctioning of the program.
*
Model Saving - Naming of the models is under the same convention as that of the parts,
i.e. names cannot be longer than 8 characters and they cannot contain blank spaces.
*
Ordering of Modules - Performing of the software modules have to be in order, i.e.
Constraint Analysis cannot be run before SPAS and DFCPR, and EDIT can only be run
last when the operation of the other three modules are completed.
Section 4.2 DOME Logs
DOME System
*
Model Initiation - When a DOME model is initiated, windows of different external programs
will pop up. It is advised that the user should wait until all the programs are done
initializing before doing anything on the screen. Changing the contents of these external
programs at this time causes DOME to lose connection with the programs. Note that this
problem is observed often with Excel.
*
Server Initiation/Re-initiation - Before starting a DOME server, it is advised that the users
should go to the Windows Task Manager to check if there are Excel programs left from
previous sessions which may still be running in the background. All the Excel programs
should be terminated before DOME is initiated/re-initiated.
*
Server Shutdown - To avoid crashing of the DOME server, it is advised that the user
should always follow the standard shutdown procedures described below:
70
1.
Terminate all active models by right clicking the models before closing the DOME
interface and the other external windows
2. Type Ctrl-Alt-Del at the DOME server window to close down. Answer "Y" for the
question "Terminate batch job?" posted by the server window
3. Go to the Windows task manager to manually terminate any Excel programs that
are running in the background after all the DOME related windows have been
closed
*
DLL Conflicts - If an "Entry Point Not Found" error message comes up when the user
attempts to open a DOME model, it is probably because there is a DLL file conflict in the
system. To solve this problem, copy the DOME specific DLL files Mfc42d.dll, Mfcd42d.dll,
Mfco42d.dll, and Msvcrtd.dll into the System32 directory under the main disk drive C:\. In
this applications it is the sharing of these DLL files between DOME and KCTool that
causes the problem. Since the two programs use different versions of these DLL files,
switching of their corresponding DLL files into the System32 directory is required in order
to run both DOME and KCTool on the same computer.
*
Remote References - Significant slow down can be experienced when a model with one
or more remote references is initiated. To speed up the initiation process, make sure that
all the associated remote servers are opened before attempting to open the local model.
Interfaces to External Programs
,Excel Plug-in - In order to attach an Excel spreadsheet to DOME, the user has to
"DOMEified" the spreadsheet by opening it on a DOME-enabled computer. He/she has to
first initialize the DOME interface toolbar by clicking "View"->"Toolbars"->"DOME Wrapper
Commands" on the main menu, then click "Create Interface" on the toolbar to save create
a file for the "DOMEified" spreadsheet. When that is done, click "Edit Interface" to add and
delete input/output assignments for variables to be displayed in DOME by simply following
the order set by the interface. Save the "DOMEified" file when the input/output assignment
is completed.
71
Once these three files are created, the user can go to the client window, add an Excel
container to the DOME model, open the container by clicking on its name, then input the
full Windows address of the "DOMEified" spreadsheet file. Note that the .xIs extension of
the file should be excluded in the address.
Excel files for the DOME sample application can be found in Appendix 1.
*
MATLAB Plug-in - In order to attach a MATLAB model to DOME, the user has to create
three files in a single directory. These files should be of type .m, .txt, and .mtxt, of which
the .txt and the .mtxt files must share the same name. The .m file should contain the
model and the calculations in MATLAB acceptable codes. The .txt file should contain the
input/output assignments of variables in the .m file in the following formats:
For real number variables
VarNAMEDOME
IN/OUT
1
VarNAMEMATLAB
R
INITvalue
Unit
MATLABFILENAME.m
In which
-
VarNAMEDOME is the variable name to be displayed in DOME
VarNAMEMATLAB is the variable name in the MATLAB model
-
R stands for real number
-
INITvalue is the initial value of the variable to be displayed in DOME
-
Unit is the unit type of the variable
-
IN/OUT denotes whether the variable is an input or an output for the MATLAB
-
model, with 1 for input and 0 for output
-
1 is a dummy variable
-
MATALBFILENAME.m is the name of the file in which the MATLAB model resides
in
For matrix variables
VarNAMEDOME
VarNAMEMATLAB
72
M
ROWsize
COLsize
1
IN/OUT
MATLABFILENAME.m
In which
"
VarNAMEDOME is the variable name to be displayed in DOME
-
VarNAMEMATLAB is the variable name in the MATLAB model
-
M stands for matrix
"
ROWsize is the number of rows in the matrix
-
COLsize is the number of columns in the matrix
-
IN/OUT denotes whether the variable is an input or an output for the MATLAB
model, with 1 for input and 0 for output
"
1 is a dummy variable
-
MATALBFILENAME.m is the name of the file in which the MATLAB model resides
in
Lastly, the .mtxt files should contain the name of the .m files to be executed in DOME.
Note that the extension .m does not need to be included.
For example, if the user would like to attach the MATLAB model testMATLAB.m to DOME
with 2 real variables and 1 matrix variable, he/she can create a testMATLAB.txt file as
follows, with the assignment for each variable on a separate line:
A
A
R
5.0
meter 1
1
testMATLAB.m
B
B
R
3.5
pascal 0
1
testMATLAB.m
C
C
M
2
2
1
testMATLAB.m
1
After that the user can create a testMATLAB.mtxt file with the single line:
testMATLAB
Notice that in this example all three files are given the same name for ease of discussion,
but in reality the .m file can have a different name than the .txt and .mtxt files. MATLAB
related files for the DOME sample application can be found in Appendix 1.
73
Once these three files are created, the user can go to the client window, add a MATLAB
container to the DOME model, open the container by clicking on its name, then input the
full Windows address of the .txt file. Note that the .txt extension of the file should be
included in the address.
*
SolidWorks Plug-in - In order to attach a SolidWorks model to DOME, the user has to
create a .txt file containing the input/output assignments of variables in the following
format:
VarTYPE
VarNAMEDOME
SolidWorksVarNAME Unit
INITvalue
SolidWorksFILENAME
IN/OUT
In which
" VarTYPE is the type of the variable in SolidWorks
" VarNAMEDOME is the variable name to be displayed in DOME
-
INITvalue is the initial value of the variable to be displayed in DOME
SolidWorksFIlLENAME is the full Windows name of the SolidWorks file in which
the variable is defined
" SolidWorksVarNAME is full name of the variable in SolidWorks. Note that
"dummy" can be used for derived variables with no full name in SolidWorks
" Unit is the unit type of the variable
- IN/OUT denotes whether the variable is an input or an output for the SolidWorks
model, with 1 for input and 0 for output
For example, if the user would like to attach the SolidWorks models testSWASSM.sidasm
and testSWPART.sldprt to DOME with 1 DIMENSION and 1 VOLUME variable, he/she
can create a testSW.txt file as follows, with the assignment for each variable on a separate
line:
DIMENSION
A
5.0
C:\dome\models\testFILES\testSWASSM.sldasm
A@Base-Extrude@PART 1.Part
3.5
VOLUME
B
dummy
cubicmeter
meter 1
C:\dome\models\testFILES\testSWPART.sIdprt
0
74
SolidWorks related .txt file for the DOME sample application can be found in Appendix 1.
Once the .txt file is created, the user can go to the client window, add a SolidWorks
container to the DOME model, open the container by clicking on its name, then input the
full Windows address of the .txt file. Note that the .txt extension of the file should be
included in the address.
DOME Operations
*
Excel Discrepancy - DOME opens up a new Excel spreadsheet every time an optimization
operation is requested. This creates a problem in a situation in which modifications of
non-search variables have been made prior to the operation (non-search variables are
parameters that are held fixed during the optimization run). The user may think that the
optimization algorithm is running with the modified values displayed on the DOME client
windows, but in fact it is the original values stored in the Excel spreadsheet that are being
used. To avoid this problem the user have to make sure that the numbers stored on the
Excel spreadsheet are those that are supposed to be used in the optimization algorithm,
and that their values do not need to be changed during the course of the DOME operation.
*
Remote References - DOME allows referencing of variables between local and remote
models. This functionality works fine when aliases of local variables are pasted onto the
remote model.
However, when aliases of remote variables are pasted onto the local
model, DOME has problem updating their values, or in order words, the linkage between
the remote variables and their aliases on the local model cannot be accomplished. There
is no known fixed to this problem as of the time of writing this publication.
*
Relation Definition - When defining relation among DOME variables using the relation
container, the statements inputted into the "Relation text" should be compatible with C
programming language. In particular, all statements should end with a semi-colon. Also,
the user have to make sure that the units of the variable match the expected outcomes of
the relation definitions, or DOME will not be able to compile the calculation results.
75
*
Optimizer Warning - When objective variable of an optimization operation is copied onto
the optimizer window, an alert window will pop up with the message: "Child not found: 1".
This alert message can be ignored by clicking the "ok" button.
Section 4.3 DSM Logs
DSM Operations
" Data Saving - When changes are made on the DSM spreadsheet, saving can only be
done when the program focus is on the "DSM" page. Attempting to save on the
"Clustering" and Clusters" page will result in runtime error and program malfunctioning
next time the spreadsheet is opened.
*
Clustering Results - The current version of the spreadsheet allows the appearance of
components in multiple modules, which can be confusing to the user. The important
points to remember are:
-
A component shared by more than two modules is considered as a system
-
element. In reality it does not belong to any particular module in the system.
In case a component is shared by two modules, the actual placement decision of
which module the component is made by the engineers based on other design
criteria not captioned in the DSM. For example, although the Peristaltic Pump is
shared by both cluster 3 and 4 in Table 3.5, the engineers may decide to place it in
cluster 4 so that the wiring between the pump and the other control and signal
processing components can be mininized.
Section 4.4 KCTooI Logs
KCTool System
*
DLL Conflicts - If the user has trouble initiating the KCTool program, it may be because
there is a DLL file conflict in the system. To solve this problem, copy the KCTool specific
DLL files Mfc42d.dll, Mfcd42d.dll, Mfco42d.dll, and Msvcrtd.dll into the System32 directory
under the main disk drive C:\. In our applications it is the sharing of these DLL files
76
between DOME and KCTool that causes the problem.
Since the two programs use
different versions of these DLL files, switching of their corresponding DLL files into the
System32 directory is required in order to run both DOME and KCTool on the same
computer.
KCTool Operations
*
Inspection Limit Optimization - KCTool delivers the result of an inspection limit
optimization to the InsLimit.txt file created in the same directory where KCTool resides. In
order to visualize the cost vs. the inspection limit curve, the user has to cut and paste the
numbers from the .txt file to an external program with graphing capability such as Excel.
"
Data Discrepancy - KCTool has occasional problems with its data storing functionality. In
particular, the author has experienced a few incidents in which the performing of an
optimization operation causes the inspection costs and limit data of some of the KCs to
reset to zero. To avoid introducing data discrepancy into the optimization, it is therefore
recommended that parameters associated with each KCs should be checked before
optimization algorithm is performed. Another way to avoid this problem is to open up a
new KCTool window every time an optimization operation is performed, so that the user
can be sure that the data used in the operation is the same as what is stored in the Access
database file.
77
Chapter 5: TOOL INTEGRATION
A framework for integration is proposed in this chapter. Tool integration based on the
framework is presented based on the context of this thesis project, and suggestions on
specific future research opportunities are discussed. It is hoped that such discussion can
unveil some insights on how Thrust 2 researchers can proceed in the efforts on developing an
end-to-end system for product development.
5.1 The Integration Framework
Presented in this section is an integration framework proposed by Thomas and Nejmeh in
their article Definitions of Tool Integration for Environments [9]. Based on an earlier work by
Anthony Wasserman [10], the framework defines integration in terms of the following four
relationships:
*
Presentation - "The goal of presentation integration is to improve the efficiency and
effectiveness of the user's interaction with the environment by reducing his/her cognitive
Well integrated tools should allow the user to apply his/her experiences and
expectations from one tool to the other. Furthermore, they should share the same
load."
"
metaphors and mental models to minimize learning and usage interference for the user.
Data - "The goal of data integration is to ensure that all information in the environment is
managed as a consistent whole, regardless of how parts of it are operated on and
transformed." Well integrated tools should be able to exchange and use each other's data
with little work required. They should minimize redundant data, and they should share the
same semantic constraints on data consistency. Finally, the tools should have a
synchronization mechanism for making sure that changes to all shared non-persistent data
made by one tools is communicated to the other.
"
Control - "The goal of control integration is to allow the flexible combination of an
environment's functions, according to project preferences and driven by the underlying
processes the environment supports." Well integrated tools should offer services other
tools in the environment require and use, and at the same time they should be able to use
the services provided by other tools appropriately.
*
Process - "The goal of process integration is to ensure that tools interact effectively in
support of a defined process." Well integrated tools should be able to achieve goals that
78
are part of a coherent decomposition of a process step in which the completion of one goal
by one tool leads to the achievement of other goals by others tools. They should also
generate and handle event notification consistently. Lastly, the tool should make similar
assumptions about the range of constraints they recognize and respect.
Figure 5.1 summarizes the four-relationship definition above by presenting in questioning form
what integration means to a single tool based on the elaborated properties of each
relationship. This diagram is taken directly from the Thomas and Nejmeh article [9].
Process Integration
Process step
How well do relevant tools combine to
support the performance of a process step?
Event
How well do relevant tools agree on the
events required to support a process?
Constraint
How well do relevant tools cooperate to
Presentation Integration
Appearance and behavior
To what extent do two tools use similar
screen appearance and interaction
behavior?
enforce a constraint?
Data Integration
Interoperability
How much work must be done for a tool to
manipulate data produced by another?
Nonredundancy
How much data managed by a tool is
duplicated in or can be derived from the
data managed by the other?
I4
TOOL
Interaction paradigm
To what extent do two tools use similar
metaphors and mental models?
Provision
To what extent are a tool's services used
by other tools in the environment?
Use
To what extent does a tool use the services
provided by the other tools in the
environment?
Data consistency
How well do two tools cooperate to
maintain the semantic constraints on the
data they manipulate?
Data exchange
How much work must be done to make the
nonpersistent data generated by one tool
usable by the other?
Synchronization
How well does a tool communicate
changes it makes to the values of
nonpersistent, common data?
Control Integration
Figure 5.1: Integration Definition by Thomas and Nejmeh
79
5.2 Implication on Thrust 2 Tool Integration
Thomas and Nejmeh suggested that integration should be defined independently of the
mechanisms and approaches used to support the process. Following their idea, the author
applies the integration framework to the context of the thesis project. Implications are then
presented on how such framework can assist the CIPD, in particular, the Thrust 2
researchers, in laying out an end-to-end system of product development. Limited by the
scope of this research project, the discussion is only involved with the four Thrust 2 tools.
Please note that it is not the intention of the center to exclude other tools and methodologies
from participating in the product development system. In fact, the center realizes that its
success relies on the its ability to reach out and get outside resources to contribute to system,
as it understands that it does not have the all the resources required in tackling all the existing
problems.
5.2.1 Presentation Integration
The goal of presentation integration is to reduce the user's cognitive load on interacting with
the individual tools, the tool sets, and the environment as a whole. Based on this definition,
the author has identified among the Thrust 2 tools the following opportunities for presentation
integration:
IImplementation of a Standard Graphic User Interface - One possible solution for giving
the Thrust 2 system a consistent "look and feel" is to implement a standard user interface
across the four tools. A familiar example of this kind of presentation integration can be
observed in the Microsoft Office Suite. Although the Office components all have different
functionality, they are designed under a similar layout of tool bars and wizard windows.
This gives the users a rough sense of where the commands are and what they do, such
that once a user knows how to format a document in Word, it is not difficult for him/her to
figure out how to make a nice looking spreadsheet in Excel.
This integration solution is appropriate if the proposed Thrust 2 system is targeted for
small, non-distributed development teams. It is typical for these teams to have developers
in charge of multiple tools, in which case having a standard user interface can reduce the
cognitive loads required for the developers to learn and interact with the different tools.
80
The author would like to point out however that this solution requires a significant amount
of effort first in creating and maintaining an interface standard, then in rewriting the
existing codes to accommodate the standard. In a research entity like the CIPD where
tool development projects are predominantly independent in nature, such kind of
integration may not be easily achievable.
*
Employment of a Common Wrapping Interface - An alternative solution to the standard
interface is a wrapping interface system.
A wrapping interface works on top of the
different Thrust 2 interfaces. It acts as a middle person between the users and the tools,
providing the users with a common "look and feel" while letting the tools to operate with
their existing interfaces underneath.
This integration solution is good for a Thrust 2 system that is targeted for large, distributed
development teams. These teams usually have one or more developers in charge of each
tool, i.e. one system engineer is maintaining a DSM model by himself, while a few
manufacturing engineers are responsible only for the Assembly designer model. In such
setting, there is no need for the system engineer nor the manufacturing engineer group to
learn about each others' tool interface, as long as they can get access to the services and
obtain the desirable results.
The author feels that this kind of integration solution can be achievable through the DOME
environment. In particular, DOME containers and interface windows should be created for
Assembly Designer, DSM, and KCTool. Instead of creating plain input/output interface like
that of Excel, the author recommends the employment of more customized interface
windows like that of the genetic algorithm optimizer.
Listed below are suggestions of
possible tool interfaces:
-
The Assembly Designer interface may have an embedded EDIT module for
-
assembly sequence editing.
The DSM interface may have a page for changing the weighting factors among the
four dependencies, and a page for triggering the clustering algorithm and obtaining
the result.
81
-
The KCTool interface may have a page for assigning of corrective actions to KCs,
and a page for performing the inspection simulation and obtaining the expected
production results.
5.2.2 Data Integration
The goal of data integration is to maintain data consistency among tools in the environment.
Based on this definition, the author has identified the following opportunities for data
integration:
Assembly Designer and KCTool - KCTool can be modified to offer an alternative data
For example, the KC
representation format using the Datum Flow Chain (DFC).
Flowdown data in Figure 3.11 can be represented as shown in Figure 5.2, in which the
arrows trees depict the DFC model, and the dotted trees represent the KC Flowdown
Structure. Note that there are three levels of KCs illustrated in this representation:
" Part KCs are listed within the boxes associated with the parts
-
Subassembly KCs are listed between the dots associated with the parts
System KC are listed between the boxes associated with the subsystems
82
Subsystem Cell Unit
Subsyst em Optic Unit
Part Flo w Cell:
KC Cell TI k.
Part Mounting
Base:
KC S12 X Loc
KC S1 YLoc
KC S2 Y Loc
sI
KC
Distance
I
Part L ens:
lKC
hread Tolerance
KC
Alignment
Part Camera:
KC S12 XLoc
KC S1 YLoc
KC S2 YLoc
g..... ............
-
KC
Kd
Lens X
Lopatio
Window X
KC Angle
Tilted ..
Location
Q.
K
ngle
ilted
Part Optical Plate:
KC S1 Hole Size (MB)
KC S2 Hole Size (MB)
KC S1 Hole Size (C)
KC S2 Hole Size (C)
-*
mates
............. KC linkage
Figure 5.2 DFC-based Data Representation for KCTool
By adding such DFC-based data representation to KCTool, data integration between
Assembly Designer and KCTool can be promoted through either the employment of a
common data source, or the implementation of an automatic functionality in KCTool for
deriving KC Flowdown directly from Assembly Designer outputs.
The proposed DFC-based representation also unveil interesting system information not
currently offered by either of the tools. Namely, the DFC-KC combined model is able to
provide a visual clue on why the LaserNet Fines system is having problem delivery the
distance and alignment KCs between the Cell Unit and the Optic Unit subsystems. It can
be observed in Figure 5.2 that the distance and alignment KCs are the only KCs in the
83
.
system that are not defined directly by a mate. Instead, they rely on two tree structures of
mates for their KC delivery, one for the Cell Unit, and the other for the Optic Unit. As
production variations build up at those mates, the failure rate at the two KCs also
increases. The proposed DFC-KC model can therefore help engineers visualize the
problems in the system that are otherwise hidden, which can be extremely useful in an
iterative designing process.
DSM and Assembly Designer - New version of the DSM spreadsheet can be designed to
output the module formation in an Assembly Designer acceptable format, so that the
connectivity requirements embedded in the clustering result can be utilized during the
sequence editing process of Assembly Designer. For example, suppose that the
engineers are interested in exploring the manufacturing feasibility of having an optical
subassembly. Also suppose that the DSM clustering algorithm suggests a module
formation composing of the Camera, the Focus Optics, and the Laser & Optics. Since
components in a subassembly are typically assembled in order, the engineers can choose
to eliminate all sequences with the components being assembled at different times by
applying the DSM output in Assembly Designer. This increases the efficiency of the
assembly designing process by reducing the size of the design space to be explored.
*
DOME and KCTool - Product data obtained from suppliers through the DOME remote
service connections can be made compatible with the input format of KCTool, so that
information such as manufacturing process capabilities and cost can be loaded
automatically onto the KC Flowdown models without human intervention.
5.2.3 Control Integration
The goal of control integration is to ensure that tools are able to provide and accept services
as part of a whole system. Based on this definition, the author has identified the following
opportunity for control integration:
*
A Service Exchange System - Since human intervention is required in many of the tools,
the creation of an entirely automatic process using the four Thrust 2 tools is not feasible.
Therefore, the author proposes instead the implementation of a service exchange system,
one that can accommodate both human interactions and automatic triggering among tools.
84
In particular, the author recommends utilizing the DOME program linkage capability by
coupling control integration with the wrapping interface presentation integration method
mentioned earlier in this section. Once the customized interfaces for the Thrust 2 tools are
created, the proposed service exchange system can conveniently be built in the DOME
environment.
5.2.4 Process Integration
The goal of process integration is to make sure that tools interact well to support a defined
process. Based on this definition, we have identified the following opportunity for process
integration:
0
System designing process - A 4-stage scenario is presented illustrating one way of
combining the Thrust 2 tools to support an integrated development process.
Refer to
Appendix 2 for a demo script of this proposed process.
Stage 1: DSM is used to determine module configuration based on a specific system
architecture and the associated connectivity criteria.
Input(s)
-
System architecture/breakdown in DSM format
-
Component dependency definition in spreadsheet matrix format
Quantified module formation criteria, i.e. evaluation scores assigned to different
-
system dependencies
Output(s)
- Module formations based on specified criteria
Stage 2: DOME is applied to select and optimize supplier components based on the
modularized system architecture proposed by the DSM.
Input(s)
- Supplier database maintained by the purchasing department
-
CAD models of system components, maintained by the engineering department
85
-
Product cost models in spreadsheet format, maintained by the manufacturing
department
-
Performance simulation model maintained by system specialist
Evaluation criteria in DOME format, defined by the engineering department
" Other related product data in spreadsheet format, maintained by the engineering
-
department
-
Product specifications including CAD models and cost models, provided by the
suppliers
Output(s)
-
Supplier selection and component optimization based on specified design and
performance criteria
Stage 3: Assembly Designer is utilized to determine an appropriate assembly process based
on the product system defined by DSM and DOME.
Input(s)
Part list with detailed product data obtained from DOME
" Assembly constraint information obtained based on CAD models, i.e. exit
directions for disassembly and degree-of-freedom constraint for each component
-
-
Sequence evaluation criteria defined by manufacturing engineers
Output(s)
-
Set of feasible assembly sequences complying with specified manufacturing
criteria
Stage 4: Once the assembly sequence has been finalized and production testing has been
performed, KCTool is employed to configure a risk management strategy that warrants
optimal production output.
Input(s)
-
Key characteristic definitions, defined based on CAD models and assembly
-
sequence from Assembly Designer
Flowdown hierarchy, defined based on CAD models and assembly sequence
86
-
Cost of production, maintained by the manufacturing department
Cost of quality control, maintained by the manufacturing department
"
Manufacturing process capabilities, obtained both from the manufacturing
-
department and the suppliers
Output(s)
- Risk management strategy for the assembly system
Shown in figure 5.3 is a schematic of the proposed integrated development process.
87
Tool Outputs
Tool Inputs
"
"
System architecture
Connectivity criteria
DSM
-
Module formation
"
-
Vendor selection
Component optimization
Assembly
Designer
-
Assembly sequence
KCTool
-
Production variation
management strategy
--U
-
Product models
Supplier information
Design evaluation criteria
DOME
"
Geometric constraint
information
Sequence evaluation criteria
Key Characteristic
Flowdown definition
Cost of production and
quality control
" Manufacturing capabilities
Figure 5.3 One Possible Integrated Development Process
Different combinations of the tools are possible, the important point is that the tool applications
have to follow the chronological order due to data availability issues. The following are two
variations of the proposed integrated development process:
Variation 1 - Designing of a component to be manufactured in-house
This scenario starts with the definition of the component design based on cost,
performance, and compatibility with the rest of the system.
Stage 1:
DOME is used to optimize the component dimensions against simulated
operation conditions. Sets of dimension which guarantee the satisfaction of
88
certain performance specifications can therefore be determined and be used in
later analysis.
Stage 2:
Assembly Designer is used to further eliminate inappropriate dimensions by
locating geometric incompatibility with the already defined system components.
Stage 3:
KCTool is used to investigate the effects each dimensions would have on risk
management, and thereby select those that promise higher output quality and
lower assembly cost.
Stage 4:
By this stage most of the inappropriate dimensions would have been
eliminated. The remaining candidates are to be evaluated further and among
which an optimal dimension is to be determined
Variation 2 - Evaluating DFA/DFM driven design change
This scenario starts with a working design of a system and the associated
assembly process.
Stage 1:
Assembly Designer is used to determine alternative assembly sequences.
Stage 2:
DSM is used to assess module changes driven by the proposed assembly
sequence modification. For example, suppose Assembly Designer suggests
that the mating of one component is to be completed concurrently with the
mating of another component.
Using DSM, engineers can investigate how
much system dependencies can be eliminated by combining the two
components into a module.
Stage 3:
D.O.M.E. is used to investigate ways to accommodate the module changes
while satisfying all design criteria, i.e. by changing the specifications of some of
the in-house components, or by the using alternative supplier components
89
5.3 Chapter Summary
The author proposed in this chapter suggestions on how the Thrust 2 tools can be integrated
based on Thomas and Nejmeh's four-relationship integration framework. The integrated
Thrust 2 system can be envisioned as follows:
*
It supports a system-wise "look and feel" for the users and thereby reduces the cognitive
load associated with tool learning and usage.
"
It maintains data consistency and interoperability within the system.
*
It facilitates the service exchange among the tools.
*
It supports a multi-stage development process.
90
Chapter 6: CONCLUSION
This chapter summarizes the conclusions obtained from this research. In addition, possible
areas of future research in Thrust 2 tool integration are presented.
6.1 Conclusions
The author approached the thesis project by first constructing four sample tools applications
based on a product development case provided by jointly the Naval Research Laboratory and
the Lockheed Martin Tactical Defense Systems.
These applications are designed to
demonstrate the abilities of the tools to solve challenges appearing in different stages of the
product development process. Although not actually integrated, the applications provide a
common ground on which input and outputs of the tools can be studied, and potential
interactions among the tools can thereby be inferred. Details of the sample tool applications
are described in Chapter 3.
The author went on to present in Chapter 5 Thomas and Nejmeh's framework for investigating
integration opportunities of the Thrust 2 tools. Based on such framework, the author proposed
suggestions on how the Thrust 2 tools can be integrated to construct a system which gives the
users a consistent "look and feel", one that allows the tools to share data and services, and is
capable of supporting a multi-stage development process.
This thesis contributes to the CIPD research efforts by being the first to explore the integration
of the Thrust 2 tools. The problems and opportunities highlighted in this project can guide the
researchers in the development of an end-to-end product development process envisioned by
the center. The application experiences obtained in this research can also be shared by
students and researchers who are interested in getting involved in the Thrust 2 integration
effort in the future.
6.2 Future Research
Due to the limitation of data availability, only selected functionality of each Thrust 2 tools can
be explored in this research. With additional data from the industrial partners, future research
can be conducted on the tool capabilities that have been left out of this research, i.e. the other
91
three forms of DSM, the tolerance analysis module of Assembly Designer, and other plug-in
programs of DOME, etc. More interesting interactions of the tools can hopefully be
discovered, and as a result more integration opportunities can be unveiled.
Another possibility is to introduce non-Thrust 2 tools into the research. For example, a tool
named Virtual Customer has been developed by the Product Portfolio Definition group, Thrust
1, which allows developers to efficiently gather product requirements and other useful
information from the customers. The addition of this tool, along with other commercial and
academic tools, enables the development of a more complete end-to-end system that will
eventually become part of the product development service marketplace envisioned by the
CIPD.
6.3 Final Comments
The main difficulty of this research project came from the uncertainties associated with the
applications of the four independent product development tools. As these tools had never
been used concurrently before, very little was known on how the tools would behave when
installed onto a single computer, not to mention their actual interactions with each other.
Throughout the two-year period of the project, the author had run into plenty of hidden
obstacles when trying to apply the tools in a concurrent manner. For example, there was
once an unidentified problem that caused the KCTool to stop running suddenly. Despite the
author's efforts in working closely with the KCTool programmer, the source of the problem did
not become apparent until weeks after the breakdown.
More ironically, the discovery
happened during the time when the author and his DOME contact researcher were trying to
tackle a seemingly unrelated problem. It turned out that the problem was caused by the
sharing of a same set of DLL files between DOME and KCTool. When the author installed
DOME onto his computer, the DOME installation wizard automatically modified the DLL files
and made them unusable by the KCTool. As illustrated in this example, pinpointing of these
hidden obstacles can be a time-consuming process, since the relationship between a problem
and its source may not be as obvious as one would hope.
The time constraint is another major challenge of this project. The author felt that learning the
four tools and developing four tool applications in four semesters was a bit too tight, especially
since the author had to coordinate among the schedules of four different contact researchers.
92
Given that a full-scale application for DOME alone usually takes a whole team of graduate
students to develop, the author recommends that future students should each take on at most
two tools. With this thesis serving as a means for expediting the learning process, it is likely
that such proposed arrangement would warrants the development of more detailed and more
meaningful models than what could be achieved in this research project.
93
Bibliography
Year Annual
[1]
Maurice Holmes, "The Center for Innovation in Product Development
Report", MIT, Cambridge, MA, March 2000
[2]
Stephen Rhee, "Computational Tools for Assembly Oriented Design", M.S.Thesis,
MIT, Cambridge, MA, September 1999
[3]
Naba Barkakati, "Red Hat LINUX Secrets,
[4]
Nicholas Borland, David Wallace, and Heiner P. Kaufmann, "Integrating Environmental
Impact Assessment Into Product Design", 1998 ASME Design Engineering Technical
Conferences, September 1998
[5]
David R. Wallace, Shaun Abrahamson, Nicola Senin, Peter Sferro, "Integrated Design
in a Service Marketplace", Computer-aided Design, volume 32, no 2, pp. 97-107,2000
[6]
Thomas U. Pimmler and Steven D. Eppinger, "Integration Analysis of Product
Decompositions", working paper WP#3690-94-MS, Alfred P. Sloan School of
Management, MIT, Cambridge, MA, May 1994
[7]
Tony J. Chen and Anna C. Thornton, "Quantitative Selection of Inspection Plans",
1999 ASME Design Engineering Technical Conferences, September 1999
[8]
T.J. Sebok, C.J. Holloway, J. Reintjes, J.E. Tucker, "Optical Oil Debris Monitor as a
Diagnostic Tool for Condition-based Maintenance", ASNE Condition-Based
Maintenance Symposium, June 1998
[9]
Ian Thomas and Brian A. Nejmeh, "Definitions of Tool Integration for Environments",
IEEE Software, March 1992
[10]
A.I. Wasserman, "Tool Integration in Software Engineering Environments", Software
Engineering Environments: Proc. Int'l Workshop on Environment, F. Long, ed.,
Springer-Verlag, Berlin, pp 137-149, 1990
94
2 nd
3rd
Edition", IDG Books Worldwide, 1998
Appendix 1: Modeling Data for the Thrust 2 Tool Applications
Part #1:
OQplt
Transform:
Part #3: CA_plt
Part #2: M-adjstr
Transform:
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: 0.000000
TY: 0.000000
X: 5.413000
Y: 2.500000
Z: 3.375000
TX: 0.000000
TY: 0.000000
X: 5.413000
Y: 2.500000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
Part #4: camera
TZ: 0.000000
Part #5: Mlens
TZ: 0.000000
Part #6: CS blk
Transform:
Transform:
Transform:
X: 3.280000
Y: 2.250000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
Part #7: Fcell
Transform:
X: 12.563000
Y: 2.500000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
X: 5.060000
Y: 1.384000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
Part #9: L-sprt
Part #8: CM_blks
Transform:
Transform:
X: 12.513000
X: 12.083000
X: 7.413000
Y: 1.134000
Y: 1.134000
Y: 2.250000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
Z: 3.375000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
A1.1: Part Definitions for Assembly Designer Application
95
Liaison #1:
Type: mate (6 dof)
Partl: OQplt
Part2: M adjstr
Number of Features: 1
Feature #1:
Type: Prismatic Peg /
Prismatic Hole (6 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: 90.000000
TY: 0.000000
TZ: 0.000000
Attributes: none
Liaison #4:
Type: mate (6 dot)
Partl: CA-plt
Part2: camera
Number of Features: 1
Feature #1:
Type: Prismatic Peg /
Prismatic Hole (6 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: -90.000000
TY: 0.000000
TZ: -90.000000
Attributes: none
Liaison #3:
Liaison #2:
Type: mate (1 dot)
Partl: M_adjstr
Part2: CAplt
Number of Features: 1
Feature #1:
Type: Spheroid on Plane
Surface (1 dot)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: 0.000000
TY: -90.000000
TZ: 0.000000
Attributes: 0.00000,
0.00000, 0.25000, 0.00000,
0.00000, -0.25000, 180.00000,
180.00000, 180.00000, 180.00000, -180.00000, 180.00000
Liaison #5:
Type: mate (6 dof)
Partl: camera
Part2: Mlens
Number of Features: 1
Feature #1:
Type: Prismatic Peg /
Prismatic Hole (6 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: 0.000000
TY: -90.000000
TZ: 0.000000
Attributes: none
Type: mate (5 dof)
Partl: Oplt
Part2: CAplt
Number of Features: 1
Feature #1:
Type: Prismatic Peg
/Prismatic Slot (5 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: -90.000000
TY: 0.000000
TZ: -90.000000
Attributes: 0.50000, 0.50000
Liaison #6:
Type: contact
Parti: L-sprt
Part2: Mlens
Number of Features: 1
Feature #1:
Type: Plate Pin in Through
Hole (5 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: 0.000000
TY: -90.000000
TZ: 0.000000
Attributes: 180.00000, 180.00000
A1.2: Liaison Definitions for Assembly Designer Application (continue to next page)
96
L Liaison #8:
Liaison #7:
Type: mate (6 dof)
Partl: O_plt
Part2: CS blk
Number of Features: 1
Feature #1:
Type: Prismatic Peg /
Prismatic Hole (6 dof)
Transform:
Type: mate (5 dof)
Partl: CSblk
Part2: Fcell
Number of Features: 1
Feature #1:
Type: Prismatic Peg
/Prismatic Slot (5 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: -90.000000
TY: 0.000000
TZ: -90.000000
Attributes: none
Liaison #9:
Type: mate (6 dof)
Partl: CS_blk
Part2: CM_blks
Number of Features: 1
Feature #1:
Type: Prismatic Peg /
Prismatic Hole (6 dof)
Transform:
X: 0.000000
X: 0.000000
Y: 0.000000
Y: 0.000000
Z: 0.000000
TX: 0.000000
TY: 90.000000
TZ: -90.000000
Z: 0.000000
TX: 0.000000
TY: 90.000000
TZ: 0.000000
Attributes: 5.00000, -
Attributes: none
5.00000
Liaison #10:
Liaison #11:
Type: mate (1 dof)
Partl: CMblks
Part2: Fcell
Number of Features: 1
Feature #1:
Type: Spheroid on Plane
Surface (1 dof)
Transform:
Type: mate (6 dof)
Partl: CAplt
Part2: L sprt
Number of Features: 1
Feature #1:
Type: Prismatic Peg /
Prismatic Hole (6 dof)
Transform:
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: 0.000000
TY: 0.000000
TZ: 0.000000
Attributes: 0.00000,
0.00000,
0.00000,
0.00000,
0.00000,
X: 0.000000
Y: 0.000000
Z: 0.000000
TX: -90.000000
TY: 0.000000
TZ: -90.000000
Attributes: none
0.00000, 0.00000,
2.50000, 0.00000,
0.00000, 0.00000,
0.00000
A1.2: Liaison Definitions for Assembly Designer Application
97
8&10 >=9;
1 & 3 >= 2 ;
11 >=3&7&8;
11 >=3&4&7;
7 >=3&4&11 ;
11 >= 1 &2 & 3 & 7;
7 >= 1 &2 & 3 & 11;
4&5 >=6&11 ;
6&11 >=4&5;
A1.3: SPAS Precedence Relationship for Assembly Designer Application
(Note: the ">=" sign is interpreted as "should be completed before or at the same time as")
98
Total
Variables->
Variable
18
Full Name
Initial Value
Dcell
FlidCes
0.0001
meter
Input
Wcell
Fluid Cell
Width
0.00476
meter
Input
Lcell
Fluid Cell
0.01016
meter
Input
Vmin
Linear Min.
Name
Flow Rate
0.036
Unit
Input/
eroutput
meters per second Output = Vpix
meters per second Output = ( PixSmear * Vpix ) I PWlaser
Linear Max.
0.04995
Vpix
Ce Hei ht
0.000003
meter
Input
Number of
Vertical
Pixels
480
unitless
Input
Frame
25
hertz
Input
meterA3 per
second
meterA3 per
second
PixV
FrameRate
ate
Output = Dcell * Wcell * Vpix * PixV *
FrameRate
Output = ( Dcell * Wcell * PixSmear *
FlowRateMin
Min. Flow
Rate
1.7136E-08
FlowRateMax
Max. Flow
Rate
2.37762E-08
PWlaser
Laser Pulse
0.00002
second
Input
PixSmear
Allowable
Pixel Image
Movement
0.333
unitless
Input
Fluid Density
887.42
Kilogram per
Input
CellHydDia
0.000195885
meter
Output
Rnum
0.702599619
unitless
Width
Dens
Viscosity
___________
FlowVelocity
rop
Kinematic
PresureNewon
Flow Rate
13.94
centistoke
_
Dens
er-
Newto per
0.05
Mde (
meters per second
_nLoca
(2 * Dcell * Wcell )l( Dcell +
Wcell )
Output =FlowVeolcity * CellHydDia I (
Viscosity 0.000001 )
5240.881238
Viscosity_______________
Linear Fluid
Vpix ) I PWlaser
A3
___________________meter
DeP
PixV * FrameRate
*
_____
Vmax
Flow Rate
Equation
__LMTDS
*
64
*
Lcell
*(
Output FlowVelocity A 2) (2
CellHydDia * Rnum)
Input
r
Input
)r
Ep
a
Al1.4: Excel Model (on Local LMTDS Server) for DOME Application
99
Total
Variables->
Variable
2
Full Name
Initial Value
Unit
FCVolume
Fluid Cell
3.OOE-04
cubic meter
Input
UnitCost
Unit Cost of
Component
5.04E+06
dollar
Output
Volume
uput
Equation
(( ( FCVolume * 400000 )A3)
350 * HourlyLaborCost / 3600)
+ OtherComponentCost
=
*
A1.5 Excel Model (on Remote Vendor Server) for DOME Application
(Note: assume HourlyLaborCost = $30 and Other ComponentCost = $3000)
100
DIMENSION
DIMENSION
VOLUME
HousingHeightO.013 C:\dome\models\LMDemoFiles\Asseml.sidasm
meter 1
HHousing@Base-Extrude@Flowcell. Part
HousingLength
0.063 C:\dome\models\LMDemoFiles\Asseml.sldasm
meter 1
LHousing@Sketch3Flowcell.Part
1.784E-5
C:\dome\models\LMDemoFiles\Flowcell.sldprt dummy
CeIlVolume
cubicmeter
0
A1.6: LMSolidWorks.txt File (on Remote Vendor Server) for DOME Application
101
%% flow velocity simulation with viscosity range from 50cSt to 500cSt
%% note: (20 cSt, 500 cSt) = (.00002 mA2/s, .0005 mA2/s)
V = Vmin;
i = 1;
vis = (0.00002:0.00002:0.0005);
[m,n] = size(vis);
V_interval = (Vmax - Vmin)/10;
Pressuremax = -inf;
Pressure_min = inf;
while V < Vmax
Reynolds_number = V * Cellhyddia*ones(1,n)./vis;
Pressure (i,:) = Density*((64*L cell*VA2)/(Cell _hyddia*2))*(ones(1,n)./Reynolds_number);
if max(Pressure(i,:)) > Pressuremax
Pressuremax = max(Pressure(i,:));
end
if min(Pressure(i,:)) < Pressure_min
Pressure_min = min(Pressure(i,:));
end
V=V+Vinterval;
i = i + 1;
end
P = Pressure_min;
j = 1;
P-interval = (Pressuremax - Pressure_min)/15;
while P < Pressuremax
V_range
= 1/8 *
P * (((Dcell * W cell)A2)/(Density*Lcell*(D cellA2+2*D cell*Wcell+W cellA2)))*(ones(1,n)./vis);
P = P + Pinterval;
j
=
+ 1;
plot(vis, V range);
axis([O 5E-4 0 1]);
hold on;
end
hold off;
xlabel('Viscosity (mA2/s)');
ylabel(Flow Velocity (m/s)');
title('Flow Velocity Simulation with Viscosity and Pressure Drop as independent variables');
A1.7: LMMatlab.m File (on Remote Fluid Server) for DOME Application
102
L_cell
D_cell
W_cell
Cellhyddia
Density
V_min
V_max
Lcell
Dcell
Wcell
Cellhyddia
Density
V_min
Vmax
R
R
R
R
R
R
R
0.01016
0.00011
0.00476
0.00020547
887.42
0.03
0.41625
meter
1
1
meter
1
1
1
meter
1
meter
1
1
kilogramper cubicmeter
metersper second
metersper second
LMMatlab.m
LMMatlab.m
LMMatlab.m
LMMatlab.m
1
1
1
1
1
1
LMMatlab.m
LMMatlab.m
LMMatlab.m
A1.8: LMMatlab.txt File (on Remote Fluid Server) for DOME Application
103
LMMatlab
A1.9: LMMatlab.mtxt File (on Remote Fluid Server) for DOME Application
104
Name
213
1
5
4
6
7
8
9
10 11
12 13141516 17{18 19
SBC, LCD, Touch 1
Frame Grabber 2
4
Pump, Peristaltic 3
1
1
Camera 4
1
2
1
Focus Optics 5
0
1
0
3
Laser & Optics 6
0
1
0
3
2
Laser Power Supply 7
1
1
1
1
1
Interface Board[ 8 1_4 _2__21
2
1
4f
2
Flow Cell 9
0
1 2
2
3
3
1
Ultrasonic Cleaner 10
12
1
1
1
1
1
2
1
1
1
1
1
1
1E1
1
1
1
2
0
0
LS-120 Floppy 11
150W Power Supply 12
12
21_12
1
1U
Power Switch 13
0
0
0
0
0
0
0
Power Connector 14
0
0
0
0 06 0
0
0 0 0 1
2
Power Line Filter 15
0
0
0
0
0
0
0
0
2
2
2
1
2
1
1
1
1
2
0
0
0
0
0
Power Relay 16
1
U
1
AC Fan 17
3
3
1
1
0
0
0
2
0
1
2
2
1
1
2
1
Input Sample Bottle 18
0
0
0
0
0
0
0
0
1
3
0
0
0
0
0
0
1
1
0
0
010 0
Discharge Bottle 19
f
0 01
0 0
0
0
0
A1.10: Combined Dependency Matrix for DSM Application
105
0
1
1
1
Name
Rework
to
Nominal
Distance
Alignment
Window X Location
Lens X Location
Thread Tolerance
Screw1 +2 X Location
Screw1 Y Location
Screw2 Y Location
Screwi +2 X Location
Screw1 Y Location
Screw2 Y Location
Angle Tilted
Angle Tilted
Screw1 Hole Size (MB)
Screw2 Hole Size (MB)
Screw1 Hole Size (C)
Screw2 Hole Size (C)
Cell Thickness
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Yes
No
No
No
No
Yes
2.95
0
2.95
0
0.1
0.492
0.492
0.492
0.5
1.5
1.5
0
0
0.203
0.203
0.25
0.25
0.5
Inspection
Variable
Cost
2
Distance
2
Alignment
1
Window X Location
1
Lens X Location
0
Thread Tolerance
0
Screw1 +2 X Location
0
Screw1 Y Location
0
Screw2 Y Location
0
Screw1 +2 X Location
0
Screw1 Y Location
0
Screw2 Y Location
1
Tilted
Angle
1
Angle Tilted
0
Screw1 Hole Size (MB)
0
Screw2 Hole Size (MB)
0
Screw1 Hole Size (C)
0
(C)
Size
Screw2 Hole
0
Cell Thickness
Name
to
Cost of
Sigma
Mean
Scrap
Inspection
Fixed
0.003
0.02
0.01
0.01
0.0002
0.001
0.001
0.001
0.001
0.001
0.001
0.02
0.02
0.001
0.001
0.001
0.001
0.002
2.945
-0.005
2.95
0
0.1
0.492
0.492
0.492
0.5
1.5
1.5
0
0
0.203
0.203
0.25
0.25
0.5
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
0
2
0
0
0
0
0
0
0
0
0
1
1
0
0
0
0
0
Man
RworkCost
35
50
10
10
10
5
5
5
5
5
5
15
15
3
3
3
3
10
Rework
Part
Rework
Percent
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
15
20
20
10
20
20
20
20
20
10
10
5
5
10
10
10
10
20
Lower
Inspection
Limit
2.94
-0.05
2.93
-0.02
0.0995
0.487
0.487
0.487
0.495
1.495
1.495
-0.05
-0.05
0.2
0.2
0.245
0.245
0.495
Fixed
Upper
Inspection Corrective
Action
Limit
No
2.96
No
0.05
No
2.97
No
0.02
No
0.1005
No
0.497
No
0.497
No
0.497
No
0.505
No
1.505
No
1.505
No
0.05
No
0.05
No
0.205
No
0.205
No
0.252
No
0.252
Yes
0.505
A1.11: Key Characteristic Definitions for KCTool Application
(Note: costs are expressed in labor minutes. assume 60 minutes = $100)
106
System/Subsystem/Part
Name
Purchasing Cost
Assembly Cost
Optical Assembly
Cell Unit
Optic Unit
Flow Cell
Mounting Base
Lens
Camera
Optical Plate
3730
730
2020
400
300
1000
1000
800
180
30
20
0
0
0
0
0
A1.12: System/Subsystem/Part Definitions for KCTool Application
(Note: costs are expressed in labor minutes. assume 60 minutes = $100)
107
System/Subsystem/Part
KC
Assembly
Distance
10
Cost
+5.0 * Angle Tilted of Optic Unit
+0.5* Screw2 Hole Size (MB) of Optical Plate
10
+0.5 * Screw1 Hole Size (C) of Optical Plate
-0.5 *Screw2 Hole Size (C) of Optical Plate
+1.0 * Screw1 +2 X Location of Mounting Base
-1.0 * Cell Thickness of Flow Cell
+1.0 *Screw1 Y Location of Mounting Base
-1.0 * Screw2 Y Location of Mounting Base
+1.0 * Thread Tolerance of Lens
+1.0 * Screwl +2 X Location of Camera
+1.0* Screw1 Y Location of Camera
-1.0 * Screw2 Y Location of Camera
Window X
Cell Unit
ClUntAngle
Location
10
Tilted
Lens X
Optic Unit
Optical Plate
Flow Cell
Mounting Base
Lens
Camera
Location
Angle
Tilted
Screw1
Hole Size
(MB)
Screw2
Hole Size
10
NONE
NONE
NONE
NONE
NONE
NONE
NONE
NONE
Cell
NONE
NONE
Screw1 +2
X Location
NONE
NONE
Screwi Y
Location
NONE
NONE
Screw2 Y
Location
NONE
NONE
Thread
Tolerance
NONE
NONE
Screw1 +2
X Location
NONE
NONE
Screwi Y
NONE
NONE
Screw2 Y
Location
NONE
NONE
-(MB)
Screw1
Hole Size
(C)
Screw2
Hole Size
(C)
Thickness
Location
_Un
Unit
-1.0 * Window X Location of CellUnit
+1.0 * Lens X Location of Optic
+5.0 * Angle Tilted of Cell Unit
Optical Assembly
Alignment
Error Stack Up
__fCe
-1.__*_WindowXLcation
A1.13: Error Propagation Definitions for KCTool Application
(Note: costs are expressed in labor minutes. assume 60 minutes = $100)
108
Appendix 2: Thrust 2 Application Demo Scripts
Stage 1 (DSM APPLICATION):
Starting point:
*
*
USE COMPUTER ON THE RIGHT
Open window explorer in directory C:\Thrust2DEMO\DSM
DSM clustering operation:
*
*
*
Open DSM-Program.xls
Click "Enable Macros" in the Excel pop-up window
Click "Cluster DSM" button on the left tool bar (third icon with 2 gray squares on the side
and 1 yellow one in the middle). Screen will be directed automatically to the "Clustering"
page
* On the "Clustering" page, click the "Recalculate Clusters" button (pink button on the top of
the page) and take note of the Coordination Cost
* Repeat the process until a desirable cluster formation is obtained
* Click "Show Clusters" button (pink button on next to the "Recalculate Clusters" button)
" Look at the suggested clustering configuration on the Clusters page and pick out possible
ones for further evaluation
* Close all windows without saving any changes
Stage 2 (DOME APPLICATION):
Starting point:
*
*
*
*
*
*
*
*
USE COMPUTER IN THE MIDDLE AND ON THE RIGHT, AS WELL AS THE LEFT
COMPUTER BEHIND THE DIVIDER
On bubbe (local server), click "DOME Server Manager" icon on desktop to initiate DOME
server. Wait until the "User Manager" window come out
Repeat the process on farfalen and tanta (remote servers)
Go back to bubbe, click "DOME Client" icon to bring up a web browser with the DOME
interface
Click "OK" on the "Copyright Notice" window
Enter name as "thrust2" and password as "mitcipd", leave server as "localhost", then hit
Enter
Enter leave name and password as they are ("thrust2" and mitcipd" respectively), change
server to "18.38.1.137" , then hit Enter to login remotely to farfalen
Repeat the process for tanta, enter server as "18.38.1.250"
Preparing the local model:
109
"
*
*
*
*
*
*
*
Open "LMDemo.mdl" model on the bubbe client window by clicking on the triangle on the
left of the model label
Wait until windows of all the external to pop-up before going back to the bubbe client
window
Wait until the "Top_LevelModule" appears, then open the module by clicking on the
triangle on the left of the module label
Open "DesignAnalysis" module on bubbe, then open "RnumCrit" under it
Open the "Excel" module, left click on the variable "Rnum" to highlight it, then right click to
choose "Copy local location"
Close Excel module by clicking the triangle on the left
Go back to the "DesignAnalysis" module, left click on "Attribute" under the "RnumCrit"
module to highlight, then right click to choose "Connect alias"
Left click the "DesignAnalysis" module again to highlight, then right click to choose "Add" > "Analysis" -> "Optimization"
*
*
*
*
*
*
*
Left double-click on "GAOptimizer" to open optimization window
Go back to the bubbe client window, open "AggregateScore" module under
"DesignAnalysis", hightlight then right click on "score" to select "Copy local location"
Go to the optimization window, click "Add Objective" button
Wait for the "ALERT or something" window to pop-up, then click the "OK" button on it
Go back to the bubbe client window, open "VendorTest" module under the "Vendors"
module, do "Copy local location" for the "ReqDepth" variable, then click the "Add Modules"
button on the optimization window
Repeat the process for variable "FlowV"
Set upper and lower bound for the two variables on the optimization window as follows:
ReqDepth
FlowV
*
*
LB = 1.3E-4
UB = 4E-4
LB = 0.03
UB = 0.08
Click the "GASettings" tab on the top of the optimization window, set value of "Generation"
to "5" and value of "Population" to "3"
Iconize the optimization window for the time being
Preparing the farfalen CAD model:
*
*
*
*
*
Go to the farfalen client window, open the "LMCAD.mdl" model
Wait until the "TopLevel_Module" to come up, then open the "CostModel" module
Go to the farfalen screen, click "Close" on the "Tip of the Day" pop-up window
Go back to the bubbe screen, open the "Catalog" module, then change the value of
"selection" under it from "1.0" to "5.0"
Go back to the farfalen screen, maximize the SolidWorks window
Preparing the tanta Matlab model:
*
*
*
Go back to the bubbe screen, go to the tanta client window to open the "LMMatlab.mdl"
model
Wait until the "TopLevelModule" to come up, then open the "Matlab" module
Go to the tanta screen, maximize the Matlab "Figure NO. 1" window
DOME optimization operation:
110
*
*
*
Bring the optimization window back to normal size, then click the forward button on the
bottom of the window ( the double-arrow button on the far right ) to initiate the optimization
process
Take note on how the optimization result converges on the "Objective function Score"
graph
Close all models and windows properly without saving any of the changes ( refer to
Chapter 4 of the thesis for DOME shutdown procedures)
Stage 3 (ASSEMBLY DESIGNER APPLICATION)
Starting point:
*
*
*
*
*
*
"
*
*
*
USE COMPUTER ON THE LEFT
Restart computer
At the LILO boot prompt, type "linux"
Wait until the Athena screen come out, type CTRL-ALT-DEL to initialize logon window
Logon with personal Athena account
At the Athena prompt, type "ssh -1tzelee cadlab9.mit.edu"
Enter password as "kyookaral"
At the cadlab9 prompt, type "cd ASA/AD"
Then type "AD" (please do not attach an & symbol as that causes mal-functioning of the
program)
Click "File" -> "Open", then input assembly name as "OpAssm"
Geometric Constraint input:
*
*
*
*
Click "Modules" -> "SPAS" on the tool bar
Enter "n" for the question: "Would you like to have the parts displayed?"
Enter "y" for the question: " Is this information correct?"
Enter "n" for the question: "Would you like to include disassembly axis information in the
analysis?"
* Enter "n" for the question: "Would you like to read the answers stored during a previous
run of SPAS/2?"
" Answer "y" for question 1, then "n" for question 2
* Press CTRL-C to retrieve to the previously entered data
* Click "Modules" -> "DFCPR" on the tool bar to show the geometric constraints derived by
the computer based on DFC
* Click "Modules" -> "Constraint Analysis" to check for over/under constrained conditions in
the assembly model
Assembly Designer sequence editing operation:
*
*
*
Click "Modules" -> "EDIT" -> "Complete" to initiate EDIT program
Enter "n" for the question: "Do you want to read data from a previous problem?"
Enter "n" for the question: "If you want to use the part drawings, type the name of the
assembly?"
111
Click on the unexpanded sequence graph window to show all possible assembly
sequences
* Display state information by Clicking "Show" -> "Show-state"
* Initiate sequence deletion mode by click the "Delete" -> "del-state" button on the top tool
bar
* On the last level of assembly states with 6 liaison matrices, delete all but the state with
liaison 2 and 3 uncompleted (matrix number 3 counting from the left). Explain according to
the example presented in Chapter 3 of the thesis
* Click "Redraw" -> "graph" to show the edited tree
* Click "Quit" -> "yes" to quit EDIT program, then click "OK" on the pop-up message window
* Close the Assembly Designer window without saving any changes
*
Stage 4 (KCTool APPLICATION)
Starting point:
*
*
USE COMPUTER ON THE RIGHT
Open window explorer in directory C:\Thrust2DEMO\KCTool
KCTool inspection simulation operation:
*
*
*
Simulate inspection by clicking "Inspect" -> "Simulate Inspection"
Enter "100" as number of products built
Show inspection simulation result, point out the most rework are done at the alignment
and the distance KCs
KCTool inspection optimization operation:
*
*
*
*
*
Optimize inspection strategy by clicking "Inspect" -> "Optimize Inspection"
Enter "100" as initial temperature, click "ok"
Enter "100" as number of products built per setting
Open opt_result.bmp to show result of inspection strategy optimization
Close all windows without saving any changes
112