INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN

ICED 97 TAMPERE, AUGUST 19-21, 1997

Johan Malmqvist and Peter Schachinger
Design Specifications, Product Models, Computer-Aided Design, Design Methodology
TOWARDS AN IMPLEMENTATION OF THE CHROMOSOME MODEL -
FOCUSING THE DESIGN SPECIFICATION
1 Introduction
The objective of this work is to develop a system for product modelling in which all of the
information generated during a design process can be represented. This information ranges from
abstract information like design specifications to detailed information like geometry models.
Such a system will have advantages compared to currently available commercial systems by
simplifying the reuse and redesign of old design solutions and by facilitating the verification
that a product meets its requirements. Moreover, an integrated product model is an important
basis for concurrent engineering by providing a shared representation of the evolving design for
team members.
In earlier work, one of the authors has presented a prototype version of such a system
[Malmqvist 1995ab]. The system is theoretically based on the chromosome model [Andreasen
1992]. This paper focuses on how design specification data is managed in the system. The issues
covered includes the basic requirements on the design specification, data models for specifi-
cation items, and the relationships between the design specification items and other product
models such as the function, organ and component structures and behavioural and life-phase
system models. A case study of an expansion tank is used to illustrate to use of the system.
2 Modelling the contents of the design specication
This section aims at clarifying what information should be included in a design specification
and to formulate that information in an Entity-Relationship diagram. Moreover, the potential
benefits of using a computerized design specification that is linked to the product model will be
highlighted.
A design specification states the task for a development project, including requirements,
objectives and relevant information. It aims at focusing the design process at identified
customer needs while ensuring that no requirement originating from any stakeholder, life-phase
or product aspect is forgotten during the development process. Moreover, it provides a basis for
analyzing the consequences of modifying requirements. It also serves to create a common
understanding of the project goals for the development team and is a instrument for
management control of the project progress. The potential benefits of well-managed work with
the design specification includes earlier, fewer design changes, shorter development lead times
and fewer quality problems. Hence, the design specification is a central reference document for
the design team during the design process.
The engineering literature provides several procedures for collecting the information to be
included in the design specification. (Confer, e.g., [Pugh 1991], [Pahl and Beitz 1996],
[Roozenburg and Eekels 1995], [Ulrich and Eppinger 1995]). The QFD methodology [Akao
1992] further provides a matrix-based framework for translating requirements between
different stakeholders in the process. The authors generally put forward three kinds of tools for
requirement formulation: methods for gathering customer needs, methods for translating
customer needs into engineering requirements and checklists that aim at ensuring that no vital
requirement is forgotten. Moreover, recommendations on how to state individual requirements
are given: Requirements should be given unambiguous, solution-independent formulations and
be clearly linked to customer needs. Requirements should further be stated in measurable (or,
at least, verifiable) units. It is further useful to distinguish between demands and wishes.
It is further important to recognize that the specification is a dynamic entity which changes and
expands during the design process. The high-level, form-independent requirements used during
conceptual design may need to be concretized to form-dependent ones during the design process
in order to be specific enough to set goals for the embodiment design [Otto 1996]. Moreover,
new requirements will be added due to the design decisions made, for instance to connect two
selected function carriers or to compensate for negative consequences of selecting a particular
design solution [Svendsen and Thorp Hansen 1993]. Different variants of the design process
may also require different methods for managing the design specification. In original design
projects only a few requirements are known at the outset of the design process, and most will
emerge during the process as the result of design decisions. This will necessitate frequent
updates of the specification if it is to be complete, and some method of distinguishing original
and derived requirements, or there is a risk that requirements that were included to compensate
for the effects of a certain design decision remain in the specification, although the decision that
lead to their inclusion may have been changed. On the other hand, in redesign projects, such
as the design of a new car year model, most requirements will be known in advance (and these
are numerous). In this case, good requirements management may support the design team in
focusing on the requirements that are important, different or new (called deltaSpecs below).
Based on the literature cited above, a formal data model for the design specification information
may be constructed (fig 1). The model describes the data items of the specification and the
relationships between the requirements. The relationships between the design specification and
the rest of the product model is elaborated on in section 3.
The model shows that a design specification consists of:
Metadata. A standard set of metadata attributes, such as identity, product and subsystem
name, description, version, status etc, is needed to administratively keep track of the speci-
cation.
Requirements. The design specication is decomposed into a set of requirements.
Referenced documents. The design specication may further refer to a set documents of
various kinds, such as old designs, customer surveys, laws and regulations.
The individual requirements items are then described by:
Metadata. These are similar to those of the design specication.
Value. Each requirement will have value, unit and tolerances specied.
Requirements class. Examples of requirement classes include performance and geometry.
The set of requirements classes used here is adopted from Pugh [1991].
Category. Requirements can be classied as demands (which can be sub-classied into
functional requirements and constraints), wishes (or objectives), options or information.
Direction. The Direction attribute of a wish category requirement provides further guidance
for its value. For instance, it may be desirable to minimize or maximize the value of the
requirement, or to hit a specied target value. This attribute may also refer to a value
function that species a rating scale for the attribute.
Importance. The importance of the attribute may be ranked on a scale.
Competition assessment. This attribute keeps track of the competition, as a list of brands
with associated values for the requirement.
Stakeholder. The stakeholder is the entity who requires the requirement, for instance, the
customer or the government.
Responsible. The person who is responsible for the satisfaction of the requirement.
Origin. The origin of the requirement is documented as original, derived due to a design
decision, compensating or interfacing.
IsDeltaSpec. This attribute marks a requirement that has changed since the last model of
the product. This is useful in redesign situations.
Descriptive documents may also be attached to the requirement. See above.
Further, we need to be able to register certain relationships between the requirements:
ConsistsOf relationships. A requirement may consist of sub-requirements. According to
Svendsen and Thorp Hansen [1993] three basic types of decomposition mechanisms for
requirements can be identied: A requirement may be decomposed by distribution, such
that it is only relevant to some sub-systems, or it may be decomposed by magnitude, such
that the value of the system requirement is a sum of the sub-system requirements. Typical
examples of the latter are cost and weight requirements. Finally, it may be decomposed by
transformation where the property type of a system requirement is transformed into a
different type of requirement. This kind of decomposition is dependent on the chosen
solution and on the context.
TradeOff relationships. In practice, requirements are not independent. Rather, conicts
between requirements (corresponding to the House of Quality (HoQ) roof) are likely to
exist. For redesigns, these may be known at the outset of the design process. For original
designs, trade-offs are likely to emerge during the design process.
InuencedBy relationships. Inuences between requirements is here used in a similarly
fashion to the translation between customer attributes and engineering characteristics in the
HoQ, i.e, as the HoQ matrix area.
This model has been implemented in the current version of the system (see section 4). The
system can then support a design team in generating and analyzing design specifications. While
this is valuable in itself, a more powerful support for the design process is obtained if the design
specification can also be effectively linked to the product model. How this can be achieved will
be discussed in the following section.
3 Modelling design specications and product models
In this section the relationships between the design specification and a product model are
analyzed, with the aim of identifying what relationships are important to be able to represent in
a design system.
The product modelling framework employed in this work is constituted by the chromosome
model [Andreasen 1992], which is based on the technical systems theory [Hubka and Eder
1988]. Hubka states that four different types of models are needed to describe a technical system
and the transformation process that it affects. These are termed the process, function, organ and
component structures, and are said to define the design characteristics of the system. The
chromosome expands this theory by adding genetic information, that captures the origin of
the design characteristics (hence chromosome). This is achieved by linking the structures
with causal relationships: the process determines the functions, the functions are created by the
organs, and the organs are materialized by the components. It has further been pointed out
[Mortensen and Andreasen 1996] that in order to derive the properties (weight, cost, etc) of a
product it is not sufficient to model only the product. We also need to model the various life-
phase systems (parts manufacturing, assembly and so on) that the product meets, since many
properties (e.g., assembly cost) are relational in the sense that they cannot be determined
without knowledge of the life-phase system.
The chromosome model offers a general framework for modelling the various aspects of
technical systems and is also strongly linked to design methodology. The theory further
provides a flexible design process model, by suggesting that the product chromosome (the set
of design characteristics) should be seen as a basic map, on which the progress of the design
Figure 1: Entity-Relationship diagram for design specication.
Design Specification
Requirement
Identity
Name
Description
IssuedBy
ApprovedBy
Version
Status
CreationDate
ChangeDate
Requirements Class
Identity
Name
Description
IssuedBy
ApprovedBy
Version
Status
CreationDate
ChangeDate
Value
Category
Direction
Importance
Competitor assessment
Stakeholder
Responsible
Origin
Referenced Documents
IsDeltaSpec
BelongsTo
HasMetadata
HasMetadata
Referenced Documents
HasAttributes
HasAttributes
ConsistsOf
ConsistsOf TradeOff
InfluencedBy
process is chartered. When the design is finalized, all design characteristics will have been
established but the sequence of the design activities, which are described as navigations on the
map, is not prescribed. We have in earlier work [Malmqvist 1995b] argued that this property
and the fact that the causal relationships constitute the genetic information of the system makes
the chromosome model well suited as a basis for a design history system. Particularly, the
benefits of using an extended function-means tree as a tool for design history representation
were put forward in that paper. We are further expanding on that basis here.
Having clarified the contents of the design specification and of the product model we may now
proceed to discuss the relationships between the specification and the product model. We
suggest that at least four principally different relationships can be identified:
Measures relationships. The most obvious link between the design specication is when
the performance of the design is to be evaluated against a requirement. This type of relation
will then link a requirement and a property model that is used to assess the actual value of
the property. A property model may in this context be a computational procedure, a experi-
mental test or a subjective assessment. The utilization of this kind of relation facilitates
checking that a design meets its requirements by comparing the desired and actual states of
the properties. Alternatively, a value function could be used to grade the design according to
some scale.
CorrespondsTo relationships. Some items of the design specication directly corresponds
to elements in the product models. For instance, this applies to functions stated in the design
specication that have direct correspondents in the function-means tree and the function
structure of the product model. This relationship may also link a design specication item to
a solution element (means/organ/component) if the design specication states that a
particular design solution should be used (carry-over, design re-use). While such
requirements are not recommended in the design methodology literature, which states that
requirements should be given solution-neutral formulations, they are common in practice.
RequirementsOn relationships. In general, a design decision, e.g., the selection of a
particular means to solve a certain functional requirement, will generate new requirements
to support the means, to connect the means to other means or to compensate for negative
effects caused by the means (e.g., noise). It is then important to keep track of this
dependency so that if the means is (ex)changed, its generated requirements will also be
(ex)changed. The inclusion of RequirementsOn relationships in the model enables the
detection of such requirements.
IsSolvedBy relationships. IsSolvedBy relationships link a requirement and the means that
has been chosen to satisfy the relation. Note that this kind of relation may also be
represented via the function-means tree.
The resulting product information model is shown in figure 2 as an Entity-relationshipship
diagram. Including the design specification data into this model simplifies the verification of
requirements and the analysis of the consequences of requirements changes. Moreover, this
kind of integrated product model is an important basis for concurrent engineering by providing
a shared representation of the evolving design for team members.
4 Implementation
In order to verify and experiment with the ideas expressed in the previous sections, a prototype
design system has been developed. The aim of this system is to provide an environment for
experimentation with design methods based on design theory. While the implementation of this
system is not complete, the main framework exists [Malmqvist 1995a]. The emphasis is placed
on verification of theories for managing the information created during the design process rather
than on creating a working system for synthesis, which would require a larger knowledge base.
METIS Software [NCR Norge A/S 1996], a general tool for developing systems for managing
complex information structures, was used to implement the system. METIS provides a generic
set of system modelling concepts and operations. Object-oriented techniques (type hierarchies)
are then used to create objects, relationships and methods tailored to a particular situation. The
objects are defined by attributes and methods, and may also include so-called information
elements which contain references and parameters to invoke external processes and systems,
such as CAD or word processing programs. Information elements can also be scanned pictures
or refer to external database files. This enables the construction of very heterogeneous and
complex models. System models can be visualized and edited in network, as well as matrix
fashion as indicated in fig. 4. A hierarchic visualization is also available.
The system has been tested on a number of problems, some originating from industry. The tests
have demonstrated the feasibility of the approach, though there is a need for further verification.
Figure 2: Entity-Relationship diagram for design specication and product model.
Requirement
ConsistsOf
ConsistsOf
TradeOff InfluencedBy
ConsistsOf
ConsistsOf
Process structure
ConsistsOf
ConsistsOf
ConsistsOf
Function structure
Organ structure
Component structure
Means
HasInfluenceOn
I
s
S
o
l
v
e
d
B
y
H
a
s
A
l
t
e
r
n
a
t
i
v
e
R
e
q
u
i
r
e
m
e
n
t
s
O
n
ProcRelation
FuncRelation
OrganRelation
CompRelation
C
o
n
t
r
i
b
u
t
e
s
T
o
M
a
t
e
r
i
a
l
i
z
e
d
B
y
I
s
S
o
l
v
e
d
B
y
R
e
q
u
i
r
e
m
e
n
t
s
O
n
N
e
e
d
s
E
f
f
e
c
t
s
N
e
e
d
s
P
r
o
c
e
s
s
Func Req Objective Constraint Evaluation
Property value
Test procedure
Computational model
Subj assessement
Uses
I
s
D
e
t
e
r
m
i
n
e
d
B
y
ConsistsOf
ConsistsOf
B
a
s
e
d
O
n
Measures
R
e
q
u
i
r
e
m
e
n
t
s
O
n
I
s
S
o
l
v
e
d
B
y
CorrespondsTo
C
o
r
r
e
s
p
o
n
d
s
T
o
C
o
r
r
e
s
p
o
n
d
s
T
o
C
o
r
r
e
s
p
o
n
d
s
T
o
PROPERTIES PRODUCT CHROMOSOME
DESIGN SPECIFICATION
FUNCTION-MEANS TREE
Lifephase system
LIFE-PHASE SYSTEMS
As an example, consider fig 4 which shows a design specification and a product model for an
expansion tank, used to maintain a constant water level in an automobile engine cooling system.
The figure illustrates a scenario of tracing the relationships between a requirement and the
components that realizes the requirement (function). The basic question is: Which components
will be affected by a change to a certain requirement? (or vice versa). In this case, the
requirement that designer chooses to examine is that the expansion tank system should alert the
driver when the water level is lower than a certain level (1). The designer could then follow the
CorrespondsTo relation to the function-means tree to learn that the alert function is triggered by
an electrical switch and that it also requires a supporting function: transient oscillations in the
water level need to be dampened out or else false alerts may result. This is solved by dampening
ribs (2). For further insight into the context of the requirement the designer could follow links
to the function structure (3) and the organ structure (4). The organ structure is linked to the
component structure (5). By this traversal, it is shown that a change to the alert driver
requirement may lead to changes to two component (structures), namely the indicator assembly
and the expansion tank, since the latter houses the dampening ribs. It is further evident from the
figure that overall structure of the models become quite complex, and that navigating in the
information may be difficult. However, the ability to visualize system relationships in matrices
is very helpful when analyzing system structures. As an example, a matrix depicting the
relationships between the organ and component structures is shown. Such a matrix can be used
to analyze the amount of function sharing in the system. It also makes it clear that a changes to
the expansion tank may affect almost all of the functions in the system, as there is a (almost)
one-to-one mapping between the functions and organs. Similar matrices are available in the
system for analysis of any kind of relationships in or between system models
5 Related work
The framework proposed in this paper is based on the chromosome model developed at TU
Denmark by Andreasen [1992] and co-workers. Design specifications in relation to this model
have been adressed by Svendsen & Thorp Hansen [1993]. The present paper builds on that work
by connecting the design specification to the different parts of the chromosome model This
work further contributes with an implementation that can be used as a test-bed for experimen-
tation with product models based on the chromosome framework. This is in our opinion crucial
as the chromosome model leads to large and complex product models. Such models are difficult
to record, keep updated and analyze on paper. An important precondition for testing utilizing
the chromosome model in full is therefore that there exists enabling computer support. The
current system can also be compared to systems aimed at supporting Systems Engineering, such
as RDD-100 [Ascent Logic 1996]. This system also enables traceability from requirements to
functions, and from functions to components. However, its terminology is limited from a
(mechanical) design methodology viewpoint: RDD-100 does not distinguish between organs
(function carriers) and components and there is no correspondent to the function-means tree
employed here as a design history representation. We argue that the same argument may be
employed for comparisons between the current system and such that are based on QFD - the
current system has a richer vocabulary for supporting design work. Finally, the current system
is also related to work that has aimed at developing computational support for conceptual design
(Tomiyama et al. [1994]; Sharpe [1996]). While these systems provide more powerful support
for synthesis than the current, by including design solution libraries, the design specification is
not adressed in detail in these works. Rather, the problem is stated as a function (structure).
While this may be sufficient for guiding the search for solutions during conceptual design, a
more comprehensive approach towards design specifiations is needed if the system shall be
used also during the latter design phases
6 Conclusions
The inclusion of the design specification in a integrated product model has benefits in terms of
increased traceability of design decisions and simplified redesign due to requirements changes.
To achieve this, the contents of the design specification and the relationships between the rest
of the product model needs to be adressed. The contents of the design specification are well
described in the design methodology literature. The relationships, however, are not equally well
treated in the literature. In this paper, four relation types are identified and have been
implemented in a product modelling system. The paper demonstrates through an example how
the proposed product model traces a design decision from a requirement through the function-
means tree and further to an individual component.
Figure 3: Trace from a requirement to its realizing components.
Expansion tank component structure
Coolant
Pressure
cap
spatial
relation
t
spatial
relation
from
Expansion
tank
spatial
relation
t
spatial
relation
from
energy
flow to
energy
flow
from
spatial
relation
t
spatial
relation
t
Hose
spatial
relation
t
spatial
relation
from
spatial
relation
t
material
flow to
material
flow
from
Hose
spatial
relation
t
spatial
relation
from
spatial
relation
t
material
flow to
material
flow
from
MVD
relation
from
MVD
relation
from
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
Indicator
assembly
spatial
relation
t
spatial
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
Design Specification
Environment
Weight
Maintenance
Aesthetics,
appearance
& finish
Materials
Life in
service
Quality &
reliability
Safety
Processes
Manufacturing
facility
Packing
Shipping
Installation
Quantity
Target
product
cost
Disposal Competition
Product
life span
Market
constraints
Shelf life
(storage)
Time-scales Legislative
requirements
Standards
&
specifications
Documentation
Political &
social
implications
Patents,
literature
& product
data
Total
system
performance
specification
Interfacing
&
geometric
requirements
Testing
Function structure
Organ structure
Component structure
Function Means Tree
Maintain constant water level in cooling system
Expansion tank systemsolved by solves
Enable coolant refill Maintain constant water level Enable inspection of water level
Enable open/closed lid Connect to maximum level area
requires
is required by
requires is required by
requires
is required by
Refill opening - above maximum water level solved by solves
requires
is required by
requires
is required by
Lockable lid solved by solves Tube connection solved by solves Tube connection CAD model
FM Tree RM
. Means
Requirements
FM SS use used by
X-axis consist of
part of X-axis in
Y-axis consist of
part of Y-axis in
Expansion tank solved by solves
Enable input from high pressure section Store pressurized fluid De-air water Enable output to low pressure section Manage internal pressure overflow
requires
is required by
requires
is required by
requires
is required by
requires
is required by
requires
is required by
Tube connection Pressure tank Slow steady flow Tube connection Pressure valve solved by solves solved by solves solved by solves solved by solves solved by solves
Enable off-line inspection Alert driver if low water level detected when driving
Transparent wall between mimimum and maximum levels Electrical indicator at minimum level solved by solves solved by solves
Connect to system section with minimum water level Change electrical state when low water level detected Stabilize measured water level
requires is required by requires is required by requires is required by
Req to functions
P_0 Preparation process
Expansion
tank
system in
prepared
state
W_0 Working process
P_1 Inspect current water level
P_2 Open lid P_3 Fill expansion vessel system with water P_4 Close lid
Expansion system water level
Expansion vessel: State: lid open, non-filled Expansion vessel; State lid open, filled
Expansion vessel system Water Expansion vessel; State: lid closed, filled
Required water level
W_1 Vary water level
W_2 Channel water from high-level section
W_3 Detect if water level <= minimum W_4 Detect pressure overflow
W_5 De-air water
W_6 Alert driver
W_7 Channel through pressure valve Water level
Water level Water level
Low water level signal Open pressure valve signal
W_8 Store pressurized water and air W_9 Channel water to low-pressure section
Water level
Expansion vessel system Water level-affecting perturbations Water level
Low water level signal to driver Excess water Water to low pressure sections
Expansion vessel system
OS RM
.. Organ
Organ
OS RM SS use used by
Expansion tank component structure
Coolant
Pressure cap spatial relation t spatial relation from
Hose clip
Hose clip
Expansion tank spatial relation t
spatial relation from energy flow to
energy flow from
spatial relation t spatial relation from
spatial relation t
spatial relation from
Hose spatial relation t spatial relation from
spatial relation t spatial relation from material flow to
material flow from
Hose spatial relation t
spatial relation from
spatial relation t
spatial relation from material flow to material flow from
CS RM
- Component
Component
CS SS
use
used by
X-axis consist of
part of X-axis in
Y-axis consist of
part of Y-axis in
Customer
Ergonomics
MVD relation to
MVD relation to
MVD relation to
MVD relation from
MVD relation from
PS-OS-RM
PS-OS-PAT Organs
Functions
PS-OS-SS
use
used by
X-axis consist of
part of X-axis in
Y-axis consist of
part of Y-axis in
Y-axis consist of
part of Y-axis in
requirement to
from requirement from requirement
MVD relation to
MVD relation from MVD relation from
MVD relation from
OS-CS-RM
+ Components
Organs
OS-CS-SS
MVD relation from
MVD relation from MVD relation from
MVD relation from
MVD relation from MVD relation from
MVD relation from
MVD relation from
MVD relation from
MVD relation from
MVD relation from MVD relation from
Indicator assembly spatial relation t spatial relation from MVD relation from MVD relation from
X-axis consist of
part of X-axis in
Y-axis consist of
part of Y-axis in
Properties
Pressure
cap
opening
pressure
evaluation
Pressure
cap
opening
pressure
test
MVD relation to
MVD relation from
MVD relation to
MVD relation from
Impact
resistance
test
Dynamic
pressure
test
Static
resistance
to
pressure
test
Burst test
Burst
evaluation
MVD relation to
MVD relation from
Ageing
test
Thread
strength
test
Level
indicator
tests
from requirement
from requirement
from requirement
Sealed hole in tank Electrical switch mechanism Ribs solved by solves solved by solves solved by solves MVD relation to
MVD relation from
MVD relation from
Y-axis consist of
part of Y-axis in
X-axis consist of
part of X-axis in
use
used by
MVD relation from
Performance
Main function
The function of
the expansion
vessel is to work
as an expansion
volume for the
engine cooliing
system
Refilling function
The expansion
vessel should be
refillable
Enable water
level inspection
Alert driver if
water level <=
minimum
Minimal leakage
requirement
to
requirement
to
requirement
to
requirement
to
Alert driver if low
water level
detected when
driving
Electrical
indicator at
minimum level
solved
by
solves
Connect to
system section
with minimum
water level
Change electrical
state when low
water level
detected
Stabilize
measured water
level
requires
is
required
by
requires
is
required
by
requires
is
required
by
from
requirement
Sealed hole in
tank
Electrical switch
mechanism
Ribs
solved
by
solves
solved
by
solves
solved
by
solves
MVD
relation
from
MVD
relation
from
1
5
3
4
2
Acknowledgements
Mitchell Tan Gin Teck is acknowledged for work on a prototype version of the current system
[Gin Teck 1995].
Figure 4: Component structure for expansion tank as a network structure , with attached drawing. The
component structure shown here is a subset of the total model shown in g 4.
Figure 5: Relationship matrix between the organ and component structures.
Expansion tank component structure
Coolant
Pressure
cap
spatial
relation
t
spatial
relation
from
Hose clip
Hose clip
Expansion
tank
spatial
relation
t
spatial
relation
from
energy
flow to
energy
flow
from
spatial
relation
t
spatial
relation
from
spatial
relation
t
spatial
relation
from
Hose
spatial
relation
t
spatial
relation
from
spatial
relation
t spatial
relation
from material
flow to
material
flow
from
Hose
spatial
relation
t
spatial
relation
from
spatial
relation
t
spatial
relation
from
material
flow to
material
flow
from
p
X
in
p
Y
in
MVD
relation
from
MVD
relation
from
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
Indicator
assembly
spatial
relation
t
spatial
relation
from
MVD
relation
from
MVD
relation
from
MVD
relation
from
Drawing attached
to expansion tank
object
+
Components
Organs
E
x
p
a
n
s
i
o
n

t
a
n
k
c
o
m
p
o
n
e
n
t
s
t
r
u
c
t
u
r
e
C
o
o
l
a
n
t
P
r
e
s
s
u
r
e

c
a
p
H
o
s
e

c
l
i
p
H
o
s
e

c
l
i
p
E
x
p
a
n
s
i
o
n

t
a
n
k
H
o
s
e
H
o
s
e
I
n
d
i
c
a
t
o
r

a
s
s
e
m
b
l
y
Expansion
vessel system
Refill opening
Lockable lid
Tube connection
Expansion
vessel
Tube connection
Pressure tank
Slow steady flow
Tube connection
Pressure valve
Transparent wall
Electrical level
indicator
Sealed hole in tank
Damping ribs in tank
Indicating mechanism
References
Akao, Y., Quality Function Deployment. Integrating Customer Requirements into Product
Design, Productivity Press, Cambridge, MA, USA, 1990.
Andreasen, M. M., Designing on a Designers Workbench (DWB), Proceedings of the 9th
WDK Workshop, Rigi, Switzerland, 1992.
Ascent Logic Corp., Introduction to RDD-100, version 4.1, San Jos, CA, USA, 1996.
Gin Teck, M. T., Computer Tool for Design Specification Modelling, Technical Report,
Machine & Vehicle Design, Chalmers University of Technology, Gteborg, Sweden, 1995.
Hubka, V. and Eder, W. E., Theory of Technical Systems, Springer-Verlag, Berlin, 1988.
Malmqvist, J., A Computer-based Approach Towards Including Design History Information
in Product Models and Function-Means Trees, Proceedings of DTM-95, Boston, 1995a, pp
593-602.
Malmqvist, J. Improved Function-Means Trees by Inclusion of Design History Information,
Proceedings of ICED-95, Praha, Czech Republic, 1995b, pp 1415-1423.
Mortensen, N. H., Andreasen, M. M., Designing in Interplay with a Product Model - Explained
by Design Units, Proceedings Tools and Methods for Concurrent Engineering, Budapest,
1996.
NCR Norge A/S, Metis Users Guide, version 1.9.1, Horten, Norway, 1996.
Otto, K. N., Forming Product Design Specifications Proceedings of the 1996 ASME Design
Engineering Technical Conferences, Irvine, CA, USA, 1996, Paper No 96-DETC/DTM-1517.
Pahl, G. and Beitz, W., Engineering Design, 3rd edition. Springer-Verlag, Berlin, 1995.
Pugh, S., Total Design, Addison-Wesley, Wokingham, 1991.
Roozenburg, N. F. M. and Eekels, J., Product Design Fundamentals and Methods, Wiley &
Sons, Chichester, 1995.
Sharpe, J. E. E., Integrated Platform for AI Support of Complex Design - Part I & II,
Concurrent Engineering - Research and Applications, Vol. 3, 1995, pp 295-318.
Svendsen, K.-H. and Thorp Hansen, C., Decomposition of Mechanical Systems and
Breakdown of Specifications, Proceedings of ICED-93, Den Haag, The Netherlands, 1993, pp
119-126.
Tomiyama, T., Kiriyama, T. and Umeda, Y., Towards Knowledge Intensive Engineering,
Proceedings of the 1994 Lancaster International Conference on Engineering Design, Lancaster,
1994, pp 319-338.
Ulrich, K. T. and Eppinger, S. D., Product Design and Development, McGraw-Hill, New York,
1995.
Dr Johan Malmqvist
Chalmers University of Technology
Machine & Vehicle Design
S - 412 96 Gteborg
Sweden
tel: +46 - 31 - 772 1382
fax: +46 - 31 - 772 1375
e-mail: joma@mvd.chalmers.se