This paper will be included in the Proceedings of Design Theory and Methodology { DTM '95 {, ASME, 1995.

REPRESENTATION OF DESIGN OBJECTBASED ON THE FUNCTIONAL EVOLUTION PROCESS MODEL
Yoshiki Shimomura

Mita Industrial Co,. Ltd.
Chuo-ku, OsakaJapan
Hideaki Takeda

Graduate School of Information Science
Nara Institute of Science and Technology
Ikoma, NaraJapan
Masaharu Yoshioka, Yasushi Umeda, Tetsuo Tomiyama
Department of Precision Machinery Engineering
Graduate School of Engineering, The University of Tokyo
Bukyo-ku, TokyoJapan
ABSTRACTOne of the crucial issues for developing computer
aided conceptual design system is representation offunctions which represent designers' intention. Representing functions is also crucial not only for representing
design objects but also for describing conceptual design
processes, in which designers operate mainly functional
concepts. Namely, function is a key concept to integrate
object modeling and process modeling in design.
In this paper, rst we extend the FBS (FunctionBehavior-State) diagram, which we have already proposed, by introducing three additional concepts for representing a function; namely, function body that represents designers' intention directly, function modi erthat quali es a function body, and objective entity on
which the function body occurs. This extended FBS
diagram, called FBS/m (modi er) diagram, enables us
to represent designers' intention more precisely thanthe original FBS diagram. Then, we propose an FEP(Functional Evolution Process) model to represent design processes. In the FEP model, the FBS model of adesign object is evolved through three steps, i.e., functional actualization, functional evaluation and functional operation. Functional actualization depicts a process to obtain physical descriptions from functional description. Functional evaluation is a process to measurerealizability of functions of the design object. Functional operation is a process to operate functions to improve the design. Based on the FEP model, we analyze
some actual design processes, and show that the FEP
model is suitable for representing designers' intention
along with design processes.
INTRODUCTION

One of the crucial issues for developing computer aided
conceptual design system is representation of functions
which represent designers' intention. Function is a key
concept in design, because ideally design produces adesign object that ful lls with the required functions(Takeda et al., 1990b). Although function is a wellknown concept, its de nition is unclear.
The objective of our research is to establish a method
for aiding conceptual design and to develop computer
aided conceptual design system that realize more natural computer supports in design processes by representing a functional evolution process of design objects.
Design is a process in which a representation of a design object which includes functions is gradually rened: this is called functional evolution. Recording
functional evolution is critical to preserve designers' intentions which is one of the core issues for developing
advanced CAD systems and for designing functionallyinnovative products.
We rst discuss properties of function that we want
to deal with and roles of function in design. Second, we
describe the FBS (Function-Behavior-State) modeling(Umeda et al., 1990), and introduce related functional
concepts, i.e., function body, objective entity, and function modi er. Third, we propose the FEP (Functional
Evolution Process) modeling to model a design process
in which a model of design object is gradually evolved
by applying functional realization, functional evaluationand functional operation iteratively. Finally, we represent some design examples in the FBS and FEP schemes
and analyze the results.
ROLES OF FUNCTION

We consider that a function has the following threeroles in a design process. Figure 1 depicts the relationships among these three roles.
A. Required speci cations
The designer speci es the requirements in termsof functional concepts. Therefore, function should
represent designer's intention given as the requirements.
B. Design object representation
Functional concepts describe a design object thatcan satisfy the requirements. The physical description of the design object should be associated withthe functional description.
C. Evaluation
The designer evaluates the design object from thefunctional view point. Function should be evaluated qualitatively or quantitatively in order tomeasure how much designer's intention is satis ed.
In order to help designers to conduct design that focuses more on function that has these three roles, we
propose two schemes for representing function. One is
the FBS/m (m stands for modi er) diagram and the another is the Functional Evolution Process (FEP) modelthat represents how function is operated in the design
process.
MODEL OF FUNCTION

In above chapter, we discussed roles of function indesign. In this chapter, we propose a model of function
for object modeling.
There are many approaches to represent function (e.g., (Roth, 1982) (Pahl and Beitz, 1984)), butthere is a common problem that function and behavior are often confused and mixed each other(Ulrich and Seering, 1988) (Iwasaki et al., 1993). For
instance, behavior can be de ned objectively as transitions of physical states and therefore can be derived

Designers' intention
Role C

Role A

FunctionRole B

Physicalobject representation

Figure 1: Three Roles of Function in Designfrom physical states of an entity and its environment.
However, function is related not only to physical behavior but also to the designers' perception of behavior.
For example, regarding function of a car, one may say
one of its functions is \moving" and others \carrying,"
even if they observe the same behavior. Therefore, we
represent functions based on the FBS diagram in whicha function is represented as an association of the designer's intention and a behavior that can actualize thisfunction (Umeda et al., 1990).
However, while the FBS diagram satis es the roleB (design object representation), the roles A (required
speci cation) and C (evaluation) are not fully satis ed.
Functional representation in the FBS diagram is limited to the form \to do something," and its evaluation
just tells whether or not the function can be performed
qualitatively but not the degree of the performance. In
this paper, we propose an FBS/m diagram as a representational scheme of function by extending the FBS
diagram.
FBS modelingIn the FBS modeling, a state of a design object isrepresented by entities, attributes of the entities, andrelations among entities. While entities are identi ers,
attributes of the entities and relations among entities
represent their states and structures. Then, a behavior is de ned as \sequential changes of states." In thephysical world, changes of states are governed by physical laws. We call this set of de nitions of state andbehavior view point that is a basic unit of object representation. A view point consists of de nitions of terms(entities, attributes, and relations) and rules (physicallaws). A designer has various kinds of view points from

Function Set: function
F-B Relationshipfunction A
decomposed-intofunction B

function C

Behavior Set: behavior: behavior sequence
B-S RelationshipPhysical Laws

VIEW POINT

Structure Set: state: state change

Figure 2: Relationship among Function, Behavior, andState (Umeda et al., 1990)
well-de ned ones (e.g., rigid body dynamics) to ill- orvaguely-de ned ones (e.g., manufacturability).
We de ne a function as \a description of behavior
abstracted through recognition of behavior for utilization." In other words, while a behavior is an objective
concept grounded on states and described within an
view point, a function is subjective concept related tobehaviors (see Figure 2).
We de ne structure of function as follows. A function is represented as combination of a function body,
objective entities, and function modi ers. A function
body is a symbol that carries meaning of the function.
A typical function body is a verb word like \to move"or \to carry." We often call a function body to mean afunction for short in this paper. An objective entity isan entity that a function occurs on. It should be speci ed in the state level before the design terminates. A
function modi er is a symbol that details the function
body. A typical function modi er is an adverb word
like \precisely" or \ rmly." The di erence between afunction body and a function modi er in terms of functional evaluation that will be described later is the typeof value given by the evaluation. A function body has arelation to its actualizing behavior and is evaluated ina binary manner, that is, a function body is evaluatedwhether or not it exists in a design object by using therelation. On the other hand, since a modi er includes
parametric conditions given by the designer, it is evaluated how much the modi er is achieved in the design
object quantitatively.
Relations among functions

Based on the structure of the function, we here
introduce four kinds of relations among functions;
i.e., decomposed-into, conditioned-by, enhanced-by, anddescribed-as relations.

behavior B
state Bbehavior C
state C

Figure 3: Evolution by Decomposed-into Relation
conditioned-byfunction B
behavior B
state Bfunction A
behavior A
state A

Figure 4: Evolution by Conditioned-by Relation
Decomposed-into relation This relation indicatesthat a function body is decomposed into subfunction bodies (see Figure 3).
Conditioned-by relation This relation denotes thata new function body B is needed to actualize afunction body A. In other words, the function
body B is necessary condition for the function
body A. This relation should be supported bycausal relation in the behavior level (see Figure 4).
Enhanced-by relation This relation denotes that a
new function body B is needed for satisfying amodi er A1 of function body A (see Figure 5).
In this case, though the function body B is nota necessary condition for the function body A, it
is assumed that the modi er A1 is achieved betterby adding the the function body B.
Described-as relation This relation denotes that amodi er is detailed into one or more concrete modi ers (see Figure 6).
FUNCTIONAL EVOLUTION PROCESS(FEP)As described in above chapter, we clari ed functional
representation of a design object; that is, functionaldescription is an intentional representation, while behavior and state are objective representation. In thisenhanced-byfunction B
behavior B
state B

modifier A1function A
behavior A
state A

Figure 5: Evolution by Enhanced-by Relation
described-asmodifier B
function B
behavior B
state B

modifier A
function A
modifier C
function C
behavior C
state C

Figure 6: Evolution by Described-as Relation
chapter, we focus on how to operate functions in thedesign process.
Steps of Functional Evolution Process

One of the three roles of function is to describe required speci cations. However, requirements are notcomplete at the beginning of a design process, and therequirements are also detailed as the object descriptions. In other words, functional descriptions of a design object are gradually re ned and detailed as thedesign proceeds. We call this functional detailing process of a design object a functional evolution process.
A step of the functional evolution process is described by functional description, functional actualization, and functional evaluation. Functional descriptionof a design object is revised by the designer at each stepof the process. In the FEP (Functional Evolution Process) model, we represent revisions of the functionaldescription with functional operations. A functional
operation includes operations to modify functional description, i.e., adding new functions, function modiers, or functional relations. Functional actualizationand functional evaluation proposes and justi es adding
functions, functional modi ers, or functional relations,functionbody A

function body A

functionbody Bfunction body A
function body A

function body B

function body B

function body A

modifier M

A : complement of A

Figure 7: Di erence between Function Body and Modi er
respectively.

Functional Description, Functional Actualization,
and Functional Evaluation

Functional description is the step in which a designer
describes required speci cations of the design object
with function bodies, objective entities, and function
modi ers. Functional actualization corresponds to thestep to obtain behavioral description from the functional description by using the knowledge about function. We have proposed a function prototype as theknowledge about function for functional actualization(et al., 1993). Functional evaluation means con rming
functional description with behavioral description andestimates how intended functions are satis ed by the
proposed behavioral description.
As described in above chapter, a function body isevaluated in a binary manner (et al., 1993). However,a designer judges how much a function is achieved in
the design object and compares two design candidate
solutions with respect to the degree of satisfaction of
the speci cations. This kind of evaluation is executedfor the parametric conditions described in the function
modi er of the FBS/m diagram.
However, since this kind of evaluation tends to be
subjective, it is not easy to describe the relationshipbetween the parametric conditions and the degree offunctional satisfaction. To deal with this kind of subjective relationship, we have proposed amount of function,
which is de ned by probability distribution of subjective evaluation of a physical parameter that characterizefunction modi ers (Shimomura et al., 1994).
Functional Operation

The main task of a functional evolution process isto obtain a new functional description, which is represented with the functional operations in the FEP model.

We de ne the following six kinds of functional operations in this model. These six kinds of operations can
be classi ed into two types according to whether or not
functional relations are added by each operation. One
type includes four kinds of operations each of which
generates decomposed-into, conditioned-by, enhancedby, and described-as relations, respectively. The othertype includes two kinds of operations that do not generate functional relations; namely, discovery of functions
and discovery of modi ers.
We use the example of the FBS/m diagram shownin Figure 8 for explaining each functional operations.
Figure 8 shows a result of an experimental designof a weighting scale obtained by design experiments(Takeda et al., 1990a).
1. Adding functional relations
Decomposed-into operation It is an operationin which a designer decompose a function
body into sub-function bodies for detailing it.
As a result, a decomposed-into relation andsome sub-function bodies are added to the
FBS/m diagram.
In Figure 8, for example, the function body\to visualize weight" is decomposed into function bodies \to convert weight into displacement" and \to convert displacement and visualize" and a decomposed-into relation among
these function bodies is also added.
Conditioned-by operation When the designernds out that an actualizing behavior for
function body A is inadequate to occur, thisoperation is executed to add behaviors necessary for actualizing function body A as follows(see Figure 4):(a) The designer nds out behavior A associated to the given function body A.
(b) He / she nds out that behavior A will
not occur and another behavior B isneeded to cause behavior A by using
causal simulation (Ishii et al., 1993).
(c) Finally he / she adds a function body B
associated to the derived behavior B (seeFigure 4) in order to explain why behavior B is attached.
As a result of this operation, a conditionedby relation, a behavior, and a function bodyfor explaining why the original behavior isconditioned by the new behavior are added.
In Figure 8, for example, the designer
found out from mental simulation that thefunction \to translate linear displacement into
rotational displacement," of which actualizing

structure is \a rack & a spiral gear," is insucient. Therefore, the designer added another actualizing structure \a lever" to use\the rack & the spiral gear" e ectively. Thisbehavior is then recognized as a function \totranslate spring displacement into linear displacement" by the designer.
Enhanced-by operation When the designer nds out that a modi er is not actualized enough, e.g., by executing the functional
evaluation, this operation is executed. This
operation generates an enhanced-by relation,a function body related by this relation, anda behavior actualizing the generated function
body (see Figure 5).
This operation is typically executed as aresult of functional evaluation. When a behavior is proposed to actualize the function A,
the designer can evaluate this behavior using
a functional modi er A1 attached to function
A. Namely, functional modi er A1 is used
for showing how much function A is satis edwith the proposed behavior to the function A.
Then the designer would add another function
B in order to increase the value of the function A. In other words, this new function B
realizes functional modi er A1.
In Figure 8, a function \to enumerate rotation" is actualized by the \rotation plate."
The designer examines whether or not the rotation plate can actualize the function withthe functional modi er \as large as possible." Then the designer nds out that anotherfunction \to enlarge an indicator" is neededto achieve the functional modi er adequately.
The evaluation of the functional modi er isessential to encourage the designer to nd out
additional functions in this type.
Described-as operation After a decomposedinto operation, this operation is typically executed in order to detail a functional modi er
into one or more concrete functional modiers. When a function body with functionalmodi ers is decomposed into some function
bodies, these sub-function bodies cannot be
evaluated precisely without functional modiers; so, the designer interprets the modi er
for the super-function body into those of the
sub-function bodies. As a result of this operation, a described-as relation and some functional modi ers for sub-function bodies areadded (see Figure 6).
In Figure 8, for example, the functionalDs

M1: comfortably
M2: easy to see
M3: precisely
Ds
M4 : continually

to visualize weight

D

Ds

Ds

to convert weight into displacementD

M9: repeatedlyED

to convert displacement
and visualizeDD

to return
initial state

D

(M9)

to translate weight into
displacement

M5: comfortably

to receive vertical weight

C

Ds

C

to numeraterotationto translate liner disp.
into rotation displacement(M6)

to translate vertical disp.
into horizontal disp.

to guideE (M5)
to make foot touch spring
betterM6: as large as possible

M6: as large as possible
M7: tightly
M8: along with looking direction

to translate spring disp. E
into liner displacement (M8)E

to enlarge
a indicatorrotation
plate

lens

E

(M6)

cradleplate
spring
Mn: modifier nameresinfunction nameto enlarge rotation
lever

Ds: described-as

E

(M7)

to control backlash

rack &
spiral gear

relation typestate
(structure)

D: decomposed-into
C: conditioned-by
E(Mn): enhanced-by(related modifier)helicalgear

Figure 8: Functional Evolution in Design of a Weighting Scalemodi er \comfortably (M1)" of the function\to visualize weight" is detailed into threefunctional modi ers; namely, \comfortably(M5)" of the function \to receive verticalweight," and \as large as possible (M6)" and\along with looking direction (M8)" of thefunction \to translate linear displacement into
rotation displacement." Each of which is considered as a more concrete functional modi erthan \comfortably (M1)."
2. Discovery of functions and modi ers
Discovery of functions The designer nds out
new functions from existing behavioral descriptions. First, the designer proposes a new
behavior as actualization of the given function. Then, functional evaluation may show
functions other than the designer noticed, because the designer speci es only those necessary functions. These functions can be included in the functional description if they aredesirable.
Discovery of modi ers The designer also nds
out new modi ers from existing behavioral

descriptions. When it is found that a newly
proposed behavioral description may have advantages or disadvantages compared with theprior description by executing functional evaluation, the designer adds modi ers to the
FBS/m diagram in order to describe these advantages or disadvantages if the designer considers useful.

ANALYSIS OF AN ACTUAL DESIGNPROCESSIn this chapter, we analyze an actual design processof a photocopier using the FBS and FEP schemes.
Modeling Method

First, we collected the documents and the technicaldrawings about a photocopier and interviewed with thedesigners to complement these documents. Then, we
extracted FBS elements, namely, functions, function
modi ers, behaviors, and states according to the following criteria.
Function Body and Objective Entity We
regarded verbs that explain the design object asFunctionModel 1

FunctionModel 2

FunctionModel 3

FunctionModel 4

F Model 1

F Model 2

F Model 3

F Model 4: functional evolution: structure evolution

S Model 1

S Model 2

StructureModel 1

StructureModel 2

S Model 4:FS model

StructureModel 4

StructureModel 5

S Model 3

StructureModel 3

Figure 9: Combination of Function and Structure Models
function bodies. We picked up verbs as function
bodies and objective words as objective entities.
Function Modi er We interpreted adverbial phrases
as function modi ers. Here, we also interpreted
explanations of functions (e.g., \along with looking
direction" in Figure 8) as functional modi ers.
Behavior and States Behavior is appeared when thedesigners invoke simulations. The problem is thatsuch simulation is often executed manually with
non-verbal actions. For example, the designers
simulate motion by operating physical objects,
with drawings or even mentally. However, because
in this design example the designers explained thephotocopier in terms of structure, we focused on
only the structure instead of behavior and state of
the photocopier. We traced revisions of the structural descriptions along the design process by observing their drawings and interviewing with them,and represented the structure instead of behaviors
used in it. Here, we represented the structures
symbolically by using entities, relations among entities, and attribute of entities.
After extraction of the FBS elements, we constructed
descriptions of the FBS model at each step of the design
process, which we call FS models. An FS(FunctionStructure) model consists of three elements that arefunction, structure, and functional relations. We represent the FEP model of this design process by tracing
the evolution of the FS models.
First, we modeled functions and function modi ers
at each step of the design process, in which functions
or function modi ers were added newly or changed, andstructure model

function modelf1
s18 lamp

s19 slit

f2

s21 reflector
s20 adjusting platef3
s22 motor
s23 wire & pulleys24 rodbar

f4
s26 crutch

f5

s25 dual drivef6
s30 mirror #1
f7

s31 mirror #2
s33 mirror #4

s32 mirror #3

s34 field lenss35 lens coverf8
s36 slit
time

Figure 10: Example of Evolution of FS Models
then ordered the function models linearly according to
the actual design process.
Second, we focused on the structures that the designers proposed in design. We modeled structures at
each step of the design process, in which structures wereadded newly or changed, and then ordered the structure
models linearly according to the actual design process.
A structure model was partially based on the earlierstructure models.
Finally, we could build an FS model at each step bycombining the function model and the structure model(see Figure 9). Figure 10 depicts the FS model of thephotocopier. Figure 11 shows examples of relations
among functions and structures as an FS model. In
gure 10, a symbol starting with f indicates a function
model, a symbol starting with s indicates a structure
model and its short explanation. An arrow indicates a
relation between structure models.
Analysis of the functional operations

In this chapter, we investigate how each function orfunctional modi er was developed in the design process.
Table 1 shows the numbers of appearance of functional
operation types.
Decomposed-into operation It has been claimed
that decomposition of functions is the most basic procedure to deal with functions in design(Pahl and Beitz, 1984). In this design, we found53 decomposed functions in this category.
Conditioned-by operation This is the procedure to
add functions needed to cause the existing functions. Since most of behaviors are implicit or nonverbal, it is dicult to nd such causal relations.
However by interviewing the designers, we found
10 functions in this category.
Enhanced-with operation In our model, converting modi ers into functions is achieved by adding
enhanced-by relations. An enhanced function isfound by evaluating the modi ers. The initial function model of this design had relatively a few functions and many modi ers. It implies that interpretation of those modi ers plays important role inthis design. In this design, we found 29 functionsin this category.
Described-as operation A typical procedure observed in this design process is adding modi ers
with described-as relations. This way to add modi ers gives more detail descriptions to other modiers. In this design, we found 30 modi ers in thiscategory.
Discovery of functions A new function is added byexamining a newly suggested structure model. It issimilar to decomposing functions, but added functions are auxiliary or unexpected functions so thatthey are not relevant to the existing functions. New
functions are found either by positive reasons or by
negative reasons. The former means that the proposed structure can satisfy an unexpected function,and the latter means that the proposed structure
cannot satisfy an unexpected function. In bothcases, a newly found function itself is added to thefunction model. Unless the structures used in thisdesign is well investigated or well known to thedesigners, it was not easy to discover this type offunctional operation. Therefore, in this design, we
could not nd any functions in this category.
Discovery of modi ers Figure 12 illustrates how
discovery of modi ers is executed. First, a function model and a structure model are provided as
the current model of the design object (see Figure12(a)). After executing functional evaluation bycomparing the function model with the structure
model, the designers suggest a new structure modelin order to realize the function model (see Figure12(b)). Then, behavioral simulation is executedfor this structure model, and a function model forthis structure model is created by functional operations (see Figure 12(c)). If the new function model
is considered better than the previous one, the newmodi ers representing the di erence are added to
the functional description of the design object. If
the new function model is considered worse, negation of the modi ers representing the di erence isadded by the designers (see Figure 12(d)).
It is interesting that adding modi ers for negative reasons appeared more frequently than ones
for positive reasons. It suggests that contradictionof function model and structure model is important to drive design (we have already discussed inconsistency in design process and modeled use ofinconsistency in design (Takeda et al., 1992)). In
this design, we found 9 modi ers in this category.
As we mentioned, there are relatively a few functions
and many modi ers in the initial function model of thisdesign. It means that operating modi ers is important
process to evolve function models.
CONCLUSION

In this paper, we discussed properties and roles of function in design and proposed a representational schemeof function which includes function bodies, objective
entities, and function modi ers. Furthermore we proposed the FEP (Functional-Evolution-Process) modelin which a design object is gradually evolved according to results of functional evaluation, and 6 types offunctional operation were de ned in the FEP model.
Finally we analyzed an actual design process based on
the FEP model. We can draw some remarks from thisanalysis.
1. Recording revisions of functions is indispensable to trace design processes.

M1: beautifuly
M2: effectively
M3: speedy
M4: exactly

Ds

Ds

Ds

to copy information on originals to plain papers

D

D

D

M6: uniformly
M5: effectivelyD

to translate light and shade on
original to distribution of optical intensity
M11:live longD

to transmit distribution ofDs
optical intensity
to generateD
E (M6)
light
M10:clearly
to raise luminance inE (M5)
to receive distribution D
specific direction
to balance amount of lightof optical intensity
to light up withD
distribution ofDDM9:exactly
optical intensity
to light up lineallylamplight adjusting reflector#
to relay distribution of
mirror 1
plate
optical intensity
to move lightEsourceholizentallyslit
DD
to light up thesurface of original

M7: effectively

D

E

D

D

(M9)

(M10)

to hold optical diffusion

to transmit driving power
M8: smoothly

to generate driving powerE

to keep distribution of lightintensity away unwanted lightto maintain optical path

M12:strongly

(M7)

E

to restrict direction of(M8)
movement to horizon
to stabilize light source unit 1

wire
pulleyto bring exposed
face close to plane

motor
dual drive

to stabilize
rotationrod- bar

field lensmirror # 2,3

slit

Mn: modifier namelens coverCmirror # 4

to move light source toinitial point

function nameDs: described-as

relation typestate
(structure)

D: decomposed-into
C: conditioned-by
E(Mn): enhanced-by(related modifier)Figure 11: An FS model of the Photocopier Design (Optical Part)
Existing research e ort mainly focused on revisionsof structures to clarify what happened in design
processes. However, recording functional descriptions is also necessary to clarify the designers' intention, and the FS model described in the analysis
is appropriate for this purpose, because revisions offunctions and structures are represented explicitly
in this model.
2. Function models are also results of design.
Not only the designed structure but also its functions the designers intended are results of design.
Here, the functions of a design object include not
only the requirements given by the designer at the
beginning of the design process but also functions
added by the functional operations and discoveries
during the design process.
3. Functional evolution is not magic but rational in most cases.
Designers often determine their own design criteria
in order to converge their design processes. Design-ers seem to have such criteria a priori, and such
criteria, which are represented as function modiers, are detailed more concretely by the designer
as a result of the functional evaluation in the FEP
model. One of the advantages of the FEP modelis that the reason the designer adds new functions
and modi ers is described explicitly.
Future works includes:- Applying the FBS and FEP schemes to actual design of photocopier by collaborating actual designers.
- Developing computer aided conceptual design system that can realize more natural computer supports in design processes and support designers to
execute innovative design.

REFERENCES

T. Tomiyama et al. A CAD for functional design. In
Annals of the CIRP '93, volume 42/1, pp. 143{146.
CIRP, 1993.

Function Model 1

Function Model 2

Function Model 2

Behavior Model 2

Structure Model 1

Structure Model 2

Structure Model 2

Structure Model 2

(a)

(b)

(c)

(d)

Figure 12: The Process of Discovery of Modi ers
Table 1: Numbers of Appearance of Evolutional Steps
Discovery of functions
by positive reasonsby negative reasonsby other reasons
Functions with be-decomposed-into relation
Functins with be-conditioned-by relations
Functions with be-enhanced-by relations
Discovery of modifiersby positive reasonsby negative reasonsby other reasons
Modifiers with be-described-as relations
Total

0
0
0
0
53
10
29
9
2
6
1
30
131

M. Ishii, T. Tomiyama, and H. Yoshikawa. A synthetic reasoning method for conceptual design. In
M.J. Wozny and G. Olling, editors, Towards WorldClass Manufacturing, IFIP Transactions B-17, pp. 3{
16, Amsterdam, 1993. IFIP, North-Holland.
Y. Iwasaki, R. Fikes, M. Vescovi, and B. Chandrasekaran. How things are intended to work: Capturing functional knowledge in device design. In Proceedings of IJCAI-93, pp. 1516{1522, 1993.
G. Pahl and W. Beitz. Engineering Design. The Design Council, London, 1984.
K. Roth. Konstruieren mit Konstruktions Katalogen.
Springer-Verlag, Berlin, 1982.
Y. Shimomura, H. Takeda, Y. Umeda, andT. Tomiyama. Representation of Design Objects Using
Functional Modi er. In Proceedings of Design Symposium 1994, pp. 58{62. JSPE (Japan Society for Precision Eng.), 1994. (In Japanese).
H. Takeda, S. Hamada, T. Tomiyama, andH. Yoshikawa. A cognitive approach of the analysis

of design processes. In Proceedings of Design Theory
and Methodology { DTM'90{, pp. 153{160. ASME,

1990.
H. Takeda, P. Veerkamp, T. Tomiyama, andH. Yoshikawa. Modeling design processes. AI Magazine, Vol. 11, No. 4, pp. 37{48, 1990.
H. Takeda, T. Tomiyama, and H. Yoshikawa. A logicaland computable framework for reasoning in design. In
D. L. Taylor and L. A. Stau er, editors, Proceedings of
Design Theory and Methodology { DTM'92{, pp. 167{174. ASME, 1992.
K. T. Ulrich and W. P. Seering. Function sharing
in mechanical design. In Proceedings of AAAI-88,
pp. 342{346, 1988.
Y. Umeda, H. Takeda, T. Tomiyama,and H. Yoshikawa. Function, Behaviour, and Structure. In AIENG'90 Applications of AI in Engineering,pp. 177{193. Computational Mechanics Publications
and Springer-Verlag, 1990.