University of Southern California Dissertations and Theses

A document-driven approach to conceptual design

(USC Thesis Other)

A document-driven approach to conceptual design

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content NOTE TO USERS
Page(s) not included in the original manuscript and are
unavailable from the author or university. The manuscript
was scanned as received.
ii
This reproduction is the best copy available.
®
UMI
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
A DOCUMENT-DRIVEN APPROACH TO CONCEPTUAL DESIGN
BY
OREN BENAMI
A Thesis Presented to the
Faculty of the School of Engineering
University of Southern California
In Partial Fulfillment of the Requirements for the Degree
Master of Science in Mechanical Engineering
December 1999
Copyright 1999 OrenBenami
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
UMI Number: 1427988
INFORMATION TO USERS
The quality of this reproduction is dependent upon the quality of the copy
submitted. Broken or indistinct print, colored or poor quality illustrations and
photographs, print bleed-through, substandard margins, and improper
alignment can adversely affect reproduction.
In the unlikely event that the author did not send a complete manuscript
and there are missing pages, these will be noted. Also, if unauthorized
copyright material had to be removed, a note will indicate the deletion.
®
UMI
UMI Microform 1427988
Copyright 2005 by ProQuest Information and Learning Company.
All rights reserved. This microform edition is protected against
unauthorized copying under Title 17, United States Code.
ProQuest Information and Learning Company
300 North Zeeb Road
P.O. Box 1346
Ann Arbor, Ml 48106-1346
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
ACKNOWLEDGEMENTS
I would like to thank my advisor, Dr. Yan Jin for his guidance in developing this thesis,
and more importantly, for showing me how to do research. I would like to thank the
other members of my thesis committee; Dr. Richard Kaplan and Dr. Geoffrey Shiflett for
their perceptive observations and remarks. I would like to thank Ping Ge (Christine) for
helping me design the DDCD Graphical User Interface. I would like to thank the other
members of the IMPACT Laboratory for their insightful comments at our weekly
meetings. I would like to thank my family and friends for supporting my decision to
continue in graduate school; especially my parents, Uriel and Henrietta Benami, and my
Uncle and Aunt, Norman and Mauma Abrams, who have stood behind me in my
scholarly endeavors.
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
iii
TABLE OF CONTENTS
1 Introduction............................................................................................................................1
1.1 Conceptual Design....................................................................................................... 2
1.2 Design Rationale...........................................................................................................3
1.3 Documentation...............................................................................................................6
1.4 The Roles Of Documentation In Conceptual Design.................................................7
1.5 Research Questions........................................................................................................8
1.6 Overview Of The Thesis Contents.............................................................................. 9
2 Design Methodology And Documenting Approaches............................................... 11
2.1 Design Methodology....................................................................................................11
2.1.1 Systematic Design............................................................................................ 13
2.1.2 Axiomatic Design..............................................................................................14
2.2 Documenting Approaches.......................................................................................... 15
2.2.1 Notebooks.......................................................................................................... 16
2.2.2 Active Reading...................................................................................................16
2.2.3 Hypertext............................................................................................................ 17
3 Research Objectives............................................................................................................19
3.1 Explicate The Information Generating Process........................................................ 19
3.2 Manage The Information Generating Processes......................................................20
3.3 Stimulate Designers To Generate Design Concepts................................................21
4 The DDCD Approach........................................................................................................ 22
4.1 The Configuration And Process Flow Of DDCD....................................................22
4.2 Perspectives On DDCD..............................................................................................26
4.2.1 Product Flow Perspective.................................................................................26
4.2.2 Information Flow Perspective.............................................................................28
4.2.3 Resource Perspective...........................................................................................29
4.2.4 The Complete Model Of DDCD.........................................................................29
4.3 Applying DDCD To Design Methodologies............................................................ 30
4.3.1 Developing The Function Structure....................................................................31
4.3.2 Developing the Working Principles....................................................................32
4.3.3 Software Development.........................................................................................33
4.4 Conceptual Design Issues Addressed By DDCD.....................................................38
4.5 Limitations Of The DDCD Approach........................................................................39
5 Tools That Support Concept Generation And Information Management...................... 41
5.1 Existing Tools.............................................................................................................41
5.1.1 vmacs................................................................................................................. 41
5.1.2 Dynomite...............................................................................................................43
5.1.3 AESOP..................................................................................................................43
5.1.4 Xlibris...................................................................................................................44
iv
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
5.1.5 C -D eSS...............................................................................................................45
5.2 Comparison To DDCD..............................................................................................46
6 Case Scenario— Function Structure Development Of A Water Sampler...................... 48
6.1 Problem Statement..................................................................................................... 48
6.2 Solving The Problem With A DDCD— Systematic Design Approach.................... 48
7 Conclusions And Recommendations For Future Work...................................................51
7.1 Research Contributions...............................................................................................51
7.2 Future Work................................................................................................................52
7.2.1 Developing The Information Model.................................................................52
7.2.2 Extending DDCD To Collaborative Design......................................................52
7.2.3 Stimulating Creativity In Design........................................................................56
BIBLIOGRAPHY.................................................................................................................62
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
v
LIST OF FIGURES
Figures
3.1 Knowledge Resources For Design.............................................................................20
4.1 Documentation Units................................................................................................. 23
4.2 The Configuration and Process Flow of DDCD...................................................... 25
4.3 Product Flow Perspective Of DDCD........................................................................ 26
4.4 The Abstraction Process............................................................................................ 27
4.5 Information Flow Perspective Of DDCD.................................................................28
4.6 Resource Perspective Of DDCD................................................................................29
4.7 Complete Model Of DDCD.......................................................................................30
4.8 The DDCD Graphical User Interface....................................................................... 34
4.9 Developing A Function Structure With DDCD....................................................... 36
4.10 Developing Working Principles With DDCD....................................................... 37
6.1 Water Sampler: Function Structure Development...................................................49
6.2 Water Sampler: System Generated Solution And Design Rationale......................50
7.1 CDDCD Design M atrix............................................................................................. 56
7.2 Design Processing Mediums......................................................................................58
7.3 Creative Design Mechanisms....................................................................................60
Table
5.1 Design Tool Evaluation...........................................................................................47
v i
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
1 Introduction
Product design is people, knowledge, tools, and skills working together to develop a
product. Engineers work with marketing, manufacturing, and management in order to
bring the design to fruition. Marketing communicates a perceived market need to
engineering, which interprets the request, develops concepts, and refines the best
concepts into manufacturing specifications (i.e. drawings, bills of materials, and assembly
instructions).
Today’s products have become so complex that most designs require a team of engineers
from diverse areas of expertise to develop an idea into a working solution. The more
people involved in a project, the greater the need for assistance with communication, and
for structure to ensure that nothing important is overlooked. The global marketplace has
fostered the need to develop new products at a very rapid and accelerating pace. As
products are developed at a rapid pace by larger teams, companies must find better ways
to handle the information being generated. A very efficient information control process is
essential to a companies survival in an increasingly competitive marketplace.
Design can be divided into the following main phases: conceptual design, embodiment
design, and detailed design. Conceptual design is the process of creating design concepts
and developing them into working principles. Embodiment design is the process of
transforming the working principles into a technical system. Detail design is the process
of transforming the technical system into detailed specifications (i.e. material
1
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
specifications, cost estimates, drawings, and all other product documents).
Many systems that improve the embodiment and detailed design phases (e.g. CAD, FEA)
have been developed, and are being used in industry, but very few conceptual design
systems have made their way into engineering organizations. This research attempts to
develop a methodology to support the information generating process of conceptual
design.
1.1 Conceptual Design
A concept is an idea that is sufficiently developed to evaluate the physical principles that
govern its behavior. Conceptual design is the process of creating design concepts and
developing them into design solutions. The concepts evolve through a process of
selecting preliminary materials, producing rough dimensional layout, and considering
technological possibilities. The design concepts must be refined enough to evaluate the
technologies needed to realize them and to evaluate their basic architecture.
Conceptual design is the most creative phase of design because innovative ideas are
generated at a rapid pace. It is also the most informal, most ambiguous, and least
understood phase of the design. Relationships are often unclear or not well developed.
Ideas come and go, and can easily be lost forever if not recorded immediately.
Unfortunately, the implications of conceptual design are not always well thought out.
2
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
Often, relatively little time is invested but conceptual design results are critical to the rest
of the design. It is estimated that 75% of final costs are obligated during conceptual
design [1.1].
The most important characteristics of the conceptual design phase are:
• large amounts of inventive ideas are generated in a short amount of time;
• it is difficult to categorize the informal information that is generated;
• it is difficult to keep track of ideas as they are being generated;
• it is difficult to organize ideas during concept development; and
• it is not well supported by computational tools.
These conceptual design issues point to the need for methods to support the information
generating process during conceptual design. Many researchers are trying to meet this
challenge but progress has been slow because of the informal and creative nature of
conceptual design.
1.2 Design Rationale
The role of design rationale in conceptual design is to help designers:
• evaluate design ideas;
• evaluate design decisions; and
• stimulate generation of new ideas.
3
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
Design rationale also helps designers reduce conflicts, minimize undesirable effects in
products, and make design modifications easier.
Design rationale can be represented implicitly or explicitly. Implicit design rationale is
inferred by designers when reviewing design documents. For example, a designer may
look at a drawing of a truss and infer that there is a specific strength associated with it.
The danger of implicit design rationale is non— uniformity; one designer may interpret the
design different then another because they have different background knowledge. In
addition, designers may not consider all the relevant design factors if they are lacking
expertise. Explicit design rationale, on the other hand, is a record that leaves little doubt
about the rationale for a design.
Conceptual design involves working with an infinitely large design space in which an
infinite number of design ideas can be generated. Since conceptual design ideas come
from abstract thinking, they may not be generally sound, or they may not make sense in
the larger context of a design. A record of explicit design rationale can help validate
these ideas. Design ideas that make sense after design rationale has been analyzed are
likely to be good solutions.
In addition to evaluating design ideas, design decisions are evaluated during conceptual
design. During conceptual design, decisions are made about which ideas should be
included in the design and how ideas should be combined. Explicit design rationale
assigned to decisions can help designers backtrack and analyze the decisions that have
4
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
been made. If a decision still makes sense after the explicit rationale has been analyzed,
then it is a rationale decision (in the given design space).
Researchers have developed methodologies for explicitly capturing design rationale.
There are two types of approaches being used to explicitly capture conceptual design.
One approach attempts to generate design rationale by automated inference from
designers’ actions [1.2 et al.]. The advantage of using this approach is that the process of
capturing design rationale is transparent to the designer. The disadvantages of using this
approach are twofold. First, the ambiguity inherent in conceptual design cannot be
captured. Second, automated systems cannot generate the rationale for design ideas in an
infinite design space (such as conceptual design). The second approach captures design
rationale by providing methods for designer’s to record dependencies between design
decisions [1.3 et al.]. The disadvantage of this approach is that designers must take the
time to record the design rationale. There are two main advantages of this approach.
First, designers are able to capture any aspects of the design that they deem important. If
the methods are informal enough, even design ambiguities can be captured. Second, the
process of recording design rationale stimulates designers to generate design concepts.
Research into design rationale points to the need for non— intrusive methods for explicitly
recording conceptual design rationale. Many researchers are trying to meet this challenge
but progress has been slow because designers are unwilling to spend time recording
design rationale and it is difficult to develop a system that is user friendly.
5
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
1.3 Documentation
Documentation is information recorded for others/oneself for use in a different time
and/or place. People generally think of documentation as being useful for
communicating, and for recalling information from the past, but documentation has other
useful purposes. The documenting process can help synthesize ideas and stimulate
concept generation. The information processing capacity of humans is only about seven
clusters of information at a time [1.4], so even simple analysis situations can be aided by
documentation.
There are three main steps to creating a document: record, organize, and index.
The purpose of recording is to create a record of ideas before they are forgotten and to
stimulate the mind to find associations between existing ideas. The purpose of
organizing is to eliminate possible confusions about information, to present the
information to others, and to make future retrieval of the information easier. The purpose
of indexing is to make retrieval of information faster.
Recorded information can be structured or unstructured. Information that is recorded into
a template is structured. Information that is recorded in free form is unstructured.
Structured recording media are useful for recording data, and pre— rationalized
information. Some examples of structured recording mediums are spreadsheets and
databases. Unstructured recording media are useful for recording abstracts and
underdeveloped ideas. Some examples of unstructured recording mediums are an artists
6
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
canvas and engineering notebooks. Unstructured documents may become structured by
organizing and arranging the information with a process called structuring.
The abstract nature of conceptual design makes structured recording difficult. That is
why designers usually record unstructured information and later structure the information
as the artifact develops. Currently, designers typically record unstructured conceptual
design information in notebooks and structure the information by intuition. This points to
the need for methodologies to guide designers in the structuring of information.
1.4 The Roles Of Documentation In Conceptual Design
Some aspects of documentation are emphasized more in certain design phases then in
others. For example, detailed design emphasizes a rigorous record of information (e.g.
detailed drawings), while conceptual design emphasizes the idea generating and
synthesizing aspects of documentation (e.g. freehand sketches).
In conceptual design, idea generating and synthesizing are facilitated by the recording
and structuring processes. New design concepts are generated by recording conceptual
design ideas and design rationale. A record of rationale is necessary to justify ambiguous
design ideas. The process of structuring design ideas and rationale helps designers
synthesize design information, create a consensus among participating engineers,
stimulate the generation of new concepts, and develop a repository of information for
future reference.
7
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
Documenting mediums may be informal or formal (section 1.3). An informal
documenting medium allows designers the flexibility to record design information in the
way that is best for them. A formal medium restricts designers to entering design
information in a specific way.
In conceptual design, the documenting medium should be informal. Using a formal
medium to record conceptual design ideas inhibits the ability of a designer to “say what
they mean” and therefore limits the “richness” of the captured information. On the other
hand, the documenting medium should not just be a blank page. It should also provide
the resources for structuring information as the design matures.
1.5 Research Questions
The information processing issues relevant to conceptual design are:
♦ Ideas are easily lost if not recorded immediately;
♦ Ideas generated are very abstract, informal, ambiguous, and complex;
♦ It is difficult to organize, structure, and categorize ideas; and
♦ There is a lack of knowledge about how to innovate.
These issues raise the following important research questions:
♦ What controls and mechanisms govern the information generating process?
♦ What constructs help us understand and support the information generating process?
8
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
❖ How can we capture as much conceptual design information as possible?
❖ How should design ideas and design rationale be recorded and structured?
❖ What documenting methods stimulate designers to innovate?
❖ What language and media are best for recording and structuring information?
❖ How can documentation concepts be applied to existing design theory?
❖ Can we develop a methodology and system to support the information generating
process in conceptual design?
1.6 Overview Of The Thesis Contents
Chapter 1 presented the major conceptual design issues and the role of documentation in
conceptual design. Chapter 2 presents a more detailed description of design theory and
documentation approaches. Two of the more widely known process models for design are
described and several documenting approaches are presented. In chapter 3, the main
objectives of this research, and the research limitations are described. In chapter 4, the
DDCD (Document— Driven Conceptual Design) approach and the DDCD structure are
explained and decomposed from three perspectives: product flow, information flow, and
resources. DDCD is applied to a design process model to develop functions and
solutions, and the limitations of DDCD are described. Chapter 5 describes the state of
technology for developing a DDCD design tool. Existing tools for designing and
documenting informal information are presented and conceptual design information
generating processes that are missing from these tools are identified. In Chapter 6, the
DDCD system is demonstrated with a case scenario that follows the DDCD
9
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
methodology. The case is evaluated and recommendations are made for improving the
DDCD methodology and the DDCD system. Chapter 7 contains conclusions and
recommendations for future research. Four areas identified for future work are:
developing information models; extending the DDCD methodology to collaborative
design; and enhancing creativity in design.
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
10
2 Design Methodology And Documenting
Approaches
This research encompasses two areas: design methodology and documenting approaches.
Design methodology develops models to say how design should be done. Documenting
approaches look at media and processes as methods for creating, reading, and
understanding information.
Two design methodologies: systematic design [2.1] and axiomatic design [2.2], were
analyzed to determine how design information is generated. Three documenting
approaches: notebooks, active reading [2.3], and hypertext; were analyzed to understand
how to manage conceptual design information. The design methodologies and
documentation approaches were studied simultaneously to advance the development of a
document— driven approach to conceptual design.
2.1 Design Methodology
Design methodology develops models to say how design should be done. The design
methodologies reflect three points of view: decision view, knowledge view, and process
view [1.5].
The decision view treats design as repetitions of a simple two-step process, namely,
option generation and decision making. It assumes that designers can acquire all needed
11
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
information to make estimates on all considerable choices. However, it does not
recognize the ambiguity that is prevalent in conceptual design.
The knowledge view of design focuses on how knowledge should be organized to design
effectively. The knowledge view sees little difference between designing and other goal
driven processes. Complexity and uncertainty are dealt with by acquiring and organizing
knowledge about engineering products and processes.
The process view of design focuses on process flow and defines steps or phases of design
and methods that are applied at different phases of design. The process view of design
attempts to reduce design ambiguity, complexity, and uncertainty by restricting designers
activities to a set of predefined ones. This restriction can maintain the consistency of
design and keep it going in the right direction. The down side of following a process
view is that the process restrictions imposed may limit a designer’s thinking space, and
therefore limit creativity.
Two examples of the process view of design are systematic design, and the zig-zag part
of axiomatic design. When systematic design and the zig-zag part of axiomatic design
are implemented with the DDCD approach, the result is a more effective method for
designing and managing the information generated.
12
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
2.1.1 Systematic Design
Systematic design [2.1] prescribes four information generating steps in conceptual design
and gives recommendations for how to document the information generated. The first is
abstracting design requirements into essential problems. The procedure for abstracting
requirements consists of: 1) eliminating personal preferences; 2) omitting requirements
that have no direct bearing on the function and essential constraints; 3) transforming
qualitative data into quantitative data; 4) generalizing the results of the previous steps;
and 5) formulating the problem as solution-neutrally as possible.
The second step of conceptual design is establishing a function structure. Systematic
design identifies several types of functions in the function structure. The overall function
is the highest level function that specifies what goal the design should achieve. The
overall function is decomposed into main functions, which specify the goal of each main
component in the design. The main functions are decomposed further into sub-
functions, which specify the goals of each sub— system. Sub— functions are decomposed
further into lower level sub— functions until the desired level of detail is acquired. A
designer with little experience will generally need to decompose functions further then a
designer with a lot of experience.) Auxiliary functions are secondary tasks that effect the
system in some way but are not part of the main flow of a function structure. Functions
are connected by energy flows, material flows, and signal flows.
The third step in systematic design is the search for sub— structures, systematic design
13
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
recommends creating a document to help develop working principles. Functions are
recorded as row headings and possible sub— structures are recorded in columns.
Theoretical ideas about the nature and form of the sub— structures are usually presented
with diagrams or working sketches.
The fourth step in conceptual design is combining sub— structures. Systematic design
recommends using a morphology matrix to create variant working structures from a table
of sub— structures. A selection chart is used to evaluate working structures by qualitative
criteria such as “fulfills demands of the requirements list” and “realizable in principle.”
The four steps outlined above serve as basic guidelines for designers to follow in the
information generating process. DDCD can assist systematic design by specifying basic
constructs for recording and structuring information.
2.1.2 Axiomatic Design
Axiomatic design [2.2] recognizes four domains in the “design world.” The customer
domain is characterized by customer needs, the functional domain is characterized by
functional requirements, the physical domain is characterized by design parameters, and
the process domain is characterized by process variables.
The conceptual design process in axiomatic design is accomplished by zig-zagging
between functional requirements and design parameters. The zig-zag process starts from
14
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
a functional requirement in the function domain, then “zigs” to a design parameter in the
physical domain, then “zags” back to the functional domain to create a lower level
function that satisfies the higher level function and the corresponding design parameter in
the physical domain. Then, the process “zigs” back to the physical domain to find a
design parameter that satisfies the newly created functions. This process continues until
the functional requirements are satisfied without any further decomposition.
The zig-zag method serves as a basic guideline for designers to follow in the information
generating process. DDCD can assist axiomatic design by specifying basic constructs for
recording and structuring information.
2.2 Documenting Approaches
Documenting approaches look at media and documenting processes as ways of recording,
structuring, and reusing information. Surveys show that reusing design information is
much less costly, and much more time effective than regenerating the same information.
Effective documenting approaches can make documentation usage a more transparent
process.
Three documenting approaches that make documentation usage a more transparent
process are notebooks, active reading, and hypertext.
15
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
2.2.1 Notebooks
The engineering notebook is a traditional medium for the conceptual phase of
engineering design. Design notebooks gather many kinds of information for later use,
including inferred design rationale and a dynamic history of the concepts generated.
Electronic design notebooks try to mimic the freedom and agility of pen and paper while
adding the processing power of computers. In developing a system to support the DDCD
approach, the informal nature of conceptual design was considered. Section 4.3.3,
software development, describes the features that make the DDCD system user-friendly
for conceptual design.
2.2.2 Active Reading
People read more actively when they are underlining, highlighting, commenting, and
otherwise marking up a document. The combination of reading and critical thinking and
learning has been defined as active reading.
During active reading, comments and sketches are annotated on the page. The
advantages of annotating directly on a page are convenience, immersion in the document
context, and visual search. Marks on the page may represent various levels of agreement
or disagreement. Annotations stand out visually, allowing readers to scan for them.
16
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Researchers have attempted to integrate computation with active reading. This type of
research is most helpful for the interactive / redesign process. The combination of
computation power and active reading can allow designers to find related design material
make comments and suggestions about the design, and move from one design to another
with ease.
Concept generation requires reading existing design information with a very critical eye
to develop new ideas and improve existing ideas. Active reading is precisely the type of
reading that is required for conceptual design. Active reading concepts have been
incorporated into the DDCD approach to make the designer more proactive.
2.2.3 Hypertext
Hypertext is a way of instantaneously jumping from a point in one document to a
different point in the same or another document by keyword links. This process of
jumping between different places in document(s) saves time that would otherwise be
spent searching for necessary information.
Hypertext research has identified several categories of useful information retrieval
techniques. The newspaper metaphor (e.g. the internet) is one technique for information
retrieval. Loosely related articles are organized to support browsing and selective
reading. The links on the page connect a particular anchor to another document. The
links can be displayed with a different brightness or saturation value than other terms to
17
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
differentiate them from the other parts of the page.
Jumping from one document to another is a common occurrence in conceptual design.
The DDCD system uses hypertext to instantaneously jump to design solutions generated
by an information model.
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
18
3 Research Objectives
There are two main objectives of this research:
1) Explicate the information generating process in conceptual design
2) Develop a methodology that:
> manages the information generating processes; and
> stimulates designers to generate design concepts.
3.1 Explicate The Information Generating Process
Knowledge resources for design are human minds, design documents, and information
models (Figure 3.1). These resources can be exploited to develop a better understanding
of how information is generated in conceptual design and how the information generation
process may be assisted.
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
19
Human Intelligence/Knowledge
Information Models
Documentation
Figure 3.1: Knowledge Resources For Design
3.2 Manage The Information Generating Processes
Recording, structuring, and reuse of information in conceptual design can be supported
by an information management methodology. Critics of the process view of design point
out that restricting a designer’s activities to a set of pre-defined actions may cause a
designer to miss a good design that is not on the track of the specific process flow. A
flexible methodology for documenting design that does not a priori eliminate potential
designs is therefore essential.
If a DDCD process model is flexible enough to allow a designer to record ideas,
relationships, and design rationale as they are developed, then the design space will not
20
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
be compromised. Furthermore, a DDCD methodology may minimize the loss of
information that usually occurs during the structuring of a document. Design information
is usually lost when designer’s jump to conclusions by making incorrect assumptions
about functional requirements. With DDCD, designers will be encouraged to document
all their ideas and design rationales as they are generated.
3.3 Stimulate Designers To Generate Design Concepts
Concept generation can be stimulated in two ways. First, the process of recording may
foster the development of additional design concepts. (“Insights can be triggered by
producing freehand sketches or technical drawings of solution ideas” [2.1].) Second,
solutions generated from information models can encourage the development of new
design concepts.
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
21
4 The DDCD Approach
DDCD views design as a concept generation and management process. The DDCD
approach helps designers manage design information as it is recorded, structured, and
reused. Basic organizational constructs are used to categorize design information as it is
generated. With DDCD, information can be quickly and easily recorded and structured.
Product and process models contain design solutions that can be provided to designers
when necessary. Designers can use the DDCD approach to drive the design forward with
minimal loss of information and maximum design efficiency. The result of following the
DDCD approach is that less information is lost during the recording and structuring
process and more design concepts are generated.
4.1 The Configuration And Process Flow Of DDCD
There are five main components in DDCD: 1) conceptual design idea; 2) unstructured
document; 3) semi— structured document; 4) structured document; and 4) information
model (product and process model).
Conceptual design ideas are concepts that contribute to or result in the specification of a
design solution. Once ideas are recorded, they are identified as documentation units.
Two types of documentation units are defined: 1) entity and 2) relationship. An entity is
a requirement, function, or working principle. A relationship is a flow or geometric
interaction between entities. Two types of relationships are defined: 1) flow relationships
22
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
are 2) geometric relationships. Flow relationships are energy, material, or signals
traveling between entities. Geometric relationships are physical interactions between
entities. Each entity and each relationship has design rationale associated with it. A
summary of the different types of documentation units is shown below (Figure 4.1).
Design Rationale
Associated With
Entity \
Design Rationale
Associated With
I Relationship
Entity
Requirement,
Function,
Working principle
Relationship
Flow,
Geometric
Figure 4.1: Documentation Units
In the DDCD approach, entities and their associated design rationale are recorded in an
unstructured format. The document becomes semi-structured as the designer links the
entities with relationships (and associated design rationale). When all the entities,
relationship, and associated design rationale have been filled in, the document is
23
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
structured.
The structured documents are compared to information models (product and process
models) in the particular design domain (e.g. car, ship, etc...). The process models
contain generic knowledge about tasks, interfaces (inputs and outputs between tasks), and
the controls and mechanisms for achieving tasks. The product models contain generic
knowledge about product modularity and product decomposition. Product modularity
focuses on the independence of ideas for allowing standardization and interchangeability.
Product decomposition breaks down the product into classifications and hierarchy of
ideas.
Design solutions are suggested to the designer based on an interpretation of the structured
document. There are two main benefits of suggesting solutions to the designer. 1) The
solution may be used in the design 2) The solution will usually stimulate the designer to
generate new design ideas. The new design ideas can be synthesized into existing
documents or be recorded in a new document. The designer uses the DDCD process loop
continuously until the conceptual design phase is complete.
The configuration and flow of DDCD is shown in Figure 4.2. The main components in
the DDCD process are denoted as follows: idea (I), unstructured document (U), semi-
structured document (SS), structured document (S), and product or process model (M).
The main activities in the DDCD process are denoted as follows: record ( r ),
structure ( s ), compare ( c ), generate ( g ) and stimulate ( s t).
24
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
u
ss s
Figure 4.2: The Configuration and Process Flow of DDCD
During the DDCD process, the designer should ask his/herself the following questions to
insure that the design is headed in the right direction:
• Is the entity or relationship compatible with the overall task?
• Does the entity or relationship fulfill the functional requirements?
• Is the entity or relationship technologically realizable?
• Does the entity or relationship meet cost requirements?
2 5
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.2 Perspectives On DDCD
Process models can be better understood by decomposing them from three perspectives:
1) a product flow perspective; 2) an information flow perspective; and 3) a resource
perspective [1.5]. Since DDCD is a process, it is useful to analyze it from these three
perspectives.
4.2.1 Product Flow Perspective
The product flow perspective focuses on the activities that transform customer
requirements into working structures. The critical activities in DDCD are: record,
structure, generate, and stimulate (Figure 4.3).
Record Structure Generate Stimulate
Figure 4.3: Product Flow Perspective Of DDCD
Recording is the process of documenting written symbols that represent ideas. In DDCD,
a group of written symbols representing a design concept is called a documentation unit.
The structuring process consists of the following activities: recording relationships
between entities; recording design rationale for documentation units; removing entities,
merging entities; splitting entities; and redefining relationships. Solutions are generated
26
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
by comparing the design to relevant product and process models. The solutions stimulate
the designer to think of new ideas and analyze existing ideas.
The new ideas emerge by an abstraction process. Ideas are abstracted by reducing the
number of entities and emphasizing the essential characteristics of the problem. Creative
ideas are generated first at a high level, which then provides an opportunity for further
recording (Figure 4.4). Many new ideas can be recorded during a burst of inspiration.
Essential
Characteristics
Abstraction
Documentation
Entities
Figure 4.4: The Abstraction Process
2 7
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.2.2 Information Flow Perspective
The information flow perspective represents control over execution of activities. Figure
4.5 shows the DDCD information flow perspective. Recording and structuring are
controlled by the design methodology, the designer’s experience, solution documents.
Generating is controlled by the design methodology and the product/process model that
generates sub— solutions. Stimulating is controlled by the design methodology and the
designer’s experience.
_ DDCD _
Guidelines
Solution
Document
Design
Methodology
Design __
Experience
Record
Product/Process
Model
I
Design
Methodology
Structure Generate
Design
Experience
Design
Methodology
i
Stimulate
Figure 4.5: Information Flow Perspective of DDCD
28
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.2.3 Resource Perspective
The resource perspective (Figure 4.6) provides activities with a mechanism for
transforming inputs to outputs. A design engineer records and structures design
information with the aid of a DDCD tool (presented later in this research). The DDCD
tool is also the mechanism for generating sub-solution views, which stimulate the
designer to think of new ideas.
Design_
Engineer
Design
Engineer
DDCD DDCD
Record Structure Generate Stimulate
Tool Tool
Figure 4.6: Resource Perspective of DDCD
4.2.4 The Complete Model Of DDCD
The three process models views are combined to form a complete process model of
DDCD (Figure 4.7).
29
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
_ DDCD _
Guidelines
_ Solution _
Document
Design __
Methodology
_ Design _
Experience
Product/Process
Model
I
Design
Methodology
Design
Experience
I
Design
Methodology
Design
Engineer
Design_
Engineer
DDCD DDCD
Record Structure Generate Stimulate
Tool Tool
Figure 4.7: Complete Model Of DDCD
4.3 Applying DDCD To Design Methodologies
DDCD is applied to the Systematic Design process to demonstrate how DDCD manages
design information. First, DDCD is applied to the function structure development
process, then DDCD is applied to the working principle development process. Finally,
the software being developed to implement DDCD approach is introduced.
30
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.3.1 Developing The Function Structure
The first phase of DDCD— Systematic Design is recording functions (entities in DDCD).
The types of functions recorded during function structure development are overall
function, main functions, sub-functions, and auxiliary functions.
Systematic Design provides guidelines for developing function structures. “It is useful to
record main functions first, and then break down the main functions into sub-functions
that are more complex. Fusing functions (combining two or more functions into one)
provides what are often simple and economic solutions” [2.1].
Two types of relationships were defined in DDCD: flow and geometric. Combinations of
all three flows are usually found in mechanical engineering applications. There are no
geometric relationships between functions because functions have no form.
Function structuring is the process of recording flows between functions, specifying
design rationale for functions, specifying the design rationale for relationships between
functions, and organizing function structures. Each function has design rationale
associated with it, and there are relations and design rationale linking functions.
Functions are organized by changing the arrangement of functions, and by fusing
functions. Design rationale tries to answer the following questions:
• How does the function or relationship fulfill demand(s) from the requirements list?
31
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• How is the function or relationship compatible with the overall task?
• How can the function or relationship be realized?
• How can the function or relationship meet cost requirements?
4.3.2 Developing the Working Principles
When function structure development is complete, many working principles are
generated for each function. A working structure is converged upon by excluding
obviously bad working principles, generating new variants by combining working
principles, and selecting one or several variants as concepts for further developing.
Systematic Design gives guidelines for developing working principles. “Only solutions
that meet the demands of the requirement list should be pursued, a morphology chart is
useful to relate functions to working principles, working principles should be combined
with consideration of geometric and physical compatibility.” [2.1]
The working principles and their relationships are sketched or described with text in a
design notebook. Design rationale attempts to answer the following questions:
• How does the working principle fulfill requirement list demands?
• How does the working principle fulfill function structure demands?
• Is the working principle compatible with the overall task?
• How can the working principle be technologically realized?
• How can the working principal meet cost requirements?
32
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.3.3 Software Development
A software program is being developed to demonstrate the usefulness of the DDCD
approach. The program is designed to work with an electronic pen— tablet interface. It
combines editing features with the computation power of computers. Designers can
easily zoom in and out of the electronic pages, move around a page, and merge separate
pages into one large document.
The graphical user interface (Figure 4.8) consists of a creative design panel for recording
design information and guidelines to guide the designer through the documenting
process.
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
33
Hg C:\Funclion_Struclure
File D om ain Edit Help
Functions J Working Principles ■
GUI
CREATIVE DESIGN PANEL
T j Page 1 j P ag e 2 j P a g e 3 , P a g e 4 ) Merge I Variant |
l - ^ i l IN ZOOM o u r i
I d
l- |g |x i
laHonship | Input Rationale | Com pare with Existing Models |
SYSTEMATIC APPROACH A> lO V IA 'l :C APPROACH OTKtR
Figure 4.8: The DDCD Graphical User Interface
Before starting a design, the designer selects a design methodology (e.g. systematic
design, axiomatic design) and a design domain (e.g. ship design, car design). The
designer records his/her thoughts in the creative design panel throughout the conceptual
design process. The information in the creative design panel is recognized as an entity
after it has been circled with an electronic pen. Entities can be modified, dragged around
the page, and interpreted by the DDCD program. Entities are linked by drawing lines
between them. Relationships are entered along side the lines between entities. Design
rationale is input by clicking on the “entity/relationship” button and entering the rationale
34
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
in a pop-up box. Guidelines are specified by the DDCD system to guide the designer
through the recording and structuring processes. The document is completely structured
when all entities, relationships, and design rationale have been filled in.
The structured document is compared to domain-specific product and process models by
pressing on the button “Compare with Existing Models.” The solutions generated by the
information models are shown by captions in the existing design page and hyperlinked to
another page, which contains a more detailed explanation. The solutions encourage
evaluation of alternatives and stimulate designers to think of new concepts.
Figure 4.9 shows the information that is entered and viewed by a designer using the
systematic design methodology to develop a function structure. Main functions, sub
functions, auxiliary functions, and flows between functions are entered in the creative
design panel. Guidelines for recording functions, structuring functions, and recording
design rationale are specified in the guidelines panel.
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
35
File
C :\F unclion S tru ctu re
Edit Kelp
r r m
Functions ; Working Principles
Guidelines ip r
Recording aid
Structuring
Functions
G u i d e l i n e : '
For Recording
De.iicn Rationale
CREATIVE DESIGN PANEL
T j Page 1 j P a g e 2 | P a g e 3 ! P a g e 4 1 M erge ] Variant j
Ll J
Overall Function
H n c r g y F lo w 1
Main Functions
I
M a te ria l F lo w I
S u M u n iio m
1
Signal Flow I
AlKilwiv 1 uuaam
1
E S l . . H
ZOOM OIIT
Define ObjectVtelationship j Input Rationale | C om pare with Existing M odels |
SYSTEMATIC APPROACH AXIOMATIC APPROACH OTHER
Figure 4.9: Developing A Functional Structure With DDCD
A process model contains knowledge about how functions in the particular domain fulfill
design requirements, how functions contribute to the overall task, possible realizations of
functions, and cost requirements for achieving functions. The information model also
contains knowledge about energy/material/signal flows for specific functions. The
working principles suggested by the process model encourage the designer to think of
other possible working principles, evaluate functions and flows, and re-evaluate existing
design rationale.
36
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Figure 4.10 shows the information that is entered and viewed by a designer using the
systematic design methodology to develop working principles. Requirements, functions,
working principles, and relationships are entered in the creative design panel. Guidelines
for recording and structuring working principles and for recording design rationale are
specified by the DDCD guidelines.
\i]
\W orking_P rinciples
File D om ain Edit Help
Q n Q l
Functions Working Principles
GUIDELINES CREATIVE DESIG N PANEL
-----------------------------2 ] * :>a9 e 1 | P ag e 2 1 P a g e 3 ) P ag e 4 \ M erge j Variant |
Guidelines for
Recording and
Structuring:
Worjdng
Principles
GuidelinesTQT
Recording
Design:
R ationale
Id J
I F u n c tio n s
Relationships j
I Working Principles
►
Requirements
S i .
IN ZOOM our !► -!
Define ObjectVtelationship | nput Rationale | C om pare with Existing Models
SYSTEMATIC APPROACH AXIOMATIC APPROACH OTHER
Figure 4.10: Developing Working Principles With DDCD
The designer structures the document by merging, splitting, and removing working
principles. The structuring process is complete when the following information has been
37
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
entered: working principles, relationships between working principles, design rationale,
functions, and requirements.
The design information is compared to a product model which contains knowledge about
working principles, relationships between working principles, and design rationale for
working principles. Recommended working structure solutions are generated by the
DDCD system, displayed on the design page, and hyperlinked to another page, with a
more detailed explanation. The recommendation “encourages” designers to evaluate
existing alternatives, and stimulates designers to generate new working principles.
4.4 Conceptual Design Issues Addressed By DDCD
The conceptual design issues addressed by DDCD are:
1) information loss;
2) lack of design concepts and solutions; and
3) scattering of design information.
DDCD minimizes loss of information with an environment for seamless recording and
structuring of entities and relationships. The DDCD documenting philosophy combines
with standard design methodologies to improve the design process without compromising
flexibility.
DDCD stimulates concept development by providing the designer with possible design
38
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
solutions. The design solutions are presented in graphical views annotated with text to
stimulate the designer to think of new ideas and improve on existing ideas.
All conceptual design information is recorded and organized in one place with the DDCD
software. Since the documents are recorded electronically and follow an organized
documenting process, they can be easily sorted and searched to find the necessary
information at later stages of design.
4.5 Limitations Of The DDCD Approach
There are three main limitations to DDCD:
1) the quality of the recording and structuring processes is not perfect;
2) the solutions suggested by the DDCD system may not be feasible; and
3) the solutions suggested by the DDCD system may stifle innovation.
The quality (information retention) of recording information is not perfect because
DDCD does not guarantee that information will always be recorded after conception. It
is difficult to build a system which forces designers to record information immediately
because it slows the free flow of ideas.
The quality of structuring information suffers because whenever solutions are combined,
some of the richness of the information is lost. In addition, DDCD is a human— based
structuring process, so it is subject to human error.
39
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The information models in DDCD do not contain all product and process knowledge
because conceptual design space is infinitely large. Therefore, the DDCD method of
comparing formal documents to information models can recall solutions that were
effective in previous designs but those solutions may not be feasible in the new design
task. In addition, those solutions may stifle innovation by leading designers along a path
that is not original (since the suggested solution is based on previous designs).
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4 0
5 Tools That Support Concept Generation And
Information Mangement
Few tools have been developed to support the conceptual design process because it is so
informal and ambiguous. There are two main requirements for a concept generation and
management tool. 1) The tool should assist designers to record and structure ideas in a
“freeform” manner. 2) The tool should provide design solutions to designers to drive the
information generating process in the right direction.
5.1 Existing Tools
Information management tools developed in other research programs have made some
contribution to assisting the conceptual design process. These tools help designers record
and organize design information but they do not structure the design and push design
solutions to the designer the way that DDCD does. Section 5.1 discusses the
functionality of some information management tools developed in other research
programs, and the commonalties and differences between these tools and DDCD.
5.1.1 vmacs
Vmacs [5.1] was designed specifically for the conceptual design process. It combines the
processing power of a computer with the freedom and agility of paper and pen. With
vmacs, designers have complete freedom to construct images which may start out looking
41
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
like one thing and end up being another. One of the key concepts of vmacs is to provide
the designer with the agility to do design quickly and easily. The basic principle is that
when a designer is inspired to create, any interference may stifle the flow of concepts.
Vmacs achieves text— graphic agility with a touch— typing interface that does not require
the designer to look away from the drawing at any time (because it may cut off the
development of ideas).
The concept behind the processing of visual images in vmacs is as follows. People in a
particular discipline tend to express their solutions is conventional drawings for that
discipline. For example, electrical engineers draw standard circuit diagrams consisting of
capacitors, resistors, etc..., and mechanical engineers use rigid body diagrams consisting
of pulleys, masses, springs, trusses, etc... Vmacs can recognize the design domain of a
collection of visual images and translate the visual images into a series of logical
statements which are used as input into an expert system.
The vmacs concepts used in DDCD are the freedom and agility of an electronic design
notebook and the processing of visual images. The part of DDCD not supported by
vmacs is a methodology for structuring design information and design solutions
generated by an information model.
4 2
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
5.1.2 Dynomite
Dynomite [5.2] is a portable electronic notebook that merges the flexibility of paper note-
-taking with the organizational capabilities of computers. The four main features of
Dynomite are the paper— like interface, indexing, document retrieval, and audio storage.
The paper— like interface attempts to match the ease of use of paper notebooks. Freeform
digital ink marks created sequentially are grouped together; the groups can be cut, pasted,
and moved around on a page. The audio recording feature is time stamped to allow the
audio record to be synchronized with pen strokes.
The Dynomite concepts included in DDCD are the paper— like interface, the ability to
group information, and the easy retrieval of documents. The DDCD concepts not
supported by Dynomite are document structuring and design solution generation.
5.1.3 AESOP
Authoring Environment for the Desktop (Aesop) [5.3] is based on the principle that an
author develops a vision of a document before constructing it. This vision is developed
by extracting useful segments from available resource materials and linking them
together.
Aesop provides two outlining tools to handle content development and organizing
43
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
requirements. One tool is used to develop a logical tree structure of a document
(describes the content of the document). The other tool is used to create and manipulate
viewing areas (organizes the document).
The parts of Aesop included in DDCD are document structuring and document
organizing. Aesop’s use of a logical tree structure inspired the development of the
DDCD configuration. The parts of DDCD not supported by Aesop are solution
generation and concept stimulation.
5.1.4 Xlibris
Xlibris [5.4] is a tool that was developed to support active reading. The premise behind
Xlibris is that computation can enhance active reading (critical thinking and learning).
Xlibris attempts to mimic the advantages of reading paper (tangibility; free— form ink
annotation, and page orientation) by providing a page-oriented display, document-like
navigation, and ink annotation.
Xlibris allows designers to mark up documents in a manner analogous to writing on
paper. The free form ink annotations later remind designers what information they were
previously interested in and what there comments were. Xlibris can also search for
material related to annotated text, and sort and filter documentation.
4 4
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The parts of Xlibris that were useful in the development of DDCD were the quick, easy,
and fluid recording capability and computation features that enable faster access to
information and design stimulation from previous note taking. The parts of DDCD not
supported by Xlibris are document structuring and solution generation.
5.1.5 C-DeSS
Collaborative Design Support System (C— DeSS) [5.5] is a web based tool that allows
design team members to collaboratively access and update design decisions and design
rationale. Design decisions and rationale are stored in a shared database using a semi-
formal representation. This data is accessed and updated by design team members using
graphical user interfaces on standard Web browsers.
The C— DeSS representation language captures designs using a vocabulary consisting of
entities as well as claims about entities. Claims can be made about the design, rationale
for design decisions, and reasons why a design rationale should be believed. There is
also an all-purpose text claim used to capture information that is not otherwise
expressible. The net result of describing designs and rationale in this way is a graph of
entity and text claim instances connected by relational claims.
There are several congruities between C— DeSS and DDCD. The idea of creating entities
is common to both methodologies. The idea of linking design rationale to entities is also
common to DDCD and C— DeSS. The main differences between DDCD and C— DeSS is
45
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
that C— DeSS does not emphasize the formalization of semiformal design information and
does not emphasize the conceptual design process. DDCD, on the other hand, attempts to
formalize the design information so that it can be compared with product models and
process models that were formulated specifically for the conceptual design process.
5.2 Comparison To DDCD
Some of the tools described above allow the user to record design information (vmacs,
dynomite, C— DeSS, Xlibris) and structure it (vmacs, dynomite, C— DeSS). However,
none of the design tools prescribe a structuring process for the purpose of knowledge
based interpretation. Vmacs interprets formal components within a domain but does not
specify a structuring process to generate those components.
C— DeSS, identifies entities and relationships (similar to entities and relationships in
DDCD) and claims about entities (similar to design rationale in DDCD). However, it
does not identify knowledge domains such as requirements, functions, working
principles, flow relationships, and geometric relationships.
Another weakness of the existing information management tools is that none of them
push design solutions to designers. Instead, they depend on the designers own initiative
to find solutions.
As indicated above, some design tools developed by other research programs fulfill
46
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
various design and information generating concepts called for by the DDCD
methodology. Table 5.1 summarizes which DDCD concepts are supported by these
design tools and which DDCD concepts are lacking in each tool.
Table 5.1: Design Tool Evaluation
Record Idea Structure Generate Stimulate
Document Solution Designer
vmacs
•/ ✓ ✓
Dynomite
V S
AESOP
S
Xlibris
C-DeSS
S
Creative Design
Panel
V S S
■f partially fulfills requirements S completely fulfills requirements
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4 7
6 Case Scenario-- Function Structure
Development O f A Water Sampler
In Chapter 6, the DDCD system is demonstrated with a case scenario. The design
problem chosen is the development of the function structure for a water sampler. The
systematic approach is used with the DDCD methodology to record and structure the
main functions of a water sampler. The system suggests a working principle to fulfill one
of the functions.
6.1 Problem Statement
Develop a function structure for a water sampler that has the following requirements. A
research worker in a row boat uses a water sampler to collect samples of water from
fresh— water lakes at known depths down to a maximum of 500 meters. After release, the
water sampler must not be attached to the boat, and must descend to within 10 meters of
an easily adjustable pre— determined depth. The water sampler should retrieve a 0.5 liter
water sample at the specified depth and return to the surface where is should float until
picked up.
6.2 Solving The Problem With A DDCD— Systematic Design
Approach
The overall function of this design problem is to retrieve underwater samples at various
48
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
depths. The main functions of the water sampler are “dispatch water sampler”, “collect
water”, and “return water sampler.” The main functions are decomposed into sub-
functions. In this example, the main function “collect water” is decomposed into four
sub— functions: “open water sampler”, “get water”, “detect if filled”, “close sampler”
(Figure 6.1).
C :\W atei_Sam plei_Function__S Iruclure
File D om ain Edit H elp
Functions ] Working Principles ';
G UIDELINES
----------------------- 3
— Function
should fulfill
demands from
the requirements
list.
— Function
should be
compatible with
the overall task.
-Function
should be general
enough so as not
to guide oneself
to a specific
solution.
U
CREATIVE DESIGN PANEL
1 : P a g e 2 ) P a g e 3 1 P ag e 4 [ Merge j V ariant)
; . t A
j (y'/v-k-
il,
V
Move
Valve
c
1 " S
C M .U . 1
“I
FMi>/ Ct*s£
it u
Define Object’ Relationship
IN ZOOM OUT
Input Rationale Com pare i
SYSTEMATIC APPROACH A AXIOMATIC APPROACH OH IER
. inlxl
.i ■
Figure 6.1: Water Sampler Function Structure Development
The system suggests working principles and design rationale when the designer presses
on the button “Compare with Existing Models.” For example, in this scenario (Figure
4 9
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.2), a working principle “Open Valve” is presented for the function “Open Sampler.”
The designer can get a detailed explanation of the working principle by clicking on the
hyperlink. The working principle provides stimulation for the designer to evaluate the
function structure and think of other possible working principles.
li:
File Dom ain
C :\W atef_ S am p lei_ F u n ctio n _ S tru ctu ie
Functions \ Working Principles j
GUIDELINES
3 P a g e 1 1 P a g e 2
-Function
should fulfill
demands from
the requirement
list.
-Function
should be
compatible with
the overall task.
— Function
should be general
enough so as not
to guide oneself
to a specific
solution.
j j
CREATIVE D ESIG N PANEL
P a g e 3 j P a g e 4 I M erge Variant:
Suggestion: Existing water is pushed out with a
valve letting in fresh water at a specific depth.
This method will let the water in fast. See
diagram below.
Water Existing
I— in z o o m our ll^ H
Define ObjectW elationship Input Rationale C om pare with Existing Models
SYSTEMATIC APPROACH AXIOMATIC APPROACH OTHER
Figure 6.2: Water Sampler: System Generated Solution And Design Rationale
50
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
7 Conclusions And Recommendations For
Future Work
This thesis has presented a methodology to manage conceptual design information.
First, the important information generating aspects of conceptual design were identified
and constructs for recording and structuring design information were described. Then, a
methodology for recording and structuring, and reusing design information was built
around these constructs.
The research contribution of this thesis is an explication of the information generating
process in conceptual design and a methodology that supports the information generating
process in conceptual design. Future work will focus on developing information models
that store design knowledge, extending the DDCD methodology to collaborative design,
and stimulating creativity in design.
7.1 Research Contributions
This research makes two main contributions:
i. An explication of the information generating process of conceptual design; and
ii. A method to support conceptual design by:
> assisting the recording and structuring processes;
> generating design solutions; and
51
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
> stimulating concept generation.
7.2 Future Work
The plan for future work is:
• develop the domain— specific product and process models
• extend DDCD to collaborative design; and
• develop methods to stimulate designers to be more creative.
7.2.1 Developing The Information Model
In the future, domain— specific product and process models will be further developed.
Methods will be developed to compare the information models with structured design
documents to generate design solutions. The KICAD research group is developing
intelligent agents that will be able to quickly access existing designs, load them into
product and process models, and analyze the design so that suggestions can be made to
designers based on their unique profiles (i.e. their design experience, design knowledge,
etc...).
7.2.2 Extending DDCD To Collaborative Design
In today’s world of advanced technology, most designs are collaborative. Design is more
sophisticated then it was in the past and requires designers that have specialized
52
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
expertise. The time to market for designs is constantly being reduced to keep up with
competition. These challenges must be met by expert designers collaborating as a team
to achieve a common goal.
Recent advancements in collaborative technology such as email and chat provide
opportunities for designers that are temporally and spatially dispersed to work together.
Collaboration between distributed team members separated by space and time has unique
problems. Co— workers are more likely to collaborate if they are in the same place.
Physical collocation enables the easy construction of shared contexts for problem solving,
negotiation, and information sharing. It also enables rich, multi-layered, and multi
modal interaction using speech, body movement, gesture, and intonation.
The technology that can enable dispersed collaborative design is still in the early
developmental stages. In one system called Design Map Maker, knowledge engineers
create links between design requirements and design notebook documentation. That way,
they can quickly review the entire project and use the links in the maps to retrieve
information that is more detailed.
The DDCD methodology described in this thesis has the potential to be used in a
collaborative design setting to facilitate communication between members of a design
team. As a starting point to see how DDCD can be used for collaborative design, a
matrix (Figure 7.1) has been created which shows the design spaces and design actions in
collaborative design. The boxes in the design matrix indicate design spaces such as
53
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
“single designers idea”, and “group of designers unstructured document.” The letters (a -
1 ) in the design matrix indicate coordination between various design domains.
Brainstorming (a) is a useful way to generate ideas. Designers propose ideas to a group
while a note taker records the ideas informally, thereby stimulating other designers to
think of new ideas.
Designers record their new ideas in an unstructured format (b) and structure the
information into a semi— structured format (c). The concept of brainstorming was created
with the assumption that designers would be co— located while brainstorming. Future
research should concentrate on figuring out how the benefits of a brainstorming session
can be implemented in a virtual world; i.e. a media should be created to mimic the
benefits of a co— located brainstorming session.
In future research, the concept of “knowledge engineer” will be further investigated. A
knowledge engineer could be responsible for assigning relationships between functions
and solutions from different domains. The knowledge engineer would then create a map
of the relationships so that an individual designer could be aware of the interactions
between his or her work and the work of other designers (d). This raises the question:
“what information and experience does a knowledge engineer need in order to link
entities in different domains?”
If designers can navigate through a design map to find dependencies, they will be able to
54
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
avoid conflicts, and be more confident as they proceed through the structuring process
(e).
Formal design documents can be merged to form the groups formal documents (f); i.e.
the completed design. In collaborative design, there could be two ways of generating
product models and process models. The group’s product/process models could be
generated from a group document (g) or from individual designer’s documents (h), and
later combined into a group information model (i). Future research into product/process
models will reveal which method is most appropriate.
Regardless of which forum is used to merge the information, conflicts will arise between
designers. Future research should concentrate on identifying these conflicts and
developing methods for conflict resolution.
Once the group’s information model is generate, it can be compared with the generic
information model to generate solution documents (k) for each designer telling them how
they can improve their design. A solution document that is generated for the group (j)
would make general statements about conflicts between designers. The group’s solution
document would be useful for keeping the knowledge engineers and managers up to date.
Individual solution documents would be useful for helping designers generate new ideas
(1). The issues surrounding the collaborative design actions outlined above will be
addressed more in the future.
55
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
(Belongs To)
Single Group of
Designer Designers
Idea
1
Unstructured
Document
b
f
Semi-
Structured
Document
c
u
d ► w
Structured
e
r
f
Document
w
Information
h
r 1 j
g
r
Model
i
Solution
Document
1
j
r
Figure 7.1: CDDCD Design Matrix
7.2.3 Stimulating Creativity In Design
Creativity is the development of innovative and valuable ideas. In science, creativity
leads to scientific discoveries that change our view of the world. In engineering,
creativity leads to inventions that change the way people live in the world.
56
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
As design tools become more sophisticated at automating routine tasks, an important
question has come to the fore: how can we improve creativity in the design?
A model of design processing mediums is presented in Figure 7.2 to show why designers
have more opportunities to be creative then they did in the past. The three design
processing mediums are short-term biological memory, long-term biological memory,
and documentation. Short-term memory can only process about seven chunks of
information thereby limiting a designer’s creativity. However, with DDCD facilitating
knowledge management, storage and retrieval; and intelligent agents monitoring the
design process, the short term memory is free to spend more time on creative thinking.
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
57
Limited Capacity
(7 +/— 2 chunks o f info.)
Short Term Memory
Intelligent
Agent
Creative Thinking
Process Monitoring
Knowledge Development
Knowledge Storage
Knowledge Retrieval
Unlimited
Capacity
Long Term Memory
General Knowledge
Domain— Specific Knowledge
Procedural Knowledge
DDCD
Unlimited
Capacity
Documentation
Domain— Specific Knowledge
Procedural Knowledge
Figure 7.2: Design Processing Mediums
Creative design mechanisms are the psychological processes that generate innovative and
valuable design concepts/solutions. Three important mechanisms for generating creative
ideas are: analogy, mutation, and instantiation. Analogies relate new problems to past
58
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
experiences. Mutation changes features or attributes of an entity in an unconventional
manner to find new properties and new functions. Instantiation is the process of
generating specific design solutions from concept— level solutions.
Creative design mechanisms are used quite often during the conceptual design process.
The designer makes analogies between information in the knowledge base and the current
design, mutates information in the knowledge base to generate new ideas, and instantiates
design concepts to develop design solutions (Figure 7.3).
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
59
Creative Design Mechanisms
Analogy Mutation
Instantiation
j
r
a
\r
u
KB
DDCD
ss
S'
A a m 1
A
a Ft 1
< t
& © EJ
i & a
----- © ej a
—
Long-Term Memory,
Documentation
iu A H ®
A ■ ■ < § > © Ei
c -V @
Figure 7.3: Creative Design Mechanisms
Future work on creativity will focus on understanding and using the creative design
mechanisims to enhance creativity in design. Four main objectives have been identified
for this creative design research. First, develop a taxonomy of terms for creativity in
60
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
design. Second, model creative processes in design. Third, develop methodologies to
stimulating creativity in design. Fourth, develop a prototype system to stimulate
creativity in design.
61
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
BIBLIOGRAPHY
[1.1] Ullman, David G., book. The Mechanical Design Process. New York: McGraw-
Hill, 1997.
[1.2] Stahovich, Thomas F. Working Paper. "Interpreting the Engineer's Sketch: A
Picture is Worth a Thousand Constraints."
Http://www.me.cmu.edu/facultvl/stahovich/stahovich.html: CMU Mechanical
Engineering Department, 1996.
[1.3] Klein, Mark. "Capturing Design Rationale in Concurrent Engineering Teams.,"
IEEE Computer. January, 1993.
[1.4] Miller, G. A. "The Magical Number Seven, Plus or Minus Two: Some Limits on
Our Capacity for Processing Information." Psychological Review 63 (1956): 81—
97.
[1.5] Jin, Yan and Lu, Stephen. "Towards a Better Understanding of Engineering."
Universal Design Theory, Grabowski H., Rude S., Grein H. Germany, 1998.
[2.1] Pahl, P.G. and Beitz, W. Engineering Design A Systematic Approach. Great
Britain: Springer, 1996.
[2.2] Impact o f Axiomatic Design. By Suh, Nam P., Chairman. Tokyo, Japan, CIRP
Design Workshop. 1996.
[2.3] Schilit, Bill, N. and Golovchinsky, Gene and Price, Morgan, N. "Beyond Paper:
Supporting Active Reading with Free Form Digital Ink Annotations."
Proceedings o f CHI 98, 1998.
Http://www.fxpal.xerox.com/maior publications.htm.
[5.1] Lakin, Fred. "The Electronic Design Notebook: Performing Medium and
Processing Medium." The Visual Computer 5 (1989): 214-226.
[5.2] Shilit, Bill N., and Wilcox, Lynn, and Nitin, Sawhney. "Scenes From a
Demonstration: Merging the Benefits of Paper Notebooks with Teh Power of
Computers in Dynomite.," FX Palo Alto Laboratory, Working Paper. 1998.
Http://www.fxpal.xerox.com/maior publications.htm.
[5.3] Shimizu, Takeshi and Smoliar, Stephen W. and Boreczky, John. "AESOP: An
Outline-Oriented Authoring System.," FX Palo Alto Research Laboratory, Inc.,
Working Paper. 1998. Http://www.fxpal.xerox.com/maior publications.htm.
62
R eproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[5.4] Kusiak, A., and Larson, N. "Decomposition and Representation Methods in
Mechanical Design." Special 50th Anniversary Design Issue 117 (1995): 17-24.
[5.5] Klein, Mark. "Capturing Geometry Rationale for Collaborative Design." Wetice,
1997. Http://ccs.mit.edu/klein/wetice97/.
63
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

A cognitive approach to creative conceptual design

PDF

A hierarchical co-evolutionary approach to conceptual design

PDF

A work structure based approach to collaborative engineering design

PDF

An analytical approach to functional design

PDF

Cognitive modeling of iteration in conceptual design

PDF

A socio-technical approach to support collaborative engineering design

PDF

Automotive engine model linearization

PDF

A framework for value -based conceptual engineering design

PDF

General and explicit equations of motion for mechanical systems

PDF

Investigation of a switching G mechanism for MEMS applications

PDF

Investigation of several important phenomena associated with the development of Knudsen compressors

PDF

Thermally-driven angular rate sensors in standard CMOS

PDF

Design-for-reliability starting from conceptual design

PDF

A study on relative permeabilities in three-phase flow in porous media

PDF

Destructive and non-destructive approaches for quantifying the effects of a collagen cross-linking reagent on the fatigue resistance of human intervertebral disc

PDF

Design tradeoffs in a packet-switched network on chip architecture

PDF

Interactive C++ program to generate plank system lines for timber rib shell structures

PDF

Collaborative negotiation for early stage parametric design of mechanical systems

PDF

Effect of spark kernel dynamics on laser-induced minimum ignition energies of combustible gases

PDF

Experimental demonstration of techniques to improve system performance in fiber -optic communication systems using subcarrier -multiplexed and digital baseband signals

Asset Metadata

Creator Benami, Oren (author)

Core Title A document-driven approach to conceptual design

Contributor Digitized by ProQuest (provenance)

School School of Engineering

Degree Master of Science

Degree Program Mechanical Engineering

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag engineering, mechanical,OAI-PMH Harvest

Language English

Advisor Jin, Yan (committee chair), Kaplan, Richard (committee member), Shiflett, Geoffrey (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c16-44541

Unique identifier UC11327453

Identifier 1427988.pdf (filename),usctheses-c16-44541 (legacy record id)

Legacy Identifier 1427988.pdf

Dmrecord 44541

Document Type Thesis

Rights Benami, Oren

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA