1. art and entertainment
2. visual art and design
3. design

Master Recherche
Sciences de l’Entreprise : Génie Industriel
Mémoire thématique
Spécialité MoMaC
How to develop functional architecture ?
Antoine GRANDOU
Soutenu le 24 mars 2014
Encadrants :
Jurys :
Sonia BEN AMIDA
Marija JANKOVIC
Bernard YANNOU
François CLUZEL
Marija JANKOVIC
Yann LEROY
Bernard YANNOU
Abstract
How to develop functional architectures? 2014
This work is aimed at reviewing different approaches dedicated to the development of
systems and artifacts architectures. Function modeling is the first field of study to be reviewed,
focusing specifically on the different definitions of function. Then the practicality of function
modeling is questioned and the emergence of new concepts such as affordance-based design is
developed. Finally a case study on the design of a fridge is conducted based on four approaches, the
obtained architectures are then evaluated.
Keywords
System architecture
Function modeling
Function-based design
Affordance-based design
1
Mémoire Thématique
Contents
How to develop functional architectures? 2014
Abstract ................................................................................................................................................... 1
Keywords ................................................................................................................................................. 1
Introduction............................................................................................................................................. 3
Part 1: Context and issues ....................................................................................................................... 4
Part 2: State of the art and synthesis ...................................................................................................... 5
1) Eighteen different approaches and representations ...................................................................... 5
2.2) Existence of a solution of disambiguation about functional description..................................... 7
3) Practicality of functional modeling ................................................................................................. 9
4) Affordance based design ............................................................................................................... 10
4.1) Designers-Artifacts-Users model............................................................................................ 10
4.2) Artifact-User Affordance & Artifact-Artifact Affordance ....................................................... 11
Part 3: Case study: The fridge................................................................................................................ 12
1) Selected approach for the study ................................................................................................... 12
1.1) Function-Behavior-State ........................................................................................................ 12
1.2) Functional representation to support idea generation ......................................................... 14
1.3) Finding the right problem ...................................................................................................... 15
1.4) Working with affordances ...................................................................................................... 15
2) Criteria of evaluation..................................................................................................................... 18
Part 4: Application ................................................................................................................................. 20
1) Function-Behavior-State ............................................................................................................... 20
2) Functional representation to support idea generation ................................................................ 20
3) Finding the right problem ............................................................................................................. 22
4) Working with affordances ............................................................................................................. 27
Part 5: Comparison and discussion ....................................................................................................... 32
1) Evaluation of the approaches ....................................................................................................... 32
2) Encountered difficulties ................................................................................................................ 33
Conclusion ............................................................................................................................................. 34
Acknowledgments ................................................................................................................................. 34
References ............................................................................................................................................. 35
Appendix................................................................................................................................................ 38
2
Mémoire Thématique
How to develop functional architectures? 2014
Introduction
System architecture is an essential part of conceptual design. Function, behavior and form
are three key aspects of design (Albers et al. (2011)). Form and parts embody the design, while
function can be used to describe desired behaviors. Many studies address this subject often using
functions and functional decomposition as a principled way of designing systems or artifacts (Pahl &
Beitz (1996)) (Hubka & Eder (1996)). Nevertheless, the definition of what is functional and functions
in general appears to be vaguer, more blurred. The proof is, for example the eighteen, different
approaches of function that (Erden et al. (2007)) found in the literature.
The purpose of this paper is to attempt to make a review of approaches that enable
engineers and designers to develop system architectures and to apply some of these approaches to a
case study based on the design of a fridge. Therefore the two first parts to be discussed in this paper
deal with the place of function modeling in design and what the definitions of function are. Which
approach should be considered to be the most appropriate to work with on systems architecture?
The research for a single definition is also reviewed based on the work of (Vermaas & Eckert
(2013)).This development will lead to the emergence of a lack of applicability and practicability of
function modeling in design. Thus the question of the relevance of the use of function in design and
the fact that functions appear to be extremely interesting on a theoretical point of view, but when it
comes to the real world of applications in industry, the concept is no longer applicable (Tomiyama et
al. (2013)) and (Eckert (2013)).Following the emergence of the lack of applicability of functional
architecture it might appear to be interesting to focus on other type of architectures that are not
based on functions. The concept of Affordance-based design can then be developed as an alternative
as it is developed by (Maier & Fadel (2009a) (2009b)). Affordance then appears to be very interesting
with broader applicability to the design process.
Then, a case study is realized, four different approaches are implemented on the design of a
fridge. Two of those methods are reviewed in the work of (Erden et al. (2007)), the first, one by
(Shimomura et al. (1998)), is based on the Function-Behavior-State approach of (Umeda et al.
(1990)) and the second is developed by (Chakrabarti & Bligh (2001)). The third approach is entitled
“Finding the right problem by (Thuillier & Wippler (2011)) and the last one is based on the work of
(Cormier et al. (2013)) on the affordances.
Eventually an evaluation of the different architectures of the fridge developed through the
implementation of the four approaches is realized. Moreover the encountered difficulties are
detailed.
3
Mémoire Thématique
How to develop functional architectures? 2014
Part 1: Context and issues
The term of function is used by engineers in many different meanings thus the hampering of
the use of functional description (Vermaas & Eckert (2013)). For example, (Erden et al. (2007)) in a
review of function modeling, identify eighteen different approaches based on different definitions of
function. Here emergence different issues about the ambiguity around functional description in
engineering. The comparative review of the literature realized by (Erden et al. (2007)) is based on the
idea that the basic concern of function modeling is how to represent knowledge about function. As
(Szykman et al. (2000)) state, “a single designer or design team can no longer manage the complete
product development effort”, function modeling provides a framework for overall system
description. (Muller (2007)), developed a scheme representing the design process, he aimed at
showing the gap between the high-level requirements and the low level details and (Erden et al.
(2007)), completed the scheme stating that “function modeling serves as a mean of linking the upper
and lower levels of system design and description”. This is illustrated in Fig.1. Nevertheless, the
solution to “how to bridge the multitude of models required to support a complex design” (Wang et
al. (2002)) is not trivial.
Fig.1. The device pyramid of design according to (Erden et al. (2007)) adapted from (Muller (2007))
4
Mémoire Thématique
How to develop functional architectures? 2014
Part 2: State of the art and synthesis
The review of function modeling approaches of (Erden et al. (2007)) identifies three domains
in functional ontology. The device ontology which considers devices as black box modules connected
with input and output connections. The process ontology deals with the process rather than the
components; it is focused on the participants and the changing entities. And the functional concept
ontology that aims at developing a model of a device. Even if function modeling is a tool to define
what the system does and what is its purpose, (Umeda et Tomiyama (1995)) state that “there is no
clear and uniform definition of a function, and moreover, it seems impossible to describe function
objectively”. Then, the semantic definition of function appears to be a point of comparison between
approaches. Different points will be discussed in this section; the first one is aiming at establishing a
comparison of those eighteen different approaches reusing the comparison points established by
(Erden & al (2007)). The second goal of this section will be to see if it is possible to come to a solution
of disambiguation about functional descriptions (Vermaas & Eckert (2013)). Then a focus on the
practicality of function modeling will be realized followed by a review of an alternative solution for
the development of systems architectures.
1) Eighteen different approaches and representations
This list is a quote from (Erden et al. (2007)); all the definitions introduce in these approaches are
represented in the Tlable.1 of the appendix:
1. In their function–behavior–state (FBS) model, Umeda, Tomiyama, and colleagues (Umeda et
al., 1990, 1995a, 1996, 2005; Umeda & Tomiyama, 1995, 1997; Shimomura et al. 1998)
develop a function representation in which the subjective and objective realms are related to
each other with function–behavior relationship.
2. In ontological engineering of (Kitamura & Mizoguchi (2004)), the functionalities are defined
in the basis of “is-a (function abstraction),” “a part of (function composition)” and “is
achieved by (relation between function and structure or behavior)” relations.
3. The structure–behavior–function (SBF) model developed by Goel and colleagues (Goel &
Bhatta (2004); Bhatta & al. (1991)) considers behavior as an intermediate concept between
the structure and subjectively defined functional requirements.
4. The Schemebuilder program developed by (Bracewell & Sharpe (1996)) is based on the bond
graph ontology.
5. (Welch & Dixon (1994)) develop behavioral primitives for conceptual mechanical design and
name those as “features”. The implementation generates behavior graphs based on
knowledge of available combinations of the primitives.
6. In their function–environment–behavior–structure (FEBS) design model, (Deng et al. (2000),
Deng (2002)) propose a “working environment” which give a definition of the environmental
elements that contribute to the functions of the design.
7. (Chakrabarti et al. (2005)) propose a functional representation to support idea generation
for product design using the analogy between the knowledge of natural and artificial
systems.
5
Mémoire Thématique
How to develop functional architectures? 2014
8. (Van Wie et al. (2005)), develop an approach that adopts direct mapping of functions to
components. This method describes the mappings in a matrix.
9. The function–behavior–structure (FBStr) model developed by (Gero (1990)) defines function
as an intermediate between the goal of human and the behavior of a system.
10. (Snooke & Price (1998)) introduce the idea of functional label to relate system components
to the behaviors at various hierarchical abstraction levels, and apply their scheme to design
and diagnose electrical devices (systems) in automotives.
11. (Chandrasekaran & Josephson (2000)) developed the ideas of environment-centric and
device-centric views in order to express the mode of deployment in the design process.
12. (Keuneke (1991)) considers functional representation as a means of constructing a new
organizational structure.
13. (Pahl &Beitz (1996)), systematic design.
14. (Suh (1990)), axiomatic design.
15. (Miles (1972)), Value engineering.
16. (De Kleer & Brown (1984)), Qualitative physics.
17. (Forbus (1984)), qualitative process theory.
18. (Rausand (1998); Labib (2006); Klein & Lalli (1989)), Failure Mode and Effect Analysis and
Fault Tree Analysis in general.
6
Mémoire Thématique
How to develop functional architectures? 2014
In order to realize a comparison between the different approaches (Table.1.), (Erden et al.
(2007)) define six main domains of comparison. Among those domains the ontology delineates if the
approach follows a device-centered or a process-centered perspective. Semantic definition of
function identifies how the term function is defined. Function representation formalism refers to the
mode of function representation. The function–context relation identifies if the semantics of function
is derived from the context or if it is defined following the no function in structure principle. Under
the domain of decomposition and verification it is mentioned if the authors propose methodologies
for functional decomposition and verification of the functional design. The criteria named
implementation in a programming environment and application aims at checking if a representation
scheme for computer programming is proposed and used.
Table.1. A comparative view of the eighteen approaches by (Erden et al. (2007)).
2.2) Existence of a solution of disambiguation about functional description
Taking into account the eighteen definitions of (Erden et al. (2008))’s review,
(Vermaas & Eckert (2013)) try to find a solution of disambiguation about functional
description. Their work aims at obtaining a single meaning to function.
First, the attempt to converge toward a single meaning appears to be impossible. In fact
7
Mémoire Thématique
How to develop functional architectures? 2014
different meanings co-exist without being equivalent or dealing with the same concepts.
Therefore “a single concept of function cannot emerge” (Vermaas & Eckert (2013)). The
same problem appears in the attempt of imposing a single meaning to function, “arguing for
one meaning and thus rejecting the others” (Vermaas & Eckert (2013)). Engineers use
different meanings of function side-by-side and those co-existing meanings even seem to be
useful for engineers and designers. If a single meaning can’t emerge and can’t be imposed,
could it be possible to find an overarching theory? The result seems to be that this approach
is useful and relevant if the overarching theory include all the approaches without replacing
them. Nevertheless by considering the eighteen different approaches and involving all of
them, the concept can’t be applied practically and “it should not be seen as the true concept
of function” (Vermaas & Eckert (2013)). The family resemblance concept is the one that
“stays close” to engineering practice. Nevertheless it shows the drawback of giving a rather
elusive definition that doesn’t fit with a practical use of the definition. The main conclusion of
(Vermaas & Eckert (2013)) is that it is a need to keep the co-existing meanings. After
the
failure of those four different approaches, it appears legitimate to try to explain the coexisting of all those meanings. Going further from the work of (Houkes & Vermaas (2010))
and (Brown & Blessing (2005)), (Vermaas & Eckert (2013)), focus their attention on the
device to be design by organizing an iterative process based on the goals, the actions, the
functions, the behavior and the structure.
Fig.2. Reasoning from a device’s goal to its structure.
Those five key terms (Fig.2.) emerge from a comparison of the use of Functional Basis (FB)
(Stone and Wood (2000)), Multilevel Flow Modeling (MFM) (Lind (1994)) and Function-BehaviorStructure (FBS) (Gero (1990)). Taking into account these key terms (Vermaas & Eckert (2013)) point
out that FB, MFM or FBS are just design methods that use some of them. Here we reach an
interesting point that consists on showing that even if we can’t manage to come to a single meaning
of function, it is possible to find a model that can overarch design methods that are based on
functional modeling. Ultimately (Vermaas & Eckert (2013)) give a recap of their findings stating that
“function is a term with a number of co-existing meanings and with the common role of relating goal
descriptions of devices with structural descriptions of the devices in a general interdisciplinary way”.
8
Mémoire Thématique
How to develop functional architectures? 2014
So far, no proper solution of disambiguation has been found. In fact, it even appears that the
different definitions of function are something benefic for designers and engineers. It seems easier to
deal with all those different approaches instead of using a single one, it apparently provides more
flexibility.
3) Practicality of functional modeling
As it has been said above, the implementation of certain approaches is not an easy thing
(Albers et al. (2011)). Therefore, the practicality of function modeling in design engineering appears
as a real challenge. (Tomiyama et al. (2013)) point out that function modeling is not used by
practitioners in reality even if it is taught in educational institutions. (Eckert (2013)) develops this
idea stating that “[designers] have to describe that which is not form about a product and don’t have
easy and intuitive ways of doing so”. Here again emerges the lack of a single definition of function.
(Tomiyama et al. (2013)) focused on this lack of practicality and identified three syndromes that
would explain this phenomenon:
(1) “Never used it” syndrome. (Or simple neglect): Practitioners have heard of function modeling but
don’t think it will bring useful results. They’ve never received any formal training beyond
“transformational boxes” or “to do something” verb noun pairs.
(2) “No added value” syndrome. Practitioners stay at the same level of knowledge and detail in
function modeling without going deeper.
(3) “Not practical” syndrome. Practitioners think that function modeling tools are only for academics
since they were developed by them. Therefore they believe that no use of that king of tool can be
made in industry.
Facing this lack of use in the industry, (Eckert (2013)) identified what would be the ideal tool
for designers in order to identify the goals to achieve in further tools developments. The main idea is
to focus on a user-centered tool. The current need in industry is for methods that are easy to follow
with clear and intuitive training materials. Nevertheless new methods should not require huge
learning efforts and show immediate benefits, moreover there is a need of entertainment in
modeling and also the outcomes of the models should be easy to explain to others.
Even though function is a problematic concept for designers, it appears that established approaches
are relatively well accepted in industry (Eckert (2013)). Quality function deployment or Failure mode
and effect analysis are applied across industry sector taking part in formal processes. In order to
tackle the three syndromes, (Tomiyama et al. (2013)) foresee three possible solutions:
(1) Demonstrate the interest of deep functional level analysis applied to conceptual design in regard
of the “Never use it” syndrome.
(2) Proving the useful knowledge and the possibilities to explore other applications is good mean to
tackle the preconceived idea that function reasoning doesn’t generate “added value”.
(3) Then the “Not practical” syndrome is the proof that easy-to-use tools must be developed and also
that effective training methods should be put into practice so that engineers are able to handle
different function structures.
Even though directions are given in order to develop and perfect the use of function
modeling for architectures development among designers and engineers, there is still an issue. In fact
function modeling is not something new and after many years of development and deployment it is
9
Mémoire Thématique
How to develop functional architectures? 2014
still not very well spread in industry, thus the questioning of a new approach of architecture
development; an approach that would be somehow easier and perhaps not based on function
modeling.
4) Affordance based design
Now that the limits inherent to Function Modeling have been spotted, it may appear
interesting to look for different approaches of architecture generation. (Maier & Fadel (2009a)
(2009b)) have developed the theory of affordance based design a lot. The introduction of the idea of
affordance was realized by the psychologist James J. Gibson; he stated (Gibson (1979)) “The
affordances of the environment are what it offers the animal, what it provides or furnishes, either for
good or ill. The verb to afford I found in the dictionary, but the noun affordance is not. I have made it
up. I mean by it something that refers to both the environment and the animal in a way that no
existing term does. It implies the complementarity of the animal and the environment.”
4.1) Designers-Artifacts-Users model
In order to develop a relational model of design, (Maier & Fadel (2006)) define three entities:
the designer of the artifact, the artifact being designed and the user of the artifact. Moreover they
define the relationships: The designer designs that artifact, the user uses the artifact. Nevertheless
(Maier & Fadel (2006)) admit that those relationships are entangled since the designer determines
how the user uses the artifact through the structure of the artifact itself and the design is also
dependent of the users’ own demands and wishes. The three entities defined above and the two
relations are represented by the designer-artifact-user (DAU) system (Fig.3)
Fig.3. Generic situated design-artifact-user (DAU) system. (Maier & Fadel (2009a))
10
Mémoire Thématique
How to develop functional architectures? 2014
4.2) Artifact-User Affordance & Artifact-Artifact Affordance
Affordances describe a potential behavior between two or more subsystems within a larger
designer-artifact-user complex system. (Maier & Fadel (2001) (2002) (2003)) identified two different
categories of affordances, when interacting subsystems are an artifact or a user. They state that
“artifact-user affordance expresses an interactive relationship between an artifact and a user where
a behavior may occur between the artifact and user that neither the artifact nor the user could
manifest alone”. On the other hand “artifact-artifact affordance is a potential behavior that may be
exhibited by the two artifacts together, that could not be manifested by either artifact alone”. There
is a close relation between Artifact-Users Affordances and Artifact-Artifact Affordances since ArtifactArtifact Affordances are usually designed to satisfy Artifact-User Affordances. Linking this last point
to the Designer-Artifact-User complex system, it appears that the designer’s objective is to define the
artifact properties in order to meet the affordances needed desire of the artifact expressed by the
user.
Fig.4. Affordance related interactions within a designer-artifact-user system. (Maier & Fadel (2009a))
11
Mémoire Thématique
How to develop functional architectures? 2014
Part 3: Case study: The fridge
Now that some of the different opinions and viewpoints that could be found in the literature
have been reviewed, it might appear relevant to try to apply some of the approaches seen earlier. To
do so, a case study based on a fridge is going to be developed.
1) Selected approach for the study
Four different approaches have been chosen for this study:




The Function-Behavior-State approach, developed by (Shimomura et al. (1998))
Functional representation to support idea generation by (Chakrabarti & Bligh (2001))
Finding the right problem by (Thuillier & Wippler (2011))
Formalization of affordance modeling in the early stages of design by (Cormier et al. (20013))
These approaches where chosen because of their points of view on the development of
functional architectures, which are very different. For example the ‘Function-Behavior-State’
approach is process-centered whereas ‘Functional representation to support idea generation’ is
device-centered. Moreover they don’t share the same definition of function or the same mode of
representation of systems architecture. The different characteristics and formalisms of the chosen
approaches are detailed below.
1.1) Function-Behavior-State
The first approach is the one of (Shimomura et al. (1998)); it is widely based on the FunctionBehavior-State approach developed by (Umeda et al. (1990)), but offers a more refined
representation of systems architectures. In their work, Shimomura et al., define function as “A
description of behavior abstracted by human through recognition of the behavior for utilization”. The
notion of behavior is introduced as “Sequential changes of state”, while State is “A combination of
Entities, attributes of entities and relations among entities”. The main particularity of this approach is
to be process centered, whereas most of the eighteen ones reviewed by (Erden et al. (2007)) are
device-centered. The architecture provided by this method is represented by three main sets; the
Function set, the Behavior set, and the Structure set (Fig. 5). The links between those sets are called
Function-Behavior relationship and Behavior-structure relationships.
The formalism provided by this method is based on the description of “relations among
functions”. In their work, (Shimomura et al (1998)) introduce four types of relations among
functions. The first type is “Decomposed-into relation” (Fig. 6), it is the outcome of the ‘decomposedinto operation’ in which the designer decomposes a function into sub-functions.
The second type is “Conditioned-by relation” (Fig.7.), it is outcome of the ‘conditioned-by operation’
in which the designer adds a causal relation between two functions because the behavior linked to
12
Mémoire Thématique
How to develop functional architectures? 2014
the first function will not occur if the behavior linked to the second function is not observed.
The third type is “Enhanced-by relation” (Fig.8.), it is the outcome of the ‘enhanced-by operation’ in
which the designer adds a function in order to fulfill of function modifier. A function modifier is an
adverb or a group of words that are used to give more information about the function and the
expected behavior. During the evaluation of a function, if the designer finds out that a function
modifier is not fully satisfied by a function, he will add a new function to the first function in order to
improve the level of satisfaction of the provided architecture in regard of the defined function
modifiers. Finally the “Described-as relation” (Fig.9.) is the outcome of the ‘described-as operation’ in
which the designer gives details on a function modifier. This operation takes place after the
decomposed-into operation. The main function that has been decomposed-into had a function
modifier to precise it, so the sub-functions that will fulfill the function modifier of the main function
will also receive a function modifier.
Fig.5.Relationship among Function,
Behavior and State (Umeda et al. (1990))
Fig.7.Evolution by Conditioned-by Relation
(Shimomura et al. (1998))
Fig.6.Evolution by Decomposed-into
Relation (Shimomura et al. (1998))
Fig.8. Evolution by Enhanced-by
Relation (Shimomura et al. (1998))
Fig.9. Evolution by Described-as
Relation (Shimomura et al. (1998))
13
Mémoire Thématique
How to develop functional architectures? 2014
1.2) Functional representation to support idea generation
The “functional representation to support idea generation” approach developed by
(Chakrabarti & Bligh (2001)) is based on the work of (Freeman & Newell (1971)). The considered
definition of function is “A description of the action or effect required by a design problem, or that
supplied by a solution” and it is device-centered. The aim of this method is to represent structures
and solutions in terms of the provided and required functions in order to ensure the generation of
solutions to a problem. To achieve that purpose it needs a functional maping between the known
solutions and the problem. Therefore it works with a known set of solutions and provides a
framework for design at a given level but not all levels of conceptual design.
The implementation proceeds through several steps. First, the design problem must be
defined in terms of a set of functions that have to be fulfilled. Then a knowledge base of known
solution is needed in order to provide a structure of solutions concepts. When all those elements are
defined and ordered, six steps must be followed; in the beginning the problem has been described
and defined by its function so now the problem must be divided in parts representing each function
(Step 1). For one part of the problem, that is to say one function, a set of partial alternative solutions
is synthesized using the knowledge base of solutions in order to fulfill that function (Step 2). That
partial alternative set of solutions is evaluated in regard of the whole problem to see if the selected
function has been fulfilled and if some other functions of the problem haven’t also been fulfilled ( a
set of solution can fulfill more than one function). Then the problem must be revised considering the
remaining functions that, yet, haven’t been fulfilled by the first set of solutions (Step 3). Now, like in
step 1, the revised problem must be divided in parts representing each remaining functions and a
new set of partial solutions is synthesized, using the knowledge base of solutions like in step 2, to
fulfill one of the functions of the revised problem. The new set of solutions is added to the first one
and evaluated in regard of the whole problem to see which functions are fulfilled and which aren’t,
then the problem is revised again and a new set of solution is synthesize, and so on, until all the
functions are fulfilled (Step 4). Now iterations are made going back to the previous step to evaluate
another set of partial solutions different from the one that has been chosen and evaluated (Step 5).
In Fig.10, the two first steps of the process are represented. In the end, the idea here is to evaluate
each set of partial solutions that can be found in the knowledge base of solutions until the solutions
tree is completely searched and see which one provides the most relevant solutions regarding the
whole problem.
Fig.10.The proposed Scheme for Functional reasoning (Chakrabarti & Blight (2001))
14
Mémoire Thématique
How to develop functional architectures? 2014
1.3) Finding the right problem
The third approach to be implemented is called “Finding the right problem”. It was developed
by (Thuillier & Wippler (2011)) and is the fourth chapter of a book entitled “Complex Systems and
Systems of Systems Engineering”. The interesting part of this approach is that, even if it is process
centered like the Function-Behavior-Structure by (Shimomura et al. (1998)), it forces the designer to
think about the environment of the system and the functions needed in the architecture are not
considered until a certain step in the approach, whereas in the two previous methods, the functions
provided by the system are needed from the beginning. First the “Finding the right problem
approach” asks the designer to focus on the system that will be dealt with, its purpose and mission,
its perimeter and its context. Then the system lifecycle is analyzed from its conception to its
retirement. A complete analyze of the system’s stakeholders is then conducted to see who the
system involves. A working framework is created, followed by different methods and tools to gather
information from the stakeholders of the system, this aims at creating mind-maps of the systems,
storyboards of the use that will be made of the system and operational scenarios. Later a complete
model of the system context in realized using the deferent points seen above. This will help for the
understanding and the definition of the system’s goals, the representation of the goals can be
realized using KAOS: “Knowledge Acquisition in automated Specification” / “Keep All Objects
Satisfied”. The last parts of this approach consist in modeling the domain and defining stakeholders’
requirements and constraints this will allow the representation of detailed entity-relation models,
the expression of service requirements, the expression of the functional interface requirements, the
physical interfaces that are needed and finally the requirements from the goal model.
1.4) Working with affordances
Developing the work of Maier & Fadel, (Cormier et al. (2013)) detailed the classification of the
user categories, the artifact-artifact relationships and the artifact-user relationships. Their work
intended to formalize an affordance-based method for capturing consumers’ needs. In regard to the
Designer-Artifact-User complex system that has been seen above, (Cormier et al. (2013)) use the
concept of Desired Affordance Model (DAM) which is a structure for organizing users, artifacts and
affordances. It enables engineers to proceed from the identification and development of general
requirements to move on to generating design specification. To do so, (Cormier et al. (2013)) based
there approach on the four steps described by (Maier & Fadel (2013)):
-
Step 1: Understanding, Gathering and Expressing User Needs in term of Affordances
Step 2: Apply Generic Affordance Structure Template Fig.11.
Step 3: Prioritize Affordances
Step 4: Organize the Affordance into a Structure
15
Mémoire Thématique
How to develop functional architectures? 2014
Fig.11.Generic affordance Structure (Cormier et al. (2013))
Moreover the Desired Affordance Model can be used at different stages in the design
process (Fig.12.) and it can be used in addition to other tools such as the House of quality, as
(Cormier et al. (2013)) state, “the Desired Affordance Model helps identify and organize benefits
from different users, while the House of Quality traditionally has focused on developing the required
performance characteristics of the solution.”
Fig.12. Desired Affordances model in a design process (Cormier et al. (2013)).
The most interesting part of (Cormier et al. (2013))’s work has been to try to explicit and
summarize the concepts of Affordance-Based Design into tables and figures. Moreover it also
appears that they have managed to define a standard and specific vocabulary for describing the
different stakeholders and this new process of design (Fig.13.Table.2.Table.3). More detailed tables
from the literature appear in the Appendix (Table.2. Table.3. of the Appendix)
16
Mémoire Thématique
How to develop functional architectures? 2014
Fig.13. Affordance Model Structure (Cormier et al. (2013))
Class
Production
Usage
End of Life
17
Potential Users
Category
Definition
Examples
Manufacturer
Users involved in the Factory worker,
production of the artifact packager
Delivery
User
involved
in Installer, delivery
transferring the artifact person, distributor
from the design firm to
the end user
Operator
User who control the Operator, driver,
artifact
doctor
Client
Users who receive the Client, passenger,
purpose of the artifact patient
but do not control it
Collateral
Users who are in the Pedestrians,
operating environment bystanders, other
but do not directly participants in an
activity
interact with the artifact
Support
User involved in assisting Technical support
other
users
with work, maintenance
problems
with
the
artifact
Removal
Users involved taking the Delivery person,
product out of usage
sanitation worker
Disposal
Users involved with the Recycler, sanitation
recycling, destroying, or worker
end of life storing of the
product
Table.2. User Classification and examples (Cormier et al. (2013))
Mémoire Thématique
How to develop functional architectures? 2014
Category
Support
Definition
An artifact which supports the
capabilities of another artifact,
either adding or enhancing
performance
Examples
A computer support the iPod
Classic by allowing a user to
manage media, a coffee grinder
supports a coffee maker; a dust
separator supports a shop
vacuum
Dependent
An artifact which is dependent The iPod Classic is dependent
upon another artifact
upon a computer for managing
media
Environmental
An artifact which exists in the A microwave in an office may
same environment or is issued interfere with other devices in
in conjunction (either in parallel the environment (e.g., laptop)
or series) with the principal that use wireless signals;
artifact
sanding devices are often used
after sawing to improve the
surface finish of a cut
Table.3. Artifact-Artifact Relationship Categories (Cormier et al. (2013))
2) Criteria of evaluation
In order to compare those four approaches, criteria of evaluation have been selected
(Table.4.), those criteria have been provided by ASTRIUM ST.
Quality
characteristic
(ISO 25010)
Criteria Type
Criterion
Number
Criterion Description
Associated SMS Voice of
customers’ needs
Means of
evaluation
Possible way to
measure this
Satisfaction of
usability
Use/Ergono
mics
US1
Ease of use/Ergonomics
Test
along the SMS
process
Satisfaction of
usability
Use/Ergono
mics
US2
Customization Capability
Ease of use by system
designers: Graphical User
Interface, Powerful editing
capabilities (copy/paste,
drag/drop, search...), level
of knowledge necessary
Customization of the tool to
Airbus processes
Test
see step in
evaluation
process
Satisfaction of
usability
Documentati
on
US3
Quality of user
documentation
Analysis &
test
Satisfaction of
usability
Use/Ergono
mics
US4
Efficiency
Vendor &
tool
information
RE1
Readability of models
(easiness to review ,
communicate and present
to non-specialist)
Maturity of the software
product incl. Product
reliability
Level of tool support
(documentation, trainings,
hotline, ...)
readability of the models
18
Mémoire Thématique
Analysis &
test
Test
Number of
crash,
Number of
worldwide users
(OoM)
How to develop functional architectures? 2014
Efficiency
Robustness
RE2
Scalability
Tool scalability: is the tool
ready to manage 10000
objects?
Analysis or
test
Efficiency
Performance
s
Performance
s
EF1
Verification capabilities
(consistency checks)
Performance/efficiency
when simulating
Capability to import and
export requirements from
DOORS
Verification capabilities
(checks)
Verification capabilities
(simulation...)
Transversal services: link to
requirements,
Test
IO2
Support for standardized
exchange formats (model
content and simulation
results)
Transversal services:
import/export
Test
CM1
Support for Configuration
Management
Transversal services:
configuration management
Test
Efficiency
Context coverage
EF2
IO1
Interoperabil
ity
Context coverage
Interoperabil
ity
Context coverage
Interoperabil
ity
Context coverage
Test
Analysis &
Test
CM2
Support for Change
Management
Transversal services
Test or
analysis
Effectiveness
Interoperabil
ity
SMS process
M1
SMS process
M2
See SMS Process and Tool
Requirements
Ability to manage the
required data: compliance
of the data model to the
activity
Test
Effectiveness
Effectiveness
SMS process
M3
Effectiveness
SMS process
M4
Effectiveness
SMS process
M5
Effectiveness
SMS process
M6
Effectiveness
SMS process
M7
Refine operational scenario
until elementary operation
and function
Specifies functional
interface between
elementary functions
Specifies behavior of
elementary function
Specifies Physical Platform
Architecture
Map Elementary function
and flow on physical items
and links
Interoperate with Common
Data Referential
(import/export model
element)
Document generation
Test
Effectiveness
SMS process
SIM1
Simulate simple behavior
Transversal services: doc
generation
See SMS Process and Tool
Requirements
Table.4. Criteria of evaluation
19
Mémoire Thématique
Generate
through the API
as many as
elements as
identified
Capacity of
checking,
Test
to export to
detailed design
tool (Simulink,
SCADE, etc.) or
simulation
environment
Capability to
connect to CMS
See evaluation
process
How to develop functional architectures? 2014
Part 4: Application
In order to apply those four approaches on the case study of the fridge, five key
performances indicators have been chosen. The system to be designed must have low energy
consumption, a low economic cost; also it must minimize food wastes, provide comfort of use and
allow the user to save his time for other activities. The four selected approach have been
implemented taking those five elements into account, the outcomes are shown below.
1) Function-Behavior-State
Ds: Described-
Fig.14.Extraction of Functional Evolution in Design of a fridge
2) Functional representation to support idea generation
20
Mémoire Thématique
Fig.15.The proposed scheme for a Standard fridge/ advanced fridge
Output:
How to
develop functional architectures? 2014
Input: KPI
- Energy consumption
- Economic cost
- Food waste
- Comfort of use
- Time
Overall function of the
problem:
Provide an efficient
mean of food
conservation
A satisfied consumer/user
Input: KPI
- Energy consumption
- Economic cost
- Food waste
- Comfort of use
- Time
Problem
redefinition
Input: KPI
- Economic cost
(partially satisfied)
- Food waste
- Comfort of use
- Time
Remaining Function of
the Problem
Output:
A satisfied
consumer/user
Solution
redefinition
Input: KPI
- Economic cost
(partially satisfied)
- Food waste
- Comfort of use
- Time
Problem
redefinition
Input: KPI
- Economic cost (partially
satisfied)
- Food waste
- Comfort of use (partially
satisfied)
Remaining Function of
the Problem
Input: KPI
- Economic cost (partially
satisfied)
- Food waste
- Comfort of use (partially
satisfied)
Input: KPI
- Food waste (partially
satisfied)
- Comfort of use
(partially satisfied)
21
Remaining Function of
the Problem
Efficient cooling
system
+
insulating
materials
Shelves
+
Transparent
materials
+
Food preview
system
Output:
A satisfied
consumer/user
Problem
redefinition
Input: KPI
- Food waste (partially
satisfied)
- Comfort of use
(partially satisfied)
Output: KPI
- Economic cost (partially
satisfied)
- Food waste
- Comfort of use (partially
satisfied)
Solution
redefinition
Efficient cooling
system
+
insulating
materials
Shelves
+
Transparent
materials
+
Food preview
system
Output:
A satisfied
consumer/user
Mémoire Thématique
Output: KPI
- Economic cost
(partially satisfied)
- Food waste
- Comfort of use
- Time
Efficient cooling system
+
insulating materials
Reusable
materials
+
Colorful
indicators
of fridge
settings
Output: KPI
- Food waste (partially
satisfied)
- Comfort of use
(partially satisfied)
Solution
redefinition
Efficient
cooling
system
+
insulating
materials
Shelves
+
Transparent
materials
+
Food preview
system
Reusable
materials
+
Colorful
indicators
of fridge
settings
Analyzer
of earlier
expiration
date of
foods
+
Ergonomic
features
Output:
A satisfied
customer/user
How to develop functional architectures? 2014
3) Finding the right problem
Creating a working framework
- Operational perimeter of the system: Why? What for? : Allow a person to manage efficiently or as
he/she is pleased his/her food consumption
- Principal missions of the Intelligent fridge:





Provide the necessary means to reduce food wastes
Provide comfort of use
Provide a mean to reduce energy consumption
Provide a mean to reduce the financial expenses linked to the fridge
Provide mean to reduce time wasting when using the fridge
- With whom/what does the system interact? This aims at identifying external entities in the
periphery of the system.
The
Foods
The
environment
(Some) external entities
Operational context of
the system
Fridge
The
user
Energy
supply
System boundary
Fig.16. Context of the fridge
- What will the system chronology look like? Definition of the system life cycle
Conception
Development
Production
Fig.17. System Life-cycle
22
Mémoire Thématique
Use/Support
Retirement
How to develop functional architectures? 2014
- Structure data :{ stakeholders}*{external entities}*{phases and situations of lifecycle}: Defining the
framework for the direction of activities:
 Define a set of external entities with which the system interacts, which may limit the system
or be limited by the presence of the system
 They are defined for one or more situation in the system life cycle.
Stakeholder
Consumer
Manufacturers
Environment
Type
Stakeholder representing the main user of the
intelligent fridge
Stakeholder representing an actor from the
conception/development/production/retirement
phase
Stakeholder that shows specific needs that must
be satisfied by the intelligent fridge
Stakeholder representing must-have constraints
Informative stakeholder during the phase of
definition
Stakeholder representing regulatory constraints
Supplier of technologic data (RFID, specific
materials, Wi-Fi-system…)
Ministry of Ecology and Sustainable
Development
Table.5.Different stakeholders
Gathering information
-5Why (food waste)
In UK each household throw away an average estimate £480 of food per year.
Why?
The foods are expired.
Why?
The expiration date came too quick.
Why?
There was a poor management of the amount of food left in the fridge (too much of something)
Why?
The consumer didn’t know what he needed when he went shopping.
Why?
He didn’t checked what was left in the fridge before he went shopping.
Fig.18Example of the use the 5Why
23
Mémoire Thématique
How to develop functional architectures? 2014
-Ishikawa diagram to analyze the problem
Fig.19.Example of the use of an Ishikawa diagram
- Who what where when how why
- mind map of the needs
Fig.20.Example of the use of mind mapping
24
Mémoire Thématique
How to develop functional architectures? 2014
-story style approach
The aim of all those questions is to produce a short narrative summary, a story board
Fig.21. Graph of the main “goals” of the intelligent fridge
25
Mémoire Thématique
How to develop functional architectures? 2014
Fig.22. Extraction of the expression of service requirements
Fig.23. Extraction of requirements from the goal model
26
Mémoire Thématique
How to develop functional architectures? 2014
4) Working with affordances
Sep 1: Identifying the needs linked to the Key Performance indicators:





Afford low energy consumption
Afford low economic cost
Afford low food waste
Afford comfort of use
Afford time saving
Step 2: Apply Generic affordance Structure templates
Fig.24. Application of generic affordance Structure in regard of the KPI (the shadowed areas are the
ones concerned by the KPI)
Table.6.Application of working affordance basis in regard of a standard fridge/advanced fridge
Affordance
Definition
Description for the fridge
Augmentation
Improve an object’s existing capabilities
Afford the augmentation of the
during interaction with the principal artifact
duration of food/ food life expectancy
Production
Allow an object to create another object
Afford production of cold
Provisioning
Allow an object to provide or supply
something to another object
Transformation
Allow an object to change or significantly
alter the state of another object or resource
Conditioning
Allow an object to put another object into its
27
Mémoire Thématique
Shaping
Incorporation
Separation
Capture
Storage
Aestheticization
How to develop functional architectures? 2014
proper state
Allow an object to give definite form to an
object (itself or a different object)
Allow an object to combine two or more
objects or resources into a single mixture of
entity
Allow an object to divide an assemblage into
individual units, components, or elements
Allow an object to gain control or exert
influence over another object by force or
stratagem; allow an object to represent or
record information in lasting form
Allow an object to accumulate or put away
objects, set of objects, or resources for future
use
Make an object visually pleasing (relative to
the user)
Communication
To take information (condition, status, intent)
or data known to an object
Organization
Allow the user to arrange objects
systematically
Transportation
Afford an object the ability to transport one
or more objects
Preserve an object, environmental entity, or
resource from injury, damage, theft,
contamination, embarrassment, discovery,
etc.
Allow an object the ability to hold the
attention of a user pleasantly or agreeably
Protection
Entertainment
Control
Cleaning
28
Allow an object to exercise restraint or
direction over another object’s operation,
movement, behavior, etc.
Allow an object to clean an object or
environmental entity
Mémoire Thématique
Allow storage of food
The fridge afford to make the room
look nicer, A fridge skin could afford
users the ability to aestheticize their
fridge
Give indications on the temperature
inside the fridge, in the different
compartments, to indicate the users if
the fridge is well set (alarm,…)
Cleanliness of the fridge (level of
bacteria)
Allow the user to store foods on
shelves
Afford organizing the food by earlier
expiration date
Protect food from external and
internal hazards (bacteria, dust,
pollution, temperature)
Magnetic surface for kids’ magnets
News, weather forecast, important
things display
Regulate inside temperature,
Control food consumption of users in
regard of physiological needs
Clean users hands
Clean vegetables
How to develop functional architectures? 2014
Auto-cleaning
Afford positioning of food
No need for the user to organize the
fridge (optimization of food position)
Positioning
Allow an object the ability to physically place
the object in a specific location; this could be
the principal artifact, another artifact, or a
user
Orientation
Allow an object the ability to physically place
the object relative to a frame of reference
Table.6.Application of working affordance basis in regard of a standard fridge/advanced fridge
3. AFFORD
IMPROVEMENT
1. AFFORD
MANUFACTURE
3. AFFORD
MAINTENANCE
2. AFFORD
AESTHETICS
4. AFFORD
RETIREMENT
Artifact
2. Comfort of
2. AFFORD
SUSTAINABILIT
Y
2. Injuring users
1. Preserve
f d
2. Damaging the
food
2. Allow the user to
save time
AFFORD DESIRED
PURPOSES
3. Communicate
information on
DO NOT AFFORD
UNDESIRED
PURPOSES
2. Low energy
consumption
3. Pollution to the
environment
3. Degradation of
itself
2. Low economic
cost
2. Low quantity of
wasted food
3. Frustration of
user
Fig.25.Affordance Structure with order of priority for a fridge
29
Mémoire Thématique
How to develop functional architectures? 2014
Fridge
Owner
Food
consumer
Repairman
Food buyer/fridge
filler
Fig.26. User group for a fridge
Fig.27. Food consumer portion of the fridge Desired Affordance Model
30
Mémoire Thématique
How to develop functional architectures? 2014
Fig.28. Fridge owner portion of the fridge Desired Affordance model
Fig.29. Food buyer/ Fridge filler portion of the fridge desired affordance Model
31
Mémoire Thématique
How to develop functional architectures? 2014
Part 5: Comparison and discussion
1) Evaluation of the approaches
The evaluation realized below is completely subjective since no evaluation method was
provided. The marks given are based on the author’s feelings related to the different difficulties that
he had to face while implementing the four approaches.
Shimomura et
al. (1998)
FunctionBehavior-State
Chakrabarti &
Bligh (2001)
Function
repres. To
support idea
generation
Thuillier &
Wippler
(2001)
Complex
systems and
systems of
systems
Engineering
Cormier et
al. (2013)
Formalizat
ion of
ABD
Preferred
means of
evaluation
Weight
US2
M1
M2
Customization Capability
5,00%
Refine operational scenario until elementary
operation and function
6,00%
Specifies functional interface between elementary
functions
6,00%
Specifies behavior of elementary function
6,00%
Specifies Physical Platform Architecture
6,00%
Map Elementary function and flow on physical
items and links
6,00%
Interoperate with Common Data Referential
(import/export model element)
6,00%
Verification capabilities (consistency checks)
6,00%
Simulate simple behavior
6,00%
Readability of models (easiness to review ,
communicate and present to non-specialist)
6,00%
Document generation
5,00%
Ease of use/Ergonomics
6,00%
Maturity of the software product incl. Product
reliability
6,00%
Support for standardized exchange formats (model
content and simulation results)
4,00%
Support for Configuration Management
4,00%
Scalability
6,00%
Performance/efficiency when simulating
4,00%
Support for Change Management
6,00%
Global score
100,00%
M3
M4
M5
M6
EF1
SIM1
US4
M7
US1
RE1
IO2
CM1
3,0
3,0
4,0
5,0
5,0
5,0
4,0
4,0
3,0
3,0
5,0
3,0
4,0
4,0
3,0
4,0
4,0
4,0
4,0
4,0
3,0
3,0
5,0
3,0
3,0
3,0
4,0
4,0
4,0
4,0
4,0
4,0
4,0
4,0
4,0
5,0
3,0
3,0
3,0
5,0
3,0
3,0
3,0
4,0
3,0
3,0
5,0
5,0
4,0
4,0
4,0
3,0
4,0
4,0
4,0
4,0
3,0
3,0
4,0
4,0
5,0
5,0
5,0
5,0
3,0
3,0
4,0
4,0
3,0
3,0
4,0
5,0
3,58
3,58
4,07
4,17
3,28
3,28
3,67
3,71
RE2
EF2
CM2
TOT
AL
32
Mémoire Thématique
Test
Test
Test
Test
Analysis &
test
Test
Test
Test
Test
Test
Analysis or
test
Test
Test or
analysis
How to develop functional architectures? 2014
2) Encountered difficulties
The application of those four approaches revealed to be quite difficult for many reasons. First the
Function-Behavior-State approach and the Functional representation to support idea generation
approach both require the problem to be described in term of functions. This suggests that all the
main functions provided by the system are known, but most of the time they aren’t. For example,
here in this case study, the only known functions that the system must provide are the ones directly
linked to the Key Performance Indicators, but those approaches implies that the main function of the
system are known precisely. In their article (Shimomura et al. (1998)) propose a representation of a
Weighting scale taking as the main function: “to visualize weight”. Here we can notice that this
approach considers as the main function of a system a function that somehow is linked to a known
solution, there is no process of redefinition of the system to be designed. This phenomenon can be
observed in the approach of (Chakrabarti & Bligh (2001)) where it is even more obvious. In fact this
method asks from the beginning for a complete knowledge-base of solutions and, like the previous
approach, it needs the problem to be completely defined by the functions it must provide. Thinking
of the problematic of the development of functional architecture here emerges an issue. The notion
of development implies that idea of representation which is well satisfied by those two approaches
but there is also the idea of innovation, improvement, but here none of these approaches allow that.
In fact since they need from the beginning the problem to be defined by its functions, and those
functions are defined by the designer but are already dealing with a solution, when the approach
asks for a set of functions, this implies that the solution has also been chosen. For example here, for
the fridge, the designer is forced to think about the system as a device that conserves food using
cold, it is the first function of the system. Those two approaches take as a main function of the
system that it conserves food and the solution for that is using cold. Those two approaches don’t
allow a rethinking of the problem, they are efficient for representing the architecture of the system
when it has completely been defined, but they don’t help defining and developing the main functions
that it has to provide.
On the other hand the third approach, “Finding the right problem” by (Thuillier & Wippler (2011)),
propose several steps that will help the designer to come up with new ideas of the system to be
designed. Nevertheless, even if it forces the designers to think about the whole problem, all the
questions that must be asked to the different users of the device, the ‘Why questions’ focus on the
way they use the system but not on the way they would like to be able to use it. Moreover, in the last
steps of this method, the designer has to provide the functional and the physical interfaces of the
system but this is linked to the solution-defining part of the problem and it shouldn’t be necessary to
provide those interfaces when the designer is in the “Problem finding” stage of design. Another issue
that the designer will have to deal with while applying this method is that it is a process-centered
approach and many graphs and schemes that this approach helps to represent are difficult to realize
when the system to be designed is a device; many adjustments need to be realized in order to
provide a relevant architecture.
Eventually, the affordance based approach proposes a very efficient way to consider the system, it
appears like a more bottom-up method whereas to three previous ones were more top-down like.
Here the focus is mainly on the different users of the device especially with (Cormier et al. (2013))
approach. On the other hand, because the affordance propose a bottom-up approach, it implies that
the designer start with a solution and evaluates it in regard of the different templates provided by
the method, therefore the designer will face the issue of been limited to consider preconceived
33
Mémoire Thématique
How to develop functional architectures? 2014
solutions and it will be difficult to propose a radical type of innovation. This last problem appears in
all of the approaches reviewed and developed here; in fact, since they all consider the problem in
term of its functions, the designer is forced, from the beginning of the implementation of these
methods, to consider suggested solutions, without being able to rethink the problem from the
beginning.
Conclusion
In this work a review of two main types of design approaches is realized. The review of
Function modeling shows that a lot of different definitions exist in the literature, a comparison of the
eighteen definitions is given. Moreover it appears that Function modeling is not widely used by
designers and engineers in the industry in relation with three main aspect; the “Never used it”
syndrome, the “No added value” syndrome and the “Not practical” syndrome. Nevertheless for those
of them whom do use function modeling, the multiple definitions of function appear as a need and
an opportunity and converging toward a single meaning to function wouldn’t be of any good for
them.
Then this paper enlightens a new approach, Affordance-based design. This approach is rather
young; it has been going on for only fourteen years, thus the need to define it properly. Nevertheless
the use of affordance-based design shows great opportunities for the design process. The emergence
of Artifact-User Affordances, Artifact-Artifact Affordances and the Designer-User-Artifact system
allows designers and engineers to broader their point of view on the system to be designed.
Eventually the case study revealed that all those approaches show a lack of concern on how
to consider the problem. They are widely “solution oriented” approaches and they only afford a low
level of innovation. In the issue of developing architectures, there is the idea of representing
architectures and also the notion of creating something new, bringing an innovation of some sort,
but through the case study this innovation doesn’t appear. A further work could be to associate
those approaches to innovative processes such as Radical Innovation Design Process and combine
them in order to innovate and represent systems architecture.
Acknowledgments
The author wishes to acknowledge the assistance gained from personal communication with
M. Jankovic, S. Ben Hamida and B. Yannou, as well as the comments by the reviewers. Any mistakes
in the paper or misrepresentations of the authors in references are, of course, the default of the
author.
34
Mémoire Thématique
References
How to develop functional architectures? 2014
(Albers et al. (2011)) System Architecture Modeling in a Software Tool Based on the Contact and
Channel Approach (C&C-A), Journal of Mechanical Design, October 2011, Vol.133.
(Bhatta et al. (1994)) Innovation in analogical design: a model based approach. Proc. Third Int. Conf.
Artificial intelligence in design (AID-94), pp. 57-74, Lausanne, Switzerland.
(Bracewell & Sharpe (1996)) Functional descriptions used in computer support for qualitative scheme
generation: Schemebuilder. Artificial intelligence for engineering design, analysis and manufacturing
10, 333-346
(Chakrabarti & Blight (2001)) A scheme for functional reasoning in conceptual design, Design studies
22, 493-517.
(Chakrabarti et al. (2005)) A functional representation for aiding biomimetic and artificial inspiration
of new ideas, Artificial intelligence for engineering design, analysis and manufacturing 19, 113-132
(Chandrasekaran (2005)) Representing function: relating functional representation and functional
modeling research streams. Artificial intelligence for engineering design, Analysis and manufacturing
19, 65-74
(Chandrasekaran & Josephson (2000)) Function in device representation.
computers 16, 162-177
Engineering with
(Cormier et al. (2013)) Towards a formalization of affordance modeling in the early stages of design,
Proceedings of ASME 2013 International Design engineering Technical Conferences
(De Kleer & Brown (1984)) A qualitative physics based on confluences. Artificial intelligence 24, 7-83
(Deng (2002)) Function and behavior representation in conceptual mechanical design, Artificial
Intelligence for engineering design, analysis and manufacturing 16, 343-362
(Deng et al. (2000)) Constraint-based functional design verification for conceptual design, Computer
aided design 32, 889-899.
(Dorst & Vermaas (2005)) John’s Gero function-behavior-structure model of designing: a critical
analysis. Research in engineering design 16, 17-26
(Eckert (2013)) That which is not form: the practical challenges in using functional concepts in design,
the design group, Open University, Milton Keynes, and (UK)
(Erden et al. (2007)) A review of function modeling: Approaches and applications, Artificial
Intelligence for Engineering Design, Analysis and Manufacturing.
(Forbus (1984)) Qualitative process theory, Artificial intelligence 24(3), 85-168
35
Mémoire Thématique
How to develop functional architectures? 2014
(Freeman & Newell (1971)) A model for functional reasoning in design, in Proceedings of the second
international joint conference in artificial intelligence, London pp. 621-633
(Gero (1990)) Design prototypes: a knowledge representation schema for design. AI magazine
11(4)), 26-36
(Gero & Kannengiesser (2004)) The situated Function-Behavior-structure framework, Design studies
25,373-391.
(Gibson (1979)) The theory of affordances, the ecological approach to visual perception
(Goel & Bhatta (2004)) Use of design patterns in analogy-based design, advanced engineering
informatics 18, 85-94
(Hubka & Eder (1996)) Design science: Introduction to the Needs, Scope and Organization of
engineering Design Knowledge, London: Springer-Verlag.
(Keuneke (1991)) Device representation: the significance of functional knowledge. IEEE expert 6(2),
22-25
(Keuneke & Allemang (1996)) Exploring the no-function-in-structure principle, Journal of
experimental & theoretical artificial intelligence 1(1), 79-89
(Kitamura & Mizoguchi (2004)) Ontology-based systematization of functional knowledge, Journal of
engineering design 15(4), 327-351
(Kitamura et al. (2004)) Deployment of ontological framework of functional design knowledge,
Advances engineering informatics 18(2), 115-127
(Klein & Lalli (1989)) Model 0A wind turbine generator FMEA, Cleveland, OH: NASA Glenn research
center
(Labib (2006)) Next generation maintenance systems: towards the design of a self-maintenance
machine. 2006 IEEE int. conf. industrial informatics, pp. 213-217
(Maier & Fadel (2001) Affordance: the fundamental concept in engineering design, ASME design
theory and methodology conference, Pittsburgh
(Maier & Fadel (2002)) Comparing function and affordances as base for design, ASME design theory
and methodology conference, Montreal
(Maier & Fadel (2003)) Affordance-based methods for design, ASME design theory and methodology
conference, Chicago
(Maier & Fadel (2006)) Understanding the complexity of design, Complex engineering systems:
science meets technology
(Maier & Fadel (2009a)) Affordance based design: a relational theory for design, Res Eng. Design
36
Mémoire Thématique
How to develop functional architectures? 2014
(Maier & Fadel (2009b)) An affordance-based approach to architectural theory, design and practice,
Design Studies 393-414
(Miles (1972)) Techniques of value analysis and engineering, New York: McGraw-Hill
(Muller (2007)) A multidisciplinary research approach, illustrated by the Boderc project, Accessed at
http://www.gaudisite.nl
(Pahl & Beitz (1996)) Engineering design: A systematic approach, 2nd ed. London: Springer-Verlag.
(Rausand (1998)) Reliability centered maintenance. Reliability engineering & system safety 60, 121132
(Shimomura et al. (1998)) Representation of design object based on the functional evolution process
model. Journal of mechanical design 120, 221-229.
(Snook & Price (1998)) Hierarchical functional reasoning, Knowledge-based systems 11, 301-309
(Stone & Wood (2000)) Development of a functional basis for design, Journal of mechanical design
122, 359-370.
(Suh (1990)) The principle of design, New York: oxford university press
(Szykman et al. (2000)) A web-based system for design artifact modeling, Design studies 21,145-165.
(Thuillier & Wippler (2011)) Finding the right problem, Large scale complex Systems and Systems if
systems engineering case studies
(Tomiyama et al. (1993)) A CAD for functional design, Annals of the CIRP 42(1), 143-146
(Tomiyama et al. (2013)) Making function modeling practically usable, AI EDAM special Issue on
functional descriptions
(Umeda et al. (1990)) Function, behavior, and structure, In Application of artificial intelligence in
engineering V
(Umeda et al. (1996)) Supporting conceptual design based on the Function-Behavior-State modeler,
Artificial intelligence for engineering design, analysis and manufacturing.
(Umeda & Tomiyama (1995)) FBS modeling: modeling scheme of function for conceptual design.
Proc. Working papers of 9th int. workshop on qualitative reasoning about physical systems, pp. 271278, Amsterdam.
(Umeda et Tomiyama (1997)) Functional reasoning in design, IEEE Expert 12(2), 42-48
(Van Wie et al. (2005)) A model of function-based representation, Artificial intelligence for
engineering design, Analysis and manufacturing 19, 89-111
(Vermaas & Eckert (2013)) On the co-existence of engineering meanings of function: four responses
and their methodological implications, AIEDAM Special Issue, summer 2013, Vol.27, No.3
37
Mémoire Thématique
How to develop functional architectures? 2014
(Wang et al. (2002)) Collaborative conceptual design state of the art and future trends, ComputerAided Design 34, 981-996
(Welch & Dixon (1992)) Representing function, behavior and structure during conceptual design,
Design theory and methodology-DTM92 pp11-18, New York ASME
(Wu et al. (2013)) A comparison of function- and affordance-based design, Proceedings of ASME 2013
International Design engineering Technical Conferences and Computers and information in
engineering conference
(Yanner & Goel (2006)) From form to function: from SBF to DSSBF. Design computing and cognition
2006 (Gero, J.S, Ed.), pp.423-441, Berlin: Springer
(Yoshioka et al. (2004)) Physical concept ontology for the knowledge intensive engineering
framework, Advanced engineering informatics 18(2), 69-127
Appendix
Table.1.Recap of all the definitions of Function, behavior and structure found in the different
reviewed approaches
Approac
h
1
Authors
Year
Notion
Definition
Umeda
Takeda
Tomiyama
Yoshikawa
199
0
Function
A description of behavior abstracted by human through recognition of the behavior in order to
utilize it
"to do something"
Behavior
Sequential one and more change of state over time
State
Structure; entity+atrribute+relation
Function
A description of behavior abstracted by human through recognition of the behavior in order to
utilize it
"to do something"
Behavior
Determined objectively by its attributes and its relations to other entities based on physical
principles
attributes and relations of an entity
Tomiyama
Umeda
Yoshikawa
199
3
State
Umeda
Tomiyama
Shimomura
Takeda
Yoshioka
Umeda
Tomiyama
38
199
5
199
8
Function
A description of behavior abstracted by human through recognition of the behavior in order to
utilize it
"to do something"
Behavior
Sequential one and more change of state over time
State
Entity+attributes+relations
Function
A description of behavior abstracted by human through recognition of the behavior for
utilization
Behavior
Sequential changes of state
State
entities, attributes of entities, and relations among entities
Mémoire Thématique
Yoshioka
Umeda
Takeda
Shimomura
Nomaguchi
Tomiyama
2
Kitamura
Mizoguchi
Kitamura
Kashiwase
Fuse
Mizoguchi
3
BhattaGoel
Goel
Bhatta
Yanner
Goel
4
5
Bracewell
Sharpe
Welch
Dixon
How to develop functional architectures? 2014
200
4
SOFTWARE
FBS modeler + KIEF: Knowledge Intensive Engineering Framework
200
4
Ontological
engineering
Behavior
Research methodology which gives us kernel conceptualization of the world of interest,
semantic constraints of concepts
together with sophisticated theories and technologies enabling accumulation of knowledge in
the real world
Conceptualization of the change of attribute value in the spatio-temporal space over time
B0 Behavior
change of an attribute value of an operand at the same location over time
B1 Behavior
B2 Behavior
Change of an attribute value of an operand from that at the input port of a device to that at
the output of the device
focus on the identity of the observed operand rather than the location
What motion is the device performing?
B3 Behavior
any behavior to another device
Function
Teleological interpretation of B1 Behavior under a given goal (Sasajima et al. 1995)
Structure
a hierarchical structure according to the grain size in the lowest level [of design]
Function
Teleological of a behavior under an intended goal
SOFTWARE
SOFAST: Sumitomo Osaka-university Function Analysis and Systematization Tool
Structure
constituent component and substances and the interactions between them
Behavior
sequences of state transitions behavioral states
Function
Schema that specifies the behavioral state the function takes as input, the behavioral state it
gives as output, and the
pointer to the internal causal behavior of the design that achieves the function
Structure
Constituted of component and substance
Function
Schema that specifies the behavioral state the function takes as input, the behavioral state it
gives as output, and the
pointer to the internal causal behavior of the design that achieves the function
Behavior
DSSBF
Specify and explain how the functions of structural elements in the device get composed into
device functions
Drawing Shape Structure Behavior Function
SOFTWARE
KRTIK IDEAL
Function
Classified as a data function, an energy function or a mass transfer function. Functions
communicate with each
other and with components via links
FESTER
Functional Embodiment Structure - Extended Recursively
SOFTWARE
Schemebuilder
Function
A set of causal relationships between physical parameters. Describing the outward physical
action of a device
Behavior
Mean the detailed description of internal physical action based on established physical
principles phenomena
No Name
200
4
199
4
200
4
200
6
199
6
199
4
SOFTWARE
39
Mémoire Thématique
6
Deng
Britton
Tor
How to develop functional architectures? 2014
200
0
Simple Function
specifying a set of physical structures (objects) that can achieve that function
Complex function
Requires a full specification of the behavioral process that can produce the function, the
physical structure that can perform
the process, and the working environment
represented by a set of driving inputs (required physical interactions from its source
environment to the design), and a
set of functional output (desired physical interactions from the design to its target
environment
Geometric relations and physical interactions are defined within the structure, that is,
between the physical components
of the design
Behavior
Structure
Deng
7
8
9
ChakrabartiBlig
h
Van Wie
Bryant
Bohm
McAdams
Gero
Tham
Lee
Rosenman
Gero
40
200
2
200
1
200
5
199
2
199
8
Action
A physical interaction between two objects of interest, each if which may be a component of a
design or the design itself and its environment
Purpose Function
A description of the designer's intention or the purpose if the design
Action function
an abstraction of intended and useful behavior that an artifact exhibits
Semantic repres
An action function can be represented by an input-output flow transformation (energy,
material, and signal) and an
initial-ending state transformation
Syntactic repres
The instantiation and embodiment of a semantic representation
Behavior
3 semantic representation of behavior:
1) Input-output flow of object: intended/unintended input, intended/unintended output
(object=energy/material/signal)
2) input-output flow of action: driving input, harmful input, functional output, side effect
3) State transition: a chain or a network of physical states
SOFTWARE
No Name
Function
A description of the action or effect required by a design problem, or that supplied by a
solution
Functional
representation
Describe design problems and solutions in term of their functions
1) natural-language-like
2)mathematical representation
SOFTWARE
IDEA-INSPIRE
Function
Physical effect imposed on an energy or a material flow by a design entity without regard of
the working principles or
physical solutions used to accomplish this effect
Behavior
Physical events associated with physical artifact (or hypothesized concept) overt time (or
simulated time) as perceived
by an observer
Structure
Most tangible concept, partitions of an artifact into meaningful constituents such as features,
Wirk elements, and interfaces in addition to the widely used assemblies and components
Function
The design intentions or purpose
Behavior
How the structure of an artifact achieves its functions
Structure
The components which make up an artifact and their relationships
Function
The result of the artifact's behaviors
Mémoire Thématique
How to develop functional architectures? 2014
Gero
10
11
Snooke
Price
Chandrasekara
n
Josephson
200
2
199
8
200
0
Behavior
The artifact's actions or processes in given circumstances of the natural environment
Structure
Functions
The elements of the artifact, the material arrangement of these elements and their
connectivity
The purpose of the design being used, i.e. its teleology
Behavior
Attributes derivable from structure or expected of structure
Structure
The elements of an artifacts and their relationships
Functional label
Provide an abstraction of some aspects of what a system is designed for
AutoSteve syst
Single level of functional abstraction to summaries the state of a circuit in the a car
Structure relations
Categories the relations in the initial configuration into those that remain stable through
causal interactions of interest, and those that can change during such interactions
Structure
Basic interaction framework, within which other, temporary, interactions take place
Behavior 1
The values or relations between values of state variables of interest at a particular instant
Behavior 2
The values or relations between values of properties of an object
Behavior 3
The values of state variables of interest over an interval of time
Behavior 4
The values of state variables specifically labeled 'output' state variables, either et an instant or
over an interval of time
The values of all the state variables in the object description, either at an instant or over an
interval of time
The causal rules that describe the values of the variables under various conditions
Behavior 5
Behavior 6
Function
1)Device-centric: device's properties or behavior
2) Environment-centric: What the device might help achieve in the world outside it
Function
Relationship between inputs and outputs, and hence changes in the magnitudes of the system
variables
Behavior
Boundaries which cut across the system's links with the environment. These links determine
the external behavior of the system, so that it is possible to define a function
Structure
Sizes and arrangements of parts assemblies are varied within the limits set by the designed
product
The independence axiom
Alternate statement 1: An optimal design always maintain the independence of FRs
Alternate statement 2: In an acceptable design, the DPs and the FRs are related in such way
that specific DP can be adjusted to satisfy its corresponding FR without affecting other
functional requirements
12
13
14
15
16
Pahl
Beitz
Suh
199
0
Miles
De Kleer
Brown
41
198
8
197
2
198
4
Axiom 1
Axiom 2
The information axiom
Alternate statement: The best design in a functionally uncoupled design that has minimum
information content
Function
To do something
Value
Price
Value Engineering
Comparing the value of function with respect to the cost of the product
Function
What the device is for
Behavior
What the device does
Structure
What the device is
Mémoire Thématique
17
Forbus
18
How to develop functional architectures? 2014
198
4
Qualitative process
theory
1) Means to draw several types of basic, qualitative, deduction, including describing what is
happening in a physical situation
2) model several interesting physical phenomena for commonsense reasoning
3) Provides highly constrained account of physical causality changes
4) Provides a structured role for the use of experiential and default knowledge in physical
reasoning
5) Partially specifies a language for writing qualitative dynamics theories.
Klein
Lalli
198
9
FMEA
Failure Mode and Effect Analysis
Labib
200
8
NGMS
Next Generation Maintenance Systems
42
Mémoire Thématique
How to develop functional architectures? 2014
Table.2. Working Affordance Basis (Cormier et al. (2013))
43
Mémoire Thématique
How to develop functional architectures? 2014
Table.3. Adaptation of the Generic Affordance Structure from Maier and Fadel into the Affordance
Basis (Cormier et al. (2013))
44
Mémoire Thématique