DESIGNING DESIGN PROCESSES
IN DECISION-BASED
CONCURRENT ENGINEERING
BERT BRAS
RESEARCH ASSOCIATE
SYSTEMS DESIGN LABORATORY
DEPARTMENT OF MECHANICAL ENGINEERING
UNIVERSITY OF HOUSTON
HOUSTON, TEXAS 77204-4792, USA
ABSTRACT
We believe that the efficiency and effectiveness of
human designers can be improved by making
available tools that can be used to help negotiate
solutions to open or unstructured parts of the
process of designing. We assert that the efficiency
and effectiveness of a designer can be increased by
increasing the speed with which the design
iteration is accomplished and reducing of the
number of iterations. An increment in the iteration
speed can be achieved if at least some parts of a
design process are known and can be modelled on
a computer. One way of reducing the number of
iterations in design is by avoiding this corrective
redesign. This provides the stimulus for
developing approaches to design that include
Concurrent Engineering considerations. Thus, in
our opinion, a necessary ingredient in increasing
efficiency and effectiveness of human designers is
the modeling of design processes in a manner that
they can be analyzed, manipulated and
implemented. This is the central theme of our
paper.
OUR FRAME OF REFERENCE
PROBLEM IDENTIFICATION - Often
flaws in the solution of a design problem are
detected during manufacture and even
maintenance. The corrective redesign effort is
usually extremely expensive and ideally should be
Bras, B. A. and Mistree, F., "Designing Design Processes in Decision-Based Concurrent Engineering," SAE Transactions, Journal
of Materials & Manufacturing, vol. 100, pp. 451-458, 1991.
© Copyright 1991 SAE International, Warrendale, Pennsylvania.
FARROKH MISTREE
PROFESSOR
have been “designed out” prior to manufacture.
The effort to reduce such costly iterations has
provided the stimulus for developing approaches
to design that include life cycle considerations
(that is, design, manufacture and support).
Approaches to design that incorporate life cycle
considerations include Concurrent Engineering [1-
3]*, simultaneous engineering, Unified Life Cycle
Engineering (ULCE) [4-7], producibility
engineering [8]. Companies that have made use of
some of these approaches have reported
impressive benefits [3].
Our primary interest is in developing the
capabilities for a team of human designers to
design concurrently in the early stages of project
initiation. Why? Dierolf and Richter in the
conclusion of a recent study for the Institute of
Defense Analysis state [6]:
“The importance of early design decisions is
widely recognized. It is often stated that
roughly 70 percent of the total life cycle cost of
the system is determined during the conceptual
phase. Due to the lack of hard data, very few
traditional CAD tools are available to support
the early stages of design. Considering the high
leverage of the decisions made during these
stages, this is an undesirable situation.”
* Numbers in parentheses designate references at end of
paper.
* Numbers in parentheses designate references at end of
paper.
Page 1

In their comprehensive review of the research in
mechanical engineering design Finger and Dixon
state [9,10]:
“An important area that has received little
attention to date is the creation of design
environments that integrate available tools into
a consistent system to support the designer.”
The significance of the need for a computer-based
design environment to support the activities of
designers in the early stages of design is clear from
the preceding quotation. Our research and
development efforts are directed towards
developing a decision-based design environment
for Concurrent Engineering; an environment that
is geared towards increasing the efficiency* and
effectiveness** of a team of designers designing
concurrently in the early stages of project
initiation.
OUR APPROACH - At the Second
National Symposium on Concurrent Engineering
we described a conceptual model for decision-
based Concurrent Engineering Design for the life
cycle [1]. We offered Decision-Based Design
(DBD) as a starting point for the creation of
design methods that are based on the notion that
the principal role of an engineer, in the design of
an artifact, is to make decisions. We recognized
that the implementation of DBD can take many
forms; our implementation, at the University of
Houston, is the Decision Support Problem (DSP)
Technique. It is being developed and implemented
to provide support for human judgment in
designing systems that can be manufactured and
maintained. We indicated that our approach to
engineering design is embodied in the DSP
Technique and the principal support support for
human designers is provided through the
formulation and solution of Decision Support
Problems (DSPs). The software to solve DSPs on
* We consider efficiency to be a measure of the swiftness
with which information, that can be used by a designer
to make a decision, is generated.
** We consider effectiveness to be a measure of quality of
a decision (correctness, completeness, com-
prehensiveness) that is made by a designer.
the computer is called DSIDES (Decision Support
in the Design of Engineering Systems) [11].
Details about the mathematical structure of the
DSPs and the corresponding data structure in the
DSPT Workbook are presented in [12,13].
Independently of the approaches or
methods used to plan, establish goals and model
systems, designers are, and will continue to be
involved in two primary activities, namely,
processing symbols and making decisions.
Therefore, we assert that the process of design, in
its most basic sense, is a series of decisions. By
focusing upon decisions, we have a description of
the processes written in a common “language” for
teams from the various disciplines -- a language
that can be used in the process of designing.
We believe that the efficiency and
effectiveness of a human designer can be improved
by making available tools that can be used to help
negotiate a solution to the open or unstructured
parts of the process of designing. We assert that
the efficiency and effectiveness of a designer can
be increased by:
• increasing the speed with which the design
iteration is accomplished, and
•reducing of the number of iterations.
An increment in the iteration speed can be
achieved if at least some parts of a design process
are known and can be modelled on a computer.
One way of reducing the number of iterations in
design is by avoiding this corrective redesign.
This provides the stimulus for developing
approaches to design that include Concurrent
Engineering considerations. Thus, in our opinion,
a necessary ingredient in increasing efficiency and
effectiveness of human designers is the modeling
of design processes in a manner that they can be
analyzed, manipulated and implemented.
Our formal definition of the term designing
is as follows [14,15]:
Designing is a process of converting
information that characterizes the needs and
requirements for a product into knowledge
about a product.
B. A. Bras and F. Mistree
Page 2
 The DSP Technique consists of two
phases, namely, a meta-design phase (Phase I) and
a design phase (Phase II). During meta-design,
the product-specific decisions themselves are not
made or even pursued, but the design process to
be implemented in Phase II is itself designed. In
Phase II, a solution to the design process is sought
and validated. The implementation of the DSP
Technique on the computer is called the DSPT
Workbook. It embodies tools that can be used by
designers to implement both phases of the DSP
Technique. Different features of the DSPT
Workbook are described in [13,16,17].
At present, much of our effort is directed
towards developing tools that can be used in meta-
design. Our aim is to develop software tools that
help designers create models of design processes
that are appropriate for Concurrent Engineering
are particularly important. The essence of our
approach is as follows:
• Let a designer specify a model of his/her
design process explicitly (by entering) and/or
implicitly (by allowing a computer to monitor).
• Classify all information into certain basic
entities (e.g., phases, events, decisions, tasks,
systems, goals) and consider all information as
relationships with an input and an output. Use
the entities to build networks which model
design processes and are represented in a form
suitable for manipulation.
In the DSP Technique the process of design is
modeled using entities, for example, phases,
events, decisions, tasks and the like. The set of
basic entities used to model a design time-line is
called the DSPT Palette [18]. A designer working
within the DSP Technique has the freedom to use
submodels of a design process (prescriptive
models) created and stored by others and to create
models (descriptive models) of the intended plan
of action using the aforementioned entities. These
descriptions along a time-line are used as
prescriptions in implementing the design process.
OUR FOCUS IN THIS PAPER - We
believe one's ability to represent design processes
on a computer in a form that can be manipulated is
important. This facilitates analysis and debugging
of the processes before implementation. More
importantly, it facilitates improvement by finding
and eliminating redundancies, inconsistencies, and
detecting (sub)processes that are independent of
each other and can therefore be implemented
concurrently. In this paper we focus on designing
design processes. Specifically, we focus on
answering two questions:
• How can design processes be modeled on a
computer?
• How can computer models of design processes
be “designed” to suit our needs, namely,
Concurrent Engineering?
MODELING DESIGN PROCESSES
Two different classes of models of the
design process have been proposed, namely,
prescriptive and descriptive models [18,19]. The
principle underlying prescriptive models is to
persuade or encourage designers to adopt a
particular way of designing. Many prescriptive
models have been developed and proposed over
the years. Descriptive models embody sequences
of activities that typically occur in a design
process. These models exemplify how design is
done and not what should be done to arrive at a
solution. However, there is no generally accepted
unique model of the engineering design process.
Andreasen [20] reflects on some of the problems
of applying such models in practice. De Boer [21]
also alerts us to the reluctance of designers in
industry to accept (prescriptive) models of design
processes.
It is questionable whether processes used
for designing complex systems such as ships and
aircraft can be described by one single information
form, e.g., rules or optimization models.
Numerous attempts have (unfortunately) been
made to fit the process of design into a particular
mode of representing information, for example,
production rules. However, the information
needed by a designer within any design process is
usually provided in different forms, for example, a
computer program, knowledge base, rule, neural
network, mathematical programming formulation,
a simple formula, raw data, program output,
natural language, etc. Therefore, we contend that
any information management system developed for
B. A. Bras and F. Mistree
Page 3
 INCREASING QUALITATIVE RATIO OF HARD TO SOFT INFORMATION

T DECISION SUPPORT AUTOMATION

O Ideation, CAD,
O Artist's conception, Solid modelling,
L Selection, Tolerances,
S Compromise, Manufacturing processes,
Rapid prototyping. Costing.
P
H
A Designing for Designing for
S Concept Manufacture
E
S

E Economic Detailed Detailed Processes

V Viability Analysis Drawings for Serial
E (costing, Manufacture
N manufacturability,
T Conceptual etc.) Prototype
Testing
S
Preliminary Dimensional
Synthesis Synthesis
(includes
tolerancing)
Fig. 1 -- A Typical Design Time-Line: An Example Incorporating Designing for Concept and
Designing for Manufacture

design must be capable of supporting the storage
and processing of various types of information.
One promising approach is documented in [22].
We subscribe to the notion that the
principal function of an engineer in general and a
design engineer in particular is to make decisions.
In Decision-Based Design we expect decision-
based models of design processes to take on
different forms to accommodate design of all types
of systems*; designs that are characterized by
information from multiple disciplines, different
types of designs, and different events in the life
cycle. In effect, our primary design process model
(i.e., the DSP Technique), considered as a system,
is open to its environment and we expect it to
evolve with time. To facilitate this, our thrust is to
make available tools (analogous to the palette of a
* Definition: A system is a grouping of associated
entities which is characterized by a mental construct;
one of the associated entities is the boundary, Mistree
et al. [18].
painter) that a human designer can use to describe
a design time-line. These descriptions along a
time-line are used as prescriptions in a new design
process. By giving designers the lead role in
model development, we believe, it will ensure
continuous feedback that can be used to improve
the tools themselves.
MODELING A TIME-LINE FOR
DESIGN - Let us consider the life cycle of a large
system, for example, a ship. A ship’s life cycle is
delimited by the decision to create a design to
satisfy a set of specifications and the ship's
disposal. Thus a ship's life cycle has a beginning
and an end with certain characteristic events
occurring at approximately predictable points
along a time-line, for example, launching, refitting,
etc. One way of assessing the passage of time is in
terms of these events. For example, the passage of
time could be related to the number of voyages
taken, the extent of corrosion of the hull, or the
obsolescence of the fittings. This is defined as

B. A. Bras and F. Mistree

Page 4
event-based time [18]. On the other hand,
physical time is measured in years, days and hours.
While event-based time bears some relationship to
physical time, it need not be linearly related. Time
in a design process may be modeled using event-
based time rather than physical time.
In the context of our definition of
designing, for an engineering system, the
conversion of information into knowledge is
invariably accomplished in stages. In the
traditional design process names have been given
to the stages. These stages are frequently called
feasibility, conceptual, preliminary and detail
design. From the standpoint of the information
necessary for making decisions in each of the
stages their name and number are not important.
What is important is that:
• the types of decisions being made (e.g.,
selection and compromise) are the same in all
stages, and
• the quantity of hard information (relative to
soft information) increases as the knowledge
about the product increases.
In the DSP Technique the qualitative ratio of hard-
to-soft information available at any time along a
time-line is a key factor in determining the nature
of the support that a human designer needs as
he/she negotiates a satisficing* solution to a design
problem (see Fig. 1). We assert that it is possible,
based on this qualitative relationship to define any
of the processes in design in terms of phases (e.g.,
designing for concept and designing for
manufacture) and events (e.g., economic viability,
preliminary synthesis, detailed analysis).
By way of example, a simplified time-line
for original design* is illustrated in Fig. 1. In the
* being phases, events, tasks, decisions and systems.
Satisficing - not the “best” but “good enough” (use of
this term, in the context of optimization, is first
attributed to Herbert Simon [23])
* Original Design - an original solution principle is
determined for a desired system and used to create the
design of a product.
Adaptive Design - an existing design is adapted to
different conditions or tasks; thus, the solution
principle remains the same but the product will be
sufficiently different so that it can meet the changed
tasks that have been specified.
designing for concept phase we seek to cast as
wide a net as practicable to generate as many
concepts as possible and then to home in
systematically on a concept that satisfies the
functional specifications and which also can be
produced and maintained. In other words, in
designing for concept we are involved in the
process of converting information that
characterizes the needs and requirements for a
product into specific knowledge that can be used
in designing for manufacture and maintenance. In
the designing for manufacture phase we seek to
ensure that the product can be manufactured cost-
effectively. We recognize that in practice iteration
between events (and phases) will occur; however,
such an eventuality is not explicitly shown in Fig.
1.
THE DSPT PALETTE FOR MODELING
DESIGN PROCESSES - The DSPT Palette
contains the entities for modeling processes.
These entities are used to build hierarchies and
model design processes independent of the domain
of application. The DSPT Palette contains three
different classes of entities, namely, Potential
Support Problem entities, Base entities and
Transmission entities (see Fig. 2).
DSPT Palette Entities
Potential Base Transmission
Support Problem Entities Entities
Entities
Fig. 2 -- DSPT Palette Entity Classes
The most complex entities in the DSPT
Palette are the Potential Support Problem entities,
The icons for these entities are shown in Fig. 3.
Variant Design - the size and/or arrangement of parts
or subsystems of the chosen system are varied. The
desired tasks and solution principle are not changed.
B. A. Bras and F. Mistree
Page 5

P Phase
E Event
T Task
? Decision...
System
Compromise
? Decision
Selection
? Decision
?
Preliminary
Selection Decision
Heuristic
? Decision
Fig. 3 -- Potential Support Problem Entities
The phase icon is identified by a “P” and is
used to represent pieces of a partitioned process.
In Fig. 1 two phases, namely, “Designing for
Concept” and “Designing for Manufacture”, are
indicated. Events occur within a phase and the
event icon is identified by an “E”. Tasks and
decisions are used to model phases and events.
Tasks and decisions require direct involvement of
human designers and/or systems. This, in contrast
with phases and events on which human designers
do not have direct influence. Phases and events
are accomplished by performing tasks and making
decisions. A task is an activity to be
accomplished. The design process itself is a task
for the design team, namely, “design a suitable
product”. A task itself may contain other tasks
and decisions, even phases and events, as in the
design task. However, simple tasks like “run
computer program A” do not involve decisions.
In our palette a task is identified by a “T”.
A decision icon is defined by a rectangle
with a question mark within it. This choice is
natural as a question mark often connotates a call
for a decision. Currently we have included the
compromise, selection, preliminary selection and
heuristic decisions in the palette. The
corresponding icons are a combination of the basic
decision icon with some further symbolism [18].
In the DSP Technique,
• selection is the process of making a choice
between a number of possibilities taking into
account a number of measures of merit or
attributes.
• compromise is the process of determining the
“right” values (or combination) of design
variables, such that, the system being designed
is feasible with respect to constraints and
system performance is maximized.
Selection is a converging activity since the number
of alternatives is reduced. The icons for both
selection and preliminary selection characterize
this in our palette. The selection decision icon has
a single point, indicating that on solving a selection
decision a single alternative is identified for further
development. The preliminary selection icon is
similar but it does not end with a point indicating
that on making a preliminary selection decision a
number of most-likely-to-succeed concepts are
identified for further development. The icon for a
compromise decision ends in a “C”. A
compromise represents a trade-off between
conflicting goals. When there is no conflict
between the goals the solution could be
represented by the upper or lower extremes of the
C in the rectangle. However, when there is a
conflict, which invariably is the case, the result
emerges from the middle; it represents a
compromise between two extremes. The heuristic
decision [24] is, roughly speaking, a combination
of a preliminary selection and compromise
decision. This is represented by the lines
converging in a “C”. However, the solution
process for a heuristic decision differs from the
compromise and selection DSPs and involves
reasoning.
A system can be either concrete (e.g., a
ship, an airplane) or abstract (e.g., a company’s
organization) and can be modeled by a grouping of
associated subsystems. Accordingly, a process is a
system as are, potentially, the higher-level entities
used to model the process. A system is identified
by a circle with a smaller circle in the middle. This
illustrates the central nature of a system in the
process. The fact that other systems and their
B. A. Bras and F. Mistree
Page 6
associated information are embedded in the system denoting the auxiliary nature and possible
and is symbolized by the small circle. embodiment of multiple dimensions.
Base entities are the most elementary Relationships are often considered as
entities for modeling design processes. Base “black boxes”, therefore, our representation of
entities are implementable on a computer and/or relationships as rectangles. All icons having a
easy to understand by designers. The icons for the rectangular shape are relationships. Phases,
Base entities are shown in Fig. 4. events, tasks and decisions are also relationships.
Analytical relationships are divided in
System equality relationships (e.g., force = mass *
Variable
acceleration), assignments (e.g., i := i + 1) and
Auxiliary
a Parameter functions (e.g., the trigonometric functions, sine
Analytical and cosine). Note that we use an assignment sign
Relationship... that is similar to the one used in some
? Conditional
Relationship...
programming languages (e.g., Pascal). We could
Limiting
have used merely an equality sign, but this
Relationship... distinction eases the classification of assignments.
The icons for the analytical relationship entities are
= Equality
? Rule Goal... self explanatory.
Relationship
Conditional relationships are
:= Assignment ? Loop Constraint... IF..THEN..ELSE rules and WHILE..DO loops. A
Bound...
characteristic of this type of relationship is that a
f(x) Function
condition has to be satisfied before a decision
(indicated by the question mark) can be made on
= = = Equality how to proceed. The icons indicate different
Greater Than
routes depending on the outcome of the decision.
> > > Inequality A loop icon models comments and a rule icon a
• • • Greater Than or Equal To junction.
Inequality
An icon consisting of a nozzle embedded
Less Than
< < < Inequality within a rectangle represents a limiting relationship
Less Than or Equal To (e.g., length / beam = c). The nozzle is symbolic
Š Š Š Inequality
of the restrictive nature of these relationships.
<> <> <> Inequality Limiting relationships are grouped as goals,
constraints, bounds. The goals, constraints and
bounds represent the aspirations, requirements and
limits imposed respectively. Constraints and
Fig. 4 -- Base Entities bounds describe the feasible design space (the
space representing all feasible solutions) and the
System variables (e.g., a ship’s length, goals define the aspiration space. The hard
beam and depth, etc.) are embedded in systems. nature of constraints and bounds is categorized by
The icon for a system variable is a small circle the black filling representing the region of
showing its atom-like character and that no lower infeasibility. Bounds embed a circle indicating the
hierarchical level is possible. icon of a variable. Note that we have also icons
Auxiliary parameters are parameters that embedding the sign of the limiting relationship in
are required for modeling a process, but cannot be the DSPT Palette. However, a designer modeling
categorized as system variables. Counters in loops his/her process will never select these icons,
are an example. Auxiliary parameters can be because the expression he/she enters for the
multi-dimensional (i.e., matrices) whereas system limiting relationship uniquely defines the sign;
variables are always scalars. Its icon is similar to a these icons are included for representing a design
system variable icon, but it embeds an “a” process network graphically.

B. A. Bras and F. Mistree

Page 7
 In our work we have been influenced by
Miller’s Living Systems Theory [25]. Like Miller,
we use Transmission entities to achieve the
connections between the aforementioned entities.
With the exception of system variables and scalar
auxiliary parameters all entities require an input
and provide some output. The Transmission
entities capture these inputs and outputs. Like
Miller and others (e.g., [26-28]) we distinguish
three types of transmissions, namely, information,
energy, matter, and combinations of these three
basic transmissions. Our icons for the
Transmission entities are shown in Fig. 5.
A Transmission entity usually embeds a list
of other DSPT Palette entities that are transmitted
from one entity to another. For instance the task
“Provide the goals and constraints” would have an
information Transmission entity as output
embodying a list of constraint and goal entities
representing the specific output of the task.
i Information
Energy
Matter
Information+
i Energy
Information+
i Matter
Energy+
Matter
Information+
i Energy+
Matter
Fig. 5 -- Transmission Entities
BUILDING PROCESS NETWORKS - A
uniform representation scheme for the DSPT
Palette entities is developed by recognizing that all
entities, with the exception of system variables,
scalar auxiliary parameters (a multi-dimensional
parameter which requires indices as input) and
Transmission entities convert some input into an
output. In the context of our definition of
designing, these entities convert information into
knowledge. Thus, in their most abstract form
these entities are relationships with an input and an
output. This view facilitates the combination of
different types of entities into networks, that is,
into hierarchies. These hierarchies represent the
information and knowledge held and generated at
different levels of complexity. An example of this
is the combination of subroutines into a
FORTRAN program.
AN ILLUSTRATIVE EXAMPLE - In this
section we illustrate the use of the DSPT Palette
using the design of a frigate as an example. In Fig.
6 a portion of the time-line of the life cycle of a
frigate is shown. From left to right, the qualitative
relationship between hard and soft information
increases. The design phases, events and product-
specific information are included. The
“storybook” on the bottom line represents the
strategic need, various concepts, the selected basic
concept, the preliminary design, the contract
negotiations, the manufacturing, the finished ship,
the ship after the half-life refit and the
decommissioned ship. The design process shown
in Fig. 6 is partitioned into four major design
phases for this example. Typically, the end of each
phase is not abrupt and it is often difficult to see
when a new phase starts. Therefore, the phases in
Fig. 6 overlap each other. Within these phases we
identify a number of events. Events are not
restricted to one phase. For instance the
preliminary design event is found in designing for
concept, manufacture and maintenance. The
horizontal bars in Fig. 6 provide an indication of
the duration, in physical time, of phases and
events. Input to the design process is a strategic
need or foreign policy, and as the design of the
frigate progresses, more and more hard
information (e.g., drawings, documentation)
becomes available. Thus, the qualitative ratio of
hard to soft information is seen to increase as the
time-line is traversed from left to right.
The icons from the DSPT Palette are now
used to model the time-line shown in Fig. 6. In
Fig. 7 the top level model is given. This model
consists of four overlapping phases (Designing for
Concept, Designing for Manufacture, Designing
for Maintenance and Designing for Improvement)
and the input and output information (the strategic
need and the total life cycle design knowledge). In
a computer desk-top environment a designer is
B. A. Bras and F. Mistree
Page 8
 P DESIGNING FOR CONCEPT
DESIGNING FOR MANUFACTURE
DESIGN DESIGNING FOR MAINTENANCE
PHASES DESIGNING FOR IMPROVEMENT

Development of Naval Staff Requirements (NSR)

E Conceptual Design
Preliminary Design
EVENTS Contract Design
Tender Evaluation
Contract Negotiations
Detail Design
Construction
Launching
Trials
Commissioning
Post Design
Intermediate Dockings
Half Life Refit
Decommissioning
Disposal

Strategic Need / Foreign Policy

i Statement of Requirements
Basic Concept (product of Conceptual Design)
PRODUCT Top Level Specification (product of Preliminary Design)
SPECIFIC Ship Characteristics (product of Preliminary Design)
INFORMATION Detailed Ship Design and Construction Specification (product of Contract Design)
Contract Guidance Drawings (products of Contract Design)
Construction Work Packages (products of Detail Design)
Maintenance Documentation
Operational Documentation
Test and Trial Reports
Service Life History

SHIP
YARD
Commissioning Refit Scrap

INCREASING QUALITATIVE RATIO OF HARD TO SOFT INFORMATION

Fig. 6 -- Time-Line for Designing a Frigate (see [18])

able to “open” the lower level model embodied in
a particular entity by clicking on its icon. By way
of example we have opened the phase icon for
The first event is the development of the
Naval Staff Requirements that results in a
document. This document plus general design
information forms the input for the conceptual
design event that feeds forward a basic concept
while initiating a feedback loop to the
development of the naval staff requirement event.
The basic concept and the general design
knowledge provide the necessary information for
the preliminary and contract design events. Note
Designing for Concept in Fig. 7. Now the events
that constitute this phase are visible.
that again an overlap between these two events
occurs. The preliminary design event provides the
top level specification and the ship characteristics,
whereas the contract design event provides the
general specification and the guidance drawings.
For a closer look at the conceptual design
event we click on its icon and the opened model of
this event is given in Fig. 8. The primary goal of
the conceptual design event is to establish the
basic concept. Therefore, concepts have to be

B. A. Bras and F. Mistree

Page 9
generated from general design knowledge. A
preliminary selection decision is to be made to
identify the most suitable concepts for further
development. This is to be followed by making a
compromise decision to improve these concepts
through modification. Finally, a selection decision
is to be made to identify the basic concept.
Attributes are needed for both the preliminary
selection and the selection decisions. Therefore, a
task is introduced in the model for determining the
most influential attributes from the Naval Staff
Requirements. For
B. A. Bras and F. Mistree
Page 10
 the compromise decision we need to know the
areas to be improved and what the goals and
Strategic Need/ constraints are. The goals and constraints are
Foreign Policy
i P
P extracted from the Naval Staff Requirements. The
P
P i Total Life Cycle task of finding the areas of possible improvement
Design Knowledge
depend on the concept to be improved and the
DESIGNING general design knowledge. After having improved
FOR CONCEPT the concepts, the basic concept is selected. In the
Concept(s) model, concurrency can be detected easily. The
Information
Top
tasks of determining the influencing attributes,
i
i Level
Specification
extracting the goals and constraints from the Naval
Strategic Need/ Preliminary Ship Staff Requirements and the generation of concepts
i Characteristics
Foreign Policy NSR Design can be performed simultaneously. Also, the task
i E i E i E
Development Conceptual Basic
E of extracting goals and constraints and the task of
of NSR Design Concept Contract
Design
General
i Specification determining the areas for potential improvement
Contract can be performed concurrently.
i
i Guidance
Drawings
So far we have shown how a design
General Design process can be modeled as a network of entities.
Knowledge
However, only the Base entities can be directly
implemented and understood by a computer. If
Fig. 7 -- A Model of the Designing for Concept
we want a computer to be able to evaluate a
Phase (Adapted from [18])
design process, then it is necessary for us to model
phases, events, tasks, decisions and systems in the
form of Base entities. How do we model phases,
Conceptual
events, tasks, decisions and systems in Base
Basic
Design Concept entities? By means of Support Problems.
E i

MODELING PHASES, EVENTS, TASKS,

DECISIONS AND SYSTEMS AS SUPPORT
Extract Goals
PROBLEMS
NSR and Constraints
i T
In this section we introduce the notion of
Goals and
Support Problems (SPs). Support for humans
Attributes i
Determine
Influencing T i
Constraints using the DSP Technique is provided through
Attributes solutions to Support Problems, especially Decision
Suitable Support Problems.
Concepts Concepts
Not all entities in the DSPT Palette are
i ? i ? i ? i
Improved Basic
associated with Support Problems. Only phases,
Concepts Concept events, tasks, decisions and systems have Support
Generate Measures of
Problems associated with them. To support a
T i
Concepts Improvement
(variables)
human designer in making a decision a computer
needs a model of it and this model is given in the
form of a Decision Support Problem (DSP). (The
i T
General Design Determine DSPs are a subset of the general class of Support
Knowledge Areas for
Potential Improvement
Problems (SPs).) Similarly we have Phase, Event,
Task and System Support Problems (SPs). To
Fig. 8 -- A Model of the Conceptual Design Event obtain computer support for the fulfillment of a
(Adapted from [18]) task, a Support Problem of the task, i.e., a Task
Support Problem, should be “known” to the

B. A. Bras and F. Mistree

Page 11
computer. Phase and Event Support Problems
facilitate the modeling of a design time-line. A
System Support Problem is comprised of a
system’s life cycle events which in itself are
modeled as Event Support Problems.
To indicate that a Support Problem has
been formulated for a specific entity we attach the
icon shown in Fig. 9 (representing a support), to
the entity. The icons for the Phase, Event, Task,
Decision and System SPs are as shown in Fig. 10.
In the DSP Technique we are especially interested
in the decisions a designer makes. The icons for
the possible Decision Support Problems are given
in Fig. 11.
A SP can only be solved if its solution
network is known. An important step in finding
such a solution network is the creation of the SP
word formulation. The word formulation of a SP
consist of keywords and descriptors.
Support
Problem
Fig. 9 -- Support Problem Icon
P Phase
Support
Problem
E Event
Support
Problem
T Task
Support
Problem
? Decision
Support
Problem
System
Support
Problem
information is organized using keywords and
descriptors. Keywords act on problem
descriptors. These descriptors are DSPT Palette
entities representing domain-dependent
information and knowledge. This is in contrast to
the keywords which are domain-independent.
Thus the framework of a SP is domain
independent, but it contains domain dependent
information and information.
This organization results in a knowledge
representation scheme built on layers of data
abstraction as shown in Fig. 12. The keywords
and descriptors act as the medium of
communication between a (specific) designer’s
view of the world and the domain-independent
view of the design process. The domain-
independent view of the design process is relevant
for both the “communication” of the design
between various concerned parties (e.g., clients,
designers) and for computer-based design
synthesis. Depending on the desired level of detail
a design process may be viewed at different levels
of abstraction. The levels include Potential
Support Problem entities (i.e., phases, events,
tasks, decisions and systems), SPs, keywords
associated with a SP, and descriptors associated
with the keywords of a particular SP.
DESIGN PROCESS
Domain-independent
representation
KEYWORDS
Procedural knowledge
about the design
process
DESCRIPTORS
Declarative knowledge
about the domain of
interest
DESIGNER'S VIEW
Domain information

Fig. 10 -- Support Problems Fig. 12 -- Layers of Representation for SPs [12]

Most of our experience is with Decision

?
Compromise
Decision
Support Problems. We have modeled a large
Support
Problem number of engineering decisions as DSPs. An
Selection
? Decision overview is given in [29]. An extensive discussion
Support
Problem

?
Preliminary of DSPs is given in [12]. In the following we
Selection Decision
Support
Problem provide the keywords and descriptors for DSPs.
?
Heuristic
Decision
Support
Note that we express the descriptors in DSPT
Problem
Palette entities.
Fig. 11 -- Decision Support Problems Compromise DSP
Keywords Descriptors
SUPPORT PROBLEM KEYWORDS Given Symbolic and mathematical Base entities
AND DESCRIPTORS - Within each SP the and Support Problems necessary for

B. A. Bras and F. Mistree

Page 12
 evaluating the goals, constraints and Given • The object of the event (i.e., the
bounds and the deviation function. transmission from the event).
Find System variables (symbolic and • Palette entities necessary for describing
mathematical). the event.
Satisfy Goals, constraints and bounds, i.e., Identify The task or decision to be performed in
symbolic and mathematical limiting the event.
relationships.
Minimize A deviation function.
Phase SP
Keywords Descriptors
Given • The object of the phase (i.e., the
Selection DSP transmission from the phase).
Keywords Descriptors • Palette entities necessary for describing
Given Alternatives, i.e., DSPT Palette entities. the phase.
Identify • Attributes, i.e., a subset of the meta- or Identify The task or decision to be performed in
embedded information of entities. For the phase.
instance, to select between formulas the
attributes have to be identified from the System SP
meta-information. To select between Keywords Descriptors
systems the attributes can also be Identify • Desired output transmission to
identified from the embedded environment.
information. • Input transmission fromenvironment.
• Relative importance of attributes, i.e., • Required events for converting the input
one or two dimensional symbolic or into the output.
mathematical matrix (symbolic or
mathematical auxiliary parameter).
Rate Alternatives with respect to attributes, From the perspective of keywords there is no
i.e., two dimensional symbolic or difference between a Phase SP and an Event SP.
mathematical matrix (symbolic or However, the syntax for the expression of a phase
mathematical auxiliary parameter). differs from the syntax of an event expression.
Rank Order of preference, i.e., one dimensional
symbolic or mathematical matrix
Also note that decisions are a special type of tasks.
(symbolic or mathematical auxiliary For instance
parameter).
“design a ship”
The preliminary selection DSP is a special type
selection DSP [29]. The heuristic DSP and its is clearly a task. The formulation of the task SP is
keywords and descriptors are presented in [24].
TASK, PHASE AND EVENT SUPPORT Task Design a ship
PROBLEM KEYWORDS AND DESCRIPTORS Given The task: design
The object of the task: a ship
- We would like to stress that Phase, Event, Task DSPT Palette entities necessary for
and System SPs are still research issues. At the performing the task.
moment we use the following keywords and
descriptors for these SPs. However, if we add to this formulation (in the
“given” part) the task
Task SP
Keywords Descriptors “satisfy the client’s requirements”
Given • The task.
• The object of the Task (i.e., the
transmission from the task). then the task SP becomes a compromise DSP
• Palette entities necessary for describing because the compromise DSP keyword “satisfy” is
and performing the task. used. The expression “design a ship” is thus not a
task SP, but a compromise DSP with the following
Event SP (incomplete) formulation.
Keywords Descriptors

B. A. Bras and F. Mistree

Page 13
 Compromise decision Design a ship
Given DSPT Palette entities necessary for Support Problem

performing the task.

Template

Find
Satisfy The client requirements Fig. 13 -- Support Problem Template Icon
Minimize

Examples of Decision Support Problems
are summarized in [29]. Some small examples of
other SPs follow.
Task Design the propeller
Given The task design
The object of the task the propeller
DSPT Palette entities necessary for
performing the task.
Event Calculation of hull resistance.
Given The object of the event hull resistance
Identify The task or decision
to be performed calculate
Phase Designing for concept.
Given The object of the phase concept
Identify The task or decision
to be performed design
SUPPORT PROBLEM TEM PLATES -
Our motivation for formulating SPs is to express
phases, events, tasks, decision and system entities
using Base entities on a computer. If these entities
cannot be modeled as Support Problems then a
human designer is definitely required. If a SP is
formulated, then human intervention may still be
required, but we are one step closer to using the
computer for solving the SP.
We have developed a syntax for the SPs.
This syntax is on the SP keywords and allows us
to classify SPs. As soon as one or more SP
keywords are detected in the input stream we
know that a Support Problem is being defined. As
an example consider the two sentences
“satisfy length / beam = 7”
and
“length / beam = 7”.
The first sentence explicitly uses the compromise
DSP keyword “satisfy” and thus explicitly
indicates that a compromise DSP is being defined.
The second sentence implies a constraint or goal
to be satisfied. Thus, although not explicitly
stated, the second sentence implies the keyword
“satisfy” and implicitly indicates that a
compromise DSP is being defined.
As soon as one keyword of a SP is
detected we speak of a partial Support Problem.
A SP is completely defined if all its keywords are
specified and is called acomplete Support Problem
in such a case. Note that a Task SP is already a
complete SP if only the “given” keyword is
specified.
A complete Support Problem becomes a
Support Problem template if it is expressed in
Base entities only at the lowest (hierarchical) level
of abstraction. Only complete SPs can be
transformed into templates. The icon for a
Support Problem template is the same as for a
Support Problem (see Fig. 13), but its color is
black indicating solidity and making it easily
distinguishable in a graphical entity network.
The solution of a SP requires a template be
formulated in mathematical terms only. However,
computer languages based on Artificial
Intelligence principles, such as Prolog, are able to
solve problems stated in symbolic terms. Thus, in
principle, Support Problems can be solved
symbolically and numerically. Further information
on the mathematical formulations of DSPs suitable
for numerical solution are given in [12]. Based on
the preceding the following observations are made.
OBSERVATIONS
A phase, event, task, decision or system becomes
a partial Phase, Event, Task, Decision or System
Support Problem if at least one of its keywords is
specified.
A partial Support Problem becomes a complete
Support Problem if all its keywords are specified.
A Support Problem template is a Support Problem
formulated in Base entities only.

B. A. Bras and F. Mistree

Page 14
 In the light of the preceding discussion we Preliminary Top
Design i Level
pose and answer the following question: Why do E
Specification

we not use the phrase Support Problem Technique i Ship

Characteristics
instead of Decision Support Problem Technique?
We believe decisions, and especially the
compromise decision, to be the most important Goals and Refine Goals and
entities in design. This is rooted in our Constraints Constraints
i T
philosophy: Decision-Based Design. Decisions
help bridge the gap between an idea and reality.
Hull
Decisions serve as markers to identify the Analysis Goals and
Information i
progression of a design from initiation to Basic i
Constraints
Top
Level
implementation to termination. They represent a Concept
Propeller Specification
i
unit of communication; one that has both domain- Order
Information
Concepts &
Attributes ?
Model
Solution
Prepare
Documents
dependent and domain-independent features. T i ? i T
Decisions have the most complex Support Propeller
?

Problem formulation and embed all other SPs. A i Analysis

Information Preliminary Ship
General Design Ship Characteristics
task can also embed a decision, but at the ultimate Knowledge i Synthesis
highest level a decision is required. DSP Template

SUPPORT PROBLEMS: AN Experimental

EXAMPLE - In Fig. 7 and Fig. 8 we show models
of the phase “Designing for Concept” and the
event “Conceptual Design”. In Fig. 14 we provide
a model of the event “Preliminary Design”. Note
that in Fig. 14 the event is shown as an Event SP.
The model in Fig. 14 thus represents the solution
network for the Event SP “Preliminary Design”.
To be consistent and complete we point out that
the models in Fig. 7 and Fig. 8 are in fact also
solution networks to SPs.
The model in Fig. 14 includes various SPs.
Most noticeable is the DSP template “Preliminary
Ship Synthesis” (see also Fig. 15). It consists of a
hull compromise DSP, propeller selection DSP
and a propeller compromise DSP. The DSPs
forming the preliminary ship synthesis model have
to be solved concurrently and are embedded in one
template. More DSPs are required for a real
world ship synthesis, but these have been omitted
for simplification.
Validation of Solution
i E
Experimental
Information
Note that the template in Fig. 15 is expressed in
Base entities. Also note the use and amount of
gray shading in the resistance calculation and
seakeeping calculation relationships. Both are
empirical relationships. Assuming an available set
of algorithms, the seakeeping calculation is shown
darker, implying that it is vaguer than the
resistance calculation. This is a simple example of
using colors and shading to include additional
information about the entities in the model. We
call such information about entities meta-
information. We are able to solve the template
using the coupled mathematical formulations of
the DSPs shown in the lower part of Fig. 15. A
detailed discussion of the solution of such
templates is given in [11,12]. Design processes
can be modeled using DSPT Palette entities, as
shown in the example, as SPs. But how are these
models obtained? And how do we find the most
suitable model for a given design problem? The
quest for answers to these questions brings us to
our ultimate goal, namely, designing design
processes.

Fig. 14 -- Ship Preliminary Design Event (Adapted

from [18])

B. A. Bras and F. Mistree

Page 15
 • original design of a design process: the
DESIGNING DESIGN PROCESSES model has to be created from scratch,
• adaptive design of a design process: the
In the preceding we have shown how to network representation of the model of a
model an (existing) design process. In this section design process is changed, and
we focus on how we obtain a suitable (new) • variant design of a design process: the
design process for the design of an artifact. In network representation of the model is left
short we are focusing on designing design unchanged but the values associated with the
processes. entities are changed.
We consider three different types of design
of design processes, namely, We have adopted this classification from Pahl and
Beitz [27]. The type of design has its influences
on the amount of designer interaction
Length Volume greater than
Required Volume
required.
Beam
Achieve desired
Draft Seakeeping Performance
Depth Depth to Propeller Shaft
...... within specified bounds REPRESENTING DESIGN ,
......
Resistance
MANUFACTURING,
Calculation MAINTENANCE AND RECYCLING
Seakeeping
Calculation
Hull PROCESSES AS SUPPORT
Analysis G oals and
Space Information i Constraints PROBLEMS - Probably the most
Calculation
...... i general problem statement for a design is
Propeller
Concepts & Model
Attributes ? Solution “design a product”.
Wageningen i ? i
B-series
Propeller ? As discussed previously, this statement is
Controllable
Pitch Analysis
Preliminary
a task. For this task we want to
...... Information
i
Ship formulate a SP. If we are able to obtain
Pitch Synthesis
Blade Area
DSP template a SP formulation describing how the task
...... is or should be performed, then we also
have a formulation of the design process.
Further, “design” is merely a specific
Selection DSP Compromise DSP 1 Compromise DSP 2
task and a design process is the SP
(Propeller) (Hull) (Propeller )
________________________________________________________________________
formulation of the task “design a
product”.
Find
Y, e -, e + X, d -, d + Z, h -, h + The same reasoning applies for
Satisfy
the tasks “manufacture a product” and
•Y=1 g 1(Z,X,Y) • 0 g 2(Z,X,Y) • 0 “maintain a system”. Both are specific
MF(X,Z) . Y + e - - e+ = 1 A 1 (Z,X,Y) + d - - d + = G1 A 2(Z,X,Y) + h - - h + = G2
0ŠY Š1 Xmin Š X Š Xmax Zmin Š Z Š Zmax
tasks and their respective task SPs
represent the manufacturing and
< e - * e+ = 0 > # < d - * d+ = 0 > # < h - * h+ = 0 > #
________________________________________________________________________
maintenance process. As should be
Minimize (Lexicographically)
clear, our approach bridges design,
manufacture, maintenance and even
Z = { f 1(e -, d -, d +, h -, h +), ..., f k(e -, d -, d +, h -, h +) }
recycling, because they are merely
specific tasks for which SPs have to be
X, Y, Z - system variables h -, h +, d -, d +, e -, e + - deviation variables (• 0)
g - constraint functions A - goal functions G - goal target values formulated to obtain the processes.
MF i - merit function of alternative i
Z - deviation function (Preemptive form, k priority levels) Are processes always Task SPs?
# < can be omitted if a vertex-solution algorithm is used > No. It is more likely that design,
manufacturing, maintenance and

Fig. 15 -- Preliminary Ship Synthesis Template (Adapted from B. A. Bras and F. Mistree
[18]) Page 16
recycling processes are compromise Decision
Support Problems. Instead of “design a product”
a more realistic design problem statement is
“design a product and satisfy all given
requirements”.
The keyword “satisfy” indicates a compromise
decision and the design process is thus a specific
compromise DSP.
In summary, by recognizing that a design
process is merely a (Decision) Support Problem
the design of design processes collapses to the
design of (Decision) Support Problems. To
achieve the design of Support Problems, what is
needed? We believe the following is required
• information and knowledge about Support
Problems
• a systematic approach to designing Support
Problems
In the next sections we focus on the information
and knowledge about SPs, which is used for
designing SPs, and our systematic (decision-based)
approach.
DESIGNING SUPPORT P ROBLEMS
USING THE DSP TECHNIQUE - In order to
design a Support Problem we use the DSP
Technique. The task “Design a Support Problem”
is in fact a compromise decision because there are
tradeoffs involved. The formulation for this
particular compromise DSP is as follows:
Compromise DSP for designing SPs
Given An entity for which a SP has to be
formulated.
Existing information.
Find The formulation and solution of the SP
by means of the DSP Technique.
Satisfy Various constraints and goals posed on
the SP, such as:
• minimum information content [30]
• minimum amount of non-
mathematical information
• maximum concurrency
• minimum inconsistency
• maximum consistency
• maximum confidence
• maximum validity
• other goals and constraints available
in design literature.
Minimize The deviation function derived from the
constraints and goals imposed upon the
SP.
Note that the preceding compromise DSP
formulation captures both the design of a process
and a product, since both are modeled as Support
Problems. Furthermore, in the discussion
associated with Fig. 15 we have mentioned meta-
information as being information about DSPT
Palette entities. Entity meta-information is for use
in higher level models embodying the entity only.
The goals and constraints imposed upon the design
of the SP make use of the SP meta-information.
For instance a measure of the information content
is required. This measure is meta-information; it
says something about the SP.
We use a particularization of the DSP
Technique to find a satisficing SP formulation and
solution. This particularization, namely, the DSP
Technique for the design of a Support Problem, is
given in Fig. 16. The DSP Technique for the
design of a Support Problem is written in terms of
phases, events, tasks and decisions confirm our
views on modeling design processes using the
DSPT Palette. The result of the meta-design
phase is a SP word formulation (i.e., a formulation
in the form of keywords and DSPT Palette
entities) and an initial plan (i.e., an initial solution
network in the form of DSPT Palette entities) to
solve this SP.
B. A. Bras and F. Mistree
Page 17

In the design phase we focus in depth on
obtaining, validating and improving a solution
to this SP formulation. In defining a SP and
effecting its solution we simultaneously check
whether the goals and constraints imposed
PHASE I: META-DESIGN FOR SOLUTION
upon its design are satisfied. The deviation
function derived from these goals is used as a
measure of performance with respect to these
goals and constraints. If the performance of the
SP formulation and solution cannot be
improved anymore, the iteration within the DSP
Technique for the design of a Support Problem
will stop, else we keep iterating and changing
the design of the SP. If the performance of the
“converged” SP formulation and solution is not
satisfactory, we may have to examine and even
adjust the goals and constraints imposed upon
the SP design.
To show the versatility of our approach
we illustrate the two phases of the DSP
Technique using DSPT Palette entities (see
Figs. 17 and 18). We stress that this is not a
final model; the work is still in progress and a
number of issues are still to be resolved. The
two phases of the DSP Technique for the
design of Support Problems embed events. The
events provide a measure of (event-based) time.
Note that within each event a number of tasks
PHASE II: DESIGN FOR SOLUTION
have to be performed and decisions to be made
to finish the event. Thus the DSP Technique
for the design of Support Problems itself is
modeled in DSPT Palette icons and we can
design Support Problems for the embedded
phases, events, tasks and decisions. In short,
we use both phases of the DSP Technique to
design Support Problems for effecting meta-
design (the first phase of the DSP Technique).
Existing (real world) information
Event 1: Identifying
Task 1a: Write a SP problem story (in natural language) embodying all
information required to formulate and solve the SP.
Task 1b: Identify important terms and create a lexicon.
Event 2: Translating
Task 2a: Write a SP problem statement in the syntax of DSPT Palette entities.
Task 2b: Analyze the problem statement and obtain a hierarchy of DSPT
Palette entities.
Event 3: Partitioning
Task 3: Create partitions in the problem statement hierarchy.
Avoid mixing phases and events with other entities at the hierarchy's top level,
rather creat new events. Group related entities by introducing a new entity
encapsulating these entities.
Event 4: Formulating
Task 4a: Write the word formulation of the SP in the form of keywords.
Preferably by using the entities given in the top level of the problem statement
hierarchy only.
Task 4b: Decompose the word formulation into a hierarchy of DSPT Palette
entities.
Event 5: Planning
Task 5a: Plan an initial solution sequence for the SP in the form of a network
model, preferably by using the entities in the word formulation hierarchy only.
Task 5b: Identify entities (phases, events, tasks, decisions and systems) for
which possibly Support Problems need to be designed.
Event 6: Structuring
Task 6: Structure the SP solution network. Design each lower level SP by
using the DSP Technique recursively to solve the following compromise
DSPs for the design of each SP:
Given: The entity for which a SP needs to be designed.
Existing information.
Find:
The SP formulation and solution.
Satisfy: Goals and constraints posed on the SP formulation and solution.
Minimize: The weighted lexicographic deviation function derived from the
goals and constraints posed upon the SP formulation and solution.
Check and update (if required) the solution network with every change in
the lower level entities.
Event 7: Solving
Task 7: Obtain solutions by propagating through the solution network.
Event 8: Post-Solution Analysis
Task 8a: Validate the solution.
Task 8b: Investigate the effect on the solution of small changes.
Task 8c: Determine whether the SP formulation and solution is satsifactory
with respect to the goals and constraints placed upon the SP or whether
iteration is necessary.
Satisficing design
Fig. 16 -- The DSP Technique for the Design of
B. A. Bras and F. Mistree
Page 18
 P
Meta-Designing for Solution

i E i E i E i E i E i
Existing Identifying Problem Translation Entity Partitioning Partitioned Formulation Word Planning Initial
information story and hierarchy hierarchy formulation solution
lexicon network

T i T i T i T T T T i T
Identify Problem Create Write Problem Analyze Create Write Create Initial Identify
Lexicon solution
problem story lexicon problem statement problem partitions word initial possible
story statement statement into in entity formulation solution network Support
entity hierarchy network Problems
hierarchy
Fig. 17 -- Meta-Design Formulated in DSPT Palette Entities

P
Designing for Solution

i E i E i E i
Initial Structuring Solution Solving Solution Post-Solution Satisficing
solution network Analysis solution
network

? i T T T i T i ?
Structured Check Obtain Validate Validated Investigate Final Decide
Design all solution and solution solution solution effect of solution between
Support network update small iteration
Problems solution changes or
in solution network accepting
network solution
Fig. 18 -- Design Formulated in DSPT Palette Entities
B. A. Bras and F. Mistree
Page 19

DESIGN GUIDANCE SYSTEM
Formulate Support Problems
Hierarchy Editor
Information Synthesizer
Heterarchy Editor
Information
Evaluator
Information
Analyzer
SUPPORT TOOLS
Editor
INFORMATION
LEXICONS
HETERARCHY
KNOWLEDGE BASE
DESIGN OBJECT BASE
Fig. 19 -- The DSPT Workbook
COMPUTER ENVIRONMENT
DESIGNING DESIGN PROCESSES
What are the computer implementations under
development to support Concurrent Engineering
and the DSP Technique?
THE DSPT WORKBOOK - The
implementation of the DSP Technique on the
computer is called the DSPT Workbook. It is still
under development. In order to achieve full
computer support for the DSP Technique, i.e., a
complete DSPT Workbook, we have to obtain SP
templates of the tasks in the DSP Technique.
Among others we recognize the need for the
following types of software tools, namely,
USER INTERFACE
SUPPORT PROBLEM
SOLVER
Domain Indepedent
Programs
DSIDES
Solves
Decision Support
Problems
•
User Interface
•
(X windows)
Domain Dependent
Program
Library
INFORMATION INFORMATION
with schema
HIERARCHY
definition for
different domain
dependent and
independent systems
• tools to analyze* and synthesize** information
FOR and knowledge with the primary purpose of
supporting the designer in the meta-design
phase of the DSP Technique,
• tools to evaluate *** information and solve SPs
to support Phase II of the DSP Technique, and
• tools that facilitate the exchange and sharing of
knowledge and information between different
designers and computer systems.
* Analysis: A process of partitioning or decomposing
any system into its subsystems and component parts to
determine their separate and collective nature,
proportion, functions, relationships, etc.
** Synthesis: A process of integrating a collection of
subsystems to create a system with emergent
properties.
*** Evaluation: A process of assessing the degree to
which a solution satisfies the goals that were
originally stated.
B. A. Bras and F. Mistree
Page 20
The DSPT Workbook, at present, consists of three
software systems, namely, the Design Guidance
System (DGS), the Design Object Base and
DSIDES. Components of these three software
systems and their interactions within the DSPT
Workbook are shown in Figure 19. The Design
Guidance System’s primary purpose is to support
a designer in modeling and designing SPs. The
DGS embodies tools for the analysis and synthesis
of information. Further details are presented in
[16-18,31]. DSIDES is used for the solution of
DSPs. The Design Object Base is the tool used
for the storage of and access to the information
and knowledge related with the design. DSIDES
is used for the solution of compromise and
selection DSP templates.
AN OVERVIEW OF THE DSPT
WORKBOOK - In the following some features of
the DSPT Workbook are discussed.
User Interface: In Concurrent Engineering
the multitude of information has to be represented
in a fashion that will be understandable to a
designer. The user interface for the DSPT
Workbook is developed using X windows [16].
We use an Enhanced Entity Relationship Model
[32].to display the objects used in the Design
Object Base and the associations between them on
the screen. Examples of the Design Object Base’s
user interface are presented in [13].
Design Object Base - The most important
consideration in the development of the Design
Object Base is that multiple designers should have
concurrent access to design information and DSPs.
Based on this we have taken the following
strategies into consideration during the
development:
• A designer can create his/her own version of
Decision Support Problems and templates,
while working on the design problem as a
separate instance*.
• At the end of every session a designer is given
an opportunity to save his/her own instance.
Differences between two versions of a design
can be found. This includes differences
between versions created by two designers
working on the same design.
* currently stored
The data in the database at a particular moment is
called a database instance.
• Changes made to the original design can be
stored in a script file and saved separately
without changing the original design. The
information related with the design is not lost
even if the design has been changed. The
difference between two design versions can be
used for merging the two versions to form an
improved version.
• Changes made by a designer to specific
Decision Support Problems or templates can
be stored separately.
These features have been implemented using tools
available in the ROSE Database Management
System [33,34]. More information on the Design
Object Base can be found in [13].
Information Analyzer (Parser) -
Information is analyzed by means of a syntax
parser. The parser not only decomposes entities
into hierarchies, but also retrieves information and
performs consistency checks. We therefore prefer
to speak of information analysis rather than merely
information decomposition. The Parser-utility
analyzes input from a designer and translates it
into language understandable for the DGS. In
order to facilitate the communication the Parser
has natural language processing capabilities. More
information on our approach and use of natural
language processing techniques is given in [17].
Information Evaluator (Calculator) -
Information is evaluated by the Calculator module
which thus determines the value(s) of information.
It makes use of the Parser-utility to analyze the
given information before determining its value. At
the moment it only evaluates mathematical and
logical limiting relationships, assignments, equality
relationships and rules. For evaluating SP solution
networks and functions the Calculator will initially
produce conventional programming language
source code which is compiled, linked and
executed. Compromise and selection DSPs are
solved using the DSIDES software [11]. At a
later stage we plan to include network propagation
mechanisms in the Calculator.
Heterarchy Editor - This utility processes
(i.e., acquires, analyzes, evaluates, displays and
stores) “loose” information. The information is
B. A. Bras and F. Mistree
Page 21
 • in the computer’s working memory for fast
access, and
• in the Design Object Base.
There is no connection between such “loose”
information elements except for the storage
mechanism. Therefore, we call such a collection
of elements an information heterarchy*.
Information Synthesizer - Information
synthesis is performed manually by the designer, in
conjunction with the DGS or autonomously by the
DGS by means of the Assist-utility. The Assist-
utility synthesizes information in the form of DSPT
Palette entities into models. Currently Assist
• creates a dependency network to conclude a
specified goal (depth first backward chaining).
This network includes alternative ways to
reach the goal.
• finds all possible paths within a dependency
network. It can maximize concurrency by
finding these paths in a breadth first manner.
• monitors the consistency of the network with
respect to loops and reassignment of values.
In the future Assist will also show a designer what
can be achieved with the information given.
Hierarchy Editor - This utility processes
(i.e., creates, modifies, analyzes, evaluates,
displays and stores) hierarchies, i.e., networks.
The networks are graphically displayed and can be
modified by a designer through point and click
operations. There is a one-to-one mapping
between the graphical and the internal data-
structure representation of the network. This
supports recursion. And of course a network can
be embedded in another network.
CLOSURE
What has been shown in this paper?
• The DSPT Palette that allows us to create
graphical network models of (design)
processes.
*
Heterarchy - a formal organization of nodes without
any single permanent uppermost node, a non-
hierarchical organization [18].
• The use of Support Problems to model
complex entities such as phases, events, tasks,
decisions and systems.
• A compromise Decision Support Problem
formulation for the design of such Support
Problems.
• A particularization of the DSP Technique,
namely, the DSP Technique for Designing
Support Problems for solving the
aforementioned compromise DSP.
• The recursive nature of the design of Support
Problems.
• An overview of the computer implementation
of the DSP Technique, i.e., the DSPT
Workbook.
What is the status of development?
• A unified information representation scheme
has been developed by viewing all DSPT
Palette entities as relationships that require
input and transmit output. Note that we focus
on information management of which
constraint management and rule inferencing
are subsets.
• A syntax for all DSPT Palette entities has been
developed and implemented in the DGS Parser
utility. The Parser supports a certain degree of
natural language processing and facilitates the
definition of SPs.
• We have a prototype version of the DSPT
Workbook for the design of SPs.
• Applications of DSPs include:
• ship design,
• aircraft design,
• lubricant design,
• mechanical systems,
• electrical systems,
• thermal energy systems,
• design using composite materials, and
• design of automobile and aircraft tires.
A detailed set of references to these
applications is presented in [29]. These
studies all have the following characteristics:
• they are practical, real world problems,
B. A. Bras and F. Mistree
Page 22
 • within the domain of conceptual design
they are large scale problems,
• soft empirical as well as hard information
is used,
• multiple conflicting goals and constraints
are present,
• selection and compromise decisions need
to be made, and
• they involve discrete and continuous
system variables.
What are some issues we would like to resolve?
• How can one model function, process and
time in original design? Miller’s Living
Systems Theory is a conceptual framework
that deals with the hierarchical structure of life
at many levels (see Miller [25]). LST has been
used to model living [25] and nonliving
systems [25,35,36]. Miller proposes 20
generic subsystems grouped in three categories
(two subsystems which process both matter-
energy and information, eight subsystems
which process matter-energy, and ten
subsystems which process information) which
we believe could be used to model both
function and processes associated with the
design, manufacture and support of
engineering systems.
LST provides a convenient domain-
independent, pictorial language that can be
used to represent the functional requirements
of a system without regard to the specific
means by which this requirement will be
satisfied. For example, say the functional
requirement is specified as an energy to motion
mechanism. Using LST subsystems this could
be represented without reference to the type of
energy source (electrical, mechanical, solar,
thermal) or to the specific type of mechanism
(scotch yoke, four bar linkage and the like).
LST is particularly suitable for use when
quantitative information is not available. LST
facilitates modeling time and the evolution of a
system. Some exploratory work has been
completed; Shupe and co-workers
investigated the use of LST subsystems in
modeling the functional requirements of a
system [37,38]. This was extended to include
the research issues involved in modeling life
cycle considerations and planning [39].
We plan to link the DSPT Palette entities and
Miller’s entities to engineering design
databases. This would enable us to map
entities to (physical) real world phenomena
and/or devices. However, Miller’s entities for
modeling living systems are of a detailed,
atom-like type and may not have a proper level
of abstraction for original design of
engineering systems. The entities in the DSPT
Palette allow a high level of abstraction. The
question: How and at what level of
abstraction can we create a link between
Miller’s Living Systems Theory and our
approach to designing design processes and
Support Problems?
• How does one assess the quality of a plan?
The quality of a plan embodied in a SP
depends on its formulation. Suh [30] proposes
two axioms. We believe the first axiom
(independence of function) can be used to
identify and classify goals and constraints for
the SP and Suh's second axiom (minimize
information) to assess the quality of the
proposed solution. We would like to
investigate this and in so doing understand the
relationship between Suh’s axiomatic approach
and our DSP Technique.
• Automating process design: We believe, in
principle, any process can be modeled as a
Support Problem and designed using the DSP
Technique particularized for designing a SP.
How can this particularized form be made to
design its own process?
• Designing open engineering systems: We are
intrigued by the possibility of investigating the
processes associated with designing, building,
deploying, supporting and operating open
engineering systems, that is, systems (like the
space station) that will be deployed and
developed incrementally over a long time-
frame. The key to success in designing,
B. A. Bras and F. Mistree
Page 23
 building, deploying, operating and supporting
open engineering systems is to maintain
flexibility of options throughout the life cycle
of the system. The early stages of project
initiation are especially important because
major decisions, which can have far-reaching
effects on the system, are made at this time.
By early stages we mean those stages that are
characterized by unclear and changing mission
objectives and incomplete and soft
information. We believe that research along
these lines is particularly appropriate in a
world in which a new political and economic
order is emerging - a world in which new
political, economic and technical alliances
alliances are being forged.
In closing we stress the importance of knowing in
advance what to do (i.e., the meta-design aspect of
our work). Designing a process for a specific
design problem and maximizing the independence
between its contents will reduce unnecessary
design iterations far more than by merely
instituting a concurrent attack on the problem.
Therefore, we view the modeling and design of
design processes as an efficient and effective
approach to realize the benefits of Concurrent
Engineering.
ACKNOWLEDGEMENTS
We gratefully acknowledge the Maritime Research
Institute Netherlands (MARIN), Wageningen, The
Netherlands, for their cooperation and funding of
the research of B.A. Bras. The financial
contribution of our corporate sponsor, The BF
Goodrich Company, to further develop the
Decision Support Problem Technique is gratefully
acknowledged. An equipment grant from NSF
(No. 8806811) and another from Apple Computer
Inc. are gratefully acknowledged.
REFERENCES
1. F. Mistree and D. Muster, "Conceptual
Models for Decision-Based Concurrent
Engineering Design for the Life Cycle",
Proceedings of the Second National
Symposium on Concurrent Engineering,
Morgantown, West Virginia, 1990, 443-467.
2. J. P. Pennell and M. M. G. Slusarczuk, "An
Annotated Reading List for Concurrent
Engineering", IDA Document D-571,
Institute for Defense Analyses, Alexandria,
Virginia, 1989.
3. R. I. Winner, J. P. Pennell, H. E. Bertrand
and M. M. G. Slusarczuk, "The Role of
Concurrent Engineering in Weapons System
Acquisition", IDA Report R-338, Institute for
Defense Analyses, Alexandria, Virginia, 1988.
4. S. Azarm, D. A. Dierolf, J. Naft, M. Pecht, K.
J. Richter and B. T. Sawyer, "Decision
Support Requirements in a Unified Life Cycle
Engineering (ULCE) Environment", IDA
Paper P-2064, Institute for Defense Analyses,
Alexandria, Virginia, 1988.
5. M. Brei, W. E. Cralley, D. A. Dierolf, D. J.
Owen, K. J. Richter and E. Rogan,
"Architecture and Integration Requirements
for an ULCE Design Environment", IDA
Paper P-2063, Institute for Defense Analyses,
Alexandria, Virginia, 1988.
6. D. A. Dierolf and K. J. Richter, "Computer-
Aided Group Problem Solving for Unified
Life Cycle Engineering (ULCE)", IDA Paper
P-2149, Institute for Defense Analyses,
Alexandria, Virginia, 1989.
7. U. D. W. Group, "Decision Support
Requirements in a Unified Life Cycle
Engineering (ULCE) Environment", IDA
Paper P-2064, Institute for Defense Analyses,
Allexandria, Virginia, 1988.
8. D. E. Calkins, R. S. Gaevert, F. J. Michel and
K. J. Richter, "Aerospace System Unified Life
Cycle Engineering: Producibility
Measurement Issues", IDA Paper P-2151,
Institute for Defense Analyses, Alexandria,
Virginia, 1989.
9. S. Finger and J. R. Dixon, "A Review of
Research in Mechanical Engineering Design.
Part 1: Descriptive, Prescriptive, and
B. A. Bras and F. Mistree
Page 24
 Computer-Based Models of Design
Processes", Research in Engineering Design,
1, 1989, 51-67.
10. S. Finger and J. R. Dixon, "A Review of
Research in Mechanical Engineering Design.
Part 2: Representations, Analysis, and Design
for the Life Cycle", Research in Engineering
Design, 1, 1989, 121-137.
11. O. F. Hughes, F. Mistree and B. A. Bras, "An
Adaptive Linear Programming Algorithm for
Multicriteria Problems", Structural
Optimization: Status and Promise, (M. P.
Kamat ed.), AIAA, Washington, D.C., 1992.
12. F. Mistree, W. F. Smith, S. Z. Kamal and B.
A. Bras, "Designing Decisions: Axioms,
Models and Marine Applications", Fourth
International Marine Systems Design
Conference, Kobe, Japan, 1991, 1-24.
13. F. Mistree, S. Karandikar, B. A. Bras and T.
Bollam, "Formulation, Storage and Solution
of Decision Support Problems in a
Concurrent Engineering Environment",
Proceedings Third National Symposium on
Concurrent Engineering, Washington, D.C.,
1991, 625-645.
14. F. Mistree, D. Muster, J. A. Shupe and J. K.
Allen, "A Decision-Based Perspective for the
Design of Methods for Systems Design",
Recent Experiences in Multidisciplinary
Analysis and Optimization, NASA CP 3031,
Hampton, Virginia, 1989.
15. S. Z. Kamal, H. M. Karandikar, F. Mistree
and D. Muster, "Knowledge Representation
for Discipline-Independent Decision Making",
Expert Systems in Computer-Aided Design,
(J. Gero ed.), Elsevier Science Publishers
B.V., Amsterdam, 1987, 289-321.
16. S. Karandikar, B. Bras and F. Mistree,
"Visualization and Manipulation of Design
Related Infromation and Knowledge", Joint
International Conference on Factory
Automation and Information Management,
University of Limerick, Ireland, 1991, 793-
803.
17. B. A. Bras, J. Garson and F. Mistree, "Using
Natural Language Processes in Modeling
Design Processes", Report No.
SDL/REP.1/91, Systems Design Laboratory,
University of Houston, 1991.
18. F. Mistree, W. F. Smith, B. Bras, J. K. Allen
and D. Muster, "Decision-Based Design: A
Contemporary Paradigm for Ship Design",
Transactions, Society of Naval Architects and
Marine Engineers, Jersey City, New Jersey,
1990.
19. N. Cross, Engineering Design Methods, John
Wiley & Sons, Chichester, 1989.
20. M. M. Andreasen, "Design Strategy",
Proceedings 1987 International Conference
on Engineering Design, Vol. 1, Boston, 1987,
171-178.
21. S. J. De Boer, Decision Methods and
Techniques in Methodical Engineering
Design, Academisch Boeken Centrum, De
Lier, The Netherlands, 1989.
22. J. E. Lewis, "Wrappers: Integration Utilities
and Services for the DICE Architecture",
Proceedings Third Annual Symposium on
Concurrent Engineering, Washington, D.C.,
1991, 445-457.
23. H. A. Simon, The Sciences of the Artificial,
The MIT Press, Cambridge, Mass., 1982.
24. S. Z. Kamal, "The Development of Heuristic
Decision Support Problems for Adaptive
Design", Ph.D. Dissertation, Interdisciplinary
OR Program, University of Houston, Hous-
ton, Texas, 1990.
25. J. G. Miller, Living Systems, McGraw-Hill
Book Company, New York, 1978.
26. V. Hubka, Principles of Engineering Design,
(W. E. Eder ed.), Butterworth & Co.
(Publishers) Ltd., London, 1982.
27. G. Pahl and W. Beitz, Engineering Design,
The Design Council/Springer-Verlag,
London/ Berlin, 1984.
28. K. Roth, Konstruieren mit Konstruktion-
skatalogen, Springer-Verlag, Berlin, 1982.
29. F. Mistree, D. Muster, S. Srinivasan and S.
Mudali, "Design of Linkages: A Conceptual
Exercise in Designing for Concept",
Mechanism and Machine Theory, Special
Issue on "Theories of Design - Application to
the Design of Machines", 25(3), 1990, 273-
286.
30. N. P. Suh, Principles of Design, Oxford
University Press, Oxford, U.K., 1990.
31. B. Bras, W. F. Smith and F. Mistree, "The
Development of a Design Guidance System
B. A. Bras and F. Mistree
Page 25
 for the Early Stages of Design", CFD and Exposition", USAF Contract FY 1457-88-
CAD in Ship Design, (G. v. Oortmerssen ed.), 05215, DM&A Inc., Houston, 1989.
Elsevier Science Publishers B.V.,
Wageningen, The Netherlands, 1990, 221-
231.
32. R. Elmasri and S. B. Navathe, Fundamentals
of Database Systems, Benjamin/Cummings,
1989.
33. M. Hardwick, D. Spooner, E. Hvannberg, B.
Downie, A. Faulstich, D. Loffredo, A. Mehta,
D. Sanderson, R. Harris, G. Abou-Ezzi, J.
Gong and J. Young, "ROSE: A Database
System for Concurrent Engineering
Applications", Report Number 89062,
Rensselaer Design Research Center,
Rensselaer Polytechnic Institute, Troy, New
York, 1990.
34. M. Hardwick and D. Spooner, "User Manual
for ROSE: A Database for Concurrent
Engineering Application", TR-89052,
Rensselaer Design Research Center,
Rensselaer Polytechnic Institute, Troy, New
York, 1990.
35. G. A. Swanson and J. G. Miller,
Measurement and Interpretation in
Accounting, Quorum Books, New York,
1989.
36. J. F. Walker and F. C. Thiemann, "The
Relationship of the Internal Security System
to Group Level Organization in Miller's
Living Systems Theory", Behavioral Science,
35, 1990, 147-153.
37. J. A. Shupe, "Decision-Based Design:
Taxonomy and Implementation", Ph.D.
Dissertation, Department of Mechanical
Engineering, University of Houston, Houston,
Texas, 1988.
38. J. A. Shupe, D. Muster, J. K. Allen and F.
Mistree, "Decision-Based Design: Some
Concepts and Research Issues", Expert
Systems, Strategies and Solutions in
Manufacturing Design and Planning , (A.
Kusiak ed.), Society of Manufacturing
Engineers, Dearborn, Michigan, 1988,
Chapter 1, 3-37.
39. D. Muster, F. Mistree and J. K. Allen,
"Partitioning and Planning for Unified Life-
Cycle Engineering Design: A Conceptual

B. A. Bras and F. Mistree

Page 26